VMware ESXi and vSphere Cluster Management

Configure Host Monitoring in VMware vSphere HA

Learn how vSphere HA Host Monitoring detects ESXi host failure and isolation, and how restart priority and isolation response affect VM recovery.

Host Monitoring is a cluster-level setting in vSphere HA that helps detect unavailable ESXi hosts and possible management-network isolation. When HA identifies a host failure, it can restart eligible virtual machines on surviving hosts. When a host is still running but isolated from management communication, the configured host isolation response controls what happens to its powered-on VMs.

This lesson covers the relationship among host monitoring, VM restart priority, and host isolation response. It assumes familiarity with vSphere and ESXi fundamentals, vCenter Server, clusters, and virtual machines.

Purpose of Host Monitoring

Host Monitoring enables vSphere HA to watch the health and reachability of ESXi hosts in a cluster. Its availability objective is to help HA determine whether recovery action may be necessary, including restarting protected VMs on other hosts.

A host failure means that an ESXi host is no longer operational or reachable by HA. Its virtual machines may stop running and require recovery elsewhere. Host isolation is different: the ESXi host may remain powered on and its VMs may continue running, but the host has lost management-network communication with other cluster hosts or with the isolation-detection path.

Condition	ESXi host status	Management-network visibility	Possible VM state	Relevant HA policy
Host failure	Not operational or not reachable by HA	Unavailable because the host or its communication path has failed	VMs may stop and need recovery on surviving hosts	Host failure detection and VM restart priority
Host isolation	May still be powered on and executing workloads	Management communication is lost	VMs may continue running, shut down, or power off depending on policy	Host isolation response

How vSphere HA Monitors Hosts

An HA agent is the vSphere HA component running on an ESXi host. HA agents exchange recurring heartbeats across the management network. A heartbeat is an availability signal that helps establish whether cluster hosts remain reachable.

Missed management heartbeats contribute to HA decisions about whether a host may have failed or become isolated. HA does not rely only on a single observation in every situation. Where available, datastore heartbeats provide supplemental evidence through shared datastore access. This information can help distinguish a management-network disruption from a complete host failure.

At a high level, HA evaluates host communication and other available signals before selecting a host state and recovery action. Reliable operation therefore depends on a functioning HA configuration, suitable management-network connectivity between hosts, and appropriate shared datastore heartbeat access where the environment uses it.

Enabling or Disabling Host Monitoring

Host Monitoring is configured at the cluster level in the vSphere HA settings. The normal operational choice is to leave it enabled so HA can detect host failures and perform normal automated recovery for eligible VMs.

Administrators may temporarily disable Host Monitoring during planned ESXi maintenance or planned work on the management network. This can prevent HA from reacting to an expected communication interruption as though it were an unplanned failure.

Disabling Host Monitoring reduces protection during the maintenance window. HA does not perform normal host-failure detection and automated VM recovery while monitoring is disabled. Re-enable it as soon as the work is complete, then verify that hosts and HA report healthy operation. Record temporary changes in the maintenance plan and change records.

VM Restart Priority

VM restart priority is the relative recovery order HA uses after an ESXi host failure. Higher-priority VMs are considered for restart before lower-priority VMs, subject to available resources, placement, admission-control policy, dependencies, and other HA restart conditions.

A cluster has a default restart priority. Individual VMs can have VM overrides, which replace the relevant cluster default for those VMs. An override is useful when one workload needs treatment different from the general cluster policy.

Priority level	Relative restart treatment	Typical workload use	Notes and limitations
Higher priority	Considered earlier than lower-priority VMs	Critical infrastructure, directory services, DNS, authentication, or essential application tiers	Does not guarantee immediate restart or sufficient resources
Medium or standard priority	Uses the cluster's normal recovery order	Ordinary production application VMs	May be overridden for selected VMs
Low priority	Considered after higher-priority workloads	Noncritical, reporting, or easily recoverable workloads	Recovery remains subject to capacity and HA conditions
Disabled	Not restarted by HA on another host after the original host fails	Disposable test VMs or workloads intentionally excluded from HA restart	Other eligible VMs can still be recovered

