vSphere HA did not restart some VMs: reading the event trail and checking admission control and isolation settings

Direct answer: work VM by VM. For each VM that stayed down or was powered off unexpectedly, find the cluster event that explains HA's decision, then confirm it in /var/log/fdm.log on the primary host. The common reasons are all recorded. A VM override set restart priority to Disabled. Host Monitoring was off. HA found no compatible host, for example because of local storage or an ISO on a missing datastore. Failover capacity ran out. Or the host was judged isolated and its isolation response powered VMs off. Only after the per-VM reasons are known should you change policy. When you do, review admission control against the real failure tolerance you need, and isolation addresses and heartbeat datastores against how your network and storage are built, especially on vSAN. Validate with configuration and capacity checks, not by pulling a power cable on production.

Why it matters

HA is often treated as "on, therefore protected". After a real event, the question from the service owner is specific: why did this VM stay down for forty minutes? A generic answer ("HA was overloaded") does not survive review, and a policy change made without the per-VM evidence can make the next event worse. For example, disabling admission control to "make room" removes the guarantee that failover capacity exists at all.

The isolation case is the opposite failure. HA did act, but it powered off VMs on a host that was still running, because the host could not reach its peers or its isolation addresses. Whether that was correct depends on the network and storage design, not on HA itself.

How it works

Failure detection. The vSphere 8 Availability guide describes three host failure types: failure (the host stopped functioning), isolation (the host is running but cannot see HA agent traffic on its HA network) and partition (the host lost connectivity with the primary). The primary host exchanges network heartbeats with secondaries every second. When those stop, it checks datastore heartbeats and pings the host's management addresses before declaring it failed. A host that is still writing datastore heartbeats is treated as partitioned or isolated, not failed, and its VMs are not restarted on that basis alone.

Isolation. A host declares itself isolated when it cannot observe HA agent traffic and cannot ping its isolation addresses. Then it applies the cluster's host isolation response: Power off and restart VMs or Shutdown and restart VMs. Shutdown needs VMware Tools in the guest; VMs that have not shut down within 300 seconds, or das.isolationshutdowntimeout, are powered off. Isolation responses require Host Monitoring to be active, and a VM whose restart priority is Disabled gets no isolation response. By default, the isolation address is the management network's default gateway. Up to ten more can be set with das.isolationaddress0 to das.isolationaddress9, and das.usedefaultisolationaddress controls whether the gateway is used.

Heartbeat datastores. vCenter picks heartbeat datastores to maximise the number of hosts that can reach them and to avoid datastores backed by the same LUN or NFS server. das.heartbeatdsperhost sets how many: valid values 2 to 5, default 2. HA keeps a .vSphere-HA directory at the root of each datastore for heartbeats and for the list of protected VMs. The guide says not to delete or modify it.

vSAN changes the networking. With vSAN enabled, HA agent traffic uses the vSAN network, not management. vSAN datastores cannot be heartbeat datastores. A host is declared isolated only when its isolation addresses are unreachable and the vSAN network is inaccessible. Changes to the vSAN network are not picked up by HA automatically: the guide's order is deactivate Host Monitoring, change the network, Reconfigure for vSphere HA on every host, then re-activate. Broadcom KB 313763 recommends setting das.usedefaultisolationaddress=false and das.isolationaddress0 to a reachable address on the vSAN network where the management default gateway is not a meaningful test, and never to use an existing VMkernel interface IP as the isolation address.

Admission control. Admission control reserves capacity so failover can succeed for the configured Host failures cluster tolerates. The vSphere 8 guide lists four ways to define that capacity: cluster resource percentage, slot policy (powered-on VMs), dedicated failover hosts and disabled. With dedicated failover hosts, failovers can still use other hosts if the designated ones lack resources. A separate Performance degradation VMs tolerate percentage expresses how much degradation is acceptable during a failure. Admission control is about whether power-ons are allowed while the reservation holds. It does not guarantee that every VM restarts if reservations, overrides or placement constraints prevent it.

Restart priority and overrides. The cluster default restart priority applies to all VMs. VM overrides can change restart priority and isolation response per VM, which is useful for infrastructure services such as DNS that should start first. KB 395002 shows the cost of a forgotten override: a VM with restart priority Disabled is not powered on, and the cluster event says so explicitly.

Read-only checks

