During a host failure event virtual machines (VMs) fail to automatically restart on the healthy hosts in a cluster. The affected VMs remain in a disconnected state on the failed host.
When reviewing the vCenter Server User Interface (UI), the affected ESXi host reports a "Not Responding" status, but vSphere High Availability (HA) VM failover fails.
The following symptoms and logs are observed on the Fault Domain Manager (FDM) logs of Primary host:
vSphere HA triggers the failover process but logs insufficient resource events.
VM Placement fail with NoActiveHostInCluster
In the /var/log/fdm.log on the Primary FDM host, you will see log entries similar to:
xxxx-xx-xxT0x:xx:xx.xxxZ Db(167) Fdm[6719454]: [Originator@6876 sub=Placement opID=3f2a6789] Setting insufficient resource timeout to 60 seconds and retrying placement for vm /vmfs/volumes/xxxxxxxx-xxxxxx-0000-000000000000/VM_Name/VM.vmxxxxx-xx-xxT0x:xx:xx.xxxZ Db(167) Fdm[6719454]: [Originator@6876 sub=Placement opID=3f2a6789] Reset the placement status of vm /vmfs/volumes/xxxxxxxx-xxxxxx-0000-000000000000/VM_Name/VM.vmx to 0, vim.fault.NoActiveHostInCluster (vim.fault.NoActiveHostInCluster)
xxxx-xx-xxT0x:xx:xx.xxxZ Db(167) Fdm[6719471]: [Originator@6876 sub=Invt opID=placementService.cpp:151-1039e3be] Can't find datastore with moId 10.x.xxx.xxx:Datastore_Name on host host-xxxx for VM /vmfs/volumes/xxxxxxxxx/VM_Name/VM.vmx
xxxx-xx-xxT0x:xx:xx.xxxZ Db(167) Fdm[2099744]: [Originator@6876 sub=Placement opID=47f7e02c] Vm /vmfs/volumes/xxxxxx/VM_Name/VM.vmx failed placement with fault [N3Vim5Fault21NoActiveHostInClusterE:0x000000e254e2f1a0]
VMware ESXi 7.x / 8.x
VMware vCenter Server 7.x / 8.x
NFS Storage
This issue occurs due to non-uniform NFS mount point configurations across the ESXi hosts in the cluster. For vSphere HA to successfully protect and restart a virtual machine, all potential failover target hosts within the cluster must have uniform storage visibility to the same datastores.
If an NFS datastore is mounted with a mismatch in the share path (for example, missing the leading forward slash / on some hosts), vCenter Server handles them as distinct mount points. As a result, the vSphere HA placement engine determines that no compatible target hosts are available to run the virtual machines, blocking the automated recovery process.
You can verify this mismatch by running the following CLI command on the ESXi hosts:
localcli storage nfs41 list
Example of a healthy Master host (with leading slash /):
Volume Name Host(s) Share Accessible Mounted
----------------------- ------------ ---------- ---------- -------
Datastore_Name x.x.x.x /Mount_Point true true
Example of an affected Slave host (missing the leading slash /):
Volume Name Host(s) Share Accessible Mounted
----------------------- ------------ ---------------- -------------- -------
Datastore_Name x.x.x.x Mount_Point true true
To resolve this issue, Correct the inconsistent NFS paths so that all ESXi hosts share an identical mount path.
Audit the Cluster: Log into ESXi hosts via SSH or check the vSphere Client to identify all hosts exhibiting the mismatched NFS share path syntax. Use command : localcli storage nfs41 list
Prepare the Host: Select an affected ESXi host, migrate all running virtual machines off the host using vMotion, and place the host into Maintenance Mode.
Unmount the Inconsistent Datastore: Right-click the mismatched NFS datastore, navigate to Storage, and select Unmount Datastore.
Remount with the Correct Path: Remount the NFS volume onto the ESXi host, ensuring the Folder/Share path perfectly matches the working hosts (including the leading /).
Verify and Exit Maintenance Mode: Ensure the datastore can be successfully browsed from the host, then take the host out of Maintenance Mode.
Repeat: Complete steps 2 through 5 for any remaining affected hosts in the cluster.
Reconfigure HA (Optional): Right-click the cluster and select Reconfigure for vSphere HA to force an updated inventory sync across the FDM cluster components.