Broadcom retira el VDDK: lo primero que se rompe no es tu migración, es tu backup

A finales de agosto, una URL del portal de desarrolladores de Broadcom dejó de funcionar. Sin anuncio, sin aviso de obsolescencia, sin una línea en unas notas de versión: una página de descarga que un día estaba y al siguiente devolvía un 404. Detrás de esa URL había una librería que fuera de un departamento de sistemas nadie sabría nombrar, y de la que dependen a la vez dos cosas que casi nunca se piensan juntas: tu plan para salir de VMware algún día, y la copia de seguridad que se hizo anoche.

Qué es el VDDK, en una frase

El Virtual Disk Development Kit es la librería que permite a un programa que corre fuera del hipervisor leer y escribir discos virtuales de VMware. Su parte visible se llama VixDiskLib, y por debajo implementa los modos de transporte con los que ese programa llega hasta los datos: por red (NBD y NBDSSL), enganchando el disco a una máquina auxiliar (HotAdd) o leyendo directamente de la cabina (SAN). Lleva casi dos décadas siendo la vía por defecto para todo lo que necesita tocar un .vmdk sin ser el propio ESXi.

Eso incluye, prácticamente, todo el ecosistema de backup, recuperación ante desastres y migración. Y también incluye un detalle de licencia que explica por qué esto es un problema y no una molestia: el VDDK no se puede redistribuir libremente. Un fabricante sin acuerdo firmado con VMware no puede meterlo en su instalador. La consecuencia práctica desde 2008 fue que muchas herramientas te pedían que fueras tú quien se lo bajara del portal. Esa página es la que ya no está.

La palabra que casi nadie ha leído

Cuando los clientes preguntaron, la respuesta que circuló desde atención al cliente de Broadcom fue esta: «To ensure the highest standard of security, reliability, and product features, the Virtual Disk Development Kit (VDDK) is no longer available for use or download». Y añadía que Broadcom sigue manteniendo APIs y SDKs para que los «authorized technology alliance partners» construyan soluciones de copia y recuperación.

Aquí va nuestra reserva, y la ponemos antes de seguir en lugar de al final: esa frase procede de respuestas de soporte reproducidas por usuarios afectados y recogidas después por varias publicaciones del sector. No la hemos visto en un comunicado formal de Broadcom, porque no lo ha habido. No somos abogados y no vamos a decirte qué significa jurídicamente para tu contrato. Lo que sí decimos es que hay una distancia enorme entre «no puedes bajártelo» y «no puedes usarlo», que esa distancia cae justo encima de sistemas que están en producción, y que de todo lo que hemos leído estos días nadie se ha parado en ella.

Sí, salir cuesta más. Depende de a dónde vayas

El titular que ha corrido es que salir de VMware acaba de ponerse más difícil. Es verdad, y es incompleto, porque no se ha puesto más difícil por igual para todos. Depende de qué herramienta uses para copiar los discos, y eso depende de a dónde vayas.

Del lado de los que sí lo notan:

• Migration Toolkit for Virtualization, de Red Hat. Red Hat publicó un artículo de soporte reconociendo que los clientes se encuentran errores de «no encontrado» o «acceso denegado» al ir a por el VDDK, y dejó dicho algo importante: no puede alojarlo ni redistribuirlo, porque es software propietario de Broadcom, así que remite a soporte de Broadcom mientras su ingeniería busca una salida a largo plazo.
• Azure Migrate, de Microsoft, en su modo sin agente: la documentación te manda a bajar el VDDK 8.0 o 9.0 del portal de Broadcom, y el enlace ya no lleva a ninguna parte. Que la dependencia es real y no una interpretación se lee en la propia matriz de soporte de Microsoft, donde tres de los permisos que hay que dar en vCenter se justifican textualmente «para leer el disco usando el VDDK». La alternativa que queda es la migración basada en agente —el otro método que la misma página documenta— y es otra cosa, con otro coste operativo: hay que instalar el servicio de movilidad dentro de cada máquina.
• virt-v2v y el plugin VDDK de nbdkit, que es la maquinaria que hay debajo de buena parte de las conversiones de VMware a KVM, y Apache CloudStack, que lo usa como ruta optimizada.

Y del otro lado, el dato que la cobertura ha mencionado de pasada y que a nosotros nos parece el más útil de todos: el importador de ESXi de Proxmox VE no depende del VDDK. El wiki oficial de migración no lo nombra en ningún punto —lo hemos comprobado buscando la palabra en la página, y no aparece ni una vez—; lo que describe es un componente propio, esxi-folder-fuse, que hace de interfaz entre Proxmox VE y ESXi hablando con la API del host. El wiki llega a decir hasta dónde aprieta: ese servicio «limita las conexiones paralelas a cuatro y serializa los reintentos» justamente para no saturar una API de ESXi que, cuando se pasa de vueltas, bloquea a los clientes unos treinta segundos. Sus limitaciones documentadas van por otro lado —vSAN no soportado, discos cifrados por Storage Policy tampoco, mucho más lento con instantáneas, y una caída de rendimiento seria si importas vía vCenter en lugar de contra el host— pero ninguna de ellas tiene que ver con una librería que Broadcom haya dejado de publicar.

