Resumen de la publicación
El 25 de agosto Broadcom sacó de circulación las descargas públicas del VDDK, la biblioteca que casi todas las herramientas de migración y varias de backup usan para leer los discos de una máquina virtual de VMware. No hubo anuncio, no hubo aviso de discontinuación y hoy no existe una vía pública para conseguirla.
Pasó en la misma semana en que Tottenham Hotspur contó que se fue de VMware y recortó más del 85% de sus costos de licenciamiento, y en la que Broadcom salió a admitir que perdió a las empresas medianas. Acá va qué se rompe concretamente, qué alternativas están maduras y cómo planificar la salida sin quedar colgado en el medio.
Hay decisiones de producto que se anuncian y hay decisiones que se ejecutan borrando una página web. Esta es de las segundas, y me parece la más reveladora de todo lo que hizo Broadcom con VMware desde que la compró.
Lo probé yo antes de escribir esto: la dirección del portal desde donde se bajaba el kit devuelve 404. No un aviso de mudanza, no un formulario. Un 404.
Qué es el VDDK y por qué te importa aunque no sepas que existe
El VDDK (Virtual Disk Development Kit, «kit de desarrollo de discos virtuales») es la biblioteca que VMware publicaba para que software de terceros pudiera leer y escribir los discos de una máquina virtual desde afuera del hipervisor.
Traducido: es la pieza que le permite a tu herramienta de backup copiar una VM sin apagarla, y a tu herramienta de migración llevarse esa misma VM a otra plataforma. La cronología del corte la reconstruyeron los que se quedaron sin ella:
- 25 de agosto de 2026: ShapeBlue documenta que las páginas de descarga desaparecieron del portal, sin anuncio, sin política de retención y sin archivo.
- 27 de agosto: Red Hat publica un artículo de soporte y deriva a sus clientes a pedirle el kit directamente a Broadcom.
- 1 de septiembre: Platform9 avisa a sus usuarios y publica la única respuesta oficial que consiguió alguien.
Esa respuesta vale transcribirla: «Para garantizar el más alto nivel de seguridad, confiabilidad y funcionalidad, el Virtual Disk Development Kit ya no está disponible para su uso ni descarga».
Y sigue: Broadcom mantiene APIs y SDKs para que los «socios tecnológicos autorizados» construyan soluciones de backup. La biblioteca no murió, cambió de puerta, y la puerta nueva tiene lista de invitados.
Qué se rompe concretamente
Los proveedores con acuerdo firmado de redistribución pueden seguir empaquetando el VDDK en su instalador y su cliente no se entera de nada. Los que no lo tienen quedan sin nada que ofrecer, y ahí es donde duele:
- Azure Migrate en su modo sin agente. Microsoft ya actualizó la documentación: si tenés una copia previa del kit seguís, si no, hay que instalar agente en cada máquina.
- Red Hat Migration Toolkit for Virtualization, con el que se migra a OpenShift Virtualization, y Nutanix Move, que pide el kit como paso de instalación.
virt-v2vy el plugin VDDK denbdkit, base de media docena de productos comerciales además de los flujos artesanales.- Xen Orchestra (XCP-ng), el caso más incómodo: desde la versión 5.110 su migrador V2V abandonó el método viejo por NFS y pasó a
nbdkitmás VDDK porque era más rápido. La documentación oficial todavía te manda al portal de Broadcom que hoy tira 404.
La excepción es Proxmox. Su asistente de importación nunca usó el VDDK porque lee las VMs por la API pública de ESXi, una decisión tomada para poder distribuir la herramienta como software libre que hoy resulta que además era una decisión de resiliencia.
Quedan caminos de escape, todos más lentos: exportar en OVF, leer los discos con qemu-img, migración asistida por la cabina de almacenamiento o meter un agente en cada máquina. Ninguno es imposible, pero todos convierten una migración de un fin de semana en un proyecto de varias semanas.
Ese es exactamente el efecto que produce subir la fricción sin prohibir nada.
El caso Tottenham y la cifra que hay que leer con cuidado
La misma semana apareció el número que va a circular en todas las reuniones de presupuesto del próximo trimestre. Tottenham Hotspur sacó VMware del datacenter que tiene adentro del estadio y lo reemplazó por HPE VM Essentials.
Su CTO, Rob Pickering, le dijo a The Register que el ahorro es «significativo, por encima del 85 por ciento» contra lo que pagaban antes. Antes de copiar la cifra en una presentación, tres aclaraciones:
- El 85% es sobre licenciamiento, no sobre el costo total. La migración fue parte de una renovación completa de servidores, almacenamiento y red.
- El club no publicó cuánto pagaba antes ni qué productos tenía. Un 85% de un número que no conocés sigue siendo un número que no conocés.
- Pickering aclaró que el ahorro no fue el motivo principal sino la gestión unificada del stack.
Aun así el dato importa, y no porque el 85% sea replicable en tu empresa. Importa porque una organización que corre seguridad, IPTV, puntos de venta y analítica de público sobre esa base decidió que podía irse, y se fue en tres meses.
Es el mismo movimiento que ya vimos con Tesco sacando 40.000 cargas de trabajo, solo que en escala mediana. Y la escala mediana es la que se parece a la nuestra.
Broadcom pide otra oportunidad justo ahora
Lo fascinante del timing es que el bloqueo sucede en la misma semana en que VMware salió a decir que quiere recuperar a los clientes chicos.
En VMware Explore, Paul Turner, jefe de producto de la división Cloud Foundation, anunció que viene una versión nueva de vSphere Standard, el paquete básico de virtualización de servidores que no se actualiza desde 2022.
Turner admitió además que cambiaron los incentivos internos que empujaban a los vendedores a colocar VCF (la suite grande de nube privada) donde el cliente solo quería virtualizar servidores. Su frase fue «lo corregimos», y reconoció que hubo «demasiado foco en VCF».
Me alegra que lo digan, pero hay un problema de secuencia que no se arregla con un anuncio. Durante tres años el mensaje al cliente mediano fue «no sos nuestro público», y muchos hicieron los deberes y empezaron a moverse.
Ahora que están a mitad de camino, la herramienta con la que se movían desaparece del portal. No puedo probar que las dos cosas estén coordinadas y no lo voy a afirmar, pero desde la silla del cliente se siente igual que si lo estuvieran.
Las alternativas, con la realidad argentina encima
Conozco varios hostings y datacenters argentinos chicos atados a VMware. La foto local tiene tres particularidades que no aparecen en ningún análisis internacional.
- La licencia se paga en dólares y el ingreso se cobra en pesos, así que cada renovación es una devaluación en cuotas.
- Broadcom se desprendió de la mayoría de sus partners de canal, y acá el partner no era un intermediario decorativo: era el único que te atendía el teléfono en tu huso horario y en tu idioma.
- Muchos proveedores locales venden «VPS sobre VMware» como argumento comercial, y eso convirtió a la marca del hipervisor en parte de la promesa al cliente final.
Proxmox: el que más creció y el que menos se rompió
Es la mejor relación entre madurez y esfuerzo para un datacenter chico, y esta semana dio el paso que le faltaba: soporte empresarial 24×7 desde el 19 de octubre y una subsidiaria en Norteamérica.
Hasta ahora solo atendían en horario de Austria, que era el argumento número uno para descartarlo en cualquier comité. Declaran más de 2,3 millones de servidores activos, y su importador no depende del VDDK.
XCP-ng, Hyper-V, Nutanix y KubeVirt
XCP-ng con Xen Orchestra es sólido y tiene una comunidad excelente, pero su migrador es justamente el que quedó colgado del VDDK. Hyper-V es la respuesta obvia si ya tenés Windows Server Datacenter y gente que sabe administrarlo, y deja de serlo en cuanto la mayoría de tus cargas es Linux.
Nutanix es el reemplazo natural del que hacía virtualización «seria», con el detalle de que cambiás un proveedor único por otro proveedor único. Y KubeVirt tiene sentido si además querés unificar VMs y contenedores; si tu objetivo es solo dejar de pagarle a Broadcom, es una obra desproporcionada.
Cómo evaluar la salida sin romperte
La enseñanza de este episodio no es «huí de VMware ya». Es algo más aburrido y más útil: la puerta de salida es parte de la infraestructura, y hay que probarla antes de necesitarla.
Si tenés VMware corriendo, esto es lo que yo haría en las próximas dos semanas.
- Buscá si ya tenés el VDDK en algún lado. Si alguien lo bajó alguna vez, ese
.tar.gzvale más que ayer. Guardalo con el resto de los artefactos críticos, no en la notebook de quien lo bajó. - Preguntale a tu proveedor de backup si tiene acuerdo de redistribución, y pedí la respuesta por escrito. No es una pregunta comercial sino de continuidad.
- Migrá una VM de verdad a la plataforma candidata. Una sola, de producción, no un servidor de pruebas vacío. Es la única forma de saber cuánto tarda y qué se rompe.
- Poné número a la salida antes de la próxima renovación: horas de trabajo, ventanas de indisponibilidad, licencias, hardware. Sin ese número no negociás, pedís.
- Escribí de qué dependés para irte: bibliotecas, formatos de disco, portales de descarga, herramientas de un solo proveedor. Cualquier cosa de esa lista puede devolver 404 mañana.
Ese último punto es el que me quedó dando vueltas toda la semana. Medimos la dependencia de un proveedor por lo que le pagamos, y casi nadie la mide por lo que costaría dejar de pagarle.
Un 404 en un portal de descargas acaba de poner esa segunda cifra sobre la mesa de mucha gente que no la tenía calculada.
