ESXi host hangs in Maintenance Mode due to missing virtual machine .vswp file

Products

• VMware vSphere ESXi

Issue/Introduction

A vSAN-enabled ESXi host takes an exceptionally long time (e.g., over 9 hours) to complete a Maintenance Mode evacuation during a patching window (such as a vSphere Lifecycle Manager image-based update).

Virtual machine migration (vMotion) halts or hard-fails, leaving the host hung at a high percentage.

The vSphere Client displays a missing swap file error for a specific virtual machine attempting to migrate off the host.

A vSphere High Availability (HA) event or alarm is triggered during the 9-hour window, displaying messages such as "vSphere HA agent on this host is disabled" or "Configuring vSphere HA".

In the /var/log/hostd.log file on the source ESXi host, you see errors confirming the vSAN descriptor is missing:

Unable to the read the descriptor file '/vmfs/volumes/vsan:.../vm-name.vswp' (No such file or directory)
Failed to get vm swap objectId... No such file or directory.

in /var/log/fdm.log file, you see state changes for the HA agent without an actual host failure or isolation:

isolated=false
Cluster state changed: Slave -> Startup

Environment

VMware ESXI 8.0x

vCenter SErver 8.0x

vSAN 8.0x

Cause

This issue occurs when a virtual machine's swap descriptor file (.vswp) is missing from the vSAN namespace. Virtual machine swap files are often deployed with no redundancy (FTT=0). A previous storage micro-outage or cluster event can orphan the swap descriptor file. Because the VM is already running in memory, it continues to function normally until a vMotion is attempted.

When DRS attempts to vMotion the virtual machine to complete the compute evacuation for Maintenance Mode, the source host cannot locate the descriptor file within the vSAN datastore to transfer the active memory state. The vMotion fails.

Because Maintenance Mode relies on DRS to clear the host, the task does not gracefully time out when a compute evacuation fails. The host simply remains stuck waiting indefinitely—resulting in hours-long delays. After a prolonged period of unresponsiveness, vCenter or automated lifecycle operations may restart the host's Fault Domain Manager (FDM) service to try and unstick the host. This agent restart (transitioning from Slave to Startup) generates the transient HA configuration alarm in vCenter, which is a symptom of the hang, not a cluster failover.

Resolution

To resolve this issue, the orphaned virtual machine swap file must be cleanly recreated. Simply rebooting the Guest OS will not resolve the issue, as the virtual hardware remains powered on and maintains the stale swap configuration.

1. Identify the virtual machine that is failing to migrate by reviewing the hostd.log for the missing .vswp file path.

2. Initiate a graceful Guest OS shutdown for the identified virtual machine.

3. Wait for the virtual machine to fully power off.
Note: This action forces the ESXi host to release any stale vRAM locks and drop the existing, corrupted swap configuration from the vSAN namespace.

4. Power On the virtual machine.
Note: Upon boot, the ESXi host will generate a brand new, healthy .vswp descriptor and data object on the datastore.

5. Perform a test vMotion to confirm the virtual machine can successfully migrate between hosts.

6. Re-attempt the host Maintenance Mode operation.

Important Note: If the ESXi host is still hung in a "Entering Maintenance Mode" state, you may need to cancel the current Maintenance Mode task in vCenter or restart the management agents (services.sh restart) on the affected host before attempting the steps above.