VMware ESXi and vSphere Cluster Management

Preparing a vSphere HA Cluster for Network Maintenance

Learn how to prepare a vSphere HA cluster for planned network maintenance by disabling Host Monitoring, evacuating ESXi hosts, using maintenance mode, and validating HA afterward.

Planned network maintenance can look like an unexpected ESXi host failure to vSphere High Availability (vSphere HA). A careful sequence prevents unnecessary virtual machine recovery actions while preserving a controlled path back to normal protection.

This lesson covers management-network changes, switch work, uplink changes, VLAN changes, and other maintenance that may interrupt communication between ESXi hosts and vCenter Server.

Key terms

• vSphere HA: A cluster capability that detects certain host failures and restarts affected virtual machines on surviving hosts.
• ESXi host: A physical server running the VMware hypervisor and hosting virtual machines.
• Cluster: A group of ESXi hosts managed together for availability and resource operations.
• Host Monitoring: A vSphere HA setting that enables host heartbeat monitoring for host-failure detection.
• Maintenance mode: An ESXi host state that removes the host from normal workload use so it can be serviced.
• vMotion: Live migration of a running virtual machine between compatible ESXi hosts.
• DRS: Distributed Resource Scheduler, which can recommend or automate workload placement and migration.
• Failover: An HA recovery action in which virtual machines are restarted on alternate hosts after a failure is declared.
• Host isolation: A condition where a host loses communication with the management network while potentially continuing to run virtual machines.
• VM override: A per-virtual-machine HA policy that can modify the cluster default availability behavior.

Why network maintenance affects vSphere HA

vSphere HA uses communication between cluster participants to determine whether hosts are reachable. Management-network connectivity and HA heartbeat mechanisms are important inputs to that determination. A heartbeat is a periodic communication signal indicating that a host is still participating in the cluster.

If a switch port, uplink, VLAN, vmkernel adapter, or management path is intentionally interrupted, other hosts may stop receiving expected heartbeats. From their perspective, the result can resemble an ESXi host failure even though the physical server and its virtual machines are still running.

When HA declares a host failure, it may attempt to restart affected virtual machines on surviving hosts. That recovery action is appropriate for an actual failure, but it is unnecessary and potentially disruptive during planned network work. It can create duplicate-workload risks, service interruptions, resource contention, and confusion about which virtual machine instance is authoritative.

Host failure and host isolation are different conditions

A host failure generally means the host is no longer operating or is otherwise unavailable to the cluster. Host isolation means the host has lost management-network communication with the rest of the cluster but may still be powered on and running its virtual machines. Network maintenance can produce an isolation-like condition without a server failure.

The exact response also depends on HA configuration, network redundancy, datastore heartbeating, VM-specific overrides, and the evidence available to the cluster. Do not assume that a network interruption will be harmless merely because the ESXi servers remain powered on.

Maintenance planning and impact assessment

Before changing the network, map the complete path from each affected ESXi host to vCenter Server and to the other cluster members. Identify the following:

• ESXi hosts and physical NICs that will be affected.
• Uplinks, switch ports, switches, link aggregation, and physical redundancy.
• VLANs, port groups, and distributed or standard switch objects.
• Management vmkernel adapters and their IP paths.
• HA heartbeat paths and any configured redundancy.
• vMotion vmkernel adapters and the network used for live migration.
• Storage paths, including networks used by iSCSI, NFS, or other storage protocols.
• Virtual machine networks that may lose connectivity.
• Routing, MTU, gateway, firewall, and access-control dependencies.

Classify the expected effect of the change. A switch replacement may affect management traffic, HA heartbeats, vMotion, storage, and virtual machine traffic at the same time. A change to only a virtual machine VLAN may not interrupt HA, but it can still affect applications. Confirm the scope rather than relying on the change description alone.

Network Maintenance Preparation Checklist

Preparation item: Identify affected hosts, uplinks, switches, VLANs, port groups, and vmkernel adapters. Purpose: Define the maintenance boundary. How to verify: Compare the approved network diagram with vSphere networking and switch configuration. Risk if skipped: An unplanned host or traffic path may be disconnected.

Preparation item: Determine whether management, HA heartbeat, vMotion, storage, or VM networks will be interrupted. Purpose: Predict availability and recovery effects. How to verify: Trace each traffic type through its vmkernel adapter, uplink, VLAN, and physical path. Risk if skipped: A network change may cause host isolation, failed migrations, storage disruption, or application outages.

Preparation item: Check workload placement and destination capacity. Purpose: Confirm that affected workloads can run elsewhere. How to verify: Review cluster resources, reservations, admission-control capacity, and destination compatibility. Risk if skipped: Hosts may not enter maintenance mode or workloads may become resource constrained.

