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