VMware ESXi and vSphere Cluster Management

vSphere High Availability (HA) Explained

Learn how vSphere HA detects ESXi, guest, and application failures, restarts VMs, protects cluster capacity, and differs from vSphere Fault Tolerance.

vSphere High Availability (HA) is a cluster capability that reduces virtual-machine downtime by detecting selected failures and automatically restarting affected VMs. It is recovery-based availability: a VM normally stops or becomes unavailable during the failure, then starts again on suitable surviving infrastructure.

This lesson explains what HA protects, how failure detection and recovery work, how to plan capacity, and when Fault Tolerance may be more appropriate.

What High Availability Means

High availability is a design objective that minimizes service downtime through redundancy, detection, and recovery. Instead of depending on one server or one path, an available design provides alternatives and automates a response when a component fails.

Availability exists at several layers:

Physical layer: redundant power supplies, power feeds, cooling, and server components.
Network layer: redundant adapters, switches, paths, VLANs, and routing.
Storage layer: multiple paths and storage systems designed to remain accessible during a component failure.
Virtualization layer: a surviving ESXi host restarts a VM after another host fails.
Application layer: service clustering, replication, load balancing, and application-native recovery.

vSphere HA improves recovery availability at the virtualization layer; it does not eliminate every outage. A shared-storage failure, site-wide power loss, corrupted application data, or a guest configuration error may require a different protection mechanism.

What vSphere HA Is

vSphere HA is a vCenter Server-managed capability configured on a vSphere cluster. It uses HA agents on ESXi hosts to monitor host and VM state. When HA identifies an eligible failure, it attempts to restart affected VMs on surviving hosts.

HA is configured at the cluster level rather than as an isolated feature of one ESXi host. Individual VMs can have monitoring, restart-priority, and other policy overrides, but those choices operate within the cluster's HA design.

Cluster Fundamentals

A cluster is a managed group of ESXi hosts that shares resource and availability policies. vCenter Server provides the management context; ESXi hosts supply compute resources and run the VMs.

Host-failure recovery requires at least one other viable host. The surviving host must be able to access the VM's configuration and virtual disks through shared storage or another supported storage architecture. A VM whose files are available only on the failed host cannot normally be restarted elsewhere.

Capacity planning is equally important. After a host failure, remaining hosts need sufficient CPU, memory, storage performance, and network capacity for the VMs that should restart. A three-host cluster that is already nearly full may be operational before a failure but unable to recover all workloads afterward.

Review datastore heartbeating and your datastore design when planning how HA determines host state.

Protection Against an ESXi Host Failure

HA primarily uses management-network heartbeats between hosts. These regular signals indicate that an ESXi host is communicating with the HA service. When network heartbeats disappear, HA also uses datastore heartbeats, which are storage-based signals, to help determine whether a host is still running.

A simplified recovery sequence is:

HA detects that a host is no longer communicating normally.
HA evaluates host state using network information, datastore heartbeats, and other available evidence.
A surviving host is selected based on compatibility, storage access, resource availability, and policy.
The VM is registered on the selected host, if necessary.
The VM is powered on and the guest operating system and applications start.

This is a VM restart, not uninterrupted execution. Users may experience the time required for failure detection, placement, power-on, guest boot, and application initialization. In-memory state that was not written to storage can be lost.

Host Failure, Isolation, and Network Partition

An actual host failure means the ESXi host has stopped functioning or is no longer able to run its workloads. Host isolation means a host has lost connection to the HA management network but may still be running VMs. A management-network partition means communication has been disrupted between groups of hosts or management components; it does not automatically prove that any host has failed.

HA uses multiple signals and configured isolation responses to reduce the risk of two hosts independently acting on the same VM. Redundant management networking and appropriate datastore heartbeat configuration are essential for making this decision safely.

VM Monitoring and Guest Operating-System Failure

VM Monitoring uses heartbeats from VMware Tools, guest software that supports features such as VM and application heartbeat reporting. If the guest operating system stops responding and the heartbeat remains absent for the configured detection interval, HA may reset the VM on its current host.

This is guest-level recovery. Under normal VM Monitoring behavior, HA does not migrate the VM to another host; it resets the VM where it is running. The reset is useful when the guest is genuinely hung, but it is a coarse action.

Prerequisites and design considerations include:

VMware Tools must be installed, running, and able to report heartbeats.
VM Monitoring must be enabled at the appropriate cluster or VM level.
Sensitivity and failure-interval settings should match the workload's normal startup and load behavior.
Guest CPU or memory pressure, long pauses, or unhealthy VMware Tools can create false indications of failure.

