Broadcom removed public access to VDDK download links
-
Hi everyone,
Some of you may already be aware of this but I learned the news this morning.
Essentially, Broadcom has decided, without any announcement, to remove all download links (and even some documentation it seems) for VDDK.
This impacts all migration tools that use the VDDK for copying data of VM disks.If you have any version of VDDK, please keep it somewhere safe and make backups.
I only have a x86-64 linux release from september 2025 that I used for testing V2V. Obviously, I can't share any link here but the release has the following sha256 hash:
79d215198f1b8fd1d240a16b27ac2543c521ae2afdc1876444c2acf8945d74ca VMware-vix-disklib-9.0.0.0.24742305.x86_64.tar.gz
Apparently, web archival links are also taken down.
-
Hi everyone,
Some of you may already be aware of this but I learned the news this morning.
Essentially, Broadcom has decided, without any announcement, to remove all download links (and even some documentation it seems) for VDDK.
This impacts all migration tools that use the VDDK for copying data of VM disks.If you have any version of VDDK, please keep it somewhere safe and make backups.
I only have a x86-64 linux release from september 2025 that I used for testing V2V. Obviously, I can't share any link here but the release has the following sha256 hash:
79d215198f1b8fd1d240a16b27ac2543c521ae2afdc1876444c2acf8945d74ca VMware-vix-disklib-9.0.0.0.24742305.x86_64.tar.gz
Apparently, web archival links are also taken down.
@olivierlambert
With Broadcom removing public access to VDDK downloads, we now have users who either cannot obtain VDDK at all or whose existing VDDK installations (main + backup) have become corrupted.This creates a real need for a fully open‑source fallback path inside V2V, one that still meets the performance requirements normally associated with VDDK.
The open‑source community has already demonstrated that VDDK‑level throughput is achievable without VMware’s proprietary stack. Several projects have shown that:
• Parallel NBD can saturate modern storage bandwidth when implemented correctly
• Highly multithreaded block pipelines can outperform single‑threaded VDDK transfers
• A throwaway Linux Proxy Copy VM can act as an efficient intermediary, reading blocks via NBD and streaming them directly to the destination hypervisor.This approach avoids VDDK entirely, remains fully open source, and provides a reliable fallback for users who can no longer access VMware’s proprietary components.
Given the direction Broadcom is taking, having this fallback inside V2V would significantly improve resilience for XCP‑ng users and ensure long‑term independence from VMware licensing changes.
The Proxy Copy VM must be treated as an ephemeral orchestration component — automatically excluded from the migration set and destroyed once the transfer completes — ensuring it never interferes with HA, LB, or startup/shutdown sequencing.
This architecture also gives Vates a clean, open‑source answer to Broadcom’s decision to pull public VDDK access — ensuring V2V remains fully functional even if VMware continues removing or restricting proprietary components.
-
P poddingue marked this topic as a question on
-
We are fully aware of Broadcom's decision to stop providing the VDDK library to the cloud community or to reserve its download to some authorized partners and customers. As much as we regret this decision, we have to respect it.
Because it impacts users who need to make backups, we are evaluating alternative options to address this situation. We will provide further guidance as this evaluation progresses but can't share more information for now.
-
J john.c referenced this topic on
-
Hi,
I'd like to introduce OpenVDDK, an open-source library I've been building.
OpenVDDK is an independent implementation of VixDiskLib, the virtual disk library in VMware's VDDK 8.0.3, for Linux x86-64. It is a drop-in replacement. It builds as libvixDiskLib.so.8.0.3 (with the usual .so.8 and .so links) and has the same C interface. Programs written for VixDiskLib, such as nbdkit's VDDK plugin and virt-v2v, load it in place of VMware's library without any source changes.
What it supports today:
- vSphere 6.7, 7.0 and 8.0 (tested on 6.7 U3, 7.0.3 and 8.0.3), through vCenter or by connecting directly to an ESXi host, including a standalone host without vCenter
- HotAdd, NBDSSL and NBD transports (hotadd:nbdssl:nbd); HotAdd is used through vCenter
- Linux x86-64 with glibc 2.28 or newer
- All 43 public functions of VixDiskLib 8.0.3, with the same SONAME and symbol versions as VMware's library
It is read-only by design: it reads virtual disks and does not write to them.
OpenVDDK is past its initial testing phase. Independent companies and individuals have validated it with their own tools:
- Forklift, migrating from VMware to KubeVirt, cold and warm
- Migration Toolkit for Virtualization (MTV) on OpenShift, cold and warm
- a VMware to Proxmox VE migration pipeline
- custom migration tools built on nbdkit's VDDK plugin
- V2K Migrate, migrating from VMware to Apache CloudStack
It is already in production use. A German cloud provider has migrated a large production file server with V2K Migrate, and at least one US-based company is using it to migrate off VMware to Apache CloudStack with KVM. It is ready for end-user testing and production use.
OpenVDDK is released under the Apache License 2.0, so you are free to use, modify, fork and redistribute it, including in commercial products.
Source code, documentation and how to report issues: https://github.com/openvddk/openvddk
More technical information, including performance improvements: https://openvddk.comIf it could be useful for your work, I'd be glad to hear your feedback.
OpenVDDK is an independent project and is not affiliated with or endorsed by VMware or Broadcom.
Andrija
-
Hello @andrija.panic !
I'm aware and I followed your work and announcements
It's great!On our side, we rely on our solution since the end of September: https://github.com/vatesfr/xen-orchestra/blob/master/CHANGELOG.md#690-2026-09-30 : "[V2V] Migrations no longer need the VDDK library".
We couldn't wait much more and we had to act very fast to remove this dependency.
-
Hello @andrija.panic !
I'm aware and I followed your work and announcements
It's great!On our side, we rely on our solution since the end of September: https://github.com/vatesfr/xen-orchestra/blob/master/CHANGELOG.md#690-2026-09-30 : "[V2V] Migrations no longer need the VDDK library".
We couldn't wait much more and we had to act very fast to remove this dependency.
Hi @olivierlambert, thanks for the insight on
vectura! Completely understand the need to move fast and gain full vertical integration over the V2V pipeline—it’s a great move for standard migrations.My suggestion to consider a dual-path approach with an OpenVDDK fallback is less about day-to-day operations and more about strategic, ecosystem-level insurance.
If we look at how the Xen Project / Xen Foundation handles governance, it provides a perfect architectural blueprint for this problem:
-
Shared Governance vs. Vendor Control: For OpenVDDK to be a reliable fallback against Broadcom's moving goalposts, it ultimately needs a single, unified organizational structure (similar to a Linux Foundation sub-project). If Vates, Red Hat, and the CloudStack/Proxmox communities pool resources into a shared, neutrally governed utility, the burden of reverse-engineering VMware's disk-format shifts is distributed across the entire industry.
-
Isolating the Core Stack: Just like XCP-ng handles alternative storage plugins or drivers, OpenVDDK wouldn't need to be baked into your core engine. It could live as a completely decoupled, optional legacy transport layer. If
vecturahits an unforeseen edge case, a specific CBT lock, or an old ESXi topology (like the legacy versions dropped in 6.9.0), the system has an automated valve to fall back on. -
Focusing R&D Resources: By helping steer a shared industry standard for the low-level data extraction layer, Vates secures a massive legal and engineering buffer against VMware licensing and structural changes, allowing your internal teams to focus 100% of their energy on making Xen Orchestra the best frontend destination.
It prevents Xen Orchestra from ever being caught by surprise, while still keeping your in-house binary as the primary choice.
-
-
Hi @olivierlambert, proposing a dual-path approach with an OpenVDDK fallback helps manage edge cases, as well idiosyncratic actions that are specific to VDDK or OpenVDDK when reading VMware specifics on their side.
-
@john.c Hey guys, my understanding (based on Googling...and NOT working with your software) is that you've historically used only the NBD/NBDSSL data path as a way to copy data from VMware. Is this correct? I refer to Xen Orchestra.
Over the weekend, I've finished testing the compatibility with Broadcom VCF 9.1.1 (actually, vCenter/ESXi 9.1.1) and have confirmed identical behaviour with the B library and openVDDK (the B one even crashes on AlmaLinux 9 without an additional package).
So all VMware vSphere versions from 6.7 to 9.1 are covered (this would allow you to support VMware customers moving away from 6.7 - and unfortunately there are still people using it).
With OpenVDDK you get HotAdd as well, besides NBD/NBDSSL (your current custom solution) - if you later decide to implement the VDDK HotAdd transport (proxy/worker VM inside the source vCenter, mounting local snapshot disk with datastore-speed reads which are significantly faster than the NBD/NBDSSL transport method - this is a general fact when it comes to VDDK).
Also pay attention to not "choke" the VM Kernel adapter with too many parallel NBD streams (NFC port 902), it has its own limits.Some performance notes:
Due to VMware's Terms and Conditions (inside VDDK bundles, and I have them all fresh from August 2026, v 7.xxx, 8.xxx. 9.xxx) - users are forbidden to "publish" benchmarking data, so I did not put a lot of that onto my website. But here is some real-world feedback from a few USA/EU companies that were testing it - and the speed gains are significant (I knew this due to my own testing, but it's always good to have 3rd party confirm it) - these below are from different companies and different tooling (Migratkit; Forklift into KubeVirt) - and I have more results, but don't want to share too much due to the evil eyes of B...
This is from another company:
These are just to scratch your imagination. And it behaves more properly than the B one - no silent failback to NBD on multi-disk VM migrations or short network hiccups, no crashing in certain cases, and much more helpful error/exit messages (identical exit/error codes, but I aimed to give a more informative message so users can more easily troubleshoot their software)
I'm already trying to put this under the umbrella of an open-source foundation (not ASF), but it will take time due to internal processes and, of course, legal reviews, etc.
Happy to share more if anyone is interested, but that would probably be better over a call, etc.
-
VMware customers moving away from 6.7 - and unfortunately there are still people using it
Sounds like people pretending to be in business. Can't update your software, really sounds like a "way to cheap to afford supported software, and to lazy to find other solutions".
Heck Hyper-V was more mainstream when 6.7 hit it's end of life.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login