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 and restarts virtual machines on surviving hosts, including storage, networking, capacity, FDM, limitations, and validation.

What vSphere High Availability Protects

vSphere High Availability (HA) is a cluster service that detects certain failures of an ESXi host and automatically restarts affected virtual machines on surviving hosts. An ESXi host is a physical server running the ESXi hypervisor. A vSphere cluster is a group of ESXi hosts managed together by vCenter Server.

HA primarily reduces service interruption after a host-level failure. It does not keep a virtual machine executing continuously while its host is unavailable. Instead, HA performs an automated VM restart: it powers the VM on again on another eligible host.

Host-level protection: HA responds to failures of the physical ESXi host or to certain host communication conditions.
VM-level protection: HA restarts the VM, but it does not guarantee that the guest operating system or its applications will be healthy afterward.
Application-level protection: databases, clustered applications, backups, replication, and transaction recovery address requirements that HA alone cannot meet.

HA therefore provides recovery after an interruption, not uninterrupted execution, zero downtime, or preservation of the VM's memory state.

For background on inventory and cluster administration, see adding an ESXi host to vCenter Server inventory and the VMware ESXi online course.

What Happens During an ESXi Host Failure

Possible failure conditions include an ESXi kernel crash, physical hardware outage, power loss, a host becoming isolated from cluster communication, or loss of management-network connectivity. HA evaluates host communication and available cluster information to determine whether a host has failed, is isolated, or is otherwise unreachable.

When a host failure is confirmed, HA identifies the virtual machines that were running on that host. It then selects eligible surviving hosts in the same HA cluster and attempts to power on the affected VMs there.

Failure detection: HA agents observe host communication and related cluster signals.
Host-state determination: the cluster coordinates whether the host is failed, isolated, or reachable through another path.
Restart-location selection: HA chooses a surviving host with access to the VM's files, compatible networking, and sufficient CPU and memory.
VM power-on: the destination host opens the VM files and powers on the VM.
Guest and application recovery: the operating system boots and applications perform their normal startup or crash-recovery procedures.

Restart success depends on more than the presence of another ESXi host. The destination must have available compute resources, access to the VM's datastore, compatible virtual networking, and a usable path to required physical networks.

Example: Single-host hardware failure

Suppose a host running several application VMs experiences a hardware crash. The VMs reside on a shared iSCSI datastore that is visible to the other hosts. HA identifies the failed host, selects surviving hosts with sufficient resources, and powers on the affected VMs across the cluster.

HA Cluster Requirements

HA is enabled and configured at the vSphere cluster level through vCenter Server. All participating ESXi hosts must be managed as members of that same cluster and must be prepared to run the workloads that may be moved to them through HA restart.

Requirement	Why it is required	Validation method	Effect if missing
Shared datastore access	Another host must open the failed VM's configuration, virtual disk, and related files.	Compare datastore inventory, mounts, permissions, paths, and health on every host.	The VM may have no eligible restart location.
Consistent virtual networking	The restarted VM must connect to the network it used before the failure.	Compare port groups, VLANs, switches, distributed-switch membership, and uplinks.	The VM may start without network connectivity.
HA licensing or entitlement	The deployed vSphere edition must include the HA feature.	Review licensing and cluster feature availability in vCenter Server.	HA cannot be enabled or configured.
vCenter-managed cluster membership	HA coordinates hosts as one cluster service.	Confirm each host appears in the intended vCenter cluster.	Hosts do not participate in the same HA domain.
Available failover capacity	Surviving hosts need enough CPU and memory for affected VMs.	Review normal utilization, reservations, admission-control settings, and failure scenarios.	Some or all VMs may fail to restart.
Healthy host management connectivity	HA agents require reliable communication to maintain cluster membership and coordinate recovery.	Check host connectivity, management redundancy, alarms, and HA agent status.	A host may appear unreachable or the HA domain may behave unexpectedly.

Shared storage

A shared datastore is storage accessible by multiple ESXi hosts. VM files must be reachable from every host that could become a restart destination. Supported shared-storage examples include Fibre Channel (FC), Fibre Channel over Ethernet (FCoE), iSCSI, and NFS datastores.

Validate consistent datastore presentation, storage paths, permissions, mounts, and health across the cluster. It is not enough for one host to see a datastore: each possible restart host must be able to access the particular datastore containing the VM's files.

Inconsistent storage access can prevent a restart and can also influence HA coordination and host election. For example, if one surviving host cannot see an NFS datastore containing a failed VM, that host cannot restart the VM from that datastore.

Virtual networking

A restarted VM retains its virtual network configuration. Every candidate host must therefore provide the required network. With standard switches, use consistent port group names and VLAN configuration on the hosts. Replicate newly added standard switches, port groups, VLAN access, and physical uplink connectivity as appropriate.

When using a vSphere Distributed Switch, ensure that every eligible host is correctly connected to the distributed switch and that its physical uplinks are working. The physical switches must also provide the required VLAN trunking or access configuration.

A VM can restart successfully and still be unavailable to users if its destination host lacks the required port group or cannot reach the configured VLAN.

Capacity planning

HA does not create CPU or memory capacity. A cluster operating near full utilization may be unable to restart all workloads after losing a host. Plan spare capacity for the expected host-failure scenario, and review admission-control or other operational policies that prevent normal placement from consuming the planned reserve.

Fault Domain Manager and HA Coordination

When HA is enabled, the Fault Domain Manager (FDM) service starts on each ESXi host in the cluster. FDM agents maintain cluster membership, monitor host communication, participate in election activity, and coordinate recovery.

