Storage vMotion fails with network timeout on vSphere 7/8

Just the fix (30 seconds)

Check if your ESXi hosts have a dedicated vMotion vmkernel interface. If they don't, storage vMotion steals bandwidth from management or VM traffic. The fastest check: SSH into each host and run esxcli vmkernel port list | grep -A5 'vMotion'. If nothing returns, you're probably running storage vMotion over the management network. That's your problem.

Temporary workaround: increase the storage vMotion TCP timeout. On each host, run:

esxcliq system settings advanced set -o /LSOM/swapTimeout -i 120

Default is 30. Bumping to 120 buys you time but doesn't fix the root cause. Do this only if you need the migration done right now.

If that alone resolves the timeout, you've got a bandwidth contention issue. Plan for a dedicated vMotion network next.

Moderate fix (5 minutes)

The real fix is making sure your vMotion network has jumbo frames (MTU 9000) and is on a separate VLAN or physical NIC. Here's the process:

1. Go to each ESXi host in the vSphere Client, navigate to Networking > VMkernel adapters.
2. Edit the vMotion vmkernel adapter and set MTU to 9000.
3. Make sure the physical switch ports and the vSwitch itself also have MTU 9000. Jumbo frames drop CPU overhead on TCP segmentation and let large storage blocks transfer without fragmentation.
4. Still have the timeout? Check if the physical NICs for vMotion are on a different PCIe slot than storage adapters. If they share lanes (common on single-socket hosts), you get IO contention that mimics a network timeout.

Why jumbo frames help: Storage vMotion uses TCP to move VM disk data. With standard MTU (1500), each 64 KB block from the storage stack gets split into ~43 packets. With MTU 9000, it's ~7 packets. Fewer interrupts per block, less CPU burn, and the TCP window fills faster. VMware's own tests show up to 40% faster migrations with jumbo frames on 10 GbE.

Advanced fix (15+ minutes)

If you're still seeing timeouts after jumbo frames and a dedicated network, the issue is deeper. Three things to check:

1. TCP offload and ring buffer settings

Modern NICs (Intel X710, Mellanox ConnectX-5) have hardware offloads for TCP segmentation and checksums. If your switch or hypervisor misconfigures these, you'll get silent packet drops that manifest as timeouts. On each ESXi host:

esxcli network ip tcp get
net.sched.enable_tso = 1
net.sched.enable_lro = 1

If TSO or LRO are disabled, turn them on:

esxcliq system settings advanced set -o /net/sched/enableTSO -i 1
esxcliq system settings advanced set -o /net/sched/enableLRO -i 1

2. TCP window scaling

Storage vMotion across higher latency links (metro clusters, stretched clusters) hits the TCP window limit fast. Check your current window size:

esxcli system settings advanced list -o /Net/TcpipHeapSize

Default is 1024 MB. If your RTT is above 1 ms (common in stretched clusters), bump it to 2048:

esxcliq system settings advanced set -o /Net/TcpipHeapSize -i 2048

Also increase the TCP receive window:

esxcliq system settings advanced set -o /Net/TcpipDefRecvWin -i 1048576

Default is 256 KB. Jump to 1 MB. This lets the host acknowledge more data before waiting for an ACK, directly reducing timeout risk on high-latency links.

3. Check for NVMe TCP or iSCSI interactions

If your storage is NVMe over TCP or iSCSI, those protocols also use the same physical NICs. They can starve storage vMotion for buffer space. Look at the vmkernel log during a migration:

tail -f /var/log/vmkernel | grep -i timeout

If you see "NFS operation timed out" or "iSCSI operation timed out" alongside your vMotion timeout, you're saturating the network path. In that case, you need a separate physical network for storage traffic — VLANs won't fix buffer starvation.

When to call in the network team

One last thing: I've seen cases where the timeout is actually caused by a switch STP reconvergence or a flapping port. If your vMotion network uses multiple switches (for redundancy), and one switch reboots, the STP convergence can drop packets for several seconds. ESXi's TCP stack doesn't handle that gracefully. Enable edge port (PortFast on Cisco) on all vMotion switchports to bypass STP delays. That's a 2-second fix from the switch side.

Most of the time, jumbo frames + dedicated vMotion NIC + proper switch config kills the timeout. The advanced TCP tunings are for edge cases like stretched clusters or converged networks. Start simple, escalate only if needed.