Broadcom pulls the VDDK: the first thing that breaks is not your migration, it is your backup

In late August, a URL on Broadcom's developer portal stopped working. No announcement, no deprecation notice, not a line in any release notes: a download page that was there one day and returned a 404 the next. Behind that URL sat a library nobody outside a systems department could name, and on which two things depend that are almost never thought about together: your plan to leave VMware some day, and the backup that ran last night.

What the VDDK is, in one sentence

The Virtual Disk Development Kit is the library that lets a program running outside the hypervisor read and write VMware virtual disks. Its visible face is called VixDiskLib, and underneath it implements the transport modes by which that program reaches the data: over the network (NBD and NBDSSL), by attaching the disk to a helper machine (HotAdd), or by reading straight off the array (SAN). For the best part of two decades it has been the default route for anything that needs to touch a .vmdk without being ESXi itself.

That includes, in practice, the entire backup, disaster recovery and migration ecosystem. It also includes a licensing detail that explains why this is a problem rather than an annoyance: the VDDK cannot be freely redistributed. A vendor without a signed agreement with VMware cannot bundle it in its installer. The practical consequence since 2008 was that many tools asked you to fetch it from the portal yourself. That page is the one that is gone.

The word almost nobody has read

When customers asked, the answer that circulated from Broadcom customer care was this: "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." It added that Broadcom continues to maintain APIs and SDKs so that "authorized technology alliance partners" can build backup and recovery solutions.

Here is our caveat, and we are putting it before we go on rather than at the end: that sentence comes from support replies reproduced by affected users and picked up afterwards by several industry publications. We have not seen it in a formal Broadcom statement, because there has not been one. We are not lawyers and we will not tell you what it means legally for your contract. What we will say is that there is a large gap between "you cannot download it" and "you cannot use it", that the gap falls squarely on systems that are in production, and that in everything we have read these past days nobody has stopped on it.

Yes, leaving costs more. It depends where you are going

The headline doing the rounds is that leaving VMware just got harder. That is true, and it is incomplete, because it did not get harder equally for everyone. It depends which tool you use to copy the disks, and that depends where you are going.

On the side of those who do feel it:

• Red Hat's Migration Toolkit for Virtualization. Red Hat published a support article acknowledging that customers hit "not found" or "access denied" errors when going for the VDDK, and stated something important: it cannot host or redistribute it, because it is proprietary Broadcom software, so it points customers at Broadcom support while its engineering team looks for a long-term way out.
• Microsoft's Azure Migrate, in agentless mode: the documentation sends you off to download VDDK 8.0 or 9.0 from the Broadcom portal, and the link now leads nowhere. That the dependency is real and not our reading can be seen in Microsoft's own support matrix, where three of the vCenter permissions you must grant are justified in so many words as being "to read the disk using the VDDK". The remaining alternative is agent-based migration — the other method the same page documents — and it is a different thing with a different operational cost: the mobility service has to be installed inside every machine.
• virt-v2v and nbdkit's VDDK plugin, the machinery underneath a good share of VMware-to-KVM conversions, and Apache CloudStack, which uses it as its optimised route.

And on the other side, the fact the coverage mentioned in passing and that strikes us as the most useful of all: Proxmox VE's ESXi importer does not depend on the VDDK. The official migration wiki never names it — we checked by searching the page for the word, and it does not appear once — what it describes is a component of its own, esxi-folder-fuse, which acts as the interface between Proxmox VE and ESXi by talking to the host API. The wiki even says how hard it squeezes: that service "limits parallel connections to four and serializes retries of requests after getting rate-limited", precisely so as not to overload an ESXi API which, once pushed too far, blocks clients for roughly thirty seconds. Its documented limitations lie elsewhere — vSAN unsupported, disks encrypted via Storage Policy unsupported, much slower with snapshots, and a serious performance drop if you import through vCenter instead of against the host — but none of them has anything to do with a library Broadcom stopped publishing.

This is not an argument for picking a hypervisor, and it would be dishonest to sell it as one. It is a cost item that was not in the comparison table yesterday and is today, and which could just as easily vanish tomorrow if Broadcom restores the download. Making a five-year architecture decision off a broken URL would be exactly the kind of decision you pay for later. We have written calmly about when not to migrate from VMware to Proxmox and about why the mass exodus that was announced never really happened. None of that changes because of a 404.

A migration has a date. A backup is just another Tuesday

This is where we think the focus is wrong. A migration is a project: it has a date, an owner, a planning meeting. If the VDDK complicates your migration, you find out in that meeting, with time to spare, and you look for another route. It is an expensive, annoying problem, but it is a visible problem.

A backup has no meeting. A backup is a process that runs every night and that you only remember twice: when it fails and when you need it. And that is where this library has been working for the best part of twenty years without anyone looking at it. In Veeam, for instance, its own best practice guide places the VDDK inside the transport service and describes the modes that use it — Direct SAN, the virtual appliance hot-add mode, and NBD — while noting that in some scenarios it is bypassed in favour of Veeam's own Advanced Data Fetcher. We work with Veeam and with Proxmox Backup Server. Worth saying plainly, so as not to feed the alarm: what is installed stays installed, and keeps working. Pulling a download does not switch off a backup that is already running.

