VMware ESXi and vSphere Cluster Management

Enable and Configure vSphere HA on an Existing vSphere Cluster

Learn how to enable vSphere HA, configure host monitoring, admission control, VM monitoring, datastore heartbeats, restart behavior, and validate host-failure recovery.

vSphere High Availability (HA) is a cluster service managed by vCenter Server. It detects qualifying ESXi host or virtual machine failures and restarts affected virtual machines on available hosts. HA improves service availability, but it does not prevent outages, guarantee zero data loss, or replace backups, replication, disaster recovery, or application-level clustering.

This lesson assumes that you understand the vSphere inventory hierarchy, ESXi management networking, datastores, vCenter permissions, and virtual machine CPU and memory reservations. For background, review basic ESXi configuration and communication between vCenter Server and ESXi.

What vSphere HA Does—and Does Not Do

Technology	Primary purpose	Difference from HA
vSphere HA	Restarts VMs after qualifying host or guest failures.	Recovery normally involves a VM restart, so there can be downtime.
vMotion	Moves a running VM between compatible hosts.	Used for planned mobility and maintenance, not automatic recovery from every failure.
DRS	Balances workloads and recommends or performs VM placement changes.	DRS manages resource balance; HA manages failure recovery. They can work together.
Fault Tolerance	Maintains a synchronized secondary execution path for supported workloads.	Provides more continuous protection but has different requirements and limitations.
Backup and disaster recovery	Protects data, restores earlier states, or recovers at another site.	HA does not replace backups, replication, or a disaster-recovery site.

HA is also not an application health system. A guest operating system or application can fail while the ESXi host remains healthy. Use application-aware clustering and monitoring when the workload requires it.

Prerequisites and Pre-Change Review

Use an existing vCenter Server-managed cluster containing compatible ESXi hosts.
Verify reliable, redundant management networking between ESXi hosts and vCenter Server. Check VLANs, uplinks, routing, DNS, name resolution, and time synchronization.
Confirm that the hosts have compatible networking and shared or otherwise supported storage. HA must be able to identify hosts and access VM files after a failure.
Reserve enough CPU, memory, storage connectivity, and network capacity to restart protected VMs after the planned host-failure scenario.
Use a vCenter role with permission to edit cluster services and settings. See assign permissions for role planning.
Review cluster health, host connectivity, datastore accessibility, existing alarms, pending tasks, licensing, and compatibility before making the change.
Document the intended isolation response, admission-control policy, restart priorities, and any nondefault advanced settings. Apply change control and use a maintenance window when operational risk warrants it.

Enable HA on an Existing Cluster

In the vSphere Client, select the target cluster in the inventory.
Open the cluster's management or configuration area. Navigation labels vary between vSphere Client releases.
Locate the vSphere HA service and choose its edit or configure control.
Enable vSphere HA.
Configure Host Monitoring, Admission Control, VM Monitoring, Datastore Heartbeating, and only the advanced options required by your design.
Save the configuration. vCenter Server deploys or configures the HA agent on participating hosts.
Wait for configuration tasks to finish, then confirm that HA is enabled and every eligible host reports a healthy HA-agent state.

The HA agent is the host-side component used for HA coordination and monitoring. If a host remains in an error or unconfigured state, do not assume the cluster is protected.

HA Architecture and Failure Detection

HA hosts coordinate through a primary and secondary role model. A primary host performs coordination duties, while a secondary host participates in monitoring and recovery. Older interfaces and documentation may use the terms “master” and “slave” for these roles.

HA uses several signals:

Management-network heartbeats: Hosts exchange signals over the ESXi management network and communicate with vCenter Server.
Datastore heartbeats: Hosts write state information to selected shared datastores. This provides an additional signal when management-network communication is interrupted.
Isolation-address checks: An isolated host can test whether it can reach configured network endpoints from its management network.
VMware Tools heartbeats: VM Monitoring uses guest-to-host signals to assess whether a guest appears responsive.

HA attempts to distinguish a complete host failure, management-network isolation, a network partition, and a host that is unavailable to vCenter. The evidence affects whether HA restarts a VM elsewhere or applies the configured isolation response. Detection is not infallible: a surviving host, a broken network path, and storage visibility can create ambiguous conditions.

Condition	Typical signals available to HA	Likely HA decision	Administrator considerations
Complete host failure	Management heartbeat stops; datastore evidence may also stop.	Restart protected VMs on surviving capacity.	Check storage accessibility, admission control, and restart placement.
Management-network isolation	Host may still run VMs and may retain datastore access; isolation-address and datastore checks provide context.	Apply the configured isolation response and avoid duplicate execution where possible.	Investigate management redundancy and isolation-address reachability.
Network partition	Different host groups can communicate with different parts of the cluster.	Coordinate recovery using available heartbeat evidence and cluster state.	Review events carefully; split-brain risk makes isolation settings important.
Datastore connectivity issue	Management communication may work while datastore heartbeats or VM files are inaccessible.	Recovery may be limited or impossible for VMs whose storage cannot be reached.	HA is not storage failover; investigate paths, mounts, and array health.
Guest OS unresponsiveness	VMware Tools heartbeat may stop while the ESXi host remains healthy.	VM Monitoring may reset the VM if thresholds and reset limits allow it.	Validate that a reset is safer than allowing the guest to continue.

