OpenStack Gazpacho : l'alternative VMware open source qui passe enfin en production.

Le modèle SLURP et pourquoi Gazpacho est la version qui compte

OpenStack publie deux versions par an. Depuis 2022, les versions alternées sont marquées SLURP (Skip Level Upgrade Release Process) : elles permettent aux opérateurs de mettre à jour une fois par an, en sautant directement d'un SLURP au suivant sans toucher la version intermédiaire.

Voici l'état des versions à la date de cet article :

Le calendrier officiel du cycle Gazpacho détaille tous les jalons, les dates de gel des fonctionnalités et les équipes responsables. La page officielle de la version regroupe les points forts sélectionnés par la communauté.

La conséquence concrète : si votre environnement tourne sous Epoxy (2025.1), vous pouvez passer directement à Gazpacho sans toucher Flamingo. Cela divise par deux vos mises à jour obligatoires et simplifie la planification des fenêtres de maintenance en production.

Et si vous êtes sous Flamingo, c'est une mise à jour standard en une seule étape.

Le calendrier des versions est clair. Voyons maintenant ce qui justifie réellement une mise à jour — au-delà de la simple fermeture d'une fenêtre de support.

Migrations en direct parallèles dans Nova : le changement de donne

Si nous devions choisir une seule nouveauté de Gazpacho pour expliquer pourquoi cette version compte pour les entreprises, ce serait celle-ci : Nova prend désormais en charge les migrations en direct parallèles.

Jusqu'ici, la migration en direct des instances traitait les transferts mémoire de façon séquentielle : une connexion après l'autre. Gazpacho introduit plusieurs connexions simultanées, ce qui accélère significativement le transfert des workloads lourds entre hôtes ou zones de disponibilité.

Pourquoi est-ce si important ? Parce que la vitesse de migration détermine en pratique la durée d'une fenêtre de maintenance. Pour une organisation gérant des centaines de VMs — ou qui évalue une sortie de VMware — la différence entre migration série et migration parallèle, c'est la différence entre une nuit de maintenance et un week-end entier.

Et ce n'est pas tout ce qui change dans Nova

Les migrations parallèles sont la nouveauté la plus visible, mais Nova apporte trois autres changements qui reposent sur le même principe : moins de friction opérationnelle.

Migration en direct avec vTPM

Une autre nouveauté qui s'articule avec les migrations parallèles : Nova permet désormais de migrer des instances utilisant le vTPM (module de plateforme sécurisée virtuelle) sans les arrêter. Les workloads avec chiffrement de disque ou démarrage sécurisé — courants dans les environnements réglementés — peuvent désormais être déplacés entre nœuds sans interruption de service. Auparavant, migrer une VM avec vTPM nécessitait un cycle complet arrêt-déplacement-redémarrage. C'est terminé.

IOThread par défaut par instance QEMU

Un changement plus subtil mais avec un impact réel : Nova active par défaut un IOThread par instance QEMU, déchargeant le traitement des E/S disque des vCPU. Dans les environnements haute densité — nombreuses VMs par hôte — cela se traduit par des performances de stockage plus constantes sous charge, sans toucher à la configuration.

Couverture OpenAPI complète dans Nova

Nova atteint une couverture totale de son schéma OpenAPI : chaque endpoint de l'API dispose désormais d'une spécification lisible par machine. Pour les équipes qui automatisent avec Terraform, Ansible ou des outils maison, cela permet de valider les requêtes avant de les envoyer et de réduire les erreurs dans les déploiements d'infrastructure en tant que code.

Nova gère les VMs. Mais les VMs doivent bien vivre quelque part. Et si ce quelque part est du matériel physique qui n'est pas encore passé par OpenStack — ce qui est exactement la situation lors de la plupart des migrations depuis VMware — Ironic entre en jeu.

Ironic : automatisation intelligente qui réduit le travail manuel

Ironic est le service OpenStack pour provisionner des serveurs physiques — bare metal — comme s'il s'agissait de machines virtuelles. Dans Gazpacho, Ironic reçoit un ensemble d'améliorations qui représentent collectivement un vrai saut dans les opérations quotidiennes :

