Troubleshooting vSphere HA Admission Control and Overcommit
VMware vSphere High Availability (HA) admission control protects a cluster from accepting more powered-on workloads than it can restart after a host failure. Problems appear when HA reservations, failover policy, and physical capacity do not align with the level of CPU or memory overcommit in use.
A cluster may show an admission control warning even when current hosts have plenty of free resources. Conversely, a cluster can pass admission checks while virtual machines experience contention after a failure. The difference comes from how vSphere calculates protected capacity and how workloads consume resources at runtime.
Effective troubleshooting starts by separating three concerns: whether HA will permit a VM to power on, whether enough capacity exists for failover, and whether the surviving hosts can deliver acceptable performance under overcommit.
How HA Admission Control Calculates Capacity
Admission control reserves capacity for host failures before vCenter allows additional virtual machines to power on. Depending on the selected policy, vSphere may calculate this reserve using host failure slots, a percentage of cluster resources, or one or more dedicated failover hosts.
The percentage-based policy is generally easier to understand in clusters with hosts of different sizes. For example, reserving 25 percent of CPU and memory capacity means vSphere attempts to keep enough uncommitted resources for the configured failure tolerance. The actual result still depends on VM reservations, host capacity, and the number of failures the cluster is configured to tolerate.
The slot policy can be less intuitive because a slot is based on the largest CPU and memory reservation among powered-on VMs. One VM with an unusually large reservation can inflate the slot size and make the cluster appear nearly full. Reviewing reservation values is therefore essential before changing HA settings.
What Overcommit Changes
CPU overcommit allows the total amount of virtual CPU assigned to VMs to exceed the number of physical CPU cores available. ESXi manages this through scheduling, co-stop control, ready time, and shares. Moderate overcommit can work well, but a host failure concentrates more vCPUs on fewer physical CPUs and can sharply increase contention.
Memory overcommit is more sensitive because physical memory cannot provide the same performance as guest RAM indefinitely. ESXi first uses transparent page sharing where applicable, memory compression, and ballooning through VMware Tools. If pressure continues, host swapping may occur, causing significant latency.
HA admission control typically focuses on capacity reservations rather than the full configured size of every virtual disk or the theoretical maximum of every vCPU. A VM with a low memory reservation may be admitted even though its configured memory is large. That can make the cluster look safe during normal operation while leaving less practical headroom during failover.
Distinguishing Admission Errors From Resource Contention
The vSphere Client may report that a VM cannot power on because doing so would violate HA admission control. This is a placement and policy decision, not proof that the cluster has exhausted all physical CPU or memory. Check the cluster’s Summary and Monitor views, then inspect the HA configuration and the resource reservation of the VM being powered on.
Runtime contention produces different evidence. CPU ready, co-stop, ballooning, compression, swapping, and memory pressure indicate that workloads are competing for resources. These counters should be reviewed at host and VM level during normal utilization and during simulated maintenance events.
| Symptom | Likely cause | Useful checks | Practical response |
|---|---|---|---|
| VM power-on blocked | Admission reserve would be exceeded | HA policy, failover percentage, VM reservations | Reduce reservations, add capacity, or revise policy |
| Large slot size | One or more oversized reservations | CPU and memory reservations by VM | Correct unnecessary reservations or use percentage policy |
| High CPU ready after host failure | CPU overcommit is too aggressive | Ready, co-stop, vCPU-to-core ratio | Reduce vCPUs, rebalance VMs, add hosts |
| Ballooning or swapping | Memory demand exceeds surviving capacity | Host memory pressure, balloon, swap metrics | Lower memory overcommit and preserve failover headroom |
| HA restarts succeed but apps slow down | Restart capacity exists, performance capacity does not | Application latency and host contention | Define operational headroom beyond HA minimums |
A Practical Troubleshooting Workflow
Begin with the cluster’s current HA settings. Record the admission control policy, configured host failure response, percentage reservations, and whether dedicated failover hosts are configured. Also verify that HA is enabled on every intended host and that datastore and network accessibility support VM restart.
Next, inventory powered-on VMs and sort them by CPU and memory reservation. Look for old reservations left behind by testing, database systems with deliberately reserved memory, and templates or infrastructure VMs that were assigned excessive vCPUs. A reservation can be useful for performance isolation, but it also affects protected capacity calculations.
Then compare aggregate demand with surviving-host capacity. Do not rely only on average utilization across the cluster. Model the loss of the largest host, or the number of simultaneous failures defined by the policy, and check whether the remaining hosts can accommodate reservations plus a reasonable operating buffer.
Correcting Policy And Configuration Problems
The “Percentage of cluster resources reserved” policy is often the clearest choice for mixed-size clusters and environments where host failure tolerance is expressed as a percentage. Set CPU and memory percentages deliberately rather than accepting a value without validating it against actual failure scenarios.
The “Dedicated failover hosts” policy can provide predictable placement, but it removes those hosts from normal workload capacity. Confirm that the failover hosts are compatible in CPU generation, networking, datastore access, and licensing. A reserved host that cannot run the required VMs is not meaningful protection.
Review DRS alongside HA. DRS can distribute workloads during normal operation, but it does not create CPU or memory capacity after a host failure. Automation rules, affinity settings, and manual VM-Host rules may also restrict placement and make admission control appear more restrictive than expected.
Hybrid environments introduce an additional operational dimension. If an application tier depends on external cloud services, validate its recovery dependencies separately from vSphere capacity; for example, a workload protected with a Radware Cloud WAAP deployment may still require DNS, identity, and network paths to remain available after VM recovery.
Validating Failover Under Overcommit
A configuration review should be followed by a controlled test. Schedule a maintenance evacuation or place a host into maintenance mode, then observe whether DRS can move workloads and whether the remaining hosts sustain acceptable performance. This is safer and more informative than waiting for an unexpected host outage.
For a stronger test, use a representative workload window and monitor CPU ready, memory ballooning, compression, swapping, datastore latency, and application response time. Record baseline values first so that failover impact can be measured rather than judged by appearance in the client.
Do not treat successful VM restart as the only acceptance criterion. HA may restart every VM while applications remain degraded because CPU scheduling or memory reclamation becomes severe. Recovery objectives should therefore include service performance, dependency availability, and the time required for DRS or operators to rebalance the cluster.
Recommendations For Sustainable Capacity
- Use percentage-based admission control when hosts differ in size or when failover tolerance is easier to express as a resource percentage.
- Audit CPU and memory reservations regularly, especially on test, legacy, and database VMs.
- Model the loss of the largest host and compare surviving capacity with reservations, expected demand, and operational headroom.
- Track CPU ready, co-stop, ballooning, compression, and swapping instead of relying only on aggregate utilization.
- Test maintenance evacuation periodically and document the performance impact of a realistic host failure.
Keep HA admission control conservative enough to protect the services that matter, but avoid using it as a substitute for capacity planning. Review policy changes through a failure scenario, validate them with controlled evacuation, and monitor the cluster after each major workload or reservation change. Apply these checks during the next vSphere maintenance window to confirm that admission decisions and real-world failover performance tell the same story.