Alternatives à VMware après Broadcom : Proxmox, XCP-ng et Nutanix comparés

Le rachat de VMware par Broadcom, finalisé en 2023, n’a pas seulement changé le propriétaire d’un éditeur historique de la virtualisation. Il a remis en cause des modèles d’exploitation, des budgets pluriannuels et parfois des architectures entières construites autour de vSphere, vCenter, vSAN, NSX et de leur vaste écosystème. Pour beaucoup d’organisations, le sujet n’est plus de savoir si VMware reste techniquement capable de faire tourner leurs charges de travail - il l’est - mais si le nouveau modèle commercial reste compatible avec leurs contraintes financières, contractuelles et opérationnelles.

La difficulté est que l’arbitrage ne se résume pas à comparer le prix d’une licence VMware avec celui d’un abonnement Proxmox VE, XCP-ng ou Nutanix. Une plateforme de virtualisation est au cœur du système d’information : elle porte les serveurs métiers, les bases de données, les services d’annuaire, les outils de sauvegarde, les applications industrielles et parfois les environnements de postes virtuels. Changer d’hyperviseur touche donc aux compétences, aux procédures de reprise, à la supervision, aux contrats éditeurs, aux appliances virtualisées et à la responsabilité opérationnelle en cas d’incident.

Ce guide propose une grille de décision orientée production. L’objectif n’est ni de déclarer VMware obsolète, ni de présenter l’open source comme une solution sans coût. Il s’agit de comprendre ce qui a changé, d’identifier les alternatives réalistes en 2026 et de construire une trajectoire de migration proportionnée au risque. Dans bien des cas, la meilleure décision n’est pas une sortie immédiate et totale : c’est un plan de réduction de dépendance, segmenté par criticité, avec des preuves techniques et financières avant toute bascule à grande échelle.

Ce que le rachat par Broadcom a réellement changé

Avant le rachat, VMware proposait un catalogue complexe mais largement fondé sur des licences perpétuelles, des contrats de support et des éditions fonctionnelles relativement identifiables. Une organisation pouvait amortir ses licences sur plusieurs années, renouveler le support selon ses priorités et faire évoluer son architecture par étapes.

Le changement majeur n’est donc pas seulement tarifaire. Il porte sur la nature de la relation fournisseur : l’accès à la plateforme devient principalement un abonnement récurrent, calculé selon des métriques qui peuvent modifier profondément le coût d’un parc existant.

Fin des licences perpétuelles et généralisation de l’abonnement

Broadcom a mis fin à la commercialisation des licences perpétuelles VMware et a orienté le portefeuille vers des abonnements. Une entreprise ne raisonne plus seulement en investissement initial, mais en coût opérationnel annuel qui doit être reconduit pour maintenir les droits d’usage et le support.

Cette évolution a plusieurs conséquences pratiques :

• les arbitrages budgétaires basculent du CAPEX vers l’OPEX ;
• l’augmentation de capacité peut entraîner une hausse immédiate de la souscription ;
• le renouvellement devient un point de négociation plus sensible ;
• le coût de sortie d’une plateforme doit être comparé au coût de reconduction, et non au prix historique des licences déjà amorties ;
• l’organisation perd une partie de la souplesse qu’offrait l’usage prolongé d’une version stable sous licence perpétuelle.

Pour les environnements très standardisés, fortement automatisés et déjà dépendants de vSphere, cette évolution peut rester acceptable. Pour les PME, les sites distants, les laboratoires, les environnements de recette ou les infrastructures aux budgets contraints, elle peut devenir un déclencheur de migration.

Facturation par cœur et effet de seuil

Le passage à une logique de souscription par cœur a un impact particulièrement visible sur les infrastructures modernes. Les serveurs récents concentrent davantage de cœurs CPU, même lorsque la consommation réelle de ressources virtuelles n’augmente pas proportionnellement.

Une consolidation matérielle, qui devait initialement réduire les coûts d’exploitation, peut ainsi augmenter la base de facturation logicielle. Il faut également prendre en compte les minima éventuels de cœurs par processeur et les effets de bord liés au dimensionnement des noeuds de secours.

Le raisonnement doit donc être mené au niveau du cluster, et non serveur par serveur :

Bundles VVF et VCF : simplification commerciale, rigidité fonctionnelle

