An AHV cluster is running more allocated VM memory than physical host memory, and guests begin reporting poor performance. Which metric best indicates that memory overcommit is causing guest-level contention?
Select an answer to reveal the explanation.
Short Explanation
Think of memory overcommit like overselling seats on a flight: it works until everyone shows up. If your AHV guests start inflating their balloon drivers, that’s the hypervisor politely asking VMs to give pages back under pressure. Watch that balloon growth, not disk latency, when you’re hunting memory contention.
Full Explanation
Memory overcommit on AHV becomes a workload risk when the sum of VM configured and active memory exceeds the physical memory available to the hypervisor after host and CVM overhead. The balloon driver is the guest-visible control surface for reclaiming memory: as host pressure rises, AHV can inflate the balloon inside a VM, reducing usable guest memory and forcing the guest OS to page or throttle allocations. Sustained balloon inflation is therefore the relevant metric for identifying overcommit-driven contention, especially when paired with host memory pressure and per-VM balloon activity. Disk read latency reflects storage path, queue depth, or disk performance, not host memory reclamation. CPU ready time signals scheduler delay from CPU oversubscription or CPU affinity/reservation mismatches, not memory ballooning. Container free space is a capacity metric for storage pools and does not reveal whether guests are being forced to surrender pages to the hypervisor. Exam caveat: distinguish host memory pressure from guest OS memory pressure; ballooning proves the hypervisor is reclaiming memory, not merely that a guest is using RAM. Operational check: review AHV host memory utilization and per-VM balloon metrics in Prism, then compare configured VM memory against available host memory and adjust reservations, affinity, or host capacity before adding workloads.