Blog

Veröffentlicht am

Probleme mit Windows Server 2022 (KB5022842) unter VMware ESXi

Seit wenigen Wochen treten vermehrt Probleme beim Start/Neustart von Microsoft Windows 2022 basierten virtuellen Maschinen unter VMware vSphere ESXi 7.0 auf. Beim Startvorgang erhält man die im obigen Screenshot gezeigte Fehlermeldung „Security Violation“ im VMware Log wird „SECUREBOOT: Image DENIED“ protokolliert.
Dieses Fehlerbild ergibt sich nach Installation des Microsoft Update KB5022842 in Kombination mit konfiguriertem Secure Boot der VM. Virtuelle Umgebungen die bereits VMware vSphere 8.0 einsetzen sind hiervon nicht betroffen.

Lösungen

Seit dem 21.02.2023 bietet VMware als Lösung dieser Problematik das Upgrade auf ESXi 7.0 Update 3k an. Sofern die Installation dieses Updates nicht möglich ist, sind die folgenden Workarounds durchzuführen.

Auch Microsoft bietet inzwischen seit dem 14.03.2023 ein Update (KB5023705) zur Lösung des Problems. Zur Installation dieses Updates muss, sofern die VM bereits betroffen ist, der unten beschriebene Workaround 2 (Secure Boot Deaktivierung der VM) angewandt werden. Anschließend kann die Secure Boot Option wieder aktiviert werden.

Workarounds

  1. Sofern das betroffene Microsoft Windows 2022 Update KB5022842 noch nicht eingespielt beziehungsweise per Windows Server Update Services zentral freigegeben wurde, sollte dieser ausgesetzt werden bis die Aktualisierung auf VMware vSphere ESXi 7.0 U3k oder 8.0 durchgeführt wurde
  2. Sollte das Microsoft Update bereits eingespielt worden sein, so kann die „Secure Boot“ Option der VM deaktiviert werden. Hierzu muss die virtuelle Maschine heruntergefahren sein. Anschließend lässt sich die Option in den Einstellungen der VM unter „VM Options“ > „Boot Option“ > „Secure Boot enabled“ deaktivieren.

Notizen

  • Zur Auflistung der VMs in denen die Secure Boot Option gesetzt ist, kann der folgende PowerCLI Befehl verwendet werden:
    Get-VM | select Name, @{N='EfiSecureBootEnabled';E={$_.ExtensionData.Config.BootOptions.EfiSecureBootEnabled}}
  • Virtuelle Maschinen, die auf einer beliebigen Version von vSphere ESXi 8.0.x ausgeführt werden, sind von diesem Problem nicht betroffen
  • Der allgemeine Support für vSphere ESXi 6.7 ist beendet
  • Wenn das Problem bereits aufgetreten ist, befolgen Sie einen der hier beschriebenen Schritte
Veröffentlicht am

VMware vSphere 8 Update 1 – Was ist neu? Was ist anders?

Quelle: Introducing vSphere 8 Update 1 – VMware vSphere Blog

Nachdem im vierten Quartal letzten Jahres die Versionen vSphere 6.5 und 6.7 abgekündigt wurden, wurde nahezu zeitgleich die neue Version 8 als „die Workload-Plattform für Unternehmen für traditionelle Anwendungen und Anwendungen der nächsten Generation“ eingeführt. Kaum ein halbes Jahr später nun soll es das erste große Update von vSphere 8 geben. Die „Update 1“ genannte Aktualisierung soll voraussichtlich im April verfügbar sein. In diesem Blogbeitrag möchte ich die Fragen „Was ist neu? Was ist anders?“ in den für mich persönlich besonders interessanten Punkten zusammenzufassen.

vSphere Konfigurationsprofile

Durch vSphere 8 wurde die neue Funktion der „vSphere Konfigurationsprofile®TM“ als Technologievorschau eingeführt und sind als Nachfolger der „Hostprofile“ zu sehen. Das neue Feature soll die deklarative Konfigurationsverwaltung (mittels JSON-Datei) von VMware Hosts und Clustern ermöglichen und so die manuellen Konfigurationsaufwände weiter reduzieren. So können Host Konfigurationen auf Clusterebene bezüglich Compliance und Sicherheit erleichtert sichergestellt werden. Neu in Update 1 ist der die Unterstützung der Verwendung von vSphere Distributed Switches in Kombination mit den Konfigurationsprofilen.
Achtung: VMware Umgebungen die NSX einsetzen, werden nach aktuellem Stand weiterhin nicht unterstützt.

