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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