Restart priority is not a performance setting. It does not control CPU shares, reservations, boot order, or the resources assigned to a VM. It only expresses relative preference during HA restart operations after host failure.

Example: Cluster Default and VM Override

Suppose a cluster default is set to Medium. A noncritical reporting VM has a per-VM override of Low. After an eligible host failure, HA considers the reporting VM after Medium-priority workloads when capacity and other restart conditions permit.

Conversely, a critical DNS or authentication VM can receive a higher priority while ordinary application VMs retain the standard default. This affects relative restart ordering; it does not guarantee that the critical VM will start if surviving hosts lack capacity or if the VM cannot be placed or started.

A disposable test VM can be assigned Disabled. HA will not automatically restart that VM on another host after its original host fails, even if other eligible VMs are recovered.

Host Isolation Response

The host isolation response determines what an isolated ESXi host does with its powered-on VMs after the host concludes that it is isolated. The available response concepts and exact labels can vary by vSphere release, so use the options presented by the vSphere Client version in operation.

Response approach	What occurs on the isolated host	Potential benefit	Primary risk	Suitable considerations
Leave VMs powered on	VMs continue running on the isolated host when possible	Retains workload availability without an immediate local shutdown	HA may later attempt recovery elsewhere, creating duplicate workload risk in some scenarios	Consider for workloads that can safely continue and have strong network or application-level coordination
Power off VMs	The host powers off affected VMs	Allows HA to recover workloads elsewhere without the original instances continuing to run	Causes an abrupt outage and possible guest or application interruption	Consider where avoiding duplicate execution is more important than graceful shutdown
Shut down guest operating systems where supported	The host requests a guest shutdown before or as part of the isolation action	Can reduce filesystem and application disruption compared with an abrupt power-off	Shutdown may take time or fail if the guest does not respond	Requires a functioning guest tools or guest shutdown mechanism and should be tested

Isolation policy involves a trade-off. Leaving VMs running may preserve availability on the isolated host, but it can complicate recovery elsewhere. Powering off or shutting down VMs can make recovery on another host safer, but it interrupts service on the isolated host.

Consider split-brain risk: two instances of the same workload may believe they are authoritative when communication is disrupted. For clustered applications, shared storage, and stateful systems, an inappropriate isolation response can cause competing instances or data-integrity problems. A graceful guest shutdown is not guaranteed if the guest cannot receive or process the request.

How the Three Policies Work Together

HA agents exchange management-network heartbeats and use other available evidence, including datastore heartbeat information where available.
HA evaluates the evidence and determines whether the condition is consistent with a host failure, host isolation, or another state.
If the host is isolated and still running, the host isolation response governs what happens to its local powered-on VMs.
If HA determines that a host has failed, eligible VMs may be restarted on surviving hosts.
VM restart priority influences the relative order in which those eligible VMs are considered.

Restart priority applies to HA restart operations after host failure. Host isolation response governs VM action on a host that is still running but isolated. These settings solve different problems and should not be treated as interchangeable.

A VM marked with restart priority Disabled is not automatically restarted elsewhere after a host failure, even when other VMs on the same failed host are recovered.

Configuration Workflow in the vSphere Client

Select the target cluster in the vSphere Client.
Open the cluster Configure or settings area.
Open the vSphere HA settings and locate Host Monitoring.
Enable Host Monitoring for normal operation, or disable it only when the approved maintenance plan requires monitoring to be suspended.
Set the cluster-level default VM restart priority.
Open VM Overrides and assign a different restart priority to individual VMs when needed. Review whether any VM is intentionally set to Disabled.
Locate and review Host Isolation Response. Select the response that matches the workload, application-cluster, and data-consistency design. Exact labels may vary by vSphere release.
Save the changes.
Confirm that vSphere HA remains enabled, host status is healthy, management-network communication is stable, and the intended policies appear on the cluster and VM settings.

Host Monitoring is separate from HA admission control. Admission control validates or reserves failover capacity; it does not replace host failure monitoring. Review both when planning recovery behavior.

