OpenVDDK es una nueva alternativa independiente a la librería VDDK de VMware que permite leer discos virtuales desde herramientas de copia de seguridad y migración. Su creador asegura que la implementación, desarrollada desde cero a partir de documentación pública y pruebas de caja negra, ha reducido de 330 a 118 segundos una migración en caliente de una máquina virtual Linux en las primeras pruebas con V2K Migrate. El proyecto se encuentra todavía en fase de pruebas y, por ahora, solo admite lecturas mediante el transporte HotAdd en sistemas Linux.

Las claves de OpenVDDK en 20 segundos

• OpenVDDK busca sustituir a libvixDiskLib.so.8.0.3 sin modificar las aplicaciones que la utilizan.
• En una prueba de migración con V2K Migrate, el tiempo pasó de 330 a 118 segundos.
• La lectura de un disco de 200 GiB alcanzó 2.488 MiB/s, frente a 1.441 MiB/s con VDDK.
• La implementación actual funciona en Linux x86-64 y utiliza HotAdd para acceder a los discos.
• NBD y NBDSSL están previstos, pero todavía no están disponibles. El proyecto aún no ofrece una descarga pública.

La propuesta apunta a una parte concreta de la infraestructura de virtualización: la biblioteca que utilizan determinadas aplicaciones para acceder a los discos de las máquinas virtuales alojadas en VMware vSphere. OpenVDDK intenta mantener la compatibilidad con la interfaz de VDDK para que las herramientas existentes puedan utilizar la nueva implementación sustituyendo la biblioteca, sin necesidad de integrar un método de acceso diferente.

El proyecto se presenta como una alternativa independiente de VMware y Broadcom. Según su documentación, no incorpora código de VMware y reproduce las funciones necesarias mediante documentación pública y pruebas de caja negra. La compatibilidad anunciada se centra, de momento, en la lectura de discos para procesos de migración y copia de seguridad.

De 330 a 118 segundos en una migración con CBT

La primera prueba publicada se realizó con V2K Migrate, una herramienta gratuita y autoalojada para migrar máquinas virtuales desde VMware a KVM. El responsable del proyecto afirma que mantuvo la misma versión de la aplicación, la misma máquina virtual y el mismo entorno de ejecución, y que únicamente sustituyó la biblioteca utilizada para leer los discos.

El ensayo consistió en una migración en caliente de una máquina virtual con Debian 13 y un disco de 20 GB. El procedimiento incluyó una copia de referencia completa, dos transferencias incrementales mediante Changed Block Tracking (CBT), con 2 GiB y 5 GiB de cambios, respectivamente, y una última pasada después de apagar la máquina virtual.

Con VMware VDDK 8.0.3, el proceso duró 330 segundos. Con OpenVDDK, el tiempo descendió a 118 segundos, aproximadamente un 64 % menos en esa ejecución concreta. El responsable indica que ambas bibliotecas procesaron los mismos datos y que las comprobaciones de integridad dieron resultados idénticos.

La diferencia también aparece en el tiempo que transcurre desde que se completa una instantánea hasta que el disco queda disponible para el sistema proxy. Según los resultados publicados, ese intervalo pasó de unos 30 segundos con VDDK a alrededor de cinco segundos con OpenVDDK. Una vez conectado el disco, la nueva biblioteca comienza a leer en milisegundos y tarda aproximadamente 0,35 segundos en devolverlo, frente a los 12,6 segundos registrados con la implementación de VMware.

Estos tiempos ayudan a explicar por qué el autor destaca las operaciones de apertura y cierre del disco. En migraciones incrementales, que pueden implicar varias pasadas de lectura sobre una máquina virtual en funcionamiento, la espera entre operaciones puede acumularse y alargar el trabajo aunque el volumen de datos transferidos sea reducido.

Las cifras deben interpretarse como resultados de pruebas publicadas por el propio proyecto, no como una garantía de mejora para cualquier infraestructura. La ejecución se realizó en un entorno concreto con ESXi y vCenter 8.0.3, una máquina de trabajo con tres CPU virtuales y 4 GiB de memoria, un almacenamiento NFS 4.1 respaldado por RAM y una conexión de 100 GbE. Además, se trató de ejecuciones individuales, sin una batería de repeticiones que permita establecer la variabilidad de los resultados.

Una segunda prueba con almacenamiento NetApp

OpenVDDK también publica una prueba de migración en frío de una máquina virtual con Windows Server 2019 y un disco de 200 GiB. En este caso, V2K Migrate leyó el disco mediante HotAdd desde un almacenamiento NFS de NetApp y escribió el resultado como un archivo qcow2 en una exportación NFS del mismo sistema.

La migración completa tardó siete minutos y 24 segundos con OpenVDDK, frente a los 15 minutos y dos segundos con VMware VDDK 8.0.3. La velocidad de copia indicada fue de 537 MiB/s con la nueva biblioteca y de 282 MiB/s con la de VMware. El tiempo desde el inicio hasta el primer byte copiado también bajó de 93 a siete segundos.

