VMware ESXi Probleme nach Upgrade zu ESXi 7.0 U2a – Build 17867351

UPDATE: Nun gibt es auch einen öffentlichen KB Artikel dazu https://kb.vmware.com/s/article/83963


Nachdem ich vor Kurzem bei einem Kunden am Wochenende auf ein unschönes Problem mit der aktuellen VMware vSphere ESXi 7.0 U2a Version nach einer vorhergehenden Aktualisierung gestoßen bin, hier eine kurze Zusammenfassung.

VMware hat in der ESXi Version 7.0 U2a einen Bug für den bisher aber nur ein interner KB Artikel existiere „Bootbank cannot be found at path ‚/bootbank‘ errors being seen after upgrading to ESXi 7.0 U2 (83963)“ – Dieser Fehler trete bei Systemen mit SD oder USB Bootmedien auf und führt dazu, dass der Host in einem „disconnected/not responding state“ endet.

Die virtuellen Maschinen (VMs) laufen soweit beobachtet ohne Probleme weiter, allerdings ist keine Kommunikation mit dem vCenter mehr möglich, was in der Regel dann auch Auswirkungen auf das Backup hat. In diesem Zustand sollten unter keinen Umständen die Management Services neu gestartet werden, da der Host bereits zu sehr mit sich selbst beschäftigt ist.

Lösung laut Support: auf 7.0 U2 (voraussichtlich) P03 warten; bis dahin auf Version 6.7 bleiben

Workaround: VMs auf die auf dem Host laufen per RDP oder SSH geordnet herunterfahren und anschließend Host neustarten. Danach ist der Host zunächst mal wieder in einem normalen Zustand.

Ein Kollege hat mich noch auf den Blog Eintrag von Luciano Patrão hingewiesen. Allerdings konnte ich noch nicht testen ob es in diesem Fall hilft.

Ich hoffe damit den ein oder anderen vor dieser Fehlersituation bewahren zu können 😉

Neues VMware vSphere ESXi Lizenzmodell 2020

Gestern hat VMware das neue Lizenzmodell vorgestellt. Insbesondere zum Nachteil der AMD Prozessoren mit hoher CPU Dichte (größer 32 Cores pro CPU).

Zwar hält VMware am Grundsatz des bisherigen Modells (per-CPU Lizenzen) fest, zählt zukünftig aber auch die Anzahl der Kerne pro CPU. Eine CPU Lizenz bei VMware beinhaltet dann 32 physische Kerne. Sofern eine CPU mehr als 32 physische Kerne besitzt wird eine weitere CPU Lizenz benötigt.

Die Begrenzung auf 32 physische Kerne pro CPU wurde von VMware so gewählt, dass es für die meisten Anwendungsfälle bei einer CPU Lizenz pro Sockel bleiben wird. Allerdings sind besonders moderne CPUs von AMD mit mehr hoher CPU Dichte zukünftig (ab 02.04.2020) davon betroffen.

VMware Lizenzen und physische Server die mehr als 32 physische Kerne pro CPU sollen eine zusätzliche kostenfreie CPU Lizenz pro CPU Lizenz erhalten um die Lizenz Compliance einhalten zu können.

FAQs und weitere Details sind unter https://www.vmware.com/company/news/updates/cpu-pricing-model-update-feb-2020.html nachzulesen

Quelle: https://www.vmware.com/company/news/updates/cpu-pricing-model-update-feb-2020.html

ESXi 6.5 Partitions Deep Dive

Zuletzt wurde ich mit einem vSAN Host Problem konfrontiert. Im Laufe des Support Tickets bei VMware kristalllisierte sich ein Host des Clusters als „Problemkind“ es gab laut Support im Log Einträge wonach das Cluster sehr instabil war und dieser sich zeitweise nicht mehr im Cluster befand. Geäußert hatten sich die Probleme ursrpünglich in extrem hohen Storage I/O Latenzen welche aber auch nur im Monitoring des Kunden und nicht direkt im VMware vSphere Web Client ersichtlich waren. Im Zuge des Troubleshooting wurde der Host mit der alternativen Bootbank gestartet und das Problem war behoben. Ich war darüber nicht im Bilde, weshalb ich mich dazu entschied das hier Festzuhalten.

Das Partitionlayout eines ESXi Servers ist von VMware gegeben. Bei der Installation eines ESXi gibt es keine direkte Möglichkeit hierauf Einfluss zu nehmen. Meinen Recherchen zufolge gibt es zwischen den Versionen 6.x keine Unterschiede.

Um die ESXi Partitionen zu untersuchen sollten wir uns zunächst die vorhandenen Disks ausgeben lassen. Hierzu verbinden wir uns per SSH auf einen Host und geben folgendes Kommando ein.

