Licences VMware ESXi en 2026 : changements, coûts et meilleures alternatives (Proxmox inclus)

Ce qui a changé dans les licences ESXi (et pourquoi cela compte opérationnellement)

Le changement principal n’est pas un nouvel ordonnanceur d’hyperviseur ou une fonctionnalité de stockage astucieuse. C’est le packaging et les conditions commerciales. La propriété et le modèle go-to-market de VMware ont évolué, et le récit produit s’est déplacé : moins de réglages à la carte, plus de bundles, plus d’accent sur l’abonnement, et moins de tolérance pour « je n’ai besoin que de cette petite chose ».

En termes pratiques pour les SRE, les changements de licence se manifestent comme :

• Volatilité budgétaire : les renouvellements deviennent moins prévisibles, surtout quand le nouveau packaging vous force dans un niveau supérieur.
• Pression sur l’architecture : les changements basés sur le nombre de cœurs ou les bundles peuvent pénaliser les « nombreux petits hôtes » ou récompenser la consolidation — parfois jusqu’à un niveau malsain.
• Friction opérationnelle : vous passez plus de temps à prouver ce que vous exécutez qu’à l’exécuter.
• Risque de roadmap : des décisions qui étaient réversibles (renouveler une année de plus) deviennent collantes (abonnements pluriannuels, accords d’entreprise).

Les évolutions concrètes à supposer en 2026

Les SKU exacts varient selon le contrat, la région et le comportement des revendeurs, mais la plupart des équipes rencontrent les mêmes thèmes :

1. Économie axée sur l’abonnement : les licences perpétuelles sont devenues moins centrales et les bundles d’abonnement dominent l’approvisionnement.
2. Consolidation des bundles : des fonctionnalités qui étaient autonomes sont maintenant liées à des suites ; vous pouvez payer pour des choses que vous n’utilisez pas tout en perdant des points d’entrée moins coûteux.
3. Considérations basées sur les cœurs deviennent l’unité de douleur : si vous avez monté en nombre de cœurs pour gagner du temps (ou parce que les CPU deviennent denses), la licence peut croître plus vite que votre chiffre d’affaires.
4. Le droit au support compte autant que les clés de licence : exécuter des versions non supportées devient un risqué opérationnel plus important car les fournisseurs et les auditeurs y prêtent attention.

Faits intéressants et contexte historique (ce qui explique le présent)

Voici quelques points de contexte concrets qui aident à expliquer pourquoi 2026 ressemble à cela :

• ESX (l’original) a commencé comme une architecture basée sur Linux ; ESXi a ensuite supprimé la « console de service » Linux complète, réduisant la surface d’attaque et changeant la façon dont les admins interagissent avec les hôtes.
• vMotion a changé le contrat social de la maintenance : l’interruption de service a cessé d’être « normale », et les clusters sont devenus l’unité d’opérations.
• HA/DRS a fait de la question « combien d’hôtes faut-il ? » une question de licence autant que de disponibilité, parce que la capacité de réserve n’est pas gratuite.
• vCenter a évolué d’un outil de confort à une infrastructure critique ; beaucoup ont appris à la dure que « on peut le reconstruire » n’est pas un plan de reprise.
• vSAN a normalisé la pensée hyperconvergée dans les environnements VMware, mais a aussi lié l’architecture de stockage aux matrices de licence et de support.
• La montée de KVM a fait de l’hyperviseur moins un rempart et plus une commodité, poussant les fournisseurs à monétiser la gestion, la sécurité et l’écosystème.
• NVMe et 25/100GbE ont déplacé les goulots d’étranglement : les clusters modernes sont souvent limités par le CPU/la licence avant d’être limités par l’E/S, ce qui change les incitations à la consolidation.
• L’adoption du cloud a habitué les dirigeants à la facturation par abonnement, même s’ils détestent la facture ; le logiciel on‑premise a suivi l’argent.

Une réalité opérationnelle : vous n’expérimentez pas les changements de licence au moment de l’achat. Vous les vivez à 02:13 pendant un incident, quand quelqu’un demande si vous avez le droit d’ajouter un autre hôte pour arrêter l’hémorragie.

Petite blague n°1 : La licence est la seule partie de la pile qui peut mettre la production à l’arrêt sans toucher un seul paquet.

Ce que « changer » signifie réellement pour l’architecture

Quand le modèle commercial vous pousse vers des boîtes plus grandes et moins nombreuses, vous serez tenté de consolider agressivement. Cela peut être correct — jusqu’à ce que ça ne le soit plus. Le moment où vous passez de « N+1 » à « espérer et prier », votre domaine de défaillance grandit. La panne d’un hôte devient une crise de capacité, pas un événement de routine.

Donc la bonne question n’est pas « quelle est la licence la moins chère ». C’est :

• Quelle est la licence la moins chère qui nous permet encore d’opérer sainement pendant les pannes et la maintenance ?
• Quel est le coût de sortie migratoire si nous devons pivoter dans 18 mois ?
• Pouvons‑nous prouver la conformité avec un inventaire réel, et non des connaissances tribales ?

Ce que ça coûte en 2026 : comment raisonner le budget sans deviner

Je ne vais pas prétendre qu’il existe un prix unique. Il n’y en a pas. Les accords varient selon l’entreprise, le secteur et les incitations des revendeurs. Ce que vous pouvez faire, de façon fiable, c’est cesser de traiter le devis de renouvellement comme la météo et commencer à le traiter comme un problème d’ingénierie : mesurer les entrées, modéliser des scénarios, puis décider.

Le modèle de coût : les variables qui déplacent vraiment la ligne

Pour la plupart des environnements, voici les moteurs de coût qui importent plus que la brochure :

