HA Admission Control Starves a Cluster After One Host Fails
A FusionCompute 8.x cluster has five CNA hosts, each with 2 x 20-core CPUs and 384 GB RAM, and runs 150 VMs. Most VMs are 4 vCPU / 16 GB with no reservation. One ERP VM is configured with 16 vCPU, 64 GB RAM, and full reservations on both because the application vendor demands it. HA is enabled with the policy Cluster HA and reserved resources set to 20 percent. Last Tuesday a host power supply failed. The 30 VMs on that host went to to-be-restarted state; only 6 restarted, and the rest raised insufficient resources. The operations team points at the cluster summary, which shows 41 percent free memory and 38 percent free CPU on the surviving hosts, and asks why HA ignores this capacity. They propose buying one more identical host and keeping all settings unchanged.
1. Explain why the summary capacity and the schedulable HA capacity differ. Quantify the slot size and show which resource is limiting.
Read the worked answer
HA admission control does not sum free memory and free CPU. It computes a slot size from the largest reservation in the cluster, then reserves slots on every surviving host. Here the ERP VM sets the slot at 16 vCPU and 64 GB because both are fully reserved. Per host, usable CPU after the 20 percent reservation is 40 x 0.8 = 32 cores, so 32 / 16 = 2 CPU slots. Usable memory is 384 x 0.8 = 307 GB, so 307 / 64 = 4 memory slots. CPU is therefore the limiting dimension at 2 slots per host. With four surviving hosts the cluster can schedule only about 8 slots, and pre-existing placement consumes part of that, so 6 restarts is consistent. The summary chart averages unused capacity across all VMs and all resource types; it does not model the largest-reservation slot or the per-host fragmentation caused by HA reserves. Memory is not the constraint, so 41 percent free memory is irrelevant to admission control.
2. Will one additional identical host fix the problem? Justify with numbers and state what would happen to the 30 failed-over VMs.
Read the worked answer
No. One host adds only 2 CPU slots at the current slot size, taking the schedulable total from roughly 8 to 10. The failed host carried 30 VMs, and each VM consumes one slot regardless of whether it is 4 vCPU or 16 vCPU. Ten slots cannot absorb 30 VMs, so most would still stay pending. The purchase improves headroom for routine growth but does not change the arithmetic that caused the outage. A second hidden problem is that the ERP VM reservation is a cluster-wide slot definition: every host must be able to host that reservation, so small hosts or hosts with other pinned reservations reduce effective slots further. Before approving hardware, the team should verify the slot count in the HA planning view at the proposed policy, then compare it with the real failover demand of the busiest host. Adding hosts without changing the reservation or policy simply scales the wrong number.
3. Recommend configuration changes, with tradeoffs, that let the cluster recover all 30 VMs after a single host failure.
Read the worked answer
First reduce the slot size. Ask the ERP vendor whether 8 vCPU and 32 GB reservations are acceptable; that alone cuts the slot in half and roughly doubles slots per host. Second, review the 20 percent reserve: lowering it to 10 percent increases usable CPU to 36 cores and yields 2 slots at 16 vCPU, but reduces headroom for normal growth, so it is a secondary lever. Third, isolate the ERP VM into its own small cluster with a policy tuned for large reservations; this stops one workload from defining slots for 149 other VMs. Fourth, evaluate a host-failure-based admission policy if the installed version supports it, and validate the resulting slot count rather than assuming it is safer. Fifth, add DRS so placement does not leave stranded fragments. Keep the extra host purchase only after the policy change is modeled; otherwise the customer pays for capacity that admission control still will not schedule. Document the chosen reservation values and re-test with a planned host evacuation.