composed KVM guests could be created with maxmem > mem

[Andrea Ieri]

Composed KVM virtual machines are currently created with mem == maxmem. The consequence is that if one of these virtual machines needs to subsequently be resized (which is likely to happen at some point during the life of a cloud), it will have to be stopped and started. Having a higher maxmem would allow operators to live-update ram in VMs, reducing downtime. For this reason it would be great if maas pods composed machines with a higher maxmem value, and possibly set it by default to something reasonable.

More specifically:

Let's say I have a KVM guest with 8GB of RAM assigned. I now realize this is too small, and I want to double its RAM to 16GB. With maxmem == mem I have to run the following:

* virsh setmaxmem <domain> <16GB_or_more> --config
* virsh setmem <domain> 16GB --config
* shutdown the VM
* virsh start <domain>

If the KVM guest had however been originally created with (for example) maxmem = 4*mem, I would be able to do the following instead and avoid a reboot:

* virsh setmem <domain> 16GB --live

[Alberto Donato (ack)]

You can set memory (and cpu) overcommit in the settings tab of the POD once it's been added to maas.

Setting a higher overcommit ratio will increase the maximum "available" memory and let you set a higher limit for VMs.

Would that work for your use case?

[Andrea Ieri (aieri)]

Hi Alberto, I have realized I've been using the wrong terminology, which could have caused confusion. I have now updated the bug description and title; my use case should now hopefully be clear.

Would tweaking the pod overcommit ratio help, and if so would it affect already running VMs?

[Alberto Donato (ack)]

Hi Andrea, could you please paste an example of "virsh dumpxml <domain>" for a VM before and after the setmaxem/setmem commands?

[Andrea Ieri (aieri)]

Here you go:

$ virsh dominfo ubuntu18.04
Id: 1
Name: ubuntu18.04
UUID: 8e37b057-d5f5-41a2-84ef-075a17bd6ba6
OS Type: hvm
State: running
CPU(s): 1
CPU time: 11.5s
Max memory: 2097152 KiB
Used memory: 2097152 KiB
Persistent: yes
Autostart: disable
Managed save: no
Security model: apparmor
Security DOI: 0
Security label: libvirt-8e37b057-d5f5-41a2-84ef-075a17bd6ba6 (enforcing)

$ virsh dumpxml ubuntu18.04 > /tmp/bionic-t0.xml
$ virsh setmaxmem ubuntu18.04 8GB --config
$ virsh setmem ubuntu18.04 4GB --config

[... reboot VM ...]

$ virsh dumpxml ubuntu18.04 > /tmp/bionic-t1.xml

As you can see the only things that change are the memory and currentMemory parameters.

[Alberto Donato (ack)]

Currently, MAAS only specified <memory> when composing a VM, it doesn't do currentMemory.

So IIUC what you want could be achieved by starting with a bigger memory (and possibly incresing the overcommit ratio so that it doesn't affect availability for other machines) and then tune the currentMemory down to the current use.

I realize this is not ideal, to do this properly (whithout having to tweak the machine manually via virsh) MAAS would have to allow specifying memory/currentMemory separately.

[Jerzy Husakowski (jhusakowski)]

Moved the feature request to the internal product feedback board for further prioritisation.