On Tue, 14 Mar 2017 19:40:38 +0100 Andrea Bolognani <abologna@xxxxxxxxxx> 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. > it's arguably better than illuding people their guests > will be good in the long run while in reality we can't > provide such guarantee. > > 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. PS: Still, we should have "unlimited" support for <hard_limit> -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