Preparation item: Review evacuation constraints. Purpose: Find workloads that cannot be migrated automatically. How to verify: Check affinity rules, reservations, CPU compatibility, local storage, pass-through devices, connected devices, and licensing. Risk if skipped: The host may retain powered-on virtual machines during network work.

Preparation item: Define rollback and validation steps. Purpose: Restore service quickly if the change fails. How to verify: Document switch configuration, port assignments, prior settings, owners, and decision points. Risk if skipped: Troubleshooting may extend the outage.

Preparation item: Coordinate with application owners. Purpose: Approve migration or shutdown impacts. How to verify: Confirm dependencies, maintenance windows, and recovery contacts. Risk if skipped: An application may be disrupted without an approved recovery plan.

Confirm capacity and evacuation options

Verify that at least one suitable destination host has enough CPU, memory, storage access, networking, and HA capacity for the workloads being moved. Check whether DRS is enabled and whether its rules permit the desired placement.

Review admission control and failover capacity as well. A cluster may have enough resources for normal operation but not enough to tolerate another host failure after evacuation. If the maintenance affects several hosts, use a rolling sequence and retain enough active hosts to run required workloads and preserve recovery capacity.

Disable vSphere HA Host Monitoring before the network change

Host Monitoring controls whether vSphere HA uses missed host heartbeats as a host-failure condition. For intentional disruption of the management or heartbeat path, temporarily turning off Host Monitoring prevents that particular planned interruption from triggering normal host-failure responses.

1. Open the vSphere Client and select the affected cluster.
2. Open the cluster's configuration or settings.
3. Open vSphere HA settings.
4. Edit the Host Monitoring setting and turn it off.
5. Apply the change and wait for the cluster configuration task to complete.
6. Recheck the setting at the cluster level to confirm it is disabled for the intended cluster, not a different cluster or object.

The relevant configuration path is:

Cluster settings > vSphere HA > Host Monitoring

While Host Monitoring is disabled, HA will not automatically react to lost host heartbeats as it normally would. This reduces protection against a real host failure during the window. Record the original setting and define the exact point at which it will be restored.

Place affected ESXi hosts into maintenance mode

Maintenance mode removes an ESXi host from normal workload use so it can be serviced. It also prevents HA from selecting that host as a destination for recovered virtual machines while it is being maintained.

1. In the vSphere Client inventory, select the affected ESXi host.
2. Use the host context menu and choose Enter Maintenance Mode.
3. Review the migration or shutdown prompts.
4. Wait for the host to become empty and for the task to complete successfully.

Host context menu > Enter Maintenance Mode

Maintenance mode and Host Monitoring address different risks. Maintenance mode controls the host's participation in workload placement. Host Monitoring controls the cluster's response to missed host heartbeats. During planned network maintenance, both may be needed: Host Monitoring suppresses an unintended failure interpretation, while maintenance mode removes workloads from the host.

Handle virtual machines during host evacuation

A host cannot fully enter maintenance mode while powered-on workloads remain that cannot be handled by the selected evacuation policy. Each powered-on virtual machine must be migrated to another suitable host or shut down before maintenance begins.

Use vMotion and DRS when live migration is available

When vMotion is configured and its network is healthy, a running virtual machine can be moved to a compatible ESXi host with little or no guest-visible interruption. DRS can recommend or automate placement, depending on its configured automation level. Confirm that the source and destination hosts have compatible CPU features, accessible datastores, suitable networks, and enough resources.

After requesting evacuation, verify the task results rather than assuming that a successful request means every workload moved. Check the host's virtual machine list and confirm each critical workload's destination.

Use an approved shutdown path when migration is unavailable

Some workloads cannot be moved with vMotion, or the maintenance plan may intentionally avoid live migration. Examples include virtual machines using incompatible CPU features, local storage, pass-through devices, certain connected hardware, restrictive licensing, or policies that prevent migration.

For these workloads:

1. Identify the virtual machines and document application dependencies.
2. Obtain approval from application owners for the interruption.
3. Gracefully shut down guests and applications according to their runbooks.
4. Power off the virtual machines if a guest shutdown is not possible or if the approved procedure requires it.
5. Confirm that the host is empty before retrying maintenance mode.

Virtual Machine Evacuation Options

Option: vMotion. Prerequisites: Healthy vMotion networking, compatible hosts, shared or accessible storage, and sufficient destination resources. Service interruption: Normally minimal. Typical use case: Planned host evacuation for routine maintenance. Limitations: Reservations, CPU compatibility, device use, local storage, licensing, or network problems can block migration.

