Migrer de VMware vers Proxmox au Maroc : méthode, outils et pièges

Une migration de VMware vers Proxmox se réussit avant le premier import : inventaire complet du parc, sauvegarde testée, stockage cible décidé, outils VMware retirés des machines. Le transfert lui-même est devenu simple grâce à l’assistant d’import intégré à Proxmox VE. Ce qui fait échouer un projet, ce sont les dépendances oubliées, un stockage mal choisi et l’absence de retour arrière. Voici la méthode que nous appliquons au Maroc pour les PME qui quittent VMware, en tant que partenaire Proxmox.

Pourquoi tant d’entreprises au Maroc quittent VMware

Depuis le rachat de VMware par Broadcom, les conditions de licence ont profondément changé : fin de la vente des licences perpétuelles, passage à des offres par abonnement regroupées, nouveaux interlocuteurs commerciaux. Pour beaucoup de PME, le renouvellement devient une décision à reprendre à zéro, et non plus une simple formalité.

Proxmox VE est la plateforme que nous déployons le plus souvent en remplacement. Elle est open source, sans licence par fonctionnalité, et réunit dans une même interface la virtualisation, la haute disponibilité, le stockage distribué Ceph et la sauvegarde. Le support éditeur est vendu par abonnement annuel par processeur physique occupé, avec accès au dépôt Enterprise.

Cet article porte sur la migration elle-même. Pour l’architecture cible, voyez notre guide Proxmox et Ceph en haute disponibilité. Si vous comparez encore les plateformes, lisez aussi notre article sur XCP-ng et Xen Orchestra.

Étape 1 : l’inventaire, sans exception

Tout commence par une liste exhaustive. Pour chaque machine virtuelle, nous relevons :

• le système d’exploitation et sa version, le mode de démarrage (BIOS ou UEFI) ;
• le rôle métier, le propriétaire et la criticité ;
• les dépendances : base de données, annuaire, licences liées au matériel, flux réseau ;
• l’adressage IP, les réservations DHCP et les règles de pare-feu qui la concernent ;
• les snapshots en cours, le chiffrement éventuel, le stockage utilisé (local, SAN, vSAN) ;
• la fenêtre d’arrêt acceptable.

Les licences logicielles méritent une attention particulière : certaines applications métier sont liées à l’identifiant matériel ou à l’adresse MAC de la machine. Une nouvelle carte réseau virtuelle peut suffire à les désactiver. Mieux vaut le savoir avant la bascule, avec l’éditeur au téléphone, qu’après.

Étape 2 : les outils de migration

Méthode	Quand l’utiliser	Points d’attention
Assistant d’import ESXi (intégré)	La grande majorité des machines	Se connecter à l’hôte ESXi plutôt qu’au vCenter, beaucoup plus lent
Import à chaud (live-import)	Serveurs dont l’arrêt doit être le plus court possible	Si l’import échoue, les données écrites depuis son démarrage sont perdues
Export OVF puis import	Machines déjà exportées, sources sans accès direct	Étape d’export supplémentaire
Import de disque ou clonage	Cas particuliers, machines physiques	Plus manuel, configuration à recréer

L’assistant d’import se configure en ajoutant l’hôte ESXi comme source de stockage dans Proxmox VE. Il affiche les machines disponibles et reprend l’essentiel de leur configuration. Proxmox documente plusieurs limites à connaître :

• les disques hébergés sur vSAN ne s’importent pas : il faut d’abord les déplacer vers un autre stockage ;
• les disques chiffrés par une politique de stockage doivent être déchiffrés avant ;
• les snapshots ralentissent nettement l’import : consolidez-les ;
• l’état d’un TPM virtuel ne se migre pas : si un chiffrement de disque complet en dépend, ayez les clés de récupération sous la main ;
• lancer trop d’imports en parallèle peut saturer l’API de l’hôte ESXi : mieux vaut les enchaîner.

Étape 3 : préparer chaque machine

Proxmox recommande de retirer les outils VMware avant la migration, car ils sont difficiles à désinstaller ensuite. Notez la configuration réseau : l’adaptateur change de nom, et Windows signale un conflit si vous réutilisez la même adresse IP fixe. Pour les réservations DHCP, reportez l’adresse MAC ou adaptez la réservation.

Côté cible, nous appliquons les bonnes pratiques Proxmox : contrôleur VirtIO SCSI single, carte réseau VirtIO, agent invité QEMU, type de processeur compatible avec la migration à chaud entre nœuds, et le même mode de démarrage que la source (SeaBIOS ou OVMF/UEFI).

Pour Windows, les pilotes VirtIO ne sont pas présents par défaut. Une machine Windows démarre en général d’abord avec un disque en SATA, puis on installe les pilotes depuis l’ISO VirtIO avant de passer le disque système en VirtIO SCSI. Cette étape se répète sur chaque machine Windows : elle doit figurer dans la procédure, pas être découverte le soir de la bascule.

