vSphere HA ‘Insufficient resources to satisfy configured failover level’: admission control

The error “Insufficient resources to satisfy configured failover level for vSphere HA” is admission control refusing a VM power-on, vMotion, or reservation change because granting it would leave the cluster without enough spare capacity to honor the configured HA failover policy. Admission control is doing its job: protecting the restart guarantee after a host failure.

The cluster may physically hold more capacity than admission control lets you commit. A cluster with 500 GHz of CPU and 2 TB of RAM may only let you deploy against roughly 70% of that, with the rest held in reserve so HA can restart protected VMs after a host failure. Operators who bought hardware expecting to use all of it hit this wall during provisioning and reach for the disable switch.

Disabling admission control unblocks deployments in seconds and silently removes the restart guarantee. With admission control off, the “Protected” column in the HA UI becomes aspirational, not guaranteed. When a host fails, surviving hosts may have no room to restart its VMs, and HA will leave them powered off. VMware’s own documentation is blunt on this point: “Do not permanently deactivate admission control.”

What this means

vSphere HA admission control is a capacity-reservation gatekeeper. Before any operation that increases committed resources (power-on, vMotion into the cluster, reservation increase, memory-heavy snapshot), it evaluates whether the cluster would still satisfy its configured failover level after the change. The failover level is the number of host failures the cluster tolerates while still being able to restart all protected VMs.

Three admission control policies are available in vSphere 7.0 and 8.0, unchanged since the 6.5 overhaul:

Cluster Resource Percentage (default since vSphere 6.5). Reserves a percentage of total cluster CPU and memory for failover. The percentage is derived from the configured number of host failures to tolerate and is recalculated automatically when hosts join or leave the cluster. The reserved capacity is computed against current committed resources, not a static carve-out of total hardware: current uncommitted capacity must remain at or above the configured percentage of total resources. A setting of “25%” does not mean a quarter of the cluster sits idle. It means current slack must stay above 25% of total.

Slot Policy. Divides the cluster into fixed-size “slots,” each sized from the largest powered-on VM’s CPU and memory reservations plus overhead. Each powered-on VM consumes one slot. The cluster must keep at least N slots free, where N is the host failure tolerance. Default slot size when no reservation is set is 32 MHz CPU (since vSphere 5.0) and the largest memory reservation plus overhead among powered-on VMs. Slot policy is the most conservative and the most easily distorted: a single VM with a very large reservation inflates slot size for every VM in the cluster, wasting capacity across the board.

Dedicated Failover Hosts. Identifies specific hosts as pure failover targets. They run no VMs under normal operation. Admission control requires those hosts to remain empty, connected, and available.

Admission control requires at least three hosts in the cluster. A two-node cluster will refuse strict policies or behave unpredictably. There is a documented gotcha in two-node vSphere 7.0.x and 8.0.x clusters where vCenter may count only one host (numHosts=1) due to underlying datastore connectivity issues, producing the “Insufficient resources” error even when both hosts appear healthy. The documented resolution is to remove and re-add the affected host to vCenter.

