Troubleshooting VMware vSphere High Availability Admission Control
VMware vSphere High Availability (HA) admission control determines whether a cluster has enough capacity to restart virtual machines after a host failure. When the setting is misunderstood or configured against outdated assumptions, administrators can see blocked vMotion operations, failed power-ons, warning alarms, or a cluster that appears healthy while lacking practical failover capacity.
The feature reserves CPU and memory for expected failures. It does not move workloads automatically before an outage, and it does not guarantee application recovery if storage, networking, DNS, or dependencies are unavailable. Effective troubleshooting therefore requires checking both the admission control policy and the wider cluster design.
The terms vary slightly between vSphere releases, but the core choices remain familiar: host failures the cluster tolerates, percentage-based reservation, dedicated failover hosts, and slot-based calculations. Reservations, VM overhead, host imbalance, and maintenance activity can all affect the result.
This matters in Australian environments where a VMware cluster may support offices in Sydney, Melbourne, Brisbane, or Perth while relying on a small local team and an external managed service provider. A warning that seems harmless during a quiet afternoon can become a serious capacity issue during a planned maintenance window or a regional connectivity incident.
What admission control protects
HA admission control prevents the cluster from accepting more powered-on workload than it can recover after a defined number of host failures. If a host fails, HA needs sufficient CPU, memory, datastore access, and network connectivity to register and power on affected VMs elsewhere.
The control applies primarily to VM power-on and migration decisions. It does not reserve a fixed physical server for every virtual machine, nor does it predict application demand. A VM may restart successfully while its database, DNS service, storage path, or upstream firewall remains unavailable.
A common misunderstanding is treating an admission control warning as proof that HA is broken. The warning usually indicates that the current workload cannot satisfy the selected failover policy. HA may still restart VMs after a failure, but the cluster has less protection than the policy promises.
Check the cluster state first
In vCenter, open the cluster’s Configure view and review vSphere Availability, admission control, host monitoring, and the selected policy. Record the number of hosts, each host’s usable CPU and memory, maintenance state, connection state, and whether DRS is enabled.
Look at the Summary and Monitor views for HA configuration issues, insufficient resources, inaccessible datastores, heartbeat warnings, and host isolation events. A host in maintenance mode, disconnected from vCenter, or marked as not responding can change the available failover calculation immediately.
Check recent changes before adjusting the policy. A new large VM reservation, a host firmware upgrade, an expanded memory configuration, or a change from shared storage to vSAN can explain a warning that appeared without any obvious workload increase. Exporting cluster events before making changes provides a useful audit trail.
Understand slot-based calculations
The slot policy estimates the largest CPU and memory reservation among powered-on VMs, then treats that value as a slot. The cluster must retain enough slots to cover the configured number of host failures. One unusually large reservation can therefore make the cluster look unable to tolerate a failure, even when average resource use is low.
For example, a VM with a 32 GB memory reservation and a 4 GHz CPU reservation can drive the slot size for the entire cluster. Smaller VMs then consume the same calculated slot, creating what administrators often call slot-size inflation. Review VM reservations, especially for database, ERP, and virtual desktop workloads.
Slot calculations can be inspected in the cluster’s HA admission control information, although the exact presentation differs by vSphere release. If the slot policy produces an unrealistic result, percentage-based admission control is generally easier to explain and operate.
Test percentage-based protection
The percentage-based policy reserves a proportion of cluster CPU and memory for failover. It is usually more predictable for mixed workloads because the reservation reflects aggregate capacity rather than the largest VM. Set the value according to the number of host failures required and the actual size of the hosts.
A cluster with four equal hosts configured to tolerate one failure might require roughly 25 percent of aggregate capacity, but CPU and memory headroom must be assessed separately. Uneven hosts, reservations, vSAN overhead, and DRS imbalance can make the practical requirement higher than the simple formula.
Do not set the percentage to a low value merely to remove a warning. Confirm that the remaining hosts can run the highest-priority workloads during a failure. In an Australian colocation facility, for example, delayed hardware replacement across a public holiday or a long parts shipment can make a conservative reserve worthwhile.
Investigate hosts, reservations, and overhead
Compare host capacity rather than relying on installed hardware figures. ESXi consumes memory for its own operations, vSphere features add overhead, and usable capacity can differ between identical-looking hosts because of BIOS settings, NUMA layout, or licensing-enabled features.
Review VM reservations, limits, shares, large memory configurations, and snapshots. A memory reservation can consume admission control capacity even when the guest is idle. CPU limits can create performance problems after failover without necessarily changing the admission result.
Storage and network health are equally important. Verify that every host can see the required datastores and port groups, particularly after a storage migration or switch change. In a Perth or Darwin site with limited WAN redundancy, a healthy local HA calculation cannot compensate for a lost inter-site link if the recovery design depends on remote services.
Validate failover with controlled tests
Use vMotion and maintenance mode to check whether DRS can redistribute VMs while preserving the admission control reserve. A migration blocked by admission control is useful evidence: capture the task error, identify the affected reservations, and compare the required and available failover resources.
Planned HA tests should be performed during an approved change window. Confirm VM restart priority, VM monitoring settings, datastore accessibility, network port groups, and application dependencies before simulating a host failure. A hard power-off test is more representative than simply disconnecting a host from vCenter, but it carries operational risk.
After recovery, check HA events, VM power-on timing, guest heartbeat status, and application logs. Record which VMs restarted, which required manual intervention, and whether performance remained acceptable. A short “arvo” maintenance test with application owners is often more valuable than relying on a green cluster icon.
Choose and document the operating policy
The best admission control policy depends on workload shape, host consistency, and the failure scenario that the business accepts. Slot-based protection can work well in a uniform environment with similarly sized VMs. Percentage-based protection is generally clearer when VM sizes and reservations vary.
Dedicated failover hosts provide a straightforward model: one or more hosts remain available for recovery and are excluded from normal workload placement. This can be easier to explain to auditors, although it reduces everyday utilisation and may be expensive for smaller Australian businesses using leased hardware or an MSP contract.
| Policy | Useful when | Common troubleshooting concern | Operational trade-off |
|---|---|---|---|
| Slot-based | Hosts and VM reservations are consistent | One large reservation inflates the slot size | Simple concept, but can be conservative |
| Percentage-based | Workloads and VM sizes vary | The reserve does not reflect an uneven host layout | Predictable aggregate protection |
| Dedicated failover hosts | A clear recovery target is required | Standby hosts may be unsuitable or under-tested | Strong isolation with lower utilisation |
| Host failures tolerated | The failure count is the primary business requirement | Capacity may be insufficient for the selected count | Easy to communicate, dependent on host sizing |
Document the selected policy, tolerated host failures, reservations that influence the calculation, and the test date. Include dependencies such as vSAN, shared datastores, DNS, Active Directory, and network services. When the design is reviewed after a hardware refresh or workload expansion, the team can distinguish a genuine capacity change from a configuration problem.