The Impact and Importance of VMware's Restriction on VDDK

Over the past several weeks, a relatively technical issue in the VMware ecosystem has started creating a very real business problem for organizations trying to move and protect VMware workloads.

Access to VMware's Virtual Disk Development Kit (VDDK) has become increasingly restricted. This matters because VDDK is not simply another VMware utility. It is a foundational component used by many migration, backup, and disaster recovery products to access and transfer VMware virtual disks. The impact is already becoming visible.

Red Hat recently published guidance acknowledging that VMware VDDK images are no longer available to end users through the standard public download paths previously used by its Migration Toolkit for Virtualization (MTV). Because VDDK is proprietary Broadcom software, Red Hat cannot distribute it directly and is instructing customers to contact VMware/Broadcom to request access.

For organizations trying to migrate away from VMware, that creates an uncomfortable situation: the technology required to leave one infrastructure platform can itself depend on that platform's vendor.

At RackWare, this situation reinforces an architectural decision we made long ago.

RackWare RMM does not depend on VDDK because we purposely built our replication technology at the FileSystem level rather than the virtual-disk level.

Why VDDK Matters

VDDK was designed to provide applications with programmatic access to VMware virtual disks. Broadcom's own documentation describes VDDK as a set of libraries for manipulating and mounting virtual disks and explains its role in data protection workflows alongside VMware's VADP APIs.

That architecture, even with some drawbacks, can be extremely effective when the objective is operating within a homogeneous VMware ecosystem.  It can also be somewhat effective, to a lesser degree, when migrating to some Cloud environments.  Solutions that do this transform the VMDK to a form supported in the Target environment with a different hypervisor.  For example, multiple solutions can migrate workloads to AWS, Azure, GCP, and OCI.  

All these solutions for all these use cases require the VDDK to perform these functions. It involves installing a Virtual Appliance that runs at the hypervisor level incorporating functions from VDDK to access the virtual disks and track changes. 

Without the VDDK they cannot function . . . at all, leaving these solutions useless. 

It may be the case that some preferred partners with Broadcom/VMware have redistribution rights that will allow them to continue to function.  Any product without redistribution rights, as of this writing, is "dead-in-the-water".  It's conceivable that Broadcom/VMware will allow its preferred partners to continue to provide backup and DR functions. 

It's a reasonable conclusion, though certainly not proved, that VMware's intention is to inhibit migration from VMware to other platforms.  Even if companies have a redistribution agreement, will it be limited to backup and DR?  Perhaps even expressly prohibit migration use cases? 

Even if you are using a solution that is still allowed to use the VDDK (via redistribution rights, or because it was previously downloaded), this raises great concern for the longevity of those products.  If Broadcom/VMware is looking to maximize profits, will it continue to restrict usage so only their backup/DR solutions can be used?  

Given this surprising move by Broadcom/VMware and the uncertainty ahead, it behooves Enterprises to find a solution not dependent on the VDDK. 

We Built RackWare Differently

Fortunately, RackWare does not require the VDDK and operates completely independently of the Hypervisor.  RackWare employs a unique, patented, delta sync mechanism to execute Migration, DR, and backup operations that has the largest scope of use cases in the industry. It is a FileSystem mechanism, operating on used data, not a storage sector or VMDK-based approach.

RackWare's powerful solution replicates the operating system, applications, configurations, and data that make up the entire workload rather than making the underlying VMware VMDK the center of the migration or recovery process.

This gives us an important architectural separation between the workload and the infrastructure underneath it.

• A VMware VM can become a workload running on a different hypervisor.

• A physical server can become a cloud instance.

• A workload running in one public cloud can move to another.

• A workload can be replicated from one infrastructure architecture to a fundamentally different one.

  
  

If you have any migration or DR projects in flight that are impacted by restricted access to VMware's VDDK, please contact us.

Other Advantages of the FileSystem Architecture

It is important to make one distinction: we did not build RackWare's FileSystem architecture because we anticipated a VDDK access issue. We built it because we believed enterprise infrastructure would become increasingly heterogeneous.

That prediction has proven correct. Organizations today operate combinations of physical infrastructure, VMware, KVM-based platforms, private clouds, hyperscalers, sovereign clouds, and emerging virtualization platforms. They need to migrate and protect applications across these environments without requiring the source and destination infrastructure to look identical.

RackWare's architecture was designed around that reality. Our replication engine works with the workload rather than relying on a source hypervisor's virtual-disk format as the fundamental replication mechanism.

That is why RackWare describes RMM as hypervisor- and cloud-independent.

There Is Another Benefit: Data Consistency

The FileSystem approach also provides advantages beyond infrastructure independence.

RackWare integrates replication with operating-system mechanisms designed to maximize data consistency. RMM uses logical-volume snapshot capabilities such as LVM and VSS so outstanding I/O can be properly handled before replication occurs.

This becomes particularly important with databases and applications where simply copying changed storage blocks does not necessarily tell you everything you need to know about application state.

The objective of disaster recovery isn't merely to reproduce storage; it's to optimally recover entire production operations.

What This Means for VMware Customers Today

For organizations currently planning migrations from VMware or implementing a new DR solution for VMware staying in place, finding a VMware-independent solution seems prudent. 

But RackWare provides much more than just overcoming a VMware issue today:

• Selective sync at the drive, directory and file level

• Highly flexible DR policies with granularity of frequency and selected data

• Converged backup features such as retention policies and single file restore

• Far superior data consistency ensuring applications achieve production operational state with little to no intervention

• Permits DR test without bringing up a second site

• Not sensitive to network outages, never requires a complete re-replication of data no matter how long the outage

• Flexible and better storage options on target side

• Easy automation for both keeping IPs and updating IPs

• Supports in-memory applications (e.g., SAP HANA) as part of standard operations with no special or additional configuration or product extensions

• Initial replication is more efficient as it only replicates used data as opposed to the entire disk

• Not sensitive to disk defragmentation

• Single file restore and restore anywhere

• BIOS → UEFI and UEFI → BIOS conversion

• Can operate over private, public, and VPN networks

• No constraints from Image Template requirements

That distinction is particularly important as enterprises evaluate VMware exit, modernization, cloud migration, and disaster recovery strategies simultaneously. The same architecture can support migration today and resilience tomorrow.