Storage vMotion fails with 'Cannot open file for write' error

I know this error is infuriating — your Storage vMotion hits 95%, then throws 'Cannot open file for write' and just sits there. You've checked permissions, the datastore isn't full, and everything looks fine on the surface. But there's a reason it's stuck. Let's fix it.

The fastest fix: Kill the leftover process

Most of the time, this happens because a previous vMotion or snapshot operation left a stale lock. The file that can't be written to is usually the VM's .vmsd or a snapshot .vmdk delta file. Here's what to do:

1. SSH into the ESXi host where the VM is registered. If SSH isn't enabled, enable it in the host's Security Profile settings.
2. Run esxcli storage vmfs snapshot list to see any active or orphaned snapshots on the datastore.
3. If you see a snapshot that doesn't match the VM's current state, remove it with vim-cmd vmsvc/snapshot.removeall [VMID]. Get the VMID by running vim-cmd vmsvc/getallvms.
4. Still stuck? Check for a .lck file on the VM's folder: ls -la /vmfs/volumes/[datastore]/[VM]/ and delete any orphaned .lck files. Use rm -rf *.lck — but only after confirming the VM isn't actively writing.
5. Finally, retry the Storage vMotion from the vSphere Client.

This worked for a client last week who'd been fighting the error for 3 hours. The .lck file was from a failed snapshot consolidation that nobody had cleaned up.

Why this happens

The 'Cannot open file for write' error is VMware's way of saying: 'I can't get exclusive write access to this file.' It's not a permission problem — it's a lock problem. When Storage vMotion tries to open a delta disk file (like VM-000001.vmdk), the file must not be in use by any other process. Stale locks from previous operations, orphaned snapshots, or even a second vMotion attempt from another vCenter server can all trigger this.

The real culprit is almost always the SCSI reservation held by a previous operation that didn't clean up properly. The VMFS datastore uses SCSI reservations to coordinate writes between hosts. If a host crashes or a process hangs, the reservation sticks around. Clearing the lock file releases that reservation.

Less common variations

Variant 1: Cross-datastore vMotion fails with 'Cannot open file'

This happens when the source and target datastores are on different storage arrays, and the lock isn't released during the migration. If the above fix doesn't work, try migrating the VM to a different host first, then retry the storage vMotion. That shuffles the SCSI reservation and often clears the lock.

Variant 2: Error only on certain hosts

If the error only appears when vMotioning from one specific ESXi host, check that host's storage stack. I've seen this happen when a host has a pending storage array path failure that's not visible in the UI. Run esxcli storage core path list to see if any paths are dead. If they are, rescan the storage adapter or reboot the host.

Variant 3: Error after a VM clone or template deployment

When you clone a VM and then try a Storage vMotion, the clone process can leave a temporary lock on the source disk. The fix here is to wait 2-3 minutes after cloning — don't rush the vMotion. If it's already stuck, delete any orphaned snapshots from the clone operation using the same vim-cmd command above.

Prevention: Don't let locks pile up

The easiest way to avoid this is to never cancel a vMotion mid-transfer. If you need to stop it, let it fail gracefully. Also, keep an eye on snapshot consolidation — if it fails, fix it immediately. A good rule: run vim-cmd vmsvc/snapshot.get [VMID] once a week on critical VMs to check for orphaned snapshots.

Another prevention step: use separate datastores for different workloads. When you mix high-I/O VMs on the same datastore, lock contention rises. Keep your VDI or SQL Server VMs on their own datastores to reduce the chance of lock conflicts during migrations.

One more thing: if you're running vSphere 7.0u2 or newer, use the 'upgrade' option in Storage vMotion to let it use the newer, more stable path. It handles lock conflicts better than the classic mode.

If you've tried all this and the error still shows up, check the host's syslog at /var/log/hostd.log. Search for 'Cannot open file' — the exact file path it complains about will tell you if it's a snapshot file, a VM swap file, or something else. That narrows the hunt fast.