Pour illustrer ces enjeux, nous avons interroge Julien Morel, administrateur infrastructure dans un groupe industriel multi-sites, un profil representatif que nous avons construit a partir de plusieurs temoignages du secteur. Son nom, son entreprise et certains éléments de contexte sont fictifs : ils servent à décrire un parcours réaliste de migration d’un environnement VMware vSphere vers Proxmox VE après l’évolution du modèle de licences Broadcom.

Julien a piloté, avec une équipe de six personnes, la migration progressive d’un parc de 40 hôtes ESXi et d’environ 620 machines virtuelles vers Proxmox VE. L’environnement initial reposait sur plusieurs clusters vSphere, vCenter, du stockage SAN FC et NFS, ainsi que des sauvegardes pilotées par une solution tierce. Un an après la bascule, l’équipe exploite huit clusters Proxmox VE répartis sur trois sites, avec une stratégie de sauvegarde et de supervision revue en profondeur.

Pourquoi avoir envisagé une sortie de VMware ?

VM Nerds : Quel a été le déclencheur de votre réflexion ?

Julien Morel : Le déclencheur a été la projection budgétaire au renouvellement. Jusqu’alors, VMware était un coût connu, élevé mais prévisible. Avec la transition vers les abonnements par cœur et la disparition de certaines références historiques, notre estimation a augmenté de façon très sensible.

Le sujet n’était pas seulement le montant de la facture. Nous avons aussi constaté une perte de lisibilité : quelles fonctionnalités étaient incluses, quelles options étaient nécessaires pour maintenir les usages existants, quelle granularité de licence s’appliquait à notre matériel, et quelle évolution prévoir sur trois ans ? Pour une DSI, le problème devient rapidement autant opérationnel que financier.

Nous avons donc présenté plusieurs scénarios à la direction : renouveler à périmètre constant, réduire le parc VMware en consolidant certaines charges, ou étudier une plateforme alternative. La consigne n’était pas “sortir de VMware à tout prix”. Elle était de retrouver une trajectoire de coûts maîtrisable, sans dégrader la disponibilité ni imposer un risque excessif aux métiers.

VM Nerds : La hausse du coût de licence a donc été l’unique raison ?

Julien Morel : Non. Elle a été le catalyseur, mais pas l’unique argument. Nous avions accumulé au fil des ans une dépendance importante à un ensemble de composants : vCenter, vSphere, vSAN sur un périmètre limité, des plug-ins de sauvegarde, des workflows d’automatisation et plusieurs procédures très directement liées à l’interface VMware.

Cela représentait un confort réel, mais aussi une forme de dette opérationnelle. Certains gestes étaient devenus tellement spécifiques à l’écosystème que nous ne questionnions plus leur pertinence. La réflexion nous a obligés à revenir aux besoins fondamentaux : exécuter des VM de façon fiable, disposer de haute disponibilité, administrer le stockage, sauvegarder, restaurer et superviser.

Proxmox VE s’est imposé dans l’étude parce que la pile est relativement intégrée, parce qu’elle s’appuie sur des composants connus comme KVM, QEMU, LXC, Ceph et ZFS, et parce que son modèle d’abonnement était plus simple à expliquer. Nous n’avons pas considéré l’open source comme un argument suffisant. Nous avons évalué le produit, le support, les compétences disponibles et la capacité de l’équipe à l’exploiter durablement. Pour aller plus loin, consultez notre dossier complet sur les alternatives à VMware.

Comment la décision a-t-elle été prise ?

VM Nerds : Quels critères avez-vous utilisés pour comparer les plateformes ?

Julien Morel : Nous avons construit une grille avec des critères techniques, financiers et opérationnels. L’erreur aurait été de comparer uniquement une ligne de licence VMware avec une ligne d’abonnement Proxmox. Une migration implique aussi de la formation, du temps d’ingénierie, des changements de procédures, de nouveaux outils de sauvegarde et parfois du matériel différent.

Les critères principaux étaient les suivants :

Nous avons réalisé un pilote sur quatre nœuds, avec un petit cluster Ceph distinct du stockage de production. Le but n’était pas de reproduire tout le datacenter, mais de valider les scénarios qui nous inquiétaient : perte d’un nœud, panne réseau, restauration de VM, comportement des sauvegardes, réseau VLAN, migrations, performances disque et opérations de maintenance.

