Slower transfer speed when migrating to different datastore type
Article ID: 431479
Updated On:
Products
Issue/Introduction
You observe severely degraded performance, unutilized network capacity, and extended migration windows when performing Storage vMotion operations across disparate environments.
Your Storage vMotion migration speeds are significantly slower (averaging 500–700 MB/s or less) when you migrate between different storage types (e.g., NFS to FC/vSAN) or between different physical storage arrays (e.g., EMC to Pure).
Your migration durations for large, thick-provisioned VMs (10TB+) exceed your planned maintenance windows.
Your physical NIC speeds (10G/25G) are not fully utilized during the migration, and throughput fails to scale with your available physical bandwidth.
If you review your in-depth ESXi host logging (/var/log/vmkernel.log), you see VAAI/XCOPY failures (such as Error Code 24) immediately followed by the system falling back to Network File Copy (NFC).
Environment
ESXi (all versions)
Mixed storage types (eg, EMC and Pure, Fiber Channel to vSAN)
Cause
This issue occurs because your migration cannot leverage vStorage APIs for Array Integration (VAAI) hardware offloading (such as XCOPY). Your system automatically bypasses VAAI and reverts to slower software methods when you migrate across different storage types (such as vSAN to SAN/FC) or between separate physical arrays (such as EMC to Pure), use mismatched VMFS block sizes, or perform an Enhanced vMotion where your source and destination hosts lack shared visibility to both datastores.
Your system will drop VAAI offloading and revert to software methods under the following conditions:
You are converting an eagerzeroedthick disk to thin, converting an RDM to a non-RDM format, or utilizing any kind of sparse or hosted disk formats.
You are migrating a virtual machine that has snapshots, which forces your host to actively consolidate the snapshots into the target virtual disks during the transfer.
Your VMFS datastore has multiple LUNs/extents spread across different arrays, or the logical address/transfer length is not aligned to the minimum required by your storage device.
When this bypass occurs, your environment defaults to one of two software-based fallback paths:
If your migration occurs within the same host context, your system falls back to the Software Data Mover to traverse your local storage fabric paths.
If your data transfer must cross distinct hosts or unshared storage clusters, your system invokes NFC, routing the traffic directly over your management/vMotion network stack (requiring bidirectional connectivity over TCP port 902).
Falling back to these software-driven methods introduces severe architectural constraints on your environment:
Both the Data Mover and NFC operate on a single-threaded, synchronous, serial "Read-Write-Acknowledge" cycle, capping speeds well below your raw fabric bandwidth. Furthermore, if traffic defaults to NFC, it uses SSL encryption and is generally limited to a 1Gbps ceiling by design.
Without VAAI, your ESXi host cannot offload commands to the storage array. It must actively read and write every block itself, directly draining your host CPU cycles and memory buffers.
If you migrate thick-provisioned disks, your host must sequentially process every empty block. Conversely, with thin-provisioned disks, your system instantly skips unallocated space, which is why your other environment workloads complete in significantly shorter timeframes.
Resolution
This behavior operates as intended when you migrate data to a different storage solution or to an unshared datastore on a completely separate array. Because your system cannot use VAAI, it must revert to the slower Network File Copy (NFC) method. By default, NFC utilizes your Management network unless you have configured a dedicated Provisioning TCP/IP stack or enabled the provisioning service on your vMotion network.
To optimize these software-based migrations within your environment, you can implement the following adjustments:
You should convert your target VMs to thin-provisioned disks prior to your migration window, which allows the Data Mover or NFC engine to instantly skip unallocated space.
You should run UNMAP or TRIM operations within your guest OS ahead of the migration to maximize the amount of skippable, empty blocks.
You should change your destination array's Path Selection Policy (PSP) to Round Robin and tune it to iops=1, which helps balance the sequential block stream across all available paths and prevents single-path fabric saturation.
You should ensure that the Provisioning traffic service is enabled on your vMotion VMkernel adapters; if you are running vSphere 8.x, this configuration unlocks Unified Data Transport (UDT) to more efficiently stream bulk data for your large VMs over high-bandwidth links.
You should verify that your storage fabric is free of CRC errors and physical layer issues, as even minor packet drops will cause severe retransmission throttling due to the synchronous nature of software-based transfers.
Additional Information
Feedback
