[libvirt] [BUG] mlock support breakage

[Andrea Bolognani]

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 ;)

> > 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.

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.

> PS: Still, we should have "unlimited" support for <hard_limit>

Definitely.

-- 
Andrea Bolognani / Red Hat / Virtualization