Option: DRS-assisted migration. Prerequisites: DRS configuration, eligible hosts, and placement rules that allow movement. Service interruption: Normally minimal when DRS uses vMotion. Typical use case: Coordinated placement across a cluster. Limitations: DRS does not override incompatible hardware, unavailable networks, reservations, affinity rules, or insufficient capacity.

Option: Graceful guest shutdown. Prerequisites: Application approval, guest access, and a tested startup procedure. Service interruption: Yes. Typical use case: Workloads that cannot be migrated or when live migration is intentionally avoided. Limitations: Requires downtime and careful dependency handling.

Option: Forced power off. Prerequisites: Explicit approval and a recovery plan. Service interruption: Yes, with possible guest or application recovery. Typical use case: A last resort when graceful shutdown is unavailable. Limitations: Risk of data loss or filesystem and application inconsistency.

Example: no live migration path

Suppose a host has virtual machines on local storage and no usable vMotion path. Identify those machines, confirm their restart and application dependencies, and schedule approved shutdowns. Gracefully stop the workloads, verify that they are powered off, and then enter the host into maintenance mode. Do not proceed merely because the network change is scheduled; the host must be empty or have an explicitly approved exception.

Safe maintenance sequence

1. Assess impact. Identify affected network paths, hosts, workloads, and application dependencies.
2. Ensure evacuation capacity. Confirm suitable destination hosts, storage, networks, compatibility, and failover capacity.
3. Disable Host Monitoring. Change the setting at the intended cluster scope and verify that the applied state is off.
4. Evacuate affected hosts. Use vMotion or DRS where possible; shut down approved workloads when migration is unavailable.
5. Enter maintenance mode. Use the host context menu and wait for the host to become empty and enter the state successfully.
6. Perform the network change. Follow the approved switch, VLAN, uplink, routing, MTU, and rollback procedure.
7. Validate connectivity. Confirm management reachability, vmkernel paths, uplinks, vMotion, storage, and required virtual machine networks.
8. Exit maintenance mode. Use the host context menu and choose Exit Maintenance Mode only after the host is healthy.
9. Restore Host Monitoring. Re-enable it at the cluster level after network and management connectivity are stable.
10. Perform post-change checks. Review cluster health, HA state, workload placement, capacity, and alarms.

Host context menu > Exit Maintenance Mode

The restoration order matters. If Host Monitoring is restored before management connectivity is stable, HA may immediately interpret the remaining interruption as a host problem. Network health and host participation must be confirmed first; normal HA detection comes afterward.

Practical example: planned switch maintenance affecting one host

1. Confirm that the host's management uplinks and associated switch ports will be interrupted.
2. Check that another host has sufficient CPU, memory, storage, network access, and HA capacity.
3. Temporarily disable Host Monitoring in the cluster's vSphere HA settings.
4. Migrate eligible virtual machines with vMotion or DRS.
5. Gracefully shut down any workload that cannot be migrated, if approved.
6. Enter the affected ESXi host into maintenance mode.
7. Complete the switch maintenance.
8. Verify switch ports, VLANs, uplinks, vmkernel reachability, and vCenter connectivity.
9. Exit maintenance mode.
10. Confirm host and cluster health, then re-enable Host Monitoring.

This sequence prevents a planned management interruption from being treated as an unexpected host failure while ensuring that workloads are not left on the host being serviced.

Cluster-wide management-network changes

A shared management-network change is more hazardous than a single-host change because it can remove communication from several HA participants at once. Avoid disconnecting every host simultaneously. Use a rolling host-by-host or batch-by-batch sequence where the design permits it.

• Maintain enough active hosts to run the required workloads.
• Retain recovery capacity for an additional host or workload problem.
• Complete connectivity and HA checks after each maintenance batch.
• Stop and reassess if more hosts or paths are affected than planned.
• Do not restore Host Monitoring until the intended management and heartbeat paths are stable.

vSphere HA design considerations

Use redundant management and heartbeat paths

Redundant management and heartbeat network paths reduce the chance that a single switch, uplink, cable, port, VLAN, or adapter failure will appear to be host failure or isolation. Redundancy should be designed, configured, and tested; simply having two physical links does not guarantee that they use independent network paths.

Do not confuse Host Monitoring with VM Monitoring

Host Monitoring concerns whether HA detects host-level heartbeat loss and treats it as a host-failure condition. VM Monitoring concerns the health or responsiveness of individual virtual machines and can trigger recovery for a guest that is not responding according to its policy. Turning off Host Monitoring does not necessarily disable VM Monitoring.

Review both settings before maintenance. A VM-specific HA override can change recovery behavior for one virtual machine even when the cluster default is different. Document important overrides and confirm that their behavior is appropriate for the maintenance window.

Review isolation and recovery policies

