Aller au contenu

Semaine 5 — Migrer une VM de VMware ESXi vers Proxmox

Prérequis : Sauvegarder une VM et la remettre en place

Exercices associés : Exercice 1 — Remettre Cyclo-Nord en service · Exercice 2 — Importer les VM de Cycles Pignon Sud

Objectifs d'apprentissage

  • Expliquer pourquoi une entreprise quitte VMware ESXi et ce qu'une migration doit préserver.
  • Décrire les fichiers d'une VM VMware et leur équivalent dans Proxmox.
  • Choisir le matériel virtuel d'une VM importée, et dire pourquoi le changer peut l'empêcher de démarrer.
  • Importer une VM depuis un hôte ESXi et lister ce que Proxmox reprend et ce qu'il laisse de côté.
  • Dresser la liste des ajustements à faire dans la VM après l'import.

1. Le problème : un hyperviseur devenu trop cher

Cyclo-Nord vient de racheter Cycles Pignon Sud, un concurrent de la Rive-Sud. Le site web et le serveur de fichiers de Pignon Sud tournent sur un hôte VMware ESXi, dans une petite salle sous l'escalier. La licence est échue, et la renouveler coûterait plus cher que les deux serveurs eux-mêmes.

Cyclo-Nord n'est pas un cas isolé. En 2023, Broadcom a racheté VMware et remplacé les licences perpétuelles par des abonnements. Pour beaucoup de PME, la facture a changé d'ordre de grandeur du jour au lendemain, et la question « comment sortir de VMware ? » est devenue très concrète.

Une migration réussie, c'est une VM qui redémarre ailleurs avec ses données, ses services et son rôle. Le matériel virtuel autour d'elle, lui, peut et doit changer.

2. Ce qu'est une VM VMware

Une VM VMware est un dossier dans un datastore, l'équivalent d'un stockage Proxmox. Voici celui de srv-web :

Texte
/vmfs/volumes/datastore1/srv-web/
├── srv-web.vmx          la configuration
├── srv-web.vmdk         le descripteur du disque, quelques lignes de texte
├── srv-web-flat.vmdk    le contenu du disque
├── nvram                l'état du BIOS
└── vmware.log           le journal de la dernière exécution

Le .vmx joue le rôle du fichier de configuration de Proxmox. C'est un fichier texte, une ligne par réglage :

INI
guestOS = "other6xlinux-64"
memSize = "512"
scsi0.virtualDev = "pvscsi"
scsi0:0.fileName = "srv-web.vmdk"
ethernet0.virtualDev = "vmxnet3"
ethernet0.networkName = "Publique (VLAN 460)"

Le .vmdk est le disque. Il vient en deux morceaux : un petit descripteur qui décrit la géométrie, et un fichier -flat qui contient les données, bloc pour bloc.

La plupart des notions se retrouvent d'un côté comme de l'autre, sous un autre nom :

VMware ESXi Proxmox VE
datastore stockage (local-lvm, local)
srv-web.vmx /etc/pve/qemu-server/404.conf
srv-web.vmdk volume vm-404-disk-0
vSwitch + groupe de ports avec un VLAN bridge vmbr0 + étiquette VLAN sur la carte
VMware Tools (open-vm-tools sous Linux) qemu-guest-agent
Host Client, sur https://<hôte> interface web, sur le port 8006

Un groupe de ports (port group) est un nom donné à un ensemble de ports du vSwitch, avec un numéro de VLAN. La VM ne connaît que ce nom : Publique (VLAN 460). Ce nom n'a aucun sens pour Proxmox, et c'est une des choses que vous aurez à retraduire.

3. Le matériel virtuel suit la VM

Une VM ne voit jamais le vrai matériel du serveur. Elle voit un matériel imaginaire, fabriqué par l'hyperviseur : un contrôleur de disque, une carte réseau, un BIOS. Le système d'exploitation de la VM a installé des pilotes pour ce matériel-là, et pour lui seul.

Chaque hyperviseur a son propre matériel paravirtualisé, conçu pour aller vite :

Rôle Chez VMware Chez Proxmox (QEMU/KVM)
Contrôleur de disque pvscsi (VMware Paravirtual) VirtIO SCSI
Carte réseau vmxnet3 VirtIO
Outils invités VMware Tools qemu-guest-agent

Paravirtualisé veut dire que le pilote sait qu'il parle à un hyperviseur et non à une vraie carte. Il échange des blocs de données directement avec l'hyperviseur, sans imiter les registres d'un vrai composant. C'est beaucoup plus rapide qu'un matériel émulé à l'ancienne, comme une carte e1000.

QEMU sait imiter pvscsi et vmxnet3. Une VM importée sans aucun changement démarre donc sur Proxmox. Mais c'est un matériel de compatibilité, moins testé et moins performant que VirtIO. Le but d'une migration propre est de passer en VirtIO.

Quand le changement de matériel casse le démarrage

