Référence des codes d'erreur VMware ESXi
Référence cherchable des erreurs VMware vSphere et ESXi avec la cause réelle et un correctif pas à pas pour chacune.
Cette référence des codes d'erreur VMware ESXi est la liste cherchable que je garde ouverte quand un hôte affiche un écran violet ou que vCenter dit juste Not Responding. Collez le code, le texte de la bannière rouge ou un symptôme à moitié retenu, et elle filtre en direct à travers les PSOD, le boot, le stockage (APD, PDL, verrous VMFS), le réseau, vMotion, HA, les snapshots, le licensing, vSAN et l'appliance VCSA. Ouvrez une erreur et vous obtenez la cause réelle, un correctif numéroté avec la commande esxcli ou PowerCLI à lancer, le log à lire et un moyen de vérifier que ça a marché. Tout le jeu de données est cuit dans la page, donc la recherche tourne en JavaScript sur votre machine. Rien de ce que vous tapez ne quitte le navigateur.
100% dans votre navigateur. Rien de ce que vous tapez ne quitte cette page.
Référence des erreurs VMware vSphere / ESXi, avec les correctifs
Une erreur ESXi ou vCenter, et aucune idée par où commencer ? Collez le code ou le message, même un symptôme à moitié retenu. Vous récupérez la cause et les étapes exactes pour corriger : la commande esxcli ou PowerCLI à lancer, plus le log qui vaut le coup d'oeil ou le service à redémarrer. Cliquez sur n'importe quelle erreur pour ouvrir la résolution complète, plus un moyen de vérifier que ça a vraiment marché. Il y a aussi un filtre par catégorie, pratique quand vous préférez parcourir tout le stockage, ou seulement les PSOD. Tout tourne dans votre navigateur, rien ne quitte la page.
Comment utiliser cette référence des erreurs VMware ESXi
Cette référence des erreurs VMware ESXi rassemble les pannes vSphere courantes pour que vous colliez un code ou un symptôme et obteniez la cause réelle plus un correctif numéroté. VMware tombe en panne d'une douzaine de façons différentes. Un écran de diagnostic violet (PSOD) sur l'hôte. Une bannière rouge dans le vSphere Client. Un retour esxcli cryptique qui ne vous dit presque rien. Ou juste un discret Host not responding qui traîne dans vCenter. Et voilà le truc agaçant : le même problème de fond apparaît formulé de façon complètement différente selon l'endroit où vous le surprenez. Du coup, cette référence couvre ESXi, vCenter et vSphere, et pour chacun elle donne la cause réelle et un correctif que vous pouvez lancer tout de suite. Collez n'importe quel bout du message dans la barre de recherche, ou filtrez par catégorie, puis ouvrez la fiche.
Franchement, la plupart des galères vSphere se rangent dans une poignée de familles. Un crash hôte (PSOD). Des échecs de boot et d'install. L'hôte qui perd son lien avec vCenter. Le stockage, qui est un monde à lui tout seul : APD, PDL, verrous de datastore, VMFS. Ensuite le réseau, tout ce qui touche à la migration et à la disponibilité (vMotion, HA, DRS), les snapshots, les VM qui refusent de démarrer, et VMware Tools qui fait des siennes. Trouvez la famille et vous avez en général trouvé à la fois le correctif et le log qu'il faut aller ouvrir.
Les logs et commandes qui résolvent la plupart des soucis VMware
- vmkernel.log (
/var/log/vmkernel.log) est votre premier arrêt pour les événements hôte, pilote et stockage, et tout ce qui gravite autour d'un PSOD. - hostd.log et vpxa.log quand c'est l'agent de gestion ou le lien vers vCenter qui a lâché.
- vmware.log vit à l'intérieur du dossier de chaque VM sur le datastore. C'est là que se cachent les erreurs de power-on et de disque propres à chaque VM.
- Besoin de redémarrer les agents de gestion ? C'est sans danger depuis le shell de l'hôte :
/etc/init.d/hostd restartet/etc/init.d/vpxa restart. - Vérifiez les chemins de stockage avec
esxcli storage core path list, les adaptateurs avecesxcli network nic list.
PSOD, APD et PDL : les familles qui piègent les gens
Un Purple Screen of Death stoppe net l'hôte ESXi et affiche l'exception, le module qui a planté et une backtrace. Le type d'exception est la partie qui vous en dit le plus. Une #PF Exception 14 (page fault), c'est presque toujours un pilote. Un LINT1/NMI matériel, ça veut dire mémoire ou composant qui agonise. Configurez d'abord une cible de coredump pour que l'hôte écrive bel et bien un dump que vous pourrez fouiller la prochaine fois, puis partez à la chasse au pilote, au firmware ou au composant défaillant. Côté stockage, deux états piègent les gens plus que tout. L'APD (All Paths Down) est une perte temporaire de tous les chemins où la baie pourrait encore revenir, donc ESXi se contente d'attendre et de réessayer. Le PDL (Permanent Device Loss), c'est la baie qui dit carrément à ESXi que le périphérique est parti pour de bon, repéré aux codes de sense SCSI. L'APD, c'est en général un souci de fabric, de zoning ou de contrôleur de baie à ramener. Le PDL veut dire que vous retirez le périphérique et remédiez le datastore. Confondez les deux et vous brûlerez des heures à courir après la mauvaise piste.
Confidentialité et fonctionnement de l'outil
Tout le jeu de données d'erreurs est juste là, dans la page, et la recherche tourne en local avec du simple JavaScript. Rien de ce que vous tapez n'est envoyé ni conservé où que ce soit. Chargez-la une fois et elle marche sans aucune connexion, pratique quand l'hôte qui vient de mourir était aussi votre passerelle.
Questions fréquentes
Qu'est-ce qui provoque un écran violet (PSOD) sur VMware ESXi ?
Presque toujours un pilote défectueux ou mal assorti. Le matériel qui lâche en provoque aussi, de la barrette mémoire qui agonise à la carte PCIe qui devient instable, tout comme l'épuisement du heap de stockage. Ce que ce n'est généralement pas, c'est ESXi lui-même. Lisez d'abord l'exception affichée à l'écran : une #PF Exception 14 pointe vers un pilote, un LINT1 ou NMI pointe vers le matériel. Mettez en place une cible de coredump, puis mettez à jour le pilote et le firmware incriminés, en les vérifiant contre la VMware HCL.
Comment réparer un hôte ESXi qui apparaît Not Responding dans vCenter ?
Commencez par redémarrer les agents de gestion depuis le shell de l'hôte : /etc/init.d/hostd restart et /etc/init.d/vpxa restart. Ensuite, assurez-vous que le réseau de management est bien up et que vCenter peut joindre l'hôte sur les ports 902 et 443. Faites maintenant un clic droit sur l'hôte et choisissez Reconnect. Si les agents refusent carrément de démarrer, le coupable habituel, c'est l'espace disque sur le scratch de l'hôte, donc vérifiez ça et le hostd.log.
Quelle est la différence entre APD et PDL ?
L'APD (All Paths Down) est temporaire. Le périphérique pourrait revenir, donc ESXi se contente de réessayer en espérant. Le PDL (Permanent Device Loss), c'est la baie qui vous dit franchement, via les codes de sense SCSI, que le périphérique est parti pour de bon. Et les correctifs ne se recouvrent pas non plus. L'APD est une histoire de fabric ou de baie que vous ramenez en ligne. Le PDL veut dire que vous retirez le périphérique mort, puis que vous remédiez les datastores et les VM qu'il a emportés avec lui.
Comment démarrer une VM qui dit que le fichier est verrouillé ?
Autre chose tient un verrou sur le VMDK ou le .vmx, soit un autre hôte, soit un processus zombie qui n'a jamais lâché. Lancez vmkfstools -D sur le fichier verrouillé et lisez l'adresse MAC dans la sortie, ça vous dit quel hôte le possède. Assurez-vous que la VM ne tourne vraiment pas là-bas. Ensuite, levez le verrou bloqué en redémarrant les agents de gestion sur l'hôte qui le détient, ou redémarrez cet hôte s'il le faut. Une règle quand même : ne supprimez jamais les fichiers .lck juste parce que vous êtes pressé.
Pourquoi je n'arrive pas à supprimer ou consolider un snapshot ?
En général l'une de deux choses. Soit le datastore n'a pas assez d'espace libre pour la fusion, soit un job de sauvegarde garde encore un handle ouvert sur le delta disk. Donc libérez de l'espace, au minimum la taille de toute la chaîne de delta, tuez toute sauvegarde qui touche à la VM, puis lancez Snapshot Consolidate. Si ça reste coincé, le vmware.log dans le dossier de la VM nomme le fichier exact sur lequel la fusion s'étrangle.