Test monitoring with representative workloads. Aggressive thresholds can reset a VM that is overloaded but still making progress.

Application Monitoring

Application Monitoring extends health checking to an application. An application-monitoring agent or supported integration reports application heartbeats through VMware Tools. If the application stops responding and the configured health condition is met, HA can reset the entire VM on its current host.

Restarting the whole VM is a broad recovery action. It may restore a service, but it is not equivalent to an application-native restart, database recovery process, application cluster, or load-balanced design. Use application monitoring only when the health check accurately represents service availability and the consequence of a VM reset is understood.

Failure Detection and Recovery Concepts

HA agents run on ESXi hosts and exchange state information. One or more HA coordination functions organize cluster decisions, while individual hosts continue to execute workloads. Exact implementation details and terminology can vary by vSphere release, so focus on the operational concepts rather than relying on a particular internal role name.

Management heartbeats: network signals used to establish host communication.
Datastore heartbeats: storage signals that help distinguish a failed or isolated host from a host that is still active.
Isolation response: the configured action when a host loses required management connectivity. The action must account for whether other hosts can safely restart or access the affected VMs.
Split-brain avoidance: state checks and storage coordination help prevent multiple hosts from treating the same VM as theirs to run.
Restart priority: a policy that influences which VMs HA attempts to recover first.

Recovery time varies. Detection may take time, then HA must find capacity and storage, power on the VM, boot the operating system, start dependencies, and make the application ready. A fast host restart does not guarantee a fast service recovery.

Failure Types and HA Responses

ESXi host failure — Detection: management heartbeats and datastore heartbeats. Recovery: register and power on affected VMs elsewhere. VM location: surviving compatible host. Interruption: detection plus VM and application startup. Caveats: shared storage, networking, capacity, and HA health are required.

Guest OS heartbeat loss — Detection: VMware Tools heartbeat. Recovery: reset the VM when monitoring thresholds are met. VM location: normally the same host. Interruption: reset and guest boot time. Caveats: overloaded guests or unhealthy Tools can cause unnecessary resets.

Application heartbeat loss — Detection: application agent or supported integration through VMware Tools. Recovery: reset the VM. VM location: normally the same host. Interruption: VM reset and application startup. Caveats: whole-VM reset may be less precise than application-native recovery.

Host isolation — Detection: loss of HA management connectivity combined with other state signals. Recovery: the configured isolation response; surviving hosts may recover workloads if safe. VM location: depends on the response and whether the isolated host is still running. Interruption: variable. Caveats: validate gateway reachability, datastore heartbeats, and storage design.

Management-network partition — Detection: communication loss between host groups or management components. Recovery: HA uses available state evidence and partition-handling logic. VM location: depends on determined ownership and policy. Interruption: variable. Caveats: a partition is not automatically a host failure; redundant paths and split-brain safeguards matter.

Admission Control and Capacity Protection

Admission control is an HA capacity policy intended to preserve enough resources to restart VMs after configured host failures. It prevents or warns against placing workloads in the cluster when doing so would violate the selected failover target.

Common conceptual approaches include:

Dedicated failover capacity: reserve the capacity of one or more hosts for failure recovery.
Percentage-based capacity: reserve a percentage of CPU and memory resources for failover.
Policy behavior appropriate to the vSphere release: current versions may offer additional policy choices or different presentation in the vSphere Client. Verify the behavior for the deployed release.

Stronger protection generally means less capacity for new workloads. If admission control is disabled, VMs may run normally before a failure but there may be insufficient CPU or memory on surviving hosts afterward. Admission control also cannot compensate for a failed storage system or a site-wide outage.

For related capacity concepts, see admission control explained and admission control policy.

Configuration Overview

Create or select a cluster in vCenter Server.
Add eligible ESXi hosts to the cluster; see adding an ESXi host to vCenter inventory.
Verify compatible management networking, redundant network paths, and storage access.
Enable vSphere HA in the cluster availability settings. The HA configuration workflow is performed through vCenter.
Configure admission control for the desired host-failure tolerance.
Select datastore heartbeat behavior and a host isolation response appropriate to the environment.
Enable VM Monitoring where guest-level recovery is required.
Set VM restart priorities and VM-specific overrides only for documented workload requirements.
Review HA status, agent health, events, alarms, and available failover capacity.

Reliable redundant management networking is particularly important. Check physical switch paths, redundant uplinks, VLANs, VMkernel configuration, routing, and gateway reachability. Do not select an isolation response without understanding what happens to VMs on the isolated host and what surviving hosts can safely access.

Validation Checklist

vCenter and cluster configuration — Requirement: hosts are managed in the intended cluster and HA is enabled. Why it matters: HA policies apply through the cluster. Validation: inspect cluster HA status and host membership.

