OpenVDDK, the independent alternative to VMware’s VDDK library that lets backup and migration tools read virtual disks, is now open source under the Apache 2.0 license, and version 0.7.4, released on October 29, 2026, adds the NBD and NBDSSL transports alongside HotAdd. 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.
OpenVDDK in 20 seconds
- It replaces
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.
- Version 0.7.4 runs on Linux x86-64 and reads over HotAdd, NBD and NBDSSL.
- It is now open source (Apache 2.0) and free to download from GitHub.
Updated on November 3, 2026, with the source code release, version 0.7.4, and the newly supported transports and vSphere versions. The original version of this article, published on October 15, 2026, described a project in evaluation, with no public download and limited to HotAdd.
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 keeps the same shared object name and exported functions as VDDK, so existing tools can use it by swapping the file and restarting the service, with no need to integrate a different access method.
The project presents itself as independent of VMware and Broadcom, with no affiliation with or endorsement from either. According to its documentation, it contains no VMware code and reproduces the 43 public functions of VixDiskLib 8.0.3 through public documentation and black-box testing. Its scope remains 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, built by the same creator as OpenVDDK. 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 project’s website now adds that part of the gap came from a DNS lookup delay in the lab, so the advantage attributable to the library alone would be somewhat smaller.
The difference also shows up in disk open and close operations. According to the published results, opening a 40 GB disk takes 1.0 seconds with OpenVDDK versus 19.1 seconds with VDDK, and closing it takes 0.3 seconds versus 12.6. In incremental migrations, which can involve several read passes over a running virtual machine, those waits add up and stretch out the job even when the data volume transferred is small.
These figures are the project’s own lab measurements, not a guarantee of improvement for every infrastructure. The run took place 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 information, 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 sequential reads, though it also increases CPU use on the worker machine during the transfer. Final performance will also depend on source and destination storage, the network, and concurrent load.
What changes with version 0.7.4 and the open source release
The first change is the license. OpenVDDK is now published under Apache 2.0, with the code in its official GitHub repository, and it can be freely downloaded, forked, and redistributed. Its website says the tool is free and will stay free, and that moving the project to a neutral open source foundation is under discussion. The repository does not yet accept external pull requests and describes itself as read-only for now; bugs are reported through issues.
The second change concerns transports. Version 0.7.4 adds NBD and NBDSSL, which let the library read disks directly from an ESXi host or through vCenter, including standalone ESXi hosts without vCenter. HotAdd, which temporarily attaches the disk to a proxy machine, still requires vCenter; HotAdd on standalone ESXi is being considered for 0.7.5. According to the documentation, a request configured for NBDSSL only never falls back to clear-text NBD, and the library can open between 1 and 16 NFC sessions per disk.
Over NBDSSL, the project reports reads 14% to 42% faster than VDDK with a single reader, and roughly equal performance with four readers on the same disk. It also acknowledges cases where VMware’s library was faster: NBDSSL on CPUs without AES instructions, multiple readers under some loads, and an iSCSI VMFS path at an MTU of 1,500, where the gap was about 3%. Hardware-accelerated decryption requires the aes and pclmulqdq CPU flags; without them, software decryption is used.
vSphere compatibility has also widened. The website lists testing on vSphere 6.7 U3, 7.0.3, 8.0.3, and 9.1.1. Andrija Panic, the project’s author, clarified to this publication that the 9.1.1 testing was done after 0.7.4 was released, using that same version. That is why the README bundled with the 0.7.4 download still lists only 6.7, 7.0, and 8.0: the project does not change released files, so their published SHA-256 checksums stay valid, and the updated list will ship with the next release. The website and the main GitHub README now say so. vSphere 6.5 is not supported. Host requirements are unchanged: Linux x86-64 with glibc 2.28 or later, tested on Enterprise Linux 8 and 9.
Tested tools and remaining limits
The project lists several tools it has validated the library with: Apache CloudStack’s VMware import (using virt-v2v and nbdkit’s VDDK plugin), virt-v2v directly, nbdkit with nbdcopy and qemu-img, V2K Migrate to CloudStack or Proxmox VE, VEXXHOST’s MigrateKit to OpenStack, Forklift with KubeVirt’s disk importer, and the Migration Toolkit for Virtualization (MTV) to OpenShift Virtualization. It also names SYSTAVO, Celum, and ProxCenter as partners that have tested it in their own workflows, including a VMware-to-Proxmox VE migration pipeline.
Some gaps noted in October are now listed as covered. The documentation includes tests with CBT, snapshot chains, virtual-mode RDMs, disks of up to 3 TiB, and encrypted virtual machines over NBDSSL. It also describes crash recovery: if a process ends unexpectedly, the next run cleans up the resources left behind. The library connects only to the vCenter and ESXi hosts you specify and sends no telemetry.
Other limits remain. Encrypted virtual machines over plain NBD return an error in 0.7.4, and the 0.7.5 roadmap includes automatic encryption switching for that case. The SAN transport is deliberately out of scope, and writing is unsupported by design: write calls return the same read-only error as VMware’s library, so OpenVDDK cannot be used for restores. It is also a community project provided “AS IS,” with no guaranteed response times.
The download is offered on GitHub in two packages: a user kit for running existing tools and a developer kit for writing your own. Building from source is documented using an AlmaLinux 8 container under rootless Podman, and each release ships with an SPDX software bill of materials (SBOM). For teams planning moves off VMware, a shift partly driven by Broadcom’s new VMware pricing, which is already pushing some organizations away from the platform, interface compatibility can cut integration work, but it should still be validated in each environment with its own vSphere versions, storage, and workloads.
Frequently asked questions
What is OpenVDDK?
It’s an independent, open source implementation that replaces 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 only performs read operations.
Is OpenVDDK free and open source?
Yes. It is distributed under the Apache 2.0 license and can be downloaded for free from its GitHub repository, which does not accept external pull requests for now.
Which transports and vSphere versions does OpenVDDK support?
Version 0.7.4 supports HotAdd, NBD, and NBDSSL; SAN is out of scope. Its website lists testing on vSphere 6.7, 7.0, 8.0, and 9.1, and vSphere 6.5 is not supported.
How much faster is OpenVDDK than VMware VDDK?
In the project’s own tests, a hot migration went from 330 to 118 seconds, and a cold migration of a 200 GiB disk went from 15 minutes and two seconds to seven minutes and 24 seconds. These are lab measurements and don’t guarantee the same improvement in other environments.
Sources:
- OpenVDDK official website
- openvddk/openvddk on GitHub
- Andrija Panic, OpenVDDK author, communication to CloudNews.tech (November 3, 2026)