Core HA Settings

Setting category	Primary purpose	What it monitors or controls	Key operational consideration
Host Monitoring	Enables host and management-network failure responses.	Host heartbeats, isolation, and isolation response.	Disabling it prevents normal HA reaction to host conditions.
Admission Control	Protects recovery capacity.	Whether new or expanded workloads fit within the failure policy.	Reservations and uneven hosts can make usable capacity smaller than raw capacity.
VM Monitoring	Detects an apparently unresponsive guest.	VMware Tools heartbeats and reset thresholds.	Atypical or heavily loaded guests can produce false positives.
Datastore Heartbeating	Adds host-state evidence when management communication is lost.	Heartbeat files or state on selected datastores.	It does not replace redundant management networking.
Advanced Options	Tunes behavior for a defined design requirement.	Isolation addresses, cluster behavior, and other version-specific values.	Validate keys and values for the exact vSphere release.
VM restart priority and dependencies	Orders recovery of workloads.	Priority levels and supported dependency relationships.	Ordering does not create capacity or prove application readiness.

Host Monitoring and Isolation Response

Host Monitoring permits HA to react to host failure and management-network failure conditions. If a host cannot communicate through its management network but may still be running, it is considered isolated. The isolation response determines what happens to its VMs, such as leaving them powered on, shutting them down, or powering them off, depending on the available release and configuration.

Choose an isolation response according to storage behavior, application tolerance, and the risk of the same VM continuing on the isolated host while another host attempts recovery. Disabling Host Monitoring may stop HA from responding to these conditions and should be reserved for a documented maintenance or troubleshooting reason.

Admission Control and Restart Capacity

Admission control reserves or evaluates enough cluster resources for configured host-failure scenarios. It trades some ability to power on or expand workloads for predictable recovery capacity. The relevant capacity is not simply the sum of host CPU and memory: VM reservations, VM sizing, resource fragmentation, and host heterogeneity affect the calculation.

Policy approach	How capacity is reserved or evaluated	Best fit	Advantages	Limitations
Cluster resource percentage	Reserves a configured percentage of CPU and memory for failover.	Small, relatively balanced clusters.	Flexible and straightforward.	May not correspond precisely to the largest host or a particular failure.
Dedicated failover hosts	Designates host capacity for failure recovery where supported.	Environments requiring predictable standby capacity.	Clear failure target and planning model.	Reserved hosts can remain underused during normal operation.
Slot-based policy where available	Calculates capacity from slot sizes based on VM reservations and overhead.	Older or version-specific designs.	Expresses host-failure tolerance in VM units.	One large reservation can inflate slot size and waste usable capacity.
Admission control disabled	Does not block power-on or expansion when recovery capacity is insufficient.	Temporary, explicitly accepted risk only.	Maximum normal-operation flexibility.	No enforced guarantee that workloads can restart after failure.

For a two-host production cluster, first determine whether losing either host leaves enough capacity for the protected VMs. A large memory reservation on one VM can cause admission control to reject additional power-on operations even when free memory appears available. Review warnings and failover capacity before and after enabling HA; add capacity, rebalance workloads, or adjust justified reservations through change control.

VM Monitoring

VM Monitoring observes VMware Tools heartbeats. If a conventional server VM stops sending meaningful heartbeats, HA can monitor it and, depending on the selected sensitivity and supported mode, reset the VM. Some releases provide monitoring-only behavior, reset behavior, and reset limits or time windows.

Install and maintain VMware Tools, confirm healthy guest behavior, and select conservative thresholds. A workload that intentionally pauses, performs long CPU-intensive operations, or experiences unusual I/O waits may appear unresponsive and receive an unwanted reset. VM Monitoring handles guest responsiveness; it is not the same as recovering a VM after an ESXi host failure, and it does not replace application-level health checks.

Datastore Heartbeating

Datastore heartbeating helps HA assess host state when management-network communication is interrupted. Automatic selection chooses suitable accessible datastores where supported. Manual selection lets an administrator identify reliable shared datastores according to the storage design.

Select datastores that are mounted and reachable by the relevant cluster hosts and have dependable storage paths. A manually selected datastore unavailable to part of the cluster undermines the signal. Datastore heartbeating cannot repair storage failures and is not a substitute for redundant management-network paths.

Advanced HA Options

Change advanced settings only for a defined operational requirement with a documented change plan. Isolation addresses are endpoints that an ESXi host pings from its management network to help determine whether it is isolated. Use at least one reachable address appropriate to that network; use multiple addresses when the design requires independent reachability.

Advanced settings may also affect isolation detection, restart behavior, and minimum usable VM resource assumptions. Available keys and supported values vary by vSphere release. Validate every setting against the exact version, record its justification, and avoid copying undocumented values between environments. See advanced options in vSphere HA for related configuration study.

VM Restart Priorities and Dependencies

