VMware ESXi and vSphere Cluster Management

Monitor a vSphere HA Cluster

Learn how to monitor vSphere HA in the vSphere Client, interpret host roles, VM protection, datastore heartbeats, configuration issues, and failover readiness.

vSphere High Availability (vSphere HA) is a vCenter Server cluster service that detects certain ESXi host failures and attempts to restart affected virtual machines on surviving hosts. Monitoring HA helps you verify that this recovery mechanism is ready before an incident occurs.

This lesson focuses on HA control-plane health and protection status. It does not replace monitoring of ESXi performance, VM guest operating systems, applications, storage, or networks. For background on cluster capacity policy, review Admission Control Explained.

Why Monitor vSphere HA?

Regular HA monitoring helps administrators:

Validate that the cluster is prepared to respond to a host failure.
Detect management-network communication loss before it causes host isolation or incorrect failure interpretation.
Confirm that expected virtual machines are protected for HA restart processing.
Verify that heartbeat datastores remain accessible to participating hosts.
Find configuration problems, disconnected hosts, and capacity concerns before a failure occurs.

HA monitoring is different from other monitoring layers. Cluster HA monitoring asks whether hosts can coordinate and whether VMs are eligible for restart. ESXi host performance monitoring examines CPU, memory, storage, and network utilization. Guest OS monitoring examines operating-system health, services, and applications. A cluster can report healthy HA while an application inside a protected VM is failing.

Open the HA Monitoring View

Open the vSphere Client, the management interface for vCenter Server.
In the inventory, select the HA-enabled cluster.
Open Monitor.
Open the vSphere HA view.
Review the summary first, then inspect hosts, virtual machines, heartbeat information, and configuration issues.

A typical navigation path is Inventory > cluster > Monitor > vSphere HA. Labels, tabs, and the exact location of individual panels can differ between vSphere releases and vSphere Client versions. Use the equivalent HA monitoring sections available in the installed version rather than relying on an exact label.

Understand the HA Summary

The summary provides the fastest view of cluster readiness. It commonly combines the overall HA state, participating host information, protected and unprotected VM counts, heartbeat status, and configuration health.

Start with the overall state, but do not treat a normal summary as proof that every application will recover successfully. A normal state means that HA's reported control-plane conditions are acceptable at that time. Investigate warnings, errors, disconnected or isolated hosts, unexpected unprotected VMs, missing heartbeat datastores, and incomplete HA configuration.

Monitoring area	Primary information shown	Typical healthy state	When to investigate
HA summary	Overall state, host participation, VM protection, heartbeat and configuration indicators	Normal state with expected counts and no unresolved errors	Warnings, errors, unexpected count changes or incomplete status
Hosts	HA coordinator and participating host states	All expected hosts are connected and participating	A host is disconnected, not responding, isolated, in maintenance mode unexpectedly, or missing
Virtual machines	Protected and unprotected VM status	Expected workloads are protected	An expected VM is unprotected or protection changes without a planned reason
Heartbeat datastores	Datastores selected and used for HA heartbeat signaling	Suitable shared datastores are accessible to the required hosts	Datastores are missing, inaccessible, degraded, or visible to too few hosts
Configuration issues	HA warnings and errors with affected objects	No unresolved issues affecting readiness	An issue remains after a configuration or infrastructure change
Tasks and events	Reconfiguration activity, state changes, and related history	Changes match planned operations	HA changes unexpectedly, repeatedly fails to reconfigure, or reports a new event

Monitor HA Hosts and Cluster Membership

The host section shows which ESXi hosts participate in HA and identifies the host role that coordinates HA activity. Current interfaces may call this the HA coordinator. Older documentation may use primary or master. Other participating hosts may historically be called secondary or slave; current terminology and labels can differ.

Review both the host count and each host's state. Relevant states include:

Connected: The host is connected to vCenter Server and is participating as expected.
Disconnected: vCenter Server cannot currently manage the host through its connection.
Not responding: Communication with the host or its management agents is unavailable.
Maintenance mode: The host is being drained or intentionally excluded from normal workload operation. Check whether the reduced capacity is expected.
Isolated: The host has lost management-network communication with other HA participants but may still be running workloads.

HA depends primarily on communication over the ESXi management network. A host that cannot exchange management heartbeats may be misclassified, excluded from coordination, or require an isolation decision. Host membership therefore affects both failure detection and the capacity available for VM restarts.

Monitor Protected and Unprotected Virtual Machines

A protected virtual machine is recognized by HA as eligible for HA restart processing under applicable failure conditions. An unprotected virtual machine is not currently covered by that restart protection and should be investigated when protection is expected.

VM protection state	Meaning	Possible causes	Administrator response
Protected	HA recognizes the VM as eligible for restart handling	Normal HA configuration and host or datastore access	Confirm that capacity, storage, networking, restart priority, and admission-control policy also support recovery
Unprotected	The VM is not currently covered by HA restart protection	Unsupported configuration, disabled or incomplete HA monitoring, unavailable host or datastore, VM or cluster configuration conflict, or intentional exclusion	Identify the VM, review alerts and events, correct the cause, and confirm protection after HA reconfiguration

