VMware ESXi and vSphere Cluster Management

vSphere HA Admission Control Policies

Learn how vSphere HA Admission Control reserves cluster CPU and memory for ESXi host failures, compare its four policies, and configure and validate the right option.

vSphere HA Admission Control is a capacity-protection feature for a vSphere cluster. It controls whether new virtual machines may be powered on or migrated into the cluster when those operations could consume the resources reserved for recovery.

The goal is not to maximize normal-state utilization. The goal is to keep enough usable capacity available for vSphere HA to restart affected VMs after an ESXi host failure.

This lesson assumes familiarity with vSphere clusters, ESXi hosts, vCenter Server, vSphere HA, VM CPU and memory reservations, and basic capacity planning.

Admission Control Policy

Purpose of vSphere HA Admission Control

vSphere HA is the high-availability service that detects host failures and attempts to restart affected virtual machines on surviving hosts. Admission Control works before a failure occurs: it reserves or protects capacity so that the planned recovery operation has a reasonable chance of succeeding.

When a power-on request would leave insufficient capacity for the configured host-failure target, Admission Control can deny the request. The VM is not necessarily faulty; the cluster is protecting its recovery reserve.

Function	When it operates	Purpose
Admission Control	Before a failure	Preserves capacity and restricts operations that would undermine the failover plan.
HA restart process	After a host failure	Detects affected VMs and attempts to restart them on surviving compatible hosts.

Cluster capacity concepts

Total, usable, and reserved capacity

A cluster is a group of ESXi hosts managed as a shared compute pool. Its total CPU capacity is the aggregate CPU capacity of participating hosts, and its total memory capacity is the aggregate physical memory available to the cluster after applicable system overheads.

Failover capacity is the CPU and memory kept available so workloads can be restarted after one or more host failures. Usable capacity is the portion that can be consumed by ordinary workloads while still maintaining the configured failover reserve. Therefore, total capacity is not the same as capacity available for new VM power-ons.

For example, a cluster can have free memory in the aggregate while still refusing a power-on because the free memory is part of the HA reserve or is located on hosts that cannot run the requested VM.

Reservations and placement

A CPU reservation is guaranteed CPU allocation assigned to a VM. A memory reservation is guaranteed physical memory assigned to a VM. Powered-on VM reservations affect Admission Control calculations because HA must account for the resources that a VM requires to be restarted, not merely its current average consumption.

Host-failure tolerance depends on more than arithmetic totals. HA also needs suitable placement opportunities on surviving hosts. Important constraints include:

Uneven host sizes can make aggregate capacity look larger than the capacity available after a particular host fails.
Large CPU or memory reservations can consume a substantial portion of a host's recovery capacity.
Host overhead, VM overhead, and management workloads reduce effective capacity.
Resource fragmentation occurs when free resources exist but are distributed across hosts or cannot satisfy a VM's CPU, memory, compatibility, network, or storage requirements.
Hardware compatibility, datastore accessibility, networking, licensing, and placement rules can prevent an otherwise apparently available host from receiving a VM.

Input	Why it matters	Where to review it	Potential impact if ignored
Host CPU and memory size	Determines aggregate and post-failure capacity.	Cluster hosts and host summary views.	Failure tolerance may be lower than expected.
VM CPU reservations	Defines guaranteed CPU needed during recovery.	VM resource settings and reservation reports.	Power-on operations may be denied or recovery may be under-sized.
VM memory reservations	Defines guaranteed physical memory needed during recovery.	VM resource settings and cluster capacity views.	Memory becomes the limiting resource.
Host overhead	Reduces resources available to VMs.	Host and cluster monitoring views.	Planning based on raw hardware capacity is optimistic.
Compatibility and placement	Determines where a recovered VM can actually run.	HA, DRS, networking, storage, and host compatibility checks.	Aggregate free resources may not be usable.

Admission Control policy options

vSphere provides four conceptual approaches: static number of host failures, percentage of cluster resources, dedicated failover hosts, and no reserved failover capacity. The exact labels can vary by vSphere release, but the capacity models remain distinct.

Policy	Capacity calculation approach	Best suited workload pattern	Main benefit	Main limitation	Effect on VM power-on
Static number of host failures	Slot-based calculation for a selected number of host failures.	VMs with relatively similar CPU and memory reservations.	Directly expresses a host-failure target.	Large reservations and uneven hosts can make slots misleading or waste capacity.	Denies operations that would violate the slot-based target.
Percentage of cluster resources	Reserves configured percentages of aggregate CPU and memory.	Highly variable VM reservation sizes.	Flexible resource-based protection.	The selected percentage may not map exactly to a host count.	Evaluates CPU and memory independently; the more constrained resource can block power-on.
Dedicated failover hosts	Designates one or more ESXi hosts as failover-only capacity.	Environments that require clearly separated standby capacity.	Simple operational boundary and predictable standby location.	Idle capacity and possible compatibility or sizing gaps.	Protects designated hosts from normal powered-on production workloads.
No reserved failover capacity	Does not enforce a failover reserve.	Temporary, deliberate exceptions with accepted risk.	Maximizes immediate power-on capacity.	No capacity guarantee for restarting every affected VM.	Allows power-on even when HA availability constraints would otherwise be violated.

