De plus en plus d’organisations envisagent de migrer de VMware ESXi vers Proxmox VE à la suite des changements récents dans le modèle de licences introduits par Broadcom. Cependant, le transfert de machines virtuelles entre ces deux plateformes va bien au-delà de la simple conversion d’un fichier VMDK ou de l’importation d’une machine virtuelle. La différence entre une migration planifiée et une migration improvisée peut se traduire par plusieurs heures de downtime, des écrans bleus, des systèmes Linux incapables de démarrer ou des pertes de performance difficiles à diagnostiquer.

Les clés pour une migration réussie de VMware vers Proxmox VE en 20 secondes

• Migrer une VM ne consiste pas uniquement à convertir des disques ; cela implique également de changer d’hyperviseur, de pilotes et d’architecture d’entrée/sortie.
• Windows et Linux doivent être préparés avant l’arrêt définitif dans VMware pour éviter des problèmes de démarrage.
• Le stockage, le réseau et les pilotes VirtIO sont parmi les points les plus sensibles lors de la transition.
• Tester l’ensemble du processus en laboratoire et disposer de sauvegardes vérifiées réduit considérablement les risques en environnement de production.

La bonne nouvelle est que Proxmox VE offre une plateforme mature basée sur des technologies ouvertes telles que KVM, QEMU, Linux et ZFS. La moins bonne est que cette flexibilité exige également de comprendre comment ces composants interagissent. Ce guide rassemble les recommandations techniques principales pour minimiser les risques lors d’une migration.

La migration ne se limite pas à copier un disque virtuel

Une idée reçue courante est de penser qu’il suffit d’éteindre une machine virtuelle dans VMware ESXi, de convertir le disque VMDK et de l’importer dans Proxmox VE.

En réalité, ce processus modifie plusieurs composants fondamentaux :

• l’hyperviseur passe de VMware ESXi à KVM ;
• le matériel virtuel présenté au système d’exploitation change ;
• les pilotes de stockage et réseau sont différents ;
• la gestion du stockage évolue ;
• les mécanismes de snapshots et de sauvegarde sont modifiés.

Si le système d’exploitation invité n’est pas préparé à ces changements, des erreurs de démarrage peuvent survenir immédiatement après la migration.

Dans les environnements Windows, il est fréquent de rencontrer l’erreur connue INACCESSIBLE_BOOT_DEVICE (0x0000007B) lorsque le système tente de démarrer avec un pilote qui n’existe plus.

Dans les distributions Linux basées sur Red Hat, Rocky Linux, AlmaLinux ou SUSE, un symptôme courant est une chute sur la console d’urgence de dracut, car l’initramfs ne contient pas les modules nécessaires pour accéder au nouveau disque.

Préparer Windows avant d’éteindre la machine virtuelle

Une bonne pratique consiste à préparer le système d’exploitation pendant que la VM fonctionne encore sous VMware.

Parmi les vérifications courantes figurent :

Dans de nombreuses migrations, le service viostor est également configuré pour démarrer automatiquement en modifiant le registre Windows.

Linux doit reconstruire l’initramfs

Sur les systèmes Linux, le problème se trouve généralement dans l’initramfs.

Avant l’arrêt définitif, il est conseillé de le régénérer en y intégrant les modules VirtIO nécessaires à KVM.

Sous les distributions basées sur RHEL, on peut utiliser une commande similaire à :

dracut --add-drivers "virtio_blk virtio_scsi virtio_net virtio_pci" --force

Il est également recommandé de vérifier :

• la présence des modules VirtIO ;
• la suppression des composants VMware obsolètes ;
• l’installation du paquet qemu-guest-agent.

Les outils diffèrent selon la distribution. Debian, Ubuntu ou SUSE disposent de procédures spécifiques, il est donc important de suivre la documentation officielle adaptée.

Le stockage est plus critique qu’il n’y paraît

La conversion de disque s’effectue généralement avec des outils comme :

qemu-img convert -f vmdk -O raw origine.vmdk destination.raw

Mais cette étape ne suffit pas en soi.

La performance finale dépendra de la configuration du backend de stockage dans Proxmox VE.

Si vous utilisez ZFS

Il est important d’étudier attentivement certains paramètres tels que :

• volblocksize
• ashift
• compression
• ARC

Particulièrement pour les bases de données, une mauvaise configuration du volblocksize peut considérablement augmenter le phénomène connu sous le nom de Write Amplification, ce qui réduit la performance.

De plus, sur des serveurs avec beaucoup de mémoire, il est courant de limiter la consommation d’ARC à l’aide de paramètres comme zfs_arc_max, afin d’éviter de concurrencer la mémoire allouée aux VM.

Si vous utilisez Ceph