flowchart TD
    A["Power-on / vMotion / reservation change"] --> B{"Admission control check"}
    B -->|"Failover level preserved"| C["Operation allowed"]
    B -->|"Failover level breached"| D["Operation blocked"]
    D --> E["Error: Insufficient resources for HA failover"]
    E --> F["Add capacity, reduce reservations,
or right-size slot policy"]
    E --> G["Disable admission control
(removes restart guarantee)"]

Common causes

Quick checks

All read-only. None of these change cluster state.

# PowerCLI: cluster HA and admission control state, current failover level
Get-Cluster | Select Name, HAEnabled, HAAdmissionControlEnabled,
  @{N='CurrentFailover';E={$_.ExtensionData.Summary.CurrentFailoverLevel}}

# PowerCLI: configured vs current failover level side by side
Get-Cluster | Select Name,
  @{N='ConfiguredFailover';E={$_.ExtensionData.Configuration.DasConfig.FailoverLevel}},
  @{N='CurrentFailover';E={$_.ExtensionData.Summary.CurrentFailoverLevel}}

# ESXi SSH: FDM (HA agent) status
/opt/vmware/fdm/bin/fdm --status

# ESXi SSH: HA runtime state via hostsvc
<!-- TODO: verify the exact vim-cmd subcommand. Candidates are hostsvc/ha/getfdlstate or hostsvc/runtimeinfo; fdmstate may not be valid. -->
vim-cmd hostsvc/ha/fdmstate

# FDM log for admission control, election, and failover-level events
grep -i "admission\|failover\|slot" /var/log/fdm.log | tail -50

How to diagnose it

1. Confirm admission control is the source. Open Cluster > Monitor > vSphere HA. If HA and admission control are both enabled, the error is admission control refusing the operation. If HA is disabled, the error is from a different source (resource pool reservation, host-level check).
2. Read the current failover level. CurrentFailoverLevel in the cluster summary tells you how many host failures the cluster can currently tolerate. Zero means no spare capacity for restarts. Compare to the configured failover level. If current is below configured, every new power-on will fail until capacity is added or VMs are removed.
3. Identify which policy is active. Cluster > Configure > vSphere HA > Admission Control. The policy dictates your fix path. Cluster Resource Percentage means capacity is genuinely committed. Slot Policy means you should hunt for an oversized VM driving slot size. Dedicated Failover Hosts means you should confirm the failover host is empty.
4. For Slot Policy, identify the slot driver. The slot size is set by the largest CPU reservation and the largest memory reservation among powered-on VMs. A single database VM with a 256 GB memory reservation makes every small web VM count as a 256 GB slot. List VMs sorted by reservation.
5. For Cluster Resource Percentage, verify the calculation. The reserved percentage is computed against current committed resources, not total hardware. A cluster that looks lightly loaded on paper can still fail admission control if active reservations and overhead consume the slack.
6. Check for the two-node numHosts=1 issue. If you have a two-node cluster and the error appears despite obvious capacity, check /var/log/fdm.log for numHosts=1. The documented fix is to remove and re-add the suspect host.

Metrics and signals to monitor

Fixes

Genuine capacity exhaustion. Either add hosts, reduce VM reservations, or accept a lower failover level. Reducing the failover level is a real tradeoff: you are accepting that the cluster cannot survive N host failures and still restart everything. The UI will silently revert the value back up if existing reservations already consume the lower level’s capacity. Check Cluster > Monitor > vSphere HA > Reserved failover CPU/Memory to see whether a decrease is even possible.

Slot policy distortion. A single oversized VM should not dictate capacity for every other VM. Use the advanced options das.slotcpuinmhz and das.slotmeminmb to set upper bounds on slot size, decoupling the slot from the largest reservation. This is a documented, supported mechanism. Re-evaluate whether Slot Policy is the right choice at all: Cluster Resource Percentage is more forgiving for environments with mixed VM sizes because it does not let one VM inflate the accounting unit for the rest of the cluster.

Dedicated Failover Hosts. Confirm the failover host is empty, connected, and not in maintenance mode. If VMs have landed on it (DRS will not place them there, but manual operations can), vMotion them off. If the failover host is down, admission control has no failover target and will block operations.

The disable switch. Disabling admission control is the fastest unblock and the worst long-term decision. It removes the restart guarantee. “Protected” becomes aspirational. Use it only for a planned, time-bounded maintenance window where you have accounted for the unprotected interval, and re-enable it before the window closes. If you must disable it, treat the disabled interval as an incident: page on it, track its duration, and have a rollback plan.

The “Performance degradation VMs tolerate” misconception. This setting (default 100%) is often confused with admission control. It does not require admission control to be enabled. It requires only DRS. It evaluates a single failure scenario, not the configured failover count, and it issues a configuration notice rather than blocking operations. Do not treat it as a substitute for admission control, and do not assume that because it is configured, your restart guarantee is intact.

Prevention

• Monitor CurrentFailoverLevel continuously. A cluster trending toward zero is a cluster about to refuse power-ons. Alert before it hits zero, not after.
• Track the largest VM reservation in Slot Policy clusters. A new oversized VM can collapse slot headroom overnight.
• Treat admission control disable events as incidents. If monitoring shows admission control flipped off, page someone. It is almost always someone unblocking a deployment and forgetting to re-enable.
• Right-size reservations. Reservations are the most common silent capacity consumer. Many are inherited from templates and never revisited.
• Plan capacity against usable capacity, not physical capacity. If your failover policy reserves 25%, your deployable capacity is roughly 75% of hardware. Provisioning against 100% guarantees you will hit admission control.
• Prefer Cluster Resource Percentage for mixed workloads. Slot Policy is simple to reason about but punishes you for any one large VM. The default policy exists for good reasons.

How Netdata helps

• Cluster-level HA signals. Netdata surfaces HA cluster health, admission control state, and current failover level as first-class metrics, so you can see capacity headroom without logging into vCenter during an incident.
• Correlation with host connection state. Admission control depends on hosts being connected. Netdata correlates HA failover capacity with per-host connection state, so a notResponding host that collapses the failover level shows up in the same view.
• Slot policy distortion detection. By tracking the largest VM reservations alongside slot count and powered-on VM count, Netdata highlights when a single VM is driving slot size for the whole cluster.
• Disable event detection. A boolean toggle on admission control enabled, tracked per-second, catches the “someone turned it off to unblock a deploy” pattern before the next host failure exposes the gap.
• Capacity trending. Long-term trends on reserved failover CPU and memory give you runway estimates before the cluster starts refusing power-ons.

Related guides

• vSphere active vs consumed vs granted memory: why the percentage lies
• vSphere CPU co-stop high (%CSTP): the SMP vCPU co-scheduling penalty
• vSphere CPU limit hit (%MLMTD): the forgotten MHz cap that silently throttles a VM
• vSphere CPU ready time high (%RDY): VMs starved while the guest looks idle
• vSphere datastore full: ‘No space left on device’, paused VMs, and power-on failures
• vSphere datastore IOPS and throughput: spotting storage saturation before latency bites
• vSphere datastore latency high: reading GAVG, DAVG, and KAVG
• vSphere dropped packets (%DRPRX/%DRPTX): ring buffers, CPU, and uplink backpressure
• vSphere storage latency cliff: the ’everything is slow’ incident that hits every VM at once
• vSphere PSOD (purple screen of death): diagnosing an ESXi host crash
• vSphere host swapping (SWCUR/SWW/s): hypervisor swap and the memory death spiral
• How vSphere actually works in production: a mental model for operators