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.