None of these was run for this article. All of them read events, logs or configuration.

1. Cluster events. In the vSphere Client, select the cluster > Monitor > Tasks & Events > Events, show cluster entries, and filter on "vSphere HA". KB 316525 lists the messages to expect: "vSphere HA initiated a failover action", and one "vSphere HA restarted virtual machine on host " per restarted VM. Export the list for the incident window. If events were not retained, KB 316525 notes the vCenter journal as an alternative source.

2. Per-VM reasons. For each VM not in the restarted list, look in its own events and the cluster events for messages such as "vSphere HA did not attempt to restart ... because its VM restart priority is Disabled" (KB 395002), "vSphere HA virtual machine failover failed" or "Not enough resources to failover this virtual machine" (KB 343894).

3. FDM log on the primary. The cluster's Hosts view shows each host's vSphere HA state (primary or secondary). As root on the host that was primary at the time, read /var/log/fdm.log. KB 316525 shows host host-NNNN changed state: Dead for failed hosts; KB 343894 shows DrmFault: reason powerOnVm ... NoCompatibleHost and HandleNotPlacedVms for VMs HA could not place.

4. Cluster HA configuration. Under Configure > vSphere Availability, record Host Monitoring state, host failure response, host isolation response, datastore heartbeat selection, admission control policy and the Host failures cluster tolerates value, and the advanced options in use (das.isolationaddress*, das.usedefaultisolationaddress, das.heartbeatdsperhost).

5. VM overrides. Configure > VM Overrides lists every VM with a non-default restart priority or isolation response. Compare it with the VMs that stayed down.

6. Heartbeat datastores per host. In each host's vSphere HA view, list the datastores actually selected for heartbeating. Note whether they share a LUN, an array or an NFS server.

7. Placement constraints. For VMs reported as not placed, check for local-disk VMDKs, ISOs or other files on datastores not visible to other hosts, VM-host "must" rules, and network port groups that exist only on some hosts.

Interpreting the results

A single incident often shows several reasons at once. Write them down per VM before drawing a cluster-wide conclusion.

Decision guidance

Overrides and dependencies first. These are per-VM, low-risk changes. Remove stale Disabled priorities, move ISOs to shared storage or disconnect them, and remove local-disk dependencies for VMs that are meant to be protected. Rollback is restoring the recorded override.

Admission control. Decide what the cluster must survive (for example, one host failure at peak) and choose a policy that reserves for it. Cluster resource percentage is the most direct way to express "keep this much spare". If admission control is currently Disabled, enabling it can block new power-ons when the cluster is already over-committed. That is the purpose, but it should be planned and announced. Check current usage against the reservation before changing the policy, and record the old values as the rollback.

Isolation addresses and heartbeat datastores. Choose isolation addresses that are reachable only when the host's HA network is genuinely healthy, and that are not themselves single points of failure. On vSAN, follow KB 313763 and the vSAN networking table rather than management-network habits. For heartbeat datastores in a cluster with conventional shared storage (VMFS or NFS), prefer datastores on independent storage paths. If such a cluster raises an insufficient-heartbeat-datastores warning, look at why fewer shared datastores are visible to every host than expected before deciding whether to suppress it. A vSAN-only cluster is different: the guide states that a vSAN datastore cannot be used for heartbeating, so with no other shared storage there can be no heartbeat datastores, and that is a supported configuration. Where storage reachable over a network path independent of vSAN exists, it can serve as a heartbeat datastore; adding such storage is a design choice, not a requirement. When you change the vSAN network or HA networking, follow the guide's sequence: deactivate Host Monitoring, make the change, reconfigure HA on each host, re-activate Host Monitoring.

Isolation response choice. Shutdown and restart preserves guest state at the cost of slower failover, and requires VMware Tools. Power off and restart is faster but abrupt. The right choice depends on how likely an isolated host is to also have lost its storage. This article does not state the product default; check your cluster's configured value.

Non-disruptive validation. After changes, confirm that Host Monitoring is on and the summary shows no HA configuration issues. Confirm each host shows the expected primary or secondary state and heartbeat datastores. Confirm VM overrides match the intended list, and that admission control shows the reservation you expected against current usage. If a failure test is required, plan it on a non-production cluster or with a maintenance window and a documented recovery. Do not pull a power cable on a production host.

What not to do

