The 404 Isn't Your Fault: What Broadcom Pulling the VDDK Means If You're Trying to Leave VMware
If you’ve spent part of the last few weeks clicking a Broadcom download link, getting an error page, clearing your cache, trying a different browser, then asking a colleague to try it from their machine stop. It isn’t you. It isn’t your proxy, your entitlement, or something you misconfigured.
The page really is gone.
Sometime around late August, Broadcom removed the public download pages for the VMware Virtual Disk Development Kit (VDDK). The landing page and the VDDK 8.x and 9.x downloads all return errors. There was no deprecation notice, no announcement, no replacement link, and no migration path published alongside it. ShapeBlue documented the dead links on August 25. Red Hat followed with a support note two days later. Microsoft’s Azure Migrate documentation still points at a page that no longer resolves.
Customers who have asked Broadcom support directly have been told the kit is no longer available for general download, with the reasoning framed around security, reliability and product features.
I want to be straightforward about what this changes and what it doesn’t because the coverage has ranged from “nothing to see here” to “the exit door is bolted,” and neither is quite right.
What the VDDK actually is, in plain terms
The VDDK is a library that lets software read and write VMware virtual disks from outside the hypervisor. That’s it. It’s the plumbing at the data-transfer layer the part that copies the bits of a VMDK somewhere else without needing an agent inside the guest or a process running on the ESXi host.
VMware released it back in 2008 and it quietly became the backbone of an entire ecosystem: image-level backup products, disaster recovery tooling, and most relevant right now nearly every agentless migration tool that moves workloads off vSphere.
Which tools feel it:
- Microsoft Azure Migrate the agentless path depends on it
- Red Hat Migration Toolkit for Virtualization customers hit “not found” and “access denied” errors
- Nutanix Move agentless path affected
- ShapeBlue Migrate / Apache CloudStack two of four migration methods read through VDDK, including the direct hand-off to
virt-v2vand the changed-block-tracking path via nbdkit’s VDDK plugin - Assorted VMware-to-KVM tooling built on the same foundations
So when one download disappears, a dozen products degrade at once. That’s not a coincidence, and it’s not a small thing.
Why this one stung more than the price increases
Here’s the part I think deserves saying out loud.
The licensing changes were painful, but they were at least legible. You got a renewal quote, you did the math, you made a business case, you built a plan. Awful, but navigable. Teams have spent two years doing exactly that assessing estates, standing up target platforms, running proofs of concept, getting budget approved, booking change windows.
This is different. This is a dependency vanishing mid-project with no notice, no communication, and no stated policy about whether it’s coming back or who’s allowed to have it. If you’re the person who put your name on the migration plan, that’s a genuinely bad week. You didn’t miss a memo. There wasn’t one.
And it landed at the worst possible point in the cycle when renewal pressure is already high, budgets are already tight, and “we’re leaving” has already been promised to a leadership team that will now ask why the timeline moved.
If that’s where you are: the frustration is proportionate. You’re not overreacting, and you’re not behind your peers. Everyone running an agentless migration path hit this wall in the same fortnight.
What this does not mean
It does not mean you’re trapped. A few things are worth holding onto:
Existing copies keep working. This wasn’t a kill switch. Implementations already using VDDK continue to function normally. The problem is obtaining fresh copies new versions, new environments, new staging hosts.
The VDDK is the transfer layer, not the migration. It copies disk bytes. It doesn’t map your application dependencies, sequence your waves, coordinate your cutover windows, or handle your rollback plan. The genuinely hard 80% of a VMware exit the part that actually determines whether the project succeeds is untouched by this.
There are VDDK-free paths, and they work. They’re generally slower or hungrier for staging storage, but they exist:
- OVF/OVA export via
ovftoolthe well-trodden fallback for CloudStack and others - Agent-based migration what Microsoft’s own documentation now suggests when the VDDK is unreachable
- Proxmox’s import wizard adds the ESXi host as a storage source and pulls VMDKs directly, no VDDK involved
- Open-source proxy-copy approaches the Vates/XCP-ng community is actively building one for V2V specifically so the dependency can be dropped entirely
- Red Hat has signalled it’s looking at removing or working around the dependency long-term as well
The ecosystem is routing around this. It will take some months, and the interim is uncomfortable, but the direction of travel is clear.
What to actually do this week
Inventory what you already hold. Search your build servers, your migration appliances, your ISO shares, your engineers’ laptops. If you find a VDDK build, back it up somewhere durable and write down the version and architecture. Do the same for ovftool it’s a separate download from the same portal, and there’s no reason to assume it’s safer.
Put the question to your account team in writing. Ask specifically: what’s the availability policy now, is there an archival commitment, and what happens to your access at the moment your vSphere entitlement lapses because that’s exactly when a migration project needs it most. Get the answer in email, not on a call.
Exercise your fallback path on purpose. Pick a real workload, run it through the OVF or agent-based route, and time it. Measure the staging storage it consumes. Find out now what it does to your cutover window. The worst possible moment to discover your Plan B is three times slower is 2am on migration night with a change freeze expiring at six.
Re-plan your waves around the slower method, not the faster one. If your schedule assumed changed-block tracking and you’re now doing full exports, the arithmetic changed. Better to move the date once, deliberately, with numbers behind it, than to miss it three times.
A word of caution on unofficial copies. Mirrors surfaced quickly and disappeared just as quickly the Internet Archive copies were taken down, and the original download page was excluded from the Wayback Machine. Beyond the licensing questions, pulling a proprietary binary from an unvetted source and running it with privileged access to your production disk estate is a supply-chain risk you probably don’t want to explain to your security team afterwards. Route the request through Broadcom support or a partner instead, even if the answer is slow.
The longer view
General support for vSphere 8 the last perpetually licensed version ends in October 2027. That’s the clock that actually matters, and it hasn’t moved.
Which reframes this whole episode. A removed download is a schedule problem. The support cliff is a strategy problem. If this week’s frustration pushes anything, let it push the strategy conversation forward rather than stall it: the thing worth building isn’t a migration that depends on one SDK, it’s an exit plan that doesn’t depend on any single vendor’s goodwill.
That’s the lesson underneath all of this, and it’s one a lot of teams have now learned twice.
You’ll get there. It’ll take longer than it should have, and you shouldn’t have had to work this hard for it. Both things are true.
Working through this with BroadDigix
If your migration plan just developed a hole in it, we can help you figure out how big the hole actually is.
BroadDigix is a US-based IT solutions and managed services firm headquartered in Austin, with delivery teams across the US, UK and Pakistan. A lot of what this change breaks sits squarely in work we already do every day Azure and Microsoft 365 migrations (including the Azure Migrate agentless path this directly affects), managed IT and NOC services, infrastructure assessment, and staff augmentation for teams that are short-handed at exactly the wrong moment.
Practical places we can pick up the load:
- Estate assessment a current, honest picture of what you’re running on vSphere and what depends on what, before you commit to a transfer method
- Re-planning your waves around VDDK-free routes, with realistic timings rather than the ones your original plan assumed
- Testing the fallback path on a real workload in a controlled window, so nobody finds out how slow it is on cutover night
- Extra hands for the migration itself, if your team is already at capacity
No obligation and no pitch deck start with a conversation about where your project actually stands.
Get in touch: broaddigix.com