在Ubuntu 16.04上使用Libvirt / KVM
Compiled against library: libvirt 1.3.1 Using library: libvirt 1.3.1 Using API: QEMU 1.3.1 Running hypervisor: QEMU 2.5.0 # dpkg -s qemu-kvm | grep Version Version: 1:2.5+dfsg-5ubuntu10. 如果“currentMemory”永远不会超过主机上的实际可用内存，那么将“MaxMemory”（ 参考 ）设置为高于主机的总物理内存是否安全？
想象一下这样的情况：
……虚拟机有可能以多种方式利用currentMemory来使主机崩溃，特别是在启动过程中？
从引用的链接引用，“currentMemory”是指：
客人的实际内存分配。
这似乎意味着VM的内存使用的真正限制是“currentMemory”; 不过，这句话：
客户的运行时间最大内存分配。
…参考“MaxMemory”的意思是“在运行时间”，也许它可以使用多于currentMemory？
有人可以解释一下吗？ 我认为这样做的一个方法就是KVM启动虚拟机并告诉它有可用的“MaxMemory”，然后不久之后告诉虚拟机它只能使用“currentMemory”。 我担心在那里虚拟机可能会被允许快速声明“MaxMemory”。 尽pipe我猜想即使这样做，OOM Killer也可能会杀死虚拟机在主机上的进程。
我想这样做的原因是，我可以实时迁移到其他主机，即使在虚拟机最初configuration的主机上不可能，也可以提供16GB的“currentMemory”。
当客人第一次启动时，它会看到MaxMemory值的内存已注册，理论上可以在这个时候使用它。 当客户端中的气球驱动程序加载时，它会将客户RAM减less到CurrentMemory。 至less对于Linux客户来说，在气球驱动程序加载之前，客人永远不会碰到MaxMemory所允许的所有内存，所以您不应该冒主机内存压力的风险。 某些客户操作系统（至less某些版本的Windows）喜欢在启动时清零所有的RAM页面，这可能会导致QEMU消耗完整的MaxMemory。 而且，如果guest虚拟机中没有加载气球驱动程序，它将永远不会将其RAM降低到CurrentMemory级别。 此外，如果客人是恶意的，它可以select不尊重CurrentMemory级别只是忽略气球请求。
从本质上讲，如果你使用可信的Linux guest，并且在guest虚拟机中有气球驱动程序（在任何现代Linux操作系统中都应该默认使用），那么你应该没问题。