• Total des cœurs physiques sur les hôtes licenciés (ou cœurs par CPU multipliés par le nombre de CPU).
• Nombre d’hôtes (car le support et les pratiques opérationnelles évoluent avec lui, même si la licence est basée sur les cœurs).
• Niveau du bundle (le phénomène « montée forcée » : vous vouliez seulement A, mais vous achetez A+B+C).
• Niveau de support (les temps de réponse et fenêtres de couverture affectent la façon dont vous organisez l’astreinte).
• Composants optionnels qui ne sont pas optionnels en pratique (intégration de sauvegarde, supervision, rétention des logs, MFA/SSO).
• Taux de croissance : si vous ajoutez des hôtes chaque trimestre, les coûts d’abonnement se cumulent plus vite que vous ne le pensez.

Cessez de comparer des factures ; comparez des architectures

Quand quelqu’un dit « Proxmox est gratuit » ou « Hyper‑V est inclus », il compare généralement une ligne budgétaire à un système. Ce n’est pas sérieux.

Une comparaison honnête inclut :

• Le temps d’ingénierie pour la migration et la replateformisation.
• L’outillage opérationnel : supervision, sauvegardes, patching, gestion des secrets, RBAC, journalisation d’audit.
• Le coût du risque : probabilité d’indisponibilité, temps de récupération, et rayon d’impact.
• Le coût du verrouillage fournisseur : options de sortie quand votre contrat devient désagréable.

Voici la vérité brutale : VMware reste souvent le choix opérationnel à moindre risque quand vous l’avez déjà, que vous le connaissez déjà et que vous avez déjà construit des processus autour. Mais quand le modèle commercial change suffisamment, la « courbe de risque » s’inverse : rester devient le risque.

Comment prendre une décision de coût en 2026 sans se faire avoir par son propre tableur

Utilisez trois scénarios :

1. Renouvellement en statu quo : ce que coûte le renouvellement pour continuer comme aujourd’hui.
2. Redimensionner + renouveler : réduire cœurs/hôtes, retirer les clusters morts, standardiser vers moins de SKU, puis renouveler.
3. Sortie progressive : déplacer d’abord les charges non critiques, garder VMware pour le « dur » (appliances legacy, support strict des fournisseurs), et réduire la surface dans le temps.

Le troisième scénario est où beaucoup d’organisations mûres atterrissent en 2026. Ce n’est pas idéologique. C’est de la gestion du risque.

Risque d’audit et de conformité : où les équipes sont surprises

Les ennuis de licence ne commencent que rarement par la malveillance. Ils commencent par des suppositions : « cet hôte est seulement pour le DR », « ces cœurs ne comptent pas », « ce cluster de labo n’a pas d’importance », « on réglera ça plus tard ». Puis quelqu’un demande des preuves, et vous découvrez que vos preuves sont une page wiki obsolète écrite par un ingénieur parti depuis deux réorganisations.

Modes de défaillance qui créent des conversations de licence désagréables

• Clusters fantômes : clusters test/dev qui sont devenus production parce que quelqu’un avait besoin de capacité « temporairement ».
• DR qui n’est pas froid : hôtes de secours qui exécutent en réalité des charges pendant la maintenance, les rendant opérationnellement « chauds » même si vous les appelez « DR ».
• Dérive après refresh CPU : vous avez remplacé des hôtes deux-sockets par des CPU à densité de cœurs élevée et avez accidentellement doublé votre exposition de licence.
• Creep fonctionnel : vous avez activé des fonctionnalités (chiffrement, switching distribué, stockage avancé) qui vous placent dans un niveau supérieur.
• Inadéquation contractuelle : les achats par la procurement ne correspondent pas aux déploiements par l’ingénierie. Personne ne ment. Ils vivent juste dans des univers différents.

Une citation à garder sur votre mur

Werner Vogels (CTO d’Amazon) l’a dit simplement : « Everything fails, all the time. » Si vous concevez pour cela, les choix de licence et d’architecture deviennent moins émotionnels et plus justes.

Petite blague n°2 : La seule chose plus permanente qu’une VM temporaire est le centre de coût dans lequel elle finit par vivre.

Playbook de diagnostic rapide : quoi vérifier en premier/deuxième/troisième pour trouver vite le goulot

Voici le flux de triage que j’utilise quand quelqu’un dit « VMware est lent » et que le sous-texte est « on devrait migrer ». Parfois il faut migrer. Parfois vous êtes juste à une file mal dimensionnée de la paix.

Premier : confirmer que le symptôme est réel et bien circonscrit

1. Est‑ce une VM, un hôte, un datastore ou un cluster ? Si vous ne pouvez pas répondre, vous ne diagnostiquez pas — vous devinez.
2. Est‑ce du CPU ready/steal, latence stockage, contention mémoire ou pertes réseau ? Choisissez l’axe avant de choisir le coupable.
3. Quelque chose a‑t‑il changé ? Patches, firmware, jobs de sauvegarde, snapshots, nouveaux agents de sécurité, nouveau pilote NIC. Accusez le changement jusqu’à preuve du contraire.

Second : isoler la classe de ressource

• Signes CPU-bound : haut temps CPU ready, files d’exécution, co‑stop fréquent sur des VM SMP.
• Signes mémoire-bound : swapping, ballooning, pression sur la mémoire compressée, tempêtes de pagination invitées.
• Signes stockage-bound : pics soutenus de latence de datastore, saturation de profondeur de file, thrashing de chemins.
• Signes réseau-bound : pertes, retransmissions, saturation pNIC, MTU mismach, mauvaise config LACP.

Troisième : prouver si le goulot est « plateforme » ou « design »

Si votre design est fragile, changer d’hyperviseur ne le réparera pas. La même charge échouera simplement avec un autre accent.

• Vérifiez si vous êtes trop juste (pas de marge pour les événements HA).
• Vérifiez le sprawl de snapshots et le recouvrement des sauvegardes.
• Vérifiez l’agencement du stockage (trop de VM par datastore, mauvais recordsize RAID/ZFS, roulette du thin provisioning).
• Vérifiez le réseau : MTU, offloads, compatibilité driver/firmware.

