On Fri, 2017-03-24 at 13:58 -0400, Luiz Capitulino wrote: [...]
+ 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.
Sure.
+ 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. """
Another stab at it (which plugs into my original version): [...] remove the limit on locked memory altogether. Thus, enabling this option opens up to a potential security risk: the host will be unable to reclaim the locked memory back from the guest when it's running out of memory, which means a malicious guest allocating large amounts of locked memory could cause a denial-of-service attach on the host. Because of this, using the option is discouraged unless your [...] Does it look reasonable? -- Andrea Bolognani / Red Hat / Virtualization