VMware ESXi and vSphere Cluster Management

VMware vSphere HA Admission Control Explained

Learn how vSphere HA Admission Control reserves cluster capacity for host failures, evaluates VM power-ons, and protects failover recovery.

vSphere HA Admission Control is a capacity-protection feature for a vSphere HA cluster. It preserves enough CPU and memory capacity for virtual machines to restart on surviving ESXi hosts after a host failure.

Admission Control evaluates operations such as a VM power-on against the cluster's configured availability policy. If the operation would consume capacity reserved for failover, vSphere can reject the operation rather than allow the cluster to become overcommitted.

This feature is not a general performance optimizer. It does not balance workloads, improve application performance, or replace HA policy configuration. Its purpose is to protect the ability to recover workloads after the number of host failures specified by the policy.

Prerequisites and terminology

You should understand basic ESXi host administration, vCenter Server clusters, virtual machine CPU and memory settings, and the difference between resource shares, limits, and reservations. The VMware ESXi online course provides related foundational material.

• vSphere HA: High Availability functionality that restarts virtual machines after an ESXi host failure when sufficient resources are available.
• HA cluster: A group of ESXi hosts managed as a shared resource pool and configured for high availability.
• Failover capacity: Compute capacity intentionally kept available so protected VMs can restart after a failure.
• Host failure tolerance: The number of host failures the cluster is designed to withstand while retaining the ability to restart protected workloads.
• Resource reservation: Guaranteed CPU or memory capacity configured for a VM. Reservations can affect HA calculations even when current usage is low.
• Slot: A unit used by some HA admission policies to represent the capacity needed for a VM. Slot size can be influenced by VM CPU and memory reservations.
• Host Monitoring: HA functionality that detects an unavailable or isolated ESXi host and initiates recovery actions.

Why Admission Control matters

An HA cluster is a shared pool formed from the capacity of several ESXi hosts. Under normal conditions, that capacity runs the cluster's VMs. Under failure conditions, the workloads from a failed host must be placed on surviving hosts.

For example, a policy that tolerates one host failure requires the cluster to retain enough usable capacity for the workloads that could be displaced by one failed host. A power-on that fills this reserve may work immediately, but it could leave HA unable to restart all affected VMs later.

With Admission Control enabled, the cluster evaluates the requested power-on and the resulting protected-capacity state. If the request violates the configured policy, vSphere denies it or reports an admission-control warning, depending on the operation and configuration.

With Admission Control disabled, administrators may continue powering on workloads while immediate CPU and memory appear available. The trade-off is explicit: the cluster can consume its failover reserve, and HA may be unable to restart every affected VM after a host failure.

How capacity protection works

1. Several ESXi hosts contribute compute capacity to the HA cluster.
2. The administrator selects an availability target, such as tolerating one host failure.
3. HA determines how much CPU and memory must remain available on surviving hosts.
4. Current workload requirements, reservations, host availability, and the selected policy are considered.
5. When a VM power-on or similar operation is requested, HA checks whether the resulting state still meets the target.
6. If the target would be violated, Admission Control blocks the operation or identifies insufficient failover capacity.

The simplified relationship for equal hosts is:

Required failover capacity = capacity represented by the tolerated host failures

For identical hosts, one tolerated failure generally corresponds to one host's share of the aggregate cluster capacity. However, real clusters may include different host sizes, unavailable resources, reservations, VM placement constraints, and CPU-to-memory imbalances. Heterogeneous clusters therefore require capacity-based evaluation rather than a simple host-count percentage assumption.

Host failure tolerance and reserved capacity

The desired number of tolerated host failures determines the amount of capacity that must remain available. Increasing the target from one host to two hosts requires a larger reserve. Adding hosts can increase total capacity, but it does not automatically eliminate the need for a reserve.

For equal-capacity hosts, the approximate reserve is:

Failover reserve percentage = tolerated host failures / total host count

This relationship is useful for explaining the concept, not for replacing the HA calculation. For example, two failures in a six-host cluster represent approximately one-third of the aggregate capacity if every host is identical. Reservations and policy-specific calculations can change the effective result.

For unequal hosts, losing the largest host may remove more capacity than losing the smallest host. A policy that protects against a specified number of failures must be reviewed against actual host capacities and the failure scenarios the organization considers important.

Worked example: four equal hosts

Consider a cluster with four identical ESXi hosts. Each host contributes 25% of the aggregate cluster capacity. The HA policy is configured to tolerate one host failure.