Tâches pratiques avec commandes : mesurer, décider et éviter les douleurs auto‑infligées

Voici des vérifications pratiques que vous pouvez exécuter aujourd’hui. Certaines sont spécifiques à ESXi (via SSH et le shell ESXi). D’autres proviennent de nœuds Linux que vous avez probablement déjà (serveurs de sauvegarde, boîtes de monitoring) parce que les opérations réelles sont multi‑plateformes. Chaque tâche inclut : la commande, ce que signifie la sortie, et la décision qu’elle entraîne.

Tâche 1 : Identifier la version/build ESXi sur un hôte (baseline de support et vulnérabilité)

cr0x@server:~$ ssh root@esxi-01 'vmware -vl'
VMware ESXi 8.0.2 build-23305546
VMware ESXi 8.0.2 GA

La sortie signifie : Vous êtes sur ESXi 8.0.2 avec un build spécifique. Cela importe pour l’éligibilité au support, la compatibilité des pilotes, et si vous êtes dans les matrices supportées par les fournisseurs.

Décision : Si vous êtes en retard sur les mises à jour majeures ou sur un build hors support, corrigez cela avant de prendre une décision de licence. Les plateformes non supportées transforment chaque incident en argument d’achat.

Tâche 2 : Inventorier les cœurs CPU physiques (l’unité que suit souvent la licence)

cr0x@server:~$ ssh root@esxi-01 'esxcli hardware cpu global get'
   Package Count: 2
   Core Count: 32
   Core Count Per Package: 16
   Thread Count: 64
   Thread Count Per Package: 32
   HV Support: 3
   HV Replay Support: 1

La sortie signifie : Cet hôte a 32 cœurs physiques au total. Ignorez les threads pour les discussions de licence sauf si votre contrat l’indique.

Décision : Construisez une feuille de compte de cœurs cluster‑wide à partir de données réelles d’hôte. Si votre devis de renouvellement est basé sur des « cœurs estimés », vous êtes déjà perdant.

Tâche 3 : Confirmer quels hôtes ESXi sont connectés et sains (éviter les licences « fantômes »)

cr0x@server:~$ ssh root@vcenter-01 'vim-cmd vmsvc/getallvms | head'
Vmid   Name              File                      Guest OS        Version   Annotation
1      vcenter-01        [vsanDatastore] ...        vmwarePhoton64  vmx-19
12     backup-proxy-01   [ssd01] backup-proxy...    ubuntu64Guest   vmx-19
34     app-prod-02       [ssd02] app-prod-02...     centos64Guest   vmx-19

La sortie signifie : Vous listez les VM enregistrées. Si vous voyez des charges « labo » ou « temporaires » inattendues, elles ne sont pas théoriques — elles consomment de la capacité et possiblement des fonctionnalités sous licence.

Décision : Étiquetez et classez les VM (prod/dev/labo/DR). La réduction de coûts la plus rapide est de supprimer ce dont vous n’avez plus besoin — après avoir vérifié que c’est vraiment mort.

Tâche 4 : Détecter le sprawl de snapshots (aimant à échecs de perf et sauvegarde)

cr0x@server:~$ ssh root@esxi-02 'find /vmfs/volumes -name "*.vmsn" -o -name "*-delta.vmdk" | head'
/vmfs/volumes/datastore1/app-prod-02/app-prod-02-000002-delta.vmdk
/vmfs/volumes/datastore1/app-prod-02/app-prod-02-Snapshot2.vmsn
/vmfs/volumes/datastore2/db-prod-01/db-prod-01-000001-delta.vmdk

La sortie signifie : Des disques delta et fichiers mémoire de snapshot existent. Les snapshots de longue durée peuvent casser la latence, gonfler l’utilisation de stockage et briser les hypothèses RPO.

Décision : Si vous voyez beaucoup de delta vieux de plus que vos fenêtres de changement, arrêtez‑vous et nettoyez-les avec un plan contrôlé. Faites cela avant de migrer — snapshots plus migration égalent perte de données créative.

Tâche 5 : Vérifier rapidement la latence des datastores (le stockage est‑il le goulot ?)

cr0x@server:~$ ssh root@esxi-01 'esxtop -b -n 2 -d 2 | grep -E "CMDS/s|DAVG/cmd|KAVG/cmd|GAVG/cmd" | head'
CMDS/s   DAVG/cmd   KAVG/cmd   GAVG/cmd
120.00   8.12       0.44       8.56
135.00   22.50      0.60       23.10

La sortie signifie : GAVG est la latence perçue par le guest. Des pics au‑dessus d’environ 20ms en soutenu corrèlent souvent avec le sentiment « tout est lent », surtout pour les bases de données.

Décision : Si GAVG pique, ne blâmez pas d’abord l’hyperviseur. Examinez l’array de stockage, la profondeur de file, le multipathing, et les voisins bruyants.

Tâche 6 : Confirmer le multipath et la santé des chemins (dégradation silencieuse du stockage)

cr0x@server:~$ ssh root@esxi-01 'esxcli storage core path list | head -n 12'
fc.20000024ff2a1b33:vmhba2:C0:T0:L12
   Runtime Name: vmhba2:C0:T0:L12
   Device: naa.600508b1001c3a2f9e3f0d2b7f3b0001
   Device Display Name: DGC Fibre Channel Disk (naa.600508b1...)
   Path State: active
   Adapter: vmhba2
   Target Identifier: 20000024ff2a1b33
   LUN: 12

La sortie signifie : Vous avez des chemins actifs. Si vous voyez « dead » ou « standby » là où vous attendez active/active, les performances et la résilience peuvent être compromises.

Décision : Réparez le pathing avant de changer quoi que ce soit d’autre. Une migration ne réparera pas un SAN fabric cassé.

