[libvirt] [BUG] mlock support breakage

[Luiz Capitulino]

On Mon, 13 Mar 2017 16:08:58 +0000
"Daniel P. Berrange" <berrange at 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.