Préparer une migration VMware : inventaire, dépendances, ordre¶

Day 0 · ConcevoirNiveau 2 · OpérerChecklistRédigé · à valider en lab

Objectif. Arriver au jour de la bascule avec un inventaire complet, chaque VM classée (méthode de migration, fenêtre, risque) et un ordre de vagues validé avec le MSP. Chaque point se coche après vérification par une commande ou un écran.

Outils utilisés

Côté VMware : client vSphere, PowerCLI (Connect-VIServer) ou un export d'inventaire de type RVTools. Côté Proxmox : GUI et shell d'un nœud (pve01).

1. Inventaire des VMs source¶

Liste exhaustive exportée (nom, OS invité, vCPU, RAM, disques, taille provisionnée et utilisée, réseau, état) : Get-VM | Select Name, PowerState, NumCpu, MemoryGB, ProvisionedSpaceGB, UsedSpaceGB, @{N='OS';E={$_.Guest.OSFullName}} | Export-Csv vms.csv -NoTypeInformation
Propriétaire métier et criticité renseignés pour chaque VM (colonne ajoutée au CSV).
VMs obsolètes identifiées et exclues : elles ne seront pas migrées.
Firmware relevé (BIOS ou EFI) et Secure Boot : Get-VM | Select Name, @{N='Firmware';E={$_.ExtensionData.Config.Firmware}}.
VMs avec vTPM identifiées (Windows 11, BitLocker) : clé de récupération BitLocker sauvegardée avant la migration.
Version d'OS invité supportée par les pilotes VirtIO actuels (les vieux Windows peuvent exiger une ancienne version de virtio-win).

2. Points bloquants pour l'import¶

Aucun snapshot en cours : Get-VM | Get-Snapshot ne renvoie rien (sinon consolider ; un import avec snapshots est nettement plus lent).
Aucun disque sur vSAN : l'assistant d'import ne sait pas les lire. Déplacer d'abord vers un datastore VMFS ou NFS.
Aucun disque chiffré par une politique de stockage : retirer le chiffrement avant.
Noms de datastores sans caractères spéciaux (par exemple +) : renommer si besoin.
Disques RDM, disques partagés multi-writer (clusters MSCS/WSFC), périphériques USB ou PCI en passthrough listés : traitement au cas par cas avec le MSP.
Accès direct aux hôtes ESXi possible (l'import via vCenter fonctionne mais est 5 à 10 fois plus lent selon la documentation).
Version ESXi entre 6.5 et 8.0 (plage testée par l'éditeur) : Get-VMHost | Select Name, Version, Build.

3. Dépendances applicatives¶

Flux réseau de chaque application cartographiés (serveurs liés, ports, partages).
Groupes de VMs à migrer ensemble identifiés (application + base de données + serveur de licences).
Licences liées à l'adresse MAC, au numéro de série matériel ou à l'UUID repérées : la carte réseau change de modèle et de MAC à la migration.
IP statiques relevées pour chaque VM Windows : la nouvelle carte VirtIO devra être reconfigurée.
Réservations DHCP liées à une MAC listées : à mettre à jour ou conserver la MAC d'origine dans la configuration Proxmox.
Éditeurs d'applications consultés sur le support de KVM/Proxmox.

4. Plateforme cible prête¶

Cluster sain et en quorum : pvecm status affiche Quorate: Yes.
Stockage cible dimensionné (espace utilisé source + 30 % de marge) : pvesm status.
Ceph HCI : ceph -s en HEALTH_OK, remplissage prévisionnel sous le seuil nearfull (calculateur Ceph).
Chaque port group VMware a son équivalent : bridge VLAN aware et numéro de VLAN, ou VNet SDN. Contrôle : cat /etc/network/interfaces, Datacenter → SDN.
Débit entre ESXi et PVE mesuré (lien 10 Gb/s conseillé pour les gros volumes).
ISO virtio-win déposée sur un stockage ISO du cluster.
PBS local pbs-local opérationnel et job de sauvegarde prêt à inclure les nouveaux VMID.
Plage de VMID réservée pour les VMs migrées (par exemple 101 à 199).

5. Préparation des invités¶

Pilotes VirtIO installés dans les VMs Windows avant la migration (procédure).
Linux : modules virtio_scsi, virtio_blk, virtio_net présents dans l'initramfs ; /etc/fstab utilise des UUID ou labels, pas /dev/sdX.
Procédure de désinstallation des VMware Tools prête (à faire juste avant l'arrêt de la VM source : après migration, la désinstallation peut échouer).
Comptes administrateur local connus pour chaque VM (en cas de perte du domaine au premier démarrage).

6. Ordre et vagues¶

flowchart LR
    V0[Vague 0<br/>VM de test jetable] --> V1[Vague 1<br/>VMs Linux non critiques]
    V1 --> V2[Vague 2<br/>Windows non critiques]
    V2 --> V3[Vague 3<br/>Applications métier<br/>par groupe de dépendances]
    V3 --> V4[Vague 4<br/>Infra cœur : AD, DNS,<br/>bases critiques]

Vague 0 réalisée sur une VM de test, durée réelle d'import mesurée (Go/heure).
Chaque vague tient dans sa fenêtre de maintenance, calculée avec ce débit réel.
Pas plus de quatre disques importés simultanément (recommandation éditeur).
Contrôleurs de domaine : au moins un reste sur l'ancienne plateforme tant que l'autre n'est pas validé.
Planning de vagues validé par les métiers et communiqué au MSP par ticket P4.

7. Bascule et retour arrière¶

Méthode choisie par VM : assistant d'import ESXi, OVF/VMDK ou réinstallation.
Règle écrite : la VM source reste éteinte, jamais supprimée, jusqu'à la fin de la recette.
Critère de retour arrière défini par VM (qui décide, avant quelle heure).
Rollback décrit : arrêt de la VM Proxmox, démarrage de la VM VMware, restauration des MAC/IP.
Recette prévue par VM : checklist post-migration.

Pièges vus en support

VM Proxmox et VM VMware démarrées en même temps : conflit d'IP, de nom NetBIOS, voire réplication AD corrompue.
Désinstallation des VMware Tools oubliée sur Windows : elle échoue ensuite hors de VMware et laisse des services en erreur.
Durée d'import estimée sur la taille provisionnée au lieu du débit réel mesuré : fenêtre dépassée.
Licence applicative liée à la MAC : le logiciel refuse de démarrer au lundi matin.

Quand ouvrir un ticket iTop

Ticket P4 pour faire valider l'inventaire, le dimensionnement et le planning de vagues par le MSP. Ticket P3 si un point bloquant de la section 2 n'a pas de solution évidente (vSAN, RDM, cluster Windows à disques partagés).

Ouvrir un ticket iTop