Broadcom Deleted the SDK Everyone Uses to Leave VMware, and Never Announced It
The VMware Virtual Disk Development Kit vanished from Broadcom's developer site around 25 August. We checked all three documented URLs and the SDK catalog ourselves: 44 SDKs still resolve, VDDK returns 404 on every path and is not listed anywhere.
The WJS Desk
Sep 8, 2026 · updated 10 days ago · 7 min read
Around 25 August 2026, the download pages for the VMware Virtual Disk Development Kit stopped existing. No blog post, no deprecation notice, no end-of-life bulletin. Broadcom's Customer Care told a Platform9 customer only that "to ensure the highest standard of security, reliability, and product features, the Virtual Disk Development Kit (VDDK) is no longer available for use or download."
We wanted to know whether this was a broken link or a deletion, so we checked it ourselves rather than trust the screenshots. On 8 September we requested every VDDK path that ShapeBlue documented as previously working, plus the SDK catalog it used to sit in. All three VDDK URLs return 404. The catalog returns 200 and lists 44 other SDKs, and we sampled four of them at random. Every one resolved.
What we measured
| Path on developer.broadcom.com | Status |
|---|---|
| /sdks (catalog index, 44 SDKs listed) | 200 |
| /sdks/pyvmomi/latest/ | 200 |
| /sdks/vcenter-converter-sdk/latest/ | 200 |
| /sdks/vsphere-automation-sdk-for-python/latest/ | 200 |
| /sdks/vsan-management-sdk-for-java/latest/ | 200 |
| /sdks/vmware-virtual-disk-development-kit-vddk | 404 |
| /sdks/vmware-virtual-disk-development-kit-vddk/8.0 | 404 |
| /sdks/vmware-virtual-disk-development-kit-vddk/9.0 | 404 |
We also searched the catalog page's own markup for the string. VDDK appears zero times across 179,670 bytes of HTML. It is not hidden behind a login wall on that page, it is not listed as deprecated, it is simply not in the catalog. For a before-and-after, the Internet Archive holds 200-status captures of the VDDK 6.0 and 6.5 pages from May 2024 at the same URL prefix that now 404s.
One honest limit on our check: a 404 on a public path does not prove the binaries are gone from Broadcom's estate, and we have no visibility into what an authenticated partner sees. What we can say is that the public route documented by every downstream vendor is dead, and that the failure is specific to VDDK rather than a site-wide problem.
Why a disk library is the load-bearing piece
VDDK is not a nice-to-have. It is the C library that lets software outside ESXi open a VMDK and read blocks out of it, including changed-block tracking, which is how incremental backups know what moved. If you want to copy a running virtual machine off VMware and onto something else, VDDK is the fast path.
The list of things that call it is the list of ways people are currently leaving:
- Microsoft Azure Migrate, which has since added warnings to its documentation about VDDK access
- Red Hat Migration Toolkit for Virtualization, the route into OpenShift Virtualization
- Nutanix Move, where community posts report being unable to obtain VDDK 7.0.3.1 and 8.0.3.2
- virt-v2v and nbdkit, the open-source KVM conversion path
- Most VMware backup products, which is the part nobody has fully priced in yet
Red Hat published a support article on 27 August acknowledging that customers cannot pull the VDDK images. It cannot fix this by shipping the library itself: VDDK is proprietary Broadcom code that Red Hat has no right to redistribute, so its guidance is to go ask Broadcom.
If you run VMware backups, check your build hosts now. Nothing already installed stopped working. The risk is the next clean install, container rebuild or version bump that expects to fetch VDDK and finds a 404. That failure will surface as a backup job, not as a download error, and it will surface at the worst time.
Where to actually get VDDK 8.0.3 now
This is the question people arrive with, so it goes near the top. The old
public URL under developer.broadcom.com is gone: we checked it
again on 14 September and it returns a 404, while
support.broadcom.com is up and serving normally. The kit has moved
behind entitlement, not disappeared.
The sanctioned route, and the only one we will point you at:
- Sign in at support.broadcom.com. Note the host: this is the
support portal, not
developer.broadcom.com, which is where every stale link and search result still sends people. - Change the division selector at the top right to VMware Cloud Foundation. This is the step almost everyone misses, and without it the downloads you are looking for are not in the list at all.
- Open My Downloads and find vSphere SDKs. VDDK sits under there rather than under its own product name.
- If VDDK is not listed after all of that, your account has no matching VMware entitlement. That is an account problem rather than a navigation one, and the fix is your Broadcom account team.
Why we are not linking a mirror. The kit is redistributable only under Broadcom's terms, which is why the vendors whose products depend on it, Platform9, ShapeBlue and Nutanix among them, are all telling customers to contact Broadcom rather than quietly hosting a copy. If companies with legal departments and a commercial incentive will not mirror it, a copy on a random file host is not a shortcut you want in your supply chain.
Worth knowing before you start: the entitlement check is the actual gate. If you are evaluating a migration away from VMware and have no current VMware contract, steps 1 to 3 will work perfectly and step 4 is where you stop. That is not a bug in the process, it is the point of the change.
What still works, and what it costs
The exits are not sealed, they are slower. ShapeBlue, which verified the outage from Europe and through exit nodes in the United States, Brazil, Finland and Japan, lists three routes that avoid VDDK entirely: OVF export, which it describes as "slower and hungry for staging storage"; a qcow2 overlay backed by the source VMDK over shared NFS, needing CloudStack 4.22.1 or newer; and reading disks directly, since qemu-img and several virt-v2v input modes do not need the library at all. Its own summary is that the VDDK methods were the fastest and most flexible, which tells you what the alternatives cost.
Platform9 lists a similar set for its own tooling: storage-assisted cold migration over iSCSI or Fibre Channel, which currently excludes NFS datastores, and a proxy-VM copy path. Notably, VMware to Proxmox migrations are unaffected, because that path never used VDDK.
So the practical shape of this is: cold migrations still work, warm and incremental ones get harder, and anything that depended on changed-block tracking loses its efficient implementation.
What the threads actually said
The Hacker News discussion stood at 228 points and 111 comments when we last checked on 8 September, and the useful comments were not the angry ones. WokeUp420 reported the operational reality from inside a migration: "I'm in the middle of a massive Azure Local migration and noticed the VDDK was no longer available. Thankfully I saved off my copy but I have no idea how Microsoft is going to handle this going forward with Azure Migrate."
The sharpest question came from vrighter, who has worked on backup software and asked simply: "how are vm backups supposed to work now?" Nobody in the thread had an answer, and neither do we.
The most useful dissent was anonymousiam pointing out that qemu-img converts VMDKs perfectly well, and asking what migration involves beyond that plus rebuilding the virtual hardware profile. That is close to right for a handful of cold VMs and badly wrong at fleet scale, where the whole value of VDDK was reading a disk while the VM kept running.
And dare944 named the strategic logic in one line: "They're building the cage around you. Why would you stick around?" Set against that, firesteelrain gave the view that keeps VMware revenue alive: a large enterprise on VMware Cloud Foundation, happy with it, covered by existing agreements, not interested in Proxmox. Both of those people are describing their actual situation accurately.
The pattern this fits
Since the 2023 acquisition Broadcom has removed perpetual licences, restructured the partner programme, and raised prices by figures Platform9 puts at 300 to 1,500 percent. Every one of those was a pricing decision you could argue about at renewal. This one is different in kind: it removes a technical capability, it was not announced, and its only clear effect is on customers who have already decided to leave.
Broadcom's stated reason is security and reliability. We can find no security advisory, no CVE and no replacement SDK offered on the same page, and Broadcom's own statement points instead at "authorized technology alliance partners." That is a distribution decision wearing a security jacket.
The open question is what happens to the software you already trust. Unofficial mirrors of VDDK tarballs have appeared, complete with checksum archives, and we are not linking them, because installing a proprietary Broadcom library from a third party is how you end up with a supply chain incident on top of a migration deadline. If your organisation has a legitimately obtained copy, put it in artifact storage today and record where it came from. That is unglamorous advice and it is the only advice we would actually give.
If you were planning to leave VMware in 2027, the thing that just changed is that the cost of leaving is now partly set by your vendor. Plan the migration around cold copies and staging storage, or start the partner-access conversation now, because two weeks of no official statement suggests nobody at Broadcom is in a hurry to clarify.
