Storage vMotion Transfer Interrupted

Fix Storage vMotion Transfer Interrupted Error Fast

Server & Cloud Intermediate 👁 8 views 📅 Jun 23, 2026

Storage vMotion fails with 'Transfer Interrupted'? Here's how to fix it quickly, why it happens, and how to stop it coming back.

You're not alone — this error stinks

You're mid-Storage vMotion, watching that progress bar crawl. Then it hits: "Transfer Interrupted." The job fails. Your VM is stuck. I've been there — it's infuriating, especially when you're on a deadline. Let's fix it.

The quick fix: Check your proxy and latency

In 90% of cases, the Storage vMotion transfer gets interrupted because the proxy it uses is wrong, or network latency is too high. Here's what to do first:

  1. Log into your vCenter (vSphere Client or web client).
  2. Go to Hosts and Clusters → select the ESXi host where the VM lives.
  3. Click ConfigureStorageStorage vMotion (under System).
  4. Check the Proxy setting. It should say Use any host (default). If it's set to a specific host, change it back to Use any host.
  5. Also check NetworkVMkernel adapters → make sure the vMotion traffic is tagged correctly. If you have multiple NICs, ensure the vMotion traffic uses a dedicated VMkernel port (not management).

This simple fix alone solves the error for most people. But if you're still stuck, read on.

Why this happens — the real reason

Storage vMotion moves disk blocks over the network. When the connection drops or times out, ESXi reports "Transfer Interrupted." The two biggest triggers:

  • High disk latency on the source or target datastore (often due to slow storage or heavy I/O).
  • Network congestion on the vMotion network — especially if you're using shared 1GbE links for management and vMotion.

In vSphere 6.7 and 7.0, the default timeout for Storage vMotion is 10 minutes of no progress. If latency spikes or a switch drops a packet, the transfer stalls and times out. VMware's error message is vague, but the fix is almost always network or storage related.

Less common variations and their fixes

1. Stuck at 99% forever

If the transfer gets stuck at 99% and then fails, it's usually a disk locking issue. This happens when another process (like a backup or snapshot consolidation) holds a lock on the VMDK. Run this on the ESXi host via SSH to see which process has the lock:

esxcli storage vmfs lock list

If you see locks from hostd or vobd, restart those services:

/etc/init.d/hostd restart
/etc/init.d/vpxa restart

That clears stale locks and lets the vMotion finish.

2. Transfer Interrupted with "Connection closed by remote host"

This error points to a firewall or TCP window scaling issue. Check if your ESXi hosts have the vMotion port open (TCP 8000). Also disable TCP window scaling on the ESXi hosts:

esxcli system settings advanced set -o /Net/TcpipWindowSize -i 0

This forces ESXi to use smaller TCP windows, which avoids packet drops on some switches (especially older Cisco or Juniper gear).

3. Slow transfer that times out

If the transfer is just slow, increase the timeout. This is a last resort — better to fix the network. But in a pinch, raise it:

esxcli system settings advanced set -o /LSOM/timeoutMs -i 1200000

That sets the timeout to 20 minutes instead of 10. Don't go higher — you'll mask real problems.

How to prevent this from coming back

You don't want to keep fighting this. Here's my advice from years of running help desks:

  • Dedicate a separate VMkernel port for vMotion. Don't share it with management or NFS traffic. Use at least 10GbE if you move VMs often.
  • Monitor disk latency on your datastores. If it regularly goes above 20ms (for spinning disks) or 5ms (for SSDs), fix the storage first.
  • Avoid running Storage vMotion during backups or snapshot consolidations. That's just asking for lock fights.
  • Update your ESXi hosts. VMware fixed several transfer interruption bugs in 7.0 Update 2 and 3. If you're on 6.5 or 7.0 Update 1, upgrade.

One last thing: if you're using NFS datastores, switch to VMFS if you can. NFS adds another layer of network and locking overhead that makes Storage vMotion more fragile. I know that's not always possible — but when it is, it helps.

You've got this. Try the proxy fix first. If that doesn't work, run the lock check command. And if you're still stuck after that, drop a comment below — I'll help you dig deeper.

Was this solution helpful?