01Trois voies, et comment choisir
| Voie | Quand la choisir | Fenêtre d'arrêt | Limites |
|---|---|---|---|
| Assistant ESXi | Cas général, ESXi 6.5 à 8 | Durée de la copie | Ni vSAN, ni disque chiffré |
| Import à chaud | Fenêtre d'arrêt très courte | Quelques minutes | Performance dégradée pendant la copie |
| OVF ou qemu-img | Ce que l'assistant refuse, plateformes isolées | Copie plus export | Configuration à réécrire à la main |
En pratique, sur les migrations que nous menons, environ quatre machines sur cinq passent par l'assistant, une sur dix par l'import à chaud pour des raisons de fenêtre, et le reste par la voie manuelle.
02L'assistant d'import ESXi
Le principe est élégant : l'hôte ESXi est déclaré comme un stockage de type ESXi côté Proxmox VE. Le paquet dédié expose le contenu des datastores à travers un système de fichiers en espace utilisateur, lit les fichiers de configuration VMX, et traduit ce qu'il peut vers le modèle de configuration de Proxmox VE : processeurs, mémoire, disques, cartes réseau, type de firmware. Rien n'est modifié côté VMware, l'assistant se contente de lire.
# interface : Centre de donnees > Stockage > Ajouter > ESXi # en ligne de commande, equivalent : pvesm add esxi esxi-01 \ --server esxi-01.exemple.fr \ --username import@esxi \ --password \ --skip-cert-verification 1 # les machines de l'hote apparaissent alors dans ce stockage pvesm list esxi-01
L'import se lance ensuite depuis l'interface, machine par machine. La fenêtre affiche la configuration proposée avant de valider : c'est le moment de corriger le stockage cible, le pont réseau et l'étiquette VLAN, en s'appuyant sur la table de correspondance du chapitre précédent. Trois réglages méritent une attention particulière à cet écran.
- Le stockage cible de chaque disque, qui n'est pas nécessairement le même pour le disque système et pour un gros volume de données.
- Le pont et l'étiquette VLAN de chaque carte, l'assistant ne pouvant pas deviner votre plan.
- Le type de processeur exposé, à choisir cohérent sur tout le cluster pour ne pas interdire la migration à chaud entre noeuds.
Les disques portés par vSAN ne sont pas lisibles ; déplacez-les d'abord vers un autre datastore. Les disques chiffrés par une politique de stockage doivent être déchiffrés côté VMware. Un nom de datastore contenant un caractère spécial peut faire échouer l'accès. Enfin, une machine porteuse d'instantanés s'importe nettement plus lentement : consolidez-les avant, systématiquement.
03L'import à chaud et ses limites
L'option d'import à chaud change complètement le profil de la fenêtre d'arrêt. La machine source doit être éteinte côté ESXi, mais Proxmox VE démarre immédiatement la machine cible et va chercher les blocs à la demande pendant que la copie se poursuit en arrière plan. Le service revient en quelques minutes au lieu d'attendre la fin du transfert.
Le temps d'arrêt est réduit, il n'est pas supprimé : la source doit bien être éteinte. Et pendant toute la durée de la copie, les accès disque de la machine passent par le lien vers ESXi, donc les performances sont dégradées. C'est excellent pour un serveur applicatif ordinaire, discutable pour une base de données sollicitée. Si la machine ne démarre pas tout de suite, on peut la relancer sans interrompre la copie en cours.
Notre règle de choix : import à chaud lorsque la fenêtre d'arrêt négociée est plus courte que la durée de copie estimée, import à froid partout ailleurs. Un import à froid reste plus simple à diagnostiquer si quelque chose se passe mal.
04OVF, OVA et conversion manuelle
Pour ce que l'assistant ne sait pas lire, ou lorsque les deux plateformes ne se voient pas sur le réseau, la voie manuelle reste parfaitement viable. Elle demande simplement d'écrire la configuration soi-même.
# export depuis un hote ESXi avec ovftool, machine eteinte ovftool --noSSLVerify \ vi://import@esxi-01.exemple.fr/SRV-APP-01 \ /srv/export/SRV-APP-01.ovf # import du descripteur : cree la machine et importe les disques qm importovf 101 /srv/export/SRV-APP-01.ovf ceph-vm --format raw
# viser le descripteur .vmdk, pas le fichier -flat.vmdk qemu-img info SRV-APP-01.vmdk # conversion vers le stockage, -p affiche la progression qm disk import 101 SRV-APP-01.vmdk ceph-vm --format raw # variante hors Proxmox VE, vers un fichier qemu-img convert -p -f vmdk -O raw SRV-APP-01.vmdk /var/tmp/srv-app-01.raw
Un disque VMware est décrit par un petit fichier .vmdk texte qui pointe vers un
gros fichier -flat.vmdk. Convertir directement le fichier plat produit une image
incohérente sur les disques à plusieurs extensions. Visez toujours le descripteur, et vérifiez
avec qemu-img info avant de lancer une conversion de plusieurs heures.
05Les réglages après import
Une machine importée démarre souvent du premier coup, mais avec une configuration qui ne tire rien de la plateforme. Ces réglages ne sont pas des raffinements : ils conditionnent les performances disque, la sauvegarde cohérente et l'arrêt propre.
# controleur disque moderne, une file par disque qm set 101 --scsihw virtio-scsi-single # disque : liberation d'espace, profil SSD, file dediee qm set 101 --scsi0 ceph-vm:vm-101-disk-0,discard=on,ssd=1,iothread=1 # ordre de demarrage explicite qm set 101 --boot order=scsi0 # carte reseau VirtIO sur le bon VLAN, adresse MAC reprise de la source qm set 101 --net0 virtio=00:50:56:A1:B2:C3,bridge=vmbr1,tag=110 # agent invite, indispensable pour l'arret propre et la sauvegarde qm set 101 --agent enabled=1,fstrim_cloned_disks=1 # type de systeme, il conditionne des optimisations internes qm set 101 --ostype win11 # ou l26 pour un Linux recent # identifiant SMBIOS repris, pour les licences qui s'y accrochent qm set 101 --smbios1 uuid=421f8b2c-9e4d-4a17-b3c8-7d2e6f0a1b45
| Réglage | Pourquoi | Si on l'oublie |
|---|---|---|
discard=on | Rend l'espace supprimé au stockage | Le pool se remplit sans raison |
iothread=1 | Une file d'entrées-sorties par disque | Contention sur les machines actives |
agent enabled=1 | Arrêt propre, sauvegarde cohérente | Sauvegardes à chaud moins fiables |
ostype | Optimisations propres au système | Performances en retrait sur Windows |
| Type de processeur | Compatibilité entre noeuds | Migration à chaud refusée |
| Ballon mémoire | Souplesse d'allocation | Mémoire figée, marge N+1 réduite |
Ces commandes sont toujours les mêmes. Un script qui les applique à partir de l'inventaire supprime la principale source d'erreur d'une migration en volume : l'oubli d'un réglage sur une machine parmi cent. Nous générons ce script depuis le fichier d'inventaire, et il produit aussi la trace de ce qui a été appliqué à chaque machine.
06Débit, durée et parallélisme
L'import lit à travers l'API de l'hôte ESXi, ce qui plafonne le débit bien en dessous de ce que laisserait espérer le lien réseau. Trois conséquences pratiques.
- Mesurez sur la vague pilote et extrapolez à partir de ce chiffre. Un volume total divisé par un débit théorique donne un calendrier faux.
- Deux ou trois imports en parallèle par hôte ESXi au maximum. Au-delà, le débit total n'augmente plus et l'hôte source, qui fait encore tourner de la production, se met à souffrir.
- Surveillez la cible autant que la source. Une vague d'imports écrit massivement sur le stockage partagé. Sur Ceph, regardez les latences de validation des OSD pendant l'opération : c'est le moment où l'on découvre qu'une marge était trop juste.
Tant que la recette n'est pas prononcée, la machine source reste en place, éteinte. C'est le plan de repli le plus efficace qui existe, et il ne coûte que de l'espace disque. La suppression intervient au décommissionnement, traité au chapitre 05, jamais le jour de la bascule.
Une migration VMware a cadrer, a executer ou a securiser
Nous accompagnons les sorties de VMware vers Proxmox VE, du cadrage et de l'audit de l'existant jusqu'a la recette et a la formation des equipes. Nous intervenons aussi en renfort ponctuel sur les lots les plus sensibles d'une migration deja engagee.