Troubleshooting VMware vSphere Storage vMotion Performance Issues

Storage vMotion is designed to move a running virtual machine between datastores with minimal disruption. When the transfer takes far longer than expected, the visible symptom is usually a slow migration task, but the underlying cause may be storage latency, network contention, snapshots, host configuration, or an overloaded array.

A practical diagnosis starts with measurement rather than changing advanced settings. Record the VM’s provisioned and used capacity, the source and destination datastores, transfer duration, observed throughput, and any events reported by vCenter Server. A 500 GB thin-provisioned disk may contain only 40 GB of data, while a thick disk with free guest space can still require substantial block processing.

Australian environments often add operational constraints. A small team supporting sites in Sydney, Melbourne, Brisbane, and Perth may share one vCenter instance across several latency-sensitive links. Data sovereignty requirements can keep workloads in Australian cloud regions, while an organisation’s storage platform may still be managed by a local provider or an interstate operations team.

Schedule testing around business demand and the local working day. A migration that looks quick at 2 am AEST can compete with backups, Microsoft 365 traffic, or a morning reporting workload at 9 am in Sydney. In many shops, an MSP handles the array while internal administrators manage vSphere, so clear evidence is essential when escalating the fault.

Establish A Reliable Performance Baseline

Begin in vCenter by checking the migration task details and performance charts for the VM, source datastore, destination datastore, and participating ESXi hosts. Compare read and write latency, IOPS, throughput, CPU usage, memory pressure, and network utilisation during the move. The reported task percentage is not a reliable throughput measurement because VMware may process changed blocks, snapshots, metadata, and consolidation work at different stages.

Calculate an approximate transfer rate using the amount of data actually copied and the elapsed time. Compare this with a normal migration between the same datastores. If one VM is slow while several others move normally, investigate the VM and its snapshots. If every VM is slow between the same storage systems, concentrate on the shared path, array, fabric, or host configuration.

Capture the ESXi and vCenter versions before making changes. Behaviour and available counters vary between releases, and an upgrade or patch may have altered multipathing, VAAI, vSAN, or network scheduling behaviour. Keep the baseline from a healthy migration so that later tests have a meaningful comparison.

Trace The Storage And Network Path

Map the complete path from the source datastore to the destination. For VMFS over Fibre Channel, inspect host bus adapters, fabric ports, zoning, storage processor ports, and device multipathing. For iSCSI, check VMkernel binding, physical NICs, port groups, MTU consistency, target sessions, and network drops. NFS requires similar attention to VMkernel connectivity, routing, packet loss, and NAS controller load.

Storage vMotion can use the vMotion network for data movement, so verify that the configured VMkernel adapters are present and reachable on both hosts. Check whether the migration network is sharing uplinks with management, virtual machine traffic, backup flows, or replication. Network I/O Control can help prioritise traffic, but an incorrect share or limit can also throttle migrations.

Large Australian campuses and regional sites can expose path problems that remain hidden in a single-room lab. A stretched design between a Sydney primary site and a Melbourne recovery site may introduce distance, encryption overhead, or limited WAN bandwidth. Storage vMotion across such a boundary should be treated as a planned data transfer, not as a routine local datastore move.

Inspect Datastore And Array Constraints

Review datastore latency and queue behaviour at the time of the migration. High device or kernel latency indicates that ESXi is waiting for storage, while high queue depth with modest throughput may point to an oversubscribed array or a constrained path. Check for concurrent backup jobs, replication, deduplication, snapshots, rebuilds, or firmware tasks on the storage platform.

Snapshots deserve particular attention. A VM with several snapshots can require additional snapshot-chain processing and eventual consolidation. A large delta file may also grow during a busy workload, causing the migration to chase changed blocks. Confirm whether snapshots are required, check for consolidation warnings, and avoid deleting snapshots blindly during production activity.

Thin provisioning can make capacity appear available while the array is handling allocation and reclamation work. UNMAP activity, deduplication, compression, and space reclamation may affect latency. On VMFS and supported arrays, verify that VMware Hardware Acceleration and VAAI primitives are working as expected. Failed or unsupported offload operations can force more work through ESXi.

For vSAN, examine the health service, resync activity, congestion, cache tier, disk groups, and policy compliance. A datastore undergoing repairs or resynchronisation may deliver poor migration performance even when the VM appears healthy. For NFS, inspect NAS controller CPU, aggregate utilisation, export settings, and per-volume latency.

Validate Host Health And Migration Settings

Compare the source and destination ESXi hosts. Check CPU ready time, memory contention, host management agents, firmware, driver versions, and the health of every storage and network adapter. A single degraded HBA, NIC, or path can reduce performance while leaving the migration technically successful.

Confirm that both hosts can access the required datastores and that their multipathing policies are consistent. Review path states for dead, standby, or frequently failing paths. On iSCSI systems, inconsistent binding or a missing session can produce an apparently mysterious reduction in available bandwidth.

Check vMotion settings, including VMkernel adapters, TCP/IP stacks, MTU, and Network I/O Control policies. Jumbo frames should be used only when every device along the path supports the same configuration. A mismatch can cause fragmentation or dropped packets rather than improving performance. Also review whether encryption is enabled for the migration and whether host CPU capacity can support it.

Do not treat Storage vMotion as a tuning exercise involving one universal advanced parameter. ESXi storage queues, array limits, and network controls interact with one another. Change one item at a time, document the original value, and retest with a comparable VM during a controlled maintenance window.

A Practical Triage Workflow

Use a repeatable sequence so that a busy help desk, an MSP, and an infrastructure team can work from the same evidence. Start with a small, representative VM, then compare local datastore moves with cross-array moves. If local moves are fast but cross-array moves are slow, the shared storage path or array relationship is the likely boundary.

Quick Checks For The Next Maintenance Window

• Record VM size, snapshot state, source, destination, duration, and average throughput.
• Check datastore latency, queue depth, array workload, and active backup or replication jobs.
• Confirm VMkernel reachability, MTU consistency, uplink utilisation, and packet errors.
• Compare the result across another VM and another host pair.

Once the boundary is known, collect logs and counters before escalating. Include timestamps in AEST or the site’s local time, task identifiers, ESXi host names, datastore names, array volumes, and any path failover events. This is especially useful when a Perth site and a Sydney operations team are working on the same incident.

Evidence Worth Attaching To A Ticket

• vCenter task details and performance screenshots from both datastores.
• ESXi storage, network, and VMkernel logs covering the migration window.
• Array latency, controller load, replication, and snapshot reports.
• Host driver, firmware, multipathing, VAAI, and vSphere build information.

A successful fix should be demonstrated with a repeatable migration and documented before-and-after measurements. That record helps distinguish a genuine improvement from a quiet period in the environment and provides a dependable runbook for the next storage change.