VM Nerds : Avez-vous remplacé vSAN par Ceph partout ?

Julien Morel : Non, et c’est une décision importante. On voit parfois des projets où Proxmox VE est présenté avec Ceph comme si les deux étaient indissociables. Ce n’est pas le cas. Ceph est très pertinent dans certains contextes, mais il nécessite une architecture réseau, des disques et des pratiques d’exploitation adaptées.

Nous avons conservé notre SAN sur les sites principaux au début de la migration. Cela nous a permis de limiter le nombre de variables qui changeaient simultanément. Sur un site secondaire, où nous devions renouveler une baie vieillissante, nous avons déployé Ceph avec un réseau dédié à 25 Gb/s, des SSD NVMe pour les journaux et métadonnées, et des disques SSD pour les VM les plus sensibles.

Cette approche hybride a été plus réaliste qu’un remplacement généralisé. Elle a aussi permis à l’équipe de monter progressivement en compétence sur Ceph, sans faire reposer toute la production sur une technologie encore nouvelle pour nous.

Quelles ont été les phases de migration ?

VM Nerds : Comment avez-vous structuré un projet de cette ampleur ?

Julien Morel : Nous avons découpé le programme en six phases, avec des jalons techniques et métier très explicites.

La première phase a été l’inventaire. Nous avons recensé les VM, leurs systèmes d’exploitation, leurs dépendances réseau, leurs besoins en sauvegarde, leurs fenêtres de maintenance, leur niveau de criticité et leurs propriétaires applicatifs. Cet inventaire a révélé des surprises : des VM oubliées, des appliances sans documentation, des snapshots anciens, des disques RDM, ainsi que des dépendances à des adresses MAC ou à des règles de pare-feu très spécifiques.

Le témoignage d'une migration menée sur plusieurs mois.
Le témoignage d'une migration menée sur plusieurs mois.

La deuxième phase a été la standardisation de la cible. Avant de migrer, nous avons défini les conventions de nommage, les modèles de VM, les plans réseau, les rôles et droits, les règles de haute disponibilité, les politiques de sauvegarde et les seuils de supervision. C’est moins spectaculaire que la conversion des disques, mais c’est ce qui évite de recréer le désordre initial sur une nouvelle plateforme.

La troisième phase a porté sur le socle Proxmox VE : installation des nœuds, configuration des clusters, stockage, réseau, sauvegarde, supervision et accès d’administration. Nous avons intégré Proxmox Backup Server dans l’architecture dès le départ, plutôt que de le traiter comme un composant secondaire.

La quatrième phase a été le pilote applicatif. Nous avons déplacé des VM non critiques, puis des applications internes avec des propriétaires disponibles pendant les tests. Chaque migration générait une fiche de retour d’expérience : durée, méthode, incident, performance avant/après, sauvegarde et restauration validées.

La cinquième phase a concerné les lots de production. Nous avons regroupé les VM par famille technique et niveau de risque, non pas simplement par site ou par cluster d’origine. Les contrôleurs de domaine, les serveurs de supervision, les services de fichiers, les applications métier et les bases de données ont chacun reçu une méthode de migration spécifique.

Enfin, la sixième phase a été la stabilisation : suppression des ressources VMware devenues inutiles, mise à jour de la documentation, adaptation des procédures d’exploitation et exercices de restauration.

VM Nerds : Quelle méthode de conversion avez-vous le plus utilisée ?

Julien Morel : Pour une grande partie des VM Linux et Windows classiques, nous avons employé une approche par arrêt planifié, export ou copie du disque, puis import dans Proxmox VE. La conversion de format n’est généralement pas le point le plus complexe. Ce qui compte est de préparer l’OS invité.

Un exemple typique était l’import d’un disque VMDK vers un stockage Proxmox :

qm create 1201 --name app-linux-01 --memory 8192 --cores 4 --net0 virtio,bridge=vmbr0
qm importdisk 1201 app-linux-01.vmdk local-lvm
qm set 1201 --scsihw virtio-scsi-single --scsi0 local-lvm:vm-1201-disk-0
qm set 1201 --boot order=scsi0

