Índice
Há cerca de duas semanas, as páginas públicas de download do Virtual Disk Development Kit (VDDK) da VMware desapareceram sem aviso prévio. A interrupção imediata é real. O risco maior reside no que a Broadcom poderá fazer a seguir – e o que isso significaria para todas as ferramentas que leem discos VMware.
No final de agosto de 2026, as páginas públicas de download do Virtual Disk Development Kit (VDDK) da VMware desapareceram silenciosamente. Sem aviso de descontinuação, sem plano de transição, sem substituição. A ShapeBlue documentou a remoção em 25 de agosto, depois que todos os URLs específicos das versões 8 e 9 do VDDK começaram a retornar erros. Os clientes que abriram chamados de suporte foram informados de que a biblioteca "não estava mais disponível para uso ou download" e foram redirecionados para o Programa de Aliança Tecnológica da Broadcom. Dois dias depois, a Red Hat publicou um artigo de suporte confirmando que os usuários do Migration Toolkit for Virtualization não conseguiam mais baixar imagens do VDDK pelos caminhos indicados em sua própria documentação.
Por que uma biblioteca de desenvolvimento é tão importante?
A maioria dos administradores nunca baixou o VDDK por conta própria, mas quase todas as ferramentas que eles usam para migrar ou proteger cargas de trabalho do VMware dependem dele. Azure Migrate, Red Hat Migration Toolkit for Virtualization, Nutanix Move, virt-v2v, nbdkit, Platform9 vJailbreak e uma longa lista de produtos de backup e migração leem dados do VMDK por meio dessa biblioteca.
A dependência é excepcionalmente frágil porque a licença do VDDK não permite a redistribuição geral. Nenhuma distribuição Linux o inclui, nenhuma imagem de contêiner o contém e nenhum fornecedor sem um acordo assinado pode incluí-lo em um instalador. A documentação da maioria dos produtos afetados termina com a mesma instrução: baixe-o você mesmo do portal do fornecedor. Essa instrução agora é um beco sem saída – e a licença que criou a dependência também impede a solução óbvia, porque espelhar os binários simplesmente transfere a responsabilidade legal para quem os hospeda.
O acesso não desapareceu completamente. Clientes com uma licença vSphere ativa ainda podem encontrar o SDK no portal de suporte da Broadcom, e membros do Programa de Aliança Tecnológica podem solicitá-lo. Mas ambas as opções exigem um relacionamento comercial com a Broadcom, e o programa de parceiros é voltado para empresas que desenvolvem produtos na plataforma VMware – não para clientes que desejam migrar. Disponibilizar o download público transforma a etapa de “baixar o VDDK e migrar” em “abrir um chamado e torcer para dar certo”.”
O verdadeiro risco está no próximo passo.
A remoção do download é disruptiva, mas viável: fornecedores e clientes que já possuem os binários podem continuar a usá-los por enquanto. O cenário que o mercado deveria temer é a Broadcom dar um passo além e encerrar formalmente a licença, proibindo qualquer uso do VDDK sem permissão explícita.
Isso não seria um inconveniente técnico; seria um gargalo legal na porta de saída. Todos os fornecedores cujos produtos incorporam o VDDK precisariam da autorização da Broadcom para continuar distribuindo seus produtos, e há poucos motivos para esperar que essa autorização seja concedida livremente a empresas cujo negócio é migrar clientes do vSphere. Um fornecedor não entrega aos seus concorrentes as ferramentas para esgotar sua base instalada. Posição da Red Hat – o fato de não poder redistribuir o pacote por se tratar de um software proprietário da Broadcom – demonstra a fragilidade da base legal para todos que o utilizam como base.
As consequências se espalhariam rapidamente. Os cronogramas de migração atrasariam enquanto os fornecedores reestruturariam suas soluções. Produtos de backup que dependem do rastreamento de blocos alterados baseado em VDDK perderiam seu caminho mais rápido para os dados da VMware. Os clientes ficariam pressionados entre o aumento dos preços de renovação e uma rota de saída que se tornou mais lenta e arriscada. Na mesma semana, durante o VMware Explore, executivos da Broadcom sinalizaram o lançamento de uma nova versão do vSphere Standard voltada para ambientes menores – uma combinação que muitos clientes interpretarão como uma estratégia de incentivo e punição. Seja qual for a intenção, o efeito é a dependência da empresa por meio do controle da interface, em vez da qualidade do produto, e isso é ruim para todos os clientes, parceiros e concorrentes do ecossistema.
Onde fica a Hystax Acura
O Hystax Acura não é afetado por essa mudança, e isso se aplica a todos os três casos de uso: Migração, recuperação de desastres e backup.
Na arquitetura Acura, o VDDK reside em um único local: o VMware Replication Agent externo e sem agente, que lê discos virtuais por meio das APIs da própria VMware. Os clientes que já utilizam a biblioteca podem executá-la sem alterações. Todos os demais contam com uma alternativa compatível que não a utiliza.
→ Do lado da fonte, recursos Agente de replicação interno É executado dentro do sistema operacional convidado e replica em nível de bloco, independentemente do hipervisor subjacente. Não requer acesso à API da VMware nem ao VDDK, portanto, continua funcionando mesmo que a Broadcom encerre o suporte completamente.
→ Do lado do alvo, O Direct2Target elimina a dependência equivalente da plataforma de destino. Introduzido no Acura 4.5 e estendido a cenários de recuperação de desastres no Acura 4.6, O D2T replica e recupera dados no nível do disco por meio de um agente dedicado, sem acionar a API de gerenciamento da plataforma de destino.
Em conjunto, o agente interno e o Direct2Target fornecem um caminho de replicação que não depende da biblioteca da Broadcom na origem nem de uma API de gerenciamento no destino. Na prática, a alteração representa um pequeno inconveniente para uma das opções de implementação e não afeta a capacidade da Acura de migrar, proteger ou fazer backup de cargas de trabalho VMware – independentemente do destino. Pilha aberta, KVM, Virtualização Red Hat OpenShift, ou A própria VMware.
Está planejando um projeto de migração, recuperação de desastres ou backup para cargas de trabalho VMware e deseja um caminho de replicação que não dependa da biblioteca da Broadcom?
Descreva seu ambiente e nossos engenheiros mapearão as opções para suas plataformas de origem e destino.
Obrigado pelo seu pedido!
Entraremos em contato em breve.
O que fazer agora?
Se você está planejando migrar do VMware ou executar um sistema de recuperação de desastres (DR) dependente do VMware, há quatro coisas que vale a pena fazer neste trimestre.
- Faça um levantamento das dependências. Verifique se todas as ferramentas na cadeia – migração, backup, recuperação de desastres e qualquer script interno criado com base em virt-v2v ou nbdkit – exigem o VDDK.
- Confirme uma alternativa para cada uma. Uma ferramenta sem um caminho alternativo ao VDDK representa um ponto único de falha controlado pelo fornecedor que você está deixando.
- Conserve os arquivos binários que você já possui., e registre para quais versões do produto eles estão licenciados. Não os obtenha de servidores não oficiais: a licença restringe a redistribuição e cópias não verificadas representam um risco para a cadeia de suprimentos.
- Dê preferência a ferramentas que não foram construídas com base na suposição de que que a Broadcom sempre deixaria a porta aberta, porque essa suposição acaba de ser comprovada como errada.
A remoção do VDDK nos lembra que um plano de migração é tão portátil quanto sua dependência mais fraca. Descubra como a Hystax Acura aborda essa questão. migração para nuvem, recuperação de desastres e backup em plataformas VMware, OpenStack, baseadas em KVM e ambientes com acesso restrito à API.