Schlagwort: CPU

Veröffentlicht am

Ungewöhnliches CPU Problem nach Update auf ESXi 7.0b

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

ServerSuperMicro SYS-E300-9D-8CN8TP
BIOS1.3
ESXi7.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.

„Ungewöhnliches CPU Problem nach Update auf ESXi 7.0b“ weiterlesen
Veröffentlicht am

VM Template in Clustern mit heterogenen CPU Generationen

Probleme bei der Ableitung vom Template

Ich konnte in der Vergangenheit immer wieder beobachten, dass die Ableitung vom Template gelegentlich scheiterte und die neue VM in einem endlosen Sysprep fest hing. Eine erneute Ableitung führte oftmals zum Erfolg, aber die Hintergründe waren mir bislang unklar. Nur durch Zufall bin ich heute auf die Ursache des gestoßen. Die VM war für automatische Anmeldung als Administrator konfiguriert und ich konnte sehen was unmittelbar vor dem Sysprep Versuch passierte. Es wurde ein Treiber für die CPU installiert und der Anwender zu einem Neustart aufgefordert.

sysprepCPU03Dies ist erstaunlich, da das Template der VM zuvor intensiv mit Updates versorgt und mehrfach neu gestartet wurde. Warum also wird nach dem Ableiten ein neuer CPU Treiber installiert?

Dazu muss man verstehen, dass sich der der beschriebene Cluster aus zwei unterschiedlichen Typen von Intel Servern zusammensetzt.

  • Xeon E5-2640 – Dual Socket Hexa-Core
  • Xeon E5-2690 v3 – Dual Socket Dodeca-Core

Durch EVC wurde die vMotion Komaptibilität zwischen den Hosts sichergestellt, dennoch muss das Template jeden Host Typ einmal “sehen”, um den passenden CPU Treiber zu installieren. Passiert dies erstmalig nach dem ableiten, so ist der Sysprep Vorgang gestört und scheitert.

Prevention

Es zeigt sich, daß es eine gute Praxis ist, ein Template auf jedem Host Typ im Cluster mindestens einmal zu booten. Sind erst alle Treiber installiert gibt es auch keine Probleme mehr bei der Ableitung.

 

Veröffentlicht am

CPU Ready und CPU Co-STOP

Bei der Kontrolle der Leistungsdaten eines ESXi Servers (vSphere-Client – Performance – Realtime) fiel mir ein unglaublich hoher Wert für CPU-Ready auf. Laut Graph war dort ein Wert von fast 23 Sekunden. Wie kann das sein?

Bevor man die Werte deutet, sollte man zunächst einige Bergriffe definieren.

CPU-Ready

Angabe in Prozent (%RDY) oder in Millisekunden (ms). CPU-Ready bezeichnet die Zeit, die eine VM warten muß bis ihrer vCPU eine physische CPU zugeteilt wird.

VM bereit – Host nicht.

Co-Scheduling

Hat eine VM mehr als eine vCPU, so müssen diese zeitgleich physischen CPU Kernen des Host Systems zugeordnet werden. Das bedeutet im Klartext, eine VM mit einer vCPU muß warten bis ein Kern frei ist. Eine VM mit 4 vCPU muß entsprechend warten bis 4 Kerne gleichzeitig frei sind. Letzteres ist wesentlich weniger wahrscheinlich. Und damit sind wir auch beim dritten Schlagwort: Co-Stop.

Co-STOP

Zeit, die eine VM bereit ist, jedoch aufgrund von Wartezeiten durch Co-Scheduling nicht einem physischen Kern zugeteilt werden kann. Im Prinzip das selbe wie CPU-Ready, jedoch für VMs mit Virtual Symetric Multiprocessing (vSMP). Während hohe CPU-Ready Werte auf ein Hostsystem unter Druck schließen lassen, kann man dies bei hohen Co-STOP Werten nicht unbedingt folgern. Es bedeutet nur, daß der Host nicht die geforderte Anzahl physischer Kerne gleichzeitig bereitstellen kann. „CPU Ready und CPU Co-STOP“ weiterlesen