Migration VMware vers Proxmox : méthodes, commandes et outils

La réponse en bref. Pour migrer de VMware ESXi vers Proxmox, utilisez l’assistant d’import intégré si la source est compatible. Sinon, préparez un export OVF/VMDK ou une conversion avec virt-v2v. Commencez par une VM pilote : vérifiez démarrage, application, réseau et restauration. Planifiez l’arrêt de la source et la reprise des données avant de basculer le reste du parc.

Pour utiliser ce guide. Commencez par le choix de méthode et les points à reconstruire. Pour préparer une intervention, utilisez ensuite le cas chiffré, la recette métier et le cahier pratique. Les commandes concernent des versions à qualifier dans votre environnement.

Sommaire

Comment migrer VMware vers Proxmox ?

Choisissez selon l’accès à la source, l’état du système et l’arrêt acceptable. Le nombre de VM vient ensuite.

Import direct depuis ESXi

Dans Proxmox, ouvrez Datacenter → Storage → Add → ESXi, renseignez l’hôte et les accès, puis sélectionnez une VM dans la source et cliquez sur Import. Choisissez le stockage cible et le bridge réseau. Préférez une connexion directe à l’hôte ; passer par vCenter peut ralentir le transfert. Procédure Proxmox.

Relevez auparavant CPU, RAM, disques, BIOS/UEFI et réseaux. Une correspondance de configuration ne prouve pas que l’application fonctionne : testez aussi ses dépendances, licences et traitements planifiés.

Ce qui doit être reconstruit autour de la VM

Importer les disques ne déplace pas toute l’exploitation. Le guide de Veeam sur la continuité de migration attire utilement l’attention sur les dépendances et la protection pendant la coexistence. Pour votre projet, transformez chaque dépendance en vérification :

Cette grille est une proposition de recette. Pour la haute disponibilité, la supervision et le placement des VM, vérifiez les fonctions de votre version et la façon dont votre organisation les exploitera. Chacune demande sa propre configuration et sa propre validation.

Écrire la correspondance réseau avant l’import

Un bridge relie la carte virtuelle au réseau disponible sur l’hôte. Un VLAN sépare des réseaux logiques ; le numéro seul ne garantit pas que le trafic circule jusqu’au bon réseau physique. La documentation réseau Proxmox décrit notamment bridges et configurations VLAN.

Exemple fictif à faire valider par l’exploitant réseau :

Ne basculez pas tous les serveurs en DHCP pour contourner un problème d’interface. Cela modifierait aussi les dépendances. Une carte détectée par l’OS ne prouve ni le bon VLAN ni le fonctionnement du DNS.

Préparer Windows, Linux et les cas sensibles

Le tutoriel NAKIVO montre un parcours Windows Server 2022 avec configuration de la VM puis rattachement des disques. Il aide à visualiser les étapes, mais ses réglages correspondent à son environnement. Pour le vôtre, choisissez le contrôleur à partir des pilotes réellement disponibles.

Windows. Relevez BIOS/UEFI, contrôleur de stockage, état du chiffrement et carte réseau. Prévoyez une console et les pilotes compatibles avec la version de Windows. Testez leur chargement avant d’utiliser VirtIO pour le disque de démarrage. Si vous passez provisoirement par un contrôleur déjà reconnu, validez chaque changement séparément. Le retrait de VMware Tools dépend du parcours choisi ; ne désinstallez pas un composant dont votre méthode a encore besoin.

Linux. Vérifiez le montage des volumes, les identifiants utilisés dans fstab, les interfaces attendues et les modules nécessaires au démarrage. L’initramfs est l’environnement initial qui permet notamment d’accéder au disque système. Un disque correctement copié peut rester impossible à démarrer si cet environnement ne reconnaît pas le contrôleur cible. Configuration des VM Proxmox, adaptation des invités avec virt-v2v.

Un contrôleur de domaine ne se traite pas comme une VM bureautique

Microsoft documente des mécanismes spécifiques à Active Directory autour du VM-Generation ID. Ils ne rendent pas sûre la remise en ligne de deux copies possédant la même identité. Définissez un parcours AD adapté, contrôlez la réplication et prévoyez une restauration compatible ; n’appliquez pas aveuglément le retour d’une VM autonome à un annuaire. Architecture des contrôleurs de domaine virtualisés.

Pour une base transactionnelle, un cluster applicatif, un disque partagé ou un périphérique transmis directement à la VM, faites préciser le parcours par l’exploitant et l’éditeur. Une migration de service vers une nouvelle VM peut être préférable à une conversion intégrale.