Changer le contrôleur de disque, c'est retirer le disque d'un contrôleur pour le brancher sur un autre. Si le système n'a pas de pilote pour le nouveau, il ne trouve plus son propre disque au démarrage et s'arrête.

  • Linux a presque toujours les pilotes VirtIO dans son noyau et dans son initramfs, l'image de démarrage qui monte le disque. Le changement se fait sans préparation.
  • Windows n'a aucun pilote VirtIO de base. Changer le contrôleur sans les avoir installés d'avance donne un écran bleu INACCESSIBLE_BOOT_DEVICE. La méthode consiste alors à importer d'abord en SATA, à installer les pilotes VirtIO, puis à basculer.

Quand le changement de carte réseau casse le réseau

Une nouvelle carte réseau peut porter un nouveau nom. Debian et Ubuntu nomment les cartes d'après leur position sur le bus PCI : une carte vmxnet3 s'appelle souvent ens192 sous VMware, et la carte VirtIO de Proxmox ens18. Le fichier de configuration réseau parle encore d'ens192, qui n'existe plus : la VM démarre sans réseau.

Alpine, le système des VM de Pignon Sud, garde le nom eth0 quelle que soit la carte. Ce problème ne se posera pas dans l'exercice, mais il se posera sur la moitié des VM Linux que vous migrerez un jour.

4. Les chemins pour sortir d'ESXi

Chemin Principe Quand l'utiliser
Stockage ESXi dans Proxmox Proxmox se connecte à l'hôte ESXi, lit ses VM et copie leurs disques l'hôte ESXi est encore joignable : le cas normal
Export OVA / OVF VMware produit une archive, déposée ensuite dans Proxmox l'hôte n'est pas joignable depuis Proxmox, ou la VM voyage sur un disque
Copie du .vmdk + qm disk import le disque est copié à la main, puis attaché à une VM créée d'avance dernier recours, quand les deux autres échouent

Le premier chemin existe depuis Proxmox VE 8.2. C'est celui des exercices : aucun fichier intermédiaire, aucun disque transporté deux fois.

L'assistant d'import

L'hôte s'ajoute dans Datacenter > Storage > Add > ESXi, avec son adresse et un compte. Le nouveau stockage liste les VM de l'hôte. Un clic sur Import ouvre un assistant en trois onglets.

  • General : l'identifiant, le nom, la mémoire, les cœurs, et le stockage et le bridge qui recevront la VM.
  • Advanced : le contrôleur de disque, chaque disque, et chaque carte réseau avec son modèle, son bridge et son VLAN Tag.
  • Resulting Config : la configuration Proxmox qui sera écrite, à relire avant de cliquer sur Import.

Proxmox lit le .vmx et le traduit du mieux qu'il peut :

Proxmox reprend Proxmox ne reprend pas
la mémoire, les cœurs, le type de système le VLAN : le nom du groupe de ports n'a aucun sens ici
les disques, avec leur taille la configuration réseau à l'intérieur de la VM
les adresses MAC les outils invités, qui restent ceux de VMware
le contrôleur pvscsi et la carte vmxnet3, tels quels

La dernière ligne de gauche est le point essentiel : par défaut, Proxmox garde le matériel VMware. C'est à vous de choisir VirtIO dans l'onglet Advanced.

Important

La VM doit être éteinte sur l'hôte ESXi pendant l'import. Si elle tourne, l'assistant affiche Virtual guest seems to be running on source host. Un disque copié pendant que le système écrit dedans arrive dans un état incohérent, exactement comme une sauvegarde prise sans précaution.

La case Live Import démarre la VM sur Proxmox tout de suite et copie les disques en arrière-plan. L'interruption de service est plus courte, mais si l'import échoue en cours de route, tout ce que la VM a écrit depuis son démarrage est perdu. Elle se réserve aux machines dont chaque minute d'arrêt coûte cher.

5. Après l'import : ce qui reste à faire dans la VM

L'import a déplacé la machine. Il n'a rien changé à ce qu'elle croit savoir de son réseau. Une VM migrée demande toujours le même tour de vérification.

  1. Le réseau. L'adresse, la passerelle et le DNS d'avant ne valent plus rien dans le nouveau VLAN. Ils se réécrivent dans la configuration de la VM.
  2. Les outils invités. Les VMware Tools cherchent un hyperviseur VMware qui n'existe plus. Ils se remplacent par qemu-guest-agent, et l'option QEMU Guest Agent de la VM s'active dans Proxmox.
  3. Tout ce qui dépend de l'ancienne adresse. Un partage NFS autorisé pour l'ancien sous-réseau, une règle de pare-feu, un enregistrement DNS, un certificat : la VM fonctionne, mais plus personne n'y a accès.
  4. Le stockage ESXi. Proxmox garde le mot de passe de l'hôte en clair dans /etc/pve/priv/storage/. Le stockage se retire une fois l'import terminé.

Le troisième point est le plus souvent oublié. Il ne produit aucune erreur au démarrage, seulement un service qui refuse ses clients.

