On August 25, 2026, Broadcom removed the VMware Virtual Disk Development Kit from public download. No announcement and no deprecation notice. The pages on developer.broadcom.com started returning 404s and stayed that way. ShapeBlue documented the missing pages the same day, Red Hat published a support article on August 27, and by September 7 the Hacker News thread had 198 points and 81 comments. If you were planning a migration off VMware and didn't already have a copy of VDDK sitting somewhere, you now have a dependency you can't get.
My read is that Broadcom looked at the tools people use to leave VMware, noticed that most of them share one proprietary library, and stopped handing it out. Whether a product manager wrote that down as the goal doesn't change the effect.
One library, most of the market
VDDK is the piece of software that lets a program read VMware virtual disks from outside the hypervisor. It talks to ESXi over the network and returns raw disk blocks. It knows which regions of a disk are empty so you don't copy zeros, and it exposes change block tracking, so a migration tool can do a full copy while the VM is running and then copy only the blocks that changed during the cutover window. Richard W.M. Jones, who maintains virt-v2v at Red Hat, walked through those capabilities in the Hacker News thread. There is no open-source equivalent that does all three.
The affected tools cover most of the migration market:
- Microsoft Azure Migrate in agentless mode
- Red Hat Migration Toolkit for Virtualization, which moves workloads to OpenShift Virtualization
- Nutanix Move
- virt-v2v and the nbdkit VDDK plugin, which sit underneath most of the KVM migration tooling
- Apache CloudStack's VMware to KVM conversion
- Platform9 vJailbreak
Microsoft's migration support matrix now says Broadcom may restrict access to VDDK and recommends the agent-based path when a supported package isn't available. Red Hat says it can't host or redistribute the library because Broadcom owns it, tells customers to ask Broadcom for a copy, and says it is working on removing the dependency. Good. Every migration vendor should be doing the same, and should have started in 2024.
Proxmox is the exception. Its ESXi importer reads disks through the ESXi HTTPS API and never used VDDK, so it kept working. That was a design choice, and this month it looks like the right one.
The only explanation came through a support ticket
As of September 8, Broadcom has said nothing publicly. The only explanation anyone has is a support response to customers that Platform9 quoted on September 1. It cites security, reliability and product features, then says VDDK is "no longer available for use or download."
The words "for use" are the problem. Plenty of customers have VDDK baked into migration appliances and automation pipelines. Broadcom's own wording implies that continuing to use a copy you already have is now an issue, and a support ticket is not a license amendment, so nobody can say what changed. Microsoft's guidance treats a copy downloaded before August 25 as still usable. I'd act on Microsoft's reading and keep the receipt.
Jones also reported that VMware is still supplying VDDK directly to backup vendors, and only to backup vendors. Veeam and the other partners with signed redistribution agreements keep their access. The library still exists and still ships. The people cut off are the ones using it to leave.
A mirror at kddv.download briefly hosted the 7.0.3, 8.0.3 and 9.1.0 packages. Broadcom filed a copyright complaint on August 26, one day after its own pages went dark, and the binaries came down. The site now hosts only MD5 and SHA-256 checksums, which are useful for verifying a copy you got from somewhere else. Broadcom couldn't manage a deprecation notice in two years, but it found the copyright complaint form in a day.
This had been coming for two years
ShapeBlue's timeline shows the download was decaying long before it vanished:
- February 2024: the 8.0.2.1 release notes disappeared. They came back five months later.
- September 2024: the download buttons started returning JSON errors. ShapeBlue got no response from Broadcom.
- November 2025: the 8.x download stopped working entirely. Only 9.x remained, and 9.x didn't work with the tools people were running in production.
- August 2026: the pages disappeared.
Three warnings over 30 months, and the migration vendors kept building on the assumption that Broadcom would keep publishing the library. Broadcom never promised that. Everyone assumed it.
Look at the rest of the record. Perpetual licenses ended in December 2023. Free ESXi was killed in February 2024, then brought back in 2025. Platform9 lists reported price increases of 300 to 1,500 percent across 2024 and 2025, plus a partner program consolidation that pushed out smaller resellers through 2026. One Hacker News commenter who said they had led about $20 million of migrations off VMware in two years called it "vulture capitalism." A former VMware engineer called it a "controlled descent," meaning extract the revenue before the value hits zero.
I don't need to know Broadcom's intent to draw a conclusion. The pattern is to squeeze the customers who can't leave, and now to slow down the ones who can. A lot of teams are moving to Hyper-V, Proxmox or KVM right now, and the hypervisor has nothing to do with it. They are leaving over renewal quotes that tripled, partners that got cut out of the program, and a vendor that treats every account as something to wring out. Pulling VDDK wins none of those customers back. It makes the exit slower and more expensive, and it confirms the reason they wanted out.
What to do this week
If you have a VDDK zip anywhere, preserve it now. Copy it off the migration appliance into an artifact repository, record its SHA-256, and compare it against the checksums at kddv.download so you know which version you're holding. A checksum doesn't settle the licensing question, but it settles which package you have.
If you don't have a copy, test one of these instead of waiting on a Broadcom support ticket:
- Agent-based replication. Azure Migrate, RackWare and others replicate at the file system level from an agent inside each guest. More setup per VM, no VDDK.
- Storage-side access. Give the destination hypervisor direct access to the datastore over iSCSI or Fibre Channel. Platform9 and ShapeBlue both describe this path. NFS support is thinner.
- Cold export and qemu-img. Export the VM and convert the VMDK. Fine for tens of VMs, painful for thousands, and without change block tracking the full copy happens during downtime.
- Proxmox's ESXi importer. It pulls disks over HTTPS and never needed VDDK. If Proxmox was already on your shortlist, this moves it up.
Run one production VM through whichever path you pick before you schedule the fleet. The gap between an incremental copy with change block tracking and a cold export can move a project by months, and the per-VM setup plus your downtime window decide which option is realistic.
Vendors still have the problem
Red Hat removing the dependency is the right fix, and every migration product that reads VMware disks needs the same fix. Migration vendors without redistribution rights can't host their own copy, the backup vendors' agreements don't extend to them, and a product that works fine with an existing package still breaks the moment a new customer needs one.
My forecast is that within six months Broadcom formalizes VDDK as partner-only, keeps the backup vendors supplied, and goes after the ESXi API documentation the Proxmox importer relies on. As of September 8, that importer still works. If Proxmox is on your list, I'd test it this month, before that changes too.
