VxRail : L’hôte ESXi ne répond pas dans vCenter et le problème se reproduit après le redémarrage de l’hôte pendant plusieurs jours

Il peut arriver que certains hôtes ESXi ne répondent pas dans vCenter. Le redémarrage de l’hôte peut résoudre le problème temporairement, mais après plusieurs jours, le problème se reproduit. Ce problème se produit uniquement sur les serveurs Dell PowerEdge 14G avec iDRAC9.

Dans le journal TSR, un message tel que :

2019-06-04 15:26:05 ISM0049 The iDRAC Service Module (iSM) is unable to communicate to the iDRAC because the client certificate is either unavailable or invalid.

En vmkernel.log,

2019-06-04T02:05:56.920Z cpu61:2105520)WARNING: VisorFSObj: 1576: Cannot create file /etc/cim/dell/srvadmin/iSM/ini/tttttttttttttyZxIL9 for process sfcb-dcism because the inode table of its ramdisk (etc) is full.

En hostd.log,

2019-06-02T13:39:59.688Z error hostd[2105490] [Originator@6876 sub=Libs opID=e4a0107a-853b-11e9-f2a3 user=dcui:vsanmgmtd] VsanUtil: Failed to lock esx.conf /etc/vmware/esx.conf.LOCK.2104629: symlink failed: No space left on device

Dans l’interface utilisateur de l’iDRAC :

L’iDRAC9 v3.30.30 a introduit une exigence obligatoire pour créer un canal TLS sécurisé avec iSM v3.4.0-1471 ou une version ultérieure.

Les ingénieurs Dell ont identifié un scénario dans lequel une fuite de mémoire se produit si l’iDRAC9 n’a pas encore négocié cette connexion TLS sécurisée si l’iSM v3.4.0-1471 a été installé ou mis à niveau avant la mise à niveau du firmware de l’iDRAC. La fuite finit également par entraîner une perte du nombre d’inodes du noyau en raison d’un flot de fichiers INI temporaires créés dans /etc/dell.

Les versions logicielles VxRail 4.5.400, 4.7.200 et supérieures intègrent l’iSM v3.4.0-1471. Une solution de contournement pour éviter ce problème a été ajoutée aux versions 4.5.400 et 4.7.212. La version 4.7.210 n’est pas concernée, car il s’agit d’une version de fabrication uniquement. Il n’y a donc aucune mise à niveau. Par conséquent, les versions VxRail 4.7.200 et 4.7.211 sont les plus susceptibles de rencontrer ce problème.

Redémarrez l’hôte ESXi s’il ne répond pas dans vCenter.

La réinstallation de l’iSM peut déclencher la renégociation du canal TLS sécurisé avec l’iDRAC9 et résoudre le problème.

Sur les hôtes ESXi concernés, exécutez les commandes suivantes pour réinstaller l’iSM.

esxcli software vib remove -n dcism
esxcli software vib install -d <path to iSM VIB>

S’il n’y a pas d’inode disponible dans ESXi, vous pouvez d’abord supprimer les fichiers inutiles, car ce problème peut également entraîner un manque d’inode.

ls -l /etc/cim/dell/srvadmin/iSM/ini/
rm -f /etc/cim/dell/srvadmin/iSM/ini/tttttt*

Si la carte système a été remplacée en raison d’une défaillance matérielle, les étapes de résolution ci-dessus s’appliquent également.