Tabla de contenido
Hace aproximadamente dos semanas, las páginas de descarga pública del kit de desarrollo de discos virtuales de VMware desaparecieron sin previo aviso. La interrupción inmediata es real. El mayor riesgo reside en lo que Broadcom podría hacer a continuación y en las consecuencias que esto tendría para todas las herramientas que leen discos de VMware.
A finales de agosto de 2026, las páginas de descarga pública del Kit de Desarrollo de Discos Virtuales (VDDK) de VMware desaparecieron sin previo aviso. No hubo aviso de descontinuación, plan de transición ni reemplazo. ShapeBlue documentó la eliminación el 25 de agosto, después de que todas las URL específicas de las versiones 8 y 9 de VDDK comenzaran a mostrar errores. A los clientes que abrieron casos de soporte se les informó que la biblioteca "ya no estaba disponible para su uso o descarga" y se les redirigió al Programa de Alianza Tecnológica de Broadcom. Dos días después, Red Hat publicó un artículo de soporte confirmando que los usuarios de Migration Toolkit for Virtualization ya no podían descargar imágenes de VDDK a través de las rutas que su propia documentación había indicado.
Por qué una biblioteca para desarrolladores es tan importante
La mayoría de los administradores nunca han descargado el VDDK, pero casi todas las herramientas que utilizan para migrar o proteger cargas de trabajo de VMware dependen de él. Azure Migrate, Red Hat Migration Toolkit for Virtualization, Nutanix Move, virt-v2v, nbdkit, Platform9 vJailbreak y una larga lista de productos de copia de seguridad y migración leen los datos VMDK a través de esta biblioteca.
La dependencia es inusualmente frágil porque la licencia VDDK no permite la redistribución general. Ninguna distribución de Linux la incluye, ninguna imagen de contenedor la incorpora y ningún proveedor, sin un acuerdo firmado, puede incluirla en un instalador. La documentación de la mayoría de los productos afectados termina con la misma instrucción: descárguelo usted mismo desde el portal del proveedor. Esta instrucción ahora es un callejón sin salida, y la licencia que creó la dependencia también bloquea la solución obvia, ya que replicar los binarios simplemente traslada la responsabilidad legal a quien los aloja.
El acceso no ha desaparecido por completo. Los clientes con una licencia de vSphere vigente aún pueden encontrar el SDK a través del portal de soporte de Broadcom, y los miembros del Programa de Alianza Tecnológica pueden solicitarlo. Sin embargo, ambas opciones requieren una relación comercial con Broadcom, y el programa de socios está diseñado para empresas que desarrollan productos en VMware, no para clientes que intentan migrar a otra plataforma. Eliminar la descarga pública convierte la opción de "descargar el VDDK y luego migrar" en "abrir un ticket y esperar".“
El verdadero riesgo está en el siguiente paso.
Eliminar la descarga supone una interrupción, pero es viable: los proveedores y clientes que ya poseen los binarios pueden seguir utilizándolos por ahora. El escenario que debería preocupar al mercado es que Broadcom vaya un paso más allá y cierre formalmente la licencia, prohibiendo cualquier uso del VDDK sin autorización explícita.
Eso no sería un inconveniente técnico; sería un obstáculo legal insalvable. Cada proveedor cuyo producto incorpore el VDDK necesitaría el consentimiento de Broadcom para seguir comercializándolo, y hay pocas razones para esperar que dicho consentimiento se otorgue libremente a empresas cuyo negocio consiste en migrar clientes fuera de vSphere. Un proveedor no les da a sus competidores las herramientas para que le roben su base de clientes instalada. La postura de Red Hat El hecho de que no pueda redistribuir el paquete porque es software propietario de Broadcom demuestra lo débil que es la base legal para todos aquellos que trabajan con él.
Las consecuencias se extenderían rápidamente. Los plazos de migración se retrasarían mientras los proveedores rediseñaran sus arquitecturas. Los productos de copia de seguridad que dependen del seguimiento de bloques modificados basado en VDDK perderían su vía más rápida hacia los datos de VMware. Los clientes se verían presionados entre el aumento de los precios de renovación y una ruta de salida que se ha vuelto más lenta y arriesgada. Esa misma semana, en VMware Explore, los ejecutivos de Broadcom anunciaron una nueva versión de vSphere Standard dirigida a entornos más pequeños, una estrategia que muchos clientes interpretarán como una estrategia de incentivos y sanciones. Cualquiera que sea la intención, el efecto es la dependencia del proveedor mediante el control de la interfaz en lugar de la calidad del producto, lo cual es perjudicial para todos los clientes, socios y competidores del ecosistema.
¿Dónde se encuentra Hystax Acura?
Hystax Acura no se ve afectado por este cambio, y esto se aplica a sus tres casos de uso: migración, recuperación ante desastres y copias de seguridad.
El VDDK se ubica en un único lugar dentro de la arquitectura de Acura: el Agente de replicación de VMware, externo y sin agente, que lee discos virtuales mediante las API de VMware. Los clientes que ya utilizan la biblioteca pueden ejecutarla sin modificaciones. Los demás usuarios disponen de una alternativa compatible que no la modifica.
→ Por el lado de la fuente, el Agente de replicación interno Se ejecuta dentro del sistema operativo invitado y se replica a nivel de bloque, independientemente del hipervisor subyacente. No requiere acceso a la API de VMware ni VDDK, por lo que seguirá funcionando incluso si Broadcom cierra definitivamente la puerta.
→ En el lado objetivo, Direct2Target elimina la dependencia equivalente en la plataforma de destino. Introducido en Acura 4.5 los extendido a escenarios de recuperación ante desastres en Acura 4.6, D2T replica y recupera a nivel de disco mediante un agente dedicado, sin necesidad de llamar a la API de administración de la plataforma de destino.
En conjunto, el agente interno y Direct2Target proporcionan una ruta de replicación que no depende ni de la biblioteca de Broadcom en el origen ni de una API de administración en el destino. En la práctica, el cambio es un inconveniente menor para una de las opciones de implementación y no tiene impacto en la capacidad de Acura para migrar, proteger o realizar copias de seguridad de las cargas de trabajo de VMware, independientemente de si el destino es OpenStack, KVM, Virtualización de Red Hat OpenShift, o VMware en sí mismo.
¿Está planificando un proyecto de migración, recuperación ante desastres o copia de seguridad para cargas de trabajo de VMware y desea una ruta de replicación que no dependa de la biblioteca de Broadcom?
Cuéntenos sobre su entorno y nuestros ingenieros analizarán las opciones disponibles para sus plataformas de origen y destino.
¡Gracias por tu solicitud!
Nos pondremos en contacto contigo pronto.
¿Qué hacer ahora?
Si está planeando abandonar VMware o gestionar una recuperación ante desastres que dependa de VMware, hay cuatro cosas que vale la pena hacer este trimestre.
- Inventaría la dependencia. Compruebe si todas las herramientas de la cadena (migración, copia de seguridad, recuperación ante desastres y cualquier script interno basado en virt-v2v o nbdkit) requieren VDDK.
- Confirma una alternativa para cada uno. Una herramienta sin una ruta que no sea VDDK es un punto único de fallo controlado por el proveedor que estás abandonando.
- Conserva los binarios que ya tienes, y registre para qué versiones del producto están licenciadas. No las obtenga de réplicas no oficiales: la licencia restringe la redistribución y las copias no verificadas conllevan riesgos para la cadena de suministro.
- Favorezca las herramientas que no se construyeron bajo esa premisa. Se ha demostrado que Broadcom siempre dejaría la puerta abierta, pues esa suposición acaba de resultar errónea.
La eliminación de VDDK nos recuerda que un plan de migración es tan portable como su dependencia más débil. Descubra cómo Hystax Acura aborda migración a las nubes, recuperación ante desastres y copias de seguridad en plataformas VMware, OpenStack, basadas en KVM y en entornos con acceso restringido a la API.