OpenVDDK: what the free replacement for VMware's VDDK really carries

In late August 2026 Broadcom removed the public download pages for VMware's Virtual Disk Development Kit, with no announcement and no alternative route. ShapeBlue documented on 25 August 2026 that every VDDK path variant on the Broadcom portal returns an error page, tested from Europe and through exit nodes in the United States, Brazil, Finland and Japan. Install instructions for virt-v2v, nbdkit and Apache CloudStack's VMware import have pointed at that dead link ever since. The cloud architect Andrija Panić wrote the affected library again.

OpenVDDK is an independent, open-source reimplementation of the VMware library libvixDiskLib.so.8.0.3, the layer through which backup and migration tools read VMware virtual disks from outside the hypervisor. It builds as the same file name with the same functions and symbol versions, which lets existing tools such as virt-v2v or nbdkit swap the file without any change of their own. The author states it was written clean-room, without VMware code. It reads, and only reads.

What the repository proves

The repository openvddk/openvddk is open and can be measured. Standing as of 11 November 2026:

The compatibility matrix is the most informative of these, because it treats negative and positive entries the same way. AlmaLinux 9.8, Debian 13 and Ubuntu 24.04 are tested as readers. vSAN, vVols and Fibre Channel are untested. vSphere 6.5 and older are excluded by name, and the SAN transport is unimplemented. All 43 public functions of VDDK 8.0.3 are listed with a status each, including the ones the project has not looked at yet.

Where the gap sits

Read-only is a deliberate decision, recorded in decision record D-0027. Write, WriteAsync, WriteMetadata, Shrink and Defragment are permanently out of scope. That is enough for a migration, which reads the source and writes the destination with its own code. It is not enough for a restore path through the same library, and that path is exactly what a backup chain built on VDDK needs.

A second point is missing from almost every report on the project: OpenVDDK reproduces the interface of VDDK 8.0.3, and the one of VDDK 9.0 stays open. Issue 3 in the tracker covers disk writes and the changed-area functions of the newer line. Tools built against 9.0 get nothing from it for now.

The open bug on ESXi 7.0 GA

On 7 November 2026 an operator posting as adminsyspro opened Issue 1. His setup is a typical migration setup: nbdkit with the VDDK plugin on a Proxmox VE node, reading a VM's disk over NBDSSL straight from an ESXi host address, with no vCenter in between. The host runs ESXi 7.0.0 GA, build 15843807. Every attempt fails with bad frame magic 0x4; the host tears the NFC session down after the handshake. The reporter captured the traffic, narrowed the problem to the resource pool request and attached a patch.

The maintainer replied on 8 November 2026 and confirmed the cause: 6.7 answers NFC version 2, 7.0.3 answers 9, 8.0 answers 11 and 9.1.1 answers 12. OpenVDDK sends features and the resource pool request from version 9 upwards, and at 7.0 GA that does not belong there. The fix lands in 0.7.5. The author also recorded that he will call 7.0 GA verified only once a real 7.0 GA host has run, and that he expects the builds between GA and Update 3 to take the same path without having tested them.

This is where a deployment decision is made. The matrix names 7.0.3, and an unpatched 7.0 host without vCenter runs into an open bug. Reaching for ESXi 7.0 GA without a vCenter is something that happens in a migration precisely when the vCenter has already been switched off and only the hosts are left.

The measurements, with their scale

The OpenVDDK project site carries figures against VMware's library. They are published with their conditions, and we have not remeasured them. Anyone quoting them has to send the scale along.

The fourth row comes from the same source and names a case where OpenVDDK is slower. Two more sit next to it: with four readers of one disk both libraries are on par, and reading in series over iSCSI VMFS at MTU 1500 left VMware's library about three percent ahead. The larger differences also hang on a detail the author lays out openly. VMware's library performs four name lookups when opening a disk, and in his lab every one of them waited five seconds for a DNS server that never answered. That alone explains a large share of the 19 seconds.

The comparison runs use V2K Migrate, a migration tool by the same author, shipped as a closed private beta and impossible to inspect. The data identity is still the strongest part of these measurements: both libraries produced the same SHA-256 across the whole disk and across all 800 ranges, and two qcow2 outputs compared identical under qemu-img compare.

State of the testing

The project tested itself and published that testing. docs/SECURITY-REVIEW-0.7.4.md from 30 October 2026 counts four low findings, no high and no medium, all four open and proposed for 0.7.5. The fourth is the most tangible: the allocated-block query over HotAdd runs across unencrypted NFC. Anyone able to change traffic between the proxy and the host's port 902 changes the block map that way, and a consumer copying only allocated blocks then skips data. No emergency scenario, but one line for a risk assessment of a production migration.

An outside audit does not exist. The Register reported on 3 November 2026 about successful production reports, including a German cloud provider and a US company moving to Apache CloudStack and KVM, and added explicitly that those reports are not independently audited. Thirteen days after the source was published the repository carries 13 commits, two contributors and 58 stars. The bus factor is one.

A predecessor exists in cloudbase/OpenVixDiskLib, 24 stars, last changed 8 October 2026. That is a Python library for the NFC path which can also write, but it requires vCenter 8, has vSphere 9 untested and knows no changed-block queries. OpenVDDK lists it as a source in its clean-room documentation. Free reimplementations of this library have existed for longer, then; what is new is the form as a swappable C library.

What this means for customer projects

Our host inventory lists no ESXi system and no backup path hanging on VDDK; our estate runs on Proxmox. The topic matters on the customer side: anyone leaving VMware needs exactly this read access to the source data.

We therefore keep OpenVDDK out of our toolkit for now and re-check three conditions. The first is release 0.7.5 with the fix from Issue 1, confirmed against a real 7.0 GA host. The second is a run of our own in a customer environment whose vSphere level and target platform are known, with a data comparison across the whole chain and into the started target VM. The third is a written assessment of the clean-room position before any commissioned run, because the raw evidence of that method sits outside the repository.

Anyone migrating today has routes without OpenVDDK as well. Nutanix changed its migration tool Move to manage without VDDK, OpenNebula accepted adding OpenVDDK to OneSwap for version 7.6, and Red Hat documents a workaround for its Migration Toolkit. Which route fits depends on the starting version and the target.

We have already worked through a multi-year migration calculation for three hosts, here. The individual steps of a move are in the VMware to Proxmox post, and the Forklift review post shows the gate we run an open-source project through. Every post on hypervisors, clusters and networking collects in the servers, Proxmox and network hub. Anyone who would rather not do the summing alone can go through it with us, our IT service for infrastructure and operations.

Further Reading

• OpenVDDK, repository, Apache-2.0, as of 11 Nov 2026
• OpenVDDK, compatibility matrix, tested vSphere levels, transports and gaps
• OpenVDDK, decision record D-0027, reasoning behind the read-only scope
• OpenVDDK, Issue 1, NBDSSL against a standalone ESXi 7.0.0 GA, with capture and a fix promised for 0.7.5
• OpenVDDK, Issue 3, disk writes and the changed-area functions of VDDK 9.0
• OpenVDDK, security review 0.7.4, self-review with four open low findings
• OpenVDDK, project site with measurements, own labs, no independent benchmark
• The Register: Architect creates open source replacement for VM migration tool, 3 Nov 2026
• ShapeBlue: Broadcom Removes VDDK Pages Without Explanation, 25 Aug 2026