Policy Design Guidance

Assign higher restart priority to essential dependency services such as directory services, DNS, authentication, application tiers, and monitoring components, according to the organization's recovery design.
Use lower priority for noncritical, disposable, or easily recoverable workloads.
Prefer a VM-specific override when most of the cluster should retain the standard policy and only a small number of VMs need different treatment.
Choose the isolation response with application clustering, shared storage behavior, management-network resiliency, and data-consistency requirements in mind.
Do not assume that one isolation response is appropriate for every workload. A stateless application and a stateful database may require different decisions.
Test failure and isolation behavior in a controlled environment before relying on policy changes in production.
Document temporary Host Monitoring changes and restore the normal setting immediately after planned work.

For broader cluster availability planning, compare these settings with vSphere HA admission-control policies, advanced HA options, and the design of communication between vCenter Server and ESXi.

Planned Management-Network Maintenance

Stage	Action	Reason	Validation
Before maintenance	Review the change plan, affected hosts, HA settings, isolation response, and VM overrides.	Identifies recovery and isolation consequences before communication is interrupted.	Confirm the intended cluster and maintenance scope.
Preparation	Temporarily disable Host Monitoring at the appropriate cluster scope if the approved plan requires it.	Reduces unwanted HA failure or isolation handling during expected disruption.	Verify the setting is disabled and record the change.
Maintenance	Perform the ESXi or management-network work.	Completes the planned change while HA monitoring is intentionally suspended.	Check VM state, host connectivity, VLANs, uplinks, routing, and switch status.
Restoration	Restore management connectivity and re-enable Host Monitoring immediately afterward.	Returns normal HA protection.	Confirm HA is enabled, hosts are healthy, and heartbeats are working.
Aftercare	Review events and update the change record.	Provides evidence that the cluster returned to its intended policy.	Verify no temporary setting remains active.

Troubleshooting

A VM Was Not Restarted After a Host Failure

Verify that vSphere HA and Host Monitoring were enabled before the event.
Check whether the VM had a restart-priority override set to Disabled.
Review HA events to determine whether HA detected a host failure.
Check surviving-host resources, admission-control status, placement constraints, dependencies, and VM startup errors.

A Host Appears Isolated After Management-Network Changes

Verify management VMkernel connectivity, VLAN configuration, uplinks, routing, and physical-switch state.
Confirm that HA heartbeat communication is possible between cluster hosts.
Review HA events and datastore heartbeat availability to distinguish network isolation from actual host failure.
Confirm that a temporary Host Monitoring change made for maintenance was restored correctly.

A VM Shut Down or Powered Off During a Network Incident

Review the configured host isolation response.
Determine whether the ESXi host was isolated rather than failed.
If guest shutdown was selected, verify that the guest can receive and process shutdown requests through the available guest mechanism.
Assess whether the policy matches the workload's data-integrity and availability requirements.

Critical VMs Do Not Recover Before Less Important VMs

Verify the cluster default restart priority and every relevant per-VM override.
Confirm that the critical VM is eligible for HA restart.
Check resource availability, dependencies, startup failures, placement constraints, and HA event history.
Remember that restart priority is relative ordering, not an absolute recovery-time guarantee.

HA Behavior Remains Suppressed After Maintenance

Confirm whether Host Monitoring is still disabled.
Review change records and the cluster HA settings.
Validate management-network stability and host health, then re-enable monitoring.

Exam-Relevant Notes

Host Monitoring is a cluster-level vSphere HA control for detecting host failure and possible isolation.
HA agents exchange management-network heartbeats; datastore heartbeats can provide supplemental evidence where available.
Host failure and host isolation are not the same condition.
Restart priority controls relative HA restart order after host failure, not performance, resource reservations, or guaranteed boot order.
A VM override takes precedence over the cluster default for that VM.
Disabled restart priority excludes the VM from automatic HA restart elsewhere after host failure.
Host isolation response controls what an isolated, still-running host does with its VMs.
Disabling Host Monitoring reduces HA protection and should be temporary, documented, and followed by prompt re-enablement.