Une machine virtuelle peut démarrer sur le nouveau système sans être prête pour la production. Le passage de VMware à Proxmox inclut donc la recette de l’application et de ses dépendances. L’importation technique est une composante de cette démarche.
Recenser les dépendances avant l’importation
L’inventaire couvre le système d’exploitation, le mode de démarrage, les périphériques virtuels, les réseaux, les disques et les services nécessaires. Les licences applicatives, les logiciels de sauvegarde et les moyens d’accès sont également examinés. Une modification du matériel virtuel peut affecter les pilotes et les licences liées au matériel.
Un ordre est défini pour les systèmes qui fonctionnent ensemble. Une application, son service de base de données et les services d’identité ne peuvent pas être évalués indépendamment. Chaque vague de migration dispose donc d’un interlocuteur métier et de critères vérifiables de réussite.
Choisir une méthode de migration adaptée
Proxmox documente les méthodes d’importation depuis VMware ESXi et d’autres procédures de migration. Le choix dépend de la version source, des accès, des disques et du créneau prévu. Le fabricant décrit également des limites, par exemple pour le transfert de l’état du TPM virtuel. Ces dépendances sont évaluées avant la bascule en production.
Pour les systèmes invités Windows, les pilotes VirtIO appropriés et le matériel de disque et de réseau effectivement choisi sont notamment importants. Les informations nécessaires à la restauration sont conservées. Un pilote à faible risque peut révéler rapidement les adaptations requises par le parc existant ; il ne démontre pas la compatibilité de toutes les autres VM.
Tester l’application du point de vue de l’utilisateur
La recette comprend la connexion, des traitements représentatifs, les fichiers, l’impression ou les interfaces externes lorsqu’ils font partie de l’application. La sauvegarde et la restauration doivent également fonctionner sur le nouveau système. Un ping et un bureau démarré ne suffisent pas.
Les adresses réseau, le service de temps et la résolution de noms sont vérifiés explicitement. Le démarrage de copies pour les tests ne doit pas créer une instance de production en double, incontrôlée et utilisant les mêmes identités. L’environnement de test reçoit un rôle clairement délimité et des règles d’accès adaptées.
Définir une limite temporelle au retour arrière
Avant la bascule, il est précisé jusqu’à quel point un retour arrière reste possible. Les nouvelles données déjà créées sur la cible ne se récupèrent pas simplement en rallumant l’ancienne VM. Les décisions, la réconciliation des données et les responsabilités sont prévues pour ce cas.
DAXS structure la migration en vagues traçables avec un pilote, une validation métier et des contrôles ultérieurs documentés. L’ancien environnement n’est retiré qu’après une clôture explicitement définie. La migration reste ainsi un changement d’exploitation vérifiable et n’est pas assimilée à un simple transfert de fichiers réussi.
Planification de l’infrastructure · Estimer l’effort informatique · Parler d’une migration
Sources : Proxmox : migration et importation depuis ESXi (lien externe) · Proxmox : pilotes VirtIO pour Windows (lien externe)
