OpenVDDK vise à accélérer les migrations de VMware vers KVM sans dépendre de la bibliothèque de Broadcom

VMware revisite Proxmox : préparer un nouveau vSphere Standard

OpenVDDK est une nouvelle alternative indépendante à la bibliothèque VDDK de VMware, permettant de lire les disques virtuels via des outils de sauvegarde et de migration. Son créateur affirme que cette solution, développée de zéro à partir de documentation publique et de tests en boîte noire, a réduit le temps de migration à chaud d’une machine virtuelle Linux, passant de 330 à 118 secondes lors des premières expérimentations avec V2K Migrate. Le projet est encore en phase de test et, pour l’instant, il ne supporte que la lecture via le transport HotAdd sur des systèmes Linux.

Les points clés d’OpenVDDK en 20 secondes

  • OpenVDDK vise à remplacer libvixDiskLib.so.8.0.3 sans modifier les applications qui l’utilisent.
  • Lors d’un test de migration avec V2K Migrate, le temps a été réduit de 330 à 118 secondes.
  • La lecture d’un disque de 200 GiB a atteint 2,488 MiB/s, contre 1,441 MiB/s avec VDDK.
  • La version actuelle fonctionne sur Linux x86-64 et utilise HotAdd pour accéder aux disques.
  • NBD et NBDSSL sont prévus, mais ne sont pas encore disponibles. Le projet ne propose pas encore de téléchargement public.

L’objectif du projet concerne une partie spécifique de l’infrastructure de virtualisation : la bibliothèque utilisée par certaines applications pour accéder aux disques des machines virtuelles hébergées sur VMware vSphere. OpenVDDK cherche à assurer la compatibilité avec l’interface VDDK, pour que les outils existants puissent utiliser la nouvelle implémentation simplement en remplaçant la bibliothèque, sans nécessiter un autre mode d’accès.

Le projet se positionne comme une alternative autonome à VMware et Broadcom. Selon sa documentation, il ne contient pas de code VMware et reproduit les fonctionnalités nécessaires à partir de documentation publique et de tests en boîte noire. La compatibilité annoncée concerne principalement la lecture des disques pour la migration et la sauvegarde.

De 330 à 118 secondes lors d’une migration avec CBT

La première expérience publiée a été réalisée avec V2K Migrate, un outil gratuit et auto-hébergé pour migrer des machines virtuelles de VMware vers KVM. Selon le responsable du projet, il a utilisé la même version de l’application, la même machine virtuelle et le même environnement d’exécution, en ne changeant que la bibliothèque de lecture de disque.

Il s’agissait d’une migration à chaud d’une VM Debian 13 avec un disque de 20 Go. La procédure comprenait une copie de référence complète, deux transferts incrémentaux avec le Changed Block Tracking (CBT) – avec 2 GiB et 5 GiB de changements respectivement – et une dernière étape après arrêt de la machine virtuelle.

Avec VMware VDDK 8.0.3, la migration a duré 330 secondes. Avec OpenVDDK, le processus a été réduit à 118 secondes, soit environ 64 % de temps en moins pour cette expérience précise. Le responsable indique que les deux bibliothèques ont traité les mêmes données et que les vérifications d’intégrité ont donné des résultats identiques.

Une autre différence notable concerne le délai entre la prise d’une instantanée et la disponibilité du disque pour le système proxy. Selon les résultats, ce délai est passé de 30 secondes avec VDDK à environ cinq secondes avec OpenVDDK. Une fois le disque connecté, la nouvelle bibliothèque commence à lire en millisecondes et met environ 0,35 seconde pour renvoyer les données, contre 12,6 secondes avec VMware.

Ces chiffres expliquent pourquoi l’auteur souligne l’intérêt opérationnel lors des phases d’ouverture et de fermeture du disque. En migration incrémentale, où plusieurs passes de lecture peuvent s’effectuer sur une VM en fonctionnement, le temps d’attente entre opérations peut s’accumuler et rallonger la migration, même si la quantité de données transférées est limitée.

Il convient de préciser que ces résultats, issus de tests publics du projet, ne garantissent pas une amélioration systématique dans toutes les infrastructures. La configuration de l’expérimentation comprenait un environnement ESXi et vCenter 8.0.3, une machine avec 3 CPU virtuels, 4 GiB de RAM, un stockage NFS 4.1 en RAM et une connectivité 100 GbE. De plus, il s’agit de mesures isolées, sans essais répétitifs permettant d’évaluer la variabilité des résultats.

Une seconde expérience avec stockage NetApp

OpenVDDK présente également un test de migration à froid d’une VM Windows Server 2019 avec un disque de 200 GiB. Dans cette configuration, V2K Migrate a lu le disque via HotAdd depuis un stockage NFS de NetApp, puis a écrit le résultat sous forme de fichier qcow2 sur un export NFS du même système.

