ESXi 6.7 Purple Screen Qlogic 57xxx

ESXi 6.7 Purplescreen mit verbauten Qlogic 10 GBit Netzwerkkarten.

In der neuen Version von ESXi ist das Treiberpaket QLFE3 aktiv. Bei Qlogic Netzwerkkarten wird dieses aktiv. Auch gut zu erkennen, dass die VMHBA Bezeichnungen nach dem Upgrade verändert ist.

In meine Fall von VMHBA33 auf VMHBA68. Sobald der Netzwerkfluss zunimmt, stürzt z.B. ein HP Proliant DL360 Gen8 ab mit Purplescreen. Dell PowerEdge R630 läuft, aber das Management reagiert nicht mehr.

Im DiagnosticScreen sieht man aber schön den Fehler.

Via SSH kann man sich auf den Host anmelden. Mittels Befehl kann das QFLE3 Modul deaktiviert werden:

esxcli system module set --enabled=false --module=qfle3

Danach den Host neu starten und das bnx2 Modul wird wieder genutzt und es folgt kein Absturz mehr in Folge des QFLE3 Moduls.


Update 1:

Via VMware Support bekam ich einen aktuelleren Treiber zugestellt:

https://my.vmware.com/group/vmware/details?downloadGroup=DT-ESXI65-QLOGIC-QCNIC-10514&productId=614

In den nächsten Schritten wird nun ein Testhost mit dem Treiber gepatcht:

Der Treiber wird dazu via WinSCP auf den Host kopiert, anschliessend mit dem folgenden Befehl installiert:

esxcli software vib install –d /path/offline-bundle.zip

Danach wird das qfle3 Modul wieder aktiviert:

esxcli system module set --enabled=true--module=qfle3

 

Getestet wird das ganze dann mit einem künstlich bealdenen Host, in meinem Fall mit dem HA PoC, welcher 6 nested Hosts beinhaltet, damit auch ordentlich Traffic verursacht wird. Sollte der Host das während dem Wochenende überleben, sind wir das Problem auch los.


Update 2

Nachdem die ersten versuche gemacht wurden, musste ich feststellen, dass der neue Treiber auch keine Verbesserung erbracht. Hatte mich dann auf die Suche gemacht, nach aktuelleren Images, wobei HP keines geliefert hatte. Bei Dell wurde von Version A00 auf A01 gewechselt. Also her damit und testen. Leider wurde der Host nicht stabiler dadurch und war auch mit QFLE nicht wirklich produktiv zu nutzen.

Eine Nachfrage bei Dell oder HP macht hier kaum Sinn, da sie hier nur Hardwaresupport liefern und für den ESXi VMware zuständig ist.

Interessanterweise gibts aber News seitens VMware. Auf der Webseite zum ESXi Server wurde kürzlich in den Release Notes 6.7 folgende Einträge ergänzt.

Network flapping on a NIC that uses qfle3f driver might cause ESXi host to crash

The qfle3f driver might cause the ESXi host to crash (PSOD) when the physical NIC that uses the qfle3f driver experiences frequent link status flapping every 1-2 seconds.

Workaround: Make sure that network flapping does not occur. If the link status flapping interval is more than 10 seconds, the qfle3f driver does not cause ESXi to crash. For more information, see KB 2008093.

 

ESXi might fail during reboot with VMs running on the iSCSI LUNs claimed by the qfle3i driver

ESXi might fail during reboot with VMs running on the iSCSI LUNs claimed by the qfle3i driver if you attempt to reboot the server with VMs in the running I/O state.

Workaround: First power off VMs and then reboot the ESXi host.

Sprich derzeit bin ich guter Hoffnung, das VMware sich dem Problem bewusst ist. Die Lösung mit dem Abschalten des QFLE-Modules verzögert das ganze Problem ein wenig, aber führt trotzdem zu regelmässigen PSOD.