Tâche 7 : Vérifier l’espace libre VMFS (les mensonges du thin provisioning finissent toujours par se voir)

cr0x@server:~$ ssh root@esxi-03 'df -h /vmfs/volumes/* | head'
Filesystem                         Size   Used   Available Use% Mounted on
/vmfs/volumes/datastore1           9.8T   9.1T     700G    93% /vmfs/volumes/datastore1
/vmfs/volumes/datastore2           7.3T   6.0T     1.3T    82% /vmfs/volumes/datastore2

La sortie signifie : datastore1 est à 93% d’utilisation. C’est là où les snapshots meurent et où les performances de stockage deviennent étranges.

Décision : Imposer des planchers d’espace libre (souvent 15–20%) et arrêter le sur‑engagement sans alerte. Si vous planifiez une migration, vous avez besoin d’espace tampon.

Tâche 8 : Valider NTP/dérive d’horloge (parce que Kerberos et les logs sont tatillons)

cr0x@server:~$ ssh root@esxi-01 'esxcli system time get'
   Local Time: 2025-12-28 03:14:06
   Universal Time: 2025-12-28 03:14:06

cr0x@server:~$ ssh root@esxi-01 'esxcli system ntp get'
   Enabled: true
   Servers: 10.0.0.10, 10.0.0.11

La sortie signifie : NTP est activé et pointe vers des serveurs internes.

Décision : Si l’heure est fausse, corrigez‑la avant de faire des changements d’auth, rotations de certificats ou migrations. Sinon vous passerez du temps à déboguer des échecs de login « aléatoires » qui sont en fait physiques.

Tâche 9 : Vérifier ballooning/swapping sur l’hôte (contention mémoire)

cr0x@server:~$ ssh root@esxi-02 'esxtop -b -n 2 -d 2 | grep -E "MCTL|SWCUR|MEMSZ" | head'
MCTL(GB)  SWCUR(GB)  MEMSZ(GB)
0.00      0.00       512.00
12.50     4.00       512.00

La sortie signifie : Ballooning (MCTL) et swapping (SWCUR) sont non nuls dans le deuxième échantillon — cet hôte est sous pression mémoire.

Décision : Si la contention mémoire a lieu, cessez de consolider « pour économiser des licences ». Vous payez en latence, pas en euros, et les utilisateurs remarquent toujours la latence en premier.

Tâche 10 : Confirmer l’état des liens vSwitch / vmnic (les problèmes réseau ressemblent à des problèmes applicatifs)

cr0x@server:~$ ssh root@esxi-01 'esxcli network nic list'
Name    PCI Device    Driver  Admin Status  Link Status  Speed  Duplex  MAC Address
vmnic0  0000:3b:00.0  i40en   Up            Up           25000  Full    3c:fd:fe:aa:bb:01
vmnic1  0000:3b:00.1  i40en   Up            Down           0     Half   3c:fd:fe:aa:bb:02

La sortie signifie : vmnic1 est administrativement Up mais link Down. Cela peut réduire la redondance ou casser les attentes LACP.

Décision : Réparez les liens physiques avant de courir après une « instabilité VMware ». La moitié de votre réseau de cluster qui fonctionne sur une seule voie n’est pas un problème de plateforme.

Tâche 11 : Mesurer le recouvrement des sauvegardes (la sauvegarde est une charge de performance)

cr0x@server:~$ ssh root@backup-01 'systemctl status veeamservice | head -n 12'
● veeamservice.service - Veeam Service
     Loaded: loaded (/lib/systemd/system/veeamservice.service; enabled)
     Active: active (running) since Sun 2025-12-28 00:01:10 UTC; 3h 12min ago
   Main PID: 2143 (veeamservice)
     Tasks: 34
     Memory: 1.2G

La sortie signifie : Votre service de sauvegarde est actif. Cela ne garantit pas qu’il est sain, mais confirme la planification et le runtime.

Décision : Si les plaintes de performance coïncident avec les fenêtres de sauvegarde, limitez la concurrence des sauvegardes ou isolez‑les sur un réseau/datastore proxy. Ne migrez pas d’hyperviseur pour corriger un problème d’ordonnancement.

Tâche 12 : Estimer l’empreinte CPU/mémoire d’une VM Linux (redimensionnement pour toute plateforme)

cr0x@server:~$ ssh cr0x@app-prod-02 'uptime; free -h; nproc'
 03:18:40 up 47 days,  6:22,  2 users,  load average: 1.12, 0.98, 0.91
               total        used        free      shared  buff/cache   available
Mem:            32Gi        9.1Gi        2.3Gi        1.0Gi         21Gi         22Gi
Swap:          4.0Gi          0B        4.0Gi
16

La sortie signifie : La VM a 16 vCPU et 32GiB RAM ; elle utilise ~9GiB RAM et une charge CPU modeste. Probablement surdimensionnée.

Décision : Right‑sizez avant les renouvellements ou migrations. Les VM surdimensionnées gonflent les besoins en cœurs, forcent des hôtes plus gros, et font paraître le coût de licence « inévitable ».

Tâche 13 : Vérifier la latence stockage depuis une VM Linux (contrôle invité)

cr0x@server:~$ ssh cr0x@db-prod-01 'iostat -x 1 3 | sed -n "1,20p"'
Linux 6.5.0 (db-prod-01) 	12/28/2025 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.21    0.00    2.10    9.88    0.00   81.81

Device            r/s     w/s   rMB/s   wMB/s avgrq-sz avgqu-sz await r_await w_await  svctm  %util
sda             45.0    30.0     5.1     8.3    355.2     2.14  27.4    19.2    39.8   1.9   14.3

La sortie signifie : await autour de 27ms suggère une latence de stockage visible à l’intérieur de la VM.

Décision : Si les guests voient un await élevé tandis que les hôtes montrent aussi de la latence, c’est du stockage réel. Si seuls les guests le voient, vérifiez le système de fichiers invité, l’ordonnanceur I/O ou un processus bruyant en invité.

