Transformez la dépendance VMware en trajectoire OpenStack maîtrisée
Nous qualifions ce qui peut migrer, validons la cible avec un pilote représentatif, puis industrialisons les vagues avec recette et retour arrière. L'objectif n'est pas une simple conversion de format : c'est un modèle d'exploitation stable que vos équipes peuvent maîtriser.
- 1QualificationInventaire des invités, disques, firmware, dépendances réseau et licences ; matrice d'éligibilité par VM.
- 2Pilote représentatifWorkloads réels couvrant plusieurs profils de risque, fenêtres mesurées, retour arrière testé.
- 3Vagues industrialiséesConversion avec pilotes VirtIO, intégration Glance et Cinder, correspondance réseau, recette applicative.
- 4Bascule et stabilisationVM source conservée intacte jusqu'à la recette ; optimisation stockage, réseau et coûts côté OpenStack.
Une trajectoire structurée de VMware vers OpenStack
Inventaire VM et dépendances
Nous identifions les workloads, la topologie, le stockage et les dépendances réseau avant la conversion.
Conversion et validation
Nous convertissons les disques, injectons les pilotes VirtIO si nécessaire et validons la VM sur l'environnement OpenStack cible.
Bascule et optimisation
Après la bascule, nous optimisons le stockage, le réseau et les workloads pour garantir stabilité et maîtrise des coûts.
Les décisions prises avant le pilote
Éligibilité des workloads, flavors cibles, correspondance réseau, stratégie de stockage, préparation des pilotes Windows et Linux, fenêtres de migration, critères de recette et seuils de retour arrière.
Les livrables que vous conservez
Inventaire des dépendances, scripts de l'usine de migration, rapport de pilote, plan de vagues, runbooks de bascule et de retour arrière, procès-verbaux de recette et documentation d'exploitation.
Pourquoi les organisations quittent VMware maintenant
Coûts de licence imprévisibles
Le passage à des offres par souscription facturées au cœur a fortement alourdi les budgets de virtualisation et supprimé toute visibilité tarifaire. OpenStack élimine la licence d'hyperviseur et redonne le contrôle de la trajectoire budgétaire.
Souveraineté et réversibilité
Standards ouverts, APIs documentées, aucune dépendance à un éditeur unique. Vos données et votre plan de contrôle restent sous votre gouvernance, sur une infrastructure auditable et réversible.
Un écosystème éprouvé en production
KVM, Ceph et OVN sont des briques open source exploitées à grande échelle par les plus grands opérateurs de cloud, portées par une communauté active et un large vivier de compétences.
Équivalences VMware → OpenStack
Chaque capacité VMware possède un équivalent OpenStack. Connaître cette correspondance en amont évite de concevoir la cible comme une copie de la source.
| Composant VMware | Équivalent OpenStack | Points d'attention |
|---|---|---|
| ESXi / vSphere | Nova + KVM/QEMU | Pilotes VirtIO requis dans les invités pour les performances disque et réseau |
| vCenter | Horizon + CLI/APIs OpenStack | Modèle multi-tenant avec projets, quotas et accès par rôles |
| vSAN / datastores VMFS | Ceph RBD via Cinder + Glance | Format RAW optimal pour Ceph, thin provisioning et snapshots natifs |
| NSX / vDS | Neutron + OVN/OVS | Les groupes de sécurité remplacent les règles de pare-feu distribué ; anticiper la matrice de flux |
| vMotion | Live migration Nova | Nécessite un stockage partagé type Ceph entre les nœuds de calcul |
| vSphere HA | Masakari | Évacuation automatique des instances en cas de panne d'un nœud de calcul |
| DRS | Nova scheduler + Watcher | Placement initial complété par des politiques d'optimisation continue |
| vROps / vRealize | Prometheus + Grafana + Alertmanager | Alerting orienté service et tableaux de bord construits avec la plateforme |
| Templates / Content Library | Images Glance + Heat / Terraform | Chaîne d'images versionnée et automatisée plutôt que des templates manuels |
Deux chemins de migration éprouvés
Ce sont les deux chemins de migration que nous industrialisons le plus souvent. Le choix se fait pendant la qualification, par profil de workload ; les procédures commande par commande sont publiées dans nos guides techniques.
Voie A : conversion directe via virt-v2v
vCenter ➔ CinderOutillage automatisé qui se connecte à vCenter, convertit le système invité, injecte les pilotes VirtIO et crée directement les volumes Cinder dans OpenStack. Le chemin privilégié pour les parcs Windows et les distributions Linux standards.
Guide technique : procédure virt-v2v →Voie B : export vSphere et import Glance
OVF ➔ GlanceLa procédure standard, entièrement maîtrisable : exporter les disques ESXi, les convertir hors ligne, puis les réinjecter dans Glance et Cinder. Idéale pour les environnements isolés et les migrations de masse scriptées.
Guide technique : procédure export et import →Quand privilégier virt-v2v
Invités Windows nécessitant l'injection des pilotes VirtIO, distributions Linux standards, chemin réseau direct entre vCenter et le nœud de conversion, et équipes recherchant une automatisation maximale par VM.
Quand privilégier l'export puis la conversion
Environnements isolés ou strictement segmentés, invités non standards, contrôle total de chaque artefact intermédiaire, et migrations de masse scriptées dans une usine de migration répétable.
Les pièges que nous neutralisons avant qu'ils ne surviennent
Pilotes VirtIO Windows
Sans pilotes de stockage VirtIO injectés avant le premier démarrage, les invités Windows plantent au boot. Nous injectons et vérifions les pilotes pendant la conversion, pas après.
Conservation des IP et MAC
Licences applicatives, règles de pare-feu et configurations en dur dépendent souvent des adresses. Les ports Neutron sont créés avec IP et MAC fixes quand la continuité l'exige.
Désinstallation de VMware Tools
Des VMware Tools résiduels dégradent l'invité migré. Ils sont désinstallés avant l'export et remplacés par le qemu-guest-agent pour une intégration OpenStack propre.
Boot UEFI ou BIOS
Un invité UEFI démarré en mode BIOS échoue systématiquement. Le type de firmware est inventorié par VM et fixé sur l'image Glance via hw_firmware_type.
Volumes de plusieurs téraoctets
Les gros disques allongent considérablement les fenêtres d'export. Nous convertissons en flux direct vers Ceph RBD et dimensionnons les fenêtres de bascule sur des débits mesurés, pas estimés.
Snapshots et chaînes CBT
Des chaînes de snapshots non consolidées corrompent ou alourdissent les exports. Les snapshots sont consolidés et les intégrations de sauvegarde suspendues avant toute sortie de disque de vSphere.
Questions fréquentes
Quelle interruption de service prévoir par VM ?
La fenêtre couvre l'export, la conversion et le premier démarrage : elle dépend surtout de la taille des disques et du débit disponible. Les vagues sont planifiées par application, les gros volumes sont transférés en flux direct vers Ceph, et chaque fenêtre est validée sur le pilote avant tout engagement.
Les machines virtuelles Windows sont-elles prises en charge ?
Oui. virt-v2v injecte les pilotes VirtIO pendant la conversion et l'invité démarre sur KVM sans intervention manuelle. Les impacts d'activation et de licence sont vérifiés dès la qualification, avant la vague de migration.
Que se passe-t-il si une VM ne démarre pas côté OpenStack ?
La VM source reste intacte sur vSphere jusqu'à la signature de la recette. Le retour arrière est un runbook documenté et testé : redémarrage de la source, rebranchement des flux, journalisation de l'écart et réinjection dans la matrice d'éligibilité.
Faut-il tout migrer ?
Non. La qualification produit une matrice d'éligibilité distinguant migration directe, remédiation préalable, reconstruction sur la cible et décommissionnement. Les exceptions deviennent des décisions explicites du programme plutôt que des surprises tardives.
Qui exploite la plateforme après la migration ?
Vos équipes. Runbooks, automatisation, observabilité et procès-verbaux de recette sont livrés et transférés lors de sessions en binôme, afin que le modèle d'exploitation ne dépende plus de nous une fois la production stabilisée.
Prêt à construire votre trajectoire de sortie VMware ?
Un pilote représentatif lève les incertitudes avant tout engagement de programme : workloads réels, fenêtres mesurées, retour arrière testé.