Diagnosing and Resolving a vSphere VM Stuck in Migration In Progress

Problem Overview

When a virtual machine (VM) appears in vCenter with the status "Migration in progress" and never completes, operators often suspect a network glitch or storage issue. The VM remains in a pending queue, consuming resources but not running. This guide walks through a structured diagnostic workflow that maps symptoms to root causes, checks, and corrective actions.

Common Causes

Cause	Typical Symptoms	Key Log Message
Network partition between source and destination hosts	Migration stalls, VM remains queued; host‑to‑host ping fails	"Unable to reach destination host"
Datastore lock or contention	Timeout after several minutes; no progress in vCenter; .vmx file locked	"VMX file lock" or "timeout"
ESXi host services (vpxa, vmknet0) unresponsive	VM pauses until services recover; event log shows service restart	"vpxa service restarted"
HA admission control or resource pool limits	Migration queued indefinitely; HA cluster reports insufficient resources	"Admission control failed"

Diagnostic Checklist

1. Verify host connectivity: ping source and destination host IPs from a management workstation.
2. Check ESXi host services: ensure vpxa and vmknet0 are running.
3. Inspect datastore locks: confirm no other host holds a lock on the VM’s .vmx file.
4. Review resource pool and HA settings for capacity constraints.
5. Examine vCenter Tasks & Events for detailed error messages.

Step‑by‑Step Troubleshooting

1. Host Connectivity

Run from a management machine or ESXi shell:

# ping -c 4 <destination-host-ip>
# esxcli network ip interface list | grep vmknet0

Expected: ICMP echo replies and vmknet0 status UP. If ping fails, check firewall rules or network switches. Risk: excessive ping traffic can trigger rate limits; use small count.

2. ESXi Service Health

On each host:

# esxcli system processes list | grep vpxa
# esxcli system services status | grep vpxa

If vpxa is not running, restart:

# esxcli system services restart vpxa

Verify the service is back online. If vmknet0 shows DOWN, investigate network stack or reset the interface.

3. Datastore Lock Detection

On the source host:

# esxcli storage vmfs lock list | grep <vmx-file-name>

If a lock is present, identify the holder host and either shut down the conflicting VM or move the lock by restarting the ESXi host. After clearing locks, re‑initiate the migration from vCenter.

4. Resource Pool & HA Admission Control

In vCenter:

Navigate to Cluster > Settings > Resources > Resource Pools.
Check the "Maximum Allocation" and "Reservation" settings.

Go to Cluster > Settings > vSphere HA > Admission Control.
Verify that the cluster has sufficient free CPU and memory for the migration target.

If limits are reached, either reduce the pool reservation or pause HA for the migration target host. After adjustment, retry migration.

5. Event Log Review

In vCenter, open the VM’s Tasks & Events tab. Look for entries like:

• Task: Migrate VM; Status: Error; Reason: Unable to reach destination host
• Task: Migrate VM; Status: Error; Reason: VMX file locked
• Task: Migrate VM; Status: Error; Reason: Admission control failed

These messages confirm the root cause identified earlier.

Escalation Criteria

• If the migration remains stuck after 30 minutes and all local checks pass, open a support ticket with VMware.
• When a datastore lock cannot be cleared without downtime, coordinate with storage operations to release or move the lock.
• If HA admission control consistently blocks migrations, consider adjusting cluster settings or adding capacity.

Limitations & Verification

The steps above assume vCenter 8.x and ESXi 8.x. Earlier versions may use slightly different commands (e.g., esxcli system services restart vmware-vpxa). Always verify host IPs and datastore paths before running commands. After each fix, confirm the VM status changes to Powered On or Powered Off and that no pending migration tasks remain.