VMware ESXi 5.0 Known Issues at Hetzner

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.