« Ce correctif ESX va-t-il se poser sans redémarrer l’hôte ? » La réponse n’est ni « oui, parce que nous sommes en VCF 9.1 », ni « non, parce qu’ESXi a toujours rebooté ». Le live patch est une propriété du correctif et du cluster. Il faut qualifier les deux avant d’ouvrir le changement.
Cet article suit Nordwind Logistics, une organisation fictive qui exploite vcf-par-01. L’objectif est de trier le lot CHG-2026-0742 en deux piles : les correctifs applicables en mémoire, puis les exceptions qui devront passer par le rolling vSAN ESA.
Contrat de sincérité
Aucun lab VCF 9.1 n’a été exécuté pour cette série. Cette limite ne bloque pas le guide : les gabarits indiquent les informations à relever sur l’instance cible, et les résultats marqués RÉSULTAT_ATTENDU ne sont jamais présentés comme observés. Les assertions dépendantes du build ou du matériel doivent être vérifiées sur une plateforme de test.
TL;DR
- La release note du patch tranche :
Live Patchable,Host Reboot RequiredetVirtual Machine Migration or Shutdown Requiredsont les champs de décision. - Le cluster doit aussi être éligible : image vLCM, versions minimales, DRS actif, remédiation parallèle désactivée, aucun hôte déjà en maintenance mode, pas de DPU.
- L’action du lundi matin consiste à archiver ces trois champs, lancer le précheck par hôte et sortir toutes les exceptions du lot live avant toute remédiation.
L’éligibilité est une double porte
Deux patchs de sécurité ESX 9.1 peuvent avoir des contrats d’impact opposés. Les release notes de 9.1.0.0100 indiquent un patch live, sans reboot ni migration de VM. Celles de 9.1.0.0200 indiquent l’inverse. Le libellé « Security only image » ne suffit donc pas : seul le triplet publié dans la release note permet de router le changement.
| Champ à archiver | Pourquoi il compte | Décision |
|---|---|---|
Live Patchable |
confirme qu’une variante live existe pour ce patch | Yes ouvre le contrôle du cluster |
Host Reboot Required |
traduit l’impact sur l’hôte | Yes route vers le rolling |
Virtual Machine Migration or Shutdown Required |
traduit l’impact pour les workloads | Yes consomme une fenêtre applicative |
triage:
change_reference: CHG-2026-0742
cve: collect_from_release_notes
severity: collect_from_release_notes
patch_release: collect_from_release_notes
release_notes_url: archive_with_change
read_from_release_notes:
live_patchable: confirm_yes_or_no
host_reboot_required: confirm_yes_or_no
vm_migration_or_shutdown_required: confirm_yes_or_noHYPOTHÈSE_DE_DESIGN
Nordwind suppose un délai de correction de quatorze jours pour une CVE critique et une seule nuit d’arrêt par trimestre. Le live patch ne supprime pas la gouvernance du changement : il sépare les correctifs qui peuvent sortir du budget de fenêtre de ceux qui doivent y rester.
La deuxième porte est l’état réel du cluster. Un patch marqué live ne force pas un hôte inéligible à le devenir. Sur cl-fret-prod-01, le préflight doit contrôler cumulativement :
- le cluster est géré par une image vLCM unique ;
- vCenter est au minimum en 9.0 et ESX au minimum en 8.0 Update 3 ;
- DRS est activé — le mode entièrement automatisé reste le choix prudent ;
- la remédiation parallèle est désactivée ;
- aucun hôte n’est déjà en maintenance mode ;
- une variante live existe pour l’image de base ;
- un hôte avec TPM est au minimum en ESX 9.1 ;
- aucun hôte à DPU n’entre dans le lot.
preflight:
cluster: cl-fret-prod-01
current_esx_build: collect_from_cluster
gates:
image_managed: true
drs_enabled: true
parallel_remediation: false
hosts_in_maintenance: 0
live_variant_present: confirm_yes_or_no
tpm_requires_esx_9_1: true
dpu_hosts_in_scope: 0Le précheck de remédiation apporte ensuite la réponse la plus forte : il indique par hôte si un reboot ou un passage en maintenance mode est nécessaire. Cette réponse intègre l’état réel du serveur, là où la release note ne décrit que la capacité du patch.
Live patch, Quick Boot et reboot : trois contrats
Le mot « live » entretient une confusion coûteuse. Ces trois mécanismes réduisent l’impact, mais ils ne promettent pas la même chose.
| Live patch | Quick Boot | Maintenance mode + reboot | |
|---|---|---|---|
| L’hôte redémarre | non | oui, sans réinitialisation matérielle | oui, cycle complet |
| État de l’hôte | partial maintenance mode | maintenance mode | maintenance mode |
| VM évacuées | non | oui, ou suspendues en mémoire | oui |
| Interaction VM | FSR si vmx est touché |
suspension/reprise ou vMotion | vMotion |
| Upgrade de version | non | possible, mais pas avec suspend-to-memory | oui |
| Statut | DOCUMENTÉ | DOCUMENTÉ | DOCUMENTÉ |
Le live patch applique en mémoire des correctifs au vmkernel, à des daemons user space, à certains composants NSX et au runtime vmx. Un redémarrage de daemon peut faire apparaître brièvement l’hôte déconnecté de vCenter sans arrêter les VM. Si vmx est concerné, Fast-Suspend-Resume réalise une suspension et une reprise locales en mémoire, sans vMotion.
Quick Boot reste un reboot : il saute la séquence matérielle BIOS ou UEFI, mais l’hyperviseur est rechargé et l’hôte passe en maintenance mode. L’option suspend-to-memory n’est pas disponible pour un upgrade de version. Ce raccourci ne transforme donc jamais un rolling en opération live.
À_VALIDER_EN_LAB — activation par défaut
Un billet officiel VCF 9.1 annonce le live patch activé par défaut avec repli automatique sur reboot. Une KB et la documentation vSphere 9.0 décrivent un réglage désactivé par défaut. Sur un cluster construit avant 9.1 puis mis à niveau, il faut constater le réglage global et son éventuel override au niveau cluster.
Les exceptions FSR ne bloquent pas tout le lot
Certaines VM ne supportent pas Fast-Suspend-Resume : Fault Tolerance, DirectPath I/O, vSphere Pods ou clustering à disques partagés. Leur présence ne bloque pas le live patch du cluster. Le compliance scan doit les identifier avec leur motif ; elles peuvent rester sur l’ancien code après la remédiation.
| Cas Nordwind | Traitement proposé | Statut |
|---|---|---|
| VM FT du suivi de flotte | planifier un cycle applicatif séparé | HYPOTHÈSE_DE_DESIGN |
| base SQL en FCI à disques partagés | programmer une vMotion ciblée | HYPOTHÈSE_DE_DESIGN |
| vSphere Pods | ne pas promettre 100 % de conformité live | HYPOTHÈSE_DE_DESIGN |
| VM GPU en Enhanced DirectPath | qualifier la configuration réelle | À_VALIDER_EN_LAB |
La bonne unité de suivi n’est donc plus uniquement le cluster. Le dossier de changement doit conserver la liste des VM incompatibles, leur propriétaire et la méthode qui leur permettra de rejoindre l’image cible. Un badge vert agrégé ne remplace pas cette dette résiduelle.
Runbook : décider, appliquer, prouver
Le flux d’exploitation tient en six étapes.
- Lire la release note. Archiver les trois champs d’impact avec l’identifiant du patch et la CVE.
- Exécuter le preflight. Refuser le lot live si une condition cluster manque ; ne pas espérer que l’orchestrateur la contourne.
- Lancer le précheck par hôte. La nécessité de reboot ou de maintenance mode fait foi.
- Arbitrer les VM FSR-incompatibles. Les nommer avant le changement, puis affecter une action à leur propriétaire.
- Remédier séquentiellement. Le premier hôte devient le canari naturel puisque la remédiation parallèle est incompatible avec le live patch.
- Comparer l’état obtenu à l’image. Sortir les hôtes non éligibles vers le runbook rolling vSAN et les incidents d’orchestration vers le guide LCM.
Pièges à éviter
Ne pas déduire l’éligibilité depuis la sévérité de la CVE. Ne pas appeler Quick Boot « sans reboot ». Ne pas activer la remédiation parallèle sur le lot live. Ne pas forcer une VM incompatible FSR à disparaître du rapport : elle doit devenir une action tracée.
Les preuves qui ferment le changement
Une preuve utile comporte quatre niveaux. S’arrêter au premier revient à prouver que le correctif existe, pas qu’il est appliqué.
| Niveau | Preuve | Statut |
|---|---|---|
| Décision | champs de la release note archivés | DOCUMENTÉ |
| Environnement | précheck par hôte, avec besoin de reboot ou maintenance | DOCUMENTÉ |
| Exécution | aucune tâche de maintenance mode ou vMotion ; uptime inchangé |
RÉSULTAT_ATTENDU |
| Conformité | hôtes conformes à l’image ; restes expliqués par les VM FSR-incompatibles | RÉSULTAT_ATTENDU / À_VALIDER_EN_LAB |
Un hôte peut être Compliant, Non-Compliant, Incompatible ou Unknown. Il faut conserver le détail par hôte : Unknown ne signifie pas conforme, et Incompatible n’est pas un échec transitoire à relancer.
À_VALIDER_EN_LAB — preuve binaire
Les sources chargées documentent la conformité à l’image, mais pas le marqueur exact permettant de prouver le contenu binaire actif en mémoire après live patch. Si l’audit de sécurité exige un build par hôte, cette preuve doit être définie et testée avant publication du runbook.
Conclusion
Le patch décide
La catégorie sécurité ne suffit pas. Les trois champs de release note sont le contrat d’impact.
Le cluster confirme
Le précheck par hôte transforme une capacité théorique en décision exploitable.
La preuve ferme
Exécution, conformité et exceptions FSR doivent raconter exactement le même état.
La pile live peut maintenant sortir du budget de fenêtre. La pile reboot, les hôtes à DPU et les autres exceptions alimentent l’étape suivante : dérouler un rolling vSAN ESA sans confondre disponibilité et redondance.
Sources principales : configuration du live patch vLCM, prérequis KB 419942, release notes ESX 9.1.0.0100, release notes ESX 9.1.0.0200 et nouveautés vSphere dans VCF 9.1.
Reçois le prochain par email
Les nouveaux articles et séries, envoyés à leur publication. Aucun autre courrier.
