Hide Forgot
Description of problem: The guest kernel will panic when set memory on the active guest. Version-Release number of selected component (if applicable): # rpm -q libvirt libvirt-0.8.7-7.el6.x86_64 # rpm -q qemu-kvm qemu-kvm-0.12.1.2-2.145.el6.x86_64 # uname -r 2.6.32-113.el6.x86_6 How reproducible: always Steps to Reproduce: 1. virsh start domainname 2. virsh setmem domainname --kilobytes 131072 3. virt-viewer domainname Actual results: kernel panic Expected results: fix it Additional info: # virsh dominfo vr-rhel6u1-x86_64-kvm Id: 25 Name: vr-rhel6u1-x86_64-kvm UUID: a03093a1-5da6-a2a2-3baf-a845db2f10b9 OS Type: hvm State: running CPU(s): 1 CPU time: 1193.6s Max memory: 2097152 kB Used memory: 1048576 kB Persistent: yes Autostart: disable Security model: selinux Security DOI: 0 Security label: system_u:system_r:svirt_t:s0:c104,c286 (permissive) # virsh memtune vr-rhel6u1-x86_64-kvm hard_limit : unlimited soft_limit : unlimited swap_hard_limit: unlimited # virsh setmem vr-rhel6u1-x86_64-kvm --kilobytes 131072 # virsh dominfo vr-rhel6u1-x86_64-kvm Id: 25 Name: vr-rhel6u1-x86_64-kvm UUID: a03093a1-5da6-a2a2-3baf-a845db2f10b9 OS Type: hvm State: running CPU(s): 1 CPU time: 1225.2s Max memory: 2097152 kB Used memory: 194492 kB Persistent: yes Autostart: disable Security model: selinux Security DOI: 0 Security label: system_u:system_r:svirt_t:s0:c104,c286 (permissive) # virt-viewer vr-rhel6u1-x86_64-kvm Note: current used memory does change, but use virt-viewer to check guest screen, which display Out of memory and kernel panic...
Created attachment 480795 [details] virtio_balloon driver
Created attachment 480796 [details] guest screen
That's the dark side of memory ballooning. If you want to shrink too much your guest may get into an OOM condition and start killing processes like crazy. Frankly, decreasing memory from 2GB to 128MB really sounds like too much to me. It's hard to find a general rule what amount of memory is still ok and what is already not enough for a guest so I don't think we can really do anything useful with this in libvirt. The user (of libvirt API, so it can even be an application higher in the stack) should know what the guest OS is, what processes need to run in it and what the memory consumption should look like. I'm inclined to close this as CANTFIX although I'll wait a bit in case someone else has a better suggestion.
Agreed, we have tried to set a minimum limit in the past, but had to remove it precisely because it will always be wrong for at least one person's valid use case.