Summary
Third-party migration tools depend on VMware’s VDDK to read VM disks, and the VDDK is no longer available as a public download. When your VMware datastores and your target platform share the same Everpure FlashArray system, the copy happens inside the array, and the VDDK never enters the picture.
If your VMware migration runs through Red Hat’s Migration Toolkit for Virtualization (MTV), Nutanix Move, or Azure Migrate, it depends on the VMware Virtual Disk Development Kit (VDDK). That dependency just got harder to satisfy.
There’s a way around it. Below, we cover what changed and how storage copy offload on FlashArray™ moves your VMs with no VDDK in the path at all.
What happened
The VMware Virtual Disk Development Kit is the SDK that third-party tools use to read virtual disks from vSphere, and it underpins most migration and backup software that works with VMware.
As of August 2026, the VDDK is no longer available as a public download. Broadcom distributes it through the Technology Alliance Program (TAP), and customers opening support cases are being directed to TAP partners for backup and migration tooling.
Red Hat’s knowledge base article confirms that MTV customers can no longer download the VDDK images their migration plans use and notes that Red Hat is evaluating alternatives, including storage copy offload. Microsoft’s Azure Migrate documentation now points to agent-based migration as the fallback, and Nutanix community threads and Platform9 report the same for Nutanix Move and vJailbreak.
If you’re mid-migration, the practical effect is a prerequisite that may take time to obtain or may not be available for your tooling.
Why the VDDK matters more than you’d think
The VDDK is the library that lets a tool outside vSphere read virtual disk files off an ESXi host over the network. That sounds narrow, but it isn’t. It’s the engine under nearly every third-party path off VMware: MTV and its upstream project Forklift, Nutanix Move, Azure Migrate’s agentless mode, virt-v2v, nbdkit, and most vendor tools built on top of them. It also sits under a good share of backup software. Red Hat’s own MTV planning documentation walks through building the VDDK image before a standard migration can run.
Every one of those tools follows the same pattern: Pull disk contents through the VDDK, push them across the network, land them on the destination. That pattern was already slow for large VMs. Now it has a gate in front of it.
Another path: Move the copy into the array
The alternative is to stop moving data through the host at all.
When the VMware datastore you’re leaving and the Kubernetes or hypervisor platform you’re moving to both sit on the same FlashArray system, the migration tool can hand the copy to the array. FlashArray already holds the blocks. Cloning them to a new volume is a metadata operation, and no VM data crosses the network or a worker node.
This is what storage copy offload means in practice, and FlashArray is a supported storage provider for it in MTV. For VMFS datastores, it uses SCSI XCOPY. For vVols and RDMs, it goes further and uses the FlashArray Volume Copy API to offload the entire migration to the array. Either way, there is no VDDK in the data path. We covered the architecture in depth in “FlashArray Simplifies VMware to Red Hat OpenShift Virtualization Migration.” The short version is that the array does the heavy lifting rather than accelerating part of a host-based copy.
How it works with OpenShift Virtualization and Portworx
MTV added storage copy offload in version 2.10, and FlashArray is a supported target. Enable the copy offload feature on the Forklift controller, map your source datastores to a FlashArray Direct Access (FADA) storage class, and MTV uses XCOPY to clone each VMDK into a FlashArray volume presented to OpenShift. The step-by-step procedure is in our Red Hat documentation, including the StorageMap configuration that turns offload on.
Getting the data onto Portworx® volumes takes one more step because Portworx volumes aren’t raw LUNs the array can address directly. Portworx and FlashArray engineering built a post-migration hook that handles it: After MTV’s XCOPY lands the disk on a temporary FADA volume, the hook performs a second XCOPY from that volume into the Portworx-backed devices on the same array, rebinds the VM’s PVCs, and restarts the VM. Both copies stay inside the FlashArray system. The VM comes up on OpenShift Virtualization with Kubernetes-native snapshots, replication, and backup already in place through Portworx.
Figure 1: Comparison of data migration via the VDDK path and the offload path.
The results from our own lab testing hold up. A Linux VM with roughly 305GB of used data took 1 hour, 25 minutes to migrate over the VDDK path. With XCOPY offload, it took 5 minutes, 10 seconds. Shared-disk migrations on RDMs and vVols, which took more than eight hours per stage over the network, completed in about five minutes each with volume copy.
What you need:
- Portworx Enterprise 3.5.1 or later on PX-StoreV2
- Purity 6.3 or later
- MTV 2.10 or later
- Source vmfs or vvol datastore and target Portworx storage on the same FlashArray
- Cold migration (the VM is powered off; its state is preserved)
Current validation covers up to 25 VMs and 100 disks per migration plan, with data disks up to 35TB. The full procedure, including the RBAC setup and the hook manifest, is in the Portworx documentation.
Not on OpenShift? The same idea applies
The principle doesn’t depend on the destination. Nutanix Move with FlashArray as external storage uses the same array-side approach: The source vDisks are cloned by updating metadata pointers, the new VM comes up on AHV, and the original VMware VM stays intact for a clean rollback. We cover it in “Zero-Copy Migrations with Nutanix Move and Everpure FlashArray.”
If your VMware datastores aren’t on FlashArray today, you still have a path. Use Storage vMotion to move the VMs you plan to migrate to a FlashArray datastore first. Then offload from there. That step happens inside vSphere with tooling you already have, and it puts your data on a platform both sides of the migration can address. For larger estates, FlashArray-to-FlashArray replication can pre-stage the bulk of the data ahead of the cutover window, so the final step touches only changed blocks.
What this means for your migration plan
Every migration plan has dependencies. The question this move exposed is which ones you control.
A plan that reads disks through the hypervisor depends on tooling licensed from someone else. A plan that copies data inside the storage layer depends on storage you already run. When the data sits on a FlashArray system, the exit path is there whether you use it this quarter or in three years, and it’s there for OpenShift Virtualization, Nutanix, or whatever you evaluate next.
That’s the case for treating storage and data management as the durable layer under a changing compute stack. You keep control of how your data moves. You keep the option to move it later. And you’re not rebuilding the plan every time something upstream changes.
If you’re still weighing which path fits, “The 2026 Buyer’s Guide to Modern Virtualization” lays out the four options side by side.
Where to go next
- “FlashArray Simplifies VMware to Red Hat OpenShift Virtualization Migration” covers the offload architecture and test results in more depth.
- “Rapid Migration of VMs from VMware to OpenShift Virtualization using XCOPY” is the step-by-step Portworx procedure.
- “OpenShift Migration Toolkit for Virtualization with FlashArray” provides the validated reference architecture.
- Red Hat’s storage copy offload documentation for MTV explains how to configure and use the feature.
Want to see it run against your own environment? Join a hands-on lab or talk to us.
Get the Complete Reference Architecture
See the validated architecture for VMware to OpenShift Virtualization migrations using storage copy offload on FlashArray—including tested configurations and step-by-step procedures.