Esto no es un argumento para elegir hipervisor, y sería deshonesto venderlo como tal. Es un dato de coste que ayer no estaba en la tabla comparativa y hoy sí, y que además puede desaparecer mañana si Broadcom recupera la descarga. Tomar una decisión de arquitectura a cinco años por una URL rota sería exactamente el tipo de decisión que luego se paga. Nosotros hemos escrito con calma sobre cuándo no migrar de VMware a Proxmox y sobre por qué el éxodo masivo que se anunció no llegó a producirse. Nada de eso cambia por un 404.

Una migración tiene fecha. El backup es un martes cualquiera

Aquí es donde creemos que el foco está mal puesto. Una migración es un proyecto: tiene fecha, tiene dueño, tiene una reunión de planificación. Si el VDDK te complica la migración, te enteras en esa reunión, con tiempo, y buscas otra ruta. Es un problema caro y molesto, pero es un problema visible.

El backup no tiene reunión. El backup es un proceso que corre todas las noches y del que solo te acuerdas dos veces: cuando falla y cuando lo necesitas. Y ahí es donde esta librería lleva casi veinte años trabajando sin que nadie la mire. En Veeam, por ejemplo, la propia guía de buenas prácticas sitúa el VDDK dentro del servicio de transporte y describe los modos que lo usan —Direct SAN, el modo hot-add de máquina virtual auxiliar y NBD—, anotando además que en algunos escenarios se puentea a favor de su propio Advanced Data Fetcher. Trabajamos con Veeam y con Proxmox Backup Server. Conviene decirlo claro para no alimentar la alarma: lo que está instalado sigue instalado, y sigue funcionando. Retirar una descarga no apaga una copia que ya está corriendo.

Es una de las formas de fallo que más veces hemos visto de cerca operando infraestructura ajena: un sistema que lleva años funcionando perfectamente y que nadie ha vuelto a instalar desde cero desde el día que se montó. Funciona porque nadie lo ha tocado, no porque se pueda reponer. Hay una frase que decimos mucho y que hoy admite una vuelta de tuerca: un backup sin probar no es un backup, es un amuleto. La prueba de siempre es restaurar un fichero. La prueba que casi nadie hace es reconstruir la máquina que hace la copia, con lo que hoy tienes a mano, sin abrir el portal de nadie.

Tres preguntas que sí puedes contestar esta semana

No vamos a darte una lista de diez puntos. Con tres basta, y las tres se contestan sin comprar nada.

1. ¿Qué hay dentro de tu copia? Concretamente: si tu backup de VMware es sin agente, ¿usa el VDDK, qué versión tiene instalada y de dónde salió esa versión —del instalador del fabricante o de una descarga manual que alguien hizo hace años—? Esa última parte es la que decide si puedes reponerla tú solo.
2. ¿Sobrevive a una reconstrucción? La prueba se hace hoy, en horario de oficina, sin tocar el sistema de producción: levanta un proxy de backup nuevo, desde cero, y comprueba que llega a copiar una máquina. Si en algún paso hace falta abrir un portal de descargas, ya tienes la respuesta.
3. ¿Y si un día te mueves? No hace falta que decidas nada hoy. Basta con saber si la herramienta con la que saldrías depende de esta librería o no, porque eso ha cambiado de precio esta semana y conviene que lo sepas antes de la reunión, no durante.

La segunda es la que más gente se salta y la única que da una respuesta que no es una opinión. Es la misma idea que contábamos hablando de por qué un disco llega entero de VMware y luego Windows no arranca: el trabajo que salva la noche del sábado es el que se hace un martes por la mañana, con las máquinas encendidas y con vuelta atrás cómoda.

Cuándo esto no va contigo

Si no tienes VMware, esto no te toca en absoluto y puedes cerrar la pestaña con la conciencia tranquila. Si tu copia de seguridad se hace con agente dentro del sistema invitado, tampoco: ese camino no pasa por el VDDK. Y si tienes VMware, un backup sin agente que funciona y ninguna intención de tocar nada en año y medio, la respuesta honesta es que hoy no tienes una emergencia. Tienes un riesgo aplazado, que es distinto de un riesgo inexistente. Y cuánto se puede aplazar depende de una sola cosa: de si sabes reponer la pieza tú solo.

