VMware ESXi and vSphere Cluster Management

Monitor a vSphere HA Cluster

Learn how to monitor vSphere HA in the vSphere Client, including host participation, VM protection, datastore heartbeating, and configuration issues.

Monitoring vSphere High Availability (vSphere HA) verifies that a cluster can detect qualifying ESXi host failures and attempt to restart protected virtual machines on surviving hosts. Monitoring is different from configuring HA settings or performing a failover test: it is the routine process of checking current health, participation, protection, and dependencies.

Review HA status after cluster changes, host maintenance, storage or networking changes, and any report that a virtual machine is not protected.

Navigate to vSphere HA monitoring views

  1. In the vSphere Client, select the target cluster in the inventory.
  2. Open Monitor.
  3. Locate the vSphere HA monitoring section.
  4. Open Summary, Heartbeat, or Configuration Issues as needed.

The exact labels and navigation placement can differ between vCenter Server and vSphere Client releases. The monitoring goals remain the same: confirm cluster participation, inspect VM protection, review heartbeat datastores, and resolve reported issues.

Cluster inventory object > Monitor > vSphere HA > Summary, Heartbeat, and Configuration Issues

Read the vSphere HA Summary

Use Summary as the first health check for an HA-enabled cluster. An HA-enabled cluster has vSphere HA turned on and configured.

  • Confirm that HA is enabled.
  • Check that the cluster has an active HA coordination role.
  • Review the Hosts section for the coordinating host and the state or count of participating hosts.
  • Compare the displayed host count with the hosts you expect in the cluster.
  • Review the Virtual Machines section for protected and unprotected VM counts.

Depending on the vSphere version, the interface may use primary and secondary, or may use coordinator terminology. Older releases and older technical material may use master host and slave host. These terms describe HA coordination and participation; they do not change the monitoring objective.

Unexpected membership, missing hosts, or communication problems can reduce HA protection even when the cluster object itself appears available.

Monitoring views and what to check

Summary — Displays overall HA state, coordination information, host participation, and VM protection. Healthy indicators include enabled HA, an active coordination role, all expected hosts participating, and expected protection counts. Investigate disabled HA, missing hosts, agent errors, or unexpected unprotected VMs.

Hosts — Shows participating ESXi hosts and their HA-related state. Healthy indicators include every intended host being connected and participating. Investigate disconnected, not responding, isolated, partitioned, maintenance-mode, or agent-inoperative hosts.

Virtual Machines — Shows protected and unprotected VM information. Healthy indicators include the expected VMs being protected. Investigate any unprotected VM instead of assuming that HA will restart it.

Heartbeat — Shows datastores selected for HA datastore heartbeating. Healthy indicators include appropriate shared datastores accessible to the relevant hosts. Investigate missing, inaccessible, or unexpected heartbeat datastores after storage changes.

Configuration Issues — Shows warnings and errors affecting HA operation. Healthy indicators include no unresolved issues that prevent protection or leave hosts without an operational HA agent. Read and remediate every relevant warning or error.

Monitor host participation and HA agent status

An ESXi host is a physical server running the ESXi hypervisor. Every intended ESXi host should be a member of the cluster and participate in HA.

The HA agent is the host-side component that participates in failure detection and recovery coordination. An agent installation or configuration error reduces cluster protection and requires investigation.

  • Disconnected or not responding: vCenter Server cannot currently communicate normally with the host. Check host connectivity, management networking, and recent events.
  • Maintenance mode: The host is deliberately being prepared for maintenance and may not be available for normal workload placement or failover capacity.
  • Isolated: The host has lost communication with the HA network while it may still be running workloads. Review isolation response and management-network paths.
  • Partitioned: A network partition allows subsets of hosts to communicate internally while preventing communication with another subset.
  • HA agent unavailable: HA cannot reliably use the host for coordination or protection until the agent issue is corrected.

An HA communication issue is not always the same as a general vCenter inventory connectivity issue. A host can have an inventory connection problem, an HA agent problem, or both. Use HA-specific status, configuration issues, host events, and management-network checks to distinguish them.

Review protected and unprotected virtual machines

A protected virtual machine is recognized by HA as eligible for restart handling after a qualifying host failure. Protection means HA can attempt a restart; it does not guarantee success if surviving hosts lack capacity, files are inaccessible, or VM and cluster conditions prevent startup.

An unprotected virtual machine is not currently protected by HA. Investigate it rather than assuming it will be restarted.

Common reasons include:

  • An active HA configuration error or a host HA agent problem.
  • Inaccessible VM files, datastore paths, or required storage.
  • Unsupported placement or storage conditions for the cluster's HA design.
  • A temporary cluster reconfiguration in progress.

For an unprotected VM, identify the VM and host details, review Configuration Issues, check datastore accessibility, inspect recent HA-related events and tasks, and confirm protection again after remediation.

Monitor datastore heartbeating

Management network heartbeats are HA communications exchanged through the host management network to help determine host connectivity. Datastore heartbeating uses shared datastores as an additional signal when management-network communication is disrupted.

Open the Heartbeat view and identify the datastores selected for HA heartbeating. Appropriate datastores should be shared and accessible to the relevant cluster hosts. Reliable accessibility matters because HA uses these datastores to supplement host-state determination.

Review the displayed list whenever shared storage is added, removed, made unavailable, remounted, or otherwise changed. A datastore that is inaccessible to enough hosts may not be useful for heartbeating, and HA may select other eligible datastores.