Pièges fréquents

  • Accepter les valeurs par défaut de l'assistant. La VM démarre en pvscsi et vmxnet3, personne ne s'en rend compte, et elle tourne pour des années sur un matériel de compatibilité plus lent et moins testé que VirtIO.
  • Oublier le VLAN Tag. L'assistant ne peut pas le deviner. Sans lui, la carte tombe dans le VLAN natif du câble, c'est-à-dire le réseau de gestion.
  • Importer une VM allumée. L'import réussit, et le système de fichiers arrive abîmé.
  • Laisser les outils VMware. Ils ne cassent rien, mais Proxmox n'affiche aucune adresse IP et ne peut pas geler le système de fichiers pendant une sauvegarde.
  • Reconfigurer l'adresse et s'arrêter là. Le serveur répond au ping, et son service refuse tout le monde parce qu'il n'autorise encore que l'ancien réseau.

Vérification des acquis

Question 1

Vous importez une VM Windows Server depuis ESXi et vous choisissez VirtIO SCSI dans l'onglet Advanced. Elle affiche un écran bleu INACCESSIBLE_BOOT_DEVICE au démarrage. Pourquoi ?

  • a) Le disque a été abîmé pendant la copie depuis l'hôte ESXi.
  • b) Windows n'a pas de pilote pour le contrôleur VirtIO SCSI, donc il ne trouve plus son propre disque.
  • c) Proxmox ne sait pas lire le format .vmdk des VM Windows.
Voir la réponse **b) Windows n'a pas de pilote pour le contrôleur VirtIO SCSI, donc il ne trouve plus son propre disque.** Le disque est intact. Il est simplement branché sur un contrôleur que Windows ne sait pas piloter. Il faut importer d'abord sur un contrôleur que Windows connaît (SATA), installer les pilotes VirtIO, puis basculer. Le choix a) est tentant parce que l'écran bleu fait penser à une panne de disque. Mais une VM Linux importée de la même façon démarre sans problème : la différence vient des pilotes, pas de la copie.

Question 2

Une VM Debian importée démarre sans réseau. Son fichier de configuration parle d'ens192, et ip link affiche une carte ens18. Que s'est-il passé ?

  • a) La carte réseau a changé de modèle, et Debian l'a nommée d'après sa nouvelle position sur le bus PCI.
  • b) L'assistant d'import a oublié de copier la carte réseau.
  • c) Le VLAN Tag est mal réglé, donc la carte ne reçoit aucune trame.
Voir la réponse **a) La carte réseau a changé de modèle, et Debian l'a nommée d'après sa nouvelle position sur le bus PCI.** Debian nomme les cartes selon leur emplacement. La carte `vmxnet3` de VMware et la carte VirtIO de Proxmox n'occupent pas la même position, donc le nom change. Il suffit de remplacer `ens192` par `ens18` dans la configuration. Le choix c) produirait une carte présente, mais sans trafic. Ici, la carte n'est même pas configurée, puisque le fichier parle d'une interface qui n'existe plus.

Question 3

Après l'import, pourquoi Proxmox n'ajoute-t-il pas de lui-même l'étiquette VLAN que la VM avait sous ESXi ?

  • a) Parce que Proxmox ne gère les VLAN que sur les VM créées chez lui.
  • b) Parce que la VM ne connaissait que le nom d'un groupe de ports, et que ce nom n'existe pas dans Proxmox.
  • c) Parce que l'étiquette VLAN est stockée dans le disque, que Proxmox ne lit pas.
Voir la réponse **b) Parce que la VM ne connaissait que le nom d'un groupe de ports, et que ce nom n'existe pas dans Proxmox.** Le `.vmx` contient `ethernet0.networkName = "Publique (VLAN 460)"`. Le numéro de VLAN est une propriété du groupe de ports, sur l'hôte ESXi, pas de la VM. Proxmox n'a donc aucun numéro à reprendre, et c'est à vous de choisir le VLAN de destination. Le choix c) confond le contenu du disque et la configuration de la VM. Le disque contient le système invité ; le branchement réseau se décide dans l'hyperviseur, d'un côté comme de l'autre.

Question 4

Vous avez déplacé un serveur NFS dans un nouveau sous-réseau et corrigé son adresse. Il répond au ping, mais les clients reçoivent access denied by server. Quelle est la cause la plus probable ?

  • a) Le pare-feu bloque le port 2049.
  • b) Le fichier /etc/exports n'autorise encore que l'ancien sous-réseau.
  • c) Le service NFS ne redémarre pas après une migration.
Voir la réponse **b) Le fichier `/etc/exports` n'autorise encore que l'ancien sous-réseau.** Le message vient du serveur lui-même : il a reçu la demande, l'a lue, et l'a refusée. C'est le comportement d'un export qui ne reconnaît pas l'adresse du client. Le choix a) donnerait un autre symptôme : un pare-feu qui bloque ne répond rien du tout, et le client attend jusqu'à l'expiration du délai. Un refus explicite prouve que le paquet est bien arrivé.

Pour aller plus loin