VMware ESXi and vSphere Cluster Management

vSphere High Availability (HA) Explained

Learn how vSphere HA detects ESXi, guest OS, and application failures, restarts virtual machines, preserves failover capacity, and differs from Fault Tolerance.

vSphere High Availability (HA) is a cluster feature that reduces virtual machine service interruption by detecting failures and automatically restarting or resetting affected VMs. It improves recovery, but it does not provide uninterrupted execution or guarantee protection from every outage.

This lesson explains HA architecture, host failure recovery, host isolation, VM and application monitoring, admission control, capacity planning, configuration, testing, and troubleshooting.

High availability fundamentals

High availability (HA) is a design approach that reduces service interruption through redundancy, monitoring, and automated recovery. A highly available service can still experience a short outage while a failure is detected and the service is restarted.

Availability can be implemented at several layers:

These layers complement one another. vSphere HA does not replace application clustering, backups, storage protection, or disaster recovery. For example, HA may restart a database VM after a host failure, but the database still needs time to boot, recover its transaction log, and accept connections.

What vSphere HA does

vSphere HA is a vCenter Server-managed feature configured for a cluster, not for an isolated standalone ESXi host. It monitors ESXi hosts and can optionally monitor guest operating system and application heartbeats. When a protected workload is affected, HA selects an eligible recovery action.

• After an ESXi host failure, HA powers on affected VMs on surviving hosts.
• After a guest OS failure, VM Monitoring can reset the VM on its current host.
• After an application heartbeat failure, Application Monitoring can trigger a configured VM recovery action.
• HA does not repair a failed application process in place or prove that application data is correct.

HA cluster architecture

A cluster is a group of ESXi hosts managed as a shared resource pool. An ESXi host is the VMware hypervisor server that runs virtual machines. vCenter Server provides the management platform used to configure and coordinate the cluster.

A functioning HA design usually depends on these components:

• vCenter Server: creates the cluster policy and coordinates configuration and status reporting.
• ESXi hosts: run VMs, exchange HA signals, and provide recovery capacity.
• VM storage: VM files must be accessible to an eligible recovery host. This is commonly shared storage, but the important requirement is accessibility from the destination host.
• Cluster networking: management connectivity carries host communication and heartbeats. Redundant adapters, switches, and paths reduce false isolation events.
• VMware Tools: guest software that reports guest heartbeats and supports optional VM and application monitoring.

Hosts exchange periodic heartbeats, which are signals used to determine whether a host is responsive. Datastore heartbeating provides an additional signal through accessible datastores. It helps HA distinguish a truly failed host from a host that is still running but cannot communicate over the management network.

Recovery also requires resources. Surviving hosts must have enough available CPU and memory to power on the affected VMs, and they must be able to access the VMs' files and virtual networks.

Protection against ESXi host failure

When a host becomes unresponsive, HA evaluates host heartbeats, datastore heartbeats, and cluster state. If HA determines that the host has failed, it identifies the VMs that were running there and selects other eligible hosts.

1. HA detects missing or abnormal host signals.
2. HA evaluates whether the condition represents failure, isolation, or a communication partition.
3. HA selects a surviving host with suitable CPU, memory, storage, and configuration access.
4. HA powers on affected VMs on the selected hosts.
5. The guest operating systems boot and their services recover using their normal startup procedures.

This is restart-based recovery, not uninterrupted execution. Users can experience downtime during failure detection, VM power-on, operating system boot, and application initialization.

Restart priority and dependencies

Restart priority assigns relative importance or order to VM recovery. Dependency-sensitive services may need infrastructure VMs, directory services, databases, and then application or web servers. Priorities help express this order, but they do not replace application dependency management or guarantee that a service is ready immediately after its VM powers on.

Host isolation and partition scenarios

Host isolation occurs when an ESXi host loses management-network communication with the rest of the HA cluster while it may still be running VMs. A true host failure means the host cannot continue running its workloads. These conditions can look similar from the cluster's point of view, so HA uses multiple signals and an isolation response policy.

If HA incorrectly assumes that an isolated but healthy host has failed, another host might start copies of the same VMs. This split-brain situation can cause duplicate operating systems, conflicting network identities, or data corruption. The configured host isolation response determines what the isolated host does with its running VMs, such as leaving them powered on, powering them off, or shutting them down, depending on the environment and supported configuration.

Datastore heartbeating helps answer an important question: is the apparently unavailable host still active and able to access storage? It is not a substitute for reliable networking, but it gives HA another source of evidence.

• Use redundant management adapters and independent physical switch paths where possible.
• Validate VLANs, routing, gateways, MTU settings, and firewall rules.
• Ensure hosts can access the datastores selected for heartbeat use.
• Choose an isolation response based on the risk of duplicate VM execution versus the risk of leaving workloads running.

Guest OS failure protection with VM Monitoring

VM Monitoring is an optional HA capability that uses VMware Tools heartbeats from the guest operating system. A VM can remain powered on while its guest OS is hung, so host-level health alone cannot detect every guest failure.

When VMware Tools heartbeats stop for the configured failure interval, HA can reset the affected VM on its current host when possible. The reset is similar to restarting a machine that is no longer responding.

Monitoring sensitivity determines how quickly HA treats missing heartbeats as a failure. Aggressive settings can shorten detection time but increase false-positive resets during temporary CPU pressure, guest pauses, Tools problems, or operating system load. Tune the interval according to the workload and validate it with controlled tests.

Application failure protection

Application Monitoring detects application heartbeats reported from inside a VM. It generally requires VMware Tools plus an appropriate third-party or application-aware monitoring agent installed and configured in the guest.

If the application stops reporting its heartbeat, HA can perform the configured VM recovery action, normally a VM reset or restart on the same host. This is not live application repair: HA does not automatically fix a dead process, repair corrupted data, or verify that transactions are correct.