Tâche 14 : Valider l’état du pool ZFS sur un nœud candidat Proxmox (si vous envisagez HCI)

cr0x@server:~$ ssh root@pve-01 'zpool status -x'
all pools are healthy

La sortie signifie : Aucun erreur ZFS connue pour l’instant.

Décision : Si vous évaluez Proxmox avec ZFS, traitez la santé du pool comme un SLO de première classe. Si vous ne pouvez pas maintenir ZFS en bonne santé, ne l’utilisez pas encore pour les charges critiques.

Tâche 15 : Vérifier l’état du cluster Ceph (si votre alternative utilise du stockage distribué)

cr0x@server:~$ ssh root@pve-01 'ceph -s'
  cluster:
    id:     8b1b2c42-1a72-4c8d-8d4a-0a7c1c6b5d1a
    health: HEALTH_WARN
            1 osds down
  services:
    mon: 3 daemons, quorum pve-01,pve-02,pve-03 (age 2h)
    mgr: pve-01(active, since 2h)
    osd: 9 osds: 8 up (since 5m), 9 in (since 2h)
  data:
    pools:   2 pools, 128 pgs
    objects: 2.1M objects, 8.3 TiB
    usage:   24 TiB used, 48 TiB / 72 TiB avail
    pgs:     126 active+clean, 2 active+degraded

La sortie signifie : Le cluster est en warning : un OSD down, certains PGs dégradés. La performance et la résilience sont réduites jusqu’à la fin de la récupération.

Décision : Si vous ne pouvez pas tolérer des états dégradés opérationnellement (alerting, réponse on‑call, pièces de rechange), ne choisissez pas une plateforme de stockage distribuée dès le premier jour pour votre niveau critique.

Tâche 16 : Convertir et vérifier une image disque VMware pour un test de migration (ne devinez pas ; testez)

cr0x@server:~$ qemu-img info disk.vmdk
image: disk.vmdk
file format: vmdk
virtual size: 200 GiB (214748364800 bytes)
disk size: 78 GiB

cr0x@server:~$ qemu-img convert -p -f vmdk -O qcow2 disk.vmdk disk.qcow2
    (100.00/100%)

cr0x@server:~$ qemu-img info disk.qcow2
image: disk.qcow2
file format: qcow2
virtual size: 200 GiB (214748364800 bytes)
disk size: 79 GiB

La sortie signifie : Vous avez validé le format source et l’avez converti en qcow2 pour les plateformes KVM (comme Proxmox).

Décision : Utilisez‑cela pour lancer un test de boot isolé d’une VM représentative. Si elle ne démarre pas proprement, vous apprenez quelque chose à bas coût.

Tâche 17 : Vérifier l’alignement firmware/driver sur des hôtes Linux utilisés pour la virtualisation (éviter les « resets mystères »)

cr0x@server:~$ sudo dmesg -T | grep -E "firmware|Microcode|IOMMU" | tail -n 8
[Sun Dec 28 02:41:11 2025] microcode: updated early: 0x2c -> 0x31, date = 2024-11-12
[Sun Dec 28 02:41:12 2025] DMAR: IOMMU enabled
[Sun Dec 28 02:41:12 2025] AMD-Vi: Interrupt remapping enabled

La sortie signifie : Le microcode est mis à jour et IOMMU est activé — important pour la stabilité et les fonctionnalités de passthrough.

Décision : Si vous migrez vers KVM, assurez‑vous que le microcode et les réglages BIOS sont production‑grade d’abord. « On optimisera plus tard » devient « pourquoi l’hôte a‑t‑il redémarré sous charge ? »

Trois mini-récits d’entreprise depuis le terrain

Mini-récit n°1 (incident causé par une mauvaise hypothèse) : « Le DR n’est pas un style de vie »

Une entreprise SaaS de taille moyenne exploitait un cluster VMware primaire et un « cluster DR » dans une colocation moins chère. L’environnement DR avait démarré en standby cold : des hôtes minimaux, assez de stockage pour contenir des répliques, et un plan pour alimenter la capacité supplémentaire en cas de sinistre.

Puis la réalité a fait ce qu’elle fait toujours. Le site DR est devenu un endroit pratique pour exécuter des jobs batch « temporaires » et quelques services internes non critiques. Personne ne voulait risquer la capacité de production, donc ils ont discrètement déplacé des charges vers le DR pour « juste un mois ». Les mois sont devenus une année.

La mauvaise hypothèse : les finances et les achats traitaient toujours le DR comme de la capacité inerte. L’ingénierie le considérait comme une extension de production. Lors des négociations de renouvellement, le fournisseur a demandé un inventaire de l’environnement. L’inventaire montrait le cluster DR exécutant de vraies charges, avec des fonctionnalités activées correspondant aux patterns de production.

L’incident n’était pas l’audit lui‑même. L’incident a été la ruée opérationnelle qui a suivi : la direction a exigé l’évacuation immédiate des charges du DR pour préserver le récit « cold standby ». Ils ont tenté des vMotion et Storage vMotion agressifs à travers un WAN contraint, pendant les heures ouvrables, sur un cluster déjà chaud.

La latence a grimpé, les sauvegardes ont pris du retard, et une VM base de données a déclenché une consolidation de snapshot qui a plongé un datastore dans le rouge. Résultat final : une panne perçue par les utilisateurs attribuée, dans le postmortem, à une « latence stockage inattendue ». La vraie cause racine était une défaillance de gouvernance : ils n’avaient pas de définition appliquée du DR ni de garde‑fous empêchant qu’il devienne production.

Mini-récit n°2 (optimisation qui s’est retournée contre eux) : « Consolidation : le tueur d’SLO silencieux »

