OpenVDDK reads VMware disks through the library slot migration tools already use

The interesting VMware migration tool has a deliberately boring filename: libvixDiskLib.so.8.0.3. OpenVDDK uses the library name and C interface existing migration programs expect, putting a different implementation behind a plug they already know how to use. Sometimes the exit is a shared library.

The project README describes an independent implementation for Linux x86-64. It names nbdkit’s VDDK plugin and virt-v2v as existing consumers. That keeps the scope pleasantly specific. An administrator evaluating it can ask whether a particular disk-reading workflow works, without being asked to replace an entire virtualization platform before lunch.

Compatibility at this boundary means callers can keep speaking the interface they already use. That is the same practical advantage as replacing a worn adapter with one that fits the socket: the devices on either side still have their own requirements, but the connector does not demand that everything become a new product.

The project is explicit about the direction of travel. “It reads disks; writing is unsupported by design,” says the README. A migration plan must still account for what creates the destination disk, converts the guest and verifies the result. A successful read is a necessary piece of an exit, with several important pieces still waiting after it.

OpenVDDK says it was built from public documentation, linking information and observations of the reference library’s behavior. Its repository includes provenance and clean-room documentation. Those are the places to investigate the implementation’s stated origin; a library having the right name would establish none of that on its own.

The documentation also separates released files from the current source tree. It explains why the source build and an earlier distributed binary have different hashes after a module-path change. That kind of detail matters when a migration team is trying to identify exactly what it evaluated. A version number alone can be an annoyingly roomy address.

For a trial, the useful unit is one representative guest and its actual route through the conversion tools. Record the source platform, transport, library build and final disk result. Then check the migrated guest through the destination workflow you intend to use. A command finishing politely does not tell you whether the application inside the guest came along happily.

The Apache-2.0 release gives a team source it can inspect and build. It does not give the team a support contract or a successful cutover. The README describes community support without a guaranteed response time, which belongs in the planning conversation alongside the appealing absence of a proprietary library in this particular slot.

If the interface match holds for a team’s workload, evaluating a second implementation could become a manageable step inside the migration rehearsal. The remaining question belongs to the disk and the consumer together: does this specific pair produce the destination result the team can actually use?

The disk still gets the final say.