Am 20.07.2018 habe ich bei VMware erneut ein Ticket eröffnet, mit einem CoreDump und dem PSOD, mit abgeschaltetem QFLE. Bleiben wir gespannt.


Folgeproblem 1

Der Haken an deaktivierten qfle3 Modul war, dass die CIM von den HPE Servern ständig nach der Karte gesucht haben und diese nicht finden konnte. Das fürhte dann wiederum dazu, dass die Datei /var/log/EMU/mili/mili2d.log geflutet wurde und die Partition keinen Speicherplatz mehr hatte. Das wiederum führte dazu, dass auf de Host keine vMotion-Aktionen mehr ausgeführt wurden.

Das kann man so temporär lösen: Als erstes prüft man, wie es um den Speicher der Mountpunkte bestellt ist:

vdf -h

Ist der Mountpunkt /var voll und die Datei mili2d.log gut beladen, kann man diese einfach überschreiben mit >/var/log/EMU/mili/mili2d.log.


Des Problems Lösung

Nach vielen Tagen suchen, probieren und erforschen, ist das Problem endlich identifiziert.

Ein wenig zum Background. Die Anlage wird noch richtig legacy betrieben, sprich Datenspeicher, Rechenpower sind getrennt. Damit jeder Host sicher genügend Bandbreite bedienen kann, verfügen die Server über eine 4-Port 10GBE Karte von Qlogic. Davon ist Port 1 und 3 reserviert für iSCSI Traffic und Port 2 und 4 für den VM Traffic. Die Ports sind via Portbinding fest mit einem VMKernel verknüpft. Erschlossen sind die Server mit DAC Kabel der Firma... egal. Alle vom gleichen Typ und Produktionsdatum. Länge 7m.

Nun, wo finden wir nun das Problem? Erst mal im Voraus, wäre der Alarm "lost uplink redundancy" nicht deaktiviert gewesen, wäre man dem ganzen eine Spur schneller auf die Schliche gekommen.

So nun nach ein wenig ratlosem stochern lief irgendwann beläufig der VMKernel Log Monitor nebenbei gemütlich mit. Die Switches waren auch schon im Monitoring und eigentlich wartete ich nur auf eine Art Impact. Aber da war nichts. Und plötzlich war es da. Auf dem Port 3 wurde einfach mal so die Verbindung unterbrochen und wieder aufgebaut. Ok, das müsste ja der Switch eigentlich realisieren. Also Sprung auf den Switch, nein, der Port war seit Tagen online. Das Spiel wiederholte sich dann immer mehr und mehr, bis der Host in den PurpleScreen lief.

Ok, kurze Überlegung, das muss am Kabel liegen. Stecken wir also Port 1 und 3 um und schauen, was passiert. Das Problem blieb auf Port 3.

Ein erster Test lief dann weiter, indem einfach nur 1 Port gesteckt bleibt und siehe da, die ganze Problematik ist verschwunden. Aber das Problem muss gelöst werden können. Kabel hin und her stecken, brachte genau keine Änderung.

Erst der Wechsel auf den gleichen Typ DAC mit älterem Produktionsdatum hat schlussendlich dazu geführt, dass die Abbrüche nicht mehr auftauchen. Die Vermutung liegt also nahe, dass die Konstellation DAC aus dieser Produktionsreihe mit iSCSI und Portbindung Auslöser, dass der 2. Port begann, Unterbrüche zu produzieren.

Nun wenn man im Detail betrachtet: iSCSI, Portbinding und einem Switch Counter von 3 Paketen, kann man sich wage vorstellen, was ein ESXi mit knappen 60 VMs durchmacht, wird einfach mal ein iSCSI Uplink gedropped. Und einmal ist ja nicht genug, es artet aus in drops im Sekundentakt. Der Purple Screen muss da vorprogrammiert sein.

Inzwischen ist die Strecke ausgetauscht und der Wechsel dieser letzten DAC Kabel auf LWL war bereits in der Pipeline.

 


Drucken