Según los datos publicados, ambas ejecuciones escribieron la misma cantidad de información y omitieron los mismos bloques de ceros. La comprobación de datos de V2K Migrate terminó correctamente y la comparación con qemu-img compare confirmó que los dos archivos qcow2 eran idénticos.

El proyecto atribuye buena parte de la mejora a la forma de realizar las lecturas. En lugar de solicitar un único bloque y esperar a recibirlo antes de continuar, OpenVDDK utiliza lectura anticipada y mantiene varias peticiones en vuelo. Esa estrategia puede reducir los tiempos muertos en determinadas cargas de trabajo, aunque también modifica la latencia de cada petición y aumenta el uso de CPU de la máquina de trabajo durante la transferencia.

En la prueba de NetApp, la documentación estima que el proceso pasó de dedicar 594 segundos a esperar por lecturas con VDDK a unos 180 segundos con OpenVDDK. Tras reducir la espera de origen, la escritura del archivo qcow2 pasa a representar una parte mayor del tiempo total.

El comportamiento observado no significa que todos los discos vayan a alcanzar esas velocidades. El rendimiento dependerá también del almacenamiento de origen y destino, de la red, de la configuración de las máquinas virtuales y de la carga concurrente. El propio proyecto advierte, además, de que las cifras internas de velocidad de lectura que aparecen en los registros de las dos bibliotecas no son directamente comparables, porque la lectura anticipada permite que OpenVDDK tenga datos preparados antes de que la aplicación los solicite.

HotAdd es el primer paso, no una sustitución completa de VDDK

La versión actual de OpenVDDK se concentra en el transporte HotAdd, que permite conectar temporalmente el disco de una máquina virtual a otra máquina utilizada como proxy para leer sus datos. El proyecto afirma haber probado migraciones en frío y en caliente, operaciones incrementales con CBT, cadenas de instantáneas y varios discos en paralelo.

La compatibilidad declarada abarca Linux x86-64 con glibc 2.28 o posterior, con pruebas en Enterprise Linux 8 y 9. En cuanto a vSphere, el proyecto indica que ha trabajado con las versiones 7.0.3 y 8.0.3. La compatibilidad con vSphere 6.5 y 6.7 figura en la hoja de ruta.

La documentación también recoge pruebas de recuperación tras interrupciones durante las operaciones de conexión y desconexión. La intención es que una ejecución posterior pueda limpiar los recursos que hayan quedado pendientes si un proceso se termina de forma inesperada. Entre las pruebas realizadas figuran ciclos prolongados, discos de hasta 3 TiB y configuraciones con 17 discos en un mismo trabajador.

Aun así, quedan casos por cubrir, como las máquinas virtuales cifradas, los dispositivos de asignación directa de discos (RDM) y las pruebas de mayor escala con varias máquinas virtuales. Los transportes NBD y NBDSSL están previstos para una fase posterior, mientras que el transporte SAN queda fuera del alcance anunciado. La escritura de discos tampoco está prevista: OpenVDDK está diseñado para leer datos, no para realizar restauraciones mediante operaciones de escritura.

El estado del proyecto es importante para los equipos que gestionan infraestructuras de copia de seguridad o migración. La compatibilidad de interfaz puede reducir el trabajo de integración si funciona con las aplicaciones existentes, pero todavía debe comprobarse en entornos reales con distintas versiones de vSphere, almacenamiento y cargas de trabajo.

OpenVDDK no está disponible todavía para descarga pública. Su responsable busca equipos de migración y copia de seguridad que puedan probar versiones de evaluación en sus propios procesos. La publicación abierta está prevista para una fase posterior, cuando el proyecto alcance su primera versión candidata.

Preguntas frecuentes

¿Qué es OpenVDDK?

Es una implementación independiente que busca sustituir a la biblioteca libvixDiskLib.so.8.0.3 utilizada por herramientas que leen discos virtuales de VMware. Está desarrollada desde cero, según sus responsables, y se centra en operaciones de lectura.

¿Cuánto más rápido es OpenVDDK que VMware VDDK?

En las pruebas publicadas por el proyecto, una migración en caliente pasó de 330 a 118 segundos. En una migración en frío de un disco de 200 GiB, el tiempo descendió de 15 minutos y dos segundos a siete minutos y 24 segundos. Son resultados de pruebas concretas y no garantizan la misma mejora en otros entornos.

¿Qué transportes admite OpenVDDK?

Actualmente, el proyecto se centra en HotAdd para lectura de discos desde Linux. NBD y NBDSSL están previstos, mientras que SAN queda fuera del alcance anunciado.

¿Se puede descargar OpenVDDK?

Todavía no existe una descarga pública. El proyecto está buscando equipos de migración y copia de seguridad que participen en las pruebas con versiones de evaluación antes de publicar una primera versión candidata.