On imagine souvent qu’une migration VMware vers Proxmox se joue au moment du transfert, à l’heure où l’on appuie sur le bouton. C’est l’inverse. Le transfert, les outils le font sans broncher. Ce qui décide du sort d’un chantier, c’est tout ce qui l’entoure : la préparation en amont, et la porte de sortie en aval. Le contexte, lui, pousse de plus en plus de DSI à regarder ailleurs que VMware depuis le rachat par Broadcom et l’envolée des tarifs. Proxmox tient la route. Encore faut-il ne pas transformer l’économie de licence en facture cachée.
Une migration VMware vers Proxmox ne se joue pas au moment du transfert, mais en amont, à la préparation, et en aval, sur un retour arrière réellement testé.
Voici les douze points que je vérifie, regroupés selon le moment où ils comptent.
La préparation, là où tout se gagne
- Inventaire complet : VM, ressources allouées, dépendances entre machines, et surtout les contraintes de disponibilité. Quelle appli ne peut pas tomber une seconde ?
- Stockage cible tranché : ZFS local pour un hôte simple, Ceph pour du distribué, stockage partagé selon ce qui tourne dessus.
- Réseau cartographié : VLAN, plan d’adressage, passerelles, et le MTU (la taille maximale des paquets réseau, à reporter à l’identique des deux côtés). Un MTU mal reporté, c’est le grand classique des migrations qui « marchent sauf pour deux serveurs ».
- Sauvegardes testées : Proxmox Backup Server en place, et une restauration réellement prouvée. Une sauvegarde qu’on n’a jamais remontée ne protège de rien le jour où ça brûle.
- Pilotes VirtIO prêts pour les VM Windows. Sans eux, le disque part en IDE et les performances s’effondrent.
- Plan de vagues : l’ordre de passage. Le moins critique en premier, le cœur métier tout à la fin.
La bascule et l’après
- Vague pilote : on migre d’abord deux ou trois VM dont personne ne se soucie, histoire de valider la chaîne sans pression.
- Import depuis ESXi quand la VM est compatible, conversion à la main sinon.
- Vérification post-démarrage : réseau, disques montés, services applicatifs qui répondent. Et l’heure système, qu’on oublie toujours : une horloge qui dérive passe inaperçue jusqu’au jour où une authentification refuse tout.
- Fenêtre maîtrisée pour les VM critiques, hors heures de service, avec quelqu’un de l’équipe applicative en ligne.
- Garder l’ancien sous le coude : laissez vSphere accessible en lecture quelques jours, c’est votre filet.
- Documenter et transférer : un runbook d’exploitation, puis une vraie passation à l’équipe qui va vivre avec.
Ce qui plante, ce n’est presque jamais le transfert. Ce sont les oublis : un VLAN recopié de travers, une sauvegarde qu’on croyait bonne, un retour arrière qui n’existe que sur le papier. Mon pire souvenir reste un client industriel d’une trentaine de VM dont le retour arrière n’avait jamais été essayé. Une VM applicative refuse de booter après bascule, on veut revenir, et là, mauvaise surprise : le snapshot de secours avait été écrasé la veille pour gagner de la place. Une nuit à reconstruire la machine depuis les sauvegardes. Réparable, mais six heures perdues pour un point qui demandait trois minutes de vérification.
Si vous ne deviez retenir qu’un geste de toute cette liste, prenez celui-ci : avant de toucher à la première VM critique, faites une bascule à blanc puis un retour arrière complet sur une machine sans enjeu, et chronométrez-le. Tant que cette porte de sortie est testée et qu’elle s’ouvre dans un délai que vous connaissez, vous gardez la main, quoi qu’il arrive ensuite.