You stand up a fresh migration appliance, you go to fetch the library it needs, and the page 404s. That's been the experience since 25 August 2026, when the public download pages for the VMware Virtual Disk Development Kit disappeared from developer.broadcom.com. No announcement and no deprecation notice. The installation guide on TechDocs went with them. We checked on 8 September and the 8.0 release notes URL still answers 404. Broadcom's line to customers who ask through support is that the VDDK is no longer available for use or download. If you're partway through leaving VMware, that library is very probably how your tooling reads the disks.
The short answer
The VDDK is the library that lets software outside the hypervisor read VMware virtual disks, and nearly every agentless migration or backup tool links against it. Its public download pages started returning 404 on 25 August 2026. Broadcom tells customers it's no longer available for use or download, and points at authorised technology alliance partners. Copies you already hold still work, the licence has never let you redistribute them, and the fallbacks are storage assisted migration, an agent inside the guest, a plain OVF export, or a platform whose importer never needed the VDDK.
What the VDDK actually does
Short version: it's a C library, shipped as a tarball for Linux and a zip for Windows, that lets a program read and write VMDK files without running inside ESXi. Two transports carry the data. NBD pushes blocks over the network through the host management interface, which is slow and works from anywhere. HotAdd attaches the source disk to a proxy virtual machine so the copy runs over the storage path, which is fast and needs that proxy sitting in the right place. Backup vendors have built on this since the late 2000s, and so has every agentless migration tool that wants to pull a powered off VM out of vSphere without logging into the guest.
The licence is what turns this from annoying into awkward. It has never permitted redistribution. No Linux distribution packages the VDDK and no container image ships with it. Tools work around that by asking you to supply the tarball yourself at install time. Red Hat's Migration Toolkit for Virtualization builds an image around a file you upload. Others do some version of the same dance. Perfectly reasonable while the download page existed. It also means the fix here isn't a mirror, and anyone offering you one on a forum is offering you a licence problem instead of a solution.
This has been eroding for a while, honestly. The 8.x downloads went quiet around November 2025 and only the 9.x line stayed up, which already broke tools pinned to the older releases. August finished the job.
Nobody announced it, and that's the story
The sequence is easy enough to reconstruct. On 25 August, ShapeBlue reported that every VDDK URL on the developer portal returned the generic "we might have removed the page during a website redesign" error, the 8.0 and 9.0 paths included, along with the installation guide. Two days later Red Hat published a support article titled "Unable to download VMware VDDK images for Migration Toolkit for Virtualization", telling customers to contact Broadcom because it can't host a proprietary package itself, and saying it's investigating ways to drop the dependency altogether.
Platform9 wrote it up on 1 September with the answer Broadcom gives customers who ask. To ensure the highest standard of security, reliability and product features, the Virtual Disk Development Kit is no longer available for use or download, and Broadcom continues to maintain APIs and SDKs so that authorised technology alliance partners can build backup and recovery software.
Read that twice. It isn't a deprecation with an end of life date attached. It's a redirection of everybody who isn't a partner towards somebody who is.
I might be wrong about the intent, and there's a duller explanation on the table: portal migrations at Broadcom have swallowed VDDK pages before, in February 2024 and again that September, and both times the pages came back. But a broken link doesn't usually come with a support answer explaining the philosophy behind it. This one reads like a policy that nobody wrote a blog post about.
What to do about it this week
Start by finding out whether you already have it. Plenty of shops pulled the tarball down years ago and never thought about it again, and a copy you obtained under the terms of the day is a copy you can keep using. On Linux hosts and appliances, this catches the archive and the installed library in one pass:
find / ( -name 'VMware-vix-disklib*' -o -name 'libvixDiskLib.so*' ) 2>/dev/null
Windows migration proxies usually keep the DLL somewhere under Program Files, and the search is worth running on the backup servers too:
Get-ChildItem C: -Recurse -Filter vixDiskLib.dll -ErrorAction SilentlyContinue
Anything you turn up, hash it and write the hash down somewhere durable, because the usual way of confirming a download is now a 404. Our hash generator does SHA-256 in the browser if you'd rather not remember which flag the command line wants, and if the tarball itself is unfamiliar territory, extracting and creating tar.gz archives covers the two commands you need.
Then work out what happens to the jobs that can't run without it. Storage assisted migration sidesteps the library completely by copying at the array, so your storage vendor is the first call. An in guest agent works on anything that boots. OVF export from vCenter is slow and wants staging space, and it has the considerable merit of being a feature nobody can take off a download page. Proxmox VE ships an importer that never touched the VDDK to begin with. And if you hold an active entitlement, open a support case, because that's the only route Broadcom has actually named, and undocumented policies get documented when enough tickets pile up against them.
Sources
ShapeBlue, Broadcom removes VDDK pages without explanation, 25 August 2026 (the 404s, the affected URLs, the licence and redistribution position, the 2024 and 2025 history). Platform9, Broadcom cut public access of Virtual Disk Development Kit overnight, 1 September 2026 (the statement Broadcom gives customers, and the alternative transports). Virtualization Howto, Leaving VMware just got harder after Broadcom pulled VDDK downloads, 7 September 2026 (the affected release lines and the list of tools). Red Hat support article, Unable to download VMware VDDK images for Migration Toolkit for Virtualization (MTV), 27 August 2026. The 8.0 release notes URL on Broadcom TechDocs was checked and returned 404 on 8 September 2026.
Frequently asked questions
Is the VDDK discontinued, or is this just a broken link?
Broadcom hasn't published either statement, which is the frustrating part. What exists is an answer given to customers through support saying the kit is no longer available for use or download, plus a pointer to authorised partners. That's more deliberate than a redesign accident, and the pages have now been gone for a fortnight. Two earlier disappearances in 2024 did get reversed, so I wouldn't call it permanent, but I'd stop planning around the download page coming back.
Can I keep using a copy I downloaded before August?
Yes, under whatever terms you accepted when you got it. Nothing has been revoked on machines that already hold the library, and tools that bundle it into an appliance image at build time keep working. What you can't do is pass that copy to a colleague at another company, put it in a container image, or drop it on a file share for a partner. The licence has never allowed redistribution, and that hasn't changed just because the source went away.
Which migration paths don't need the VDDK at all?
Storage assisted migration, where the array does the copy and the tool orchestrates it. Agent based migration, where something inside the guest streams the filesystem out. OVF or OVA export from vCenter, which is slow and storage hungry and entirely under your control. Proxmox VE's built in import wizard also reads VMware disks without the library. None of these are drop in replacements for an agentless job, and each one costs you either downtime or staging capacity.
Does this break my existing backups?
Not the ones already running. Backup software that installed the VDDK when it was deployed still has it, and jobs carry on. The exposure is a rebuild: a new proxy, a version upgrade that wants a newer VDDK, a lab rebuild, or a disaster recovery restore onto fresh infrastructure. That last one is the case to test now rather than discover later, so check whether your restore procedure assumes it can download anything from Broadcom.
Someone posted a mirror. Should I use it?
No. The redistribution terms are the reason no distribution ever packaged this library, and a random archive of a proprietary binary that reads your production disks is a bad trade whichever way you look at it. If you genuinely need a fresh copy and you hold an entitlement, the support case is the route Broadcom named. If you don't hold one, the honest answer is that your migration plan needs a path that doesn't depend on this library.
