On Mon, 13 Mar 2017 16:08:58 +0000 "Daniel P. Berrange" <berrange@xxxxxxxxxx> 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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