Mehr nachzulesen bei VMware unter https://core.vmware.com/vsphere-configuration-profiles

ESXi Quick Boot mit TPM 2.0

Seit der Einführung von Quick Boot in der Version vSphere 6.7 musst man sich stets zwischen der Verwendung eines Trusted Platform Moduls (TPM) zur erhöhung der Sicherheit und der Nutzung der beschleunigten „Neustart“ Möglichkeit (ESXi Quick Boot) entscheiden. Bei immer größer werdenden Arbeitsspeicherkonfiguration und vSAN Nodes bietet Quick Boot einen nicht zu verachtenden Mehrwert bei Wartungsaktivitäten . Aber auch die Verwendung von TPM2.0 in Kombination mit Secure Boot zur Verifikation der Konfiguration und Malware Erkennung gewinnt immer mehr an Bedeutung. Somit liegt es auf der Hand, dass es nur Sinnvoll wäre beides nutzen zu können.
vSphere 8 Update 1 nimmt einem nun diese Entscheidung und bietet Quick Boot auch mit TPM 2.0

Skyline Health Diagnostic

VMware Skyline als proaktive Self-Service-Support Technologie bietet VMware Kunden mit aktivem Production Support oder Premier Service Vertrag durch die automatische Erfassung und Analyse spezifischer Daten die Möglichkeit einer proaktiven Erkennung potenzieller Probleme. VMware selbst gewährleistet hierbei den Schutz und die Sicherheit der dabei erfasstet Daten. Mit Update 1 wird die „VMware Skyline Health Diagnostics“ nun direkt in das vCenter integriert zur Verfügung gestellt. Dieses Feature hilft bei der Diagnose von Fehlern, Durchführung von Health Checks und der Identifikation von möglichen Herausforderungen bei einer bevorstehenden Aktualisierung.

vSphere Green Metrics

Auch in der IT und dem Betrieb von Rechenzentren spielt die Energieeffizienz eine immer bedeutendere Rolle. Daher hatte VMware in vSphere 8 eine neue Möglichkeit zur Überwachung des Energieverbrauchs der Hosts eingeführt. Nun folgt die Erweiterung, sodass nun auch der Verbrauch einzelner virtueller Maschinen überwacht werden kann.

Okta Identitätsverwaltung

