Migration VMware vers Proxmox VE : guide technique pour PME et ETI

Migration VMware vers Proxmox VE : guide technique pour PME et ETI

Le rachat de VMware par Broadcom fin 2023 a entraîné une restructuration brutale des licences. Fin des licences perpétuelles, passage obligatoire aux abonnements annuels par socket CPU (VCF ou vSphere Foundation), arrêt de plus de 50 solutions et partenariats revendeurs : lors du renouvellement, de nombreuses PME et ETI ont constaté des hausses de coût de 2 à 10 fois selon leur configuration. Pour certaines, le coût annuel d'une infrastructure de 4 hôtes ESXi a dépassé celui d'un projet de remplacement complet.

Proxmox VE est devenu l'alternative open source la plus étudiée. Mais avant de décider, il faut comprendre ce que la migration implique techniquement — et notamment répondre à la question que pose tout administrateur VMware : peut-on faire un vMotion vers Proxmox ? Quels arrêts de service prévoir ? Quelles fonctionnalités n'ont pas d'équivalent ?

Cet article s'adresse aux DSI, responsables infrastructure et administrateurs systèmes. Son objectif : un état des lieux technique honnête, sans biais dans un sens ou dans l'autre.

Salle serveur et infrastructure virtualisée

Proxmox VE : ce que c'est vraiment

Proxmox VE n'est pas un substitut low-cost. C'est une plateforme de virtualisation complète, basée sur Debian Linux, déployée en production par des hébergeurs, des universités et des entreprises gérant plusieurs milliers de VMs.

Ce qui en fait une alternative crédible à vSphere :

• Hyperviseur KVM natif : même technologie que AWS EC2 (via la couche Nitro, dérivée de KVM) et GCP Compute Engine. À noter : Microsoft Azure repose sur Hyper-V, non sur KVM — une nuance importante si votre benchmark inclut les clouds Microsoft.
• Clustering intégré sans licence additionnelle : HA automatique, live migration de VMs entre nœuds d'un même cluster Proxmox, et migration de stockage à chaud (Storage Migration). Ces fonctionnalités nécessitent vCenter sous VMware — un poste de coût en plus.
• Interface web unifiée : gestion des VMs, containers LXC, snapshots, sauvegardes PBS, accès console — tout dans une interface unique, sans client lourd.
• Subscription optionnelle, mais à comprendre : Proxmox VE est utilisable sans abonnement. Sans subscription, l'accès est limité aux dépôts communautaires (pve-no-subscription), stables mais sans mises à jour enterprise ni accès au support officiel Proxmox Server Solutions. L'abonnement (à partir de 95 €/an par nœud) débloque les dépôts enterprise, les correctifs de sécurité prioritaires et le support.
• Proxmox Backup Server (PBS) : solution de sauvegarde dédiée, open source, avec déduplication côté client, chiffrement AES-256, et sauvegardes incrémentales via dirty-bitmap QEMU. PBS est souvent la première chose qui surprend positivement les équipes venant de VMware.
• Import depuis VMware : Proxmox VE 8.2 (avril 2024) a introduit un assistant d'import expérimental depuis vSphere/ESXi directement dans l'interface web. La conversion manuelle via qemu-img reste la méthode de référence pour les migrations complexes.

Pas de vMotion VMware → Proxmox : les méthodes réelles

C'est la première question que pose tout architecte VMware, et elle mérite une réponse directe.

