Keine RAID-Informationen mehr im vSphere Client

Von Zeit zu Zeit kann es vorkommen, daß der Hardware Monitor im vSphere Client keine Informationen mehr über den RAID-Controller anzeigt. Möglicherweise verschwinden die einzelnen Einträge nach und nach, bis der Controller irgendwann gar nicht mehr auftaucht.
Dieser Fehler könnte mit der aktuellen Version des CIM/SMIS Providers von LSI behoben worden sein.
Ansonsten gibt es einen Workaround. Wir loggen an der SSH-Konsole des ESXi ein und führen diesen Befehl aus:
[bash]/etc/init.d/sfcbd-watchdog restart >/scratch/log/sfcbd.log 2>&1[/bash]
Dies startet den SFCBD (Small Footprint CIM Broker Daemon, zuständig fürs Einsammeln und Abfragen der Sensordaten) neu. Die Umleitung in eine Dummy-Logdatei ist nötig, da der Watchdog ansonsten das Terminal alloziert hält, was zu dem Fehler “Warnungen “PTY Would block” im Kernel-Log” führt.

Warnungen “PTY Would block” im Kernel-Log

Symptom: Im Kernel-Log /scratch/log/vmkernel.log tauchen im Minutentakt Warnungen dieser Form auf:
[bash]Failed to crossdup fd 1, /dev/char/pty/t1 type CHAR: Would block[/bash]
Dies liegt daran, daß ein per SSH-Konsole ausgeführtes Kommando seine Verbindung zum virtuellen Terminal nicht geschlossen hat und versucht, dort Ausgaben zu tätigen. Wurde die Shell inzwischen geschlossen, existiert das Terminal nicht mehr.
Oft wurde der SFCBD-Watchdog ohne Umleitung in ein Dummy-File neugestartet, siehe “Keine RAID-Informationen mehr im vSphere Client”, oder aber die Systemdienste mittels/sbin/services.sh restart neugestartet, was den SFCBD-Watchdog einschließt.

Keine neuen Einträge in Logs

Falls ab einem gewissen Zeitpunkt keine Einträge mehr in die Logs (Syslog, Kernel-Log etc.) geschrieben werden, könnte einfach der Syslog-Daemon abgestürzt sein. Dies läßt sich auf der SSH-Konsole beheben durch einen Neustart des Syslog-Daemon:
[bash]esxcli system syslog reload[/bash]

Fehler beim Statusabruf der BBU im Syslog

Symptom: Im Syslog /scratch/log/syslog tauchen im Minutentakt solche Meldungen auf:
[bash]
2012-09-28T13:00:50Z sfcb-LSIESG_SMIS13_HHR[10850792]: INTERNAL StoreLibFacade::fireStorelibCommand – caller StoreLibFacadeMR::getBBUStatus, ProcessLibCommandCall failed, returnValue = 0x22
2012-09-28T13:00:50Z sfcb-LSIESG_SMIS13_HHR[10850792]: INTERNAL BBU::refresh: Failed BBUStatus
2012-09-28T13:00:50Z sfcb-LSIESG_SMIS13_HHR[10850792]: INTERNAL StoreLibFacade::fireStorelibCommand – caller StoreLibFacadeMR::getBBUCapacityInfo, ProcessLibCommandCall failed, returnValue = 0x22
2012-09-28T13:00:50Z sfcb-LSIESG_SMIS13_HHR[10850792]: INTERNAL BBU::refresh:Failed CapacityInfo
2012-09-28T13:00:50Z sfcb-LSIESG_SMIS13_HHR[10850792]: INTERNAL StoreLibFacade::fireStorelibCommand – caller StoreLibFacadeMR::getBBUDesignInfo, ProcessLibCommandCall failed, returnValue = 0x22
2012-09-28T13:00:50Z sfcb-LSIESG_SMIS13_HHR[10850792]: INTERNAL BBU::refresh:Failed DesignInfo
2012-09-28T13:00:50Z sfcb-LSIESG_SMIS13_HHR[10850792]: INTERNAL StoreLibFacade::fireStorelibCommand – caller StoreLibFacadeMR::getBBUProperties, ProcessLibCommandCall failed, returnValue = 0x22
2012-09-28T13:00:50Z sfcb-LSIESG_SMIS13_HHR[10850792]: INTERNAL BBU::refresh:Failed Properties[/bash]
“BBU” bedeutet “Backup Battery Unit”, gemeint ist eine Backupbatterie im RAID-Controller.
Ältere Versionen des LSI MegaRAID CIM-Providers haben einen Fehler, der diese Meldungen produziert. Sie sind im wesentlichen harmlos. Update auf eine aktuelle Version sollte das Problem komplett beseitigen.

