OpenVDDKIndependent Virtual Disk Library.
Drop-in. Written from scratch.
OpenVDDK is an independent drop-in for libvixDiskLib.so.8.0.3, the disk library that VMware backup and migration tools load to read virtual disks. It was written from scratch, using only public documentation and black-box testing, and contains no VMware code.
Your application doesn't have to know
An application that loads libvixDiskLib.so.8.0.3 doesn't need to know whether it got VMware's VDDK or OpenVDDK: same file name, same functions, same calls, same data back. No rewrite and no new integration path. In our tests, the difference applications noticed was the timing.
Same file, same interface
The same shared object name and the same exported VixDiskLib functions. Replace the file and restart the service.
HotAdd
Attaches the snapshot disk to your proxy VM, finds and verifies it in the guest, reads it and hands it back. An interrupted run is cleaned up by the next one.
NBDSSL and NBD
Reads the disk directly from the ESXi host over NBDSSL or NBD, without a HotAdd proxy VM. NBDSSL encrypts the connection. Only the transports you request are used: an NBDSSL-only request never falls back to clear-text NBD. A disk can be read over several NFC sessions at once (OpenVDDK.nbd.sessions, 1 to 16, default 1), so a single reader gets parallel transfers without a wrapper.
Quick to open and close
Opening a disk takes about a second and handing it back a fraction of a second in our measurements. Sequential readers get read-ahead, including programs that read asynchronously, such as nbdkit's VDDK plugin under virt-v2v.
Read-only by design
OpenVDDK reads disks for backup and migration and cannot write to them. Write calls return the same read-only error as VMware's library.
Talks only to your vSphere
It connects only to the vCenter and ESXi hosts your tool points it at. No telemetry; nothing is sent anywhere else.
Measurements
How to read these figures. They are our own measurements in our own labs, not an independent benchmark. Each comparison used the same application build, the same VM, worker and storage, and swapped only the library file; most are single runs or pairs.
Results depend on your storage, network, CPU and application. In your environment the two libraries may perform the same, and in the cases listed under Where VMware's library was faster, OpenVDDK was slower. Please measure in your own setup. Ask us for the method in a GitHub issue.
Single operations on physical ESXi 8.0.3 hosts, read over HotAdd, with only the library file swapped.
The 200 GiB disk was read with one request in flight and gave the same SHA-256 through both libraries, for the whole disk and for all 800 ranges. Opening and closing were measured on a 40 GB disk on VMFS from the same worker, two runs each; these times depend on vCenter and the ESXi host.
In a warm migration of a running 20 GB Debian 13 VM under V2K Migrate, a free, self-hosted VMware-to-KVM migration tool (a full baseline, two Changed Block Tracking deltas of 2 GiB and 5 GiB, and the final pass after shutdown), OpenVDDK completed the four passes in 118 s. Every pass carried the same bytes with both libraries, V2K Migrate's data check passed, and the changed files hash identically in both migrated VMs. VMware's library took 330 s for the same four passes. At the time, every name lookup on our lab's workers waited 5 s for a DNS server that did not answer. VMware's library made four such lookups in each disk open (39 s, against 19 s once the DNS server was fixed); OpenVDDK's disk open looks up no name. V2K Migrate's own vCenter connections waited the same way with both libraries.
ESXi and vCenter 8.0.3. Read rate: worker VM with 3 vCPUs and 4 GiB, NFS 4.1 datastore backed by RAM over 100 GbE, single runs, 3 October 2026; the gain applies to a reader with one request in flight. Open and close: worker VM with 8 vCPUs, VMFS datastore on an iSCSI LUN, 8 October 2026.
A real migration on a storage array
Cold migration of a 200 GiB Windows Server 2019 VM with V2K Migrate: the disk is read over HotAdd from a NetApp NFS datastore and written as a qcow2 file to an NFS export on the same NetApp. Same V2K Migrate build, same VM, same worker, same settings; only the library file was swapped.
Both runs wrote exactly the same data: 181.3 GB to the qcow2 file and 33.4 GB of zeros skipped. V2K Migrate's data check passed both times, and qemu-img compare of the two output files reported them identical. The copier reads a block, writes it, then reads the next one: with VMware's library it spent 594 of the copy's 727 seconds waiting for reads, with OpenVDDK about 182 of 381 seconds. Most of the time now goes to writing the qcow2 file.
The whole migration took 7 min 24 s with OpenVDDK and 15 min 2 s with VMware's library. The same 5 s name-lookup wait applied: VMware's library made four lookups in its disk open and one in each of its seven allocated-block queries. Closing the disk, reading and the copy figures above were not affected.
Screenshot: the V2K Migrate worker's journal, filtered and shortened with the command shown at the top; internal names in the command are covered with grey bars. OpenVix: was the library's development log prefix up to 0.6.7; from 0.6.8 on it logs OpenVDDK: VixDiskLib: …. The MiB/s figure printed inside the log ("inside Read") counts only the time the application spent inside the library's read calls; with read-ahead the data is mostly in memory before it is asked for, so it is not a transfer rate. The real rate is the copy rate above.
ESXi and vCenter 8.0.3; worker VM with 3 vCPUs and 4 GiB on the source VM's host; NetApp NFS v3 datastore, destination over NFS 4.2 with 1 MiB transfers. Single run per library, 4 October 2026. The source datastore's NFS version made no difference: the same disk on an NFS 4.1 datastore of the same NetApp gave the same read rate.
How the hardware behaved
The worker VM and its ESXi host were sampled every two seconds during both runs. The full side-by-side profiler report is linked below; the main figures:
| OpenVDDK | VMware VDDK 8.0.3 | |
|---|---|---|
| Disk reads inside the worker, average / peak | 461 / 967 MiB/s | 227 / 616 MiB/s |
| Worker CPU busy, average | 37.8 % | 18.4 % |
| Worker memory used, average | 0.73 GiB | 0.70 GiB |
| ESXi host CPU, average | 12.9 % | 11.5 % |
| Read latency per request at ESXi, average | 18.8 ms | 2.5 ms |
- Twice the data per second, the same total work. The worker's CPU was twice as busy for half as long: CPU busy × duration comes to the same amount within 1 % for both runs. The ESXi host's CPU barely changed.
- Memory did not change: the read-ahead keeps a few 2 MiB blocks in flight, not the disk.
- The higher latency per request is how the speed is gained. VMware's library asks for one 1 MiB block at a time, so each request finds an empty queue (2.5 ms). OpenVDDK keeps several 2 MiB requests in flight; each waits longer in the queue (18.8 ms), and twice as much data arrives per second.
- The worker's I/O wait rose with it (average 40 % against 18 %): it is writing the qcow2 file over NFS twice as fast and waits for those writes more often.
- Both runs show a few dropped incoming network frames (58 and 120), at the same rate of about one every 7.6 seconds on both of the worker's network cards, including the idle management card: background frames the guest discards, not lost migration data.
Show the eight charts
Data written to the destination, MiB/s
Data read from the source disk, MiB/s
Worker CPU busy, %
Read latency per request at ESXi, ms
Both graphs of a pair share the same time axis, in seconds from the start of each migration plan; the grey area is the time after the OpenVDDK run had already finished. VMware's run starts copying later, partly because of the name-lookup waits described above.
NBDSSL and NBD on vSphere 8.0.3
The same disks read over the network transports, with the tools that use them: nbdkit's VDDK plugin with virt-v2v's settings, and virt-v2v itself. Same worker, same disks; only the library file was swapped.
In these tests, both libraries read the same bytes over HotAdd, NBDSSL and NBD, with the same allocated-block maps, the same metadata and the same error codes. virt-v2v converted the guest with either library, every connection over NBDSSL. With one reader at a time OpenVDDK was 14 to 42 % faster; with four readers of one disk at once the two were on par, the difference going either way with the load on the storage.
In one four-reader NBDSSL-only test on vSphere 8.0.3 (9 October 2026), three of the four connections made with VMware VDDK 8.0.3 used clear-text NBD without reporting an error. OpenVDDK kept all four connections on NBDSSL.
ESXi and vCenter 8.0.3; worker VM with 8 vCPUs and 16 GiB; a NetApp NFS v3 datastore and a VMFS datastore on a RAM-backed iSCSI LUN; 20 GiB disks; nbdkit 1.38.5 with virt-v2v's filters and 64 requests in flight, virt-v2v 2.7.1. Copy-phase figures from two runs (9 and 15 October 2026), read rates from one series (9 October 2026), each library run twice in alternating order. Measured on a worker whose CPU exposes AES instructions, as servers and most virtual machines do.
Where VMware's library was faster
- NBDSSL on a CPU without AES instructions. Some virtual machines are given a CPU model that hides them. NBDSSL then decrypts in software, which slows both libraries and OpenVDDK more: in a test on a physical ESXi 8.0.3 host, OpenVDDK read at 102–104 MiB/s against 158–176 MiB/s with VMware's library. OpenVDDK logs a warning at open naming the fix: give the reader VM the host's CPU features. NBD is not affected.
- Several readers of one disk at once. With four readers the two libraries were on par; the difference went either way with the load on the storage.
- A path that limits both libraries. Reading with nothing to do between reads, over iSCSI VMFS at MTU 1500 (about 1.0 GB/s), VMware's library was about 3 % faster.
Built alongside V2K Migrate
Validated with
OpenVDDK loads where VMware's VDDK library loads. These tools have used it as a drop-in, with no change to the tool itself.
| Tool | Migrates into | Tested by |
|---|---|---|
| Apache CloudStack's VMware import (virt-v2v with nbdkit's VDDK plugin) | Apache CloudStack (KVM), cold and warm | The OpenVDDK project |
| virt-v2v, VDDK input | KVM | The OpenVDDK project |
| nbdkit VDDK plugin, with nbdcopy and qemu-img | Any target nbdkit can write | The OpenVDDK project |
| V2K Migrate | Apache CloudStack, Proxmox VE; cold and warm with changed block tracking | The OpenVDDK project; in production at a German cloud provider |
| MigrateKit (VEXXHOST) | OpenStack | The OpenVDDK project |
| Forklift with KubeVirt's disk importer | KubeVirt, cold and warm | An independent tester |
| Migration Toolkit for Virtualization (MTV) on OpenShift | OpenShift Virtualization, cold and warm | An independent tester |
| A Proxmox VE migration pipeline (nbdkit's VDDK plugin) | Proxmox VE, cold and warm | An independent tester |
| A custom migration tool built on nbdkit (NBD and NBDSSL) | KVM | An independent tester |
| A custom fork of MigrateKit | Apache CloudStack, production migrations | An independent tester |
Project tests cover vSphere 6.7, 7.0 and 8.0 with HotAdd, NBDSSL and NBD. Coverage varies by tool and tester; not every tool was tested across every version or transport. Tested with something else? Tell us in a GitHub issue and we'll add it.
Tested by our partners
Companies that have tested OpenVDDK in their own environments.
SYSTAVO
Tested with V2K Migrate:
VMware to Apache CloudStack
Celum
Tested with Forklift:
VMware to KubeVirt, cold and warm
ProxCenter
Tested with their own
VMware to Proxmox VE pipeline
Logos are shown with each company's permission and reflect their own testing of OpenVDDK.
They do not mean that OpenVDDK is part of their products, or that they endorse it.
Where it stands
| Area | State | Notes |
|---|---|---|
| Licence | Apache 2.0, open source | Apache License 2.0. Use it, build it, ship it, fork it. |
| Latest release | 0.7.4 | 29 October 2026; user and developer kits available on GitHub |
| HotAdd transport, read | Working (released in 0.7.4) | Cold and warm migrations, CBT incremental passes, snapshot chains, virtual-mode RDMs, several disks in parallel, workers with or without disk IDs. The LVM safety check before a HotAdd attach runs once per process and again only when LVM's configuration changes. |
| NBD and NBDSSL transports | Working (released in 0.7.4) | Compared with VMware's library in the tested cases on vSphere 6.7, 7.0.3 and 8.0.3: same data, same allocated-block maps and metadata, same error codes; virt-v2v conversions; network faults and endurance tests of 20,000 cycles. Listed by the library as hotadd:nbdssl:nbd, in VMware's order. Transport lists are read as VMware's library reads them; skipz compression is honoured. VMware's NFC tuning keys (buffer size and count, read timeout, socket buffers, tmpDirectory, log levels) are honoured as VMware's library honours them, and keys the library does not act on are named in a warning at start-up. An unreachable host is answered within 10 s with VMware's own error code (14009). Upstream Migratekit (VMware to OpenStack) completes end-to-end migrations with OpenVDDK. |
| Direct ESXi connections (NBDSSL, NBD) | Working (0.7.4) | Read disks directly from an ESXi host, including a standalone host without vCenter. |
| HotAdd on a standalone ESXi host | Considered for 0.7.5 | Not available in 0.7.4. Use NBDSSL or NBD for a direct ESXi connection. |
| SAN transport | Not implemented | Deliberately left out of scope. Contact us if you need it. |
| Writing to disks (restores) | Not planned | Read-only by design: OpenVDDK reads disks for backup and migration. Write calls return the same read-only error as VMware's library. |
| Platform | Linux x86-64 | glibc 2.28 and newer; tested on Enterprise Linux 8 and 9. For hardware-accelerated NBDSSL, the reader's CPU must expose the aes and pclmulqdq flags; software decryption is used otherwise |
| vSphere | 6.7, 7.0.3, 8.0.3 | 6.7 Update 3; 6.5 is not supported for now |
| Crash safety | Tested | Process killed at every step of attach and detach; the next run cleans up |
| Negative, failure and scale tests | Mostly done | Done: duplicate proxies, lost vCenter sessions, full SCSI controllers, disks up to 3 TiB, virtual-mode RDMs, network faults, long endurance tests, 17 disks on one worker, two readers on one disk at once. Remaining: encrypted VMs, larger multi-VM runs |
| Software bill of materials | Included | The GitHub release includes an SPDX SBOM of the library and its tools |
What comes next
- Wider testing: test partners running it in their own pipelines, larger runs with many VMs and disks, Windows guests, OpenStack migrations.
- Encrypted VMs.
- A home in a neutral open-source foundation: in discussion.
- HotAdd on a standalone ESXi host: considered for 0.7.5.
OpenVDDK is free and will stay free. Download the kits from the GitHub release: a user kit for running existing tools, a developer kit for writing your own. Or build it from source.
Get OpenVDDK by email, or stay in touch
Subscribe for a personal download link and occasional release news. Tell us which software or project you would like to use it with. Personal download links from get.openvddk.com remain available.
Also on GitHub. Found a bug or tested it with your tool? Open a GitHub issue. Security reports: see SECURITY.md for private reporting via [email protected] or GitHub's private reporting where enabled.