VMware ESXi and vSphere Cluster Management

Enable and Configure vSphere HA on an Existing Cluster

Learn how to enable vSphere HA on an existing vCenter cluster, configure monitoring and admission control, and validate host failover readiness.

vSphere High Availability (HA) detects failures affecting ESXi hosts and automatically restarts impacted virtual machines on surviving hosts. This lesson explains how to enable HA on an existing cluster through vCenter Server and how to choose the main HA settings.

The exact labels and layout can vary between vSphere releases, but the workflow and configuration concepts remain similar.

What vSphere HA Does

An ESXi host is a physical virtualization server. A cluster is a group of ESXi hosts managed together by vCenter Server. When vSphere HA is enabled, vCenter Server configures an HA agent on participating hosts. The agents exchange status information and help determine whether a host or virtual machine has failed.

After a host failure, HA uses the surviving hosts and available datastore access to register and power on affected VMs elsewhere. HA therefore provides automated VM restart, not continuous execution of the VM during the failure.

Host failure recovery: Restarts VMs after an ESXi host stops functioning.
Guest or application recovery: Detects selected unresponsive VMs using VMware Tools and may restart them. Application-specific monitoring is still needed for problems that do not stop guest heartbeats.
Workload balancing: Distributes workloads to improve resource utilization. This is a different function from HA and should not be confused with workload-balancing features such as DRS.

HA does not provide zero downtime, continuous application availability, or protection against every guest operating system and application problem.

Requirements Before Enabling HA

Prepare the cluster before changing its settings. HA configuration depends on reliable management communication, storage visibility, correct host configuration, and enough capacity to restart workloads.

An existing cluster managed by vCenter Server with connected ESXi hosts.
Working management-network connectivity between all hosts and vCenter Server.
Correct DNS name resolution and consistent time synchronization. Host and vCenter clock differences can interfere with management and agent configuration.
Shared or otherwise accessible datastores suitable for the VMs and for datastore heartbeating.
Enough CPU, memory, and storage capacity on surviving hosts to restart workloads after the planned number of host failures.
Compatible licensing, permissions, and vCenter privileges for editing cluster settings.
Healthy ESXi hosts, management services, storage paths, and network configuration.
A documented plan for VM restart priorities, dependencies, isolation response, and admission-control behavior.

Also account for dependencies such as DNS, storage, networking, and vCenter Server. A cluster may be correctly configured for HA yet still have a poor recovery outcome if essential infrastructure services are unavailable.

Ways to Enable vSphere HA

During cluster creation: Select the HA option while creating a new cluster and configure the initial policies.
After cluster creation: Edit the settings of an existing cluster and enable vSphere HA. This is the procedure covered here.

Enable HA on an Existing Cluster

Select the target cluster in the vSphere Client inventory.
Open the cluster management or settings area.
Locate the vSphere HA configuration section and choose to edit the cluster settings.
Enable the vSphere HA service.
Review the available HA options before saving. At minimum, review host monitoring, admission control, VM Monitoring, and datastore heartbeating.
Change specialized settings only when the design requires it. Record every nondefault value and its reason.
Save the cluster configuration.
Allow vCenter Server to apply the HA configuration to every host. Do not assume that clicking Save means all hosts have completed configuration.
Verify that HA is enabled at the cluster level and that each host completes HA agent configuration with a healthy status.

An HA agent is the host-level component used for cluster membership, heartbeat, and failure-detection functions. If one or more hosts cannot receive the agent configuration, resolve that issue before treating the cluster as protected.

Main vSphere HA Settings

Setting	What It Monitors or Controls	Primary Benefit	Key Configuration Consideration
Host Monitoring	Host availability using management-network heartbeats	Detects host failure and supports VM restart on surviving hosts	Management networking and isolation behavior must be reliable
Admission Control	Capacity reserved or validated for host failure recovery	Protects failover capacity before additional VMs are powered on	Stronger protection can prevent power-on operations when capacity is limited
VM Monitoring	VMware Tools heartbeats and, where configured, guest activity	Can restart an unresponsive VM even when its host remains available	Requires healthy VMware Tools and suitable sensitivity and restart behavior
Datastore Heartbeating	Host liveness through shared datastore signals	Provides an additional signal during management-network communication loss	Hosts need consistent access to suitable shared datastores
Advanced Options	Specialized behavior such as isolation addresses and minimum CPU-related values	Supports documented, unusual designs	Leave defaults unchanged unless the impact is understood and tested

Host Monitoring

Host Monitoring uses heartbeats over the management network. These signals help HA determine whether an ESXi host is responding and participating in the cluster.

When a host stops responding, HA evaluates the available evidence before deciding whether the host has failed, is isolated, or is separated by a network partition. If HA determines that a host failure has occurred, it can restart the host's affected VMs on other hosts, subject to capacity and policy.

