VMware ESXi and vSphere Cluster Management

Protect Virtual Machines from ESXi Host Failures with vSphere High Availability

Learn how vSphere HA detects ESXi host failures, coordinates recovery with FDM, and restarts VMs on surviving hosts. Review storage, networking, licensing, capacity, risks, and testing.

VMware vSphere High Availability (vSphere HA) protects virtual machines when an ESXi host becomes unavailable. It uses a vSphere cluster to detect the failure and restart affected VMs on other eligible hosts.

This is restart-based availability, not continuous execution. A VM stops with its failed host and boots again elsewhere. The guest operating system and its applications therefore experience an interruption.

What vSphere HA Protects

An ESXi host is the VMware hypervisor server that runs virtual machines. A vSphere cluster is a group of ESXi hosts managed together for resource and availability features.

vSphere HA is a cluster-level service whose central use case is recovery from physical ESXi host failures, such as a hardware outage or host crash. Depending on configuration, HA can also respond to certain virtual machine or guest-application failures by restarting a VM. These options do not change the fundamental model: HA restores service by restarting a workload.

• HA: Restarts VMs after a host failure and causes downtime during detection and boot.
• vMotion: Live-migrates a running VM during planned maintenance or resource balancing. It is not a response to an unexpected host crash.
• VMware Fault Tolerance: Uses a secondary execution instance for selected workloads to reduce interruption during some host failures.
• Backup or replication: Protects recoverability and copies of data, but does not normally provide immediate VM restart on another host.

What Happens During an ESXi Host Failure

A failure may appear as a host crash, loss of communication with peer hosts, or isolation from the management network. HA must distinguish an unavailable host from a temporary communication problem before taking action.

The failed host does not live-migrate running VMs during an unexpected outage. Its VMs are powered on again elsewhere, subject to restart priorities, resource availability, and the condition of required infrastructure.

Downtime and Recovery Expectations

HA introduces an interruption because the VM must be powered on and restarted. Recovery time depends on several stages:

• Failure detection and isolation handling.
• Host coordination and, when necessary, leadership election.
• Selection of a restart host and placement of the VM.
• Access to the VM's configuration, virtual disks, and other files.
• VM power-on and virtual hardware initialization.
• Guest operating system boot and filesystem recovery.
• Application startup, client reconnection, and application-level recovery.

Applications that maintain sessions or connections must tolerate the interruption. Databases and other transactional systems may need to replay logs or roll back incomplete work.

Shared Storage Requirements

A surviving ESXi host needs access to the VM's files in order to restart it. These files include the VM configuration and virtual disks. For HA-protected workloads, the required shared datastore must be visible and usable from every host that may be selected for restart.

If a datastore is accessible only from the failed host, HA may detect the host failure but cannot successfully restart VMs stored there. A similar problem occurs when storage paths are intermittently broken or permissions and presentations differ between hosts.

Consistent Virtual Networking

A VM can start successfully and still be unavailable if its network is missing on the restart host. Every host that may restart the VM needs compatible virtual networking, including the correct virtual switch, port group, VLAN access, uplinks, and physical switch configuration.

For example, suppose a production VM uses a port group connected to VLAN 120. If that port group exists only on Host A and Host A fails, the VM may boot on Host B without usable production connectivity. Create an equivalent network on Host B and every other eligible host, then verify that the physical uplinks and switches carry VLAN 120.

Standardized designs reduce configuration drift. Where available, a vSphere Distributed Switch can help apply consistent port groups and policies across hosts. Standard switches can also support HA, but their configuration must be maintained consistently on each relevant host.

• Use equivalent VM port groups and VLAN assignments on all eligible hosts.
• Verify that the VM's virtual NIC connects to the intended port group.
• Check physical uplink status and switch configuration.
• Provide redundant, reliable paths for HA management communication.
• When adding a virtual switch or required VM network to one host, apply the corresponding configuration to the rest of the cluster.

Licensing and Cluster Prerequisites

The vSphere edition and licensing entitlement must include HA. HA is enabled at the cluster level; it is not a standalone availability feature configured independently on one ESXi host.

• Use vCenter Server to create or select a cluster containing multiple ESXi hosts.
• Enable vSphere HA in the cluster availability settings.
• Confirm that all participating hosts are compatible with the cluster configuration.
• Provide shared datastore access and consistent networking.
• Reserve enough CPU and memory for workloads from a failed host.

A single host cannot provide host-failure restart protection by itself. The cluster must have surviving hosts with enough usable resources to run the failed host's workloads.

Fault Domain Manager and HA Coordination

Fault Domain Manager (FDM) is the HA service and agent framework that runs across hosts in an HA-enabled cluster. FDM agents communicate with one another, coordinate cluster membership, monitor host state, and manage recovery decisions.

HA uses a leadership election to choose the host coordination role that manages the HA domain and monitors peers. Older VMware materials may use the terms master and slave; current descriptions generally refer to a leader and other hosts or agents. During historical HA coordination behavior, datastore visibility was an important tie-breaker: a host that could see the greatest number of datastores could be favored during leadership selection. Administrators should focus on the current cluster role and health information shown by their vSphere version while recognizing this terminology in older documentation and event records.

Capacity Planning and Admission Control

Restart protection depends on surviving hosts having enough CPU and memory. A cluster that is fully committed before a failure may detect the outage but still be unable to restart every affected VM.

Admission control is the HA capacity policy that reserves resources for failed-host workloads. Configure it according to the number of host failures the environment must tolerate. The policy should account for host size, VM reservations, resource pools, planned maintenance, and growth.