Broadcom a simplifié le catalogue autour de bundles tels que VMware vSphere Foundation, souvent désigné VVF, et VMware Cloud Foundation, ou VCF. Cette approche peut faciliter l’achat pour les grandes organisations qui consomment réellement l’ensemble des composants proposés. Elle pose davantage question lorsque l’entreprise ne souhaite qu’un hyperviseur, une administration centralisée et quelques fonctions de disponibilité. Pour aller plus loin, consultez l’état de l’art de Proxmox VE.

Le problème n’est pas que les composants inclus soient inutiles sur le plan technique. vSAN, NSX, Aria et les briques d’automatisation peuvent répondre à de vrais besoins. Le problème est l’imposition d’un périmètre commercial supérieur à la consommation effective.

Un DSI doit donc séparer deux questions trop souvent confondues :

1. Avons-nous besoin des fonctions incluses dans le bundle ?
2. Avons-nous intérêt à payer ces fonctions sur l’ensemble du parc ?

Si la réponse à la première question est oui uniquement pour une petite partie des applications, une architecture à deux vitesses peut être plus rationnelle : conserver VMware sur le périmètre où son écosystème apporte une valeur concrète, et déplacer les charges plus standardisées vers une autre plateforme.

Disparition de l’offre gratuite et pression sur les environnements périphériques

La suppression de la gamme gratuite a également eu un effet symbolique et opérationnel. Les environnements de formation, de validation, de laboratoire, de petite agence ou de test ne peuvent plus s’appuyer sur la même voie d’adoption qu’auparavant.

Ce point semble secondaire face aux contrats de production, mais il affecte la capacité des équipes à tester, automatiser et former les nouveaux administrateurs. Une plateforme dont l’accès est plus difficile dans les environnements périphériques tend aussi à réduire sa présence future dans les standards internes.

Enfin, de nombreuses entreprises ont rapporté des hausses de coûts significatives lors des renouvellements, même si les montants varient selon les contrats, les remises historiques, les volumes et les composants consommés. Il faut traiter ces retours comme un signal de gouvernance, pas comme une règle universelle : demandez une proposition contractuelle détaillée, simulez plusieurs scénarios de croissance et comparez-la à un plan de sortie réaliste.

Ne pas confondre remplacement d’hyperviseur et stratégie de sortie VMware

Une migration hors VMware n’est pas une opération homogène. Les machines virtuelles ont des profils de dépendance très différents. Une VM Linux stateless sous Debian, reconstruite par Ansible et sauvegardée par une solution indépendante, n’a pas le même niveau de risque qu’une appliance de sécurité validée uniquement sur ESXi ou qu’un cluster applicatif supporté par un éditeur tiers dans une matrice très restrictive.

Avant de sélectionner une cible, classez le parc selon sa migrabilité.

Construire une cartographie applicative exploitable

Un inventaire vCenter est nécessaire mais insuffisant. Il faut associer chaque VM à un service, un propriétaire, une criticité, un objectif de reprise et un niveau de support éditeur. Les données à consolider incluent notamment :

• système d’exploitation et version ;
• dépendances réseau, VLAN, règles de filtrage et services DNS ;
• consommation CPU, mémoire, stockage et IOPS sur plusieurs semaines ;
• type de disque, snapshots, RDM éventuels et mode de démarrage ;
• solution de sauvegarde et capacité de restauration hors VMware ;
• compatibilité des agents de supervision, de sécurité et de sauvegarde ;
• support de l’éditeur applicatif sur la plateforme cible ;
• contraintes de fenêtre de maintenance et de retour arrière.

Une approche efficace consiste à définir quatre catégories : migrable rapidement, migrable avec remédiation, à conserver temporairement, et à retirer. La dernière catégorie est importante : une migration est souvent l’occasion d’éliminer les VM oubliées, les environnements de recette abandonnés et les serveurs surdimensionnés.

Identifier les dépendances invisibles

Les obstacles les plus coûteux ne sont pas toujours dans la VM. Ils sont souvent dans l’intégration autour de VMware :

• sauvegardes reposant sur les API VMware et sur Changed Block Tracking ;
• automatisation PowerCLI ou workflows vRealize/Aria ;
• microsegmentation NSX ;
• réseaux distribués et configurations spécifiques de vSwitch ;
• solutions de PRA utilisant la réplication VMware ;
• outils d’inventaire, de CMDB ou de conformité interfacés à vCenter ;
• appliances dont l’éditeur certifie uniquement ESXi ;
• licences logicielles liées à l’identifiant matériel ou à la topologie virtuelle.