La migration complète a duré 7 minutes et 24 secondes avec OpenVDDK, contre 15 minutes et 2 secondes avec VMware VDDK 8.0.3. La vitesse d’écriture indiquée était de 537 MiB/s avec la nouvelle bibliothèque, contre 282 MiB/s avec VMware. Le délai entre le début et le premier octet transféré est également passé de 93 secondes à 7 secondes.

Selon les données, les deux méthodes ont écrit la même quantité de données et ont exclu les blocs de zéros. La vérification des données effectuée avec V2K Migrate s’est terminée avec succès, et la comparaison des fichiers qcow2 à l’aide de qemu-img compare a confirmé leur identité.

Le projet attribue cette amélioration à la façon dont les lectures sont effectuées. Au lieu de demander un seul bloc et attendre sa réception, OpenVDDK utilise une lecture anticipée avec plusieurs requêtes en parallèles. Cette stratégie peut réduire le temps d’inactivité, mais modifie la latence des requêtes et augmente l’utilisation CPU de la machine hôte durant la transfert.

Dans le cas de NetApp, la documentation estimer que le processus passe de 594 secondes à environ 180 secondes, en réduisant l’attente sur la lecture. La partie restante du temps de transfert correspond alors davantage à l’écriture des données.

Il faut souligner que cette performance n’est pas garantie pour tous les disques. Le rendement dépend aussi du stockage source et destination, du réseau, de la configuration des VM et de la charge en cours. Le projet indique également que les chiffres d’agilité de lecture ne sont pas directement comparables, car la lecture anticipée permet à OpenVDDK d’avoir les données préparées à l’avance.

HotAdd : une étape, mais pas un remplacement complet de VDDK

La version actuelle d’OpenVDDK se concentre sur le transport HotAdd, qui permet de connecter temporairement le disque d’une VM à une autre machine pour en lire les données. Le projet indique avoir testé des migrations à froid et à chaud, des opérations incrémentales avec CBT, des chaînes d’instantanés et plusieurs disques en parallèle.

La compatibilité déclarée concerne Linux x86-64 avec glibc 2.28 ou ultérieure, avec des tests sur Enterprise Linux 8 et 9. Pour vSphere, le projet mentionne avoir travaillé avec les versions 7.0.3 et 8.0.3. La compatibilité avec vSphere 6.5 et 6.7 est prévue dans la feuille de route.

Le projet inclut aussi des tests de reprise après interruption lors des opérations de connexion et déconnexion. L’objectif est que les ressources résiduelles puissent être nettoyées lors d’une nouvelle exécution si un processus se termine de façon imprévue. Des tests sur des cycles prolongés, avec des disques jusqu’à 3 TiB et jusqu’à 17 disques dans un même processus ont été menés.

Cependant, certains cas restent à couvrir, comme les VM chiffrées, les dispositifs RDM ou les tests à grande échelle avec plusieurs VM. Les transports NBD et NBDSSL sont prévus pour une phase ultérieure. La transmission SAN ne rentre pas dans le cadre actuel. La fonction d’écriture n’est pas encore prévue : OpenVDDK est conçu uniquement pour la lecture, pas pour la restauration via des opérations d’écriture.

L’état actuel du projet est important pour les équipes de gestion d’infrastructures de sauvegarde ou de migration. La compatibilité d’interface peut simplifier l’intégration avec les applications existantes, mais doit encore être vérifiée dans différents environnements avec diverses versions de vSphere, stockage et charges de travail.

OpenVDDK n’est pas encore disponible en téléchargement public. Son responsable recherche des équipes intéressées pour tester des versions d’évaluation dans leurs processus. La publication officielle est prévue pour une étape ultérieure, lorsque le projet aura atteint sa première version candidate.

Questions fréquentes

Qu’est-ce qu’OpenVDDK ?

Il s’agit d’une implémentation indépendante visant à remplacer la bibliothèque libvixDiskLib.so.8.0.3 utilisée par les outils de lecture de disques VMware. Elle est développée de zéro selon ses créateurs, et se concentre sur les opérations de lecture.

OpenVDDK est-il plus rapide que VMware VDDK ?

Selon les tests publiés par le projet, une migration à chaud est passée de 330 à 118 secondes. Lors d’une migration à froid d’un disque de 200 GiB, le temps est passé de 15 minutes et 2 secondes à 7 minutes et 24 secondes. Ces résultats sont spécifiques à des expérimentations ponctuelles et ne garantissent pas une amélioration similaire dans tous les environnements.

Quels transports OpenVDDK supporte-t-il ?

Pour le moment, le projet se concentre sur HotAdd pour la lecture des disques sous Linux. NBD et NBDSSL sont à venir, tandis que le transport SAN n’est pas encore inclus dans le périmètre annoncé.

OpenVDDK est-il téléchargeable ?

Il n’existe pas encore de téléchargement public. Le projet recherche des équipes de migration et de sauvegarde intéressées pour tester des versions d’évaluation en attendant de publier une première version candidate.

le dernier