Broadcom pulled VDDK: migrating to KubeVirt without it

On 25th August 2026, the download page for VMware’s Virtual Disk Development Kit (VDDK) on Broadcom’s developer portal started returning an error, with no prior public announcement.

Broadcom later confirmed to TechTarget that the library is now only available to selected Technology Alliance Program (TAP) partners, and only for backup and recovery uses: “The approved use case for VDDK per the SDK license has always been for backup and recovery solutions”.

If you are partway through leaving vSphere, that last sentence presents a problem. VDDK is the library most agentless migration tools use to read disks out of vSphere, Forklift included, and Red Hat’s support article on the subject now says it “cannot host, distribute, or provide this image directly to customers”. Migrations which were already running when the page went dark were now left without a supported way to build the image they depend on.

Until now, the cost of staying on VMware has mostly been a pricing problem, and pricing is something which can be negotiated. Withdrawing VDDK is the first change we have seen that makes leaving harder at a technical level. We have spent a good part of this year running Forklift against vSphere, so in this post we will cover what has changed for a migration to KubeVirt, and which routes are still open.

What did VDDK do in a migration?

VDDK is a closed-source library that reads virtual disks from vSphere over the network, through the same snapshot-based path that backup products use. That is why Broadcom can describe its licensed use as backup and recovery.

For a migration, there were two things it did well. It copied only the blocks a disk had allocated and, with Changed Block Tracking (CBT) enabled, only the blocks which had changed since the last copy. The second is what makes a warm migration possible: Forklift copies the disk while the VM keeps running, tops it up with incremental precopies, and shuts the VM down only for the final delta at cut-over. That is the approach we walked through in our technical demo of migrating from VMware to Kubernetes back in April 2026.

The VDDK licence never allowed redistribution, so each team essentially built its own VDDK image from the tarball on Broadcom’s portal. That download step is now gone.

What does Forklift lose without a VDDK image?

Forklift can still migrate from vSphere without VDDK, but only cold, more slowly, and not for every VM:

• No warm migration. Forklift will not start a warm plan from vSphere without a VDDK image, so every VM is powered off for the whole copy, including the guest conversion which comes afterwards.
• Slower cold copies. The Migration Toolkit for Virtualization (MTV) documentation strongly recommends a VDDK image, which it says “accelerates migration and reduces the risk of a plan failing”.
• No VMs on vSAN. The same documentation states that “migrations do not work without VDDK when a VM is backed by VMware vSAN”.

The first of these is the one that changes plans. To paint a picture, let’s say you have a database VM holding 400 GB of data and a short maintenance window. With warm migration, its downtime was the last few minutes of changes plus the conversion.

Without it, the downtime is the time it takes to copy all 400 GB, and then convert the guest. Every downtime estimate in a plan built around warm migration now needs redoing on the same basis.

Which routes to KubeVirt still work without VDDK?

Three routes still work today, but each one of them is cold.

Storage copy offload is the one we would look at first, where the storage allows it. It hands the copy to the array instead of pulling each disk across the network, and Forklift’s own documentation describes it as typically much faster than copying with VDDK. It also has the most prerequisites to work, and these belong to different teams:

• which arrays the datastores and the cluster sit on,
• credentials for the array,
• and changes on every ESXi host.

Which route fits a given VM depends on where its disks live, how long it can be down, and what your storage and host teams will agree to. Most estates may end up using more than one, and proving a route on a single candidate VM is where a migration pilot starts.

Is there an open-source alternative to VDDK?

One may be on its way. Red Hat has written nbdkit-nfc-plugin, a free reimplementation of the Network File Copy (NFC) protocol VDDK uses to copy disks. virt-v2v, the Containerized Data Importer (CDI), and Forklift have all added support for it: virt-v2v on the same day the download page disappeared, CDI six days later, and Forklift on 2nd September.

As of 7th October 2026, this plugin is not yet publicly available, and it does not appear to have reached MTV yet either. In Forklift it covers cold migrations only, so it restores the copy path without bringing warm migration back. We would follow it closely, but not plan a wave around it until there is a release to install.

How can LiveWyer help?

If your migration relied on VDDK, the plan needs revisiting before the next wave:

• which VMs still fit their downtime windows when copied cold,
• which route each one takes,
• and what your storage and host teams need to agree to first.

The quickest way to start is to talk to our engineers. After a short intro call, we run a two-hour workshop on your migration with our senior engineers, looking at the copy routes your storage and hosts allow and where losing VDDK leaves gaps in your plan. We send you a written summary of the trade-offs and recommended next steps afterwards, and we cover the cost of the workshop.

If the workshop points towards KubeVirt, our VMware Kubernetes Migration pilot is the next step. Over three weeks, we take a single candidate VM from your estate through to KubeVirt from start to finish: the copy route, the checks before it reaches a plan, the cut-over, and the downtime it took. That walking skeleton gives you a measured result to plan the next wave from. LiveWyer has built and run Kubernetes platforms since 2015, and we do not sell a hypervisor, a storage array, or a migration tool, so the route we recommend is the one your estate supports.

Frequently asked questions