Protection is not a guarantee of a successful restart. Recovery also depends on surviving compute capacity, admission control, accessible storage, usable networks, VM restart settings, host compatibility, and the configured restart priority. Admission Control Policy explains how reserved failover capacity affects this assessment.

Understand Datastore Heartbeating

A datastore heartbeat is shared-datastore signaling used as an additional availability indicator. When management-network heartbeats are disrupted, datastore heartbeat information helps HA distinguish a host isolation event from a host failure. It is not a replacement for a resilient management network.

In the HA monitoring view, open the heartbeat or datastore-heartbeat section to see which datastores are selected and being used. Depending on the vSphere version, the interface may show accessibility, usage, host visibility, or related status indicators.

Heartbeat datastores should be:

Accessible and mounted by the intended cluster hosts.
Stable enough to provide reliable signaling.
Located on appropriately redundant storage paths where the design requires redundancy.
Visible across the cluster rather than available only to one host.

Loss of datastore heartbeat visibility makes failure determination less certain, especially when management-network communication is also impaired. Assess the two signals together: determine whether hosts can communicate over the management network, then verify whether shared storage still provides heartbeat evidence.

HA Communication and Redundant Network Design

HA relies primarily on network heartbeats sent between hosts over management networking. A resilient design reduces false isolation and lowers the risk that a single failed component partitions the cluster's view of host availability.

Use redundant physical paths for management traffic.
Use NIC teaming and separate switches or uplinks where appropriate for the network design.
Maintain consistent VLAN configuration across the required switch ports and hosts.
Verify that management VMkernel adapters are present, correctly addressed, and assigned to the intended network.
Confirm IP reachability between participating hosts and the vCenter Server management path.
Check physical uplink status and confirm that losing one path does not unnecessarily isolate a host.

Signal	Transport or dependency	Role in failure detection	Common failure indicators	Validation checks
Management network heartbeat	ESXi management VMkernel networking, VLANs, switches, uplinks and IP paths	Primary communication method for host availability and HA coordination	Host isolation, not responding state, missing host participation, or repeated HA communication warnings	Check VMkernel configuration, IP reachability, VLAN consistency, switch paths, uplink status and teaming
Datastore heartbeat	Shared datastore visibility and storage paths	Additional evidence when network heartbeat communication is uncertain	No usable heartbeat datastore, inaccessible datastore, missing host visibility, or storage path errors	Check mounts, accessibility on each host, storage paths, selected heartbeat datastores and recent storage events

Review HA Configuration Issues and Errors

The configuration issues view is a starting point for warnings and errors that affect HA readiness. Classify each finding by severity and scope:

Host-specific: One host has a connection, agent, configuration, or networking problem.
VM-specific: A workload has an unsupported setting, unavailable dependency, or protection conflict.
Network-related: Management VMkernel, VLAN, uplink, switch, or reachability conditions are inconsistent.
Datastore-related: Shared storage is inaccessible, insufficiently visible, or unsuitable for heartbeat signaling.
Licensing or feature-related: A required capability or supported configuration is unavailable.
Cluster-wide: HA enablement, admission control, policy, or cluster configuration affects multiple objects.

Use this remediation workflow:

Read the complete issue details, including severity and affected object.
Determine whether the scope is a host, VM, network, datastore, feature, or the entire cluster.
Correct the underlying configuration or infrastructure condition.
Allow HA to reconfigure, or use the supported vSphere Client control to reconfigure HA when necessary.
Review related Tasks and Events entries.
Confirm that the issue clears and that the summary returns to a healthy state.

Do not dismiss an issue merely because the cluster is still running workloads. An unresolved warning can represent reduced failover readiness.

Repeatable Operational Monitoring Workflow

Inspect the overall HA state in the cluster summary.
Review host participation, coordinator status, connection states, maintenance states, and isolation indicators.
Validate protected and unprotected VM totals against the expected inventory.
Open the heartbeat datastore view and confirm suitable shared datastores are visible and usable.
Inspect configuration issues and classify their severity and scope.
Review alarms, recent Tasks, and Events when the HA state changes or reconfiguration occurs. See Alarms in vSphere for related monitoring concepts.
Escalate from dashboard review to host logs, management-network tests, switch and uplink checks, storage-path checks, and failover-capacity verification when the dashboard does not identify the root cause.

Practical Monitoring Scenarios

Daily HA health verification

Select the target cluster and open Monitor > vSphere HA.
Confirm a normal operational state.
Check that all expected hosts are connected and participating.
Compare protected VM totals with the expected VM inventory.
Verify that heartbeat datastores are present and that configuration issues are absent.

This produces a quick readiness check that can be repeated during daily operations.

Investigate an unexpected unprotected VM count

