Migrer de VMware à Proxmox : le mode opératoire
La décision de quitter VMware est souvent prise avant d'ouvrir ce guide. Ici, on parle du comment : ce qui a un équivalent et ce qui n'en a pas, comment préparer chaque machine virtuelle, et pourquoi la migration se fait par vagues, avec un retour arrière toujours possible.
Estimer mon coût →Les correspondances qui rassurent #
Si vous en êtes encore à l'arbitrage cloud, on-premise ou colocation, commencez par notre guide sur l'après-VMware : celui-ci suppose la décision prise. L'essentiel de ce que vous utilisez chez VMware existe en face : la haute disponibilité (vSphere HA) correspond au gestionnaire HA intégré, vMotion à la migration à chaud, Storage vMotion au déplacement de disque en ligne, vSAN à Ceph, et les snapshots restent des snapshots. Les règles de placement (affinité et anti-affinité, l'équivalent fonctionnel de DRS) permettent d'interdire que deux serveurs redondants tournent sur le même hôte. La différence la plus visible est économique : pas de licence à l'unité de calcul, une souscription par socket processeur.
Ce qui n'a pas d'équivalent, et il faut le dire #
Fault Tolerance, le mode où une copie fantôme de la machine tourne en parallèle et prend le relais sans aucune interruption, n'a pas d'équivalent. Si une application en dépend vraiment, la réponse est applicative (un cluster actif/actif au niveau du logiciel), pas hyperviseur. Un plan de migration honnête liste ce point dès le départ, plutôt que de le découvrir en recette.
Préparer chaque VM avant de la déplacer #
Une machine virtuelle VMware embarque des pilotes VMware (les VMware Tools). Sur le nouvel hyperviseur, elle a besoin des pilotes VirtIO et de l'agent invité QEMU. L'ordre importe : installer les nouveaux pilotes avant la bascule, retirer les anciens outils après. Pensez aussi aux licences Windows liées au matériel, et au mode de démarrage (BIOS ou UEFI) qui doit suivre. Une VM préparée bascule en minutes ; une VM non préparée démarre sans réseau et sans disque, à l'heure où tout le monde regarde.
L'assistant d'import, et le piège de l'import à chaud #
Depuis la version 8.2 de l'hyperviseur, un assistant d'import fait l'essentiel du travail : on déclare l'hôte VMware comme une source de stockage, la liste des machines virtuelles apparaît, on choisit et on importe. L'assistant lit la configuration d'origine, transfère les disques et les convertit. Deux limites à connaître avant de compter dessus. D'abord il ne sait pas lire un stockage vSAN : il faut alors passer par une étape intermédiaire. Ensuite, l'option d'import à chaud, qui démarre la machine avant la fin de la copie pour réduire la coupure, se paie : les accès disque passent par le réseau tant que la copie n'est pas finie, ce qui peut rendre une base de données inutilisable, et surtout, si l'import échoue en cours de route, tout ce qui a été écrit depuis le démarrage est perdu. On repart de l'état d'avant. Pour une application sensible, une fenêtre de maintenance annoncée reste plus sûre qu'un import à chaud raté.
Le geste Windows que personne ne documente #
Installer les pilotes VirtIO dans une machine Windows ne suffit pas : Windows ne les utilise que s'il a vu le contrôleur correspondant. D'où une manœuvre en quatre temps qui surprend la première fois. On ajoute à la machine un disque temporaire de un gigaoctet sur un contrôleur VirtIO SCSI, on redémarre, et Windows charge alors le bon pilote. On supprime ensuite le disque temporaire, on détache le disque système puis on le rattache en VirtIO SCSI, et on vérifie l'ordre de démarrage. Répétez l'opération sur une machine de test avant de la faire sur une machine de production : une erreur d'ordre de démarrage se répare, une base perdue beaucoup moins.
Migrer par vagues, jamais d'un bloc #
La première vague est un jeu de machines de test : elle valide la chaîne complète, outillage, réseau, sauvegarde, supervision. La deuxième prend les applications non critiques. Les applications critiques passent en dernier, quand la mécanique est rodée. Chaque vague a sa fenêtre annoncée, sa bascule DNS et sa procédure de retour arrière : tant que la vague n'est pas validée, l'ancienne plateforme reste prête à reprendre.
Les bases de données : migration logique, pas copie à chaud #
Copier à chaud une base de données active est le meilleur moyen d'embarquer un état incohérent. La voie sûre est logique : une réplication vers la nouvelle machine, ou une sauvegarde suivie d'une restauration dans la fenêtre. C'est plus long à préparer et beaucoup plus court à réparer.
L'occasion de re-choisir son hébergement #
Une migration d'hyperviseur est le moment naturel de reposer la question de l'hébergement : le contrat de colocation, la puissance souscrite, les opérateurs présents sur le site. Notre Architecte Digital dimensionne le cluster cible et produit la fiche de besoin (espace, puissance, refroidissement) que vous pouvez comparer site par site avant de signer.
Questions fréquentes #
La bascule d'une VM préparée se compte en minutes ; le projet, lui, se compte en semaines, car l'essentiel du temps part dans l'inventaire, la préparation des pilotes et la validation vague par vague. C'est ce temps-là qui évite la coupure surprise.
Souvent oui : les principaux éditeurs de sauvegarde prennent en charge plusieurs hyperviseurs. À valider avec votre version, et à tester sur la première vague, restauration comprise.
Traiter le besoin au niveau applicatif (cluster actif/actif du logiciel) avant la migration : ce mode n'a pas d'équivalent côté hyperviseur, et le découvrir en fin de projet coûte cher.
Non : préférez une migration logique (réplication ou sauvegarde/restauration) à la copie à chaud, pour garantir un état cohérent au démarrage sur la nouvelle plateforme.
Rédigé le 10 septembre 2026.
Passer à la pratique : les datacenters à comparer
Estimer mon coût → Comparer les datacenters