Broadcom removed VDDK and shut VMware's exit door

In late August 2026, anyone who tried to reach the VMware VDDK download hit a 404 page. No advance warning. No official notice. No suggested alternative.

If you do not know what VDDK is, it sounds like a developer topic. It is not. It is a direct problem for anyone trying to move VMs off VMware — and that includes most of the environments I work with.

What VDDK is and why it matters

VDDK is the Virtual Disk Development Kit — a VMware library that gives low-level access to vSphere virtual disks. Technically: it abstracts the ESXi storage layer so external tools can read, copy, and move VMDKs without going through the management API.

In practice: it is the component that makes most migration and backup tools work. If you use any of those solutions, you depend on VDDK directly:

• Azure Migrate (Microsoft) — agentless migration of VMware VMs to Azure
• Migration Toolkit for Virtualization (Red Hat) — migration to OpenShift Virtualization
• Nutanix Move — migration from ESXi to AHV
• virt-v2v + nbdkit — VMware to KVM migration
• vJailbreak (Platform9) — VMware to private OpenStack migration
• Many third-party backup tools that snapshot at the disk level

What Broadcom did — and how the market found out

On August 25, 2026, ShapeBlue — a company focused on CloudStack and KVM migration — discovered that the VDDK pages referenced in VMware-to-KVM migration documentation were returning errors. They tested multiple paths, VDDK versions 8 and 9. All inaccessible.

No announcement. No deprecation note, no official alternative listed.

Customers who opened tickets with Broadcom support got a direct answer: VDDK is no longer available for general use or download. Support redirected customers to backup and recovery products from Broadcom Technology Alliance Program partners — meaning you need an active commercial relationship with Broadcom to get access.

The r/sysadmin thread about it was later removed by moderators of the official VMware subreddit. The comments are still accessible.

Who was affected and how each responded

Microsoft updated the official Azure Migrate documentation with a warning: Broadcom may restrict access to VDDK. The suggested alternative is agent-based migration instead of agentless — which raises complexity, requires OS access on each VM, and makes at-scale migration impractical without manual intervention.

Red Hat published a support article on August 27 confirming that Migration Toolkit for Virtualization customers are getting “not found” or “access denied” errors when downloading VDDK images. Red Hat’s position is clear: since VDDK is Broadcom proprietary software, they cannot host or redistribute it. Guidance is to contact Broadcom support. Red Hat engineering is investigating long-term alternatives to remove the dependency.

Nutanix was hit on Move — the VMware-to-AHV migration tool. Customers reported 404 even after logging into their Broadcom account. Broadcom told some of those customers that VDDK was moved inside the Technology Alliance Program and requires a specific contractual relationship for access.

Platform9 was vocal: the vJailbreak project, which uses VDDK + NBD for VMware migration, was directly affected. The company announced it is working on alternatives based on storage-assisted migration and an internal VM proxy.

The timing is hard to ignore

Days before the VDDK removal, Broadcom brought back VMware vSphere Standard — a more accessible edition, clearly trying to hold the SMB and mid-market that was leaving in bulk.

On one side, they relaunch a cheaper edition to slow the exit. On the other, they quietly remove the library the main migration tools need to work.

The sequence draws attention, but draw your own conclusions.

What is hard to ignore is the pattern: since the Broadcom acquisition in 2023, VMware has accumulated a series of moves that — regardless of intent — create friction for anyone who wants to leave. Perpetual license disappeared. Free ESXi was discontinued and then came back. Mandatory download tokens. And now VDDK.

Trust in the vendor is the most important asset in a long-term relationship with an infrastructure platform. And that asset is being eroded with each move like this.

What still works for migration — without VDDK

Good news: there are paths that do not depend on VDDK. But each has its own conditions.

Proxmox VE — native import wizard

Proxmox has a built-in import tool that connects directly to the ESXi host and copies the VMDKs. It does not use VDDK — it works via storage protocol. Works well for direct VMware → Proxmox migrations, with or without downtime depending on strategy. It is the most direct path for anyone already evaluating Proxmox as the destination.

If you have not read my analysis of when Proxmox makes sense, it is worth reading here →.

ZSvirt — agentless ZMigrate

ZMigrate, ZSvirt’s native migration tool, works agentless at the virtualization layer — without depending on VDDK. Full-disk block copy with background incremental sync, and cutover can happen in an approximately 5-minute window. For anyone evaluating ZSvirt as the destination, this is one of the concrete differentiators in this scenario.

I wrote about ZSvirt recently here → if you want the full context.

Agent-based migration

The alternative Microsoft points to for Azure Migrate without VDDK. Works, but requires installing an agent inside each source VM, OS access, and significantly raises complexity in environments with dozens or hundreds of VMs.

Storage-assisted migration

Depends on the underlying storage capabilities. Some arrays support replication that can be used as a migration base. Not universal, and requires case-by-case validation.

Standalone tools

Solutions like Doubletake (OpenText Migrate) do V2V without direct access to the source hypervisor — they work at the OS level, not the virtual disk level. Useful especially for unsupported OSes or when you do not have access to the VMware management layer.

What to do now if you have a migration in progress

First: check which tools in your process depend on VDDK. If you use agentless Azure Migrate, Nutanix Move, Red Hat MTV, or any third-party backup solution, confirm with the vendor what the current status is and what the alternative path looks like.

Second: do not rule out that Broadcom may reverse or soften the access. This move drew significant reaction from major vendors — Microsoft, Red Hat, Nutanix. Some adjustment is possible. But planning on the assumption that VDDK comes back is risky.

Third: document the environment before anything else. If you still have vCenter access, export a full inventory — VMs, network configs, datastores, snapshots, dependencies. That is the prerequisite of any migration strategy regardless of which tool you will use.

In my read

I work with environments of every size — from a single-host SMB to multi-cluster operations with DR. In most of them, especially the smaller ones, the “when do we leave VMware” question has been on the table in some form since 2023. Not because VMware is necessarily bad technically — but because the business model changed and the budget did not follow.

What the VDDK move changes in practice is the cost of exit. It did not make migration impossible — but it made it more work, more expensive, and more dependent on commercial support from Broadcom itself for anyone using the conventional tools.

Here it is worth a pause to explain where my defense of free software comes from — because it is not ideology, it is field experience.

The company you pay for years of licensing is exactly the one that can shut the door without advance warning. Not because it is necessarily malicious — but because its interest and yours diverge the moment you decide to leave. VDDK is just the most recent example of that.

Free software works differently. When there is a conflict of interest, the community reacts. The clearest example I remember: when the fight between pfSense and Netgate created an environment of uncertainty for anyone depending on the platform, the community did not wait — OPNsense was born, the project gained its own traction, and today it is a mature, independent alternative. Life went on its course, without depending on any vendor’s goodwill.

I am not saying paid software is always wrong. I am saying that when you pay for a proprietary license, you are renting the ability to operate your own infrastructure — and the rental contract has clauses you do not negotiate. In free software, the worst scenario is a fork. And forks have been happening faster than vendor notices.

For environments that have not started the migration: the planning window got smaller. The longer you stay on VMware without a clear exit plan, the more exposed you are to the next restriction of the same kind.

For those already in process: worth reviewing the toolchain now, before reaching the execution phase and finding a 404 halfway there.

Sources: VirtualizationHowto — Brandon Lee · ShapeBlue · Red Hat KB · Platform9 · 4sysops · r/sysadmin