A cloud architect has created an open-source replacement for VMware's Virtual Disk Development Kit, or VDDK, after Broadcom-owned VMware restricted public access to the software. VDDK is widely used by backup, storage and virtual machine migration tools because it allows applications to read and interact with VMware virtual disks. When VMware changed the way VDDK could be downloaded, the decision created problems not only for VMware customers but also for organisations trying to move virtual machines to competing platforms.
Cloud architect Andrija Panić decided to address that problem by building OpenVDDK, an independent implementation designed to work as a replacement for the VMware disk library. The project is intended primarily for reading virtual disks during backup and migration operations, giving users another way to access their own VM data without depending on VMware's restricted download process.
What VMware VDDK Actually Does
VMware describes VDDK as a collection of libraries and utilities that allows developers to build applications capable of accessing and manipulating virtual disks. It is particularly useful for storage, backup and disaster-recovery software because those applications often need to read the contents of VMware virtual machine disks directly.
Over time, however, VDDK became useful for another important purpose: moving virtual machines away from VMware. Migration tools could use the library to read VMware disk formats and transfer the contents into another hypervisor or cloud environment. That made VDDK valuable not only to VMware ecosystem partners but also to competitors offering migration paths towards alternative platforms.
VMware Restricted Public VDDK Downloads
In August, VMware restricted access to VDDK downloads so that the software was available primarily through its partner programme. This meant ordinary VMware customers could no longer obtain the library as easily as they had before.
The change also affected several migration tools from competing platforms because those tools relied on users downloading VMware's VDDK separately. Without easy access to the library, installing and running some migration workflows became more complicated. This created another obstacle for organisations already evaluating alternatives to VMware.
Many Migration Tools Depend On The Same Library
Panić explained that a surprisingly large number of migration and backup tools rely on the same underlying VMware disk library. These include virt-v2v, nbdkit, Forklift, Migration Toolkit for Virtualization, Proxmox VE, Apache CloudStack and numerous internally developed scripts.
Although these projects have very different purposes, they all need a way to read VMware virtual disks. VDDK provided that capability, so restricting access to the library created problems across several unrelated platforms at the same time. The change effectively made it harder for users to move or protect their own virtual machine data.
Panić Says Users Should Control Their Own Data
Panić said he did not think access to a user's own virtual machine data should depend on whether VMware continues offering a particular download page. That concern became one of the motivations behind creating OpenVDDK.
From his perspective, users should be able to back up or migrate their virtual machines without relying on continued access to a proprietary component distributed at the discretion of the original vendor. OpenVDDK therefore attempts to recreate the functionality required for those operations without using VMware's own source code.
OpenVDDK Is Designed As A Drop-In Replacement
Panić describes OpenVDDK as an independent replacement for libvixDiskLib.so.8.0.3, the VMware library commonly loaded by migration and backup software when it needs to access virtual disks. The idea is that existing applications expecting the VMware library can instead load OpenVDDK without requiring major modifications.
To achieve this, the project exposes the same C interface, library name and symbol versions expected by compatible software. From the perspective of the calling application, OpenVDDK is intended to behave closely enough to VMware's original library that migration tools can continue operating.
The Implementation Was Written From Scratch
Panić says OpenVDDK was built entirely from scratch using publicly available documentation and black-box testing. According to him, the project does not contain VMware source code or copied implementation details.
The software itself is primarily written in Go, with a thin C compatibility layer used to expose the expected interface to applications originally built around VMware's library. This approach allows the project to provide compatibility while maintaining an independent implementation.
The Tool Is Read-Only
One important limitation is that OpenVDDK can currently read virtual disks but cannot write to them. This means it is mainly intended for backup, export and migration scenarios rather than modifying VMware virtual disks directly.
For most migration tools, read access is the critical requirement because the software needs to extract data from VMware and convert or transfer it into another environment. The destination platform normally handles the creation of the new virtual disk, so write support to the original VMware disk is not necessarily required.
Read-Only Access Also Reduces Risk
The lack of write support can actually be beneficial for migration workflows because it reduces the risk of accidentally modifying the source virtual machine during extraction. A migration tool generally wants to preserve the original VMware environment until the new virtual machine has been successfully validated.
Read-only access means the source disk remains unchanged while its contents are copied elsewhere. If something goes wrong during the migration, administrators still have the original VM available as a fallback.
OpenVDDK Has Been Tested Across Several vSphere Versions
Panić says he successfully tested OpenVDDK against several VMware vSphere releases, including 6.7 U3, 7.0.3, 8.0.3 and 9.1.1. His testing included both environments managed through vCenter and standalone ESXi hosts.
According to Panić, every disk read performed during his lab testing produced matching results. That suggests the implementation is functioning correctly across a relatively wide range of VMware versions, although wider production testing is naturally still important.
Independent Users Have Reported Successful Migrations
Panić says other users have also reported successful testing with several migration platforms. These include Forklift for VMware-to-KubeVirt migrations, Red Hat's Migration Toolkit for Virtualization, Proxmox VE workflows and custom tools built around nbdkit.
Both cold and warm migration scenarios have reportedly been tested with some of these platforms. This is important because warm migration is significantly more demanding than simply copying a powered-off virtual machine, as administrators generally want to reduce downtime while data continues changing.
Production Use Has Also Been Reported
Panić says he has received reports of OpenVDDK being used in production environments. One example involved a German cloud provider migrating a large file server using V2K Migrate, while another involved a US company moving workloads towards Apache CloudStack running on KVM.
He was careful to clarify that these reports should not be treated as independently audited customer endorsements or as guarantees that OpenVDDK will work perfectly in every environment. That caution is appropriate for an open-source project that is still gaining broader real-world testing.
Open Source Software Still Requires Testing
The availability of OpenVDDK does not mean organisations should immediately replace VMware's library across critical production systems without validation. As with any infrastructure component, migration teams should test it carefully using representative workloads before relying on it for important virtual machines.
Storage layouts, snapshots, unusual disk configurations and different VMware versions may all introduce edge cases. A successful migration in one environment does not automatically prove every possible combination will behave identically.
The Tool Could Be Particularly Useful For VMware Exit Projects
OpenVDDK arrives at a time when many organisations are actively evaluating alternatives to VMware. Changes to VMware licensing, pricing and product strategy have led some customers to investigate Proxmox, KVM, OpenShift Virtualization, Nutanix, Apache CloudStack and other platforms.
Migration tooling becomes increasingly important during these transitions because moving hundreds or thousands of VMs manually is not practical. Anything that simplifies access to VMware disks can therefore make a large-scale platform migration considerably easier.
VDDK Restrictions Created Another Migration Friction Point
For organisations already planning a VMware exit, losing convenient public access to VDDK added another complication. Migration tools may still support VMware technically, but deployment becomes more difficult if administrators cannot easily obtain one of the required libraries.
This is especially frustrating because the VMs and their data belong to the customer. Organisations naturally expect to be able to export or migrate those workloads without unnecessary dependency on proprietary components that suddenly become restricted.
Vendor Lock-In Is Not Always About File Formats
Discussions about vendor lock-in usually focus on proprietary formats, licensing or APIs, but dependency on supporting libraries can create similar problems. A virtual disk may technically remain accessible, yet practical migration still becomes harder if the tools required to read it depend on software that is no longer publicly available.
OpenVDDK attempts to remove one of those dependencies. By recreating the interface used by migration tools, the project gives administrators another way to access the virtual disks they already own.
Compatibility Is The Key To Making OpenVDDK Useful
The clever part of the project is not simply that it can read VMware disks. Several tools can already access virtual disk formats through other methods. The important feature is that OpenVDDK aims to behave like the library existing migration software already expects.
This reduces the amount of work required from other projects. Instead of every migration platform rewriting its VMware integration immediately, developers may be able to replace the proprietary library with OpenVDDK and keep much of the surrounding workflow intact.
A Drop-In Replacement Can Extend Existing Tools
Software compatibility layers have historically been extremely useful when proprietary components disappear or become difficult to obtain. If the interface can be reproduced accurately, existing applications can continue operating without major architectural changes.
OpenVDDK follows the same idea. Migration tools already know how to communicate with VMware's disk library, so recreating that interface potentially preserves years of existing development work.
Proxmox Users Could Benefit
Proxmox VE has become one of the more frequently discussed alternatives for organisations moving away from VMware. Migration workflows involving VMware disks can depend on tools such as nbdkit and other conversion components that historically interacted with VDDK.
If OpenVDDK continues proving compatible, Proxmox users could gain another route for importing VMware workloads without needing access to VMware's restricted library. That could make migrations easier for smaller organisations that are not VMware partners.
KubeVirt And OpenShift Migrations Could Benefit Too
Forklift and Red Hat's Migration Toolkit for Virtualization are designed to help organisations move workloads into KubeVirt and OpenShift Virtualization environments. These tools also need to read VMware disks during the migration process.
Independent testers have reportedly used OpenVDDK successfully with both cold and warm migration scenarios. If that compatibility holds across larger environments, it could become particularly useful for enterprises shifting from traditional hypervisor infrastructure towards Kubernetes-based virtualisation.
Apache CloudStack Could Gain Another Migration Path
Apache CloudStack is another platform that may benefit from the project, particularly when KVM is used as the underlying hypervisor. Panić has already received a report of a company using OpenVDDK as part of a migration towards CloudStack.
For cloud providers managing large VMware estates, reliable disk migration is essential because the workloads may include large virtual disks and complex storage configurations. An open implementation gives those operators another tool to include in their migration pipelines.
OpenVDDK Is Not The Only Alternative
Organisations looking to migrate away from VMware are not completely dependent on OpenVDDK. Several platform vendors have already developed approaches that avoid VMware's restricted library.
OpenNebula, for example, provides OneSwap, which the company says achieves around a 96% success rate when migrating workloads. The tool is designed specifically to help move virtual machines from VMware environments into KVM-based OpenNebula deployments.
Nutanix Has Modified Move To Work Without VDDK
Nutanix has also adjusted its Move migration tool so that VMware workloads can be migrated without relying on VDDK. This is particularly important for Nutanix because migration simplicity has become a significant part of the company's efforts to attract VMware customers.
Removing the proprietary dependency gives Nutanix more control over the entire migration process. It also avoids situations where VMware changes access to a component and unexpectedly disrupts a competitor's migration tooling.
Red Hat Is Working On Its Own Solution
Red Hat is also developing changes intended to address the VDDK availability issue. In the meantime, the company has provided workarounds for customers using its migration tooling.
OpenVDDK could potentially provide another option depending on how well it integrates with Red Hat's supported workflows. However, enterprise customers may still prefer officially supported approaches rather than introducing an independently maintained library into production migration processes.
The Apache License Makes Adoption Easier
Panić released OpenVDDK under the Apache License, giving other developers considerable freedom to use, modify and distribute the software. This could make it easier for migration platforms to incorporate the project directly rather than requiring users to install it separately.
Projects such as Red Hat's migration tools, Proxmox integrations or other open-source platforms could potentially build on OpenVDDK if they determine the implementation is sufficiently mature. A permissive licence reduces legal and practical barriers to that kind of adoption.
Open Source Could Reduce Dependence On One Vendor
The wider significance of OpenVDDK is that it provides another example of open-source software reducing dependency on proprietary infrastructure components. If a migration workflow relies entirely on a library controlled by the vendor users are trying to leave, that creates an uncomfortable dependency.
An independent implementation gives users and competing platforms more control. Even if VMware changes its download policies again, the open-source community can continue maintaining the alternative.
Migration Tools Are Becoming Strategically Important
Historically, hypervisor migration was often something organisations performed occasionally during major infrastructure refreshes. The current VMware market has changed that considerably, with many companies actively evaluating migration at the same time.
As a result, tools capable of moving workloads reliably between hypervisors have become strategically important. The easier it is to migrate, the less power any single virtualisation vendor has to lock customers into its platform.
Moving Storage Is Often The Hardest Part
Virtual machine configuration information is usually relatively small, but the actual disk data can be enormous. A single enterprise VM might contain hundreds of gigabytes or several terabytes of storage.
Reading those disks efficiently while maintaining consistency becomes one of the biggest challenges in migration. Tools such as VDDK historically provided highly optimised access to VMware storage, which is why replacing that functionality matters so much.
Warm Migration Makes The Problem Even Harder
Cold migration is conceptually straightforward because the source virtual machine can be powered off before copying its disk. The downside is downtime, which may be unacceptable for critical applications.
Warm migration attempts to copy most data while the source VM remains running, then synchronises the remaining changes during a shorter cutover period. Supporting this process requires reliable and consistent access to virtual disk data, making compatibility particularly important.
Backups Depend On The Same Capabilities
The issue extends beyond migration because backup products also need reliable access to VMware virtual disks. VDDK has long been used by backup vendors to read VM data without requiring software agents inside every guest operating system.
Although VMware partners can still access the official VDDK, independent tools and smaller developers benefit from having an open implementation available. OpenVDDK could therefore eventually become useful beyond migration alone.
Read-Only Design Fits Backup Workflows Well
Because OpenVDDK is read-only, backup applications are another natural fit. A backup system typically needs to extract data from a source disk without modifying it.
This makes the current limitation less problematic for many use cases. Write support could expand the project's possibilities later, but reliable read access already covers the most important requirement for backup and export operations.
Independent Testing Will Be Important
For OpenVDDK to become widely trusted, it will need testing across much larger combinations of VMware versions, storage systems and VM configurations. VMware environments can include snapshots, thin-provisioned disks, encrypted storage and several transport methods.
Community testing can gradually identify edge cases that a single developer's lab cannot realistically reproduce. Clear bug reports and reproducible test cases will therefore be important as the project matures.
Enterprise Support Could Become A Future Question
Open-source projects frequently become widely adopted once organisations begin offering commercial support around them. Enterprises often care less about whether software is free and more about who they can call when something breaks during a critical migration.
If OpenVDDK becomes popular enough, service providers or migration vendors may eventually build supported products around it. The Apache licence makes that possibility relatively straightforward.
VMware's Decision May Have Accelerated Competition
Ironically, restricting access to VDDK may ultimately encourage competitors and independent developers to create alternatives that reduce dependence on VMware entirely. When a proprietary component remains easily available, there is less incentive to replace it.
Once access becomes difficult, building an independent implementation suddenly becomes worthwhile. OpenVDDK is a direct example of that effect.
Open Standards Make Exits Easier
The situation also demonstrates why infrastructure architects frequently prefer open formats and interfaces. A platform becomes easier to adopt when users know they can eventually leave without facing significant technical barriers.
Migration does not need to be effortless, but organisations generally want confidence that their own data remains accessible without depending indefinitely on one vendor. Open implementations can provide an important escape path when proprietary tooling changes.
The Project Is Still Young
Despite the promising test results, OpenVDDK should still be viewed as a relatively young project. Panić himself has cautioned that reported successful migrations do not represent audited guarantees of suitability for every production environment.
Organisations planning large migrations should therefore test carefully and maintain rollback options. Successful open-source infrastructure projects usually earn trust gradually through widespread testing rather than immediately after release.
Existing VMware Customers Should Plan Migration Tools Early
Even organisations that have not decided to leave VMware may benefit from understanding their migration options before they actually need them. Waiting until contract renewal or another urgent business event can create unnecessary pressure.
Testing alternative tools in advance provides a clearer understanding of how long migrations take and which workloads may require special handling. OpenVDDK could become one more option worth evaluating during that planning process.
Final Thoughts
OpenVDDK is an interesting response to VMware's decision to restrict public access to the Virtual Disk Development Kit. By building an independent implementation of libvixDiskLib.so.8.0.3, cloud architect Andrija Panić is attempting to restore a capability that many migration and backup tools previously depended on.
The project was written from scratch using public documentation and black-box testing, with no VMware code included. It currently provides read-only access to virtual disks and has reportedly been tested successfully across vSphere 6.7 U3, 7.0.3, 8.0.3 and 9.1.1, along with several migration tools including Forklift, MTV, Proxmox VE and Apache CloudStack workflows.
OpenVDDK is not the only route away from VMware, as OpenNebula, Nutanix and Red Hat are already developing or providing alternatives that avoid VDDK. However, the project's Apache licence and drop-in compatibility approach could make it particularly useful to other open-source migration tools.
The broader lesson is arguably more important than one library. Customers should not need permission from the platform they are leaving simply to access and migrate their own virtual machines. OpenVDDK exists because one developer decided that dependency did not make sense and built an open alternative instead.
Comments 0