Enable vSphere HA for Automatic VM Restart After Host Failure

Problem and Takeaway

When an ESXi host fails or loses management connectivity, powered-on virtual machines become unavailable until manually restarted elsewhere. vSphere High Availability (HA) solves this by automatically restarting those VMs on surviving cluster hosts. The key takeaway: enable HA at the cluster level, configure admission control to reserve failover capacity, and verify that VMs show a Protected status before you rely on it.

Prerequisites

• vCenter Server managing a cluster of ESXi hosts (version 7.0 or later assumed).
• Shared datastore storage (VMFS, NFS, vSAN, or VVols) accessible to every host in the cluster. VMs must reside on this shared storage.
• Working management network with consistent DNS and reverse DNS resolution across all hosts.
• Valid vSphere license that includes HA entitlement (Standard, Enterprise Plus, or equivalent).
• Administrator or Cluster Administrator role in vCenter to modify cluster availability settings.

Procedure: Enable and Configure vSphere HA

1. Open Cluster Availability Settings

In the vSphere Client, navigate to Hosts and Clusters, select the target cluster, then choose Configure > vSphere Availability. Click Edit next to vSphere HA.

2. Turn On vSphere HA and Host Monitoring

• Check Turn on vSphere HA.
• Check Turn on Host Monitoring so the cluster actively monitors host health via the management network.

3. Choose an Admission Control Policy

Admission control reserves capacity so that VM restarts are guaranteed after a host failure. Select one of the following:

• Host failures the cluster tolerates (recommended for most clusters): specify an integer, e.g., 1. vCenter calculates required CPU and memory reservations based on the largest host.
• Percentage of cluster resources reserved as failover spare capacity: set a percentage (e.g., 25%) of total cluster CPU and memory.
• Dedicated failover hosts: designate specific hosts that remain idle until needed. Use only when you have spare licensed hosts.

Example: For a 4-host cluster where each host has 512 GB RAM and 128 CPU cores, choosing Host failures the cluster tolerates = 1 reserves roughly 25% of aggregate resources. If you power on a VM that would exceed the remaining unreserved capacity, vCenter blocks the operation with an Insufficient resources to satisfy configured failover level error.

4. Set VM Restart Priority

Under VM Monitoring (not to be confused with VM Component Protection), set VM Restart Priority for each VM or use the cluster default:

• High: restarts first, within 30 seconds of host failure detection.
• Medium (default): restarts after high-priority VMs.
• Low: restarts last.
• Disabled: VM is not restarted by HA.

Assign High to business-critical workloads (databases, load balancers). Leave development VMs at Low or Disabled.

5. Configure Host Isolation Response (Optional but Important)

Under Host Isolation, set Host Isolation Response to Power off and restart VMs (default) or Shut down and restart VMs if you prefer a graceful guest shutdown attempt. Define an Isolation Address (e.g., the management gateway IP) that HA pings to distinguish a network partition from a host failure. If the isolation address is unreachable but the host can still reach other hosts, HA treats it as isolation and triggers the response.

6. Apply and Verify

Click OK. vCenter pushes the HA agent (FDM) to each host. Wait until the cluster summary shows vSphere HA: Enabled with a green checkmark.

Expected Checks and Verification

Cluster-Level Health

1. Go to Cluster > Monitor > vSphere HA > Summary.
2. Confirm Current Failover Capacity meets or exceeds the configured tolerance (e.g., shows "1 host failure" tolerated).
3. Check HA Agent State for each host: all should be Connected.

VM Protection Status

In Cluster > Monitor > vSphere HA > Virtual Machines, verify that target VMs list Protected in the HA State column. VMs on local storage or with Restart Priority = Disabled will show Not Protected.

Functional Test: Simulate Host Failure

Permissions required: Host > Maintenance mode operations on the test host.

1. Power on a test VM (e.g., test-vm-01) on Host A. Confirm it shows Protected.
2. Right-click Host A > Maintenance Mode > Enter Maintenance Mode. Select Ensure accessibility or Migrate powered-off VMs as appropriate.
3. Observe Recent Tasks: HA should initiate a restart of test-vm-01 on another host within the configured timeout (default 15 minutes for host failure detection, plus restart priority ordering).
4. After restart, verify the VM runs on a different host and shows Protected again.

Risk: If admission control is misconfigured, the test VM may fail to restart with Insufficient resources. This is expected behavior—admission control is doing its job.

Recovery Options

Failed Host Returns

When the failed host recovers, reconnect it to vCenter. The HA agent will rejoin the cluster automatically. If the agent state appears stale (Disconnected or Error), remove the host from the cluster and re-add it to force a clean agent installation.

Unwanted Restarts During Maintenance

If you need to perform host maintenance without triggering HA restarts, temporarily set Host Monitoring to Disabled in the cluster HA settings, or set the specific VM's Restart Priority to Disabled. Re-enable after maintenance.

False Isolation Events

If hosts incorrectly report isolation (causing unnecessary VM restarts), verify the Isolation Address is reachable from all hosts and that the management network has no partitioning. Adjust the isolation address to a highly available gateway or add multiple isolation addresses (advanced setting das.isolationaddress).

Limitations and Cautions

• Guest OS crashes are not covered: HA only restarts VMs after host failure, isolation, or loss of management connectivity. For guest-level protection, enable VM Monitoring (separate from HA) which monitors VMware Tools heartbeats.
• Admission control can block legitimate power-on operations in overcommitted clusters. Monitor Current Failover Capacity and adjust the tolerance or add hosts if capacity is consistently insufficient.
• Incorrect isolation address causes false positives: A single unreachable gateway can make HA think a host is isolated, triggering mass VM restarts. Use multiple isolation addresses or a dedicated HA network.
• HA is not a backup: It does not protect against datastore corruption, storage array failure, or site-wide outages. Combine with backups and, for site resilience, vSphere Replication or SRM.

Practical Verification Checklist

Run the restart test quarterly or after any cluster topology change (host add/remove, storage changes, network reconfiguration). Document the observed restart time for each priority tier to validate SLAs.