VMware ESXi and vSphere Cluster Management

VM Monitoring in vSphere HA Explained

Learn how vSphere HA VM Monitoring uses VMware Tools heartbeats and guest disk I/O to detect failed guest operating systems and control automatic VM resets.

VM Monitoring is a vSphere High Availability (vSphere HA) capability that detects when a virtual machine remains powered on but its guest operating system is no longer functioning correctly. When the configured failure condition is met, vSphere HA can reset the VM automatically.

This feature addresses a different failure domain from host protection. Host failure recovery responds when an ESXi host fails or becomes unavailable. VM Monitoring responds when an individual guest operating system fails while its ESXi host continues running.

What VM Monitoring Protects Against

A VM can appear powered on in vCenter even though the operating system inside it is frozen, crashed, or unable to process work. Without guest-level monitoring, the VM may not restart because the ESXi host itself is still healthy.

VM Monitoring helps close this gap. It evaluates guest responsiveness and can reset the affected VM on its current ESXi host. A reset is disruptive: the guest operating system reboots, running processes are interrupted, and applications experience an outage similar to a forced restart.

VM Monitoring: Detects a failed or unresponsive guest operating system and resets its VM on the current host.

vSphere HA host failure recovery: Detects an unavailable ESXi host and restarts affected VMs on other available hosts.

Application-aware monitoring: Detects problems with a particular application or service and may use application-specific recovery actions.

How VM Monitoring Detects a Failure

VMware Tools heartbeats

VMware Tools is software installed in a guest operating system to provide integration and management functions. One of its signals is the VMware Tools heartbeat, a guest-to-host indication that the Tools service and guest environment are responding.

VM Monitoring uses this heartbeat as one indicator of guest health. If the heartbeat stops, the guest may be stalled, VMware Tools may have stopped, or the operating system may be failing. A missing heartbeat alone does not always prove that the VM has failed.

Guest disk I/O activity

Guest disk I/O activity means read or write activity generated by the guest operating system. vSphere HA uses this activity alongside the VMware Tools heartbeat.

The additional I/O signal helps prevent unnecessary resets. For example, VMware Tools might temporarily stop sending heartbeats while the operating system continues processing work and producing disk activity. In that case, the VM is still showing signs of life.

Failure condition

VM Monitoring considers the VM failed when both of these conditions persist for the configured failure interval:

No VMware Tools heartbeat is received.
No guest disk I/O activity is detected.

After that interval expires, vSphere HA can reset the VM. The exact timing and tolerance depend on the selected sensitivity or custom policy.

Heartbeat status: Present. Disk I/O: Present. Duration: Any. Outcome: The VM appears active; VM Monitoring should not reset it based on these signals.

Heartbeat status: Missing. Disk I/O: Present. Duration: Within the failure interval. Outcome: The VM still shows activity, so HA should not treat heartbeat loss alone as a failure.

Heartbeat status: Missing. Disk I/O: Missing. Duration: Less than the failure interval. Outcome: HA continues evaluating the condition.

Heartbeat status: Missing. Disk I/O: Missing. Duration: At least the failure interval. Outcome: VM Monitoring declares the guest unresponsive and can reset the VM.

What vSphere HA Does After Detection

When VM Monitoring detects the configured guest failure condition, vSphere HA automatically resets or restarts the affected VM. This is not the same as host-failure recovery:

The ESXi host is assumed to remain available.
The VM is reset on its current ESXi host.
The VM is not moved to another host as a response to this guest failure.
The guest operating system boots again and applications must restart or recover normally.

A reset may restore service from a transient guest failure, but it does not correct the underlying cause. A defective driver, corrupted operating system component, storage problem, application deadlock, or VMware Tools issue can cause the problem to return.

Prerequisites and Dependencies

vSphere HA must be enabled and functioning for the cluster. VM Monitoring is a cluster-level HA capability.
VMware Tools should be installed and running in each guest VM that requires heartbeat-based monitoring.
The cluster must be healthy enough for HA to apply its policy. Review cluster HA state, host connectivity, and relevant vCenter events.
Guest disk activity affects detection. Active I/O can indicate that a guest is still working even when a heartbeat is temporarily unavailable.
VMware Tools availability affects detection quality. A stopped or malfunctioning Tools service can remove an important guest responsiveness signal.

Enable VM Monitoring in the vSphere Client

Select the target cluster in the vSphere inventory.
Open the cluster Manage or Configure area, depending on the vSphere version.
Open the cluster's vSphere HA settings.
Edit the cluster HA configuration.
Under VM Monitoring, select VM Monitoring Only.
Choose a predefined sensitivity option, or select Custom to specify the monitoring parameters.
If using custom settings, configure the failure interval, minimum uptime, maximum per-VM resets, and maximum resets time window.
Save or apply the cluster configuration.

Client labels and navigation locations can differ between vSphere releases. The setting remains part of the target cluster's vSphere HA configuration.

Monitoring Sensitivity

Monitoring sensitivity controls how quickly HA decides that a guest has failed and how readily it initiates a reset. The vSphere client provides predefined sensitivity choices through an interface slider or similar control.

A more aggressive policy can restore service sooner after a real guest failure.
A more aggressive policy also increases the risk of resetting a VM during a long guest pause, maintenance operation, startup delay, or temporary loss of heartbeat.
A less aggressive policy allows more time for a guest to recover, but service may remain unavailable longer before HA acts.

Use a predefined option when the workload has ordinary and predictable behavior. Use custom settings when the VM has unusual boot times, irregular I/O, long maintenance pauses, specialized operating-system behavior, or a carefully measured recovery requirement.

Custom VM Monitoring Parameters