It is the failure mode we have seen up close most often while running other people's infrastructure: a system that has worked perfectly for years and that nobody has reinstalled from scratch since the day it was built. It works because nobody has touched it, not because it can be replaced. There is a line we say a lot that today takes an extra turn: an untested backup is not a backup, it is a lucky charm. The usual test is restoring a file. The test almost nobody runs is rebuilding the machine that makes the copy, with what you have to hand today, without opening anybody's portal.

Three questions you can actually answer this week

We are not going to give you a ten-point list. Three will do, and all three can be answered without buying anything.

1. What is inside your backup? Specifically: if your VMware backup is agentless, does it use the VDDK, what version is installed, and where did that version come from — the vendor's installer, or a manual download somebody did years ago? That last part is what decides whether you can replace it yourself.
2. Does it survive a rebuild? The test is done today, in office hours, without touching production: stand up a brand-new backup proxy from scratch and check that it actually manages to copy a machine. If at any step you need to open a download portal, you already have your answer.
3. And if one day you move? You do not have to decide anything today. It is enough to know whether the tool you would leave with depends on this library or not, because that changed price this week and you want to know it before the meeting, not during it.

The second one is the one most people skip and the only one that yields an answer rather than an opinion. It is the same idea we described when writing about why a disk arrives intact from VMware and then Windows will not boot: the work that saves Saturday night is the work you do on a Tuesday morning, with the machines still running and an easy way back.

When this does not apply to you

If you do not run VMware, this does not touch you at all and you can close the tab with a clear conscience. If your backup runs with an agent inside the guest, likewise: that path does not go through the VDDK. And if you do run VMware, with an agentless backup that works and no intention of touching anything for eighteen months, the honest answer is that you do not have an emergency today. You have a deferred risk, which is different from no risk. And how long you can defer it depends on one thing only: whether you can replace the part yourself.

Nor do we know — and we say it because nobody does — whether Broadcom will reverse this, whether access will return through another door, what the criteria are for getting into that authorised partner programme, or how long it takes. Anyone telling you today how this story ends is making it up.

What can be said is what Broadcom's sentence describes precisely, like it or not: the ability to read your own disks — to copy them or to take them with you — now lives inside another company's partner catalogue. From Broadcom's point of view that is a perfectly reasonable decision. From the point of view of whoever has to restore tomorrow, it is a dependency that until 25 August appeared in no inventory at all, because there was no need for it to.

Note on sources

The removal of the public VDDK download pages and the 25 August 2026 date come from ShapeBlue's analysis "Broadcom Removes VDDK Pages Without Explanation", published on that same 25 August, which was first to document the paths returning 404, and from Platform9, which is what places the removal on that date; they were picked up afterwards by It's FOSS and Virtualization Howto; ShapeBlue is also the source for the specific paths returning 404, for the observation that the VDDK licence does not permit general redistribution, and for the VDDK-free alternatives in CloudStack (OVF export and direct NFS reads). Broadcom's sentence, which we quote in its English original — "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" — and the reference to "authorized technology alliance partners" come from Broadcom customer care replies reproduced by affected users and published by Platform9 and It's FOSS; there has been no formal Broadcom statement, which is why we attribute it that way and not as an official notice. That Red Hat published a support article about being unable to download the VDDK for the Migration Toolkit for Virtualization, that it cannot host or redistribute it because it is proprietary software, and that its engineering team is looking for a long-term alternative, comes from that same coverage, as does Azure Migrate's agentless dependency on VDDK 8.0 or 9.0; the three vCenter permissions justified as being "to read the disk using the VDDK" and the existence of agent-based migration with its mobility service inside every machine, we checked directly against Microsoft Learn's support matrix for VMware vSphere migration. Also from that same coverage are the dependencies of virt-v2v, nbdkit's VDDK plugin and Apache CloudStack. The description of the VDDK and its transports (NBD, NBDSSL, HotAdd and SAN) is long-standing public VMware documentation. That the VDDK lives inside the Veeam transport service, the list of modes that use it, and the note that in some scenarios it is bypassed in favour of the Advanced Data Fetcher, come from Veeam's public vSphere best practice guide. That Proxmox VE's ESXi importer never names the VDDK, that it uses the esxi-folder-fuse component, and its documented limitations (vSAN, disks encrypted via Storage Policy, slowness with snapshots, performance drop via vCenter) come from the official Migrate to Proxmox VE wiki. Spanish and Catalan quotations are our own translations from the English originals. The following is OUR reading, not that of any source cited: the distinction between "use" and "download" and what follows from it; that the coverage has its focus in the wrong place because a migration is a visible project and a backup is not; and that a backup with this dependency does not fail on the day of the removal but on the day it has to be rebuilt. We give no timelines, no percentages of affected tools and no legal reading of the licence, because we have none of them anchored and we would rather say so. That we run Proxmox VE with Ceph in production, that we work with Veeam and with Proxmox Backup Server, that we have migrated companies from VMware to Proxmox and also advised them to stay, and that we are not resellers of either platform, is everyWAN's own information. Check it in your own environment before relying on any of it. The cover photograph is "IBM TS3500 LTO-6 Tape drive cabling", by vaxomatic, published on Wikimedia Commons under CC BY 2.0.