Dans les environnements basés sur Ceph RBD, il est souvent recommandé d’activer le support TRIM et discard pour mieux récupérer l’espace disque.

Les configurations courantes comprennent des options telles que :

• discard=on
• issue_discards=1

Ces réglages dépendent du type de stockage et de la version utilisée.

Le réseau virtuel évolue aussi

Un autre aspect souvent sous-estimé est la configuration réseau.

Dans VMware, on retrouve fréquemment :

• vSwitch Standard
• vSwitch distribué (vDS)
• Groupes de ports
• VLAN Trunk

Alors que dans Proxmox VE, les principales options sont :

• Linux Bridge
• Open vSwitch (optionnel)
• Proxmox SDN
• VXLAN
• EVPN

Reproduire la configuration visuelle ne suffit pas.

Il faut également vérifier des aspects tels que :

• MTU
• VLAN tagging
• Bonding
• LACP
• Jumbo Frames

Un simple désalignement entre MTU 9000 et MTU 1500 peut provoquer des pertes intermittentes difficiles à diagnostiquer.

N’oubliez pas les sauvegardes

Un autre changement essentiel concerne la protection des données.

Chez VMware, de nombreuses organisations utilisent VMware VADP avec des solutions de sauvegarde tierces.

Dans Proxmox VE, l’intégration est différente et repose généralement sur Proxmox Backup Server (PBS), qui offre notamment :

• des sauvegardes incrémentielles via QEMU’s Dirty Bitmaps
• la déduplication par blocs variables
• la compression
• le chiffrement
• la vérification automatique de l’intégrité des copies

Avant une migration, il est conseillé de vérifier que la stratégie de sauvegarde couvre toujours les mêmes objectifs de récupération (RPO et RTO).

Liste de vérification avant de démarrer la migration

Avant de planifier une fenêtre de maintenance, il est utile de passer en revue au moins les points suivants :

Migrer, c’est aussi changer la gestion de l’infrastructure

Une erreur fréquente consiste à croire que quitter VMware réduit uniquement le coût des licences.

En réalité, cette économie est aussi souvent liée à une montée en compétence technique : maîtriser une plateforme ouverte requiert un savoir-faire spécifique.

Gérer efficacement Proxmox VE implique de se familiariser avec des technologies telles que :

• Linux
• QEMU/KVM
• ZFS
• Ceph
• Réseaux Linux
• Automation
• Haute disponibilité

Pour beaucoup d’organisations, cela représente un avantage, car cela élimine la dépendance à des logiciels propriétaires. Cependant, cela exige également de disposer de personnel formé ou de faire appel à un prestataire spécialisé durant la transition.

Questions fréquentes

L’importation d’un VMDK suffit-elle pour migrer une machine virtuelle ?

Non. En plus du disque virtuel, il faut vérifier les pilotes, la configuration du système d’exploitation, le réseau, le stockage et les outils d’intégration avec le nouvel hyperviseur.

Tous les systèmes Windows nécessitent-ils l’installation de pilotes VirtIO ?

Dans la majorité des cas, oui. Les préparer avant la migration réduit considérablement les risques d’erreurs de démarrage liées à l’accès au disque.

Que faire si Linux ne contient pas les modules VirtIO dans l’initramfs ?

Le système peut ne pas détecter le disque au démarrage, ce qui peut conduire à une console de récupération comme dracut ou à un initramfs d’urgence, selon la distribution.

Proxmox VE propose-t-il des outils de sauvegarde comparables à ceux de VMware ?

Oui. Proxmox Backup Server offre des sauvegardes incrémentielles, la déduplication, la compression, le chiffrement et la vérification de l’intégrité, bien que son fonctionnement diffère de l’écosystème VMware.

Important à noter

Ce guide est exclusivement d’ordre technique et informatif. Chaque infrastructure possède ses caractéristiques propres liées au matériel, aux versions de VMware ESXi, Proxmox VE, au système d’exploitation invité, au stockage et aux applications déployées.

Les configurations, commandes et paramètres évoqués sont des exemples courants et ne doivent pas être considérés comme valides dans tous les contextes. Avant toute migration en environnement de production, il est fortement conseillé de réaliser une validation en laboratoire, de disposer de sauvegardes vérifiées et de suivre la documentation officielle de VMware, Proxmox, QEMU, Microsoft, Red Hat, SUSE, Debian, Ubuntu, ZFS, Ceph, et de tous les autres fabricants impliqués.

Enfin, des paramètres comme volblocksize, zfs_arc_max, discard, issue_discards ou la configuration des pilotes VirtIO doivent être ajustés en fonction de la charge de travail, de l’architecture du stockage et des recommandations spécifiques de chaque plateforme. La responsabilité de ces opérations et de leurs conséquences incombe exclusivement de l’administrateur ou de l’organisation qui les exécute.