vSphere HA Admission Control: Matching Failover Reservations to Restart Priorities

The outage you did not plan for

Your four-host vSphere cluster is running hot. Memory utilization sits near the line where DRS can still balance load, and every host carries a meaningful share of production workloads. Then one host fails. vSphere High Availability (HA) detects the loss and attempts to restart your virtual machines on the surviving hosts. The outcome depends on two settings that are often configured in isolation: admission control and VM restart priority. One governs whether reserved capacity exists. The other governs who gets to use it first.

Admission control decides the supply

Admission control prevents vCenter from powering on or migrating a VM if doing so would break the cluster's failover guarantee. It does this by reserving a slice of cluster resources. vSphere offers three common modes, and the choice changes how much headroom you keep.

• Percentage-based: You reserve a percentage of total cluster CPU and memory. If a four-host cluster has 512 GB of RAM and you set 25%, HA keeps roughly 128 GB in reserve for failover. This is easy to explain, but it treats all VMs as equals. A single 96 GB database VM can consume most of that reserve, while a fleet of 4 GB dev VMs barely touches it.
• Slot policy: HA calculates a slot size based on the largest VM in the cluster, including memory overhead, and reserves enough slots to cover the configured number of host failures. The math is more precise, but it is sensitive to VM resource profiles and overhead. A few oversized VMs can inflate the slot size and reduce cluster utilization.
• Dedicated failover host: You designate a host as an empty standby. The mental model is simple, but you pay for a full host of idle capacity.

Restart priority decides the demand order

VM restart priority does not create capacity; it sequences recovery. Each VM carries a priority of High, Medium, Low, or Manual. After a host failure, HA restarts High-priority VMs first, then Medium. Low-priority VMs restart later, or not at all if reserved capacity is exhausted. Manual-priority VMs wait for an operator. The setting lives on the VM itself, under VM Options, not in the cluster HA dialog.

If admission control reserved generously, priority mostly affects the order of the recovery wave. If the reservation is tight, priority determines which workloads actually start and which ones stall.

A worked example: four hosts, one failure

Consider a four-host cluster with 128 GB of RAM per host, totaling 512 GB. You configure percentage-based admission control to tolerate one host failure, reserving 25% of CPU and memory. That leaves roughly 128 GB of reserved memory headroom.

Your workload mix looks like this:

• A tier-1 database VM: 64 GB RAM, restart priority High
• Two application VMs: 16 GB RAM each, restart priority Medium
• Ten development VMs: 4 GB RAM each, restart priority Low

When Host 1 fails, HA restarts the database first, consuming 64 GB of the reserve. The two application VMs follow, using 32 GB. That leaves roughly 32 GB for the dev tier. HA can restart about eight of the ten dev VMs before the reserved headroom is gone. The remaining two stay powered off until capacity is reclaimed or an operator intervenes.

Now flip the priorities. If the database is set to Low and a dev VM is set to High, the dev VM claims headroom first. The database may fail to restart entirely, even though the cluster has enough raw resources across the surviving hosts. Admission control blocked the placement because the reserved slice was consumed out of order.

The trade-off you cannot avoid

Percentage-based admission control is comfortable in capacity meetings because the number is easy to repeat. It is also blunt. In heterogeneous clusters, it can over-reserve—wasting capacity on small VMs—or under-reserve when a few large VMs dominate. Slot policy corrects the math, but it demands that you understand memory overhead and CPU reservations across your fleet. Neither mode is universally correct; the right choice depends on how uniform your VMs are and how much idle capacity you can afford.

Changing admission control or restart priorities on a live cluster is not a casual edit. It affects DRS placement and VM power-on behavior immediately. Plan the change during a maintenance window, and review cluster capacity before and after.

How to check your current state

You do not need a lab to validate this. Open the vSphere Client, select your cluster, and navigate to Configure > Services > vSphere HA. Review the Admission Control policy and the host failure tolerance. Then inspect individual VMs under VM Options to confirm restart priority values. Compare the cluster summary capacity against the configured threshold or failover host pool. Document your host count, VM resource requirements, and desired failover target so the policy matches the protection level you actually intend.

These UI paths reflect the vSphere Client in recent vSphere 7 and 8 releases; exact labels may differ by version and edition. Editing HA settings requires a role with cluster configuration privileges. Start by auditing whether your current reservation obviously covers your largest tier-1 VM. If the math is not obvious, tighten the reservation before you tune priorities. Then align restart priority with business criticality. HA is only as predictable as the capacity you deliberately left behind.