VM Monitoring in vSphere HA: Guest OS Failure Detection and Automatic VM Restart
Learn how vSphere HA VM Monitoring detects unresponsive guest operating systems, configures automatic VM resets, tunes sensitivity, and prevents restart loops.
VM Monitoring is a vSphere HA capability that detects probable failures inside a virtual machine's guest operating system and can restart the VM automatically. It is different from host monitoring: host monitoring detects an ESXi host failure, while VM Monitoring evaluates whether an individual guest is still responsive.
This lesson explains VMware Tools heartbeats, guest disk I/O, failure intervals, minimum uptime, reset limits, configuration workflow, testing, and troubleshooting.
What VM Monitoring does
vSphere HA is a cluster availability feature that can recover workloads after qualifying failures. VM Monitoring extends that availability model to a guest operating system that appears to have stopped responding even though its ESXi host is still operating.
VM Monitoring uses guest activity indicators to identify a probable guest OS failure. When the configured conditions persist, vSphere HA performs a VM reset, which is a restart operation against the virtual machine.
- Guest-level failure: The VM's operating system or application stack may be hung, while the ESXi host remains healthy.
- Host-level failure: An ESXi host has failed or become unavailable, causing HA to restart affected VMs on another suitable host.
VM Monitoring normally leaves the VM on its current ESXi host. It is not host failover, automatic workload migration, vMotion, or DRS placement. Because a reset interrupts the guest, in-memory work and unsaved guest data can be lost.
How VM Monitoring detects a guest failure
VMware Tools heartbeat
The primary responsiveness signal is the VMware Tools heartbeat. VMware Tools runs inside the guest and reports a guest-to-host responsiveness signal. VMware Tools must be installed, running, and able to communicate its heartbeat for heartbeat-based monitoring to work as intended.
Guest disk I/O activity
VM Monitoring also considers guest disk I/O activity. Storage activity can indicate that the guest is still doing useful work even when a heartbeat is absent or delayed. This means a VM that continues disk activity may not be declared failed immediately.
A failure declaration can occur when both conditions persist for the configured failure interval:
- The VMware Tools heartbeat is absent.
- The VM shows no guest disk I/O activity.
This assessment indicates a likely guest OS or application-stack hang. It does not prove the root cause. A driver deadlock, resource exhaustion, storage pause, VMware Tools problem, operating system fault, or application failure may produce similar symptoms.
| Observed condition | Heartbeat status | Guest disk I/O status | Configured timing considered | Expected HA action |
|---|---|---|---|---|
| Guest is responsive | Present | Active or inactive | Failure interval is not reached | No VM Monitoring reset |
| Heartbeat is missing but the guest is still doing storage work | Absent | Active | Activity may prevent a failure declaration | Continue evaluating the VM |
| Guest appears unresponsive | Absent | Absent | Both conditions persist through the failure interval | HA resets and restarts the VM |
Recovery behavior and availability impact
When VM Monitoring determines that a VM has probably failed, vSphere HA initiates a VM reset/restart. This is equivalent to abruptly restarting an unresponsive machine rather than repairing its operating system.
- The VM normally remains on its current ESXi host.
- The guest OS boots again and applications attempt their normal startup procedures.
- Unsaved data and in-memory transactions can be lost.
- The underlying guest or application defect remains and may cause another failure.
VM Monitoring is therefore useful when an automatic reboot is preferable to leaving a nonresponsive service unavailable, but it should not be treated as a substitute for root-cause analysis or application-aware recovery.
Requirements and operational dependencies
- The VM must be managed in a vSphere HA-enabled cluster.
- VM Monitoring is configured through vSphere HA at the cluster level.
- VMware Tools must be installed, running, and able to report heartbeats.
- The guest must have a startup process and application behavior compatible with an automatic reset.
- Storage availability and guest disk behavior can affect the activity assessment.
Guest configuration, VMware Tools health, storage latency or outages, CPU and memory pressure, boot duration, and workload behavior can all affect detection results. A healthy heartbeat proves that VMware Tools can report responsiveness; it does not prove that every service or application inside the guest is healthy.
For background, review Enable vSphere HA and Host Monitoring Option.
Enable VM Monitoring in the vSphere Client
The exact labels can vary slightly by vSphere release, but the configuration follows this general path:
- In the inventory, select the target cluster.
- Open the cluster's Manage or Configure area.
- Open the vSphere HA settings and choose to edit the cluster configuration.
- Locate the VM Monitoring section or option.
- Select VM Monitoring Only, the mode that enables VM Monitoring without expanding this lesson into other HA functions.
- Choose a predefined sensitivity level or select Custom and enter individual values.
- Save the cluster configuration.
- Reopen or review the settings and verify that the intended monitoring mode is active.
VM Monitoring depends on vSphere HA being enabled. It is not an independent ESXi host setting. For related cluster planning, see Create Clusters and Admission Control Explained.
Monitoring modes and scope
The VM Monitoring Only mode enables guest VM monitoring while keeping the focus on VM-level recovery. vSphere HA itself supplies the cluster framework and performs the reset when the monitoring policy declares a likely failure.
Do not confuse this setting with:
- Application monitoring: Checks a named service, process, endpoint, or transaction rather than general guest responsiveness.
- Guest OS monitoring agents: Run inside the operating system and can report operating-system or service-specific conditions.
- Host isolation response: Defines what happens when an ESXi host cannot communicate appropriately with the rest of the cluster.
- Host failure recovery: Restarts workloads after an ESXi host failure, usually on another host.
- Admission control: Reserves cluster capacity for HA recovery; it does not detect guest hangs.
- Datastore heartbeating: Helps HA assess host state when network communication is impaired; it is not a guest heartbeat.
See Datastore Heartbeating Explained for the datastore-related mechanism.
Sensitivity and custom configuration
Sensitivity is a bundled collection of timing and reset-limit values. A predefined sensitivity level simplifies configuration by applying a coordinated profile. A Custom selection permits direct entry of individual values.
- A more aggressive profile can detect failure sooner and reduce downtime, but it increases the chance of restarting a guest during a temporary pause.
- A more conservative profile reduces unnecessary resets, but a genuinely failed guest may remain unavailable longer before recovery.
- Custom values should be based on boot time, storage behavior, workload tolerance, and the quality of other monitoring signals.
Do not choose a profile solely because it has the shortest detection time. A forced reset is itself an availability event and can damage in-flight work.
Failure interval
The Failure interval is the duration used while evaluating the absence of the required guest activity signals. In practical terms, the VM may be restarted when the VMware Tools heartbeat is missing and guest disk I/O is also absent for this interval.
- Shorter interval: Faster recovery from a real guest hang, with greater false-positive risk during transient pauses.
- Longer interval: More tolerance for pauses and workload bursts, with a longer outage before an automatic reset.
Choose an interval that exceeds expected short pauses but is still useful for the service's availability objective.
Minimum uptime
Minimum uptime is the delay after a VM powers on before VMware Tools heartbeat monitoring begins. This startup grace period excludes the time when the operating system, VMware Tools, drivers, and applications are still initializing.
For a slow-starting database server, for example, a minimum uptime of only a few seconds could cause evaluation before VMware Tools is ready. Choose a value that covers normal and occasionally slower boot sequences. Validate the choice after operating-system patches, storage changes, or application upgrades that alter startup time.
Reset limiting and loop prevention
Maximum per-VM resets is the maximum number of automatic VM restart attempts permitted for one VM. Maximum resets time window is the period over which those attempts are counted.
When the allowed number of resets is exceeded within the configured window, HA stops automatically restarting that VM. This prevents an endless recovery loop, limits disruption to the cluster, and signals that repeated failures require investigation.
For example, if a VM is allowed three resets in a defined time window, three failures may trigger automatic recovery. A further failure inside that same window can leave the VM without another automatic reset attempt. An administrator should then investigate the guest OS, drivers, startup services, storage, and application before changing limits or repeatedly powering on the VM.
| Setting | Purpose | Effect of a lower value | Effect of a higher value | Planning considerations |
|---|---|---|---|---|
| Failure interval | Time used to evaluate missing heartbeat and disk activity | Faster recovery; higher false-positive risk | Slower recovery; greater tolerance for pauses | Compare with normal guest pauses and outage objectives |
| Minimum uptime | Startup grace period before heartbeat monitoring begins | Earlier evaluation during boot | More time for slow guests to initialize | Measure normal and worst-case boot duration |
| Maximum per-VM resets | Allowed automatic restart attempts for one VM | Stops repeated failures sooner | Allows more recovery attempts | Balance availability against restart loops and data risk |
| Maximum resets time window | Period used to count automatic reset attempts | Attempts accumulate over a shorter period | Failures are spread across a longer counting period | Align with known crash patterns and investigation procedures |
Configuration planning and validation
Choose suitable workloads
Good candidates are workloads where an automatic reboot is safer or more useful than prolonged guest unresponsiveness. Consider whether the application can recover after an abrupt restart, whether data is durable, and whether another monitoring system already performs a more precise recovery action.
- Application restart tolerance and transaction recovery behavior
- Normal and worst-case boot duration
- Data durability, in-memory state, and backup coverage
- Maintenance windows and expected restart activity
- Overlap with application monitoring, guest agents, and external load balancers
- Storage pauses and resource pressure that could resemble a failure
Test safely
Use a nonproduction VM or an approved failure simulation. Record the expected detection interval, reset behavior, boot duration, and application recovery result before testing. Do not simulate a failure on a production workload without an approved change and recovery plan.
After a test, verify:
- VMware Tools status and heartbeat availability
- vSphere HA events and VM reset events
- Guest uptime before and after the reset
- Guest operating-system logs and application recovery
- Whether the VM remained on the same ESXi host
- Whether reset counters behaved as planned
VM Monitoring compared with related availability features
| Feature | Failure scope | Primary signal or condition | Recovery action | Whether the VM stays on the same host |
|---|---|---|---|---|
| VM Monitoring | Guest OS or probable guest-stack failure | VMware Tools heartbeat plus guest disk I/O assessment | VM reset/restart | Normally yes |
| vSphere HA host failure recovery | ESXi host failure | Host failure detection and cluster state | Restart affected VMs on another suitable host | No; workload is recovered elsewhere |
| Host isolation response | Host communication isolation | Host network communication and isolation state | Configured host isolation response | Depends on the response and resulting host state |
| Datastore heartbeating | Assists host-state assessment during network problems | Datastore heartbeat files and host communication context | Supports HA decision-making; not a guest reset policy by itself | Not applicable as a guest-monitoring scope |
| Application monitoring | Specific service, process, or application function | Application-aware checks or service responses | Depends on the monitoring system; may restart a service or VM | Usually yes unless separately integrated with migration or HA |
Limitations and important distinctions
- VM Monitoring does not repair the underlying guest OS or application defect.
- A healthy VMware Tools heartbeat does not prove that every application is healthy.
- Disk I/O activity can make a guest appear active, so some failure states may not be detected as quickly as expected.
- VM Monitoring does not replace application-aware health checks.
- It does not perform host failure recovery, admission control, host isolation response, or datastore heartbeating.
- A VM reset can lose unsaved guest data and may trigger application recovery procedures.
Troubleshooting VM Monitoring
The VM appears hung but is not restarted
- Confirm that vSphere HA and VM Monitoring are enabled for the cluster.
- Confirm that the VM is subject to the cluster policy and has no VM-specific override disabling monitoring.
- Verify that VMware Tools is installed and running.
- Check whether guest disk I/O continues; ongoing activity can affect failure determination.
- Review the failure interval and HA event history.
The VM restarts unexpectedly
- Review HA and VM events for lost heartbeat and activity conditions.
- Check VMware Tools stability and guest CPU, memory, and storage pressure.
- Assess whether the failure interval is too aggressive for this workload.
- Look for guest boot, storage, or application pauses that resemble a failure.
Automatic recovery attempts stopped
- Check whether Maximum per-VM resets was reached within the Maximum resets time window.
- Investigate guest OS errors, drivers, startup services, storage, and application failures.
- Adjust reset limits only after understanding the repeated failure pattern.
VM Monitoring reports healthy but the application is unavailable
Heartbeat monitoring measures general guest responsiveness, not full application health. Use application-aware checks, service checks, or guest monitoring tools when the workload requires service-level validation.
Exam-relevant notes
- VM Monitoring detects probable guest failure; host monitoring detects ESXi host failure.
- The primary signal is the VMware Tools heartbeat, evaluated with guest disk I/O activity.
- A missing heartbeat alone does not necessarily produce a reset when disk activity continues.
- VM Monitoring resets the VM and normally keeps it on the same ESXi host.
- Minimum uptime provides startup grace time before heartbeat evaluation.
- Maximum per-VM resets and Maximum resets time window prevent endless restart loops.
- VMware Tools heartbeat health does not equal application health.
Summary
VM Monitoring helps vSphere HA recover from a probable guest OS hang by evaluating VMware Tools heartbeats together with guest disk I/O. When the required activity remains absent through the failure interval, HA resets the VM on its current host. Sensitivity, minimum uptime, failure interval, and reset limits must be chosen according to boot behavior, application tolerance, data durability, and the risk of false positives. Always validate the policy with controlled testing and investigate any VM that reaches its reset limit.