Multiple ESXi hosts — Requirement: at least one suitable surviving host. Why it matters: recovery needs somewhere to run. Validation: review host health, compatibility, and maintenance state.

Management network redundancy — Requirement: independent paths and correct VMkernel connectivity. Why it matters: heartbeat loss must not be caused by one avoidable path failure. Validation: test paths and review HA host-state events.

Storage accessibility — Requirement: surviving hosts can access VM files and datastores. Why it matters: a VM cannot be restarted without its required files. Validation: verify datastore visibility and paths on every host.

Failover capacity — Requirement: reserved or available CPU, memory, storage, and network capacity. Why it matters: detection alone does not guarantee placement. Validation: review admission-control state and runtime utilization.

VMware Tools — Requirement: installed and running for VM or application monitoring. Why it matters: monitoring depends on guest heartbeats. Validation: inspect Tools status in the vSphere Client and inside the guest.

Monitoring and alerting — Requirement: events, alarms, and capacity warnings are reviewed. Why it matters: failed recovery attempts and shrinking headroom need attention. Validation: inspect HA events, alarms, restart activity, and cluster health.

Important HA Policy Decisions

Admission control — Purpose: preserve failover resources. Options: dedicated host capacity, percentage-based reservations, or release-specific policies. Risk: disabling or mis-sizing it can leave VMs without restart capacity.

Host isolation response — Purpose: define behavior when management communication is lost. Options depend on storage access, network design, and whether VMs should be powered off or left running. Risk: an unsuitable response can cause unnecessary shutdowns or unsafe workload ownership.

Datastore heartbeat configuration — Purpose: provide another host-state signal. Options should use suitable accessible datastores. Risk: insufficient or inaccessible heartbeat storage makes isolation decisions less reliable.

VM Monitoring sensitivity — Purpose: determine how quickly an unresponsive guest is reset. Options range from conservative to more sensitive thresholds, depending on version and policy interface. Risk: aggressive settings can reset slow but healthy VMs.

VM restart priority — Purpose: influence recovery order. Options should reflect business importance and service dependencies. Risk: low-priority critical services may start after less important VMs.

Practical Failure Scenarios

Three-Host Cluster with One Failed Host

Suppose a three-host cluster runs production VMs and one host suddenly becomes unavailable. HA identifies the failure, selects the two surviving hosts, and restarts the affected VMs if storage, networks, compatibility, and capacity permit. Users experience detection time, VM power-on time, guest boot time, and application initialization time. This is recovery availability, not continuous execution.

Guest Operating System Hang

The ESXi host remains healthy, but VMware Tools heartbeats stop because the guest OS is hung. With VM Monitoring enabled and thresholds met, HA resets the VM on that same host. Check Tools health and guest resource pressure before choosing sensitive settings.

Application Stops Responding

An application-monitoring integration reports that its heartbeat is absent. HA can reset the VM on the current host. Compare this coarse recovery action with a service restart, application cluster, database failover, or load balancer that may preserve more of the guest environment.

Insufficient Failover Capacity

A nearly full cluster may continue operating until a host fails. If surviving hosts lack CPU or memory, some VMs cannot restart. This demonstrates why admission control and continuous capacity monitoring are protection mechanisms rather than optional paperwork.

Management Network Loss

One host loses management connectivity but continues running VMs. HA may classify it as isolated rather than failed. Redundant management paths, datastore heartbeats, and the configured isolation response determine the outcome. Test this condition separately from a true host failure.

HA Compared with Fault Tolerance

vSphere Fault Tolerance (FT) is a separate availability feature designed to protect eligible workloads through continuous execution protection. HA accepts restart downtime; FT is intended to substantially reduce or avoid interruption for supported workloads.

Recovery model — vSphere HA: detect a failure and restart the VM. vSphere Fault Tolerance: maintain protected execution for eligible workloads.

Downtime expectation — vSphere HA: nonzero interruption and possible loss of in-memory state. vSphere Fault Tolerance: designed to reduce or avoid interruption during a supported protected-component failure.

Protection scope — vSphere HA: broad cluster coverage for automated VM restart. vSphere Fault Tolerance: narrower protection for workloads meeting its compatibility and configuration requirements.

Resource impact — vSphere HA: reserves and consumes resources for possible restart. vSphere Fault Tolerance: requires additional resources, networking, storage, and careful design for protected execution.

Workload compatibility — vSphere HA: generally broad, subject to cluster and VM compatibility. vSphere Fault Tolerance: stricter version, VM, host, resource, and feature constraints; verify current support.

