On Mon, 13 Mar 2017 16:08:58 +0000 "Daniel P. Berrange" <berrange@redhat.com> wrote:
On Mon, Mar 13, 2017 at 11:58:24AM -0400, Luiz Capitulino wrote:
Libvirt commit c2e60ad0e51 added a new check to the XML validation logic where XMLs containing <memoryBacking><mlocked/> must also contain <memtune><hard_limit>. This causes two breakages where working guests won't start anymore:
1. Systems where mlock limit was set in /etc/security/limits.conf
I'm surprised if that has any effect, unless you were setting it against the root user.
The limits.conf file is loaded by PAM, and when libvirtd spawns QEMU, PAM is not involved, so limits.conf will never be activated.
This is why libvirt provides max_processes/max_files/max_core settings in /etc/libvirt/qemu.conf - you can't set those in limits.conf and have them work - unless you set them against root, so libvirtd itself got the higher limits which are then inherited by QEMU.
My quick test seemed to work, but I may have declared success before the guest had time to crash. I'll double check this, but we agree about the best way to fix it.
2. Drop change c2e60ad0e51 and automtically increase memory locking limit to infinity when seeing <memoryBacking><locked/>
pros: make all cases work, no more <hard_limit> requirement
cons: allows guests with <locked/> to lock all memory assigned to them plus QEMU allocations. While this seems undesirable or even a security issue, using <hard_limit> will have the same effect
I think this is the only viable approach, given that no one can provide a way to reliably calculate QEMU peak memory usage. Unless we want to take guest RAM + $LARGE NUMBER - eg just blindly assume that 2 GB is enough for QEMU working set, so for an 8 GB guest, just set 10 GB as the limit.
Better to set it to infinity and be done with it.
Lastly, <locked/> doesn't belong to <memoryBacking>, it should be in <memtune>. I recommend deprecating it from <memoryBacking> and adding it where it belongs.
We never make these kind of changes in libvirt XML. It is sub-optimal location, but it has no functional problem, so there's no functional benefit to moving it and clear backcompat downsides.
Fine with me.