A host is put into maintenance mode for patching or hardware work. The task stops moving, the virtual machines stay where they are, and the cluster's DRS Faults page shows the line in the title. Admission control is applying the failover capacity rule it was set up with, and refusing migrations that would break it.
A common suggestion is to turn admission control off. That stops vCenter enforcing the failover capacity reserve; vSphere HA itself stays on. Even with admission control on, a restart after a host failure still depends on placement, storage and network, so neither setting is a promise that every VM restarts. This article records what admission control is counting and hands that record to the cluster owner. It does not cover how to change anything.
Scope
vSphere 8.0 clusters with HA and DRS, without vSAN. Everything below is a read in the vSphere Client. Numerical interpretation is given for the cluster resource percentage policy only; the slot and dedicated failover host policies are recorded and handed over without a capacity verdict. Out of scope: vSAN data evacuation choices, other stall causes (listed in Step 4 as other candidates), and any change to HA, DRS, hosts, VMs or a running maintenance or remediation task. For HA not restarting VMs after a failure, see the published article vSphere HA did not restart some VMs.
What admission control does to a migration
The vSphere 8.0 guide says admission control "imposes constraints on resource usage. Any action that might violate these constraints is not permitted." Among its examples is "Migrating a virtual machine". An evacuation is a set of migrations, so admission control can refuse them.
For the percentage policy, the 8.0 guide describes two separate checks:
- The minimum host check. The percentage policy "also checks that there are at least two vSphere HA-enabled hosts in the cluster (excluding hosts that are entering maintenance mode)." With only one such host, the operation is refused "even if there is a sufficient percentage of resources available", because HA cannot fail over to a host that is not there.
- The capacity check. It compares current with configured failover capacity, for CPU and memory separately. In the host totals, "Only hosts that are connected, not in maintenance mode, and have no vSphere HA errors are considered." The guide states the exclusion of hosts entering maintenance mode for the minimum host check only. This article does not assume how a host that is still entering maintenance mode is treated in the capacity totals or in slot calculations.
With dedicated failover hosts, "you are prevented from powering on virtual machines or using vMotion to migrate virtual machines to a failover host." Evacuated VMs cannot land there.
Step 1: record the stalled task
| Field | What to record |
|---|---|
| A | Cluster name, vCenter version and build, ESXi version and build of each host |
| B | The host entering maintenance mode, who started it, when (with time zone), and from where: by hand, or by a vSphere Lifecycle Manager remediation |
| C | Task progress percentage and its status text. KB 318773 (vCenter 8.0, ESXi 8.0) shows the message "Waiting for all virtual machines to be powered off or suspended or migrated. In a DRS cluster check the Faults page on the DRS tab for troubleshooting" |
| D | Monitor > vSphere DRS > Faults: each fault line, the VM it names, and the time |
| E | VMs still on the host, with power state and CPU and memory reservations |
KB 394680 (no version stated) shows this pair of lines on the Faults page for its two-host case: "The operation is not allowed in the current state." and "vSphere HA admission control is preventing the operation." Record the exact text you see for each VM. A different fault line points to a different candidate (Step 4).
Step 2: record the admission control settings
From the cluster's Configure > vSphere Availability > Admission Control, read only:
| Field | What to record |
|---|---|
| F | Host failures the cluster tolerates |
| G | Define host failover capacity by: cluster resource percentage, slot policy, dedicated failover hosts, or disabled; with the percentages, slot size or failover host names |
| H | Performance degradation VMs tolerate |
| I | If a Lifecycle Manager remediation started the task: whether its remediation settings are set to deactivate HA admission control, and whether the cluster uses baselines or a single image |
The 8.0 Lifecycle Manager page says it "deactivates HA admission control before remediation, but not before compliance checks", and for baseline-managed clusters also before staging, and that it "restores the HA admission control settings" after the whole cluster is remediated. Field I records what was configured, so nobody assumes it.
Step 3: record the hosts and capacity admission control sees
| Field | What to record |
|---|---|
| J | Every host in the cluster: connected or not, in maintenance mode or entering it, any vSphere HA error, and whether it is a dedicated failover host |
| K | For the percentage policy: the number of HA-enabled hosts left once every host entering maintenance mode is excluded |
| L | For the percentage policy: current and configured CPU and memory failover capacity as shown, the screen they were read from, and the time. Note whether the time is close to the fault times in D |
| M | For the slot policy: slot size, slot counts and current and configured failover capacity as shown, the screen they were read from, and the time |
How to read the percentage numbers
The 8.0 guide computes current failover capacity, separately for CPU and memory, as total host resources minus total resource requirements of powered-on VMs, divided by total host resources. Host resources are those "contained in the host's root resource pool", counted only for hosts that are connected, not in maintenance mode and without HA errors. Requirements are each powered-on VM's reservation; with no CPU reservation, "a default of 0MB memory and 32MHz CPU is applied", and memory adds each VM's overhead. Admission control refuses when either current value "is less than the corresponding Configured Failover Capacity".
Two consequences for the record:
- A VM that moves from one host to another in the same cluster is already powered on there. Its reservation is already in the requirements total, so the move does not add a new requirement.
- Only a value strictly below configured is a refusal. A screenshot that shows current capacity equal to or near configured does not, on its own, show that the capacity check refused anything.
A fictional calculation. Three counted hosts give 30 GHz of CPU. Powered-on VMs require 20 GHz. Current CPU failover capacity is (30 − 20) / 30 = 33.3%. Configured is 33%. 33.3% is not less than 33%, so the capacity check allows the operation, even though the two numbers look "near". If one 10 GHz host had dropped out of the counted set, the total would be 20 GHz and current capacity (20 − 20) / 20 = 0%, which is below 33%. The difference comes from which hosts are counted, not from the VMs moving.
For the slot policy, the 8.0 guide defines current failover capacity as "the number of hosts that can fail and still leave enough slots to satisfy all of the powered-on virtual machines", and refuses when it is less than configured. Field M records those values. This article gives no verdict on how a host entering maintenance mode changes the slot count.
Step 4: classify
| What the record shows | Candidate explanation | Handed to |
|---|---|---|
| Percentage policy, K is 1, and D shows the admission control line | The minimum host check: only one HA-enabled host is left once hosts entering maintenance mode are excluded | Cluster owner |
| Percentage policy, K is 2 or more, D shows the admission control line, and L (read close to D) shows current CPU or memory capacity strictly below configured | The capacity check is refusing the migrations | Cluster owner |
| Percentage policy, K is 2 or more, and L shows current equal to, near or above configured, or L was read at another time | Not established by this record; record as unresolved | Cluster owner |
| Slot policy with the admission control line in D | Slot policy refusal; M recorded without a verdict on how the entering host is counted | Cluster owner |
| Dedicated failover hosts, and the other hosts lack room | Evacuated VMs cannot be placed on the failover host | Cluster owner |
| D names a VM-VM or VM-Host rule, a device, or a vMotion compatibility error | Another blocker, not admission control (see the DRS rules and vMotion articles) | vSphere owner |
| DRS is not fully automated, or a VMware Tools installer ISO is still connected | Other candidates (KB 451053, KB 310528), not covered here | vSphere owner |
| D has no admission control line, or the fields conflict | Unresolved | vSphere owner, record as is |
More than one row can apply at once.
What this record does not authorise
The record ends with the handover. A matching row, or a named owner, does not authorise reducing protection, powering off or suspending VMs, or changing a maintenance or remediation task that is in progress. That includes disabling admission control, changing its policy or percentages, changing reservations, cancelling the task and changing Lifecycle Manager settings. The 8.0 guide warns that without admission control "you have no assurance that the expected number of virtual machines can be restarted after a failure."
Any such change is outside this article. It would first need a qualified review, and validation away from production, of at least: the exact topology and versions; which host is left and how its workloads stay protected; every maintenance or remediation task already running; dependencies and access for recovery; how to abort or reverse it; and how the application owners accept the result. This article gives no steps for it.
Two-host clusters
The guide's two-host warning is about maintenance: "when one of the two hosts enters maintenance mode, vCenter Server cannot failover virtual machines to that host and HA failovers are never successful." While one host is in maintenance mode, there is no other host to fail over to. That holds whether admission control is on or off; turning it off removes the capacity check, not HA and not the second host once it is back.
Worked example (fictional)
The values below are invented. Cluster prod-b has three hosts, esx-11 to esx-13, on vSphere 8.0 U3 with HA and DRS fully automated, no vSAN. At 21:05 AEDT an operator puts esx-12 into maintenance mode by hand.
| Field | Value |
|---|---|
| C | 2%, waiting for virtual machines to be powered off or migrated |
| D | Eight lines naming db-04 to db-11: "vSphere HA admission control is preventing the operation." |
| F, G | Tolerates 1 host failure; cluster resource percentage, 33% CPU and 33% memory |
| J | esx-11 and esx-13 connected, no HA errors; esx-13 entering maintenance mode since 20:40 (started by another team for a firmware update) |
| K | 1 |
| L | Recorded for completeness; not used for this row |
Classification: the minimum host check row. With esx-12 and esx-13 both entering maintenance mode, only esx-11 counts for that check, so the percentage policy refuses the migrations. This example uses only the minimum host check; it says nothing about how slot or capacity totals treat the two entering hosts. The record goes to the cluster owner with both maintenance tasks and their owners named. Admission control and both tasks stay as they are.
Acceptance checks
- Fields A to M are recorded, or marked not available with the reason, with times and time zone.
- The exact Faults page text is recorded per VM.
- K is counted from field J, not assumed from the host count.
- A capacity refusal is only recorded when L shows a value strictly below configured, read close to the faults.
- Each stall ends in a candidate row or as unresolved, with the owner named.
- Nothing was changed. Reading needs no rollback.
Learning notes
- Admission control refusing an evacuation is working as configured.
- For the percentage policy, a host entering maintenance mode is excluded from the minimum host check.
- Two hosts entering maintenance mode at once can leave a three-host cluster with one counted host, which fails that check.
- Moving a powered-on VM inside the cluster does not add a new reservation.
- Admission control off is not HA off. Neither setting alone guarantees a restart.
Related articles
- Published: vSphere HA did not restart some VMs: reading the event trail and checking admission control and isolation settings
- Published: How to patch an ESXi cluster with vSphere Lifecycle Manager
- Proposed, live only once published: DRS moves a VM back after a manual vMotion
Sources
KBs retrieved 2026-11-03 between 17:34:47 and 17:34:49 UTC and TechDocs pages between 17:35:26 and 17:35:30 UTC (4 November, Australia/Sydney). Dates are each page's own Last Updated or Updated On date.
- Broadcom TechDocs, vSphere 8.0, "vSphere HA Admission Control", 28 October 2026. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-availability/creating-and-using-vsphere-ha-clusters/vsphere-ha-admission-control.html
- Broadcom TechDocs, vSphere 8.0, "Configure Admission Control", 28 October 2026. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-availability/creating-and-using-vsphere-ha-clusters/configuring-cluster-settings/configure-admission-control.html
- Broadcom TechDocs, vSphere 8.0, "Cluster Resources Percentage Admission Control", 28 October 2026. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-availability/creating-and-using-vsphere-ha-clusters/vsphere-ha-admission-control/cluster-resources-percentage-admission-control.html
- Broadcom TechDocs, vSphere 8.0, "Slot Policy Admission Control", 28 October 2026. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-availability/creating-and-using-vsphere-ha-clusters/vsphere-ha-admission-control/slot-policy-admission-control.html
- Broadcom TechDocs, vSphere 8.0, "Dedicated Failover Hosts Admission Control", 28 October 2026. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-availability/creating-and-using-vsphere-ha-clusters/vsphere-ha-admission-control/dedicated-failover-hosts-admission-control.html
- Broadcom TechDocs, vSphere 8.0, "vSphere Lifecycle Manager Remediation Settings", 28 October 2026. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/managing-host-and-cluster-lifecycle/configuring-vlcm-remediation-settings-1.html
- Broadcom KB 318773, "ESXi host stuck \"in progress\" when entering maintenance mode", 28 September 2026. https://knowledge.broadcom.com/external/article/318773/esxi-host-stuck-in-progress-when-enterin.html
- Broadcom KB 394680, "2 node ESXi cluster fails to automatically migrate VMs when placed into maintenance mode", 19 June 2026. https://knowledge.broadcom.com/external/article?articleNumber=394680
- Broadcom KB 451053, "VMs won't vMotion off Host when host is put into maintenance mode: vCenter Server", 14 September 2026. https://knowledge.broadcom.com/external/article/451053/vms-wont-vmotion-off-host-when-host-is-p.html
- Broadcom KB 310528, "Migrating a virtual machine fails when entering the maintenance mode with the error: Tools installation in progress", 21 February 2025. https://knowledge.broadcom.com/external/article/310528/migrating-a-virtual-machine-fails-when-e.html