Chiffrement : distinguez le disque VMware et le chiffrement dans l’invité. Avant de modifier un TPM virtuel, Secure Boot ou un protecteur de disque, identifiez les mécanismes en jeu et vérifiez la disponibilité des moyens de récupération. Testez le redémarrage sur une copie. Une recette qui demande de déchiffrer un disque doit être évaluée et encadrée pour votre environnement ; ce n’est pas une étape universelle à exécuter par réflexe.

Combien d’espace prévoir pour exporter et convertir ?

Il faut distinguer capacité virtuelle, espace réellement alloué, taille exportée et espace temporaire. Un stockage de fichiers et un stockage de blocs ne proposent pas les mêmes formats ; QCOW2 n’est donc pas une destination universelle. La documentation de stockage Proxmox permet de vérifier les fonctions du stockage retenu.

Exemple de dimensionnement fictif pour un espace de travail : export mesuré à 180 Go, fichier converti prévu à 240 Go, tous deux présents simultanément. Le pic prévu est 420 Go. Avec une réserve de 60 Go choisie pour cet exemple, il faut 480 Go disponibles dans cet espace, en plus des besoins distincts du stockage final. Cette réserve n’est pas un pourcentage recommandé par Proxmox. Mesurez les fichiers du pilote et incluez extraction OVA, journaux, snapshots éventuels et croissance.

Avant l’import, ces commandes d’inventaire se lancent sur le nœud cible ; elles ne créent ni ne suppriment de VM :

pveversion -v
pvesm status
qm list

Conservez les versions, le nom exact du stockage et sa capacité disponible. Un stockage affiché actif ne prouve pas qu’il accepte le format souhaité. Pour un espace temporaire de fichiers, contrôlez aussi le système de fichiers qui le porte. Vérifiez les options avec l’aide de votre version de pvesm et qm avant les commandes de modification.

Restaurer depuis une sauvegarde : vérifier le parcours précis

La restauration vers un autre hyperviseur est une méthode possible lorsque le produit et ses versions la prennent en charge. Veeam publie une matrice Proxmox, plug-in et serveur de sauvegarde. Ne confondez pas « protéger des VM Proxmox », « restaurer une VM VMware vers Proxmox » et « récupérer un fichier » : ce sont des opérations différentes.

Demandez une preuve sur une VM représentative, la liste des limites et le chemin de sauvegarde après bascule. Un démarrage temporaire depuis un dépôt de sauvegarde peut nécessiter une finalisation sur le stockage de production ; vérifiez cette étape dans votre produit. La source ne peut être retirée simplement parce que la VM cible a démarré.

Quelles commandes pour importer OVF, OVA ou VMDK ?

Ces exemples se lancent dans le shell du nœud Proxmox cible, avec les droits nécessaires. Prévoyez une sauvegarde restaurable et un export cohérent réalisé VM arrêtée. Adaptez les chemins et le stockage ; local-lvm doit exister et disposer de l’espace nécessaire. 900 doit être libre pour l’import OVF ; 901 doit être réservé puis utilisé par la VM vide de l’exemple VMDK. Les deux exemples sont des alternatives.

Importer une VM exportée en OVF

OVF décrit la configuration ; les VMDK contiennent les disques. Conservez ensemble tous les fichiers de l’export, puis lancez :

qm importovf 900 \
  /mnt/import/serveur.ovf \
  local-lvm
qm config 900

La première commande crée la VM et importe ses disques. La seconde affiche sa configuration. Avant démarrage, vérifiez carte réseau, contrôleur, firmware et ordre de démarrage. L’OVF ne restitue pas tous les paramètres VMware. Documentation de l’import OVF.

Une OVA regroupe ces fichiers dans une archive. Selon votre version, utilisez l’import OVA de l’interface ou extrayez son contenu dans un répertoire dédié avant d’importer l’OVF.

Importer un disque VMDK seul

Créez d’abord une VM cible vide, sans disque, avec les ressources et le mode BIOS/UEFI de la source. Pour cette VM, ici 901 :

qm disk import 901 \
  /mnt/import/serveur.vmdk \
  local-lvm
qm config 901

Le disque apparaît comme Unused Disk / unusedX. Dans Hardware, attachez-le au contrôleur adapté ; dans Options → Boot Order, sélectionnez le disque système. Répétez l’import pour les autres disques en respectant leur rôle.

Utilisez le VMDK descripteur avec les fichiers qu’il référence, notamment -flat.vmdk s’il existe. Un fichier isolé dans une chaîne de snapshots ne constitue pas forcément l’état complet de la VM. Import de disque Proxmox.

