ESXi 7.0 Update 3i | 8. DEZEMBER 2022 | 20842708 Überprüfen Sie, ob Erweiterungen und Updates für diese Versionshinweise zur Verfügung stehen.

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

• Neuigkeiten
• Vorherige Versionen von ESXi 7.0
• In dieser Version enthaltene Patches
• Hinweise zu Produktunterstützung
• Behobene Probleme
• Bekannte Probleme
• Bekannte Probleme aus vorherigen Versionen

WICHTIG: Wenn Ihr Quellsystem Hosts mit Versionen zwischen ESXi 7.0 Update 2 und Update 3c sowie Intel-Treiber enthält, lesen Sie vor dem Upgrade auf ESXi 7.0 Update 3i den Abschnitt Neuigkeiten der Versionshinweise zu VMware vCenter Server 7.0 Update 3c, da der gesamte Inhalt im Abschnitt auch für vSphere 7.0 Update 3i gilt. Weitere Informationen erhalten Sie auch in den verwandten VMware-Knowledgebase-Artikeln: 86447, 87258 und 87308. 

Neuigkeiten

• ESXi 7.0 Update 3i unterstützt vSphere Quick Boot auf folgendem Server:

  • HPE ProLiant MicroServer Gen10 Plus v2

• In dieser Version werden die Schwachstellen CVE-2022-31696 und CVE-2022-31699 behoben. Weitere Informationen zu diesen Schwachstellen und deren Auswirkungen auf VMware Produkte finden Sie unter VMSA-2022-0030.

Vorherige Versionen von ESXi 7.0

Neue Funktionen sowie die gelösten und bekannten Probleme von ESXi werden in den entsprechenden Versionshinweisen beschrieben. Versionshinweise zu vorherigen Versionen von ESXi 7.0:

• Versionshinweise zu VMware ESXi 7.0, ESXi 7.0 Update 3g
• Versionshinweise zu VMware ESXi 7.0, ESXi 7.0 Update 3f
• Versionshinweise zu VMware ESXi 7.0, ESXi 7.0 Update 3e
• Versionshinweise zu VMware ESXi 7.0, ESXi 7.0 Update 3d
• Versionshinweise zu VMware ESXi 7.0, ESXi 7.0 Update 2e
• Versionshinweise zu VMware ESXi 7.0, ESXi 7.0 Update 1e
• Versionshinweise zu VMware ESXi 7.0, ESXi 7.0 Update 3c
• Versionshinweise zu VMware ESXi 7.0, ESXi 7.0 Update 2d
• Versionshinweise zu VMware ESXi 7.0, ESXi 7.0 Update 2c
• Versionshinweise zu VMware ESXi 7.0, ESXi 7.0 Update 2a
• Versionshinweise zu VMware ESXi 7.0, ESXi 7.0 Update 2
• Versionshinweise zu VMware ESXi 7.0, ESXi 7.0 Update 1d
• Versionshinweise zu VMware ESXi 7.0, ESXi 7.0 Update 1c
• Versionshinweise zu VMware ESXi 7.0, ESXi 7.0 Update 1b
• Versionshinweise zu VMware ESXi 7.0, ESXi 7.0 Update 1a
• Versionshinweise zu VMware ESXi 7.0, ESXi 7.0 Update 1
• Versionshinweise zu VMware ESXi 7.0, ESXi 7.0b

Informationen zu Internationalisierung, Kompatibilität und Open Source-Komponenten finden Sie in den Versionshinweisen zu VMware vSphere 7.0.

In dieser Version enthaltene Patches

Diese Version von ESXi 7.0 Update 3i stellt die folgenden Patches bereit:

Build-Details

Download-Dateiname:	VMware-ESXi-7.0U3i-20842708-depot
Build:	20842708
Download-Größe:	570,5 MB
md5sum:	7ec976758701d4287393aebcc2c5d55c
sha256checksum:	26b26ddb4e0d3ba2bc4ac3b693addb111a0b1980abf03fce243473812ec460f7
Neustart des Hosts erforderlich:	Ja
Migration oder Herunterfahren der virtuellen Maschine erforderlich:	Ja

Komponenten

Komponente	Bulletin	Kategorie	Schweregrad
ESXi-Komponente - ESXi-Kern-VIBs	ESXi_7.0.3-0.65.20842708	Fehlerkorrektur	Kritisch
ESXi-Komponente „Installieren/Aktualisieren“	esx-update_7.0.3-0.65.20842708	Fehlerkorrektur	Kritisch
Broadcom NetXtreme I ESX VMKAPI-Ethernet-Treiber	Broadcom-ntg3_4.1.8.0-4vmw.703.0.65.20842708	Fehlerkorrektur	Kritisch
ESXi-Komponente - ESXi-Kern-VIBs	ESXi_7.0.3-0.60.20841705	Sicherheit	Kritisch
ESXi-Komponente „Installieren/Aktualisieren“	esx-update_7.0.3-0.60.20841705	Sicherheit	Kritisch
ESXi Tools-Komponente	VMware-VM-Tools_12.1.0.20219665-20841705	Sicherheit	Kritisch

WICHTIG:

• Ab vSphere 7.0 verwendet VMware Komponenten zum Verpacken von VIBs mit Bulletins. Die Bulletins ESXi und esx-update bauen aufeinander auf. Schließen Sie immer beide in eine einzelne ESXi-Host-Patch-Baseline oder das Rollup-Bulletin in die Baseline ein, um Fehler während des Patchens von Hosts zu vermeiden. 
• Beim Patchen von ESXi-Hosts mithilfe von VMware Update Manager von einer Version vor ESXi 7.0 Update 2 wird dringend empfohlen, das Rollup-Bulletin in der Patch-Baseline zu verwenden. Wenn Sie das Rollup-Bulletin nicht verwenden können, stellen Sie sicher, dass alle der folgenden Pakete in der Patch-Baseline enthalten sind. Wenn die folgenden Pakete nicht in der Baseline enthalten sind, schlägt der Updatevorgang fehl:
  • VMware-vmkusb_0.1-1vmw.701.0.0.16850804 oder höher
  • VMware-vmkata_0.1-1vmw.701.0.0.16850804 oder höher
  • VMware-vmkfcoe_1.0.0.2-1vmw.701.0.0.16850804 oder höher
  • VMware-NVMeoF-RDMA_1.0.1.2-1vmw.701.0.0.16850804 oder höher

Rollup-Bulletin

Dieses Rollup-Bulletin enthält die neuesten VIBs mit allen Fixes nach der ersten Version von ESXi 7.0.

Bulletin-ID	Kategorie	Schweregrad	Detail
ESXi70U3i-20842708	Fehlerkorrektur	Kritisch	Sicherheit und Fehlerbehebung
ESXi70U3si-20841705	Sicherheit	Kritisch	Nur Sicherheit

Image-Profile

Patch- und Updateversionen von VMware enthalten allgemeine und kritische Image-Profile. Die Anwendung des allgemeinen Image-Profils der Version gilt für die neuen Fehlerkorrekturen.

Name des Image-Profils

ESXi-7.0U3i-20842708-standard

ESXi-7.0U3i-20842708-no-tools

ESXi-7.0U3si-20841705-standard

ESXi-7.0U3si-20841705-no-tools

ESXi-Image

Name und Version	Datum der Veröffentlichung	Kategorie	Detail
ESXi_7.0.3-0.65.20842708	8. DEZEMBER 2022	Verbesserung	Image für Sicherheit und Fehlerbehebung
ESXi_7.0.3-0.60.20841705	8. DEZEMBER 2022	Verbesserung	Image nur für Sicherheit

Informationen zu den einzelnen Komponenten und Bulletins finden Sie auf der Seite Produkt-Patches und im Abschnitt Behobene Probleme.

Patch-Download und -Installation

In vSphere 7.x wird das für die Verwaltung von vSphere Update Manager verwendete Update Manager-Plug-In durch das Lifecycle Manager-Plug-In ersetzt. Verwaltungsvorgänge für vSphere Update Manager stehen weiterhin mit neuen Funktionen für vSphere Lifecycle Manager im Lifecycle Manager-Plug-In zur Verfügung.
Die typische Methode zum Anwenden von Patches auf ESXi 7.x-Hosts besteht in der Verwendung des vSphere Lifecycle Manager. Weitere Informationen finden Sie unter Info zu vSphere Lifecycle Manager und vSphere Lifecycle Manager-Baselines und -Images.
Sie können ESXi-Hosts auch ohne das Lifecycle Manager-Plug-In aktualisieren und stattdessen ein Image-Profil verwenden. Dazu müssen Sie die ZIP-Datei des Patch-Offline-Pakets manuell von VMware Customer Connect herunterladen. Wählen Sie im Dropdown-Menü Produkt auswählen die Option ESXi (eingebettet und installierbar) und im Dropdown-Menü Version auswählen die Option 7.0. Weitere Informationen finden Sie unter Aktualisieren von Hosts mithilfe von ESXCLI-Befehlen und im Handbuch VMware ESXi-Upgrade.

Hinweise zu Produktunterstützung

• Ab vSphere 7.0 Update 3i müssen Sie bei der Konfiguration des Reverse-Proxys auf dem vCenter Server-System zum Aktivieren von Smartcard-Authentifizierung Port 3128 verwenden, der automatisch festgelegt und geöffnet wird. Sie müssen auf jeden Fall über Zugriff auf den Port auf dem entsprechenden vCenter Server verfügen. Überprüfen Sie die Perimeter Firewalls, um sicherzustellen, dass Zugriff gewährt wurde. Starten Sie den STS-Dienst nach der Konfiguration des rhttpproxy-Diensts neu.
  Weitere Informationen finden Sie unter Konfigurieren des Reverse-Proxys zum Anfordern von Clientzertifikaten und in den VMware-Knowledgebase-Artikeln 78057 und 90542.

Behobene Probleme

Die behobenen Probleme werden in folgende Kategorien unterteilt.

• ESXi_7.0.3-0.65.20842708
• esx-update_7.0.3-0.65.20842708
• Broadcom-ntg3_4.1.8.0-4vmw.703.0.65.20842708
• ESXi_7.0.3-0.60.20841705
• esx-update_7.0.3-0.60.20841705
• VMware-VM-Tools_12.1.0.20219665-20841705
• ESXi-7.0U3i-20842708-standard
• ESXi-7.0U3i-20842708-no-tools
• ESXi-7.0U3si-20841705-standard
• ESXi-7.0U3si-20841705-no-tools
• ESXi_7.0.3-0.65.20842708
• ESXi_7.0.3-0.60.20841705

ESXi_7.0.3-0.65.20842708

Patch-Kategorie	Fehlerkorrektur
Patch-Schweregrad	Kritisch
Hostneustart erforderlich	Ja
Migration oder Herunterfahren der virtuellen Maschine erforderlich	Ja
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Enthaltene VIBs	VMware_bootbank_esx-xserver_7.0.3-0.65.20842708 VMware_bootbank_gc_7.0.3-0.65.20842708 VMware_bootbank_vsan_7.0.3-0.65.20842708 VMware_bootbank_cpu-microcode_7.0.3-0.65.20842708 VMware_bootbank_crx_7.0.3-0.65.20842708 VMware_bootbank_esx-base_7.0.3-0.65.20842708 VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.3-0.65.20842708 VMware_bootbank_vsanhealth_7.0.3-0.65.20842708 VMware_bootbank_native-misc-drivers_7.0.3-0.65.20842708 VMware_bootbank_esx-ui_2.1.1-20188605 VMware_bootbank_trx_7.0.3-0.65.20842708 VMware_bootbank_bmcal_7.0.3-0.65.20842708 VMware_bootbank_vdfs_7.0.3-0.65.20842708 VMware_bootbank_esxio-combiner_7.0.3-0.65.20842708
Behobene Probleme	3021935, 2994966, 2983919, 3014323, 2996511, 2982013, 3011324, 3048788, 2983043, 3035934, 3015498, 3031708, 3041100, 3044475, 2990414, 3003866, 3011850, 3002779, 3033161, 3016132, 3015493, 3029194, 3007116, 2977496, 3021384, 2988179, 3025470, 3033159, 3011169, 3018832, 2977486, 2932056, 3013368, 2995471, 3006356, 2981272, 3000195, 3026623, 2981420, 3025469, 3042776, 2916160, 2996208, 3014374, 2977957, 2979281, 2976953, 2999968, 3031566, 3036859, 3029490, 2992407
CVE-Nummern	Nicht verfügbar

Die Bulletins „ESXi“ und „esx-update“ bauen aufeinander auf. Schließen Sie immer beide in eine einzelne ESXi-Host-Patch-Baseline oder das Rollup-Bulletin in die Baseline ein, um Fehler während des Patchens von Hosts zu vermeiden.

Aktualisiert die VIBs esx-xserver, gc, vsan, cpu-microcode, esx-base, esx-dvfilter-generic-fastpath, vsanhealth, native-misc-drivers, esx-ui, trx, bmcal, vdfs, esxio-combiner und crx zur Behebung der folgenden Probleme:

• PR 3021935: Bei VM-Ereignissen wird die Vorlageneigenschaft manchmal falsch gemeldet

  In seltenen Fällen kann es bei VM-Ereignissen zu einer inkorrekten Meldung der Eigenschaft template kommen. Diese Eigenschaft gibt an, ob eine virtuelle Maschine als Vorlage markiert ist. Infolgedessen besteht die Möglichkeit, dass die Eigenschaft template als true angezeigt wird, obwohl die VM keine Vorlage ist, oder aber als false, obwohl eine VM als Vorlage markiert ist.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2994966: Zu ESXi-Hosts werden in der MOB-Schnittstelle (Managed Object Browser) keine Speicherstatusinformationen angezeigt

  Aufgrund einer fehlenden Speichermoduleinheit für Cisco-Server im Managed Object Browser werden bei Verwendung von MOB unter Umständen keine Speicherstatusinformationen zu einem ESXi-Host angezeigt.

  Dieses Problem wurde in der vorliegenden Version behoben. Der Fix bewirkt zusätzliche Unterstützung für Speichermoduleinheit ID 8 (08h).

• PR 2983919: Nicht reagierende Active Directory-Domänencontroller können zeitweise dazu führen, dass der hostd-Dienst auch nicht mehr reagiert

  In sehr seltenen Fällen können zufällige Probleme mit Active Directory-Umgebungen, die einen Zustand bedingen können, in dem der Domänencontroller nicht mehr reagiert, auch dazu führen, dass der hostd-Dienst nicht mehr reagiert.

  Dieses Problem wurde in der vorliegenden Version behoben. Der Fix bewirkt, dass der hostd-Dienst weiterhin reagiert, wenn der Active Directory-Domänencontroller vorübergehend nicht reagiert.

• PR 3014323: Nach dem Erstellen einer VM oder dem Zurücksetzen auf einen VM-Snapshot werden die gastbezogenen Leistungsindikatoren in VMware Tools nicht mehr aktualisiert

  In seltenen Fällen kann es vorkommen, dass der interne Zustand des VMX-Prozesses aufgrund des schnellen Suspend-Resume-Mechanismus beim Erstellen oder Zurücksetzen einer VM basierend auf einem Snapshot ohne Benachrichtigung an die oberen Schichten des virtuellen Infrastrukturmanagement-Stacks neu initialisiert wird. Dies hat zur Folge, dass alle gastbezogenen Leistungsindikatoren in VMware Tools nicht mehr aktualisiert werden. In allen Schnittstellen zum ESXi-Host werden dauerhaft die zuletzt aufgezeichneten Werte angezeigt.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2996511: Der rhttpproxy-Dienst schlägt gelegentlich mit einem Coredump und der Meldung eines Pufferüberlaufs fehl

  Wenn der rhttpproxy-Dienst mehrere Vorgänge für eingehende URIs durchführt, kann er den Puffer-Offset der einzelnen Verbindungen falsch berechnen. Dies führt möglicherweise zu Fehlern wie Pufferüberläufen und negativen Lesevorgängen. Dies führt dazu, dass der Dienst fehlschlägt.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2982013: Sie können eine Hypercall-Option nicht ändern, wenn eine virtuelle Maschine eingeschaltet ist

  Standardmäßig funktioniert das Ändern von Hypercall-Optionen mithilfe von Befehlen wie vm | Get-AdvancedSetting -Name isolation.tools.autoInstall.disable nur, wenn die VM ausgeschaltet ist. Bei eingeschalteten VMs lösen solche Aufrufe den folgenden Fehler aus: Der versuchte Vorgang kann im aktuellen Zustand (Eingeschaltet) nicht durchgeführt werden. Dies wird erwartet.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 3011324: Mit dem Update von ESXi 7.0 Update 3c auf eine höhere Version werden alle erweiterten Sicherheitsoptionen eines ESXi-Hosts möglicherweise auf die Standardwerte zurückgesetzt

  Nachdem Sie einen ESXi 7.0 Update 3c-Host auf eine höhere Version von 7.0.x aktualisiert oder ein ESXi 7.0 Update 3c-VIB installiert oder entfernt und den Host neu gestartet haben, werden möglicherweise alle erweiterten Sicherheitsoptionen auf dem Host auf ihre Standardwerte zurückgesetzt. Folgende erweiterte Einstellungen sind betroffen:
  Security.AccountLockFailures
  Security.AccountUnlockTime
  Security.PasswordQualityControl
  Security.PasswordHistory
  Security.PasswordMaxDays
  Security.SshSessionLimit
  Security.DefaultShellAccess

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 3048788: SR-IOV-Geräte melden möglicherweise einen falschen NUMA-Knoten für virtuelle Funktionen

  Der Befehl esxcli hardware pci list, der den NUMA-Knoten für ESXi-Hostgeräte meldet, gibt für die physischen Funktionen (PF) eines SR-IOV-Geräts den korrekten NUMA-Knoten zurück, für seine virtuellen Funktionen (VF) hingegen null.

  Dieses Problem wurde in der vorliegenden Version behoben. Mit dem Fix wird sichergestellt, dass die NUMA-Knoten sowohl für PF als auch für VF von SR-IOV-Geräten konsistent sind.

• PR 2983043: Windows-Gastbetriebssystem schlägt nach der Migration von virtuellen Maschinen zu ESXi-Hosts der Version 7.0 Update 2 oder höher möglicherweise mit einem blauen Diagnosebildschirm fehl

  Wenn Sie virtuelle Windows-Maschinen nach einem Upgrade auf ESXi 7.0 Update 2 oder höher mithilfe von vSphere vMotion zu den aktualisierten Hosts migrieren, schlagen einige VMs nach der Migration möglicherweise mit einem blauen Diagnosebildschirm fehl. Auf dem Bildschirm wird die Fehlermeldung Betriebssystem konnte nicht gestartet werden, kein Betriebssystem gefunden angezeigt. Dieses Problem tritt aufgrund eines Fehlers in der Adressoptimierungslogik des Virtual Machine File System (VMFS) auf.

  Dieses Problem wurde in der vorliegenden Version behoben. 

• PR 3035934: ESXi-Hosts reagieren möglicherweise nicht mehr, wenn kein registrierter Standardanforderungshandler verfügbar ist, und die Ausführung von vmacore.dll schlägt fehl

  Wenn die Clientanwendung über keinen registrierten Standardanforderungshandler verfügt, können Anforderungen mit einem Pfad, der in der Handlerzuordnung nicht vorhanden ist, dazu führen, dass die Ausführung von vmacore.dll fehlschlägt. Dies führt dazu, dass der ESXi-Host vom vCenter Server-System getrennt ist.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 3015498: ESXi-Hosts schlagen während Reservierungsvorgängen für die Ressourcenzuteilung möglicherweise mit einem violetten Diagnosebildschirm fehl

  Einige Zuteilungsreservierungsvorgänge überschreiten möglicherweise den Grenzwert von 128 parallelen Reservierungsschlüsseln sowie den zugeteilten Arbeitsspeicherbereich eines ESXi-Hosts. Dies führt möglicherweise dazu, dass ESXi-Hosts während Reservierungsvorgängen für die Ressourcenzuteilung mit einem violetten Diagnosebildschirm fehlschlagen. Die Fehleranzeige enthält sinngemäße Meldungen wie z. B. PSOD BlueScreen: #PF-Ausnahme 14 in World 2097700:SCSI Periode IP.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 3031708: Während Vorgängen zum Aufheben der Geräte- oder Pfadbeanspruchung fallen ESXi-Hosts möglicherweise mit einem violetten Diagnosebildschirm fehl

  Wenn Sie einen Befehl zum Aufheben der Beanspruchung auf einem Gerät oder Pfad ausführen, während virtuelle Maschinen auf dem Gerät noch aktive E/A-Vorgänge aufweisen, schlägt der ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm fehl. Auf dem Bildschirm wird sinngemäß folgende Meldung angezeigt: PSOD bei bora/modules/vmkernel/nmp/nmp_misc.c:3839 beim Laden/Löschen von lpfc.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 3041100: Wenn TPM 2.0 mit TXT auf einem ESXi-Host aktiviert ist, schlagen Versuche, eine virtuelle Maschine einzuschalten, möglicherweise fehl

  Wenn TXT auf einem ESX-Host aktiviert ist, schlagen Versuche, eine VM einzuschalten, möglicherweise mit einem Fehler fehl. Im vSphere Client wird folgende Meldung angezeigt: Dieser Host unterstützt Intel VT-x, aber Intel VT-x ist eingeschränkt. Intel VT-x ist möglicherweise eingeschränkt, weil „trusted excecution“ in den BIOS/Firmware-Einstellungen aktiviert wurde oder der Host nach dem Ändern dieser Einstellung nicht aus- und wieder eingeschaltet wurde.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 3044475: Virtuelle Maschinen schlagen möglicherweise aufgrund eines seltenen Problems bei der Verarbeitung von AVX2-Anweisungen mit einem von ESX nicht behebbaren Fehler fehl

  Aufgrund eines seltenen Problems bei der Verarbeitung von AVX2-Anweisungen schlägt eine virtuelle Maschine der Version ESX 7.0 Update 3f möglicherweise mit einem von ESX nicht behebbaren Fehler fehl. In der Datei vmware.log wird sinngemäß folgende Meldung angezeigt: MONITOR PANIC: vcpu-0:VMM Fehler 6: src=MONITOR ....
  Das Problem ist spezifisch für virtuelle Maschinen mit Hardwareversionen 12 oder früher.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2990414: Upgrade-Vorgänge unter Verwendung einer vSphere Lifecycle Manager-Upgrade-Baseline mit einem benutzerdefinierten in vSphere ESXi Image Builder erstellten .iso-Image schlagen möglicherweise fehl

  Wenn Sie ein mithilfe von Image Builder erstelltes ESXi .iso-Image verwenden, um eine vSphere Lifecycle Manager-Upgrade-Baseline für ESXi-Hosts zu erstellen, schlagen Upgrades mithilfe solcher Baselines möglicherweise fehl. Im vSphere Client wird folgender Fehler angezeigt: Upgrade-Skript kann nicht auf Host ausgeführt werden.. Auf dem betroffenen ESXi-Host wird in der Datei /var/log/vua*.log sinngemäß folgender Fehler angezeigt: ValueError: Wenn ein Add-On vorhanden ist, sollte ein Basisimage vorhanden sein.
  Der Fehler tritt auf, wenn das vorhandene Image des ESXi-Hosts über ein Add-On verfügt, das von Image Builder generierte ISO-Image hingegen kein Add-On bereitstellt.

  Dieses Problem wurde in der vorliegenden Version behoben.
   

• PR 3003866: ESXi-Hosts schlagen möglicherweise aufgrund von unzureichendem XMAP-Speicher mit einem violetten Diagnosebildschirm fehl

  Viele parallele Anforderungen für Arbeitsspeicherbereiche durch virtuelle Maschinen, die das Data Plane Development Kit (DPDK) auf einem ESXi-Host verwenden, überschreiten möglicherweise den XMAP-Arbeitsspeicher auf dem Host. Folglich schlägt der Host mit einem violetten Diagnosebildschirm und sinngemäß folgender Fehlermeldung fehl: Panic Message: @BlueScreen: VERIFY bora/vmkernel/hardware/pci/config.c:157.

  Dieses Problem wurde in der vorliegenden Version behoben. Mit dem Fix werden die für alle vmxnet3-Adapter verfügbaren Standardarbeitsspeicherbereiche auf 8192 MB festgelegt.

• PR 3011850: Einige Leistungsberichte für virtuelle Maschinen mit NVMe-Controllern werden in ESXi 7.0 Update 3 und höher nicht angezeigt

  Nach einem Upgrade von ESXi-Hosts auf ESXi 7.0 Update 3 und höher werden möglicherweise einige Leistungsberichte für virtuelle Maschinen mit NVMe-Controllern nicht mehr angezeigt. Beispielsweise wird das Diagramm „Virtuelle Festplatte – Zusammenfassung aller Instanzen“ nicht in VMware Aria Operations angezeigt.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 3002779: ESXi-Host mit einer sekundären VM mit aktivierter Fault Tolerance-Verschlüsselung schlägt möglicherweise aufgrund eines Entschlüsselungspufferüberlaufs mit einem violetten Diagnosebildschirm fehl

  In seltenen Fällen, wie z. B. bei einem geplanten Neustart der primären virtuellen Maschine mit FT-Verschlüsselung, die hohe Arbeitslasten ausführt, verfügt die sekundäre virtuelle Maschine möglicherweise nicht über ausreichend Puffer, um mehr als 512 MB an modifizierten Seiten in einem einzelnen FT-Prüfpunkt zu entschlüsseln, und es tritt ein Pufferüberlauffehler auf. Dies führt dazu, dass der ESXi-Host, auf dem sich die sekundäre virtuelle Maschine befindet, möglicherweise mit einem violetten Diagnosebildschirm fehlschlägt.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 3033161: Nach einem Upgrade bzw. Update auf ESXi 7.0 Update 2 und höher ändert sich als Flash (SSD) markierter vSAN-Speicher möglicherweise in Magnetplattenspeicher (HDD)

  In seltenen Fällen kann die vSAN-Speicherkonfiguration nach einem Upgrade bzw. Update auf ESXi 7.0 Update 2 und höher das Tag mark_ssd verlieren und standardmäßig HDD verwenden.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 3016132: Es werden häufige Protokolle für die fehlgeschlagene Registrierung getrennter LUNs angezeigt

  Selbst wenn sich ein Gerät oder eine LUN im Zustand „Getrennt“ befindet, versucht die Pluggable Storage Architecture (PSA) möglicherweise weiterhin, das Objekt zu registrieren. Die PSA erstellt bei jedem Pfadauswertungsintervall dieser Versuche ein Protokoll für jeden Pfadauswertungsschritt. Infolgedessen werden möglicherweise mehrere identische Meldungen angezeigt, wie z. B. nmp_RegisterDeviceEvents fehlgeschlagen für die Geräteregistrierung, die bei getrenntem Gerät bzw. getrennter LUN nicht erforderlich sind.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 3015493: Wenn Sie eine Gerätekonfiguration zur Laufzeit ändern, kann ein Datenspeicher nach einem Neustart eines ESXi-Hosts möglicherweise nicht gemountet werden

  Wenn Sie eine Gerätekonfiguration zur Laufzeit ändern, werden Änderungen möglicherweise nicht im ESXi ConfigStore widergespiegelt, der die Konfigurationen für einen ESXi-Host enthält. Dies führt dazu, dass der Datenspeicher nach dem Neustart des ESXi-Hosts möglicherweise nicht gemountet wird.

  Dieses Problem wurde in der vorliegenden Version behoben. Der Fix stellt sicher, dass ConfigStore Änderungen der Gerätekonfiguration zur Laufzeit widerspiegelt.

• PR 3029194: Nach dem Upgrade auf ESXi 7.0 Update 3 und höher schlagen ESXi-Hosts möglicherweise aufgrund eines Legacy-E/A-Schedulers mit einem violetten Diagnosebildschirm fehl

  Ab ESXi 6.0 ist mClock der standardmäßige E/A-Scheduler für ESXi, aber einige Umgebungen verwenden möglicherweise weiterhin Legacy-Scheduler von ESXi-Versionen vor 6.0. Infolgedessen schlagen Upgrades dieser Hosts auf ESXi 7.0 Update 3 und höher möglicherweise mit einem violetten Diagnosebildschirm fehl.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 3007116: Wenn Sie ESXi-Hosts auf ESXi 7.0 Update 3d oder höher aktualisieren, indem Sie ein Hostprofil mit Token verwenden, die auf den ALUA-Status hinweisen, schlägt der Host möglicherweise mit einem violetten Diagnosebildschirm fehl

  Ab ESXi 7.0 Update 1 wurde die Konfigurationsverwaltung von ESXi-Hosts aus der Datei /etc/vmware/esx.conf in das ConfigStore-Framework verschoben. Dadurch erfolgt eine explizite Trennung von Status und Konfiguration. Token in der esx.conf-Datei, wie z. B. implicit_support oder explicit_support, die einen Status angeben, werden nicht als gültige Token erkannt und vom satp_alua-Modul ignoriert. Wenn Sie ESXi-Hosts mithilfe eines Hostprofils mit Token, die den ALUA-Status angeben, auf ESXi 7.0 Update 3d oder höher aktualisieren, könnte der Vorgang daher mit einem violetten Diagnosebildschirm fehlschlagen. Auf dem Bildschirm wird sinngemäß folgende Fehlermeldung angezeigt: Modulfehler: /var/lib/vmware/configmanager/upgrade/lib/postLoadStore/libupgradepsadeviceconfig.so.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2977496: Ein ESXi-Host reagiert möglicherweise aufgrund eines Zuteilungsproblems mit einem seltenen Dateiblock (FB) nicht mehr

  Ein Hilfsmechanismus, der FB-Ressourcenzuteilungsdetails im Hintergrund zwischenspeichert, kann die FB-Ressourcenzuteilung an den ESXi-Host während E/A-Vorgängen versehentlich anhalten und blockieren. In einigen Fällen wirkt sich dieses Problem möglicherweise auf andere Prozesse aus, die für dieselbe Datei ausgeführt werden, und blockiert sie. Dies kann dazu führen, dass der ESXi-Host nicht mehr reagiert.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 3021384: vSAN-Dateidienst kann nicht aktiviert werden, wenn ein isoliertes Zeugennetzwerk konfiguriert ist

  Der vSAN-Dateidienst erfordert, dass Hosts miteinander kommunizieren. Der Dateidienst verwendet möglicherweise fälschlicherweise eine IP-Adresse im Zeugennetzwerk für die Interkommunikation. Wenn Sie ein isoliertes Zeugennetzwerk für vSAN konfiguriert haben, kann der Host über das Zeugennetzwerk mit einem Zeugenknoten kommunizieren, aber Hosts können über das Zeugennetzwerk nicht miteinander kommunizieren. Die Kommunikation zwischen Hosts für den vSAN-Dateidienst kann nicht hergestellt werden.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2988179: Wenn sich ein ESXi-Host im Zustand „Geringer Arbeitsspeicher“ befindet, könnte eine unzureichende Heap-Zuteilung zu einem Netzwerkmodul dazu führen, dass der Host mit einem violetten Diagnosebildschirm fehlschlägt

  Wenn sich ein ESXi-Host im Zustand „Geringer Arbeitsspeicher“ befindet, könnte eine unzureichende Heap-Zuteilung zu einem Netzwerkmodul dazu führen, dass die Port-Bitmap auf NULL festgelegt wird. Folglich kann ein ESXi-Host bei einem Paketweiterleitungsversuch mit einem violetten Diagnosebildschirm fehlschlagen.

  Dieses Problem wurde in der vorliegenden Version behoben. Mit dem Fix wird sichergestellt, dass Bitvektoren in der portsBitmap-Eigenschaft nur dann festgelegt werden, wenn die Heap-Zuteilung erfolgreich ist. Sie müssen jedoch weiterhin sicherstellen, dass ESXi-Hosts über ausreichend RAM verfügen, um Pakete erfolgreich zu verarbeiten und weiterzuleiten.

• PR 3025470:  Der CLOMD-Daemon (Cluster Level Object Manager Daemon) schlägt während der Änderung des Objektformats fehl

  Während der Änderung des Objektformats werden einige Objekte mit altem Layout möglicherweise teilweise bereinigt, sodass die Konfiguration in einem ungültigen Zustand bleibt. Dieses Problem kann dazu führen, dass CLOMD immer dann fehlschlägt, wenn versucht wird, das Objekt während der Neukonfiguration zu verarbeiten.
  
  Möglicherweise werden die folgenden Einträge in der clomd.log-Datei angezeigt:
  
  2022-10-14T16:17:26.456Z PANIC: NOT_REACHED bora/lib/vsan/vsan_config_builder.c:744