Mais avant cela, nous vérifiions systématiquement le noyau, les pilotes VirtIO, la configuration réseau persistante, les services dépendants de l’interface réseau, et les mécanismes de licence applicative liés au matériel virtuel.

Pour les VM Windows, le point clé était l’installation préalable des pilotes VirtIO lorsque cela était possible. Sans cela, on peut se retrouver avec une VM qui ne démarre pas après le changement de contrôleur disque. Nous avons également vérifié le comportement des logiciels de sécurité, de sauvegarde et de supervision, qui peuvent considérer le changement de matériel virtuel comme un événement significatif. Pour aller plus loin, consultez le calcul détaillé du coût total de possession.

Quelles difficultés avez-vous rencontrées ?

VM Nerds : La conversion des VM a-t-elle été plus difficile que prévu ?

Julien Morel : Oui, surtout parce que “conversion de VM” recouvre des réalités très différentes. Une VM Linux récente avec un disque VMDK standard et une carte réseau classique se migre généralement sans drame. En revanche, une appliance ancienne, un serveur Windows avec des pilotes particuliers, une VM utilisant des RDM ou un système très dépendant de son identifiant matériel nécessitent une analyse au cas par cas.

Les VM avec snapshots multiples ont posé problème. Nous avons imposé une règle : consolider les snapshots avant migration, sauf justification formelle. Importer une chaîne de disques avec plusieurs niveaux de delta ajoute une complexité inutile et augmente le risque de corruption ou de divergence.

Les appliances éditeur ont également demandé du temps. Certaines étaient officiellement supportées uniquement sur VMware. Dans ces cas, nous n’avons pas forcé la migration. Nous avons soit maintenu temporairement une petite enclave VMware, soit demandé à l’éditeur une position écrite sur KVM, soit remplacé l’appliance lorsqu’une solution était disponible.

VM Nerds : Et sur le réseau ?

Julien Morel : Le réseau est souvent sous-estimé. Dans VMware, les équipes avaient l’habitude des port groups, des vSwitch distribués et de leurs automatismes. Dans Proxmox VE, nous avons choisi une architecture Linux bridge avec VLAN aware sur certains clusters, et Open vSwitch sur d’autres environnements où nous avions des besoins spécifiques.

Le sujet n’était pas de reproduire exactement la terminologie VMware, mais de définir clairement qui configure quoi entre les équipes virtualisation et réseau. Nous avons documenté les bridges, les VLAN, les bonds, les MTU, les réseaux de migration et les réseaux de stockage.

Voici un exemple simplifié de principe de configuration réseau, à adapter au matériel et à l’architecture retenue :

eno1 + eno2  -> bond0     -> trafic administration et VM
eno3 + eno4  -> bond1     -> trafic stockage et migration
bond0        -> vmbr0     -> bridge VLAN aware
bond1        -> vmbr1     -> réseau stockage dédié

Le piège classique est de traiter la migration comme un projet uniquement hyperviseur. En réalité, la cohérence du réseau, du stockage, des sauvegardes et de l’identité est déterminante.

Documenter chaque étape facilite les migrations suivantes.
Documenter chaque étape facilite les migrations suivantes.

VM Nerds : La formation des équipes a-t-elle constitué un frein ?

Julien Morel : C’était probablement le principal risque humain. Les administrateurs VMware expérimentés ont des réflexes, des outils et des repères. Passer à Proxmox VE ne signifie pas repartir de zéro, mais il faut accepter que certains mécanismes changent : le cluster, le stockage, les commandes, les sauvegardes, le dépannage et les responsabilités entre couches.

Nous avons évité la formation uniquement théorique. Chaque administrateur devait réaliser un parcours pratique : création d’un cluster de laboratoire, gestion des réseaux, import d’une VM, configuration de sauvegarde, restauration complète, simulation de panne de nœud et lecture des journaux. L’objectif était de rendre les équipes autonomes sur les incidents courants avant les premières bascules de production.

Nous avons aussi nommé deux référents internes Proxmox VE, sans créer une dépendance à deux personnes. Ils produisaient les standards, animaient les revues de changements et validaient les choix d’architecture. Cela a accéléré l’homogénéisation des pratiques.