Non, il n'existe pas de vMotion natif entre VMware et Proxmox. Le vMotion est un protocole propriétaire VMware qui ne fonctionne qu'entre hôtes ESXi gérés par vCenter. Proxmox dispose de sa propre mécanisme de live migration KVM (au sein d'un cluster Proxmox), mais ces deux systèmes sont architecturalement incompatibles pour une migration à chaud cross-hyperviseur.

Toute migration VMware → Proxmox implique un arrêt de service, sauf dans le scénario de réplication préalable qui réduit la coupure à quelques minutes. Voici les méthodes disponibles :

Migration à froid (cold migration)

Méthode la plus courante pour les VMs non critiques ou avec une tolérance à l'arrêt :

1. Consolidation de tous les snapshots VMware avant export (impératif : une chaîne de snapshots non consolidée produit un VMDK composite difficile à convertir)

2. Arrêt propre de la VM sur l'hôte ESXi

3. Export au format OVF/OVA via vSphere Client, ou accès direct aux fichiers VMDK sur le datastore (NFS ou SSH)

4. Conversion du disque : qemu-img convert -f vmdk -O qcow2 source.vmdk destination.qcow2

5. Import dans Proxmox via qm importdisk ou l'interface web

6. Ajustement de la configuration VM (firmware BIOS ou UEFI, contrôleur de bus SCSI/VirtIO, interface réseau)

7. Injection des drivers VirtIO si la VM est Windows (voir section dédiée)

8. Démarrage et validation des performances et de la connectivité réseau

Points d'attention sur la conversion VMDK :

• Les VMDKs fragmentés (split en fichiers de 2 Go) peuvent être convertis directement par qemu-img qui gère la réassemblage automatiquement
• Les disques thin-provisioned restent thin après conversion en qcow2 ; les thick eager-zeroed peuvent être convertis en raw ou qcow2 avec allocation forcée selon les besoins de performance
• La durée dépend de la taille des disques et du débit réseau/stockage : compter entre 30 minutes et plusieurs heures pour des disques de plusieurs centaines de Go

Migration à chaud avec réplication préalable (warm migration)

Pour minimiser la coupure sur des VMs plus critiques :

1. Mise en place d'une réplication régulière de la VM VMware vers Proxmox (via Veeam B&R v12.1 avec cible Proxmox, ou via PBS avec agent dans la VM source)

2. Synchronisations différentielles répétées jusqu'à la fenêtre de bascule

3. Arrêt de la VM source, synchronisation finale du delta résiduel (quelques Go maximum si la réplication est récente)

4. Démarrage de la VM restaurée sur Proxmox et validation

5. Reconfiguration du DNS/IP si nécessaire

Coupure effective : de 5 à 30 minutes selon la taille du delta final et la vitesse du réseau.

Import via l'assistant Proxmox VE 8.2+

Depuis Proxmox VE 8.2 (avril 2024), un assistant expérimental permet d'importer directement des VMs depuis un hôte ESXi standalone ou vCenter via l'API VMware, sans export manuel préalable. L'assistant automatise la récupération des métadonnées VM et la conversion des disques. Il reste marqué "experimental" et couvre mal les scénarios avec configurations réseau complexes ou VMs Windows nécessitant des drivers spécifiques. À valider systématiquement sur un environnement de test avant usage en production.

Ce que la migration implique techniquement

1. L'audit d'inventaire : avant toute chose

Sans inventaire précis, on avance à l'aveugle. Ce qu'il faut documenter :

• Inventaire complet des VMs : vCPU, vRAM, taille des disques, type de provisioning (thin/thick), firmware (BIOS ou UEFI), OS et version
• Criticité et tolérance à l'arrêt de chaque VM
• Dépendances réseau : VLANs, groupes de ports vSphere Standard ou Distribués, règles NSX-T, pare-feu distribué
• Outils dépendants de l'API vSphere : scripts PowerCLI, jobs de sauvegarde, solutions de monitoring (vROps, Zabbix via VMware integration, Datadog)
• Licences OS Windows : certaines licences OEM ou SPLA sont liées à l'hyperviseur et peuvent nécessiter une révision contractuelle

2. Les drivers VirtIO sur Windows : étape critique

Les VMs Windows sous VMware utilisent les drivers PVSCSI (contrôleur de stockage haute performance) et VMXNET3 (réseau). Sous Proxmox avec KVM, les équivalents sont les drivers VirtIO (virtio-scsi pour le stockage, virtio-net pour le réseau).

Sans injection de drivers VirtIO avant migration, une VM Windows importée peut :

• Ne pas démarrer du tout (contrôleur de stockage non reconnu, BSOD 0x0000007B)
• Démarrer en mode dégradé avec les drivers IDE génériques (performances 3 à 5 fois inférieures aux drivers VirtIO)

La méthode recommandée : installer les drivers VirtIO avant l'arrêt de la VM sur VMware, en montant l'ISO VirtIO officielle (fournie par le projet Fedora/Red Hat, compatible avec toutes les versions Windows depuis Windows XP). Les VMs Linux n'ont généralement pas ce problème car les modules VirtIO sont intégrés dans le noyau depuis longtemps.

3. La reconfiguration réseau : le poste de travail le plus sous-estimé

VMware et Proxmox ont des modèles réseau différents. Voici la correspondance :

• vSwitch Standard → Linux bridge (vmbr0, vmbr1...) : correspondance directe, relativement simple
• vSwitch Distribué (vDS) → Linux bridge avec trunk VLAN ou OVS (Open vSwitch) : nécessite une reconfiguration manuelle sur chaque nœud
• NSX-T overlay / VXLAN / micro-segmentation → Pas d'équivalent natif dans Proxmox. OVS permet une partie des fonctionnalités VLAN avancées, mais les règles de pare-feu distribué NSX-T doivent être portées vers iptables/nftables ou vers une solution externe (OPNsense, pfSense en VM dédiée)
• LACP / Bond : supporté sous Linux avec bond ou OVS LACP — reconfiguration requise

La refonte réseau peut représenter 30 à 50 % du temps total d'un projet de migration dans les environnements avec des VLAN multiples ou NSX.

4. La stratégie par lots

Ne migrez pas simultanément. Une séquence typique :

• Lot 1 : Environnements dev et test — validation complète de la procédure, mesure des performances, identification des problèmes réels avant de toucher à la production
• Lot 2 : Services internes à faible criticité (AD secondaires, serveurs de fichiers non critiques)
• Lot 3 : Applications métier avec tolérance à une coupure planifiée (fenêtre maintenance week-end)
• Lot 4 : Production critique — avec procédure de retour arrière documentée et testée, fenêtre formalisée

Conserver l'infrastructure VMware opérationnelle le temps de valider chaque lot est non négociable pour des environnements en production.

Migration par étapes et validation de serveurs

Sauvegardes : Veeam et Proxmox Backup Server

Veeam Backup & Replication v12.1 (décembre 2023) a officiellement ajouté le support de Proxmox VE comme plateforme managée. Sauvegarde, restauration granulaire et réplication de VMs Proxmox sont disponibles dans les éditions Community (gratuit, 10 VMs max) et les éditions Enterprise.

Proxmox Backup Server (PBS) est la solution native : open source, déduplication côté client, chiffrement AES-256-GCM, sauvegardes incrémentales via dirty-bitmap QEMU (équivalent du CBT VMware), et restauration granulaire fichier par fichier. Pour les environnements purement Proxmox, PBS offre une solution complète et sans coût de licence.

Point d'attention : si votre stratégie de sauvegarde actuelle repose sur le Changed Block Tracking (CBT) VMware intégré à vCenter, le mécanisme équivalent côté Proxmox est le dirty-bitmap QEMU. La compatibilité outil par outil doit être vérifiée avant migration.

Stockage : ZFS et Ceph, sans alarmisme

ZFS ARC utilise de la RAM pour le cache disque, mais ce comportement est entièrement configurable via le paramètre zfs_arc_max dans /etc/modprobe.d/zfs.conf. Une pratique courante : réserver 8 à 16 Go d'ARC sur un hôte avec 64 Go de RAM, ou 1 à 4 Go pour des charges légères. ZFS ARC libère la mémoire sous pression des VMs — ce n'est pas une fuite mémoire, c'est du cache dynamique. Il faut simplement le paramétrer consciemment, et non le laisser en configuration par défaut sur un hôte très chargé.

Ceph apporte un stockage distribué redondant comparable fonctionnellement à vSAN. Il nécessite au minimum 3 nœuds, des disques dédiés (SSD NVMe recommandés pour les journaux WAL/DB), et un réseau dédié à faible latence entre nœuds. La configuration initiale est plus complexe que vSAN, mais les performances et la résilience sont comparables pour des charges standard.

VMFS (le système de fichiers VMware) n'a pas d'équivalent dans Proxmox — et ce n'est pas nécessaire. Proxmox utilise ext4, XFS, ZFS ou un stockage Ceph/RBD selon le cas d'usage.

Fonctionnalités VMware sans équivalent direct dans Proxmox

Être précis sur ce point est essentiel pour une décision éclairée :

• NSX-T / NSX : micro-segmentation, pare-feu distribué, overlays VXLAN, politiques réseau centralisées — aucun équivalent intégré dans Proxmox. OVS couvre une partie des besoins VLAN avancés, mais les fonctionnalités NSX avancées nécessitent une refonte architecture ou des solutions tierces.
• HCX (Hybrid Cloud Extension) : outil VMware de migration live entre on-premise et cloud public (VMC on AWS, Azure VMware Solution, Google Cloud VMware Engine). Aucun équivalent natif dans Proxmox.
• vCenter à grande échelle : la gestion centralisée multi-cluster de vCenter, avec ses politiques de ressources DRS, ses tags, ses alarmes et ses workflows vRO, est plus mature pour les très grands environnements (plusieurs centaines d'hôtes). L'interface Proxmox gère bien jusqu'à quelques dizaines de nœuds.
• vRO / Aria Automation : orchestration et automatisation avancées, intégration ITSM, gestion du cycle de vie des VMs — sans équivalent intégré dans Proxmox. Le provider Terraform Proxmox (communautaire) et Ansible couvrent les besoins d'automatisation courants, mais avec moins de maturité.
• Support constructeur formalisé : Dell, HPE, Cisco et la plupart des grands constructeurs certifient leurs matériels pour vSphere et fournissent des plugins de gestion intégrés (Dell OpenManage Integration for vCenter, HPE iLO Amplifier Pack). Proxmox s'appuie sur la compatibilité Linux standard — les matériels récents fonctionnent bien, mais sans plugins constructeur dédiés.
• Certifications réglementaires : vSphere dispose de certifications Common Criteria, FIPS 140-2 et FedRAMP importantes pour certains secteurs réglementés (défense, santé aux États-Unis). Proxmox n'a pas ces certifications formelles.

Ces limites ne disqualifient pas Proxmox pour la majorité des PME et ETI — elles indiquent que les environnements avec des dépendances fortes sur ces fonctionnalités ont un coût de migration plus élevé ou doivent revoir leur architecture réseau et d'automatisation.

VMware vs Proxmox : comparaison équilibrée

Par où commencer

La première question n'est pas "comment migrer" mais "est-ce que Proxmox est adapté à mon contexte". Ce n'est pas toujours le cas.

Un environnement fortement dépendant de NSX-T, vSAN ou HCX a des coûts de migration significatifs qu'il faut chiffrer honnêtement avant de décider. Un environnement soumis à des certifications réglementaires spécifiques VMware doit vérifier sa compatibilité. À l'inverse, une PME ou ETI avec 10 à 200 VMs, peu de dépendances NSX, et un parc Windows/Linux standard a généralement les conditions requises pour une migration Proxmox réussie.

Un bon point de départ : un audit d'exposition couvrant l'inventaire des VMs, les dépendances réseau et applicatives, les outils de sauvegarde actuels, les compétences Linux disponibles en interne, et les contraintes réglementaires éventuelles. À partir de là, on peut estimer la charge réelle, identifier les lots par criticité, et définir un calendrier qui ne met pas la production en danger.

Chez AXIIZ, on accompagne les PME et ETI sur ce type de projet : audit d'exposition, scénarios comparés avec coûts chiffrés, migration par lots avec procédures de retour arrière documentées, formation des équipes internes. 20 ans d'expérience infrastructure. Zéro junior.