Le bon indicateur n’est donc pas le nombre de VM migrées, mais le nombre de services restaurables, supervisés et supportés après migration. Pour aller plus loin, consultez le témoignage d’un administrateur ayant migré.

Proxmox VE : l’alternative open source la plus étudiée en 2026

Proxmox VE est devenu l’une des alternatives les plus adoptées dans les projets de sortie VMware, notamment parce qu’il combine KVM pour les machines virtuelles, LXC pour les conteneurs système, une interface d’administration intégrée, la haute disponibilité, la réplication et une intégration native de Ceph.

Son positionnement est particulièrement intéressant pour les organisations qui veulent reprendre le contrôle de leur plateforme, éviter une facturation par cœur et conserver une architecture x86 standard. Le logiciel est open source, tandis que le support et l’accès au dépôt entreprise sont proposés par abonnement par socket. Le wiki officiel Proxmox VE documente en détail le fonctionnement du gestionnaire de haute disponibilité.

Les forces de Proxmox VE en production

Proxmox VE ne doit pas être réduit à une solution de laboratoire. Déployé avec une architecture cohérente, il peut héberger des charges de production significatives. Ses atouts principaux sont les suivants :

• KVM est un hyperviseur mature, largement utilisé dans l’écosystème Linux ;
• l’administration centralisée est simple à prendre en main pour des équipes système ;
• le clustering est intégré sans imposer de serveur de gestion externe ;
• la réplication et la migration à chaud sont disponibles selon le stockage utilisé ;
• Ceph permet de bâtir un stockage distribué, avec les compromis associés ;
• l’intégration avec Proxmox Backup Server offre une chaîne de sauvegarde efficace ;
• les API et l’automatisation sont accessibles, notamment via Terraform, Ansible et les outils d’orchestration ;
• les coûts sont prévisibles et ne sont pas indexés sur le nombre de cœurs.

Pour une infrastructure de taille petite ou moyenne, utilisant du stockage partagé existant et des VM Linux ou Windows classiques, Proxmox VE peut fournir le socle nécessaire avec une complexité maîtrisable.

Les limites à assumer face à VMware

Proxmox VE n’est pas un clone de vSphere. Les équipes qui l’évaluent doivent accepter une différence de maturité sur certains usages, certains partenaires et certaines couches d’intégration.

Les écarts les plus fréquents concernent :

• la profondeur de l’écosystème d’intégrations tierces ;
• les certifications d’éditeurs applicatifs et de constructeurs ;
• les outils de gouvernance très avancés pour les grands environnements multiéquipes ;
• la richesse historique de certaines fonctions VMware, notamment autour de NSX, de l’automatisation enterprise ou des opérations à très grande échelle ;
• la responsabilité d’architecture lorsque Ceph est choisi sans compétence stockage distribuée suffisante.

Ceph, en particulier, ne doit pas être adopté par défaut. Il est très pertinent pour des clusters conçus pour lui, avec des disques adaptés, un réseau robuste et une exploitation capable de suivre la capacité, la latence, le rebalancing et les domaines de défaillance. Sur un petit cluster ou avec un stockage SAN déjà amorti, conserver NFS, iSCSI ou Fibre Channel peut être une décision plus simple et plus fiable.

Architecture cible et exploitation quotidienne

Pour une cible Proxmox VE, commencez par séparer les décisions :

1. Hyperviseur : Proxmox VE et KVM.
2. Stockage : SAN/NAS existant, stockage local répliqué ou Ceph.
3. Sauvegarde : Proxmox Backup Server, solution tierce compatible, ou combinaison des deux.
4. Réseau : VLAN, bonding, réseau dédié à la migration et réseau dédié au stockage si nécessaire.
5. Automatisation : Ansible, Terraform, API et gestion de configuration des invités.

Un exemple minimal de vérification d’un cluster après ajout de noeuds :

pvecm status
pvecm nodes
pvesh get /cluster/resources --type vm

La disponibilité n’est pas créée par la simple présence de trois noeuds. Elle dépend du quorum, du fencing, de la redondance réseau, de la stratégie de stockage et de tests réels de panne. Les exercices doivent inclure la perte d’un noeud, d’un lien réseau, d’un contrôleur de stockage et d’un site lorsque le périmètre le justifie.

