OpenVDDK is a new independent alternative to VMware’s VDDK library that lets backup and migration tools read virtual disks. Its creator says the implementation, built from scratch using public documentation and black-box testing, cut a hot migration of a Linux virtual machine from 330 to 118 seconds in early tests with V2K Migrate. The project is still in testing and, for now, only supports reads over the HotAdd transport on Linux systems.
OpenVDDK in 20 seconds
- OpenVDDK aims to replace
libvixDiskLib.so.8.0.3without requiring changes to the applications that use it. - In a migration test with V2K Migrate, the time dropped from 330 to 118 seconds.
- Reading a 200 GiB disk hit 2,488 MiB/s, compared with 1,441 MiB/s using VDDK.
- The current implementation runs on Linux x86-64 and uses HotAdd to access disks.
- NBD and NBDSSL are planned but not yet available, and the project doesn’t offer a public download yet.
The project targets a specific piece of virtualization infrastructure: the library certain applications use to access the disks of virtual machines hosted on VMware vSphere. OpenVDDK aims to keep compatibility with the VDDK interface so existing tools can use the new implementation simply by swapping the library, with no need to integrate a different access method.
The project presents itself as an alternative independent of VMware and Broadcom. According to its documentation, it doesn’t include any VMware code and reproduces the needed functions through public documentation and black-box testing. The compatibility it claims is currently focused on reading disks for migration and backup processes.
From 330 to 118 seconds in a CBT migration
The first published test was run with V2K Migrate, a free, self-hosted tool for migrating virtual machines from VMware to KVM. The project’s maintainer says the same application version, the same virtual machine, and the same execution environment were used throughout, with only the disk-reading library swapped out.
The test consisted of a hot migration of a virtual machine running Debian 13 with a 20 GB disk. The process included a full baseline copy, two incremental transfers using Changed Block Tracking (CBT) with 2 GiB and 5 GiB of changes respectively, and a final pass after shutting the virtual machine down.
With VMware VDDK 8.0.3, the process took 330 seconds. With OpenVDDK, the time dropped to 118 seconds — roughly 64% less in that particular run. The maintainer notes both libraries processed the same data and that integrity checks produced identical results.
The difference also shows up in the time between completing a snapshot and having the disk available to the proxy system. According to the published results, that gap went from about 30 seconds with VDDK to around five seconds with OpenVDDK. Once the disk is attached, the new library starts reading within milliseconds and takes roughly 0.35 seconds to return it, compared with the 12.6 seconds recorded with VMware’s implementation.
These numbers help explain why the author highlights the disk’s open and close operations. In incremental migrations, which can involve several read passes over a running virtual machine, the wait between operations can add up and stretch out the job even when the data volume transferred is small.
These figures should be read as results from tests published by the project itself, not as a guarantee of improvement for every infrastructure. The run took place in a specific environment with ESXi and vCenter 8.0.3, a worker machine with three virtual CPUs and 4 GiB of memory, RAM-backed NFS 4.1 storage, and a 100 GbE connection. It was also a single run each, with no batch of repetitions to establish how much the results vary.
A second test with NetApp storage
OpenVDDK also published a cold migration test of a Windows Server 2019 virtual machine with a 200 GiB disk. In this case, V2K Migrate read the disk over HotAdd from NetApp NFS storage and wrote the result as a qcow2 file to an NFS export on the same system.
The full migration took seven minutes and 24 seconds with OpenVDDK, compared with 15 minutes and two seconds with VMware VDDK 8.0.3. Copy speed came in at 537 MiB/s with the new library and 282 MiB/s with VMware’s. The time from start to the first byte copied also dropped, from 93 to seven seconds.
According to the published data, both runs wrote the same amount of information and skipped the same blocks of zeros. V2K Migrate’s data check finished successfully, and a qemu-img compare confirmed the two qcow2 files were identical.
The project attributes much of the improvement to how reads are carried out. Instead of requesting a single block and waiting for it before continuing, OpenVDDK uses read-ahead and keeps several requests in flight. That approach can cut idle time in certain workloads, though it also changes the latency of each request and increases CPU use on the worker machine during the transfer.
In the NetApp test, the documentation estimates the process went from spending 594 seconds waiting on reads with VDDK to around 180 seconds with OpenVDDK. Once the wait at the source is reduced, writing the qcow2 file ends up accounting for a larger share of the total time.
The behavior observed doesn’t mean every disk will reach these speeds. Performance will also depend on the source and destination storage, the network, the virtual machine configuration, and concurrent load. The project itself also warns that the internal read-speed figures appearing in the two libraries’ logs aren’t directly comparable, because read-ahead lets OpenVDDK have data ready before the application requests it.
HotAdd is the first step, not a full replacement for VDDK
The current version of OpenVDDK focuses on the HotAdd transport, which temporarily attaches a virtual machine’s disk to another machine used as a proxy to read its data. The project says it has tested cold and hot migrations, incremental operations with CBT, snapshot chains, and multiple disks in parallel.
Declared compatibility covers Linux x86-64 with glibc 2.28 or later, tested on Enterprise Linux 8 and 9. On the vSphere side, the project says it has worked with versions 7.0.3 and 8.0.3. Support for vSphere 6.5 and 6.7 is on the roadmap.
The documentation also covers recovery testing after interruptions during connect and disconnect operations. The goal is for a later run to be able to clean up any resources left behind if a process ends unexpectedly. Tests performed include long-running cycles, disks of up to 3 TiB, and configurations with 17 disks on a single worker.
Even so, some cases remain uncovered, such as encrypted virtual machines, raw device mapping (RDM) disks, and larger-scale tests with multiple virtual machines. The NBD and NBDSSL transports are planned for a later phase, while the SAN transport is outside the announced scope. Writing disks isn’t planned either: OpenVDDK is designed to read data, not to perform restores through write operations.
The project’s status matters for teams running backup or migration infrastructure. Interface compatibility could cut integration work if it functions with existing applications, but it still needs to be tested in real environments with different vSphere versions, storage systems, and workloads — a shift partly driven by Broadcom’s new VMware pricing, which is already pushing some organizations to migrate away from the platform.
OpenVDDK isn’t available for public download yet. Its maintainer is looking for migration and backup teams willing to test evaluation builds in their own processes. A public release is planned for a later phase, once the project reaches its first release candidate.
Frequently asked questions
What is OpenVDDK?
It’s an independent implementation that aims to replace the libvixDiskLib.so.8.0.3 library used by tools that read VMware virtual disks. It was built from scratch, according to its maintainers, and focuses on read operations.
How much faster is OpenVDDK than VMware VDDK?
In tests published by the project, a hot migration went from 330 to 118 seconds. In a cold migration of a 200 GiB disk, the time dropped from 15 minutes and two seconds to seven minutes and 24 seconds. These are results from specific tests and don’t guarantee the same improvement in other environments.
Which transports does OpenVDDK support?
Currently, the project focuses on HotAdd for reading disks from Linux. NBD and NBDSSL are planned, while SAN is outside the announced scope.
Can OpenVDDK be downloaded?
Not yet. The project is looking for migration and backup teams to take part in testing with evaluation builds before it publishes a first release candidate.
