Re: [libvirt] [BUG] mlock support breakage
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