Multi-Faktor Authentication (MFA) und einfaches Identitätsmanagement sind ein wichtiger Bestandteil der heutigen IT Sicherheit. Neu in vSphere 8 Update 1 bietet VMware nun zusätzlich zu den bisherigen Identitätsquellen Active Directory, OpenLDAP und Active Directory Federation Services (ADFS) die Option zur Nutzung von Okta (https://www.okta.com/). Dieser moderne cloudbasierte Identitätsprovider kann sowohl für die Anmeldung am vCenter als auch NSX Manager genutzt werden. Die MFA Option mittels Okta bietet einen erhöhten Mehrwert der Sicherheit.

Mehr zum Thema bei VMware unter https://core.vmware.com/resource/whats-new-vsphere-8-update-1

Veröffentlicht am

Interesting VMware Homelab Kits for 2023

Really nice updated collection of „Interesting VMware Homelab Kits for 2023“ by William Lam
Some of them are ready for diffrent use cases like #vSAN, #NSX and #Tanzu.

#VMware #vExpert #homelab

Interesting VMware Homelab Kits for 2023

Similiar to my post last year on interesting VMware Homelab Kits for 2022, I figured it was time to put together the 2023 edition, especially with some of the kits that I have come to learn about or ones that are planned for release later this year. The list below is not an exhaustive by […]

VMware Social Media Advocacy

Veröffentlicht am

VMware Brings In-House Benchmarking Tool to…

#Security Härtungsgrad von #Windows #Server mittels #VMware #CarbonBlack Workload ermitteln. Center for Internet Security (#CIS) Benchmarking Tool ist nun in der Carbon Black Cloud verfügbar.

VMware Brings In-House Benchmarking Tool to…

Benchmarks are a valuable resource that help security practitioners implement and manage their cybersecurity defenses and data. One such benchmarking tool is The Center for Internet Security (CIS). They’ve published CIS Benchmarks, […]

VMware Social Media Advocacy

Veröffentlicht am

„Weltweite Ransomware-Angriffe: Viele Systeme in Deutschland betroffen“ Quelle: heise online

Der aktuelle #heiseonline Artikel (https://heise.de/-7487095) sowie Mails von verschiedenen #Security Produkt Herstellern sorgen bei einigen Kunden zur Zeit für Unruhe, allerdings bezieht dieser #heise Artikel sich auf einen relativ alten #CVE

Wie #VMware dazu in deren Blog (https://blogs.vmware.com/security/2023/02/83330.html) schreibt, sind bei aktuellen Vorfällen veraltete Systeme betroffen (#ESXi 7.x versions earlier than ESXi70U1c-17325551)

Außerdem wird empfohlen den OpenSLP Service der #ESXi Hosts zu deaktivieren. Dieser ist ab Version 7.0 U2c per default deaktiviert.

Ist gar nicht schlecht sich auch persönlich von #VMware per #Mail oder #RSS zu neuen #CVEs benachrichtigen zu lassen (siehe https://www.vmware.com/security/advisories.html)
So kann man schnell auf neue Sicherheitslücken reagieren.

Veröffentlicht am

VMware vCenter Server Appliance (vCSA) Update per CLI

Die inzwischen auf Photon OS basierende vCenter Server Appliance (vCSA) bietet, wie so oft mehrere Wege zur Update Installation. Photon OS selbst gehört zu VMware und stellt ein gehärtetes Linux dar. Zuvor basierte die vCSA auf SUSE Linux Enterprise Server, was allerdings zu starke Abhängigkeiten mit sich brachte.

In diesem Beitrag möchte ich die Vorgehensweise zur Aktualisierung der vCSA per CLI genauer beleuchten. Hierzu müssen wir zunächst den Zugriff (sofern nicht bereits vorher aktiv) per SSH auf das vCenter zulassen. Dazu per VAMI mittels modernem Browser unter https://<vCenter IP / FQDN>:5480 den unter „Zugriff“ die Verbindung per SSH zulassen.

Nun per SSH die Verbindung zur vCSA im root User Kontext herstellen und das Patch ISO Image der VMware vCenter Server Appliance zuweisen. Anschließend die folgenden Befehle zur Durchführung des Updates geben. Zuerst werden die Patches auf die VM heruntergeladen (staging) und daraufhin angezeigt. Abschließend erfolgt die Installation der Patches.

software-packages stage --iso
software-packages list --staged
software-packages install --staged
Veröffentlicht am

VMware vCSA – Shell wechseln

Die Installation der vCenter Updates bei einer Appliance (vCSA) ist inzwischen relativ simple und schnell über die GUI des vCenter Server Appliance Management Interface (VAMI) möglich geworden. Allerdings könnten bei der Durchführung der Update Installation hier ein wenig mehr Informationen von VMware angezeigt werden.

Um den Fortschritt einer Update Installation besser beobachten zu können ist die Verwendung der CLI empfehlenswert. Hierbei werden Details zu den einzelnen Schritten detailliert aufgelistet.

Wenn man sich per SSH zur vCSA verbindet, findet man sich seit version 6.5 entweder direkt auf der Appliance Shell oder der BASH Shell des vCenter Servers wieder. Um Updates per CLI zu bereitzustellen und anschließend installieren zu können, muss also gegebenenfalls auf die Appliance Shell gewechselt werden. 

chsh -s /bin/appliancesh root

Anschließend ist ein Logout und anschließende Neuanmeldung notwendig damit die Änderung wirksam wird.

Um zu einem späteren Zeitpunkt wieder auf die Bash Shell zu wechseln ist folgender Befehl zu verwenden:

chsh -s /bin/bash root

Anschließend ist wieder ein Logout und anschließende Neuanmeldung notwendig damit die Änderung wirksam wird.

Veröffentlicht am

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.

vSphere 7 Update 2 loses connection with SD Cards a Workaround

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

Veröffentlicht am

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
Veröffentlicht am

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