Troubleshooting mit Treiber, Firmware und ESXi Versionen
Hardware Ausfälle sind in vSphere Clustern in der Regel keine große Sache. Nahezu jede Komponente ist redundant ausgelegt und bei Ausfall springt ein Ersatz ein. Schwieriger wird es, wenn eine Komponente nicht komplett ausfällt, sondern Fehlfunktionen zeigt. Ein so genannter Zombie ist viel kritischer, als ein Ausfall. Die Ersatzkomponente wird unter Umständen nicht einspringen, so lange noch irgendwelche Lebenszeichen von der gestörten Komponente kommen.
Ein solches Szenario erlebte ich bei dem geplanten Neustart eines Top-of-Rack (ToR) Switches. Der angeschlossene 10 Gbit Port eines ESXi Servers wurde nachhaltig gestört, aber er ist nicht ausgefallen.
Die aktiven Link-LEDs trotz entferntem Kabel sind ein untrügliches Kennzeichen, dass hier etwas nicht in Ordnung ist.
Der virtuelle Distributed-Switch (vDS) welcher den betroffenen vmnic als Uplinkport benutzte, war auf Static Port Binding eingestellt. Das bedeutet VMs werden statistisch einem dvUplink Port zugeteilt. Demzufolge war ein Teil der VMs im LAN erreichbar (über vmnic1), andere waren isoliert (vmnic0). Man würde in einer solchen Situation ein Failover erwarten, aber vmnic0 war nicht gänzlich ausgefallen. Daher machte keine VM und auch nicht der vMotion Kernelport ein Failover zum funktionalen vmnic1.
Es war daher auch nicht möglich, den Host zu evakuieren, da einer der beiden Multi-NIC-vMotion Kernelports ins Leere ging. Auch hier kein Failover. Sämtliche vMotion Operationen scheiterten.
Die einzige Möglichkeit war, den gestörten NIC aus dem dvSwitch zu entfernen. Danach mussten alle Portgruppen vmnic1 als einzig verbleibenden NIC verwenden und der Host konnte geräumt werden.
Analyse
Wie konnte es zu einer derartigen Störung kommen? Das Verhalten des NICs deutete sehr auf ein Problem in der Hardware hin. Möglicherweise eine ungünstige Treiber/Firmware Kombination. Um dies zu ermitteln mussten zunächst Informationen zu den Netzwerk Adaptern gesammelt werden.
esxcli network nic list
Der Adapter ist ein Emulex OneConnect OCe14000. Es handelt sich um einen LoM (LAN on Motherboard) Adapter, der als OEM (Original Equipment Manufacturer) Komponente im Server verbaut wurde. Also ein Emulex Chipsatz auf einem Board des Serverherstellers.
Wir benötigen nähere Informationen zu vmnic0.
esxcli network nic get -n vmnic0
Wir sehen, dass der Treiber elxnet in der Version 10.2.309.6v verwendet wird, mit Firmware 11.2.1194.36.
Zur Abfrage der VMware Hardware Compatibility List (HCL) benötigen wir die genaue Bezeichnung des Adapters, da wir es hier mit OEM Ware zu tun haben.
VID, DID, SVID und SSID
Um hier Klarheit zu schaffen, kann in der HCL nach der „Vendor-ID“ (VID), „Device-ID“ (DID), „Subsytem-Vendor-ID“ (SVID) und der „Subsystem-ID“ (SSID) gesucht werden. Die VID ist eine eindeutige Nummer, die den Hersteller des Chipsatzes identifiziert (z.B. Intel, Emulex oder Qlogic). Die Device-ID DID ist die Typenbezeichnung des Chipsatz-Herstellers. Oftmals werden die Chipsätze von Serverherstellern zugekauft und auf eigenen Platinen verbaut. Dafür gibt es die Subvendor-ID (SVID). Sie bezeichnet den Kartenhersteller (z.B. Dell, Fujitsu oder HPE). Diese Hersteller haben für ihre Produkte eine eigene Device-ID, die Subsystem-ID (SSID). Aus allen vier Kennziffern läßt sich das Gerät in der HCL genau bestimmen.
vmkchdev -l | grep vmnic0
Vendor ID (VID)= 10df
Device ID (DID)= 0720
Sub-Vendor ID (SVID)= 1734
Sub-Device ID (SDID)= 120e
VMware HCL
Mit diesen Imformationen kann man die VMware HCL abfragen. Im rot markierten Kasten sind die Werte für VID, DID, SVID und SSID zu sehen.
Es handelt sich um einen Emulex OCe14000-LoM, der als Fujitsu gelabelt ist. Tatsächlich wurde das Gerät mit einer Fujitsu Primergy RX2540 M1 ausgeliefert. LoM bedeutet LAN on Motherboard. Eine Steckplatine entscheidet über den Anschluss (SFP+, 10G T, 1G-T).
Die HCL gibt Informationen darüber, dass bestimmte Treiberversionen auch spezielle Firmware erfordern. Details zum Treiber kann man auf der CLI abfragen.
esxcli software vib list | grep elxnet elxnet 10.2.309.6v-1vmw.600.0.0.2494585 VMware VMwareCertified 2018-10-01 emulex-esx-elxnetcli 10.2.309.6v-0.0.2494585 VMware VMwareCertified 2018-10-01
Aus den Adapter Informationen hatten wir bereits ermittelt, dass wir Firmware 11.2.1194.36 verwenden. Für diese Firmware Version wird aber ein anderer Treiber empfohlen. Nicht die installierte Version 10.2.309.6v, sondern Version 11.2.1149.0 (roter Kasten).
Die vorhandene Firmware/Treiber Kombination (gelb) ist unter ESXi 6.0 nicht zertifiziert und muss korrigiert werden.
Treiber Download
Der geforderte Treiber ist nicht im Standard der verwendeten ESX Version 6.0 U3 enthalten und muss gesondert bereitgestellt werden. Der entsprechende Download Link ist in den Details [+] aufgeführt. Das Treiberpaket kann per Update-Manager oder per CLI verteilt werden.
Auch die Fujitsu Support Matrix für Broadcom Adapter (ex Emulex) bestätigt die Treiber / Firmware Kombination.
The following Broadcom CNA driver and firmware combinations have been tested and released on FUJITSU Server PRIMERGY Hardware with VMware ESXi versions 5.x and 6.x
Treiber Firmware Matrix für ESXi 6.0
ESXi Version / Treiber Name / Treiber Version / Firmware Version
Zusammenfassung
Nicht nur beim Systemupgrade ist auf Hardware Kompatibilität zu achten – auch bei Firmware-Updates ist Vorsicht geboten. Neue Firmware ist sicherlich eine gute Idee, da hierbei in der Regel Verbesserungen implementiert wurden, aber der verwendete Treiber muss zur Firmware passen.