Faut-il convertir en QCOW2 avant ? L’import peut effectuer la conversion. --format qcow2 concerne les stockages de fichiers compatibles ; ne l’ajoutez pas systématiquement à un import vers LVM-thin ou ZFS.

Convertir avec virt-v2v

Sur une machine Linux de conversion, avec virt-v2v installé et un répertoire de sortie existant :

virt-v2v -i ova \
  /mnt/import/serveur.ova \
  -o local -os /mnt/converti \
  -of qcow2

Contrairement à une simple conversion de format, virt-v2v peut adapter le système invité à KVM et préparer ses pilotes. Les fichiers produits, généralement nom-sda, nom-sdb, doivent ensuite être transférés vers Proxmox, importés et attachés. Cette commande ne crée pas la VM Proxmox. Les pilotes Windows nécessaires doivent être disponibles pour la conversion. Manuel virt-v2v.

L’entrée peut aussi provenir d’un VMX ou d’une connexion VMware. Les transports ont leurs propres prérequis ; VDDK ajoute notamment des bibliothèques VMware. La VM source doit être arrêtée pendant la conversion. Entrées VMware de virt-v2v.

Automatiser après avoir validé le pilote

Un outil de traitement par lots devient utile lorsque plusieurs VM partagent une méthode déjà testée. Il ne remplace pas la vérification de chaque application. Pour le sélectionner, relevez sa version, ses droits, ses prérequis, les étapes journalisées et le comportement après interruption. Validez une VM isolée, puis un petit lot.

Le choix d’un projet communautaire demande une revue de sa documentation et de sa maintenance au moment du déploiement. Évitez de retenir un outil sur la seule promesse de migrer « en un clic ».

Quelles limitations peuvent bloquer la migration ?

Les restrictions d’import figurent dans le guide de migration. Pour le démarrage et les contrôleurs, consultez la documentation des VM Proxmox. Le guide réseau aide à préparer les correspondances de bridges et VLAN. Ces symptômes orientent le diagnostic ; ils ne donnent pas une cause certaine.

Migrer depuis ESXi 5.5 : quelle méthode choisir ?

La documentation Proxmox consultée mentionne une plage testée de 6.5 à 8.0 pour cet assistant. Ce n’est pas une matrice exhaustive des versions disponibles aujourd’hui. Pour 5.5 ou une autre version hors de cette plage, validez l’import en laboratoire ; étudiez ensuite export, conversion ou restauration.

Distinguez l’hyperviseur et le système invité. Mettre ESXi à jour ne corrige pas Windows ou Linux. Relevez correctifs, pilotes et dépendances ; testez les mises à jour requises sur une copie. Le dernier pilote VirtIO n’est pas forcément compatible avec un ancien Windows. Si l’application exige un système obsolète, prévoyez sa modernisation : cas de Windows Server 2012/R2.

Basculer en trois étapes

1. Tester. Importer une copie isolée, vérifier l’application et restaurer une sauvegarde sur la cible.
2. Migrer. Geler les écritures, transférer l’état final et valider le service avant réouverture.
3. Confirmer. Contrôler sauvegardes, supervision et traitements avant de retirer la source.

Une migration « live » ne garantit pas zéro arrêt. Le live-import natif demande l’arrêt de la source, puis peut démarrer la cible pendant la copie. Mesurez l’indisponibilité du service jusqu’à sa validation métier, pas seulement le temps de transfert.

Après réouverture, l’ancienne VM ne contient pas les nouvelles écritures. Définissez qui peut annuler la bascule et comment récupérer ces données. Un annuaire ou une base transactionnelle demande une procédure adaptée. Isolez les copies pour éviter adresses identiques et traitements en double.

Préparer une VM pilote : un exemple rempli

Objectif : décider si une bascule est prête, avec des preuves. Ce cas fictif concerne une application de devis sur une VM unique. Ce n’est pas une procédure pour un contrôleur de domaine ou une base distribuée. Le responsable de l’application doit adapter les tests à son service.

RTO désigne l’objectif de durée de reprise ; RPO, la perte de données maximale tolérée, exprimée en durée. Pour une migration planifiée, décrivez aussi les transactions à préserver. « RPO nul » demande un gel effectif des écritures et un transfert final cohérent, pas seulement une copie récente.

Calculer une fenêtre réaliste

Dans ce scénario, il reste 240 Go à transférer, avec un débit utile mesuré de 80 Mo/s pendant le pilote. En unités décimales : 240 × 1 000 ÷ 80 = 3 000 secondes, soit 50 minutes. Le débit utile inclut ici les limites du stockage et du réseau ; ce n’est pas la vitesse annoncée de la carte réseau.