Static number of host failures

This policy defines failover capacity by specifying how many host failures the cluster should tolerate, such as one host failure. It uses a slot-based algorithm to model capacity.

An HA slot is a calculated unit representing the CPU and memory reservation requirements of a VM. The cluster estimates how many such units can fit in the available host capacity while preserving enough slots for the selected number of failed hosts.

The largest applicable CPU and memory reservation can influence the slot size. If one VM has an unusually large reservation, the slot model may use that large requirement as a limiting value. The result can be fewer apparent available slots even when most VMs are small.

Example: similar reservations

Suppose a cluster runs many VMs with similar CPU and memory reservations. Configure the static host-failure policy to tolerate one host failure. Because VM requirements are consistent, each slot represents a reasonably typical workload, and administrators can interpret the available-slot count more easily.

This policy is generally most suitable when VM reservations are relatively homogeneous. Its advantages are a clear failure target and straightforward communication: “the cluster reserves capacity for one host.” Its limitations include sensitivity to unusually large reservations, uneven host sizes, and resource fragmentation.

Adding a high-reservation VM can increase the effective slot size and reduce the number of slots that appear available. Administrators should therefore review the slot calculation after creating or resizing heavily reserved VMs.

Percentage of cluster resources

This policy reserves a configured percentage of aggregate cluster CPU and memory capacity for failover. For example, configuring 30% CPU and 30% memory tells HA to preserve that portion of each resource for recovery.

CPU and memory are evaluated independently. A cluster may have enough reserved CPU but insufficient reserved memory, or the reverse. The more constrained resource can determine whether a VM power-on is allowed.

Example: variable workloads

Consider a cluster with VMs whose CPU and memory reservations vary widely. Configure the percentage-of-cluster-resources policy with a 30% CPU and memory reservation for HA. New power-on requests can be denied when accepting them would consume the capacity preserved for recovery.

This policy is generally appropriate for heterogeneous reservations because it does not depend on one VM's reservation defining a universal slot size. However, a percentage must be selected deliberately:

A percentage that is too low may not protect the intended number of host failures, especially when hosts are large or unevenly sized.
A percentage that is too high reduces capacity available for normal workloads and can cause avoidable power-on denials.
The percentage should be tested against the actual host distribution, reservations, overhead, and desired simultaneous failure scenario.

To select a percentage, start with the recovery objective. Estimate the resources needed to restart the workloads from the expected failed hosts, compare that requirement with aggregate CPU and memory capacity, and include margin for placement and operational variation. Validate the result with the actual cluster rather than assuming that a percentage exactly equals a particular host count.

Dedicated failover hosts

The dedicated failover host policy designates one or more ESXi hosts as reserved failover capacity. These hosts should not normally run powered-on production VMs. When an active host fails, HA can restart protected VMs on the designated hosts.

This model is useful when an organization wants a visible, operationally separate standby host. It can simplify capacity discussions and maintenance planning, but the capacity is normally idle. A dedicated host may also be unavailable during maintenance, hardware failure, or a configuration error.

Size dedicated hosts for the workloads that may need recovery, not merely for the number of hosts. Check CPU, memory, networking, storage access, licensing, hardware compatibility, VM compatibility, and the aggregate reservation requirements of likely failed workloads. A single standby host that is too small cannot provide the expected protection, even if it is correctly designated.

Where the failure objective or workload size exceeds one host's capability, consider multiple dedicated failover hosts or a shared-capacity policy with sufficient reserve.

No reserved failover capacity

No reserved failover capacity permits VM power-on even when the operation would violate the capacity constraints that another Admission Control policy would enforce. This effectively disables Admission Control capacity enforcement; it does not disable vSphere HA itself.

After a host failure, surviving hosts may not have enough usable compatible resources to restart all affected VMs. Some VMs may restart later, remain powered off, or compete for insufficient resources.

This setting can be used temporarily during a migration, maintenance activity, or short-term capacity constraint when additional workloads must be powered on. Before using it, document the reduced availability guarantee, identify who accepts the risk, monitor cluster headroom, and restore a capacity-protection policy when the temporary demand ends.

Choosing the correct policy

Choose a policy based on the business recovery objective, the expected number of simultaneous host failures, VM reservation patterns, host-size distribution, and the operational cost of keeping capacity unused.