XCP-ng : une plateforme Xen mature pour les équipes orientées VM

XCP-ng est une distribution open source bâtie autour de Xen. Elle s’inscrit dans la continuité technique de l’écosystème XenServer et vise clairement les environnements de virtualisation de serveurs. Avec Xen Orchestra comme couche d’administration, de sauvegarde et d’orchestration, elle constitue une alternative crédible pour les entreprises qui recherchent une expérience centrée sur la gestion de machines virtuelles plutôt que sur une convergence étroite avec l’écosystème Linux.

Son intérêt est souvent sous-estimé dans les comparatifs dominés par Proxmox VE. Pourtant, pour une équipe habituée à vCenter, l’approche Xen Orchestra peut être plus immédiatement lisible : gestion de pools, modèles de VM, sauvegardes, réplication, restauration et administration via une console Web dédiée. Pour aller plus loin, consultez le coût total de possession sur cinq ans. La documentation officielle XCP-ng détaille l’architecture complète, du dom0 aux mécanismes de sauvegarde.

Points forts de XCP-ng et Xen Orchestra

XCP-ng est particulièrement pertinent lorsque la priorité est une plateforme de virtualisation traditionnelle avec une couche de pilotage cohérente. Les fonctions généralement recherchées sont présentes : haute disponibilité, migration à chaud, gestion de stockage partagé, réseau virtuel, modèles, snapshots et outils de sauvegarde.

Xen Orchestra apporte une partie importante de la valeur opérationnelle. Il faut donc l’inclure dans l’évaluation financière et technique, au lieu de considérer uniquement l’hyperviseur. Cette couche fournit notamment des mécanismes de sauvegarde, de restauration granulaire selon les cas, de réplication et de gestion centralisée.

XCP-ng est souvent un bon candidat pour :

• des parcs majoritairement composés de VM classiques ;
• des équipes qui privilégient une console d’administration dédiée ;
• des infrastructures utilisant déjà NFS, iSCSI ou du stockage partagé ;
• des organisations souhaitant une alternative open source avec support professionnel disponible ;
• des projets de migration où la simplicité d’exploitation prime sur une plateforme hyperconvergée complète.

Vigilance sur l’écosystème et les compétences

Le principal sujet n’est pas la capacité de Xen à exécuter des VM de production. C’est la profondeur relative de l’écosystème par rapport à VMware. Certains éditeurs de sauvegarde, de sécurité, de PRA ou de supervision disposent d’une intégration plus mature avec vSphere qu’avec XCP-ng.

Il faut également vérifier les compétences internes. L’administration reste accessible, mais le dépannage bas niveau, le réseau, le multipathing et le stockage nécessitent une compréhension réelle de Xen et de Linux. Une preuve de concept doit inclure un incident simulé, pas seulement le déploiement de quelques VM.

Nutanix AHV : l’option hyperconvergée pour réduire la charge d’intégration

Nutanix AHV est une alternative commerciale à considérer lorsque l’enjeu principal est moins la réduction maximale du coût logiciel que la simplification de l’exploitation d’une infrastructure hyperconvergée. AHV s’intègre à la plateforme Nutanix, dont la couche de stockage distribué et l’administration centralisée constituent le cœur de la proposition technique.

Cette option est souvent pertinente pour les organisations qui souhaitent limiter le nombre de composants à intégrer elles-mêmes : hyperviseur, stockage, supervision, gestion du cycle de vie et automatisation sont proposés dans un cadre unifié. Ce positionnement est différent de Proxmox VE ou XCP-ng, qui laissent davantage de liberté mais demandent aussi davantage de choix d’architecture.

Quand AHV est un bon arbitrage

Nutanix AHV peut être adapté si l’entreprise remplit plusieurs conditions :

• elle cherche une approche hyperconvergée standardisée ;
• elle accepte un fournisseur commercial et un modèle de souscription ;
• elle veut réduire les interactions entre plusieurs fournisseurs de serveurs, de stockage et d’hyperviseur ;
• elle exploite déjà Nutanix ou dispose de compétences sur Prism ;
• elle a des besoins importants de simplification opérationnelle, d’automatisation et de gestion du cycle de vie.

