Migration hors de VMware : les risques de perte de données à anticiper

Depuis le rachat de VMware par Broadcom et la refonte de son modèle de licences, des milliers d’organisations migrent leurs machines virtuelles vers d’autres plateformes. Le mouvement est profond : Gartner anticipe que plus d’un tiers des charges VMware tourneront ailleurs d’ici 2028. Les guides expliquent abondamment comment mener cette bascule. Presque aucun ne dit ce qui, en chemin, fait perdre des données de façon définitive.

C’est pourtant la question qui compte pour un responsable d’infrastructure. Une migration n’est pas un simple déplacement de fichiers : c’est une réécriture, une reconversion et un remappage de stockage, et chacune de ces étapes a ses points de rupture. Cet article ne compare pas les hyperviseurs et ne déroule aucune procédure. Il décrit, par nature de défaillance, ce qui détruit réellement des données pendant une migration, et comment l’éviter.

La conversion de format : une migration « réussie » ne l’est pas toujours vraiment

Passer un disque virtuel d’un format à un autre, du VMDK de VMware vers le VHDX de Hyper-V ou le QCOW2 de KVM et Proxmox, n’est pas une simple traduction. Les plateformes ne représentent pas les données de la même façon : la taille des blocs, la gestion du provisionnement fin, la manière de coder les zones vides et les zones réécrites diffèrent d’un format à l’autre. Un outil de conversion peut terminer son travail sans erreur et produire un disque qui démarre, tout en ayant mal interprété certaines de ces subtilités.

La corruption est alors silencieuse. Elle ne se voit pas au premier démarrage, mais dans un fichier ouvert des semaines plus tard, ou dans une base de données qui refuse soudain de se monter. Une conversion réussie au sens de l’outil n’est donc pas toujours une conversion intègre. La seule parade sérieuse est la vérification : contrôler l’intégrité applicative des données sur la cible, pas seulement le fait que la VM s’allume.

Les snapshots : la chaîne qu’on croit accessoire

Une VM VMware traîne souvent une chaîne de snapshots, ces états intermédiaires empilés les uns sur les autres. C’est un piège de migration à part entière, pour une raison simple : l’état réel de la machine n’est pas dans le disque de base, il est dispersé dans cette chaîne. Migrer une VM sans consolider proprement ses snapshots, c’est risquer de basculer une image incohérente, amputée des dernières modifications ou, pire, mêlant des états qui ne devraient pas coexister. Le risque monte avec les snapshots mémoire, et quand les datastores source et cible ne gèrent pas les fichiers de delta de la même manière.

La documentation de VMware est sans ambiguïté sur ce point : un snapshot n’est pas une sauvegarde, faire tourner une VM sur ses snapshots de façon prolongée peut provoquer instabilité et perte de données, et une consolidation peut échouer. Avant toute migration, la règle est de consolider les snapshots et de vérifier qu’il n’en reste aucun en attente, plutôt que d’emporter une chaîne fragile dans la bascule.

Le stockage sous-jacent : migrer, c’est aussi remapper des disques

On l’oublie souvent : une machine virtuelle ne flotte pas dans le vide, elle vit sur du stockage physique, du RAID, un NAS ou un SAN. Migrer, c’est donc aussi remapper ce stockage, faire passer les données d’un système de fichiers VMFS vers autre chose, réattacher des LUN, resynchroniser des baies. Cette couche a ses propres accidents.

Un LUN mal réattaché, une baie RAID resynchronisée dans le mauvais sens, une reconstruction lancée au mauvais moment exposent les données autant qu’une conversion ratée. Sur un NAS ou un SAN qui héberge les datastores, une erreur de manipulation pendant la bascule peut rendre inaccessibles des volumes entiers, indépendamment de l’état des VM elles-mêmes. Une migration se prépare donc autant côté stockage que côté hyperviseur, et les deux plans se valident séparément.

La réplication et la bascule : démarrer sur des données partielles

La plupart des migrations reposent sur une réplication continue de la source vers la cible, jusqu’à une bascule finale, le cutover. Le point faible est cette réplication, car elle peut échouer pour des raisons multiples. Microsoft documente, pour la migration de VM VMware, des échecs de cycle allant de la configuration réseau au backend du service cible, et signale que le suivi des blocs modifiés, le Changed Block Tracking, peut être réinitialisé ou bloqué par des snapshots préexistants, ou encore qu’un manque d’espace sur le datastore fait échouer les opérations.

Le danger n’est pas l’échec en lui-même, qui se voit, mais la bascule lancée sur une réplication incomplète : on démarre alors la cible sur des données partielles, en croyant la migration terminée. Avant tout cutover, il faut vérifier que le dernier cycle de réplication s’est réellement achevé, et pas seulement qu’un tableau de bord affiche un statut vert.

Le point de non-retour : effacer la source trop tôt

Vient le moment le plus dangereux, et c’est celui que les guides éludent. Une fois la cible en apparence fonctionnelle, la tentation est grande de libérer les ressources : décommissionner l’environnement source, réutiliser le datastore, effacer les VM d’origine. Tant que la cible n’a pas été validée complète et démarrable, ce geste est irréversible. Si la conversion avait corrompu un disque, si la réplication était partielle, si un volume manquait, la source était le dernier exemplaire intact des données, et elle vient de disparaître.

C’est précisément là qu’un dernier filet est censé jouer, la sauvegarde. Encore faut-il qu’elle protège vraiment. Une sauvegarde qui n’a jamais été restaurée pour de vrai reste une hypothèse, et une chaîne de sauvegarde encore liée à l’ancien environnement ne garantit rien sur la cible. La règle tient en une phrase : ne jamais effacer la source avant d’avoir vérifié, données en main, que la cible est complète et qu’elle démarre.

Quand la migration a déjà détruit des données

Il arrive qu’une bascule tourne mal. Un disque virtuel corrompu à la conversion, un VMDK devenu orphelin, une VM restée à moitié migrée, un datastore source effacé trop tôt : dans tous ces cas, la récupération devient un travail de laboratoire. Et là, une règle vaut comme pour tous les autres supports. Ce qui a été écrasé par une réécriture est perdu, personne ne le reconstruira. Ce qui subsiste sur un support intact, ou sur une source pas encore réutilisée, peut souvent être remonté.

C’est le cas de la récupération d’une VM corrompue ou d’un VMDK inexploitable après migration : on reconstruit le disque virtuel à partir de ce qui reste lisible, puis on en réextrait les données. Une chose compte alors plus que tout, le moment où l’on appelle. Quand la bascule a détruit des données, le laboratoire a d’autant plus de chances d’aboutir qu’on le sollicite tôt, avant d’avoir écrasé la source en tentant de refaire la migration par-dessus.

Ce qui sépare une migration réussie d’un sinistre différé

La migration hors de VMware n’est pas dangereuse en soi. Ce qui l’est, c’est de la traiter comme une formalité technique dont la réussite se mesurerait au seul fait que les VM redémarrent. Une VM qui démarre n’est pas une VM dont toutes les données sont intactes, et c’est cet écart, entre « ça marche » et « rien n’a été perdu », qui distingue une migration réussie d’un sinistre différé. Le seul moment où l’on peut effacer la source sans risque, c’est quand on en a la preuve, et pas seulement l’impression : la cible est complète, et elle démarre.