VMware ESXi and vSphere Cluster Management
Preparing a vSphere HA Cluster for Network Maintenance
Learn how to prevent false vSphere HA host-failure detection and unwanted VM failover before planned ESXi network maintenance.
Planned network work can look like an ESXi host failure to vSphere HA. Before changing switches, VLANs, uplinks, or management connectivity, temporarily adjust HA protection, evacuate workloads, and place affected hosts into maintenance mode. After connectivity is restored and validated, return the cluster to its normal protection state.
Why Network Maintenance Affects vSphere HA
vSphere HA is a cluster service that helps recover virtual machines when an ESXi host is considered failed. HA uses network-based communication and host heartbeats to exchange availability information between hosts and the cluster management service.
Host failure detection is the process by which HA determines that an ESXi host is unavailable. A planned interruption to a management or heartbeat network can therefore resemble an unexpected host outage. If HA cannot communicate with a host, it may interpret the loss of communication as a false host failure.
When HA detects a host failure, its recovery behavior can include failover: restarting affected virtual machines on another eligible host. During planned network maintenance, that response may be unwanted. It can cause unnecessary VM restarts, duplicate recovery activity, alarms, or contention for capacity while administrators are already changing the network.
Redundant heartbeat networks reduce the chance that one failed path will cause loss of HA communication, but redundancy does not remove the need for a maintenance plan. Identify every affected path, including management interfaces, physical uplinks, switches, port groups, and VLANs. Datastore heartbeating may provide additional host-state information in some designs, but it should not be treated as a replacement for stable network connectivity and controlled maintenance procedures.
Pre-Maintenance Planning for an HA-Enabled Cluster
Begin with a change plan that identifies the exact scope and order of operations. The objective is to prevent a planned connectivity loss from being processed as an unplanned host failure.
- Identify affected hosts: list each ESXi host connected to the switches, VLANs, uplinks, or network segments being changed.
- Map cluster networks: identify management, vMotion, storage, VM, and other relevant networks. Confirm which paths carry HA-related host communication in your environment.
- Identify physical dependencies: record switch pairs, ports, NICs, uplinks, port groups, VLANs, and routing dependencies.
- Check vCenter reachability: determine how the planned change could affect communication between vCenter Server and ESXi hosts. Review communication between vCenter Server and ESXi before proceeding.
- Confirm capacity: verify that the remaining healthy hosts have sufficient CPU, memory, storage access, and compatible configuration to receive the workloads.
- Classify workloads: decide which VMs will be live-migrated, shut down, or kept available under an approved alternative plan.
- Check compatibility: confirm that migration networking and destination hosts support the VMs. A live migration requires appropriate vMotion configuration and functioning migration networks.
- Review VM overrides: inspect any VM override, which is a per-VM HA behavior setting that differs from the cluster-wide configuration. Do not assume every VM follows identical HA behavior.
- Coordinate the sequence: adjust HA protection before interrupting connectivity, then evacuate workloads and enter maintenance mode before the network work begins.
Critical workloads need an explicit availability decision. Live migration preserves service more effectively than shutdown when the environment supports it, but migration itself depends on capacity, compatibility, storage access, and functional migration networking.
Disable vSphere HA Host Monitoring Before Network Changes
Host Monitoring is the vSphere HA setting that monitors ESXi host availability and can trigger a failure response when a host is judged unavailable. Temporarily disabling Host Monitoring suppresses HA host-failure monitoring during the planned maintenance window.
This is a temporary operational change, not a permanent reduction in cluster protection. Restore Host Monitoring after the network is stable and the cluster has been validated.
vSphere Client procedure
- Select the affected cluster in the vSphere Client inventory.
- Open Manage.
- Open Settings.
- Open vSphere HA.
- Choose to edit the cluster settings.
- Clear the option that enables Host Monitoring.
- Apply the change and confirm that the setting is disabled before starting network work.
Disable Host Monitoring at the cluster level before the planned interruption. If multiple clusters or separate maintenance scopes are involved, verify that the setting was changed in the correct cluster.
Place Affected ESXi Hosts Into Maintenance Mode
Maintenance Mode is an ESXi host state used for planned servicing. A host in maintenance mode is not selected as a destination for HA failover placement. This prevents the host from being treated as an available target while it is being serviced.
Enter maintenance mode while the host still has the connectivity needed for controlled workload evacuation. Do not wait until the host has already lost management or heartbeat communication.
vSphere Client procedure
- Locate the affected ESXi host in the inventory.
- Right-click the host.
- Choose Enter Maintenance Mode.
- Wait for the evacuation task to complete or resolve any workloads that prevent completion.
Maintenance mode does not automatically solve capacity or compatibility problems. Running VMs must be moved to another compatible host or powered down before maintenance mode can complete.
Handle Virtual Machines Before Maintenance Mode
VM evacuation means moving or shutting down virtual machines so an ESXi host can enter maintenance mode. There are two primary choices:
| Choice | How it works | Important requirements |
|---|---|---|
| Live migration | Move a running VM to another compatible host without shutting it down. | Requires suitable destination capacity, compatible host configuration, accessible storage, and functional migration networking. |
| Shutdown | Power off the VM before servicing the host. | Requires an approved outage plan, application shutdown procedure, and a defined restart plan. |
If a host cannot enter maintenance mode, identify the remaining powered-on VMs and determine why each was not evacuated. Migrate eligible VMs to another host or shut them down according to the approved plan, then retry the operation.
Confirm that critical workloads have an availability plan before proceeding. Do not force a maintenance operation by ignoring a VM that still requires service or by moving it to a host without adequate capacity.
Safe Sequence for Network Maintenance
| Phase | Administrator action | Purpose | Expected result |
|---|---|---|---|
| Preparation | Identify affected hosts, networks, uplinks, switches, VLANs, workloads, and available capacity. | Define scope and prevent overlooked dependencies. | The maintenance plan and workload disposition are approved. |
| Disable Host Monitoring | In the cluster, open Manage > Settings > vSphere HA, edit the settings, and clear Host Monitoring. | Prevent planned communication loss from triggering host-failure recovery. | HA host-failure monitoring is temporarily suppressed. |
| Evacuate workloads | Live-migrate eligible VMs or shut them down according to the plan. | Remove workloads from hosts that will be serviced. | No unplanned workload remains on an affected host. |
| Enter Maintenance Mode | Right-click each affected host and choose Enter Maintenance Mode. | Mark hosts as unavailable for planned service and HA placement. | Hosts complete evacuation and enter maintenance mode. |
| Perform network change | Change the planned switch, VLAN, uplink, or related network configuration. | Complete the scheduled network work without treating it as host failure. | Network changes are implemented. |
| Validate connectivity | Restore paths and verify management reachability, host responsiveness, and cluster communication. | Confirm that hosts are healthy before returning them to service. | Affected hosts are connected and stable in vCenter Server. |
| Restore normal HA operation | Exit maintenance mode on ready hosts and re-enable Host Monitoring after validation. | Return hosts and HA protection to normal operation. | Hosts can receive normal workloads and HA monitoring is active. |
The order matters: disable Host Monitoring first, evacuate workloads, enter maintenance mode, perform the network change, validate connectivity, exit maintenance mode, and then re-enable Host Monitoring.
Host Monitoring and Maintenance Mode Effects
| Condition | Host failure monitoring behavior | HA failover destination eligibility | VM handling requirement |
|---|---|---|---|
| Normal host operation | Host Monitoring is active and HA evaluates host availability. | The host may be eligible if it is healthy and has capacity. | VMs may run normally. |
| Host Monitoring temporarily disabled | HA host-failure monitoring is suppressed for the maintenance window. | Other HA rules and host state still matter; this setting is not a substitute for evacuation. | Planned workload handling is still required. |
| Host in Maintenance Mode | The host is being serviced rather than used for normal cluster operation. | The host is not selected as an HA failover destination. | Running VMs must be migrated or powered off before entry completes. |
| Planned network interruption | Communication may be lost and can resemble a false host failure if monitoring remains active. | Eligibility depends on host state and cluster conditions; do not rely on the interruption itself to protect workloads. | Disable Host Monitoring and evacuate affected hosts before the interruption. |
Post-Maintenance Validation
- Verify management connectivity: confirm that every affected ESXi host has stable access through the intended management network.
- Check vCenter status: verify that each host is connected and responsive in vCenter Server rather than merely reachable at the network layer.
- Review HA health: confirm that the cluster reports the expected HA state and that no unresolved configuration or communication alarm remains.
- Confirm Host Monitoring: verify that Host Monitoring has been re-enabled as intended after the cluster is stable.
- Exit maintenance mode: for each ready host, exit maintenance mode so it becomes eligible for normal workload placement.
- Review placement: confirm that VMs are running on appropriate hosts and that the remaining capacity is acceptable.
- Review events and alarms: inspect host status, cluster alarms, VM placement, and any unexpected HA events generated during the change.
A host that remains unavailable for normal placement is commonly still in maintenance mode or has not regained stable connectivity. Validate both conditions before returning it to service.
Practical Scenarios
Planned switch or VLAN maintenance
- Identify the ESXi hosts connected to the affected switches, VLANs, and uplinks.
- Temporarily disable cluster Host Monitoring.
- Migrate or shut down VMs on the affected hosts.
- Enter maintenance mode on those hosts before changing the switch or VLAN.
- Restore the network and test host management connectivity.
- Exit maintenance mode for ready hosts.
- Re-enable Host Monitoring and confirm normal HA health.
Planned loss of HA communication should not be handled like an unplanned host failure.
A host cannot enter maintenance mode
Inspect the host's remaining workloads. A powered-on VM may still require migration or shutdown. Move eligible VMs to another compatible host, or power them off under the approved plan. Retry maintenance mode and confirm that the host is no longer a candidate for HA workload placement.
Network maintenance has completed
Confirm stable management connectivity for every affected host, check HA health and alarms, exit maintenance mode on ready hosts, restore Host Monitoring, and verify normal VM placement and cluster protection.
Troubleshooting
| Symptom | Likely cause | Resolution direction |
|---|---|---|
| HA reports a host failure or starts unexpected recovery during planned network work. | Host Monitoring remained enabled while heartbeat or management communication was interrupted. | For future planned changes, disable Host Monitoring before the interruption and place affected hosts in maintenance mode. |
| An ESXi host does not enter maintenance mode. | VMs are still running on the host and were not migrated or shut down. | Move eligible VMs to another host or power them off according to the maintenance plan, then retry. |
| A host remains unavailable for normal workload placement. | The host is still in maintenance mode or has not regained stable network connectivity. | Validate connectivity and host health, then exit maintenance mode when the host is ready. |
| The cluster has reduced HA protection after maintenance. | Host Monitoring was not restored. | After verifying stable operation, re-enable Host Monitoring and confirm HA status. |
Exam-Relevant Notes
- Planned network interruption can be interpreted as a host failure when HA loses heartbeat or management communication.
- Disabling Host Monitoring is a temporary cluster-level control for the maintenance window; it must be restored afterward.
- Maintenance mode prevents a host from being selected as an HA failover destination.
- VM evacuation must occur before maintenance mode can complete. Live migration and shutdown are separate workload-handling choices.
- Entering maintenance mode before connectivity is interrupted provides controlled evacuation and avoids relying on failure detection during planned work.
- After maintenance, validate connectivity and host state before exiting maintenance mode and restoring Host Monitoring.
Related Administration Topics
- vSphere HA admission control and capacity planning for host maintenance.
- Advanced vSphere HA options for understanding additional cluster behavior.
- Alarms in vSphere for reviewing connectivity and HA events.
- Adding an ESXi host to vCenter Server inventory when validating host management.