In this article
Broadcom Removed the VMware Exit Tool Without a Word
Since late August 2026, the download pages for VMware's VDDK library on Broadcom's developer portal have returned 404 — with no announcement, no deprecation notice, and no stated alternative. The library itself is obscure to most people, but the tools that depend on it are not: image-level backup products for VMware servers, and the tooling used to migrate off VMware onto other platforms. The practical result is that a company evaluating an exit from VMware found the official exit road closed. And the lesson applies to every system owner, VMware user or not: your dependence on a vendor is not measured by the subscription price. It is measured by how much time, money, and expertise it would take you to leave.
What VDDK Is, and Why It Matters If You've Never Heard of It
VDDK stands for Virtual Disk Development Kit. It is the library that lets software outside the hypervisor read and write VMware virtual disks. In plainer terms: it is the bridge every program crosses when it wants to take a copy of a virtual server or move it somewhere else.
That is why it sits at the heart of tools with no obvious connection to Broadcom. The open-source conversion engine virt-v2v, which underpins most VMware-to-KVM migration work, supports it as an input transport. Apache CloudStack's migration path uses it to stream disk blocks directly instead of exporting a full OVF file first. And any backup product taking an image-level copy of a vSphere VM passes through it somewhere in the chain.
The key point: you do not need VDDK to keep running VMware. You need it to leave quickly, and to protect what you are running while you decide.
What Actually Happened
ShapeBlue documented the change on 25 August 2026: the page that Apache CloudStack's official administration guide points to for downloading the library returns an error, and so does every other VDDK path on the portal, including version-specific paths for versions 8 and 9. They tested from Europe and through exit nodes in the United States, Brazil, Finland, and Japan, and got the same result everywhere — so it is not a local fault or a geographic block.
Stranger still, there is no Broadcom announcement explaining the change. No phased deprecation notice, no retention policy, and no stated route for a customer or a small vendor to obtain the library. The official CloudStack guide still directs users to a link that no longer resolves. We checked the link ourselves while writing this article and got a 404, while the CloudStack guide page loads normally.
You don't need the library to run the system. You need it to leave. That is precisely what makes its absence matter.
Why There Is No Workaround
Normally, when a file everyone needs disappears, the technical community routes around it: someone mirrors it, someone packages it, and the story ends as a footnote in a docs page. But the VDDK licence does not permit general redistribution. No Linux distribution ships it, no container image bundles it, and no backup vendor without a signed redistribution agreement can put it inside their installer.
That completes the picture: a single URL became a hard dependency for an entire ecosystem of software, and the licence that created the dependency is the same one that blocks the obvious remedy. Mirroring the binaries elsewhere fixes nothing — it moves the legal exposure onto whoever hosts them.
The damage also lands unevenly. A large backup vendor with a partner relationship has someone to call. A three-person migration consultancy, an open-source project, or a customer converting their own workloads has a forum post and an error page.
The Real Lesson: Exit Cost Is the Measure of Lock-In
Most system purchasing decisions get made by comparing prices and features. That is half an evaluation. The missing half is one question: if we decide in three years to leave this vendor, what does that cost us?
What happened with VDDK shows that exit cost is not fixed. A vendor can raise it later, unilaterally, and sometimes without any announcement at all. A company that signed with VMware five years ago evaluated price and performance. It did not know ownership of the product would change, nor that the exit tool would quietly vanish from the portal.
How to Measure Your Exit Cost in Practice
Before any new contract, and before renewing any existing one, ask these questions and get the answers in writing:
- Is my data exportable in an open format? Not a partial dump into a spreadsheet — a full export of the data and the relationships between records, in a format another system can read.
- Is the exit tool owned by the vendor itself? If the only road out runs through a tool controlled by the party you want to leave, you do not have an exit plan. You have a hope.
- What do I keep if the contract stops suddenly? Ask for an explicit clause guaranteeing delivery of data and documentation within a fixed window when the relationship ends, for any reason.
- Have we actually tried leaving? An exit plan that has never been tested is not a plan. Run a full export at least once a year, and confirm it imports somewhere else.
- How long would the migration take, in numbers? Estimate the days and the cost honestly. If the answer is "we don't know," that is also an answer — and it means your dependence is higher than you think.
How We Handle This at Origami
We are a technology company, and we build client systems on the principle that the code and the data belong to the client. In practice that means a standard database any other team can read, documentation handed over with the system rather than on request, and APIs that export the full dataset rather than fragments of it. We do not say this because the relationship is temporary — we say it because a client who knows they can leave is a client who stays by choice.
And when depending on a third-party product is necessary, which it often is, we write into the design document what happens if that party disappears: what the alternative is, how long switching would take, and which parts of the system would be affected. It is one page in the document, but it is the difference between a surprise and a planned manoeuvre.
Sources
Frequently asked questions
I don't use VMware — does this news affect me?
Yes, because the lesson is not about the product but the principle. Any system you depend on today — accounting, point of sale, hosting, an AI service — has an exit cost. The difference is that some companies know their number and others discover it at the worst possible moment. Ask about exporting your data in an open format before you sign, not after.
What exactly is VDDK, and why does its removal matter?
It is a VMware library that lets software outside the hypervisor read and write virtual disks. Image-level backup products and VMware-to-other-platform migration tools depend on it. You don't need it to run VMware, but you need it to leave VMware, or to protect your workloads while you decide.
How do I find out the exit cost of my current system?
Actually try leaving. Request a full export of your data in a standard format, confirm it imports into another system, and record how long it took and what it cost. An untested plan is not a plan, and "we don't know" is an answer that means your dependence is higher than you estimate.
Is the answer to build everything in-house to avoid lock-in?
No — building everything in-house is expensive, slow, and creates a different dependency: on your own team. The answer is deliberate dependence. Use off-the-shelf products where they fit, but require data ownership and exportability, and write into your design document the alternative for every critical third party and how long switching would take.
Follow Origami in Google
Pin Origami as a preferred source and our articles will surface first for you in Google Search and Top Stories.