La migration vers AHV doit néanmoins être analysée comme une transformation d’infrastructure, pas comme un simple changement d’hyperviseur. Le coût inclut les noeuds, les abonnements, l’évolution de capacité, les éventuels services de migration et les compétences à acquérir.

Le risque : remplacer une dépendance par une autre

Quitter VMware pour Nutanix peut résoudre une problématique de modèle commercial, mais ne signifie pas automatiquement retrouver une indépendance technologique. L’organisation reste dépendante d’une plateforme intégrée, de son matériel certifié, de sa feuille de route et de ses conditions contractuelles.

Ce n’est pas nécessairement un défaut. Pour certaines DSI, une responsabilité fournisseur plus centralisée a une valeur importante. Mais la décision doit être explicite : AHV est un choix de plateforme commerciale intégrée, alors que Proxmox VE et XCP-ng sont davantage des choix de maîtrise technique et de flexibilité d’assemblage.

Construire un coût total de possession sur cinq ans

Le prix de la souscription n’est qu’une ligne du coût total de possession. Une comparaison sérieuse sur cinq ans doit inclure les coûts visibles et les coûts de transition. Sinon, l’entreprise risque de choisir une alternative peu chère à l’achat mais coûteuse à stabiliser, ou de reconduire VMware faute d’avoir chiffré correctement les options de sortie.

Les postes à intégrer dans le modèle financier

Le modèle doit comparer des scénarios homogènes : même capacité utile, même niveau de disponibilité, même objectif de reprise et même horizon de croissance. Intégrez au minimum :

• abonnements, support et renouvellements ;
• matériel serveur, réseau et stockage ;
• capacité supplémentaire liée à la haute disponibilité ;
• licences de sauvegarde, de PRA, de supervision et de sécurité ;
• coûts de migration et de transformation des procédures ;
• formation des administrateurs et du support de niveau 1 ;
• prestations externes ponctuelles ;
• coûts d’indisponibilité ou de risque pour les applications critiques ;
• dépenses de fonctionnement : énergie, baie, maintenance matérielle ;
• temps interne mobilisé pour l’exploitation et les incidents.

Le TCO ne doit pas prétendre prédire exactement cinq ans de dépenses. Il doit plutôt rendre visibles les hypothèses et permettre une analyse de sensibilité : que se passe-t-il si le parc croît de 20 %, si un contrat augmente, si la migration prend six mois de plus, ou si l’organisation doit conserver VMware pour 15 % des applications ?

Ne pas surévaluer les économies de licences

Les alternatives open source réduisent souvent le coût de licence de l’hyperviseur, mais elles ne suppriment ni le besoin d’expertise ni le besoin de support. L’économie est réelle lorsque l’organisation réinvestit une partie du budget dans l’industrialisation : automatisation, documentation, sauvegardes testées, supervision et montée en compétence.

Une plateforme sans abonnement coûteux mais exploitée sans procédures de restauration, sans support adapté et sans capacité de diagnostic peut devenir plus risquée qu’une plateforme commerciale chère mais maîtrisée. Le bon calcul est donc le coût du service virtualisé, pas le coût du binaire installé.

Critères de décision : choisir selon le parc et la criticité

Aucune alternative n’est universellement supérieure. Le choix dépend du profil de parc, de la maturité des équipes et du niveau de dépendance à l’écosystème VMware.

Taille du parc et effet d’échelle

Pour un petit parc, par exemple quelques dizaines de VM sur deux ou trois hôtes, la simplicité d’exploitation et le coût de support dominent souvent. Proxmox VE ou XCP-ng peuvent apporter une réponse directe, surtout avec un stockage existant et des applications peu dépendantes de VMware.

Pour un parc intermédiaire, la question devient celle de la standardisation. Il faut choisir une plateforme que les équipes peuvent exploiter en astreinte, automatiser et documenter. Une coexistence temporaire de plusieurs hyperviseurs est normale, mais une coexistence permanente de trop nombreuses plateformes augmente les coûts cachés.

Pour un très grand parc, notamment avec plusieurs sites, du PRA avancé, des milliers de VM, du réseau virtualisé et de nombreux outils tiers, la sortie VMware exige une approche par domaine de service. Le maintien de VMware sur certains périmètres peut être rationnel pendant plusieurs années.

Compétences internes et modèle de support