Une équipe IT d’entreprise a reçu un devis de renouvellement qui a soudainement fait s’intéresser les dirigeants à l’architecture de virtualisation. L’équipe a proposé de consolider : moins d’hôtes, des CPU plus gros, plus de cœurs par machine. Le tableur était séduisant. Les diagrammes de rack étaient propres. Tout le monde a applaudi.

Ils sont passés d’un cluster confortable avec beaucoup de marge à un design plus serré. Le HA « fonctionnait » encore, dans le sens où les VM redémarraient ailleurs après la panne d’un hôte. Mais la performance pendant une panne était affreuse : le CPU ready a grimpé, les files de stockage se sont saturées, et quelques services sensibles à la latence ont commencé à timeout sous charge.

Puis une mise à jour firmware de routine a mis un hôte hors ligne. Rien de dramatique — jusqu’à ce que DRS rééquilibre. Le cluster est resté dans un mode de capacité d’urgence pendant des heures. Les utilisateurs ont râlé, les tickets d’incident se sont accumulés, et l’équipe s’est rendue compte qu’elle s’était conçue en « mode dégradé permanent ».

L’optimisation qui a mal tourné n’était pas la consolidation elle‑même. C’était l’échec à traiter la marge comme une exigence, pas comme un luxe. La consolidation a sauvé des euros de licence et créé une taxe de disponibilité payée à chaque fenêtre de maintenance et à chaque incident.

Ils se sont remis en ajoutant un hôte de plus (oui, la chose qu’ils voulaient éviter) et en right‑sizant des VMs surdimensionnées. Le design final coûtait un peu plus que le « parfait » du tableur — mais bien moins que le churn opérationnel.

Mini-récit n°3 (pratique ennuyeuse mais correcte qui a sauvé la mise) : « L’inventaire est une fonctionnalité »

Une organisation de santé avait la réputation d’être conservatrice, ce qui est une façon polie de dire « ils n’aiment pas les surprises ». Ils maintenaient une exportation automatisée mensuelle de l’inventaire de virtualisation : specs hardware des hôtes, comptes de cœurs, fonctionnalités activées, nombre de VM par niveau, et tendances de consommation de stockage.

C’était du travail ennuyeux. Ça ne faisait pas applaudir. Mais ça leur permettait de répondre rapidement aux questions difficiles : qu’est‑ce qu’on exécute, où ça vit, et combien ça coûte à maintenir ?

Quand le packaging des licences a changé, ils n’ont pas paniqué. Ils ont exécuté des scénarios à partir de leur inventaire, identifié des clusters avec capacité inutilisée, et déplacé des charges à faible risque hors des fonctionnalités premium. Ils ont aussi trouvé des VM « legacy » que personne ne possédait et les ont retirées après avoir validé l’impact métier avec les équipes applicatives.

Le résultat n’a pas été une migration héroïque de dernière minute. Ce fut une négociation calme appuyée par des données. Ils ont renouvelé une empreinte plus petite et lancé un pilote mesuré d’alternatives sans parier l’hôpital sur une bascule du week‑end.

La pratique qui a sauvé la mise n’était pas un produit. C’était de la discipline : inventaire, classification et gestion de capacité régulière.

Meilleures alternatives en 2026 (Proxmox inclus), avec compromis

Les alternatives sont réelles aujourd’hui. Pas parce que VMware a cessé d’être bon en virtualisation, mais parce que le marché a cessé d’accepter une taxe mono‑fournisseur comme inévitable. La meilleure alternative dépend de ce sur quoi vous comptez réellement : sémantiques HA, migration à chaud, intégration du stockage, écosystème de sauvegarde, fonctionnalités réseau, et le facteur humain — ce que votre équipe peut gérer à 03:00.

1) Proxmox VE (KVM + QEMU + LXC) : le favori pragmatique

Proxmox est populaire parce qu’il est simple : KVM pour les VM, LXC pour les conteneurs, clustering, migration à chaud, et plusieurs backends de stockage. Ce n’est pas « VMware gratuit ». C’est un système différent avec ses propres angles tranchants.

Où Proxmox brille :

• Contrôle des coûts : l’abonnement concerne surtout le support, pas des verrous de fonctionnalités, et vous pouvez choisir les niveaux.
• Transparence opérationnelle : c’est du Linux en dessous. Le debug n’est pas une boîte noire fournisseur.
• Stockage flexible : ZFS pour la résilience locale, Ceph pour le stockage distribué, NFS/iSCSI pour les baies externes.
• Itération rapide : mises à jour et patterns communautaires évoluent vite, et l’écosystème est vivant.

Où Proxmox mord :

• Vous assumez plus d’intégration : profondeur RBAC, intégration IAM et un certain polish des workflows d’entreprise demandent un vrai effort d’ingénierie.
• La justesse du stockage repose sur vous : ZFS et Ceph sont puissants, mais ils ne sont pas « set and forget ». Ils récompensent la compétence et punissent l’optimisme.
• Support fournisseur pour appliances : certains fournisseurs tiers n’approuvent que VMware, et s’en serviront pour refuser des tickets.

Mon avis tranché : Proxmox est la meilleure option pour sortir de la prison VMware pour les équipes prêtes à exploiter sérieusement Linux. Si votre organisation considère Linux comme un hobby étrange, corrigez ça d’abord.

2) Microsoft Hyper-V / Azure Stack HCI : le standard corporate

Hyper‑V est rarement excitant. C’est un compliment. Pour les environnements très Windows, c’est souvent le chemin de moindre résistance, surtout si vous utilisez déjà l’identité et les outils de management Microsoft.

Forces : bonne intégration Windows, base de virtualisation mature, large pool de talents opérationnels, et familiarité des achats.

Faiblesses : les guests Linux sont acceptables mais parfois moins polis opérationnellement, et l’histoire de la « solution complète » peut vous entraîner dans des stacks Microsoft adjacents non planifiés.

