El acceso a VDDK de Broadcom complica las migraciones de VMware

Los equipos que preparan migraciones de VMware tienen un nuevo problema de dependencias. El acceso público a VMware Virtual Disk Development Kit, o VDDK, cambió en agosto de 2026, y varias rutas documentadas para descargar VDDK dejaron de funcionar o quedaron restringidas. Las herramientas de backup y migración utilizan VDDK para leer discos virtuales de VMware con eficiencia, de modo que si tu plan de salida asume que VDDK se podrá descargar sin más al arrancar el proyecto, conviene que verifiques esa hipótesis ahora mismo.

Antes de escribir esto revisé informes de proveedores de migración e hilos en la comunidad de Broadcom. Las pruebas respaldan la afirmación concreta de que el acceso público cambió y de que los usuarios encontraron enlaces rotos o descargas restringidas. No sostienen una afirmación más tajante sobre las intenciones de Broadcom, por lo que no calificaría el cambio como un sabotaje deliberado sin una declaración directa que demuestre ese propósito.

¿Qué es VMware VDDK y por qué es importante?

VMware Virtual Disk Development Kit es un conjunto de bibliotecas y API para trabajar con archivos de disco virtual de VMware. Los productos de backup, replicación, conversión, recuperación ante desastres y migración pueden utilizarlo para acceder a los discos de las VM sin tener que tratar a cada máquina virtual como si fuera un servidor físico ordinario.

Eso convierte a VDDK en fontanería básica, y la mayoría de los equipos de infraestructura no piensan en la fontanería a diario. La notan cuando desaparece.

Una herramienta de migración puede anunciar un flujo sencillo de VMware a KVM, pero por debajo sigue necesitando un método con soporte para leer los discos de origen. Si ese método espera contar con VDDK y no se puede conseguir la versión requerida, el proceso de migración puede fallar antes de mover la primera VM. Se trata de un riesgo de dependencia, y mucho mayor que una simple molestia de descarga.

¿Qué cambió en el acceso a VDDK en agosto de 2026?

Varios proveedores de migración señalaron que las páginas públicas de descarga de VDDK de Broadcom dejaron de comportarse como debían en torno al 25 de agosto de 2026. ShapeBlue documentó errores en páginas utilizadas para migraciones de VMware a KVM, mientras que Platform9 describió el acceso público como restringido y avisó a sus clientes de que planificaran rutas alternativas.

Los debates en la comunidad de Broadcom muestran el mismo síntoma práctico desde el lado del cliente: los usuarios seguían los enlaces oficiales y no lograban obtener el paquete que esperaban descargar.

VDDK también sigue siendo una dependencia activa en productos de migración actuales. Oracle, por ejemplo, anunció soporte para VDDK 8.0.3 en Oracle Cloud Migrations en agosto de 2026, lo que demuestra la relevancia del acceso. Un flujo de migración actual puede depender de una versión concreta del conjunto de herramientas incluso cuando el objetivo final sea abandonar VMware.

Dicho con claridad: la disponibilidad cambió, los enlaces documentados se rompieron o quedaron restringidos para algunos usuarios, y los equipos de migración no deberían asumir que conseguir VDDK es un trámite que no cuesta nada.

¿Eliminó Broadcom el VDDK para frenar las migraciones de VMware?

No hay pruebas públicas suficientes para presentar las motivaciones de Broadcom como un hecho indiscutible. Algunos proveedores y usuarios interpretan el cambio de acceso como un intento de aumentar la dependencia del proveedor, una lectura comprensible porque VDDK resulta útil justo cuando los datos deben salir de VMware. Aun así, el análisis técnico debe separar los hechos de las intenciones.

El efecto se puede constatar: algunos flujos de migración se complicaron porque una dependencia que antes era accesible de forma pública dejó de estar disponible por la vía habitual. Confirmar el motivo requeriría una explicación directa de Broadcom, pruebas internas u otra fuente con autoridad.

Para quien planifica una migración, el motivo además importa menos que la respuesta operativa. Si una herramienta necesita VDDK, necesitas saber si puedes obtener de forma legal y fiable la compilación requerida con tu cuenta y tus licencias antes de que empiece la ventana de migración. Haz esa comprobación durante la planificación, porque el fin de semana del cambio de producción es el peor momento para enterarte.

¿Qué proyectos de salida de VMware están más expuestos?

Los proyectos que dependen de conversiones de disco sin agente o de herramientas de destino diseñadas en torno a VDDK son los más expuestos. El impacto exacto varía según la plataforma de destino y el producto de migración empleado.

Una herramienta de conversión de VMware a KVM puede utilizar VDDK para acceder con rapidez a los discos de origen. Una plataforma de backup puede usarlo para protección a nivel de imagen. Un producto de recuperación ante desastres puede apoyarse en él para la replicación. Y un servicio de migración a la nube puede incluir VDDK como un requisito previo que el propio cliente debe aportar.

Si algún paso de tu manual de procedimientos indica "descargar VDDK", trátalo como una dependencia formal del proyecto, con un responsable, versión, suma de verificación (checksum), derechos de licencia y plan de contingencia.

Aplica esa misma disciplina al firmware, controladores, dispositivos virtuales de conversión, licencias, certificados y credenciales de API. Una migración es una cadena que suele romperse por la dependencia que nadie se molestó en probar.