An HA election selects the host that coordinates the HA domain after HA starts or cluster membership changes. Current terminology commonly calls this host the primary host. Older documentation may call the same role the master. Other participating hosts are commonly called secondary hosts; older documentation may call them slaves.

The primary host monitors other hosts and orchestrates recovery actions. Datastore accessibility influences the election, and the host with access to the greatest number of datastores is normally favored. This preference helps select a coordinator with broad visibility into cluster storage, but it does not replace proper storage validation on every host.

HA Recovery Compared with Other Availability Methods

Method	Failure scope addressed	Recovery behavior	Expected interruption	Data-loss considerations
vSphere HA	ESXi host failure or related host availability conditions	Restarts affected VMs on surviving hosts	Downtime for detection, power-on, guest boot, and application recovery	Memory state is lost; in-flight work may be lost.
Backup and restore	Data loss, corruption, and broader recovery scenarios	Restores VM or application data from a backup point	Usually longer than HA and dependent on restore performance	Recovery point depends on backup frequency and consistency.
Replication-based recovery	Site, storage, or host loss when a replica is available	Recovers a replicated VM or workload at a designated location	Depends on detection, orchestration, and replica startup	Recovery point depends on replication interval and consistency.
Application clustering	Application or service-instance failure	Another application node continues or takes over service	May be low, depending on application design	Application-aware coordination can reduce transaction loss.
VMware Fault Tolerance	Specific VM-level host failure scenarios	Maintains a synchronized secondary execution path for supported workloads	Designed for much less interruption than a restart, subject to feature limits	Different protection model and workload constraints apply.

Downtime, Data Loss, and Application Implications

HA recovery includes downtime. There is an interval between host failure, failure detection, VM power-on, guest operating-system boot, and application readiness. HA does not preserve the failed VM's memory state.

An abrupt interruption can cause in-flight transaction loss, guest filesystem inconsistency, or application recovery work. Journaled guest filesystems can help recover filesystem metadata after an unclean shutdown, but journaling is not a guarantee that every application transaction will be preserved.

Applications should use their own recovery mechanisms. Databases may need crash recovery, log replay, integrity checks, or reconciliation. For stricter recovery-time or recovery-point objectives, combine HA with backups, replication, and application-level resiliency.

Recovery limitation timeline

Host failure → failure detection → restart location selection → VM power-on → guest operating-system boot → application recovery → restored service.

Planning and Validation Workflow

Pre-enable checklist

Create or select a vCenter-managed cluster.
Add only ESXi hosts with compatible shared-storage and virtual-network access.
Confirm the deployed license or edition includes vSphere HA.
Confirm every host can see the datastores used by protected VMs.
Compare datastore mounts, permissions, storage paths, and health across hosts.
Compare standard-switch port groups, VLANs, distributed-switch configuration, and physical uplinks.
Confirm reliable and preferably redundant management-network connectivity.
Measure CPU and memory usage and reserve enough capacity for the planned host-failure scenario.
Document which VMs require special application recovery, storage, or network treatment.

Enable and review HA

In the vSphere Client, open the intended cluster's availability settings.
Enable vSphere HA at the cluster level.
Allow the hosts to install or start their FDM agents.
Review the cluster HA status and each host's HA status.
Confirm FDM agents are running and that no host reports an agent configuration error.
Resolve storage, networking, licensing, inventory, or capacity warnings before relying on HA.
Review recent HA events after a configuration change or controlled test.

For related capacity behavior, review HA admission control and admission control policies.

Safe validation

Use controlled maintenance procedures and documented failure-testing procedures. Begin with non-production workloads, confirm expected alarms and events, and verify guest and application recovery. A successful test demonstrates one tested scenario; it does not prove resilience against every hardware, storage, network, capacity, or application failure.

Troubleshooting vSphere HA

HA cannot be enabled or reports an agent configuration error

Review cluster and host tasks, alarms, and HA configuration messages.
Verify host connectivity to vCenter Server and to other cluster hosts.
Confirm the vSphere edition or license includes HA.
Check for unresolved host inventory, management-network, or FDM installation issues.

A VM does not restart after a host failure

Review HA events to determine whether a restart was attempted and why it failed.
Confirm that an eligible host can access the VM's datastore and storage paths.
Check surviving-host CPU and memory capacity.
Verify that the VM's required networks exist on candidate hosts.
Review VM configuration and operational constraints that could prevent power-on.

The VM restarts but has no network connectivity

Compare port group names and VLAN IDs across hosts.
Check standard-switch configuration or distributed-switch membership.
Validate physical-switch VLAN trunking and ESXi uplink health.
Confirm the VM is connected to the intended port group after restart.

Cluster behavior changes after communication loss

Review HA events and host state transitions.
Verify management-network redundancy and connectivity.
Compare datastore visibility across hosts.
Inspect which host is acting as the elected HA coordinator.

The guest or application is inconsistent after recovery

Review guest filesystem and application logs after restart.
Confirm the guest uses a journaled filesystem where appropriate.
Run the application's transaction-recovery and integrity procedures.
Restore or reconcile data from backups, logs, or replication when required.

Key Takeaways

vSphere HA detects qualifying ESXi host failures and restarts affected VMs on surviving hosts.
HA is automated restart, not live migration, continuous execution, or zero-downtime protection.
Shared datastore visibility, equivalent virtual networking, healthy FDM communication, licensing, and spare capacity are essential.
The primary HA host coordinates the domain, while secondary hosts participate in monitoring and recovery.
Memory state is lost during an unplanned host outage, so applications may need crash recovery and transactions may be lost.
Use HA together with backups, replication, and application-aware resiliency when business requirements exceed restart-based recovery.