libvixDiskLib.so.8.0.3, la librería VDDK de VMware que cargan las herramientas de copia de seguridad y migración para leer discos de vSphere. Mismo nombre de fichero y mismas funciones: se cambia el fichero y la aplicación no se entera.Quien migra máquinas de VMware a KVM se encuentra pronto con una pieza que no controla: VDDK, el Virtual Disk Development Kit. Es la librería que VMware, ahora Broadcom, ofrece para que otros programas lean y escriban los discos de las máquinas de vSphere. La usan las herramientas de copia de seguridad, y también buena parte de las de migración, porque es el camino documentado para leer un disco de una máquina encendida, aprovechar el seguimiento de bloques cambiados (CBT) y hacer pasadas incrementales.
El problema es que es software propietario de Broadcom. Las herramientas de terceros no pueden incluirlo: cada usuario tiene que descargarlo por su cuenta, y su evolución depende de una empresa de la que precisamente se está intentando salir. La documentación del plugin de VDDK de nbdkit, el que usa virt-v2v, lo dice sin rodeos: requiere la librería propietaria de VMware, «que debes descargar tú mismo».
OpenVDDK propone reescribirla, y ha publicado sus primeras pruebas este mes. Nos parece un proyecto interesante y con una idea muy concreta, así que vamos a contar qué hace, qué miden de verdad sus pruebas y qué le falta antes de que tenga sentido meterlo en un proceso de migración real.
Según su web, es una implementación desde cero de libvixDiskLib.so.8.0.3, la versión 8.0.3 de la librería de VDDK, escrita solo a partir de documentación pública y pruebas de caja negra, sin código de VMware. La idea es que una aplicación que carga esa librería no sepa si ha recibido la de VMware o la de OpenVDDK: mismo nombre de fichero, mismas funciones exportadas, mismas llamadas, mismos datos de vuelta. Se sustituye el fichero, se reinicia el servicio y ya está.
Por ahora implementa un único transporte, HotAdd. Es el modo en el que el disco de la máquina que se quiere leer, en realidad su instantánea, se conecta temporalmente a una máquina virtual que hace de proxy en el mismo entorno vSphere. El proxy lo ve como un disco local y lo lee a la velocidad del almacenamiento, sin pasar por la red de gestión de ESXi. Es el transporte más rápido de VDDK para leer mucho volumen, y también el más delicado: hay que conectar, localizar, verificar y desconectar discos de una máquina que no es tuya mientras sigue en producción.
El proyecto pone el acento justo ahí. Dice que su HotAdd es tolerante a fallos: han matado el proceso en cada paso de la conexión y la desconexión, y la siguiente ejecución limpia lo que quedó a medias.
Este dato no sale en la portada de OpenVDDK, pero sí en su pie y en la web de V2K Migrate: el autor de OpenVDDK es Andrija Panić, miembro del comité de gestión (PMC) del proyecto Apache CloudStack y con años de trabajo en migraciones de VMware a CloudStack y KVM en ShapeBlue. Es también el responsable de V2K Migrate, una plataforma de migración de VMware a KVM que se anuncia como gratuita, autoalojada, con destinos CloudStack y Proxmox VE, y que de momento está en fase previa al lanzamiento.
Las dos piezas se han desarrollado juntas: V2K Migrate lee los discos por HotAdd, con la librería de VMware o con OpenVDDK. Que el autor tenga experiencia real en migraciones es una buena noticia para el proyecto. Que las pruebas comparativas se hayan hecho con su propia herramienta es algo que hay que tener presente al leerlas.
La web publica dos pruebas. En las dos se usó la misma versión de V2K Migrate, la misma máquina y el mismo entorno, y lo único que se cambió fue el fichero de la librería.
Una máquina Debian 13 encendida, con un disco de 20 GB: copia completa de referencia, dos pasadas incrementales por CBT de 2 y 5 GiB, y una pasada final tras apagarla.
| Medida | VMware VDDK 8.0.3 | OpenVDDK |
|---|---|---|
| Migración completa, todas las pasadas | 330 s | 118 s |
| De «instantánea hecha» a «disco conectado» | ~30 s | ~5 s |
| Lectura de un disco de 200 GiB | 1.441 MiB/s | 2.488 MiB/s |
| Devolver el disco al terminar | 12,6 s | 0,35 s |
Entorno: ESXi y vCenter 8.0.3, máquina de trabajo con 3 vCPU y 4 GiB, almacén NFS 4.1 respaldado por RAM y red de 100 GbE. Ejecuciones únicas, 3 de octubre de 2026. Fuente: openvddk.com.
Lo interesante de esta tabla no es la velocidad de lectura, sino los tiempos de conexión y desconexión. En una migración en caliente hay varias pasadas, y en cada una hay que hacer una instantánea, conectar el disco, leer lo cambiado y desconectarlo. Si cada ciclo pierde 40 segundos esperando a la librería, con pasadas incrementales de pocos GiB ese tiempo muerto es la mayor parte de la migración. De ahí sale casi toda la diferencia entre 330 y 118 segundos.
Según el proyecto, las dos librerías movieron exactamente los mismos bytes, la comprobación de datos del producto pasó y el disco de 200 GiB dio el mismo SHA-256 con ambas, tanto completo como en sus 800 tramos.
Dos matices que la web incluye y que conviene no perder. El primero, que el almacén estaba en RAM, lo que elimina el disco como cuello de botella y favorece a quien mejor aproveche el canal. El segundo, que la mejora de lectura se aplica a un lector con una sola petición en vuelo. Una herramienta que ya lance varias lecturas en paralelo sacaría menos ventaja.
La segunda prueba es más cercana a la realidad: una máquina Windows Server 2019 apagada, con un disco de 200 GiB en un almacén NFS de NetApp, convertida a qcow2 sobre otra exportación NFS de la misma cabina.
| Medida | VMware VDDK 8.0.3 | OpenVDDK |
|---|---|---|
| Migración completa | 15 min 2 s | 7 min 24 s |
| Velocidad de copia | 282 MiB/s | 537 MiB/s |
| Del inicio al primer byte copiado | 93 s | 7 s |
| Tiempo de la copia esperando lecturas | 594 de 727 s | ~180 de 381 s |
| CPU media de la máquina de trabajo | 18,4 % | 37,8 % |
| Latencia media por petición en ESXi | 2,5 ms | 18,8 ms |
ESXi y vCenter 8.0.3; origen NFS v3 y destino NFS 4.2 en la misma NetApp. Una ejecución por librería, 4 de octubre de 2026. Fuente: openvddk.com.
Las dos ejecuciones escribieron los mismos 181,3 GB en el qcow2 y se saltaron los mismos 33,4 GB de ceros, y qemu-img compare dio los dos ficheros por idénticos.
La explicación de la mejora está en las dos últimas filas, y es honesta. La librería de VMware pide un bloque de 1 MiB, espera a recibirlo y pide el siguiente, así que cada petición encuentra la cola vacía y tarda poco, 2,5 ms, pero el canal pasa mucho tiempo ocioso. OpenVDDK mantiene varias peticiones de 2 MiB en vuelo con lectura anticipada: cada una espera más en la cola, 18,8 ms, pero llega el doble de datos por segundo. A cambio, la CPU de la máquina de trabajo trabaja el doble durante la mitad de tiempo; el proyecto calcula que el trabajo total sale igual con un 1 % de diferencia. La memoria apenas cambia.
Con la espera de lectura reducida, el cuello de botella pasa a ser la escritura del qcow2. Es lo esperable, y es una buena señal de que el resultado no está inflado: si la librería fuera mágica, el destino no sería el que manda.
Son resultados prometedores y están documentados con más detalle del habitual, incluidos los registros de las dos librerías y un informe del perfilador. Pero no son una comparación independiente:
La mejora que más nos convence no es la de rendimiento puro, sino la de los tiempos de conexión y desconexión de HotAdd, porque es la que más pesa en las migraciones en caliente con varias pasadas, y es donde VDDK tiene fama de lento.
| Área | Estado según el proyecto |
|---|---|
| Lectura por HotAdd | Funciona; en fase final de pruebas. En frío y en caliente, pasadas CBT, cadenas de instantáneas, varios discos en paralelo |
| Plataforma | Linux x86-64 con glibc 2.28 o posterior; probado en Enterprise Linux 8 y 9 |
| vSphere | 7.0.3 y 8.0.3; 6.5 y 6.7 previstos |
| Tolerancia a fallos | Probada: proceso interrumpido en cada paso de conexión y desconexión |
| Pruebas de carga y de fallo | Casi terminadas: discos de hasta 3 TiB, 1.000 ciclos seguidos, 17 discos en un mismo proxy, sesiones de vCenter perdidas, controladoras SCSI llenas |
| Pendiente | Máquinas cifradas, RDM, pruebas con muchas máquinas a la vez, invitados Windows |
| NBD y NBDSSL | Previstos, después de HotAdd |
| SAN | Fuera de alcance |
| Escritura (restauraciones) | No prevista: las llamadas de escritura devuelven el mismo error de solo lectura que la librería de VMware |
Lo de la escritura importa para entender a quién sirve. OpenVDDK no sustituye a VDDK en un producto de copia de seguridad que también restaura sobre vSphere. Sirve para leer: migrar fuera de VMware o hacer copias, no para devolver datos a VMware.
El nombre invita a pensarlo, pero la web de OpenVDDK no publica ni código ni licencia. No se puede descargar: los socios de pruebas reciben versiones de evaluación, y la descarga pública llegará con la primera versión candidata. La versión que aparece en los registros de la prueba de NetApp es la 0.6.7.
V2K Migrate, la herramienta con la que se ha desarrollado, deja clara su postura: será gratuita, sin tarifas por máquina ni ediciones, pero de código cerrado al principio, con el objetivo de abrirlo a largo plazo y sin fecha. Es razonable pensar que OpenVDDK seguirá un camino parecido, pero no lo dice.
Para un equipo que decida qué meter en su proceso de migración, esto cambia la evaluación. Una librería de código abierto se puede auditar y, si el proyecto se para, mantener. Una librería gratuita de código cerrado es otra dependencia de un tercero, aunque sea más pequeño y más amable que Broadcom. Conviene saber cuál de las dos es antes de construir encima.
Hay además una cuestión legal que el proyecto aborda de frente: VMware, VDDK y VixDiskLib son marcas de Broadcom, y OpenVDDK las usa solo para describir compatibilidad. Reimplementar una interfaz desde documentación pública y pruebas de caja negra es una práctica con larga tradición en el software, pero en un entorno corporativo es el tipo de cosa que el departamento jurídico querrá revisar antes de usarlo en producción.
Si tu destino es Proxmox VE, conviene saber que el asistente de importación de Proxmox no usa VDDK. Monta los almacenes de ESXi a través de la API HTTPS del host y lee los discos desde ahí, sin librerías de Broadcom. Lo explicamos en la guía del asistente de importación de ESXi. Su modo Live Import arranca la máquina en Proxmox mientras copia el disco, pero con la máquina ya apagada en ESXi.
Lo que el asistente no hace es una migración en caliente con pasadas incrementales por CBT, que copia casi todo mientras la máquina sigue funcionando en VMware y deja para la parada solo la última diferencia. Ahí es donde entran las herramientas basadas en VDDK, y donde una librería que conecte y desconecte discos en 5 segundos en lugar de 30 marca diferencia. Para máquinas grandes que no admiten una parada larga, es la técnica que reduce la ventana de corte de horas a minutos.
Así que OpenVDDK no cambia el camino habitual a Proxmox, pero puede abaratar y acelerar el de las migraciones grandes con poca parada, que hoy dependen de la librería de Broadcom. Lo vigilaremos cuando haya versión pública y pruebas de terceros. Mientras tanto, la guía de migración de VMware a Proxmox sigue siendo el punto de partida.
En Cloud Privado planificamos migraciones de VMware a Proxmox con el método que pide cada carga: importación directa para la mayoría y pasadas incrementales para las que no pueden parar. Si estás dimensionando una salida de VMware, es una buena conversación para empezar.
Una implementación independiente de libvixDiskLib.so.8.0.3, la librería de VDDK de VMware con la que las herramientas de copia de seguridad y migración leen discos de vSphere. Está escrita desde cero a partir de documentación pública y pruebas de caja negra, y está pensada como sustituto directo, sin cambiar la aplicación que la carga.
En las pruebas publicadas por el proyecto, una migración en caliente pasó de 330 a 118 segundos y una en frío de 200 GiB, de 15 min 2 s a 7 min 24 s. Son ejecuciones únicas, hechas con V2K Migrate, una herramienta del mismo autor, y no garantizan la misma mejora en otros entornos.
De momento, no se puede decir. No hay código publicado ni licencia anunciada, y no está disponible para descarga. Los socios de pruebas reciben versiones de evaluación, y la descarga pública llegará con la primera versión candidata.
Solo HotAdd, y solo para lectura, en Linux x86-64. NBD y NBDSSL están previstos. SAN y la escritura de discos quedan fuera.
No. El asistente de importación de Proxmox VE lee los discos a través de la API HTTPS de ESXi, sin VDDK. Las herramientas basadas en VDDK aportan migraciones en caliente con pasadas incrementales por CBT, útiles para máquinas que no admiten una parada larga.
Andrija Panić, miembro del comité de gestión de Apache CloudStack y autor también de V2K Migrate, una plataforma gratuita de migración de VMware a KVM con destinos CloudStack y Proxmox VE.
virt-v2v, y el requisito de descargar la librería propietaria de VMware.Las cifras de rendimiento son las publicadas por el proyecto OpenVDDK y no las hemos reproducido, porque la librería no está disponible para descarga.
Desde Proxmox VE 8.2 no hace falta exportar OVF ni convertir discos a mano: se conecta el host ESXi como un almacenamiento, se elige la VM y se importa, en frío o en vivo. Qué preparar en VMware antes, qué opciones tiene el asistente, qué hacer en Windows y Linux después, cómo automatizarlo con qm import y qué límites tiene.
Tras el giro de licencias de Broadcom, miles de empresas buscan salida. Cómo planificar la migración, qué herramientas de P2V/V2V usar y los errores que arruinan un proyecto.
No solo se migra desde VMware. Muchas organizaciones quieren salir de Hyper-V —por coste de Windows, por consolidar en una plataforma abierta o por soberanía— y el camino tiene sus particularidades. Explicamos las diferencias entre Hyper-V y Proxmox, cómo se convierten los discos VHDX, por qué los drivers VirtIO son imprescindibles y qué comprobar en las VMs Windows y Linux antes y después del salto.