For example, in a three-host cluster intended to tolerate one host failure, the remaining two hosts must have sufficient capacity for the workloads that could be displaced. Without that spare capacity, some VMs may remain powered off after an outage. Admission control helps prevent the cluster from accepting a configuration that consumes the planned failover reserve, although it cannot compensate for incorrect sizing or infrastructure failures.

Risks of an Unplanned VM Restart

A host failure is similar to an abrupt power loss from the guest's perspective. In-memory work and disk writes that were not safely committed may be lost. The guest filesystem may require recovery, and an application may need to roll back incomplete transactions.

• Use journaled guest filesystems where appropriate.
• Enable application-aware transaction logging, especially for databases.
• Test database and application crash-recovery procedures.
• Maintain backups and, where required, replication to another failure domain.
• Set VM restart priorities and dependencies when services must recover in a particular order.

HA is not a replacement for backups, replication, or application-level resilience. It improves service restoration after a host outage, but it does not guarantee preservation of every in-memory operation or protect against corruption caused by an unrelated storage or application failure.

vSphere HA Prerequisites and Why They Matter

Configuration Checklist

Cluster

1. Create or select a vSphere cluster containing multiple ESXi hosts.
2. Enable vSphere HA in the cluster availability settings.
3. Confirm that FDM or HA agents report a healthy state on every participating host.
4. Configure admission control or an equivalent failover-capacity policy.
5. Set VM restart priorities and dependencies where ordered recovery is needed.

Storage

• Present each required datastore to every host that may restart the VM.
• Verify uniform visibility, mounts, access permissions, and paths.
• Validate FC, FCoE, iSCSI, or NFS connectivity before relying on production protection.

Network

• Create equivalent VM networks, port groups, VLAN assignments, and uplink connectivity across hosts.
• Ensure redundant and reliable HA management paths.
• Confirm that distributed or standard switch settings are consistent.

Guest and application

• Use a journaled filesystem where appropriate.
• Configure transaction logging, application recovery, and backups.
• Document how clients reconnect after a VM restart.

Operational Validation

Do not rely on the HA checkbox alone. Before placing workloads under HA protection, check the cluster HA status, FDM agent health, datastore connectivity, network consistency, admission-control state, events, and alarms.

Perform a controlled resilience test under approved change-control procedures. Confirm that the selected VMs restart on surviving hosts, attach to their datastores, regain expected network connectivity, complete guest boot, and provide healthy application services. Review events and alarms to verify the sequence from failure detection through restart and recovery.

Troubleshooting Common HA Symptoms

VM does not restart after an ESXi host outage

Likely causes include disabled HA, unhealthy agents, insufficient failover capacity, inaccessible datastores, VM exclusion from HA protection, or an unsuitable restart policy.

• Review cluster HA configuration, events, and alarms.
• Confirm FDM or HA agent status on the hosts.
• Check datastore visibility and access on surviving hosts.
• Review admission control and available CPU and memory.
• Check the VM's restart priority, dependencies, and protection settings.

VM restarts but has no network connectivity

Check for a missing port group, VLAN mismatch, incorrect physical uplink or switch configuration, or inconsistent standard and distributed switch settings.

• Compare virtual networking and port-group configuration across hosts.
• Verify VLAN reachability and uplink status.
• Confirm that the VM virtual NIC is connected to the intended network.

HA declares or handles isolation unexpectedly

Management network interruption, incorrect isolation-address or heartbeat configuration, and intermittent switching or uplink failures can cause unexpected isolation handling.

• Review management network redundancy.
• Inspect HA events and heartbeat status.
• Validate physical network paths and relevant HA settings.

Guest filesystem or application requires recovery

This commonly follows abrupt VM power loss during a host failure, uncommitted application data, or a non-journaled or improperly configured guest filesystem.

• Review guest boot and filesystem logs.
• Run application-specific recovery validation.
• Confirm backup integrity and transaction-log recovery procedures.

Practical Failure Scenarios

Single host hardware failure

A three-host HA cluster runs a VM on Host A. Host A suffers a hardware outage. HA identifies the loss and powers the VM on from shared storage using Host B or Host C, provided the selected host has adequate capacity and matching network access.

Inconsistent port group configuration

A workload uses a production VLAN port group that exists only on its original host. After failover, the VM starts on another host but lacks production connectivity. The fix is to provide an equivalent port group and VLAN configuration on every eligible host.

Insufficient failover capacity

A cluster has little spare memory. When one host fails, HA detects the event but cannot restart every VM because the remaining hosts cannot satisfy their resource requirements. Admission control and capacity planning help prevent this condition.

Storage visibility problem

A VM resides on an iSCSI datastore reachable from only one host. If that host fails, other hosts cannot access the VM files, so HA cannot restart the VM until storage presentation and connectivity are corrected.

Guest consistency after abrupt restart

A database VM loses power when its host fails. The guest reboots elsewhere, and the filesystem and database recover using their journals and transaction logs. Backups and tested application recovery procedures remain necessary.

Exam-Relevant Notes

• vSphere HA is primarily for restarting VMs after an ESXi host failure.
• HA does not live-migrate VMs after an unexpected host crash.
• Shared datastore access is required because another host must read the VM files.
• Equivalent port groups, VLAN access, uplinks, and physical switch configuration are required for network connectivity after restart.
• FDM agents coordinate membership, monitor hosts, and conduct leadership elections.
• Admission control preserves capacity for failover; detection alone does not guarantee restart.
• HA causes a service interruption and does not replace backups, replication, or application-aware recovery.

For related cluster protection guidance, return to vSphere HA host-failure protection.