Host isolation is different from complete host failure. In an isolation event, the host may still be running VMs but cannot communicate over the management network. Restarting those VMs elsewhere while they are still running can create conflicts, so the configured isolation response and additional heartbeat evidence are important.

Admission Control

Admission Control reserves or validates enough cluster capacity to tolerate the configured number of host failures. It evaluates whether a new VM power-on or migration would consume capacity needed for recovery.

Common policy concepts include:

Host failures to tolerate: The cluster reserves capacity for one or more host failures.
Percentage of cluster resources reserved: A percentage of CPU and memory remains available for failover.
Dedicated failover hosts or other policy models: The policy identifies where recovery capacity should come from.
Slot-based considerations: In applicable configurations, a slot represents the resource requirement used to estimate how many VM placements can be restarted. Large or uneven VM sizes can make slot calculations appear conservative.

The trade-off is operationally important: stronger failover protection can limit powering on additional VMs. If admission control is disabled, workloads may be admitted even when guaranteed restart capacity does not exist. Disabling it should be an explicit, documented risk decision, not a workaround for ordinary capacity pressure.

VM Monitoring

VM Monitoring evaluates VMware Tools heartbeats and, depending on the configured behavior, guest activity signals. VMware Tools is software installed in the guest operating system that supplies integration and heartbeat information to the virtualization layer.

When a VM stops responding, HA can use an escalation process: detect missing heartbeats, wait according to the selected sensitivity or threshold, and restart the VM if it remains unresponsive. The exact response depends on the VM Monitoring policy and the vSphere version.

VMware Tools must be installed, running, and healthy for meaningful guest heartbeat monitoring. VM Monitoring is different from host-level HA recovery: host HA reacts when the ESXi host fails or becomes isolated, while VM Monitoring can react to an unresponsive guest while the host itself remains operational.

VM Monitoring cannot reliably identify every application failure. An application may be unhealthy while the guest operating system and VMware Tools continue sending heartbeats. Use application-level monitoring when service health must be measured directly.

Datastore Heartbeating

Datastore Heartbeating provides an additional host-liveness signal through shared datastores. During a management-network communication loss, HA can use datastore heartbeat information to help determine whether a host is still alive.

This evidence helps distinguish a genuinely failed host from management-network isolation or a network partition. Automatic datastore selection normally chooses suitable shared datastores visible to the hosts. Verify that the selected or eligible datastores have consistent visibility and reliable storage connectivity across the cluster.

Missing or inaccessible heartbeat datastores reduce HA's confidence when classifying a failure state. They do not replace the management network, and they cannot compensate for broad storage failure.

Advanced HA Options

Advanced options are specialized settings. Change them only when a documented design requirement exists, and validate the result in a test environment before applying the design to production.

Isolation addresses: Network destinations that a host tests to help determine whether it is isolated from the management network. The addresses should be reachable according to the intended design and should not create misleading results.
Minimum CPU-related settings: Values that influence whether a VM is considered viable for restart in constrained situations. These settings can affect restart decisions when available resources are limited.

Document the value, purpose, expected behavior, owner, and rollback plan for every nondefault advanced setting. Incorrect isolation-address or resource-threshold choices can produce incorrect failure-state decisions or unexpected recovery behavior.

Failure States and Recovery Behavior

Condition	Typical Symptoms	Relevant Detection Signals	Possible HA Outcome
Complete host failure	Host is powered off, crashed, or otherwise unavailable	Missing management heartbeats, datastore heartbeat evidence, host events	Restart affected VMs on surviving hosts if capacity and policies permit
Management network isolation	Host may continue running but cannot communicate with cluster management	Management heartbeats, isolation-address checks, datastore heartbeats	Isolation response may be applied; VM restart depends on the determined state and policy
Network partition	Parts of the cluster cannot communicate with one another	Different heartbeat views, management paths, and datastore evidence	HA behavior depends on which hosts appear active and how the state is resolved
Guest operating system or VM failure	VM or guest becomes unresponsive while its ESXi host remains available	VMware Tools heartbeats and guest activity signals	VM Monitoring may restart the VM after its threshold is reached

An isolation event does not always mean the host has failed. The host could be running normally but disconnected from management communication. Recovery actions depend on the failure state, isolation response, restart priority, admission-control policy, datastore access, and available capacity.

Post-Configuration Validation

Use this checklist after saving the cluster settings:

