Table of contents
About two weeks ago, the public download pages for VMware’s Virtual Disk Development Kit disappeared without notice. The immediate disruption is real. The larger risk is what Broadcom could do next – and what that would mean for every tool that reads VMware disks.
In late August 2026, the public download pages for VMware’s Virtual Disk Development Kit (VDDK) quietly disappeared. No deprecation notice, no transition plan, no replacement. ShapeBlue documented the removal on August 25, after every version-specific URL for VDDK 8 and 9 began returning errors. Customers who opened support cases were told the library is “no longer available for use or download” and were redirected to Broadcom’s Technology Alliance Program. Red Hat published a support article two days later confirming that Migration Toolkit for Virtualization users can no longer pull VDDK images through the paths its own documentation had pointed to.
Why a developer library matters this much
Most administrators have never downloaded the VDDK themselves, but almost every tool they use to move or protect VMware workloads depends on it. Azure Migrate, Red Hat’s Migration Toolkit for Virtualization, Nutanix Move, virt-v2v, nbdkit, Platform9 vJailbreak, and a long list of backup and migration products read VMDK data through this library.
The dependency is unusually brittle because the VDDK license does not permit general redistribution. No Linux distribution ships it, no container image bundles it, and no vendor without a signed agreement can put it in an installer. Most affected products’ documentation ends with the same instruction: download it yourself from the vendor’s portal. That instruction is now a dead end – and the license that created the dependency also blocks the obvious remedy, because mirroring the binaries simply moves the legal exposure to whoever hosts them.
Access has not vanished entirely. Customers with a current vSphere entitlement can still locate the SDK through the Broadcom support portal, and Technology Alliance Program members can request it. But both routes require a commercial relationship with Broadcom, and the partner program is designed for companies building products on VMware – not for customers trying to leave it. Pulling the public download turns “download the VDDK, then migrate” into “open a ticket and hope.”
The real risk is the next step
Removing the download is disruptive but survivable: vendors and customers who already hold the binaries can keep using them for now. The scenario the market should worry about is Broadcom going one step further and formally closing the license, prohibiting any use of the VDDK without explicit permission.
That would not be a technical inconvenience; it would be a legal chokepoint on the exit door. Every vendor whose product embeds the VDDK would need Broadcom’s consent to keep shipping, and there is little reason to expect that consent to be granted freely to companies whose business is moving customers off vSphere. A vendor does not hand its competitors the tools to drain its installed base. Red Hat’s position – that it cannot redistribute the package because it is proprietary Broadcom software – shows how thin the legal footing is for everyone building on it.
The consequences would spread quickly. Migration timelines slip while vendors re-architect. Backup products that rely on VDDK-based changed block tracking lose their fastest path to VMware data. Customers get squeezed between rising renewal quotes and an exit route that just got slower and riskier. In the same week, at VMware Explore, Broadcom executives signaled a new release of vSphere Standard aimed at smaller environments – a pairing many customers will read as carrot and stick. Whatever the intent, the effect is lock-in through control of the interface rather than through product quality, and that is bad for every customer, partner, and competitor in the ecosystem.
Where Hystax Acura stands
Hystax Acura is not blocked by this change, and that holds across all three of its use cases: migration, disaster recovery, and backup.
The VDDK sits in exactly one place in the Acura architecture: the external, agentless VMware Replication Agent, which reads virtual disks through VMware’s own APIs. Customers who already use the library can run it unchanged. Everyone else has a supported alternative that never touches it.
→ On the source side, the internal Replication Agent runs inside the guest OS and replicates at the block level, independently of the underlying hypervisor. It requires no VMware API access and no VDDK, so it keeps working even if Broadcom closes the door completely.
→ On the target side, Direct2Target removes the equivalent dependency on the destination platform. Introduced in Acura 4.5 and extended to disaster recovery scenarios in Acura 4.6, D2T replicates and recovers at the disk level through a dedicated agent, without calling the target platform’s management API.
Together, the internal agent and Direct2Target provide a replication path that depends on neither Broadcom’s library at the source nor a management API at the destination. In practice, the change is a minor inconvenience for one of the deployment options and has no impact on Acura’s ability to migrate, protect, or backup VMware workloads – whether the destination is OpenStack, KVM, Red Hat OpenShift Virtualization, or VMware itself.
Planning a migration, disaster recovery, or backup project for VMware workloads and want a replication path that does not depend on Broadcom’s library?
Tell us about your environment, and our engineers will map the options for your source and target platforms.
Thank you for your request!
We will be in touch soon.
What to do now
If you are planning a VMware exit or running VMware-dependent DR, four things are worth doing this quarter.
- Inventory the dependency. Check every tool in the chain – migration, backup, DR, and any in-house scripting built on virt-v2v or nbdkit – for a VDDK requirement.
- Confirm a fallback for each one. A tool with no non-VDDK path is a single point of failure controlled by the vendor you are leaving.
- Keep the binaries you already hold, and record which product versions they are licensed for. Do not source them from unofficial mirrors: the license restricts redistribution, and unverified copies carry supply-chain risk.
- Favor tooling that was not built on the assumption that Broadcom would always leave the door open, because that assumption has just been proven wrong.
The VDDK removal reminds us that a migration plan is only as portable as its weakest dependency. Explore how Hystax Acura approaches cloud migration, disaster recovery, and backup across VMware, OpenStack, KVM-based platforms, and environments with restricted API access.