Short answer: When vCLS VMs refuse to power on, the error text usually points to the cause. “No host is compatible with the virtual machine” with cpuid.mwait in the details means the host CPU does not expose MONITOR/MWAIT, which the per-VM EVC baseline of vCLS VMs requires. Enable it in the server BIOS (or fix the nested ESXi VM configuration in labs), then cycle Retreat Mode so vCenter redeploys fresh vCLS VMs. Other causes are nested virtualization flags, privileges and resource or datastore problems.
This article covers only the power-on failure. For what vCLS is and why DRS and HA depend on it, see Introduction to vSphere Clustering Service (vCLS). For the Retreat Mode procedure used below, see How to disable vCLS on a vSphere cluster using Retreat Mode.
Match the error to the cause
Open the failed power-on task in the vSphere Client and expand the details, or check vmware.log of the vCLS VM. The detail line tells you which of these applies.
| Error / detail | Cause | Broadcom KB |
|---|---|---|
| No host is compatible with the virtual machine; Feature ‘cpuid.mwait’ was 0, but must be 1 | MONITOR/MWAIT disabled or hidden by the host firmware | 395205, 390674 |
| Cluster Agent VM cannot be powered on due to insufficient resource | Per-VM EVC requires MWAIT; the same root cause surfacing differently | 326217 |
| Insufficient resources on a single-host cluster after a vCenter restore | Stale vCLS state after the restore | 410905 |
| Feature ‘bad_requirement:hv.capable’ was 0, but must be at least 1 | vhv.enable = true set host-wide in /etc/vmware/config | 344779 |
| Privilege check failed for user VSPHERE.LOCAL\vpxd-extension-… | Solution users have excessive group memberships | 316318 |
| Can’t provision VM for ClusterAgent due to lack of suitable datastore | EAM keeps retrying a datastore that is no longer suitable | 423594 |
Fix: “No host is compatible” and cpuid.mwait
vCLS VMs are deployed with a per-VM EVC mode that expects the cpuid.mwait flag. If the host firmware hides MONITOR/MWAIT, DRS cannot find a host that meets the VM’s CPU requirements, and every power-on attempt fails.
- Place the host in maintenance mode and reboot into BIOS/UEFI setup.
- Enable the Monitor/MWAIT option in the CPU or power-management section. KB 390674 also recommends updating outdated BIOS firmware and setting C-States to the vendor’s recommended (“autonomous”) value.
- Boot ESXi and exit maintenance mode. Repeat for every host in the cluster.
- Put the cluster into Retreat Mode, wait for the vCLS VMs to be removed, then set it back to normal. vCenter deploys new vCLS VMs that pick up the corrected CPU features.
To check the flag from the ESXi shell, KB 395205 uses esxcfg-info. Look at the ECX value of CPUID leaf 1. If the last hex digit is f, MWAIT is exposed.
esxcfg-info | less
# search for "CPUID 1" and check the ECX register valueIf you cannot change the BIOS right away, KB 326217 describes a workaround (ESXi 6.7 or later): upgrade the vCLS VM compatibility to hardware version 14, which makes the per-VM EVC setting editable on the VM’s Configure tab. Then disable EVC for each vCLS VM until it powers on. Treat this as temporary. The BIOS change is the real fix.
Nested ESXi and VCF Holodeck labs
Nested hosts often expose a reduced CPUID set, so the same MWAIT error shows up in labs built with Holodeck or similar toolkits. William Lam (linked below) fixed it with the hardware version 14 plus per-VM EVC step described above. He later traced it to the guest OS type configured for the nested ESXi VMs. For lab-only setups, check that the nested ESXi VMs use the correct ESXi guest OS type before touching vCLS.
The reverse problem happens on physical hosts. If someone enabled nested hardware virtualization host-wide with vhv.enable = true in /etc/vmware/config, vCLS fails with bad_requirement:hv.capable. KB 344779 resolves it by commenting out or removing that line and restarting the host. Only do this on hosts that are not meant to run nested hypervisors.
Other causes and fixes
- Privilege check failed for vpxd-extension: KB 316318 provides a
fixAdministratorsGroupscript. Take an offline snapshot of vCenter (all linked vCenters in ELM) first, run the script in check mode, then in fix mode. - Insufficient resources after a vCenter restore (KB 410905): cycle Retreat Mode to regenerate the vCLS VMs.
- No suitable datastore (KB 423594): cycle Retreat Mode so EAM re-evaluates placement against the currently healthy shared datastores. On Supervisor (Workload Management) clusters, the KB says to fix the underlying datastore issue instead.
- ESXi 8.0 U3 embedded vCLS: if Cluster Services shows Unhealthy, check the Infravisor service on each host (KB 386044).
/etc/init.d/infravisor status
/etc/init.d/infravisor startAfter any fix, confirm that all vCLS VMs are powered on and that the cluster summary no longer reports impaired DRS or HA.
