Broadcom removed public access to VDDK download links

afk

Hi everyone,

Some of you may already be aware of this but I learned the news this morning.

https://www.virtualizationhowto.com/2026/09/leaving-vmware-just-got-harder-after-broadcom-pulled-vddk-downloads/

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.

john.c

@afk said:

Hi everyone,

Some of you may already be aware of this but I learned the news this morning.

https://www.virtualizationhowto.com/2026/09/leaving-vmware-just-got-harder-after-broadcom-pulled-vddk-downloads/

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.

poddingue

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.

andrija.panic

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.com

If 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

olivierlambert

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.

john.c

@olivierlambert said:

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 vectura hits 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.

john.c

Hi @olivierlambert, proposing a dual-path approach with an OpenVDDK fallback helps manage edge cases like encrypted disk images via TPM/KMIP key servers and metadata parsing failures by sharing the maintenance burden and isolating the transport layer.