A capacity planner sees 15% free memory on a four-node AHV cluster and wants to place 20 more steady-state VMs without buying hardware. Increasing memory oversubscription would allow placement, but what should the planner do first?
Select an answer to reveal the explanation.
Short Explanation
Think of memory oversubscription like squeezing more passengers into an elevator: it works right up until the load starts slowing every trip. You want to see the gauges—pressure, swapping, SLA headroom—before you promise more seats. That way capacity gains don't turn into a noisy support ticket.
Full Explanation
Memory oversubscription increases usable VM capacity by allowing allocated vRAM to exceed physical RAM, but it only works while the combined working set stays below available memory and latency-sensitive workloads tolerate reclaim. Capacity planning should treat oversubscription as a risk trade-off: confirm current pressure, balloon and swap trends, and SLA headroom before promising more VMs. The reactive plan of letting free memory reach zero and adding nodes after ballooning or swapping is wrong because degradation occurs before hardware is purchased, and runway forecasting requires proactive thresholds. The CPU-overcommit idea is wrong because CPU scheduling cannot remove memory reclaim cost; memory pressure directly affects guest responsiveness and can increase I/O and CPU overhead. The uniform reservation-disabling approach is wrong because reservations protect critical workloads and different projects have different tolerance for reclaim, so blanket settings ignore workload tiers and contractual performance. Exam caveat: do not assume a higher oversubscription ratio is safe merely because Prism reports capacity headroom. Operational check: review Prism memory pressure and guest balloon or swap metrics for the busiest projects, then model the proposed VM count against peak working set and SLA latency targets.