El centro de comparativas de Mr.PlanB resulta muy útil al evaluar plataformas de destino, pero la decisión final debe contemplar la mecánica de la migración. Una plataforma puede parecer muy atractiva en régimen de funcionamiento normal y ser un mal destino si el camino desde tu entorno actual es frágil.

¿Se puede migrar de VMware sin VDDK?

Sí. VDDK es muy útil, pero es solo una de las diversas vías para mover una máquina virtual. Las alternativas dependen de la tolerancia al tiempo de inactividad, el sistema operativo invitado, la estructura del almacenamiento, el hipervisor de destino y las herramientas disponibles.

Una opción es la migración a nivel de invitado. Instalas un agente o herramienta de replicación dentro de la VM, copias la aplicación o los datos de bloque a un nuevo invitado y realizas la conmutación. Esto funciona especialmente bien cuando la aplicación ya dispone de un mecanismo de replicación nativo, como replicación de base de datos o sincronización de archivos.

Otra posibilidad es la exportación y conversión. Según el entorno, puedes exportar paquetes OVF u OVA, copiar discos virtuales o usar un conversor que admita otro método de acceso al origen. Este enfoque puede ser más lento y exigir mayor tiempo de inactividad.

La migración a nivel de almacenamiento puede funcionar cuando el origen y el destino comparten acceso a la misma tecnología de almacenamiento, o cuando la replicación de cabina permite mover datos de forma independiente del hipervisor.

Algunas plataformas de destino ofrecen su propio kit de migración. Revisa los requisitos previos antes de dar por hecho que soluciona todo, ya que un asistente amigable puede seguir dependiendo de VDDK en segundo plano.

Si Proxmox es tu destino, empieza con el resumen actual de la plataforma Proxmox y monta una prueba de migración representativa. No bases tu plan en un vídeo que convirtió una pequeña VM en condiciones que no tienen nada que ver con el diseño de tu red y almacenamiento.

¿Qué deberías archivar antes de una migración de VMware?

Archiva los medios de instalación, la compilación de VDDK, las sumas de verificación, licencias, documentación, herramientas de conversión y scripts de los que dependa tu plan de migración, siempre respetando las condiciones de licencia del proveedor. Registra de dónde salió cada archivo y qué versión del entorno de origen admite. Es una cuestión básica de reproducibilidad; un programa de migración de seis meses no puede depender de que una página web no cambie.

Registra también las versiones exactas de VMware en tu parque de origen. La compatibilidad de VDDK puede depender de las versiones de vSphere y ESXi, y una herramienta validada para una compilación puede no comportarse de forma idéntica frente a otra.

Mantén los artefactos bajo control de versiones o gestión de cambios en lugar de dejarlos en el equipo de un solo ingeniero. Si el proyecto se detiene y se reanuda más tarde, quien tome el relevo debe ser capaz de reconstruir la cadena de herramientas probada.

Esta misma práctica se aplica más allá de VMware. Los proveedores de infraestructura cambian portales, nombres de producto, sistemas de inicio de sesión y políticas de descarga, y un proyecto de migración es mucho más seguro cuando las dependencias críticas se custodian como artefactos del proyecto en lugar de como enlaces en favoritos.

¿Hace esto más atractivos a Proxmox o KubeVirt?

Puede hacer más atractivas las alternativas abiertas, aunque un destino abierto no facilita la salida del entorno de origen. Tanto Proxmox como KubeVirt se apoyan en bases de virtualización abierta, pero la primera migración sigue teniendo que cruzar la frontera de VMware.

El artículo sobre la curva de aprendizaje de vMotion incide en esa misma idea: salir de VMware exige mucho más que convertir archivos. Los equipos necesitan asimilar nuevos conceptos operativos, procedimientos de backup, monitoreo, redes y manuales de actuación ante fallos.

El acceso a VDDK es un motivo más para empezar cuanto antes. Cuanto más esperes, más probable será que un contrato, un derecho de licencia, un portal de descargas o la dependencia de una herramienta pasen a entorpecer la ruta crítica.

¿Qué haría yo antes de aprobar un plan de salida de VMware?

Exigiría al equipo que demostrara la viabilidad del camino de migración con las herramientas y versiones exactas que piensa utilizar. Descarga todos los requisitos previos ahora, verifica los derechos de licencia, documenta las sumas de verificación y convierte cargas de trabajo representativas antes de que la empresa se comprometa con una fecha de corte definitiva.

También diseñaría al menos una alternativa que no dependa del mismo método de acceso al origen. Quizá resulte más lenta o exija mayor tiempo de inactividad, pero una vía conocida y más lenta es preferible a descubrir durante la puesta en producción que la herramienta principal no puede conseguir un componente imprescindible.

La opción contraria tiene sentido si la herramienta de migración está gestionada por completo por el proveedor e incluye contractualmente todos los componentes necesarios de VMware. En ese caso, haz que el proveedor lo demuestre en un piloto y deje esa responsabilidad por escrito.

El episodio de VDDK recuerda que solo descubres cuántas alternativas reales tiene tu infraestructura cuando intentas utilizarlas. Una opción de migración que dependa de un archivo que no puedes conseguir no es todavía una opción viable.