VMware ESXi and vSphere Cluster Management
Configure Host Monitoring in vSphere HA
Learn how vSphere HA Host Monitoring detects ESXi host failures and isolation, and how to configure VM restart priority and Host Isolation Response.
Host Monitoring is a cluster-level vSphere HA setting that helps vCenter Server and the HA master detect ESXi host failures and management-network isolation. It also determines whether HA can take the associated recovery actions.
This lesson covers the monitoring process, configuration workflow, VM restart priority, Host Isolation Response, planning, and validation. Menu names can vary slightly between vSphere versions, but the settings and concepts are consistent.
Purpose of Host Monitoring in vSphere HA
vSphere HA is a vSphere availability feature that monitors cluster hosts and can restart affected virtual machines after an ESXi host failure. Host Monitoring enables HA to monitor participating ESXi hosts through HA agent communication.
Each ESXi host in an HA-enabled cluster runs an HA agent. The HA agents exchange information over the ESXi management network. The management network is used for host administration and for HA communication between hosts.
The HA master is the HA cluster role responsible for coordinating monitoring and recovery decisions. When a host becomes unreachable, the HA master evaluates available information and determines whether virtual machines should be restarted on other hosts. When a host remains powered on but loses management connectivity, HA evaluates the condition as possible host isolation and applies the configured isolation policy.
Host Monitoring is configured at the cluster level. Its setting affects ESXi hosts participating in that vSphere HA cluster; it is not an independent per-VM monitoring switch.
How HA Detects Host Conditions
HA agent heartbeats
A network heartbeat is regular communication exchanged by HA agents across management-network connectivity. Successful heartbeats help HA verify that a host is reachable and participating in the cluster.
Missed heartbeats do not automatically prove that an ESXi host has failed. They indicate that the HA master should investigate a possible host failure, a management-network problem, or another communication fault. HA uses heartbeat-based monitoring along with other cluster information to make recovery decisions.
Host failure versus host isolation
A host failure is a condition in which an ESXi host is no longer operational or cannot be contacted by the HA cluster. Its running VMs may no longer be executing, so HA can attempt to restart them on other hosts.
Host isolation is different: the ESXi host continues running, but it loses management-network communication with the HA cluster. Its VMs may still be running. HA must therefore consider the risk that the isolated host and another host could both run instances of the same workload.
| Condition | ESXi host state | Management network state | HA concern | Relevant setting |
|---|---|---|---|---|
| Normal operation | Running | Connected to the cluster | Continue normal monitoring and workload operation | Host Monitoring and normal HA policy |
| Host failure | Failed, powered off, or unreachable | Unavailable from the cluster | Determine whether affected VMs need recovery elsewhere | Host Monitoring, restart priority, and Admission Control |
| Host isolation | Still running | Management communication to the cluster is lost | Prevent unsafe continued execution or duplicate VM execution | Host Isolation Response |
| Planned maintenance-related interruption | May be running or intentionally serviced | Intentionally interrupted | Avoid treating planned work as an unexpected failure or isolation event | Temporarily review or disable Host Monitoring when appropriate |
Enabling or Disabling Host Monitoring
vSphere Client workflow
- Select the vSphere HA-enabled cluster.
- Open the cluster Configure or Settings area.
- Locate the vSphere HA settings and the Host Monitoring section.
- Enable or disable Host Monitoring as required by the operational procedure.
- Set the cluster default VM restart priority.
- Configure the Host Isolation Response.
- Open VM Overrides to apply a different restart priority to an individual VM when needed.
- Review the complete HA configuration and save the changes.
Effect of enabling Host Monitoring
When Host Monitoring is enabled, HA agents participate in host monitoring and heartbeat communication. The HA master can use this information to identify likely host failures or isolation conditions and initiate the associated recovery behavior.
When to disable monitoring
Host Monitoring may be temporarily disabled before planned ESXi maintenance or planned work that will interrupt management-network connectivity. Disabling it can prevent HA from interpreting intentional communication loss as an unexpected host failure or isolation event.
This is an availability trade-off. While Host Monitoring is disabled, HA does not monitor hosts through this mechanism and does not initiate the associated host-failure recovery behavior. The change should be planned, documented, and limited to the maintenance window. Re-enable monitoring after management connectivity and HA agent communication have been confirmed.
VM Restart Priority
VM restart priority is the relative order vSphere HA uses when restarting workloads after an ESXi host failure. It does not guarantee an absolute recovery time or a perfectly strict completion sequence. Resource availability, datastore access, guest startup behavior, and dependencies can affect the actual result.
Assign higher priority to more critical virtual machines and lower priority to less important workloads. For example, an application VM may need to start before reporting, test, or batch-processing VMs.
Cluster default
The cluster default is the restart-priority setting applied to VMs unless an individual VM Override changes it. Using a sensible default for most workloads makes the cluster easier to administer.
VM Overrides
A VM Override is a per-virtual-machine HA configuration that replaces the cluster default for the selected VM. Use overrides for documented exceptions rather than configuring every VM independently without a clear reason.
If a VM has an override, that VM uses the override instead of the cluster default. Selecting Disabled for the VM restart priority means HA does not restart that VM on another ESXi host after a host failure.
| Workload category | Suggested relative priority | Reasoning | Use of VM Override |
|---|---|---|---|
| Business-critical VM | High | Return essential services before less important workloads | Use when the cluster default is lower or when the application has special recovery requirements |
| Standard production VM | Medium | Recover normal production services after the highest-priority workloads | Often no override is needed if Medium is the cluster default |
| Noncritical VM | Low | Preserve capacity for more important services first | Use to lower the priority of a VM from a higher cluster default |
| VM requiring manual recovery | Disabled | Prevent automatic restart when a controlled or manual procedure is required | Use only when the exclusion is intentional, documented, and regularly reviewed |
Example: default with an exception
Suppose the cluster default is Medium for normal workloads. A business-critical application VM can receive a VM Override of High, while a noncritical test VM can receive an override of Low. A VM governed by a manual recovery procedure can receive Disabled.
The result is a relative recovery plan: the critical application is selected before the test VM when resources and other conditions permit. The priority does not guarantee that the critical VM will finish starting before every other VM or that it will recover within a particular number of seconds.
Host Isolation Response
Host Isolation Response determines what an isolated ESXi host does with VMs that continue to run on it. An isolated host is still powered on but has lost management-network communication with the HA cluster.
Available choices depend on the vSphere version and configuration. Common choices include:
- Leave powered on: Keep VMs running on the isolated host. This may preserve service when the host can continue operating safely, but it can increase the risk of duplicate VM execution if HA later starts the same workloads elsewhere.
- Power off: Power off the VMs on the isolated host so HA can restart them elsewhere, when the environment and recovery policy support that behavior.
- Shut down: Request a guest operating system shutdown where VMware Tools, guest configuration, and the VM workload support graceful shutdown. This can reduce abrupt power-off effects but may take longer or fail if guest tools are unavailable.
The correct choice depends on shared-storage accessibility, management and VM network design, network redundancy, VM criticality, and the organization’s recovery policy. It must also account for the possibility that an isolated host can still access storage and continue running workloads.
Isolation response and VM restart priority solve different problems:
- Host Isolation Response controls what happens to VMs on a host that remains running but is isolated from the HA cluster.
- VM restart priority controls the relative ordering of VM restarts on other hosts after HA determines that a host failure requires recovery.
Host Monitoring Configuration Elements
| Setting | Purpose | Scope | Operational impact |
|---|---|---|---|
| Host Monitoring enabled or disabled | Allow or stop HA host monitoring through agent heartbeats | Cluster | Controls whether HA can use this monitoring mechanism for host-failure and isolation decisions |
| VM restart priority | Define the relative recovery order for VMs | Cluster default or individual VM | Influences which workloads HA attempts to restart first after host failure |
| Cluster default priority | Provide the restart priority for VMs without overrides | Cluster | Simplifies administration for the majority of workloads |
| VM Override | Replace the cluster default for a selected VM | Individual VM | Supports justified exceptions such as High, Low, or Disabled priority |
| Host Isolation Response | Define the action for VMs on an isolated host | Cluster policy applied to isolated hosts | Balances service continuity against duplicate-execution and split-brain risk |
Configuration Planning
- Classify workloads as business-critical, standard production, noncritical, or intentionally excluded from automatic HA restart.
- Choose a cluster default restart priority that fits most VMs.
- Document each VM Override, including the owner, reason, and review date.
- Set Disabled only for workloads with a deliberate manual recovery process.
- Choose an isolation response after reviewing storage accessibility, network redundancy, VM criticality, and application recovery requirements.
- Coordinate the plan with Admission Control. Admission Control reserves enough cluster capacity to support VM restart after a host failure; restart priorities cannot compensate for insufficient available capacity.
- Review Host Monitoring before planned maintenance that affects ESXi management connectivity.
- Restore the intended monitoring state after maintenance and confirm that HA is healthy.
Validation and Testing
After saving the configuration, review the cluster’s HA health, configuration tasks, events, and alarms. Confirm that the intended cluster default, VM Overrides, Host Isolation Response, and Host Monitoring state are present.
Validate recovery behavior with an approved nonproduction or controlled procedure. A useful test plan records the expected condition, the VMs that should restart, their relative priorities, the expected isolation action, available capacity, datastore access, and the evidence collected from HA events.
Do not use an uncontrolled management-network interruption or unexpected host power-off as a first test in production. Coordinate testing with application owners and operations staff.
Troubleshooting Common Problems
A VM did not restart after an ESXi host failure
- Verify that vSphere HA and Host Monitoring were enabled for the cluster.
- Check whether the VM restart priority was Disabled through the cluster default or a VM Override.
- Review HA events and alarms for host-failure detection and the recovery decision.
- Confirm that sufficient cluster capacity was available under Admission Control and the current resource state.
- Check datastore accessibility and other conditions required for the VM to power on.
HA behavior occurred during planned management-network maintenance
- Confirm whether Host Monitoring remained enabled while management connectivity was intentionally interrupted.
- Check whether the maintenance procedure includes temporarily disabling Host Monitoring when appropriate.
- Restore management networking and verify HA agent communication.
- Re-enable Host Monitoring and confirm the cluster reports a healthy HA state.
An isolated host did not handle VMs as expected
- Review the configured Host Isolation Response.
- Determine whether the condition was host isolation rather than a complete host failure.
- Check management-network connectivity, redundancy, VLAN configuration, and physical network health.
- Review shared-storage reachability and VM network architecture before changing the isolation policy.
- Confirm whether guest tools and guest shutdown configuration support a graceful shutdown response.
A lower-importance VM restarted before a critical VM
- Review the cluster default restart priority.
- Check VM Overrides for both VMs.
- Confirm that assignments match the current application dependency plan.
- Remember that relative priority is not an absolute completion sequence; capacity, startup conditions, and dependencies can change observed order.
Exam-Relevant Notes
- Host Monitoring is a cluster-level vSphere HA setting.
- HA agent network heartbeats use management-network connectivity to help detect reachability problems.
- A failed host is not the same as an isolated host: a failed host is unavailable, while an isolated host remains running but cannot communicate with the HA cluster.
- Host Isolation Response controls VM behavior on the isolated host.
- VM restart priority controls relative restart ordering after a host failure.
- A VM Override takes precedence over the cluster default for that VM.
- Disabled VM restart priority prevents HA from restarting that VM on another host after host failure.
- Admission Control capacity planning remains important even when restart priorities are configured.
For the related cluster setting, review Host Monitoring configuration while comparing your intended monitoring, restart, and isolation policies.