Qui devrait le choisir : organisations avec opérations Microsoft fortes et volonté de standardiser plutôt que d’expérimenter.

3) Nutanix AHV : plateforme intégrée, économie différente

Nutanix vend une plateforme : compute + stockage + management. AHV est la pièce hyperviseur. L’expérience peut être fluide, et opérationnellement c’est un produit cohérent.

Forces : management intégré, solide histoire HCI, bonnes operations day‑2 pour beaucoup d’environnements.

Faiblesses : vous échangez une histoire fournisseur pour une autre. Les coûts de sortie et la complexité contractuelle sont réels ; vous achetez un écosystème, pas juste un hyperviseur.

Qui devrait le choisir : équipes voulant une plateforme packagée et à l’aise avec la dépendance fournisseur si cela réduit la charge opérationnelle.

4) KVM/libvirt pur (DIY) : contrôle maximal, responsabilité maximale

Oui, vous pouvez exécuter KVM avec libvirt, Ansible et un backend de stockage choisi. Beaucoup de prestataires le font. C’est puissant et rentable.

Forces : contrôle total, friction de licence minimale, options d’automatisation profondes.

Faiblesses : vous construisez votre propre couche opérationnelle « vCenter‑like » — supervision, RBAC, workflows, garde‑fous. Si votre équipe est en sous‑effectif, le DIY devient « faites‑le vous‑même, seul, la nuit ».

Qui devrait le choisir : équipes avec maturité Linux/SRE forte et culture d’automatisation claire.

5) Cloud managé (IaaS) : l’option nucléaire parfois correcte

Déplacer des charges vers le cloud IaaS n’est pas tant une alternative à VMware qu’un modèle d’exploitation différent. Cela peut réduire la gestion du hardware et de l’hyperviseur, mais vous payez en conception réseau, gouvernance des coûts et limites de service.

Forces : élasticité, services managés, moins de douleur de cycle de vie du hardware.

Faiblesses : surprises de coût, gravité des données, et nouveaux modes de panne (IAM, quotas, incidents régionaux).

Qui devrait le choisir : équipes capables d’un FinOps cloud discipliné et avec des charges adaptées aux services managés.

Et conserver VMware en adaptant simplement ?

Parfois c’est la bonne démarche. Si vous avez :

• une profonde maturité opérationnelle VMware,
• une équipe plateforme stable,
• des appliances critiques de fournisseurs liées aux déclarations de support VMware,
• et un contrat négocié vivable,

…alors renouvelez, standardisez et arrêtez l’hémorragie. Mais faites‑le avec des données, et construisez quand même une rampe de sortie. « On ne partira jamais » n’est pas une stratégie ; c’est une note de prise d’otage écrite dans Excel.

Erreurs courantes : symptômes → cause racine → correctif

1) Symptôme : le devis de renouvellement explose après un refresh matériel

Cause racine : vous avez augmenté significativement le nombre de cœurs par hôte et votre modèle de licence évolue avec les cœurs ou des minimums de bundle.

Correctif : modélisez l’impact licence avant le refresh CPU. Envisagez moins de cœurs avec plus de fréquence si cela répond aux performances, ou rééquilibrez les clusters (gardez les hôtes à haute densité pour dev/test).

2) Symptôme : « VMware est lent » après consolidation

Cause racine : vous avez supprimé la marge ; les événements HA et la maintenance forcent maintenant la contention (CPU ready, files de stockage).

Correctif : imposez une politique de capacité : marge N+1 plus tampon de performance. Right‑sizez les VMs. Planifiez les jobs disruptifs (sauvegardes, scans) en tenant compte de la capacité du cluster.

3) Symptôme : vMotion marche mais la performance devient erratique

Cause racine : la redondance réseau est compromise (liens down, LACP mal configuré, MTU mismatch), ou les chemins de stockage sont dégradés.

Correctif : validez l’état des NIC et la santé du multipath stockage. Traitez le réseau et le stockage comme des dépendances de première classe, pas comme « le problème de quelqu’un d’autre ».

4) Symptôme : les sauvegardes prennent subitement deux fois plus de temps et impactent la production

Cause racine : sprawl de snapshots, incohérences CBT, ou hausse de la concurrence des sauvegardes sans tête de stockage suffisante.

Correctif : auditez les snapshots, ajustez la concurrence des sauvegardes, et isolez l’I/O des sauvegardes. Ne lancez pas « tous les jobs à minuit » sauf si vous aimez l’auto‑sabotage.

5) Symptôme : les tests de migration vers Proxmox bootent mais les applis se comportent bizarrement

Cause racine : pilotes invités (VMware Tools vs virtio), changements de nommage NIC, différences de contrôleur de stockage, ou différences de synchronisation temporelle.

Correctif : standardisez les pilotes invités et validez le boot + réseau + perf disque avec un plan de test. Traitez la préparation des guests comme un flux de travail de migration, pas comme une pensée secondaire.

6) Symptôme : la direction pense « on changera d’hyperviseur en un trimestre »

Cause racine : la complexité de migration est sous‑estimée : réseau, stockage, sauvegardes, monitoring, et déclarations de support des fournisseurs.

Correctif : présentez un plan en phases avec des tiers de charges et des tests d’acceptation. Calez les délais sur la réalité : contrôle des changements, fenêtres de maintenance, et plans de rollback.

Listes de contrôle / plan étape par étape

Plan A : renouveler VMware sans se faire dépouiller financièrement ou opérationnellement

1. Inventoriez tout : hôtes, cœurs, clusters, fonctionnalités activées, nombre de VM par niveau.
2. Right‑sizez les VMs : réduisez vCPU et RAM là où c’est sûr ; retirez les workloads morts.
3. Retirez les fonctionnalités premium accidentelles : si vous n’avez pas besoin des réseaux/stockages avancés partout, arrêtez de les utiliser partout.
4. Recalculez la marge : prouvez que vous pouvez survivre à la panne d’un hôte et toujours respecter les SLO.
5. Négociez avec des options : arrivez avec un plan crédible de phase‑out. Les fournisseurs tariferont différemment quand ils croiront que vous pouvez partir.
6. Documentez la posture de conformité : conservez des exports mensuels et des traces de changement.