Detecting an unresponsive application and proving application data correctness are different tasks. Application monitoring should therefore be combined with application health checks, logs, transaction validation, and an appropriate recovery procedure.

Admission control and capacity planning

Admission control is the HA capacity policy that preserves enough cluster resources for VM restart after host failure. It prevents the cluster from accepting a workload placement that would undermine the selected failure tolerance.

Common planning approaches include reserving capacity for one or more host failures and reserving a percentage of cluster CPU and memory capacity. The exact choices and names depend on the vSphere release and configuration model.

There is a direct tradeoff:

• Maximizing consolidation increases utilization but leaves less spare capacity for recovery.
• Reserving more capacity improves the chance of meeting a failover objective but may leave resources idle during normal operation.

Restart guarantees are affected by VM resource reservations, oversized VMs, uneven host utilization, and the number of simultaneous failures. A large VM may require a specific host with enough contiguous available resources even when the cluster appears to have sufficient total capacity.

Capacity questions to answer

• How many host failures must the cluster tolerate?
• Can surviving hosts provide the CPU and memory required by protected VMs?
• Are reservations based on actual business requirements or historical over-sizing?
• Can all eligible hosts access the VM files, networks, and required datastores?
• What happens if maintenance, a second failure, or a storage outage occurs at the same time?

HA recovery behavior and limitations

HA recovery follows a general sequence: detect a problem, declare the failure or isolation condition, select a recovery host, and power on or reset the VM. Timing varies with heartbeat detection, cluster state, storage access, host load, operating system boot, and application startup.

HA does not replace:

• Backups and restore testing
• Storage redundancy and protection
• VM or data replication
• Guest OS clustering
• Application clustering
• Site-level disaster recovery

vSphere Fault Tolerance (FT) is a separate capability designed for continuous availability of supported workloads. HA normally accepts a brief outage while a VM restarts; FT's goal is to avoid interruption through continuously maintained execution. FT has different workload, resource, scale, and configuration requirements, so it is not simply a faster HA setting.

Configuring vSphere HA

1. Create or select a cluster in vCenter Server.
2. Enable vSphere HA for the cluster.
3. Configure admission control for the required host-failure tolerance.
4. Review and select the host isolation response.
5. Enable and tune VM Monitoring for VMs that require guest OS failure recovery.
6. Enable Application Monitoring only where VMware Tools and a supported guest-side application monitoring agent are present.
7. Assign VM restart priorities for services with startup dependencies.
8. Review HA status, alarms, recent tasks, and cluster events.

After configuration, confirm that every host reports healthy HA status. Verify that protected VM files are accessible from eligible recovery hosts, VMware Tools is running where monitoring is required, and the cluster has sufficient reserved capacity.

Operational validation and testing

Document recovery objectives before relying on HA in production. Define acceptable recovery time, acceptable data loss, the host failures to tolerate, and the application checks that prove recovery is complete.

Perform approved, controlled failure tests during a maintenance window. Record failure detection time, VM restart time, guest boot time, application readiness time, and any data or dependency issues. Test more than the simplest host failure when appropriate, including management-network interruption and guest monitoring behavior.

Troubleshooting common HA problems

VMs do not restart after an ESXi host failure

• Review HA events and cluster alarms in vCenter.
• Check whether HA is enabled and healthy on the cluster and hosts.
• Verify datastore and VM storage accessibility from surviving hosts.
• Check admission-control status and remaining CPU and memory capacity.
• Review VM eligibility and restart priority.

Likely causes include insufficient failover capacity, inaccessible VM files, unhealthy or disabled HA, and VM configuration or eligibility issues.

A VM is repeatedly reset by VM Monitoring

• Verify VMware Tools status and logs.
• Review guest CPU, memory, and operating system event logs.
• Review VM Monitoring sensitivity and reset history.
• Correct guest resource pressure or OS instability before reducing monitoring sensitivity.

Intermittent Tools heartbeat loss can be caused by guest overload, Tools failure, overly aggressive intervals, or an unstable operating system.

HA reports host isolation unexpectedly

• Validate redundant management adapters and physical switch paths.
• Confirm management addressing, VLANs, routing, gateways, and firewall settings.
• Review host network connectivity and HA event details.
• Verify datastore heartbeat availability.

Application Monitoring does not detect an outage

• Confirm VMware Tools is operational.
• Verify that a supported guest-side monitoring agent is installed.
• Check the application's heartbeat configuration and whether it reflects the failure being tested.
• Perform a controlled application failure test and review agent, guest OS, and vCenter logs.

Scale and version considerations

Supported host and VM counts are version- and licensing-dependent. Always verify limits and compatibility against the VMware documentation for the specific vSphere release and edition being deployed.

As a historical example, a cluster was described as supporting up to 32 ESXi hosts and 4,000 VMs. Do not treat those figures as universal limits for current releases; product versions, licensing, configuration constraints, and supported design guidance can change.

Exam-relevant notes

• vSphere HA is configured at the cluster level through vCenter Server.
• HA restarts VMs after host failure; it does not preserve uninterrupted VM execution.
• Host isolation is loss of management communication, not proof that the host has powered off.
• Datastore heartbeats provide additional evidence about whether an isolated host remains active.
• VM Monitoring depends on VMware Tools guest heartbeats and is optional.
• Application Monitoring requires an application-aware guest agent and normally responds with a VM reset or restart.
• Admission control protects failover capacity but may reduce consolidation.
• HA does not replace backups, replication, application clustering, or disaster recovery.
• Fault Tolerance has a different goal: continuous availability for supported workloads.

For related planning, use the vSphere High Availability guide as the internal reference for this topic.