Alrededor del 25 de agosto de 2026 desaparecieron las descargas públicas del VDDK de VMware, y la lectura que corrió fue que Broadcom había cerrado la puerta de salida. Fuimos a mirar de qué puerta hablábamos. Hay rutas de migración que leen los discos a través de esa biblioteca y rutas que no la tocan en ningún momento; la del importador de ESXi de Proxmox es de las segundas. Comprobarlo cuesta tres minutos y tiene truco, porque la prueba que todo el mundo usaría —abrir las dependencias del paquete— es justamente la que no demuestra nada.
De esto ya escribimos en septiembre, cuando la noticia era reciente, y entonces sostuvimos que lo primero que se rompe no es tu migración, es tu backup: lo urgente no era la migración sino la cadena de copias. Este post es la otra mitad, la que allí dejamos sin resolver. Si el software que lee discos de VMware desde fuera depende de una biblioteca que ya no se descarga, la pregunta que queda es cuál de las rutas de salida pasa por ella. Esa se responde abriendo ficheros, no opinando.
Qué se retiró, exactamente
El VDDK (Virtual Disk Development Kit) es el kit con el que un programa externo abre un disco virtual de VMware y lo lee bloque a bloque sin pasar por el sistema operativo invitado. Conviene separar dos cosas que se confunden a menudo: la lista de qué bloques han cambiado desde la pasada anterior se le pide a la API de vSphere, con QueryChangedDiskAreas, que sigue siendo pública; lo que aporta el VDDK es la lectura de esos bloques. En el disco es un fichero con nombre propio y versionado, libvixDiskLib.so.N, que viaja dentro del paquete vmware-vix-disklib-distrib. Durante años se bajaba de la web de desarrolladores sin más trámite que una cuenta, y encima de él se construyó buena parte del software de backup, de replicación y de migración que toca VMware.
Esas páginas dejaron de responder alrededor del 25 de agosto de 2026, sin aviso previo ni anuncio público, según la cronología que publicó heise el 22 de septiembre. Broadcom lo confirmó el 9 de septiembre en los términos más secos posibles: «el caso de uso aprobado del VDDK según la licencia del SDK ha sido siempre el de las soluciones de backup y recuperación de nuestros socios TAP, y este cambio simplemente refuerza esos términos». Es decir: no lo presentan como una retirada, sino como la aplicación de una licencia que ya decía eso. La biblioteca sigue existiendo para los miembros seleccionados del Technology Alliance Program; lo que se ha ido es la descarga abierta.
Comprobado el 2 de noviembre de 2026, antes de publicar esto: /sdks/vmware-virtual-disk-development-kit-vddk, su variante sin vmware y la misma con /latest devuelven 404 en developer.broadcom.com; la del SDK de pyvmomi, en el mismo dominio, devuelve 200. Y ahora la parte honesta, que nos costó un rato aceptar: ese 404 no demuestra por sí solo que se haya retirado nada. Probamos un identificador inventado por nosotros y devuelve exactamente lo mismo, y también lo devuelve /sdks/vsphere-web-services-sdk/latest, de un SDK que sigue existiendo. Lo que sostiene la retirada es el reportaje y la confirmación del propio fabricante, no nuestro curl. Lo dejamos aquí porque la fecha de nuestra comprobación sí vale: a día de hoy, por esa puerta no se entra.
Lo que dicen las dependencias del importador de Proxmox
El asistente de importación de ESXi de Proxmox VE vive en un paquete llamado pve-esxi-import-tools. Fuimos al índice del repositorio pve-no-subscription de Debian trixie y lo copiamos tal cual viene, con sus restricciones de versión. Versión 1.0.1:
Package: pve-esxi-import-tools
Version: 1.0.1
Depends: python3, python3-pyvmomi, libc6 (>= 2.34),
libfuse3-4 (>= 3.17.2), libgcc-s1 (>= 4.2),
libssl3t64 (>= 3.0.0), libzstd1 (>= 1.5.5)
Description: Tools to allow importing VMs from ESXi hosts
Provides a FUSE file system to access files on ESXi hosts and a python utility
to query the list of VMs and datastores.
Ahí no hay ningún VDDK. Hay python3-pyvmomi, que es el SDK de Python para la API de vSphere —código abierto con licencia Apache, versión 9.1.1.0 publicada en PyPI el 3 de septiembre de 2026, descargable por cualquiera ahora mismo— y hay libfuse3, porque el paquete monta el datastore del ESXi como un sistema de ficheros y lee desde ahí los .vmdk, hablando con el host directamente.
Y aquí está el truco que anunciábamos, porque esa ausencia demuestra mucho menos de lo que parece. El VDDK no se puede redistribuir: su licencia no lo permite. Por tanto ningún paquete de Debian puede declararlo en Depends, lo use o no lo use. La ausencia es una certeza estructural, no una prueba.
El contraejemplo está a mano y lo comprobamos el mismo día: nbdkit-plugin-vddk (versión 1.48.1-1 en la sección contrib de Debian) lee los discos a través del VDDK —es, literalmente, el complemento del VDDK— y su campo de dependencias dice libc6, nbdkit. Nada más. Carga la biblioteca en caliente, desde una ruta que pones tú. Así que quien se quede solo con el Depends puede equivocarse en los dos sentidos.
Entonces, ¿qué sí prueba algo? Tres cosas, y en este orden de peso. La más floja es la que acabamos de enseñar. La segunda: la wiki oficial de Proxmox describe el procedimiento entero sin nombrar el VDDK ni una sola vez, y lo que describe es un componente propio hablando con la API del host ESXi. La tercera y buena se ejecuta en la máquina, porque ahí ya no hay declaraciones que valgan: o la biblioteca está, o no está.
apt-cache show pve-esxi-import-tools | grep -E '^(Version|Depends)' dpkg -L pve-esxi-import-tools find / -name 'libvixDiskLib.so*' 2>/dev/null
La tercera orden es la que vale, y no solo en Proxmox: pásala por cada máquina que participe en tu plan de salida o en tu cadena de copias. Si devuelve algo, esa pieza lee los discos por VDDK y acabas de encontrar una dependencia de un fichero que ya no se descarga en abierto. Si no devuelve nada, no celebres todavía: la biblioteca puede viajar empotrada dentro del contenedor o del instalador de tu proveedor, que es precisamente la vía que Broadcom deja abierta a sus socios. Por eso al comercial de turno hay que preguntarle otra cosa: si su producto incluye la biblioteca o espera que la pongas tú, y de dónde salió la que trae.
Qué rutas leen por VDDK y cuáles no
Lo que sigue son declaraciones de cada fabricante sobre su propia herramienta, no nuestra interpretación. Con un aviso que ShapeBlue se pone a sí mismo y que repetimos porque es justo: su sección sobre su producto hay que leerla «como el folleto de fabricante que es».
| Ruta de salida | ¿Lee por VDDK? | Quién lo dice |
|---|---|---|
| Importador ESXi de Proxmox VE | No | Dependencias del paquete 1.0.1: pyvmomi + FUSE |
| Migration Toolkit for Virtualization (Red Hat) | Opcional, pero recomendado | «Es muy recomendable crear una imagen VDDK»: «acelera la migración y reduce el riesgo de que un plan falle»; si falla sin ella, «reinténtalo con VDDK instalado» |
| MTV sobre discos en vSAN | Imprescindible | «Las migraciones no funcionan sin VDDK cuando la VM está respaldada por vSAN» |
| Métodos directo y CBT de ShapeBlue Migrate | Sí | «Dos de las cuatro leen hoy a través del VDDK» |
| Sus métodos de overlay y OVF | No | «Dos de las rutas no necesitan la biblioteca en absoluto» |
La tercera fila es la que conviene leer dos veces. En discos sobre vSAN, la ruta de Red Hat sin VDDK no migra. Y el importador de Proxmox, que no usa VDDK en absoluto, tampoco toca vSAN: lo dice su wiki, por un motivo técnico distinto y con el mismo resultado para quien tiene las VMs ahí. Dos rutas opuestas, la misma pared, y esa pared no es la biblioteca retirada. Es vSAN, que lleva años donde está y no ha salido en ningún titular de agosto.
La letra pequeña de la ruta que sí funciona
Quedarse con que «Proxmox importa sin VDDK» es la forma rápida de llevarse un disgusto a mitad de una ventana de mantenimiento. Su documentación enumera seis cosas que el importador no hace, y las seis se leen mejor antes de prometer una fecha que después:
- ✗«Importar una VM con discos respaldados por un almacenamiento VMware vSAN no funciona.» Una frase, sin condicionales ni matices: si tus discos están en vSAN, esta ruta se acabó aquí.
- ✗Discos cifrados, no. «Los discos de VM cifrados, por ejemplo mediante una Storage Policy, no se pueden importar.»
- ✗Con snapshots, lento. «Importar una VM desde VMware ESXi puede ser significativamente más lento si la VM tiene snapshots.» Consolidar esa cadena de delta-disks forma parte de la preparación, no de la ventana.
- ✗Por vCenter, peor. «Aunque también se puede importar a través de una instancia de vCenter, hacerlo reducirá drásticamente el rendimiento.» Conviene apuntar directamente al host ESXi.
- ✗Probado hasta ESXi 8.0. «La importación se probó desde la versión 6.5 de ESXi hasta la 8.0.» Si ya estás en una rama posterior, estás en territorio no declarado: pruébalo con una VM de usar y tirar antes de prometer fechas.
- ✗Y no, no hay cero parada. Hay importación en vivo —la VM arranca en Proxmox mientras se copian los datos—, pero la propia documentación aclara que «la VM en el ESXi sigue apagada, así que habrá algo de parada». Sigue habiendo ventana de parada: lo que se reduce es su duración.
A esa lista le añadimos la nuestra, la de las migraciones que hemos hecho: el disco suele llegar bien y es el invitado el que se queja. Windows arrancando sobre un controlador que no conoce es el caso clásico, y lo contamos con detalle en el disco llega entero y Windows no arranca. El asistente te trae el bloque; el arranque sigue siendo tu problema.
El riesgo que nadie tituló
La vía que queda para conseguir la biblioteca por tu cuenta pasa por el portal de soporte. ShapeBlue lo formula así en su aviso del 25 de agosto: los clientes con derechos de VMware activos deberían revisar su acceso al portal de soporte de Broadcom y pedir a su contacto una vía de descarga autorizada. La condición va delante del consejo, y es la parte que importa.
Una herramienta de salida que exige seguir dentro tiene una fecha de caducidad que no decides tú. Durante la migración no molesta, porque el soporte todavía se paga. Molesta dieciocho meses después, cuando alguien pide recuperar un fichero de una copia de 2025 guardada en formato VMware y el contrato lleva un año cerrado. Eso ya no se arregla en el departamento de compras: es una restauración que no se puede hacer, y vive en el mismo cajón que el resto de dependencias de terceros que nadie inventarió.
La ruta de salida es una decisión de arquitectura y se toma por escrito antes de firmar, con el mismo cuidado con el que se elige el almacenamiento. Que un proveedor cambie las reglas de su SDK sin avisar entra dentro de lo previsible: el fallo es inevitable. Que eso te deje sin poder leer tus propios discos ya es una decisión de diseño, y la firmaste tú.
Las cinco comprobaciones que hacemos antes de dar una fecha
- 1Dónde vive cada disco. VMFS, NFS, vSAN o cifrado por política. Si aparece vSAN o cifrado, la ruta del importador se cae y hay que resolverlo antes de hablar de calendario.
- 2Qué biblioteca usa cada herramienta. El
findde antes en todo lo que participe, y la pregunta por escrito al proveedor sobre si empotra el VDDK o lo espera de ti. - 3Una VM real, cronometrada. No una de prueba vacía: una con su tamaño de disco de verdad, para medir la ventana con el ancho de banda que tienes, no con el que promete el folleto.
- 4Las copias antiguas. Decidir hoy cómo se leerá dentro de dos años una copia en formato VMware, suponiendo que el contrato ya no esté. Si la respuesta empieza por -entramos al portal de soporte y-, conviene seguir buscando.
- 5La vuelta atrás. Qué se hace si a las dos horas la VM no arranca y hay gente esperando. Lo escribimos antes de empezar, y lo tenemos desarrollado en el plan de vuelta atrás de una migración a Proxmox.
Lo que de verdad decide quién sale y quién no
Broadcom ha cerrado una puerta concreta, la del software que lee discos de VMware desde fuera, y la ha dejado abierta para sus socios. Quien iba a salir con el importador de Proxmox nunca pasó por ahí. Quien iba a salir con una herramienta que lee por VDDK tiene ahora un problema de contrato disfrazado de problema técnico. Y por debajo de los dos grupos está lo que de verdad decide la fecha: dónde viven los discos. En vSAN se estrellan las dos rutas, la que usa la biblioteca y la que no, y eso no lo arregla ningún portal de descargas.
En everyWAN esto cae en migración de VMware a Proxmox y, cuando la pregunta es si conviene moverse o aguantar, en consultoría. Operamos Proxmox VE con Ceph en producción, y venimos trabajando con Proxmox desde las ramas 3.x; hemos migrado empresas y también hemos recomendado quedarse en VMware cuando la cuenta salía a favor de quedarse. No somos resellers de ninguna de las dos plataformas, así que la recomendación no nos cambia la factura.
Fuentes. Retirada de las descargas y cronología (25-ago-2026, sin anuncio público) — heise, 22-sep-2026. Confirmación y cita de Broadcom sobre los socios TAP, y declaración de Platform9 (Nicole Silva, vicepresidenta de la compañía: «al restringir el acceso públicamente, sin aviso, Broadcom interrumpió muchas migraciones que ya estaban en curso»; conviene saber que Platform9 vende migraciones fuera de VMware) —TechTarget, 09-sep-2026. Rutas que dependen o no del VDDK y vía del portal de soporte — ShapeBlue, 25-ago-2026. Recomendación de imagen VDDK y caso vSAN — documentación de Red Hat MTV 2.8. Limitaciones del importador, versiones probadas y nota de importación en vivo — wiki de Proxmox VE. Versión y dependencias de pve-esxi-import-tools 1.0.1 — índice de paquetes de download.proxmox.com, consultado el 02-nov-2026. Versión 9.1.1.0 de pyvmomi (Apache 2.0, 03-sep-2026) — PyPI. Nombre y ubicación de libvixDiskLib.so — manual de nbdkit-vddk-plugin. Los códigos 404 y 200 son comprobaciones nuestras del 02-nov-2026; las citas de fabricantes están traducidas del inglés original.
¿Sabes por qué biblioteca lee tu plan de salida de VMware?
Lo revisamos contigo: dónde vive cada disco, qué herramienta depende de qué, cuánto dura la ventana real y qué se hace si no arranca. Y si la cuenta sale a favor de quedarte, te lo diremos.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN