VDDK Replacement Acceptance Test: What OpenVDDK’s Provenance Record Does and Doesn’t Establish

A VDDK replacement acceptance test starts with one question about the artifact: what exactly did qualification validate, and is that the file you would deploy? In late August, Broadcom’s public VDDK download pages stopped resolving. On November 3, The Register reported OpenVDDK, an Apache-2.0 library written in Go with a C shim that presents itself as a drop-in replacement for VMware’s disk library on Linux. The access story is covered in VMware Exit Plan: Broadcom Still Controls the Way Out and is not retold here. This post covers the narrower decision a team faces if it considers letting a third-party library sit inside a vendor-supported migration tool. It is a decision record, not a product review, and nothing in it recommends replacing an existing VDDK dependency.

Four Provenance Details, One Question

In virtualization architecture, a migration tool’s disk reader is part of the evidence chain. The disk reader sits in the source-data path, so the question of which file was tested is not a formality. The OpenVDDK project documents its artifacts openly. Read side by side, that documentation shows four details.

The release candidate. The library from the release candidate, hash prefix 9f3cc949…, took the project’s full release checks (record NBD-0031). Three builds from commit af1a56f produced identical output.

The shipped 0.7.4 library. The library in the shipped release, hash prefix 785883f6…, differs from the candidate, in the project’s words, “only in its commit stamp.” It received a short check: one read through vCenter and one directly from ESXi. The v0.7.4 release publishes two tarballs, a developer kit and a user kit, each named 0.7.4-94926da2f764, plus an SBOM and a SHA256SUMS file. The release page describes SHA256SUMS as the checksums of those three files. It does not list the library’s own hash, so the library hash cannot be reconciled against the published checksums, and this post does not assign it to either tarball.

A source build. A library built from the published source hashes differently again. The Go module path changed to github.com/openvddk/openvddk, and the library records the commit it was built from. The README states there is no functional difference.

A stale README in the download. On November 3, commit 93aee044dd9133f54fb7456dc7dd673ef8ba6340 (19:13 UTC) added a note that the README inside the 0.7.4 download predates the vSphere 9.1.1 test results. Those results landed in commits 558b9664e86cab3b7678eacecea01e11e3c6f03c and 165f823c5263d05ffc7f6a9b6e4f5244a7d8ecd9. The bundled README lists 6.7, 7.0 and 8.0. The project’s stated rule is that released files are not changed, which keeps the published checksums valid and also means the stale text ships with them.

Artifact	Hash prefix	What was run against it	What the project asserts
Release candidate library	9f3cc949…	Full release checks; three identical builds	Reproducible from commit af1a56f
Shipped 0.7.4 library	785883f6…	Short check: one vCenter read, one direct ESXi read	Differs from the candidate only in its commit stamp
Library built from published source	Different again	No qualification run stated in the material reviewed	No functional difference (README)

The project deserves a fair reading here. It documents all of this, publishes checksums and an SBOM, and shows reproducibility for the candidate builds. The gap is narrower and sharper than a disclosure failure. “No functional difference” is an assertion, and the full checks ran against a different file than the one a reader would deploy. The table does not show three independently qualified artifacts. It shows one fully release-qualified candidate, a shipped binary that received an abbreviated check, and a source build for which functional equivalence is asserted. A VDDK replacement acceptance test is meaningful only when the tested file and the deployed file are demonstrably the same.

What This Decision Is, and What It Is Not

The VDDK replacement acceptance test is not the route decision. Migration Path Authorization: Who Approves the VDDK-Free Route? owns the approval of a Move route that avoids VDDK and the five-part record behind it. It is also not the access boundary, which the exit plan post above owns.

The decision here is acceptance: whether a third-party library may sit inside a vendor-supported migration tool, and what evidence at the artifact, estate and vendor layers would justify it. Without a record, nobody can later say what was accepted, against which file, or on whose authority.

Several things stay outside this VDDK replacement acceptance test. It makes no performance claims, and the project’s own lab figures are not used. It reaches no legal conclusion about the project’s clean-room claim or about VMware’s SDK terms, and that status is NOT ASSESSED. It does not treat OpenVDDK as a general backup-and-recovery replacement. It compares no other substitute library.

One distinction on code origin belongs here. VMware’s proprietary VDDK is one thing. The project also compiles in govmomi v0.56.0, an Apache-2.0 Go library for vSphere, and used govmomi source as a reference for one request format. Those are different dependencies with different terms, and the first should not be read into the second.

The VDDK Replacement Acceptance Test: Five Requirements

A replacement library clears the test when each requirement below has a recorded status for your estate. The last column shows the current status of the published evidence, as reviewed on November 8, 2026. It is not a universal judgment about OpenVDDK, and a status changes when the evidence does.

Requirement	What to establish	What the published record shows	Status
Provenance and reproducibility	The library you deploy, hashed after extraction, matches the one that was tested	Candidate builds reproduce; shipped and source builds are asserted equivalent	PARTIAL
Coverage by transport and estate	Your transports and storage are inside the tested set	HotAdd, NBDSSL and NBD; named storage tested; vSAN, vVols and Fibre Channel not	BOUNDED
Operational boundary	The library does only what the migration needs	Read-only by design; writes refused	DOCUMENTED
Equivalence against your estate	Output matches the reference library on your disks	Project differential tests exist; no independent result	NOT INDEPENDENTLY ESTABLISHED
Receiving-vendor support	The tool vendor states a position on the substitute	Reviewed documentation states none	NOT STATED