HA host-isolation responses determine what may happen when a host loses management communication but continues running. Depending on policy and evidence, virtual machines may remain running, be powered off, or be otherwise handled for recovery. Review the configured policy, VM overrides, datastore heartbeating, and network redundancy before making a change that could cause isolation.

Post-maintenance validation

Post-Maintenance Validation

Validation area: ESXi host connectivity. Expected result: The host is connected in vCenter and management vmkernel reachability is healthy. Where to check: vSphere Client host state, vmkernel networking, uplink status, and network monitoring. Corrective action if unsuccessful: Check physical ports, VLANs, port groups, routing, MTU, and vmkernel configuration; keep Host Monitoring disabled until stable.

Validation area: Cluster health. Expected result: The cluster reports healthy HA configuration and no unexpected host errors. Where to check: Cluster summary, vSphere HA settings, recent tasks, events, and alarms. Corrective action if unsuccessful: Restore connectivity, inspect HA configuration, and investigate before re-enabling normal monitoring.

Validation area: Host maintenance state. Expected result: The host exits maintenance mode only when ready to serve workloads. Where to check: Host status and recent tasks in the vSphere Client. Corrective action if unsuccessful: Resolve remaining tasks, disconnected paths, or workload constraints.

Validation area: Virtual machine placement. Expected result: Critical workloads are running or stopped exactly as planned. Where to check: Virtual machine inventory, host placement, guest health, and application monitoring. Corrective action if unsuccessful: Follow the application recovery plan and correct placement or power-state issues.

Validation area: vMotion and storage. Expected result: Migration and storage paths are available where required. Where to check: vmkernel adapters, datastore accessibility, path status, and a controlled test migration if approved. Corrective action if unsuccessful: Repair the affected network or storage path before normal workload balancing.

Validation area: HA monitoring. Expected result: Host Monitoring is restored to its documented pre-maintenance state. Where to check: Cluster settings under vSphere HA. Corrective action if unsuccessful: Do not leave the cluster unintentionally unprotected; restore the setting after confirming connectivity.

Validation area: Alarms and events. Expected result: No unresolved maintenance-related HA, host, network, storage, or virtual machine alarms remain. Where to check: vCenter alarms, events, tasks, and external monitoring. Corrective action if unsuccessful: Acknowledge only understood alarms and investigate recurring or unknown conditions.

Troubleshooting

The ESXi host cannot enter maintenance mode

Likely causes include powered-on virtual machines, unavailable vMotion, insufficient destination capacity, restrictive placement rules, reservations, incompatible CPU features, local storage, or devices that cannot be migrated.

1. List the remaining virtual machines on the host.
2. Review each migration task and its specific error.
3. Check destination capacity, compatibility, storage, networking, reservations, affinity rules, licensing, and connected devices.
4. Resolve the migration issue or obtain approval for a graceful shutdown.
5. Confirm that the host is empty, then retry maintenance mode.

HA alarms or recovery actions appear during planned network work

Host Monitoring may not have been disabled, the change may have affected more hosts or paths than expected, or network redundancy may not have worked. First assess the current host and virtual machine state; do not make additional changes based only on an alarm.

Restore stable management connectivity, confirm which workloads are running, verify the cluster HA setting, and investigate the failed network path. If a recovery action may have started, check for duplicate or unexpectedly restarted workload instances before changing power states.

Virtual machines cannot be migrated off the host

Check vMotion network availability, destination capacity, CPU compatibility, storage access, affinity policies, reservations, connected devices, pass-through hardware, and licensing. Adjust the maintenance plan or use an approved shutdown path. Do not begin host network maintenance while workload handling remains unknown.

The host remains disconnected after network maintenance

Common causes include an incorrect VLAN, port group, uplink, switch port, MTU, routing configuration, or management vmkernel setting. Validate the physical switch and virtual networking configuration against the approved design. Check management reachability, uplink status, and physical redundancy. Keep Host Monitoring disabled until stable connectivity is confirmed, then restore normal HA settings.

Exam-relevant notes

• Network connectivity loss can resemble an ESXi host failure to vSphere HA.
• Host Monitoring controls host heartbeat-based failure detection; maintenance mode controls host workload participation.
• Disabling Host Monitoring is temporary and reduces automatic host-failure protection during the change.
• Powered-on virtual machines must be migrated or shut down before a host can fully enter maintenance mode.
• VM Monitoring and Host Monitoring are separate concepts.
• VM-specific HA overrides can change recovery behavior from the cluster default.
• Restore network and management health before re-enabling Host Monitoring.
• For shared network changes, use rolling maintenance and preserve workload and failover capacity.

For related material within this lesson path, see network maintenance and vSphere HA.