Summary
When series enforces one-VM-at-a-time by stopping the other running guest, suspending a large guest shuffles gigabytes of RAM to/from disk and keeps competing for host memory during the handoff. A clean shutdown frees the guest's RAM faster and avoids the thrash window.
Evidence
In portzero run 30092755473, >> stopping other running VM: Windows 11 Pro took ~15 minutes and coincided with the host OOM-killing a test subprocess (see #3). A suspend of a multi-GB Windows guest is exactly the operation that both takes long and holds memory.
Proposed behavior
- For the one-VM-at-a-time stop, prefer a hard/clean shutdown (
prlctl stop <vm>) over suspend (prlctl suspend <vm>), so the guest's RAM is returned to the host promptly.
- Make the stop mode configurable (e.g.
VMKIT_STOP_MODE=shutdown|suspend or a host.conf key), since suspend is nicer for a developer's interactive VMs but worse for CI throughput/stability.
- Default to
shutdown in CI contexts if a clean signal is available.
Trade-off worth noting in docs: shutdown loses the guest's in-memory state (slower cold boot next time), which is fine for the reset-to-snapshot E2E flow but not for interactive use — hence configurable.
Related: #3.
Summary
When
seriesenforces one-VM-at-a-time by stopping the other running guest, suspending a large guest shuffles gigabytes of RAM to/from disk and keeps competing for host memory during the handoff. A clean shutdown frees the guest's RAM faster and avoids the thrash window.Evidence
In
portzerorun 30092755473,>> stopping other running VM: Windows 11 Protook ~15 minutes and coincided with the host OOM-killing a test subprocess (see #3). A suspend of a multi-GB Windows guest is exactly the operation that both takes long and holds memory.Proposed behavior
prlctl stop <vm>) over suspend (prlctl suspend <vm>), so the guest's RAM is returned to the host promptly.VMKIT_STOP_MODE=shutdown|suspendor ahost.confkey), since suspend is nicer for a developer's interactive VMs but worse for CI throughput/stability.shutdownin CI contexts if a clean signal is available.Trade-off worth noting in docs: shutdown loses the guest's in-memory state (slower cold boot next time), which is fine for the reset-to-snapshot E2E flow but not for interactive use — hence configurable.
Related: #3.