Storage vMotion Fails: Quick Fixes for VM Migration Errors

1. Snapshot locks are the #1 cause

You try to Storage vMotion a VM and it just sits there. Or it fails after 15 minutes with a generic error. What's actually happening here is a lock on the snapshot chain. VMware ESXi (6.7 through 8.x) won't move a VM if any snapshot is in an inconsistent state or if the .vmdk delta files are still being written to.

I see this most often on VMs running databases or mail servers where the backup software snaps the disk, the backup completes, but the snapshot doesn't get deleted cleanly. The snapshot delta file stays behind, and vCenter treats it as a live snapshot. Storage vMotion can't move it because it can't get a consistent point to copy.

Check for hidden snapshots

1. Right-click the VM in vCenter and go to Snapshots > Manage Snapshots. If you see anything there, delete it.
2. If the snapshot list is empty but the VM still fails, SSH into the ESXi host (or use the vSphere CLI) and run this command for the VM:

vmkfstools -v10 /vmfs/volumes/datastore1/VMname/VMname.vmdk

Look for lines that say something like delta.vmdk or child disk. If you see a delta file but no snapshot in the UI, you've got a stuck snapshot.

Fix: Remove orphaned snapshots

1. Make a backup of the VM first. Really. I've seen snapshot consolidation go wrong.
2. Right-click VM > Snapshots > Consolidate. This merges any remaining delta files back into the base disk.
3. Wait for the consolidation task to finish. Then try the Storage vMotion again.

The reason step 3 works is consolidation forces ESXi to grab an exclusive lock on the VMDK chain, merge deltas, and release old locks. After that, vMotion can get its own lock.

2. Datastore latency or I/O queue saturation

Second most common cause: the source or target datastore is slow. Not always obviously slow — sometimes it's fine for reads but has high write latency under load. Storage vMotion needs to read blocks from the source and write them to the target. If the target can't keep up, the operation times out after default 180 seconds.

I've hit this on shared NFS datastores with too many VMs, and on local SAS arrays with a single spindle failing. The vMotion fails with Timeout or I/O error messages.

Check datastore performance

1. In vCenter, go to Monitor > Performance for both the source and target datastores.
2. Look at Average latency (in ms) and Commands aborted. Anything above 15ms for writes is risky for Storage vMotion.
3. Check the ESXi host's storage adapter too: Host > Storage > Storage Adapters > pick the HBA > look for Reservation conflicts. High counts mean SCSI reservation collisions.

Fix: Reduce load or increase timeouts

1. Move some VMs off the slow datastore temporarily. Even pausing backup jobs helps.
2. Increase the Storage vMotion timeout. On the ESXi host, edit /etc/vmware/config and add this line (if it's not there):

vmotion.timeout = 600

That sets the timeout to 600 seconds (10 minutes). Reboot the host after changing it. Then try the vMotion again. This doesn't fix the root cause, but it gives the migration time to finish instead of failing halfway.

3. CBT (Changed Block Tracking) bug in older ESXi builds

This one's sneaky. Storage vMotion fails for a VM that has CBT enabled (used for backup tools like Veeam or vSphere Data Protection). The error looks like Cannot open the disk for read or Failed to quiesce the virtual machine.

What's happening inside: CBT creates a log file (vmname-ctk.vmdk) that tracks changed blocks. In ESXi 6.5 Update 2 and some 6.7 builds, this file can get corrupted or its metadata mismatches the base disk. Storage vMotion reads the CBT metadata first, gets confused, and aborts.

Check if CBT is the problem

1. Right-click VM > Edit Settings > VM Options > Advanced > Configuration Parameters.
2. Look for ctkEnabled. If it's set to true, that's your candidate.
3. Temporarily disable CBT: set ctkEnabled to false and remove the vmname-ctk.vmdk file from the datastore (if it exists).

Fix: Reset CBT

1. Power off the VM (yes, you need downtime for this).
2. Remove the CBT log file from the datastore using the Datastore Browser: delete vmname-ctk.vmdk and vmname-ctk.vmdk.ctk if present.
3. Power on the VM. vCenter will recreate the CBT files automatically.
4. Try Storage vMotion again. I've seen this fix work on VMs that couldn't move for months.

The reason this works: deleting the old CBT log forces ESXi to regenerate it from scratch. The new metadata matches the disk's actual layout, so vMotion can read it correctly.

Quick reference table