Quel bilan un an après la migration ?

VM Nerds : Les objectifs financiers ont-ils été atteints ?

Julien Morel : Oui, mais il faut être précis sur ce que cela signifie. Nous avons réduit le coût récurrent de la plateforme de virtualisation, mais nous avons aussi investi du temps et du budget dans la formation, le support, le matériel de certains clusters et la refonte de la sauvegarde.

Le gain ne s’est donc pas traduit par une économie nette instantanée la première année sur chaque ligne budgétaire. En revanche, nous avons retrouvé une visibilité sur les coûts futurs et réduit notre dépendance à un modèle de licence devenu difficile à anticiper. À partir de la deuxième année, l’écart est devenu plus net.

VM Nerds : La disponibilité est-elle comparable à celle de l’environnement précédent ?

Julien Morel : Sur les workloads migrés, oui, à condition d’avoir correctement conçu l’architecture. Proxmox VE n’est pas une garantie automatique de disponibilité. La haute disponibilité dépend du quorum, du réseau, du stockage, du fencing implicite ou explicite selon le design, et de la qualité des procédures. Pour aller plus loin, consultez l’état de l’art de Proxmox VE.

Nous avons connu quelques incidents, notamment des erreurs de configuration réseau et des comportements inattendus sur le stockage lors des premières mises à jour. Mais aucun n’a remis en cause la plateforme. Ces incidents ont surtout démontré que l’exploitation devait être disciplinée : mises à jour par vagues, validation en préproduction, sauvegardes vérifiées et documentation à jour. Pour aller plus loin, consultez le guide pratique de migration.

La grande amélioration, selon moi, est que nous avons renforcé les exercices de restauration. Avant, nous avions confiance dans notre chaîne de sauvegarde parce qu’elle fonctionnait depuis longtemps. Maintenant, nous mesurons régulièrement le délai réel de restauration et nous testons des scénarios de reprise sur des VM représentatives.

Quels conseils donneriez-vous à une organisation qui envisage cette migration ?

VM Nerds : Quelle est la première erreur à éviter ?

Julien Morel : Penser qu’il s’agit seulement d’un changement d’hyperviseur. Une migration de cette nature touche l’architecture, l’exploitation, les compétences, les contrats éditeurs, les sauvegardes et les habitudes des équipes.

La deuxième erreur serait de promettre une migration complète en quelques semaines. Il est possible de déplacer rapidement certaines VM, mais un parc de plusieurs centaines de charges nécessite une segmentation. Il faut identifier ce qui est simple, ce qui est critique, ce qui est non supporté et ce qui doit être refondu plutôt que déplacé.

VM Nerds : Quelles recommandations concrètes retenez-vous ?

Julien Morel : J’en retiendrais sept :

  1. Faites un inventaire applicatif réel, pas seulement un export vCenter. Identifiez les dépendances, les propriétaires et les contraintes de maintenance.

  2. Construisez un pilote représentatif. Ne validez pas uniquement une VM Linux de test : incluez Windows, une base de données, une application réseau sensible et une restauration.

  3. Ne changez pas toutes les couches en même temps. Si possible, conservez temporairement un stockage connu pendant la bascule hyperviseur, ou inversement.

  4. Préparez les systèmes invités. Pilotes VirtIO, agents invités, configuration réseau, logiciels de sécurité et licences applicatives doivent être vérifiés avant la fenêtre de migration.

  5. Concevez la sauvegarde avant la production. Une VM qui démarre n’est pas une VM migrée tant que sa sauvegarde et sa restauration ne sont pas validées.

  6. Formez l’équipe par la pratique. Les compétences Linux, réseau et stockage prennent davantage de poids dans l’exploitation quotidienne.

  7. Acceptez une coexistence temporaire. Garder une petite capacité VMware pendant la période de transition peut être plus sûr que forcer la migration d’une appliance non supportée.

Notre résultat un an après n’est pas une plateforme parfaite ni une démonstration idéologique. C’est un environnement plus maîtrisé, mieux documenté et économiquement plus prévisible. Pour nous, la migration a été réussie parce qu’elle a été traitée comme un programme de transformation d’infrastructure, pas comme une opération de conversion de fichiers VMDK.