Executive Summary
Broadcom stopped publishing the VMware Virtual Disk Development Kit in late August, and the library inside it is how backup and migration tools read a disk on a running vSphere host. OpenVDDK is an independent implementation of that library under Apache 2.0, written from public documentation and black-box observation, with no VMware code in the tree. It builds to the same file name and the same 43 exported functions, so tools that already load VMware’s library load this one without a source change.
Version 0.7.4 shipped on 29 October, and the production stories attached to it come from its author rather than audited customers. The important part is not the license or the lab speed figures. It is that the choke point Broadcom created in August was a single binary sitting in a library path, and a single binary is the kind of thing one determined engineer can replace. The verdict is that migration friction dropped again this week, and the installer now carries a trust decision with it.
The kit Broadcom withdrew is called VDDK. It is a set of libraries. The one that matters is libvixDiskLib, which a backup or migration tool loads to read a virtual disk over the network. Every tool that reads a live VMware disk links against it.
Broadcom’s argument was that migration is not the licensed use case. The technical consequence was narrower. The disk format did not change and the readers did not change. What disappeared was a download.
The lock was a file name, not a disk format
OpenVDDK replaces the file rather than the format. It builds as libvixDiskLib.so.8.0.3 with the usual .so.8 and .so links, exports all 43 public functions of the 8.0.3 interface, and keeps the reference library’s symbol versions, so nbdkit’s VDDK plugin, virt-v2v and the commercial tools load it in place of VMware’s.
The provenance is documented rather than asserted. The repository records how each behavior was learned, from public documentation and from watching what VMware’s library visibly does when it runs, and the author states there is no VMware code in the tree. It targets Linux x86-64 with glibc 2.28 or newer. The tested platforms are vSphere 6.7 U3, 7.0.3 and 8.0.3, and the author told The Register this week that a 9.1.1 lab run, reached through vCenter, read every disk identically.
Read-only covers the migration and leaves the restore open
The library cannot write. Write calls return the same read-only error VMware’s returns, which is deliberate and which draws the boundary of the tool. Migrations and backup reads work. A restore path that expects to write through the same interface does not, and that rules out recovery use for now.
Transport support is narrower than the original too. HotAdd, NBDSSL and NBD are in, with HotAdd running through vCenter only. SAN transport is out, and so is direct access to local VMDK files. That removes the fastest path on a SAN-backed estate and leaves storage-side migration or a proxy copy.
The speed numbers are the project’s own, measured by swapping only the library file. A 200 GiB disk read at 2,488 MiB/s against 1,441. A 40 GB disk opened in 1.0 seconds against 19.1, and handed back in 0.3 seconds against 12.6. A warm migration of a running 20 GB virtual machine finished in 118 seconds against 330. The same page says some cases were slower with the replacement. Single runs in one lab are a reason to test, not a reason to believe.
Treat it as a binary in root’s path, because that is what it is
The production reports deserve the caveat the author attached to them. A German cloud provider migrated a large file server with V2K Migrate, a US company moved to Apache CloudStack with KVM, and testers reported Forklift to KubeVirt, Red Hat’s Migration Toolkit for Virtualization, and a Proxmox VE pipeline. None of it is an audited reference, and he says so.
That leaves ordinary third-party hygiene. Pin the release, check the hash against the published one, read the SPDX software bill of materials that ships with the kit, and confirm the no-telemetry claim on an isolated network. Start with a cold migration of one non-critical virtual machine before a wave goes near it.
Two other exits exist. OpenNebula says OneSwap succeeds on 96 percent of conversions, and Nutanix shipped a VDDK-free path in October. The difference this week is that the free option no longer waits on a vendor.
Three questions worth putting to your migration plan. Does it name the library it loads, or only the tool? Can you restore without that library? And who signs off on a community binary running as root on your proxy appliance?
Related reading. We covered Nutanix rewriting its own migration path around the VDDK removal in October, and the original analysis of why the public download disappeared explains what Broadcom said it had done.
The project is at github.com/openvddk/openvddk, with release 0.7.4 and the clean-room notes included in the repository. Its own site carries the documentation, compatibility notes and lab measurements. Broadcom’s position on the download is on the record with TechTarget, and the tools that load the library, nbdkit and KubeVirt among them, are open source.
Get the next one before it is old news
Independent analysis of cloud-native infrastructure, Kubernetes and data center economics. No vendor spin.