Provenance and reproducibility

Hash the exact artifact you would deploy, in steps. Verify the archive checksum against SHA256SUMS. Extract the library from the archive and record its own hash. Compare that library hash with the hash of the artifact qualification ran against, and with a source build of the same tag. Record the module path, the commit stamp and the build environment. For OpenVDDK today, the candidate is reproducible and documented, while the shipped file and the source build rest on the project’s assertion of equivalence, and the release checksums cover archives rather than the library. Status: PARTIAL.

Coverage by transport and estate

The project documents HotAdd, NBDSSL and NBD. Testing covered VMFS 6 over iSCSI and local storage, and NFS v3 and v4.1 with HotAdd. Fibre Channel, vSAN and vVols are untested, and they should stay untested in your record until someone runs them. Encrypted VMs are refused. Independent disks and physical-mode RDMs are refused by OpenVDDK. SAN transport is not supported by design, and local VMDK files are not planned for 1.0. The build targets Linux x86-64 only. The project lists 45 known differences from VMware’s library. One of them carries a note in the release text itself: HotAdd on a direct ESXi connection is not used in 0.7.4, and the known-differences file inside the kit still describes it in older terms. Status: BOUNDED.

Operational boundary

OpenVDDK is read-only by design. Opening a disk requires the read-only flag, and write calls fail with VIX_E_FILE_READ_ONLY. OpenVDDK itself provides no write path to the opened disk. Read-only access can be used in backup workflows, but read-only behavior does not establish compatibility with a given backup product’s workflow. Any restore capability supplied by another component is outside this acceptance record and requires separate qualification. An acceptance record for a migration read path is not a record for a backup workflow. Status: DOCUMENTED.

Equivalence against your source estate

In a VDDK replacement acceptance test, the project’s differential tests are supporting evidence, not independent certification. The method compares OpenVDDK against VMware’s own library on identical inputs, which means the project’s testing process depends on a copy of VMware’s library. Three distinctions follow, and they should stay separate.

First, that dependency belongs to the testing process. It is not evidence that OpenVDDK incorporates proprietary VDDK code. Second, the project’s ability to run the test is not an ordinary reader’s ability to reproduce it today, because many readers can no longer download VMware’s package, and a cached copy may be the only reference left. Third, your own differential run against your own estate is the independent test, and it carries the same dependency. Status: NOT INDEPENDENTLY ESTABLISHED.

Receiving-vendor support

A migration tool vendor’s support position is a separate fact from a library’s transport compatibility. Three bodies of documentation were reviewed. Red Hat’s Migration Toolkit for Virtualization, version 2.4 prerequisites, requires building a VDDK image and warns about the license implications of pushing it to a public registry. Red Hat’s August 27 support note says it cannot host or redistribute that image. The nbdkit VDDK plugin documentation describes VMware’s proprietary VDDK as the required component and lists testing up to 8.0.0. Nutanix Move still requires a VDDK upload, and DirectPath in Move 6.3.3 is a separate route that avoids VDDK rather than a statement about substitutes. In each case, the reviewed documentation does not state a support position on substituting it. Broadcom’s wording on its own VDDK use cases, as reported by TechTarget, says nothing about OpenVDDK, and The Register’s report carried no Broadcom statement.

The review has limits. MTV 2.7 documentation was not read. Nutanix portal documentation was not read. The nbdkit page could not be fetched directly, so that evidence rests on search excerpts. Treat this as a bounded reading of three sources, not a complete vendor support investigation. Absence of a stated position is not acceptance, and it is not refusal. Status: NOT STATED.

A Worked Acceptance Record

The record below applies the VDDK replacement acceptance test to the published evidence as of November 8, 2026, filling every field, including the ones that stay empty. Every status is the current status of the evidence reviewed, not a verdict on OpenVDDK. It is a worked example of the method, not a certification, and it does not reach an outcome.

Field	Entry
Artifact under evaluation	OpenVDDK 0.7.4, Linux x86-64; operator to verify the downloaded archive and record the extracted library hash
Hash chain reconciled	No: SHA256SUMS covers archives, and library hash 785883f6… is not among the published checksums
Qualification basis	Full checks on candidate 9f3cc949…; short check on shipped library
Transports and storage in scope	HotAdd, NBDSSL, NBD; VMFS 6 and NFS tested; vSAN, vVols, Fibre Channel untested
Operational boundary	Read-only; no restore or write
Independent equivalence result	None; your own differential run required
Receiving-vendor position	NOT STATED (Red Hat MTV 2.4, nbdkit plugin documentation, Nutanix Move material)
Legal status of clean-room claim	NOT ASSESSED
Outcome	Accept for evaluation, defer, or decline: owner’s decision, with date and approver

Accept for evaluation, defer and decline are all outcomes this VDDK replacement acceptance test can support, and which one applies is the owner’s decision. Production use inside a vendor-supported tool would be a different record, because the vendor field would then carry a support consequence and not just a gap.

What Would Change the Record

Each change below is a dated, checkable event, and none of them appears in the material reviewed as of this writing. A receiving-tool vendor documents a position on substitute libraries, in either direction. A release appears whose published checksum matches a reproducible source build, or whose library hash is published alongside the archive checksums. An independent party publishes differential results on a named estate. vSAN or vVols coverage is recorded with results. Any of these moves a status in the VDDK replacement acceptance test, and the record should be reissued with its date when one does.

Additional Resources