Restart priority influences the order in which HA attempts to recover VMs after a host failure. For a tiered application, a database VM might receive higher priority than application and web-tier VMs. Where supported, restart dependencies can delay one VM until another recovery attempt has occurred.

Priorities and dependencies do not create capacity, guarantee that a service is application-ready, or replace service health checks. Configure them according to service order rather than merely business importance. Per-VM overrides can replace inherited cluster defaults, so review both the cluster setting and each important VM's override.

Validation After Configuration

Validation item	Where to verify	Expected result	Action if unsuccessful
HA service enabled	Cluster management or configuration settings.	HA is enabled for the target cluster.	Review configuration tasks and permissions.
Host HA-agent state	Cluster hosts, health, events, or configuration issues.	Every eligible host is configured and healthy.	Investigate agent deployment, connectivity, DNS, time, certificates, licensing, and compatibility.
Admission-control status	HA capacity or cluster summary.	Policy is active and required failover capacity is available.	Review reservations, host balance, policy, and current workload demand.
Datastore heartbeat selection	HA datastore-heartbeat settings and storage view.	Selected datastores are accessible to intended hosts.	Check mounts and storage paths; use automatic selection or suitable shared datastores where supported.
Network redundancy	ESXi networking, physical switches, uplinks, and isolation-address tests.	Management paths are redundant and endpoints are reachable.	Correct VLAN, routing, uplink, or switch faults.
Events and alarms	Recent tasks, events, alarms, and configuration issues.	No unresolved HA or capacity warnings remain.	Resolve or document each warning before relying on HA.
Recovery test	Approved test record and HA events.	A noncritical VM or isolated test host restarts as expected.	Review failure classification, priority, dependencies, capacity, storage, and destination compatibility.

When policy permits, test with a noncritical workload or isolated test host. Confirm the expected restart destination, ordering, storage access, guest boot, and application recovery. Do not perform an uncontrolled host failure test on production workloads.

Troubleshooting

HA Cannot Be Enabled or Hosts Show Configuration Errors

Check vCenter tasks and events for HA-agent deployment errors.
Verify host connectivity to vCenter and between management interfaces.
Check DNS, name resolution, time synchronization, certificates, licensing, and host compatibility as applicable.
Confirm each host can access required datastores and has healthy management interfaces.

Admission Control Blocks a VM Power-On

Review the selected host-failure tolerance and current failover capacity.
Identify high CPU or memory reservations, oversized VMs, uneven host capacity, and fragmentation.
Add capacity, rebalance workloads, adjust justified reservations, or revise the policy through approved change control.

Do not simply disable admission control to remove the warning unless the resulting loss of recovery assurance is explicitly accepted.

Unexpected Isolation or Partition State

Inspect management-network redundancy, VLANs, routes, uplinks, and physical or virtual switch failures.
Validate isolation-address reachability from the affected ESXi host.
Review datastore heartbeat availability and determine whether the condition is isolation, partition, or complete host failure.
Check the isolation response because an incorrect choice can cause unnecessary shutdowns or duplicate VM execution.

Datastore Heartbeat Warnings

Confirm selected datastores are mounted and reachable by the intended hosts.
Review storage paths, shared-storage connectivity, and array health.
Allow automatic selection or manually select suitable shared datastores where supported.

VM Monitoring Resets or Misses a VM

Verify VMware Tools installation, version, status, and guest heartbeat behavior.
Review sensitivity, reset thresholds, and reset limits.
Check guest CPU and I/O contention and the workload's normal pause behavior.
Consider application-level monitoring when guest heartbeats do not represent service health.

VMs Do Not Restart as Expected

Review HA events to determine whether HA classified the condition as failure, isolation, or partition.
Verify restart priority, dependencies, admission-control capacity, datastore availability, and destination-host compatibility.
Confirm the test did not leave the source host capable of continuing to run the VM.

Operational Limitations and Ongoing Care

HA does not protect against every storage failure, vCenter Server failure, split-brain condition, guest failure, or application failure in the same way.
HA usually requires a VM restart, so expect downtime and validate service recovery time.
Network isolation can leave a host running while other hosts believe recovery is needed. Isolation-response selection, redundant networking, and heartbeat evidence reduce this risk but cannot eliminate all ambiguity.
Continue using backups, replication, application resilience, and disaster-recovery planning.
Monitor alarms and events, review capacity after workload changes, and periodically retest documented recovery expectations.

For related planning, compare admission-control policies, review admission control concepts, and maintain appropriate vSphere alarms.

Exam-Relevant Notes

HA detects failures and restarts VMs; vMotion moves running VMs, DRS balances resources, and Fault Tolerance provides a distinct continuous-protection design.
Host Monitoring concerns host and management-network failure response. VM Monitoring concerns guest responsiveness through VMware Tools.
Datastore heartbeating is an additional host-state signal, not a replacement for redundant management networking.
Admission control protects restart capacity but can block power-on operations.
Restart priority changes ordering; it does not create resources or guarantee application readiness.
Advanced HA settings are version-dependent and should be changed only for a documented requirement.