使用 kvm/libvirt 過度送出“MaxMemory”是否安全？
在 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”（參考）設置在主機的總物理記憶體之上是否安全？
想像一下這樣的情況：
- 主機有 8GB 的 RAM
- VM 配置有 16GB 的“MaxMemory”和 4GB 的“currentMemory”
… VM 是否有可能以任何方式利用超過 currentMemory 來使主機崩潰，尤其是在啟動過程中？
引用引用的連結，“currentMemory”指的是：
來賓的實際記憶體分配。
這似乎暗示虛擬機記憶體使用的真正限制是“currentMemory”；然而，這句話：
來賓的執行時最大記憶體分配。
…這是指“MaxMemory”類暗示“在執行時”也許它可以使用比 currentMemory 更多的東西？
有人可以對此有所了解嗎？我假設這一切正常的方式是KVM啟動VM並告訴它它有可用的“MaxMemory”，然後不久之後告訴VM它只能使用“currentMemory”。我擔心那裡可能存在一些競爭條件，VM 可能被允許快速聲明“MaxMemory”。儘管我想即使它確實如此，OOM Killer 也可能只會殺死主機上的 VM 程序。
我想這樣做的原因是，我可以實時遷移到可能提供 16GB 的“currentMemory”的其他主機，即使它在最初配置 VM 的主機上是不可能的。
當客戶機第一次啟動時，它會看到註冊了 MaxMemory 價值的 RAM，理論上此時可以使用它。當客戶機中的氣球驅動程序載入時，它會將客戶機 RAM 減少到 CurrentMemory。至少對於 Linux 來賓，在氣球驅動程序載入之前，來賓永遠不會真正觸及 MaxMemory 允許的所有 RAM，因此您不應該冒主機記憶體壓力的風險。一些客戶作業系統（至少是某些版本的 Windows）喜歡在啟動時將所有 RAM 頁面歸零，這可能導致 QEMU 消耗完整的 MaxMemory。此外，如果來賓中沒有載入氣球驅動程序，它永遠不會將其 RAM 減少到 CurrentMemory 級別。此外，如果來賓是惡意的，它可以選擇不遵守 CurrentMemory 級別，而忽略氣球請求。
本質上，如果您使用的是受信任的 Linux 客戶機並且客戶機中有氣球驅動程序（它應該在任何現代 Linux 作業系統中預設存在），那麼您應該沒問題。