Custom settings let you tune detection and reset throttling for a workload instead of relying only on a predefined sensitivity.

Failure interval: The period during which both VMware Tools heartbeats and guest disk I/O must be absent before HA resets the VM. A lower value detects failures sooner but tolerates fewer temporary pauses. A higher value provides more tolerance but delays recovery. Base the value on normal guest pauses and workload behavior.

Minimum uptime: The grace period after VM startup before HA begins monitoring VMware Tools heartbeats. A lower value begins monitoring sooner but may overlap with operating-system and Tools startup. A higher value gives slow-starting guests more time but delays protection after power-on. Choose a value that covers normal boot and initialization time.

Maximum per-VM resets: The maximum number of automatic resets allowed for one VM during the evaluation period. A lower value limits repeated disruption but may leave a failed VM stopped sooner. A higher value permits more recovery attempts but can prolong a reboot cycle and hide a recurring fault.

Maximum resets time window: The period used to evaluate the per-VM reset count. A shorter window limits repeated resets quickly; a longer window permits more resets across a longer period, depending on the reset limit. Interpret this value together with maximum per-VM resets.

Reset throttling and reset loops

A reset loop occurs when a VM repeatedly starts, encounters the same failure, and is reset again. The maximum reset count and time window provide throttling. Once the VM reaches the configured reset limit within that window, HA stops continuously resetting it automatically.

Reset throttling protects the cluster and makes persistent failures visible for investigation. Increasing the reset limit should not be the first response to repeated crashes.

Operational Design Considerations

Workload criticality: A critical service may justify faster recovery, but only if its normal behavior is well understood.
Boot duration: Slow database or infrastructure VMs may need a longer minimum uptime so startup is not mistaken for failure.
Normal I/O patterns: A VM that pauses or produces irregular disk activity may need less aggressive timing than a consistently active workload.
Application behavior: Applications that perform long transactions, maintenance tasks, or recovery operations may temporarily appear inactive.
Reset limits: Set limits that provide useful recovery attempts without allowing an endless reboot cycle.

VM Monitoring complements, but does not replace, application-aware monitoring, backups, root-cause analysis, guest operating-system maintenance, patching, and application recovery procedures. A VM reset cannot repair corrupted data or an application that fails every time it starts.

Verification and Ongoing Administration

Confirm that vSphere HA is enabled and healthy for the intended cluster.
Confirm that VM Monitoring is enabled at the intended cluster scope.
Check VMware Tools status for every VM intended to receive guest-level protection.
After a test or production event, review vCenter tasks and events for the VM and cluster.
Correlate the HA event with guest operating-system logs, application logs, storage activity, and VMware Tools status.

Testing should use a controlled maintenance plan. A forced guest failure causes a service interruption and may trigger application recovery behavior.

VM Monitoring Compared With Other Availability Functions

Capability: VM Monitoring. Failure detected: Unresponsive guest operating system. Detection basis: VMware Tools heartbeat plus guest disk I/O. Recovery: Reset the VM on its current ESXi host. Scope: Individual VM guest.

Capability: vSphere HA host failure recovery. Failure detected: ESXi host failure or loss of host availability. Detection basis: HA host and cluster health mechanisms. Recovery: Restart affected VMs on another eligible host. Scope: Host and its resident VMs.

Capability: Application-aware monitoring. Failure detected: Failed application, service, or transaction. Detection basis: Application-specific probes and health checks. Recovery: Depends on the monitoring and orchestration system. Scope: Application or service.

Troubleshooting VM Monitoring

The VM is not reset even though it appears frozen

Check whether VM Monitoring is enabled for the cluster.
Confirm that vSphere HA is active and healthy.
Check whether the failure interval has actually elapsed.
Determine whether guest disk I/O continued. Ongoing I/O can prevent HA from declaring failure.
Check VMware Tools installation, running state, and recent guest or Tools errors.
Review relevant VM and cluster events in vCenter.

The VM is reset unexpectedly

Review the selected sensitivity and custom failure interval.
Check whether the guest experienced a long pause or stall.
Verify whether VMware Tools stopped heartbeating while guest disk I/O was also absent long enough to meet the failure condition.
Correlate HA events with guest, application, and storage logs.
Increase timing values only after confirming that the workload legitimately requires more tolerance.

The VM stops being restarted after repeated failures

The VM may have reached the configured maximum per-VM reset count within the maximum resets time window. Review those settings and investigate the recurring guest failure before changing the limit or manually restarting the VM.

A recently powered-on VM is not monitored immediately

The minimum uptime grace period may not have expired. Compare the VM power-on time with the configured minimum uptime. Reduce the value only when normal guest boot and VMware Tools initialization consistently complete sooner.

Exam-Relevant Notes

VM Monitoring protects against guest operating-system failure, not ESXi host failure.
Its primary guest signals are VMware Tools heartbeats and guest disk I/O.
The failure condition requires both signals to be absent for the configured interval.
VM Monitoring resets the VM on its current ESXi host; host-failure recovery is a different HA response.
VM Monitoring Only is configured in cluster-level vSphere HA settings.
Minimum uptime delays heartbeat monitoring after startup.
Maximum per-VM resets and maximum resets time window prevent persistent reset loops.

Summary

VM Monitoring extends vSphere HA protection into the guest operating system. It combines VMware Tools heartbeats with guest disk I/O activity, waits through the configured failure interval, and resets a VM when the guest appears inactive. Correct configuration requires a healthy HA cluster, functioning VMware Tools, workload-appropriate sensitivity, a realistic startup grace period, and reset limits that prevent endless reboot cycles.

For continued reference, see VM Monitoring in vSphere HA.