Typical use case — vSphere HA: most workloads that can tolerate reboot-based recovery. vSphere Fault Tolerance: an eligible workload with a strong requirement for substantially reduced interruption and acceptance of extra constraints.

Choose HA for broad automated restart coverage. Consider FT only when its protection model is justified by the workload's recovery objective and the environment satisfies the current compatibility and capacity requirements. See enabling vSphere Fault Tolerance for the separate configuration topic.

Limitations and Scope

HA restarts VMs after failure, so recovery time is not zero and in-memory state may be lost.
HA does not inherently prevent application data corruption or fix guest misconfiguration.
HA does not protect against failure of the shared storage system on which the VM depends.
HA does not provide site-wide disaster recovery for a data-center or regional outage.
vCenter Server is needed to configure and manage the cluster, but an already-established HA cluster can perform many failure responses through its host agents even if vCenter is temporarily unavailable. Verify release-specific behavior and operational scope.
The protection level depends on redundant host, network, storage, and power design.
Maximum supported host and VM counts depend on vSphere release and licensing. Verify current VMware compatibility and configuration maximums before designing a cluster.

Monitoring, Testing, and Maintenance

Availability claims should be tested rather than assumed. Perform controlled failover tests during an approved maintenance window and document expected and measured recovery times.

Inspect HA events, alarms, cluster health, host HA-agent status, and VM restart activity.
Test an ESXi host failure scenario separately from a management-network isolation scenario.
Measure failure detection, placement, VM power-on, guest boot, and application-readiness stages separately.
Confirm that critical VMs have working VMware Tools when VM or application monitoring is enabled.
Review admission-control warnings before adding powered-on workloads.
For planned maintenance, enter the host into maintenance mode and use workload evacuation or shutdown procedures rather than treating planned work as an unplanned failure. See maintenance mode.
Use alarms and event review to identify repeated heartbeat loss, restart failures, capacity pressure, or isolation conditions.

Troubleshooting Common Problems

VMs Do Not Restart After Host Failure

Verify HA is enabled and healthy on the cluster and affected hosts.
Check admission-control reservations and actual surviving-host CPU and memory capacity.
Confirm surviving hosts can access the VM's storage and required networks.
Review events for host-state determination, restart attempts, placement failures, and storage errors.

VM Monitoring Resets a VM Unexpectedly

Check VMware Tools status, guest resource pressure, and heartbeat interruptions.
Review VM Monitoring sensitivity and failure intervals.
Determine whether the guest was truly unresponsive or merely slow under load.
Consider a less aggressive policy or application-level checks before allowing automatic VM resets.

HA Reports a Host as Isolated

Test management VMkernel connectivity and physical switch paths.
Verify redundant uplinks, VLAN configuration, routing, and gateway reachability.
Review datastore heartbeat availability.
Confirm that the isolation response matches the storage and network design.

Application Monitoring Does Not Detect an Outage

Verify that VMware Tools is operational.
Verify that the monitoring agent or integration is installed, configured, and sending heartbeats.
Confirm that the selected health check detects the application's actual failure mode.
Compare VM reset recovery with application-native service recovery.

Cluster Cannot Admit Additional Powered-On VMs

Review the admission-control policy and configured host-failure tolerance.
Compare reserved and available CPU and memory capacity.
Choose whether to add capacity, reduce demand, adjust policy after a risk review, or place the workload elsewhere.

Recovery Takes Longer Than Expected

Measure detection, placement, power-on, guest boot, and application startup independently.
Check storage performance and network health.
Review VM boot dependencies and application startup sequencing.
Set realistic recovery objectives: HA cannot make an application ready before its operating system and services finish starting.

Exam-Relevant Notes

vSphere HA is a cluster feature managed through vCenter Server.
Host failure recovery normally means restarting VMs on surviving hosts, not continuing execution without interruption.
VM Monitoring uses VMware Tools heartbeats and normally resets the VM on its current host.
Application Monitoring can use application heartbeats through VMware Tools and also normally resets the VM on its current host.
Datastore heartbeats supplement management-network heartbeats when determining host state.
Admission control protects failover capacity but trades available workload capacity for stronger recovery guarantees.
HA is not the same as Fault Tolerance: HA is restart-based, while FT is designed for continuous availability for supported workloads.

Summary

vSphere HA detects selected host, guest, and application failures and automates VM recovery within a cluster. Effective protection requires multiple healthy ESXi hosts, accessible VM storage, redundant management networking, sufficient failover capacity, correct isolation and heartbeat policies, and tested monitoring.

HA reduces downtime but does not remove it. Use it as one layer in a broader availability design that may also include application clustering, storage redundancy, backup, and disaster recovery.