Rognotudju du Jeudi : quand les agents HP plantent nos ESXi

NDLR: à propos des billets Rognotudju

Il y a des jours, des moments, ou on se trouve “assez seul” face à la complexité de notre métier. Il arrive même qu’on se dise qu’on est “pas aidés” par nos chers éditeurs/fournisseurs/intégrateurs/constructeurs. S’empare alors de nous un sentiment de lassitude et de ras-le-bol, qui peut durer quelques temps, avant de s’estomper progressivement. C’est ce sentiment qui prévaut, en ce moment même, alors que j’écris ces lignes, concernant un problème de prod auquel nous sommes épisodiquement confrontés. Oh, je vous rassure, rien de très grave, mais cela nous consomme à chaque fois de l’énergie et du temps, qui finit par s’accumuler au fil des années. Aujourd’hui, désolé que ça tombe sur eux, je vais vous parler de HP et ses foutus agents sur ESXi.

Le fait est que, c’est comme ça : HP fait globalement du très bon matériel et est reconnu pour ça. Cependant, une forme, peut-être, d’héritage de l’acquisition de Compaq (dont les moins de 35/40 ans ne peuvent pas connaître) … ils ne savent pas faire de matériel “standard” ou, tout du moins, assez standard pour fonctionner avec des images natives de VMware ESXi. Résultat, nous sommes obligés d’utiliser des images spécifiques, fournies par VMware, certes, mais intégrant des agents et drivers complémentaires.

La conséquence directe, hormis le fait d’être obligé d’avoir deux images distinctes d’ESXi sur notre infra équipé de HP Proliant mais aussi de Dell PowerEdge. Conséquence indirecte, nous ne pouvons, depuis des années, constater que les fameux “ajouts HP” sur les images hyperviseurs les rendent sinon instables, du moins plantogènes au niveau de la couche de supervision (hostd, vpxa, fpm etc. …). Récemment, j’ai constaté que le démon “AMS” spécifiques aux Proliant remplissait régulièrement les /tmp de nos ESXi, rendant toute forme de mise à jour ou reconfiguration plus qu’aléatoire et provoque régulièrement la déconnexion desdits serveurs de nos vCenter, les rendant quasi impossible à administrer. Même le bon vieux démon SSH ne fonctionne plus, ne nous laissant plus que l’accès console encore valide.

HP documente ce problème depuis des années (j’en trouve des traces sur le net depuis 2014) et conseille le plus simplement du monde d’arrêter les démons ams. Ben voyons. En gros : “ça plante, on est désolé, arrêtez le machin et ça plantera plus”.

Du coup, effectivement, ça re-fonctionne, mais dans ce cas, expliquez-moi pourquoi ça n’est pas débuggué ou a minima retiré de l’image ESXi ? Ca me dépasse…

En attendant, j’ai été obligé de monter un petit dashboard Log Insight pour superviser spécifiquement le symptôme le plus commun qui présage un futur plantage ou un souci d’administration sur les ESXi “HP” (et nous en avons beaucoup…).

La solution de contournement, pour le moment, c’est de désactiver complètement le démon AMS sur les machines exposées (pas forcément toutes).
Après connexion au serveur, on peut constater rapidement que le /tmp est bien rempli :

On arrête le démon et on le supprime du démarrage. Ensuite, on se précipite dans le /tmp et on supprime très vite les fichiers “log/stats”.

Voila qui devrait faire le plus grand bien à la machine en question…

On est pas aidé, moi’j’vous l’dit…

NDLR: c’est pas la première fois que j’en parle en plus, voyez plutôt ici, déjà en 5.5 on avait des annuis avec ce “machin”…