• Détection automatique de l'interface de déploiement. Ironic détermine automatiquement la bonne méthode de déploiement pour chaque serveur, éliminant la sélection manuelle. Cela peut sembler banal, mais dans un datacenter avec du matériel hétérogène (générations et fabricants différents), c'est des heures de configuration économisées par nœud.
• Détection automatique du protocole (NFS/CIFS) pour Redfish. La configuration du boot par virtual media est simplifiée : Ironic détermine le protocole correct sans intervention de l'opérateur.
• Planification des ports par traits. L'attribution du réseau est automatisée en fonction des attributs réels de l'infrastructure — type de NIC, vitesse, capacités — au lieu de dépendre de mappages manuels.
• Interface de déploiement noop. Probablement la plus intéressante pour les projets de migration : elle permet d'enregistrer et de surveiller des serveurs déjà déployés et en production, sans nécessité de les reprovisionner. Le cas d'usage typique : intégrer du matériel existant dans l'inventaire OpenStack lors d'une migration graduelle depuis VMware.

Guide des drivers Cyborg

Cyborg, le service d'accélérateurs d'OpenStack, publie pour la première fois un guide unifié de configuration des drivers couvrant tous les types supportés : FPGA, GPU, NIC, QAT, SSD et PCI passthrough. Pour les organisations qui intègrent des accélérateurs IA ou des workloads HPC dans leur cloud privé, disposer d'une documentation testée et unifiée réduit significativement la barrière à l'entrée.

Les VMs sont migrées avec Nova et le matériel existant est intégré avec Ironic. Place maintenant à la partie qui finit toujours par être plus complexe que prévu : le réseau.

Ce qui change en profondeur : OVN, Manila, OpenBao

Réseau : BGP natif et améliorations OVN dans Neutron

Le contrôleur OVN de Neutron intègre des fonctionnalités très demandées en environnement enterprise :

• Support BGP natif pour annoncer les routes directement depuis le contrôleur réseau, sans outillage externe.
• Routage Nord-Sud pour les ports externes, simplifiant la connectivité avec les réseaux physiques.
• Paires d'adresses autorisées avec MACs virtuels, permettant les scénarios multi-tenant et les architectures hybrides.

Historiquement, ce sont des scénarios où OpenStack nécessitait des contournements ou des outils tiers. Gazpacho les résout nativement.

Stockage : QoS dans Manila et attachements asynchrones

Manila introduit des types et spécifications QoS qui permettent d'appliquer des politiques de performance par workload au stockage partagé. Si vous avez un pool de stockage pour les bases de données et un autre pour les fichiers froids, vous pouvez désormais définir des limites et des priorités au niveau de la plateforme, pas seulement au niveau matériel. Cinder progresse sur les attachements de volumes asynchrones, améliorant la réactivité en environnement haute densité.

Sécurité : PKI avec OpenBao

L'intégration avec OpenBao — fork open source de HashiCorp Vault — pour la gestion des certificats PKI dans OpenStack-Ansible permet d'aligner l'infrastructure de certificats d'OpenStack avec les outils de sécurité enterprise existants. Particulièrement pertinent dans les environnements réglementés où la gestion du cycle de vie des certificats est auditée.

Watcher : stratégies de migration inter-zones

Watcher, le service d'optimisation des ressources, améliore ses stratégies de redistribution des workloads entre zones avec des tests renforcés. Pour les opérateurs gérant des clouds multi-sites ou avec des zones de disponibilité différenciées, cela améliore la fiabilité des redistributions automatiques lors des maintenances ou des pannes.

Tout ce qui précède — migrations, automatisation, réseau — ce sont des fonctionnalités visibles que vous pouvez justifier dans une conversation budgétaire. Mais Gazpacho effectue aussi un travail silencieux, plus important à long terme que n'importe quelle nouvelle fonctionnalité : faire le ménage.

Eventlet : le début de la fin d'une dépendance héritée

L'une des histoires de fond les plus importantes d'OpenStack ces trois dernières années, c'est la suppression progressive d'Eventlet, une bibliothèque de concurrence coopérative adoptée aux débuts du projet, quand Python 2 n'avait pas d'alternative native. Python 3 en a une : asyncio. Mais migrer un projet de la taille d'OpenStack d'un modèle de concurrence à un autre est un travail monumental.

