Storage vMotion Data Transfer Interrupted – Fixes

Cause 1: Network Packet Loss or Latency Spikes

You're in the middle of a Storage vMotion—maybe 67% done, maybe 92%—and bam, the task fails. The error says "Data transfer interrupted." Nine times out of ten, it's the network.

Storage vMotion uses the VMkernel network stack to move disk blocks. If that connection drops a single packet or latency jumps above 50ms, the migration aborts. I've seen this happen on shared 1GbE links where a backup job suddenly starts. The real fix isn't changing the migration timeout—it's isolating the traffic.

Check your current setup

1. Log into your vCenter Server via the vSphere Client.
2. Go to the ESXi host that's running the source or target VM.
3. Click the Configure tab, then Networking, then VMkernel adapters.
4. Look for a VMkernel adapter that has the vMotion service enabled. If you see one assigned to a single 1GbE uplink, that's your bottleneck.

After checking, you should see that many setups share the vMotion network with management or NFS traffic. That's trouble.

Fix: Dedicated vMotion network with jumbo frames

1. Create a new standard or distributed switch port group dedicated to vMotion. Use a separate VLAN if possible.
2. Assign at least two physical NICs (10GbE preferred) to this port group.
3. On the VMkernel adapter for this port group, enable only the vMotion service—disable everything else.
4. Enable jumbo frames (MTU 9000) on both the physical switch ports and the vSwitch port group. Skip this if your network team says no—they'll be wrong, but you can still get 70% of the benefit without jumbos.
5. Test with a vmkping command from the ESXi host's console to the target host's vMotion IP (use -d for jumbo frames if enabled).

After these changes, retry the Storage vMotion. You should see steady throughput around 95% of your NIC line rate. If you still get drops, move to the next cause.

Cause 2: Queue Depth Limits on the Storage Array

Sometimes the network is fine but the storage array can't keep up. This happens more on older arrays or during heavy I/O windows. The symptom is a vMotion that starts fast, then slows to a crawl, then fails with "data transfer interrupted" after 30–60 minutes.

The queue depth is how many I/O operations the ESXi host can send to the storage target at once. When it's too low, the vMotion writer thread stalls. VMware sets default queue depths conservatively—around 64 per path. For most modern arrays, you can bump that up a lot.

Check current queue depth

1. SSH into the ESXi host (or use the DCUI if you prefer clicking).
2. Run: esxcli storage core device list | grep -A 2 "Queue Depth"
3. You'll see output like Queue Depth: 64. If it's under 128, that's a candidate.

Fix: Increase queue depth for the target datastore device

1. Identify the device NAA ID for the datastore where the VM's disks live. Run: esxcfg-scsidevs -a | grep naa. Pick the one matching your datastore's LUN.
2. Set the queue depth to 256: esxcli storage core device set -d naa.XXXXXXXXXXXX -O 256. Replace X with your actual NAA ID.
3. Verify: esxcli storage core device list -d naa.XXXXXXXXXXXX | grep Queue. You should see Queue Depth: 256.

Important: don't go above 256 unless your array vendor approves. Some older arrays (IBM V7000 Gen1, Dell Compellent) will start dropping I/O above 128. Test in a maintenance window.

After the change, the Storage vMotion should run at full speed. If it still fails, the array itself might be saturated. You can also check the array's read/write latency—anything above 20ms average will cause timeouts.

Cause 3: Incorrect TCP Stack Tuning for vMotion

I almost never see this in new vSphere 8 installs, but vSphere 6.5 and 6.7 hosts that were upgraded are often a mess. The default TCP stack for vMotion uses a small send/receive buffer (64KB). That works fine for 1GbE, but on 10GbE or faster, it chokes. You'll see the data transfer rate jump from 500 Mbps to 2 Gbps then drop to zero, over and over. The migration finishes eventually—if it doesn't time out first.

The fix is to apply the recommended vMotion TCP tuning parameters. VMware published these in KB 1027528. They still work.

Fix: Apply TCP tuning to the vMotion VMkernel adapter

1. SSH into the ESXi host.
2. Find the vMotion VMkernel adapter's interface name: esxcli network ip interface list. Look for the one with the vMotion IP. It's often vmk1 or vmk2.
3. Set the TCP send and receive buffers to 4MB (4194304 bytes):
   esxcli system settings advanced set -o /Net/TcpipHeapSize -i 32
esxcli system settings advanced set -o /Net/TcpipHeapMax -i 128
4. Then set per-connection buffers on the vMotion interface:
   esxcli system settings advanced set -o /Net/TcpipDefTOS -i 184
esxcli system settings advanced set -o /Net/TcpipSendBuffer -i 4194304
esxcli system settings advanced set -o /Net/TcpipRecvBuffer -i 4194304
5. Reboot the host for these changes to take effect. Yes, a reboot. I know it hurts, but the TCP heap settings require it.

After reboot, run a Storage vMotion test. You should see a flat line at your NIC's throughput until the migration finishes. No sawtooth pattern.

One more thing: if you're using NFSv3 datastores, check that the mount options include hard and nfsvers=3. Soft mounts will silently drop I/O during vMotion. That's a common hidden issue.

Quick-Reference Fix Table

If none of these fix the issue, check the VM's own I/O profile. A VM with a single queue disk (like a legacy RHEL 6 guest) can't keep up with modern vMotion speeds. Upgrade the VM's paravirtual adapter to VMware Paravirtual SCSI controller—that alone can double vMotion throughput.