The 3.3:1 Overcommit That Wasn't the Problem
A customer sends their design for review before you teach a three-day vSphere course that will use their environment as the running example. The cluster has three hosts, each with two 16-core processors and 768 GB of RAM. Forty production VMs run there, each configured with 8 vCPU and 32 GB of memory. Measured CPU demand averages about 35% of configured vCPU, and guests hold roughly 70% of their memory active. Shared iSCSI storage has ample free space. The customer wants N+1 host-failure tolerance through vSphere HA and insists on keeping at least 20% of post-failure capacity free for growth. Their written claim reads: "CPU overcommit of 3.3:1 is the limiting factor, so the budget must go to CPU." You have 25 minutes to prepare a correction before the review call.
1. Which resource is actually binding? Show the arithmetic and explain what the customer's own numbers prove.
Read the worked answer
Memory is binding; CPU is not.
- Configured memory: 40 x 32 GB = 1,280 GB.
- Post-failure capacity (2 of 3 hosts): 2 x 768 = 1,536 GB.
- Slack after one host loss: 1,536 - 1,280 = 256 GB, which is 16.7% of post-failure capacity.
- The stated 20% requirement needs 1,280 / 0.8 = 1,600 GB, so the design is roughly 64 GB short after a single host failure.
CPU: 320 configured vCPU against 96 physical cores is a 3.3:1 ratio, which sounds alarming, but the measured 35% demand is about 112 vCPU of real work. After a host loss those 112 vCPU-equivalents sit on 64 cores - a 1.75:1 demand ratio, which is comfortable.
The customer's mistake is comparing configured vCPU with cores while ignoring the demand figure they supplied themselves. Note also that HA admission control reserves configured or reserved memory, not the 70% active figure, so the 70% number does not rescue the design - it only explains why guests are not yet swapping. Evidence that would change this verdict: sustained CPU ready above about 5%, or measured demand above 60% of configured vCPU.
2. Which vSphere HA admission control policy should they use for this cluster, and why is the other natural choice wrong here?
Read the worked answer
Use cluster resource percentage, set to roughly 33% (one of three hosts). Treat the 20% growth margin as a separate business test, not as a second admission-control setting - the two are routinely conflated and that conflation is what produces arguments like this one.
Why slot policy fails: slot size is driven by the largest VM, here 8 vCPU and 32 GB. Per host, slots are limited by CPU, not memory: 32 cores / 8 vCPU = 4 slots (memory alone would allow 24). With N+1 that leaves 2 x 4 = 8 slots for 40 VMs, so the cluster would refuse to power on VMs it is already running today.
Percentage policy instead compares total configured memory and CPU against a reserved percentage: 1,280 GB against 0.67 x 2,304 GB = 1,536 GB passes.
State the caveats aloud: the percentage policy is coarse, it ignores per-VM reservations, and it will happily admit an oversubscribed cluster. Pair it with an alarm on cluster memory usage and with the arithmetic from the previous question, which shows the real gap is growth headroom, not failure headroom.
3. What is the smallest change that satisfies the 20% post-failure headroom requirement, and how would you defend it to a skeptical customer?
Read the worked answer
The target is 1,280 / 0.8 = 1,600 GB of post-failure capacity, so they need about 64 GB more than they have. Two defensible options:
- Right-size memory. Guests hold about 70% of their 32 GB active, roughly 22 GB. Dropping ten VMs from 32 GB to 24 GB frees 80 GB, giving 336 GB of slack - 21.9%, which clears the bar. Validate against 30 days of active-memory and ballooning data rather than a single sample, and raise it with the application owners, not unilaterally.
- Add 64 GB per host. Post-failure capacity becomes 2 x 832 = 1,664 GB, slack 384 GB = 23%. More expensive but changes nothing about guest configurations.
Defend it by reframing the question: the customer asked "CPU or memory?" when the measured evidence says neither is short for failure tolerance - growth headroom is short. Removing vCPU would help only the slot policy, which should not be in use here. If they reject both options, the honest fallback is to lower the stated 20% growth margin and record that decision in writing.