On Tue, 14 Mar 2017 20:28:12 +0100 Andrea Bolognani <abologna@xxxxxxxxxx> 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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
