Un host ESXi Not Responding dans vCenter a l'air terrifiant et ne l'est presque jamais. La machine tourne en général sans broncher et continue à faire travailler ses VM comme si de rien n'était. Ce qui a vraiment lâché, c'est la connexion de management vers vCenter, un problème bien plus petit qui se déguise en catastrophe. Voici l'ordre dans lequel je procède, le plus rapide d'abord, du redémarrage des agents jusqu'au ré-ajout du host : confirmer que le host est bien up, redémarrer hostd puis vpxa, libérer une partition scratch ou de logs pleine, vérifier le chemin réseau sur les ports 902 et 443, puis reconnecter ou ré-ajouter. Et comment repérer le cas rare où le host est vraiment tombé.
The short answer
Un host passe en gris dans vCenter en Not Responding, mais la machine est presque
toujours encore en train de faire tourner ses VM. Tu as perdu le lien de management,
pas le host. Procède dans l'ordre : confirme que le host est bien up, redémarre hostd
puis vpxa, libère une partition scratch ou de logs pleine, vérifie que vCenter peut
joindre le host sur TCP 902 et TCP 443 dans les deux sens, puis reconnecte ou ré-ajoute.
Tu ouvres vCenter et le voilà. Un host passé en gris, marqué Not Responding (ou Disconnected), avec toutes ses VM coincées sur "unknown". Pendant des années, mon instinct me disait exactement ce que le tien doit te hurler là maintenant : le host est mort. Eh bien presque jamais. La machine tourne en général sans broncher et continue à faire travailler ses VM comme si de rien n'était. Ce qui a vraiment lâché, c'est la connexion de management vers vCenter, un problème bien plus petit qui se déguise en catastrophe. Celui-là, je l'ai traité plus de fois que je ne peux compter. Voici l'ordre dans lequel je procède, le plus rapide d'abord, du redémarrage des agents jusqu'au ré-ajout du host. Et comment repérer le cas rare où le host est vraiment tombé.
Ce que "Not Responding" veut vraiment dire
Voilà la tuyauterie. Sur chaque host tourne un agent appelé vpxa, et vpxa, c'est ce à quoi vCenter parle réellement. vpxa s'appuie sur le démon de management du host lui-même, hostd. vCenter attend un heartbeat à intervalle régulier. Quand ce heartbeat se tait, parce qu'un agent est tombé, ou que le réseau de management a sauté, ou que la partition de logs s'est remplie et a entraîné hostd avec elle, vCenter hausse les épaules et peint le host en Not Responding, VM unknown. Garde bien ça en tête : tes VM tournent presque toujours pendant toute la pagaille. Tu as perdu le tableau de bord, pas le datacenter. Du coup, le boulot, c'est de remettre l'agent ou le réseau en route. Pas de ressusciter un cadavre, parce qu'en général il n'y en a pas.
Étape 1 : confirmer que le host est bien up
Avant de toucher à quoi que ce soit, prouve que le host est vivant. Ping son IP de management. Ensuite ouvre la console, physique ou via la carte out-of-band (iLO, iDRAC, IPMI), bref ce que tu as sous la main. Ce que tu cherches, c'est un écran violet. Si tu en vois un, tu peux t'arrêter de lire ici : c'est un PSOD, une tout autre bête, et ça a son propre chemin de récupération. Mais si le host répond à ton ping et que la console affiche ce DCUI jaune-et-gris familier ? Parfait. Le host va bien, et tu as affaire à un problème d'agent ou de réseau à la place. Continue.
Étape 2 : redémarrer les agents de management
C'est l'étape qui mérite son salaire. Honnêtement, je crois qu'elle en règle plus à elle seule que tous les autres fixes réunis, même si je me trompe peut-être et que je tombe juste souvent sur des pannes pépères. Ouvre un shell sur le host : SSH si tu l'as laissé activé, sinon le DCUI à la console (F2, puis Troubleshooting Options > Restart Management Agents). Ensuite, relance hostd et vpxa. Un truc que j'ai appris à la dure. Redémarre hostd d'abord, vpxa ensuite. vpxa s'appuie sur hostd, donc si tu inverses l'ordre, vpxa remonte juste tout perdu.
/etc/init.d/hostd restart
/etc/init.d/vpxa restart
# or restart all management services at once:
services.sh restartMaintenant laisse-lui une minute. Reste pas planté là à matraquer le rafraîchissement toutes les deux secondes. Surveille juste le host dans vCenter et laisse-le respirer. La plupart du temps, il rebascule tout seul en Connected et c'est plié. Et si SSH n'a jamais été activé ? Pas de drame. Cette entrée Restart Management Agents dans le DCUI fait exactement le même boulot depuis la console.
Étape 3 : vérifier que la partition de logs n'est pas pleine
Donc tu as redémarré les agents et soit ils ont refusé de remonter, soit ils se sont recroquevillés dix secondes plus tard. Pénible. Le coupable est presque toujours le même truc barbant : une partition scratch ou de logs pleine. hostd a besoin d'un endroit où écrire, et quand il reste zéro octet de libre, il te lâche. Va voir :
vdf -h
# look at /var/log and the scratch location for 100% usageTu en trouves une bloquée à 100 % ? Vide ou fais tourner les logs gonflés pour que hostd puisse respirer. Mais ne t'arrête pas là. Trouve ce qui l'a remplie, sinon elle se re-remplit aussitôt : en général un agent tiers bavard, ou une erreur qui boucle indéfiniment en arrière-plan. Et si ce host boote sur une petite clé USB ou carte SD sans vrai scratch (j'en ai hérité bien trop de ce genre), pointe un emplacement scratch persistant vers un datastore. Ça évite que les logs noient ce minuscule support de boot toutes les quelques semaines.
Étape 4 : vérifier le chemin réseau vers vCenter
Le host est up, les agents tournent, et vCenter ne le voit toujours pas ? Alors quelque chose entre les deux fait barrage. Le moment de vérifier si vCenter peut réellement joindre le host sur les ports qui l'intéressent :
- Le TCP 902 (heartbeat et migration) et le TCP 443 (API de management) doivent tous les deux être ouverts dans les deux sens entre vCenter et le host. C'est celui que les gens loupent tout le temps, parce qu'ils vérifient dans un sens et estiment que c'est bon.
- Depuis une machine proche de vCenter, demande-lui simplement :
Test-NetConnection <host-ip> -Port 902. - Vérifie que le DNS direct et inverse du host résolvent bien tous les deux. vCenter est bizarrement pointilleux sur les incohérences de nom, et honnêtement un enregistrement PTR cassé va te mordre ici au moment où tu t'y attends le moins.
- Quelqu'un a touché au réseau récemment ? Un réglage de vSwitch, un changement de VLAN, une modif de VMkernel. N'importe lequel peut couper en douce le VMkernel de management sous tes pieds. Si c'est ce qui s'est passé, l'écran Configure Management Network du DCUI est là où tu corriges ça.
Étape 5 : reconnecter ou ré-ajouter le host
Le host est sain, le réseau est clean, et vCenter n'a toujours pas rattrapé le coup tout seul ? Très bien. Maintenant tu le pousses à reconstruire le lien :
- Clic droit sur le host puis Connection > Reconnect. Commence par là. C'est l'option la plus douce et très souvent tout ce dont tu as besoin.
- Si ça te renvoie une erreur d'agent, le vpxa du host a sans doute dérivé par rapport à vCenter. Grand classique juste après une mise à jour de vCenter. Sors le host de l'inventaire (clic droit > Remove from Inventory, et oui, ça laisse les VM totalement tranquilles) puis remets-le direct. vCenter redescend un vpxa tout frais qui correspond, et l'incohérence s'évapore.
- Tu as changé l'IP ou le nom du host récemment ? Tu vas probablement tomber sur une incohérence de certificat ou de thumbprint à la reconnexion. Accepte juste le nouveau thumbprint quand il te le demande et continue.
Sortir un host de l'inventaire et le ré-ajouter ne touche ni à tes VM ni à tes données, elles sont simplement ré-enregistrées directement depuis les datastores. Je l'ai fait sur des hosts de production sans rien perdre. Le hic : ne fais ça qu'une fois que tu es vraiment sûr que le host et son stockage sont sains. Ce que tu ramènes doit être un host known-good, pas une bestiole à moitié cassée à qui tu viens de redonner la confiance de vCenter.
Sources et pour aller plus loin
Questions fréquentes
Est-ce que mes VM sont down pendant que le host affiche Not Responding ?
En général non. C'est la partie qui calme tout le monde une fois qu'elle est bien comprise. Les VM continuent de tourner sans broncher. Tout ce que tu as réellement perdu, c'est la vue de vCenter sur elles. Tu ne peux sans doute pas les voir ni cliquer dessus dans vCenter tant que le host n'est pas reconnecté, d'accord, mais elles servent du trafic pendant tout ce temps. Ne me crois pas sur parole. Ping une VM, ou attaque son service directement, et regarde-la répondre.
C'est quoi le fix le plus rapide pour un host en Not Responding ?
Redémarrer les agents de management. C'est mon premier réflexe à chaque fois. Depuis le DCUI, c'est Troubleshooting Options, puis Restart Management Agents. En SSH, c'est /etc/init.d/hostd restart puis /etc/init.d/vpxa restart (hostd d'abord, vu que vpxa s'appuie dessus). La plupart du temps, le host est de retour en moins d'une minute et tu te demandes pourquoi tu as paniqué.
Pourquoi les agents de management n'arrêtent pas de crasher ?
Presque toujours une partition scratch ou de logs pleine qui étrangle hostd. Lance vdf -h, trouve ce qui est bloqué à 100 %, vide-le. Si c'est un host qui boote sur USB ou SD, fais-toi plaisir et configure un emplacement scratch persistant sur un datastore. Saute cette étape et les logs continueront à remplir ce minuscule support de boot, et tu reliras exactement cette réponse dans un mois.
Quels ports vCenter utilise-t-il pour gérer un host ?
Deux à retenir. Le TCP 902 porte le trafic de heartbeat et de migration. Le TCP 443, c'est l'API de management. Les deux doivent être ouverts dans chaque sens entre vCenter et le host, pas seulement en sortie. J'ai vu une seule règle de firewall égarée serrer un seul port et faire tomber un host direct en Not Responding, alors dans le doute, c'est le premier endroit où je vais creuser.
La reconnexion échoue avec une erreur vpxa ou agent. Et maintenant ?
C'est presque toujours une dérive de version. Le vpxa du host ne s'aligne plus avec vCenter, ce qui arrive souvent juste après une mise à jour de vCenter. Le fix qui ne m'a jamais lâché : sortir le host de l'inventaire (tes VM restent exactement où elles sont) et le remettre. vCenter pousse un vpxa tout frais qui correspond, et l'erreur disparaît juste.