Check	Why It Matters	How to Validate
Cluster hosts connected	All intended hosts must participate in HA	Review the cluster host list and connection state in the vSphere Client
Management network connectivity	HA relies on management communication for primary heartbeats	Check host networking, VLANs, routing, DNS, and communication status
Shared datastore accessibility	Supports VM access and datastore heartbeat evidence	Confirm suitable datastores are visible and healthy on the intended hosts
Available failover capacity	Restarted VMs need CPU, memory, storage, and network resources	Review admission-control status, reserved capacity, and current utilization
HA agent health	Each host needs a functioning HA agent	Review host HA status, configuration tasks, alarms, and events
VMware Tools for VM Monitoring	Guest heartbeats require a functioning Tools component	Review VMware Tools status for protected VMs

Review HA alarms, cluster events, configuration issues, datastore heartbeat status, and admission-control warnings. A controlled failover test should be performed only under an approved maintenance and recovery plan with appropriate stakeholders informed.

Operational Cautions

Do not enable or test HA without understanding VM restart priorities, application dependencies, and available failover capacity.
Use approved change procedures when altering production clusters or hosts.
Place hosts into maintenance mode when a planned operation requires workloads to move or stop, and confirm the operation's effect on HA capacity.
Document isolation response, restart priority, admission-control decisions, datastore heartbeat design, and advanced values.
Ensure essential infrastructure services, including DNS, storage, networking, and vCenter dependencies, have their own availability plan.
Remember that HA restarts VMs after a failure; it does not preserve in-memory application state or provide zero downtime.

Troubleshooting Common Problems

HA Cannot Be Enabled or Host Configuration Does Not Complete

Likely causes include host connectivity problems, DNS or time-synchronization errors, an ESXi agent or service issue, insufficient permissions or licensing, or an inconsistent cluster configuration.

Review cluster tasks, recent events, alarms, and HA configuration messages.
Confirm every host is connected to vCenter and has healthy management networking.
Check DNS resolution, NTP or time consistency, and host service health.
Resolve the underlying host issue, then retry HA configuration.

Admission Control Blocks a VM Power-On

The requested operation may consume capacity reserved for failover, the failure-tolerance policy may be conservative for the available resources, or cluster usage may have increased.

Review the admission-control policy and current failover capacity.
Consider adding capacity or reducing workload before changing the policy.
If the policy must change, document the resulting recovery risk. Do not bypass protection merely to complete a routine power-on.

A Host Is Reported as Isolated Instead of Failed

Check for a management-network outage, incorrect VLAN, routing, gateway, or isolation-address configuration, or a partial network partition.

Verify redundant management-network paths and their reachability.
Review configured isolation addresses and test whether affected hosts can reach them as designed.
Use datastore heartbeat status and host events to determine whether the host remained alive.

VM Monitoring Does Not Restart an Unresponsive Guest

VM Monitoring may be disabled, VMware Tools may be missing or unhealthy, thresholds may not match the failure behavior, or the issue may be application-specific while guest heartbeats continue.

Confirm VM Monitoring is enabled and applies to the VM.
Check that VMware Tools is installed, running, and healthy.
Review VM and HA events and the monitoring sensitivity or restart thresholds.
Use application-level monitoring for failures that guest heartbeats cannot detect.

Datastore Heartbeating Is Unavailable

Common causes are inconsistent shared-datastore visibility, storage path failures, or a datastore accessibility problem.

Confirm that suitable shared datastores are visible to all intended hosts.
Review storage paths and datastore health.
Verify datastore heartbeat selection and examine related cluster events.

Practical Design Examples

Two- or Three-Host Production Cluster

Enable HA at the cluster level, retain host monitoring, and select an admission-control policy that reserves enough capacity for one host failure. Verify that every host receives a healthy HA configuration and that the remaining hosts can restart the required workloads.

Cluster With Limited Spare Capacity

Use admission control to prevent additional VM power-ons when they would remove the capacity needed to restart priority workloads. If the policy blocks normal operations, address capacity or workload placement rather than silently removing the protection.

Apparent Host Loss Caused by a Management Network Problem

Compare management heartbeat status, datastore heartbeat evidence, isolation-address reachability, and host events. This combination helps distinguish a failed host from an isolated host or a network partition.

Unresponsive Guest Operating System

For supported VMs with healthy VMware Tools, enable VM Monitoring and choose a sensitivity and recovery behavior appropriate to the workload. Test carefully because an unnecessary restart can interrupt an application that is slow but still making progress.

Summary

vSphere HA is enabled and configured at the cluster level through vCenter Server. Before enabling it, verify host connectivity, management networking, DNS, time, licensing, permissions, datastore visibility, host health, and failover capacity. After enabling HA, review host monitoring, admission control, VM Monitoring, datastore heartbeating, and any advanced options. Finally, confirm healthy HA agents, sufficient admission-control capacity, VMware Tools status where required, and a clean set of cluster events and alarms.

For this procedure, return to Enable and Configure vSphere HA when reviewing the cluster-level workflow.