• Do not disable admission control to fix an incident's power-on failures without understanding the capacity it was protecting.
• Do not delete or edit the .vSphere-HA directory on any datastore.
• Do not use an existing VMkernel IP as an isolation address, or point isolation at an address that fails along with the host's own uplinks.
• Do not change vSAN networking with Host Monitoring active.
• Do not draw cluster-wide conclusions from one VM's outcome.
• Do not run failure tests on production hosts.

Limitations

Fault Tolerance, Proactive HA, VM and application monitoring, and storage responses to APD and PDL conditions are out of scope, although KB references for APD exist. The default isolation response and the exact effect of the performance degradation setting were not verified beyond the guide's description and are not stated here. Event retention on your vCenter limits how far back step 1 can look. Broadcom KB dates were not displayed when accessed.

Acceptance checklist

• [ ] Every affected VM has a recorded reason from events or fdm.log
• [ ] VM overrides reviewed; stale Disabled priorities removed or justified
• [ ] Placement dependencies (local storage, ISOs, rules, port groups) removed for protected VMs
• [ ] Admission control policy and Host failures cluster tolerates match the agreed tolerance; old values recorded
• [ ] Isolation addresses reachable and independent; on vSAN, set per KB 313763
• [ ] Conventional shared storage: at least two heartbeat datastores per host on independent storage where possible; vSAN-only cluster: absence of heartbeat datastores recorded as expected
• [ ] HA reconfigured on all hosts after any HA or vSAN network change; Host Monitoring back on
• [ ] Validation done by configuration and capacity review; any failure test planned outside production

References

All accessed 2 November 2026. Broadcom KB update dates were not displayed; vSphere 8.0 TechDocs pages showed "Last Updated October 28, 2026" where displayed.

• Broadcom KB 316525, "Determining why and which virtual machines were restarted during a vSphere HA failover": https://knowledge.broadcom.com/external/article/316525/determining-which-virtual-machines-are-r.html
• Broadcom KB 395002, "Virtual Machine was not restarted during vSphere HA Failover": https://knowledge.broadcom.com/external/article/395002/virtual-machine-was-not-restarted-during.html
• Broadcom KB 343894, "HA/FDM fails to restart a virtual machine with the error: vim.fault.NoCompatibleHost": https://knowledge.broadcom.com/external/article/343894/hafdm-fails-to-restart-a-virtual-machine.html
• Broadcom KB 313763, vSAN with vSphere HA isolation address settings: https://knowledge.broadcom.com/external/article/313763/using-an-isolation-address-to-ensure-ha.html
• vSphere 8.0 Availability, "Host Failure Types": https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-availability/creating-and-using-vsphere-ha-clusters/how-vsphere-ha-works/host-failure-types-and-detection.html
• vSphere 8.0 Availability, "Determining Responses to Host Issues": https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-availability/creating-and-using-vsphere-ha-clusters/how-vsphere-ha-works/determining-responses-to-host-issues.html
• vSphere 8.0 Availability, "Datastore Heartbeating": https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-availability/creating-and-using-vsphere-ha-clusters/how-vsphere-ha-works/datastore-heartbeating.html
• vSphere 8.0 Availability, "Configure Admission Control": 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
• vSphere 8.0 Availability, "vSphere HA Advanced Options": https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-availability/creating-and-using-vsphere-ha-clusters/configuring-cluster-settings/set-advanced-options/vsphere-ha-advanced-options.html
• vSphere 8.0 Availability, "Using vSphere HA with vSAN": https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-availability/creating-and-using-vsphere-ha-clusters/vsphere-ha-interoperability/using-vsphere-ha-with-vsan.html

Related articles

• How to build and validate a VMware private-cloud cluster
• Domain Controllers on VMware: Snapshots and Restores

• How to diagnose VMware and vSAN storage latency

• ESXi Host Not Responding or Disconnected in vCenter: Narrow the Cause

Learning notes

1. Collect HA events and fdm.log evidence for each affected VM before changing policy; where an event is missing, the log usually still shows the decision.
2. A host still writing datastore heartbeats is not "failed", so its VMs are not restarted for that reason alone.
3. Isolation requires losing both peer traffic and the isolation addresses; on vSAN the vSAN network replaces management.
4. Admission control reserves capacity for power-ons; overrides and placement constraints can still stop restarts.
5. Validate HA by configuration and capacity, not by failing production hosts.