Heartbeat review after a storage change

  1. Open the cluster's HA Heartbeat view.
  2. Compare the listed datastores with the expected shared-storage design.
  3. Verify that relevant hosts can see and access each datastore.
  4. Review storage-related host events and recent tasks.
  5. Confirm the heartbeat list and HA status after the storage condition is corrected.

Review HA configuration issues and errors

Open Configuration Issues to find warnings and errors affecting HA operation. Prioritize issues that prevent HA from protecting VMs, leave hosts without an operational HA agent, or compromise host failure and isolation detection.

Use this workflow:

  1. Read the complete issue detail.
  2. Identify the affected host, VM, datastore, network, or cluster setting.
  3. Correct the underlying condition rather than simply dismissing the warning.
  4. Allow or initiate the appropriate HA reconfiguration according to operational procedures.
  5. Confirm that the issue clears and that host and VM status return to the expected state.

A warning about redundant heartbeat networking deserves attention. Multiple reliable management-network paths improve resilience. Validate physical NIC uplinks, switch-path resilience, VLANs, port groups, and consistent management-network configuration across affected hosts.

HA status conditions and administrator response

Host disconnected or not responding — The host may have lost management connectivity or may be unavailable. Check the cluster host state, management network, host events, and HA issues. Restore connectivity or follow host recovery and maintenance procedures.

HA agent problem — The host-side HA component may not be installed, configured, or operating correctly. Check host-specific configuration issues and events, then complete the approved agent or host reconfiguration procedure.

Unprotected virtual machines — HA cannot currently provide restart protection for the affected VMs. Check HA issues, host state, storage accessibility, VM placement, and recent reconfiguration activity. Recheck protection after correction.

No expected heartbeat datastore — The datastore may be inaccessible, ineligible, or replaced by other selected datastores. Verify host visibility, mounts, storage paths, and heartbeat settings.

Redundant heartbeat network warning — Management traffic may have only one physical path or inconsistent network configuration. Check VMkernel management paths, NICs, switches, VLANs, and port groups, then verify that the warning clears.

Cluster reconfiguration in progress — HA may be temporarily changing host agents or protection state. Review Recent Tasks and Events, allow the operation to finish when appropriate, and investigate if it remains stuck or produces errors.

Interpret monitoring results in operational context

A healthy-looking HA Summary does not guarantee a successful restart for every possible failure scenario. Restart behavior also depends on:

  • Admission control: the policy reserves capacity for configured failure scenarios and can affect whether workloads can be powered on.
  • Host isolation response: the configured response determines what happens when a host loses HA network communication while it may still be running.
  • VM restart priority: priority settings influence the order in which HA attempts to restart VMs.
  • Datastore accessibility: surviving hosts must be able to access the VM's files and required storage.
  • Available capacity: surviving hosts need enough CPU, memory, and other required resources.

When status changes unexpectedly, review Recent Tasks and Events alongside the HA pages. Document a baseline that includes the expected host count, protected VM count, and designated heartbeat datastores. Compare routine checks with this baseline to identify drift quickly.

Routine HA cluster health check

  1. Select the intended cluster and open Monitor > vSphere HA > Summary.
  2. Confirm that HA is enabled and an active coordination role exists.
  3. Compare participating-host status and count with the cluster inventory.
  4. Review protected and unprotected VM counts.
  5. Open Heartbeat and verify that expected shared datastores are available.
  6. Open Configuration Issues and resolve or escalate active warnings and errors.
  7. Review Recent Tasks and Events when any value differs from the baseline.

Troubleshooting examples

One or more VMs are unprotected

  1. Review the HA Configuration Issues view.
  2. Identify the affected VM and host details.
  3. Check relevant events and recent tasks.
  4. Validate host membership, host connectivity, HA agent operation, and datastore availability.
  5. Verify that the VM uses storage and placement supported by the cluster design.
  6. Confirm the VM becomes protected after remediation.

A host is absent from normal HA participation

  1. Check the cluster host list and the host connection state.
  2. Review HA configuration issues and host-specific events.
  3. Validate management-network connectivity and HA agent operation.
  4. Check whether the host is disconnected, not responding, isolated, partitioned, or in maintenance mode.
  5. Allow or initiate the appropriate reconfiguration process according to operational procedures.

An expected datastore does not appear in Heartbeat

  1. Verify datastore visibility and accessibility for the relevant hosts.
  2. Review datastore heartbeating settings.
  3. Check storage-related host events and recent changes.
  4. Determine whether HA selected other eligible datastores.
  5. Ensure the shared-storage design supports the cluster's HA requirements.

A redundant heartbeat-network warning appears

  1. Read the warning detail and identify affected hosts or networks.
  2. Review management VMkernel paths and physical NIC uplinks.
  3. Check upstream switch connectivity and path redundancy.
  4. Confirm consistent VLAN and port-group settings.
  5. Recheck HA status after redundant paths are restored.

Terminology across vSphere versions

Master host — Older term for the HA coordination host. In newer interfaces, look for primary, coordinator, or equivalent coordination information.

Slave host — Older term for a participating host connected to the coordinating host. Newer interfaces may use secondary or participating host.

Primary host — Newer or alternative term for a host performing HA coordination. Confirm the exact label in the installed vSphere release.

Secondary host — Newer or alternative term for a host participating in HA under the coordination role.

Coordinator — A release-dependent term for the active HA coordination role. The monitoring concern is whether coordination is operational and hosts are participating.

For related study, review vSphere HA cluster monitoring together with HA configuration, admission control, host isolation, datastore heartbeating, VM restart priority, and safe failover testing procedures.