vSphere HA Cluster Admission Control Failure — Fixed
HA admission control blocks VM startup when it thinks cluster resources are too low. The fix: adjust admission control policy or disable it.
You're staring at a red banner in vCenter saying "HA admission control failure: insufficient resources" and no new VMs will power on. It's frustrating. Let's get past it.
The Quick Fix: Disable Admission Control
This is the fastest way to get VMs running again. If you're in a production cluster, you might not want to disable it permanently — but for right now, it's the right move.
- Open vSphere Client (web or desktop) and connect to your vCenter Server.
- Go to Hosts and Clusters.
After clicking, you should see your datacenter and cluster objects in the left tree. - Select your cluster (the one showing the HA error).
- Click the Configure tab.
You'll see a row of sub-tabs under Configure — look for vSphere Availability. - Under Services, click vSphere Availability.
This opens the HA settings page. - Click the Edit button (top right of the vSphere Availability section).
A dialog box appears with the cluster HA settings. - Under Admission Control, change the policy from whatever it is to "Disabled admission control".
You'll see the radio buttons — pick the bottom one. - Click OK to save.
Wait 10–30 seconds. The banner should disappear. If it doesn't, right-click the cluster and select "Reconfigure for vSphere HA".
Now try powering on your VMs. They should start. If they don't, check host resource usage separately (CPU/memory). The admission control policy was the gatekeeper.
Why That Fix Works
vSphere HA's admission control is a safety mechanism. It reserves a certain percentage (or number of host failures) worth of resources so that if a host dies, the surviving hosts can restart the VMs that were on it. The problem is, this reservation is often too aggressive. For example, if you set it to reserve for 1 host failover in a 3-host cluster, the cluster effectively blocks any new VMs when total free resources drop below 33% — even if you don't actually need that much headroom. In vSphere 7 and 8, the default policy is "Host failures cluster tolerates" set to 1. That means the cluster reserves enough resources to cover one full host's worth of VM memory and CPU. If your hosts are heavily loaded already, that reservation leaves you with no room for new VMs. Disabling admission control removes that reservation, so the cluster lets you start VMs up to the actual physical limits of the hosts. The trade-off: if a host dies now, some VMs might not restart if the remaining hosts don't have enough spare resources. But in many environments, that's a risk worth taking — especially if you have DRS or other balancing tools.
Less Common Variations of the Same Issue
Admission Control Policy Set to "Percentage of cluster resources"
Same error, different number. You might see it with a custom percentage like 25% or 50%. The fix is the same — disable it, or lower the percentage. But lowering it can be tricky: if you set it to 10% and your cluster has 4 hosts, that's not enough to survive a single host failure in most cases. I'd suggest either completely disable it or use the "Host failures cluster tolerates" policy and set it to 0 (which is effectively the same as disabled).
Host Isolation Response
Sometimes the error message says "admission control failure" but the real problem is the host isolation response setting. Go back to vSphere Availability settings and check the Host Isolation Response dropdown. If it's set to "Power Off VMs and restart them" but you don't have a configured HA network, the cluster can't guarantee failover. Change it to "Leave powered on" for now, or fix your HA networking (two separate management networks, separate switches).
HA Datastore Heartbeat Failure
Less common but I've seen it. The admission control failure can also appear if HA can't determine the datastore heartbeats. Check the Advanced Options in the HA settings (there's a button at the bottom). Look for das.heartbeatDsPerHost. The default is 2. If you have fewer than 2 shared datastores across all hosts, HA might trip. Either increase datastore count or reduce this value to 1. Be careful — reducing to 1 means a single datastore failure can cause split-brain scenarios. But if you're stuck, it's a valid workaround.
# Example of checking HA advanced options through PowerCLI
Get-Cluster -Name 'YourCluster' | Get-VMHostHAProperty | Select-Object *
Prevention: Stop This from Happening Again
Don't just leave admission control disabled forever. That's a band-aid. Instead, do this:
- Monitor your cluster resource usage — set up alarms in vCenter for memory and CPU usage above 80%. When you're at 80% total, admission control often kicks in.
- Size your host reservations correctly. Use the "Host failures cluster tolerates" policy with the value set to 1 or 0, but never use the percentage slider unless you really know what you're doing. I've seen too many admins set it to 50% and then wonder why they can't start VMs on a 5-host cluster.
- Add a dedicated HA heartbeat datastore — a small 1GB VMFS datastore that's shared across all hosts. It keeps the HA heartbeats from conflicting with production datastore load.
- Test failover scenarios regularly. Shut down one host during a maintenance window and see if VMs restart on others. That'll tell you if your admission control settings are realistic.
- Consider vSphere DRS with Host Affinity rules. DRS can keep VMs spread out to avoid resource contention, which reduces the chance that admission control blocks new starts.
In short: admission control is a feature that's often more trouble than it's worth in smaller clusters. If you have fewer than 4 hosts, I'd disable it and rely on DRS and monitoring. For larger clusters, set it to tolerate 1 host failure — that's usually enough. And when in doubt, disable it, get your VMs running, and then plan the permanent fix.
Was this solution helpful?