Broadcom a coupé le VDDK : votre plan de sortie de VMware tient-il encore ?

Ce qui s'est passé

Le VDDK est la bibliothèque propriétaire qui permet à un logiciel tiers de lire et d'écrire le contenu d'un disque virtuel VMware sans passer par le système invité. C'est la brique sur laquelle repose à peu près tout l'écosystème : sauvegarde, réplication, conversion P2V et V2V, outils d'archivage et d'e-discovery.

Le 25 août 2026, les URL de téléchargement du VDDK 8 et 9 ont commencé à renvoyer des erreurs, sans annonce, sans note de dépréciation et sans archive. Interrogé, Broadcom a confirmé le changementen indiquant que la bibliothèque est destinée à la sauvegarde et à la restauration de machines virtuelles VMware par des clients sous licence, et que les partenaires technologiques autorisés continuent d'y accéder.

Le problème n'est pas là pour un grand éditeur de sauvegarde, qui a un contact et un accord de redistribution. Il est là pour tout le reste : un intégrateur de trois personnes, un projet open source, ou un DSI qui convertit ses propres charges. Pour eux, le chemin documenté pendant dix ans (« téléchargez le VDDK sur le portail développeur et déposez-le dans ce répertoire ») s'arrête sur un 404.

Pourquoi on ne peut pas simplement le contourner

C'est le point que beaucoup d'équipes découvrent trop tard. La licence du VDDK interdit la redistribution générale. Un éditeur de migration ne peut donc pas mettre la bibliothèque dans son image, un projet open source ne peut pas la packager, et un forum ne peut pas légalement héberger le tarball.

Les conséquences sont déjà visibles dans la documentation des éditeurs : les uns basculent leur recommandation par défaut vers la réplication par agent, les autres renvoient le client vers le support Broadcom, et certains outils voient une partie de leurs méthodes de transfert devenir indisponibles.

Si vous détenez encore une copie légitimement obtenue, traitez-la comme un actif de projet : version, plateforme, taille, empreinte publiée et empreinte que vous calculez vous-même, le tout sous gestion de configuration et pas dans le dossier Téléchargements d'un ingénieur.

Ce qui casse exactement (et ce qui ne casse pas)

Il faut être précis, parce que la panique est mauvaise conseillère en migration.

Ce qui n'est pas touché.L'API vSphere elle-même. Le suivi des blocs modifiés (QueryChangedDiskAreas) est un appel de l'API vSphere, pas une fonction du VDDK. La carte des blocs modifiés reste donc interrogeable. L'export OVF/OVA depuis vCenter fonctionne. L'accès aux fichiers du datastore fonctionne. Vos VM tournent, et elles continueront de tourner.

Ce qui casse. Le chemin de lecturedes blocs. Les modes de transport performants du VDDK (SAN, HotAdd, NBD/NBDSSL) sont ce que les outils utilisent pour aspirer un disque virtuel à pleine vitesse pendant que la VM tourne. Sans eux, les migrations à chaud, les synchronisations incrémentales successives et la fenêtre de bascule courte qui en découle deviennent beaucoup plus difficiles à tenir. Vous savez toujours quels blocs ont changé, vous n'avez plus le tuyau rapide pour les lire.

Traduction opérationnelle : vous ne perdez pas la possibilité de migrer, vous perdez la migration confortable en trois clics et la fenêtre de coupure de quinze minutes que vous aviez promise au métier.

Les quatre chemins de sortie de VMware qui ne dépendent pas du VDDK

AConversion hors ligne

Vous éteignez la VM, vous récupérez ses disques, vous convertissez. Trois variantes, par ordre de préférence :

• Export OVA depuis vSphere, puis virt-v2v -i ova /chemin/MaVM.ova. Le plus propre, le plus lent en préparation, aucun accès privilégié requis.
• Lecture directe du .vmx et des .vmdk sur un datastore que vous pouvez monter (NFS) : virt-v2v -i vmx /chemin/MaVM.vmx. Excellent si votre stockage est déjà en NFS.
• Lecture du .vmxvia SSH sur l'hôte ESXi (-i vmx -it ssh), en lisant dans /vmfs/volumes. Attention : cette variante échoue si la VM porte des snapshots. Il faut les consolider avant.

Coût : une coupure égale à la durée de copie plus la conversion. Bénéfice : zéro dépendance propriétaire, et un artefact reproductible. Les trois modes sont décrits dans la documentation de virt-v2v.

BRéplication dans l'invité (agent-based)

Vous installez un agent dans le système, qui réplique au niveau du bloc ou du fichier vers la cible pendant que la VM tourne, puis vous faites une dernière synchronisation delta au moment de la bascule. C'est le chemin vers lequel plusieurs éditeurs orientent désormais par défaut. Plus lent que le VDDK, mais il ignore complètement l'hyperviseur source, ce qui est précisément la propriété que vous cherchez.

Contraintes réelles : il faut pouvoir installer quelque chose dans l'invité (ce qui exclut les appliances tierces verrouillées), il faut une fenêtre de gel applicatif pour la cohérence des bases de données, et il faut de la bande passante.

CRéplication au niveau du stockage

Si vos VM vivent sur une baie qui sait répliquer, ou sur un datastore que vous pouvez copier au niveau bloc, vous déplacez les LUN ou les fichiers et vous reconstruisez la définition de la VM côté cible. C'est le chemin le plus rapide en volume et le plus exigeant en compétence stockage.

DReconstruction plutôt que migration