Tampoco sabemos —y lo decimos porque nadie lo sabe— si Broadcom revertirá esto, si el acceso volverá bajo otra puerta, cuáles son los criterios para entrar en ese programa de partners autorizados ni cuánto se tarda. Cualquiera que te diga hoy cómo acaba esta historia se lo está inventando.

Lo que sí se puede decir es lo que la frase de Broadcom describe con precisión, se quiera o no: que la capacidad de leer tus propios discos —para copiarlos o para llevártelos— ha pasado a vivir dentro del catálogo de socios de otra empresa. Desde el punto de vista de Broadcom es una decisión perfectamente razonable. Desde el punto de vista de quien tiene que restaurar mañana, es una dependencia que hasta el 25 de agosto no aparecía en ningún inventario porque no hacía falta que apareciera.

Nota de fuentes

La retirada de las páginas públicas de descarga del VDDK y la fecha del 25 de agosto de 2026 proceden del análisis de ShapeBlue «Broadcom Removes VDDK Pages Without Explanation», publicado ese mismo 25 de agosto, que es quien documentó primero las rutas en 404, y de Platform9, que es quien sitúa la retirada en esa fecha; fueron recogidas después por, It's FOSS y Virtualization Howto; de ShapeBlue salen también las rutas concretas que devuelven 404, la observación de que la licencia del VDDK no permite la redistribución general y las alternativas sin VDDK en CloudStack (exportación OVF y lectura directa por NFS). La frase de Broadcom que citamos en su inglés original —«To ensure the highest standard of security, reliability, and product features, the Virtual Disk Development Kit (VDDK) is no longer available for use or download»— y la mención a los «authorized technology alliance partners» proceden de respuestas del servicio de atención al cliente de Broadcom reproducidas por usuarios afectados y publicadas por Platform9 e It's FOSS; no ha habido comunicado formal de Broadcom, y por eso la atribuimos así y no como nota oficial. Que Red Hat publicó un artículo de soporte sobre la imposibilidad de descargar el VDDK para el Migration Toolkit for Virtualization, que no puede alojarlo ni redistribuirlo por ser software propietario y que su ingeniería busca una alternativa a largo plazo, procede de esa misma cobertura, igual que la dependencia de Azure Migrate en modo sin agente respecto al VDDK 8.0 o 9.0; los tres permisos de vCenter justificados «para leer el disco usando el VDDK» y la existencia de la migración basada en agente con su servicio de movilidad dentro de cada máquina los hemos comprobado directamente en la matriz de soporte de Microsoft Learn para migración de VMware vSphere. También son de esa misma cobertura las dependencias de virt-v2v, el plugin VDDK de nbdkit y Apache CloudStack. La descripción del VDDK y de sus transportes (NBD, NBDSSL, HotAdd y SAN) es documentación pública de VMware de siempre. Que el VDDK vive dentro del servicio de transporte de Veeam, la lista de modos que lo usan y el apunte de que en algunos escenarios se puentea en favor del Advanced Data Fetcher salen de la guía pública de buenas prácticas de Veeam para vSphere. Que el importador de ESXi de Proxmox VE no nombra el VDDK, que emplea el componente esxi-folder-fuse como interfaz contra la API del host, su límite de cuatro conexiones paralelas con serialización de reintentos, el bloqueo de unos treinta segundos que impone la API de ESXi al superar su límite de conexiones y las limitaciones documentadas del importador (vSAN, discos cifrados por Storage Policy, lentitud con instantáneas, caída de rendimiento vía vCenter) salen del wiki oficial Migrate to Proxmox VE, cuya página hemos revisado el 10 de septiembre de 2026 buscando la cadena «VDDK» sin encontrar ninguna aparición. Las citas en castellano y catalán son traducción nuestra del original inglés. Es lectura NUESTRA, y no de ninguna de las fuentes citadas: la distinción entre «use» y «download» y su consecuencia; que el foco de la cobertura está mal puesto porque la migración es un proyecto visible y el backup no; y que un backup con esta dependencia no falla el día de la retirada sino el día en que hay que reconstruirlo. No damos plazos, ni porcentajes de herramientas afectadas, ni interpretación jurídica de la licencia, porque no los tenemos anclados y preferimos decirlo. Que operamos Proxmox VE con Ceph en producción, que trabajamos con Veeam y con Proxmox Backup Server, que hemos migrado empresas de VMware a Proxmox y también recomendado quedarse, y que no somos resellers de ninguna de las dos plataformas, es información propia de everyWAN. Comprueba en tu entorno antes de fiarte de nada de esto. La fotografía de portada es «IBM TS3500 LTO-6 Tape drive cabling», de vaxomatic, publicada en Wikimedia Commons con licencia CC BY 2.0.