Slow Cloning Performance or failures Between Different Datastore Types (FC to NFS)
search cancel

Slow Cloning Performance or failures Between Different Datastore Types (FC to NFS)

book

Article ID: 442811

calendar_today

Updated On:

Products

VMware vCenter Server

Issue/Introduction

  • Cloning or copying virtual machine files from an FC-based datastore to another FC datastore (on a different array) or an NFS datastore is significantly slower or fails vs. intra-array moves.

  • Performance is even lower when moving data to an NFS-based storage.

  • Throughput appears capped or inconsistent despite high-speed physical NICs (10G/25G).

Environment

  • VMware vSphere ESXi (all versions)

Cause

  • VAAI Hardware Offload Limitations: When migrating data between different datastore types (e.g., VMFS to NFS) or between two separate physical storage arrays, vSphere Storage APIs for Array Integration (VAAI) primitives like XCOPY cannot be used.

  • Layer 3 Routing Overhead: If the ESXi host's vmkernel port and the NFS or iSCSI storage target are on different subnets, the traffic must be routed through a gateway. This adds latency and subjects the storage traffic to the throughput limits and congestion of the network.

  • Mount Datastore directly to source host: When performing a VM clone from a host not directly connected to the destination datastore (e.g. cloning between clusters or stand-alone hosts with different attached storage) the host falls back to a Network File Copy (NFC), which is single-threaded and limited to roughly 1Gbps by design.

Resolution

1. Use Optimized Cloning:
 
    • Use the vCenter Clone operation rather than the Datastore Browser "Copy" function. The cloning engine is more efficient at handling non-offloaded data moves than the browser-based copy utility.
 

2. Eliminate NFC copies:

    • Mount the destination datastore to the source.  This eliminates the need for the slower NFC copies. 
 
3. Eliminate Layer 3 Routing:
    • Create a dedicated VLAN for NFS/Storage traffic.
    • Configure new vmkernel ports on each ESXi host within that same VLAN.
    • Ensure the storage target (NFS) is accessible via this new subnet. This ensures Layer 2 connectivity, avoiding the overhead of upstream routers.
 
4. Verify Data Path:
    • Use vmkping -I vmkX <Target_IP> to ensure traffic is leaving the correct vmkernel interface and that MTU sizes (e.g., 1500 or 9000) are consistent across the entire path.

Additional Information

See also related KBs: