vmWare ESXi Host Warnung „esx.problem.hyperthreading.unmitigated“ (ESXi 6.5/6.7)

esx.problem.hyperthreading.unmitigated

Aktuelle ESXi Server beschweren sich mit einer Warnung über CPUs mit Microcode, die anfällig für Angriffe wie Meltdown, Lazy FP state restore und/oder die L1 Terminal Fault sind. Einige AMD und Intel Prozessoren können über so einen side-channel Angriff Daten lesbar machen, die nicht lesbar sein sollten.

Bevor die Warnung unterdrückt wird, lohnt abe ein Blick in die Mitigation und vor allem auch die performance impacts. In privaten Cluster Setups ist die Gefahr eines solchen Angriffs vermutlich auch nicht so hoch, wie in öffentlichen Wolken.

Lösung

Da die Mitigations dazu ziemlich viel CPU-Performance fressen, bleiben die Schutzfunktionen wie der „Side-Channel-Aware Scheduler“ in privaten und geschlossenen Clustern oft ausgeschaltet. Trotzdem will man die Warnung natürlich loswerden 🙂

Möglichkeit 1 – Warnung unterdrücken

  1. vSphere GUI (vCenter) öffnen, den betroffenen Host auswählen
  2. Konfigurieren > Erweiterte Systemeinstellungen > Bearbeiten
  3. „UserVars.SuppressHyperthreadWarning“ auf „1“ stellen
SuppressHyperthreadWarning

Möglichkeit 2 – „Side-Channel-Aware Scheduler“ einschalten

  1. ESXi Hostclient (nicht im vCenter) öffnen
  2. Konfiguration > Erweiterte Einstellungen > Bearbeiten
  3. VMkernel.Boot.hyperthreadingMitigation“ auf „true“ stellen
  4. Host neu starten

Es empfielt sich vor diesem Schritt das zugehörige Support-Dokument zu lesen. Hier sind die Vorbereitungen für diesen Schritt und die möglichen Auswirkungen davon genauer beschrieben.

„GParted Bug: Eine Partition kann nicht (xxx) nach dem Ende des Laufwerks enden (%2)“

Problem

GParted beschwert sich bei der Anpasung von Partitionsgrößen: „GParted Bug: Eine Partition kann nicht (xxx) nach dem Ende des Laufwerks enden (%2)“

Die gleiche Meldung gibt es auch auf Englisch: „GParted Bug: A partition cannot end after the end of the device (%2)“

Das tritt beim resizing oder verschieben einer Partition auf, obwohl noch genug Platz da ist und das Ende des Laufwerks noch nicht erreich scheint.

Lösung

Der Fehler (Bug) liegt in der Berechnung der Partitionsgrenzen bei der Verwendung des Binärpräfixe gemäß IEC (MiB/KiB …). Man stelle den Dialog also einfach einfach auf „Zylinder“ (Cylinder) um, schon funktioniert die selbe Operation fehlerfrei.

vCenter Update „“Error in method invocation Timeout happens while sending message to microservice“

Problem

Die Aktualisierung des VMware vCenter Servers (VCSA) kann bei der Lizenzanzeige (EULA) nicht fortgesetzt werden. Nach einem Klick auf „Next“ landet man immer im selben Bildschirm, der die Fehlermeldung „Error in method invocation Timeout happens while sending message to microservice“ zeigt.

Zudem findet man in /var/log/vmware/applmgmt/applmgmt.log mehrere Meldung wie:

DEBUG:vmware.appliance.update.update_functions: Exception happens  while sending message to microservice: ConnectionRefusedError(111,  'Connection refused')

INFO:vmware.appliance.update.update_functions:Timeout happens  while sending message to microservice

ERROR:vmware.vapi.provider.local:Error in invoking  com.vmware.appliance.update.pending in precheck - Timeout happens while sending message to microservice 

Lösung

Der Update-Micrososervice vergisst manchmal, sein PID-file zu entfernen. Das verhindert den korrekten neustart des Prozesses. Das lässt sich an der SSH-Konsole der VCSA (SSH öffnne, mit ’shell‘ eine Shell starten) aber schnell beheben.

Prüfen ob die PID noch da ist

 ls /var/run/vmware/applmgmt/update_microservice.pid 

Wenn dem so ist, diese PID File entfernen

rm /var/run/vmware/applmgmt/update_microservice.pid

Danach läuft da sUpdate sofort fehlerfrei weiter.

VMware vSphere VCSA/vCenter Liste über VMs mit Betriebssystemen ausgeben

Manchmal braucht man eine schnelle Liste über die laufenden Gast-Betriebssysteme (und -Versionen) in einer vCenter-Instanz. In meinem speziellen Fall benötigte ich vor allem die konfigurierten Betriebssysteme und die tatsächlich laufenden Gäste, um nach einer Migration die Einstellungen für die ESXi-Hosts auz zu räumen.

Nach ein bisschen Bastelei nutze ich nun diesen PowerCLI Einzeiler. Das Script erstellt einfach eine Liste über Name, Konfiguriertes OS und das gemeldete OS aller Gastsysteme.

Lösung

Liste aller OS in einem vCenter via Powershell erstellen:

Get-VM | Get-View -Property @("Name", "Config.GuestFullName", "Guest.GuestFullName") | Select -Property Name, @{N="Eingestellt";E={$_.Config.GuestFullName}},  @{N="Läuft";E={$_.Guest.GuestFullName}} | Format-Table -AutoSize
So sieht die Ausgabe des Befehls aus.

Veeam Update „Warning 1327.Invalid Drive D:\“

Normalerweise sind Veeam Backup&Replication Updates dank der extensiven Q&A-Kultur von Veeam äußerst stressfrei und unter Berücksichtung der neuen Features/Funktionen schnell erledigt. Es gibt aber ein Problem im Setup der aktuellen Versionen (hier: Update 4a) wenn der „Veeam Backup Catalog“ irgendwann einmal verschoben wurde. Das Update-Setup

Warning 1327.Invalid Drive: D:\

Lösung

Der VBRCatalog wurde offensichtlich irgendwann einmal verschoben. Das Setup liesst bei der Installation einmal den Pfad aus der Windows-Freigabe aus, wenn die Installation lokal ist, und versucht diesen veralteten Pfad dann erfolglos zu nutzen.

  1. In der Computerverwaltung unter den Freigaben die Freigabe „VBRCatalog“ prüfen und den Pfad korrigieren (auf die Berechtigungen achten!)
  2. In der Registry diesen Pfad ebenfalls korrigieren: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup Catalog (Zeichenfolge: „CatalogPath“ auf den richtigen Pfad ändern, zum Beispel „C:\VBRCatalog“)

Danach das Setup neu starten und schon läuft es wie gewohnt stressfrei durch.

vSphere Gastinformationen im vCenter manuell aktualisieren

In einen VMware Gast gehören idealerweise möglichst aktuelle VMware Tools installiert und gestartet. Denn nur dann gibt es zusätzliche Funktionen wie die Guest Operations-APIs, mit denen der Admin Dinge direkt im Gast ausführen kann, auch wenn kein Netzwerk verfügbar ist. Zusätzlich gibt es in der VCSA Konsole einen Einblick in den Gast, zum Beispiel das installierte Betriebssystem, einige Datenträger und vor allem die Netzwerkinformationen wie Hostname und IP-Adressen.

Das Standardintervall für die Aktualisierung dieser Informationen beträgt 30 Sekunden. Im Allgemeinen ist das auch vollkommen okay, da sich in der Regel weder die Adresse noch das Betriebssystem allzu häufig ändern

Wenn man aber beispielsweise mehrere Instant-Clones ausführt und sich auf die vSphere-API und die GuestInfo-Daten zur Ermittlung der IP-Adresse des Gasts verlassen muss, sind 30 viel Zeit. Zumal der eigentliche Clone-Vorgang in ein paar Sekunden fertig ist.ne viel einfachere Lösung.

Lösung

Es gibt die Möglichkeit für ein Instant-Update:

c:\Program Files\VMware\VMware Tools\VMwareToolboxCmd.exe info update network

Unter Linux:

~$> /usr/bin/vmware-toolbox-cmd info update network

VMware ESXi/vCenter: Wann war eine VM das letzte mal eingeschaltet?

Manchmal ist es hilfreich zu wissen, wann ein VMware Gast zuletzt eingeschaltet gewesen ist. Es soll ja schon mal vorkommen das „tote“ virtuelle Maschinen jahrelang auf der Infrastruktur liegen aber eigentlich nicht mehr gebraucht werden.

Lösung

Es gibt keine „eingebaute“ Möglichkeit, Einschaltdaten von VMs nachzuschlagen. Am einfachsten ist es aber, das Ereignisprotokoll rückwärts nach dem letzten „Power on“ Event zu durchsuchen.

An der PowerCLI Powershell geht das beispielsweise so:

Get-VM GASTNAME | Get-VIEvent -Types Info -MaxSamples 1000 | Where-Object {$_.fullFormattedMessage -match "Power On"} | %{Write-Host $_.vm.name $_.createdTime | Out-Default}

Wobei hier „MaxSamples“ ein Beispiel ist; möglicherweise muss man mehr Events durchsuchen. Wenn man beispielsweise oft Sicherungen von Gästen via VCB erstellt, reichen 1000 Events nicht aus.

Ohne die Angabe „GASTNAME“ gibt es eine Liste aller verbundenen virtuellen Maschinen.