Optimizing VM Migration Performance with Everpure

Traditional Migration Path (VDDK-Based Data Copy)

The standard Forklift migration path uses VMware's Virtual Disk Development Kit (VDDK) to read VM disk data from the source datastore. VDDK is a set of libraries provided by VMware that allows third-party tools to read and write VMDK disk images directly from VMFS or vVol datastores.

XCopy Offload Architecture and Enablement

XCopy Offload replaces the network-intensive VDDK copy with a FlashArray-native data movement operation. The SCSI EXTENDED COPY (XCOPY) command instructs the FlashArray to clone the source volume to a target location internally. Both operations execute within the array's controller, with no host-side data movement

Why XCopy Migration Time is Independent of Disk Size

The key insight behind XCopy performance is that FlashArray uses a redirect-on-write (RoW) clone mechanism. When the XCOPY command is issued, FlashArray creates a new volume that shares metadata pointers to the same underlying data blocks as the source volume — no physical data is moved immediately. The new volume is immediately accessible and bootable. Background destage operations write any modified blocks over time, but this is transparent to the accessing host.

From Forklift's perspective, the migration is complete as soon as the target volume is accessible — which happens after the metadata clone operation, not after all data blocks are physically copied. This is why a 500 GB disk migrates in approximately the same time as a 16 GB disk: the critical path is the metadata operation, not the data volume.

XCopy Enablement and StorageMap Configuration

# Step 1: Enable XCopy feature flag on Forklift controller
oc patch forkliftcontrollers.forklift.konveyor.io forklift-controller \
--type merge \
-p '{"spec": {"feature_copy_offload": "true"}}' \
-n openshift-mtv
# Step 2: StorageMap must include offloadPlugin section
# This is what activates XCopy for migrations using this StorageMap
offloadPlugin:
vsphereXcopyConfig:
secretRef: pure-storage-creds # FlashArray API token secret
storageVendorProduct: pureFlashArray
# Step 3: Provider spec must NOT include vddkInitImage
# Presence of vddkInitImage overrides XCopy and forces VDDK path

Impact on CPU, Network, and Migration Time

# The resource savings from XCopy Offload have two practical implications beyond faster migration times. First, production workloads on the ESXi hosts and OpenShift worker nodes experience less interference during migrations — VDDK migrations compete for NIC and CPU resources with running VMs, while XCopy migrations do not. Second, the reduced network load means migrations can be run during business hours without impacting application performance, rather than being restricted to maintenance windows.

Scaling Behavior for Batch Migrations

Understanding how migration performance scales with batch size is critical for planning migration waves. The two methods scale differently because their bottlenecks are in different layers.

VDDK Scaling

VDDK batch migrations scale approximately linearly with the number of VMs because the bottleneck is host resources — NIC bandwidth and CPU on both ESXi hosts and OpenShift worker nodes. Increasing the batch size beyond the Forklift concurrency limit (default 20) does not increase parallel throughput; it creates a queue. VMs beyond the first 20 wait for migration slots, and total wall-clock time scales proportionally.

XCopy Offload Scaling

XCopy batch migrations scale differently because the bottleneck shifts to FlashArray controller resources — specifically, the number of concurrent clone operations the controller can process. FlashArray controllers are highly parallelised and designed for concurrent operations. In lab testing, batches of 20 VMs migrated in 11 minutes 35 seconds using XCopy, compared to 32 minutes 23 seconds for VDDK — a 64% improvement at batch scale, on top of the single-VM improvement.