Broadcom retiró sin aviso la herramienta de salida de VMware

Desde finales de agosto de 2026, las páginas de descarga de la biblioteca VDDK de VMware en el portal para desarrolladores de Broadcom devuelven 404, sin anuncio, sin aviso de obsolescencia y sin ninguna alternativa indicada. La biblioteca en sí es desconocida para la mayoría, pero las herramientas que dependen de ella no lo son: los productos de respaldo a nivel de imagen para servidores VMware y las herramientas que se usan para migrar de VMware a otras plataformas. El resultado práctico es que una empresa que evaluaba salir de VMware se encontró con el camino oficial de salida cerrado. Y la lección vale para todo propietario de un sistema, use VMware o no: su dependencia de un proveedor no se mide por el precio de la suscripción. Se mide por cuánto tiempo, dinero y conocimiento le costaría marcharse.

Qué es VDDK y por qué importa aunque nunca haya oído hablar de ella

VDDK significa Virtual Disk Development Kit. Es la biblioteca que permite a software externo al hipervisor leer y escribir los discos virtuales de VMware. Dicho de forma más sencilla: es el puente que cruza todo programa que quiera hacer una copia de un servidor virtual o trasladarlo a otro lugar.

Por eso está en el centro de herramientas sin una relación evidente con Broadcom. El motor de conversión de código abierto virt-v2v, que sustenta la mayor parte del trabajo de migración de VMware a KVM, la admite como transporte de entrada. La vía de migración de Apache CloudStack la utiliza para transmitir los bloques de disco directamente en lugar de exportar primero un archivo OVF completo. Y cualquier producto de respaldo que haga una copia a nivel de imagen de una VM de vSphere pasa por ella en algún punto de la cadena.

La clave: no necesita VDDK para seguir ejecutando VMware. La necesita para salir con rapidez y para proteger lo que está ejecutando mientras decide.

Qué ocurrió realmente

ShapeBlue documentó el cambio el 25 de agosto de 2026: la página a la que remite la guía oficial de administración de Apache CloudStack para descargar la biblioteca devuelve un error, y lo mismo ocurre con todas las demás rutas de VDDK en el portal, incluidas las rutas específicas de las versiones 8 y 9. Hicieron pruebas desde Europa y a través de nodos de salida en Estados Unidos, Brasil, Finlandia y Japón, y obtuvieron el mismo resultado en todas partes, así que no se trata de un fallo local ni de un bloqueo geográfico.

Más extraño aún, no hay ningún anuncio de Broadcom que explique el cambio. Ningún aviso de obsolescencia por fases, ninguna política de conservación y ninguna vía indicada para que un cliente o un pequeño proveedor obtenga la biblioteca. La guía oficial de CloudStack sigue dirigiendo a los usuarios a un enlace que ya no funciona. Nosotros mismos comprobamos el enlace mientras escribíamos este artículo y obtuvimos un 404, mientras que la página de la guía de CloudStack carga con normalidad.

No necesita la biblioteca para ejecutar el sistema. La necesita para salir. Eso es precisamente lo que hace que su ausencia importe.

Por qué no hay una solución alternativa

Normalmente, cuando desaparece un archivo que todos necesitan, la comunidad técnica encuentra un rodeo: alguien lo replica, alguien lo empaqueta y la historia termina como una nota al pie en una página de documentación. Pero la licencia de VDDK no permite la redistribución general. Ninguna distribución de Linux la incluye, ninguna imagen de contenedor la empaqueta y ningún proveedor de respaldo sin un acuerdo de redistribución firmado puede incluirla en su instalador.

Eso completa el panorama: una sola URL se convirtió en una dependencia rígida para todo un ecosistema de software, y la licencia que creó la dependencia es la misma que bloquea el remedio obvio. Replicar los binarios en otro sitio no arregla nada: traslada el riesgo legal a quien los aloje.

El daño, además, no se reparte por igual. Un gran proveedor de respaldo con una relación de socio tiene a quién llamar. Una consultora de migración de tres personas, un proyecto de código abierto o un cliente que convierte sus propias cargas de trabajo tiene una publicación en un foro y una página de error.

La verdadera lección: el costo de salida es la medida de la dependencia

La mayoría de las decisiones de compra de sistemas se toman comparando precios y funciones. Eso es media evaluación. La mitad que falta es una pregunta: si dentro de tres años decidimos dejar a este proveedor, ¿cuánto nos cuesta?

Lo ocurrido con VDDK demuestra que el costo de salida no es fijo. Un proveedor puede aumentarlo más adelante, de forma unilateral y a veces sin ningún anuncio. Una empresa que firmó con VMware hace cinco años evaluó el precio y el rendimiento. No sabía que la propiedad del producto cambiaría, ni que la herramienta de salida desaparecería discretamente del portal.

Cómo medir su costo de salida en la práctica

Antes de cualquier contrato nuevo, y antes de renovar cualquiera existente, haga estas preguntas y obtenga las respuestas por escrito:

  • ¿Se pueden exportar mis datos en un formato abierto? No un volcado parcial a una hoja de cálculo, sino una exportación completa de los datos y de las relaciones entre registros, en un formato que otro sistema pueda leer.
  • ¿La herramienta de salida pertenece al propio proveedor? Si el único camino de salida pasa por una herramienta controlada por la parte de la que quiere irse, no tiene un plan de salida. Tiene una esperanza.
  • ¿Qué conservo si el contrato se interrumpe de repente? Pida una cláusula explícita que garantice la entrega de los datos y la documentación en un plazo fijo cuando termine la relación, por cualquier motivo.
  • ¿Hemos intentado salir de verdad? Un plan de salida que nunca se ha probado no es un plan. Haga una exportación completa al menos una vez al año y confirme que se importa en otro lugar.
  • ¿Cuánto tardaría la migración, en cifras? Estime los días y el costo con honestidad. Si la respuesta es "no lo sabemos", eso también es una respuesta, y significa que su dependencia es mayor de lo que cree.

Cómo lo gestionamos en Origami

Somos una empresa de tecnología y construimos los sistemas de nuestros clientes sobre el principio de que el código y los datos pertenecen al cliente. En la práctica, eso significa una base de datos estándar que cualquier otro equipo puede leer, documentación entregada junto con el sistema y no a petición, y API que exportan el conjunto de datos completo y no fragmentos. No lo decimos porque la relación sea temporal: lo decimos porque un cliente que sabe que puede irse es un cliente que se queda por elección.

Y cuando depender de un producto de terceros es necesario, como ocurre a menudo, dejamos escrito en el documento de diseño qué pasa si ese tercero desaparece: cuál es la alternativa, cuánto tardaría el cambio y qué partes del sistema se verían afectadas. Es una página del documento, pero marca la diferencia entre una sorpresa y una maniobra planificada.

Fuentes