Dieser Beitrag beschäftigt sich bei Zeitproblemen von Windows Computern im Zusammenspiel mit VMware.

„Quick and Dirty“ – Im Notfall

Ist es sehr dringend und zeitkritisch, kann diese Lösung verwendet werden, bis eine vollständige Problemanalyse und Problembehebung durchgeführt wurde.

Dazu auf die Domänencontroller (bzw. gewünschten Server) aufschalten, die Eingabeaufforderung als Administrator starten und folgenden Befehl eingeben:

time XX:XX:XX AM

„XX XX XX“ durch die gewünschte Uhrzeit ersetzen und AM oder PM entsprechend anhängen.

Hinweis: Dies ist keine permanente Lösung bei Zeitproblemen. Nach einem Neustart können die gemachten Einstellungen ggf. wieder verworfen sein!

Lösung

VMware Zeitkonfiguration

Sicherstellen, dass in VMware (vCenter oder ESXI) die richtige Uhrzeit entweder manuell oder via NTP-Server konfiguriert ist. Ist kein NTP-Server angegeben, bezieht sich die manuelle Zeit im Standard auf die CMOS-Clock des jeweiligen Hosts. Die Uhrzeitkonfiguration des Hosts in VMware entspricht wiederum der CMOS-Clock der VMs.

Dazu via vCenter den entsprechenden Host auswählen und über den Reiter Konfiguration auf den Punkt System wechseln und dort Uhrzeitkonfiguration klicken. Ebenso prüfen, ob das vCenter an sich mit der korrekten Uhrzeit konfiguriert wurde (vCenter Server Appliance Management).

Alle VMs sollten, wenn möglich, mit der aktuellsten VMware-Tools Version ausgestattet sein.

Gruppenrichtlinie für die Domänencontroller erstellen und zuweisen

Bei aktivierter GPO wird die Zeit extern standardmäßig von time.windows.com aus dem Internet synchronisiert. Natürlich ist es auch möglich die Zeit ausschließlich lokal vom Computer zu beziehen (CMOS). Eine andere Möglichkeit wäre die Firewall oder das Internet-Gateway als Synchronisationspunkt zu verwenden. Das ist vor allem für diejenigen Interessant, die dem Computer keine Verbindung in das Internet gestatten wollen.

Hinweis: Computer innerhalb einer Domäne synchronisieren sich automatisch mit dem Zeitgeber (DC). Eine separate Gruppenrichtlinie ist nicht nötig, kann bei Bedarf aber erstellt und zugewiesen werden.

Windows Server Konfiguration

Anschließend auf die Domänencontroller aufschalten und folgende Befehle nacheinander als Administrator in die Eingabeaufforderung eingeben:

gpupdate /force
w32tm /config /reliable:yes
net stop w32time && net start w32time
w32tm /resync /rediscover

Nach kurzer Synchronisationzeit kann geprüft werden, ob die Uhrzeit des Servers mit den eingestellten Parametern übereinstimmt. Als Hilfe kann eine Website wie https://www.uhrzeit.org/atomuhr.php als Abgleich verwendet werden.

Hinweis: Durch die definierte Karenz in der Gruppenrichtlinie kann die Tatsächliche Uhrzeit von der Uhrzeit innerhalb des Netzwerkes ein paar Sekunden abweichen

Client-Systeme aktualisieren sich automatisch im konfiguriertem Intervall.

Manuell kann dieser Vorgang über die Eingabeaufforderung wie folgt angestoßen werden :

w32tm /resync

Der Beitrag Zeitprobleme in Windows & VMware Umgebungen erschien zuerst auf Daniel Gutermuth.

Hinweis: Damit eine Wiederherstellung durchgeführt werden kann, muss sichergestellt werden, dass die zu wiederherstellende vCenter Version identisch mit der der erstellten Sicherung ist.

Lösung

