VMware ESX/ESXi est devenu le socle discret mais central d’une énorme partie des infrastructures virtuelles d’entreprise. Dès qu’un parc de serveurs commence à grossir, la question arrive très vite : sur quels hyperviseurs repose tout ça, quelles versions supportées tournent vraiment en production, et comment repérer les installations qui ont basculé en « zone rouge » niveau sécurité. Entre les changements de propriétaire côté VMware/Broadcom, les nouveaux cycles de release et la fin de vie des anciennes branches, garder une vue claire sur la gestion des versions ressemble parfois à un mini-jeu de piste.
L’enjeu dépasse largement la simple curiosité technique. Une infrastructure virtuelle qui tourne sur une version d’ESXi hors support, c’est potentiellement des failles non corrigées, des backups qui ne sont plus garantis compatibles, des outils de monitoring qui se comportent de manière étrange, ou encore des migrations impossibles vers du matériel récent. À l’inverse, mettre à jour un cluster sans visibilité fine sur les contraintes de compatibilité peut casser des automatismes, immobiliser des VMs métiers ou rendre un PRA bancal du jour au lendemain.
Dans ce contexte, comprendre ce qui distingue ESX d’ESXi, comment fonctionne un hyperviseur de type 1, quels sont les cycles de vie des versions récentes (7, 8, 9, 9.1) et comment organiser une vraie détection version fiable sur le terrain, ce n’est plus optionnel. Que tu sois côté prod dans une DSI, en ESN chez des clients, ou dev qui doit simplement éviter que son appli tombe le jour d’une mise à jour vSphere, avoir ces repères change totalement la manière de dialoguer avec l’équipe infra.
En bref
- VMware ESXi est un hyperviseur de type 1, successeur d’ESX, qui embarque son propre noyau et s’installe directement sur le serveur physique.
- Les releases majeures actuellement au centre du jeu sont ESXi 7, 8, 9 et 9.1, avec une dernière version en date numérotée 9.1.0.0200.
- Les branches 5.5, 6, 6.5 et 6.7 ont toutes atteint leur end-of-life, ce qui signifie plus de correctifs de sécurité ni de support éditeur.
- VMware/Broadcom ne propose pas de vraie version LTS d’ESXi : chaque release suit un cycle de support limité dans le temps.
- Une bonne détection des versions non prises en charge repose sur un mix d’inventaire automatisé (API, PowerCLI), de supervision et de règles claires de conformité.
- Ignorer la gestion de version ESXi met en risque la sécurité, les sauvegardes, et toute la chaîne de la virtualisation (vCenter, VMs, outils tiers).
VMware ESX vs ESXi : comprendre l’hyperviseur et ce qui tourne vraiment sur tes serveurs
Avant de parler cycle de vie ou détection, il vaut mieux clarifier sur quoi repose tout le reste. VMware ESXi, anciennement ESX, est un hyperviseur de type 1 conçu pour faire tourner des ordinateurs virtuels directement sur le matériel physique. Concrètement, ce n’est pas un logiciel qui s’ajoute sur un Windows ou un Linux existant. L’hyperviseur apporte son propre noyau et les composants nécessaires pour dialoguer avec le CPU, la RAM, le stockage et le réseau.
C’est pour ça qu’on dit qu’ESXi est un hyperviseur « bare metal ». Une fois installé, il devient la couche de base de ton serveur. Les systèmes d’exploitation invités – Windows Server, distributions Linux, appliances réseau virtuelles – tournent par-dessus, dans des VMs, sans jamais voir directement le matériel. L’hyperviseur gère le partage des ressources, l’isolation, le scheduling CPU, la mémoire, la pile réseau virtuelle et les accès au stockage.
Sur le plan historique, ESX correspond aux versions plus anciennes où l’hyperviseur incluait un composant appelé Service Console, basé sur Linux. Cette console offrait un environnement classique pour les admins : shell, outils système, etc. À partir de la génération 5, VMware a basculé complètement vers ESXi, en supprimant cette couche et en proposant à la place des APIs et des outils dédiés, plus robustes et plus faciles à maintenir à grande échelle.
Différence clé : ESX, dans ses versions 4.1 et antérieures, n’est plus supporté depuis longtemps et ne devrait plus exister sur un parc de production un minimum exposé au réseau. ESXi, à partir de la 5.5, a pris le relais et a continué d’évoluer jusqu’aux branches 7, 8, 9 et 9.1 qui dominent aujourd’hui les environnements récents. Toute la littérature actuelle sur la virtualisation VMware parle en réalité d’ESXi, même si le terme ESX traîne encore dans les habitudes.
Sur un plan très concret, passer d’ESX à ESXi a obligé pas mal de boîtes à revoir leurs habitudes d’administration. Fini les scripts bricolés dans la console Linux locale, place aux automatismes via PowerCLI, les APIs REST, vSphere Client et les outils de configuration centralisée. C’est une contrainte à court terme, mais c’est ce qui permet aujourd’hui de gérer plusieurs dizaines ou centaines d’hôtes de manière cohérente.
Pour fixer les idées, imagine une PME qui a encore un vieux cluster ESX 4.1 dans un coin, jamais migré, utilisé « juste » pour deux VMs métiers historiques. Vu de l’extérieur, tout fonctionne. Mais sur le plan sécurité et support, c’est un gouffre : aucune mise à jour récente, hyperviseur vulnérable, incompatibilité avec les outils modernes de sauvegarde. Comprendre cette différence ESX/ESXi permet déjà de pointer immédiatement les zones les plus risquées.
Dernier point souvent sous-estimé : l’hyperviseur ne se limite pas à faire tourner des VMs. Il définit aussi la manière dont les fonctionnalités avancées (vMotion, DRS, HA, snapshots, intégration avec les solutions de sauvegarde et de monitoring) se comportent. Une version vieille ou hors support ne se contente pas d’être « un peu en retard », elle peut limiter complètement ce que tu peux faire sur ton cluster. Retenir ce lien entre version d’ESXi et capacités réelles du cluster, c’est la base avant de discuter support et détection.
Fonctionnement interne de VMware ESXi et impact sur l’infrastructure virtuelle
Une fois posé le décor ESX/ESXi, il reste à comprendre comment l’hyperviseur se comporte au quotidien. ESXi embarque un noyau spécifique, dérivé du monde Unix, qui sert de chef d’orchestre. Ce noyau prend les décisions de scheduling CPU, attribue la mémoire aux VMs, arbitre les accès disque et réseau, et s’occupe de faire respecter les limites de ressources définies par l’admin (réservations, shares, limites max).
Chaque machine virtuelle se voit présenter un matériel virtuel standardisé : carte réseau virtuelle, contrôleur de disque, chipset virtuel, bus PCI simulé. L’avantage est double. D’abord, le système d’exploitation invité n’a pas besoin de connaître les détails du serveur physique, ce qui facilite énormément les migrations entre hôtes différents. Ensuite, VMware peut faire évoluer la manière dont cet « hardware virtuel » est émulé pour profiter des nouvelles fonctions CPU et mémoire sans tout casser côté invité.
C’est là qu’entrent en jeu les versions de matériel virtuel, parfois appelées virtual hardware versions. Chaque release d’ESXi sait gérer un certain éventail de niveaux de matériel virtuel. Monter trop haut ce niveau sur une VM peut empêcher son démarrage sur des hôtes plus anciens. Rester trop bas peut priver la VM d’optimisations récentes (performances CPU, prise en charge de nouvelles cartes réseau virtuelles, etc.). L’hyperviseur est donc en permanence en équilibre entre compatibilité ascendante et adoption des nouveautés.
À l’échelle d’un cluster, ESXi s’appuie sur des mécanismes de compatibilité comme Enhanced vMotion Compatibility (EVC) pour lisser les différences de génération de processeur entre hôtes. Concrètement, tant que tous les hôtes partagent une même famille CPU (Intel ou AMD), EVC permet de définir un profil commun et de masquer certaines extensions récentes pour assurer la mobilité des VMs. Encore une fois, ce comportement dépend de la version d’ESXi, et les branches les plus anciennes proposent des profils beaucoup plus limités.
On peut prendre l’exemple d’une entreprise fictive, AppCraft, qui exploite un cluster majoritairement en ESXi 8, mais qui a encore deux hôtes en 6.7 ajoutés « temporairement » il y a quelques années. Pour que vMotion fonctionne partout, l’admin a dû configurer un niveau EVC très conservateur. Résultat, même les nouveaux serveurs ne peuvent pas exposer certaines instructions CPU avancées aux VMs, ce qui bride des workloads gourmands. Autrement dit, des anciens hôtes non mis à jour polluent tout le cluster.
Côté stockage, ESXi gère différents protocoles : iSCSI, NFS, Fibre Channel, NVMe over Fabrics selon les versions. Chaque nouvelle release élargit ou ajuste cette prise en charge, et corrige des bugs parfois très subtils sur la gestion des timeouts, la reprise après incident, ou la compatibilité avec les arrays SAN récents. Quand une version passe en end-of-life, elle cesse aussi de recevoir ces corrections spécifiques. Une baie de stockage achetée après cette date peut techniquement être visible, mais ne jamais être validée officiellement comme compatible avec la version d’ESXi restée dans le datacenter.
Du côté réseau, les évolutions récentes d’ESXi (7, 8, 9) intègrent mieux les cartes 25/40/100 Gb, le support des pilotes modernes, et les scénarios de virtualisation réseau avancée. Là encore, garder des hôtes sur une version antérieure, c’est souvent garder aussi d’anciens pilotes et d’anciennes piles réseau qui n’ont pas été testés dans les combos plus récents. D’où l’importance de voir l’hyperviseur comme un composant vivant, qui interagit avec tout le reste, plutôt qu’un simple binaire qu’on installe puis qu’on oublie.
En résumé, le fonctionnement interne d’ESXi conditionne directement les performances, la stabilité et la capacité d’évolution d’une infrastructure virtuelle. Ce fonctionnement est étroitement lié à la version installée, ce qui rend la maîtrise du cycle de vie incontournable si tu veux construire quelque chose de pérenne.
Versions supportées d’ESXi, cycle de vie et politique de support VMware/Broadcom
Une fois qu’on a en tête le rôle d’ESXi, vient la question délicate : quelles sont les versions supportées, et pendant combien de temps. Le cycle de vie du produit est structuré en grandes releases, chacune déclinée en patchs et update builds. Les données de suivi publiées par des bases spécialisées comme Versio.io permettent de dresser un panorama assez précis.
Sur la période récente, on retrouve les grandes branches suivantes, avec leurs dates de première release et leur dernière mise à jour publiée :
| Release ESXi | Date de sortie | Nombre de versions | Dernier build publié | Date du dernier build | Support restant |
|---|---|---|---|---|---|
| 9.1 | 2026-05-12 | 3 | 9.1.0.0200 | 2026-07-13 | Support actif |
| 9.0 | 2025-06-17 | 6 | 9.0.2.0100 | 2026-07-26 | Support actif |
| 8.0 | 2022-10-11 | 31 | 8.0.3.0102 | 2026-08-03 | Support actif |
| 7.0 | 2020-04-02 | 39 | 7.0.3-0.150.24784741 | 2025-07-15 | Fin de support étendu le 2027-04-02 |
| 6.7 | 2018-04-17 | 30 | 670-202210001 | 2022-10-06 | End-of-life |
| 6.5 | 2016-11-15 | 37 | 650-202210001 | 2022-10-06 | End-of-life |
| 6.0 | 2015-03-12 | 35 | 600-202002001 | 2020-02-20 | End-of-life |
| 5.5 | 2013-09-22 | 31 | 550-201809001 | 2018-09-13 | End-of-life |
Ces chiffres montrent un élément que beaucoup sous-estiment : la durée de vie « confortable » d’une release majeure dépasse rarement quelques années. ESXi 7, pourtant adopté massivement, voit sa maintenance standard s’arrêter le 2 avril 2025, avec une maintenance étendue jusqu’au 2 avril 2027. Au-delà de cette date, plus de correctifs, y compris pour des failles de sécurité critiques.
Autre point marquant : contrairement à d’autres écosystèmes, Broadcom/VMware ne propose pas de version officiellement marquée LTS pour ESXi. Il n’existe pas une branche « bénie » qu’on pourrait garder dix ans sans sourciller. Cela oblige les équipes à intégrer la mise à niveau des hyperviseurs comme un chantier récurrent. À mes yeux, c’est une bonne chose d’un point de vue sécurité, mais ça demande une vraie maturité d’outillage.
Sur le plan global, les données publiques évoquent un total d’environ 212 versions d’ESXi référencées, toutes releases confondues, avec une poignée de builds marqués comme instables et une seule version notablement touchée par un CVE recensé dans cette source spécifique. Ça ne veut pas dire qu’ESXi est exempt de failles, loin de là, mais que les correctifs déployés au fil de l’eau suivent une logique structurée, alignée sur ces cycles de release.
Côté distribution, la fiche produit résumée aujourd’hui ressemble à ceci : produit VMware ESXi, fournisseur Broadcom, licence propriétaire, dernière version connue 9.1.0.0200. Derrière ces quelques lignes se cachent des dizaines de combinaisons possibles de builds, chacun avec son propre numéro de version interne, que les équipes doivent apprendre à lire pour savoir où elles en sont réellement.
Si on reprend notre entreprise AppCraft, on retrouve un cas assez typique : un premier cluster en ESXi 6.5 laissé dans un datacenter secondaire « parce qu’il marche », un cluster principal migré en 7.0 il y a deux ans, et un nouveau projet en 8.0 lancé récemment. Sur le papier, tout le monde se félicite d’avoir du 8.0 quelque part. Mais en terme de support global, un tiers du parc est officiellement hors jeu, et un autre tiers va l’être à court terme. Sans lecture attentive du cycle de vie, difficile de prendre des décisions éclairées.
Le message à retenir est simple : la notion de « versions supportées » est mouvante, rythmée par ces releases et leurs dates d’end-of-life. Ignorer ce calendrier revient à découvrir trop tard que ton contrat de support ne couvre plus l’hyperviseur qui fait tourner la moitié de ton SI.
Méthodes concrètes pour la détection des versions non prises en charge dans un parc ESX/ESXi
Parler de cycle de vie, c’est bien. Détecter les installations hors support dans une vraie prod, c’est autre chose. Sur le terrain, les environnements ESXi vieillissent souvent de manière un peu chaotique. Un hôte ajouté en urgence, un labo qui devient du semi-prod, un cluster de test qui finit par héberger une VM critique. D’où l’intérêt de mettre en place une vraie détection version automatisée.
Premier réflexe : exploiter les APIs et les outils natifs. Un vCenter récent expose toutes les données nécessaires sur les versions d’ESXi associées aux hôtes, via l’API SOAP historique ou les endpoints REST modernes. Scripter un inventaire avec PowerCLI reste l’un des moyens les plus rapides de dresser la liste des hyperviseurs, de leurs numéros de build, et de les comparer à un référentiel de versions supportées. Les scripts peuvent être planifiés et alimenter un dashboard, voire déclencher des alertes Slack ou mail.
Deuxième levier : connecter ces informations au système de supervision. Que ce soit via un outil maison, un Prometheus avec exporter vSphere, ou une solution du marché, l’idée est simple. Chaque hôte ESXi remonte un couple version/build. On le confronte à une table de vérité qui liste les branches en fin de vie. Dès qu’un hôte dépasse sa date de support ou s’éloigne de plus de X builds de la dernière version de sa release, on remonte une alerte. La détection ne repose plus sur la mémoire d’un admin, mais sur des règles fixes.
Pour structurer cette démarche, une approche efficace consiste à définir une petite matrice de conformité, avec des statuts bien clairs. Par exemple :
- Vert : version d’ESXi supportée, à jour des derniers patchs ou à un seul patch de la dernière release de sa branche.
- Orange : version supportée mais en retard de plusieurs patchs, à mettre à jour dans un plan de maintenance proche.
- Rouge : version en end-of-life ou non supportée par l’éditeur, à migrer ou évacuer en priorité.
Chaque hyperviseur se voit attribuer l’un de ces statuts selon des règles codées dans l’outil d’inventaire. Pour AppCraft, cette matrice a joué le rôle d’électrochoc : deux hôtes 6.5 utilisés pour des jobs de calcul planifiés apparaissaient en rouge vif, alors qu’ils contenaient encore des VMs internes importantes. Sans cet inventaire, personne ne les avait identifiés comme un risque.
Un autre aspect souvent oublié est la détection des installations « orphelines » sans vCenter, par exemple des hôtes ESXi Free utilisés comme bastions, hyperviseurs de labo ou plateformes de test. Dans ce cas, un scan réseau ciblé, couplé à l’API de gestion directe (et à une collecte des bannières HTTPS de l’interface d’administration), permet de retrouver ces serveurs fantômes. Là encore, le script ne suffit pas : il faut ensuite les intégrer dans le même référentiel de conformité.
Dernier point à considérer : documenter les exceptions. Il arrive qu’une équipe doive garder délibérément un hôte en version ancienne, pour la compatibilité d’un équipement exotique ou d’une appliance qui refuse de courir sur un ESXi plus récent. Dans ce cas, il vaut mieux assumer ouvertement cette dette technique, la marquer comme telle, et lui associer un plan de retrait ou de confinement réseau. Faire semblant qu’il s’agit d’un hôte « comme les autres » ne trompe que l’équipe qui devra gérer l’incident le jour où une faille sévère sera publiée.
Au final, la détection des versions non supportées n’est pas qu’une affaire d’outil ou de script. C’est aussi un sujet de gouvernance : qui possède la vérité sur le parc ESXi, qui décide du calendrier de mise à jour, et comment cette information est partagée avec les métiers qui utilisent les VMs au quotidien.
Compatibilité, risques métiers et bonnes pratiques pour piloter les versions ESXi en continu
Une fois les versions hors support identifiées, la question suivante arrive vite : que faire concrètement pour réduire les risques sans tout casser. La compatibilité est le nerf de la guerre. Il ne suffit pas de choisir la dernière version d’ESXi, encore faut-il vérifier que le matériel, les VMs et les outils autour suivent le mouvement.
Premier pilier : la compatibilité matérielle. Broadcom/VMware maintient une liste d’éléments testés pour chaque release d’ESXi. Se caler sur ces matrices évite des surprises du genre carte RAID non reconnue après upgrade, NIC passant en mode générique sans offload matériel, ou drivers communautaires qui ne survivent pas à la migration. Pour un projet de montée de version, passer quelques heures à croiser modèles de serveurs, contrôleurs de stockage et cartes réseau avec cette base est rarement du temps perdu.
Deuxième pilier : la compatibilité des VMs et du socle applicatif. Certaines applications lourdes, notamment dans l’ERP, les bases de données ou les appliances de sécurité, peuvent imposer des limites strictes sur la version du matériel virtuel ou des tools installés. Monter ESXi en 9 ou 9.1 sans vérifier les prérequis sur ces briques peut générer des comportements subtiles : perte de support, bugs non reproductibles, difficultés de restauration. Ta check-list d’upgrade doit inclure ces dépendances, même si elles ne concernent que quelques VMs très visibles.
Troisième pilier : les outils périphériques. Sauvegarde, monitoring, antivirus, solutions de clustering invité, orchestrateurs. Chacun de ces composants annonce un périmètre de versions supportées d’ESXi. Monter trop vite la version de l’hyperviseur, c’est risquer une désynchronisation avec l’agent de sauvegarde ou le plugin de snapshot. À l’inverse, refuser toute montée de version à cause d’un composant tiers peu réactif finit par bloquer toute l’infrastructure virtuelle. Pas sûr que ce soit un arbitrage idéal.
Pour structurer la gestion des versions dans le temps, une bonne approche consiste à adopter un rythme de projet régulier, plutôt que des migrations géantes tous les 5 ou 6 ans. Par exemple, décider qu’une montée de version majeure ESXi est étudiée deux fois par cycle de support, avec un environnement de préproduction qui joue le rôle de terrain d’essai. AppCraft, dans notre fil rouge, a ainsi choisi d’aligner ses upgrades ESXi sur le renouvellement de son hardware. Quand un nouveau lot de serveurs arrive, il se cale sur la branche la plus récente stable, puis entraîne le reste du cluster par vagues successives.
Pour aider à piloter ce mouvement, une vaste partie des équipes techniques s’appuie sur quelques bonnes pratiques récurrentes :
- Maintenir une cartographie claire des clusters, versions d’ESXi, modèles de serveurs et applications critiques associées.
- Automatiser au maximum les vérifications de compatibilité à l’aide de scripts, d’outils d’audit ou de plateformes spécialisées.
- Impliquer très tôt les équipes applicatives lorsque des changements de version sont planifiés sur les clusters qui hébergent leurs VMs.
- Documenter noir sur blanc les hôtes ou clusters qui restent en version ancienne, avec une date cible de retrait.
- Prévoir un plan de retour arrière réaliste, testé au moins en labo, pour les upgrades d’ESXi les plus sensibles.
Sur le plan des risques métiers, ignorer la gestion de version ESXi expose à plusieurs scénarios désagréables. Incident de sécurité sur une version hors support et impossibilité d’obtenir un patch. Blocage d’un projet de modernisation parce qu’un vieux cluster ne sait pas accueillir les VMs générées par un vSphere plus récent. Conflit avec l’éditeur d’une application critique, qui refuse le support tant que la VM tourne sur une version de matériel virtuel trop vieillissante. Tous ces cas se rencontrent régulièrement en mission.
À l’opposé, un pilotage assumé des versions transforme ESXi en composant fiable et prévisible de l’architecture. Les projets d’évolution peuvent s’appuyer sur un socle à jour, la posture sécurité est plus solide, et les discussions avec les éditeurs (VMware/Broadcom et les autres) deviennent plus simples. C’est tout l’intérêt de voir la gestion des versions non pas comme un mal nécessaire, mais comme une vraie compétence d’ingénierie infra.
Quelles versions d’ESXi sont encore officiellement supportées aujourd’hui ?
Les branches ESXi 9.1, 9.0, 8.0 et 7.0 font encore partie des versions supportées par VMware/Broadcom, avec des dates de fin de maintenance différentes selon la release. Les branches 5.5, 6.0, 6.5 et 6.7 ont atteint leur end-of-life et ne reçoivent plus de correctifs, y compris de sécurité. Pour un projet en production, il est recommandé de cibler au minimum ESXi 7, et plutôt 8 ou 9 pour les nouvelles infrastructures.
Comment savoir si un hôte ESXi est en version non prise en charge ?
La méthode la plus fiable consiste à récupérer le numéro de version et de build de l’hôte (depuis vCenter, l’interface web ou l’API), puis à le comparer aux tableaux de cycle de vie publiés par VMware/Broadcom ou des bases comme Versio.io. En pratique, beaucoup d’équipes automatisent ce contrôle avec PowerCLI ou des outils de supervision qui classent les hôtes en trois catégories : version supportée à jour, version supportée mais en retard de patchs, version en end-of-life.
Que risque-t-on à garder un cluster ESX/ESXi hors support ?
Un cluster ESXi qui tourne sur une version hors support cumule plusieurs risques : absence de correctifs de sécurité, incompatibilité croissante avec le matériel récent, non-prise en charge par les éditeurs d’applications hébergées, et difficulté à obtenir de l’aide du support VMware/Broadcom en cas d’incident majeur. À cela s’ajoute souvent une impossibilité partielle d’adopter de nouvelles fonctionnalités vSphere, ce qui freine les projets d’évolution de l’infrastructure virtuelle.
VMware ESXi propose-t-il une version LTS à privilégier ?
Non. Le modèle de support actuel ne repose pas sur une release marquée LTS, mais sur un cycle de vie par version majeure, avec une période de maintenance standard puis, éventuellement, une maintenance étendue. Chaque branche (7, 8, 9, 9.1) possède sa fenêtre de support, et il revient aux équipes d’anticiper les migrations avant l’échéance pour rester dans le périmètre des versions supportées.
Comment concilier compatibilité applicative et montée de version ESXi ?
La clé est d’intégrer très tôt les contraintes applicatives dans la stratégie d’upgrade. Avant de planifier une montée de version d’ESXi, il faut inventorier les applications sensibles, vérifier leurs matrices de support (version de matériel virtuel, version d’OS invité, prérequis VMware Tools), et éventuellement prévoir des tests ciblés en préproduction. Si une application refuse une version récente, deux options s’ouvrent généralement : négocier une mise à jour avec l’éditeur, ou isoler temporairement les VMs concernées sur un cluster dédié en version plus ancienne, documenté comme exception à traiter.
