Préparer la cible et les systèmes invités

01La cible prête avant de commencer

Cinq points doivent être acquis avant le premier import. Ils viennent tous du guide cluster, ce paragraphe n'est qu'une liste de contrôle.

• Cluster en quorum, deux liens corosync actifs, pvecm status propre.
• Stockage partagé opérationnel et éprouvé, avec la marge de reconstruction disponible.
• Ponts réseau et VLAN déjà déclarés sur tous les noeuds, à l'identique.
• Proxmox Backup Server en service, avec un magasin dimensionné pour le parc cible.
• Supervision branchée, pour voir l'effet de la charge d'import sur la plateforme.

02Table de correspondance réseau

Côté VMware, une machine est raccordée à un portgroup qui porte un VLAN. Côté Proxmox VE, elle est raccordée à un pont compatible VLAN, avec une étiquette. La table de correspondance s'écrit une fois pour tout le parc, et devient la référence de la bascule.

# le pont doit accepter la plage de VLAN attendue
bridge vlan show dev vmbr1

# test de bout en bout avec une interface temporaire
ip link add link vmbr1 name test110 type vlan id 110
ip addr add 10.110.0.250/24 dev test110 && ip link set test110 up
ping -c 3 10.110.0.1
ip link del test110

03Préparer un invité Windows

C'est ici que se joue la réputation d'une migration. Un Windows importé dont le disque système bascule sur un contrôleur VirtIO sans pilote correspondant ne démarre pas : écran bleu INACCESSIBLE_BOOT_DEVICE, ou code d'arrêt 0x0000007B sur les versions plus anciennes. Le système n'est pas endommagé, il ne sait simplement plus lire son propre disque.

Pendant que la machine tourne encore sur VMware

1. Relever ce qui est lié au matériel : adresses MAC, identifiant SMBIOS, clés d'activation d'applications sensibles. Une fois la source éteinte, ces informations sont pénibles à retrouver.
2. Installer les pilotes VirtIO depuis l'image officielle virtio-win. L'installateur place les pilotes dans la réserve de pilotes du système, ce qui permettra à Windows de trouver le contrôleur au premier démarrage sur Proxmox VE. C'est l'étape que l'on saute et que l'on regrette.
3. Désinstaller VMware Tools, puis redémarrer. À faire avant la migration : une fois la machine sortie de son environnement VMware, la désinstallation devient laborieuse et laisse des services fantômes.
4. Désactiver les agents liés à vSphere : sauvegarde par instantané, supervision par API, antivirus sans agent.
5. Vérifier l'espace disque libre et lancer une sauvegarde complète, hors instantané VMware.

# apres montage de l'image virtio-win, injection des pilotes signes
pnputil /add-driver E:\vioscsi\2k22\amd64\vioscsi.inf /install
pnputil /add-driver E:\viostor\2k22\amd64\viostor.inf /install
pnputil /add-driver E:\NetKVM\2k22\amd64\netkvm.inf /install
pnputil /add-driver E:\Balloon\2k22\amd64\balloon.inf /install

# controle : les pilotes doivent apparaitre dans la reserve
pnputil /enum-drivers | Select-String -Pattern "vioscsi|viostor|netkvm"

Après l'import, il restera à installer l'agent invité QEMU, qui remplace VMware Tools : il permet l'arrêt propre, la remontée des adresses IP dans l'interface, et la mise en pause du système de fichiers pendant la sauvegarde.

04Préparer un invité Linux

Linux pose beaucoup moins de problèmes, les pilotes VirtIO étant dans le noyau depuis longtemps. Trois points méritent quand même une vérification.

# 1. les modules virtio doivent etre presents dans l'initramfs
lsinitramfs /boot/initrd.img-$(uname -r) | grep -E 'virtio_(scsi|blk|net)'

# au besoin, sur Debian et derives
echo -e "virtio_scsi
virtio_blk
virtio_net" >> /etc/initramfs-tools/modules
update-initramfs -u -k all

# 2. les montages doivent utiliser des UUID, pas des noms de peripherique
grep -vE '^\s*#' /etc/fstab | grep -E '/dev/(sd|vd|xvd)'

# 3. l'agent VMware laisse la place a l'agent QEMU
apt purge open-vm-tools open-vm-tools-desktop
apt install qemu-guest-agent

05Firmware, EFI et démarrage sécurisé

Une machine amorcée en EFI côté VMware doit l'être aussi côté Proxmox VE. L'assistant d'import reprend en général correctement le type de firmware, mais il faut le vérifier avant le premier démarrage plutôt qu'après.

qm set 101 --bios ovmf --machine q35
qm set 101 --efidisk0 ceph-vm:1,efitype=4m,pre-enrolled-keys=1
qm set 101 --tpmstate0 ceph-vm:1,version=v2.0

06Compte d'import et accès à ESXi

L'assistant d'import se connecte à l'API des hôtes ESXi, pas à vCenter. Sur un parc géré par vCenter, chaque hôte est déclaré séparément comme stockage de type ESXi côté Proxmox VE.

• Créez un compte dédié en lecture sur chaque hôte, plutôt que d'utiliser le compte root. Il sera révoqué en fin de projet, ce qui laisse une trace propre.
• Le mode de verrouillage de l'hôte doit autoriser l'accès à l'API pendant les opérations d'import.
• Les certificats auto-signés sont la norme sur ESXi. L'assistant permet de passer outre la vérification, ce qui est acceptable sur un réseau d'administration cloisonné, et à éviter ailleurs.
• Vérifiez la résolution de nom des hôtes ESXi depuis les noeuds Proxmox VE, et la route entre les deux plateformes.