During performance analysis, an AHV VM shows an inflated balloon driver and increased guest swapping while disk latency and network packet loss remain normal. Which condition most likely explains the VM's degraded performance?
Select an answer to reveal the explanation.
Short Explanation
Think of ballooning like a landlord asking a tenant to hand back RAM when the host is oversold. If you see balloon counters rising while storage and network counters stay quiet, the bottleneck is memory pressure, not disk or network. That is why host memory overcommit is the answer here.
Full Explanation
When AHV has less available host memory than the aggregate demand from powered-on VMs, it can reclaim guest memory through the balloon driver. The guest OS then sees less usable RAM, increases paging or swapping, and application latency rises even though disk and network paths may look healthy. This is memory overcommit: the constraint is physical or reserved memory on the host, not the storage container or network bridge. Storage container latency from Curator would primarily appear as elevated disk latency, queue depth, or I/O wait, and it would not by itself inflate a balloon driver. CPU oversubscription on the host produces CPU ready, steal, or scheduler contention symptoms, which are distinct from ballooning counters and guest swap activity. Network packet drops on the bridge show up as packet loss, retransmissions, or throughput loss, not as hypervisor memory reclamation. Exam caveat: ballooning can be a normal safety valve under memory pressure, so the key is correlating it with degraded VM performance and host memory headroom. Operational check: compare the VM's balloon size, guest memory usage, host free memory, and any memory reservations or limits in Prism before increasing workload placement pressure.