2022-10-14T16:17:26.456Z Backtrace:
2022-10-14T16:17:26.456Z Backtrace[0] 0000030b4742c6a0 rip=000000bf0c7de98f rbx=0000030b4742c6a0
rbp=0000030b4742cad0 r12=000000bf0d677788 r13=0000030b4742cae8 r14=000000bf14ce052c r15=000000bf14ce3c2c

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 3033159: ESXi-Hosts schlagen möglicherweise mit einem violetten Diagnosebildschirm fehl, wenn eine VM mit der Einstellung „Physical“ (Physisch) für die gemeinsame Bus-Nutzung einen SCSI-2-Reservierungsbefehl ausgibt

  Windows 2012 und höher verwendet die SCSI-3-Reservierung für die Ressourcenvermittlung, um Windows Failover Clustering (WSFC) auf ESXi für systemübergreifende Cluster-Konfigurationen (Cluster-across-box, CAB) zu unterstützen. Wenn Sie jedoch die Einstellung Physical für die gemeinsame Bus-Nutzung des SCSI-Controllers auf dieser VM konfigurieren, führt der Befehl SCSI RESERVE dazu, dass der ESXi-Host mit einem violetten Diagnosebildschirm fehlschlägt. SCSI RESERVE ist eine SCSI-2-Semantik und wird für WSFC-Cluster auf ESXi nicht unterstützt.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 3011169: vSAN Clusterüberlastung aufgrund von Cache-Ansammlung

  vSAN könnte das Destaging von Daten aufgrund eines Problems beim Zählen ausstehender E/As beenden. Wenn eine vSAN-Festplattengruppe das Destaging von Daten aus dem Cache in die Kapazitätsschicht beendet, kann dies dazu führen, dass sich Daten in der Cache-Ebene ansammeln. Dieses Problem führt zu Überlastung, E/A-Drosselung und längerer Latenz.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 3018832: Wenn ein Cluster ein 0-Byte-Objekt enthält, schlagen vSAN Hosts möglicherweise mit einem violetten Diagnosebildschirm fehl

  Wenn ein vSAN-Cluster mit einem 0-Byte-Objekt eine Richtlinienänderungsanforderung empfängt, legt der Cluster Level Object Manager (CLOM) möglicherweise fälschlicherweise ein ungültiges Flag für eine oder mehrere Komponenten des Objekts fest. Ein solches Flag kann dazu führen, dass der Host große Schreibvorgänge sendet, die das System überlasten, sodass der Host mit einem violetten Diagnosebildschirm fehlschlägt.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2977486: Zeitweiliger Sperrungskonflikt für VMFS-Journalblöcke verzögert möglicherweise Befehle zum erneuten Prüfen von VMFS oder führt dazu, dass das Mounten eines Datenspeichers fehlschlägt

  Ein seltenes Problem bei der Verarbeitung von VMFS-Journalblöcken kann zu Sperrungskonflikten führen, wodurch Verzögerungen bei erneuten VMFS-Prüfungen entstehen oder das Mounten von Datenspeichern fehlschlägt. In den VMkernel-Protokollen werden Fehler angezeigt, wie z. B. Ressourcendatei für Ressource: 6 hat den maximalen Grenzwert von 8192 erreicht und Ressourcen-Dateierweiterung (‚Kein Speicherplatz frei auf Gerät‘).

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2932056: Der vmx-Dienst schlägt möglicherweise beim Abbrechen einer vSphere Storage vMotion-Aufgabe fehl, und vCenter Server High Availability startet virtuelle Maschinen neu

  In seltenen Fällen kann der vmx-Dienst während des Abbrechens einer vSphere Storage vMotion-Aufgabe fehlschlagen. Wenn Ihre Umgebung vCenter Server High Availability verwendet, startet der Dienst die betroffenen virtuellen Maschinen daher neu.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 3013368: Während des Startvorgangs werden Fehler angezeigt, die angeben, dass die Unterstützung für SD-Karten- und reine USB-Konfigurationen veraltet ist.

  Wenn Sie zum Starten von ESXi 7.x nur SD- oder USB-Geräte verwenden, werden möglicherweise Fehler angezeigt, wie z. B. Unterstützung der Konfiguration nur für SD-Karte/USB wird eingestellt. Diese Meldung weist nicht auf einen Fehler hin, sondern enthält nur eine Warnung, dass SD- und USB-Geräte nur für Bootbank-Partitionen unterstützt werden, und dass für eine optimale Leistung ein sekundärer persistenter Speicher mit mindestens 32 GB für /scratch und VMware Tools bereitgestellt werden muss, die sich in der OSData-Partition befinden.

  Dieses Problem wurde in der vorliegenden Version behoben. Der Klarheit halber wird die Meldung mit dem Fix entfernt, da Bereitstellungen ohne persistenten Speicher unterstützt werden, auch wenn es sich nicht um eine Best Practice handelt.

• PR 2995471: vSAN-Festplatte aufgrund eines nicht verfügbaren Verschlüsselungsschlüssels verschlüsselt und gesperrt

  Dieses Problem betrifft vSAN-Hosts, die einen externen KMS für die Verschlüsselung ruhender Daten verwenden. Wenn Sie ein Upgrade eines vSAN-Hosts von 6.7 oder früher auf 7.0 und höher durchführen, geht das KMS-Kennwort verloren. Die Festplatten des Hosts bleiben verschlüsselt und gesperrt.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 3006356: ESXi-Host schlägt aufgrund der erneuten Bindung von virtuellen Volumes mit einem violetten Diagnosebildschirm fehl

  In seltenen Fällen versuchen vSphere Virtual Volumes möglicherweise eine erneute Bindung von Volumes auf ESXi-Hosts mit persistenten SCSI-Reservierungen. Dies führt dazu, dass die ESXi-Hosts mit einem violetten Diagnosebildschirm fehlschlagen und im Backtrace folgende sinngemäße Fehlermeldung angezeigt wird: Panik-Meldung: @BlueScreen: PANIC bora/vmkernel/main/dlmalloc.c:4933 – Nutzungsfehler in dlmalloc.

  Dieses Problem wurde in der vorliegenden Version behoben. 

• PR 2981272: vSphere Client zeigt unabhängig von der tatsächlichen VMDK-Größe einer virtuellen Maschine 0 KB an

  Aufgrund eines Caching-Problems wird im vSphere Client möglicherweise eine VMDK-Größe von 0 KB angezeigt, unabhängig von der tatsächlichen Größe der virtuellen Maschinen in einer vSphere Virtual Volumes-Umgebung.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 3000195: Bei einem Site-übergreifenden Advanced Cross vCenter vMotion-Vorgang tritt möglicherweise eine Zeitüberschreitung auf und einige virtuelle Maschinen reagieren nicht mehr

  Während der Speichermigration eines Site-übergreifenden Advanced Cross vCenter vMotion-Vorgangs werden möglicherweise einige asynchrone E/A-Vorgänge im Speicher-Stack gesperrt und es tritt keine ordnungsgemäße Zeitüberschreitung auf. Dies führt dazu, dass virtuelle Maschinen weiterhin auf eine E/A-Antwort warten. Dadurch tritt beim Advanced Cross vCenter vMotion-Vorgang eine Zeitüberschreitung auf, und die virtuellen Maschinen reagieren nicht mehr.

  Dieses Problem wurde in der vorliegenden Version behoben. Mit dem Fix wird allen asynchronen E/A-Anforderungen eine Zeitüberschreitung hinzugefügt, um eine Antwort nach der Zeitüberschreitung zu gewährleisten.

