[libvirt] [BUG] mlock support breakage

[Luiz Capitulino]

On Tue, 14 Mar 2017 20:28:12 +0100
Andrea Bolognani <abologna at redhat.com> wrote:

> On Tue, 2017-03-14 at 14:54 -0400, Luiz Capitulino wrote:
> > > It's unfortunate that the current, buggy behavior made
> > > it look like you didn't necessarily have to worry about
> > > this. If we fix it, existing guests will fail to start
> > > right away instead of possibly crashing in the future:
> > > while that's going to be very annoying in the short run,  
> > 
> > It breaks existing guests, so it's beyond annoying.  
> 
> Existing guests are already broken, it's just that the
> breakage has not hit them yet ;)

We should prevent that from happening.

> > > Luiz mentioned the fact that you can't set the memory
> > > locking limit to "unlimited" with the current <hard_limit>
> > > element: that's something we can, and should, address.
> > > With that implemented, the administrator will have full
> > > control on the memory limit and will be able to implement
> > > the policy that best suits the use case at hand.  
> > 
> > Asking <locked/> users to set <hard_limit> to "unlimited"
> > is a much worse solution than automatically setting the
> > memory lock limit to infinity in libvirt, for the reasons
> > I outlined in my first email.  
> 
> Removing all memory locking limits should be something that
> admins very carefully opt-in into, because of the potential
> host DoS consequences. Certainly not the default.

There's no opt-in with <locked/>, it is mandatory to increase
the mlock limit. Asking users to do this themselves is only
adding an extra step that's causing breakage right now.

> That's the same with /etc/security/limits.conf, where the
> default memory locking limit is extremely low (64 KiB) and
> the admin can decide to raise it or even remove it entirely
> if needed.

But that's a bad example, we have to help our users not
contribute to make their life miserable.

Users want to use <locked/> without having to guess limits
that we can't figure out ourselves.