Plan B : réduire l’empreinte VMware tout en gardant les charges critiques stables

1. Classez les workloads en : facile (apps sans état), moyen (serveurs Linux/Windows standards), dur (appliances fournisseurs, bases sensibles à la latence).
2. Choisissez une plateforme alternative pour les workloads « faciles » en premier (souvent Proxmox ou Hyper‑V).
3. Construisez la parité opérationnelle : monitoring, sauvegardes, patching, contrôles d’accès, journalisation.
4. Lancez un pilote avec 10–20 VM représentatives ; validez la performance et la reprise (tests de restauration, tests de bascule).
5. Déplacez ensuite les productions non critiques ; gardez des plans de rollback et des exécutions en double quand c’est possible.
6. Gardez VMware pour les workloads durs tant que l’alternative ne s’est pas prouvée ou que les fournisseurs n’ont pas mis à jour leurs déclarations de support.

Plan C : migrer hors de VMware de manière décisive (seulement si vous avez les effectifs)

1. Gelez le churn architectural pendant la fenêtre de migration ; arrêtez « d’améliorer » tout en même temps.
2. Standardisez le design réseau (VLANs, MTU, routage, firewalling) avant de déplacer les workloads.
3. Définissez des tests d’acceptation de migration : boot, santé applicative, latence, sauvegarde/restauration, monitoring, journalisation, accès SSO.
4. Automatisez autant que possible (conversion, provisioning, validation) pour réduire la variance humaine.
5. Faites des cutovers par vagues avec des critères de rollback clairs. Pas d’héroïsme.
6. Décomissionnez proprement : retirez les anciens hôtes, révoquez les accès, mettez à jour le CMDB, et arrêtez de payer pour des fantômes.

FAQ

1) ESXi est‑il toujours techniquement excellent en 2026 ?

Oui. La plupart des problèmes attribués à ESXi sont des problèmes de capacité, stockage, réseau ou processus. La douleur de 2026 est commerciale et liée au risque opérationnel, pas à l’ordonnancement CPU.

2) Quel est le piège de licence le plus fréquent ?

Ne pas savoir ce que l’on exécute réellement : comptes de cœurs, fonctionnalités activées, et clusters « temporaires ». L’inventaire est l’antidote.

3) Doit‑on consolider les hôtes pour réduire les licences ?

Parfois. Ne le faites qu’après avoir prouvé que vous pouvez survivre à la panne d’un hôte et à la maintenance sans vivre en contention. La consolidation sans marge est une attaque des SLO.

4) Proxmox est‑il une vraie option d’entreprise ?

Oui, si vous exploitez bien Linux et acceptez d’assumer davantage d’intégration. Il est particulièrement fort pour la virtualisation générale et pour les équipes qui aiment la transparence.

5) Proxmox est‑il « gratuit » ?

Le logiciel peut être utilisé sans abonnement, mais les environnements de production doivent budgétiser le support et le temps d’ingénierie pour construire des garde‑fous opérationnels.

6) Et les remplacements de vSAN ?

Les schémas courants sont : stockage externe (iSCSI/FC/NFS), ZFS sur disques locaux pour les petits clusters, ou Ceph pour le stockage distribué. Chacun a des modes de panne et des exigences opérationnelles différents.

7) Peut‑on migrer juste en convertissant les disques ?

La conversion des disques est la partie facile. La partie difficile est les pilotes invités, le réseau, la sauvegarde/restauration, le monitoring, l’identité et la validation de la reprise.

8) Quelle est l’approche de migration la plus sûre ?

Progressive : déplacez d’abord les workloads faciles, construisez la parité opérationnelle, puis attaquez les niveaux plus difficiles. Gardez VMware pour les appliances liées au support fournisseur tant que vous n’avez pas de plan.

9) Comment éviter la panique lors d’un audit ?

Automatisez les exports d’inventaire mensuels, étiquetez les workloads par niveau/propriétaire, et imposez un contrôle de changement sur l’expansion de cluster et l’activation de fonctionnalités.

10) Si on reste sur VMware, que doit‑on faire différemment en 2026 ?

Exploitez‑le comme un produit : SLOs de capacité, standards de configuration, inventaires récurrents, hygiène des snapshots, et revues architecturales liées à la réalité des licences.

Conclusion : les prochaines étapes qui réduisent réellement le risque

En 2026, les licences VMware ESXi ne sont pas seulement un événement d’achat. C’est une contrainte d’architecture et un multiplicateur de risque opérationnel. Vous ne pouvez pas l’emporter à l’argumentation, mais vous pouvez l’emporter à l’ingénierie.

Prochaines étapes pratiques :

1. Construire un vrai inventaire (cœurs, hôtes, fonctionnalités, niveaux de VM). Traitez‑le comme des données de production.
2. Right‑sizez et nettoyez : snapshots, VMs mortes, guests surdimensionnés, datastores à 90%+.
3. Réévaluez la marge : si la consolidation provoque de la contention, cessez d’appeler ça une optimisation.
4. Choisissez une rampe de sortie même si vous renouvelez : pilotez Proxmox ou Hyper‑V avec des workloads non critiques et construisez la parité opérationnelle.
5. Décidez avec des résultats de tests, pas avec de l’idéologie. Tests de boot, restauration, bascule — puis négociez ou migrez.

Si vous voulez la posture la plus pérenne : réduisez votre dépendance à un fournisseur unique en rendant vos workloads plus portables, votre inventaire plus précis, et vos pratiques opérationnelles moins magiques. L’hyperviseur n’est qu’une couche. Votre discipline est la vraie plateforme.