Zuerst sollte über die vCenter Server-Verwaltung (https://FQDN:5480) eine Sicherung der aktuellen Konfiguration durchgeführt werden.

Möglicherweise werden bereits automatische Sicherungen durchgeführt, welche ebenfalls verwendet werden können. Generell empfiehlt sich aber immer eine aktuelle Sicherung.

Anschließend eine VMware VCSA ISO öffnen und unter vcsa-ui-installer ➔ win32 die Anwendung installer starten.

Hinweis: Die ISO mit der korrekten Softwareversion ist über das VMware-Portal erhältlich.

Im Hauptmenü den Punkt Restore wählen.

Den Assistenten bis zum Punkt Enter backup details durchlaufen.

Dort den Pfad des zuvor erstellen vCenter Konfiguration Backups, sowie die dazugehörigen Zugangsdaten eintragen.

Tipp: Den kompletten Pfad aus dem ersten Schritt 1:1 kopieren und hier einfügen

Nun müssen die Daten des vSphere Hosts angegeben werden, auf welchem das vCenter wiederhergestellt werden soll.

Hinweis: Eine möglich Zertifikatswarnung bestätigen!

Als nächstes folgt der VM-Name der vCenter-VM, sowie deren Root-Passwort.

Ebenso muss die Bereitstellungsgröße der vCenter Instanz gewählt werden. Für die meisten Umgebungen dürfte Tiny oder Small ausreichend sein.

Im nächsten Schritt folgt die Wahl des Speicherplatzes. Dabei unbedingt darauf achten, dass genügen Festplattenspeicher zur Verfügung steht!

Hinweis: Wird das vCenter auf einem dedizierten Host betrieben, so empfiehlt es sich den Speicher auch auf diesem Hosts bereitzustellen. Bei eventuellen Netzwerkprobleme ist so eine Verwaltbarkeit bzw. der Betrieb des vCenters gewährleistet.

Der letzte Schritt verlangt die Angabe der vCenter Netzwerkeinstellungen.

Nachdem alle Angaben verifiziert wurden, kann der Wiederherstellungsvorgang mit einem Klick auf Finish gestartet werden.

In der ersten Phase wird die vCenter Instanz mit den gemachten Angaben provisioniert. Dieser Vorgang kann, je nach Performance, um die 30 Minuten dauern.

Anschließend startet Phase 2. Hier wird die zuvor erstellte Sicherung eingespielt.

Nach Abschluss der Wiederherstellung ist das vCenter mit allen gewohnten Einstellungen wieder verfügbar.

Der Beitrag VMware – vCenter Sicherung wiederherstellen erschien zuerst auf Daniel Gutermuth.

Lösung

Zunächst auf die Management-Oberfläche des Hosts wechseln und dort im Reiter Netzwerk den Punkt Virtuelle Switche auswählen. Anschließend Virtuellen Standard-Switch hinzufügen klicken.

Dem vSwitch einen Namen geben (Im Beispiel ISCSI da er für iSCSI verwendet werden soll).

Des Weiteren zwei Uplinks hinzufügen und zum Schluss mit Hinzufügen bestätigen.

Hinweis: Die Bezeichnung der Uplink (vmnicX) kann von System zu System variieren.

Vom Punkt Virtuelle Switche auf Portgruppen wechseln und Portgruppe hinzufügen klicken.

Hinweis: Es müssen zwei Portgruppen erstellt werden (ISCSI1 und ISCSI2).

Der ersten Portgruppe den Namen ISCSI1 vergeben und unter Virtueller Switch den zuvor erstellen ISCSI vSwitch zur Zuordnung auswählen. Mit Hinzufügen bestätigen.

Nun in den Punkt VMkernel-Netzwerkkarte gehen und VMkernel-Netzwerkkarte hinzufügen wählen.

Im Assistenten für die erste VMkernel-Netzwerkkarte unter Portgruppe ISCSI1 auswählen, sowie in den IPv4-Einstellungen die gewünschte IP-Konfiguration vornehmen und mit Erstellen bestätigen.

Hinweis: Die Schritte erneut für die VMkernel-Netzwerkkarte ISCSI2 durchführen.

Bei den jetzt erstellten vmk-Adaptern in der Spalte Portgruppe zunächst auf ISCSI1 klicken.

Hinweis: Die Schritte müssen für ISCSI1 und ISCSI2 durchgeführt werden. Das Beispiel behandelt nur ISCSI1

Anschließend auf Einstellungen bearbeiten gehen.

Im Assistenten auf NIC-Gruppierung klicken und in den ausfahrenden Einstellungen die Failover-Reihenfolge konfigurieren.

Standardmäßig werden hier alle Uplinks des ISCSI vSwitches angezeigt und als aktiv deklariert. Damit iSCSI ordnungsgemäß funktioniert, muss dies abgeändert werden. Dazu darf immer nur ein Uplink pro Portgruppe aktiv sein. Der andere Uplink muss auf nicht verwendet gesetzt werden. Für die beiden Portgruppen ISCSI1 und ISCS2 heißt dies, dass sie gegensätzliche Failover-Einstellungen besitzen müssen.

In diesem Beispiel:

• Portgruppe ISCSI1: vmnic6 (aktiv), vmnic7 (nicht verwendet)
• Portgruppe ISCSI2:vmnic6 (nicht verwendet), vmnic7 (aktiv)

Eine andere Möglichkeit wäre die Realisierung auf vSwitch Ebene.

In den Reiter Speicher wechseln und unter Adapter auf iSCSI-Konfigurieren klicken.

Dort zunächst iSCSI aktivieren wählen und anschließend unter Netzwerk-Port-Binding die beiden Vmk-Adapter mit den zugewiesenen Portgruppen ISCSI1 und ISCSI2 hinzufügen.

Zuletzt müssen noch die statischen oder dynamischen Ziele des iSCSI-Anbieters hinzugefügt werden, bevor die Einstellungen mit Konfiguration speichern übernommen werden.

Durch einen Klick auf Erneut prüfen im Punkt Geräte wird das iSCSI-Target der Listehinzugefügt.

Über den Punkt Neuer Datenspeicher kann die iSCSI-LUN initialisiert werden, falls nicht schon geschehen.

Damit ist die ESXI Host iSCSI Konfiguration abgeschlossen und besitzt eine redundante Anbindung.

Der Beitrag VMware – ESXI Host redundante iSCSI Konfiguration erschien zuerst auf Daniel Gutermuth.

Hinweis: Alles auf eigene Gefahr!

Lösung

ESXI Host keine Antwort im vCenter:

Im vCenter wird der entsprechende Host mit dem Hinweis „Keine Antwort“ angezeigt.

Die gehosteten VMs werden ebenfalls nicht angezeigt, da sie durch den Hostausfall automatisch via vSphere-HA auf einen anderen Host migriert wurden.

Der Versuch, den Host über das vCenter neu zu verbinden, schlägt fehl.

Auch eine direkte SSH-Verbindung zum Host ist nicht möglich.

An diesem Punkt ist ein direkt Zugriff auf die Konsole des betroffenen Hosts nötig.

Dies kann entweder direkt vor Ort oder über eine BMC / Remote-Management-Schnittstelle geschehen. In diesem Beispiel erfolgt der Direktzugriff über die Remote Management Schnittstelle eines Supermicro Servers.

Im Hauptmenü des Remote-Managements muss in den Reiter Remote Control gewechselt werden.

Im Punkt Launch Console das Current Interface auf HTML5 setzen und Mouse Mode auf Absolute. Anschließend die Sitzung mit Launch Console starten.

Innerhalb der Konsole wird schnell ersichtlich, warum der Host auf keinerlei Anfragen mehr reagiert. Der sogenannte Purple Screen Of Death ist das Pendant zum Blue Screen Of Death in Windows und mitunter das Schlimmste, was einem ESXI-Host passieren kann.

Hinweis: Solche kritischen Fehler sollten sorgfältig analysiert werden, besonders wenn sie regelmäßig auftreten! Im Beispiel wird ESXI 7.0.3 U3 eingesetzt, welches zum Zeitpunkt des Artikels kritische Fehler enthält und von VMware zurückgezogen wurde.

Der Ausweg führt, in den meisten Fällen, nur über einen Neustart des gesamten Hosts.

Da im Beispiel alle VMs bereits auf einen anderen Hosts migriert wurden, ist ein Neustart des betroffenen Hosts problemlos möglich.

Im Beispiel muss auf das Dashboard des Remote-Managements gewechselt und am rechten Rand auf das An/Aus-Icon geklickt werden.

Unter Power Control den Punkt Power Reset wählen und mit Apply bestätigen. Anschließend wird der Host neu gestartet.

Über die Remote-Konsole kann der gesamte Boot-Vorgang beobachtet werden.

Sobald dieser erfolgreich abgeschlossen wurde, wieder in das vCenter wechseln.

Im vCenter sollte der Host nun wieder automatisch eine Verbindung hergestellt haben.

Manuell kann die Verbindung auch mit einem Rechtsklick auf den Host und über Verbindung → Verbinden hergestellt werden.

Je nach vSphere-Lizenz werden die vorher automatisch migrierten VMs wieder auf den ursprünglichen Host zurück migriert. Ansonsten muss dies manuell z. B. via vMotion erfolgen.

Der Beitrag VMware – ESXI Host „keine Antwort“ im vCenter erschien zuerst auf Daniel Gutermuth.

Das BSI stuft diese Lücke auf der CVSS-Skala mit dem höchstmöglichen Wert 10 (CVE-2021-44228) ein.

Bis es zu flächendeckenden Patches durch die Hersteller kommt, existieren bereits erste Workarounds für verschiedenste Produkte.

Auch das vCenter von VMware ist von dieser Sicherheitslücke betroffen – ESXI nicht!

In diesem Beitrage möchte ich den VMware vCenter Workaround erläutern.

Hinweis: Alles auf eigene Gefahr!

Lösung

Gültig für:

• vCenter 7.0 GA, 7.0.0a, 7.0.0b, 7.0.0c, 7.0.0d
• vCenter 7.0 Update 1, U1a, U1c, U1d
• vCenter 7.0 Update 3, 3a
• vCenter 7.0 Update 2, 2a, 2b, 2c, 2d

Lösungen für vCenter 6.7, 6.5 und 6.0 sind im verlinkten VMware KB-Artikel beschrieben. Das Vorgehen ist fast identisch.

Eine SSH-Verbindung mit dem vCenter (z. B. via Putty) aufbauen.

Eventuelle Zertifikatswarnungen bestätigen.

In der SSH-Sitzung als Root anmelden und mit dem Befehl Shell den Shell-Zugriff aktivieren.

vMON-Dienst

Die bestehende Java-wrapper-vmon Datei sichern.

cp -rfp /usr/lib/vmware-vmon/java-wrapper-vmon /usr/lib/vmware-vmon/java-wrapper-vmon.bak

Anschließend diese im VI-Editor öffnen und mit a in den Bearbeitungsmodus wechseln.

vi /usr/lib/vmware-vmon/java-wrapper-vmon

Dort die letzte Zeile löschen…

exec $java_start_bin $jvm_dynargs $security_dynargs $original_args

..und folgende zwei Zeilen einfügen:

log4j_arg="-Dlog4j2.formatMsgNoLookups=true"
exec $java_start_bin $jvm_dynargs $log4j_arg $security_dynargs $original_args

Hinweis: Die zwei oberen Zeilen beziehen sich auf :

• vCenter 7.0 Update 3, 3a
• vCenter 7.0 Update 2, 2a, 2b, 2c, 2d

Für die unteren vCenter-Versionen gilt:

• vCenter 7.0 GA, 7.0.0a, 7.0.0b, 7.0.0c, 7.0.0d
• vCenter 7.0 Update 1, U1a, U1c, U1d

//Löschen
exec $java_start_bin $jvm_dynargs "$@"

//Einfügen
log4j_arg="-Dlog4j2.formatMsgNoLookups=true"
exec $java_start_bin $jvm_dynargs $log4j_arg "$@"

Mit ESC den Bearbeitungsmodus verlassen und mit :wq das Dokument speichern und den Editor verlassen.

Die Berechtigungen der Datei anpassen.

chown root:cis /usr/lib/vmware-vmon/java-wrapper-vmon
chmod 754 /usr/lib/vmware-vmon/java-wrapper-vmon

Alle vCenter Dienste neu starten.

service-control --stop --all
service-control --start --all

Update Manager Dienst

Die bestehende start.ini sichern.

cp -rfp /usr/lib/vmware-updatemgr/bin/jetty/start.ini /usr/lib/vmware-updatemgr/bin/jetty/start.ini.bak

Wieder die Datei im VI-Editor öffnen und mit a in den Bearbeitungsmodus wechseln.

vi /usr/lib/vmware-updatemgr/bin/jetty/start.ini

Dort anschließend folgende Zeile am Ende des Dokuments einfügen, den Bearbeitungsmodus beenden und speichern.

-Dlog4j2.formatMsgNoLookups=true

Neustart des Update Manager Dienstes.

service-control --restart vmware-updatemgr

Analytics Dienst

Sichern der bestehenden log4j-core-2.8.2.jar Datei.

log4j-core-2.8.2.jarcp -rfp /usr/lib/vmware/common-jars/log4j-core-2.8.2.jar /usr/lib/vmware/common-jars/log4j-core-2.8.2.jar.bak

Die Klasse deaktivieren.

zip -q -d /usr/lib/vmware/common-jars/log4j-core-2.8.2.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Den Analytics Dienst neu starten.

service-control --restart vmware-analytics

DBCC Dienstprogramm

Die bestehende log4j-core-2.8.2.jar Datei sichern.

cp /usr/lib/vmware-dbcc/lib/log4j-core-2.8.2.jar /usr/lib/vmware-dbcc/lib/log4j-core-2.8.2.jar.bak

Anschließend ebenfalls deaktivieren.

zip -q -d /usr/lib/vmware-dbcc/lib/log4j-core-2.8.2.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Hinweis: Falls die Meldung „zip error: Nothing to do!“ erscheint, war dieser Schritt nicht notwendig, da DBCC nicht verwendet wird.

Schritte verifizieren

vMON Dienst:

Der Eintrag -Dlog4j2.formatMsgNoLookups=true muss in der Ausgabe des folgenden Befehls erscheinen.

ps auxww | grep formatMsgNoLookups

Update Manager Dienst:

Nach Eingabe des unteren Befehls, muss unter Properities der Eintrag log4j2.formatMsgNoLookups = true vorhanden sein.

cd /usr/lib/vmware-updatemgr/bin/jetty/
java -jar start.jar --list-config

Analytics Dienst und DBCC Dienstprogramm:

Die Ausgabe beider Befehle muss 0 ergeben.

grep -i jndilookup /usr/lib/vmware/common-jars/log4j-core-2.8.2.jar | wc -l
grep -i jndilookup /usr/lib/vmware-dbcc/lib/log4j-core-2.8.2.jar | wc -l

Zum Abschluss der Arbeiten kann die Shell-Sitzung mit exit beendet und die SSH-Verbindung geschlossen werden.

Damit ist das vCenter, bis zum Erscheinen von Patches, gegen die Log4j Sicherheitslücke gerüstet.

Der Beitrag VMware – Log4j Sicherheitslücke im vCenter mit Workaround schließen erschien zuerst auf Daniel Gutermuth.

Im Falle von VMs kann ein TPM auch virtuell emuliert werden (vTPM). Der Host selbst muss kein TPM besitzen.

Voraussetzungen

Ein Schlüsselanbieter muss im vCenter konfiguriert sein.

Lösung

Im vCenter eine Neue virtuelle Maschine erstellen.

Der neuen VM einen Namen geben und den Speicherort auswählen.

Die Computing Ressource auswählen und anschließend den Datenspeicher.

Bei der Kompatibilität die neuste Revision auswählen

In diesem Beispiel handelt es sich um eine VM mit Windows Server 2022, daher die Auswahl der Gastbetriebsfamilie mit Windows und des Gastbetriebssystems mit Windows Server 2022.

Das Kontrollkästchen für die virtualisierungsbasierte Sicherheit muss aktiviert werden.

Hinweis: Sollte Windows Server 2022 als Gastbetriebssystem noch nicht zur Auswahl stehen, kann auch Windows Server 2019 oder Windows Server 2016 gewählt werden. Für Windows 11 kann Windows 10 gewählt werden.

Die Hardware der virtuellen Maschine nach Belieben zuweisen.

Zum Hinzufügen des vTPMs auf Neues Gerät hinzufügen klicken und Trusted Platform Module auswählen.

Anschließend erscheint das vTPM in der VM-Hardware unter Sicherheitsgeräte.

Optional

Falls vMotion und Fault Tolerance verwendet werden, müssen in den VM-Optionen unter Verschlüsselung beide Punkte auf Erforderlich gesetzt werden.

Zuletzt den Assistenten bis zum Ende durchklicken und mit Finish den Abschluss bestätigen.

Damit wurde eine VM mit vTPM erstellt.

Aus dieser VM könnte nun eine Vorlage erstellt werden.

Der Beitrag vCenter – VM mit vTPM erstellen erschien zuerst auf Daniel Gutermuth.

Lösung

Mit Administratorenrechten im vCenter anmelden und in der Host-Ansicht auf die vCenter-Instanz klicken.

Dort anschließend den Reiter Konfigurieren auswählen, unter Sicherheit in Schlüsselanbieter wechseln und über Hinzufügen den Punkt Nativen Schlüsselanbieter hinzufügen wählen.

Im aufkommenden Fenster einen Namen eintragen und mit Schlüsselanbieter hinzufügen schließen.

Hinweis: Wenn die angebundenen Hosts jeweils einen TPM-Chip besitzen, das Kontrollkästchen aktiviert lassen. Falls dies nicht der Fall ist, muss das Kontrollkästchen deaktiviert werden, sonst funktioniert es nicht.

Im nächsten Schritt muss der erstellte Schlüsselanbieter gesichert werden.

Hierzu, wie empfohlen, die Daten des Schlüsselanbieters mit einem Kennwort schützen.

Das Kennwort an einem sicheren Ort aufbewahren (z. B. KeePass).

Zuletzt wird der Vorgang mit einem Klick auf Sichern des Schlüsselanbieters abgeschlossen.

Die heruntergeladene Datei ebenfalls an einem sicheren Ort aufbewahren, so dass sie für eine eventuelle Wiederherstellung zur Verfügung steht. Die Wiederherstellung wird ebenfalls über das Schlüsselanbieter-Menü im vCenter durchgeführt.

Der nun erstellte Schlüsselanbieter darf nicht gelöscht oder verändert werden. VMs mit vTPM Abhängigkeiten könnten sonst nicht mehr funktionieren.

Der Beitrag vCenter – Schlüsselanbieter hinzufügen (mit/ohne TPM) erschien zuerst auf Daniel Gutermuth.