Étape 4 : stockage cible, Ceph ou SAN existant

C’est la décision d’architecture la plus structurante.

Garder la baie SAN existante. Une baie iSCSI ou Fibre Channel peut servir de stockage partagé en LVM, avec le multipath configuré. C’est économique si la baie est récente et sous support. La limite : les snapshots ne fonctionnent pas comme sous VMware. Proxmox propose une option de snapshots sur ce type de stockage, encore en aperçu technologique ; un NAS en NFS permet aussi les snapshots via le format qcow2.

Passer à Ceph. Proxmox recommande Ceph pour le stockage partagé. Les disques sont dans les serveurs, les données répliquées sur plusieurs nœuds, sans baie centrale qui devient le point unique de panne. Il faut au minimum trois nœuds et un réseau de stockage dédié rapide.

Notre règle : une baie en fin de support ne justifie pas de reconduire l’ancienne architecture. Une baie récente peut être conservée pour la migration, puis remplacée par Ceph lors du renouvellement du matériel.

Étape 5 : bascule par vagues et retour arrière

1. Construire le cluster Proxmox, son réseau et sa sauvegarde avant la première migration.
2. Vague pilote : une ou deux machines peu critiques, pour valider la procédure complète.
3. Vagues suivantes par groupes cohérents : une application et ses dépendances migrent ensemble.
4. Serveurs critiques en dernier, une fois la plateforme éprouvée par les autres.
5. Recette après chaque bascule, avec l’utilisateur métier concerné.

Le retour arrière tient en une règle : la machine source reste intacte sur l’hôte ESXi, éteinte, tant que la recette n’est pas validée. En cas de problème, on éteint la copie Proxmox, on redémarre l’originale, et l’activité reprend. Ne recyclez pas l’ancien matériel avant la fin du projet.

Étape 6 : la sauvegarde pendant la transition

C’est le moment le plus exposé : deux plateformes coexistent, et la sauvegarde doit couvrir les deux.

• Veeam prend en charge VMware et Proxmox VE. Si Veeam protège déjà votre parc, le garder évite tout trou de sauvegarde. Sa licence par charge de travail est portable d’une plateforme à l’autre, comme nous l’expliquons dans notre guide sur les éditions Veeam Data Platform.
• Proxmox Backup Server est la solution native : sauvegardes incrémentielles dédupliquées, vérification, et restauration à chaud d’une machine.

Dans tous les cas : une sauvegarde complète et testée de chaque machine juste avant sa bascule, et le serveur de sauvegarde en dehors du cluster qu’il protège. Nos guides sur la sauvegarde 3-2-1 immuable et sur les tests de restauration détaillent la démarche.

Les pièges les plus fréquents

1. Migrer sans inventaire, puis découvrir une dépendance le lundi matin.
2. Oublier les outils VMware dans les machines, ensuite difficiles à retirer.
3. Importer via le vCenter et voir la migration traîner sur des jours.
4. Ne pas prévoir les pilotes VirtIO pour Windows : la machine ne démarre pas.
5. Une licence logicielle liée à l’adresse MAC, désactivée par la nouvelle carte réseau.
6. Reconduire une baie SAN en fin de vie par habitude.
7. Supprimer les machines sources avant la recette.
8. Lancer la production sans abonnement ni dépôt Enterprise, donc sans mises à jour stabilisées.

Checklist avant la première bascule

• Inventaire complet, criticité et fenêtre d’arrêt de chaque machine.
• Dépendances applicatives et licences liées au matériel identifiées.
• Stockage cible choisi : Ceph, SAN existant ou NAS.
• Cluster Proxmox en place, réseau dédié, abonnement actif.
• Sauvegarde fonctionnelle sur la nouvelle plateforme, restauration testée.
• Outils VMware retirés, configuration réseau notée.
• Snapshots consolidés, disques vSAN ou chiffrés traités.
• Procédure Windows VirtIO écrite et testée.
• Plan de retour arrière validé pour chaque vague.

Comment nous procédons

Nous commençons par un audit du parc VMware : inventaire, dépendances, stockage, sauvegarde et licences. Nous concevons ensuite l’architecture cible, construisons le cluster et migrons par vagues, hors heures de production, avec recette et retour arrière pour chaque machine. Après la migration, la plateforme entre dans notre supervision 24/7, avec prise en charge des incidents critiques en moins de 15 minutes. Le tout dans notre offre virtualisation Proxmox et Veeam, complétée si besoin par notre offre sauvegarde et continuité d’activité. Nos réalisations montrent ce type de projet.

Votre renouvellement VMware approche ? Demandez votre audit initial offert : nous vous remettons un inventaire et un plan de migration détaillé établi sur la base de votre parc réel, avec une réponse sous 24 h ouvrées.