One failed host represents 25% of total capacity. Therefore, the cluster should retain approximately 25% for failover, leaving 75% as the maximum protected workload capacity in this simplified example.

If running VMs consume 75% of the cluster, the one-host-failure protection limit has been reached. A request to power on another VM would consume some of the protected reserve. With Admission Control enabled, the request is blocked because the cluster could no longer guarantee recovery after one host failure.

If Admission Control is disabled, the additional VM may start if the hosts currently have enough immediate resources. If one host then fails, the surviving hosts have only the remaining capacity. They may not be able to restart all VMs from the failed host, so some VMs could remain powered off or fail to restart until capacity is restored.

Enabled versus disabled behavior

Admission Control policy approaches

vSphere versions and editions can present the settings differently. Use the terminology and options displayed by the vSphere Client for the version in use. The main policy approaches are the following.

Host-failure tolerance

A host-failure tolerance policy expresses the desired number of host failures the cluster should withstand. HA calculates the required failover capacity from the hosts and workloads. This approach is easy to relate to an operational objective: “the cluster must recover after one host failure.”

It is most intuitive in relatively uniform clusters, but administrators must still review host sizes, reservations, maintenance operations, and placement constraints. A count of tolerated hosts does not mean every possible failure removes the same amount of capacity.

Slot-based capacity

In a slot-based model, a slot represents the resources needed by a VM according to the policy calculation. The largest effective CPU or memory requirement can influence slot size. Large CPU or memory reservations can therefore produce large slots and reduce the number of available failover slots.

This can produce surprising results. A cluster may show low observed utilization but have limited admission capacity because one VM has an unusually large reservation. Slot-based calculations can be useful for consistent VM populations, but mixed VM sizes and large reservations can make the result conservative.

Percentage-based cluster resource reservation

A percentage-based policy reserves a configured percentage of aggregate cluster CPU and memory resources for failover. This model can be more understandable for clusters with uneven host capacities or mixed VM sizes because it reasons about resource quantities rather than treating all VMs as equivalent slots.

The CPU and memory percentages should be considered together. A cluster can have adequate CPU reserve but insufficient memory reserve, or the reverse. The effective protection level is constrained by the resource that becomes insufficient first.

Dedicated failover host

Where supported, a dedicated failover host is set aside to receive restarted workloads after a host failure. This makes the intended recovery destination clear and can simplify certain operational designs.

The trade-off is that the dedicated host contributes less or no capacity to normal workload placement. The cluster must also have enough capacity on that host for the workloads it is expected to receive. A dedicated host is not free reserve: its capacity is deliberately removed from ordinary production use.

Choosing a policy

Select the policy using workload reservations, host uniformity, operational goals, maintenance requirements, and recovery objectives. Do not select a policy solely because it allows the greatest number of powered-on VMs.

Resource reservations and HA calculations

A VM's resource reservation is a configured guarantee, not a measurement of what the VM happens to consume at a particular moment. For example, a VM may reserve 16 GB of memory while currently using only 6 GB inside the guest operating system.

HA admission calculations can use configured CPU and memory reservations, along with other policy inputs, rather than relying only on observed runtime utilization. Consequently, a cluster can report insufficient failover capacity even when performance charts show unused resources.

Large reservations can reduce the number of VMs that Admission Control permits. They may also increase slot size in a slot-based policy. This is appropriate when the application truly requires a guaranteed resource level, but unnecessary reservations consume protected capacity on paper.

Before reducing a reservation, validate the application's performance and licensing requirements. Reservation design must match actual availability requirements: do not remove a necessary guarantee merely to make an admission warning disappear, and do not retain an oversized reservation without a demonstrated need.

Reservation review example

1. Identify a VM with an unusually high CPU or memory reservation.
2. Compare the reservation with the application's documented requirement and observed behavior.
3. Check how the reservation affects the selected admission policy, including slot size where relevant.
4. Reduce, retain, or increase the reservation only after validating the application requirement.
5. Recheck failover capacity after the change.

Relationship with Host Monitoring

Host Monitoring detects an unavailable ESXi host or an isolation condition and helps HA decide when recovery actions should begin. It is concerned with failure detection and recovery initiation.

Admission Control has a different responsibility. It protects capacity before the failure by preventing the cluster from consuming the resources needed for the configured recovery target.

The relationship can be summarized as follows:

Host Monitoring: identifies a host failure or isolation condition.Admission Control: helps ensure surviving hosts have recovery capacity.vSphere HA: initiates VM restart when the failure and placement conditions allow it.

