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 :

vdf -h
[root@monjoliserveurHP:~] vdf -h
Tardisk                  Space      Used
vmx.v00                   102M      102M
vim.v00                   112M      112M
(...)
imgdb.tgz                   1M        1M
state.tgz                  40K       38K
-----
Ramdisk                   Size      Used Available Use% Mounted on
root                       32M        3M       28M  12% --
etc                        28M      456K       27M   1% --
opt                        32M      120K       31M   0% --
var                        48M        9M       38M  19% --
tmp                       256M      256M        0B 100% --
iofilters                  32M        0B       32M   0% --
shm                      1024M        0B     1024M   0% --
hostdstats               1053M       20M     1032M   1% --
[root@monjoliserveurHP:~]

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 ».

[root@monjoliserveurHP:/tmp] /etc/init.d/ams.sh stop
[root@monjoliserveurHP:/tmp] chkconfig ams.sh off
[root@monjoliserveurHP:/tmp] ls -la /tmp
total 262164
drwxrwxrwt    1 root     root           512 Oct 10 09:52 .
drwxr-xr-x    1 root     root           512 Oct 10 09:49 ..
-rw-------    1 root     root             0 Sep 11 01:25 .VmkCtl.LOCK-cleanup.lock
lrwxrwxrwx    1 root     root            35 Oct 10 09:51 .simsOpLock.lock.LOCK -> /tmp/.simsOpLock.lock.LOCK.12380710
-rw-rw-rw-    1 root     root             0 Oct 10 09:51 .simsOpLock.lock.LOCK.12380710
-rw-r--r--    1 root     root     268361728 Aug 24 13:29 ams-bbUsg.txt
-rw-r--r--    1 root     root             0 Oct 10 09:52 ams-fc.txt
-rw-r--r--    1 root     root             0 Sep  7 01:02 ams-hrswrun.txt
-rw-r--r--    1 root     root           877 Oct 10 07:17 ams-ip.txt
-rw-r--r--    1 root     root           330 Oct 10 07:17 ams-ipv4.txt
(...)
-rw-r--r--    1 root     root             0 Sep  7 01:02 amshrsw.done
-rw-r--r--    1 root     root             0 Sep 23 01:01 amsiscsi.done
-rw-r--r--    1 root     root             0 Oct 10 07:17 amsnic.done
-rw-r--r--    1 root     root             0 Oct 10 07:17 amssas.done
-rw-r--r--    1 root     root             0 Oct 10 09:48 amssysmd.done
-rw-r--r--    1 root     root             0 Oct 10 09:20 bootbank.lck
-rw-------    1 root     root            40 Oct 10 09:50 probe.session
drwx------    1 root     root           512 Oct 10 09:49 ssh-XXXXaPIBH6
drwx------    1 root     root           512 Oct 10 09:20 vmware-root
-rw-r--r--    1 root     root             0 Oct 10 09:26 wbem-vm-report.xml

[root@monjoliserveurHP:/tmp] rm /tmp/ams*

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 »…