Around 25 August 2026 the public VDDK downloads vanished, and the reading that spread was that Broadcom had shut VMware's exit door. We went to check which door we were talking about. Some migration routes read disks through that library and some never touch it; Proxmox's ESXi importer is one of the latter. Checking takes three minutes and has a catch, because the proof anyone would reach for first — opening the package's dependencies — is precisely the one that proves nothing.
We already wrote about this in September, when the news was fresh, and we argued then that the first thing that breaks isn't your migration, it's your backup: the urgent part wasn't the migration but the backup chain. This post is the other half, the one we left unresolved there. If the software that reads VMware disks from the outside depends on a library that is no longer downloadable, the remaining question is which exit routes run through it. That one gets answered by opening files, not by having opinions.
What exactly was pulled
The VDDK (Virtual Disk Development Kit) is the kit an external program uses to open a VMware virtual disk and read it block by block without going through the guest operating system. Two things get confused here and are worth separating: the list of which blocks changed since the last pass is asked of the vSphere API, through QueryChangedDiskAreas, which remains public; what the VDDK provides is reading those blocks. On disk it is a file with a name of its own and a version suffix, libvixDiskLib.so.N, shipped inside the vmware-vix-disklib-distrib bundle. For years you downloaded it from the developer site with nothing more than an account, and a good part of the backup, replication and migration software that touches VMware was built on top of it.
Those pages stopped responding around 25 August 2026, with no prior warning and no public announcement, according to the timeline heise published on 22 September. Broadcom confirmed it on 9 September in the driest possible terms: "The approved use case for VDDK per the SDK license has always been for backup and recovery solutions from our TAP partners, and this change merely re-enforces those terms." In other words: they don't frame it as a withdrawal but as the enforcement of a licence that already said so. The library still exists for selected members of the Technology Alliance Program; what disappeared is the open download.
Checked on 2 November 2026, before publishing this: /sdks/vmware-virtual-disk-development-kit-vddk, its variant without vmware, and the same with /latest all return 404 on developer.broadcom.com; the pyvmomi SDK page, on the same domain, returns 200. And now the honest part, which took us a while to swallow: that 404 does not on its own prove anything was withdrawn. We tried an identifier we made up and it returns exactly the same, and so does /sdks/vsphere-web-services-sdk/latest, for an SDK that still exists. What establishes the withdrawal is the reporting and the vendor's own confirmation, not our curl. We leave it here because the date of our check does count: as of today, that door doesn't open.
What the Proxmox importer's dependencies say
Proxmox VE's ESXi import wizard lives in a package called pve-esxi-import-tools. We went to the pve-no-subscription repository index for Debian trixie and copied it exactly as it comes, version constraints included. Version 1.0.1:
Package: pve-esxi-import-tools
Version: 1.0.1
Depends: python3, python3-pyvmomi, libc6 (>= 2.34),
libfuse3-4 (>= 3.17.2), libgcc-s1 (>= 4.2),
libssl3t64 (>= 3.0.0), libzstd1 (>= 1.5.5)
Description: Tools to allow importing VMs from ESXi hosts
Provides a FUSE file system to access files on ESXi hosts and a python utility
to query the list of VMs and datastores.
There is no VDDK in there. There is python3-pyvmomi, the Python SDK for the vSphere API — open source under the Apache licence, version 9.1.1.0 published on PyPI on 3 September 2026, downloadable by anyone right now — and there is libfuse3, because the package mounts the ESXi datastore as a file system and reads the .vmdk files from there, talking to the host directly.
And here is the catch we promised, because that absence proves far less than it looks like. The VDDK cannot be redistributed: its licence doesn't allow it. So no Debian package can declare it in Depends, whether it uses it or not. The absence is a structural certainty, not evidence.
The counterexample is right there and we checked it the same day: nbdkit-plugin-vddk (version 1.48.1-1 in Debian's contrib section) reads disks through the VDDK — it is, literally, the VDDK plugin — and its dependency field reads libc6, nbdkit. Nothing else. It loads the library at runtime, from a path you supply. So anyone stopping at Depends can get it wrong in both directions.
So what does prove something? Three things, in this order of weight. The weakest is the one we just showed. Second: the official Proxmox wiki describes the whole procedure without naming the VDDK once, and what it describes is a component of its own talking to the ESXi host API. The third and best one runs on the machine, because there declarations stop mattering: either the library is there or it isn't.
apt-cache show pve-esxi-import-tools | grep -E '^(Version|Depends)' dpkg -L pve-esxi-import-tools find / -name 'libvixDiskLib.so*' 2>/dev/null
The third command is the one that counts, and not only on Proxmox: run it on every machine that takes part in your exit plan or your backup chain. If it returns anything, that piece reads disks through the VDDK and you have just found a dependency on a file that is no longer publicly downloadable. If it returns nothing, don't celebrate yet: the library may ship embedded inside your vendor's container or installer, which is exactly the route Broadcom leaves open to its partners. Which is why the account manager should be asked something else: whether the product includes the library or expects you to supply it, and where the one it ships came from.
Which routes read through the VDDK and which don't
What follows are each vendor's statements about their own tool, not our interpretation. With a caveat ShapeBlue applies to itself, which we repeat because it is fair: their section about their own product should be read "as the vendor pitch it is".
| Exit route | Reads via VDDK? | Who says so |
|---|---|---|
| Proxmox VE ESXi importer | No | Package 1.0.1 dependencies: pyvmomi + FUSE |
| Migration Toolkit for Virtualization (Red Hat) | Optional, but recommended | "Strongly recommended to create a VDDK image": it "accelerates migration and reduces the risk of a plan failing"; if one fails without it, "retry with VDDK installed" |
| MTV on vSAN-backed disks | Required | "VM migrations do not work without VDDK when a VM is backed by VMware vSAN" |
| ShapeBlue Migrate direct and CBT methods | Yes | "Two of the four read through VDDK today" |
| Its overlay and OVF methods | No | "Two of the routes do not need the library at all" |
The third row is worth reading twice. On vSAN-backed disks, Red Hat's route without the VDDK doesn't migrate. And the Proxmox importer, which uses no VDDK at all, doesn't handle vSAN either: its wiki says so, for a different technical reason and with the same outcome for anyone whose VMs live there. Two opposite routes, the same wall, and that wall isn't the withdrawn library. It's vSAN, which has been sitting there for years and made no headline in August.
The small print of the route that does work
Taking "Proxmox imports without the VDDK" at face value is the quickest way to a bad surprise halfway through a maintenance window. Its documentation lists six things the importer doesn't do, and all six read better before you promise a date than after:
- ✗"Importing a VM with disks backed by a VMware vSAN storage does not work." One sentence, no conditionals, no hedging: if your disks live on vSAN, this route ends here.
- ✗No encrypted disks. "Encrypted VM disks, for example via a Storage Policy, cannot be imported."
- ✗Snapshots make it slow. "Importing a VM from VMware ESXi can be significantly slower if the VM has snapshots." Consolidating that delta-disk chain belongs to the preparation, not to the window.
- ✗Through vCenter, worse. "While one can also import through a vCenter instance, doing so will dramatically reduce performance." Point straight at the ESXi host instead.
- ✗Tested up to ESXi 8.0. "Import was tested from ESXi version 6.5 up to version 8.0." If you are already on a later branch you are in undeclared territory: test it with a throwaway VM before promising dates.
- ✗And no, there is no zero downtime. There is live import — the VM boots on Proxmox while the data copies — but the documentation itself clarifies that "the VM on the ESXi is still switched off, so there will be some downtime". There is still a downtime window: what shrinks is how long it lasts.
To that list we add ours, from the migrations we have actually done: the disk arrives fine almost every time and it's the guest that complains. Windows booting on a controller it doesn't recognise is the classic case, and we covered it in detail in the disk arrives intact and Windows won't boot. The wizard brings you the blocks; booting is still your problem.
The risk nobody put in a headline
The remaining way to get the library yourself runs through the support portal. ShapeBlue puts it like this in its 25 August note: customers with active VMware entitlements should check their Broadcom Support Portal access and ask their contact for an authorised download route. The condition comes before the advice, and it is the part that matters.
An exit tool that requires you to still be inside carries an expiry date you don't control. During the migration it doesn't bite, because support is still being paid. It bites eighteen months later, when someone asks to recover a file from a 2025 backup stored in VMware format and the contract has been closed for a year. That one doesn't get solved in procurement: it is a restore that cannot be done, and it lives in the same drawer as every other third-party dependency nobody inventoried.
The exit route is an architectural decision, written down before you sign, with the same care you put into choosing storage. A vendor changing the rules of its SDK without notice is within the realm of the foreseeable: failure is inevitable. Being left unable to read your own disks because of it is a design decision, and you signed it.
The five checks we run before giving a date
- 1Where each disk lives. VMFS, NFS, vSAN or policy-encrypted. If vSAN or encryption shows up, the importer route is out and that has to be solved before anyone talks dates.
- 2Which library each tool uses. The
findabove on everything involved, plus a written question to the vendor about whether it embeds the VDDK or expects you to supply it. - 3One real VM, timed. Not an empty test one: one with its actual disk size, to measure the window against the bandwidth you have, not the one the brochure promises.
- 4The old backups. Decide today how a VMware-format backup will be read two years from now, assuming the contract is gone. If the answer depends on a support portal, it isn't an answer.
- 5The way back. What happens if two hours in the VM won't boot and people are waiting. We write it down before starting, and we developed it in the rollback plan for a Proxmox migration.
What actually decides who gets out
Broadcom has closed one specific door, the one used by software that reads VMware disks from the outside, and left it open to its partners. Anyone leaving via the Proxmox importer never went through it. Anyone leaving with a tool that reads through the VDDK now has a contract problem dressed up as a technical one. And underneath both groups sits the thing that really sets the date: where the disks live. On vSAN both routes crash, the one that uses the library and the one that doesn't, and no download portal fixes that.
At everyWAN this falls under VMware to Proxmox migration and, when the question is whether to move or hold, under consulting. We run Proxmox VE with Ceph in production, and we have been working with Proxmox since the 3.x branches; we have migrated companies we have also recommended staying on VMware when the numbers favoured staying. We don't resell either platform, so the recommendation doesn't change our invoice.
Sources. Download removal and timeline (25 Aug 2026, no public announcement) — heise, 22 Sep 2026. Broadcom's confirmation and TAP-partner quote, plus Platform9's statement (Nicole Silva, VP at Platform9: "by publicly restricting access, without warning, Broadcom disrupted many migrations that were already in-flight"; worth knowing that Platform9 sells migrations off VMware) — TechTarget, 9 Sep 2026. Which routes depend on the VDDK and the support-portal path — ShapeBlue, 25 Aug 2026. VDDK image recommendation and the vSAN case — Red Hat MTV 2.8 documentation. Importer limitations, tested versions and the live-import note — Proxmox VE wiki. Version and dependencies of pve-esxi-import-tools 1.0.1 — package index at download.proxmox.com, retrieved 2 Nov 2026. pyvmomi 9.1.1.0 (Apache 2.0, 3 Sep 2026) — PyPI. Name and location of libvixDiskLib.so — nbdkit-vddk-plugin manual. Dependencies of nbdkit-plugin-vddk 1.48.1-1 — Debian sid contrib index, retrieved 2 Nov 2026. The 404 and 200 status codes are our own checks from 2 Nov 2026, with the negative control described in the text. Declared dedupe: the timeline of the withdrawal, Broadcom's position and the importer's limitations were already published by us on 10 Sep 2026; what is new here is the package-index evidence together with its counterexample, the per-vendor breakdown and the vSAN convergence.
Do you know which library your VMware exit plan reads through?
We review it with you: where each disk lives, which tool depends on what, how long the real window is, and what happens if it doesn't boot. And if the numbers favour staying, we'll say so.
Talk to everyWAN
Microsoft 365
ES 
CAT 
EN