[libvirt] [PATCH 8/8] docs: Improve documentation related to memory locking

Luiz Capitulino lcapitulino at redhat.com
Fri Mar 24 17:58:58 UTC 2017


On Thu, 23 Mar 2017 19:16:47 +0100
Andrea Bolognani <abologna at redhat.com> wrote:

> ---
>  docs/formatdomain.html.in | 36 +++++++++++++++++++++++-------------
>  1 file changed, 23 insertions(+), 13 deletions(-)
> 
> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
> index 4a3123e..5906de6 100644
> --- a/docs/formatdomain.html.in
> +++ b/docs/formatdomain.html.in
> @@ -937,14 +937,18 @@
>        <dt><code>locked</code></dt>
>        <dd>When set and supported by the hypervisor, memory pages belonging
>          to the domain will be locked in host's memory and the host will not
> -        be allowed to swap them out. For QEMU/KVM this requires
> -        <code>hard_limit</code> <a href="#elementsMemoryTuning">memory tuning</a>
> -        element to be used and set to the maximum memory configured for the
> -        domain plus any memory consumed by the QEMU process itself. Beware of
> -        setting the memory limit too high (and thus allowing the domain to lock
> -        most of the host's memory). Doing so may be dangerous to both the
> -        domain and the host itself since the host's kernel may run out of
> -        memory. <span class="since">Since 1.0.6</span></dd>
> +        be allowed to swap them out, which might be required for some
> +        workloads such as RT. For QEMU/KVM guests, the memory used by the QEMU

Minor, but I'd do s/RT/real-time. As this doc is for the general population,
RT may not be a know term for everyone.

> +        process itself will be locked too: unlike guest memory, this is an
> +        amount libvirt has no way of figuring out in advance, so it has to
> +        remove the limit on locked memory altogether. This can be very
> +        dangerous as the host might run out of memory and be unable to reclaim
> +        it from the guest,

I'd rewrite this to:

"""
This option has a drawback and a possible security risk for the host. If
the host is running out of memory, it will be unable to reclaim the
memory locked by this guest which could cause the host to run out of
memory. In particular, a malicious guest could be able to lock as much
memory it wants, causing a DDoS attack in the host. For setups where
this may have a significant impact, it is highly recommended to use
<hard_limit> to prevent this attack.
"""

> so using this option is discouraged unless your
> +        workload demands it; even then, it's highly recommended to set an
> +        <code>hard_limit</code> (see
> +        <a href="#elementsMemoryTuning">memory tuning</a>) on memory allocation
> +        suitable for the specific environment at the same time to mitigate
> +        the risks described above. <span class="since">Since 1.0.6</span></dd>
>         <dt><code>source</code></dt>
>         <dd>In this attribute you can switch to file memorybacking or keep default anonymous.</dd>
>         <dt><code>access</code></dt>
> @@ -989,12 +993,18 @@
>        <dt><code>hard_limit</code></dt>
>        <dd> The optional <code>hard_limit</code> element is the maximum memory
>          the guest can use. The units for this value are kibibytes (i.e. blocks
> -        of 1024 bytes). <strong>However, users of QEMU and KVM are strongly
> -        advised not to set this limit as domain may get killed by the kernel
> -        if the guess is too low. To determine the memory needed for a process
> -        to run is an
> +        of 1024 bytes). Users of QEMU and KVM are strongly advised not to set
> +        this limit as domain may get killed by the kernel if the guess is too
> +        low, and determining the memory needed for a process to run is an
>          <a href="http://en.wikipedia.org/wiki/Undecidable_problem">
> -        undecidable problem</a>.</strong></dd>
> +        undecidable problem</a>; that said, if you already set
> +        <code>locked</code> in
> +        <a href="#elementsMemoryBacking">memory backing</a> because your
> +        workload demands it, you'll have to take into account the specifics of
> +        your deployment and figure out a value for <code>hard_limit</code> that
> +        balances the risk of your guest being killed because the limit was set
> +        too low and the risk of your host crashing because it cannot reclaim
> +        the memory used by the guest due to <code>locked</code>. Good luck!</dd>
>        <dt><code>soft_limit</code></dt>
>        <dd> The optional <code>soft_limit</code> element is the memory limit to
>          enforce during memory contention. The units for this value are




More information about the libvir-list mailing list