When VMware pulled its Virtual Disk Development Kit from public downloads, plenty of people lost a tool they never thought about. VDDK is a library that lets software read virtual disks. Backup products rely on it, and so do the migration tools that move machines off VMware. So cloud architect Andrija Panić wrote a replacement.
The timeline is short. In August, VMware limited VDDK downloads to its partners. Customers could no longer fetch it, and several rival migration tools became harder to install or run. Panić says a surprising range of software shares that one small library, from virt-v2v and nbdkit to the importers in Forklift/MTV, Proxmox VE and Apache CloudStack, along with countless home-grown scripts. His view was simple: your ability to move your own data shouldn’t hinge on a download page.
His answer, OpenVDDK, is a drop-in stand-in for the disk library that backup and migration tools load. He wrote it from scratch in Go, with a thin C layer that matches VMware’s interface, library name and symbol versions. By his account it relies only on public documentation and black-box testing and contains no VMware code. One limit matters: it reads disks but cannot write them, which suits backup and migration work.
Testing claims come from Panić himself. He reports success on vSphere 6.7 U3, 7.0.3, 8.0.3 and 9.1.1, and says every disk read matched in his lab runs on the newest version. Independent testers, he says, have used it with Forklift, MTV on OpenShift, a Proxmox VE pipeline and custom nbdkit tools. He also mentions production reports, such as a German cloud provider moving a large file server and a US company heading to Apache CloudStack. He is careful to add that these are not audited endorsements or guarantees for every environment. That candor is worth noting.
Other routes exist. OpenNebula’s OneSwap reports a 96 percent success rate, Nutanix adjusted its Move tool to work without VDDK, and Red Hat has described a workaround while it prepares a fix. Panić released OpenVDDK under an Apache license, so those teams could fold it in.
Anyone planning a real migration should test it on a copy first, since a single engineer’s project carries different risks than a vendor-supported tool.