ls /dev/disks -lh

Nun werden einige Disks mit „vm1.“ beginnend farblich hervorgehoben aufgelistet. Dies sind die ESXi System Disks.
Untersuchen wir nun die erste der Disks (ohne „:x“ am Ende) mit partedUtil erhalten wir die Tabelle der Partitionen.

partedUtil getptbl vm1.<uuid>

Die Aufgelisteten Partitionen der Disk stellen folgende Bereiche dar.

1 = system Partition –> 4 MB Bootloader
Für den Start des Betriebssystems erforderlich. (System Partition)

2 = Linux native –> 4 GB Scratch Lokation (bei SD oder USB nicht vorhanden) (/scratch)
Eine vier GB große VFAT formatierte Partition um Dateien des VM-Support (vmkernel Log) zu speichern. Diese Dateien sind für die Fehler Suche und Identifikation von Problemen essentiell. Sollte bei der Installation des ESXi Host erkannt werden, dass auf USB oder SD Karte oder einem Speichermedium kleiner 5 GB installiert wird, fehlt diese Partition und man erhält den Hinweis im vSphere Client. (siehe https://varni.de/2016/vmware/was-ist-eine-esxi-scratch-partition-und-wozu-brauche-ich-die/)

3 = lokaler VMFS Datastore
Diese Partition nimmt den gesamten übrigen Speicherplatz ein und wird je nach ESXi Version in der dazugehörigen VMFS Version formatiert. Im laufenden Host wird dieser dann als lokaler Datastore auch im vSphere Client gelistet.

5 = Linux nativ –> 250 MB Bootbank (/bootbank)
Das Hypervisor Image (s.v00) liegt hier. Die Partition ist FAT formatiert. Während des Bootvorgangs wird das hier abgelegte ca. 124 MB große Image entpackt und in den RAM geladen.

6 = Linux nativ –> 250 MB Alternative Bootbank (/altbootbank)
Bei Neuinstallationen ist diese Partition leer. Erst bei einem Upgrade des ESXi Host wird das aktuelle Hypervisor Image hier abgelegt. So ist es möglich die vorherige (funktionierende) Version zu booten. Hierzu muss bei Startvorgang die Tastenkombination „Strg + R“ gedrückt werden.

7 = vmk Diagnose –> 110 MB erste Diagnose Partition
Stürzt der ESXi Host ab oder zeigt einen lilafarbenen Diagnose Screen ( Purple Screen Of Death / PSOD ) wird hier die Host Dump Datei abgelegt.

8 = Linux nativ –> 286 MB Store (/store)
VMware speichert hier eine Vielzahl von ISO Dateien der VMware Tools für die unterstützten Gast Betriebssysteme. Beim Einhängen einer VMware Tools Installations CD wird das ISO Abbild auf dem jeweiligen ESXi Host aus dieser Store Partition heraus zugewiesen.

9 = vmk Diagnose –> 2,5 GB zweite Diagnose Partition
Diese ist eine zweite Diagnose Partition. Die jeweils aktive Partition kann mit folgendem Befehl herausgefunden werden:

esxcli system coredump partition list 

Anpassung/Erzwingung der Anzeigesprache des vSphere Web Client

Standardmäßig nutzt der VMware vSphere Web Client die Anzeigesprache des Betriebssystems oder des verwendeten Browsers. Das kann besonders auf deutschen Systemen sehr nervig sein, da die Übersetzungen teilweise recht ungenau oder gar irreführend sind. Hierbei bin ich nach kurzer Recherche auf folgenden KB Artikel von VMware gestoßen: https://kb.vmware.com/s/article/1016403

Um die angezeigte Sprache des VMware vSphere Webclients nun in englisch zu erzwingen ist lediglich die Erweiterung der URL um den Parameter „?locale=“ notwendig. So ist der englischsprachige Web Client unter folgender URL zu erreichen:
https://<vCenter>/vsphere-client/?locale=en_US

weitere Sprachen:
Deutsch: /?locale=de_DE
Französisch: /?locale=fr_FR
Japanisch /?locale=ja_JP
Koreanisch: /?locale=ko_KR
Chinesisch: /?locale=zh_CN

Was ist eine ESXi scratch Partition und wozu brauche ich die?

Regelmäßig erhalte ich bei Installation von ESXi Servern auf beispielsweise Flex Flash Module der Cisco UCS Blade Server abschließend den Warnhinweis innerhalb von vSpere, dass die Systemprotokolle in einem nicht beständigen Speicher gespeichert werden. Bei den meisten Kunden erfolgt dann eine kurze Erklärung der Meldung ggfs. weitere Detailfragen zur Scratch Partition. Daher möchte ich hiermit versuchen das ganze ein wenig zu erklären.

VMware empfiehlt für den Speicherort der VMkernel-Protokolle einen beständigen Speicher mit mindestens 1 GB verfügbarer Größe. Erkennt der ESXi Installer die Installation auf einem USB-Stick oder einer SD-Karte erfolgt die Erstellung der Scratch Partition nicht darauf, sondern im Arbeitsspeicher (RAM) mit einer auf 512 MB limitierten Größe. So würden z.B. bei einem Reboot des Hosts die VMkernel Logs verloren gehen.

Werden die Protokolle nicht in einen beständigen Speicher geschrieben, so wie es von VMware vorgesehen ist, können Probleme mit der HA-Agent Konfiguration auftreten. Auch habe ich bereits „Allgemeine Systemfehler“ bei Verwendung des vSphere Update Managers bei Kunden beobachten können.

Die Konfiguration eines beständigen Speichers für die Scratch Lokation ist schnell im vSphere Client umgesetzt. Dafür ist nur ein VMFS Pfad in den erweiterten Host Einstellungen anzugeben. Den genauen Vorgang habe ich in meiner Knowledgebase (hier) beschrieben.

Alternativ zur Definition einer Scratch Lokations Partition kann auch ein Syslog Server konfiguriert werden. Hierbei wird dann kein Neustart des ESXi benötigt. Das Vorgehen hierzu ist ebenfalls in meiner KB zu finden (hier).

Zentrale NTP Konfiguration auf mehreren ESXi Servern per PowerCLI

Wie auch im realen Leben ist Zeit auch in der virtualisierten Welt von VMware einer der wichtigsten Faktoren schlecht hin. So sollte man sich bei der Implementierung neuer Virtualisierungs Hosts mindestens einmal Gedanken über die Zeitsynchronisation machen. Unterschiedliche Zeiten auf den verschiedenen Hosts können schwerwiegende Folgen haben. Trotz der Verwendung von NTP (Network Time Protocol) innerhalb einer virtuellen Maschine (VM) und somit der direkten Synchronisation mit einem Zeitserver kann diese unter Umständen abweichen.

Um das zu Verstehen muss man sich mit der Zeitsynchronisation der VMs auseinandersetzen. Neben der Verwendung eines NTP Servers innerhalb des Gast-Betriebssystems kann der Zeitabgleich auch über VMware-Tools erfolgen. Beide Methoden sind valide und können (nicht in Kombination) eingesetzt werden. In der Regel bekommen dedizierte Zeitserver innerhalb des Netzwerks von einer vertrauenswürdigen Quelle die Zeit vorgegeben. Domain Controller (DCs) gleichen dann ihre Zeit mit diesen ab. Alle innerhalb der Domäne befindlichen Server und Clients wiederum holen sich die „korrekte“ Zeit von ihren DCs. Die Angleichung der abweichenden Zeit zu der vorgegebenen erfolgt langsam indem die Geschwindigkeit des lokalen Zeitgebers beschleunigt oder reduziert wird.

Nun gibt es allerdings besondere Ereignisse die dazu führen können, dass die Zeit sich plötzlich gravierend unterscheidet. Folgende Situationen führen zu einer plötzlichen und sofortigen Angleichung der Zeit:

  1. Fortsetzung einer angehaltenen VM
  2. Erstellung oder Wiederherstellung eines VMware Snapshot
  3. Verkleinern einer virtuellen Festplatte (vmdk)
  4. Neustart des VMware-Tools Service oder der VM
    UND
  5. vMotion Migration einer VM auf einen anderen Host

Besonder Punkt fünf ist hierbei hervorzuheben. So ist die Migration von virtuellen Maschinen mittels vMotion ein reguläres Mittel von Administratoren um bspw. einen Host zur Wartung frei zu räumen. Zudem finden bei aktiviertem DRS dem VMware Dynamic Ressource Scheduler, also dem dynamischen Ressourcen Verwalter in der Einstellung „Vollautomatisch“ ständig vMotion Prozesse im Hintergrund statt.

Was also tun? NIE mehr migrieren?!? – Quatsch!
Dann doch lieber die Uhrzeit Konfiguration des VMware ESXi Hosts anpassen.

Da das händische Anlegen bei der initialen Inbetriebnahme mehrerer Hosts recht müsig ist, wollte ich mir diese Arbeit erleichtern und bin auf die Möglichkeiten der PowerCLI gestoßen. Die dazu benötigten Code Zeilen hier in meiner Knowledgebase.

Zur Überprüfung der NTP Konfigurationen verwende ich meist, wie auch für viele andere Konfigs wie bspw. HA oder EVC, die freie Software RVTools von Robware.