VMware ESXi and vSphere Cluster Management
vSphere HA Admission Control Policies and Cluster Failover Capacity
Learn how vSphere HA Admission Control reserves ESXi cluster capacity, compare its four policies, configure failover protection, and validate recovery capacity.
vSphere HA Admission Control protects capacity for virtual-machine recovery after an ESXi host failure. It is a capacity-protection mechanism, not the component that detects failures or restarts VMs by itself. vSphere HA detects a host failure and attempts to restart affected powered-on virtual machines on surviving hosts; Admission Control helps ensure that those hosts retain enough CPU and memory capacity for the planned recovery.
This lesson compares the four main Admission Control approaches, explains their calculations and trade-offs, and provides a practical configuration and validation process.
What Admission Control Protects
A cluster is a logical group of ESXi hosts managed together. An ESXi host is a physical server running the ESXi hypervisor. When a host fails, its workloads need to restart on the remaining hosts. The capacity retained for that recovery is called failover capacity.
Admission Control prevents new VM power-on operations when those operations would consume capacity needed to meet the cluster's configured failover objective. Depending on the policy, the objective might be tolerating a specified number of host failures, preserving a percentage of cluster resources, keeping one or more hosts unused as standby capacity, or enforcing no reserved capacity.
Admission Control primarily uses configured CPU and memory reservations and the selected failover policy. Ordinary utilization graphs alone do not determine whether a power-on is admitted. A cluster can appear lightly utilized and still reject a power-on if reservations and the protected reserve leave insufficient admissible capacity.
Admission Control does not guarantee that every failure scenario will be recovered. Storage accessibility, networking, VM restart settings, surviving-host health, placement constraints, and the size of the actual failed workload also matter. Its purpose is to make the capacity portion of the availability plan explicit and enforceable.
Where to Configure Admission Control
- Select the target vSphere cluster in the vSphere Client inventory.
- Open the cluster's Settings or Configuration area.
- Open the vSphere HA settings and choose to edit the cluster HA configuration.
- Open Admission Control and enable it if it is not already enabled.
- Choose a failover-capacity policy and provide the policy-specific values.
- Save the change, then review HA status, capacity warnings, and related alarms.
Labels and screen layout vary between vSphere releases, but Admission Control remains a cluster-level vSphere HA setting. The account making the change also needs suitable permission to modify cluster configuration.
The Four Admission Control Policies
1. Host failures cluster tolerates
With the host-count policy, the administrator specifies how many ESXi host failures the cluster must tolerate. For example, a value of one means the cluster should retain enough capacity to restart protected workloads after one host failure.
This policy uses slots. A slot is a calculated unit containing the CPU and memory requirement of a protected powered-on VM. In simplified terms, the slot's CPU size is influenced by the largest relevant CPU reservation and the slot's memory size is influenced by the largest relevant memory reservation. The cluster then estimates how many such slots fit on the available hosts while preserving the requested number of failed-host equivalents.
Because the largest reservations can influence slot size, one unusually large VM can make every slot appear large. That reduces the calculated number of available slots even when many other VMs are small. CPU and memory are considered together, so the more restrictive resource can limit the result.
This approach fits clusters with similar host capacity and broadly similar VM CPU and memory reservations. It can waste capacity or produce distorted results when reservations vary substantially. Review outlier VMs before treating the slot count as a realistic capacity forecast.
2. Percentage of cluster resources
The percentage policy reserves a configured percentage of aggregate cluster CPU and memory capacity for HA recovery. For example, a configuration of 30% CPU and 30% memory retains those portions as protected capacity instead of allowing normal VM power-ons to consume them.
CPU and memory are calculated independently. A power-on can be blocked because either the protected CPU reserve or the protected memory reserve would be violated. The more constrained resource therefore limits admission, even if the other resource has substantial headroom.
Percentage-based Admission Control is generally suitable when VM reservations vary widely, such as a cluster containing small infrastructure VMs and large database VMs. Choose the percentage from the expected failure scenario rather than from a preferred utilization target. Consider the number of hosts that could fail, the workload on those hosts, unequal host sizes, and whether placement could leave capacity fragmented or unavailable.
3. Dedicated failover hosts
With this policy, one or more ESXi hosts are designated as dedicated failover hosts. Their capacity is preserved as standby capacity for HA recovery rather than being used for normal powered-on workloads.
The main advantage is clarity: the recovery capacity and likely placement hosts are easy to identify. The trade-off is that the standby resources may remain idle during normal operations. Designated hosts must be appropriately sized for the VMs expected to restart, remain connected and healthy, and be available when a failure occurs.
Do not place normal production VMs on a designated failover host. Also verify that the number of standby hosts matches the documented host failure objective. A single standby host cannot provide the same protection as several standby hosts if multiple failures must be tolerated.
4. No reserved failover capacity
The no-reserved-capacity option allows VM power-on activity even when the cluster lacks enough protected capacity for the configured HA objective. It effectively turns off Admission Control capacity enforcement; it does not turn off vSphere HA itself.
After a host failure, vSphere HA may still attempt to restart affected VMs. However, surviving hosts might not have enough resources to restart every VM. This policy can be appropriate for a noncritical lab, a temporary test environment, or a formally approved operational exception. It is normally unsuitable when production workloads have a documented availability requirement.
Policy Comparison
How to Select a Policy
Policy selection should reflect the documented availability objective, not simply the desire to maximize VM density. Also consider host homogeneity, reservation uniformity, utilization targets, desired failure tolerance, and operational simplicity.
Configuration Example: Retain 30 Percent
Policy: Percentage of cluster resources
CPU failover reserve: 30%
Memory failover reserve: 30%Operationally, this configuration asks the cluster to retain 30% of its relevant aggregate CPU capacity and 30% of its relevant aggregate memory capacity for HA recovery. Admission Control blocks a new VM power-on when that operation would consume enough CPU or memory to reduce the protected reserve below the configured value.
For example, if a proposed VM requires a large memory reservation, the operation can be refused even when CPU appears available. Conversely, a CPU-heavy reservation can be the limiting factor in a cluster with sufficient memory.
Thirty percent is not automatically equivalent to one failed host. Validate it against the expected host-failure scenario. If one host contains approximately 25% of usable cluster capacity, a 30% reserve may be appropriate from a simple capacity perspective; unequal hosts, placement constraints, reservations, and workload distribution can change that conclusion.
Admission Control Capacity Inputs
Validation and Ongoing Operations
- Review the active vSphere HA policy and the displayed cluster capacity or failover status after every configuration change.
- Check Admission Control warnings and related cluster alarms. See Alarms in vSphere for alarm-management concepts.
- Investigate failed or blocked VM power-on tasks rather than treating them as arbitrary errors.
- Review CPU and memory reservations for the VM involved, especially when the cluster appears lightly utilized.
- Reassess the policy after adding or removing hosts, changing host hardware, modifying reservations, or materially changing workload size.
- Check whether a recent host failure, maintenance operation, or disconnection temporarily reduced available capacity.
- Test failover behavior under approved maintenance and change-control procedures. Confirm restart placement, storage access, networking, and the time required to recover representative workloads.
Admission Control is a planning control, so its assumptions must remain current. A policy that was sufficient before a host upgrade, reservation change, or workload expansion may no longer protect the intended failure scenario.
Troubleshooting Common Symptoms
A VM cannot be powered on even though hosts look lightly utilized
- Admission Control may be preserving the configured failover reserve.
- The VM's CPU or memory reservations may exceed the remaining protected capacity.
- Memory, rather than CPU, may be the constrained resource.
Review the active policy and failover-capacity status, inspect the VM reservations, and check for recent host failures or maintenance. Depending on the approved availability plan, add capacity, reduce unnecessary reservations, migrate or power off nonessential workloads, or revise the HA objective.
The host-count policy reports less capacity than expected
- One VM may have an unusually large CPU or memory reservation, increasing calculated slot size.
- Reservations may vary so widely that slots are inefficient for this workload mix.
- Hosts may have unequal available capacity.
Identify reservation outliers and review the slot-related calculations. If the workload is highly variable, evaluate percentage-based Admission Control instead.
The cluster cannot restart all VMs after a host failure
- No failover capacity may have been reserved.
- The configured reserve may be smaller than the workload on the failed host.
- Cluster capacity may have changed since the policy was configured.
Review the policy and current usable capacity, compare the reserve with the intended failure scenario, then add or rebalance hosts and workloads. Retest the availability plan under change control.
A dedicated failover host is unavailable
- The host may be disconnected, unhealthy, or in maintenance mode.
- Normal powered-on VMs may have been placed on the standby host.
- The number or size of designated hosts may not match the failure objective.
Verify connectivity and health, remove normal workloads from standby hosts, and reassess standby-host sizing and count.
Exam-Relevant Notes
- Admission Control reserves capacity; vSphere HA performs failure detection and VM restart attempts.
- Host-count policy uses slots, and large reservations can increase slot size.
- Percentage policy evaluates CPU and memory independently; either constrained resource can block admission.
- Dedicated failover hosts trade utilization for clearly identified standby capacity.
- No reserved failover capacity does not disable vSphere HA, but it removes capacity enforcement and reduces recovery guarantees.
- Reservation-based admission decisions are not determined by ordinary utilization alone.
Summary
Admission Control turns a vSphere HA availability objective into a cluster capacity rule. Use the host-count policy when reservations and hosts are reasonably similar, percentage-based protection when reservations vary, dedicated failover hosts when explicit standby capacity is required, and no reserved capacity only when the risk is acceptable and documented. Validate the selected policy against real host-failure scenarios and revisit it whenever cluster hardware, reservations, or workload size changes.
For related administration tasks, review Advanced Options in vSphere HA, adding an ESXi host to vCenter Server inventory, and the broader VMware ESXi online course.