• PR 3026623: LLOG-Wiederherstellung markiert vSAN-Komponenten möglicherweise fälschlicherweise als ungültig

  Ein Problem während der LLOG-Wiederherstellung kann dazu führen, dass eine vSAN-Komponente fälschlicherweise als ungültig markiert wird. Dieses Problem kann zu einer Ansammlung von Protokollen und somit zu Überlastung führen.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2981420: Der Small-Footprint CIM Broker Daemon (SFCBD) reagiert möglicherweise vorübergehend nicht mehr

  Aufgrund einer unzureichenden Ressourcenpoolzuteilung schlagen einige an den SFCBD berichtende Dienste, wie z. B. sfcb-vmware_base und sfcb-vmw, möglicherweise fehl und generieren zdump. In der syslog.log-Datei werden Fehlermeldungen wie die folgenden angezeigt:
  sfcb-vmware_base[2110110]: tool_mm_realloc_or_die: memory re-allocation failed(orig=364000 new=364800 msg=Cannot allocate memory, aborting
sfcb-vmw_ipmi[2291550]: tool_mm_realloc_or_die: memory re-allocation failed(orig=909200 new=909600 msg=Cannot allocate memory, aborting

  Dieses Problem wurde in der vorliegenden Version behoben. Der Fix erhöht die Standardpoolgröße für den sfcb-vmware_base-Dienst.

• PR 3025469:  Wenn es sich bei der Zielrichtlinie um RAID 1, StripeWidth 1 handelt, wird die Neukonfiguration großer Objekte in einem vSAN-Cluster möglicherweise ohne Fortschritt beendet

  Wenn es sich bei der Zielrichtlinie um RAID 1, StripeWidth 1 handelt und ein vSAN-Cluster nur noch wenige vorübergehende Kapazitäten aufweist, konfiguriert der Cluster Level Object Manager möglicherweise weiterhin denselben Teil von Objekten neu, der größer als 8 TB ist. Infolgedessen verbleiben diese Objekte im nicht übereinstimmenden Zustand, und möglicherweise werden einige unnötige Neusynchronisierungsvorgänge angezeigt.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 3042776: Storage I/O Control generiert schnell eine große Anzahl von Protokollen, die als kritisch markiert sind und möglicherweise auch den Datenspeicher füllen

  In VMware Aria Operations for Logs (vormals vRealize Log Insight) wird möglicherweise eine große Anzahl von Protokollen angezeigt, die von Storage I/O Control generiert werden, z. B. Ungültiger Wert für Freigaben: 0. Standard wird verwendet. und Gerät naa.xxxx wird entweder aufgrund eines VSI-Lesefehlers oder eines abnormalen Status übersprungen. Das Protokollvolumen variiert je nach der Anzahl der ESXi-Hosts in einem Cluster und der Anzahl der Geräte im ausgeschalteten Zustand. Wenn das Problem auftritt, wird das Protokollvolume schnell (innerhalb von 24 Stunden) generiert, und VMware Aria Operations for Logs stuft die Meldungen möglicherweise als kritisch ein. Diese Protokolle sind jedoch unbedenklich und wirken sich nicht auf die Vorgänge auf anderen Online-Datenspeichern aus.

  Dieses Problem wurde in der vorliegenden Version behoben. Der Fix verschiebt diese Protokolle von „Fehler“ zu „Ausführlich (erweitert)“, um eine irreführende Protokollierung zu verhindern. 

• PR 2916160: ESXi Managed Object Browser (MOB) zeigt als CPU-Status „Unbekannt“ an

  Wenn die Liste der Speichersensoren eines ESXi-Hosts leer ist, wird der von der Intelligent Platform Management Interface (IPMI) gemeldete CPU-Status möglicherweise zurückgesetzt. Dies führt dazu, dass der Sensordatensatz mit Element ID 3, dem Status des Prozessors, fälschlicherweise als Über aktuellen Status des physischen Elements kann nicht berichtet werden im MOB angezeigt wird.

  Dieses Problem wurde in der vorliegenden Version behoben. Mit dem Fix wird sichergestellt, dass der CPU-Status nur zurückgesetzt wird, wenn die Aktualisierung des Sensorstatus über die IPMI fehlschlägt.

• PR 2996208: Für Objekte in einem Stretched Cluster wird eine hohe Leselatenz angezeigt 

  In Stretched Clustern stellt vSAN jedes VMDK-Objekt mit einem bestimmten Format bereit. Wenn Sie die Richtlinie eines VMDK-Objekts von hostFailuresToTolerate=0 in hostFailuresToTolerate=1 ändern, ändert sich das Format möglicherweise so, dass Lesevorgänge den Site-übergreifenden (AZ-übergreifenden) Link durchlaufen. Dies führt dazu, dass in diesen Objekten eine höhere Leselatenz angezeigt wird.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 3014374: Im vSphere Client werden wiederholte Optionen im Dropdown-Menü „Gemeinsame Verwendung des SCSI-Busses“ angezeigt

  Wenn Sie im vSphere Client eine virtuelle Maschine erstellen oder neu konfigurieren, werden dieselben Optionen im Dropdown-Menü unter SCSI-Controller > Gemeinsame Verwendung des SCSI-Busses möglicherweise doppelt angezeigt. Auf Workflows zum Erstellen oder Konfigurieren der VM hat das Problem keine Auswirkungen.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2977957: Nach einem Migrationsvorgang fallen virtuelle Maschinen mit Windows 10 unter Umständen aus, wobei ein blauer Diagnosebildschirm angezeigt und eine falsche Microcoderevision gemeldet wird

  Nach einem Migrationsvorgang fallen virtuelle Maschinen mit Windows 10 unter Umständen aus, wobei ein blauer Diagnosebildschirm angezeigt wird und in einer Fehlermeldung wie der folgenden eine falsche Microcoderevision gemeldet wird: – MICROCODE_REVISION_MISMATCH (17e). Das Problem tritt auf, wenn während des Migrationsvorgangs ein Scan der CPUs durchgeführt wird und die Firmware der Quell-CPUs nicht mit der Firmware der Ziel-CPUs übereinstimmt.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2979281: ESXi-Hosts reagieren möglicherweise nicht mehr, weil aufgrund eines veralteten Caches zeitweilig nicht genügend Arbeitsspeicher vorhanden ist

  In bestimmten Fällen schlägt das Löschen des Caches von Objekten in einem Datenspeichervolume auf ESXi-Hosts fehl, Objekte verbleiben im Cache und führen dazu, dass nicht genügend Arbeitsspeicher vorhanden ist. Dies kommt beispielsweise vor, wenn die Verbindung mit dem zugrunde liegenden Gerät des Volumes unterbrochen wird. Folglich reagiert der ESXi-Host nicht mehr. In den Protokollen werden Fehler angezeigt, wie z. B.:
  Erneute Verbindung mit xxxxx nicht möglich] oder Fehler beim Bereinigen von VMFS-Taktsignal auf Volume xxxxx: Keine Verbindung. oder
  Das Volume auf dem Gerät xxxxx ist gesperrt, möglicherweise weil während eines Volume-Vorgangs ein nicht behebbarer Fehler auf einem Remotehost aufgetreten ist.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2976953: Der hostd-Dienst schlägt möglicherweise fehl und virtuelle Maschinen werden aufgrund zeitweiliger Auslastung des Objekt-Caches heruntergefahren

  Bestimmte Workflows wie Sicherungsvorgänge von ESXi-Hosts können eine große Anzahl von Dateien öffnen, was wiederum zu einer Auslastung des Objekt-Caches führen kann. In solchen Fällen kann es vorkommen, dass der hostd-Dienst fehlschlägt, virtuelle Maschinen heruntergefahren werden oder die VM in einen ungültigen Zustand versetzt wird, der ihr Einschalten verhindert. In den Protokollen werden Warnungen angezeigt, wie z. B. Es konnte kein Arbeitsspeicher zugeteilt werden.

  Dieses Problem wurde in der vorliegenden Version behoben. Der Fix verdoppelt die Größe des Objekt-Caches auf 183 MB, um hohe Arbeitslasten zu bewältigen.

• PR 2999968: vSAN-Systemzustand meldet einen Fehler, dass der Dateiserver neu gestartet wird

  In Überwachen > Skyline Health > Dateidienst > Integrität des Dateiservers wird möglicherweise die Fehlermeldung Dateiserver wird (neu) gestartet angezeigt.
  Das Problem wird durch eine Cache-Überlauffunktion verursacht, die zu einem Ausfall des VDFS-Daemons führt. In der Datei /var/run/log/vdfsd-server.log in einem betroffenen ESXi-Host werden Meldungen wie NOT_IMPLEMENTED bora/vdfs/core/VDFSPhysicalLog.cpp angezeigt.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 3031566: Das Ändern der Richtlinie einer eingeschalteten VM mit einem IDE-Controller löst eine Fehlermeldung aus, dass der versuchte Vorgang im aktuellen Zustand nicht durchgeführt werden kann

  Wenn Sie im vSphere Client die Richtlinie einer eingeschalteten VM mit einem IDE-Controller ändern, wird möglicherweise folgender Fehler angezeigt: Der versuchte Vorgang kann im aktuellen Zustand (Eingeschaltet) nicht durchgeführt werden.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 3036859: HCI Mesh kann den Cluster nach dem erneuten Aktivieren von vSAN mit zuvor aktivierter Verschlüsselung in Übertragung begriffener Daten nicht mounten

  Das Mounten des HCI Mesh-Clusters schlägt möglicherweise fehl, wenn Sie vSAN erneut aktivieren, nachdem Sie vSAN mit Verschlüsselung in Übertragung begriffener Daten deaktiviert haben.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 3029490: vSAN Skyline Health enthält keine Hardwarekompatibilitätsgruppe

  Wenn für vSAN verwendete NVMe-Laufwerke über eine doppelte PCI-ID verfügen und Sie den vSAN-Integritätsdienst auf vCenter Server neu starten, fehlt die Hardwarekompatibilitätsgruppe aus vSAN Skyline Health.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2992407: Der TPM 2.0-Nachweis schlägt auf Lenovo-Servern möglicherweise mit einem Fehler aufgrund unzureichenden Puffers fehl

  Der TPM 2.0-Nachweis auf Lenovo-Servern gibt den TPM-Fehlercode zurück: TSS2_SYS_RC_INSUFFICIENT_BUFFER.

  Dieses Problem wurde in der vorliegenden Version behoben.

esx-update_7.0.3-0.65.20842708

Patch-Kategorie	Fehlerkorrektur
Patch-Schweregrad	Kritisch
Hostneustart erforderlich	Ja
Migration oder Herunterfahren der virtuellen Maschine erforderlich	Ja
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Enthaltene VIBs	VMware_bootbank_esx-update_7.0.3-0.65.20842708 VMware_bootbank_loadesx_7.0.3-0.65.20842708
Behobene Probleme	Nicht verfügbar
CVE-Nummern	Nicht verfügbar

Aktualisiert die VIBs loadesx und esx-update.

Broadcom-ntg3_4.1.8.0-4vmw.703.0.65.20842708

Patch-Kategorie	Fehlerkorrektur
Patch-Schweregrad	Kritisch
Hostneustart erforderlich	Ja
Migration oder Herunterfahren der virtuellen Maschine erforderlich	Ja
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Enthaltene VIBs	VMW_bootbank_ntg3_4.1.8.0-4vmw.703.0.65.20842708
Behobene Probleme	3007883
CVE-Nummern	Nicht verfügbar

Aktualisiert das VIB ngt3 zur Behebung des folgenden Problems:

• PR 3007883: Bei NICs, die den Treiber ntg3 der Version 4.1.3 und höher verwenden, tritt Link Flapping auf

  Wenn zwei NICs, die den Treiber ntg3 der Version 4.1.3 und höher verwenden, direkt und nicht mit einem physischen Switch-Port verbunden sind, kann Link Flapping auftreten. Das Problem tritt nicht bei ntg3-Treibern mit Versionen vor 4.1.3 oder dem tg3-Treiber auf. Dieses Problem steht nicht im Zusammenhang mit dem gelegentlich auftretenden Energy Efficient Ethernet (EEE) Link Flapping bei solchen NICs. Die Lösung für das EEE-Problem besteht darin, einen ntg3-Treiber der Version 4.1.7 oder höher zu verwenden oder EEE an physischen Switch-Ports zu deaktivieren.

  Dieses Problem wurde in der vorliegenden Version behoben. ESXi 7.0 Update 3i enthält den ntg3-Treiber der Version 4.1.8. Nach dem Upgrade des ntg3-Treibers auf Version 4.1.8 müssen Sie jedoch den neuen Modulparameter noPhyStateSet auf 1 setzen. Der Parameter noPhyStateSet ist standardmäßig auf 0 gesetzt und wird in den meisten Umgebungen nicht benötigt, es sei denn, sie sind von dem Problem betroffen.

ESXi_7.0.3-0.60.20841705

Patch-Kategorie	Sicherheit
Patch-Schweregrad	Kritisch
Hostneustart erforderlich	Ja
Migration oder Herunterfahren der virtuellen Maschine erforderlich	Ja
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Enthaltene VIBs	VMware_bootbank_esx-base_7.0.3-0.60.20841705 VMware_bootbank_trx_7.0.3-0.60.20841705 VMware_bootbank_vsanhealth_7.0.3-0.60.20841705 VMware_bootbank_cpu-microcode_7.0.3-0.60.20841705 VMware_bootbank_crx_7.0.3-0.60.20841705 VMware_bootbank_vsan_7.0.3-0.60.20841705 VMware_bootbank_native-misc-drivers_7.0.3-0.60.20841705 VMware_bootbank_esx-xserver_7.0.3-0.60.20841705 VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.3-0.60.20841705 VMware_bootbank_gc_7.0.3-0.60.20841705 VMware_bootbank_esx-ui_2.1.1-20188605 VMware_bootbank_vdfs_7.0.3-0.60.20841705 VMware_bootbank_bmcal_7.0.3-0.60.20841705 VMware_bootbank_esxio-combiner_7.0.3-0.60.20841705
Behobene Probleme	2993721, 3007957, 3007958, 3015560, 3034286, 3038621, 3030691
CVE-Nummern	CVE-2020-28196, CVE-2022-31696, CVE-2022-31699

Die Bulletins „ESXi“ und „esx-update“ bauen aufeinander auf. Schließen Sie immer beide in eine einzelne ESXi-Host-Patch-Baseline oder das Rollup-Bulletin in die Baseline ein, um Fehler während des Patchens von Hosts zu vermeiden.

Aktualisiert die VIBs esx-ui, esx-xserver, cpu-microcode, trx, vsanhealth, esx-base, esx-dvfilter-generic-fastpath, gc, esxio-combiner, native-misc-drivers, bmcal, vsan, vdfs und crx zur Behebung der folgenden Probleme:

• Das VIB „cpu-microcode“ enthält den folgenden Intel-Microcode:

  Codename	FMS	PLT-ID	MCU-Rev.	MCU-Datum	Markennamen
  Nehalem EP	0x106a5 (06/1a/5)	0x03	0x0000001d	5/11/2018	Intel Xeon 35xx-Reihe; Intel Xeon 55xx-Reihe
  Clarkdale	0x20652 (06/25/2)	0x12	0x00000011	5/8/2018	Intel i3/i5 Clarkdale-Reihe; Intel Xeon 34xx Clarkdale-Reihe
  Arrandale	0x20655 (06/25/5)	0x92	0x00000007	4/23/2018	Intel Core i7-620LE-Prozessor
  Sandy Bridge DT	0x206a7 (06/2a/7)	0x12	0x0000002f	2/17/2019	Intel Xeon E3-1100-Reihe; Intel Xeon E3-1200-Reihe; Intel i7-2655-LE-Reihe; Intel i3-2100-Reihe
  Westmere EP	0x206c2 (06/2c/2)	0x03	0x0000001f	5/8/2018	Intel Xeon 56xx-Reihe; Intel Xeon 36xx-Reihe
  Sandy Bridge EP	0x206d6 (06/2d/6)	0x6d	0x00000621	3/4/2020	Intel Pentium 1400-Reihe; Intel Xeon E5-1400-Reihe; Intel Xeon E5-1600-Reihe; Intel Xeon E5-2400-Reihe; Intel Xeon E5-2600-Reihe; Intel Xeon E5-4600-Reihe
  Sandy Bridge EP	0x206d7 (06/2d/7)	0x6d	0x0000071a	3/24/2020	Intel Pentium 1400-Reihe; Intel Xeon E5-1400-Reihe; Intel Xeon E5-1600-Reihe; Intel Xeon E5-2400-Reihe; Intel Xeon E5-2600-Reihe; Intel Xeon E5-4600-Reihe
  Nehalem EX	0x206e6 (06/2e/6)	0x04	0x0000000d	5/15/2018	Intel Xeon 65xx-Reihe; Intel Xeon 75xx-Reihe
  Westmere EX	0x206f2 (06/2f/2)	0x05	0x0000003b	5/16/2018	Intel Xeon E7-8800-Reihe; Intel Xeon E7-4800-Reihe; Intel Xeon E7-2800-Reihe
  Ivy Bridge DT	0x306a9 (06/3a/9)	0x12	0x00000021	2/13/2019	Intel i3-3200-Reihe; Intel i7-3500-LE/UE; Intel i7-3600-QE; Intel Xeon E3-1200-v2-Reihe; Intel Xeon E3-1100-C-v2-Reihe; Intel Pentium B925C
  Haswell DT	0x306c3 (06/3c/3)	0x32	0x00000028	11/12/2019	Intel Xeon E3-1200-v3-Reihe; Intel i7-4700-EQ-Reihe; Intel i5-4500-TE-Reihe; Intel i3-4300-Reihe
  Ivy Bridge EP	0x306e4 (06/3e/4)	0xed	0x0000042e	3/14/2019	Intel Xeon E5-4600-v2-Reihe; Intel Xeon E5-2600-v2-Reihe; Intel Xeon E5-2400-v2-Reihe; Intel Xeon E5-1600-v2-Reihe; Intel Xeon E5-1400-v2-Reihe
  Ivy Bridge EX	0x306e7 (06/3e/7)	0xed	0x00000715	3/14/2019	Intel Xeon E7-8800/4800/2800-v2-Reihe
  Haswell EP	0x306f2 (06/3f/2)	0x6f	0x00000049	8/11/2021	Intel Xeon E5-4600-v3-Reihe; Intel Xeon E5-2600-v3-Reihe; Intel Xeon E5-2400-v3-Reihe; Intel Xeon E5-1600-v3-Reihe; Intel Xeon E5-1400-v3-Reihe
  Haswell EX	0x306f4 (06/3f/4)	0x80	0x0000001a	5/24/2021	Intel Xeon E7-8800/4800-v3-Serie
  Broadwell H	0x40671 (06/47/1)	0x22	0x00000022	11/12/2019	Intel Core i7-5700EQ; Intel Xeon E3-1200-v4-Reihe
  Avoton	0x406d8 (06/4d/8)	0x01	0x0000012d	16.09.2019	Intel Atom C2300-Reihe; Intel Atom C2500-Reihe; Intel Atom C2700-Reihe
  Broadwell EP/EX	0x406f1 (06/4f/1)	0xef	0x0b000040	5/19/2021	Intel Xeon E7-8800/4800-v4-Reihe; Intel Xeon E5-4600-v4-Reihe; Intel Xeon E5-2600-v4-Reihe; Intel Xeon E5-1600-v4-Reihe
  Skylake SP	0x50654 (06/55/4)	0xb7	0x02006e05	3/8/2022	Intel Xeon Platinum 8100-Reihe; Intel Xeon Gold 6100/5100, Silver 4100, Bronze 3100-Reihe; Intel Xeon D-2100-Reihe; Intel Xeon D-1600-Reihe; Intel Xeon W-3100-Reihe; Intel Xeon W-2100-Reihe
  Cascade Lake B-0	0x50656 (06/55/6)	0xbf	0x04003302	12/10/2021	Intel Xeon Platinum 9200/8200-Reihe; Intel Xeon Gold 6200/5200; Intel Xeon Silver 4200/Bronze 3200; Intel Xeon W-3200
  Cascade Lake	0x50657 (06/55/7)	0xbf	0x05003302	12/10/2021	Intel Xeon Platinum 9200/8200-Reihe; Intel Xeon Gold 6200/5200; Intel Xeon Silver 4200/Bronze 3200; Intel Xeon W-3200
  Cooper Lake	0x5065b (06/55/b)	0xbf	0x07002501	11/19/2021	Intel Xeon Platinum 8300-Reihe; Intel Xeon Gold 6300/5300
  Broadwell DE	0x50662 (06/56/2)	0x10	0x0000001c	17.06.2019	Intel Xeon D-1500-Reihe
  Broadwell DE	0x50663 (06/56/3)	0x10	0x0700001c	6/12/2021	Intel Xeon D-1500-Reihe
  Broadwell DE	0x50664 (06/56/4)	0x10	0x0f00001a	6/12/2021	Intel Xeon D-1500-Reihe
  Broadwell NS	0x50665 (06/56/5)	0x10	0x0e000014	9/18/2021	Intel Xeon D-1600-Reihe
  Skylake H/S	0x506e3 (06/5e/3)	0x36	0x000000f0	11/12/2021	Intel Xeon E3-1500-v5-Reihe; Intel Xeon E3-1200-v5-Reihe
  Denverton	0x506f1 (06/5f/1)	0x01	0x00000038	12/2/2021	Intel Atom C3000-Reihe
  Ice Lake SP	0x606a6 (06/6a/6)	0x87	0x0d000375	4/7/2022	Intel Xeon Silver 4300-Reihe; Intel Xeon Gold 6300/5300-Reihe; Intel Xeon Platinum 8300-Reihe
  Ice Lake D	0x606c1 (06/6c/1)	0x10	0x010001f0	6/24/2022	Intel Xeon D-Reihe
  Snow Ridge	0x80665 (06/86/5)	0x01	0x4c000020	5/10/2022	Intel Atom P5000 Series
  Snow Ridge	0x80667 (06/86/7)	0x01	0x4c000020	5/10/2022	Intel Atom P5000 Series
  Kaby Lake H/S/X	0x906e9 (06/9e/9)	0x2a	0x000000f0	11/12/2021	Intel Xeon E3-1200-v6-Reihe; Intel Xeon E3-1500-v6-Reihe
  Coffee Lake	0x906ea (06/9e/a)	0x22	0x000000f0	11/15/2021	Intel Xeon E-2100-Reihe; Intel Xeon E-2200-Reihe (4 oder 6 Kerne)
  Coffee Lake	0x906eb (06/9e/b)	0x02	0x000000f0	11/12/2021	Intel Xeon E-2100-Reihe
  Coffee Lake	0x906ec (06/9e/c)	0x22	0x000000f0	11/15/2021	Intel Xeon E-2100-Reihe
  Coffee Lake Refresh	0x906ed (06/9e/d)	0x22	0x000000f4	7/31/2022	Intel Xeon E-2200-Reihe (8 Kerne)
  Rocket Lake S	0xa0671 (06/a7/1)	0x02	0x00000056	8/2/2022	Intel Xeon E-2300-Reihe

• ESXi 7.0 Update 3i stellt die folgenden Sicherheits-Updates bereit:
  • OpenSSL wird auf Version 1.0.2zf aktualisiert.
  • Apache Thrift wurde auf Version 0.15.0 aktualisiert.
  • Der urllib3-Client wird auf Version 1.26.5 aktualisiert.
  • cURL wurde auf Version 7.84.0 aktualisiert.
  • Die SQLite-Datenbank wird auf Version 3.39.2 aktualisiert.
  • Der XML-Parser Expat wurde auf Version 2.4.9 aktualisiert.

• In dieser Version werden die Schwachstellen CVE-2022-31696 und CVE-2022-31699 behoben. Weitere Informationen zu diesen Schwachstellen und deren Auswirkungen auf VMware Produkte finden Sie unter VMSA-2022-0030.

esx-update_7.0.3-0.60.20841705

Patch-Kategorie	Fehlerkorrektur
Patch-Schweregrad	Kritisch
Hostneustart erforderlich	Ja
Migration oder Herunterfahren der virtuellen Maschine erforderlich	Ja
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Enthaltene VIBs	VMware_bootbank_loadesx_7.0.3-0.60.20841705 VMware_bootbank_esx-update_7.0.3-0.60.20841705
Behobene Probleme	Nicht verfügbar
CVE-Nummern	Nicht verfügbar

Aktualisiert die VIBs loadesx und esx-update.

VMware-VM-Tools_12.1.0.20219665-20841705

Patch-Kategorie	Sicherheit
Patch-Schweregrad	Kritisch
Hostneustart erforderlich	Nein
Migration oder Herunterfahren der virtuellen Maschine erforderlich	Nein
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Enthaltene VIBs	VMware_locker_tools-light_12.1.0.20219665-20841705
Behobene Probleme	3015499
CVE-Nummern	Nicht verfügbar

Aktualisiert das VIB tools-light.

• Die folgenden ISO-Images von VMware Tools werden mit ESXi 7.0 Update 3i gebündelt:
  • windows.iso: VMware Tools 12.1.0 unterstützt Windows 7 SP1 oder Windows Server 2008 R2 SP1 oder höher.
  • linux.iso: VMware Tools 10.3.25-ISO-Image für das Linux-Betriebssystem mit glibc 2.11 oder höher.

  Die folgenden VMware Tools-ISO-Images stehen zum Download zur Verfügung:

  • VMware Tools 11.0.6:
    • windows.iso: für Windows Vista (SP2) und Windows Server 2008 Service Pack 2 (SP2).
       
  • VMware Tools 10.0.12:
    • winPreVista.iso: für Windows 2000, Windows XP und Windows 2003.
    • linuxPreGLibc25.iso: unterstützt Linux-Gastbetriebssysteme vor Red Hat Enterprise Linux (RHEL) 5, SUSE Linux Enterprise Server (SLES) 11, Ubuntu 7.04 und andere Distributionen mit einer glibc-Version vor 2.5.
       
  • solaris.iso: VMware Tools-Image 10.3.10 für Solaris.
  • darwin.iso: Unterstützt Mac OS X-Versionen 10.11 und höher.

  Befolgen Sie die in den folgenden Dokumenten aufgeführten Vorgehensweisen, um VMware Tools für Plattformen, die nicht mit ESXi gebündelt sind, herunterzuladen:

  • Versionshinweise zu VMware Tools 12.1.0
  • Frühere Versionen von VMware Tools
  • Wichtige Informationen zu VMware Tools für Administratoren
  • VMware Tools für Hosts, die mit Auto Deploy bereitgestellt wurden
  • Aktualisieren von VMware Tools

ESXi-7.0U3i-20842708-standard

Profilname	ESXi-7.0U3i-20842708-standard
Build	Build-Informationen finden Sie unter In dieser Version enthaltene Patches.
Anbieter	VMware, Inc.
Datum der Veröffentlichung	8. Dezember 2022
Akzeptanzebene	PartnerSupported
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Betroffene VIBs	VMware_bootbank_esx-xserver_7.0.3-0.65.20842708 VMware_bootbank_gc_7.0.3-0.65.20842708 VMware_bootbank_vsan_7.0.3-0.65.20842708 VMware_bootbank_cpu-microcode_7.0.3-0.65.20842708 VMware_bootbank_crx_7.0.3-0.65.20842708 VMware_bootbank_esx-base_7.0.3-0.65.20842708 VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.3-0.65.20842708 VMware_bootbank_vsanhealth_7.0.3-0.65.20842708 VMware_bootbank_native-misc-drivers_7.0.3-0.65.20842708 VMware_bootbank_esx-ui_2.1.1-20188605 VMware_bootbank_trx_7.0.3-0.65.20842708 VMware_bootbank_bmcal_7.0.3-0.65.20842708 VMware_bootbank_vdfs_7.0.3-0.65.20842708 VMware_bootbank_esxio-combiner_7.0.3-0.65.20842708 VMware_bootbank_esx-update_7.0.3-0.65.20842708 VMware_bootbank_loadesx_7.0.3-0.65.20842708 VMW_bootbank_ntg3_4.1.8.0-4vmw.703.0.65.20842708 VMware_locker_tools-light_12.1.0.20219665-20841705
Behobene Probleme	3021935, 2994966, 2983919, 3014323, 2996511, 2982013, 3011324, 3048788, 2983043, 3035934, 3015498, 3031708, 3041100, 3044475, 2990414, 3003866, 3011850, 3002779, 3033161, 3016132, 3015493, 3029194, 3007116, 2977496, 3021384, 2988179, 3025470, 3033159, 3011169, 3018832, 2977486, 2932056, 3013368, 2995471, 3006356, 2981272, 3000195, 3026623, 2981420, 3025469, 3042776, 2916160, 2996208, 3014374, 2977957, 2979281, 2976953, 2999968, 3031566, 3036859, 3029490, 3007883, 2992407
Verwandte CVE-Nummern	Nicht verfügbar

• Dieser Patch enthält Updates zur Behebung der folgenden Probleme:

  • In seltenen Fällen kann es bei VM-Ereignissen zu einer inkorrekten Meldung der Eigenschaft template kommen. Diese Eigenschaft gibt an, ob eine virtuelle Maschine als Vorlage markiert ist. Infolgedessen besteht die Möglichkeit, dass die Eigenschaft template als true angezeigt wird, obwohl die VM keine Vorlage ist, oder aber als false, obwohl eine VM als Vorlage markiert ist.

  • Aufgrund einer fehlenden Speichermoduleinheit für Cisco-Server im Managed Object Browser werden bei Verwendung von MOB unter Umständen keine Speicherstatusinformationen zu einem ESXi-Host angezeigt.

  • In sehr seltenen Fällen können zufällige Probleme mit Active Directory-Umgebungen, die einen Zustand bedingen können, in dem der Domänencontroller nicht mehr reagiert, auch dazu führen, dass der hostd-Dienst nicht mehr reagiert.

  • In seltenen Fällen kann es vorkommen, dass der interne Zustand des VMX-Prozesses aufgrund des schnellen Suspend-Resume-Mechanismus beim Erstellen oder Zurücksetzen einer VM basierend auf einem Snapshot ohne Benachrichtigung an die oberen Schichten des virtuellen Infrastrukturmanagement-Stacks neu initialisiert wird. Dies hat zur Folge, dass alle gastbezogenen Leistungsindikatoren in VMware Tools nicht mehr aktualisiert werden. In allen Schnittstellen zum ESXi-Host werden dauerhaft die zuletzt aufgezeichneten Werte angezeigt.

  • Wenn der rhttpproxy-Dienst mehrere Vorgänge für eingehende URIs durchführt, kann er den Puffer-Offset der einzelnen Verbindungen falsch berechnen. Dies führt möglicherweise zu Fehlern wie Pufferüberläufen und negativen Lesevorgängen. Dies führt dazu, dass der Dienst fehlschlägt.

  • Standardmäßig funktioniert das Ändern von Hypercall-Optionen mithilfe von Befehlen wie vm | Get-AdvancedSetting -Name isolation.tools.autoInstall.disable nur bei ausgeschalteter VM. Bei eingeschalteten VMs lösen solche Aufrufe den folgenden Fehler aus: Der versuchte Vorgang kann im aktuellen Zustand (Eingeschaltet) nicht durchgeführt werden. Dies wird erwartet.

  • Nachdem Sie einen ESXi 7.0 Update 3c-Host auf eine höhere Version von 7.0.x aktualisiert oder ein ESXi 7.0 Update 3c-VIB installiert oder entfernt und den Host neu gestartet haben, werden möglicherweise alle erweiterten Sicherheitsoptionen auf dem Host auf ihre Standardwerte zurückgesetzt. Folgende erweiterte Einstellungen sind betroffen:
    Security.AccountLockFailures
    Security.AccountUnlockTime
    Security.PasswordQualityControl
    Security.PasswordHistory
    Security.PasswordMaxDays
    Security.SshSessionLimit
    Security.DefaultShellAccess

  • Der Befehl esxcli hardware pci list, der den NUMA-Knoten für ESXi Hostgeräte meldet, gibt für die physischen Funktionen (PF) eines SR-IOV-Geräts den korrekten NUMA-Knoten zurück, für seine virtuellen Funktionen (VF) hingegen null.

  • Wenn Sie virtuelle Windows-Maschinen nach einem Upgrade auf ESXi 7.0 Update 2 oder höher mithilfe von vSphere vMotion zu den aktualisierten Hosts migrieren, schlagen einige VMs nach der Migration möglicherweise mit einem blauen Diagnosebildschirm fehl. Auf dem Bildschirm wird die Fehlermeldung Betriebssystem konnte nicht gestartet werden, kein Betriebssystem gefunden angezeigt. Dieses Problem tritt aufgrund eines Fehlers in der Adressoptimierungslogik des Virtual Machine File System (VMFS) auf.

  • Wenn die Clientanwendung über keinen registrierten Standardanforderungshandler verfügt, können Anforderungen mit einem Pfad, der in der Handlerzuordnung nicht vorhanden ist, dazu führen, dass die Ausführung von vmacore.dll fehlschlägt. Dies führt dazu, dass der ESXi-Host vom vCenter Server-System getrennt ist.

  • Einige Zuteilungsreservierungsvorgänge überschreiten möglicherweise den Grenzwert von 128 parallelen Reservierungsschlüsseln sowie den zugeteilten Arbeitsspeicherbereich eines ESXi-Hosts. Dies führt möglicherweise dazu, dass ESXi-Hosts während Reservierungsvorgängen für die Ressourcenzuteilung mit einem violetten Diagnosebildschirm fehlschlagen. Die Fehleranzeige enthält sinngemäße Meldungen wie z. B. PSOD BlueScreen: #PF-Ausnahme 14 in World 2097700:SCSI Periode IP.

  • Wenn Sie einen Befehl zum Aufheben der Beanspruchung auf einem Gerät oder Pfad ausführen, während virtuelle Maschinen auf dem Gerät noch aktive E/A-Vorgänge aufweisen, schlägt der ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm fehl. Auf dem Bildschirm wird sinngemäß folgende Meldung angezeigt: PSOD bei bora/modules/vmkernel/nmp/nmp_misc.c:3839 beim Laden/Löschen von lpfc.

  • Wenn TXT auf einem ESX-Host aktiviert ist, schlagen Versuche, eine VM einzuschalten, möglicherweise mit einem Fehler fehl. Im vSphere Client wird folgende Meldung angezeigt: Dieser Host unterstützt Intel VT-x, aber Intel VT-x ist eingeschränkt. Intel VT-x ist möglicherweise eingeschränkt, weil „trusted excecution“ in den BIOS/Firmware-Einstellungen aktiviert wurde oder der Host nach dem Ändern dieser Einstellung nicht aus- und wieder eingeschaltet wurde.

  • Aufgrund eines seltenen Problems bei der Verarbeitung von AVX2-Anweisungen schlägt eine virtuelle Maschine der Version ESX 7.0 Update 3f möglicherweise mit einem von ESX nicht behebbaren Fehler fehl. In der Datei vmware.log wird sinngemäß folgende Meldung angezeigt: MONITOR PANIC: vcpu-0:VMM Fehler 6: src=MONITOR ....
    Das Problem ist spezifisch für virtuelle Maschinen mit Hardwareversionen 12 oder früher.

  • Wenn Sie ein mithilfe von Image Builder erstelltes ESXi .iso-Image verwenden, um eine vSphere Lifecycle Manager-Upgrade-Baseline für ESXi Hosts zu erstellen, schlagen Upgrades mithilfe solcher Baselines möglicherweise fehl. Im vSphere Client wird folgender Fehler angezeigt: Upgrade-Skript kann nicht auf Host ausgeführt werden. Auf dem betroffenen ESXi-Host wird in der Datei /var/log/vua*.log sinngemäß folgender Fehler angezeigt: ValueError: Wenn ein Add-On vorhanden ist, sollte ein Basisimage vorhanden sein.
    Der Fehler tritt auf, wenn das vorhandene Image des ESXi-Hosts über ein Add-On verfügt, das von Image Builder generierte ISO-Image hingegen kein Add-On bereitstellt.

  • Viele parallele Anforderungen für Arbeitsspeicherbereiche durch virtuelle Maschinen, die das Data Plane Development Kit (DPDK) auf einem ESXi-Host verwenden, überschreiten möglicherweise den XMAP-Arbeitsspeicher auf dem Host. Folglich schlägt der Host mit einem violetten Diagnosebildschirm und sinngemäß folgender Fehlermeldung fehl: Panic Message: @BlueScreen: VERIFY bora/vmkernel/hardware/pci/config.c:157.

  • Nach einem Upgrade von ESXi-Hosts auf ESXi 7.0 Update 3 und höher werden möglicherweise einige Leistungsberichte für virtuelle Maschinen mit NVMe-Controllern nicht mehr angezeigt. Beispielsweise wird das Diagramm „Virtuelle Festplatte – Zusammenfassung aller Instanzen“ nicht in VMware Aria Operations angezeigt.

  • In seltenen Fällen, wie z. B. bei einem geplanten Neustart der primären virtuellen Maschine mit FT-Verschlüsselung, die hohe Arbeitslasten ausführt, verfügt die sekundäre virtuelle Maschine möglicherweise nicht über ausreichend Puffer, um mehr als 512 MB an modifizierten Seiten in einem einzelnen FT-Prüfpunkt zu entschlüsseln, und es tritt ein Pufferüberlauffehler auf. Dies führt dazu, dass der ESXi-Host, auf dem sich die sekundäre virtuelle Maschine befindet, möglicherweise mit einem violetten Diagnosebildschirm fehlschlägt.

  • In seltenen Fällen kann die vSAN-Speicherkonfiguration nach einem Upgrade bzw. Update auf ESXi 7.0 Update 2 und höher das Tag mark_ssd verlieren und standardmäßig HDD verwenden.

  • Selbst wenn sich ein Gerät oder eine LUN im Zustand „Getrennt“ befindet, versucht die Pluggable Storage Architecture (PSA) möglicherweise weiterhin, das Objekt zu registrieren. Die PSA erstellt bei jedem Pfadauswertungsintervall dieser Versuche ein Protokoll für jeden Pfadauswertungsschritt. Infolgedessen werden möglicherweise mehrere identische Meldungen angezeigt, wie z. B. nmp_RegisterDeviceEvents fehlgeschlagen für die Geräteregistrierung, die bei getrenntem Gerät bzw. getrennter LUN nicht erforderlich sind.

  • Wenn Sie eine Gerätekonfiguration zur Laufzeit ändern, werden Änderungen möglicherweise nicht im ESXi ConfigStore widergespiegelt, der die Konfigurationen für einen ESXi-Host enthält. Dies führt dazu, dass der Datenspeicher nach dem Neustart des ESXi-Hosts möglicherweise nicht gemountet wird.

  • Ab ESXi 6.0 ist mClock der standardmäßige E/A-Scheduler für ESXi, aber einige Umgebungen verwenden möglicherweise weiterhin Legacy-Scheduler von ESXi-Versionen vor 6.0. Infolgedessen schlagen Upgrades dieser Hosts auf ESXi 7.0 Update 3 und höher möglicherweise mit einem violetten Diagnosebildschirm fehl.

  • Ab ESXi 7.0 Update 1 wurde die Konfigurationsverwaltung von ESXi-Hosts aus der Datei /etc/vmware/esx.conf in das ConfigStore-Framework verschoben. Dadurch erfolgt eine explizite Trennung von Status und Konfiguration. Token in der esx.conf-Datei, wie z. B. implicit_support oder explicit_support, die einen Status angeben, werden nicht als gültige Token erkannt und vom satp_alua-Modul ignoriert. Wenn Sie ESXi-Hosts mithilfe eines Hostprofils mit Token, die den ALUA-Status angeben, auf ESXi 7.0 Update 3d oder höher aktualisieren, könnte der Vorgang daher mit einem violetten Diagnosebildschirm fehlschlagen. Auf dem Bildschirm wird sinngemäß folgende Fehlermeldung angezeigt: Modulfehler: /var/lib/vmware/configmanager/upgrade/lib/postLoadStore/libupgradepsadeviceconfig.so.

  • Ein Hilfsmechanismus, der FB-Ressourcenzuteilungsdetails im Hintergrund zwischenspeichert, kann die FB-Ressourcenzuteilung an den ESXi-Host während E/A-Vorgängen versehentlich anhalten und blockieren. In einigen Fällen wirkt sich dieses Problem möglicherweise auf andere Prozesse aus, die für dieselbe Datei ausgeführt werden, und blockiert sie. Dies kann dazu führen, dass der ESXi-Host nicht mehr reagiert.

  • Der vSAN-Dateidienst erfordert, dass Hosts miteinander kommunizieren. Der Dateidienst verwendet möglicherweise fälschlicherweise eine IP-Adresse im Zeugennetzwerk für die Interkommunikation. Wenn Sie ein isoliertes Zeugennetzwerk für vSAN konfiguriert haben, kann der Host über das Zeugennetzwerk mit einem Zeugenknoten kommunizieren, aber Hosts können über das Zeugennetzwerk nicht miteinander kommunizieren. Die Kommunikation zwischen Hosts für den vSAN-Dateidienst kann nicht hergestellt werden.

  • Wenn sich ein ESXi-Host im Zustand „Geringer Arbeitsspeicher“ befindet, könnte eine unzureichende Heap-Zuteilung zu einem Netzwerkmodul dazu führen, dass die Port-Bitmap auf NULL festgelegt wird. Folglich kann ein ESXi-Host bei einem Paketweiterleitungsversuch mit einem violetten Diagnosebildschirm fehlschlagen.

  • Während der Änderung des Objektformats werden einige Objekte mit altem Layout möglicherweise teilweise bereinigt, sodass die Konfiguration in einem ungültigen Zustand bleibt. Dieses Problem kann dazu führen, dass CLOMD immer dann fehlschlägt, wenn versucht wird, das Objekt während der Neukonfiguration zu verarbeiten.
    
    Möglicherweise werden die folgenden Einträge in der clomd.log-Datei angezeigt:
    
    2022-10-14T16:17:26.456Z PANIC: NOT_REACHED bora/lib/vsan/vsan_config_builder.c:744
2022-10-14T16:17:26.456Z Backtrace:
2022-10-14T16:17:26.456Z Backtrace[0] 0000030b4742c6a0 rip=000000bf0c7de98f rbx=0000030b4742c6a0
rbp=0000030b4742cad0 r12=000000bf0d677788 r13=0000030b4742cae8 r14=000000bf14ce052c r15=000000bf14ce3c2c

  • Windows 2012 und höher verwendet die SCSI-3-Reservierung für die Ressourcenvermittlung, um Windows Failover Clustering (WSFC) auf ESXi für systemübergreifende Cluster-Konfigurationen (Cluster-across-box, CAB) zu unterstützen. Wenn Sie jedoch die Einstellung Physical für die gemeinsame Bus-Nutzung des SCSI-Controllers auf dieser VM konfigurieren, führt der Befehl SCSI RESERVE dazu, dass der ESXi-Host mit einem violetten Diagnosebildschirm fehlschlägt. SCSI RESERVE ist eine SCSI-2-Semantik und wird für WSFC-Cluster auf ESXi nicht unterstützt.

  • vSAN könnte das Destaging von Daten aufgrund eines Problems beim Zählen ausstehender E/As beenden. Wenn eine vSAN-Festplattengruppe das Destaging von Daten aus dem Cache in die Kapazitätsschicht beendet, kann dies dazu führen, dass sich Daten in der Cache-Ebene ansammeln. Dieses Problem führt zu Überlastung, E/A-Drosselung und längerer Latenz.

  • Wenn ein vSAN-Cluster mit einem 0-Byte-Objekt eine Richtlinienänderungsanforderung empfängt, legt der Cluster Level Object Manager (CLOM) möglicherweise fälschlicherweise ein ungültiges Flag für eine oder mehrere Komponenten des Objekts fest. Ein solches Flag kann dazu führen, dass der Host große Schreibvorgänge sendet, die das System überlasten, sodass der Host mit einem violetten Diagnosebildschirm fehlschlägt.

  • Ein seltenes Problem bei der Verarbeitung von VMFS-Journalblöcken kann zu Sperrungskonflikten führen, wodurch Verzögerungen bei erneuten VMFS-Prüfungen entstehen oder das Mounten von Datenspeichern fehlschlägt. In den VMkernel-Protokollen werden Fehler angezeigt, wie z. B. Ressourcendatei für Ressource: 6 hat den maximalen Grenzwert von 8192 erreicht und Ressourcen-Dateierweiterung (‚Kein Speicherplatz frei auf Gerät‘).

  • In seltenen Fällen kann der vmx-Dienst während des Abbrechens einer vSphere Storage vMotion-Aufgabe fehlschlagen. Wenn Ihre Umgebung vCenter Server High Availability verwendet, startet der Dienst die betroffenen virtuellen Maschinen daher neu.

  • Wenn Sie zum Starten von ESXi 7.x nur SD- oder USB-Geräte verwenden, werden möglicherweise Fehler angezeigt, wie z. B. Unterstützung der Konfiguration nur für SD-Karte/USB wird eingestellt. Diese Meldung weist nicht auf einen Fehler hin, sondern enthält nur eine Warnung, dass SD- und USB-Geräte nur für Bootbank-Partitionen unterstützt werden, und dass für eine optimale Leistung ein sekundärer persistenter Speicher mit mindestens 32 GB für /scratch und VMware Tools bereitgestellt werden muss, die sich in der OSData-Partition befinden.

  • Dieses Problem betrifft vSAN-Hosts, die einen externen KMS für die Verschlüsselung ruhender Daten verwenden. Wenn Sie ein Upgrade eines vSAN-Hosts von 6.7 oder früher auf 7.0 und höher durchführen, geht das KMS-Kennwort verloren. Die Festplatten des Hosts bleiben verschlüsselt und gesperrt.

  • In seltenen Fällen versuchen vSphere Virtual Volumes möglicherweise eine erneute Bindung von Volumes auf ESXi-Hosts mit persistenten SCSI-Reservierungen. Dies führt dazu, dass die ESXi-Hosts mit einem violetten Diagnosebildschirm fehlschlagen und im Backtrace sinngemäß folgende Fehlermeldung angezeigt wird: Panik-Meldung: @BlueScreen: PANIC bora/vmkernel/main/dlmalloc.c:4933 – Nutzungsfehler in dlmalloc.

  • Aufgrund eines Caching-Problems wird im vSphere Client möglicherweise eine VMDK-Größe von 0 KB angezeigt, unabhängig von der tatsächlichen Größe der virtuellen Maschinen in einer vSphere Virtual Volumes-Umgebung.

  • Während der Speichermigration eines Site-übergreifenden Advanced Cross vCenter vMotion-Vorgangs werden möglicherweise einige asynchrone E/A-Vorgänge im Speicher-Stack gesperrt und es tritt keine ordnungsgemäße Zeitüberschreitung auf. Dies führt dazu, dass virtuelle Maschinen weiterhin auf eine E/A-Antwort warten. Dadurch tritt beim Advanced Cross vCenter vMotion-Vorgang eine Zeitüberschreitung auf, und die virtuellen Maschinen reagieren nicht mehr.

  • Ein Problem während der LLOG-Wiederherstellung kann dazu führen, dass eine vSAN-Komponente fälschlicherweise als ungültig markiert wird. Dieses Problem kann zu einer Ansammlung von Protokollen und somit zu Überlastung führen.

  • Aufgrund einer unzureichenden Ressourcenpoolzuteilung schlagen einige an den SFCBD berichtende Dienste, wie z. B. sfcb-vmware_base und sfcb-vmw, möglicherweise fehl und generieren zdump. In der syslog.log-Datei werden Fehlermeldungen wie die folgenden angezeigt:
    sfcb-vmware_base[2110110]: tool_mm_realloc_or_die: memory re-allocation failed(orig=364000 new=364800 msg=Cannot allocate memory, aborting
sfcb-vmw_ipmi[2291550]: tool_mm_realloc_or_die: memory re-allocation failed(orig=909200 new=909600 msg=Cannot allocate memory, aborting

  • Wenn es sich bei der Zielrichtlinie um RAID 1, StripeWidth 1 handelt und ein vSAN-Cluster nur noch wenige vorübergehende Kapazitäten aufweist, konfiguriert der Cluster Level Object Manager möglicherweise weiterhin denselben Teil von Objekten neu, der größer als 8 TB ist. Infolgedessen verbleiben diese Objekte im nicht übereinstimmenden Zustand, und möglicherweise werden einige unnötige Neusynchronisierungsvorgänge angezeigt.

  • In VMware Aria Operations for Logs (vormals vRealize Log Insight) wird möglicherweise eine große Anzahl von Protokollen angezeigt, die von Storage I/O Control generiert werden, z. B. Ungültiger Wert für Freigaben: 0. Standard wird verwendet. und Gerät naa.xxxx wird entweder aufgrund eines VSI-Lesefehlers oder eines abnormalen Status übersprungen. Das Protokollvolumen variiert je nach der Anzahl der ESXi-Hosts in einem Cluster und der Anzahl der Geräte im ausgeschalteten Zustand. Wenn das Problem auftritt, wird das Protokollvolume schnell (innerhalb von 24 Stunden) generiert, und VMware Aria Operations for Logs stuft die Meldungen möglicherweise als kritisch ein. Diese Protokolle sind jedoch unbedenklich und wirken sich nicht auf die Vorgänge auf anderen Online-Datenspeichern aus.

  • Wenn die Liste der Speichersensoren eines ESXi-Hosts leer ist, wird der von der Intelligent Platform Management Interface (IPMI) gemeldete CPU-Status möglicherweise zurückgesetzt. Dies führt dazu, dass der Sensordatensatz mit Element ID 3, dem Status des Prozessors, fälschlicherweise als Über aktuellen Status des physischen Elements kann nicht berichtet werden im MOB angezeigt wird.

  • In Stretched Clustern stellt vSAN jedes VMDK-Objekt mit einem bestimmten Format bereit. Wenn Sie die Richtlinie eines VMDK-Objekts von hostFailuresToTolerate=0 in hostFailuresToTolerate=1 ändern, ändert sich das Format möglicherweise so, dass Lesevorgänge den Site-übergreifenden (AZ-übergreifenden) Link durchlaufen. Dies führt dazu, dass in diesen Objekten eine höhere Leselatenz angezeigt wird.

  • Wenn Sie im vSphere Client eine virtuelle Maschine erstellen oder neu konfigurieren, werden dieselben Optionen im Dropdown-Menü unter SCSI-Controller > Gemeinsame Verwendung des SCSI-Busses möglicherweise doppelt angezeigt. Auf Workflows zum Erstellen oder Konfigurieren der VM hat das Problem keine Auswirkungen.

  • Nach einem Migrationsvorgang fallen virtuelle Maschinen mit Windows 10 unter Umständen aus, wobei ein blauer Diagnosebildschirm angezeigt wird und in einer Fehlermeldung wie der folgenden eine falsche Microcoderevision gemeldet wird: – MICROCODE_REVISION_MISMATCH (17e). Das Problem tritt auf, wenn während des Migrationsvorgangs ein Scan der CPUs durchgeführt wird und die Firmware der Quell-CPUs nicht mit der Firmware der Ziel-CPUs übereinstimmt.

  • In bestimmten Fällen schlägt das Löschen des Caches von Objekten in einem Datenspeichervolume auf ESXi-Hosts fehl, Objekte verbleiben im Cache und führen dazu, dass nicht genügend Arbeitsspeicher vorhanden ist. Dies kommt beispielsweise vor, wenn die Verbindung mit dem zugrunde liegenden Gerät des Volumes unterbrochen wird. Folglich reagiert der ESXi-Host nicht mehr. In den Protokollen werden Fehler angezeigt, wie z. B.:
    Erneute Verbindung mit xxxxx nicht möglich] oder Fehler beim Bereinigen von VMFS-Taktsignal auf Volume xxxxx: Keine Verbindung. oder
    Das Volume auf dem Gerät xxxxx ist gesperrt, möglicherweise weil während eines Volume-Vorgangs ein nicht behebbarer Fehler auf einem Remotehost aufgetreten ist.

  • Bestimmte Workflows wie Sicherungsvorgänge von ESXi-Hosts können eine große Anzahl von Dateien öffnen, was wiederum zu einer Auslastung des Objekt-Caches führen kann. In solchen Fällen kann es vorkommen, dass der hostd-Dienst fehlschlägt, virtuelle Maschinen heruntergefahren werden oder die VM in einen ungültigen Zustand versetzt wird, der ihr Einschalten verhindert. In den Protokollen werden Warnungen angezeigt, wie z. B. Es konnte kein Arbeitsspeicher zugeteilt werden.

  • In Überwachen > Skyline Health > Dateidienst > Integrität des Dateiservers wird möglicherweise die Fehlermeldung Dateiserver wird (neu) gestartet angezeigt.
    Das Problem wird durch eine Cache-Überlauffunktion verursacht, die zu einem Ausfall des VDFS-Daemons führt. In der Datei /var/run/log/vdfsd-server.log in einem betroffenen ESXi-Host werden Meldungen wie NOT_IMPLEMENTED bora/vdfs/core/VDFSPhysicalLog.cpp angezeigt.

  • Wenn Sie im vSphere Client die Richtlinie einer eingeschalteten VM mit einem IDE-Controller ändern, wird möglicherweise folgender Fehler angezeigt: Der versuchte Vorgang kann im aktuellen Zustand (Eingeschaltet) nicht durchgeführt werden.

  • Das Mounten des HCI Mesh-Clusters schlägt möglicherweise fehl, wenn Sie vSAN erneut aktivieren, nachdem Sie vSAN mit Verschlüsselung in Übertragung begriffener Daten deaktiviert haben.

  • Wenn für vSAN verwendete NVMe-Laufwerke über eine doppelte PCI-ID verfügen und Sie den vSAN-Integritätsdienst auf vCenter Server neu starten, fehlt die Hardwarekompatibilitätsgruppe aus vSAN Skyline Health.

  • Wenn zwei NICs, die den Treiber ntg3 der Version 4.1.3 und höher verwenden, direkt und nicht mit einem physischen Switch-Port verbunden sind, kann Link Flapping auftreten. Das Problem tritt nicht bei ntg3-Treibern mit Versionen vor 4.1.3 oder dem tg3-Treiber auf. Dieses Problem steht nicht im Zusammenhang mit dem gelegentlich auftretenden Energy Efficient Ethernet (EEE) Link Flapping bei solchen NICs. Die Lösung für das EEE-Problem besteht darin, einen ntg3-Treiber der Version 4.1.7 oder höher zu verwenden oder EEE an physischen Switch-Ports zu deaktivieren.

  • Der TPM 2.0-Nachweis auf Lenovo-Servern gibt den TPM-Fehlercode zurück: TSS2_SYS_RC_INSUFFICIENT_BUFFER.

ESXi-7.0U3i-20842708-no-tools

Profilname	ESXi-7.0U3i-20842708-no-tools
Build	Build-Informationen finden Sie unter In dieser Version enthaltene Patches.
Anbieter	VMware, Inc.
Datum der Veröffentlichung	8. Dezember 2022
Akzeptanzebene	PartnerSupported
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Betroffene VIBs	VMware_bootbank_esx-xserver_7.0.3-0.65.20842708 VMware_bootbank_gc_7.0.3-0.65.20842708 VMware_bootbank_vsan_7.0.3-0.65.20842708 VMware_bootbank_cpu-microcode_7.0.3-0.65.20842708 VMware_bootbank_crx_7.0.3-0.65.20842708 VMware_bootbank_esx-base_7.0.3-0.65.20842708 VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.3-0.65.20842708 VMware_bootbank_vsanhealth_7.0.3-0.65.20842708 VMware_bootbank_native-misc-drivers_7.0.3-0.65.20842708 VMware_bootbank_esx-ui_2.1.1-20188605 VMware_bootbank_trx_7.0.3-0.65.20842708 VMware_bootbank_bmcal_7.0.3-0.65.20842708 VMware_bootbank_vdfs_7.0.3-0.65.20842708 VMware_bootbank_esxio-combiner_7.0.3-0.65.20842708 VMware_bootbank_esx-update_7.0.3-0.65.20842708 VMware_bootbank_loadesx_7.0.3-0.65.20842708 VMW_bootbank_ntg3_4.1.8.0-4vmw.703.0.65.20842708
Behobene Probleme	3021935, 2994966, 2983919, 3014323, 2996511, 2982013, 3011324, 3048788, 2983043, 3035934, 3015498, 3031708, 3041100, 3044475, 2990414, 3003866, 3011850, 3002779, 3033161, 3016132, 3015493, 3029194, 3007116, 2977496, 3021384, 2988179, 3025470, 3033159, 3011169, 3018832, 2977486, 2932056, 3013368, 2995471, 3006356, 2981272, 3000195, 3026623, 2981420, 3025469, 3042776, 2916160, 2996208, 3014374, 2977957, 2979281, 2976953, 2999968, 3031566, 3036859, 3029490, 3007883, 2992407
Verwandte CVE-Nummern	Nicht verfügbar

• Dieser Patch enthält Updates zur Behebung der folgenden Probleme:

  • In seltenen Fällen kann es bei VM-Ereignissen zu einer inkorrekten Meldung der Eigenschaft template kommen. Diese Eigenschaft gibt an, ob eine virtuelle Maschine als Vorlage markiert ist. Infolgedessen besteht die Möglichkeit, dass die Eigenschaft template als true angezeigt wird, obwohl die VM keine Vorlage ist, oder aber als false, obwohl eine VM als Vorlage markiert ist.

  • Aufgrund einer fehlenden Speichermoduleinheit für Cisco-Server im Managed Object Browser werden bei Verwendung von MOB unter Umständen keine Speicherstatusinformationen zu einem ESXi-Host angezeigt.

  • In sehr seltenen Fällen können zufällige Probleme mit Active Directory-Umgebungen, die einen Zustand bedingen können, in dem der Domänencontroller nicht mehr reagiert, auch dazu führen, dass der hostd-Dienst nicht mehr reagiert.

  • In seltenen Fällen kann es vorkommen, dass der interne Zustand des VMX-Prozesses aufgrund des schnellen Suspend-Resume-Mechanismus beim Erstellen oder Zurücksetzen einer VM basierend auf einem Snapshot ohne Benachrichtigung an die oberen Schichten des virtuellen Infrastrukturmanagement-Stacks neu initialisiert wird. Dies hat zur Folge, dass alle gastbezogenen Leistungsindikatoren in VMware Tools nicht mehr aktualisiert werden. In allen Schnittstellen zum ESXi-Host werden dauerhaft die zuletzt aufgezeichneten Werte angezeigt.

  • Wenn der rhttpproxy-Dienst mehrere Vorgänge für eingehende URIs durchführt, kann er den Puffer-Offset der einzelnen Verbindungen falsch berechnen. Dies führt möglicherweise zu Fehlern wie Pufferüberläufen und negativen Lesevorgängen. Dies führt dazu, dass der Dienst fehlschlägt.

  • Standardmäßig funktioniert das Ändern von Hypercall-Optionen mithilfe von Befehlen wie vm | Get-AdvancedSetting -Name isolation.tools.autoInstall.disable nur bei ausgeschalteter VM. Bei eingeschalteten VMs lösen solche Aufrufe den folgenden Fehler aus: Der versuchte Vorgang kann im aktuellen Zustand (Eingeschaltet) nicht durchgeführt werden. Dies wird erwartet.

  • Nachdem Sie einen ESXi 7.0 Update 3c-Host auf eine höhere Version von 7.0.x aktualisiert oder ein ESXi 7.0 Update 3c-VIB installiert oder entfernt und den Host neu gestartet haben, werden möglicherweise alle erweiterten Sicherheitsoptionen auf dem Host auf ihre Standardwerte zurückgesetzt. Folgende erweiterte Einstellungen sind betroffen:
    Security.AccountLockFailures
    Security.AccountUnlockTime
    Security.PasswordQualityControl
    Security.PasswordHistory
    Security.PasswordMaxDays
    Security.SshSessionLimit
    Security.DefaultShellAccess

  • Der Befehl esxcli hardware pci list, der den NUMA-Knoten für ESXi Hostgeräte meldet, gibt für die physischen Funktionen (PF) eines SR-IOV-Geräts den korrekten NUMA-Knoten zurück, für seine virtuellen Funktionen (VF) hingegen null.

  • Wenn Sie virtuelle Windows-Maschinen nach einem Upgrade auf ESXi 7.0 Update 2 oder höher mithilfe von vSphere vMotion zu den aktualisierten Hosts migrieren, schlagen einige VMs nach der Migration möglicherweise mit einem blauen Diagnosebildschirm fehl. Auf dem Bildschirm wird die Fehlermeldung Betriebssystem konnte nicht gestartet werden, kein Betriebssystem gefunden angezeigt. Dieses Problem tritt aufgrund eines Fehlers in der Adressoptimierungslogik des Virtual Machine File System (VMFS) auf.

  • Wenn die Clientanwendung über keinen registrierten Standardanforderungshandler verfügt, können Anforderungen mit einem Pfad, der in der Handlerzuordnung nicht vorhanden ist, dazu führen, dass die Ausführung von vmacore.dll fehlschlägt. Dies führt dazu, dass der ESXi-Host vom vCenter Server-System getrennt ist.

  • Einige Zuteilungsreservierungsvorgänge überschreiten möglicherweise den Grenzwert von 128 parallelen Reservierungsschlüsseln sowie den zugeteilten Arbeitsspeicherbereich eines ESXi-Hosts. Dies führt möglicherweise dazu, dass ESXi-Hosts während Reservierungsvorgängen für die Ressourcenzuteilung mit einem violetten Diagnosebildschirm fehlschlagen. Die Fehleranzeige enthält sinngemäße Meldungen wie z. B. PSOD BlueScreen: #PF-Ausnahme 14 in World 2097700:SCSI Periode IP.

  • Wenn Sie einen Befehl zum Aufheben der Beanspruchung auf einem Gerät oder Pfad ausführen, während virtuelle Maschinen auf dem Gerät noch aktive E/A-Vorgänge aufweisen, schlägt der ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm fehl. Auf dem Bildschirm wird sinngemäß folgende Meldung angezeigt: PSOD bei bora/modules/vmkernel/nmp/nmp_misc.c:3839 beim Laden/Löschen von lpfc.

  • Wenn TXT auf einem ESX-Host aktiviert ist, schlagen Versuche, eine VM einzuschalten, möglicherweise mit einem Fehler fehl. Im vSphere Client wird folgende Meldung angezeigt: Dieser Host unterstützt Intel VT-x, aber Intel VT-x ist eingeschränkt. Intel VT-x ist möglicherweise eingeschränkt, weil „trusted excecution“ in den BIOS/Firmware-Einstellungen aktiviert wurde oder der Host nach dem Ändern dieser Einstellung nicht aus- und wieder eingeschaltet wurde.

  • Aufgrund eines seltenen Problems bei der Verarbeitung von AVX2-Anweisungen schlägt eine virtuelle Maschine der Version ESX 7.0 Update 3f möglicherweise mit einem von ESX nicht behebbaren Fehler fehl. In der Datei vmware.log wird sinngemäß folgende Meldung angezeigt: MONITOR PANIC: vcpu-0:VMM Fehler 6: src=MONITOR ....
    Das Problem ist spezifisch für virtuelle Maschinen mit Hardwareversionen 12 oder früher.

  • Wenn Sie ein mithilfe von Image Builder erstelltes ESXi .iso-Image verwenden, um eine vSphere Lifecycle Manager-Upgrade-Baseline für ESXi Hosts zu erstellen, schlagen Upgrades mithilfe solcher Baselines möglicherweise fehl. Im vSphere Client wird folgender Fehler angezeigt: Upgrade-Skript kann nicht auf Host ausgeführt werden. Auf dem betroffenen ESXi-Host wird in der Datei /var/log/vua*.log sinngemäß folgender Fehler angezeigt: ValueError: Wenn ein Add-On vorhanden ist, sollte ein Basisimage vorhanden sein.
    Der Fehler tritt auf, wenn das vorhandene Image des ESXi-Hosts über ein Add-On verfügt, das von Image Builder generierte ISO-Image hingegen kein Add-On bereitstellt.

  • Viele parallele Anforderungen für Arbeitsspeicherbereiche durch virtuelle Maschinen, die das Data Plane Development Kit (DPDK) auf einem ESXi-Host verwenden, überschreiten möglicherweise den XMAP-Arbeitsspeicher auf dem Host. Folglich schlägt der Host mit einem violetten Diagnosebildschirm und sinngemäß folgender Fehlermeldung fehl: Panic Message: @BlueScreen: VERIFY bora/vmkernel/hardware/pci/config.c:157.

  • Nach einem Upgrade von ESXi-Hosts auf ESXi 7.0 Update 3 und höher werden möglicherweise einige Leistungsberichte für virtuelle Maschinen mit NVMe-Controllern nicht mehr angezeigt. Beispielsweise wird das Diagramm „Virtuelle Festplatte – Zusammenfassung aller Instanzen“ nicht in VMware Aria Operations angezeigt.

  • In seltenen Fällen, wie z. B. bei einem geplanten Neustart der primären virtuellen Maschine mit FT-Verschlüsselung, die hohe Arbeitslasten ausführt, verfügt die sekundäre virtuelle Maschine möglicherweise nicht über ausreichend Puffer, um mehr als 512 MB an modifizierten Seiten in einem einzelnen FT-Prüfpunkt zu entschlüsseln, und es tritt ein Pufferüberlauffehler auf. Dies führt dazu, dass der ESXi-Host, auf dem sich die sekundäre virtuelle Maschine befindet, möglicherweise mit einem violetten Diagnosebildschirm fehlschlägt.

  • In seltenen Fällen kann die vSAN-Speicherkonfiguration nach einem Upgrade bzw. Update auf ESXi 7.0 Update 2 und höher das Tag mark_ssd verlieren und standardmäßig HDD verwenden.

  • Selbst wenn sich ein Gerät oder eine LUN im Zustand „Getrennt“ befindet, versucht die Pluggable Storage Architecture (PSA) möglicherweise weiterhin, das Objekt zu registrieren. Die PSA erstellt bei jedem Pfadauswertungsintervall dieser Versuche ein Protokoll für jeden Pfadauswertungsschritt. Infolgedessen werden möglicherweise mehrere identische Meldungen angezeigt, wie z. B. nmp_RegisterDeviceEvents fehlgeschlagen für die Geräteregistrierung, die bei getrenntem Gerät bzw. getrennter LUN nicht erforderlich sind.

  • Wenn Sie eine Gerätekonfiguration zur Laufzeit ändern, werden Änderungen möglicherweise nicht im ESXi ConfigStore widergespiegelt, der die Konfigurationen für einen ESXi-Host enthält. Dies führt dazu, dass der Datenspeicher nach dem Neustart des ESXi-Hosts möglicherweise nicht gemountet wird.

  • Ab ESXi 6.0 ist mClock der standardmäßige E/A-Scheduler für ESXi, aber einige Umgebungen verwenden möglicherweise weiterhin Legacy-Scheduler von ESXi-Versionen vor 6.0. Infolgedessen schlagen Upgrades dieser Hosts auf ESXi 7.0 Update 3 und höher möglicherweise mit einem violetten Diagnosebildschirm fehl.

  • Ab ESXi 7.0 Update 1 wurde die Konfigurationsverwaltung von ESXi-Hosts aus der Datei /etc/vmware/esx.conf in das ConfigStore-Framework verschoben. Dadurch erfolgt eine explizite Trennung von Status und Konfiguration. Token in der esx.conf-Datei, wie z. B. implicit_support oder explicit_support, die einen Status angeben, werden nicht als gültige Token erkannt und vom satp_alua-Modul ignoriert. Wenn Sie ESXi-Hosts mithilfe eines Hostprofils mit Token, die den ALUA-Status angeben, auf ESXi 7.0 Update 3d oder höher aktualisieren, könnte der Vorgang daher mit einem violetten Diagnosebildschirm fehlschlagen. Auf dem Bildschirm wird sinngemäß folgende Fehlermeldung angezeigt: Modulfehler: /var/lib/vmware/configmanager/upgrade/lib/postLoadStore/libupgradepsadeviceconfig.so.

  • Ein Hilfsmechanismus, der FB-Ressourcenzuteilungsdetails im Hintergrund zwischenspeichert, kann die FB-Ressourcenzuteilung an den ESXi-Host während E/A-Vorgängen versehentlich anhalten und blockieren. In einigen Fällen wirkt sich dieses Problem möglicherweise auf andere Prozesse aus, die für dieselbe Datei ausgeführt werden, und blockiert sie. Dies kann dazu führen, dass der ESXi-Host nicht mehr reagiert.

  • Der vSAN-Dateidienst erfordert, dass Hosts miteinander kommunizieren. Der Dateidienst verwendet möglicherweise fälschlicherweise eine IP-Adresse im Zeugennetzwerk für die Interkommunikation. Wenn Sie ein isoliertes Zeugennetzwerk für vSAN konfiguriert haben, kann der Host über das Zeugennetzwerk mit einem Zeugenknoten kommunizieren, aber Hosts können über das Zeugennetzwerk nicht miteinander kommunizieren. Die Kommunikation zwischen Hosts für den vSAN-Dateidienst kann nicht hergestellt werden.

  • Wenn sich ein ESXi-Host im Zustand „Geringer Arbeitsspeicher“ befindet, könnte eine unzureichende Heap-Zuteilung zu einem Netzwerkmodul dazu führen, dass die Port-Bitmap auf NULL festgelegt wird. Folglich kann ein ESXi-Host bei einem Paketweiterleitungsversuch mit einem violetten Diagnosebildschirm fehlschlagen.

  • Während der Änderung des Objektformats werden einige Objekte mit altem Layout möglicherweise teilweise bereinigt, sodass die Konfiguration in einem ungültigen Zustand bleibt. Dieses Problem kann dazu führen, dass CLOMD immer dann fehlschlägt, wenn versucht wird, das Objekt während der Neukonfiguration zu verarbeiten.
    
    Möglicherweise werden die folgenden Einträge in der clomd.log-Datei angezeigt:
    
    2022-10-14T16:17:26.456Z PANIC: NOT_REACHED bora/lib/vsan/vsan_config_builder.c:744
2022-10-14T16:17:26.456Z Backtrace:
2022-10-14T16:17:26.456Z Backtrace[0] 0000030b4742c6a0 rip=000000bf0c7de98f rbx=0000030b4742c6a0
rbp=0000030b4742cad0 r12=000000bf0d677788 r13=0000030b4742cae8 r14=000000bf14ce052c r15=000000bf14ce3c2c

  • Windows 2012 und höher verwendet die SCSI-3-Reservierung für die Ressourcenvermittlung, um Windows Failover Clustering (WSFC) auf ESXi für systemübergreifende Cluster-Konfigurationen (Cluster-across-box, CAB) zu unterstützen. Wenn Sie jedoch die Einstellung Physical für die gemeinsame Bus-Nutzung des SCSI-Controllers auf dieser VM konfigurieren, führt der Befehl SCSI RESERVE dazu, dass der ESXi-Host mit einem violetten Diagnosebildschirm fehlschlägt. SCSI RESERVE ist eine SCSI-2-Semantik und wird für WSFC-Cluster auf ESXi nicht unterstützt.

  • vSAN könnte das Destaging von Daten aufgrund eines Problems beim Zählen ausstehender E/As beenden. Wenn eine vSAN-Festplattengruppe das Destaging von Daten aus dem Cache in die Kapazitätsschicht beendet, kann dies dazu führen, dass sich Daten in der Cache-Ebene ansammeln. Dieses Problem führt zu Überlastung, E/A-Drosselung und längerer Latenz.

  • Wenn ein vSAN-Cluster mit einem 0-Byte-Objekt eine Richtlinienänderungsanforderung empfängt, legt der Cluster Level Object Manager (CLOM) möglicherweise fälschlicherweise ein ungültiges Flag für eine oder mehrere Komponenten des Objekts fest. Ein solches Flag kann dazu führen, dass der Host große Schreibvorgänge sendet, die das System überlasten, sodass der Host mit einem violetten Diagnosebildschirm fehlschlägt.

  • Ein seltenes Problem bei der Verarbeitung von VMFS-Journalblöcken kann zu Sperrungskonflikten führen, wodurch Verzögerungen bei erneuten VMFS-Prüfungen entstehen oder das Mounten von Datenspeichern fehlschlägt. In den VMkernel-Protokollen werden Fehler angezeigt, wie z. B. Ressourcendatei für Ressource: 6 hat den maximalen Grenzwert von 8192 erreicht und Ressourcen-Dateierweiterung (‚Kein Speicherplatz frei auf Gerät‘).

  • In seltenen Fällen kann der vmx-Dienst während des Abbrechens einer vSphere Storage vMotion-Aufgabe fehlschlagen. Wenn Ihre Umgebung vCenter Server High Availability verwendet, startet der Dienst die betroffenen virtuellen Maschinen daher neu.

  • Wenn Sie zum Starten von ESXi 7.x nur SD- oder USB-Geräte verwenden, werden möglicherweise Fehler angezeigt, wie z. B. Unterstützung der Konfiguration nur für SD-Karte/USB wird eingestellt. Diese Meldung weist nicht auf einen Fehler hin, sondern enthält nur eine Warnung, dass SD- und USB-Geräte nur für Bootbank-Partitionen unterstützt werden, und dass für eine optimale Leistung ein sekundärer persistenter Speicher mit mindestens 32 GB für /scratch und VMware Tools bereitgestellt werden muss, die sich in der OSData-Partition befinden.

  • Dieses Problem betrifft vSAN-Hosts, die einen externen KMS für die Verschlüsselung ruhender Daten verwenden. Wenn Sie ein Upgrade eines vSAN-Hosts von 6.7 oder früher auf 7.0 und höher durchführen, geht das KMS-Kennwort verloren. Die Festplatten des Hosts bleiben verschlüsselt und gesperrt.

  • In seltenen Fällen versuchen vSphere Virtual Volumes möglicherweise eine erneute Bindung von Volumes auf ESXi-Hosts mit persistenten SCSI-Reservierungen. Dies führt dazu, dass die ESXi-Hosts mit einem violetten Diagnosebildschirm fehlschlagen und im Backtrace sinngemäß folgende Fehlermeldung angezeigt wird: Panik-Meldung: @BlueScreen: PANIC bora/vmkernel/main/dlmalloc.c:4933 – Nutzungsfehler in dlmalloc.

  • Aufgrund eines Caching-Problems wird im vSphere Client möglicherweise eine VMDK-Größe von 0 KB angezeigt, unabhängig von der tatsächlichen Größe der virtuellen Maschinen in einer vSphere Virtual Volumes-Umgebung.

  • Während der Speichermigration eines Site-übergreifenden Advanced Cross vCenter vMotion-Vorgangs werden möglicherweise einige asynchrone E/A-Vorgänge im Speicher-Stack gesperrt und es tritt keine ordnungsgemäße Zeitüberschreitung auf. Dies führt dazu, dass virtuelle Maschinen weiterhin auf eine E/A-Antwort warten. Dadurch tritt beim Advanced Cross vCenter vMotion-Vorgang eine Zeitüberschreitung auf, und die virtuellen Maschinen reagieren nicht mehr.

  • Ein Problem während der LLOG-Wiederherstellung kann dazu führen, dass eine vSAN-Komponente fälschlicherweise als ungültig markiert wird. Dieses Problem kann zu einer Ansammlung von Protokollen und somit zu Überlastung führen.

  • Aufgrund einer unzureichenden Ressourcenpoolzuteilung schlagen einige an den SFCBD berichtende Dienste, wie z. B. sfcb-vmware_base und sfcb-vmw, möglicherweise fehl und generieren zdump. In der syslog.log-Datei werden Fehlermeldungen wie die folgenden angezeigt:
    sfcb-vmware_base[2110110]: tool_mm_realloc_or_die: memory re-allocation failed(orig=364000 new=364800 msg=Cannot allocate memory, aborting
sfcb-vmw_ipmi[2291550]: tool_mm_realloc_or_die: memory re-allocation failed(orig=909200 new=909600 msg=Cannot allocate memory, aborting

  • Wenn es sich bei der Zielrichtlinie um RAID 1, StripeWidth 1 handelt und ein vSAN-Cluster nur noch wenige vorübergehende Kapazitäten aufweist, konfiguriert der Cluster Level Object Manager möglicherweise weiterhin denselben Teil von Objekten neu, der größer als 8 TB ist. Infolgedessen verbleiben diese Objekte im nicht übereinstimmenden Zustand, und möglicherweise werden einige unnötige Neusynchronisierungsvorgänge angezeigt.

  • In VMware Aria Operations for Logs (vormals vRealize Log Insight) wird möglicherweise eine große Anzahl von Protokollen angezeigt, die von Storage I/O Control generiert werden, z. B. Ungültiger Wert für Freigaben: 0. Standard wird verwendet. und Gerät naa.xxxx wird entweder aufgrund eines VSI-Lesefehlers oder eines abnormalen Status übersprungen. Das Protokollvolumen variiert je nach der Anzahl der ESXi-Hosts in einem Cluster und der Anzahl der Geräte im ausgeschalteten Zustand. Wenn das Problem auftritt, wird das Protokollvolume schnell (innerhalb von 24 Stunden) generiert, und VMware Aria Operations for Logs stuft die Meldungen möglicherweise als kritisch ein. Diese Protokolle sind jedoch unbedenklich und wirken sich nicht auf die Vorgänge auf anderen Online-Datenspeichern aus.

  • Wenn die Liste der Speichersensoren eines ESXi-Hosts leer ist, wird der von der Intelligent Platform Management Interface (IPMI) gemeldete CPU-Status möglicherweise zurückgesetzt. Dies führt dazu, dass der Sensordatensatz mit Element ID 3, dem Status des Prozessors, fälschlicherweise als Über aktuellen Status des physischen Elements kann nicht berichtet werden im MOB angezeigt wird.

  • In Stretched Clustern stellt vSAN jedes VMDK-Objekt mit einem bestimmten Format bereit. Wenn Sie die Richtlinie eines VMDK-Objekts von hostFailuresToTolerate=0 in hostFailuresToTolerate=1 ändern, ändert sich das Format möglicherweise so, dass Lesevorgänge den Site-übergreifenden (AZ-übergreifenden) Link durchlaufen. Dies führt dazu, dass in diesen Objekten eine höhere Leselatenz angezeigt wird.

  • Wenn Sie im vSphere Client eine virtuelle Maschine erstellen oder neu konfigurieren, werden dieselben Optionen im Dropdown-Menü unter SCSI-Controller > Gemeinsame Verwendung des SCSI-Busses möglicherweise doppelt angezeigt. Auf Workflows zum Erstellen oder Konfigurieren der VM hat das Problem keine Auswirkungen.

  • Nach einem Migrationsvorgang fallen virtuelle Maschinen mit Windows 10 unter Umständen aus, wobei ein blauer Diagnosebildschirm angezeigt wird und in einer Fehlermeldung wie der folgenden eine falsche Microcoderevision gemeldet wird: – MICROCODE_REVISION_MISMATCH (17e). Das Problem tritt auf, wenn während des Migrationsvorgangs ein Scan der CPUs durchgeführt wird und die Firmware der Quell-CPUs nicht mit der Firmware der Ziel-CPUs übereinstimmt.

  • In bestimmten Fällen schlägt das Löschen des Caches von Objekten in einem Datenspeichervolume auf ESXi-Hosts fehl, Objekte verbleiben im Cache und führen dazu, dass nicht genügend Arbeitsspeicher vorhanden ist. Dies kommt beispielsweise vor, wenn die Verbindung mit dem zugrunde liegenden Gerät des Volumes unterbrochen wird. Folglich reagiert der ESXi-Host nicht mehr. In den Protokollen werden Fehler angezeigt, wie z. B.:
    Erneute Verbindung mit xxxxx nicht möglich] oder Fehler beim Bereinigen von VMFS-Taktsignal auf Volume xxxxx: Keine Verbindung. oder
    Das Volume auf dem Gerät xxxxx ist gesperrt, möglicherweise weil während eines Volume-Vorgangs ein nicht behebbarer Fehler auf einem Remotehost aufgetreten ist.

  • Bestimmte Workflows wie Sicherungsvorgänge von ESXi-Hosts können eine große Anzahl von Dateien öffnen, was wiederum zu einer Auslastung des Objekt-Caches führen kann. In solchen Fällen kann es vorkommen, dass der hostd-Dienst fehlschlägt, virtuelle Maschinen heruntergefahren werden oder die VM in einen ungültigen Zustand versetzt wird, der ihr Einschalten verhindert. In den Protokollen werden Warnungen angezeigt, wie z. B. Es konnte kein Arbeitsspeicher zugeteilt werden.

  • In Überwachen > Skyline Health > Dateidienst > Integrität des Dateiservers wird möglicherweise die Fehlermeldung Dateiserver wird (neu) gestartet angezeigt.
    Das Problem wird durch eine Cache-Überlauffunktion verursacht, die zu einem Ausfall des VDFS-Daemons führt. In der Datei /var/run/log/vdfsd-server.log in einem betroffenen ESXi-Host werden Meldungen wie NOT_IMPLEMENTED bora/vdfs/core/VDFSPhysicalLog.cpp angezeigt.

  • Wenn Sie im vSphere Client die Richtlinie einer eingeschalteten VM mit einem IDE-Controller ändern, wird möglicherweise folgender Fehler angezeigt: Der versuchte Vorgang kann im aktuellen Zustand (Eingeschaltet) nicht durchgeführt werden.

  • Das Mounten des HCI Mesh-Clusters schlägt möglicherweise fehl, wenn Sie vSAN erneut aktivieren, nachdem Sie vSAN mit Verschlüsselung in Übertragung begriffener Daten deaktiviert haben.

  • Wenn für vSAN verwendete NVMe-Laufwerke über eine doppelte PCI-ID verfügen und Sie den vSAN-Integritätsdienst auf vCenter Server neu starten, fehlt die Hardwarekompatibilitätsgruppe aus vSAN Skyline Health.

  • Wenn zwei NICs, die den Treiber ntg3 der Version 4.1.3 und höher verwenden, direkt und nicht mit einem physischen Switch-Port verbunden sind, kann Link Flapping auftreten. Das Problem tritt nicht bei ntg3-Treibern mit Versionen vor 4.1.3 oder dem tg3-Treiber auf. Dieses Problem steht nicht im Zusammenhang mit dem gelegentlich auftretenden Energy Efficient Ethernet (EEE) Link Flapping bei solchen NICs. Die Lösung für das EEE-Problem besteht darin, einen ntg3-Treiber der Version 4.1.7 oder höher zu verwenden oder EEE an physischen Switch-Ports zu deaktivieren.

  • Der TPM 2.0-Nachweis auf Lenovo-Servern gibt den TPM-Fehlercode zurück: TSS2_SYS_RC_INSUFFICIENT_BUFFER.

ESXi-7.0U3si-20841705-standard

Profilname	ESXi-7.0U3si-20841705-standard
Build	Build-Informationen finden Sie unter In dieser Version enthaltene Patches.
Anbieter	VMware, Inc.
Datum der Veröffentlichung	8. Dezember 2022
Akzeptanzebene	PartnerSupported
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Betroffene VIBs	VMware_bootbank_esx-base_7.0.3-0.60.20841705 VMware_bootbank_trx_7.0.3-0.60.20841705 VMware_bootbank_vsanhealth_7.0.3-0.60.20841705 VMware_bootbank_cpu-microcode_7.0.3-0.60.20841705 VMware_bootbank_crx_7.0.3-0.60.20841705 VMware_bootbank_vsan_7.0.3-0.60.20841705 VMware_bootbank_native-misc-drivers_7.0.3-0.60.20841705 VMware_bootbank_esx-xserver_7.0.3-0.60.20841705 VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.3-0.60.20841705 VMware_bootbank_gc_7.0.3-0.60.20841705 VMware_bootbank_esx-ui_2.1.1-20188605 VMware_bootbank_vdfs_7.0.3-0.60.20841705 VMware_bootbank_bmcal_7.0.3-0.60.20841705 VMware_bootbank_esxio-combiner_7.0.3-0.60.20841705 VMware_bootbank_loadesx_7.0.3-0.60.20841705 VMware_bootbank_esx-update_7.0.3-0.60.20841705 VMware_locker_tools-light_12.1.0.20219665-20841705
Behobene Probleme	2993721, 3007957, 3007958, 3015560, 3034286, 3038621, 3030691, 3015499
Verwandte CVE-Nummern	CVE-2020-28196, CVE-2022-31696, CVE-2022-31699

• Dieser Patch enthält Updates zur Behebung der folgenden Probleme:
  • Das VIB „cpu-microcode“ enthält den folgenden Intel-Microcode:

    Codename	FMS	PLT-ID	MCU-Rev.	MCU-Datum	Markennamen
    Nehalem EP	0x106a5 (06/1a/5)	0x03	0x0000001d	5/11/2018	Intel Xeon 35xx-Reihe; Intel Xeon 55xx-Reihe
    Clarkdale	0x20652 (06/25/2)	0x12	0x00000011	5/8/2018	Intel i3/i5 Clarkdale-Reihe; Intel Xeon 34xx Clarkdale-Reihe
    Arrandale	0x20655 (06/25/5)	0x92	0x00000007	4/23/2018	Intel Core i7-620LE-Prozessor
    Sandy Bridge DT	0x206a7 (06/2a/7)	0x12	0x0000002f	2/17/2019	Intel Xeon E3-1100-Reihe; Intel Xeon E3-1200-Reihe; Intel i7-2655-LE-Reihe; Intel i3-2100-Reihe
    Westmere EP	0x206c2 (06/2c/2)	0x03	0x0000001f	5/8/2018	Intel Xeon 56xx-Reihe; Intel Xeon 36xx-Reihe
    Sandy Bridge EP	0x206d6 (06/2d/6)	0x6d	0x00000621	3/4/2020	Intel Pentium 1400-Reihe; Intel Xeon E5-1400-Reihe; Intel Xeon E5-1600-Reihe; Intel Xeon E5-2400-Reihe; Intel Xeon E5-2600-Reihe; Intel Xeon E5-4600-Reihe
    Sandy Bridge EP	0x206d7 (06/2d/7)	0x6d	0x0000071a	3/24/2020	Intel Pentium 1400-Reihe; Intel Xeon E5-1400-Reihe; Intel Xeon E5-1600-Reihe; Intel Xeon E5-2400-Reihe; Intel Xeon E5-2600-Reihe; Intel Xeon E5-4600-Reihe
    Nehalem EX	0x206e6 (06/2e/6)	0x04	0x0000000d	5/15/2018	Intel Xeon 65xx-Reihe; Intel Xeon 75xx-Reihe
    Westmere EX	0x206f2 (06/2f/2)	0x05	0x0000003b	5/16/2018	Intel Xeon E7-8800-Reihe; Intel Xeon E7-4800-Reihe; Intel Xeon E7-2800-Reihe
    Ivy Bridge DT	0x306a9 (06/3a/9)	0x12	0x00000021	2/13/2019	Intel i3-3200-Reihe; Intel i7-3500-LE/UE; Intel i7-3600-QE; Intel Xeon E3-1200-v2-Reihe; Intel Xeon E3-1100-C-v2-Reihe; Intel Pentium B925C
    Haswell DT	0x306c3 (06/3c/3)	0x32	0x00000028	11/12/2019	Intel Xeon E3-1200-v3-Reihe; Intel i7-4700-EQ-Reihe; Intel i5-4500-TE-Reihe; Intel i3-4300-Reihe
    Ivy Bridge EP	0x306e4 (06/3e/4)	0xed	0x0000042e	3/14/2019	Intel Xeon E5-4600-v2-Reihe; Intel Xeon E5-2600-v2-Reihe; Intel Xeon E5-2400-v2-Reihe; Intel Xeon E5-1600-v2-Reihe; Intel Xeon E5-1400-v2-Reihe
    Ivy Bridge EX	0x306e7 (06/3e/7)	0xed	0x00000715	3/14/2019	Intel Xeon E7-8800/4800/2800-v2-Reihe
    Haswell EP	0x306f2 (06/3f/2)	0x6f	0x00000049	8/11/2021	Intel Xeon E5-4600-v3-Reihe; Intel Xeon E5-2600-v3-Reihe; Intel Xeon E5-2400-v3-Reihe; Intel Xeon E5-1600-v3-Reihe; Intel Xeon E5-1400-v3-Reihe
    Haswell EX	0x306f4 (06/3f/4)	0x80	0x0000001a	5/24/2021	Intel Xeon E7-8800/4800-v3-Serie
    Broadwell H	0x40671 (06/47/1)	0x22	0x00000022	11/12/2019	Intel Core i7-5700EQ; Intel Xeon E3-1200-v4-Reihe
    Avoton	0x406d8 (06/4d/8)	0x01	0x0000012d	16.09.2019	Intel Atom C2300-Reihe; Intel Atom C2500-Reihe; Intel Atom C2700-Reihe
    Broadwell EP/EX	0x406f1 (06/4f/1)	0xef	0x0b000040	5/19/2021	Intel Xeon E7-8800/4800-v4-Reihe; Intel Xeon E5-4600-v4-Reihe; Intel Xeon E5-2600-v4-Reihe; Intel Xeon E5-1600-v4-Reihe
    Skylake SP	0x50654 (06/55/4)	0xb7	0x02006e05	3/8/2022	Intel Xeon Platinum 8100-Reihe; Intel Xeon Gold 6100/5100, Silver 4100, Bronze 3100-Reihe; Intel Xeon D-2100-Reihe; Intel Xeon D-1600-Reihe; Intel Xeon W-3100-Reihe; Intel Xeon W-2100-Reihe
    Cascade Lake B-0	0x50656 (06/55/6)	0xbf	0x04003302	12/10/2021	Intel Xeon Platinum 9200/8200-Reihe; Intel Xeon Gold 6200/5200; Intel Xeon Silver 4200/Bronze 3200; Intel Xeon W-3200
    Cascade Lake	0x50657 (06/55/7)	0xbf	0x05003302	12/10/2021	Intel Xeon Platinum 9200/8200-Reihe; Intel Xeon Gold 6200/5200; Intel Xeon Silver 4200/Bronze 3200; Intel Xeon W-3200
    Cooper Lake	0x5065b (06/55/b)	0xbf	0x07002501	11/19/2021	Intel Xeon Platinum 8300-Reihe; Intel Xeon Gold 6300/5300
    Broadwell DE	0x50662 (06/56/2)	0x10	0x0000001c	17.06.2019	Intel Xeon D-1500-Reihe
    Broadwell DE	0x50663 (06/56/3)	0x10	0x0700001c	6/12/2021	Intel Xeon D-1500-Reihe
    Broadwell DE	0x50664 (06/56/4)	0x10	0x0f00001a	6/12/2021	Intel Xeon D-1500-Reihe
    Broadwell NS	0x50665 (06/56/5)	0x10	0x0e000014	9/18/2021	Intel Xeon D-1600-Reihe
    Skylake H/S	0x506e3 (06/5e/3)	0x36	0x000000f0	11/12/2021	Intel Xeon E3-1500-v5-Reihe; Intel Xeon E3-1200-v5-Reihe
    Denverton	0x506f1 (06/5f/1)	0x01	0x00000038	12/2/2021	Intel Atom C3000-Reihe
    Ice Lake SP	0x606a6 (06/6a/6)	0x87	0x0d000375	4/7/2022	Intel Xeon Silver 4300-Reihe; Intel Xeon Gold 6300/5300-Reihe; Intel Xeon Platinum 8300-Reihe
    Ice Lake D	0x606c1 (06/6c/1)	0x10	0x010001f0	6/24/2022	Intel Xeon D-Reihe
    Snow Ridge	0x80665 (06/86/5)	0x01	0x4c000020	5/10/2022	Intel Atom P5000 Series
    Snow Ridge	0x80667 (06/86/7)	0x01	0x4c000020	5/10/2022	Intel Atom P5000 Series
    Kaby Lake H/S/X	0x906e9 (06/9e/9)	0x2a	0x000000f0	11/12/2021	Intel Xeon E3-1200-v6-Reihe; Intel Xeon E3-1500-v6-Reihe
    Coffee Lake	0x906ea (06/9e/a)	0x22	0x000000f0	11/15/2021	Intel Xeon E-2100-Reihe; Intel Xeon E-2200-Reihe (4 oder 6 Kerne)
    Coffee Lake	0x906eb (06/9e/b)	0x02	0x000000f0	11/12/2021	Intel Xeon E-2100-Reihe
    Coffee Lake	0x906ec (06/9e/c)	0x22	0x000000f0	11/15/2021	Intel Xeon E-2100-Reihe
    Coffee Lake Refresh	0x906ed (06/9e/d)	0x22	0x000000f4	7/31/2022	Intel Xeon E-2200-Reihe (8 Kerne)
    Rocket Lake S	0xa0671 (06/a7/1)	0x02	0x00000056	8/2/2022	Intel Xeon E-2300-Reihe

  • ESXi 7.0 Update 3i stellt die folgenden Sicherheits-Updates bereit:
    • OpenSSL wird auf Version 1.0.2zf aktualisiert.
    • Apache Thrift wurde auf Version 0.15.0 aktualisiert.
    • Der urllib3-Client wird auf Version 1.26.5 aktualisiert.
    • cURL wurde auf Version 7.84.0 aktualisiert.
    • Die SQLite-Datenbank wird auf Version 3.39.2 aktualisiert.
    • Der XML-Parser Expat wurde auf Version 2.4.9 aktualisiert.

  • In dieser Version werden die Schwachstellen CVE-2022-31696 und CVE-2022-31699 behoben. Weitere Informationen zu diesen Schwachstellen und deren Auswirkungen auf VMware Produkte finden Sie unter VMSA-2022-0030.

  • Die folgenden ISO-Images von VMware Tools werden mit ESXi 7.0 Update 3i gebündelt:
    • windows.iso: VMware Tools 12.1.0 unterstützt Windows 7 SP1 oder Windows Server 2008 R2 SP1 oder höher.
    • linux.iso: VMware Tools 10.3.25-ISO-Image für das Linux-Betriebssystem mit glibc 2.11 oder höher.

    Die folgenden VMware Tools-ISO-Images stehen zum Download zur Verfügung:

    • VMware Tools 11.0.6:
      • windows.iso: für Windows Vista (SP2) und Windows Server 2008 Service Pack 2 (SP2).
         
    • VMware Tools 10.0.12:
      • winPreVista.iso: für Windows 2000, Windows XP und Windows 2003.
      • linuxPreGLibc25.iso: unterstützt Linux-Gastbetriebssysteme vor Red Hat Enterprise Linux (RHEL) 5, SUSE Linux Enterprise Server (SLES) 11, Ubuntu 7.04 und andere Distributionen mit einer glibc-Version vor 2.5.
         
    • solaris.iso: VMware Tools-Image 10.3.10 für Solaris.
    • darwin.iso: Unterstützt Mac OS X-Versionen 10.11 und höher.

    Befolgen Sie die in den folgenden Dokumenten aufgeführten Vorgehensweisen, um VMware Tools für Plattformen, die nicht mit ESXi gebündelt sind, herunterzuladen:

    • Versionshinweise zu VMware Tools 12.1.0
    • Frühere Versionen von VMware Tools
    • Wichtige Informationen zu VMware Tools für Administratoren
    • VMware Tools für Hosts, die mit Auto Deploy bereitgestellt wurden
    • Aktualisieren von VMware Tools

ESXi-7.0U3si-20841705-no-tools

Profilname	ESXi-7.0U3si-20841705-no-tools
Build	Build-Informationen finden Sie unter In dieser Version enthaltene Patches.
Anbieter	VMware, Inc.
Datum der Veröffentlichung	8. Dezember 2022
Akzeptanzebene	PartnerSupported
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Betroffene VIBs	VMware_bootbank_esx-base_7.0.3-0.60.20841705 VMware_bootbank_trx_7.0.3-0.60.20841705 VMware_bootbank_vsanhealth_7.0.3-0.60.20841705 VMware_bootbank_cpu-microcode_7.0.3-0.60.20841705 VMware_bootbank_crx_7.0.3-0.60.20841705 VMware_bootbank_vsan_7.0.3-0.60.20841705 VMware_bootbank_native-misc-drivers_7.0.3-0.60.20841705 VMware_bootbank_esx-xserver_7.0.3-0.60.20841705 VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.3-0.60.20841705 VMware_bootbank_gc_7.0.3-0.60.20841705 VMware_bootbank_esx-ui_2.1.1-20188605 VMware_bootbank_vdfs_7.0.3-0.60.20841705 VMware_bootbank_bmcal_7.0.3-0.60.20841705 VMware_bootbank_esxio-combiner_7.0.3-0.60.20841705 VMware_bootbank_loadesx_7.0.3-0.60.20841705 VMware_bootbank_esx-update_7.0.3-0.60.20841705
Behobene Probleme	2993721, 3007957, 3007958, 3015560, 3034286, 3038621, 3030691
Verwandte CVE-Nummern	CVE-2020-28196, CVE-2022-31696, CVE-2022-31699

• Dieser Patch enthält Updates zur Behebung der folgenden Probleme:
  • Das VIB „cpu-microcode“ enthält den folgenden Intel-Microcode:

    Codename	FMS	PLT-ID	MCU-Rev.	MCU-Datum	Markennamen
    Nehalem EP	0x106a5 (06/1a/5)	0x03	0x0000001d	5/11/2018	Intel Xeon 35xx-Reihe; Intel Xeon 55xx-Reihe
    Clarkdale	0x20652 (06/25/2)	0x12	0x00000011	5/8/2018	Intel i3/i5 Clarkdale-Reihe; Intel Xeon 34xx Clarkdale-Reihe
    Arrandale	0x20655 (06/25/5)	0x92	0x00000007	4/23/2018	Intel Core i7-620LE-Prozessor
    Sandy Bridge DT	0x206a7 (06/2a/7)	0x12	0x0000002f	2/17/2019	Intel Xeon E3-1100-Reihe; Intel Xeon E3-1200-Reihe; Intel i7-2655-LE-Reihe; Intel i3-2100-Reihe
    Westmere EP	0x206c2 (06/2c/2)	0x03	0x0000001f	5/8/2018	Intel Xeon 56xx-Reihe; Intel Xeon 36xx-Reihe
    Sandy Bridge EP	0x206d6 (06/2d/6)	0x6d	0x00000621	3/4/2020	Intel Pentium 1400-Reihe; Intel Xeon E5-1400-Reihe; Intel Xeon E5-1600-Reihe; Intel Xeon E5-2400-Reihe; Intel Xeon E5-2600-Reihe; Intel Xeon E5-4600-Reihe
    Sandy Bridge EP	0x206d7 (06/2d/7)	0x6d	0x0000071a	3/24/2020	Intel Pentium 1400-Reihe; Intel Xeon E5-1400-Reihe; Intel Xeon E5-1600-Reihe; Intel Xeon E5-2400-Reihe; Intel Xeon E5-2600-Reihe; Intel Xeon E5-4600-Reihe
    Nehalem EX	0x206e6 (06/2e/6)	0x04	0x0000000d	5/15/2018	Intel Xeon 65xx-Reihe; Intel Xeon 75xx-Reihe
    Westmere EX	0x206f2 (06/2f/2)	0x05	0x0000003b	5/16/2018	Intel Xeon E7-8800-Reihe; Intel Xeon E7-4800-Reihe; Intel Xeon E7-2800-Reihe
    Ivy Bridge DT	0x306a9 (06/3a/9)	0x12	0x00000021	2/13/2019	Intel i3-3200-Reihe; Intel i7-3500-LE/UE; Intel i7-3600-QE; Intel Xeon E3-1200-v2-Reihe; Intel Xeon E3-1100-C-v2-Reihe; Intel Pentium B925C
    Haswell DT	0x306c3 (06/3c/3)	0x32	0x00000028	11/12/2019	Intel Xeon E3-1200-v3-Reihe; Intel i7-4700-EQ-Reihe; Intel i5-4500-TE-Reihe; Intel i3-4300-Reihe
    Ivy Bridge EP	0x306e4 (06/3e/4)	0xed	0x0000042e	3/14/2019	Intel Xeon E5-4600-v2-Reihe; Intel Xeon E5-2600-v2-Reihe; Intel Xeon E5-2400-v2-Reihe; Intel Xeon E5-1600-v2-Reihe; Intel Xeon E5-1400-v2-Reihe
    Ivy Bridge EX	0x306e7 (06/3e/7)	0xed	0x00000715	3/14/2019	Intel Xeon E7-8800/4800/2800-v2-Reihe
    Haswell EP	0x306f2 (06/3f/2)	0x6f	0x00000049	8/11/2021	Intel Xeon E5-4600-v3-Reihe; Intel Xeon E5-2600-v3-Reihe; Intel Xeon E5-2400-v3-Reihe; Intel Xeon E5-1600-v3-Reihe; Intel Xeon E5-1400-v3-Reihe
    Haswell EX	0x306f4 (06/3f/4)	0x80	0x0000001a	5/24/2021	Intel Xeon E7-8800/4800-v3-Serie
    Broadwell H	0x40671 (06/47/1)	0x22	0x00000022	11/12/2019	Intel Core i7-5700EQ; Intel Xeon E3-1200-v4-Reihe
    Avoton	0x406d8 (06/4d/8)	0x01	0x0000012d	16.09.2019	Intel Atom C2300-Reihe; Intel Atom C2500-Reihe; Intel Atom C2700-Reihe
    Broadwell EP/EX	0x406f1 (06/4f/1)	0xef	0x0b000040	5/19/2021	Intel Xeon E7-8800/4800-v4-Reihe; Intel Xeon E5-4600-v4-Reihe; Intel Xeon E5-2600-v4-Reihe; Intel Xeon E5-1600-v4-Reihe
    Skylake SP	0x50654 (06/55/4)	0xb7	0x02006e05	3/8/2022	Intel Xeon Platinum 8100-Reihe; Intel Xeon Gold 6100/5100, Silver 4100, Bronze 3100-Reihe; Intel Xeon D-2100-Reihe; Intel Xeon D-1600-Reihe; Intel Xeon W-3100-Reihe; Intel Xeon W-2100-Reihe
    Cascade Lake B-0	0x50656 (06/55/6)	0xbf	0x04003302	12/10/2021	Intel Xeon Platinum 9200/8200-Reihe; Intel Xeon Gold 6200/5200; Intel Xeon Silver 4200/Bronze 3200; Intel Xeon W-3200
    Cascade Lake	0x50657 (06/55/7)	0xbf	0x05003302	12/10/2021	Intel Xeon Platinum 9200/8200-Reihe; Intel Xeon Gold 6200/5200; Intel Xeon Silver 4200/Bronze 3200; Intel Xeon W-3200
    Cooper Lake	0x5065b (06/55/b)	0xbf	0x07002501	11/19/2021	Intel Xeon Platinum 8300-Reihe; Intel Xeon Gold 6300/5300
    Broadwell DE	0x50662 (06/56/2)	0x10	0x0000001c	17.06.2019	Intel Xeon D-1500-Reihe
    Broadwell DE	0x50663 (06/56/3)	0x10	0x0700001c	6/12/2021	Intel Xeon D-1500-Reihe
    Broadwell DE	0x50664 (06/56/4)	0x10	0x0f00001a	6/12/2021	Intel Xeon D-1500-Reihe
    Broadwell NS	0x50665 (06/56/5)	0x10	0x0e000014	9/18/2021	Intel Xeon D-1600-Reihe
    Skylake H/S	0x506e3 (06/5e/3)	0x36	0x000000f0	11/12/2021	Intel Xeon E3-1500-v5-Reihe; Intel Xeon E3-1200-v5-Reihe
    Denverton	0x506f1 (06/5f/1)	0x01	0x00000038	12/2/2021	Intel Atom C3000-Reihe
    Ice Lake SP	0x606a6 (06/6a/6)	0x87	0x0d000375	4/7/2022	Intel Xeon Silver 4300-Reihe; Intel Xeon Gold 6300/5300-Reihe; Intel Xeon Platinum 8300-Reihe
    Ice Lake D	0x606c1 (06/6c/1)	0x10	0x010001f0	6/24/2022	Intel Xeon D-Reihe
    Snow Ridge	0x80665 (06/86/5)	0x01	0x4c000020	5/10/2022	Intel Atom P5000 Series
    Snow Ridge	0x80667 (06/86/7)	0x01	0x4c000020	5/10/2022	Intel Atom P5000 Series
    Kaby Lake H/S/X	0x906e9 (06/9e/9)	0x2a	0x000000f0	11/12/2021	Intel Xeon E3-1200-v6-Reihe; Intel Xeon E3-1500-v6-Reihe
    Coffee Lake	0x906ea (06/9e/a)	0x22	0x000000f0	11/15/2021	Intel Xeon E-2100-Reihe; Intel Xeon E-2200-Reihe (4 oder 6 Kerne)
    Coffee Lake	0x906eb (06/9e/b)	0x02	0x000000f0	11/12/2021	Intel Xeon E-2100-Reihe
    Coffee Lake	0x906ec (06/9e/c)	0x22	0x000000f0	11/15/2021	Intel Xeon E-2100-Reihe
    Coffee Lake Refresh	0x906ed (06/9e/d)	0x22	0x000000f4	7/31/2022	Intel Xeon E-2200-Reihe (8 Kerne)
    Rocket Lake S	0xa0671 (06/a7/1)	0x02	0x00000056	8/2/2022	Intel Xeon E-2300-Reihe

  • ESXi 7.0 Update 3i stellt die folgenden Sicherheits-Updates bereit:
    • OpenSSL wird auf Version 1.0.2zf aktualisiert.
    • Apache Thrift wurde auf Version 0.15.0 aktualisiert.
    • Der urllib3-Client wird auf Version 1.26.5 aktualisiert.
    • cURL wurde auf Version 7.84.0 aktualisiert.
    • Die SQLite-Datenbank wird auf Version 3.39.2 aktualisiert.
    • Der XML-Parser Expat wurde auf Version 2.4.9 aktualisiert.

  • In dieser Version werden die Schwachstellen CVE-2022-31696 und CVE-2022-31699 behoben. Weitere Informationen zu diesen Schwachstellen und deren Auswirkungen auf VMware Produkte finden Sie unter VMSA-2022-0030.

  • Die folgenden ISO-Images von VMware Tools werden mit ESXi 7.0 Update 3i gebündelt:
    • windows.iso: VMware Tools 12.1.0 unterstützt Windows 7 SP1 oder Windows Server 2008 R2 SP1 oder höher.
    • linux.iso: VMware Tools 10.3.25-ISO-Image für das Linux-Betriebssystem mit glibc 2.11 oder höher.

    Die folgenden VMware Tools-ISO-Images stehen zum Download zur Verfügung:

    • VMware Tools 11.0.6:
      • windows.iso: für Windows Vista (SP2) und Windows Server 2008 Service Pack 2 (SP2).
         
    • VMware Tools 10.0.12:
      • winPreVista.iso: für Windows 2000, Windows XP und Windows 2003.
      • linuxPreGLibc25.iso: unterstützt Linux-Gastbetriebssysteme vor Red Hat Enterprise Linux (RHEL) 5, SUSE Linux Enterprise Server (SLES) 11, Ubuntu 7.04 und andere Distributionen mit einer glibc-Version vor 2.5.
         
    • solaris.iso: VMware Tools-Image 10.3.10 für Solaris.
    • darwin.iso: Unterstützt Mac OS X-Versionen 10.11 und höher.

    Befolgen Sie die in den folgenden Dokumenten aufgeführten Vorgehensweisen, um VMware Tools für Plattformen, die nicht mit ESXi gebündelt sind, herunterzuladen:

    • Versionshinweise zu VMware Tools 12.1.0
    • Frühere Versionen von VMware Tools
    • Wichtige Informationen zu VMware Tools für Administratoren
    • VMware Tools für Hosts, die mit Auto Deploy bereitgestellt wurden
    • Aktualisieren von VMware Tools

ESXi_7.0.3-0.65.20842708

Name	ESXi
Version	ESXi_7.0.3-0.65.20842708
Datum der Veröffentlichung	8. Dezember 2022
Kategorie	Fehlerkorrektur
Betroffene Komponenten	ESXi-Komponente - ESXi-Kern-VIBs ESXi-Komponente „Installieren/Aktualisieren“ Broadcom NetXtreme I ESX VMKAPI-Ethernet-Treiber
Behobene Probleme
Verwandte CVE-Nummern	Nicht verfügbar

ESXi_7.0.3-0.60.20841705

Name	ESXi
Version	ESXi_7.0.3-0.60.20841705
Datum der Veröffentlichung	8. Dezember 2022
Kategorie	Sicherheit
Betroffene Komponenten	ESXi-Komponente - ESXi-Kern-VIBs ESXi-Komponente „Installieren/Aktualisieren“ ESXi Tools-Komponente
Behobene Probleme
Verwandte CVE-Nummern	Nicht verfügbar

Bekannte Probleme

Die bekannten Probleme gliedern sich in folgende Gruppen.

• Installations-, Upgrade- und Migrationsprobleme
• Bekannte Probleme aus vorherigen Versionen

Installations-, Upgrade- und Migrationsprobleme

• Die vlanid-Eigenschaft in benutzerdefinierten Installationsskripts funktioniert möglicherweise nicht

  Wenn Sie ein benutzerdefiniertes Installationsskript verwenden, das die vlanid-Eigenschaft zum Festlegen eines gewünschten VLANs festlegt, wird die Eigenschaft möglicherweise auf neu installierten ESXi-Hosts nicht wirksam. Das Problem tritt nur auf, wenn eine physische Netzwerkkarte beim Starten der Installation bereits mit DHCP verbunden ist. Die vlanid-Eigenschaft funktioniert ordnungsgemäß, wenn Sie eine neu verbundene Netzwerkkarte (NIC) verwenden.

  Problemumgehung: Stellen Sie das VLAN manuell über die Benutzerschnittstelle der direkten Konsole (Direct Console User Interface, DCUI) ein, nachdem Sie den ESXi-Host gestartet haben. Deaktivieren Sie alternativ die physische Netzwerkkarte (NIC) und starten Sie den Host.

• HPE-Server mit Trusted Platform Module (TPM) werden gestartet, aber der Remote-Nachweis schlägt fehl

  Einige HPE-Server verfügen nicht über genügend Ereignisprotokollspeicher, um den TPM-Remote-Nachweis ordnungsgemäß abzuschließen. Folglich wird der VMkernel zwar gestartet, aber der Remote-Nachweis schlägt aufgrund des abgeschnittenen Protokolls fehl.

  Problemumgehung: Keine.

Bekannte Probleme aus vorherigen Versionen

Um eine Liste früherer bekannter Probleme anzuzeigen, klicken Sie hier.

Die früheren bekannten Probleme gliedern sich in folgende Gruppen.

• vSAN-Probleme
• Probleme bei vSphere Cluster Services
• Installations-, Upgrade- und Migrationsprobleme
• Probleme bei Sicherheitsfunktionen
• Netzwerkprobleme
• Speicherprobleme
• Probleme bei vCenter Server und dem vSphere Client
• VM-Verwaltungsprobleme
• vSphere HA- und Fault Tolerance-Probleme
• Probleme bei vSphere Lifecycle Manager
• Sonstige Probleme
• Probleme in Bezug auf den vSphere Client

vSAN-Probleme

• Wenn Sie die bevorzugte Site in einem VMware vSAN Stretched Cluster ändern, werden bestimmte Objekte unter Umständen fälschlicherweise als konform angezeigt

  Wenn Sie die bevorzugte Site in einem Stretched Cluster ändern, können bestimmte Objekte fälschlicherweise als konform angezeigt werden, da ihre Richtlinieneinstellungen unter Umständen nicht automatisch geändert werden. Wenn Sie eine virtuelle Maschine beispielsweise zur Beibehaltung von Daten auf der bevorzugten Site konfigurieren, verbleiben die Daten beim Ändern der bevorzugten Site unter Umständen auf der nicht bevorzugten Site.

  Problemumgehung: Legen Sie die Einstellung ClomMaxCycleMinutes vor dem Ändern einer bevorzugten Site unter „Erweiterte Einstellungen“ auf 15 Minuten fest, um sicherzustellen, dass die Objektrichtlinien aktualisiert werden. Setzen Sie die Option ClomMaxCrawlCycleMinutes nach der Änderung auf den früheren Wert zurück.

Probleme bei vSphere Cluster Services

• Bei neuen vCLS-VMs, die in einer vSphere 7.0 Update 3-Umgebung bereitgestellt werden, treten Kompatibilitätsprobleme auf

  Für den Standardnamen für neue vCLS-VMs, die in einer vSphere 7.0 Update 3-Umgebung bereitgestellt werden, wird das Muster „vCLS-UUID“ verwendet. Für vCLS-VMs, die in früheren vCenter Server-Versionen erstellt wurden, wird weiterhin das Muster „vCLS (n)“ verwendet. Da die Verwendung runder Klammern von vielen Lösungen, die mit vSphere interagieren, nicht unterstützt wird, können Kompatibilitätsprobleme auftreten.

  Problemumgehung: Konfigurieren Sie vCLS mithilfe des Rückzugsmodus neu, nachdem Sie ein Upgrade auf vSphere 7.0 Update 3 durchgeführt haben.

Installations-, Upgrade- und Migrationsprobleme

• Die Vorabprüfungen für vCenter-Upgrades/Migrationen schlagen mit „Unerwarteter Fehler 87“ fehl

  Die Vorabprüfungen für vCenter Server-Upgrades/Migrationen schlagen fehl, wenn das Security Token Service-Zertifikat (STS) kein Feld für SAN (Subject Alternative Name) enthält. Diese Situation tritt auf, wenn Sie das vCenter 5.5 Single Sign-On-Zertifikat durch ein benutzerdefiniertes Zertifikat ohne SAN-Feld ersetzt haben und versuchen, ein Upgrade auf vCenter Server 7.0 durchzuführen. Das Upgrade betrachtet das STS-Zertifikat als ungültig, und die Vorabprüfungen verhindern, dass der Upgrade-Vorgang fortgesetzt wird.

  Problemumgehung: Ersetzen Sie das STS-Zertifikat durch ein gültiges Zertifikat, das ein SAN-Feld enthält, und fahren Sie dann mit dem Upgrade/der Migration von vCenter Server 7.0 fort.

• Probleme beim Upgrade auf vSphere 7.0 mit vorhandenen CIM-Anbietern

  Nach dem Upgrade funktionieren zuvor installierte 32-Bit-CIM-Anbieter nicht mehr, da ESXi 64-Bit-CIM-Anbieter benötigt. Kunden verlieren möglicherweise Verwaltungs-API-Funktionen im Zusammenhang mit CIMPDK, NDDK (natives DDK), HEXDK, VAIODK (E/A-Filter) und sehen Fehler im Zusammenhang mit uwglibc-Abhängigkeit.
  Das Syslog meldet ein fehlendes Modul, „32 bit shared libraries not loaded“.

  Problemumgehung: Für dieses Problem gibt es keine Umgehung. Die Lösung besteht darin, neue 64-Bit-CIM-Anbieter von Ihrem Anbieter herunterzuladen.

• Die Installation von 7.0 Update 1-Treibern auf ESXi 7.0-Hosts schlägt möglicherweise fehl

  Sie können keine Treiber für ESXi 7.0 Update 1 auf Hosts installieren, auf denen ESXi 7.0 oder 7.0b ausgeführt wird.
  Der Vorgang schlägt mit einer Fehlermeldung ähnlich der folgenden fehl:
  VMW_bootbank_qedrntv_3.40.4.0-12vmw.701.0.0.xxxxxxx erfordert vmkapi_2_7_0_0, doch die Anforderung kann innerhalb des ImageProfile nicht erfüllt werden. ​
Weitere Informationen hierzu finden Sie in der Protokolldatei.

  Problemumgehung: Aktualisieren Sie den ESXi-Host auf 7.0 Update 1. Wiederholen Sie die Treiberinstallation.

• Der UEFI-Neustart von ESXi-Hosts wird während eines Updates von einer früheren Version von ESXi 7.0 auf ESXi 7.0 Update 2 möglicherweise beendet

  Wenn Sie versuchen, Ihre Umgebung von einer früheren Version von ESXi 7.0 auf Version 7.0 Update 2 zu aktualisieren und dabei vSphere Lifecycle Manager-Patch-Baselines verwenden, wird der UEFI-Neustart von ESXi-Hosts möglicherweise mit einem Fehler ähnlich dem folgenden beendet:
  Laden von /boot.cfg
crypto64.efi konnte nicht geladen werden
Fatal error: 15 (nicht gefunden)

  Problemumgehung: Weitere Informationen finden Sie in den VMware-Knowledgebase-Artikeln 83063 und 83107.

• Wenn Legacy-VIBs auf einem ESXi-Host verwendet werden, kann vSphere Lifecycle Manager eine gewünschte Softwarespezifikation für ein Seeding für einen neuen Cluster nicht extrahieren

  Mit vCenter Server 7.0 Update 2 können Sie einen neuen Cluster erstellen, indem Sie die gewünschte Softwarespezifikation von einem einzelnen Referenzhost importieren.  Wenn jedoch auf einem ESXi-Host Legacy-VIBs verwendet werden, kann vSphere Lifecycle Manager in der vCenter Server-Instanz, in der Sie den Cluster erstellen, keine Referenzsoftwarespezifikation von einem solchen Host extrahieren. In der Datei /var/log/lifecycle.log werden Meldungen ähnlich der folgenden angezeigt:
  020-11-11T06:54:03Z lifecycle: 1000082644: HostSeeding:499 ERROR Extract depot failed: Checksum doesn't match. Calculated 5b404e28e83b1387841bb417da93c8c796ef2497c8af0f79583fd54e789d8826, expected: 0947542e30b794c721e21fb595f1851b247711d0619c55489a6a8cae6675e796 2020-11-11T06:54:04Z lifecycle: 1000082644: imagemanagerctl:366 ERROR Extract depot failed. 2020-11-11T06:54:04Z lifecycle: 1000082644: imagemanagerctl:145 ERROR [VibChecksumError]

  Problemumgehung: Befolgen Sie die im VMware-Knowledgebase-Artikel 83042 beschriebenen Schritte.

• Nach jedem ESXi-Startvorgang wird in der Datei „syslog.log“ ein kurzer Anstieg von Protokollmeldungen verzeichnet

  Nach der Aktualisierung auf ESXi 7.0 Update 2 wird im Anschluss an jeden Startvorgang unter Umständen ein kurzer Anstieg von Protokollmeldungen verzeichnet.
  Solche Protokolle weisen nicht auf ein Problem mit ESXi hin. Die folgenden Meldungen können ignoriert werden. Beispiel:
  ​2021-01-19T22:44:22Z watchdog-vaai-nasd: '/usr/lib/vmware/nfs/bin/vaai-nasd -f' exited after 0 seconds (quick failure 127) 1
2021-01-19T22:44:22Z watchdog-vaai-nasd: Executing '/usr/lib/vmware/nfs/bin/vaai-nasd -f'
2021-01-19T22:44:22.990Z aainasd[1000051135]: Log for VAAI-NAS Daemon for NFS version=1.0 build=build-00000 option=DEBUG
2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoadFile: No entries loaded by dictionary.
2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoad: Cannot open file "/usr/lib/vmware/config": No such file or directory.“
2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoad: Cannot open file "//.vmware/config": No such file or directory.“
2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoad: Cannot open file "//.vmware/preferences": No such file or directory.“
2021-01-19T22:44:22.990Z vaainasd[1000051135]: Switching to VMware syslog extensions
2021-01-19T22:44:22.992Z vaainasd[1000051135]: Loading VAAI-NAS plugin(s).
2021-01-19T22:44:22.992Z vaainasd[1000051135]: DISKLIB-PLUGIN : Not loading plugin /usr/lib/vmware/nas_plugins/lib64: Not a shared library.

  Problemumgehung: Keine

• In Berichten zur vSphere Quick Boot-Kompatibilitätsprüfung werden Warnmeldungen zu fehlenden VIBs angezeigt

  Wenn Sie nach einem Upgrade auf ESXi 7.0 Update 2 die vSphere Quick Boot-Kompatibilität Ihrer Umgebung mithilfe des Befehls /usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py überprüfen, werden möglicherweise einige Warnungen zu fehlenden VIBs in der Shell angezeigt. Beispiel:
  VIB(s) wurde(n) ... in der angegebenen VIB-Sammlung nicht gefunden.
Fehlende reservierte VIB(s) wird/werden ignoriert..., sie werden aus den reservierten VIB-IDs entfernt.
  Solche Warnungen weisen nicht auf ein Kompatibilitätsproblem hin.

  Problemumgehung: Es ist sicher, die Meldungen zu fehlenden VIBs zu ignorieren. Dies wirkt sich nicht auf die vSphere Quick Boot-Kompatibilität aus. In der letzten Ausgabezeile des Befehls loadESXCheckCompat wird eindeutig angegeben, ob der Host kompatibel ist.

• Automatisches Bootstrapping eines Clusters, den Sie mit einem vSphere Lifecycle Manager-Image verwalten, schlägt mit einem Fehler fehl

  Wenn Sie versuchen, für einen Cluster, den Sie mit einem vSphere Lifecycle Manager-Image verwalten, automatisches Bootstrapping zu verwenden, um eine statusbehaftete Installation und Überschreibung der VMFS-Partitionen durchzuführen, schlägt der Vorgang mit einer Fehlermeldung fehl. Im Support-Paket werden Meldungen ähnlich der folgenden angezeigt:
  2021-02-11T19:37:43Z Host Profiles[265671 opID=MainThread]: FEHLER: EngineModule::ApplyHostConfig. Exception: [Errno 30] Schreibgeschütztes Dateisystem

  Problemumgehung: Folgen Sie den Anweisungen des Anbieters, um die VMFS-Partition auf dem Zielhost zu bereinigen, und wiederholen Sie den Vorgang. Alternativ können Sie eine leere Festplatte verwenden. Weitere Informationen zum Dienstprogramm zur Festplattenpartitionierung auf ESXi finden Sie im VMware-Knowledgebase-Artikel 1036609.

• Upgrades von ESXi 6.5.x und 6.7.0 auf ESXi 7.x unter Verwendung von ESXCLI können aufgrund einer Speicherbeschränkung fehlschlagen

  Upgrades auf von ESXi 6.5.x und 6.7.0 auf ESXi 7 mithilfe des ESXCLI-Befehls esxcli software profile update oder esxcli software profile install können fehlschlagen, da die ESXi-Bootbank möglicherweise die Größe des Image-Profils unterschreitet. In der ESXi Shell oder der PowerCLI Shell wird folgender Fehler angezeigt:

  [InstallationError]
   Die ausstehende Transaktion benötigt 244 MB freien Speicher, die maximal unterstützte Größe beträgt jedoch 239 MB.
   Weitere Informationen hierzu finden Sie in der Protokolldatei.

  Das Problem tritt auch auf, wenn Sie ein Upgrade des ESXi-Hosts mithilfe des ESXCLI-Befehls esxcli software vib update oder esxcli software vib install versuchen.

  Problemumgehung: Sie können das Upgrade in zwei Schritten durchführen, indem Sie ESXi-Hosts mit dem Befehl esxcli software profile update erst auf ESXi 6.7 Update 1 oder höher und dann auf ESXi 7.0 Update 1c aktualisieren. Alternativ können Sie ein Upgrade mithilfe eines ISO-Images und des vSphere Lifecycle Manager ausführen.

• Sie können Linked Clones nicht über vCenter Server hinweg migrieren.

  Wenn Sie einen Linked Clone über vCenter Server hinweg migrieren, schlagen Vorgänge wie Einschalten und Löschen für die virtuelle Quellmaschine möglicherweise mit dem Fehler Ungültiger Status der virtuellen Maschine fehl.

  Problemumgehung: Behalten Sie Linked Clones auf demselben vCenter Server wie die Quell-VM bei. Alternativ können Sie den Linked Clone vor der Migration auf einen vollständigen Klon heraufstufen.

• Die Migration zwischen vCenter Servern von virtuellen Maschinen mit vielen virtuellen Festplatten und Snapshot-Ebenen zu einem Datenspeicher auf NVMe-over-TCP-Speicher schlägt möglicherweise fehl

  Die Migration zwischen vCenter Servern von virtuellen Maschinen mit mehr als 180 virtuellen Festplatten und 32 Snapshot-Ebenen zu einem Datenspeicher auf NVMe-over-TCP-Speicher schlägt möglicherweise fehl. Der ESXi-Host schlägt präventiv mit einem Fehler wie Die Migration hat die maximale Umschaltzeit von 100 Sekunden überschritten fehl.

  Problemumgehung: Keine

• Eine virtuelle Maschine mit aktivierten Virtual Performance Monitoring Counters (VPMC) kann möglicherweise nicht zwischen ESXi-Hosts migriert werden

  Wenn Sie versuchen, eine virtuelle Maschine mit aktivierten VPMC mithilfe von vSphere vMotion zu migrieren, schlägt der Vorgang möglicherweise fehl, wenn der Zielhost einige der Indikatoren zum Berechnen des Arbeitsspeichers oder der Leistungsstatistiken verwendet. Der Vorgang schlägt mit einem Fehler wie Ein vom Gast verwendeter Leistungsindikator ist auf der Host-CPU nicht verfügbar fehl.

  Problemumgehung: Schalten Sie die virtuelle Maschine aus und verwenden Sie die Cold-Migration. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 81191.

• Wenn ein Live-VIB-Installations-, Upgrade- oder Entfernungsvorgang unmittelbar vor einem interaktiven oder geskripteten Upgrade auf ESXi 7.0 Update 3 unter Verwendung der ISO-Datei des Installationsprogramms erfolgt, schlägt das Upgrade fehl.

  Wenn ein VIB-Installations-, Upgrade- oder Entfernungsvorgang unmittelbar vor einem interaktiven oder geskripteten Upgrade auf ESXi 7.0 Update 3 unter Verwendung der ISO-Datei des Installationsprogramms erfolgt, behält der ConfigStore möglicherweise einige Konfigurationen des Upgrades nicht bei. Dies führt dazu, dass auf ESXi-Hosts nach dem Upgradevorgang nicht mehr zugegriffen werden kann, obwohl das Upgrade erfolgreich gewesen zu sein scheint. Um dieses Problem zu vermeiden, fügt das ESXi 7.0 Update 3-Installationsprogramm eine temporäre Prüfung hinzu, um solche Szenarien zu blockieren. In der Konsole des ESXi-Installationsprogramms wird die folgende Fehlermeldung angezeigt: Die Installation, das Upgrade oder die Entfernung von Live-VIB kann dazu führen, dass nachfolgende ESXi-Upgrades bei Verwendung des ISO-Installationsprogramms fehlschlagen.

  Problemumgehung: Verwenden Sie eine alternative Upgrademethode, um das Problem zu vermeiden, z. B. die Verwendung von ESXCLI oder vSphere Lifecycle Manager.

• Die Smartcard- und RSA SecurID-Authentifizierung funktioniert nach dem Upgrade auf vCenter Server 7.0 möglicherweise nicht mehr

  Wenn Sie vCenter Server für Smartcard- oder RSA SecurID-Authentifizierung konfiguriert haben, lesen Sie den VMware-Knowledgebase-Artikel unter https://kb.vmware.com/s/article/78057, bevor Sie den vSphere 7.0-Upgrade-Vorgang starten. Wenn Sie die Problemumgehung nicht wie in der KB beschrieben durchführen, werden möglicherweise die folgenden Fehlermeldungen angezeigt und die Smartcard- oder RSA SecurID-Authentifizierung funktioniert nicht.

  „Die Smartcard-Authentifizierung funktioniert möglicherweise nicht mehr. Die Smartcard-Einstellungen werden möglicherweise nicht beibehalten, und die Smartcard-Authentifizierung funktioniert möglicherweise nicht mehr.“

  oder

  „Die RSA SecurID-Authentifizierung funktioniert möglicherweise nicht mehr. Die RSA SecurID-Einstellungen werden möglicherweise nicht beibehalten, und die RSA SecurID-Authentifizierung funktioniert möglicherweise nicht mehr.“

  Problemumgehung: Lesen Sie vor dem Upgrade auf vSphere 7.0 den VMware-Knowledgebase-Artikel unter https://kb.vmware.com/s/article/78057.

• Das Upgrade eines vCenter Server mit einem externen Platform Services Controller von 6.7u3 auf 7.0 schlägt mit einem VMAFD-Fehler fehl

  Wenn Sie eine vCenter Server-Bereitstellung mit einem externen Platform Services Controller aktualisieren, konvergieren Sie den Platform Services Controller in eine vCenter Server Appliance. Wenn das Upgrade mit dem Fehler install.vmafd.vmdir_vdcpromo_error_21 fehlschlägt, ist der Firstboot-Vorgang von VMAFD fehlgeschlagen. Beim Firstboot-Vorgang von VMAFD wird die VMware Directory Service-Datenbank (data.mdb) vom Platform Services Controller der Quelle und von der vCenter Server Appliance des Replikationspartners kopiert.

  Problemumgehung: Deaktivieren Sie auf dem Ethernet-Adapter des Platform Services Controller der Quelle oder der vCenter Server Appliance des Replikationspartners TCP Segmentation Offload (TSO) und Generic Segmentation Offload (GSO), bevor Sie ein Upgrade eines vCenter Server mit einem externen Platform Services Controller durchführen. Weitere Informationen hierzu finden Sie im Knowledgebase-Artikel: https://kb.vmware.com/s/article/74678

• Smartcard- und RSA SecurID-Einstellungen werden während des vCenter Server-Upgrades möglicherweise nicht beibehalten

  Die Authentifizierung mit RSA SecurID funktioniert nach dem Upgrade auf vCenter Server 7.0 nicht. Eine Fehlermeldung informiert Sie über dieses Problem, wenn Sie versuchen, sich mit Ihrer RSA SecurID-Anmeldung anzumelden.

  Problemumgehung: Konfigurieren Sie die Smartcard oder RSA SecurID neu.

• Die Migration von vCenter Server für Windows auf vCenter Server Appliance 7.0 schlägt mit einer Netzwerkfehlermeldung fehl

  Die Migration von vCenter Server für Windows auf vCenter Server Appliance 7.0 schlägt mit der Fehlermeldung IP ist bereits im Netzwerk vorhanden fehl. Dadurch wird verhindert, dass der Migrationsvorgang die Netzwerkparameter auf der neuen vCenter Server Appliance konfiguriert. Weitere Informationen finden Sie in der Protokolldatei: /var/log/vmware/upgrade/UpgradeRunner.log

  Problemumgehung:

  1. Stellen Sie sicher, dass alle Windows Updates auf der vCenter Server für Windows-Quellinstanz abgeschlossen wurden, oder deaktivieren Sie automatische Windows Updates, bis die Migration beendet ist.
  2. Wiederholen Sie die Migration von vCenter Server für Windows zu vCenter Server Appliance 7.0.

   

• Wenn Sie die Anzahl der virtuellen Funktionen für ein SR-IOV-Gerät mithilfe des max_vfs-Modulparameters konfigurieren, werden die Änderungen möglicherweise nicht wirksam

  In vSphere 7.0 können Sie die Anzahl der virtuellen Funktionen für ein SR-IOV-Gerät konfigurieren, indem Sie beispielsweise die Virtual Infrastructure Management-API (VIM-API) über den vSphere Client verwenden. Für die Aufgabe ist kein Neustart des ESXi-Hosts erforderlich. Wenn Sie nach der Verwendung der VIM-API-Konfiguration versuchen, die Anzahl der virtuellen SR-IOV-Funktionen mit dem max_vfs-Modulparameter zu konfigurieren, werden die Änderungen möglicherweise nicht wirksam, da sie von der VIM-API-Konfiguration überschrieben werden.

  Problemumgehung: Keine. Um die Anzahl der virtuellen Funktionen für ein SR-IOV-Gerät zu konfigurieren, verwenden Sie jedes Mal dieselbe Methode. Verwenden Sie die VIM-API oder verwenden Sie den max_vfs-Modulparameter und starten Sie den ESXi-Host neu.

• Eine aktualisierte vCenter Server Appliance-Instanz behält nicht alle sekundären Netzwerke (NICs) der Quellinstanz bei.

  Wenn bei einem Haupt-Upgrade die Quellinstanz der vCenter Server Appliance mit mehreren sekundären Netzwerken außer der VCHA NIC konfiguriert wird, behält der vCenter Server der Zielinstanz keine sekundären Netzwerke außer der VCHA NIC bei. Wenn die Quellinstanz mit mehreren NICs konfiguriert ist, die Teil von VDS-Portgruppen sind, wird die Konfiguration der NIC während des Upgrades nicht beibehalten. Konfigurationen für vCenter Server Appliance-Instanzen, die Teil der Standard-Portgruppe sind, werden beibehalten.

  Problemumgehung: Keine. Konfigurieren Sie das sekundäre Netzwerk manuell in der Zielinstanz der vCenter Server Appliance.

• Nach dem Upgrade oder der Migration eines vCenter Server mit einem externen Platform Services Controller verlieren Benutzer, die sich über Active Directory authentifizieren, den Zugriff auf die soeben aktualisierte vCenter Server-Instanz

  Wenn nach dem Upgrade oder der Migration eines vCenter Server mit einem externen Platform Services Controller der soeben aktualisierte vCenter Server nicht einer Active Directory-Domäne beitritt, verlieren Benutzer, die sich mit Active Directory authentifizieren, den Zugriff auf die vCenter Server-Instanz.

  Problemumgehung: Stellen Sie sicher, dass die neue vCenter Server-Instanz einer Active Directory Domäne beigetreten ist. Weitere Informationen hierzu finden Sie im Knowledgebase-Artikel: https://kb.vmware.com/s/article/2118543

• Das Migrieren eines vCenter Server für Windows mit einem externen Platform Services Controller und Verwendung einer Oracle-Datenbank schlägt fehl

  Wenn in der Tabelle der Oracle-Ereignisse und -Aufgaben Nicht-ASCII-Zeichenfolgen vorhanden sind, kann die Migration beim Exportieren von Ereignis- und Aufgabendaten fehlschlagen. Die folgende Fehlermeldung wird angezeigt: UnicodeDecodeError

  Problemumgehung: Keine.

• Nach einem Upgrade des ESXi-Hosts wird bei der Konformitätsprüfung des Hostprofils der Status als nicht konform angezeigt und die Hoststandardisierungsaufgaben schlagen fehl

  Der Status „Nicht konform“ bedeutet, dass eine Inkonsistenz zwischen dem Profil und dem Host besteht.

  Diese Inkonsistenz kann eintreten, weil ESXi 7.0 keine doppelten Beanspruchungsregeln zulässt, das von Ihnen verwendet Profil jedoch doppelte Regeln enthält. Wenn Sie beispielsweise versuchen, das vom Host vor dem Upgrade von ESXi 6.5 oder ESXi 6.7 auf Version 7.0 extrahierte Hostprofil zu verwenden und das Hostprofil doppelte Beanspruchungsregeln von Systemstandardregeln enthält, treten die möglicherweise Probleme auf.

  Problemumgehung:

  1. Entfernen Sie alle doppelten Beanspruchungsregeln von Systemstandardregeln aus dem Hostprofildokument.
  2. Überprüfen Sie den Übereinstimmungsstatus.
  3. Standardisieren Sie den Host.
  4. Wenn die vorherigen Schritte nicht helfen, starten Sie den Host neu.

   

• In der vCenter Server-Verwaltungsschnittstelle wird eine Fehlermeldung angezeigt.

  Nach der Installation oder dem Upgrade auf vCenter Server 7.0 wird beim Navigieren zum Update-Bereich innerhalb der vCenter Server-Verwaltungsschnittstelle die Fehlermeldung „Überprüfen Sie die URL und versuchen Sie es erneut.“ angezeigt. Die Fehlermeldung verhindert nicht, dass Sie die Funktionen im Update-Bereich verwenden, und Sie können alle verfügbaren Updates anzeigen, bereitstellen und installieren.

  Problemumgehung: Keine.

Probleme bei Sicherheitsfunktionen

• Deaktivieren Sie den Service Location Protocol-Dienst (slpd) in ESXi, um mögliche Sicherheitsschwachstellen zu vermeiden

  Bestimmte Dienste in ESXi, die zusätzlich zum Hostbetriebssystem ausgeführt werden, darunter slpd, der CIM-Objekt-Broker, sfcbd und der verwandte openwsmand-Dienst, weisen nachgewiesene Sicherheitsschwachstellen auf. VMware hat alle bekannten Schwachstellen in VMSA-2019-0022 und VMSA-2020-0023 behoben. Die Fixes sind Bestandteil von vSphere 7.0 Update 2. Während sfcbd und openwsmand in ESXi standardmäßig deaktiviert sind, ist slpd standardmäßig aktiviert. Wenn slpd nicht benötigt wird, müssen Sie den Dienst ausschalten, um künftige Sicherheitsschwachstellen nach einem Upgrade zu vermeiden. 

  Problemumgehung: Führen Sie die folgenden PowerCLI-Befehle aus, um den slpd-Dienst auszuschalten:
  $ Get-VMHost | Get-VmHostService | Where-Object {$_.key -eq “slpd”} | Set-VMHostService -policy “off”
$ Get-VMHost | Get-VmHostService | Where-Object {$_.key -eq “slpd”} | Stop-VMHostService -Confirm:$false
  
  Alternativ können Sie den Befehl chkconfig slpd off && /etc/init.d/slpd stop verwenden.
  
  Der openwsmand-Dienst befindet sich nicht in der Liste der ESXi-Dienste. Sie können den Dienststatus mithilfe der folgenden PowerCLI-Befehle überprüfen:
  $esx=(Get-EsxCli -vmhost xx.xx.xx.xx -v2)
$esx.system.process.list.invoke() | where CommandLine -like '*openwsman*' | select commandline

  In der Liste der ESXi-Dienste wird der sfcbd-Dienst als sfcbd-watchdog angezeigt.
  
  Weitere Informationen finden Sie in den VMware-Knowledgebase-Artikeln 76372 und 1025757.

• Eine verschlüsselte virtuelle Maschine kann nicht eingeschaltet werden, wenn der für HA aktivierte vertrauenswürdige Cluster einen nicht bestätigten Host enthält

  Wenn Sie in VMware® vSphere Trust Authority™ HA im vertrauenswürdigen Cluster aktiviert haben und ein oder mehrere Hosts im Cluster nicht bestätigt werden, kann eine verschlüsselte virtuelle Maschine nicht eingeschaltet werden.

  Problemumgehung: Entfernen oder standardisieren Sie alle Hosts des vertrauenswürdigen Clusters, die nicht bestätigt werden konnten.

• Eine verschlüsselte virtuelle Maschine kann nicht eingeschaltet werden, wenn der für DRS aktivierte vertrauenswürdige Cluster einen nicht bestätigten Host enthält

  Wenn Sie in VMware® vSphere Trust Authority™ DRS im vertrauenswürdigen Cluster aktiviert haben und ein oder mehrere Hosts im Cluster nicht bestätigt werden können, versucht DRS möglicherweise, eine verschlüsselte virtuelle Maschine auf einem nicht bestätigten Host im Cluster einzuschalten. Durch diesen Vorgang wird die virtuelle Maschine in einen gesperrten Zustand versetzt.

  Problemumgehung: Entfernen oder standardisieren Sie alle Hosts des vertrauenswürdigen Clusters, die nicht bestätigt werden konnten.

• Das Migrieren oder Klonen von verschlüsselten virtuellen Maschinen über vCenter Server -Instanzen schlägt fehl, wenn dies mit dem vSphere Client versucht wird

  Wenn Sie versuchen, eine verschlüsselte virtuelle Maschine über vCenter Server-Instanzen hinweg mithilfe des vSphere Client zu migrieren oder zu klonen, schlägt der Vorgang mit folgender Fehlermeldung fehl: „Der Vorgang ist im aktuellen Zustand nicht zulässig.“

  Problemumgehung: Sie müssen die vSphere-APIs verwenden, um verschlüsselte virtuelle Maschinen über vCenter Server-Instanzen hinweg zu migrieren oder zu klonen.

Netzwerkprobleme

• Reduzierter Durchsatz bei der Netzwerkleistung auf Intel 82599/X540/X550-Netzwerkkarten

  Die neue Funktion für Warteschlangenpaare, die dem ixgben-Treiber hinzugefügt wurde, um die Netzwerkleistung auf Intel-Netzwerkkarten der Serien 82599EB/X540/X550 zu verbessern, kann den Durchsatz unter einigen Arbeitslasten in vSphere 7.0 im Vergleich zu vSphere 6.7 verringern.

  Problemumgehung: Um dieselbe Netzwerkleistung wie in vSphere 6.7 zu erreichen, können Sie das Warteschlangenpaar mit einem Modulparameter deaktivieren. Um das Warteschlangenpaar zu deaktivieren, führen Sie den folgenden Befehl aus:

  # esxcli system module parameters set -p "QPair=0,0,0,0..." -m ixgben

  Führen Sie nach dem Ausführen des Befehls einen Neustart aus.

• Mindestens ein E/A-Gerät generiert keine Interrupts, wenn die AMD IOMMU verwendet wird

  Wenn die E/A-Geräte auf Ihrem ESXi-Host mehr als insgesamt 512 verschiedene Interrupt-Quellen bereitstellen, wird einigen Quellen fälschlicherweise ein Interrupt Remapping Table Entry (IRTE)-Index in der AMD IOMMU zugewiesen, der größer als der Maximalwert ist. Interrupts von einer solchen Quelle gehen verloren. Das entsprechende E/A-Gerät verhält sich also so, als ob Interrupts deaktiviert wären.

  Problemumgehung: Verwenden Sie den ESXCLI-Befehl esxcli system settings kernel set -s iovDisableIR -v true, um den AMD IOMMU Interrupt-Remapper zu deaktivieren. Starten Sie den ESXi-Host neu, damit der Befehl wirksam wird.

• Wenn Sie automatische Aushandlung auf einem Netzwerkadapter festlegen, schlägt das Gerät möglicherweise fehl

  Wenn Sie in bestimmten Umgebungen die Verbindungsgeschwindigkeit mithilfe des Befehls esxcli network nic set -a -n vmmicx auf automatische Aushandlung für Netzwerkadapter festlegen, schlagen die Geräte möglicherweise fehl und beim Neustart werden die Verbindungen nicht wiederhergestellt. Das Problem betrifft insbesondere eine Kombination aus bestimmten Netzwerkadaptern des Typs Intel X710/X722, einem SFP+-Modul und einem physischen Switch, bei denen eine ausgehandelte Geschwindigkeit bzw. ein Duplexszenario nicht unterstützt wird.

  Problemumgehung: Stellen Sie sicher, dass Sie ein SFP+-Modul der Marke Intel verwenden. Alternativ können Sie ein DAC-Kabel (Direct Attach Copper) verwenden.

• Im 1x100G-Portmodus konfigurierte Netzwerkadapter vom Typ Solarflare x2542 und x2541 erreichen einen Durchsatz von bis zu 70 GBit/s in einer vSphere-Umgebung.

  vSphere 7.0 Update 2 unterstützt Netzwerkadapter vom Typ Solarflare x2542 und x2541, die im 1x100G-Portmodus konfiguriert sind. Unter Umständen kommt es bei den Geräten jedoch zu einer Hardwarebeschränkung, wodurch der tatsächliche Durchsatz in einer vSphere-Umgebung bis zu 70 GBit/s beträgt.

  Problemumgehung: Keine

• VLAN-Datenverkehr kann nach dem Zurücksetzen einer Netzwerkkarte fehlschlagen

  Eine Netzwerkkarte mit der PCI-Geräte-ID 8086:1537 kann nach dem Zurücksetzen möglicherweise keine VLAN-gekennzeichneten Pakete mehr senden und empfangen, z. B. mit dem Befehl vsish -e set /net/pNics/vmnic0/reset 1.

  Problemumgehung: Vermeiden Sie das Zurücksetzen der Netzwerkkarte. Wenn Sie bereits mit dem Problem konfrontiert sind, verwenden Sie die folgenden Befehle zum Wiederherstellen der VLAN-Funktion, z. B. bei vmnic0:
  # esxcli network nic software set --tagging=1 -n vmnic0
# esxcli network nic software set --tagging=0 -n vmnic0

• Jede Änderung der NetQueue-Balancer-Einstellungen führt dazu, dass NetQueue nach dem Neustart eines ESXi-Hosts deaktiviert wird

  Jede Änderung in den Einstellungen des NetQueue-Balancers mithilfe des Befehls esxcli/localcli network nic queue loadbalancer set -n <nicname>--<lb_setting> führt dazu, dass NetQueue (standardmäßig aktiviert) nach dem Neustart eines ESXi-Hosts deaktiviert wird.

  Problemumgehung: Nach einer Änderung in den Einstellungen des NetQueue-Balancers und dem Neustart des Hosts verwenden Sie den Befehl configstorecli config current get -c esx -g network -k nics, um ConfigStore-Daten abzurufen und sicherzustellen, dass /esx/network/nics/net_queue/load_balancer/enable erwartungsgemäß funktioniert.

  Nach dem Ausführen des Befehls wird eine Ausgabe ähnlich der folgenden angezeigt:
  {
"mac": "02:00:0e:6d:14:3e",
"name": "vmnic1",
"net_queue": {
  "load_balancer": {
    "dynamic_pool": true,
      "enable": true
  }
 },
 "virtual_mac": "00:50:56:5a:21:11"
}

  Bei nicht erwartungsgemäßer Ausgabe, wie z. B. "load_balancer": "enable": false", führen Sie folgenden Befehl aus:
  esxcli/localcli network nic queue loadbalancer state set -n <nicname> -e true

• Paravirtuelle RDMA-Netzwerkadapter (PVRDMA) bieten keine Unterstützung für NSX-Netzwerkrichtlinien

  Wenn Sie einen verteilten virtuellen NSX-Port für die Verwendung im PVRDMA-Datenverkehr konfigurieren, entspricht der RDMA-Protokolldatenverkehr über die PVRDMA-Netzwerkadapter nicht den NSX-Netzwerkrichtlinien.

  Problemumgehung: Konfigurieren Sie keine verteilten virtuellen NSX-Ports für die Verwendung im PVRDMA-Datenverkehr.

• Die Wiederherstellung von einem konvergierten vSphere Distributed Switch (VDS) auf NSX-T VDS wird in vSphere 7.0 Update 3 nicht unterstützt

  Eine Wiederherstellung von einem konvergierten VDS, der sowohl vSphere 7- als auch NSX-T 3-Datenverkehr auf demselben VDS unterstützt, auf einen N-VDS für NSX-T-Datenverkehr wird in vSphere 7.0 Update 3 nicht unterstützt.

  Problemumgehung: Keine 

• Wenn Sie den Parameter des „nmlx5“-Netzwerktreibermoduls nicht festlegen, schlagen die Netzwerkkonnektivität oder ESXi-Hosts möglicherweise fehl

  Wenn Sie den Modulparameter supported_num_ports für den nmlx5_core-Treiber auf einem ESXi-Host mit mehreren Netzwerkadaptern der Versionen Mellanox ConnectX-4, Mellanox ConnectX-5 und Mellanox ConnectX-6 nicht festlegen, weist der Treiber möglicherweise nicht genügend Arbeitsspeicher für den Betrieb aller NIC-Ports für den Host zu. Dies kann dazu führen, dass ein Netzwerkverlust, ein ESXi-Hostfehler mit violettem Diagnosebildschirm oder beides auftritt.

  Problemumgehung: Legen Sie den Wert des Moduls supported_num_ports im Netzwerktreiber nmlx5_core auf die Gesamtanzahl der Mellanox ConnectX-4-, Mellanox ConnectX-5- und Mellanox ConnectX-6-Netzwerkadapterports auf dem ESXi-Host fest.

• Bei virtuellen Maschinen mit hohem Durchsatz kann es zu einer Verschlechterung der Netzwerkleistung kommen, wenn Network I/O Control (NetIOC) aktiviert ist

  Bei virtuellen Maschinen, die einen hohen Netzwerkdurchsatz erfordern, kann es beim Upgrade von vSphere 6.7 auf vSphere 7.0 mit aktiviertem NetIOC zu einer Verschlechterung des Durchsatzes kommen.

  Problemumgehung: Passen Sie die Einstellung ethernetx.ctxPerDev an, um mehrere Worlds zu aktivieren.

• IPv6-Datenverkehr fließt nicht durch VMkernel-Ports, die IPsec verwenden

  Wenn Sie VMkernel-Ports von einer Portgruppe zu einer anderen migrieren, fließt der IPv6-Datenverkehr nicht durch VMkernel-Ports, die IPsec verwenden.

  Problemumgehung: Entfernen Sie die IPsec Security Association (SA) vom betroffenen Server und wenden Sie die SA dann erneut an. Informationen zum Festlegen und Entfernen einer IPsec SA finden Sie im Dokument vSphere-Sicherheit.

• Höhere ESX-Netzwerkleistung mit einem Teil der CPU-Auslastung

  Die ESX-Netzwerkleistung kann mit einem Teil der CPU-Auslastung zunehmen.

  Problemumgehung: Entfernen Sie die Netzwerkschnittstelle und fügen Sie sie mit nur 1 rx Übergabewarteschlange hinzu. Beispiel:

  esxcli network ip interface remove --interface-name=vmk1

  esxcli network ip interface add --interface-name=vmk1 --num-rxqueue=1

• Eine VM verliert nach Hinzufügen oder Entfernen im laufenden Betrieb oder Storage vMotion möglicherweise Ethernet-Datenverkehr

  Eine VM empfängt nach Hinzufügen oder Entfernen im laufenden Betrieb oder Storage vMotion möglicherweise keinen Ethernet-Datenverkehr. Dieses Problem betrifft VMs, bei denen für den Uplink der virtuellen Netzwerkkarte SR-IOV aktiviert ist. Die virtuelle Netzwerkkarte PVRDMA weist dieses Problem auf, wenn für den Uplink des virtuellen Netzwerks eine Mellanox RDMA-fähige Netzwerkkarte und RDMA-Namespaces konfiguriert sind.

  Problemumgehung: Sie können die betroffenen Ethernet-Netzwerkkarten der VM im laufenden Betrieb entfernen und wieder hinzufügen, um den Datenverkehr wiederherzustellen. Auf den Linux-Gastbetriebssystemen kann das Problem eventuell auch durch einen Neustart des Netzwerks gelöst werden. Wenn diese Problemumgehungen nicht funktionieren, können Sie die VM neu starten, um die Netzwerkkonnektivität wiederherzustellen.

• Die Änderung der IP-Adresse für eine mit statischer IP-Adresse bereitgestellte VCSA erfordert, dass Sie die DNS-Datensätze im Voraus erstellen

  Mit der Einführung von DDNS funktioniert das Aktualisieren von DNS nur für VCSA, die mit einem mit DHCP konfigurierten Netzwerk bereitgestellt wurden. Beim Ändern der IP-Adresse von vCenter Server über VAMI wird der folgende Fehler angezeigt:

  Die angegebene IP-Adresse wird nicht in den angegebenen Hostnamen aufgelöst.

  Problemumgehung: Es gibt zwei mögliche Problemumgehungen.

  1. Erstellen Sie einen zusätzlichen DNS-Eintrag mit demselben FQDN und der gewünschten IP-Adresse. Melden Sie sich bei der VAMI an und befolgen Sie die Schritte zum Ändern der IP-Adresse.
  2. Melden Sie sich mithilfe von SSH bei der VCSA an. Führen Sie das folgende Skript aus:

     ./opt/vmware/share/vami/vami_config_net

     Verwenden Sie die Option 6, um die IP-Adresse von eth0 zu ändern. Führen Sie nach der Änderung das folgende Skript aus:

     ./opt/likewise/bin/lw-update-dns

     Starten Sie alle Dienste auf der VCSA neu, um die Informationen zur IP-Adresse auf dem DNS-Server zu aktualisieren.

• Es kann einige Sekunden dauern, bis die verteilte virtuelle Portgruppe von NSX (NSX DVPG) nach dem Löschen des entsprechenden logischen Switches in NSX Manager entfernt wird.

  Bei zunehmender Anzahl logischer Switches kann es länger dauern, bis die NSX DVPG in vCenter Server entfernt wird, nachdem der entsprechende logische Switch in NSX Manager gelöscht wurde. In einer Umgebung mit 12000 logischen Switches dauert es ungefähr 10 Sekunden, bis eine NSX DVPG aus vCenter Server gelöscht wird.

  Problemumgehung: Keine.

• Für hostd ist nicht genügend Arbeitsspeicher vorhanden und es schlägt fehl, wenn eine große Anzahl von verteilten virtuellen NSX-Portgruppen erstellt wird.

  In vSphere 7.0 verbrauchen verteilte virtuelle NSX-Portgruppen wesentlich größere Mengen an Arbeitsspeicher als opake Netzwerke. Aus diesem Grund können verteilte virtuelle NSX-Portgruppen mit derselben Menge an Arbeitsspeicher nicht dieselbe Skalierung wie ein opakes Netzwerk unterstützen.

  Problemumgehung: Um die Verwendung von verteilten virtuellen NSX-Portgruppen zu unterstützen, erhöhen Sie die Menge an Arbeitsspeicher in Ihren ESXi-Hosts. Wenn Sie sich vergewissert haben, dass Ihr System über ausreichend Arbeitsspeicher zur Unterstützung Ihrer VMs verfügt, können Sie den Arbeitsspeicher von hostd mit dem folgenden Befehl direkt erhöhen.

  localcli --plugin-dir /usr/lib/vmware/esxcli/int/ sched group setmemconfig --group-path host/vim/vmvisor/hostd --units mb --min 2048 --max 2048

  Beachten Sie, dass dadurch für hostd Arbeitsspeicher verwendet wird, der normalerweise für die VMs Ihrer Umgebung reserviert ist. Dies kann eine Reduzierung der Anzahl der VMs, die Ihr ESXi-Host unterstützen kann, zur Folge haben.

• DRS startet vMotion möglicherweise falsch, wenn die Netzwerkreservierung auf einer VM konfiguriert ist

  Wenn die Netzwerkreservierung auf einer VM konfiguriert ist, wird erwartet, dass DRS die VM nur auf einen Host migriert, der die angegebenen Anforderungen erfüllt. Wenn in einem Cluster mit NSX-Transportknoten einige der Transportknoten der Transportzone über NSX-T Virtual Distributed Switch (N-VDS) und andere über vSphere Distributed Switch (VDS) 7.0 beitreten, kann DRS vMotion möglicherweise nicht korrekt starten. Dieses Problem kann in folgenden Fällen auftreten:

  • Die VM stellt eine Verbindung zu einem logischen NSX-Switch her, der mit einer Netzwerkreservierung konfiguriert ist.
  • Einige Transportknoten treten der Transportzone über N-VDS und andere über VDS 7.0 bei, oder die Transportknoten treten der Transportzone über verschiedene VDS 7.0-Instanzen bei.

  Problemumgehung: Stellen Sie sicher, dass alle Transportknoten der Transportzone über N-VDS oder dieselbe VDS 7.0-Instanz beitreten.

• Beim Hinzufügen einer VMkernel-Netzwerkkarte (vmknic) zu einer NSX-Portgruppe meldet vCenter Server einen Fehler ähnlich dem folgenden: „Das Verbinden des VMkernel-Adapters mit einer NSX-Portgruppe auf einem statusfreien Host ist kein unterstützter Vorgang. Verwenden Sie stattdessen die verteilte Portgruppe.“
  • Für statusfreie ESXi an einem vSphere Distributed Switch (VDS) wird die vmknic in einer NSX-Portgruppe blockiert. Sie müssen stattdessen eine verteilte Portgruppe verwenden.
  • Für statusorientierte ESXi auf VDS wird die vmknic in NSX-Portgruppen unterstützt, aber bei vSAN kann ein Problem auftreten, wenn die vmknic in einer NSX-Portgruppe verwendet.

  Problemumgehung: Verwenden Sie eine verteilte Portgruppe auf demselben VDS.

• Das Aktivieren von SR-IOV über vCenter für QLogic 4x10GE QL41164HFCU CNA schlägt möglicherweise fehl

  Wenn Sie zum Dialogfeld Einstellungen bearbeiten für physische Netzwerkadapter navigieren und versuchen, SR-IOV zu aktivieren, schlägt der Vorgang möglicherweise fehl, wenn QLogic 4x10GE QL41164HFCU CNA verwendet wird. Der Versuch, SR-IOV zu aktivieren, kann zu einem Netzwerkausfall des ESXi-Hosts führen.

  Problemumgehung: Verwenden Sie den folgenden Befehl auf dem ESXi-Host, um SRI-OV zu aktivieren:

  esxcfg-module

• vCenter Server schlägt fehl, wenn die Hosts in einem Cluster, in dem Distributed Resource Scheduler (DRS) verwendet wird, dem NSX-T-Netzwerk über einen anderen Virtual Distributed Switch (VDS) oder eine Kombination aus NSX-T Virtual Distributed Switch (NVDS) und VDS beitreten

  Wenn in vSphere 7.0 das NSX-T-Netzwerk auf dem vSphere VDS mit einem DRS-Cluster verwendet wird und die Hosts der NSX-Transportzone nicht über denselben VDS oder NVDS beitreten, kann dies dazu führen, dass vCenter Server fehlschlägt.

  Problemumgehung: Sorgen Sie dafür, dass die Hosts in einem DRS-Cluster der NSX-Transportzone über denselben VDS oder NVDS beitreten. 

Speicherprobleme

• VMFS-Datenspeicher werden nach dem Entfernen der Festplatte im laufenden Betrieb und dem Hinzufügen zu HPE Gen10-Servern mit SmartPQI Controller im laufenden Betrieb nicht automatisch gemountet

  Wenn SATA-Festplatten auf HPE Gen10-Servern mit SmartPQI-Controllern ohne Erweiterung im laufenden Betrieb entfernt und wieder in einem anderen Festplattenschacht desselben Rechners eingefügt werden, oder wenn mehrere Festplatten im laufenden Betrieb entfernt und in einer anderen Reihenfolge wieder hinzugefügt werden, wird der Festplatte manchmal ein neuer lokaler Name zugewiesen. Der VMFS-Datenspeicher auf dieser Festplatte erscheint als Snapshot und wird nicht automatisch wieder gemountet, da sich der Gerätename geändert hat.

  Problemumgehung: Keine. Der SmartPQI-Controller unterstützt keine ungeordneten Vorgänge zum Entfernen und Einfügen im laufenden Betrieb.

• Die VOMA-Überprüfung der auf NVMe basierenden VMFS-Datenspeichern schlägt fehl

  Die VOMA-Überprüfung wird für NVMe basierende VMFS-Datenspeicher nicht unterstützt und schlägt mit folgendem Fehler fehl:

  ERROR: Failed to reserve device. Function not implemented 

  Beispiel:

  # voma -m vmfs -f check -d /vmfs/devices/disks/: <partition#>
  Running VMFS Checker version 2.1 in check mode
  Initializing LVM metadata, Basic Checks will be done
  
  Checking for filesystem activity
  Performing filesystem liveness check..|Scanning for VMFS-6 host activity (4096 bytes/HB, 1024 HBs).
  ERROR: Failed to reserve device. Function not implemented
  Aborting VMFS volume check
  VOMA failed to check device : General Error

  Problemumgehung: Keine. Wenn Sie die VMFS-Metadaten analysieren möchten, erfassen Sie sie mithilfe der Option -l und geben Sie sie an den VMware Kundensupport weiter. Der Befehl zum Erfassen des Dump lautet:

  voma -l -f dump -d /vmfs/devices/disks/:<partition#> 

• Bei Verwendung der API zum Neukonfigurieren von VMs kann das Anhängen einer verschlüsselten First Class Disk an eine verschlüsselte virtuelle Maschine fehlschlagen

  Wenn eine FCD und eine virtuelle Maschine mit unterschiedlichen Verschlüsselungsschlüsseln verschlüsselt sind, schlägt das Anhängen der verschlüsselten FCD an die verschlüsselte VM mit der vm.Reconfigure-API möglicherweise mit der folgenden Fehlermeldung fehl:

  Festplatte kann nicht entschlüsselt werden. Ungültiger Schlüssel oder ungültiges Kennwort

  Problemumgehung: Verwenden Sie die attachDisk-API anstelle der vm.Reconfigure-API, um eine verschlüsselte FCD an eine verschlüsselte VM anzuhängen.

• Der ESXi-Host reagiert möglicherweise nicht mehr, wenn eine nicht übergeordnete Erweiterung seines übergreifenden VMFS-Datenspeichers in einen Status des dauerhaften Geräteausfalls (PDL) wechselt

  Dieses Problem tritt nicht auf, wenn eine nicht übergeordnete Erweiterung des übergreifenden VMFS-Datenspeichers zusammen mit der übergeordneten Erweiterung fehlschlägt. In diesem Fällen kann auf den gesamten Datenspeicher nicht mehr zugegriffen werden, sodass keine E/A-Vorgänge mehr zulässig sind.

  Im Gegensatz dazu scheint das Taktsignal des Datenspeichers normal zu sein, wenn nur eine nicht übergeordnete Erweiterung fehlschlägt, aber die übergeordnete Erweiterung erreichbar bleibt. Die E/A-Vorgänge zwischen dem Host und dem Datenspeicher werden fortgesetzt. Allerdings schlagen alle E/A-Vorgänge, die von der fehlgeschlagenen nicht übergeordneten Erweiterung abhängen, ebenfalls fehl. Andere E/A-Transaktionen können sich während des Wartens auf das Lösen von E/A-Vorgängen anhäufen und dazu führen, dass der Host nicht mehr reagiert.

  Problemumgehung: Beheben Sie die PDL-Bedingung für die nicht übergeordnete Erweiterung, um dieses Problem zu beheben.

• Der virtuelle NVMe-Controller ist der Standard-Festplattencontroller für Windows 10-Gastbetriebssysteme

  Der virtuelle NVMe-Controller ist der Standard-Festplattencontroller für die folgenden Gastbetriebssysteme bei der Verwendung der Hardwareversion 15 oder höher:

  Windows 10
  Windows Server 2016
  Windows Server 2019

  Einige Funktionen sind möglicherweise nicht verfügbar, wenn ein virtueller NVMe-Controller verwendet wird. Weitere Informationen finden Sie unter https://kb.vmware.com/s/article/2147714

  Hinweis: Einige Clients verwenden die vorherige Standardeinstellung von LSI Logic SAS. Hierzu gehören der ESXi Host Client und PowerCLI.

  Problemumgehung: Wenn Sie Funktionen benötigen, die für Virtual NVMe nicht verfügbar sind, wechseln Sie zu VMware Paravirtual SCSI (PVSCSI) oder LSI Logic SAS. Weitere Informationen zur Verwendung von VMware Paravirtual SCSI (PVSCSI) finden Sie unter https://kb.vmware.com/s/article/1010398

• Nach einem Upgrade des ESXi-Hosts auf vSphere 7.0 kann das Vorhandensein doppelter Core-Beanspruchungsregeln zu unerwartetem Verhalten führen

  Beanspruchungsregeln legen fest, welches Multipathing-Plug-In (NMP, HPP usw.) Pfade zu einem bestimmten Speichergerät besitzt. ESXi 7.0 unterstützt keine doppelten Beanspruchungsregeln. Der ESXi 7.0-Host warnt Sie jedoch nicht, wenn Sie doppelte Regeln zu den vorhandenen Beanspruchungsregeln hinzufügen, die über ein Upgrade von einer Legacy-Version übernommen wurden. Als Folge der Verwendung von doppelten Regeln werden Speichergeräte möglicherweise durch unbeabsichtigte Plug-Ins beansprucht, was zu unerwarteten Ergebnissen führen kann.

  Problemumgehung: Verwenden Sie keine doppelten Core-Beanspruchungsregeln. Bevor Sie eine neue Beanspruchungsregel hinzufügen, löschen Sie alle vorhandenen entsprechenden Beanspruchungsregeln.

• Eine CNS-Abfrage mit festgelegtem Konformitätsstatusfilter kann ungewöhnlich viel Zeit in Anspruch nehmen

  Mit der CNS QueryVolume API können Sie Informationen zu den CNS-Volumes abrufen, wie z. B. den Datenträgerstatus und den Konformitätsstatus. Wenn Sie den Konformitätsstatus einzelner Volumes prüfen, werden die Ergebnisse schnell abgerufen. Wenn Sie jedoch die CNS QueryVolume API aufrufen, um den Konformitätsstatus von Dutzenden oder Hunderten Volumes zu prüfen, wird die Abfrage möglicherweise langsam ausgeführt.

  Problemumgehung: Vermeiden Sie die Verwendung von umfangreichen Abfragen. Wenn Sie den Konformitätsstatus abrufen müssen, fragen Sie jeweils ein Volume ab oder begrenzen Sie die Anzahl der Volumes in der Abfrage-API auf 20 oder weniger. Vermeiden Sie bei der Verwendung der Abfrage die Ausführung anderer CNS-Vorgänge, um eine optimale Leistung zu erhalten.

• Ein VMFS-Datenspeicher, der von einem NVMe over Fabrics-Namespace oder -Gerät unterstützt wird, kann nach der Wiederherstellung von einem APD- oder PDL-Fehler dauerhaft unzugänglich werden

  Wenn ein VMFS-Datenspeicher auf einem ESXi-Host von einem NVMe over Fabrics-Namespace oder -Gerät unterstützt wird, kann der Datenspeicher im Falle eines Fehler vom Typ „keine Pfade verfügbar (APD)“ oder „dauerhafter Geräteausfall (PDL)“ auch nach der Wiederherstellung unzugänglich sein. Sie können weder vom ESXi-Host noch vom vCenter Server-System auf den Datenspeicher zugreifen.

  Problemumgehung: Führen Sie eine erneute Prüfung auf Host- oder Clusterebene durch, um diesen Zustand zu beheben. Weitere Informationen finden Sie unter Durchführen einer erneuten Speicherprüfung.

• Gelöschte CNS-Volumes werden möglicherweise vorübergehend als in der CNS-Benutzeroberfläche vorhanden angezeigt

  Nachdem Sie eine FCD-Festplatte gelöscht haben, die ein CNS-Volume unterstützt, wird das Volume möglicherweise weiterhin in der CNS-Benutzeroberfläche als vorhanden angezeigt. Versuche, das Volume zu löschen, schlagen jedoch fehl. Es wird möglicherweise eine Fehlermeldung ähnlich der folgenden angezeigt:
  Das Objekt oder Element, auf das Bezug genommen wurde, konnte nicht gefunden werden.

  Problemumgehung: Bei der nächsten vollständigen Synchronisierung wird die Inkonsistenz behoben, und die CNS-Benutzeroberfläche wird ordnungsgemäß aktualisiert.

• Versuche, mehrere CNS-Volumes an denselben Pod anzuhängen, können gelegentlich mit einem Fehler fehlschlagen

  Wenn Sie mehrere Volumes gleichzeitig an denselben Pod anhängen, kann der Anhängevorgang gelegentlich denselben Controller-Steckplatz auswählen. Dies führt dazu, dass nur einer der Vorgänge erfolgreich ausgeführt wird, während andere Volume-Einbindungen fehlschlagen.

  Problemumgehung: Nachdem Kubernetes den fehlgeschlagenen Vorgang erneut versucht, wird der Vorgang erfolgreich ausgeführt, wenn ein Controller-Steckplatz auf der Knoten-VM verfügbar ist.

• Während ein CNS-Vorgang fehlschlägt, wird der Aufgabenstatus im vSphere Client unter bestimmten Umständen als erfolgreich angezeigt

  Dies kann auftreten, wenn Sie beispielsweise eine nicht konforme Speicherrichtlinie verwenden, um ein CNS-Volume zu erstellen. Der Vorgang schlägt fehl, während der vSphere Client den Aufgabenstatus als erfolgreich anzeigt.

  Problemumgehung: Wenn der Aufgabenstatus im vSphere Client als erfolgreich angezeigt wird, garantiert dies nicht, dass der CNS-Vorgang erfolgreich war. Um sicherzustellen, dass der Vorgang erfolgreich war, überprüfen Sie dessen Ergebnisse.

• Ein nicht erfolgreicher Löschvorgang für einen dauerhaften CNS-Datenträger führt möglicherweise dazu, dass der Datenträger als nicht gelöscht im vSphere-Datenspeicher verbleibt

  Dieses Problem kann auftreten, wenn die CNS-Delete-API versucht, einen dauerhaften Datenträger zu löschen, der noch an einen Pod angehängt ist. Wenn Sie beispielsweise den Kubernetes-Namespace löschen, in dem der Pod ausgeführt wird. Infolgedessen wird der Datenträger aus CNS gelöscht, und der CNS-Abfragevorgang gibt den Datenträger nicht zurück. Allerdings befindet sich der Datenträger weiterhin im Datenspeicher und kann nicht über die wiederholten CNS-Delete-API-Vorgänge gelöscht werden.

  Problemumgehung: Keine.

Probleme bei vCenter Server und dem vSphere Client

• Anbieter gehen nach einer PNID-Änderung offline

  Wenn Sie die IP-Adresse von vCenter ändern (PNID-Änderung), gehen die registrierten Anbieter offline.

  Problemumgehung: Registrieren Sie die Anbieter erneut.

• Die vCenter-übergreifende Migration einer virtuellen Maschine schlägt mit einem Fehler fehl

  Wenn Sie vCenter vMotion zum Verschieben von Speicher und Host einer VM in eine andere vCenter Server-Instanz verwenden, erhalten Sie möglicherweise den Fehler Der Vorgang ist im aktuellen Status nicht zulässig. 

  Dieser Fehler wird im UI-Assistenten nach dem Schritt für die Hostauswahl und vor dem Schritt für die Datenspeicherauswahl angezeigt, wenn die VM über eine zugewiesene Speicherrichtlinie mit hostbasierten Regeln wie Verschlüsselung oder anderen E/A-Filterregeln verfügt.

  Problemumgehung: Weisen Sie die VM und ihre Festplatten einer Speicherrichtlinie ohne hostbasierte Regeln zu. Möglicherweise müssen Sie die VM entschlüsseln, wenn die Quell-VM verschlüsselt ist. Versuchen Sie dann erneut, die vCenter vMotion-Aktion zu starten.

• Die Informationen zu Speichersensoren auf der Registerkarte „Hardwarestatus“ zeigen falsche Werte auf der Benutzeroberfläche von vCenter, des Hosts und MOB an

  Wenn Sie in der Benutzeroberfläche von vCenter zu Host > Überwachen > Hardwarestatus > Speichersensoren navigieren, werden in den Speicherinformationen entweder falsche oder unbekannte Werte angezeigt. Dasselbe Problem tritt auf der Benutzeroberfläche des Hosts und im MOB-Pfad „runtime.hardwareStatusInfo.storageStatusInfo“ auf.

  Problemumgehung: Keine.

• Die erweiterten Hosteinstellungen der vSphere-UI zeigen den aktuellen Speicherort des Produkt-Lockers als leer mit einem leeren Standardwert an

  Die erweiterten Hosteinstellungen der vSphere-UI zeigen den aktuellen Speicherort des Produkt-Lockers als leer mit einem leeren Standardwert an. Dies ist inkonsistent, da der aktuelle Produktspeicherort symlink erstellt und gültig ist. Dies kann den Benutzer verwirren. Der Standardwert kann nicht über die Benutzeroberfläche korrigiert werden.

  Problemumgehung: Der Benutzer kann den esxcli-Befehl auf dem Host verwenden, um den aktuellen Speicherort des Produkt-Lockers wie folgt zu korrigieren.

  1. Entfernen Sie die vorhandene Einstellung für den Speicherort des Produkt-Lockers mit: "esxcli system settings advanced remove -o ProductLockerLocation"

  2. Fügen Sie die Einstellung für den Speicherort des Produkt-Lockers erneut mit dem entsprechenden Standardwert hinzu:

        2.a.  Wenn es sich bei dem ESXi um eine vollständige Installation handelt, lautet der Standardwert "/locker/packages/vmtoolsRepo" export PRODUCT_LOCKER_DEFAULT="/locker/packages/vmtoolsRepo"

        2.b. Wenn der ESXi eine PXEboot-Konfiguration wie „autodeploy“ aufweist, lautet der Standardwert: "/vmtoolsRepo" export PRODUCT_LOCKER_DEFAULT="/vmtoolsRepo"

        Führen Sie den folgenden Befehl aus, um den Speicherort automatisch zu ermitteln: export PRODUCT_LOCKER_DEFAULT=`readlink /productLocker`

        Fügen Sie die Einstellung hinzu: esxcli system settings advanced add -d "Path to VMware Tools repository" -o ProductLockerLocation -t string -s $PRODUCT_LOCKER_DEFAULT

  Sie können alle oben aufgeführten Schritte in Schritt 2 kombinieren, indem Sie folgenden einzelnen Befehl ausführen:

  esxcli system settings advanced add -d "Path to VMware Tools repository" -o ProductLockerLocation -t string -s `readlink /productLocker`

• Verknüpfte vCenter Server-Instanzen mit Software-Defined Data Center (SDDC) werden im lokalen vSphere Client angezeigt, wenn ein vCenter Cloud Gateway mit dem SDDC verknüpft ist.

  Wenn ein vCenter Cloud Gateway in derselben Umgebung wie ein lokaler vCenter Server bereitgestellt und mit einem SDDC verknüpft ist, wird der SDDC-vCenter Server im lokalen vSphere Client angezeigt. Dies ist ein unerwartetes Verhalten, und der verknüpfte SDDC-vCenter Server sollte ignoriert werden. Alle Vorgänge, die den verknüpften SDDC-vCenter Server betreffen, sollten auf dem vSphere Client ausgeführt werden, der im vCenter Cloud Gateway ausgeführt wird.

  Problemumgehung: Keine.

VM-Verwaltungsprobleme

• UEFI HTTP-Startvorgang virtueller Maschinen auf ESXi-Hosts mit Versionen vor 7.0 Update 2 schlägt fehl

  Der UEFI HTTP-Startvorgang virtueller Maschinen wird nur auf ESXi 7.0 Update 2-Hosts und höher und VMs mit Hardwareversion 19 oder höher unterstützt.

  Problemumgehung: Verwenden Sie den UEFI HTTP-Startvorgang nur auf virtuellen Maschinen mit Hardwareversion 19 oder höher. Durch Verwendung der Hardwareversion 19 wird sichergestellt, dass die virtuellen Maschinen nur auf Hosts mit ESXi Version 7.0 Update 2 oder höher platziert werden.

• VM-Snapshot-Vorgänge schlagen in vSphere Virtual Volumes-Datenspeichern unter Purity-Version 5.3.10 fehl

  VM-Snapshot-Vorgänge schlagen in vSphere Virtual Volumes-Datenspeichern unter Purity-Version 5.3.10 mit einem Fehler wie Beim Speichern des Snapshots ist ein Fehler aufgetreten: Am VVol-Ziel ist ein anbieterspezifischer Fehler aufgetreten fehl. Das Problem ist spezifisch für Purity-Version 5.3.10.

  Problemumgehung: Führen Sie ein Upgrade auf Purity-Version 6.1.7 durch oder folgen Sie den Empfehlungen des Anbieters. 

• Der Abschnitt „postcustomization“ des Anpassungsskripts wird vor der Gastanpassung ausgeführt

  Wenn Sie das Gastanpassungsskript für ein Linux-Gastbetriebssystem ausführen, wird der Abschnitt precustomization des in der Anpassungsspezifikation definierten Anpassungsskripts vor der Gastanpassung ausgeführt, und anschließend wird der Abschnitt postcustomization ausgeführt. Wenn Sie im Gastbetriebssystem einer virtuellen Maschine die Option „Cloud-Init“ aktivieren, wird der Abschnitt postcustomization aufgrund eines bekannten Problems in Cloud-Init vor der Anpassung ausgeführt.

  Problemumgehung: Deaktivieren Sie Cloud-Init und verwenden Sie die Standard-Gastanpassung. 

• Gruppenmigrationsvorgänge in vSphere vMotion, Storage vMotion und vMotion ohne gemeinsam genutzten Speicher schlagen mit einem Fehler fehl

  Wenn Sie Gruppenmigrationsvorgänge auf VMs mit mehreren Festplatten und Snapshots mit mehreren Ebene durchführen, schlagen die Vorgänge möglicherweise mit folgendem Fehler fehl: com.vmware.vc.GenericVmConfigFault Fehler beim Warten auf Daten Fehler 195887167. Verbindung von Remotehost geschlossen, möglicherweise aufgrund einer Zeitüberschreitung.

  Problemumgehung: Wiederholen Sie den Migrationsvorgang auf den fehlgeschlagenen VMs einzeln.

• Das Bereitstellen einer OVF- oder OVA-Vorlage über eine URL schlägt mit dem Fehler „403 – Verboten“ fehl

  Die URLs, die einen HTTP-Abfrageparameter enthalten, werden nicht unterstützt. Beispiele sind http://webaddress.com?file=abc.ovf oder die vorab signierten Amazon S3-URLs.

  Problemumgehung: Laden Sie die Dateien herunter und stellen Sie sie von Ihrem lokalen Dateisystem bereit.

• Die dritte Ebene verschachtelter Objekte in einem VM-Ordner ist nicht sichtbar

  Führen Sie die folgenden Schritte aus:

  1. Navigieren Sie zu einem Datencenter und erstellen Sie einen VM-Ordner.
  2. Erstellen Sie im VM-Ordner einen verschachtelten VM-Ordner.
  3. Erstellen Sie im zweiten Ordner einen weiteren verschachtelten VM-Ordner, eine weitere verschachtelte virtuelle Maschine, vApp oder VM-Vorlage.

  Dies führt dazu, dass Sie in der Bestandslistenstruktur für VMs und Vorlagen die Objekte im dritten verschachtelten Ordner nicht sehen können.

  Problemumgehung: Um die Objekte im dritten verschachtelten Ordner anzeigen zu können, navigieren Sie zum zweiten verschachtelten Ordner und wählen Sie die Registerkarte „VMs“ aus.

vSphere HA- und Fault Tolerance-Probleme

• VMs in einem Cluster sind nach dem Wiederherstellen des Speicherzugriffs, wie z. B. nach einem clusterweiten APD, möglicherweise verwaist.

  Einige VMs befinden sich möglicherweise nach der Wiederherstellung aus dem clusterweiten APD im verwaisten Zustand, selbst wenn HA und VMCP auf dem Cluster aktiviert sind.

  Dieses Problem tritt möglicherweise auf, wenn die folgenden Bedingungen gleichzeitig eintreten:

  • Für alle Hosts im Cluster tritt APD ein, und sie werden erst wieder wiederhergestellt, wenn die VMCP-Zeitüberschreitung erreicht ist.
  • Der primäre HA-Agent initiiert ein Failover aufgrund von APD auf einem Host.
  • Das Einschalten der API beim HA-Failover schlägt aufgrund eines der folgenden Fehler fehl:
    • APD über den gleichen Host hinweg
    • Kaskadierender APD über den gesamten Cluster hinweg
    • Speicherprobleme
    • Nichtverfügbarkeit von Ressourcen
  • Die Aufhebung der FDM-Registrierung und VCs-Steal-VM-Logik können während eines Fensters initiiert werden, in dem FDM die Registrierung der fehlgeschlagenen VM nicht aufgehoben hat und die VC-Hostsynchronisierung antwortet, dass mehrere Hosts die gleiche VM melden. Sowohl FDM als auch VC heben die Registrierung der verschiedenen registrierten Kopien derselben VM von verschiedenen Hosts auf, wodurch die VM verwaist wird.

   

  Problemumgehung: Sie müssen die Registrierung der verwaisten VMs im Cluster nach der Wiederherstellung aus APD aufheben und sie erneut registrieren.

  Wenn Sie die verwaisten VMs nicht manuell neu registrieren, versucht HA das Failover der verwaisten VMs; dies kann jedoch zwischen 5 und 10 Stunden dauern, je nachdem, wann APD wiederhergestellt wird.

  Die Gesamtfunktionalität des Clusters ist in diesen Fällen nicht betroffen, und HA schützt die VMs weiterhin. Dies ist eine Anomalie in der Anzeige in VC für die Dauer des Problems.

Probleme bei vSphere Lifecycle Manager

• Sie können kein NSX-T auf einem Cluster aktivieren, der bereits für die Verwaltung von Image-Einrichtung und -Updates auf allen Hosts zusammen aktiviert ist

  NSX-T ist nicht mit den Funktionen des vSphere Lifecycle Manager für die Image-Verwaltung kompatibel. Wenn Sie einen Cluster für Image-Einrichtung und -Updates auf allen Hosts im Cluster zusammen aktivieren, können Sie NSX-T auf diesem Cluster nicht aktivieren. Sie können jedoch NSX Edges für diesen Cluster bereitstellen.

  Problemumgehung: Verschieben Sie die Hosts in einen neuen Cluster, den Sie mit Baselines verwalten können, und aktivieren Sie NSX-T auf diesem neuen Cluster.

• vSphere Lifecycle Manager und vSAN-Dateidienste können auf einem vSAN-Cluster in vSphere 7.0 nicht gleichzeitig aktiviert werden

  Wenn vSphere Lifecycle Manager auf einem Cluster aktiviert ist, können vSAN-Dateidienste nicht auf demselben Cluster aktiviert werden und umgekehrt. Um vSphere Lifecycle Manager auf einem Cluster zu aktivieren, auf dem vSAN-Dateidienste bereits aktiviert sind, deaktivieren Sie zunächst vSAN-Dateidienste und wiederholen Sie den Vorgang. Beachten Sie, dass bei einem Übergang zu einem Cluster, der von einem einzelnen Image verwaltet wird, vSphere Lifecycle Manager auf diesem Cluster nicht deaktiviert werden kann.

  Problemumgehung: Keine.

• Wenn ein Hardware-Support-Manager nicht verfügbar ist, ist vSphere High Availability (HA) beeinträchtigt

  Wenn ein Hardware-Support-Manager nicht für einen Cluster verfügbar ist, den Sie mit einem einzelnen Image verwalten, in dem ein Add-On für Firmware und Treiber ausgewählt und vSphere HA aktiviert ist, ist die vSphere HA-Funktionalität beeinträchtigt. Es können folgende Fehler auftreten.

  • Das Konfigurieren von vSphere HA auf einem Cluster schlägt fehl.
  • Fehler beim Konfigurieren des vSphere HA-Agenten auf einem Host: Beim Anwenden von HA-VIBs auf dem Cluster ist ein Fehler aufgetreten.
  • Das Standardisieren von vSphere HA schlägt fehl: Ein allgemeiner Systemfehler ist aufgetreten: Abrufen der Zuordnung der effektiven Komponenten fehlgeschlagen.
  • Deaktivieren von vSphere HA schlägt fehl: Aufgabe Lösung löschen ist fehlgeschlagen. Ein allgemeiner Systemfehler ist aufgetreten: Hardware-Support-Paket wurde in Depot oder Hardware-Support-Manager nicht gefunden.

   

  Problemumgehung:

  • Wenn der Hardware-Support-Manager vorübergehend nicht verfügbar ist, führen Sie die folgenden Schritte aus.
  1. Verbinden Sie den Hardware-Support-Manager erneut mit vCenter Server.
  2. Wählen Sie im Menü „Hosts und Cluster“ einen Cluster aus.
  3. Wählen Sie die Registerkarte „Konfigurieren“ aus.
  4. Klicken Sie unter „Dienste“ auf „vSphere-Verfügbarkeit“.
  5. Aktivieren Sie vSphere HA erneut.
  • Wenn der Hardware-Support-Manager dauerhaft nicht verfügbar ist, führen Sie die folgenden Schritte aus.
  1. Entfernen Sie den Hardware-Support-Manager und das Hardware-Support-Paket aus der Image-Spezifikation.
  2. Aktivieren Sie vSphere HA erneut.
  3. Wählen Sie im Menü „Hosts und Cluster“ einen Cluster aus.
  4. Wählen Sie die Registerkarte „Updates“ aus.
  5. Klicken Sie auf „Bearbeiten“.
  6. Entfernen Sie das Add-On für Firmware und Treiber und klicken Sie auf „Speichern“.
  7. Wählen Sie die Registerkarte „Konfigurieren“ aus.
  8. Klicken Sie unter „Dienste“ auf „vSphere-Verfügbarkeit“.
  9. Aktivieren Sie vSphere HA erneut.

   

• I/OFilter wird nach einem Standardisierungsprozess in vSphere Lifecycle Manager nicht aus einem Cluster entfernt

  Das Entfernen von I/OFilter aus einem Cluster durch Standardisieren des Clusters in vSphere Lifecycle Manager schlägt mit der folgenden Fehlermeldung fehl: iofilter XXX already exists. Der E/A-Filter bleibt als installiert aufgelistet.

  Problemumgehung:

  1. Rufen Sie die IOFilter-API UninstallIoFilter_Task aus dem verwalteten Objekt von vCenter Server (IoFilterManager) auf.
  2. Standardisieren Sie den Cluster in vSphere Lifecycle Manager.
  3. Rufen Sie die IOFilter-API ResolveInstallationErrorsOnCluster_Task aus dem verwalteten Objekt von vCenter Server (IoFilterManager) auf, um die Datenbank zu aktualisieren.

   

• Beim Standardisieren eines für vSphere HA aktivierten Clusters in vSphere Lifecycle Manager führt das Hinzufügen von Hosts zu einem vSphere HA-Fehlerzustand

  Das Hinzufügen eines oder mehrerer ESXi-Hosts während eines Standardisierungsprozesses eines Clusters mit aktiviertem vSphere HA führt zu folgender Fehlermeldung: Beim Anwenden von HA-VIBs auf dem Cluster ist ein Fehler aufgetreten.

  Problemumgehung: Wenn der Cluster-Standardisierungsvorgang abgeschlossen ist, führen Sie eine der folgenden Aufgaben aus.

  • Klicken Sie mit der rechten Maustaste auf den ausgefallenen ESXi-Host und wählen Sie Für vSphere HA neu konfigurieren aus.
  • Deaktivieren und Sie vSphere HA für den Cluster und aktivieren Sie es erneut.

   

• Beim Standardisieren eines für vSphere HA aktivierten Clusters in vSphere Lifecycle Manager verursacht die Deaktivierung und erneute Aktivierung von vSphere HA einen vSphere HA-Fehlerzustand

  Das Deaktivieren und erneute Aktivieren von vSphere HA während des Standardisierungsprozesses eines Clusters kann zum Fehlschlagen des Standardisierungsprozesses führen, weil vSphere HA-Integritätsprüfungen melden, dass auf Hosts keine vSphere HA-VIBs installiert sind. Es kann eine Fehlermeldung ähnlich der folgenden angezeigt werden: Fehler beim Festlegen der gewünschten Image-Spezifikation für Cluster.

  Problemumgehung: Wenn der Cluster-Standardisierungsvorgang abgeschlossen ist, deaktivieren Sie vSphere HA für den Cluster und aktivieren Sie es erneut.

• Die Prüfung auf empfohlene Images in vSphere Lifecycle Manager hat in großen Clustern eine langsame Leistung

  In großen Clustern mit mehr als 16 Hosts kann die Aufgabe zur Empfehlungsgenerierung mehr als eine Stunde dauern oder zu hängen scheinen. Die Fertigstellungszeit für die Empfehlungsaufgabe hängt von der Anzahl der auf jedem Host konfigurierten Geräte und der Anzahl der geeigneten Images aus dem Depot ab, die vSphere Lifecycle Manager verarbeiten muss, bevor ein gültiges empfohlenes Image erhalten wird.

  Problemumgehung: Keine.

• Die Prüfung auf Hardwarekompatibilität in vSphere Lifecycle Manager hat in großen Clustern eine langsame Leistung

  In großen Clustern mit mehr als 16 Hosts kann es bis zu 30 Minuten dauern, bis die Aufgabe zur Erstellung des Validierungsberichts abgeschlossen ist, oder sie scheint zu hängen. Die Fertigstellungszeit hängt von der Anzahl der auf jedem Host konfigurierten Geräte und der Anzahl der im Cluster konfigurierten Hosts ab.

  Problemumgehung: Keine

• Unvollständige Fehlermeldungen in nicht englischen Sprachen werden beim Standardisieren eines Clusters in vSphere Lifecycle Manager angezeigt

  In der Benutzeroberfläche von vCenter Server können unvollständige Fehlermeldungen für lokalisierte Sprachen vorkommen. Die Meldungen werden angezeigt, nachdem ein Cluster-Standardisierungsprozess in vSphere Lifecycle Manager fehlgeschlagen ist. So kann z. B. die folgende Fehlermeldung auftreten.
  
  Die Fehlermeldung in englischer Sprache: Virtual machine 'VMC on DELL EMC -FileServer' that runs on cluster 'Cluster-1' reported an issue which prevents entering maintenance mode: Unable to access the virtual machine configuration: Unable to access file[local-0] VMC on Dell EMC - FileServer/VMC on Dell EMC - FileServer.vmx
  
  Die Fehlermeldung in französischer Sprache: La VM « VMC on DELL EMC -FileServer », située sur le cluster « {Cluster-1} », a signalé un problème empêchant le passage en mode de maintenance : Unable to access the virtual machine configuration: Unable to access file[local-0] VMC on Dell EMC - FileServer/VMC on Dell EMC - FileServer.vmx

  Problemumgehung: Keine.

• Beim Importieren eines Images ohne Anbieter-Add-On, Komponenten oder Firmware- und Treiber-Add-On in einen Cluster, dessen Image derartige Elemente enthält, werden die Image-Elemente des vorhandenen Images nicht entfernt

  Nur das ESXi-Basisimage wird durch das importierte Image ersetzt.

  Problemumgehung: Nachdem der Importvorgang abgeschlossen ist, bearbeiten Sie das Image und entfernen Sie ggf. das Anbieter-Add-On, die Komponenten und das Firmware- und Treiber-Add-On.

• Wenn Sie einen Cluster, der Baselines verwendet, in einen Cluster konvertieren, der ein einziges Image verwendet, wird eine Warnung angezeigt, dass vSphere HA-VIBs entfernt werden.

  Das Konvertieren eines für vSphere HA aktivierten Clusters, der Baselines verwendet, in einen Cluster, der ein einziges Image verwendet, kann dazu führen, dass eine Warnmeldung zur Entfernung einer vmware-fdm-Komponente angezeigt wird.

  Problemumgehung: Diese Meldung kann ignoriert werden. Der Konvertierungsprozess installiert die vmware-fdm-Komponente.

• Wenn vSphere Update Manager für das Herunterladen von Patch-Aktualisierungen über einen Proxy-Server aus dem Internet konfiguriert ist, schlägt nach dem Upgrade auf vSphere 7.0, das Update Manager in vSphere Lifecycle Manager konvertiert, möglicherweise das Herunterladen von Patches aus dem VMware-Patch-Repository fehl

  In früheren Versionen von vCenter Server konnten Sie unabhängige Proxy-Einstellungen für vCenter Server und vSphere Update Manager konfigurieren. Nach einem Upgrade auf vSphere 7.0 wird der vSphere Update Manager-Dienst Teil des vSphere Lifecycle Manager-Dienstes. Für den vSphere Lifecycle Manager-Dienst werden die Proxy-Einstellungen über die Einstellungen der vCenter Server Appliance konfiguriert. Wenn Sie Update Manager konfiguriert haben, um Patch-Aktualisierungen über einen Proxy-Server aus dem Internet herunterzuladen, aber die vCenter Server Appliance keine Konfiguration für die Proxy-Einstellungen hatte, kann der vSphere Lifecycle Manager nach einem vCenter Server-Upgrade auf Version 7.0 keine Verbindung zum VMware-Depot her herstellen und keine Patches oder Updates herunterladen.

  Problemumgehung: Melden Sie sich bei der vCenter Server Appliance-Verwaltungsschnittstelle https://vcenter-server-appliance-FQDN-or-IP-address:5480 an, um die Proxy-Einstellungen für die vCenter Server Appliance zu konfigurieren, und aktivieren Sie vSphere Lifecycle Manager zur Verwendung des Proxys.

Sonstige Probleme

• Beim Anwenden eines Hostprofils mit Version 6.5 auf einen ESXi-Host mit Version 7.0 schlägt die Konformitätsprüfung fehl

  Das Anwenden eines Hostprofils mit der Version 6.5 auf einen ESXi-Host mit Version 7.0 führt dazu, dass das Profil der Core-Dump-Datei als nicht konform mit dem Host gemeldet wird.

  Problemumgehung: Es gibt zwei mögliche Problemumgehungen.

  1. Wenn Sie ein Hostprofil mit Version 6.5 erstellen, legen Sie eine erweiterte Konfigurationsoption „VMkernel.Boot.autoCreateDumpFile“ auf dem ESXi-Host als „false“ fest.
  2. Wenn Sie ein vorhandenes Hostprofil mit Version 6.5 anwenden, fügen Sie eine erweiterte Konfigurationsoption „VMkernel.Boot.autoCreateDumpFile“ zum Hostprofil hinzu, konfigurieren Sie die Option für eine feste Richtlinie und legen Sie den Wert auf „false“ fest.

   

• Für native Mellanox ConnectX-4- oder ConnectX-5-ESXi-Treiber kann der Durchsatz vermindert sein, wenn die Funktion Dynamic Receive Side Scaling (DYN_RSS) oder Generic RSS (GEN_RSS) aktiviert ist

  Native Mellanox ConnectX-4- oder ConnectX-5-ESXi-Treiber weisen möglicherweise weniger als 5 Prozent Durchsatzverringerung auf, wenn DYN_RSS und GEN_RSS aktiviert sind, was normale Arbeitslasten wahrscheinlich nicht beeinträchtigt.

  Problemumgehung: Sie können DYN_RSS und GEN_RSS mit den folgenden Befehlen deaktivieren:

  # esxcli system module parameters set -m nmlx5_core -p "DYN_RSS=0 GEN_RSS=0"

  # reboot

• RDMA-Datenverkehr zwischen zwei VMs auf demselben Host schlägt in einer PVRDMA-Umgebung möglicherweise fehl

  In einer vSphere 7.0-Implementierung einer PVRDMA-Umgebung übergeben VMs den Datenverkehr über die HCA für die lokale Kommunikation, sofern eine HCA vorhanden ist. Das Loopback des RDMA-Datenverkehrs funktioniert jedoch auf dem qedrntv-Treiber nicht.  Beispielsweise können RDMA-Warteschlangenpaare, die auf VMs ausgeführt werden und unter demselben Uplink-Port konfiguriert sind, nicht miteinander kommunizieren.

  In vSphere 6.7 und früher wurde HCA für den lokalen RDMA-Datenverkehr verwendet, wenn SRQ aktiviert war. vSphere 7.0 verwendet HCA-Loopback mit VMs mithilfe von Versionen von PVRDMA, bei denen SRQ mit mindestens HW v14 mit RoCE v2 aktiviert ist.

  Die aktuelle Version der Marvell FastLinQ-Adapter-Firmware unterstützt den Loopback-Datenverkehr zwischen QPs desselben PF oder Ports nicht.

  Problemumgehung: Die erforderliche Unterstützung wird in dem für vSphere 7.0 zertifizierten, sofort einsatzbereiten Treiber hinzugefügt. Wenn Sie den Inbox-qedrntv-Treiber verwenden, müssen Sie eine 3-Host-Konfiguration verwenden und VMs auf den dritten Host migrieren.

• QP- Einschränkungen für Unreliable Datagramm-Datenverkehr im qedrntv-Treiber

  Es gibt Einschränkungen für den Marvell FastLinQ qedrntv RoCE-Treiber und Unreliable Datagram (UD)-Datenverkehr. UD-Anwendungen mit Massendatenverkehr können mit dem qedrntv-Treiber fehlschlagen. Darüber hinaus können UD-QPs nur mit DMA Memory Regions (MR) arbeiten. Physische MRs oder FRMR werden nicht unterstützt. Anwendungen, die versuchen, physische MR oder FRMR zusammen mit UD-QP zu verwenden, können den Datenverkehr bei Verwendung mit dem qedrntv-Treiber nicht weitergeben. Bekannte Beispiele für solche Testanwendungen sind ibv_ud_pingpong und ib_send_bw.

  Standardmäßige RoCE- und RoCEv2-Anwendungsbeispiele in einer VMware ESXi-Umgebung wie iSER, NVMe-oF (RoCE) und PVRDMA sind von diesem Problem nicht betroffen. Anwendungsbeispiele für den UD-Datenverkehr sind begrenzt. und dieses Problem wirkt sich auf eine kleine Reihe von Anwendungen aus, die UD-Massendatenverkehr benötigen.

  Marvell FastLinQ-Hardware unterstützt die Auslagerung von RDMA UD-Datenverkehr nicht. Um die Anforderung von VMware PVRDMA zur Unterstützung von GSI QP zu erfüllen, wurde dem qedrntv-Treiber eine eingeschränkte Softwareimplementierung der UD QP-Unterstützung hinzugefügt. Das Ziel der Implementierung besteht in der Bereitstellung von Unterstützung für die GSI-Kommunikation des Steuerpfads. Es handelt sich nicht um eine vollständige Implementierung von UD QP zur Unterstützung von Massendatenverkehr und erweiterten Funktionen.

  Da die UD-Unterstützung in der Software implementiert wird, hält die Implementierung möglicherweise hohem Datenverkehr nicht stand, und Pakete können verworfen werden. Dies kann zu Fehlern bei UD-Massendatenverkehr führen.

  Problemumgehung: Der UD QP-Massendatenverkehr wird mit dem qedrntv-Treiber nicht unterstützt, und es gibt zurzeit keine Problemumgehung. VMware ESXi RDMA (RoCE)-Anwendungsfälle wie iSER, NVMe, RDMA und PVRDMA sind von diesem Problem nicht betroffen.

• Mit QLogic 578xx-Netzwerkkarte ausgestattete Server schlagen möglicherweise fehl, wenn häufig Verbindungen mit iSCSI LUNs hergestellt oder getrennt werden

  Wenn Sie häufig innerhalb kurzer Zeit eine iSCSI-Verbindung der QLogic 578xx-Netzwerkkarte herstellen oder trennen, kann der Server aufgrund eines Problems mit dem qfle3-Treiber ausfallen. Dies wird durch einen bekannten Fehler in der Geräte-Firmware verursacht.

  Problemumgehung: Keine.

• ESXi kann während des Treiberentlade- oder Controller-Trennvorgangs in einer Broadcom NVMe over FC-Umgebung ausfallen

  In einer Broadcom NVMe over FC-Umgebung fällt ESXi möglicherweise während des Treiberentlade- oder Controller-Trennungsvorgangs fehl, und eine Fehlermeldung wie die Folgende wird angezeigt: @BlueScreen: #PF Exception 14 in world 2098707:vmknvmeGener IP 0x4200225021cc addr 0x19

  Problemumgehung: Keine.

• ESXi zeigt auf einigen Dell-Servern keine OEM-Firmware-Versionsnummer von i350/X550-Netzwerkkarten an

  Der Inbox-ixgben-Treiber erkennt nur die Firmware-Datenversion oder die Signatur für i350-/X550-Netzwerkkarten. Auf einigen Dell-Servern ist die OEM-Firmware-Versionsnummer in die OEM-Paketversion-Region programmiert, und der Inbox-ixgben-Treiber liest diese Information nicht. Es wird nur die 8-stellige Firmware-Signatur angezeigt.

  Problemumgehung: Um die OEM-Firmware-Versionsnummer anzuzeigen, installieren Sie die asynchrone ixgben-Treiberversion 1.7.15 oder höher.

• X710- oder XL710-Netzwerkkarten schlagen möglicherweise in ESXi fehl

  Wenn Sie bestimmte zerstörerische Vorgänge für X710- oder XL710-Netzwerkkarten initiieren, wie z. B. das Zurücksetzen der Netzwerkkarte oder die Bearbeitung der internen Gerätestruktur des VMkernel, kann die Hardware der Netzwerkkarte Daten aus einem Nichtpaket-Arbeitsspeicher lesen.

  Problemumgehung: Setzen Sie die Netzwerkkarte nicht zurück bzw. bearbeiten Sie den internen Gerätezustand des VMkernel nicht.

• NVMe-oF garantiert nach dem Neustart des Systems keinen dauerhaften VMHBA-Namen

  NVMe-oF ist eine neue Funktion in vSphere 7.0. Wenn Ihr Server über eine USB-Speicherinstallation verfügt, die vmhba30+ verwendet und auch eine NVMe over RDMA-Konfiguration aufweist, kann sich der VMHBA-Name nach einem Neustart des Systems ändern. Dies liegt daran, dass sich die Zuweisung des VMHBA-Namens für NVMe over RDMA von dem Verfahren für PCIe-Geräte unterscheidet. ESXi garantiert keine Persistenz.

  Problemumgehung: Keine.

• Die Sicherung schlägt fehl, wenn die vCenter-Datenbankgröße 300 GB oder mehr beträgt

  Wenn die vCenter-Datenbankgröße 300 GB oder mehr beträgt, schlägt die dateibasierte Sicherung mit einer Zeitüberschreitung fehl. Die folgende Fehlermeldung wird angezeigt: Zeitüberschreitung! Der Vorgang konnte nicht innerhalb von 72000 Sekunden abgeschlossen werden

  Problemumgehung: Keine.

• Eine Wiederherstellung von vCenter Server 7.0, der von vCenter Server 6.x mit externem Platform Services Controller auf vCenter Server 7.0 aktualisiert wurde, schlägt möglicherweise fehl

  Wenn Sie einen vCenter Server 7.0 wiederherstellen, der mit dem externen Platform Services Controller von vCenter Server 6.x auf 7.0 aktualisiert wurde, schlägt die Wiederherstellung möglicherweise fehl und die folgende Fehlermeldung wird angezeigt: Speicherliste der Appliance konnte nicht abgerufen werden

  Problemumgehung: Erhöhen Sie in der ersten Phase des Wiederherstellungsvorgangs die Speicherebene des vCenter Server 7.0. Wenn beispielsweise der eingerichtete Speichertyp für den externen Platform Services Controller für vCenter Server 6.7 „small“ ist, wählen Sie für den Wiederherstellungsvorgang den Speichertyp „large“ aus.

• Der Konfigurationsparameter für aktivierte SSL-Protokolle wird während eines Hostprofil-Standardisierungsprozesses nicht konfiguriert

  Der Konfigurationsparameter Aktivierte SSL-Zertifikate wird während der Standardisierung des Hostprofils nicht konfiguriert, und nur das Systemstandardprotokoll tlsv1.2 wird aktiviert. Dieses Verhalten wird für ein Hostprofil mit Version 7.0 und früher in einer vCenter Server 7.0-Umgebung beobachtet.

  Problemumgehung: Um TLSV 1.0- oder TLSV 1.1-SSL-Protokolle für SFCB zu aktivieren, melden Sie sich über SSH bei einem ESXi-Host an und führen Sie den folgenden ESXCLI-Befehl aus: esxcli system wbem -P <protocol_name>

• Die Sperrmoduseinstellungen können nicht mithilfe von Hostprofilen konfiguriert werden

  Der Sperrmodus kann nicht mithilfe eines Sicherheitshostprofils konfiguriert werden und kann nicht gleichzeitig auf mehrere ESXi-Hosts angewendet werden. Sie müssen jeden Host manuell konfigurieren.  

  Problemumgehung: In vCenter Server 7.0 können Sie den Sperrmodus konfigurieren und die Sperrmodusausnahme-Benutzerliste mithilfe eines Sicherheitshostprofils verwalten.

• Wenn ein Hostprofil auf einen Cluster angewendet wird, fehlen Enhanced vMotion Compatibility (EVC)-Einstellungen auf den ESXi-Hosts

  Einige Einstellungen in der VMware-Konfigurationsdatei /etc/vmware/config werden nicht von Hostprofilen verwaltet und werden blockiert, wenn die Konfigurationsdatei geändert wird. Infolgedessen gehen die EVC-Einstellungen verloren, wenn das Hostprofil auf einen Cluster angewendet wird. Dies führt zu einem Verlust von EVC-Funktionen. Beispielsweise können nicht maskierte CPUs für Arbeitslasten offengelegt werden.

  Problemumgehung: Konfigurieren Sie die entsprechende EVC-Baseline auf dem Cluster neu, um die EVC-Einstellungen wiederherzustellen.

• Die Verwendung eines Hostprofils, das eine Core-Dump-Partition in vCenter Server 7.0 definiert, führt zu einem Fehler

  In vCenter Server 7.0 ist das Konfigurieren und Verwalten einer Core-Dump-Partition in einem Hostprofil nicht verfügbar. Der Versuch, ein Hostprofil anzuwenden, das eine Core-Dump-Partition definiert, führt zu folgendem Fehler: Keine gültige Coredump-Partition gefunden.

  Problemumgehung: Keine. In vCenter Server 7.0 werden Hostprofile nur für dateibasierte Core-Dumps unterstützt.

• Wenn Sie den ESXCLI-Befehl ausführen, um das Firewall-Modul zu entladen, schlägt der hostd-Dienst fehl und ESXi-Hosts verlieren die Konnektivität

  Wenn Sie die Firewall-Konfiguration in einer Umgebung automatisieren, die mehrere ESXi-Hosts umfasst, und den ESXCLI-Befehl esxcli network firewall unload ausführen, der Filter zerstört und das Firewall-Modul entlädt, schlägt der hostd-Dienst fehl und ESXi-Hosts verlieren die Konnektivität.

  Problemumgehung: Das Entladen des Firewall-Moduls wird zu keinem Zeitpunkt empfohlen. Führen Sie die folgenden Schritte aus, wenn Sie das Firewall-Modul entladen müssen:

  1. Beenden Sie den hostd-Dienst mithilfe des Befehls:
     /etc/init.d/hostd stop.
  2. Entladen Sie das Firewall-Modul mithilfe des Befehls:
     esxcli network firewall unload.
  3. Führen Sie die erforderlichen Vorgänge aus.
  4. Laden Sie das Firewall-Modul mithilfe des Befehls:
     esxcli network firewall load.
  5. Starten Sie den hostd-Dienst mithilfe des Befehls:
     /etc/init.d/hostd start.
• vSphere Storage vMotion-Vorgänge könnten in einer vSAN-Umgebung aufgrund einer nicht authentifizierten Sitzung des NFC-Managers (Network File Copy) fehlschlagen

  Migrationen in einen vSAN-Datenspeicher mithilfe von vSphere Storage vMotion von virtuellen Maschinen mit mindestens einem Snapshot und mehreren virtuellen Festplatten mit unterschiedlicher Speicherrichtlinie könnten fehlschlagen. Das Problem tritt aufgrund einer nicht authentifizierten Sitzung des NFC-Managers auf, da der Simple Object Access Protocol (SOAP)-Body die zulässige Größe überschreitet.

  Problemumgehung: Migrieren Sie zuerst den VM-Start-Namespace und nur eine der virtuellen Festplatten. Führen Sie nach Abschluss des Vorgangs nur eine Festplattenmigration der verbleibenden beiden Festplatten durch. 

• Änderungen an den Eigenschaften und Attributen von Geräten und Speicher auf einem ESXi-Host bleiben nach einem Neustart möglicherweise nicht erhalten

  Wenn die Geräteerkennungsroutine während eines Neustarts eines ESXi-Hosts eine Zeitüberschreitung aufweist, erhält das Jumpstart-Plug-In möglicherweise nicht alle Konfigurationsänderungen von den Geräten und Speicher von allen registrierten Geräten auf dem Host. Infolgedessen setzt der Prozess die Eigenschaften einiger Geräte oder des Speichers nach dem Neustart möglicherweise auf die Standardwerte zurück.

  Problemumgehung: Stellen Sie die Änderungen der Eigenschaften des betroffenen Geräts oder Speichers manuell wieder her.

• Wenn Sie einen Beta-Build von ESXi 7.0 verwenden, schlagen ESXi-Hosts während einiger Lebenszyklusvorgänge möglicherweise mit einem violetten Diagnosebildschirm fehl

  Wenn Sie einen Beta-Build von ESXi 7.0 verwenden, schlagen ESXi-Hosts während einiger Lebenszyklusvorgänge wie dem Entladen eines Treibers oder dem Umschalten zwischen dem ENS-Modus und dem nativen Treibermodus möglicherweise mit einem violetten Diagnosebildschirm fehl. Wenn Sie zum Beispiel versuchen, den ENS-Modus zu ändern, wird im Backtrace folgende Fehlermeldung angezeigt: case ENS::INTERRUPT::NoVM_DeviceStateWithGracefulRemove hit BlueScreen: ASSERT bora/vmkernel/main/dlmalloc.c:2733. Dieses Problem tritt speziell bei Beta-Builds auf und hat keinen Einfluss auf Release-Builds wie ESXi 7.0.

  Problemumgehung: Update auf ESXi 7.0 GA.

• Sie können aufgrund eines Fehlers, bei dem ein Digest-Vorgang fehlgeschlagen ist, keine Snapshots von virtuellen Maschinen erstellen

  Eine seltene Race-Bedingung, bei der während der Aktualisierung der CBRC-Digest-Datei (Content Based Read Cache) ein APD-Status (All-Paths-Down) auftritt, verursacht unter Umständen Inkonsistenzen in der Digest-Datei. Infolgedessen können Sie keine VM-Snapshots erstellen. Im Backtrace wird ein Fehler vom Typ Beim Speichern des Snapshots ist ein Fehler aufgetreten: Fehler bei Digest-Vorgang angezeigt.

  Problemumgehung: Schalten Sie die virtuellen Maschinen ein/aus, um eine Neuberechnung der CBRC-Hashes auszulösen und die Inkonsistenzen in der Digest-Datei zu löschen.

• Wenn Sie ein Upgrade Ihrer ESXi-Hosts auf Version 7.0 Update 3 durchführen, Ihr vCenter Server jedoch eine frühere Version aufweist, schlägt der TPM-Nachweis (Trusted Platform Module) der ESXi-Hosts fehl

  Wenn Sie ein Upgrade Ihrer ESXi-Hosts auf Version 7.0 Update 3 durchführen, Ihr vCenter Server jedoch eine frühere Version aufweist, und Sie TPM aktivieren, können ESXi-Hosts keinen Nachweis bestehen. In der vSphere Client wird die Warnung „Alarm für TPM-Hostnachweis“ angezeigt. Der mit ESXi 7.0 Update 3 eingeführte ECDSA-Algorithmus (Elliptic Curve Digital Signature Algorithm) verursacht das Problem, wenn vCenter Server nicht Version 7.0 Update 3 aufweist.

  Problemumgehung: Führen Sie für Ihren vCenter Server ein Upgrade auf 7.0 Update 3 durch oder bestätigen Sie den Alarm.

• Auf dem Startladebildschirm werden Warnungen zu TPM-Asset-Tags angezeigt

  Wenn auf einem TPM-aktivierten ESXi-Host kein Asset-Tag aktiviert ist, werden auf dem Startladebildschirm möglicherweise Leerlaufwarnmeldungen wie die folgende angezeigt:
  Fehler beim Ermitteln der Tag-Größe des TPM-Assets: Puffer zu klein
Fehler beim Messen des Asset-Tags in TPM: Puffer zu klein

  Problemumgehung: Ignorieren Sie die Warnungen oder legen Sie ein Asset-Tag mit dem Befehl $ esxcli hardware tpm tag set -d fest.

• Der sensord-Daemon kann Hardwarestatus des ESXi-Hosts nicht melden

  Ein Logikfehler bei der IPMI-SDR-Validierung kann dazu führen, dass sensord keine Quelle für Stromversorgungsinformationen identifizieren kann. Wenn Sie daher den Befehl vsish -e get /power/hostStats ausführen, wird möglicherweise keine Ausgabe angezeigt.

  Problemumgehung: Keine

• Wenn ein ESXi-Host mit einem violetten Diagnosebildschirm fehlschlägt, funktioniert der netdump-Dienst möglicherweise nicht mehr

  Wenn ein ESXi-Host mit einem violetten Diagnosebildschirm fehlschlägt, schlägt der netdump-Dienst in seltenen Fällen möglicherweise mit einem Fehler wie NetDump FEHLGESCHLAGEN: Konnte nicht an den Dump-Server mit IP x.x.x.x angehängt werden fehl.

  Problemumgehung: Konfigurieren Sie den VMkernel-Core-Dump für die Verwendung des lokalen Speichers.

• Sie sehen VMware Fault Domain Manager(FDM)-Core-Dumps häufig auf mehreren ESXi-Hosts

  In einigen Umgebungen überschreitet die Anzahl der Datenspeicher möglicherweise die FDM-Dateideskriptorgrenze. Dies führt zu häufigen Core-Dumps auf mehreren ESXi-Hosts, die auf einen FDM-Fehler hinweisen.

  Problemumgehung: Erhöhen Sie den FDM-Dateideskriptorgrenzwert auf 2048. Sie können die Einstellung das.config.fdm.maxFds in den erweiterten vSphere HA-Optionen im vSphere Client verwenden. Weitere Informationen finden Sie unter Erweiterte Optionen festlegen.

• Virtuelle Maschinen in einem vSAN-Cluster mit aktiviertem NSX-T und einem konvergierten vSphere Distributed Switch (CVDS) in einer VLAN-Transportzone können nach einem Ausschalten nicht eingeschaltet werden

  Wenn die Festplatte einer sekundären Site zu 95 % voll ist und VMs vor der Simulation eines Ausfalls der sekundären Site ausgeschaltet werden, können einige der virtuellen Maschinen während der Wiederherstellung nicht eingeschaltet werden. Folglich reagieren virtuelle Maschinen nicht mehr. Das Problem tritt unabhängig davon auf, ob die Sitewiederherstellung das Hinzufügen von Festplatten, ESXi-Hosts oder CPU-Kapazität beinhaltet.

  Problemumgehung: Wählen Sie die virtuellen Maschinen aus, die nicht eingeschaltet werden, und ändern Sie unter „Einstellungen bearbeiten“ im VM-Kontextmenü das Netzwerk in ein VM-Netzwerk.

• ESXi-Hosts schlagen möglicherweise mit einem violetten Diagnosebildschirm mit dem Fehler „Assert bei bora/modules/vmkernel/vmfs/fs6Journal.c:835“ fehl

  In seltenen Fällen, z. B. beim Ausführen von SESparse-Tests, kann die Anzahl der Sperren pro Transaktion in einem VMFS-Datenspeicher den Grenzwert von 50 für den Parameter J6_MAX_TXN_LOCKACTIONS überschreiten. Dies führt dazu, dass ESXi-Hosts möglicherweise mit einem violetten Diagnosebildschirm mit dem Fehler Assert bei bora/modules/vmkernel/vmfs/fs6Journal.c:835 fehlschlagen.

  Problemumgehung: Keine

• Wenn Sie den Parameter „netq_rss_ens“ des „nmlx5_core“-Treibers ändern, schlagen ESXi-Hosts möglicherweise mit einem violetten Diagnosebildschirm fehl

  Wenn Sie versuchen, den Parameter netq_rss_ens zu aktivieren, während Sie einen erweiterten Datenpfad auf dem nmlx5_core-Treiber konfigurieren, schlagen ESXi-Hosts möglicherweise mit einem violetten Diagnosebildschirm fehl. Der Parameter netq_rss_ens, der NetQ RSS aktiviert, ist standardmäßig mit einem Wert von 0 deaktiviert.

  Problemumgehung: Behalten Sie den Standardwert für den Modulparameter netq_rss_ens im Treiber nmlx5_core bei. 

• ESXi kann aufgrund von Fehlern auf allen aktiven Pfaden E/A-Vorgänge zu NVMeOF-Geräten beenden

  Gelegentlich werden aufgrund von Link-Problemen oder dem Controllerstatus für alle aktiven Pfade zum NVMeOF-Gerät E/A-Fehler registriert. Wenn sich der Status eines der Pfade in „Ausgefallen“ ändert, wählt das High Performance Plug-In (HPP) möglicherweise keinen anderen Pfad aus, wenn eine hohe Anzahl von Fehlern angezeigt wird. Dies führt dazu, dass der E/A fehlschlägt.

  Problemumgehung: Deaktivieren Sie die Konfigurationsoption /Misc/HppManageDegradedPaths, um den E/A zu entsperren.

• Das Upgrade auf ESXi 7.0 Update 3 schlägt möglicherweise aufgrund eines geänderten Namens des i40enu-Inbox-Netzwerktreibers fehl

  Ab vSphere 7.0 Update 3 wird der Name des i40enu-Inbox-Netzwerktreibers für ESXi in „i40en“ zurück geändert. Der i40en-Treiber wurde in vSphere 7.0 Update 2 in „i40enu“ umbenannt, aber die Namensänderung wirkte sich auf einige Upgradepfade aus. Beispielsweise schlägt das Rollup-Upgrade von ESXi-Hosts fehl, die Sie mit Baselines und Baselinegruppen von 7.0 Update 2 oder 2a bis 3 verwalten. In den meisten Fällen wird der i40enu-Treiber ohne zusätzliche Schritte auf ESXi 7.0 Update 3 aktualisiert. Wenn das Treiber-Upgrade jedoch fehlschlägt, können Sie keine ESXi-Hosts aktualisieren, die Sie mit Baselines und Baselinegruppen verwalten. Sie können auch kein Host-Seeding und kein einzelnes vSphere Lifecycle Manager-Image zum Verwalten der ESXi-Hosts verwenden. Wenn Sie bereits Änderungen in Bezug auf den i40enu-Treiber und die Geräte in Ihrem System vorgenommen haben, müssen Sie vor dem Upgrade auf ESXi 7.0 Update 3 das i40enu-VIB bzw. die Komponente auf ESXi deinstallieren oder zuerst ein Upgrade von ESXi auf ESXi 7.0 Update 2c durchführen.

  Problemumgehung: Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 85982.

• Der SSH-Zugriff schlägt nach dem Upgrade auf ESXi 7.0 Update 3d fehl

  Nach dem Upgrade auf ESXi 7.0 Update 3d kann der SSH-Zugriff unter bestimmten Bedingungen aufgrund eines Updates von OpenSSH auf Version 8.8 fehlschlagen.  

  Problemumgehung: Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 88055.

• USB-Geräte-Passthrough von ESXi-Hosts zu virtuellen Maschinen schlägt möglicherweise fehl

  Ein USB-Modemgerät beansprucht möglicherweise gleichzeitig mehrere Schnittstellen durch den VMkernel und blockiert das Geräte-Passthrough zu VMs.
  Problemumgehung: Sie müssen die erweiterte Konfiguration USB.quirks auf den ESXi-Host anwenden, um die NET-Schnittstelle von VMkernel zu ignorieren und das Passthrough des USB-Modems zu VMs zuzulassen. Sie können die Konfiguration auf drei verschiedene Arten anwenden:

  1. Greifen Sie auf die ESXi-Shell zu und führen Sie den folgenden Befehl aus: esxcli system settings advanced set -o /USB/quirks -s 0xvvvv:0xpppp:0:0xffff:UQ_NET_IGNORE | |- Device Product ID |------- Device Vendor ID
     Für das Gemalto M2M GmbH Zoom 4625-Modem (vid:pid/1e2d:005b) können Sie beispielsweise den folgenden Befehl verwenden
     esxcli system settings advanced set -o /USB/quirks -s 0x1e2d:0x005b:0:0xffff:UQ_NET_IGNORE
     Starten Sie den ESXi-Host neu.
  2. Legen Sie die erweiterte Konfiguration über den vSphere Client oder den vSphere Web Client fest und starten Sie den ESXi-Host neu.
  3. Verwenden Sie ein Hostprofil, um die erweiterte Konfiguration anzuwenden.

  Weitere Informationen zu diesen Schritten finden Sie im VMware-Knowledgebase-Artikel 80416.
  

• HTTP-Anforderungen von bestimmten Bibliotheken an vSphere können abgelehnt werden

  Der HTTP-Reverse-Proxy in vSphere 7.0 erzwingt eine strengere Standardkonformität als in früheren Versionen. Dies kann bereits vorhandene Probleme in einigen Bibliotheken von Drittanbietern offenlegen, die von Anwendungen für SOAP-Aufrufe an vSphere verwendet werden.

  Wenn Sie vSphere-Anwendungen entwickeln, die solche Bibliotheken verwenden oder Anwendungen einschließen, die sich auf diese Bibliotheken in Ihrem vSphere Stack stützen, treten möglicherweise Verbindungsprobleme auf, wenn diese Bibliotheken HTTP-Anforderungen an VMOMI senden. Beispielsweise können HTTP-Anforderungen, die von vijava-Bibliotheken ausgegeben werden, folgende Form aufweisen:

  POST /sdk HTTP/1.1
  SOAPAction
  Content-Type: text/xml; charset=utf-8
  User-Agent: Java/1.8.0_221

  Die Syntax in diesem Beispiel verstößt gegen eine Voraussetzung für das HTTP-Protokoll-Kopfzeilenfeld, das einen Doppelpunkt nach einer SOAP-Aktion vorschreibt. Aus diesem Grund wird die Anforderung im laufenden Vorgang abgelehnt.

  Problemumgehung: Entwickler, die nicht konforme Bibliotheken in ihren Anwendungen nutzen, können stattdessen eine Bibliothek verwenden, die den HTTP-Standards folgt. Beispielsweise können Entwickler, die die vijava-Bibliothek verwenden, stattdessen die neueste Version der yavijava-Bibliothek verwenden.

• Möglicherweise wird bei Verwendung der Broadcom-Treiber „lsi_msgpt3“, „lsi_msgpt35“ und „lsi_mr3“ eine Dump-Datei ausgegeben

  Bei Verwendung der Controller „lsi_msgpt3“, „lsi_msgpt35“ und „lsi_mr3“ besteht ein potenzielles Risiko, dass die Dump-Datei „lsuv2-lsi-drivers-plugin-util-zdump“ ausgegeben wird. Beim Beenden der in diesem Plug-In-Dienstprogramm verwendeten storelib tritt ein Problem auf. Dies wirkt sich nicht auf ESXi-Vorgänge aus. Sie können die Dump-Datei ignorieren.

  Problemumgehung: Sie können diese Meldung bedenkenlos ignorieren. Sie können „lsuv2-lsi-drivers-plugin“ mit dem folgenden Befehl entfernen:
  
  esxcli software vib remove -n lsuv2-lsiv2-drivers-plugin

• Nach dem Konfigurieren von SR-IOV eines PCI-Geräts in vCenter, ist möglicherweise kein Neustart erforderlich, aber die Konfiguration, die durch Drittanbietererweiterungen vorgenommen wurden, gehen möglicherweise verloren und erfordern einen Neustart, damit sie erneut angewendet werden.

  In ESXi 7.0 wird die SR-IOV-Konfiguration ohne Neustart angewendet und der Gerätetreiber wird erneut geladen. ESXi-Hosts weisen möglicherweise Drittanbietererweiterungen auf, die Gerätekonfigurationen durchführen, die ausgeführt werden müssen, nachdem der Gerätetreiber während des Starts geladen wurde. Für diese Drittanbietererweiterungen ist ein Neustart erforderlich, damit die Gerätekonfiguration erneut angewendet wird.

  Problemumgehung: Sie müssen nach dem Konfigurieren von SR-IOV einen Neustart durchführen, damit Gerätekonfigurationen von Drittanbietern angewendet werden.

Probleme in Bezug auf den vSphere Client

• BIOS-Hersteller wird im vSphere Client als „--“ angezeigt

  Wenn Sie im vSphere Client einen ESXi-Host auswählen und zu Konfigurieren > Hardware > Firmware navigieren, wird anstelle des BIOS-Herstellernamens -- angezeigt.

  Problemumgehung: Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 88937.

Um die Liste früherer bekannter Probleme zu reduzieren, klicken Sie hier.