Broadcom removeu o VDDK e fechou a porta de saída do VMware
No final de agosto de 2026, quem tentou acessar o download do VMware VDDK encontrou uma página 404. Sem aviso prévio. Sem comunicado oficial. Sem alternativa indicada.
Se você não conhece o VDDK, parece tema de desenvolvedor. Não é. É problema direto de quem está tentando migrar VMs fora do VMware — e isso inclui boa parte dos ambientes que atendo.
O que é o VDDK e por que ele importa
VDDK é o Virtual Disk Development Kit — uma biblioteca da VMware que permite acesso de baixo nível aos discos virtuais do vSphere. Tecnicamente: ele abstrai a camada de storage do ESXi para que ferramentas externas consigam ler, copiar e mover VMDKs sem precisar passar pela API de gerenciamento.
Na prática: ele é o componente que faz a maioria das ferramentas de migração e backup funcionarem. Se você usa alguma dessas soluções, você depende do VDDK diretamente:
- Azure Migrate (Microsoft) — migração agentless de VMs VMware pro Azure
- Migration Toolkit for Virtualization (Red Hat) — migração pro OpenShift Virtualization
- Nutanix Move — migração do ESXi pro AHV
- virt-v2v + nbdkit — migração VMware pra KVM
- vJailbreak (Platform9) — migração VMware pra OpenStack privado
- Diversas ferramentas de backup de terceiros que fazem snapshot a nível de disco
O que a Broadcom fez — e como ficou sabendo o mercado
Em 25 de agosto de 2026, a ShapeBlue — empresa especializada em CloudStack e migração KVM — descobriu que as páginas do VDDK referenciadas na própria documentação de migração VMware-to-KVM estavam retornando erro. Testaram múltiplos caminhos, versões 8 e 9 do VDDK. Todos inacessíveis.
Sem comunicado. Sem nota de depreciação e sem alternativa oficial indicada.
Clientes que abriram chamado no suporte da Broadcom receberam a resposta direta: o VDDK não está mais disponível para uso ou download geral. O suporte redirecionou os clientes para produtos de backup e recuperação de parceiros do Technology Alliance Program da Broadcom — ou seja, você precisa de um relacionamento comercial ativo com a Broadcom para ter acesso.
O thread no r/sysadmin sobre o assunto foi posteriormente removido pelos moderadores do subreddit oficial do VMware. Os comentários ainda estão acessíveis.
Quem foi afetado e como cada um respondeu
Microsoft atualizou a documentação oficial do Azure Migrate adicionando um aviso: a Broadcom pode restringir o acesso ao VDDK. A alternativa indicada é usar migração baseada em agente em vez de agentless — o que aumenta complexidade, exige acesso ao SO de cada VM e torna inviável migração em escala sem intervenção manual.
Red Hat publicou um artigo de suporte em 27 de agosto confirmando que clientes do Migration Toolkit for Virtualization estão recebendo erros “not found” ou “access denied” ao tentar baixar as imagens do VDDK. A posição da Red Hat é clara: como o VDDK é software proprietário da Broadcom, eles não podem hospedar nem redistribuir. A orientação é contatar o suporte da Broadcom. A engenharia da Red Hat está investigando alternativas de longo prazo para remover a dependência.
Nutanix foi afetado no Move — a ferramenta de migração VMware-to-AHV. Clientes relataram 404 mesmo após login na conta Broadcom. A Broadcom comunicou a alguns desses clientes que o VDDK foi movido para dentro do Technology Alliance Program e requer relacionamento contratual específico para acesso.
Platform9 foi vocal: o projeto vJailbreak, que usa VDDK + NBD para migração VMware, foi diretamente afetado. A empresa anunciou que está trabalhando em alternativas baseadas em storage assisted migration e proxy VM interno.
O timing é difícil de ignorar
Dias antes da remoção do VDDK, a Broadcom trouxe de volta o VMware vSphere Standard — uma edição mais acessível, claramente tentando segurar o SMB e o mid-market que estava saindo em massa.
De um lado, relançam uma edição mais barata para frear a saída. Do outro, removem silenciosamente a biblioteca que as principais ferramentas de migração precisam para funcionar.
A sequência chama atenção, mas tire suas conclusões.
O que é difícil de ignorar é o padrão: desde a aquisição pela Broadcom em 2023, o VMware acumula uma série de movimentos que — independente da intenção — criam fricção para quem quer sair. Licença perpétua sumiu. ESXi gratuito foi descontinuado e depois voltou. Tokens de download obrigatórios. E agora o VDDK.
A confiança no fornecedor é o ativo mais importante numa relação de longo prazo com uma plataforma de infraestrutura. E esse ativo está sendo erodido a cada movimento assim.
O que ainda funciona para migrar — sem VDDK
A boa notícia: existem caminhos que não dependem do VDDK. Mas cada um tem suas condições.
Proxmox VE — import wizard nativo
O Proxmox tem uma ferramenta de import integrada que conecta diretamente no host ESXi e copia os VMDKs. Ela não usa VDDK — opera via protocolo de storage. Funciona bem para migrações diretas VMware → Proxmox, com ou sem downtime dependendo da estratégia. É o caminho mais direto para quem já está avaliando o Proxmox como destino.
Se você ainda não leu minha análise sobre quando o Proxmox faz sentido, vale a leitura aqui →.
ZSvirt — ZMigrate agentless
O ZMigrate, a ferramenta de migração nativa do ZSvirt, opera de forma agentless na camada de virtualização — sem depender do VDDK. Faz full-disk block copy com sincronização incremental em background, e o cutover pode ser feito numa janela de aproximadamente 5 minutos. Para quem está avaliando o ZSvirt como destino, esse é um dos diferenciais concretos nesse cenário.
Escrevi sobre o ZSvirt recentemente aqui → se quiser entender melhor o contexto.
Migração baseada em agente
A alternativa que a Microsoft indica para o Azure Migrate sem VDDK. Funciona, mas exige instalar um agente dentro de cada VM de origem, acesso ao sistema operacional, e aumenta significativamente a complexidade em ambientes com dezenas ou centenas de VMs.
Storage-assisted migration
Depende das capacidades do storage subjacente. Alguns arrays suportam replicação que pode ser usada como base para migração. Não é universal e exige validação caso a caso.
Ferramentas independentes
Soluções como o Doubletake (OpenText Migrate) fazem V2V sem acesso direto ao hypervisor de origem — trabalham a nível de OS, não de disco virtual. Úteis especialmente para OSes não suportados ou quando você não tem acesso à camada de gestão do VMware.
O que fazer agora se você tem uma migração em andamento
Primeiro: verifique quais ferramentas do seu processo dependem do VDDK. Se você usa Azure Migrate agentless, Nutanix Move, Red Hat MTV ou qualquer solução de backup de terceiros, confirme com o fornecedor qual é o status atual e qual é o caminho alternativo.
Segundo: não descarte que a Broadcom pode reverter ou flexibilizar o acesso. Esse movimento gerou reação significativa de vendors grandes — Microsoft, Red Hat, Nutanix. É possível que haja algum ajuste. Mas planejar assumindo que o VDDK volta é arriscado.
Terceiro: documente o ambiente antes de qualquer coisa. Se você ainda tem acesso ao vCenter, exporte inventário completo — VMs, configurações de rede, datastores, snapshots, dependências. Isso é o pré-requisito de qualquer estratégia de migração independente de qual ferramenta você vai usar.
Na minha leitura
Atendo ambientes de todos os portes — desde PME com um único host até operações com múltiplos clusters e DR. Na maioria deles, principalmente nos menores, a questão “quando saímos do VMware” está na mesa de alguma forma desde 2023. Não porque o VMware seja necessariamente ruim tecnicamente — mas porque o modelo de negócio mudou e o orçamento não acompanhou.
O que o movimento do VDDK muda na prática é o custo de saída. Não tornou impossível migrar — mas tornou mais trabalhoso, mais caro e mais dependente de suporte comercial com a própria Broadcom para quem usa as ferramentas convencionais.
Aqui vale uma pausa para explicar de onde vem minha defesa do software livre — porque não é ideologia, é experiência de campo.
A empresa que você paga por anos de licenciamento é exatamente a que pode te fechar a porta sem aviso prévio. Não porque seja maliciosa necessariamente — mas porque o interesse dela e o seu divergem no momento em que você decide sair. O VDDK é só o exemplo mais recente disso.
O software livre funciona diferente. Quando há conflito de interesse, a comunidade reage. O exemplo mais claro que tenho na memória: quando a briga entre pfSense e a Netgate criou um ambiente de incerteza para quem dependia da plataforma, a comunidade não ficou esperando — nasceu o OPNsense, o projeto ganhou tração própria, e hoje é uma alternativa madura e independente. A vida seguiu seu curso, sem depender da boa vontade de nenhum vendor.
Não estou dizendo que software pago é sempre errado. Estou dizendo que, quando você paga por licença proprietária, você está alugando a capacidade de operar sua própria infraestrutura — e o contrato de aluguel tem cláusulas que você não negocia. No software livre, o pior cenário é um fork. E fork tem acontecido mais rápido do que vendor notice.
Para os ambientes que ainda não iniciaram a migração: a janela de planejamento ficou menor. Quanto mais tempo no VMware sem um plano claro de saída, maior a exposição a próximas restrições do mesmo tipo.
Para os que já estão em processo: vale revisar o toolchain agora, antes de chegar na fase de execução e encontrar um 404 no meio do caminho.
Fontes: VirtualizationHowto — Brandon Lee · ShapeBlue · Red Hat KB · Platform9 · 4sysops · r/sysadmin