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