Für ESXi 7.0 GA wurde am 23. Juni 2020 ein Patch veröffentlicht, der einige Sicherheitskorrekturen und Bugfixes mit sich bringt. Die Version wird damit von ESXi 7.0 GA auf ESXi 7.0b angehoben.
Üblicherweise aktualisiere ich die Hosts in meinem Homelab sehr zeitnah. Da alle Hosts im Einklang mit der HCL sind, entschied ich mich für ein vollautomatisiertes Update durch den vSphere Lifcycle Manager (vLCM).
Die Spezifikation
| Server | SuperMicro SYS-E300-9D-8CN8TP |
| BIOS | 1.3 |
| ESXi | 7.0 GA build 15843807 (zuvor) / 7.0b build 16324942 (danach) |
| HCL | ja |
Nach dem ersten Host-Neustart bemerkte ich eine Warnleuchte am Servergehäuse und auch die Lüfter drehten mit maximaler Geschwindigkeit (was nicht zu überhören ist). Ein kurzer Blick ins IPMI zeigte, dass die CPU Temperatur einen kritischen Wert erreicht hatte.
Wie man im Screenshot erkennen kann, ist die Gehäusetemperatur moderat und die Lüfter drehen bei diesen Bedingugen normalerweise mit geringer bis mittlerer Drehzahl. Die Temperatur der Ansaugluft betrug 25°C. Im Bild unten kann man sehen, dass nur Lüfter 1+2, welche für die Kühlung der CPU verantwortlich sind am Maximum arbeiten. Lüfter B, der PCI und LAN Komponenten kühlt, dreht weiterhin mit niedriger Leistung.
Meine ESXi Knoten starteteten nach dem Update korrekt mit der neuen Buildnummer 16324942 und es gab keine Fehlermeldungen im vLCM. Man konnte jedoch deutlich hören, dass etwas nicht in Ordnung war. Ein 4cm Gehäuselüfter der am Maximum dreht, teilt einem das unmissverständlich mit. Auffallend war ausserdem, dass der Bootvorgang deutlich länger dauerte als üblich.
Ich habe den Cluster schnellstens herunter gefahren, um eine Kernschmelze in der CPU zu vermeiden.
Zuerst prüfte ich, ob etwas den Luftstrom versperrte und somit zum Hitzestau führte. Aber das war nicht der Fall und es würde auch nicht erklären, warum 4 Hosts das gleiche Phänomen nach dem Update zeigten.
Ich wiederholte die Untersuchung, indem ich einen Host beim Bootvorgang genau beobachtete. Ich ließ ihn zunächst auf Raumtemperatur (25°C) abkühlen und startete dann einen neuen Versuch. Solange sich der Host in BIOS und Power-On Selftest (POST) befand, blieb die CPU Temperatur normal. Auch solange ESXi seine Treiber lud war keine signifikante Erhöhung bemerkbar. Jedoch beim Übergang vom schwarzen zum gelb-grauen Bootbildschirm (wenn das VMkernel geladen wird) stieg die Temperatur binnen 2 Sekunden von 60°C auf kritische 98°C an. Dieses Verhalten war reproduzierbar auf allen Hosts.
Hardware oder Software?
Zum Ausschluss eines Hardwareproblems bootete ich einen Host mit einem Ubuntu Live Linux. Die Temperatur stieg nicht an. Von anfänglichen 61°C sank sie innerhalb 4 Minuten auf 52°C. Wir können also einen Hardwaredefekt, oder fehlerhafte Einstellungen ausschließen.
Der Cluster arbeitete problemlos unter ESXi 7.0 GA (Build 15843807). Somit wäre ein Rollback einen Versuch wert.
Rollback auf 7.0 GA
ESXi bietet eine Recovery Boot Funktion. Sobald der Bootloader erscheint muss die Tastenkombination [Shift] + [R] gedrücht werden, woraufhin man in einen Recovery Dialog gelangt (Bild unten).
Man kann hier beide installierten Versionen sehen. Die aktuelle 7.0b ist der Standard auf Bootbank 5. Die vorherige Version 7.0 GA ist noch auf Bootbank 6 verfügbar.
Man muss die Wiederherstellung der alten Version mit [Y] bestätigen und das System wird mit der ursprünglichen Build Version 15843807 neu starten.
Der Host startete neu mit Build 15843807. Es gab weder eine Warnanzeige, noch drehten die Lüfter mit hoher Drehzahl. Ein Blick ins IPMI zeigte dass alle Werte im Normbereich lagen.
Was lässt sich bis jetzt sagen?
Zunächst kann ich einen Hardewaredefekt ausschießen, denn der Server lief problemlos mit einem Alternativen Bootimage (Ubuntu 20.04 LTS) und die Probleme traten mit dem ursprünglichen ESXi 7.0 GA Image nicht wieder auf.
Ein Zufall kann auch als wenig wahrscheinlich ausgeschlossen werden, denn 4 Hosts zeigten das gleiche Pänomen nach dem Patchvorgang.
Nächste Schritte
Ich werde versuchen, direkt mit einem aktuellen ESXi 7.0b Image zu booten. Davon gibt es zwei Varianten:
| ESXi 7.0b – 16324942 | Security and Bugfix image |
| ESXi 7.0bs – 16321839 | Security only image |
Wir werden sehen, ob das Problem ebenfalls auftritt, wenn wir direkt vom Image booten. Vielleicht gibt es auch Unterschiede zwischen dem reinen Sicherheitsupdate und dem Bugfix- & Sicherheitsupdate.
Update 05.07.2020
Ich habe zu dem Phänomen eine Anfrage in unseren #vExpert Slackchannel gepostet. Denn entweder bin ich komplett falsch, oder ich bin nicht der einzige mit diesem Problem. Glücklicherweise bekam ich Unterstützung von meinem Kollegen Kev Johnson, der meine Beobachtung an einem von zwei Hosts bestätigen konnte.
Leider war ich bisher nicht in der Lage den Test mit den neuen Bootimages auszuführen (Tabelle oben), denn ich konnte die passenden ISO Dateien nicht finden. Wenn also jemand einen Link kennt, bitte gebt mir kurz Bescheid.
Update 06.07.2020
Es gibt mittlerweile eine Diskussion hierzu im VMTN.
Update 17.07.2020
Einen ganz herzlichen Dank an meinen Kollegen Kev Johnson, der ein Support Ticket bei SuperMicro eröffnet hatte. Er erhielt inoffiziell eine Betaversion BIOS 1.3a, die bei ihm vielversprechend aussah. Ich habe daraufhin ebenfalls ein Ticket eröffnet und mich auf seines bezogen. Kurz darauf bekam ich auch das Beta BIOS.
Ich habe das BIOS Update von 1.3 auf 1.3a auf meinem ersten Server durchgeführt. Wie man im Bild unten sehen kann ist es brandneu.
Ich habe den Host eine Weile beobachtet und als für längere Zeit nichts ungewöhnliches passierte, entschied ich alle E300-9D Hosts mit dem neuen BIOS zu aktualisiere. Ich habe dann den vSAN Cluster gebootet und die neuesten ESXi Patches eingespielt. Mit dem alten BIOS 1.3 veursachten diese Patches thermische Probleme auf der CPU. Jetzt mit der Version 1.3a blieb die Temperatur im Normbereich.
Der Cluster arbeitete mehrere Stunden ohne irgendwelche Probleme. Wir können also davon ausgehen, dass das BIOS Update das Problem beseitigt hat.
Wie funktionieren diese Microcode Updates?
Gibt es einen Unterschied zwischen Microcode Updates, die vom Hardwarehersteller über das BIOS Update kommen und denen, die vom Software Hersteller über Patches kommen? Können sich diese Updates gegenseitig stören? Die Antwort ist nein. Die CPU hat einen Versionierungsmechanismus. Beim Systemboot stellt sie sicher, den neuesten Microcode zu verwenden. Wenn der Microcode des BIOS eine kleinere Version hat, als der des OS Updates, wird sie den Microcode des OS verwenden. Wenn nicht, wird der Code des BIOS verwendet.
Wenn wir uns die Details des ESXi Patches 7.0b ansehen, dann erkennen wir, dass ein Microcode Update für viele CPU Plattformen mitgeliefert wird. Mein E300-9D ist mit einer Intel Xeon D-2146 CPU ausgestattet (Skylake Architektur). Der VMware Patch spielt für die D-2100er Generation den Microcode Version 0x02006901 ein. Die neue Betaversion des BIOS 1.3a liefert Version 0x02006906h aus, welche höher ist. Somit wird das Microcode Update aus dem VMware Patch nicht gezogen.