Tu as fait tes calculs après la hausse des licences Broadcom (voir notre article sur VMware, Hyper-V ou Azure Local : comment décider) et tu as choisi Proxmox VE. Bonne nouvelle : la décision est la partie difficile. La migration technique, elle, suit un chemin bien balisé — à condition de connaître les pièges avant de t’y engager plutôt qu’en plein milieu d’un weekend de bascule.
Ce guide te donne la checklist de préparation, les deux méthodes de migration officielles, et ce qu’il ne faut surtout pas oublier après le transfert.
Proxmox VE en bref : ce que tu gagnes (et ce que tu perds)
Proxmox VE reste open source et gratuit à l’usage — aucune licence n’est requise pour faire tourner l’hyperviseur en production. Ce que tu payes, c’est le support et l’accès au dépôt Enterprise (mises à jour testées en profondeur avant diffusion) :
- Community — 120 €/an par socket CPU, accès au dépôt Enterprise, support communautaire uniquement (forum)
- Basic — 370 €/an par socket CPU, 3 tickets/an, réponse sous 1 jour ouvré
- Standard — 550 €/an par socket CPU, 10 tickets/an, réponse sous 4h, support 24/7
- Premium — 1 100 €/an par socket CPU, tickets illimités, réponse sous 2h, support 24/7
Toutes les fonctionnalités de Proxmox VE sont identiques quel que soit le niveau choisi — seul le support technique varie. Même au niveau Standard, l’écart avec une licence VMware post-Broadcom reste massif. Le détail des tarifs est sur la page pricing officielle de Proxmox.
Ce que tu perds en changeant d’écosystème : l’intégration native avec vCenter/NSX si tu es dessus, et l’écosystème de plugins tiers construit spécifiquement pour VMware — à vérifier au cas par cas selon tes outils de supervision, sauvegarde et automatisation actuels.
Avant de migrer : la checklist de préparation
La documentation officielle Proxmox est claire sur les points qui bloquent une migration propre si tu ne les anticipes pas :
- Retire les outils invités spécifiques à VMware (VMware Tools) avant la migration — c’est plus difficile à faire proprement une fois la VM basculée.
- Documente ta configuration réseau, en particulier les IP statiques : les cartes réseau sont recréées côté Proxmox et devront être reconfigurées.
- Vérifie les disques chiffrés : un disque chiffré via une Storage Policy VMware ne peut pas être importé tel quel. Le vTPM n’est pas non plus repris automatiquement — à traiter avant la bascule si tu en dépends.
- Éteins les VM sources avant l’import pour garantir la cohérence des données.
- Note que les snapshots ralentissent significativement l’import — supprime les snapshots inutiles sur les VM VMware avant de lancer la migration.
La migration pas à pas
Méthode 1 — Import automatisé (recommandée)
Depuis Proxmox VE, l’import direct depuis un hôte ESXi (versions 6.5 à 8.0) est intégré à l’interface web : tu ajoutes ton serveur ESXi comme source, Proxmox liste les VM disponibles, et l’import mappe automatiquement la majorité de la configuration (CPU, RAM, disques). Il existe aussi un mode d’import « à chaud » qui permet de démarrer la VM pendant que le transfert des disques se termine en arrière-plan, au prix d’une performance disque réduite le temps du transfert.
Pour les migrations en masse, limite-toi à 4 disques de VM importés en parallèle maximum — au-delà, tu risques de saturer les connexions API de l’hôte ESXi source.
Méthode 2 — Import manuel
Si l’import automatisé n’est pas adapté à ton cas (version ESXi non supportée, contraintes réseau, etc.), plusieurs alternatives existent :
- Restauration depuis backup — si ta solution de sauvegarde actuelle a un connecteur Proxmox
- Clonage disque à disque avec un outil comme Clonezilla
- Import OVF via l’interface graphique ou en ligne de commande
- Import direct du disque avec la commande
qm importdisk:
# Convertit et importe un disque VMDK vers le stockage Proxmox
qm importdisk <ID_VM> /chemin/vers/disque.vmdk <nom_stockage>
# Puis attache le disque importé à la VM depuis l'interface
# (Matériel > Ajouter > Disque dur > sélectionner le disque non utilisé)
La documentation officielle détaille chaque méthode avec ses cas d’usage précis sur le wiki Proxmox — Migrate to Proxmox VE et le wiki dédié à la migration de serveurs.
Après la migration : ce qu’il ne faut pas oublier
- Installe les pilotes VirtIO — indispensable sur les VM Windows pour de bonnes performances disque et réseau, et parfois nécessaire pour que la VM démarre correctement après conversion.
- Reconfigure les interfaces réseau avec les IP statiques documentées avant la migration.
- Ajuste le mode BIOS/UEFI pour qu’il corresponde à l’environnement source : SeaBIOS pour le mode legacy, OVMF pour l’UEFI — un mauvais choix ici empêche simplement la VM de démarrer.
Et pour la sauvegarde, une fois sur Proxmox ?
Proxmox Backup Server (PBS) est le complément naturel — sauvegardes incrémentales dédupliquées, chiffrement côté client, et intégration directe avec Proxmox VE. Quel que soit l’outil choisi, garde en tête les principes qu’on détaille dans notre article sur la règle 3-2-1-1-0 face aux ransomwares : une nouvelle plateforme de virtualisation ne dispense jamais d’une vraie stratégie de sauvegarde immuable et testée.
FAQ
Combien de temps dure une migration VMware vers Proxmox ?
Ça dépend surtout du volume de données à transférer et de ta bande passante de stockage, pas du nombre de VM. Prévois un test sur un sous-ensemble non critique avant de planifier une fenêtre de bascule pour la production.
Est-ce que je peux migrer sans interruption de service ?
L’import « à chaud » de Proxmox permet de redémarrer la VM rapidement pendant que le disque continue de se copier en arrière-plan, avec une pénalité de performance temporaire. Pour un zéro-downtime strict, une réplication applicative reste plus fiable qu’un import d’hyperviseur.
Proxmox gère-t-il le vMotion ou équivalent ?
Oui, la migration à chaud entre nœuds d’un même cluster Proxmox existe nativement et fonctionne de façon comparable à vMotion, à condition d’avoir du stockage partagé ou répliqué entre les nœuds.
En bref
Une migration VMware vers Proxmox réussie tient surtout à la préparation : nettoyer les outils invités, documenter le réseau, traiter les cas particuliers (chiffrement, snapshots) avant de lancer l’import plutôt qu’en pleine bascule. Commence par un import test sur une VM non critique, valide ta checklist post-migration, puis passe à l’échelle progressivement plutôt que de basculer tout ton cluster en une seule fenêtre.

Laisser un commentaire