Une migration VMware vers Proxmox peut sembler simple sur le papier : transférer les machines virtuelles, adapter leur configuration et les redémarrer sur la plateforme cible.
Sur le terrain, les difficultés apparaissent rarement pendant la seule conversion des disques. Elles se trouvent plutôt dans les dépendances applicatives, le réseau, la validation métier, la sauvegarde et la capacité de retour arrière.
Voici sept erreurs observées en conditions réelles — et les précautions à prendre avant de généraliser une migration.
Erreur 1 : se contenter de l'inventaire VMware
Le premier réflexe consiste souvent à exporter l'inventaire vCenter : nombre de machines virtuelles, CPU, mémoire, capacité disque, systèmes d'exploitation et état des VMware Tools.
Ces informations sont indispensables, mais elles ne suffisent pas pour construire un plan de migration.
Une VM apparemment simple peut dépendre :
- d'un serveur DNS ou NTP particulier ;
- d'un partage de fichiers ;
- d'une base de données hébergée sur une autre machine ;
- d'une adresse IP inscrite dans une configuration ;
- d'un équipement réseau ou de sécurité ;
- d'une licence attachée à une caractéristique matérielle ;
- d'un service dont le responsable n'est pas clairement identifié.
L'inventaire décrit la machine. Il ne décrit pas nécessairement le service qu'elle rend.
Avant toute migration, l'inventaire technique doit donc être complété par une cartographie des dépendances applicatives, réseau et organisationnelles.
Il faut notamment savoir qui utilise le service, qui peut le valider et quels autres composants sont nécessaires à son fonctionnement.
Erreur 2 : considérer qu'une VM démarrée est une VM validée
Voir l'écran de connexion après la migration est rassurant. Ce n'est pourtant que la première étape de la recette.
Une VM peut démarrer correctement tout en présentant :
- une interface réseau mal reconnue ;
- une configuration IP incorrecte ;
- un service applicatif arrêté ;
- une tâche planifiée défaillante ;
- un problème de résolution DNS ;
- une baisse importante des performances ;
- un agent de supervision absent ;
- une sauvegarde qui ne fonctionne plus ;
- une dépendance distante devenue inaccessible.
La validation doit couvrir plusieurs niveaux :
- le démarrage du système ;
- la configuration réseau ;
- l'état des services ;
- le fonctionnement de l'application ;
- la validation par son responsable ;
- la supervision et la sauvegarde ;
- le comportement après un redémarrage supplémentaire.
Les critères de validation doivent être écrits avant la migration. Sans cela, le succès repose sur une appréciation improvisée au moment de la bascule.
Erreur 3 : utiliser le pilote comme une simple démonstration
Un pilote ne doit pas seulement démontrer qu'une VM VMware peut fonctionner sur Proxmox.
Cette démonstration est utile, mais elle ne permet pas encore de décider si la méthode peut être appliquée à plusieurs dizaines ou centaines de machines.
Le pilote doit produire des mesures :
- temps de préparation ;
- durée du transfert ;
- durée de conversion ou de restauration ;
- temps d'indisponibilité ;
- durée de la recette ;
- performances avant et après migration ;
- temps nécessaire pour revenir à la source ;
- charge réelle pour les équipes techniques.
Ces données servent ensuite à déterminer la taille des vagues, les fenêtres de maintenance et les ressources humaines nécessaires.
Un pilote qui se termine par « la VM fonctionne » reste incomplet. Il doit également répondre à une question plus importante : la méthode est-elle suffisamment fiable, reproductible et documentée pour être industrialisée ?
Erreur 4 : sous-estimer le réseau
Les échanges préparatoires se concentrent souvent sur le format des disques, la méthode d'importation et la compatibilité des systèmes invités.
Pourtant, une part importante des difficultés apparaît dans le réseau.
Avant la migration, il faut vérifier :
- la correspondance entre les port groups VMware et les bridges Proxmox ;
- les VLAN autorisés sur les interfaces physiques ;
- la MTU ;
- les routes et les passerelles ;
- les règles de pare-feu ;
- les réservations DHCP ;
- les enregistrements DNS ;
- les flux entre applications ;
- les adresses inscrites directement dans des fichiers de configuration.
Une erreur de correspondance entre un réseau VMware et un bridge Proxmox peut donner l'impression que la VM est défaillante alors que le problème se situe entièrement dans son environnement.
La cartographie réseau ne doit pas rester implicite. Elle doit faire partie des documents préparatoires, avec une correspondance claire entre l'environnement source et la plateforme cible.
Erreur 5 : supprimer ou modifier trop tôt la source VMware
Une migration ne doit pas créer immédiatement un point de non-retour.
Pendant le pilote et les premières vagues, la source VMware doit rester disponible tant que les validations techniques, applicatives et métier ne sont pas terminées.
Cette conservation doit toutefois être encadrée. Il ne suffit pas de laisser l'ancienne VM arrêtée quelque part dans vCenter.
Il faut définir :
- son état avant la migration ;
- les conditions permettant son redémarrage ;
- la personne autorisée à prendre cette décision ;
- la gestion des adresses IP et des noms DNS ;
- la manière de traiter les données créées après la bascule ;
- la durée de conservation avant suppression définitive.
Le rollback doit préciser :
- les événements qui le déclenchent ;
- l'heure limite de décision ;
- les responsabilités ;
- la procédure de remise en service ;
- les contrôles à effectuer après le retour ;
- la gestion des éventuelles données divergentes.
La source ne devrait être supprimée qu'après la validation finale et l'expiration de la période de sécurité convenue.
Erreur 6 : organiser les vagues uniquement selon la facilité technique
Commencer par des VM peu critiques est une bonne manière de valider la méthode. Mais organiser l'ensemble du projet uniquement selon la facilité technique peut créer de nouvelles incohérences.
Deux VM appartenant à la même application peuvent devoir être migrées ensemble. À l'inverse, deux machines présentes dans le même cluster VMware peuvent relever de responsables et de fenêtres de maintenance totalement différents.
Une vague cohérente regroupe des charges qui partagent :
- une dépendance métier ;
- une fenêtre de changement ;
- une équipe de validation ;
- un niveau de criticité ;
- une stratégie de retour arrière compatible.
La bonne unité de migration n'est donc pas toujours la machine virtuelle. C'est souvent le service applicatif.
Cette organisation facilite également la communication. Chaque vague possède un périmètre compréhensible, des responsables identifiés et des critères de validation communs.
Erreur 7 : oublier l'exploitation après la migration
Une plateforme Proxmox opérationnelle ne garantit pas que l'organisation soit prête à l'exploiter durablement.
Avant de généraliser la migration, l'équipe doit savoir :
- créer et restaurer une sauvegarde ;
- diagnostiquer une VM qui ne démarre pas ;
- vérifier l'état du stockage ;
- contrôler les réplications ;
- gérer les mises à jour ;
- interpréter les alertes ;
- retrouver les journaux utiles ;
- appliquer une procédure de reprise ;
- contacter le bon niveau de support.
Le changement d'hyperviseur implique aussi un changement de pratiques.
Il n'est pas toujours pertinent de reproduire à l'identique toutes les habitudes VMware. Mais les remplacer sans documentation crée une nouvelle dépendance : celle envers la personne qui a conçu la plateforme.
La supervision, la sauvegarde et les procédures de reprise doivent donc être validées pendant le pilote, pas plusieurs semaines après la mise en production.
Ce que le terrain change dans la méthode
Ces erreurs montrent qu'une migration VMware vers Proxmox ne doit pas être traitée comme une simple opération de conversion.
Une méthode solide repose sur plusieurs principes :
- comprendre les services avant de déplacer les VM ;
- mesurer les résultats du pilote ;
- définir les critères de validation en amont ;
- préparer le réseau cible ;
- conserver une possibilité de retour contrôlée ;
- organiser les vagues autour des dépendances ;
- préparer l'équipe qui exploitera la nouvelle plateforme.
La technologie utilisée pour transférer les machines compte. La capacité à décider, vérifier et revenir en arrière compte davantage.
Checklist avant de donner un GO
Avant d'autoriser une migration ou une nouvelle vague, les points suivants doivent être vérifiés :
- la VM source est sauvegardée et son état est connu ;
- ses dépendances sont identifiées ;
- le réseau cible est préparé ;
- la procédure de migration a été testée ;
- le temps d'indisponibilité est accepté ;
- les critères de recette sont documentés ;
- le responsable de la validation est disponible ;
- le rollback possède un déclencheur et un décideur ;
- la sauvegarde est prévue sur la plateforme cible ;
- la supervision est opérationnelle ;
- les résultats seront consignés après l'intervention.
Si plusieurs réponses restent incertaines, la bonne décision n'est pas nécessairement d'abandonner la migration.
Il peut être préférable de prolonger le pilote, de réduire le périmètre ou de diviser la vague en plusieurs étapes.
Point de vue
Migrer de VMware vers Proxmox est techniquement accessible dans de nombreux environnements. Mais la réussite ne se mesure pas au nombre de VM transférées.
Elle se mesure à la capacité de l'organisation à maintenir les services, valider leur fonctionnement et reprendre le contrôle lorsqu'un écart apparaît.
Une migration maîtrisée repose sur trois capacités : comprendre les dépendances, mesurer les résultats et conserver une possibilité de retour.
La vitesse vient ensuite.