VMware ESXi and vSphere Cluster Management
VMware vSphere HA Admission Control Explained
Learn how VMware vSphere HA Admission Control reserves failover capacity, affects VM power-on operations, and supports host-failure planning.
Admission Control is the vSphere High Availability (HA) capacity-enforcement mechanism for an HA cluster. It checks whether a requested operation, especially a VM power-on operation, would leave enough CPU and memory capacity to recover protected virtual machines after the configured number of host failures.
This feature is about failover protection, not general performance management. A cluster can have acceptable current utilization and still lack the capacity required to restart VMs after a host failure. Conversely, a cluster might have unused aggregate resources but still fail to place workloads because resources are fragmented across individual hosts.
This lesson explains the relationship between vSphere HA, host capacity, failover recovery, Admission Control policies, Host Monitoring, configuration, and operational troubleshooting.
What vSphere HA and Admission Control Mean
vSphere HA
vSphere HA is the vSphere availability feature that detects eligible ESXi host failures and restarts affected VMs on surviving hosts. An ESXi host is a virtualization server that provides CPU, memory, storage, and networking resources to virtual machines.
An HA cluster is a group of hosts managed together for availability and shared capacity planning. The cluster treats the hosts as a resource pool for planning purposes, while VM placement still has to work on specific surviving hosts.
Admission Control
Admission Control evaluates whether a requested VM power-on would compromise the cluster's configured availability guarantee. If the operation would consume capacity needed for the selected failover target, vSphere can deny the operation.
A power-on operation is a request to start a powered-off VM. Admission Control commonly affects this operation because powering on a VM increases the workload that must be protected. A powered-on VM is not automatically stopped merely because the cluster later becomes tight on capacity; Admission Control primarily prevents new workload admission from making the protected design invalid.
Why Admission Control Exists
The purpose of Admission Control is to preserve enough failover capacity for recovery. Failover capacity is CPU and memory capacity kept available so that VMs running on a failed host can restart on surviving hosts.
The key question is not:
“Does the cluster have enough resources for the VMs right now?”
The key question is:
“After the configured host failure, will enough usable capacity remain to restart the protected VMs?”
For example, if a cluster must tolerate one host failure, its planned workload must fit on the remaining hosts after one host is removed from the available pool. Admission Control prevents new VM power-ons when they would invalidate that condition.
Relationship Between Cluster Capacity and Failover
In normal operation, an HA cluster pools the CPU and memory capacity of its participating ESXi hosts for planning. When a host fails, vSphere HA identifies the affected VMs and attempts to restart them on surviving hosts. Restart priorities and available resources influence the order and success of recovery.
Capacity must exist after the failure, not merely before it. A cluster that is running at 90% of its total capacity may appear to have resources available, but losing a host could leave insufficient capacity for all affected VMs. Reservations, VM overhead, host differences, and placement constraints can make the practical result more restrictive than a simple aggregate percentage suggests.
Host failure means the loss of an ESXi host or its HA availability such that workloads on that host must be recovered elsewhere. Host failure is the primary event for which Admission Control reserves capacity. Network isolation and host partition conditions require separate analysis because they can affect how HA interprets host state and whether a host is actually failed.
How Admission Control Affects VM Power-On Operations
- A user or automation system requests that a powered-off VM start.
- vSphere evaluates the requested VM's resource needs and the cluster's current state.
- Admission Control applies the active failover-capacity policy.
- If the power-on would leave the cluster unable to satisfy the configured protection level, the request can be denied.
- If sufficient protected capacity remains, the request can proceed, subject to ordinary placement and resource checks.
A denial is intentional. It prevents the cluster from silently operating beyond its documented failover guarantee. Disabling Admission Control permits additional workloads to start, but it removes enforcement of the selected failover-reserve policy. The workloads may start successfully during normal operation and still fail to restart completely after a host failure.
| Condition | Admission Control enabled | Admission Control disabled | Immediate result | Result after host failure |
|---|---|---|---|---|
| Power-on would remain within the policy | Allowed if other placement checks pass | Allowed if other checks pass | VM starts | Recovery is planned according to the policy and available resources |
| Power-on would exceed protected capacity | Usually denied | May be allowed | Enabled: VM does not start; disabled: VM may start | Disabled enforcement may leave insufficient capacity for some VM restarts |
| Host enters maintenance mode | Capacity status is recalculated and new operations may be restricted | No selected failover reserve is enforced | Workload admission can change even if VM demand is unchanged | Less remaining capacity is available for recovery |
Four-Host Capacity Example
Consider four equal ESXi hosts. Each host contributes one quarter, or 25%, of the cluster's total modeled capacity. The requirement is to tolerate one host failure.
If the running VMs consume 75% of the cluster, the remaining 25% represents the capacity of one host. That unused capacity is needed to absorb the workloads from the failed host. Powering on another VM that raises protected demand above 75% would consume part of the reserve and violate the one-host protection target.
| Item | Value | Percentage of cluster | Availability implication |
|---|---|---|---|
| Equal hosts | 4 hosts | 25% per host | Loss of one host removes 25% of modeled capacity |
| Required failure tolerance | 1 host | 25% reserve | At least one-host capacity must remain available for recovery |
| Current workload | 75% of total capacity | 75% | Fits while preserving the one-host reserve |
| Remaining capacity | 25% of total capacity | 25% | Reserved to absorb the failed host's workloads |
| Additional VM | Any demand that pushes protected usage above 75% | More than 75% used | Admission Control can block the power-on |
With Admission Control enabled, the additional VM is blocked when its resource demand would consume the 25% reserve. With Admission Control disabled, the VM may start and the cluster may appear healthy immediately. If one host then fails, the surviving hosts may not have enough capacity to restart every VM.
Admission Control Policy Approaches
The selected policy determines how vSphere HA calculates or reserves failover capacity. Policy names and available choices vary by vSphere release, so verify the behavior and interface for the deployed version.
| Policy approach | How capacity is reserved or calculated | Best-fit use case | Advantages | Trade-offs |
|---|---|---|---|---|
| Number of host failures | Reserves enough capacity to tolerate a configured number of host failures | Environments with a clear failure-tolerance objective | Direct and predictable relationship to the availability requirement | Can reserve substantial or apparently unused capacity; uneven hosts can make the result more restrictive |
| Percentage of cluster resources | Reserves a configured percentage of CPU and memory resources | Clusters needing a proportional reserve as they grow or change | Flexible and easy to express as a resource budget | May not correspond precisely to losing a particular host; fragmentation and unequal host sizes can reduce practical flexibility |
| Dedicated failover host, where supported | Designates a host primarily for failover use | Designs that prioritize a clearly identified standby resource | Operationally easy to visualize and can provide a predictable standby target | Capacity may remain unused during normal operation; the dedicated host can itself become unavailable; availability varies by vSphere version and configuration |
The choice is an operational design decision. A host-failure count is often easier to map to a service requirement. A percentage reserve can be more flexible but requires careful validation. A dedicated failover host can make the standby model explicit, but it may reduce normal utilization and introduce a single designated capacity dependency.
Host Monitoring and Recovery
Host Monitoring is the HA capability used to identify whether an ESXi host is no longer responsive. It detects a condition that may require recovery; it does not itself provide the capacity needed for recovery.
| Component | Primary responsibility | When it acts | Relationship to Admission Control |
|---|---|---|---|
| Host Monitoring | Detects host failure or loss of host responsiveness | When HA evaluates host heartbeats, connectivity, and related state | Provides the failure-detection signal; it does not reserve capacity |
| Admission Control | Enforces the configured failover-capacity guarantee | When cluster configuration or a workload operation is evaluated | Ensures new workload admission does not consume the planned reserve |
| vSphere HA restart orchestration | Attempts to restart affected VMs on surviving hosts | After HA determines recovery is required | Uses the capacity that Admission Control was intended to protect |
| VM Monitoring or application monitoring | Detects selected VM or application health conditions | When guest or application-level monitoring is configured | Addresses a different availability layer from host-failure Admission Control |
Host Monitoring is not the same as application availability. A host can be running while a guest operating system or application is unhealthy. Likewise, network isolation and host partition scenarios must be assessed separately from a confirmed host failure because connectivity symptoms can produce different HA decisions and risks.
Operational Capacity Considerations
- Host availability: Hosts in maintenance mode, disconnected, failed, or otherwise unavailable reduce the capacity pool used for HA planning.
- Unequal host sizes: Four hosts do not necessarily represent four equal failure units. Losing the largest host may require more reserve than a simple host count suggests.
- CPU and memory demand: Both resource dimensions matter. A cluster can have spare CPU but insufficient memory, or the reverse.
- VM reservations: A resource reservation is capacity explicitly committed to a VM. Reservations can increase the amount of capacity that must be protected and can make admission decisions more restrictive.
- VM overhead: The memory and other overhead required to run VMs must be included in capacity planning.
- Resource fragmentation: This occurs when enough aggregate resources exist but they are distributed across hosts in a way that prevents suitable placement of one or more VMs.
- Workload changes: New reservations, larger VMs, host configuration changes, or maintenance can change failover capacity without changing the number of powered-on VMs.
A cluster can therefore have nominal aggregate capacity and still be unable to place all VMs efficiently after a failure. Administrators should monitor HA configuration warnings and current failover-capacity status before onboarding workloads or scheduling maintenance.
Configuration Workflow
Admission Control is configured at the cluster scope as part of vSphere HA settings. Exact labels and screen layouts vary by vSphere release.
- Assess current and expected CPU and memory demand, including reservations and VM overhead.
- Define the failure-tolerance target, such as tolerating one host failure.
- Select the target cluster and open its availability or vSphere HA configuration settings.
- Enable vSphere HA if it is not already enabled.
- Locate the Admission Control settings.
- Choose the policy that matches the failure target and capacity-planning model.
- Review the resulting HA status, warnings, and available failover capacity.
- Save changes through the normal change-control process.
- Validate the design by comparing protected workload demand with the capacity remaining after losing the largest relevant host.
- Test expected VM power-on behavior in a controlled, non-disruptive change window.
Verification should include the configured number of tolerable host failures or the selected reserve model, current host availability, CPU and memory demand, reservations, and expected behavior when a VM power-on is denied.
Troubleshooting VM Power-On Denials
Symptom: A VM cannot be powered on in an HA-enabled cluster
Likely causes include Admission Control determining that the operation would violate the failover-capacity policy, reduced capacity caused by maintenance or host failure, changed workload reservations, or resource fragmentation that prevents valid placement.
- Review the task error and HA-related cluster alarms.
- Check the active Admission Control policy and current failover-capacity status.
- Review host availability, maintenance state, CPU and memory usage, and VM reservations.
- Determine whether the VM's resource requirements fit on the surviving hosts while preserving the failure target.
- Add capacity, reduce protected demand, or revise the policy only after evaluating the availability impact.
Symptom: HA reports insufficient failover capacity
Calculate the capacity remaining after removing the largest applicable host from the available pool. Then identify oversized VMs, reservation-heavy workloads, unequal hosts, and hosts that are unavailable. The corrective options are usually adding capacity, reducing protected demand, changing reservations where appropriate, or revising the policy with an explicit availability decision.
Symptom: Admission Control appears overly restrictive
Review whether the policy reserves more capacity than expected, whether host sizes are uneven, and whether resource fragmentation is limiting placement. Validate the intended tolerance level against the business requirement. Simply disabling Admission Control may hide the symptom while removing the protection mechanism.
Controlled Capacity-Change Example
In the four-host example, place one host into maintenance mode. The remaining three hosts now provide the normal operating pool, but the cluster must also evaluate whether it can satisfy the configured failure target using that reduced pool. Workload demand has not changed, yet the available failover capacity has changed. HA status and VM admission decisions can therefore become more restrictive during planned maintenance.
Before maintenance, confirm whether the design supports both the maintenance event and the desired unplanned failure tolerance. If it does not, schedule the work with an explicit temporary risk decision, reduce workload demand, or add capacity.
Exam-Relevant Notes
- Admission Control protects capacity for HA failover; it is not a general CPU or memory performance-control feature.
- Host Monitoring detects a host problem; Admission Control reserves capacity for recovery.
- A VM power-on can be denied even when the VM could technically run during normal operation.
- Disabling Admission Control allows more workloads to start but removes enforcement of the selected failover reserve.
- Capacity must be evaluated after the required host failure, not only before it.
- Reservations, overhead, unequal hosts, maintenance mode, and fragmentation affect usable failover capacity.
- Policy names and exact behavior can vary between vSphere releases.
Summary
vSphere HA Admission Control preserves a planned amount of cluster capacity for host-failure recovery. It evaluates VM power-on requests against the configured failure-tolerance policy and can reject a request when the additional workload would consume the protected reserve. Host Monitoring detects host unavailability, while HA restart orchestration attempts recovery on surviving hosts. Reliable design requires more than comparing total CPU and memory: administrators must account for the largest relevant host failure, reservations, overhead, host differences, maintenance, and resource fragmentation.
For a related focused reference, see Admission Control Explained.