Pour toute charge déjà décrite en code (conteneurs, serveurs applicatifs stateless, frontaux), migrer l'image disque est une erreur de méthode. Vous reprovisionnez sur la cible, vous rejouez la configuration, vous basculez le trafic. C'est plus rapide que n'importe quelle conversion, et la dette technique ne suit pas.

Dans la plupart des parcs que nous voyons, la bonne réponse est un mélange : D pour 20 à 30 % des VM, A pour la longue traîne des serveurs peu critiques, B pour les charges qui ne tolèrent pas une longue coupure, C quand le stockage le permet.

La procédure de validation

Une conversion qui démarre n'est pas une migration réussie. Voici la séquence que nous appliquons, et que vous pouvez reprendre telle quelle.

1. 1Inventorier avant de toucher à quoi que ce soit.Version matérielle de la VM, BIOS ou UEFI (et Secure Boot), type de contrôleur disque, disques en RDM, cartes réseau et adresses MAC, snapshots existants, version des VMware Tools, agents installés (sauvegarde, antivirus, supervision), et surtout les licences applicatives liées à un UUID ou à une adresse MAC. C'est là que se cachent les mauvaises surprises, pas dans la copie des octets.
2. 2Nettoyer la source.Consolider les snapshots, arrêter les agents qui n'ont plus de raison d'être sur la cible, noter la taille exacte de chaque disque.
3. 3Choisir une VM témoin par famille, pas une VM facile. Une par système d'exploitation et par profil de stockage. Si vous validez sur un serveur web Debian de 20 Go, vous n'avez rien validé.
4. 4Convertir, puis vérifier l'intégrité avant de démarrer. Somme de contrôle par volume, cohérence du système de fichiers (fsck ou chkdsk), taille et nombre d'inodes comparés à la source.
5. 5Démarrer et vérifier le socle.Amorçage (et notamment le passage UEFI), pilotes virtio ou équivalents présents dans l'initramfs, montages /etc/fstabpar UUID et non par nom de périphérique, nom d'interface réseau (le passage d'un pilote VMware à virtio change souvent le nom prédictible de l'interface, et votre configuration statique ne suit pas), horloge et synchronisation NTP.
6. 6Vérifier l'applicatif, pas le ping.Un test métier scripté, exécuté sur la source avant et sur la cible après, avec le même jeu de données et une comparaison de résultats. « Ça boote » n'est pas un critère d'acceptation.
7. 7Mesurer pour extrapoler.Débit réel observé, durée de la copie initiale, durée du delta final. C'est ce qui vous donne la fenêtre de coupure honnête à annoncer au métier, VM par VM.
8. 8Écrire le retour arrière avant la bascule. La VM source reste éteinte et intacte pendant un nombre de jours défini, avec la procédure de retour documentée et testée une fois.
9. 9Répéter la conversion de la VM témoin une deuxième fois, à partir de la procédure écrite, par quelqu'un d'autre. Si le résultat diffère, ce n'est pas encore une procédure.

Le calendrier est contractuel, pas technique

C'est là que le sujet devient concret pour beaucoup de DSI en Tunisie. Dans la banque, l'assurance et l'industrie, vSphere est le socle par défaut depuis dix ou quinze ans, et la question de la sortie ne se pose sérieusement qu'au moment du renouvellement, quand le nouveau montant arrive.

Le problème, c'est que la coupure du VDDK déplace l'outillage de sortie du côté du fournisseur qu'on veut quitter, exactement au moment où la décision se prend. Un plan de sortie dont la faisabilité dépend d'une bibliothèque qu'on ne peut plus télécharger n'est pas un levier de négociation, c'est une intention.

Trois questions à poser cette semaine, avant la prochaine réunion de renouvellement :

• Par quel chemin technique mon outil de migration lit-il mes disques, et ce chemin dépend-il du VDDK ?
• Si oui, comment mon fournisseur obtient-il encore la bibliothèque, et qu'est-ce qui me le garantit par écrit ?
• Combien de temps prend réellement ma migration si je passe entièrement par des chemins qui n'en dépendent pas ? (Cette réponse se mesure, elle ne s'estime pas.)

Une organisation qui sait répondre à ces trois questions négocie. Les autres renouvellent.

L'expertise AuroraIQ

Nous concevons et exploitons des plateformes ouvertes qui sont précisément des cibles de sortie : OpenStack, Kubernetes, LXD et MicroCloud, avec le stockage Ceph qui va avec. Sur un chantier de sortie de vSphere, nous intervenons sur les trois temps qui comptent : l'inventaire et le classement des charges par chemin de migration, la validation sur VM témoin avec des chiffres de coupure réels, puis l'exploitation de la cibleune fois la bascule faite, parce qu'une migration réussie qui atterrit sur une plateforme que personne n'opère est un problème déplacé, pas résolu.

En résumé : testez votre sortie de VMware maintenant

La coupure du VDDK ne rend pas la sortie de VMware impossible. Elle rend caduques les plans de sortie qui n'avaient jamais été testés. C'est une différence de nature : le premier cas est un problème d'ingénierie, le second est un problème de gouvernance.

La leçon est la même que pour n'importe quelle dépendance propriétaire au cœur d'une chaîne critique (nous la tirions déjà de l'archivage de MinIO) : si votre capacité à partir repose sur un composant que votre fournisseur contrôle, vous n'avez pas un plan de sortie, vous avez une option que quelqu'un d'autre peut retirer. Testez la sortie pendant que vous n'en avez pas besoin.

Vous préparez un renouvellement vSphere ou un plan de sortie ? C'est exactement le type de chantier que nous menons chez AuroraIQ, avec notre expertise en ingénierie cloud. Parlons-en.

À vous de coder. À nous de gérer.