Cluster condition	Recommended policy	Reason	Validation considerations
VM CPU and memory reservations are mostly similar.	Static number of host failures.	Slot calculations are easier to interpret and map directly to a failure target.	Check the largest reservations, host sizes, and available slots.
VM reservations vary substantially.	Percentage of cluster resources.	Reserves aggregate CPU and memory without allowing one unusual VM to define every slot.	Test both CPU and memory against the desired failed-host scenario.
The organization requires visibly separate standby capacity.	Dedicated failover hosts.	Provides designated hosts for HA restarts.	Confirm standby capacity, compatibility, storage, networking, and maintenance coverage.
Temporary capacity pressure is accepted by the business.	No reserved failover capacity, temporarily.	Allows additional power-ons while explicitly accepting reduced recovery protection.	Document the exception, monitor continuously, and restore protection promptly.

Use shared spare capacity when normal utilization and workload variability make dedicated idle hosts too costly, provided the reserve is calculated and monitored carefully. Use dedicated hosts when recovery isolation, operational simplicity, or a strict standby requirement justifies the idle capacity.

The desired number of simultaneous host failures is also important. A design for one failed host is not automatically safe for two failed hosts. Consider correlated events, planned maintenance, host-size asymmetry, and whether all failed workloads must restart or only a prioritized subset.

Configuring Admission Control in the vSphere Client

Select the target cluster in the vCenter Server inventory.
Open the cluster configuration or settings area.
Open the vSphere HA settings and edit the cluster configuration.
Enable or review Admission Control.
Select the required failover-capacity policy.
For static host-failure tolerance, enter the number of host failures to tolerate.
For percentage-based capacity, enter the CPU and memory percentages to reserve.
For dedicated failover capacity, select the ESXi host or hosts reserved for failover.
For no reserved capacity, acknowledge that the failover capacity guarantee is reduced.
Save or apply the configuration.
Review HA status, capacity warnings, configuration issues, and the resulting failover capacity.

Exact labels and navigation can vary by vSphere release. Use the cluster's vSphere HA configuration page in the installed vSphere Client version and verify the effective policy after saving.

Cluster inventory item
  - Configure or Settings
    - vSphere Availability / vSphere HA
      - Edit cluster configuration
        - Admission Control
          - Select policy and values
          - Apply changes
          - Review status and warnings

Validation and ongoing monitoring

Do not rely on the policy selection alone. After configuration, review HA configuration issues, cluster alarms, available failover capacity, and any warnings indicating that the intended failure tolerance cannot currently be met.

Confirm that the cluster reports the intended host-failure tolerance.
Review powered-on VM CPU and memory reservations, especially unusually large reservations.
Check host CPU and memory utilization and the distribution of free resources across hosts.
Verify storage accessibility, networking, hardware compatibility, and placement compatibility for recovery.
Use a controlled validation plan where appropriate; do not create an unplanned production failure merely to test HA.
Reassess the policy after adding or removing hosts, changing host sizes, creating high-reservation VMs, or changing workload demand.

Troubleshooting common Admission Control symptoms

A VM cannot be powered on even though free resources appear to exist

Likely causes include an Admission Control reserve, VM CPU or memory reservations that would violate the failover target, or fragmented capacity across hosts.

Review the active Admission Control policy and HA configuration status.
Check the VM's CPU and memory reservations and cluster headroom.
Check whether a compatible host can satisfy the request.
Decide whether to defer the power-on, add capacity, adjust reservations where justified, or formally reevaluate the HA policy.

The static policy reports fewer slots than expected

Look for VMs with unusually large CPU or memory reservations, uneven host capacities, or insufficient spare capacity for the selected failure target. Identify the large reservations and determine whether the slot-based policy still matches the workload mix. A percentage-based policy, justified reservation changes, or additional capacity may be more appropriate.

A dedicated failover host does not provide expected protection

Validate that the host is connected, available, compatible, and large enough for the failed workloads. Check storage, networking, licensing, hardware, and VM compatibility. Review maintenance planning and consider multiple failover hosts if one standby host is insufficient.

VMs restart incompletely after an ESXi host failure

Possible causes include disabled Admission Control, an inadequate reserve, a failure scenario that exceeded the configured target, or insufficient usable compatible resources on surviving hosts.

Review HA events and the configured policy.
Compare the actual failure with the planned host-failure tolerance.
Check surviving-host capacity and workload reservations.
Increase capacity or revise the policy, then perform controlled validation of the recovery design.

Key takeaways

Admission Control reserves capacity before failure; HA restart is the recovery action after failure.
Its objective is workload availability, not maximum normal-state utilization.
Reservations, host asymmetry, overhead, fragmentation, and compatibility all affect real failover capacity.
Static host-failure tolerance suits relatively similar reservations and uses HA slots.
Percentage-based protection suits highly variable reservations and evaluates CPU and memory independently.
Dedicated failover hosts provide isolated standby capacity but require adequate sizing and incur idle-capacity cost.
No reserved failover capacity preserves power-on flexibility while accepting that all affected VMs may not restart after a failure.
Review and retest the policy whenever cluster capacity or workload requirements change.