Dans Flamingo (2025.2), quatre services ont terminé la migration : Ironic, Mistral, Barbican et Heat. Dans Gazpacho, Nova progresse significativement vers le threading natif, avec des améliorations de performance et de stabilité mesurables. Neutron avance aussi. Et neuf autres projets sont en migration active.

Pourquoi une organisation qui ne contribue pas au code d'OpenStack devrait-elle s'en préoccuper ? Parce qu'Eventlet est une source connue de bugs subtils, de difficultés de débogage et d'incompatibilités avec les bibliothèques Python modernes. Sa suppression rend OpenStack plus stable, plus maintenable et plus prévisible en production sur le long terme. C'est le type d'amélioration invisible qui n'apparaît pas dans les démonstrations mais qui fait la différence à 3h du matin quand quelque chose tombe en panne.

Gazpacho comme alternative VMware : pourquoi le moment compte

On revient au point de départ de cet article. Nous avons dit que 2026 n'est pas une année ordinaire pour l'infrastructure — que Broadcom a forcé les organisations à repenser leur stack de virtualisation. La question que ces organisations se posent n'est plus « OpenStack est-il techniquement capable ? ». Cela a été tranché depuis longtemps. La question est : « a-t-il des réponses à mes problèmes concrets ? ». Avec Gazpacho, cette réponse s'est considérablement améliorée.

Depuis que Broadcom a restructuré le modèle de licences VMware — hausses de prix significatives, fin des licences perpétuelles, passage aux bundles — les préoccupations que nous entendons le plus souvent sont toujours les mêmes. Gazpacho apporte une réponse directe à chacune, et chaque réponse renvoie directement à ce que nous venons de voir :

À cela s'ajoute qu'OpenStack dépasse les 55 millions de cœurs en production dans le monde. Ce n'est pas un projet de niche ni une promesse future : c'est de l'infrastructure qui tourne en production chez Walmart, le CERN, NTT, Deutsche Telekom, et des milliers d'organisations plus petites qui ne publient pas leurs chiffres. Le projet fonctionne depuis 15 ans et la base de contributeurs croît, elle ne rétrécit pas. La version précédente, Flamingo (2025.2), avait déjà réalisé des avancées importantes en matière de sécurité et de suppression d'Eventlet.

Comment intégrer tout cela dans votre infrastructure

Modèle de versions, migrations en direct parallèles, bare metal intelligent, réseau sans contournements, dette technique en voie de résorption, contexte de marché favorable. Tout converge vers la même question pratique : que faites-vous maintenant ? La réponse dépend de là où vous en êtes.

Il y a trois situations courantes, et le bon diagnostic diffère pour chacune :

• Vous avez OpenStack en production et devez planifier la mise à jour vers Gazpacho. Si vous êtes sous Epoxy, la mise à jour directe SLURP vers SLURP est votre chemin. Si vous êtes sous Flamingo, c'est une étape standard. Dans les deux cas, la recommandation est de valider dans un environnement de test, surtout si vous utilisez des fonctionnalités qui ont changé entre les versions (migrations, OVN, Ironic).
• Vous avez VMware et le coût de renouvellement vous pousse à explorer des alternatives. La question ici est d'architecture : quels workloads migrer en premier, quelle architecture OpenStack convient (sur quel matériel, avec quel stockage — Ceph est le choix naturel), et comment migrer les données sans interrompre le service.
• Vous démarrez un nouveau projet — cloud privé, plateforme de données, infrastructure IA — et OpenStack est sur la table. Gazpacho est la bonne version pour commencer, avec Ceph pour le stockage et, si vous avez besoin de conteneurs, Kubernetes intégré via Magnum.

Dans les trois cas, l'ordre sensé est le même : une courte conversation technique pour comprendre la situation, une proposition d'architecture avec des options et des compromis clairs, et un laboratoire de validation avant de toucher à la production. Ce que Gazpacho change, ce n'est pas le processus — c'est qu'il y a désormais plus de briques matures avec lesquelles travailler.

Pour aller plus loin

• Virtualisation et cloud privé avec SIXE — conception, déploiement et exploitation de clouds privés
• Formations certifiées — cours officiels sur les technologies d'infrastructure ouverte
• Support urgent 24/7 — pour les environnements où un problème à 3h du matin est un vrai problème
• Documentation officielle OpenStack 2026.1 — la référence complète pour Gazpacho