On Tue, 14 Mar 2017 20:28:12 +0100
Andrea Bolognani <abologna(a)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.