A VM's disks are moved to another datastore with Storage vMotion. It takes hours longer than the change window allowed. The first question is not how to make it faster, but who did the copying: the storage array, or the ESXi host.
On block storage, ESXi can ask the array to copy the data itself. The vSphere 8.0 guide calls this full copy: "Storage arrays can make full copies of data within the array without having the host read and write the data." When that cannot happen, the host reads and writes every block. This article records which of the two happened and why, so the owners can decide what to do next. It does not promise any speed.
Scope
ESXi 8.0, VMFS datastores on Fibre Channel or iSCSI. Every step is a read. Not covered: NFS datastores, vSAN, Content Library deployments, clones, and any change. Storage latency and benchmarking have their own published articles: benchmark VMware storage with DiskSpd and diagnose VMware and vSAN storage latency.
When the host does the copy itself
The vSphere 8.0 guide says that when a device does not support an operation, or supports it only in part, "your host reverts to its native methods to perform unsupported operations." It also lists cases where "The VMFS data mover does not leverage hardware offloads and instead uses software data movement":
| No | Documented condition (vSphere 8.0) |
|---|---|
| 1 | "The source and destination VMFS datastores have different block sizes." |
| 2 | "The source file type is RDM and the destination file type is non-RDM (regular file)." |
| 3 | "The source VMDK type is eagerzeroedthick and the destination VMDK type is thin." |
| 4 | "The source or destination VMDK is in sparse or hosted format." |
| 5 | "The source virtual machine has a snapshot." |
| 6 | The logical address and transfer length are not aligned to the device's minimum. Datastores created with the vSphere Client are aligned automatically |
| 7 | "The VMFS has multiple LUNs or extents, and they are on different arrays." |
| 8 | "Hardware cloning between arrays, even within the same VMFS datastore, does not work." |
KB 431479 (all ESXi versions) adds that when the source and destination hosts lack shared access to both datastores, the copy goes over the network with Network File Copy (NFC) instead.
Step 1: record the migration
| Field | What to record |
|---|---|
| A | VM, source and destination datastore, source and destination host, ESXi version and build |
| B | Migration type: storage only, or host and storage together; start and end time with time zone, from the task list |
| C | Size of each disk moved, and its format at source and destination (thin, lazy zeroed thick, eager zeroed thick, RDM) |
| D | Whether the VM had snapshots when the migration ran |
| E | Duration and average throughput, worked out the way KB 383770 (ESXi 7.x/8.x) does: "Average Throughput = (Total Data Size / Transfer Duration)" |
Step 2: record the two datastores and their devices
| Field | What to record |
|---|---|
| F | VMFS version and block size of each datastore |
| G | Each datastore's devices (extents), and the array each one is on |
| H | Whether source and destination are on the same array |
| I | Hardware Acceleration status of each datastore and device as the vSphere Client shows it |
| J | For each device: esxcli storage core device list -d <device ID>, the "VAAI Status" line |
| K | Which hosts can see each datastore |
| L | The host's DataMover.HardwareAcceleratedMove value, read only, and whether anyone has changed it |
Read I and J with the guide's meaning. The status starts as Unknown; "For block devices, the status changes to Supported after the host successfully performs the offload operation. If the offload operation fails, the status changes to Not Supported." Unknown can also mean partial support. A Supported status shows the device has offloaded before, not that this migration was offloaded.
Step 3: record the log lines
From the source host's /var/run/log/vmkernel.log, keep the lines around the migration window that mention XCOPY, VAAI or a data copy fallback, with times. KB 431479 describes "VAAI/XCOPY failures (such as Error Code 24) immediately followed by the system falling back to Network File Copy (NFC)." Record the exact text you see. No matching line is recorded as such; it does not prove the copy was offloaded.
Step 4: classify
| What the record shows | Candidate explanation | Handed to |
|---|---|---|
| H says different arrays, or G shows extents on different arrays | Documented condition 7 or 8: software copy expected | Storage owner |
| F shows different block sizes | Condition 1 | vSphere owner |
| C shows RDM to non-RDM, eager zeroed thick to thin, or a sparse or hosted disk | Conditions 2 to 4 | vSphere owner |
| D shows a snapshot | Condition 5 | vSphere owner |
| K shows the hosts could not both see both datastores | Network copy path (KB 431479 pattern) | vSphere and network owners |
| J shows Not Supported or Unknown, or L shows 0 | The host may not try the offload, or the device may not support it | Storage owner, with the array vendor |
| Step 3 shows XCOPY errors followed by a fallback | Offload tried and failed; the error code goes to the array vendor | Storage owner |
| None of the above, and E is still below expectation | Offload use remains unconfirmed on this record; investigate latency and fabric alongside it | Storage owner |
More than one row can apply. A matched condition explains why the host copied the data; it does not say how fast that copy should have been.
What this record does not authorise
This record does not authorise changing DataMover.HardwareAcceleratedMove, changing path selection, converting disks, deleting snapshots, mounting datastores on other hosts, changing VMkernel services, or running a test migration or benchmark. KB 319439 says turning that setting off takes effect "immediately without requiring any Host reboot", for every array on the host.
The owners decide, with at least:
- whether the slow copy was expected from the conditions found, and whether the next migration should be planned around them;
- whether the array vendor needs the device status and error lines;
- who approves any change, under its own change record.
Worked example (fictional)
The values below are invented. VM erp-db-01, 4 TB of disks, storage-only move from fc-a-ds07 to fc-b-ds02 on host esx-21, ESXi 8.0 U3. Planned four hours, took eleven, 22:00 to 09:00 AEDT.
| Field | Value |
|---|---|
| C | Two eager zeroed thick disks, destination thin |
| D | One snapshot from a backup job |
| E | 4,096 GB in 11 hours, about 103 MB/s |
| F | VMFS 6, 1 MB blocks on both |
| H | Different arrays: fc-a-* on array A, fc-b-* on array B |
| J | Both devices: VAAI Status: supported |
| Step 3 | No XCOPY lines found |
Classification: conditions 3, 5 and 8 all apply. The host was expected to copy the data itself, so the device status and the missing XCOPY lines are consistent with that. The record goes to the storage owner and the vSphere owner. Nothing is changed.
Acceptance checks
- Fields A to L are recorded, or marked not available with the reason, with times and time zone.
- Every matched condition is named by its number from the 8.0 list.
- A Supported status is not taken as proof that this migration was offloaded.
- No speed figure is promised for any change.
- Nothing was changed and nothing was migrated to test. Reading needs no rollback.
Learning notes
- Full copy lets the array copy data without the host reading and writing it.
- The vSphere 8.0 guide lists exact cases where the host copies data itself; copying between arrays is one.
- Device status Supported means an offload has worked before, not that it worked this time.
- Explaining the slow copy comes before any change to settings.
Related articles
- Published: How to benchmark VMware storage with DiskSpd without confusing caches and capacity
- Published: How to diagnose VMware and vSAN storage latency
- Published: CBT lost after Storage vMotion, HA restart or power loss
Sources
Retrieved 2026-11-03 between 21:38 and 21:40 UTC (morning of 4 November, Australia/Sydney). Dates are each page's own Updated On or Last Updated date.
- Broadcom TechDocs, vSphere 8.0, "Storage Hardware Acceleration in vSphere", 28 October 2026. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-storage/storage-hardware-acceleration-in-vsphere.html
- Broadcom TechDocs, vSphere 8.0, "vSphere Hardware Acceleration for Block Storage Devices", 28 October 2026. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-storage/storage-hardware-acceleration-in-vsphere/vsphere-hardware-acceleration-on-block-storage.html
- Broadcom TechDocs, vSphere 8.0, "Verify Hardware Acceleration Support Status", 28 October 2026. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-storage/storage-hardware-acceleration-in-vsphere/vsphere-hardware-acceleration-on-block-storage/managing-hardware-acceleration-filter-and-plug-ins/verify-hardware-acceleration-support-status.html
- Broadcom KB 431479, "Slower transfer speed when migrating to different datastore type", 26 June 2026. https://knowledge.broadcom.com/external/article/431479/slower-transfer-speed-when-migrating-to.html
- Broadcom KB 383770, "Troubleshooting Slow Storage vMotion", 2 October 2025. https://knowledge.broadcom.com/external/article/383770/troubleshooting-slow-storage-vmotion.html
- Broadcom KB 319439, "Disabling Hardware Accelerated Move (XCOPY) in ESXi", 8 April 2026. https://knowledge.broadcom.com/external/article/319439/disabling-hardware-accelerated-move-xcop.html