Determine whether the count is intentional, such as an excluded or specially configured workload.
Identify the affected VMs rather than relying only on the aggregate count.
Review VM and cluster alerts, Tasks, and Events.
Check host connectivity, HA configuration, datastore availability, and VM-specific settings.
Correct the condition and confirm that the VM becomes protected after HA status refresh or reconfiguration, if appropriate.

Review heartbeat datastores after storage maintenance

Open the HA heartbeat datastore view.
Confirm that selected datastores remain mounted and accessible to the intended hosts.
Identify missing shared paths or hosts that cannot see the datastore.
Review storage connectivity and recent datastore events.
Restore shared access and verify that heartbeat status returns to the expected state.

Respond to an HA configuration warning

Open the issue and record its severity, description, and affected object.
Determine whether the cause concerns hosts, networking, storage, or cluster settings.
Apply the appropriate remediation.
Allow HA to reconfigure or trigger reconfiguration through the supported interface when required.
Verify that the warning clears and cluster monitoring returns to a healthy state.

Validate redundant management heartbeat paths

Review the management VMkernel adapter configuration on every host.
Check IP addressing, VLAN consistency, and intended network assignments.
Verify multiple physical uplinks or alternate paths where required by the design.
Check switch and uplink status.
Confirm that failure of one management path does not unnecessarily isolate a host.

HA Troubleshooting Guide

Observed symptom	Likely area	Initial checks	Potential corrective action
Host is missing from the HA host list or appears disconnected	vCenter-to-host connectivity, host agents, maintenance state, or management network	Check connection state, recent events, VMkernel reachability, uplink health, and HA messages	Restore management connectivity or host-agent operation, then confirm that the host rejoins HA participation
Unexpected unprotected VMs	VM or cluster configuration, host access, storage, or intentional policy	Identify affected VMs and review VM and cluster events, host access, datastore availability, and VM settings	Correct the cause, reconfigure HA if needed, and validate protection status
No usable heartbeat datastore	Shared storage visibility or datastore selection	Check datastore accessibility and mounts on every host, storage paths, and recent storage events	Restore shared access or correct heartbeat datastore selection, then revalidate reporting
Management-network heartbeat issue	VMkernel, VLAN, switch, uplink, or IP reachability	Check management adapters, addressing, VLANs, physical paths, teaming, and host-to-host reachability	Correct the network path and verify both network and datastore heartbeat evidence
Persistent configuration warning	Unresolved dependency, affected host, stale state, or failed HA reconfiguration	Read exact details, identify every affected object, and review Tasks and Events	Fix the underlying dependency, reconfigure HA through supported controls, and confirm the issue clears

When a host appears isolated

A powered-on host reported as isolated may still be running its workloads. First distinguish isolation from complete host failure. Check management-network reachability, physical uplinks, switch and VLAN configuration, and datastore heartbeat evidence. Then review the configured host isolation response and restore redundant communication paths. Do not assume that a powered-on host is communicating correctly with the cluster.

HA and Fault Tolerance Are Different

vSphere Fault Tolerance (FT) is a separate availability feature. FT maintains a secondary instance so a protected VM can continue execution through certain host failures. HA normally responds to a host failure by restarting VMs on surviving hosts, which can involve an interruption.

Feature	Recovery approach	Expected interruption	Monitoring focus	Appropriate use case
vSphere HA	Restarts affected VMs on surviving hosts after qualifying host failures	Usually a restart interruption	Host coordination, VM protection, heartbeats, capacity, storage, network and restart policy	General cluster-level recovery for workloads that can tolerate a VM restart
vSphere Fault Tolerance	Maintains a secondary execution instance for continuous protection	Designed to minimize interruption for supported failures	Primary and secondary instance health, FT networking, resource requirements and compatibility	Specific workloads requiring stronger continuity and meeting FT requirements

Limits and Interpretation Cautions

HA pages report control-plane health and protection status, not proof that every application can recover correctly.
A protected VM can still fail to restart because of insufficient compute capacity, inaccessible storage, unavailable networks, incompatibility, restart priority, or other VM settings.
Maintenance mode intentionally changes host participation and available failover capacity.
Host disconnects, isolation events, network partitions, and resource constraints can alter observed HA behavior.
Admission-control settings determine how much capacity is reserved or evaluated for configured failover scenarios.
VM-specific restart priorities and host isolation response settings can change the outcome of a failure.
Recovery procedures should be tested according to change-control, maintenance, and operational policy.

For deeper configuration work, continue with Advanced Options in vSphere HA and Communication Between vCenter Server and ESXi.

Exam-Relevant Notes

The HA coordinator role coordinates HA activity; older terminology may refer to a primary or master host.
Participating hosts must maintain appropriate management communication for normal HA coordination.
Datastore heartbeats provide additional evidence when management-network heartbeats are disrupted.
Protected means eligible for HA restart processing; it does not guarantee successful recovery.
Host isolation is not automatically the same as host failure. Management and datastore heartbeat evidence must be considered together.
Admission control concerns failover capacity and should be considered when evaluating whether a protected VM can actually restart.
FT is distinct from HA: HA restarts VMs, while FT maintains a secondary execution instance for supported workloads.