[libvirt] [BUG] mlock support breakage

[Andrea Bolognani]

On Tue, 2017-03-14 at 15:55 +0100, Peter Krempa wrote:
> > NB if we did enforce $RAM + $LARGE_NUMBER, then I'd suggest we did
> > set a default hard_limit universally once more, not only set a mlock
> 
> We were already attempting to do this and we reverted it since there's
> no deterministic $LARGE_NUMBER which would work for all cases.
> 
> I can imagine this working if $LARGE_NUMBER is infinity or host
> memory+swap size.
> 
> commit 16bcb3b61675a88bff00317336b9610080c31000
> Author: Michal Privoznik <mprivozn at redhat.com>
> Date:   Fri Aug 9 14:46:54 2013 +0200
> 
>     qemu: Drop qemuDomainMemoryLimit
>     
>     This function is to guess the correct limit for maximal memory
>     usage by qemu for given domain. This can never be guessed
>     correctly, not to mention all the pains and sleepless nights this
>     code has caused. Once somebody discovers algorithm to solve the
>     Halting Problem, we can compute the limit algorithmically. But
>     till then, this code should never see the light of the release
>     again.

Right.

Even the current accidental limit, guest memory + 1 GiB,
doesn't give any real guarantee about the guests working
in the future: a simple QEMU upgrade could be enough to
push memory usage past the current allowance and cause
them to crash. Peter mentioned that just adding (a lot)
more disks could actually be enough.

Even for the host admin, setting the memory limits
appropriately will always be a balancing act between
making sure the host can swap out guests when pressured
for memory and making sure the guests themselves can
allocate the memory they need. Different use cases will
call for different balances, and since there is no
one-size-fits-all solution we shouldn't pretend that
this complexity doesn't exist and hide it from the
administrator.

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'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.

-- 
Andrea Bolognani / Red Hat / Virtualization