Cadrage, inventaire et cas bloquants

01Ce que la migration change vraiment

Une migration se vend souvent sur l'argument du coût de licence. C'est un vrai argument, mais ce n'est pas celui qui décide de la réussite du projet. Il faut poser honnêtement ce que la plateforme gagne et ce qu'elle perd, parce que la liste des pertes détermine la charge de travail réelle.

Ce qui se retrouve à l'identique ou presque

• La migration à chaud entre noeuds, l'équivalent de vMotion.
• Le stockage partagé et le déplacement de disque à chaud, l'équivalent de Storage vMotion.
• Le redémarrage automatique après panne d'un noeud, l'équivalent de vSphere HA.
• Les instantanés, les modèles, le clonage lié, les groupes de ressources.
• Un modèle de permissions fin, et une API complète.

Ce qui n'existe pas tel quel

• L'équilibrage de charge automatique façon DRS. Proxmox VE place les machines au démarrage et lors des bascules, mais ne rééquilibre pas en continu. En pratique, cela se compense par un dimensionnement N+1 correct et quelques règles d'affinité.
• Le commutateur virtuel distribué et NSX. Le modèle réseau repose sur des ponts Linux par noeud, ou sur le SDN intégré pour les cas plus complexes.
• Les profils d'hôte et la conformité automatique. C'est ce que remplace un outil de gestion de configuration, Ansible par exemple.
• Les écosystèmes tiers branchés sur les API vSphere : sauvegarde, supervision, sécurité. Chaque outil doit être vérifié individuellement. Le support de Proxmox VE s'est nettement élargi depuis 2024, mais il reste des trous.

02Construire l'inventaire

L'inventaire n'est pas la liste des machines. C'est la liste des machines avec ce qui empêche de les déplacer. Une extraction brute de vCenter ne suffit pas, il faut y ajouter le contexte applicatif, que seul l'exploitant possède.

export GOVC_URL=https://vcenter.exemple.fr
export GOVC_USERNAME=lecture@vsphere.local
export GOVC_INSECURE=1

# inventaire des machines avec systeme, memoire, vCPU et etat
govc find / -type m | while read vm; do
  govc vm.info -json "$vm" | jq -r '.virtualMachines[] |
    [.name, .guest.guestFullName, .config.hardware.numCPU,
     .config.hardware.memoryMB, .runtime.powerState] | @csv'
done

# disques, datastores et instantanes
govc device.info -vm '*' -json | jq -r '...'

Sur les parcs Windows, l'export d'un outil d'audit vSphere du marché fournit la même matière en quelques minutes et présente l'avantage d'être lisible par des non-administrateurs. Peu importe l'outil : ce qui compte, ce sont les colonnes.

03Trier les machines en quatre catégories

Le tri conditionne la charge du projet. Une machine qui passe par l'assistant d'import coûte quelques dizaines de minutes ; une machine à reconstruire coûte plusieurs jours.

Commencez par migrer deux ou trois machines de la catégorie directe, sans enjeu, pour valider la chaîne complète et mesurer les durées réelles. Ces chiffres servent ensuite à construire un calendrier crédible, ce qu'aucune estimation théorique ne permet.

04Les cas bloquants, à repérer tôt

Chacun de ces cas a une solution, mais aucune ne s'improvise le jour de la bascule.

Côté stockage

• Disques sur vSAN : l'assistant d'import ne les lit pas. Il faut d'abord déplacer les disques concernés vers un autre datastore, ou passer par un export.
• Mappages de périphérique brut (RDM) : à convertir en disque virtuel avant migration, ou à reprendre en passage direct côté Proxmox VE, ce qui interdit alors la migration à chaud de cette machine.
• Disques chiffrés par une politique de stockage : l'import échoue tant que le chiffrement n'a pas été retiré côté VMware.
• Disques partagés entre machines, typiquement un cluster de bascule Windows. La reprise demande une conception spécifique, jamais un import.
• Instantanés présents : ils ralentissent fortement l'import et compliquent la chaîne de disques. À consolider avant, toujours.

Côté machine

• Licences liées au matériel : certaines applications se lient à l'adresse MAC ou à l'identifiant SMBIOS. Les deux se reprennent côté Proxmox VE, à condition de les avoir relevés avant d'éteindre la source.
• Appliances fournisseur livrées en OVA avec support conditionné à l'hyperviseur. Question à poser à l'éditeur avant, pas après.
• Clés physiques USB : le passage direct existe côté Proxmox VE, mais il attache la machine à un noeud précis.
• Systèmes en fin de support : les pilotes VirtIO n'existent pas pour tout. Sur les très anciens Windows, prévoyez la reconstruction plutôt que la migration.

05Dimensionner la cible

Le dimensionnement suit les règles du chapitre architecture du guide cluster, avec trois corrections propres à une migration.

• La surréservation processeur de vSphere n'est pas transposable telle quelle. Repartez de la consommation mesurée, pas des vCPU alloués. Un parc VMware alloue typiquement deux à trois fois ce qu'il consomme.
• Prévoyez la place des deux plateformes en même temps. Pendant plusieurs semaines, une partie des machines existe en double. Le stockage cible doit encaisser l'ensemble du parc migré plus la marge de reconstruction, sans dépasser 70 à 75 % de remplissage.
• Comptez les serveurs ESXi récupérables. Une fois vidés, ils rejoignent le cluster Proxmox VE. Le dimensionnement initial peut donc être plus modeste que la cible finale, à condition que le calendrier de libération soit tenu.

06Plan de lots et fenêtres

Un lot est un ensemble de machines qui basculent dans la même fenêtre, parce qu'elles dépendent les unes des autres. Découper par service applicatif, jamais par ordre alphabétique ni par datastore.