Un lot LCM s’arrête au milieu de CHG-2026-0742. Le mauvais réflexe consiste à cliquer sur Retry. Le bon commence par une question plus froide : qu’est-ce qui a réellement changé dans le parc ? Tant que la réponse n’est pas établie par composant et par tâche, une relance transforme un incident lisible en état composite.
Cet article consomme les sorties du live patch ESX et du rolling vSAN ESA. Le parc vcf-par-01 peut être partiellement patché, certains hôtes peuvent avoir été exclus, et l’orchestrateur doit reprendre au bon niveau.
Contrat de sincérité
Il n’existe pas de guide TechDocs 9.1 unique consacré au dépannage LCM. L’arbre de reprise assemble le modèle lifecycle, les problèmes connus 9.1 et les KB Broadcom sur les verrous. Aucun lab n’a été exécuté : cela ne bloque pas le guide, mais impose de vérifier sur une plateforme de test les libellés, états et chemins dépendants du niveau de patch. Aucun chemin de log non sourcé n’est inventé.
TL;DR
- VCF 9.1 orchestre une version cible sur deux plans : les composants de gestion au niveau fleet, les composants cœur au niveau instance et domaine.
- Un statut de lot terminé peut précéder la fin des tâches unitaires ; Component Versions et les tâches actives font foi avant toute relance.
- L’action du lundi matin consiste à trancher trois questions : le lot a-t-il démarré, quel plan a rompu, et l’état affiché correspond-il aux ressources réelles ?
Le modèle LCM est déclaratif et à deux plans
L’exploitant déclare une version cible ; VCF Operations planifie les binaires, les dépendances et l’ordre. En 9.1, l’appliance Fleet Management autonome a disparu au profit du fleet lifecycle.
Le software depot fournit les binaires d’installation, d’upgrade et de patch ainsi que les images OCI et les données de compatibilité. Il peut être connecté, offline ou déconnecté. Nordwind utilise un dépôt fleet-level en mode offline.
| Plan | Composants | Reprise typique |
|---|---|---|
| Fleet | VCF Operations, services de gestion, VCF Automation, Identity Broker | précheck et reprise composant par composant |
| Instance | SDDC Manager, vCenter, NSX Manager | restauration depuis sauvegarde ou instantané pré-upgrade, avec support |
| Domaine | clusters et hôtes ESX | exclusion de cibles, nouveau lot, retry policy |
change: CHG-2026-0742
window: MW-2026-Q3-01
instance: vcf-par-01
depot:
scope: fleet-level
mode: offline
binaries_ready: confirm_target_version_in_depot
nature: classify_patch_or_maintenance_release
scope:
fleet: mandatory
management_domain: mgmt-par
workload_domains:
- name: wld-fret-prod
mode: day-nUne release de maintenance impose un ordre entre composants et un nouveau BOM. Un patch n’est pas synchronisé entre tous les composants, ne demande pas de nouveau BOM et peut cibler les composants nécessaires, sauf ordre explicite dans ses propres release notes.
| Patch | Release de maintenance | |
|---|---|---|
| Synchronisé entre composants | non | oui |
| Nouveau BOM | non | oui |
| Choix des composants | possible | séquence de cible cohérente |
| Ordre | besoin métier, sauf instruction du patch | ordre lifecycle publié |
| Statut | DOCUMENTÉ | DOCUMENTÉ |
Le sens de marche est unique
VCF n’autorise qu’une version cible publiée après la version courante. Redéclarer une cible antérieure n’est pas une stratégie de rollback. Un plan de changement doit donc trancher sa posture de restauration avant l’exécution.
Les prechecks valident le plan, pas toute l’exécution
VCF 9.1 utilise davantage les prechecks natifs des composants. Les résultats peuvent être exportés en CSV ; cet export est l’artefact à joindre au changement, puis à comparer après remédiation.
Les cas publiés montrent ce que les contrôles savent détecter : incompatibilité de BOM, composant tiers hors matrice, configuration NetFlow qui bloque un upgrade vCenter ou compatibilité matérielle des hôtes. Mais les problèmes connus publient aussi leurs angles morts :
Run Prechecks (ALL)peut échouer à cause d’une spécification d’entrée résiduelle ; le contournement consiste à lancer les contrôles composant par composant ;- Log Management 9.x vers 9.1 ne supporte pas le precheck fleet lifecycle malgré l’option visible ;
- un precheck réussi ne dit rien d’une resynchronisation vSAN encore active, d’un hôte sans chemin DRS ou d’un verrou laissé par une tâche précédente.
RECONSTITUTION
Le precheck photographie le plan de contrôle à un instant T : versions, interopérabilité, configuration et matériel. Les articles précédents ont montré que l’incident apparaît souvent plus bas, dans l’évacuation, le placement des données ou l’exécution d’une ressource.
La séquence Nordwind est donc : lancer les prechecks, corriger les erreurs, exporter le CSV, relancer par composant, puis conserver le second export. Réduire le périmètre avant cette comparaison masquerait un défaut qui reviendrait dans le lot suivant.
Lire l’état réel avant de relancer
L’onglet Component Versions centralise les versions courantes et cibles des composants gérés. C’est la première vue pour répondre à « qu’est-ce qui est réellement passé ? ».
Elle ne suffit pourtant pas. Un problème connu vSphere 9.1 indique que le statut agrégé d’un bundle peut être terminé alors que des upgrades d’hôtes sont encore actifs. La conclusion opérationnelle est ferme : les tâches unitaires font foi avant le badge du lot.
state_read:
target_version: collect_from_lifecycle_plan
component_versions:
fleet: collect_from_component_versions
instance: collect_from_component_versions
domain: collect_from_component_versions
active_resource_tasks: collect_from_resource_tasks
aggregate_batch_status: collect_from_batch
states_match: confirm_yes_or_noRÉSULTAT_ATTENDU : chaque composant affiche version courante égale à version cible, aucune tâche unitaire n’est active et l’inventaire liste tous les composants attendus. Ces sorties doivent être capturées sur l’instance réelle ; elles n’ont pas été observées pendant la recherche.
À_VALIDER_EN_LAB — libellés et logs
Les libellés exacts peuvent évoluer avec le niveau de patch 9.1. Aucun chemin de log fleet lifecycle ou SDDC lifecycle côté VCF Operations n’a été vérifié. Le seul chemin sourcé dans ce guide est /var/log/vmware/vcf/lcm/lcm-debug.log côté SDDC Manager pour le cas de verrou.
Diagnostiquer dans le bon ordre
Trois questions ferment progressivement l’espace de recherche.
1. Le lot a-t-il démarré ?
Un workflow qui passe presque immédiatement en CANCELLED peut ne pas avoir acquis le verrou de déploiement. Une tâche antérieure en échec a laissé un resource lock ; aucun composant du nouveau lot n’a encore été modifié.
Le contrôle publié est en lecture seule :
curl localhost/locks | jqRelancer sans lever le verrou reproduit l’échec. Modifier directement la table de verrous est une autre décision, traitée plus bas.
2. Quel plan a rompu ?
Une rupture fleet, une appliance cœur partiellement upgradée et un hôte ESX resté en maintenance mode n’ont ni le même rayon d’impact ni la même reprise. Localiser le plan précède la recherche d’une commande.
3. L’état affiché est-il réel ?
Comparer le statut agrégé, Component Versions et les tâches unitaires. Une interface qui charge indéfiniment n’est pas forcément un workflow bloqué : après certains upgrades SDDC Manager, le cache navigateur peut provoquer ce symptôme ; une fenêtre privée permet de le distinguer d’un incident serveur.
| Symptôme | Premier contrôle | Reprise |
|---|---|---|
CANCELLED immédiat |
verrous de ressources | lever le verrou, puis rejouer |
Run Prechecks (ALL) échoue |
precheck composant par composant | conserver les CSV, corriger la cause |
| badge terminé, tâches actives | liste des tâches unitaires | attendre ; aucune relance |
| hôte bloqué en maintenance | DRS et évacuation des VM | vMotion manuelle ou arrêt planifié |
| composant absent de l’inventaire | inventaire VCF Operations, proxy SSL | appliquer le contournement publié |
| page Lifecycle en chargement infini | session privée | distinguer cache et incident réel |
Reprendre selon le plan touché
| Périmètre | Mécanique documentée | Limite |
|---|---|---|
| verrou avant travail | libération puis relance | ne corrige pas la cause initiale |
| fleet | precheck et reprise du composant | une seule opération à la fois |
| instance | sauvegarde ou instantané pré-upgrade | aucune procédure de rollback générique |
| domaine | exclusion d’hôtes, nouveau lot, retry policy | ne réconcilie pas un hôte en maintenance |
Côté domaine, un échec de cluster n’arrête pas nécessairement les autres. Les clusters ou hôtes en échec peuvent alimenter un nouveau lot, même avant la fin du lot original. Des hôtes peuvent être explicitement exclus et une retry policy peut absorber les erreurs transitoires.
Le parallélisme porte sur les clusters, pas sur les hôtes d’un cluster vSAN. À l’intérieur d’un cluster, la règle du rolling ESA reste un hôte en maintenance mode à la fois.
recovery:
lock_cleared: confirm_yes_or_no
component_prechecks_replayed: confirm_yes_or_no
excluded_targets: record_target_list
retry_batch: record_batch_id
excluded_target_batch: record_batch_idPièges à éviter
Ne pas relancer sur un statut agrégé seul. Ne pas créer un plan de patch tant qu’un plan d’upgrade existe. Ne pas mélanger parallélisme de clusters et parallélisme d’hôtes vSAN. Ne pas restaurer une appliance isolée sans considérer la cohérence de l’inventaire qui a continué d’avancer.
Rollback, verrous et fermeture de fenêtre
La documentation ne publie pas de procédure générique pour ramener en arrière un composant VCF déjà upgradé. Elle publie en revanche des filets de sécurité avant l’opération : sauvegarde du composant, instantané des nœuds VCF Operations, sauvegarde du contenu personnalisé, puis suppression des instantanés après réussite.
Pour les hôtes, la mécanique documentée avance : exclusion, nouveau lot et retry policy. Pour les appliances, la restauration partielle pose une question ouverte de cohérence d’inventaire. À_VALIDER_EN_LAB : tant que cette cohérence n’est pas prouvée, ouvrir un dossier de support avant toute restauration isolée.
Les KB Broadcom divergent sur la levée des verrous. Une KB couvrant VCF Operations 9.x et SDDC Manager 9.x demande de contacter le support. D’autres publient une intervention directe en base après instantané, mais leur périmètre de version est hétérogène. HYPOTHÈSE_DE_DESIGN : lecture des verrous en autonomie ; écriture dans la base uniquement avec le support.
La fenêtre se ferme seulement quand :
- la nature patch ou maintenance est archivée avec son ordre ;
- les exports CSV des prechecks initial et rejoué sont conservés ;
- aucun verrou ni tâche unitaire ne subsiste ;
- Component Versions est aligné sur la cible ;
- aucun hôte ne reste en maintenance mode ;
- l’inventaire VCF Operations contient tous les composants attendus ;
- les instantanés temporaires sont retirés et une nouvelle sauvegarde est prise.
Conclusion
Lire avant de relancer
Versions de composants et tâches unitaires priment sur le badge agrégé du lot.
Localiser le plan
Fleet, instance et domaine ont des rayons d’impact et des reprises différents.
Reprendre en avant
Exclusion, nouveau lot et retry policy sont documentés ; le rollback générique ne l’est pas.
La boucle trimestrielle est complète : appliquer en mémoire ce qui peut l’être, dérouler le reste hôte par hôte, puis reprendre l’orchestration au niveau exact où elle a rompu. Le socle architectural reste détaillé dans VCF 9 expliqué aux architectes.
Sources principales : modèle lifecycle VCF 9.1, lifecycle des composants VCF, problèmes connus VCF Operations 9.1, upgrade ESX dans VCF 9.1 et KB 418563 sur les resource locks.
Reçois le prochain par email
Les nouveaux articles et séries, envoyés à leur publication. Aucun autre courrier.
