Broadcom Cuts Public VDDK Downloads and Splits the Exit

Broadcom has pulled the public download pages for VMware’s Virtual Disk Development Kit, the library third-party tools use to read VMDK disks. Support has told customers the kit is no longer available for general use and has pointed them at backup products from Technology Alliance partners.

That does not freeze every exit. It splits the ramps. Partners Broadcom still licenses for backup keep a legal copy. Tools that already copy disks over NFS, OVF, or an in-guest proxy keep moving. Azure’s agentless path, Red Hat’s Migration Toolkit for Virtualization, Nutanix Move, and virt-v2v’s VDDK transport stop at a 404 unless the tarball is already on disk.

A 404 Where the SDK Used to Sit

On August 25, 2026, ShapeBlue engineer Marco Sinhoreli wrote that Apache CloudStack’s VMware-to-KVM guide still pointed at Broadcom’s VDDK page, and that the page now returned a Broadcom Web Team 404. He tested from Europe and through exit nodes in the United States, Brazil, Finland, and Japan, with the same result each time.

The miss was not one bad bookmark. These paths all failed: the landing page, the trailing-slash variant, /latest/, /8.0, and /9.0. The TechDocs page that explained how to install the package 404’d as well, while it still showed up in search. Broadcom has not posted a withdrawal, a deprecation note, or a replacement download route.

THE VDDK PORTAL TIMELINE

1. June 10, 2026: Broadcom’s VDDK programming guide still told vendors that redistributing the libraries required TAP membership at Standard level or above and a signed redistribution agreement.
2. August 25, 2026: ShapeBlue finds every public VDDK URL on the developer portal returning 404 worldwide, with no announcement beside the error.
3. August 27, 2026: Red Hat publishes a Migration Toolkit for Virtualization note that VDDK image pulls now fail with “not found” or “access denied.”
4. September 1, 2026: Platform9 says the classic VDDK plus NBD path is blocked for customers who do not already have the files.
5. September 3, 2026: ShapeBlue ships Migrate v0.5.0 with a direct NFS read path that takes VDDK out of warm migration’s changed-block work.

The silence matters because the licence already blocked the usual community fix. No Linux distro ships VDDK, no container image can bundle it, and a vendor without that TAP paper cannot drop it into an installer. Most product docs still end on the same sentence: go fetch it yourself from the portal.

Support Tells Customers the Kit Is Gone

Customers who opened tickets did not get a “try again later.” One Broadcom Customer Care reply, posted to the VMware Cloud Foundation community, stated the change as policy, not a broken link.

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. Broadcom continues to actively maintain a variety of APIs and SDKs to enable authorized technology alliance partners to build backup and recovery software solutions that are validated and authorized to integrate, interoperate, or be compatible with Broadcom products. For all backup and recovery requirements, customers should rely on such solutions from Broadcom authorized technology alliance partners.

Broadcom Customer Care, support case reply posted to the VMware Cloud Foundation community

That sentence picks the winners in plain language. The kit is framed as a backup SDK, not a migration SDK. Broadcom’s own VDDK use-case pages still describe it as most frequently used for backup and restore. TAP’s public pitch already listed gated SDKs as a member benefit. Nutanix community users were told the same thing in shorter form: VDDK had moved into the alliance program, and you needed the right relationship to get it.

ShapeBlue put the practical warning in one line on August 25: one small dependency can become a major blocker.

Planning a VMware-to-KVM migration? One small dependency can become a major blocker.

Broadcom’s public VDDK download pages are currently unavailable, which can affect VMware migration, backup and disaster recovery workflows, including Apache CloudStack’s optimised direct… pic.twitter.com/V7hEw4rOV3

— ShapeBlue (@shapeblue) August 25, 2026

The people who still have a legal copy are the backup vendors with a signed redistribution agreement. Commvault’s docs, as ShapeBlue later corrected itself, already described shipping the library that way. Administrators who already run Veeam Backup and Replication have been lifting the libraries off the backup server install rather than waiting on the portal. That is not a public download. It is a leftover from a TAP-class product that was allowed to keep the bits.

What Happens to Azure Migrate Without VDDK?

Microsoft’s Azure Migrate discovery tutorial still tells admins to install VDDK 8.0 or 9.0 from the Broadcom developer portal, then warns that agentless migration needs a supported package and that shops without one should switch to agent-based migration. Azure Local’s VMware replicate guide is blunter: Broadcom might restrict download access, outfits that already saved a supported zip can keep using it, and everyone else should pick a third-party migration option. Supported Azure Local builds are 8.0.0, 8.0.1, and 8.0.2. Version 6.7.0 is deprecated for new deployments. The guide says not to use VDDK 7.0.X.

