在 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.
设置“MaxMemory”是否安全(参考) 高于主机的总物理内存,如果“currentMemory”永远不会超过主机上的实际可用内存?
想象一下这样的情况:
- 主机有 8GB RAM
- VM 配置了 16GB 的“MaxMemory”和 4GB 的“currentMemory”
...虚拟机是否有可能以任何方式利用超过当前内存的内存来导致主机崩溃,尤其是在启动过程中?
引用参考链接,“currentMemory”指的是:
客户机的实际内存分配。
这似乎意味着真实的VM 内存使用的限制是“currentMemory”;但是,这句话:
客户机运行时最大内存分配。
... 这是关于“MaxMemory”的引用,暗示“在运行时”也许它可以使用比 currentMemory 更多的内存?
有人能解释一下吗?我假设这一切的工作原理是 KVM 启动虚拟机并告诉它有可用的“MaxMemory”,然后不久后告诉虚拟机它只能使用“currentMemory”。我担心那里可能存在一点竞争条件,虚拟机可能被允许快速索取“MaxMemory”。不过我想即使这样,OOM Killer 也可能只会在主机上终止虚拟机的进程。
我想要这样做的原因是为了能够实时迁移到其他可能提供 16GB“currentMemory”的主机,即使在最初配置虚拟机的主机上无法做到这一点。
答案1
当客户机首次启动时,它将看到已注册的 MaxMemory 大小的 RAM,理论上此时可以使用它。当客户机中的气球驱动程序加载时,它将客户机 RAM 减少到 CurrentMemory。至少对于 Linux 客户机,在气球驱动程序加载之前,客户机永远不会真正接触 MaxMemory 允许的所有 RAM,因此您不应该冒主机内存压力的风险。某些客户机操作系统(至少是某些版本的 Windows)喜欢在启动时将所有 RAM 页面清零,这可能会导致 QEMU 消耗完整的 MaxMemory。此外,如果客户机中未加载气球驱动程序,它永远不会将其 RAM 减少到 CurrentMemory 级别。此外,如果客户机是恶意的,它可以选择不遵守 CurrentMemory 级别,只是忽略气球请求。
本质上,如果您使用的是受信任的 Linux 客户机,并且在客户机中具有气球驱动程序(它应该在任何现代 Linux 操作系统中默认存在),那么您应该没问题。