Ajoutons 10 minutes pour geler le service, 15 pour démarrer la cible et 20 pour la recette métier : 95 minutes. La fenêtre de 120 minutes laisse 25 minutes. Si l’abandon et la reprise sur la source demandent 30 minutes, la fenêtre est insuffisante. Il faut modifier la méthode, réduire le volume final ou obtenir une fenêtre plus longue, puis mesurer à nouveau.

Ce calcul illustre un transfert à froid. Une conversion, une extraction OVA ou un second transfert ajoutent des étapes. Ne cumulez pas arbitrairement leurs durées si elles se déroulent en parallèle : chronométrez le parcours réellement retenu.

Valider le service avant de rouvrir les accès

Fixez les résultats attendus avant le pilote. Voici une recette illustrative à adapter, sans données clients réelles dans les exemples :

La répétition générale permet de tester la restauration avant la bascule. Après la bascule réelle, contrôlez aussi la sauvegarde de la nouvelle production et ses possibilités de reprise. Ne retirez pas la source tant que ces contrôles et les traitements différés n’ont pas été acceptés.

On reporte si la restauration n’a pas été démontrée, si un parcours métier indispensable échoue, si les versions ne sont pas qualifiées ou si la fenêtre ne permet plus un abandon maîtrisé. Ces critères sont une proposition de méthode ; le décideur doit les valider pour son contexte.

Exercice : faut-il rouvrir le service ?

La VM démarre. L’utilisateur se connecte. Il ne peut plus produire le PDF d’un devis. Il reste 15 minutes dans la fenêtre ; le retour testé prend 25 minutes. L’administrateur propose de laisser les utilisateurs reprendre et de corriger ensuite.

Corrigé. La recette métier échoue et la réserve d’abandon est déjà dépassée. Garder les accès fermés, informer le décideur et appliquer le scénario de reprise convenu ; aucune option ne tient désormais dans la fenêtre initiale sans arbitrage. Le pilote doit avoir révélé la dépendance manquante et conduit à placer le point de décision plus tôt. Une connexion réussie n’est pas une preuve de service rendu.

Fiche à réutiliser pour votre première VM

Copiez cette trame dans votre ticket de changement. Une case vide sur une condition bloquante doit conduire à clarifier le point avant de lancer la bascule.

Service / propriétaire métier / exploitant :
Versions source, cible, OS et application :
Disques, firmware, pilotes et réseaux :
Dépendances et isolation du pilote :
Méthode testée / version de l’outil / journal :
Gel des écritures / état final à transférer :
Volume / débit mesuré / durée de chaque étape :
Fenêtre autorisée / réserve de reprise / heure limite de décision :
Tests métier / résultat attendu / résultat observé / preuve :
Sauvegarde restaurée / durée / périmètre / limites :
Abandon avant réouverture / traitement des écritures après réouverture :
Décideur / résultat / date / conditions de retrait de la source :

Le cahier pratique : pilote, exercice et fiche vierge reprend ces étapes sur trois pages imprimables. Il sert à préparer la migration ; les commandes de l’article restent à tester sur vos versions.

Télécharger la fiche modifiable au format texte.

Questions fréquentes

Combien coûte une migration VMware vers Proxmox ?

Additionnez audit + pilote + transfert + stockage + sauvegarde + exploitation + coexistence temporaire. Comparez sur une même durée et un même niveau de service. Vérifiez les conditions de souscription Proxmox pour votre matériel ; un outil gratuit ne supprime pas le travail de validation.

Peut-on conserver matériel et sauvegardes ?

Vérifiez compatibilité, capacité et restauration avec les versions utilisées. Gardez l’accès aux anciennes sauvegardes VMware pendant leur rétention ; leur lecture peut exiger de conserver un logiciel ou une licence.

Que préparer pour choisir la méthode ?

Inventaire hôtes/VM, versions des OS, taille des disques, réseaux, sauvegardes et arrêt acceptable. Ajoutez une liste des dépendances métier. Ces éléments permettent de cadrer un plan de migration avec Initial Infra.

Pour préparer le pilote, retrouvez notre méthode de test des sauvegardes et notre guide de segmentation par VLAN.

Révision pédagogique du 27 septembre 2026. Documentation Proxmox (dépôt officiel) et manuel virt-v2v revérifiés à cette date. Les cas, durées et résultats chiffrés sont fictifs. Les commandes sont documentées, mais n’ont pas été exécutées sur un hyperviseur pour cet article.

Guide approfondi le 27 septembre 2026. Les documentations liées permettent de vérifier les particularités de vos versions ; le cahier pratique accompagne le premier pilote.