Agent-based replication still works. It also means installing an agent on each guest, standing up a replication appliance, and giving up the snapshot-and-CBT path that made agentless attractive in the first place. Assessment can continue. The cutover path that never touched the guest OS is the one on the clock.

Red Hat is in a tighter bind. MTV builds a container image from the VDDK tarball and points OpenShift Virtualization at it. Red Hat’s own install docs still say to download the kit from VMware, and they warn that parking that image in a public registry may violate the licence. Because the code is Broadcom’s, Red Hat says it cannot host or reship the package. The August 27, 2026 note tells customers to ask Broadcom for access. Engineering is looking at storage copy offload as a longer fix, and that path only exists if the array vendor exposes it.

Version Pins That Do Not Match

Even a saved tarball is not a universal spare. Each product names a build, and those builds do not line up. Nutanix Move 6.1 still sends operators to the Broadcom developer portal, then asks them to upload a specific Linux archive before an ESXi cluster will add as a source.

MIGRATION TOOLS AND THEIR VDDK PIN

A zip that satisfies Azure Local can still fail Nutanix Move, which wants 8.0.3.2. A 7.0.3.1 tree that Move needs for older hosts is the line Azure Local tells you not to use. Open-source conversion has the same licence wall. The virt-v2v VMware input manual says you must obtain VDDK yourself because the licence does not permit redistribution or commercial use, and that if you have the library the VDDK transport is usually the fastest and most flexible. nbdkit’s VDDK plugin is only a loader. It dlopens Broadcom’s library at runtime and ships none of it.

CloudStack’s current admin guide is just as direct: CloudStack does not distribute VDDK, operators must download it separately, and the older OVF method stays on the table. The fast path is the one that dies when the URL dies.

Storage Copies Keep Moving Without VDDK

The other half of the market already treated VDDK as optional. Those products are now the ones that still have a cutover plan on paper.

EXIT RAMPS THAT SKIP THE KIT

• Proxmox ESXi import: Add the host as read-only storage, pick the VM, and convert the disks on the way in. No VDDK step in the wizard.
• CloudStack OVF and overlay: OVF never hands the disk to virt-v2v. Overlay needs the source datastore and the CloudStack pool on the same NFS export, plus CloudStack 4.22.1 or newer.
• ShapeBlue NFS CBT: Migrate v0.5.0 reads changed blocks straight from the NFS datastore, so warm migration no longer sits on nbdkit’s VDDK plugin.
• Platform9 accelerated paths: vJailbreak v0.4.10 defaults to Accelerated Copy. Accelerated Copy and Storage-Accelerated Copy do not require VDDK; only Standard copy still does.
• qemu-img and non-VDDK virt-v2v inputs: Several input methods read VMware disks without VixDiskLib. They are slower or need extra staging, and they still work.
• Azure agent-based replication: An agent on the guest replaces the appliance’s VDDK disk lease.

ShapeBlue’s own scorecard is the cleanest split inside one product. Two of four methods still read through VDDK, including the delta-sync path behind a short cutover. The other two do not. Platform9 made the same move earlier: a proxy VM inside vSphere and array-assisted copy, so the missing tarball is a Standard-copy problem rather than a project-stopper.

Proxmox is the blunt case. The built-in import wizard talks to ESXi as storage and pulls VMDKs without the developer kit. Third-party helpers that wrap nbdkit-vddk are a different story. At least one paid migration wrapper now says it ships the library to subscribers because the public page is gone. That is TAP logic by another name: the kit moves from a portal to a commercial relationship.

Frankfurt Is Where Standard Gets Details

The portal pages went dark in the same stretch as VMware Explore in Las Vegas, held August 31 to September 3, 2026. On the show floor, Paul Turner, chief product officer for the VMware Cloud Foundation division, and Ram Velaga, president of Broadcom’s Infrastructure Software Group, talked about bringing vSphere Standard back. The last major Standard cut was version 8 in 2022. vSphere 9 shipped with VCF 9 without a matching Standard release. Turner pointed to more product detail at Explore on Tour in Frankfurt on October 13 and 14, 2026. There has been no matching public note on VDDK.

Keeping Standard in the catalogue and pulling the library that third-party converters use are not the same decision, and they land on the same customers. The shops Broadcom most wants back in a smaller SKU are the same shops whose Move appliances, MTV plans, and Azure agentless jobs now start with a 404. Trust was already thin. A kit that vanished without a changelog does not help the pitch.

None of this erases a VMDK. The disks are still on the datastores. The fast reader for them now sits with a TAP backup vendor, a tarball someone already saved, or a product that learned to copy over NFS, OVF, or an in-guest proxy. Everyone else is rewriting the runbook.