10 Responses

  1. Hi,
    ich habe folgendes installiert
    VMW-ESX-5.0.0-lsiprovider-500.04.V0.38-0006-offline_bundle-1154845.zip
    vmware-esx-MegaCli-8.07.07.vib
    und bekomme laufend folgende Meldungen im Syslog

    2013-08-15T11:28:57Z sfcb-LSIESG_SMIS13_HHR[5795]: INTERNAL StoreLibFacade::fireStorelibCommand - caller StoreLibFacade::fireDCMDPassthru, ProcessLibCommandCall failed, returnValue = 0x2
    2013-08-15T11:28:57Z sfcb-LSIESG_SMIS13_HHR[5795]: INTERNAL StoreLibFacade::getLDGUIDList fireDCMDPassthru failed; rval = 0x2

    Jemand eine Idee?

      1. Hi Sven,
        ja, das habe ich. Wie ich die LSI-Provider-Libs deinstalliert hatte, war das Problem weg, aber halt auch das Monitoring. Auch nach der Neuinstallation traten die Meldungen wieder auf. Monitoring funktioniert, aber im Sekundentakt diese Logmeldungen. Das ist doch nicht gut. Anfrage beim Hersteller (LSI) blieb ohne Reaktion.

          1. Ich nutze bereits ESXi-5.1.0, und habe dort diese Probleme.
            Ich habe bei LSI ein Support-Ticket aufgemacht. Diese konnten den Fehler auf ihren System reproduzieren, konnten sich den Grund aber auch nicht erklären. Mir wurde seitens LSI mitgeteilt, dass es sich um einen unkritischen Fehler handelt. Ich bemerkte, dass ich es schon kritisch finde, wenn mein syslog derartig dichtgemüllt wird. LSI hat keine Lösung… Sehr unbefriedigend… Ich habe den LSIprovider nun deinstalliert.

  2. Same problem with 5.1 u1 IBM with VIB:
    lsiprovider 500.04.V0.38-0006
    vmware-esx-storcli-1.03.09
    vmware-esx-MegaCli-8.07.07
    2013-09-17T13:37:23Z sfcb-LSIESG_SMIS13_HHR[5745]: INTERNAL namespace in cmpi helper before conversion lsi/LSIMR13
    2013-09-17T13:37:23Z sfcb-LSIESG_SMIS13_HHR[5745]: INTERNAL namespace in cmpi helper after conversion lsi/LSIMR13
    2013-09-17T13:37:23Z sfcb-LSIESG_SMIS13_HHR[5745]: INTERNAL object path in cmpi helper is lsi/LSIMR13:LSIESG_DiskDrive.CreationClassName=”LSIESG_DiskDrive”,DeviceID=”65535_2″,SystemCreationClassName=”LSIESG_IntegratedRAIDController”,SystemName=”5005076043824e54″
    2013-09-17T13:37:24Z sfcb-LSIESG_SMIS13_HHR[5745]: INTERNAL StoreLibFacade::fireStorelibCommand – caller StoreLibFacade::fireDCMDPassthru, ProcessLibCommandCall failed, returnValue = 0x800E
    2013-09-17T13:37:24Z sfcb-LSIESG_SMIS13_HHR[5745]: INTERNAL StoreLibFacade::getLDGUIDList fireDCMDPassthru failed; rval = 0x800E

  3. Same problem with ESXi 5.5 IBM
    INTERNAL StoreLibFacade::getLDGUIDList fireDCMDPassthru failed; rval = 0x800E
    INTERNAL StoreLibFacade::fireStorelibCommand – caller StoreLibFacade::fireDCMDPassthru, ProcessLibCommandCall failed, returnValue = 0x800E

  4. Hi zusammen,
    selbes Problem hier, mit ESXi 5.5 Update 1.
    Hat jemand eine Lösung dafür?
    Beste Grüße