Évaluez honnêtement les compétences disponibles. Une équipe très à l’aise avec Linux, Ansible, stockage distribué et observabilité peut tirer un excellent parti de Proxmox VE. Une équipe orientée exploitation VM traditionnelle peut préférer XCP-ng et Xen Orchestra. Une DSI souhaitant limiter les choix d’intégration peut privilégier Nutanix AHV. Pour aller plus loin, consultez Hyper-V comme alternative Microsoft.

Dans tous les cas, prévoyez un support adapté à la criticité. Le support professionnel ne remplace pas les compétences internes, mais il réduit le temps de résolution sur des incidents rares et complexes.

Criticité applicative et support éditeur

La compatibilité technique ne suffit pas. Une application peut fonctionner sur KVM ou Xen tout en étant hors support contractuel chez son éditeur. Ce risque doit être arbitrée par les propriétaires applicatifs et la direction des risques, pas seulement par l’équipe infrastructure. Pour aller plus loin, consultez XCP-ng comme autre alternative open source.

Pour les applications critiques, exigez une réponse claire à ces questions :

• l’éditeur supporte-t-il la cible envisagée ?
• la sauvegarde est-elle validée par restauration complète ?
• le PRA peut-il être exécuté dans le délai demandé ?
• les performances sont-elles démontrées à charge représentative ?
• existe-t-il un retour arrière réaliste ?
• les équipes d’exploitation connaissent-elles les nouveaux outils ?

Retours du marché : les migrations qui réussissent et les pièges récurrents

Les migrations réussies partagent rarement une technologie unique. Elles partagent une méthode : inventaire fiable, segmentation du risque, pilote représentatif, formation et validation de la restauration avant généralisation.

Les organisations qui obtiennent de bons résultats ne tentent généralement pas de reproduire à l’identique chaque mécanisme VMware. Elles redéfinissent les besoins. Par exemple, une VM historiquement protégée par un snapshot long terme peut être replacée dans une stratégie de sauvegarde immuable plus saine. Un cluster surdimensionné peut être consolidé. Un serveur legacy peut être retiré plutôt que déplacé.

Les pratiques qui réduisent le risque

Une trajectoire réaliste comporte plusieurs vagues :

1. Inventaire et qualification des dépendances.
2. Mise en place de la plateforme cible et des outils de sauvegarde.
3. Migration de VM non critiques mais représentatives.
4. Tests de performance, de restauration et de panne.
5. Migration des applications standard.
6. Traitement spécifique des applications complexes ou non supportées.
7. Décommissionnement progressif des composants VMware devenus inutiles.

Le pilote doit être suffisamment réaliste pour révéler les problèmes : Windows avec outils invités, applications avec base de données, volumétrie significative, sauvegarde, supervision, réseau segmenté et restauration complète. Une VM Linux de test sans dépendance ne valide presque rien.

Les pièges à éviter

Le premier piège est de croire qu’un outil de conversion règle le projet. La conversion de disque ou l’import OVF est une étape technique, pas une validation opérationnelle. Après import, il faut vérifier les pilotes, les interfaces réseau, le démarrage, le temps, les agents, les licences, les performances et les sauvegardes.

Le deuxième piège est de sous-dimensionner le stockage. Les comportements d’IOPS, de latence et de snapshots diffèrent entre plateformes. Une migration est l’occasion de mesurer réellement les besoins au lieu de reprendre les tailles provisionnées historiques.

Le troisième piège est de négliger la sauvegarde. Avant toute migration de masse, démontrez qu’une VM migrée peut être restaurée dans un environnement isolé et remise en service selon l’objectif de reprise attendu.

Le quatrième piège est de forcer une sortie totale pour des raisons symboliques. Si quelques applications critiques imposent temporairement VMware, conservez un périmètre maîtrisé, limité et budgété. Le succès stratégique est la réduction de dépendance et de risque, pas nécessairement l’éradication immédiate de toute licence VMware.

Enfin, gardez une gouvernance de décision factuelle. Chaque scénario doit être évalué sur le coût à cinq ans, la capacité opérationnelle, le risque applicatif, le support éditeur et la réversibilité. Dans la plupart des entreprises, le meilleur résultat sera un portefeuille de plateformes réduit et intentionnel : VMware là où il reste justifié, une alternative open source ou hyperconvergée là où elle apporte un meilleur compromis, et des workloads progressivement modernisés pour dépendre moins d’un hyperviseur donné.