Host Monitoring cannot create capacity that is not available. Admission Control cannot detect a failed host. Both capabilities contribute to predictable HA recovery, but they solve different problems.

Configuring and reviewing Admission Control

Configuration names vary by vSphere release, so confirm the exact labels in your vSphere Client. A typical workflow is:

1. Select the HA-enabled cluster.
2. Open the cluster configuration settings.
3. Locate vSphere HA and its Admission Control settings.
4. Enable Admission Control when the cluster must enforce a failover-capacity objective.
5. Configure the desired host-failure tolerance or an applicable failover-capacity policy.
6. Review the displayed failover capacity, warnings, and available capacity.
7. Review each important VM's CPU and memory reservations under its virtual hardware or resource settings.
8. Document the expected behavior for VM power-ons, maintenance mode, and host failure.

Operational planning and validation

• Review total host capacity, usable CPU and memory, current workload demand, reservations, and unavailable hosts before onboarding workloads.
• Verify that the configured tolerated-host-failure target matches the organization's availability objective and service-level requirements.
• Model projected growth rather than checking only today's utilization. Growth can consume the protected reserve before ordinary capacity appears exhausted.
• Include maintenance operations in planning. A host in maintenance mode temporarily removes capacity in a way similar to a planned failure.
• Check large reservations, affinity and anti-affinity rules, host compatibility, and other constraints that can limit restart placement.
• Test and document the expected VM power-on restriction and the recovery behavior for the intended host-failure scenario.
• When capacity is insufficient, add capacity, reduce demand, or revise the protection target through an approved process.

Troubleshooting Admission Control

A VM cannot be powered on even though hosts show unused CPU or memory

Likely causes include a protected failover reserve, large VM reservations, a slot-based policy with a large slot size, unavailable hosts, or different host capacities. Investigate in this order:

1. Check the HA Admission Control policy and tolerated-host-failure setting.
2. Review the cluster's displayed failover-capacity status and warnings.
3. Inspect CPU and memory reservations for the target VM and other large VMs.
4. Check which hosts are available and their effective capacity.
5. Review host size differences and placement constraints.

Resolution options include adding host capacity, reducing unnecessary reservations after application validation, or adjusting the HA policy only when the reduced protection level is acceptable. Disabling Admission Control should not be the routine workaround.

The cluster reports insufficient failover capacity after a change

New VMs may have been powered on, existing demand or reservations may have increased, a host may have entered maintenance mode or become unavailable, or the tolerated-host-failure count may have increased.

1. Compare current demand and reservations with the previous state.
2. Verify the number and capacity of available hosts.
3. Review HA events and recent cluster configuration changes.
4. Restore or add capacity, reduce demand according to policy, or reassess the required failover target.

HA restarts only some VMs after a host failure

Possible causes include disabled or overridden Admission Control, a failure larger than the configured tolerance, reservations that consume more capacity than expected, or placement constraints that prevent restart on surviving hosts.

1. Confirm whether Admission Control was enabled before the failure.
2. Compare the number and capacity of failed hosts with the configured tolerance.
3. Review HA restart events, VM reservations, affinity rules, anti-affinity rules, and host compatibility.
4. Restore capacity and restart remaining VMs as appropriate.
5. Correct policy, reservation, or placement issues before declaring the recovery design complete.

Exam-relevant notes

• Admission Control protects failover capacity; it is not a workload-balancing feature.
• Host Monitoring detects a failure; Admission Control protects the capacity needed after that failure.
• Disabling Admission Control allows more power-ons but can leave HA unable to restart every affected VM.
• Configured reservations can matter more than observed runtime utilization in admission calculations.
• In an equal four-host cluster tolerating one failure, one host represents 25% of total capacity and approximately 25% must remain reserved, leaving 75% for protected workloads.
• Slot-based policies can be strongly affected by the largest effective VM reservation.
• Unequal hosts require capacity-based analysis; host-count percentages alone can be misleading.
• A dedicated failover host provides an explicit recovery destination but removes that host's capacity from normal workload use.

Summary

vSphere HA Admission Control prevents a cluster from consuming the capacity required to recover after its configured number of host failures. It evaluates VM power-on requests against a policy, accounts for protected CPU and memory capacity, and can use host-failure tolerance, slot-based, percentage-based, or dedicated-failover-host approaches depending on the vSphere version and design.

For reliable HA, align reservations and policy settings with the real recovery objective, include host maintenance and growth in capacity plans, and validate both blocked power-on behavior and actual restart recovery. Related subjects include advanced options in vSphere HA and adding hosts to the vCenter Server inventory.