VMware vSphere HA Datastore Heartbeating Explained
Learn how vSphere HA datastore heartbeating distinguishes ESXi host failure from management-network isolation and how to configure heartbeat datastore selection.
Datastore heartbeating is a vSphere High Availability (vSphere HA) mechanism that helps determine whether an ESXi host is still operating when management-network communication is lost. Instead of relying only on network messages, vSphere HA can observe activity through shared storage.
This additional evidence helps HA distinguish an isolated but running host from a host that has actually failed. Correct datastore selection is therefore an important part of a resilient HA cluster, although datastore heartbeating does not replace redundant management networking, admission control, or virtual machine protection settings.
What datastore heartbeating does
Under normal conditions, ESXi hosts in a vSphere HA cluster exchange management-network heartbeats. These are network-based HA messages that communicate host reachability and state.
If the HA primary host stops receiving management-network heartbeats from another host, HA evaluates datastore-heartbeat information. A heartbeat datastore is a shared datastore selected by vSphere HA for this purpose. The affected host writes or updates heartbeat information on storage that other HA hosts can inspect.
A datastore heartbeat does not provide a second general-purpose management channel. It is a host-state signal. It tells HA that the host may still be running and able to access shared storage, even though management-network communication has been interrupted.
How vSphere HA detects host state
Primary and secondary hosts
Within a vSphere HA cluster, one host performs the coordinating role. This host is called the primary host. Other hosts are secondary hosts that participate in monitoring and follow HA coordination.
Older vSphere interfaces and documentation may use master host for primary host and slave host for secondary host. The newer terms are primary and secondary.
Normal operation
During normal operation, hosts exchange management-network heartbeats. The primary host uses these messages, along with other HA state information, to monitor cluster members. Shared datastores may also be used for datastore-heartbeat evidence.
When network heartbeats disappear
The important trigger is that the primary host no longer receives management-network heartbeats from another host. HA then examines whether the host is still producing usable datastore-heartbeat evidence.
- Host failure: The ESXi host is no longer operating, or it cannot provide either network or datastore evidence that it remains active.
- Host isolation: The host is still running but has lost communication with the management network. Its workloads and storage access may continue.
- Network partition: A connectivity split prevents some HA hosts from communicating with other hosts. Different groups may have different views of cluster state.
These conditions can look similar from the management plane. Datastore heartbeating gives HA another path for evaluating the affected host.
How datastore heartbeats influence HA decisions
If the affected host continues updating a heartbeat datastore, HA has evidence that the host may still be operating despite the missing management-network heartbeat. This can help HA avoid immediately treating the host as completely failed.
If datastore-heartbeat evidence is absent, that absence contributes to HA determining that the host has failed. After a host is deemed failed, vSphere HA can attempt to restart the failed host's protected virtual machines on surviving hosts, subject to available cluster resources, admission control, restart priorities, isolation response, and other HA settings.
Example: management-network loss while the host remains online
Suppose an ESXi host stops sending management-network heartbeats because of a failed management switch uplink, VLAN problem, or VMkernel networking issue. The host continues running and can still write heartbeat information to shared storage.
HA can observe that datastore activity and recognize that the host may be isolated rather than completely failed. Administrators should still investigate the network problem and verify the configured isolation response.
Example: complete ESXi host failure
Suppose the host loses management-network reachability and also stops producing datastore heartbeats. After HA's monitoring logic completes, the lack of both forms of evidence supports a host-failure determination. HA can then initiate restart attempts for protected virtual machines on available hosts.
Heartbeat datastore requirements
Heartbeat datastores must be accessible to the applicable ESXi hosts in the HA cluster. A datastore that only one host can access cannot provide useful shared evidence for determining that host's state from the perspective of the rest of the cluster.
- Use shared datastores that are mounted and accessible across the relevant hosts.
- Prefer storage with reliable controllers, paths, fabric connectivity, and datastore availability.
- Avoid making heartbeat coverage dependent on a single vulnerable datastore.
- Check that storage design and management-network design do not share an avoidable single point of failure.
Datastore outages reduce the usefulness of datastore heartbeating. If the selected heartbeat datastore is inaccessible, HA may lose an important host-state signal. The effect depends on the configured selection policy and whether other eligible datastores are available.
Datastore heartbeat selection policies
vSphere HA provides three general selection approaches. The names shown in the client can vary slightly by vSphere version, but their behavior follows the same principles.
| Policy | Who selects heartbeat datastores | Behavior when a selected datastore is unavailable | Fallback to other cluster datastores | Best-fit use case |
|---|---|---|---|---|
| Automatically select datastores accessible from hosts | HA selects suitable accessible datastores. | HA can use other eligible accessible datastores as availability changes. | Yes, as part of automatic selection. | Most clusters, especially when no specific storage topology requires administrator control. |
| Use datastores only from the specified list | The administrator selects the complete allowed list. | HA does not automatically replace unavailable selected datastores with an unlisted datastore. | No. | Controlled environments where only named datastores are permitted, with the associated availability risk accepted. |
| Use datastores from the specified list and complement automatically if needed | The administrator identifies preferred datastores; HA can supplement them. | HA first uses available preferred datastores, then looks for other eligible datastores when necessary. | Yes, when preferred choices are unavailable. | Clusters that have preferred storage but also need resilience if that storage becomes unavailable. |
Automatic datastore selection
With automatic selection, HA chooses datastores that are accessible from the hosts. This is generally the simplest and most resilient default when the cluster has several suitable shared datastores.
Specified datastores only
A strict specified-list policy limits heartbeat monitoring to the datastores selected by the administrator. If all selected datastores become unavailable, HA does not automatically switch to another cluster datastore. This can reduce datastore-heartbeat coverage during a storage outage.
Specified datastores with automatic supplementation
This policy combines administrator preference with automatic fallback. HA first uses available datastores from the preferred list. If those choices are unavailable or insufficient, HA can select another available eligible datastore in the cluster.
This approach is useful when particular datastores are preferred because of storage topology or operational policy, but losing those datastores should not eliminate all datastore-heartbeat evidence.
Configure datastore heartbeating in the vSphere Client
- Select the target HA cluster in the vCenter inventory.
- Open the cluster's Manage or Configure area.
- Open the vSphere HA settings and choose Edit.
- Locate or expand Datastore Heartbeating.
- Choose one of the available policies: automatic selection, specified datastores only, or specified datastores with automatic supplementation.
- If using a specified list, select the intended accessible heartbeat datastores.
- Save the cluster configuration.
- After saving, validate datastore accessibility from the relevant ESXi hosts and review the resulting HA state.
The exact labels and placement can differ between vSphere Client releases. The configuration concept remains the same: choose the cluster, edit vSphere HA settings, locate Datastore Heartbeating, select the policy, and verify accessibility.
Operational guidance
- Leave automatic selection enabled unless there is a clear storage-topology, compliance, or operational reason to control the datastore list.
- If you use a strict specified list, select more than one resilient datastore where possible and understand that HA will not use an unlisted replacement.
- Use shared storage with redundant paths and reliable availability.
- Do not design heartbeat coverage around one datastore that has a single controller, path, fabric, or site dependency.
- Review HA events and host connectivity symptoms before assuming that a disconnected host has completely failed.
- Keep management-network redundancy and storage resiliency independent where practical.
Connectivity conditions and HA evidence
| Condition | Management-network heartbeat status | Datastore-heartbeat status | Likely HA interpretation | Potential result |
|---|---|---|---|---|
| Normal host operation | Present | Available or being observed as configured | Host is reachable and operating normally. | Normal HA monitoring. |
| Management-network isolation with storage still accessible | Lost | Present | Host may still be operating but isolated from management communication. | HA has evidence against an immediate complete-failure conclusion; isolation handling still applies. |
| Host failure | Lost | Absent | Host is likely failed or cannot provide sufficient evidence that it remains active. | HA may restart protected virtual machines on surviving hosts. |
| Selected heartbeat datastore unavailable | May be present or lost | Unavailable through the selected storage | Datastore-heartbeat evidence is reduced; interpretation depends on policy and alternate datastore availability. | HA may use another datastore if the policy permits, or lose this signal under a strict list. |
Troubleshooting datastore-heartbeat behavior
Host is disconnected or unreachable, but virtual machines may still be running
- Check management-network uplinks, VLANs, routing, and management VMkernel interfaces.
- Review HA events to determine whether datastore heartbeats are still being observed.
- Verify that the host retains access to the shared heartbeat datastore.
Datastore-heartbeat evidence can indicate management-network isolation rather than complete host failure. Confirm the host's actual state before taking disruptive recovery actions.
No usable datastore-heartbeat information is available
- Verify that selected heartbeat datastores are mounted and accessible from the relevant ESXi hosts.
- Check storage paths, fabric health, multipathing, controllers, and datastore availability.
- Review whether a strict specified-list policy prevents HA from choosing alternate datastores.
Storage unavailability or restrictive selection can remove an important HA host-state signal.
The expected datastore is not being used
- Review the configured selection policy.
- Confirm whether the datastore is in the administrator-selected list.
- Confirm that it is accessible and eligible for the necessary hosts.
- Check whether HA selected an alternate datastore because a preferred datastore was unavailable.
Selection behavior depends on both the policy and current datastore accessibility. A preferred datastore is not necessarily the datastore HA will use when it cannot be reached.
Virtual machines restarted after a connectivity incident
- Review HA events, host-failure determination, and datastore-heartbeat availability at the time of the incident.
- Check isolation response settings and management-network resiliency.
- Validate that shared-storage and management-network designs do not share an avoidable single point of failure.
A restart may result from HA determining that the host failed or from the host being unable to provide sufficient evidence that it remained active. Datastore heartbeating is one part of that determination.
Exam-relevant points
- Datastore heartbeating provides an additional shared-storage communication path when management-network heartbeats are lost.
- A datastore heartbeat can indicate that an apparently unreachable host may still be running.
- Absent datastore heartbeats contribute to a host-failure determination.
- Heartbeat datastores must be accessible to the applicable hosts.
- A strict specified-list policy does not automatically select an unlisted replacement datastore.
- A preferred-list policy with automatic supplementation can use other eligible cluster datastores when preferred datastores are unavailable.
- Datastore heartbeating does not replace management-network redundancy or VM protection configuration.
Summary
vSphere HA normally monitors hosts through management-network heartbeats. When the primary host stops receiving those messages from another host, datastore heartbeating supplies additional evidence through shared storage. Continued datastore activity can suggest host isolation, while the absence of both network and datastore evidence supports a host-failure decision and possible VM restarts.
For most environments, automatic datastore selection is appropriate. Use a specified list only when there is a clear reason to control the choices, and understand that a strict list can lose coverage when its datastores fail. A preferred list with automatic supplementation provides administrator preference while preserving fallback flexibility. For a related reference, see Datastore Heartbeating Explained.