Versionshinweise zu VMware ESXi 8.0 Update 1c

ESXi 8.0 Update 1c | 27. JULI 2023 | Build 22088125 Überprüfen Sie, ob Erweiterungen und Updates für diese Versionshinweise zur Verfügung stehen.

Neuigkeiten

ESXi 8.0 Update 1c unterstützt vSphere Quick Boot auf folgenden Servern:

• Cisco Systems Inc

  • UCSC-C225-M6S

• Dell Inc.

  • R660 vSAN Ready Node

  • R760 vSAN Ready Node

  • PowerEdge R660xs 

  • PowerEdge R760xd2 

  • PowerEdge R760xa 

  • PowerEdge R760xs 

  • PowerEdge R860 

  • PowerEdge R960 

  • PowerEdge T560

• HPE

  • Alletra 4120 

  • HPE Cray XD220v 

  • ProLiant DL320 Gen11 

  • ProLiant DL360 Gen11 

  • ProLiant DL380 Gen11 

  • ProLiant DL380a Gen11 

  • ProLiant DL560 Gen11 

  • ProLiant ML110 Gen11 

  • ProLiant ML350 Gen11

• Lenovo

  • ThinkSystem SR630 V3 

  • ThinkSystem SR650 V3

Vorherige Versionen von ESXi 8.0

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

• Versionshinweise zu VMware ESXi 8.0 Update 1a

• Versionshinweise zu VMware ESXi 8.0 Update 1

• Versionshinweise zu VMware ESXi 8.0c

• Versionshinweise zu VMware ESXi 8.0b

• Versionshinweise zu VMware ESXi 8.0a

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

In dieser Version enthaltene Patches

• Patch für VMware ESXi 8.0 Update 1c
• Patch-Download und -Installation

Patch für VMware ESXi 8.0 Update 1c

Diese Version von ESXi 8.0 Update 1c stellt die folgenden Patches bereit:

Build-Details

Download-Dateiname:	VMware-ESXi-8.0U1c-22088125-depot.zip
Build:	22088125
Download-Größe:	949,1 MB
sha256checksum:	ab25ede2b6c40d6bb551f41ae43187fe124cc83853e9df25cd79ccf6836546a8
Neustart des Hosts erforderlich:	Ja
Migration oder Herunterfahren der virtuellen Maschine erforderlich:	Ja

Komponenten

Komponente	Bulletin	Kategorie	Schweregrad
ESXi-Komponente - ESXi-Kern-VIBs	ESXi_8.0.1-0.25.22088125	Fehlerkorrektur	Kritisch
ESXi-Komponente „Installieren/Aktualisieren“	esx-update_8.0.1-0.25.22088125	Fehlerkorrektur	Kritisch
ESXi-Komponente „Installieren/Aktualisieren“	esxio-update_8.0.1-0.25.22088125	Fehlerkorrektur	Kritisch
Mellanox-Netzwerkkarten der 5. Generation (ConnectX- und BlueField DPU-Reihe) – Ethernet- und RoCE-Kerntreiber für VMware ESXi	Mellanox-nmlx5_4.23.0.36-15vmw.801.0.25.22088125	Fehlerkorrektur	Kritisch
Broadcom NetXtreme I ESX VMKAPI-Ethernet-Treiber	Broadcom-ntg3_4.1.10.0-5vmw.801.0.25.22088125	Fehlerkorrektur	Kritisch
VMware NVMe over TCP-Treiber	VMware-NVMeoF-TCP_1.0.1.7-1vmw.801.0.25.22088125	Fehlerkorrektur	Kritisch
ESXi-Komponente - ESXi-Kern-VIBs	ESXi_8.0.1-0.20.22082334	Sicherheit	Kritisch
ESXi-Komponente „Installieren/Aktualisieren“	esx-update_8.0.1-0.20.22082334	Sicherheit	Kritisch
ESXi-Komponente „Installieren/Aktualisieren“	esxio-update_8.0.1-0.20.22082334	Sicherheit	Kritisch
ESXi Tools-Komponente	VMware-VM-Tools_12.2.5.21855600-22082334	Sicherheit	Kritisch

Rollup-Bulletin

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

Bulletin-ID	Kategorie	Schweregrad	Detail
ESXi80U1c-22088125	Fehlerkorrektur	Kritisch	Sicherheits- und Fehlerkorrekturen
ESXi80U1sc-22082334	Sicherheit	Kritisch	Reine Sicherheitskorrekturen

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-8.0U1c-22088125-standard
ESXi-8.0U1c-22088125-no-tools
ESXi-8.0U1sc-22082334-standard
ESXi-8.0U1sc-22082334-no-tools

ESXi-Image

Name und Version	Datum der Veröffentlichung	Kategorie	Detail
ESXi 8.0 U1c – 22088125	27.07.2023	Fehlerkorrektur	Image für Sicherheit und Fehlerbehebung
ESXi 8.0 U1sc – 22082334	27.07.2023	Sicherheit	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

Weitere Informationen zu Updates und Upgrades durch vSphere Lifecycle Manager finden Sie unter Info zu vSphere Lifecycle Manager sowie unter vSphere Lifecycle Manager-Baselines und -Images. Sie können ESXi-Hosts auch ohne vSphere Lifecycle Manager mithilfe eines Image-Profils aktualisieren. 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 8.0 aus. Weitere Informationen finden Sie unter Aktualisieren von Hosts mithilfe von ESXCLI-Befehlen und im Handbuch VMware ESXi-Upgrade.

Behobene Probleme

• ESXi_8.0.1-0.25.22088125
• esx-update_8.0.1-0.25.22088125
• esxio-update_8.0.1-0.25.22088125
• Mellanox-nmlx5_4.23.0.36-15vmw.801.0.25.22088125
• Broadcom-ntg3_4.1.10.0-5vmw.801.0.25.22088125
• VMware-NVMeoF-TCP_1.0.1.7-1vmw.801.0.25.22088125
• ESXi_8.0.1-0.20.22082334
• esx-update_8.0.1-0.20.22082334
• esxio-update_8.0.1-0.20.22082334
• VMware-VM-Tools_12.2.5.21855600-22082334
• ESXi-8.0U1c-22088125-standard
• ESXi-8.0U1c-22088125-no-tools
• ESXi-8.0U1sc-22082334-standard
• ESXi-8.0U1sc-22082334-no-tools
• ESXi 8.0 U1c – 22088125
• ESXi 8.0 U1sc – 22082334

ESXi_8.0.1-0.25.22088125

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
Betroffene VIBs	VMware_bootbank_esxio-combiner-esxio_8.0.1-0.25.22088125 VMware_bootbank_esxio-base_8.0.1-0.25.22088125 VMware_bootbank_esxio-dvfilter-generic-fastpath_8.0.1-0.25.22088125 VMware_bootbank_vdfs_8.0.1-0.25.22088125 VMware_bootbank_bmcal_8.0.1-0.25.22088125 VMware_bootbank_clusterstore_8.0.1-0.25.22088125 VMware_bootbank_native-misc-drivers-esxio_8.0.1-0.25.22088125 VMware_bootbank_gc-esxio_8.0.1-0.25.22088125 VMware_bootbank_esxio_8.0.1-0.25.22088125 VMware_bootbank_bmcal-esxio_8.0.1-0.25.22088125 VMware_bootbank_esxio-combiner_8.0.1-0.25.22088125 VMware_bootbank_gc_8.0.1-0.25.22088125 VMware_bootbank_esx-xserver_8.0.1-0.25.22088125 VMware_bootbank_vsan_8.0.1-0.25.22088125 VMware_bootbank_esx-base_8.0.1-0.25.22088125 VMware_bootbank_trx_8.0.1-0.25.22088125 VMware_bootbank_native-misc-drivers_8.0.1-0.25.22088125 VMware_bootbank_cpu-microcode_8.0.1-0.25.22088125 VMware_bootbank_vsanhealth_8.0.1-0.25.22088125 VMware_bootbank_crx_8.0.1-0.25.22088125
Behobene Probleme	3239946, 3239870, 3210610, 3228383, 3248279, 3179236, 3183209, 3219196, 3229111, 3221890, 3219889, 3223909, 3225464, 3228391, 3158175, 3217410, 3211624, 3223427, 3223420, 3181600, 3212384, 3221902, 3219121, 3219196, 3222717, 3221598, 3210610, 3181603, 3213042, 3221593, 3210931, 3210931, 3221549, 3161147, 3213110, 3219262, 3118977, 3217167, 3210610, 3210610, 3219971, 3112043, 3218145, 3218218, 3217477, 3214491, 3166665, 3210840, 3210837, 3210956, 3213914, 3212431, 3187725, 3213177, 3185230, 3213207, 3187539, 2625439, 3122074, 3197383, 3187416, 3187420, 3118241, 3176359, 3184331, 3182257, 3187875, 3187547, 3210192, 3180881, 3163270, 3179236, 3157222, 3187709, 3187716, 3187494, 3186022, 3188105, 3183522, 3166280, 3183038, 3183531, 3183526, 3184327, 3166566, 3171992, 3172063, 3159074, 3181553, 3183529, 3146205, 3038908, 3038908, 3153396, 3038908, 3038908, 3038908, 3179111
CVE-Nummern	Nicht verfügbar

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

• Warnung zur vorübergehenden vSAN-Integritätsprüfung: Netzwerkkonfiguration ist nicht synchronisiert

  Die vSAN Skyline-Integrität meldet möglicherweise nach dem Zufallsprinzip, dass die Netzwerkkonfiguration nicht synchronisiert ist. Dieses vorübergehende Problem tritt auf, wenn der vSAN-Integritätsdienst eine veraltete vCenter-Konfiguration verwendet, um eine Unicast-Prüfung durchzuführen.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Eine Racebedingung zwischen zwei Vorgängen kann potenziell zu inkonsistenten Metadaten führen

  In äußerst seltenen Fällen kann eine Racebedingung zwischen einem Vorgang zum Aufheben der Zuordnung auf einer VMDK und einem gleichzeitigen Snapshot-Erstellungsvorgang für dasselbe Objekt zu inkonsistenten vSAN-Metadaten für dieses Objekt in einem vSAN-Host führen. Diese Inkonsistenz kann einen VM- oder Hostausfall verursachen.

  Dieses Problem wurde in der vorliegenden Version behoben.

• ESX-Hosts schlagen möglicherweise fehl mit einem violetten Diagnosebildschirm und einem Fehler NMI-IPI: Von einer anderen PCPU angeforderter Notfallalarm

  Der Ressourcenpool-Cache ist ein VMFS-spezifischer Cache auf Volume-Ebene, in dem die Ressourcencluster gespeichert werden, die dem VMFS-Volume entsprechen. Bei der Suche nach Clustern mit Priorität durchläuft der Cache-Bereinigungs-Workflow eine umfangreiche Liste mit zwischengespeicherten Ressourcenclustern, was zu einer Sperrung der physischen CPUs führen kann. Infolgedessen können ESX Hosts mit einem violetten Diagnosebildschirm fehlschlagen. In der Datei logDump wird ein Fehler ähnlich dem folgenden aufgeführt:

  ^[[7m2022-10-22T07:56:47.322Z cpu13:2101160)WARNING: Heartbeat: 827: PCPU 0 didn't have a heartbeat for 7 seconds, timeout is 14, 1 IPIs sent; *may* be locked up.^[[0m

  ^[[31;1m2022-10-22T07:56:47.322Z cpu0:2110633)ALERT: NMI: 710: NMI IPI: RIPOFF(base):RBP:CS

  Dieses Problem wurde in der vorliegenden Version behoben.

• ESXi ConfigStore-Datenbank füllt sich, und Schreibvorgänge schlagen fehl

  Veraltete Daten im Zusammenhang mit Blockgeräten werden möglicherweise nicht rechtzeitig aus der ESXi ConfigStore-Datenbank gelöscht und verursachen eine Bedingung für nicht ausreichenden Speicherplatz. Infolgedessen schlagen Schreibvorgänge in ConfigStore fehl. Im Backtrace werden Protokolle ähnlich dem folgenden angezeigt:

  2022-12-19T03:51:42.733Z cpu53:26745174)WARNING: VisorFSRam: 203: Cannot extend visorfs file /etc/vmware/configstore/current-store-1-journal because its ramdisk (configstore) is full.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Verzögerung vor der Evakuierung des vSAN-Speichergeräts im Zustand FEHLERHAFT

  Nachdem Geräte als FEHLERHAFT erkannt wurden, wartet der LSOM (Local Log-Structured Object Manager) möglicherweise 10 Minuten (LSOM_DEVICE_MONITORING_INTERVAL), bevor die Evakuierung auf diesen Geräten initiiert wird.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Die vSAN-Vorabprüfung für den Wartungsmodus oder die Außerbetriebnahme der Festplatte listet keine Objekte auf, die möglicherweise nicht mehr zugänglich sind

  Dieses Problem betrifft Objekte mit Neusynchronisierungskomponenten, und einige Komponenten befinden sich auf einem Gerät, das entfernt oder in den Wartungsmodus versetzt werden soll. Wenn Sie eine Vorabprüfung mit der Option No-Action ausführen, wertet die Vorabprüfung das Objekt nicht korrekt aus, um es in der Liste inaccessibleObjects zu melden.

  Dieses Problem wurde in der vorliegenden Version behoben. Die Vorabprüfung umfasst alle betroffenen Objekte in der Liste inaccessibleObjects.

• Der vSAN iSCSI-Zieldienst schlägt möglicherweise aufgrund einer seltenen Race-Bedingung fehl

  Wenn Sie den ESXCLI-Befehl esxcli network firewall load ausführen, lädt der Vorgang vorhandene dynamische Firewallregeln nicht neu, und sie gehen verloren. Wenn Sie den ESXCLI-Befehl esxcli network firewall refresh ausführen, lädt der Vorgang vorhandene dynamische Firewallregeln zwar neu, aber in einigen Fällen kann eine Race-Bedingung dazu führen, dass einige Regeln verloren gehen. Dieses Problem tritt nur auf, wenn mehrere Firewall-Aktualisierungsbefehle gleichzeitig ausgeführt werden, was zu einer Race-Bedingung führt. Infolgedessen kann der vSAN iSCSI-Zieldienst fehlschlagen.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Das Festlegen der Bildschirmauflösung einer ausgeschalteten, verschlüsselten virtuellen Maschine funktioniert nicht immer, wenn eine VMX-Datei manuell bearbeitet wird

  Wenn Sie die Bildschirmauflösung einer ausgeschalteten, verschlüsselten virtuellen Maschine durch Bearbeiten der VMX-Datei manuell angeben, wird die Änderung möglicherweise nicht wirksam.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Wenn das Internet Control Message Protocol (ICMPA) nicht aktiv ist, kann der Neustart des ESXi Hosts nach dem Upgrade auf vSphere 8.0 und höher lange dauern

  Wenn ICMPA auf den NFS-Servern in Ihrer Umgebung nicht aktiv ist, kann es nach dem Upgrade Ihres Systems auf vSphere 8.0 und höher eine Stunde dauern, bis der Neustart ESXi Hosts abgeschlossen ist, da Wiederherstellungsvorgänge für NFS-Datenspeicher fehlschlagen. NFS verwendet das Dienstprogramm vmkping, um erreichbare IPs der NFS-Server zu identifizieren, bevor ein Bereitstellungsvorgang ausgeführt wird. Wenn ICMP nicht aktiv ist, schlagen Bereitstellungsvorgänge fehl.

  Dieses Problem wurde in der vorliegenden Version behoben. Um die Abhängigkeit vom ICMP-Protokoll zum Auffinden erreichbarer IPs zu entfernen, fügt der Fix Socket-APIs hinzu, um sicherzustellen, dass IPs auf einem bestimmten NFS-Server verfügbar sind.

• Wenn Sie eine VM mit kürzlich im laufenden Betrieb hinzugefügtem Arbeitsspeicher migrieren, schlägt ein ESXi-Host möglicherweise wiederholt mit einem violetten Diagnosebildschirm fehl

  Aufgrund einer Race-Bedingung während der Neuberechnung des NUMA-Arbeitsspeicherlayouts einer VM auf einem Zielhost nach der Migration durch das Arbeitsspeicher-Hotplug-Modul schlägt ein ESXi-Host möglicherweise wiederholt mit einem violetten Diagnosebildschirm fehl. Im Backtrace werden Fehler angezeigt, wie z. B.:

  0x452900262cf0:[0x4200138fee8b]PanicvPanicInt@vmkernel#nover+0x327 stack: 0x452900262dc8, 0x4302f6c06508, 0x4200138fee8b, 0x420013df1300, 0x452900262cf0  0x452900262dc0:[0x4200138ff43d]Panic_WithBacktrace@vmkernel#nover+0x56 stack: 0x452900262e30, 0x452900262de0, 0x452900262e40, 0x452900262df0, 0x3e7514  0x452900262e30:[0x4200138fbb90]NMI_Interrupt@vmkernel#nover+0x561 stack: 0x0, 0xf48, 0x0, 0x0, 0x0  0x452900262f00:[0x420013953392]IDTNMIWork@vmkernel#nover+0x7f stack: 0x420049800000, 0x4200139546dd, 0x0, 0x452900262fd0, 0x0  0x452900262f20:[0x4200139546dc]Int2_NMI@vmkernel#nover+0x19 stack: 0x0, 0x42001394e068, 0xf50, 0xf50, 0x0  0x452900262f40:[0x42001394e067]gate_entry@vmkernel#nover+0x68 stack: 0x0, 0x43207bc02088, 0xd, 0x0, 0x43207bc02088  0x45397b61bd30:[0x420013be7514]NUMASched_PageNum2PhysicalDomain@vmkernel#nover+0x58 stack: 0x1, 0x420013be34c3, 0x45396f79f000, 0x1, 0x100005cf757  0x45397b61bd50:[0x420013be34c2]NUMASched_UpdateAllocStats@vmkernel#nover+0x4b stack: 0x100005cf757, 0x0, 0x0, 0x4200139b36d9, 0x0  0x45397b61bd80:[0x4200139b36d8]VmMem_NodeStatsSub@vmkernel#nover+0x59 stack: 0x39, 0x45396f79f000, 0xbce0dbf, 0x100005cf757, 0x0  0x45397b61bdc0:[0x4200139b4372]VmMem_FreePageNoBackmap@vmkernel#nover+0x8b stack: 0x465ec0001be0, 0xa, 0x465ec18748b0, 0x420014e7685f, 0x465ec14437d0

  Dieses Problem wurde in der vorliegenden Version behoben.

• Das Herunterfahren des vSAN-Clusters schlägt auf einem Cluster mit deaktiviertem IPv6 fehl

  Dieses Problem tritt auf vSAN-Hosts auf, auf denen ESXi 8.0 Update 1 mit deaktiviertem IPv6 ausgeführt wird. Wenn Sie den Assistenten zum Herunterfahren des vSAN-Clusters verwenden, schlägt der Workflow mit der folgenden Fehlermeldung fehl: 'NoneType' object is not iterable.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Trap-Dateien werden in einem SNMP-Verzeichnis unter /var/spool angezeigt, obwohl SNMP nicht aktiviert ist

  Nach dem Start des hostd-Diensts, z. B. nach einem Neustart des ESXi-Hosts, erstellt dieser möglicherweise ein SNMP-Verzeichnis unter /var/spool, und es sammeln sich viele .trp-Dateien in diesem Verzeichnis an.

  Dieses Problem wurde in der vorliegenden Version behoben. Mit dem Fix wird sichergestellt, dass das Verzeichnis /var/spool/snmp nur vorhanden ist, wenn SNMP aktiviert ist.

• Der hostd-Dienst schlägt wiederholt fehl, und der ESXi-Host wird vom vCenter-System getrennt

  Wenn ein ESXi-Host aus irgendeinem Grund vorübergehend nicht genügend Arbeitsspeicher aufweist, schlägt der hostd-Dienst aufgrund eines vSphere Replication-Filters, der die Zuteilung von Bitmaps verhindert, möglicherweise wiederholt fehl. Dies führt dazu, dass der ESXi-Host vom vCenter Server-System getrennt wird und nicht wieder verbunden werden kann.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Während der Service Insertion für NSX-verwaltete Arbeitslast-VMs reagieren einige VMs möglicherweise zeitweise nicht mehr, und das virtuelle Gerät wird möglicherweise zurückgesetzt

  Während der Service Insertion für NSX-verwaltete Arbeitslast-VMs wird eine Paketliste möglicherweise von der Eingabekette eines Switchports zu einem anderen Switchport neu implementiert. In solchen Fällen entspricht der Quell-Switchport nicht der tatsächlichen Port-ID der Eingabekette, und das virtuelle Gerät erhält keinen Abschlussstatus für den übertragenen Frame. Infolgedessen reagieren beim Ausführen einer Service Insertion-Aufgabe einige VMs aufgrund von Problemen mit der Netzwerkkonnektivität zeitweise nicht mehr.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Die Leistung bestimmter verschachtelter virtueller Maschinen auf AMD-CPUs kann sich verschlechtern

  Bei verschachtelten virtuellen Maschinen auf AMD-CPUs mit Betriebssystemen wie Windows mit virtualisierungsbasierter Sicherheit (VBS) kann es aufgrund eines Problems mit der Virtualisierung von AMD Rapid Virtualization Indexing (RVI), auch bekannt als Nested Page Tables (NPT), zu Leistungsbeeinträchtigungen, Zeitüberschreitungen oder fehlender Reaktion kommen.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Eine Modusänderung der virtuellen Festplatte einer ausgeführten virtuellen Maschine kann zum Fehlschlagen der VM führen

  Wenn Sie den VMware Host Client verwenden, um den Festplattenmodus einer ausgeführten virtuellen Maschine zu bearbeiten, z. B. von „Unabhängig – Nicht dauerhaft“ in „Abhängig“ oder „Unabhängig – Dauerhaft“, schlägt der Vorgang fehl und kann zu einem VM-Fehler führen. Im Protokoll „vmware.log“ werden Fehler angezeigt, wie z. B.:

  msg.disk.notConfigured2] Failed to configure disk 'scsi0:4'. The virtual machine cannot be powered on with an unconfigured disk.

  [msg.checkpoint.continuesync.error] An operation required the virtual machine to quiesce and the virtual machine was unable to continue running.

  Dieses Problem wurde in der vorliegenden Version behoben. Der Fix blockiert die Modusänderung einer Festplatte vom Typ „Unabhängig – Nicht persistent“ auf einer ausgeführten virtuellen Maschine mithilfe des VMware Host Client. Der vSphere Client blockiert derartige Vorgänge bereits.

• ESXi NVMe/TCP-Initiator kann nach der Zielfehlerwiederherstellung keine Pfade wiederherstellen

  Wenn ein NVMe/TCP-Ziel nach einem Ausfall wiederhergestellt wird, kann ESXi den Pfad nicht wiederherstellen.

  Dieses Problem wurde in der vorliegenden Version behoben.

• ESXi-Host reagiert nicht mehr, und Sie können den Host weder in den Wartungsmodus versetzen, noch VMs von diesem Host migrieren

  Das asynchrone Lesen von Metadaten auf einem an einen ESXi-Host angehängten VMFS-Volume kann zu einer Race-Bedingung mit anderen Threads auf dem Host und dazu führen, dass der Host nicht mehr reagiert. Infolgedessen können Sie den Host nicht in den Wartungsmodus versetzen oder keine VMs von diesem Host migrieren.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Eine LVM-Festplatte (Logical Volume Manager) wird während der Datenspeichererweiterung offline geschaltet

  Wenn Sie während der Erweiterung eines Datenspeichers auf einem ESXi-Host in einem Cluster eine Speicheraktualisierung ausführen, wird eine LVM-Erweiterung möglicherweise offline geschaltet, und die virtuellen Maschinen auf diesem Volume reagieren nicht mehr. Das Problem tritt auf, weil die Speicheraktualisierung eine langsame Aktualisierung der Volume-Attribute auf allen ESXi-Hosts im Cluster auslöst. Dies führt dazu, dass die LVM-Metadaten auf der Festplatte möglicherweise nicht mit den zwischengespeicherten Kapazitätsinformationen in der PSA-Schicht (Pluggable Storage Architecture) übereinstimmen und dass ESXi die LVM-Erweiterung aus Gründen der Metadaten- und Datensicherheit offline markiert.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Der dauerhafte Name einer SCSI-LUN ist möglicherweise nicht festgelegt

  Die Eigenschaft des dauerhaften Namens für ein SCSI-3-konformes Gerät stammt aus Seiten 80h und 83h der wichtigen Produktdaten (VPD) gemäß Definition durch die T10- und SMI-Standards. Um den dauerhaften Namen aufzufüllen, sendet ESXi zuerst einen Anfragebefehl, um eine Liste der vom Gerät unterstützten VPD-Seiten abzurufen. Anschließend gibt ESXi Befehle aus, um Daten für alle unterstützten VPD-Seiten abzurufen. Aufgrund eines Problems mit dem Ziel-Array lässt das Gerät möglicherweise einen Befehl zum Abrufen von VPD-Seitendaten für eine Seite in der Liste mit einem Fehler vom Typ not supported fehlschlagen. Infolgedessen kann ESXi die Eigenschaft des dauerhaften Namens für das Gerät nicht auffüllen.

  Dieses Problem wurde in der vorliegenden Version behoben. Der Fix ignoriert den Fehler beim Befehl zum Abrufen von VPD-Seitendaten mit Ausnahme der Seiten 80h und 83h, wenn diese Daten für die Generierung eines dauerhaften Namens nicht erforderlich sind.

• Übermäßige Zeit für die Pfadwiederherstellung mit ESXi High Performance Plug-In (HPP) nach einem Link-Up-Ereignis für NVMe over Fibre Channel

  In bestimmten Szenarien kann es nach einem Link-Up-Ereignis für Fibre Channel bis zu 5 Minuten dauern, bis HPP-verwaltete NVMe over Fibre Channel-Pfade wiederhergestellt sind.

  Dieses Problem wurde in der vorliegenden Version behoben.

• NVMe over Fabrics-Controller kann während der Ermittlung möglicherweise unerwartet getrennt werden

  Wenn die Ermittlung und E/A-Controller bereits für ein NVMe over Fabrics-Speicherziel vorhanden sind, das einen persistenten Ermittlungscontroller auf einem ESXi-Host unterstützt, kann ein gleichzeitiger NVMe over Fabrics-Controller-Ermittlungsvorgang dazu führen, dass einige E/A-Controller unerwartet getrennt werden.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Wenn Ihr ESXi PTP-Dienst die Hardware-Zeitstempelung verwendet, kann die Aktivierung von IGMP-Snooping auf Switches zu Synchronisierungsfehlern führen

  Wenn Sie IGMP-Snooping (Internet Group Management Protocol) auf einem verbundenen Switch aktivieren, muss der PTP-Client (Precision Time Protocol) IGMP-Multicast-Anforderungen senden, um PTP-Multicast-Streams vom Hauptmaster zu empfangen. Wenn der ESXi PTP-Agent auf Hardware-Zeitstempelung basiert, kann der Agent möglicherweise keine IGMP-Beitritts-/Verlassen-Anforderungen an den Switch senden. Dies führt dazu, dass der PTP-Multicast-Stream nicht zum ESXi-Host weitergeleitet werden kann. Zudem wird eine ordnungsgemäße PTP-Synchronisierung verhindert.

  Dieses Problem wurde in der vorliegenden Version behoben. Weitere Einzelheiten finden Sie im VMware-Knowledgebase-Artikel 92276.

• Wenn parallele Volume-Erweiterungs- und Volume-Aktualisierungsvorgänge auf demselben VMFS-Volume auf zwei ESXi-Hosts im selben Cluster ausgeführt werden, wird das VMFS-Volume möglicherweise offline geschaltet

  Wenn bei der Ausführung eines VMFS-Volume-Erweiterungsvorgangs auf einem ESXi-Host in einem vCenter-Cluster von einem Benutzer oder vCenter auf einem anderen Host eine Aktualisierung derselben VMFS-Volume-Kapazität initiiert wird, wird ein derartiges Volume möglicherweise offline geschaltet. Das Problem tritt aufgrund einer möglichen Nichtübereinstimmung bei der Gerätegröße auf, die während einer erneuten Prüfung in den Volume-Metadaten auf der Festplatte mit einem Stempel versehen wird. Ein weiterer Grund ist der Wert für die Gerätegröße in der PSA-Schicht (Pluggable Storage Architecture) auf dem Host, der möglicherweise nicht aktualisiert wird, wenn die erneute Prüfung des Geräts nicht abgeschlossen ist.

  Dieses Problem wurde in der vorliegenden Version behoben. Durch den Fix wird die Stabilität des Volume-Manager-Codes verbessert, um eine aufeinander folgende Aktualisierung der Geräteattribute und einen erneuten Vergleich der Gerätegrößen zu erzwingen, wenn vCenter eine Nichtübereinstimmung bei der Gerätegröße meldet.

• Vorgänge mit statusfreien ESXi-Hosts wählen möglicherweise nicht die erwartete Remote-Festplatte für den Systemcache aus. Dies führt zu Standardisierungs- und Konformitätsproblemen

  Vorgänge mit statusfreien ESXi-Hosts, wie z. B. Speichermigration, wählen möglicherweise nicht die erwartete Remote-Festplatte für den Systemcache. Beispielsweise möchten Sie die neue Start-LUN als LUN 0 beibehalten, aber vSphere Auto Deploy wählt LUN 1 aus.

  Dieses Problem wurde in der vorliegenden Version behoben. Der Fix bietet eine konsistente Möglichkeit, die Remotefestplatten zu sortieren und immer die Festplatte mit der niedrigsten LUN-ID auszuwählen. Um sicherzustellen, dass Sie den Fix aktivieren, führen Sie die folgenden Schritte aus:

  1. Wählen Sie auf der Seite „Hostprofil bearbeiten“ des Auto Deploy-Assistenten Erweiterte Konfigurationseinstellungen > System-Image-Cache-Konfiguration aus.

  2. Wählen Sie im Dropdown-Menü Profileinstellungen für System-Image-Cache die Option Statusfreies Caching auf dem Host aktivieren aus.

  3. Bearbeiten Sie Argumente für erste Festplatte, indem Sie remote durch sortedremote und/oder remoteesx durch sortedremoteesx ersetzen.

• VMware VIB-Installation schlägt während gleichzeitigen Anbieterpaketinstallationen möglicherweise fehl

  Wenn Sie Update-Pakete von verschiedenen Anbietern wie JetStream Software, Microsoft und VMware installieren, rufen mehrere Clients dieselben PatchManager-APIs auf. Dies kann zu einer Race-Bedingung führen. Infolgedessen werden die VMware-Installationspakete (VIBs) möglicherweise nicht installiert. In den Protokollen wird ein Fehler wie vim.fault.PlatformConfigFault angezeigt. Hierbei handelt es sich um einen Auffangfehler, der darauf hinweist, dass bei der Konfiguration des ESXi-Hosts ein Fehler aufgetreten ist. Im vSphere Client wird eine Meldung ähnlich der folgenden angezeigt: An error occurred during host configuration.

  Dieses Problem wurde in der vorliegenden Version behoben. Durch den Fix wird eine TaskInProgress-Warnung anstelle von PlatformConfigFault zurückgegeben, damit Sie das tatsächliche Problem kennen und die Installation wiederholen können.

• Bestimmte Anwendungen benötigen möglicherweise zu viele ESXi-Datei-Handles und verursachen Leistungsbeeinträchtigungen

  In sehr seltenen Fällen können Anwendungen wie NVIDIA virtual GPU (vGPU) so viele Datei-Handles verwenden, dass ESXi andere Dienste oder VMs nicht verarbeiten kann. Infolgedessen wird die GPU auf einigen Knoten nicht mehr angezeigt, oder es wird gemeldet, dass kein GPU-Arbeitsspeicher vorhanden oder dass die Leistung beeinträchtigt ist.

  Dieses Problem wurde in der vorliegenden Version behoben. Der Fix reduziert die Anzahl Datei-Handles, die eine vGPU-VM verwenden kann.

• Wenn Sie eine virtuelle Maschine aus einer OVF-Datei oder aus der Inhaltsbibliothek bereitstellen, wird die Anzahl der Kerne pro Socket für die VM auf 1 festgelegt

  Wenn Sie eine virtuelle Maschine aus einer OVF-Datei oder aus der Inhaltsbibliothek bereitstellen, wird die Anzahl der Kerne pro Socket nicht automatisch von ESXi ausgewählt, sondern auf 1 festgelegt.

  Dieses Problem wurde in der vorliegenden Version behoben.

esx-update_8.0.1-0.25.22088125

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
Betroffene VIBs	VMware_bootbank_loadesx_8.0.1-0.25.22088125 VMware_bootbank_esx-update_8.0.1-0.25.22088125
Behobene Probleme	Nicht verfügbar
CVE-Nummern	Nicht verfügbar

Aktualisiert die VIBs loadesx und esx-update.

esxio-update_8.0.1-0.25.22088125

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
Betroffene VIBs	VMware_bootbank_loadesxio_8.0.1-0.25.22088125 VMware_bootbank_esxio-update_8.0.1-0.25.22088125
Behobene Probleme	Nicht verfügbar
CVE-Nummern	Nicht verfügbar

Aktualisiert die VIBs loadesxio und esxio-update.

Mellanox-nmlx5_4.23.0.36-15vmw.801.0.25.22088125

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_nmlx5-rdma_4.23.0.36-15vmw.801.0.25.22088125 VMW_bootbank_nmlx5-core_4.23.0.36-15vmw.801.0.25.22088125 VMW_bootbank_nmlx5-rdma-esxio_4.23.0.36-15vmw.801.0.25.22088125 VMW_bootbank_nmlx5-core-esxio_4.23.0.36-15vmw.801.0.25.22088125
Behobene Probleme	3152476
CVE-Nummern	Nicht verfügbar

Aktualisiert die VIBs nmlx5-rdma, nmlx5-core, nmlx5-rdma-esxio und nmlx5-core-esxio zur Behebung des folgenden Problems:

• In einigen Fällen kann es zu einem niedrigen Durchsatz bei gekapseltem Datenverkehr mit Mellanox-Netzwerkkarten kommen

  Im Modus „Nicht erweiterter Datenpfad“ ist der Durchsatz des gekapselten Datenverkehrs von Netzwerkkarten mit dem Mellanox-Treiber (nmlx5) möglicherweise niedrig, und es kann zu einem ungleichmäßigen Datenverkehrsfluss über RSS-Warteschlangen hinweg kommen.

  Dieses Problem wurde in der vorliegenden Version behoben.

Broadcom-ntg3_4.1.10.0-5vmw.801.0.25.22088125

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.10.0-5vmw.801.0.25.22088125
Behobene Probleme	3187446
CVE-Nummern	Nicht verfügbar

Aktualisiert das VIB ntg3 zur Behebung des folgenden Problems:

• Nach dem Upgrade des ntg3-Treibers auf Version 4.1.9.0-4vmw verlieren Broadcom-Netzwerkkarten mit physischer Glasfaserverbindung möglicherweise die Verbindung zum Netzwerk

  Änderungen an der ntg3-Treiberversion 4.1.9.0-4vmw führen möglicherweise zu Verbindungsfehlern für die physische Glasfaserschicht und zu Konnektivitätsproblemen auf einigen Netzwerkkarten (z. B. Broadcom 1Gb).

  Dieses Problem wurde in der vorliegenden Version behoben.

VMware-NVMeoF-TCP_1.0.1.7-1vmw.801.0.25.22088125

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_nvmetcp_1.0.1.7-1vmw.801.0.25.22088125
Behobene Probleme	3219191
CVE-Nummern	Nicht verfügbar

Aktualisiert das VIB nvmetcp zur Behebung des folgenden Problems:

• Die automatische Erkennung des NVMe Discovery Service schlägt auf ESXi-Hosts mit NVMe/TCP-Konfigurationen möglicherweise fehl

  vSphere 8.0 bietet erweiterte NVMe-oF Discovery Service-Unterstützung in ESXi. Dies ermöglicht die dynamische Erkennung des standardkonformen NVMe Discovery Service. ESXi verwendet den mDNS/DNS-SD-Dienst, um Informationen wie IP-Adresse und Portnummer der aktiven NVMe-oF Discovery Services im Netzwerk abzurufen. In ESXi-Servern mit aktiviertem NVMe/TCP schlägt die automatische Erkennung in Netzwerken, die für die Verwendung des vSphere Distributed Switch konfiguriert sind, möglicherweise fehl. Das Problem wirkt sich nicht auf NVMe/TCP-Konfigurationen aus, die Standard-Switches verwenden.

  Dieses Problem wurde in der vorliegenden Version behoben.

ESXi_8.0.1-0.20.22082334

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_bmcal-esxio_8.0.1-0.20.22082334 VMware_bootbank_native-misc-drivers_8.0.1-0.20.22082334 VMware_bootbank_esx-dvfilter-generic-fastpath_8.0.1-0.20.22082334 VMware_bootbank_vsan_8.0.1-0.20.22082334 VMware_bootbank_bmcal_8.0.1-0.20.22082334 VMware_bootbank_esx-base_8.0.1-0.20.22082334 VMware_bootbank_trx_8.0.1-0.20.22082334 VMware_bootbank_gc-esxio_8.0.1-0.20.22082334 VMware_bootbank_gc_8.0.1-0.20.22082334 VMware_bootbank_esxio_8.0.1-0.20.22082334 VMware_bootbank_esx-xserver_8.0.1-0.20.22082334 VMware_bootbank_cpu-microcode_8.0.1-0.20.22082334 VMware_bootbank_esxio-combiner-esxio_8.0.1-0.20.22082334 VMware_bootbank_esxio-dvfilter-generic-fastpath_8.0.1-0.20.22082334 VMware_bootbank_vsanhealth_8.0.1-0.20.22082334 VMware_bootbank_vds-vsip_8.0.1-0.20.22082334 VMware_bootbank_clusterstore_8.0.1-0.20.22082334 VMware_bootbank_native-misc-drivers-esxio_8.0.1-0.20.22082334 VMware_bootbank_esxio-combiner_8.0.1-0.20.22082334 VMware_bootbank_esxio-base_8.0.1-0.20.22082334 VMware_bootbank_vdfs_8.0.1-0.20.22082334 VMware_bootbank_crx_8.0.1-0.20.22082334
Behobene Probleme	3229052, 3222888, 3184515, 3184505, 3210921, 3219294, 3217139, 3215295, 3184512, 3184517, 3213042, 3184513, 3184506, 3186149
CVE-Nummern	Nicht verfügbar

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

• ESXi 8.0 Update 1c stellt die folgenden Sicherheits-Updates bereit:

  • Der Envoy-Proxy wird auf Version v1.23.9 aktualisiert.

  • Die userworld-libxml2-Bibliothek von ESXi wird auf Version 2.10.4 aktualisiert.

  • Die cURL-Bibliothek wird auf Version 8.0.1 aktualisiert.

  • Die Go-Bibliothek wird auf Version 1.19.9 aktualisiert.

  • Das etcd-Paket wird auf 3.4.25 aktualisiert.

esx-update_8.0.1-0.20.22082334

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-update_8.0.1-0.20.22082334 VMware_bootbank_loadesx_8.0.1-0.20.22082334
Behobene Probleme	Nicht verfügbar
CVE-Nummern	Nicht verfügbar

Aktualisiert die VIBs esx-update und loadesx.

esxio-update_8.0.1-0.20.22082334

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_loadesxio_8.0.1-0.20.22082334 VMware_bootbank_esxio-update_8.0.1-0.20.22082334
Behobene Probleme	Nicht verfügbar
CVE-Nummern	Nicht verfügbar

Aktualisiert die VIBs loadesxio und esxio-update.

VMware-VM-Tools_12.2.5.21855600-22082334

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.2.5.21855600-22082334
Behobene Probleme	3186166
CVE-Nummern	Nicht verfügbar

• Aktualisiert das VIB tools-light.

  • Die folgenden VMware Tools-ISO-Images werden mit dem ESXi 8.0 Update 1c gebündelt:

    • windows.iso: VMware Tools 12.2.5 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. VMware Tools 12.1.0 war die letzte reguläre Version für macOS. Details finden Sie im VMware-Knowledgebase-Artikel 88698.

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

    • Aktualisieren von VMware Tools

    • VMware Tools für Hosts, die mit Auto Deploy bereitgestellt wurden

    • Wichtige Informationen zu VMware Tools für Administratoren

    • Frühere Versionen von VMware Tools

    • Versionshinweise zu VMware Tools 12.2.5

ESXi-8.0U1c-22088125-standard

Profilname	ESXi-8.0U1c-22088125-standard
Build	Build-Informationen finden Sie unter In dieser Version enthaltene Patches.
Anbieter	VMware, Inc.
Datum der Veröffentlichung	27. Juli 2023
Akzeptanzebene	Unterstützte Partner
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Betroffene VIBs	VMware_bootbank_vdfs_8.0.1-0.25.22088125 VMW_bootbank_nvmetcp_1.0.1.7-1vmw.801.0.25.22088125 VMW_bootbank_ntg3_4.1.10.0-5vmw.801.0.25.22088125 VMW_bootbank_nmlx5-rdma-esxio_4.23.0.36-15vmw.801.0.25.22088125 VMware_bootbank_gc_8.0.1-0.25.22088125 VMware_bootbank_native-misc-drivers_8.0.1-0.25.22088125 VMware_bootbank_cpu-microcode_8.0.1-0.25.22088125 VMware_bootbank_esx-dvfilter-generic-fastpath_8.0.1-0.25.22088125 VMware_bootbank_vds-vsip_8.0.1-0.25.22088125 VMware_bootbank_esxio-dvfilter-generic-fastpath_8.0.1-0.25.22088125 VMware_bootbank_loadesxio_8.0.1-0.25.22088125 VMware_bootbank_loadesx_8.0.1-0.25.22088125 VMware_bootbank_gc-esxio_8.0.1-0.25.22088125 VMware_bootbank_esxio-combiner_8.0.1-0.25.22088125 VMW_bootbank_nmlx5-core_4.23.0.36-15vmw.801.0.25.22088125 VMware_bootbank_esxio-update_8.0.1-0.25.22088125 VMware_bootbank_esx-update_8.0.1-0.25.22088125 VMware_bootbank_vsan_8.0.1-0.25.22088125 VMware_bootbank_crx_8.0.1-0.25.22088125 VMW_bootbank_nmlx5-rdma_4.23.0.36-15vmw.801.0.25.22088125 VMware_bootbank_bmcal_8.0.1-0.25.22088125 VMware_bootbank_esx-xserver_8.0.1-0.25.22088125 VMware_bootbank_trx_8.0.1-0.25.22088125 VMware_bootbank_esxio-combiner-esxio_8.0.1-0.25.22088125 VMware_bootbank_esxio-base_8.0.1-0.25.22088125 VMware_bootbank_clusterstore_8.0.1-0.25.22088125 VMware_bootbank_native-misc-drivers-esxio_8.0.1-0.25.22088125 VMware_bootbank_esxio_8.0.1-0.25.22088125 VMware_bootbank_bmcal-esxio_8.0.1-0.25.22088125 VMware_bootbank_esx-base_8.0.1-0.25.22088125 VMware_bootbank_vsanhealth_8.0.1-0.25.22088125 VMW_bootbank_nmlx5-core-esxio_4.23.0.36-15vmw.801.0.25.22088125 VMware_locker_tools-light_12.2.5.21855600-22082334
Behobene Probleme	3239946, 3239870, 3210610, 3228383, 3248279, 3179236, 3183209, 3219196, 3229111, 3221890, 3219889, 3223909, 3225464, 3228391, 3158175, 3217410, 3211624, 3223427, 3223420, 3181600, 3212384, 3221902, 3219121, 3219196, 3222717, 3221598, 3210610, 3181603, 3213042, 3221593, 3210931, 3210931, 3221549, 3161147, 3213110, 3219262, 3118977, 3217167, 3210610, 3210610, 3219971, 3112043, 3218145, 3218218, 3217477, 3214491, 3166665, 3210840, 3210837, 3210956, 3213914, 3212431, 3187725, 3213177, 3185230, 3213207, 3187539, 2625439, 3122074, 3197383, 3187416, 3187420, 3118241, 3176359, 3184331, 3182257, 3187875, 3187547, 3210192, 3180881, 3163270, 3179236, 3157222, 3187709, 3187716, 3187494, 3186022, 3188105, 3183522, 3166280, 3183038, 3183531, 3183526, 3184327, 3166566, 3171992, 3172063, 3159074, 3181553, 3183529, 3146205, 3038908, 3038908, 3153396, 3038908, 3038908, 3038908, 3179111, 3152476, 3187446, 3219191
Verwandte CVE-Nummern	Nicht verfügbar

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

• Das Festlegen der Bildschirmauflösung einer ausgeschalteten, verschlüsselten virtuellen Maschine funktioniert nicht immer, wenn die VMX-Datei manuell bearbeitet wird

  Wenn Sie die Bildschirmauflösung einer ausgeschalteten, verschlüsselten virtuellen Maschine durch Bearbeiten der VMX-Datei manuell angeben, wird die Änderung möglicherweise nicht wirksam.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Warnung zur vorübergehenden vSAN-Integritätsprüfung: Netzwerkkonfiguration ist nicht synchronisiert

  Die vSAN Skyline-Integrität meldet möglicherweise nach dem Zufallsprinzip, dass die Netzwerkkonfiguration nicht synchronisiert ist. Dieses vorübergehende Problem tritt auf, wenn der vSAN-Integritätsdienst eine veraltete vCenter-Konfiguration verwendet, um eine Unicast-Prüfung durchzuführen.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Problem mit dem Überschreiben des vSAN-Cache kann zu inkonsistenten Metadaten führen

  In seltenen Fällen können Racing-Bedingungen zwischen Vorgängen zum Aufheben von Zuordnungen und Snapshots zu inkonsistenten vSAN-Metadaten auf einem vSAN-Host führen. Eine solche Inkonsistenz kann zu unvorhersehbaren Folgen führen, einschließlich VM- oder Host-Ausfällen.

  Dieses Problem wurde in der vorliegenden Version behoben.

• ESX-Hosts schlagen möglicherweise fehl mit einem violetten Diagnosebildschirm und einem Fehler NMI-IPI: Von einer anderen PCPU angeforderter Notfallalarm

  Der Ressourcenpool-Cache ist ein VMFS-spezifischer Cache auf Volume-Ebene, in dem die Ressourcencluster gespeichert werden, die dem VMFS-Volume entsprechen. Bei der Suche nach Clustern mit Priorität durchläuft der Cache-Bereinigungs-Workflow eine umfangreiche Liste mit zwischengespeicherten Ressourcenclustern, was zu einer Sperrung der physischen CPUs führen kann. Infolgedessen können ESX Hosts mit einem violetten Diagnosebildschirm fehlschlagen. In der Datei logDump wird ein Fehler ähnlich dem folgenden aufgeführt:

  ^[[7m2022-10-22T07:56:47.322Z cpu13:2101160)WARNING: Heartbeat: 827: PCPU 0 didn't have a heartbeat for 7 seconds, timeout is 14, 1 IPIs sent; *may* be locked up.^[[0m

  ^[[31;1m2022-10-22T07:56:47.322Z cpu0:2110633)ALERT: NMI: 710: NMI IPI: RIPOFF(base):RBP:CS

  Dieses Problem wurde in der vorliegenden Version behoben.

• ESXi ConfigStore-Datenbank füllt sich, und Schreibvorgänge schlagen fehl

  Veraltete Daten im Zusammenhang mit Blockgeräten werden möglicherweise nicht rechtzeitig aus der ESXi ConfigStore-Datenbank gelöscht und verursachen eine Bedingung für nicht ausreichenden Speicherplatz. Infolgedessen schlagen Schreibvorgänge in ConfigStore fehl. Im Backtrace werden Protokolle ähnlich dem folgenden angezeigt:

  2022-12-19T03:51:42.733Z cpu53:26745174)WARNING: VisorFSRam: 203: Cannot extend visorfs file /etc/vmware/configstore/current-store-1-journal because its ramdisk (configstore) is full.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Verzögerung vor der Evakuierung des vSAN-Speichergeräts im Zustand FEHLERHAFT

  Nachdem Geräte als FEHLERHAFT erkannt wurden, wartet der LSOM (Local Log-Structured Object Manager) möglicherweise 10 Minuten (LSOM_DEVICE_MONITORING_INTERVAL), bevor die Evakuierung auf diesen Geräten initiiert wird.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Die vSAN-Vorabprüfung für den Wartungsmodus oder die Außerbetriebnahme der Festplatte listet keine Objekte auf, die möglicherweise nicht mehr zugänglich sind

  Dieses Problem betrifft Objekte mit Neusynchronisierungskomponenten, und einige Komponenten befinden sich auf einem Gerät, das entfernt oder in den Wartungsmodus versetzt werden soll. Wenn Sie eine Vorabprüfung mit der Option No-Action ausführen, wertet die Vorabprüfung das Objekt nicht korrekt aus, um es in der Liste inaccessibleObjects zu melden.

  Dieses Problem wurde in der vorliegenden Version behoben. Die Vorabprüfung umfasst alle betroffenen Objekte in der Liste inaccessibleObjects.

• Der vSAN iSCSI-Zieldienst schlägt möglicherweise aufgrund einer seltenen Race-Bedingung fehl

  Wenn Sie den ESXCLI-Befehl esxcli network firewall load ausführen, lädt der Vorgang vorhandene dynamische Firewallregeln nicht neu, und sie gehen verloren. Wenn Sie den ESXCLI-Befehl esxcli network firewall refresh ausführen, lädt der Vorgang vorhandene dynamische Firewallregeln zwar neu, aber in einigen Fällen kann eine Race-Bedingung dazu führen, dass einige Regeln verloren gehen. Dieses Problem tritt nur auf, wenn mehrere Firewall-Aktualisierungsbefehle gleichzeitig ausgeführt werden, was zu einer Race-Bedingung führt. Infolgedessen kann der vSAN iSCSI-Zieldienst fehlschlagen.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Wenn das Internet Control Message Protocol (ICMPA) nicht aktiv ist, kann der Neustart des ESXi Hosts nach dem Upgrade auf vSphere 8.0 und höher lange dauern

  Wenn ICMPA auf den NFS-Servern in Ihrer Umgebung nicht aktiv ist, kann es nach dem Upgrade Ihres Systems auf vSphere 8.0 und höher eine Stunde dauern, bis der Neustart ESXi Hosts abgeschlossen ist, da Wiederherstellungsvorgänge für NFS-Datenspeicher fehlschlagen. NFS verwendet das Dienstprogramm vmkping, um erreichbare IPs der NFS-Server zu identifizieren, bevor ein Bereitstellungsvorgang ausgeführt wird. Wenn ICMP nicht aktiv ist, schlagen Bereitstellungsvorgänge fehl.

  Dieses Problem wurde in der vorliegenden Version behoben. Um die Abhängigkeit vom ICMP-Protokoll zum Auffinden erreichbarer IPs zu entfernen, fügt der Fix Socket-APIs hinzu, um sicherzustellen, dass IPs auf einem bestimmten NFS-Server verfügbar sind.

• Wenn Sie eine VM mit kürzlich im laufenden Betrieb hinzugefügtem Arbeitsspeicher migrieren, schlägt ein ESXi-Host möglicherweise wiederholt mit einem violetten Diagnosebildschirm fehl

  Aufgrund einer Race-Bedingung während der Neuberechnung des NUMA-Arbeitsspeicherlayouts einer VM auf einem Zielhost nach der Migration durch das Arbeitsspeicher-Hotplug-Modul schlägt ein ESXi-Host möglicherweise wiederholt mit einem violetten Diagnosebildschirm fehl. Im Backtrace werden Fehler angezeigt, wie z. B.:

  0x452900262cf0:[0x4200138fee8b]PanicvPanicInt@vmkernel#nover+0x327 stack: 0x452900262dc8, 0x4302f6c06508, 0x4200138fee8b, 0x420013df1300, 0x452900262cf0  0x452900262dc0:[0x4200138ff43d]Panic_WithBacktrace@vmkernel#nover+0x56 stack: 0x452900262e30, 0x452900262de0, 0x452900262e40, 0x452900262df0, 0x3e7514  0x452900262e30:[0x4200138fbb90]NMI_Interrupt@vmkernel#nover+0x561 stack: 0x0, 0xf48, 0x0, 0x0, 0x0  0x452900262f00:[0x420013953392]IDTNMIWork@vmkernel#nover+0x7f stack: 0x420049800000, 0x4200139546dd, 0x0, 0x452900262fd0, 0x0  0x452900262f20:[0x4200139546dc]Int2_NMI@vmkernel#nover+0x19 stack: 0x0, 0x42001394e068, 0xf50, 0xf50, 0x0  0x452900262f40:[0x42001394e067]gate_entry@vmkernel#nover+0x68 stack: 0x0, 0x43207bc02088, 0xd, 0x0, 0x43207bc02088  0x45397b61bd30:[0x420013be7514]NUMASched_PageNum2PhysicalDomain@vmkernel#nover+0x58 stack: 0x1, 0x420013be34c3, 0x45396f79f000, 0x1, 0x100005cf757  0x45397b61bd50:[0x420013be34c2]NUMASched_UpdateAllocStats@vmkernel#nover+0x4b stack: 0x100005cf757, 0x0, 0x0, 0x4200139b36d9, 0x0  0x45397b61bd80:[0x4200139b36d8]VmMem_NodeStatsSub@vmkernel#nover+0x59 stack: 0x39, 0x45396f79f000, 0xbce0dbf, 0x100005cf757, 0x0  0x45397b61bdc0:[0x4200139b4372]VmMem_FreePageNoBackmap@vmkernel#nover+0x8b stack: 0x465ec0001be0, 0xa, 0x465ec18748b0, 0x420014e7685f, 0x465ec14437d0

  Dieses Problem wurde in der vorliegenden Version behoben.

• Nach dem Upgrade des ntg3-Treibers auf Version 4.1.9.0-4vmw verlieren Broadcom-Netzwerkkarten mit physischer Glasfaserverbindung möglicherweise die Verbindung zum Netzwerk

  Änderungen an der ntg3-Treiberversion 4.1.9.0-4vmw führen möglicherweise zu Verbindungsfehlern für die physische Glasfaserschicht und zu Konnektivitätsproblemen auf einigen Netzwerkkarten (z. B. Broadcom 1Gb).

  Dieses Problem wurde in der vorliegenden Version behoben.

• Das Herunterfahren des vSAN-Clusters schlägt auf einem Cluster mit deaktiviertem IPv6 fehl

  Dieses Problem tritt auf vSAN-Hosts auf, auf denen ESXi 8.0 Update 1 mit deaktiviertem IPv6 ausgeführt wird. Wenn Sie den Assistenten zum Herunterfahren des vSAN-Clusters verwenden, schlägt der Workflow mit der folgenden Fehlermeldung fehl: 'NoneType' object is not iterable.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Trap-Dateien werden in einem SNMP-Verzeichnis unter /var/spool angezeigt, obwohl SNMP nicht aktiviert ist

  Nach dem Start des hostd-Diensts, z. B. nach einem Neustart des ESXi-Hosts, erstellt dieser möglicherweise ein SNMP-Verzeichnis unter /var/spool, und es sammeln sich viele .trp-Dateien in diesem Verzeichnis an.

  Dieses Problem wurde in der vorliegenden Version behoben. Mit dem Fix wird sichergestellt, dass das Verzeichnis /var/spool/snmp nur vorhanden ist, wenn SNMP aktiviert ist.

• Der hostd-Dienst schlägt wiederholt fehl, und der ESXi-Host wird vom vCenter-System getrennt

  Wenn ein ESXi-Host aus irgendeinem Grund vorübergehend nicht genügend Arbeitsspeicher aufweist, schlägt der hostd-Dienst aufgrund eines vSphere Replication-Filters, der die Zuteilung von Bitmaps verhindert, möglicherweise wiederholt fehl. Dies führt dazu, dass der ESXi-Host vom vCenter Server-System getrennt wird und nicht wieder verbunden werden kann.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Die Leistung bestimmter verschachtelter virtueller Maschinen auf AMD-CPUs kann sich verschlechtern

  Bei verschachtelten virtuellen Maschinen auf AMD-CPUs mit Betriebssystemen wie Windows mit virtualisierungsbasierter Sicherheit (VBS) kann es aufgrund eines Problems mit der Virtualisierung von AMD Rapid Virtualization Indexing (RVI), auch bekannt als Nested Page Tables (NPT), zu Leistungsbeeinträchtigungen, Zeitüberschreitungen oder fehlender Reaktion kommen.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Eine Modusänderung der virtuellen Festplatte einer ausgeführten virtuellen Maschine kann zum Fehlschlagen der VM führen

  Wenn Sie den VMware Host Client verwenden, um den Festplattenmodus einer ausgeführten virtuellen Maschine zu bearbeiten, z. B. von „Unabhängig – Nicht dauerhaft“ in „Abhängig“ oder „Unabhängig – Dauerhaft“, schlägt der Vorgang fehl und kann zu einem VM-Fehler führen. Im Protokoll „vmware.log“ werden Fehler angezeigt, wie z. B.:

  msg.disk.notConfigured2] Failed to configure disk 'scsi0:4'. The virtual machine cannot be powered on with an unconfigured disk.

  [msg.checkpoint.continuesync.error] An operation required the virtual machine to quiesce and the virtual machine was unable to continue running.

  Dieses Problem wurde in der vorliegenden Version behoben. Der Fix blockiert die Modusänderung einer Festplatte vom Typ „Unabhängig – Nicht persistent“ auf einer ausgeführten virtuellen Maschine mithilfe des VMware Host Client. Der vSphere Client blockiert derartige Vorgänge bereits.

• ESXi NVMe/TCP-Initiator kann nach der Zielfehlerwiederherstellung keine Pfade wiederherstellen

  Wenn ein NVMe/TCP-Ziel nach einem Ausfall wiederhergestellt wird, kann ESXi den Pfad nicht wiederherstellen.

  Dieses Problem wurde in der vorliegenden Version behoben.

• ESXi-Host reagiert nicht mehr, und Sie können den Host weder in den Wartungsmodus versetzen, noch VMs von diesem Host migrieren

  Das asynchrone Lesen von Metadaten auf einem an einen ESXi-Host angehängten VMFS-Volume kann zu einer Race-Bedingung mit anderen Threads auf dem Host und dazu führen, dass der Host nicht mehr reagiert. Infolgedessen können Sie den Host nicht in den Wartungsmodus versetzen oder keine VMs von diesem Host migrieren.

  Dieses Problem wurde in der vorliegenden Version behoben.

• In einigen Fällen kann es zu einem niedrigen Durchsatz bei gekapseltem Datenverkehr mit Mellanox-Netzwerkkarten kommen

  Im Modus „Nicht erweiterter Datenpfad“ ist der Durchsatz des gekapselten Datenverkehrs von Netzwerkkarten mit dem Mellanox-Treiber (nmlx5) möglicherweise niedrig, und es kann zu einem ungleichmäßigen Datenverkehrsfluss über RSS-Warteschlangen hinweg kommen.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Eine LVM-Festplatte (Logical Volume Manager) wird während der Datenspeichererweiterung offline geschaltet

  Wenn Sie während der Erweiterung eines Datenspeichers auf einem ESXi-Host in einem Cluster eine Speicheraktualisierung ausführen, wird eine LVM-Erweiterung möglicherweise offline geschaltet, und die virtuellen Maschinen auf diesem Volume reagieren nicht mehr. Das Problem tritt auf, weil die Speicheraktualisierung eine langsame Aktualisierung der Volume-Attribute auf allen ESXi-Hosts im Cluster auslöst. Dies führt dazu, dass die LVM-Metadaten auf der Festplatte möglicherweise nicht mit den zwischengespeicherten Kapazitätsinformationen in der PSA-Schicht (Pluggable Storage Architecture) übereinstimmen und dass ESXi die LVM-Erweiterung aus Gründen der Metadaten- und Datensicherheit offline markiert.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Der dauerhafte Name einer SCSI-LUN ist möglicherweise nicht festgelegt

  Die Eigenschaft des dauerhaften Namens für ein SCSI-3-konformes Gerät stammt aus Seiten 80h und 83h der wichtigen Produktdaten (VPD) gemäß Definition durch die T10- und SMI-Standards. Um den dauerhaften Namen aufzufüllen, sendet ESXi zuerst einen Anfragebefehl, um eine Liste der vom Gerät unterstützten VPD-Seiten abzurufen. Anschließend gibt ESXi Befehle aus, um Daten für alle unterstützten VPD-Seiten abzurufen. Aufgrund eines Problems mit dem Ziel-Array lässt das Gerät möglicherweise einen Befehl zum Abrufen von VPD-Seitendaten für eine Seite in der Liste mit einem Fehler vom Typ not supported fehlschlagen. Infolgedessen kann ESXi die Eigenschaft des dauerhaften Namens für das Gerät nicht auffüllen.

  Dieses Problem wurde in der vorliegenden Version behoben. Der Fix ignoriert den Fehler beim Befehl zum Abrufen von VPD-Seitendaten mit Ausnahme der Seiten 80h und 83h, wenn diese Daten für die Generierung eines dauerhaften Namens nicht erforderlich sind.

• Die automatische Erkennung des NVMe Discovery Service schlägt auf ESXi-Hosts mit NVMe/TCP-Konfigurationen möglicherweise fehl

  vSphere 8.0 bietet erweiterte NVMe-oF Discovery Service-Unterstützung in ESXi. Dies ermöglicht die dynamische Erkennung des standardkonformen NVMe Discovery Service. ESXi verwendet den mDNS/DNS-SD-Dienst, um Informationen wie IP-Adresse und Portnummer der aktiven NVMe-oF Discovery Services im Netzwerk abzurufen. In ESXi-Servern mit aktiviertem NVMe/TCP schlägt die automatische Erkennung in Netzwerken, die für die Verwendung des vSphere Distributed Switch konfiguriert sind, möglicherweise fehl. Das Problem wirkt sich nicht auf NVMe/TCP-Konfigurationen aus, die Standard-Switches verwenden.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Übermäßige Zeit für die Pfadwiederherstellung mit ESXi High Performance Plug-In (HPP) nach einem Link-Up-Ereignis für NVMe over Fibre Channel

  In bestimmten Szenarien kann es nach einem Link-Up-Ereignis für Fibre Channel bis zu 5 Minuten dauern, bis HPP-verwaltete NVMe over Fibre Channel-Pfade wiederhergestellt sind.

  Dieses Problem wurde in der vorliegenden Version behoben.

• NVMe over Fabrics-Controller kann während der Ermittlung möglicherweise unerwartet getrennt werden

  Wenn die Ermittlung und E/A-Controller bereits für ein NVMe over Fabrics-Speicherziel vorhanden sind, das einen persistenten Ermittlungscontroller auf einem ESXi-Host unterstützt, kann ein gleichzeitiger NVMe over Fabrics-Controller-Ermittlungsvorgang dazu führen, dass einige E/A-Controller unerwartet getrennt werden.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Wenn Ihr ESXi PTP-Dienst die Hardware-Zeitstempelung verwendet, kann die Aktivierung von IGMP-Snooping auf Switches zu Synchronisierungsfehlern führen

  Wenn Sie IGMP-Snooping (Internet Group Management Protocol) auf einem verbundenen Switch aktivieren, muss der PTP-Client (Precision Time Protocol) IGMP-Multicast-Anforderungen senden, um PTP-Multicast-Streams vom Hauptmaster zu empfangen. Wenn der ESXi PTP-Agent auf Hardware-Zeitstempelung basiert, kann der Agent möglicherweise keine IGMP-Beitritts-/Verlassen-Anforderungen an den Switch senden. Dies führt dazu, dass der PTP-Multicast-Stream nicht zum ESXi-Host weitergeleitet werden kann. Zudem wird eine ordnungsgemäße PTP-Synchronisierung verhindert.

  Dieses Problem wurde in der vorliegenden Version behoben. Weitere Einzelheiten finden Sie im VMware-Knowledgebase-Artikel 92276.

• Wenn parallele Volume-Erweiterungs- und Volume-Aktualisierungsvorgänge auf demselben VMFS-Volume auf zwei ESXi-Hosts im selben Cluster ausgeführt werden, wird das VMFS-Volume möglicherweise offline geschaltet

  Wenn bei der Ausführung eines VMFS-Volume-Erweiterungsvorgangs auf einem ESXi-Host in einem vCenter-Cluster von einem Benutzer oder vCenter auf einem anderen Host eine Aktualisierung derselben VMFS-Volume-Kapazität initiiert wird, wird ein derartiges Volume möglicherweise offline geschaltet. Das Problem tritt aufgrund einer möglichen Nichtübereinstimmung bei der Gerätegröße auf, die während einer erneuten Prüfung in den Volume-Metadaten auf der Festplatte mit einem Stempel versehen wird. Ein weiterer Grund ist der Wert für die Gerätegröße in der PSA-Schicht (Pluggable Storage Architecture) auf dem Host, der möglicherweise nicht aktualisiert wird, wenn die erneute Prüfung des Geräts nicht abgeschlossen ist.

  Dieses Problem wurde in der vorliegenden Version behoben. Durch den Fix wird die Stabilität des Volume-Manager-Codes verbessert, um eine aufeinander folgende Aktualisierung der Geräteattribute und einen erneuten Vergleich der Gerätegrößen zu erzwingen, wenn vCenter eine Nichtübereinstimmung bei der Gerätegröße meldet.

• Vorgänge mit statusfreien ESXi-Hosts wählen möglicherweise nicht die erwartete Remote-Festplatte für den Systemcache aus. Dies führt zu Standardisierungs- und Konformitätsproblemen

  Vorgänge mit statusfreien ESXi-Hosts, wie z. B. Speichermigration, wählen möglicherweise nicht die erwartete Remote-Festplatte für den Systemcache. Beispielsweise möchten Sie die neue Start-LUN als LUN 0 beibehalten, aber vSphere Auto Deploy wählt LUN 1 aus.

  Dieses Problem wurde in der vorliegenden Version behoben. Der Fix bietet eine konsistente Möglichkeit, die Remotefestplatten zu sortieren und immer die Festplatte mit der niedrigsten LUN-ID auszuwählen. Um sicherzustellen, dass Sie den Fix aktivieren, führen Sie die folgenden Schritte aus:

  1. Wählen Sie auf der Seite „Hostprofil bearbeiten“ des Auto Deploy-Assistenten Erweiterte Konfigurationseinstellungen > System-Image-Cache-Konfiguration aus.

  2. Wählen Sie im Dropdown-Menü Profileinstellungen für System-Image-Cache die Option Statusfreies Caching auf dem Host aktivieren aus.

  3. Bearbeiten Sie Argumente für erste Festplatte, indem Sie remote durch sortedremote und/oder remoteesx durch sortedremoteesx ersetzen.

• VMware VIB-Installation schlägt während gleichzeitigen Anbieterpaketinstallationen möglicherweise fehl

  Wenn Sie Update-Pakete von verschiedenen Anbietern wie JetStream Software, Microsoft und VMware installieren, rufen mehrere Clients dieselben PatchManager-APIs auf. Dies kann zu einer Race-Bedingung führen. Infolgedessen werden die VMware-Installationspakete (VIBs) möglicherweise nicht installiert. In den Protokollen wird ein Fehler wie vim.fault.PlatformConfigFault angezeigt. Hierbei handelt es sich um einen Auffangfehler, der darauf hinweist, dass bei der Konfiguration des ESXi-Hosts ein Fehler aufgetreten ist. Im vSphere Client wird eine Meldung ähnlich der folgenden angezeigt: An error occurred during host configuration.

  Dieses Problem wurde in der vorliegenden Version behoben. Durch den Fix wird eine TaskInProgress-Warnung anstelle von PlatformConfigFault zurückgegeben, damit Sie das tatsächliche Problem kennen und die Installation wiederholen können.

• Bestimmte Anwendungen benötigen möglicherweise zu viele ESXi-Datei-Handles und verursachen Leistungsbeeinträchtigungen

  In sehr seltenen Fällen können Anwendungen wie NVIDIA virtual GPU (vGPU) so viele Datei-Handles verwenden, dass ESXi andere Dienste oder VMs nicht verarbeiten kann. Infolgedessen wird die GPU auf einigen Knoten nicht mehr angezeigt, oder es wird gemeldet, dass kein GPU-Arbeitsspeicher vorhanden oder dass die Leistung beeinträchtigt ist.

  Dieses Problem wurde in der vorliegenden Version behoben. Der Fix reduziert die Anzahl Datei-Handles, die eine vGPU-VM verwenden kann.

ESXi-8.0U1c-22088125-no-tools

Profilname	ESXi-8.0U1c-22088125-no-tools
Build	Build-Informationen finden Sie unter In dieser Version enthaltene Patches.
Anbieter	VMware, Inc.
Datum der Veröffentlichung	27. Juli 2023
Akzeptanzebene	Unterstützte Partner
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Betroffene VIBs	VMware_bootbank_vdfs_8.0.1-0.25.22088125 VMW_bootbank_nvmetcp_1.0.1.7-1vmw.801.0.25.22088125 VMW_bootbank_ntg3_4.1.10.0-5vmw.801.0.25.22088125 VMW_bootbank_nmlx5-rdma-esxio_4.23.0.36-15vmw.801.0.25.22088125 VMware_bootbank_gc_8.0.1-0.25.22088125 VMware_bootbank_native-misc-drivers_8.0.1-0.25.22088125 VMware_bootbank_cpu-microcode_8.0.1-0.25.22088125 VMware_bootbank_esx-dvfilter-generic-fastpath_8.0.1-0.25.22088125 VMware_bootbank_vds-vsip_8.0.1-0.25.22088125 VMware_bootbank_esxio-dvfilter-generic-fastpath_8.0.1-0.25.22088125 VMware_bootbank_loadesxio_8.0.1-0.25.22088125 VMware_bootbank_loadesx_8.0.1-0.25.22088125 VMware_bootbank_gc-esxio_8.0.1-0.25.22088125 VMware_bootbank_esxio-combiner_8.0.1-0.25.22088125 VMW_bootbank_nmlx5-core_4.23.0.36-15vmw.801.0.25.22088125 VMware_bootbank_esxio-update_8.0.1-0.25.22088125 VMware_bootbank_esx-update_8.0.1-0.25.22088125 VMware_bootbank_vsan_8.0.1-0.25.22088125 VMware_bootbank_crx_8.0.1-0.25.22088125 VMW_bootbank_nmlx5-rdma_4.23.0.36-15vmw.801.0.25.22088125 VMware_bootbank_bmcal_8.0.1-0.25.22088125 VMware_bootbank_esx-xserver_8.0.1-0.25.22088125 VMware_bootbank_trx_8.0.1-0.25.22088125 VMware_bootbank_esxio-combiner-esxio_8.0.1-0.25.22088125 VMware_bootbank_esxio-base_8.0.1-0.25.22088125 VMware_bootbank_clusterstore_8.0.1-0.25.22088125 VMware_bootbank_native-misc-drivers-esxio_8.0.1-0.25.22088125 VMware_bootbank_esxio_8.0.1-0.25.22088125 VMware_bootbank_bmcal-esxio_8.0.1-0.25.22088125 VMware_bootbank_esx-base_8.0.1-0.25.22088125 VMware_bootbank_vsanhealth_8.0.1-0.25.22088125 VMW_bootbank_nmlx5-core-esxio_4.23.0.36-15vmw.801.0.25.22088125
Behobene Probleme	3239946, 3239870, 3210610, 3228383, 3248279, 3179236, 3183209, 3219196, 3229111, 3221890, 3219889, 3223909, 3225464, 3228391, 3158175, 3217410, 3211624, 3223427, 3223420, 3181600, 3212384, 3221902, 3219121, 3219196, 3222717, 3221598, 3210610, 3181603, 3213042, 3221593, 3210931, 3210931, 3221549, 3161147, 3213110, 3219262, 3118977, 3217167, 3210610, 3210610, 3219971, 3112043, 3218145, 3218218, 3217477, 3214491, 3166665, 3210840, 3210837, 3210956, 3213914, 3212431, 3187725, 3213177, 3185230, 3213207, 3187539, 2625439, 3122074, 3197383, 3187416, 3187420, 3118241, 3176359, 3184331, 3182257, 3187875, 3187547, 3210192, 3180881, 3163270, 3179236, 3157222, 3187709, 3187716, 3187494, 3186022, 3188105, 3183522, 3166280, 3183038, 3183531, 3183526, 3184327, 3166566, 3171992, 3172063, 3159074, 3181553, 3183529, 3146205, 3038908, 3038908, 3153396, 3038908, 3038908, 3038908, 3179111, 3152476, 3187446, 3219191
Verwandte CVE-Nummern	Nicht verfügbar

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

• Das Festlegen der Bildschirmauflösung einer ausgeschalteten, verschlüsselten virtuellen Maschine funktioniert nicht immer, wenn die VMX-Datei manuell bearbeitet wird

  Wenn Sie die Bildschirmauflösung einer ausgeschalteten, verschlüsselten virtuellen Maschine durch Bearbeiten der VMX-Datei manuell angeben, wird die Änderung möglicherweise nicht wirksam.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Warnung zur vorübergehenden vSAN-Integritätsprüfung: Netzwerkkonfiguration ist nicht synchronisiert

  Die vSAN Skyline-Integrität meldet möglicherweise nach dem Zufallsprinzip, dass die Netzwerkkonfiguration nicht synchronisiert ist. Dieses vorübergehende Problem tritt auf, wenn der vSAN-Integritätsdienst eine veraltete vCenter-Konfiguration verwendet, um eine Unicast-Prüfung durchzuführen.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Problem mit dem Überschreiben des vSAN-Cache kann zu inkonsistenten Metadaten führen

  In seltenen Fällen können Racing-Bedingungen zwischen Vorgängen zum Aufheben von Zuordnungen und Snapshots zu inkonsistenten vSAN-Metadaten auf einem vSAN-Host führen. Eine solche Inkonsistenz kann zu unvorhersehbaren Folgen führen, einschließlich VM- oder Host-Ausfällen.

  Dieses Problem wurde in der vorliegenden Version behoben.

• ESX-Hosts schlagen möglicherweise fehl mit einem violetten Diagnosebildschirm und einem Fehler NMI-IPI: Von einer anderen PCPU angeforderter Notfallalarm

  Der Ressourcenpool-Cache ist ein VMFS-spezifischer Cache auf Volume-Ebene, in dem die Ressourcencluster gespeichert werden, die dem VMFS-Volume entsprechen. Bei der Suche nach Clustern mit Priorität durchläuft der Cache-Bereinigungs-Workflow eine umfangreiche Liste mit zwischengespeicherten Ressourcenclustern, was zu einer Sperrung der physischen CPUs führen kann. Infolgedessen können ESX Hosts mit einem violetten Diagnosebildschirm fehlschlagen. In der Datei logDump wird ein Fehler ähnlich dem folgenden aufgeführt:

  ^[[7m2022-10-22T07:56:47.322Z cpu13:2101160)WARNING: Heartbeat: 827: PCPU 0 didn't have a heartbeat for 7 seconds, timeout is 14, 1 IPIs sent; *may* be locked up.^[[0m

  ^[[31;1m2022-10-22T07:56:47.322Z cpu0:2110633)ALERT: NMI: 710: NMI IPI: RIPOFF(base):RBP:CS

  Dieses Problem wurde in der vorliegenden Version behoben.

• ESXi ConfigStore-Datenbank füllt sich, und Schreibvorgänge schlagen fehl

  Veraltete Daten im Zusammenhang mit Blockgeräten werden möglicherweise nicht rechtzeitig aus der ESXi ConfigStore-Datenbank gelöscht und verursachen eine Bedingung für nicht ausreichenden Speicherplatz. Infolgedessen schlagen Schreibvorgänge in ConfigStore fehl. Im Backtrace werden Protokolle ähnlich dem folgenden angezeigt:

  2022-12-19T03:51:42.733Z cpu53:26745174)WARNING: VisorFSRam: 203: Cannot extend visorfs file /etc/vmware/configstore/current-store-1-journal because its ramdisk (configstore) is full.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Verzögerung vor der Evakuierung des vSAN-Speichergeräts im Zustand FEHLERHAFT

  Nachdem Geräte als FEHLERHAFT erkannt wurden, wartet der LSOM (Local Log-Structured Object Manager) möglicherweise 10 Minuten (LSOM_DEVICE_MONITORING_INTERVAL), bevor die Evakuierung auf diesen Geräten initiiert wird.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Die vSAN-Vorabprüfung für den Wartungsmodus oder die Außerbetriebnahme der Festplatte listet keine Objekte auf, die möglicherweise nicht mehr zugänglich sind

  Dieses Problem betrifft Objekte mit Neusynchronisierungskomponenten, und einige Komponenten befinden sich auf einem Gerät, das entfernt oder in den Wartungsmodus versetzt werden soll. Wenn Sie eine Vorabprüfung mit der Option No-Action ausführen, wertet die Vorabprüfung das Objekt nicht korrekt aus, um es in der Liste inaccessibleObjects zu melden.

  Dieses Problem wurde in der vorliegenden Version behoben. Die Vorabprüfung umfasst alle betroffenen Objekte in der Liste inaccessibleObjects.

• Der vSAN iSCSI-Zieldienst schlägt möglicherweise aufgrund einer seltenen Race-Bedingung fehl

  Wenn Sie den ESXCLI-Befehl esxcli network firewall load ausführen, lädt der Vorgang vorhandene dynamische Firewallregeln nicht neu, und sie gehen verloren. Wenn Sie den ESXCLI-Befehl esxcli network firewall refresh ausführen, lädt der Vorgang vorhandene dynamische Firewallregeln zwar neu, aber in einigen Fällen kann eine Race-Bedingung dazu führen, dass einige Regeln verloren gehen. Dieses Problem tritt nur auf, wenn mehrere Firewall-Aktualisierungsbefehle gleichzeitig ausgeführt werden, was zu einer Race-Bedingung führt. Infolgedessen kann der vSAN iSCSI-Zieldienst fehlschlagen.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Wenn das Internet Control Message Protocol (ICMPA) nicht aktiv ist, kann der Neustart des ESXi Hosts nach dem Upgrade auf vSphere 8.0 und höher lange dauern

  Wenn ICMPA auf den NFS-Servern in Ihrer Umgebung nicht aktiv ist, kann es nach dem Upgrade Ihres Systems auf vSphere 8.0 und höher eine Stunde dauern, bis der Neustart ESXi Hosts abgeschlossen ist, da Wiederherstellungsvorgänge für NFS-Datenspeicher fehlschlagen. NFS verwendet das Dienstprogramm vmkping, um erreichbare IPs der NFS-Server zu identifizieren, bevor ein Bereitstellungsvorgang ausgeführt wird. Wenn ICMP nicht aktiv ist, schlagen Bereitstellungsvorgänge fehl.

  Dieses Problem wurde in der vorliegenden Version behoben. Um die Abhängigkeit vom ICMP-Protokoll zum Auffinden erreichbarer IPs zu entfernen, fügt der Fix Socket-APIs hinzu, um sicherzustellen, dass IPs auf einem bestimmten NFS-Server verfügbar sind.

• Wenn Sie eine VM mit kürzlich im laufenden Betrieb hinzugefügtem Arbeitsspeicher migrieren, schlägt ein ESXi-Host möglicherweise wiederholt mit einem violetten Diagnosebildschirm fehl

  Aufgrund einer Race-Bedingung während der Neuberechnung des NUMA-Arbeitsspeicherlayouts einer VM auf einem Zielhost nach der Migration durch das Arbeitsspeicher-Hotplug-Modul schlägt ein ESXi-Host möglicherweise wiederholt mit einem violetten Diagnosebildschirm fehl. Im Backtrace werden Fehler angezeigt, wie z. B.:

  0x452900262cf0:[0x4200138fee8b]PanicvPanicInt@vmkernel#nover+0x327 stack: 0x452900262dc8, 0x4302f6c06508, 0x4200138fee8b, 0x420013df1300, 0x452900262cf0  0x452900262dc0:[0x4200138ff43d]Panic_WithBacktrace@vmkernel#nover+0x56 stack: 0x452900262e30, 0x452900262de0, 0x452900262e40, 0x452900262df0, 0x3e7514  0x452900262e30:[0x4200138fbb90]NMI_Interrupt@vmkernel#nover+0x561 stack: 0x0, 0xf48, 0x0, 0x0, 0x0  0x452900262f00:[0x420013953392]IDTNMIWork@vmkernel#nover+0x7f stack: 0x420049800000, 0x4200139546dd, 0x0, 0x452900262fd0, 0x0  0x452900262f20:[0x4200139546dc]Int2_NMI@vmkernel#nover+0x19 stack: 0x0, 0x42001394e068, 0xf50, 0xf50, 0x0  0x452900262f40:[0x42001394e067]gate_entry@vmkernel#nover+0x68 stack: 0x0, 0x43207bc02088, 0xd, 0x0, 0x43207bc02088  0x45397b61bd30:[0x420013be7514]NUMASched_PageNum2PhysicalDomain@vmkernel#nover+0x58 stack: 0x1, 0x420013be34c3, 0x45396f79f000, 0x1, 0x100005cf757  0x45397b61bd50:[0x420013be34c2]NUMASched_UpdateAllocStats@vmkernel#nover+0x4b stack: 0x100005cf757, 0x0, 0x0, 0x4200139b36d9, 0x0  0x45397b61bd80:[0x4200139b36d8]VmMem_NodeStatsSub@vmkernel#nover+0x59 stack: 0x39, 0x45396f79f000, 0xbce0dbf, 0x100005cf757, 0x0  0x45397b61bdc0:[0x4200139b4372]VmMem_FreePageNoBackmap@vmkernel#nover+0x8b stack: 0x465ec0001be0, 0xa, 0x465ec18748b0, 0x420014e7685f, 0x465ec14437d0

  Dieses Problem wurde in der vorliegenden Version behoben.

• Nach dem Upgrade des ntg3-Treibers auf Version 4.1.9.0-4vmw verlieren Broadcom-Netzwerkkarten mit physischer Glasfaserverbindung möglicherweise die Verbindung zum Netzwerk

  Änderungen an der ntg3-Treiberversion 4.1.9.0-4vmw führen möglicherweise zu Verbindungsfehlern für die physische Glasfaserschicht und zu Konnektivitätsproblemen auf einigen Netzwerkkarten (z. B. Broadcom 1Gb).

  Dieses Problem wurde in der vorliegenden Version behoben.

• Das Herunterfahren des vSAN-Clusters schlägt auf einem Cluster mit deaktiviertem IPv6 fehl

  Dieses Problem tritt auf vSAN-Hosts auf, auf denen ESXi 8.0 Update 1 mit deaktiviertem IPv6 ausgeführt wird. Wenn Sie den Assistenten zum Herunterfahren des vSAN-Clusters verwenden, schlägt der Workflow mit der folgenden Fehlermeldung fehl: 'NoneType' object is not iterable.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Trap-Dateien werden in einem SNMP-Verzeichnis unter /var/spool angezeigt, obwohl SNMP nicht aktiviert ist

  Nach dem Start des hostd-Diensts, z. B. nach einem Neustart des ESXi-Hosts, erstellt dieser möglicherweise ein SNMP-Verzeichnis unter /var/spool, und es sammeln sich viele .trp-Dateien in diesem Verzeichnis an.

  Dieses Problem wurde in der vorliegenden Version behoben. Mit dem Fix wird sichergestellt, dass das Verzeichnis /var/spool/snmp nur vorhanden ist, wenn SNMP aktiviert ist.

• Der hostd-Dienst schlägt wiederholt fehl, und der ESXi-Host wird vom vCenter-System getrennt

  Wenn ein ESXi-Host aus irgendeinem Grund vorübergehend nicht genügend Arbeitsspeicher aufweist, schlägt der hostd-Dienst aufgrund eines vSphere Replication-Filters, der die Zuteilung von Bitmaps verhindert, möglicherweise wiederholt fehl. Dies führt dazu, dass der ESXi-Host vom vCenter Server-System getrennt wird und nicht wieder verbunden werden kann.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Die Leistung bestimmter verschachtelter virtueller Maschinen auf AMD-CPUs kann sich verschlechtern

  Bei verschachtelten virtuellen Maschinen auf AMD-CPUs mit Betriebssystemen wie Windows mit virtualisierungsbasierter Sicherheit (VBS) kann es aufgrund eines Problems mit der Virtualisierung von AMD Rapid Virtualization Indexing (RVI), auch bekannt als Nested Page Tables (NPT), zu Leistungsbeeinträchtigungen, Zeitüberschreitungen oder fehlender Reaktion kommen.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Eine Modusänderung der virtuellen Festplatte einer ausgeführten virtuellen Maschine kann zum Fehlschlagen der VM führen

  Wenn Sie den VMware Host Client verwenden, um den Festplattenmodus einer ausgeführten virtuellen Maschine zu bearbeiten, z. B. von „Unabhängig – Nicht dauerhaft“ in „Abhängig“ oder „Unabhängig – Dauerhaft“, schlägt der Vorgang fehl und kann zu einem VM-Fehler führen. Im Protokoll „vmware.log“ werden Fehler angezeigt, wie z. B.:

  msg.disk.notConfigured2] Failed to configure disk 'scsi0:4'. The virtual machine cannot be powered on with an unconfigured disk.

  [msg.checkpoint.continuesync.error] An operation required the virtual machine to quiesce and the virtual machine was unable to continue running.

  Dieses Problem wurde in der vorliegenden Version behoben. Der Fix blockiert die Modusänderung einer Festplatte vom Typ „Unabhängig – Nicht persistent“ auf einer ausgeführten virtuellen Maschine mithilfe des VMware Host Client. Der vSphere Client blockiert derartige Vorgänge bereits.

• ESXi NVMe/TCP-Initiator kann nach der Zielfehlerwiederherstellung keine Pfade wiederherstellen

  Wenn ein NVMe/TCP-Ziel nach einem Ausfall wiederhergestellt wird, kann ESXi den Pfad nicht wiederherstellen.

  Dieses Problem wurde in der vorliegenden Version behoben.

• ESXi-Host reagiert nicht mehr, und Sie können den Host weder in den Wartungsmodus versetzen, noch VMs von diesem Host migrieren

  Das asynchrone Lesen von Metadaten auf einem an einen ESXi-Host angehängten VMFS-Volume kann zu einer Race-Bedingung mit anderen Threads auf dem Host und dazu führen, dass der Host nicht mehr reagiert. Infolgedessen können Sie den Host nicht in den Wartungsmodus versetzen oder keine VMs von diesem Host migrieren.

  Dieses Problem wurde in der vorliegenden Version behoben.

• In einigen Fällen kann es zu einem niedrigen Durchsatz bei gekapseltem Datenverkehr mit Mellanox-Netzwerkkarten kommen

  Im Modus „Nicht erweiterter Datenpfad“ ist der Durchsatz des gekapselten Datenverkehrs von Netzwerkkarten mit dem Mellanox-Treiber (nmlx5) möglicherweise niedrig, und es kann zu einem ungleichmäßigen Datenverkehrsfluss über RSS-Warteschlangen hinweg kommen.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Eine LVM-Festplatte (Logical Volume Manager) wird während der Datenspeichererweiterung offline geschaltet

  Wenn Sie während der Erweiterung eines Datenspeichers auf einem ESXi-Host in einem Cluster eine Speicheraktualisierung ausführen, wird eine LVM-Erweiterung möglicherweise offline geschaltet, und die virtuellen Maschinen auf diesem Volume reagieren nicht mehr. Das Problem tritt auf, weil die Speicheraktualisierung eine langsame Aktualisierung der Volume-Attribute auf allen ESXi-Hosts im Cluster auslöst. Dies führt dazu, dass die LVM-Metadaten auf der Festplatte möglicherweise nicht mit den zwischengespeicherten Kapazitätsinformationen in der PSA-Schicht (Pluggable Storage Architecture) übereinstimmen und dass ESXi die LVM-Erweiterung aus Gründen der Metadaten- und Datensicherheit offline markiert.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Der dauerhafte Name einer SCSI-LUN ist möglicherweise nicht festgelegt

  Die Eigenschaft des dauerhaften Namens für ein SCSI-3-konformes Gerät stammt aus Seiten 80h und 83h der wichtigen Produktdaten (VPD) gemäß Definition durch die T10- und SMI-Standards. Um den dauerhaften Namen aufzufüllen, sendet ESXi zuerst einen Anfragebefehl, um eine Liste der vom Gerät unterstützten VPD-Seiten abzurufen. Anschließend gibt ESXi Befehle aus, um Daten für alle unterstützten VPD-Seiten abzurufen. Aufgrund eines Problems mit dem Ziel-Array lässt das Gerät möglicherweise einen Befehl zum Abrufen von VPD-Seitendaten für eine Seite in der Liste mit einem Fehler vom Typ not supported fehlschlagen. Infolgedessen kann ESXi die Eigenschaft des dauerhaften Namens für das Gerät nicht auffüllen.

  Dieses Problem wurde in der vorliegenden Version behoben. Der Fix ignoriert den Fehler beim Befehl zum Abrufen von VPD-Seitendaten mit Ausnahme der Seiten 80h und 83h, wenn diese Daten für die Generierung eines dauerhaften Namens nicht erforderlich sind.

• Die automatische Erkennung des NVMe Discovery Service schlägt auf ESXi-Hosts mit NVMe/TCP-Konfigurationen möglicherweise fehl

  vSphere 8.0 bietet erweiterte NVMe-oF Discovery Service-Unterstützung in ESXi. Dies ermöglicht die dynamische Erkennung des standardkonformen NVMe Discovery Service. ESXi verwendet den mDNS/DNS-SD-Dienst, um Informationen wie IP-Adresse und Portnummer der aktiven NVMe-oF Discovery Services im Netzwerk abzurufen. In ESXi-Servern mit aktiviertem NVMe/TCP schlägt die automatische Erkennung in Netzwerken, die für die Verwendung des vSphere Distributed Switch konfiguriert sind, möglicherweise fehl. Das Problem wirkt sich nicht auf NVMe/TCP-Konfigurationen aus, die Standard-Switches verwenden.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Übermäßige Zeit für die Pfadwiederherstellung mit ESXi High Performance Plug-In (HPP) nach einem Link-Up-Ereignis für NVMe over Fibre Channel

  In bestimmten Szenarien kann es nach einem Link-Up-Ereignis für Fibre Channel bis zu 5 Minuten dauern, bis HPP-verwaltete NVMe over Fibre Channel-Pfade wiederhergestellt sind.

  Dieses Problem wurde in der vorliegenden Version behoben.

• NVMe over Fabrics-Controller kann während der Ermittlung möglicherweise unerwartet getrennt werden

  Wenn die Ermittlung und E/A-Controller bereits für ein NVMe over Fabrics-Speicherziel vorhanden sind, das einen persistenten Ermittlungscontroller auf einem ESXi-Host unterstützt, kann ein gleichzeitiger NVMe over Fabrics-Controller-Ermittlungsvorgang dazu führen, dass einige E/A-Controller unerwartet getrennt werden.

  Dieses Problem wurde in der vorliegenden Version behoben.

• Wenn Ihr ESXi PTP-Dienst die Hardware-Zeitstempelung verwendet, kann die Aktivierung von IGMP-Snooping auf Switches zu Synchronisierungsfehlern führen

  Wenn Sie IGMP-Snooping (Internet Group Management Protocol) auf einem verbundenen Switch aktivieren, muss der PTP-Client (Precision Time Protocol) IGMP-Multicast-Anforderungen senden, um PTP-Multicast-Streams vom Hauptmaster zu empfangen. Wenn der ESXi PTP-Agent auf Hardware-Zeitstempelung basiert, kann der Agent möglicherweise keine IGMP-Beitritts-/Verlassen-Anforderungen an den Switch senden. Dies führt dazu, dass der PTP-Multicast-Stream nicht zum ESXi-Host weitergeleitet werden kann. Zudem wird eine ordnungsgemäße PTP-Synchronisierung verhindert.

  Dieses Problem wurde in der vorliegenden Version behoben. Weitere Einzelheiten finden Sie im VMware-Knowledgebase-Artikel 92276.

• Wenn parallele Volume-Erweiterungs- und Volume-Aktualisierungsvorgänge auf demselben VMFS-Volume auf zwei ESXi-Hosts im selben Cluster ausgeführt werden, wird das VMFS-Volume möglicherweise offline geschaltet

  Wenn bei der Ausführung eines VMFS-Volume-Erweiterungsvorgangs auf einem ESXi-Host in einem vCenter-Cluster von einem Benutzer oder vCenter auf einem anderen Host eine Aktualisierung derselben VMFS-Volume-Kapazität initiiert wird, wird ein derartiges Volume möglicherweise offline geschaltet. Das Problem tritt aufgrund einer möglichen Nichtübereinstimmung bei der Gerätegröße auf, die während einer erneuten Prüfung in den Volume-Metadaten auf der Festplatte mit einem Stempel versehen wird. Ein weiterer Grund ist der Wert für die Gerätegröße in der PSA-Schicht (Pluggable Storage Architecture) auf dem Host, der möglicherweise nicht aktualisiert wird, wenn die erneute Prüfung des Geräts nicht abgeschlossen ist.

  Dieses Problem wurde in der vorliegenden Version behoben. Durch den Fix wird die Stabilität des Volume-Manager-Codes verbessert, um eine aufeinander folgende Aktualisierung der Geräteattribute und einen erneuten Vergleich der Gerätegrößen zu erzwingen, wenn vCenter eine Nichtübereinstimmung bei der Gerätegröße meldet.

• Vorgänge mit statusfreien ESXi-Hosts wählen möglicherweise nicht die erwartete Remote-Festplatte für den Systemcache aus. Dies führt zu Standardisierungs- und Konformitätsproblemen

  Vorgänge mit statusfreien ESXi-Hosts, wie z. B. Speichermigration, wählen möglicherweise nicht die erwartete Remote-Festplatte für den Systemcache. Beispielsweise möchten Sie die neue Start-LUN als LUN 0 beibehalten, aber vSphere Auto Deploy wählt LUN 1 aus.

  Dieses Problem wurde in der vorliegenden Version behoben. Der Fix bietet eine konsistente Möglichkeit, die Remotefestplatten zu sortieren und immer die Festplatte mit der niedrigsten LUN-ID auszuwählen. Um sicherzustellen, dass Sie den Fix aktivieren, führen Sie die folgenden Schritte aus:

  1. Wählen Sie auf der Seite „Hostprofil bearbeiten“ des Auto Deploy-Assistenten Erweiterte Konfigurationseinstellungen > System-Image-Cache-Konfiguration aus.

  2. Wählen Sie im Dropdown-Menü Profileinstellungen für System-Image-Cache die Option Statusfreies Caching auf dem Host aktivieren aus.

  3. Bearbeiten Sie Argumente für erste Festplatte, indem Sie remote durch sortedremote und/oder remoteesx durch sortedremoteesx ersetzen.

• VMware VIB-Installation schlägt während gleichzeitigen Anbieterpaketinstallationen möglicherweise fehl

  Wenn Sie Update-Pakete von verschiedenen Anbietern wie JetStream Software, Microsoft und VMware installieren, rufen mehrere Clients dieselben PatchManager-APIs auf. Dies kann zu einer Race-Bedingung führen. Infolgedessen werden die VMware-Installationspakete (VIBs) möglicherweise nicht installiert. In den Protokollen wird ein Fehler wie vim.fault.PlatformConfigFault angezeigt. Hierbei handelt es sich um einen Auffangfehler, der darauf hinweist, dass bei der Konfiguration des ESXi-Hosts ein Fehler aufgetreten ist. Im vSphere Client wird eine Meldung ähnlich der folgenden angezeigt: An error occurred during host configuration.

  Dieses Problem wurde in der vorliegenden Version behoben. Durch den Fix wird eine TaskInProgress-Warnung anstelle von PlatformConfigFault zurückgegeben, damit Sie das tatsächliche Problem kennen und die Installation wiederholen können.

• Bestimmte Anwendungen benötigen möglicherweise zu viele ESXi-Datei-Handles und verursachen Leistungsbeeinträchtigungen

  In sehr seltenen Fällen können Anwendungen wie NVIDIA virtual GPU (vGPU) so viele Datei-Handles verwenden, dass ESXi andere Dienste oder VMs nicht verarbeiten kann. Infolgedessen wird die GPU auf einigen Knoten nicht mehr angezeigt, oder es wird gemeldet, dass kein GPU-Arbeitsspeicher vorhanden oder dass die Leistung beeinträchtigt ist.

  Dieses Problem wurde in der vorliegenden Version behoben. Der Fix reduziert die Anzahl Datei-Handles, die eine vGPU-VM verwenden kann.

ESXi-8.0U1sc-22082334-standard

Profilname	ESXi-8.0U1c-22082334-standard
Build	Build-Informationen finden Sie unter In dieser Version enthaltene Patches.
Anbieter	VMware, Inc.
Datum der Veröffentlichung	27. Juli 2023
Akzeptanzebene	Unterstützte Partner
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Betroffene VIBs	VMware_bootbank_bmcal-esxio_8.0.1-0.20.22082334 VMware_bootbank_native-misc-drivers_8.0.1-0.20.22082334 VMware_bootbank_esx-dvfilter-generic-fastpath_8.0.1-0.20.22082334 VMware_bootbank_vsan_8.0.1-0.20.22082334 VMware_bootbank_bmcal_8.0.1-0.20.22082334 VMware_bootbank_esx-base_8.0.1-0.20.22082334 VMware_bootbank_trx_8.0.1-0.20.22082334 VMware_bootbank_gc-esxio_8.0.1-0.20.22082334 VMware_bootbank_gc_8.0.1-0.20.22082334 VMware_bootbank_esxio_8.0.1-0.20.22082334 VMware_bootbank_esx-xserver_8.0.1-0.20.22082334 VMware_bootbank_cpu-microcode_8.0.1-0.20.22082334 VMware_bootbank_esxio-combiner-esxio_8.0.1-0.20.22082334 VMware_bootbank_esxio-dvfilter-generic-fastpath_8.0.1-0.20.22082334 VMware_bootbank_vsanhealth_8.0.1-0.20.22082334 VMware_bootbank_vds-vsip_8.0.1-0.20.22082334 VMware_bootbank_clusterstore_8.0.1-0.20.22082334 VMware_bootbank_native-misc-drivers-esxio_8.0.1-0.20.22082334 VMware_bootbank_esxio-combiner_8.0.1-0.20.22082334 VMware_bootbank_esxio-base_8.0.1-0.20.22082334 VMware_bootbank_vdfs_8.0.1-0.20.22082334 VMware_bootbank_crx_8.0.1-0.20.22082334 VMware_bootbank_esx-update_8.0.1-0.20.22082334 VMware_bootbank_loadesx_8.0.1-0.20.22082334 VMware_bootbank_loadesxio_8.0.1-0.20.22082334 VMware_bootbank_esxio-update_8.0.1-0.20.22082334 VMware_locker_tools-light_12.2.5.21855600-22082334
Behobene Probleme	3229052, 3222888, 3184515, 3184505, 3210921, 3219294, 3217139, 3215295, 3184512, 3184517, 3213042, 3184513, 3184506, 3186149, 3186166
Verwandte CVE-Nummern	Nicht verfügbar

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

• ESXi 8.0 Update 1c stellt die folgenden Sicherheits-Updates bereit:

  • Der Envoy-Proxy wird auf Version v1.23.9 aktualisiert.

  • Die userworld-libxml2-Bibliothek von ESXi wird auf Version 2.10.4 aktualisiert.

  • Die cURL-Bibliothek wird auf Version 8.0.1 aktualisiert.

  • Die Go-Bibliothek wird auf Version 1.19.9 aktualisiert.

  • Das etcd-Paket wird auf 3.4.25 aktualisiert.

• Aktualisiert das VIB tools-light.

  • Die folgenden VMware Tools-ISO-Images werden mit dem ESXi 8.0 Update 1c gebündelt:

    • windows.iso: VMware Tools 12.2.5 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. VMware Tools 12.1.0 war die letzte reguläre Version für macOS. Details finden Sie im VMware-Knowledgebase-Artikel 88698.

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

    • Aktualisieren von VMware Tools

    • VMware Tools für Hosts, die mit Auto Deploy bereitgestellt wurden

    • Wichtige Informationen zu VMware Tools für Administratoren

    • Frühere Versionen von VMware Tools

    • Versionshinweise zu VMware Tools 12.2.5

ESXi-8.0U1sc-22082334-no-tools

Profilname	ESXi-8.0U1c-22082334-no-tools
Build	Build-Informationen finden Sie unter In dieser Version enthaltene Patches.
Anbieter	VMware, Inc.
Datum der Veröffentlichung	27. Juli 2023
Akzeptanzebene	Unterstützte Partner
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Betroffene VIBs	VMware_bootbank_bmcal-esxio_8.0.1-0.20.22082334 VMware_bootbank_native-misc-drivers_8.0.1-0.20.22082334 VMware_bootbank_esx-dvfilter-generic-fastpath_8.0.1-0.20.22082334 VMware_bootbank_vsan_8.0.1-0.20.22082334 VMware_bootbank_bmcal_8.0.1-0.20.22082334 VMware_bootbank_esx-base_8.0.1-0.20.22082334 VMware_bootbank_trx_8.0.1-0.20.22082334 VMware_bootbank_gc-esxio_8.0.1-0.20.22082334 VMware_bootbank_gc_8.0.1-0.20.22082334 VMware_bootbank_esxio_8.0.1-0.20.22082334 VMware_bootbank_esx-xserver_8.0.1-0.20.22082334 VMware_bootbank_cpu-microcode_8.0.1-0.20.22082334 VMware_bootbank_esxio-combiner-esxio_8.0.1-0.20.22082334 VMware_bootbank_esxio-dvfilter-generic-fastpath_8.0.1-0.20.22082334 VMware_bootbank_vsanhealth_8.0.1-0.20.22082334 VMware_bootbank_vds-vsip_8.0.1-0.20.22082334 VMware_bootbank_clusterstore_8.0.1-0.20.22082334 VMware_bootbank_native-misc-drivers-esxio_8.0.1-0.20.22082334 VMware_bootbank_esxio-combiner_8.0.1-0.20.22082334 VMware_bootbank_esxio-base_8.0.1-0.20.22082334 VMware_bootbank_vdfs_8.0.1-0.20.22082334 VMware_bootbank_crx_8.0.1-0.20.22082334 VMware_bootbank_esx-update_8.0.1-0.20.22082334 VMware_bootbank_loadesx_8.0.1-0.20.22082334 VMware_bootbank_loadesxio_8.0.1-0.20.22082334 VMware_bootbank_esxio-update_8.0.1-0.20.22082334
Behobene Probleme	3229052, 3222888, 3184515, 3184505, 3210921, 3219294, 3217139, 3215295, 3184512, 3184517, 3213042, 3184513, 3184506, 3186149
Verwandte CVE-Nummern	Nicht verfügbar

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

• ESXi 8.0 Update 1c stellt die folgenden Sicherheits-Updates bereit:

  • Der Envoy-Proxy wird auf Version v1.23.9 aktualisiert.

  • Die userworld-libxml2-Bibliothek von ESXi wird auf Version 2.10.4 aktualisiert.

  • Die cURL-Bibliothek wird auf Version 8.0.1 aktualisiert.

  • Die Go-Bibliothek wird auf Version 1.19.9 aktualisiert.

  • Das etcd-Paket wird auf 3.4.25 aktualisiert.

ESXi 8.0 U1c – 22088125

Name	ESXi
Version	ESXi80U1c-22088125
Datum der Veröffentlichung	27. Juli 2023
Kategorie	Fehlerkorrektur
Betroffene Komponenten	ESXi-Komponente ESXi-Komponente „Installieren/Aktualisieren“ Mellanox-Netzwerkkarten der 5. Generation (ConnectX- und BlueField DPU-Reihe) – Ethernet- und RoCE-Kerntreiber für VMware ESXi Broadcom NetXtreme I ESX VMKAPI-Ethernet-Treiber VMware NVMe over TCP-Treiber
Behobene Probleme	3239946, 3239870, 3210610, 3228383, 3248279, 3179236, 3183209, 3219196, 3229111, 3221890, 3219889, 3223909, 3225464, 3228391, 3158175, 3217410, 3211624, 3223427, 3223420, 3181600, 3212384, 3221902, 3219121, 3219196, 3222717, 3221598, 3210610, 3181603, 3213042, 3221593, 3210931, 3210931, 3221549, 3161147, 3213110, 3219262, 3118977, 3217167, 3210610, 3210610, 3219971, 3112043, 3218145, 3218218, 3217477, 3214491, 3166665, 3210840, 3210837, 3210956, 3213914, 3212431, 3187725, 3213177, 3185230, 3213207, 3187539, 2625439, 3122074, 3197383, 3187416, 3187420, 3118241, 3176359, 3184331, 3182257, 3187875, 3187547, 3210192, 3180881, 3163270, 3179236, 3157222, 3187709, 3187716, 3187494, 3186022, 3188105, 3183522, 3166280, 3183038, 3183531, 3183526, 3184327, 3166566, 3171992, 3172063, 3159074, 3181553, 3183529, 3146205, 3038908, 3038908, 3153396, 3038908, 3038908, 3038908, 3179111, 3152476, 3187446, 3219191
Verwandte CVE-Nummern	Nicht verfügbar

ESXi 8.0 U1sc – 22082334

Name	ESXi
Version	ESXi-8.0U1sc-22082334
Datum der Veröffentlichung	27. Juli 2023
Kategorie	Sicherheit
Betroffene Komponenten	ESXi-Komponente ESXi-Komponente „Installieren/Aktualisieren“ ESXi Tools-Komponente
Behobene Probleme	3229052, 3222888, 3184515, 3184505, 3210921, 3219294, 3217139, 3215295, 3184512, 3184517, 3213042, 3184513, 3184506, 3186149, 3186166
Verwandte CVE-Nummern	Nicht verfügbar

Bekannte Probleme aus vorherigen Versionen

• Installations-, Upgrade- und Migrationsprobleme
• Sonstige Probleme
• Netzwerkprobleme
• Speicherprobleme
• Probleme bei vCenter Server und dem vSphere Client
• VM-Verwaltungsprobleme
• Probleme bei vSphere Lifecycle Manager
• Probleme mit VMware Host Client
• Probleme bei Sicherheitsfunktionen

Installations-, Upgrade- und Migrationsprobleme

• Wenn Sie Ihre vCenter auf 8.0 Update 1 aktualisieren, ESXi Hosts jedoch auf einer früheren Version verbleiben, kann möglicherweise nicht mehr auf vSphere Virtual Volumes Datenspeicher auf diesen Hosts zugegriffen werden

  Selbstsignierte VASA-Anbieterzertifikate werden in vSphere 8.0 nicht mehr unterstützt, und die Konfigurationsoption Config.HostAgent.ssl.keyStore.allowSelfSigned ist standardmäßig auf false festgelegt. Wenn Sie eine vCenter-Instanz auf Version 8.0 Update 1 aktualisieren, die vSphere APIs for Storage Awareness (VASA) Version 5.0 einführt, und ESXi-Hosts auf einer früheren vSphere- und VASA-Version verbleiben, können Hosts, die selbstsignierte Zertifikate verwenden, möglicherweise nicht auf vSphere Virtual Volumes Datenspeicher zugreifen oder das CA-Zertifikat nicht aktualisieren.

  Problemumgehung: Führen Sie eine Aktualisierung der Hosts auf ESXi 8.0 Update 1 durch. Wenn Sie kein Update auf ESXi 8.0 Update 1 durchführen, lesen Sie den VMware Knowledgebase-Artikel 91387.

• Wenn Sie ein Hostprofil mit einer Software-FCoE-Konfiguration auf einen ESXi 8.0-Host anwenden, schlägt der Vorgang mit einem Validierungsfehler fehl

  Ab vSphere 7.0 ist Software-FCoE veraltet, und in vSphere 8.0 werden Software-FCoE-Profile nicht unterstützt. Wenn Sie versuchen, ein Hostprofil aus einer früheren Version auf einen ESXi 8.0-Host anzuwenden, z. B. um die Hostanpassung zu bearbeiten, schlägt der Vorgang fehl. Im vSphere Client wird ein Fehler ähnlich dem folgenden angezeigt: Host Customizations validation error.

  Problemumgehung: Deaktivieren Sie das Unterprofil Software FCoE-Konfiguration im Hostprofil.

• Sie können ESXi-Hosts der Version 8.0 nicht als Referenzhost für vorhandene Hostprofile früherer ESXi-Versionen verwenden

  Die Validierung vorhandener Hostprofile für ESXi-Versionen 7.x, 6.7.x und 6.5.x schlägt fehl, wenn nur ein 8.0-Referenzhost in der Bestandsliste verfügbar ist.

  Problemumgehung: Stellen Sie sicher, dass Sie über einen Referenzhost der entsprechenden Version in der Bestandsliste verfügen. Verwenden Sie zum Beispiel einen ESXi 7.0 Update 2-Referenzhost, um ein ESXi 7.0 Update 2-Hostprofil zu aktualisieren oder zu bearbeiten.

• VMNICs können nach einem Upgrade auf ESXi 8.0 ausfallen

  Wenn der physische Peer-Switch einer VMNIC die automatische Medienerkennung nicht unterstützt oder die automatische Medienerkennung deaktiviert ist und der VMNIC-Link heruntergefahren und dann wieder hochgefahren wird, bleibt der Link nach dem Upgrade auf oder der Installation von ESXi 8.0 heruntergefahren.

  Problemumgehung: Verwenden Sie eine der folgenden beiden Optionen:

  1. Aktivieren Sie die Option media-auto-detect in den BIOS-Einstellungen, indem Sie zum System-Setup-Hauptmenü navigieren, in der Regel durch Drücken von F2 oder Öffnen einer virtuellen Konsole. Dort gehen Sie dann zu Geräteeinstellungen > <spezifisches Broadcom NIC> > Gerätekonfigurationsmenü > Automatische Medienerkennung. Starten Sie den Host neu.

  2. Alternativ dazu können Sie einen ESXCLI-Befehl ähnlich dem folgenden verwenden: esxcli network nic set -S <your speed> -D full -n <your nic>. Mit dieser Option legen Sie auch eine feste Geschwindigkeit für den Link fest, und es ist kein Neustart erforderlich.

• Wenn während des Upgrades auf ESXi 8.0 ein vCenter Server Security Token Service (STS) aktualisiert wird, kommt es beim Upgrade unter Umständen zu einem Fehler

  In vSphere 8.0 wird ein von VMCA erstelltes STS-Signaturzertifikat automatisch durch vCenter Single Sign-On verlängert. Die automatische Verlängerung erfolgt, bevor das STS-Signaturzertifikat abläuft und bevor der 90-Tage-Ablaufalarm ausgelöst wird. Bei langwierigen Upgrade- oder Wartungsaufgaben unter Verwendung eines vSphere Lifecycle Manager-Images auf mehreren ESXi-Hosts in einem Cluster legt vSphere Lifecycle Manager jedoch eventuell intern einen Cache mit STS-Zertifikaten an. In sehr seltenen Fällen kann, wenn eine Aufgabe zur Aktualisierung von STS-Zertifikaten parallel zu einer langwierigen Upgrade- oder Wartungsaufgabe startet, die Upgrade-Aufgabe fehlschlagen, da sich die STS-Zertifikate im internen Cache eventuell von den aktualisierten Zertifikaten unterscheiden. Nach dem Fehlschlagen der Upgrade-Aufgabe verbleiben einige ESXi-Hosts möglicherweise im Wartungsmodus.

  Problemumgehung: Beenden Sie manuell alle ESXi-Hosts im Wartungsmodus und beginnen Sie erneut mit dem Upgrade beziehungsweise der Wartung. Das Aktualisieren oder Importieren und Ersetzen der STS-Signaturzertifikate erfolgt automatisch. Um Ausfallzeiten zu vermeiden, ist ein Neustart von vCenter Server dafür nicht erforderlich.

• Nach dem Upgrade auf ESXi 8.0 gehen aufgrund veralteter Parameter möglicherweise einige Einstellungen des Treibermoduls nmlx5_core verloren

  Einige Modulparameter für den Treiber nmlx5_core, beispielsweise device_rss, drss und rss, sind in ESXi 8.0 veraltet, und alle von den Standardwerten abweichenden benutzerdefinierten Werte werden nach einem Upgrade auf ESXi 8.0 verworfen.

  Problemumgehung: Ersetzen Sie die Werte der Parameter device_rss, drss und rss wie folgt:

  • device_rss: Verwenden Sie den Parameter DRSS.

  • drss: Verwenden Sie den Parameter DRSS.

  • rss: Verwenden Sie den Parameter RSS.

• Zweite Phase des Wiederherstellungsvorgangs von vCenter Server friert bei 90 % ein

  Wenn Sie das GUI-Installationsprogramm von vCenter Server oder die vCenter Server Appliance Management Interface (VAMI) verwenden, um ein vCenter aus einem dateibasierten Backup wiederherzustellen, bleibt der Wiederherstellungsworkflow unter Umständen bei 90 % mit der Fehlermeldung 401 Unable to authenticate user stehen, obwohl die Aufgabe im Back-End erfolgreich abgeschlossen wird. Das Problem tritt auf, wenn der eingesetzte Rechner auf eine andere Zeit eingestellt ist als der NTP-Server, sodass eine Zeitsynchronisierung erforderlich ist. Infolge der Zeitsynchronisierung kann die laufende Sitzung der GUI oder VAMI durch eine Taktverschiebung gestört werden.

  Problemumgehung: Wenn Sie das GUI-Installationsprogramm verwenden, können Sie den Wiederherstellungsstatus mit dem Befehl restore.job.get in der Shell appliancesh abrufen. Wenn Sie die VAMI verwenden, aktualisieren Sie Ihren Browser.

Sonstige Probleme

• Der RDMA over Converged Ethernet (RoCE)-Datenverkehr schlägt möglicherweise in einer ENS- (Enhanced Networking Stack) und VLAN-Umgebung und einem Broadcom RDMA Network Interface Controller (RNIC) fehl

  Die VMware Lösung für hohe Bandbreite, ENS, unterstützt keine MAC-VLAN-Filter. Für eine RDMA-Anwendung, die auf einer Broadcom RNIC in einer ENS + VLAN-Umgebung ausgeführt wird, ist jedoch ein MAC-VLAN-Filter erforderlich. Dies kann dazu führen, dass ein Teil des RoCE-Datenverkehrs getrennt wird. Dieses Problem tritt wahrscheinlich in einer NVMe over RDMA + ENS + VLAN-Umgebung oder in einer ENS+VLAN+RDMA-App-Umgebung auf, wenn ein ESXi-Host neu gestartet wird oder ein Uplink hoch- und heruntergefahren wird.

  Problemumgehung: Keine

• Wenn während des Herunterfahrens oder Neustarts eines ESXi-Hosts ein PCI-Passthrough zu einer DPU aktiv ist, schlägt der Host mit einem violetten Diagnosebildschirm fehl

  Wenn eine aktive virtuelle Maschine zum Zeitpunkt des Herunterfahrens oder Neustarts eines ESXi-Hosts einen PCI-Passthrough zu einer DPU aufweist, schlägt der Host mit einem violetten Diagnosebildschirm fehl. Das Problem ist spezifisch für Systeme mit DPUs und nur im Fall von VMs, die PCI-Passthrough zur DPU verwenden.

  Problemumgehung: Stellen Sie vor dem Herunterfahren oder Neustart eines ESXi-Hosts sicher, dass sich der Host im Wartungsmodus befindet oder dass keine VMs ausgeführt werden, die PCI-Passthrough zu einer DPU verwenden. Wenn Sie Optionen für den automatischen Start einer virtuellen Maschine verwenden, stoppt der Autostart-Manager solche VMs vor dem Herunterfahren oder Neustart eines Hosts.

• Ein IPv6-basierter NFS 3-Datenspeicher mit VMkernel-Port-Bindung kann nicht mithilfe von ESXCLI-Befehlen gemountet werden

  Wenn Sie versuchen, einen NFS 3-Datenspeicher mit einer IPv6-Serveradresse und VMkernel-Port-Bindung mithilfe eines ESXCLI-Befehls zu mounten, schlägt die Aufgabe mit einer Fehlermeldung ähnlich der folgenden fehl:

  [:~] esxcli storage nfs add -I fc00:xxx:xxx:xx::xxx:vmk1 -s share1 -v volume1

  Validation of vmknic failed Instance(defaultTcpipStack, xxx:xxx:xx::xxx:vmk1) Input(): Not found:

  Das Problem ist spezifisch für NFS 3-Datenspeicher mit einer IPv6-Serveradresse und VMkernel-Port-Bindung.

  Problemumgehung: Verwenden Sie zum Mounten von IPv6-basierten NFSv3-Datenspeichern mit VMkernel-Port-Bindung stattdessen den vSphere Client.

• Das Zurücksetzen oder Wiederherstellen der ESXi-Systemkonfiguration in einem vSphere-System mit DPUs kann zu einem ungültigen Status der DPUs führen

  Wenn Sie die ESXi-Systemkonfiguration in einem vSphere-System mit DPUs zurücksetzen oder wiederherstellen, z. B. durch Auswahl von Systemkonfiguration zurücksetzen in der direkten Konsole, kann der Vorgang zu einem ungültigen Zustand der DPUs führen. In der DCUI sehen Sie möglicherweise Fehler wie Failed to reset system configuration. Note that this operation cannot be performed when a managed DPU is present. Ein Backend-Aufruf der Option -f zum Erzwingen eines Neustarts wird für ESXi-Installationen mit einer DPU nicht unterstützt. Obwohl ESXi 8.0 die Option -f zum Erzwingen eines Neustarts unterstützt, kann der erzwungene Neustart einen ungültigen Status verursachen, wenn Sie reboot -f in einer ESXi-Konfiguration mit einer DPU verwenden.

  Problemumgehung: Das Zurücksetzen der Systemkonfiguration in der direkten Konsolenschnittstelle ist vorübergehend deaktiviert. Vermeiden Sie das Zurücksetzen der ESXi-Systemkonfiguration in einem vSphere-System mit DPUs.

• Wenn IPv6 in einem vCenter Server-System mit DPUs deaktiviert ist, können Sie keine DPUs verwalten.

  Obwohl der vSphere Client den Vorgang zulässt, können Sie die DPUs nicht verwenden, wenn Sie IPv6 auf einem ESXi-Host mit DPUs deaktivieren, da die interne Kommunikation zwischen dem Host und den Geräten von IPv6 abhängt. Das Problem betrifft nur ESXi-Hosts mit DPUs.

  Problemumgehung: Stellen Sie sicher, dass IPv6 auf ESXi-Hosts mit DPUs aktiviert ist.

• Beim Neustart eines ESXi-Hosts auf einem HPE-Server mit vorinstallierter Pensando-DPU kann es zu einer 10-minütigen Verzögerung kommen

  In seltenen Fällen kann der Neustart von HPE-Servern mit vorinstallierter Pensando-DPU mehr als 10 Minuten dauern, wenn bei der DPU ein Fehler vorliegt. Infolgedessen fallen unter Umständen ESXi-Hosts aus, wobei ein violetter Diagnosebildschirm angezeigt wird. Die Standardwartezeit beträgt dann 10 Minuten.

  Problemumgehung: Keine.

• Wenn Sie in einer Remotemanagementanwendung, die Sie zur Installation von ESXi 8.0 verwenden, eine USB-Schnittstelle aktiviert haben, sehen Sie einen zusätzlichen Standard-Switch vSwitchBMC mit Uplink vusb0

  Ab vSphere 8.0 wird sowohl bei Integrated Dell Remote Access Controller (iDRAC) als auch bei HP Integrated Lights Out (ILO) mit aktivierter USB-Schnittstelle (vUSB bzw. vNIC) ein zusätzlicher Standard-Switch vSwitchBMC mit Uplink vusb0 auf dem ESXi-Host erstellt. Auf einigen Servern ist dies angesichts der Einführung von Datenverarbeitungseinheiten (Data Processing Units, DPUs) zu erwarten; es kann dadurch allerdings zum Fehlschlagen des Bring-Up-Prozesses der VMware Cloud Foundation kommen.

  Problemumgehung: Deaktivieren Sie vor der Installation von vSphere 8.0 die USB-Schnittstelle in der von Ihnen verwendeten Remotemanagementanwendung. Richten Sie sich dazu nach der Dokumentation des Herstellers.

  Verwenden Sie nach der Installation von vSphere 8.0 den ESXCLI-Befehl esxcfg-advcfg -s 0 /Net/BMCNetworkEnable, um die Erstellung eines virtuellen Switches vSwitchBMC und zugehöriger Portgruppen beim nächsten Neustart des Hosts zu verhindern.

  Hier ein Skript als Beispiel:

  ~# esxcfg-advcfg -s 0 /Net/BMCNetworkEnable

  Der Wert von BMCNetworkEnable ist 0, und der Dienst ist deaktiviert.

  ~# reboot

  Beim Neustart des Hosts werden in Verbindung mit dem Netzwerk der Remotemanagementanwendung kein virtueller Switch, keine Portgruppe und keine VMKNIC im Host erstellt.

• Wenn eine NVIDIA BlueField-DPU im Hardware-Offload-Modus deaktiviert ist, können virtuelle Maschinen mit konfigurierter virtueller SR-IOV-Funktion nicht eingeschaltet werden

  NVIDIA BlueField-DPUs müssen im Hardware-Offload-Modus aktiviert sein, damit virtuelle Maschinen mit konfigurierter virtueller SR-IOV-Funktion eingeschaltet und betrieben werden können.

  Problemumgehung: Verwenden Sie immer den standardmäßigen Hardware-Offload-Modus, der für NVIDIA BlueField-DPUs aktiviert ist, wenn Sie VMs mit konfigurierter virtueller SR-IOV-Funktion an einen virtuellen Switch angeschlossen haben.

• In der Virtual Appliance Management Interface (VAMI) wird in der Phase vor dem Upgrade eine Warnung angezeigt

  Durch die Umstellung der vSphere-Plug-Ins auf eine Remote-Plug-In-Architektur ist in vSphere 8.0 die Unterstützung für lokale Plug-Ins veraltet. Wenn in Ihrer vSphere 8.0-Umgebung lokale Plug-Ins vorhanden sind, können einige Änderungen an diesen Plug-Ins dazu führen, dass die vor dem Upgrade per VAMI durchgeführte Prüfung scheitert.

  In der Ergebnisanzeige zu der dem Update vorausgehenden Prüfung wird eine Fehlermeldung ähnlich der folgenden angezeigt:

  Warning message: The compatibility of plug-in package(s) %s with the new vCenter Server version cannot be validated. They may not function properly after vCenter Server upgrade.

  Resolution: Please contact the plug-in vendor and make sure the package is compatible with the new vCenter Server version.

  Problemumgehung: Weitere Informationen finden Sie im VMware Compatibility Guide und in der VMware Product Interoperability Matrix. Alternativ können Sie sich vor den weiteren Upgrade-Schritten bei den Plug-In-Anbietern nach Empfehlungen erkundigen, um sicherzugehen, dass die lokalen Plug-Ins in Ihrer Umgebung mit vCenter Server 8.0 kompatibel sind. Weitere Informationen finden Sie im Blog Deprecating the Local Plugins :- The Next Step in vSphere Client Extensibility Evolution und im VMware-Knowledgebase-Artikel 87880.

• Sie können ein PCI-Passthrough-Gerät, das einem virtuellen NUMA-Knoten (Non-Uniform Memory Access) zugewiesen ist, nicht aus einer virtuellen Maschine entfernen, bei der das Hinzufügen von CPUs im laufenden Betrieb aktiviert ist

  Obwohl bei aktivierter CPU-Hot-Add-Funktion das Hinzufügen von vCPUs zu einer laufenden virtuellen Maschine standardmäßig aktiviert ist, wird die virtuelle NUMA-Topologie deaktiviert. Wenn Sie jedoch einem NUMA-Knoten ein PCI-Passthrough-Gerät zugewiesen haben, enden Versuche, das Geräte zu entfernen, mit einem Fehler. Im vSphere Client sehen Sie Meldungen wie beispielsweise Invalid virtual machine configuration. Virtual NUMA cannot be configured when CPU hotadd is enabled.

  Problemumgehung: Informationen hinzu finden Sie im VMware-Knowledgebase-Artikel 89638.

• Wenn Sie eine VM mit einer früheren HW-Version als 20 mit einer Anbietergerätegruppe konfigurieren, funktionieren diese VMs möglicherweise nicht wie erwartet

  Anbietergerätegruppen, die die Bindung von Hochgeschwindigkeits-Netzwerkgeräten und der GPU ermöglichen, werden nur auf VMs mit HW-Version 20 und höher unterstützt. Sie werden jedoch nicht daran gehindert, eine VM mit einer HW-Version vor 20 mit einer Anbietergerätegruppe zu konfigurieren. Solche VMs funktionieren möglicherweise nicht wie erwartet: So schlägt beispielsweise das Einschalten fehl.

  Problemumgehung: Stellen Sie sicher, dass die VM HW-Version 20 ist, bevor Sie eine Anbietergerätegruppe in dieser VM konfigurieren.

Netzwerkprobleme

• ESXi Neustart dauert aufgrund einer Zeitüberschreitung beim Mounten des NFS-Servers lange

  Wenn auf einem NFS-Server, auf den nicht zugegriffen werden kann, mehrere Bereitstellungen vorhanden sind, versucht ESXi 30 Sekunden lang erneut, eine Verbindung zu jeder Bereitstellung herzustellen, was je nach Anzahl der Bereitstellungen eine ESXi Neustartverzögerung bis zu mehreren Minuten zur Folge haben kann.

  Problemumgehung: ESXi Update 8.0 Update 1 fügt eine konfigurierbare Option hinzu, um die standardmäßige Zeitüberschreitung für Bereitstellungen außer Kraft zu setzen: esxcfg-advcfg -s <timeout val> /NFS/MountTimeout. Wenn Sie beispielsweise die Zeitüberschreitung für die Bereitstellung auf 10 Sekunden neu konfigurieren möchten, können Sie den folgenden Befehl ausführen: - esxcfg-advcfg -s 10 /NFS/MountTimeout. Verwenden Sie den Befehl esxcfg-advcfg -g /NFS/MountTimeout, um die aktuell konfigurierte Zeitüberschreitung für die Bereitstellung zu überprüfen.

• Sie können die maximale Übertragungseinheit (MTU) auf einem VMware vSphere Distributed Switch nicht auf einen Wert größer als 9174 auf einer Pensando DPU einstellen

  Wenn Sie die vSphere Distributed Services Engine-Funktion mit einer Pensando DPU auf Ihrem ESXi 8.0-System aktiviert haben, können Sie die maximale Übertragungseinheit (MTU) auf einem vSphere Distributed Switch nicht auf einen Wert größer als 9174 festlegen.

  Problemumgehung: Keine.

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

  Wenn zwei NICs, die den ntg3-Treiber 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.

  Problemumgehung: Aktualisieren Sie den ntg3-Treiber auf Version 4.1.8 und setzen Sie den neuen Modulparameter noPhyStateSet auf 1. 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.

• Die Installation oder das Upgrade von VMware NSX in einer vSphere-Umgebung mit DPUs schlägt möglicherweise mit einem Konnektivitätsfehler fehl

  Ein zeitweiliges Zeitproblem auf der ESXi-Hostseite kann dazu führen, dass die Installation oder das Upgrade von NSX in einer vSphere-Umgebung mit DPUs fehlschlägt. Die Datei nsxapi.log enthält Protokolle wie etwa Failed to get SFHC response. MessageType MT_SOFTWARE_STATUS.

  Problemumgehung: Warten Sie 10 Minuten und wiederholen Sie die Installation oder das Upgrade von NSX.

• Wenn Sie einen ESXi-Host nach dem Aktivieren oder Deaktivieren von SR-IOV mit dem icen-Treiber beim Konfigurieren eines Transportknotens im ENS-Unterbrechungsmodus auf diesem Host nicht neu starten, erhalten einige virtuelle Maschinen möglicherweise keine DHCP-Adressen

  Nach dem Aktivieren oder Deaktivieren von SR-IOV mit dem icen-Treiber auf einem ESXi-Host und dem Konfigurieren eines Transportknotens im ENS-Unterbrechungsmodus funktionieren einige Rx-Warteschlangen (Empfangswarteschlangen) möglicherweise nicht, sofern Sie den Host nicht neu starten. Infolgedessen erhalten einige virtuelle Maschinen möglicherweise keine DHCP-Adressen.

  Problemumgehung: Fügen Sie entweder direkt ein Transportknotenprofil hinzu, ohne SR-IOV zu aktivieren, oder starten Sie den ESXi-Host nach dem Aktivieren oder Deaktivieren von SR-IOV neu.

• Es ist nicht möglich, Mellanox ConnectX-5- und ConnectX-6-Karten mit Modell 1 Level 2 und Modell 2 für den ENS-Modus (Enhanced Network Stack) in vSphere 8.0 zu verwenden

  Aufgrund von Hardwarebeschränkungen werden Modell 1 Level 2 und Modell 2 für den ENS-Modus (Enhanced Network Stack) in vSphere 8.0 von ConnectX-5- und ConnectX-6-Adapterkarten nicht unterstützt.

  Problemumgehung: Verwenden Sie Karten des Typs Mellanox ConnectX-6 Lx und ConnectX-6 Dx oder neuere Karten, die ENS Modell 1 Level 2 und Modell 2A unterstützen.

• Pensulator-DPUs unterstützen das LLDP (Link Layer Discovery Protocol) auf physischen Switch-Ports von ESXi-Hosts nicht

  Wenn Sie LLDP auf einem ESXi-Host mit einer DPU aktivieren, kann der Host keine LLDP-Pakete empfangen.

  Problemumgehung: Keine.

Speicherprobleme

• Die VASA API-Version wird nach dem Upgrade auf vCenter Server 8.0 nicht automatisch aktualisiert

  vCenter Server 8.0 unterstützt die VASA API-Version 4.0. Nach dem Upgrade Ihres vCenter Server-Systems auf Version 8.0 ändert sich die VASA API-Version jedoch möglicherweise nicht automatisch auf 4.0. Dieses Problem tritt in den folgenden beiden Fällen auf:

  1. Wenn ein VASA-Anbieter, der die VASA API-Version 4.0 unterstützt, bei einer früheren Version von VMware vCenter registriert ist, bleibt die VASA API-Version nach dem Upgrade auf VMware vCenter 8.0 unverändert. Wenn Sie beispielsweise ein VMware vCenter-System der Version 7.x mit einem registrierten VASA-Anbieter aktualisieren, der sowohl die VASA API-Versionen 3.5 als auch 4.0 unterstützt, ändert sich die VASA API-Version nicht automatisch auf 4.0, obwohl der VASA-Anbieter die VASA API-Version 4.0 unterstützt. Wenn Sie nach dem Upgrade zu vCenter Server > Konfigurieren > Speicheranbieter navigieren und die Registerkarte Allgemein des registrierten VASA-Anbieters erweitern, wird weiterhin die VASA API-Version 3.5 angezeigt.

  2. Wenn Sie einen VASA-Anbieter, der die VASA API-Version 3.5 unterstützt, mit einem VMware vCenter 8.0-System registrieren und die VASA API-Version auf 4.0 aktualisieren, wird auch nach dem Upgrade weiterhin die VASA API-Version 3.5 angezeigt.

  Problemumgehung: Heben Sie die Registrierung des VASA-Anbieters auf dem VMware vCenter 8.0-System auf und registrieren Sie ihn erneut.

• 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.

• Aufgrund eines im Content Based Read Cache (CBRC) auftretenden Fehlers im Zusammenhang mit einem Digest-Vorgang können keine Snapshots von virtuellen Maschinen erstellt werden

  Eine seltene Racebedingung bei der Zuweisung einer Inhalts-ID während der Aktualisierung der CBRC-Digest-Datei kann zu einer Diskrepanz zwischen der Inhalts-ID auf der Datenfestplatte und der Digest-Festplatte führen. Infolgedessen können Sie keine VM-Snapshots erstellen. Im Backtrace wird eine Fehlermeldung ähnlich der folgenden angezeigt: An error occurred while saving the snapshot: A digest operation has failed. Die Aufgabe zum Erstellen des Snapshots wird bei einem erneuten Versuch abgeschlossen.

  Problemumgehung: Wiederholen Sie die Snapshot-Erstellung.

Probleme bei vCenter Server und dem vSphere Client

• Die Auslastungsansicht von Ressourcenpools und Clustern wird möglicherweise nicht automatisch aktualisiert, wenn Sie das Objekt ändern

  Wenn Sie die Ansicht Auslastung auf der Registerkarte Überwachen für einen Ressourcenpool oder einen Cluster bereits geöffnet haben und dann den Ressourcenpool oder Cluster ändern, wird die Ansicht möglicherweise nicht automatisch aktualisiert. Wenn Sie beispielsweise die Ansicht Auslastung eines Clusters öffnen und dann einen anderen Cluster auswählen, werden unter Umständen weiterhin die Statistiken des ersten Clusters angezeigt.

  Problemumgehung: Klicken Sie auf das Aktualisierungssymbol.

• Wenn Sie die virtuelle vSphere-Infrastruktur zu mehr als 90 % auslasten, werden die ESXi-Hosts möglicherweise zeitweise vom vCenter Server getrennt

  In seltenen Fällen, wenn die virtuelle vSphere-Infrastruktur kontinuierlich mehr als 90 % ihrer Hardwarekapazität nutzt, kann es vorkommen, dass einige ESXi-Hosts zeitweise die Verbindung zum vCenter Server unterbrechen. Die Verbindung wird in der Regel innerhalb weniger Sekunden wiederhergestellt.

  Problemumgehung: Wenn die Verbindung zu vCenter Server versehentlich nicht innerhalb weniger Sekunden wiederhergestellt wird, verbinden Sie die ESXi-Hosts mithilfe des vSphere Client manuell neu.

• Im vSphere Client werden keine Banner-Benachrichtigungen für Importe von Verlaufsdaten angezeigt

  Aufgrund eines Back-End-Problems werden im vSphere Client keine Banner-Benachrichtigungen zur Hintergrundmigration von Verlaufsdaten angezeigt.

  Problemumgehung: Verwenden Sie die vCenter Server-Verwaltungsschnittstelle als Alternative zum vSphere Client. Weitere Informationen finden Sie unter Überwachen und Verwalten der Migration von Verlaufsdaten.

• Zu CNS-Blockvolumes (Cloud Native Storage), die per API in einer heterogenen vCenter-Umgebung erstellt wurden, wird eine Fehlermeldung angezeigt

  Wenn in Ihrer Umgebung vCenter Server-Systeme der Version 8.0 und 7.x vorhanden sind, können CNS-Blockvolumes (Cloud Native Storage) per API erstellt werden, allerdings wird im vSphere Client möglicherweise eine Fehlermeldung angezeigt, wenn Sie Detailangaben zum CNS-Volume abrufen. Es wird dann eine Fehlermeldung ähnlich der folgenden angezeigt: Failed to extract the requested data. Check vSphere Client logs for details. + TypeError: Cannot read properties of null (reading 'cluster'). Das Problem tritt nur auf, wenn Sie Volumes überprüfen, die von vCenter Server Version 7.x unter Verwendung des vSphere Client von vCenter Server Version 8.0 verwaltet werden.

  Problemumgehung: Melden Sie sich beim vSphere Client eines vCenter Server-Systems der Version 7.x an, um die Volume-Eigenschaften zu überprüfen.

• ESXi-Hosts reagieren möglicherweise nicht mehr, und es wird eine vpxa-Dump-Datei angezeigt, weil in seltenen Fällen die Dateideskriptoren für die Anforderungswarteschlange auf vpxa nicht ausreichen

  In seltenen Fällen kann es bei lange dauernden Anforderungen an den vpxa-Dienst, etwa beim Warten auf Zugang zu einem langsamen Datenspeicher, in der Anforderungswarteschlange auf vpxa zu einer Überschreitung des Limits der Dateideskriptoren kommen. Infolgedessen reagieren ESXi-Hosts dann unter Umständen kurzzeitig nicht mehr, und eine Datei vpxa-zdump.00* wird im Verzeichnis /var/core angezeigt. Die vpxa-Protokolle enthalten die Zeile Too many open files.

  Problemumgehung: Keine. Der vpxa-Dienst wird automatisch neu gestartet, um das Problem zu beheben.

• Wenn Sie ein benutzerdefiniertes Update-Repository mit nicht vertrauenswürdigen Zertifikaten verwenden, schlägt das vCenter Server-Upgrade oder das Update mithilfe von vCenter Lifecycle Manager-Workflows auf vSphere 8.0 möglicherweise fehl

  Wenn Sie ein benutzerdefiniertes Update-Repository mit selbstsignierten Zertifikaten verwenden, denen die VMware Certificate Authority (VMCA) nicht vertraut, kann vCenter Lifecycle Manager keine Dateien aus einem solchen Repository herunterladen. Dies führt dazu, dass vCenter Server-Upgrade- oder Aktualisierungsvorgänge mithilfe von vCenter Lifecycle Manager-Workflows mit dem Fehler Failed to load the repository manifest data for the configured upgrade fehlschlagen.

  Problemumgehung: Verwenden Sie zur Durchführung des Upgrades die CLI, das GUI-Installationsprogramm oder die Virtual Appliance Management Interface (VAMI). Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 89493.

VM-Verwaltungsprobleme

• Beim Hinzufügen einer vorhandenen virtuellen Festplatte zu einer neuen virtuellen Maschine wird unter Umständen eine Fehlermeldung angezeigt, dass die VM-Konfiguration abgelehnt wird

  Wenn Sie unter Verwendung des VMware Host Client einer neuen virtuellen Maschine eine vorhandene virtuelle Festplatte hinzufügen, scheitert der Vorgang eventuell mit einer Fehlermeldung ähnlich der folgenden: The VM configuration was rejected. Please see browser Console. Das Problem tritt auf, weil der VMware Host Client eventuell einige Eigenschaften, beispielsweise zum Festplattencontroller, nicht abrufen kann.

  Problemumgehung: Klicken Sie nach dem Auswählen einer Festplatte und Aufrufen der Seite Bereit zum Abschließen nicht auf die Schaltfläche Beenden. Wechseln Sie stattdessen zum vorherigen Schritt, warten Sie ab, bis die Seite geladen ist, und klicken Sie dann auf Weiter > Beenden.

Probleme bei vSphere Lifecycle Manager

• Wenn Sie einen ESXi-Host verwenden, der aus einem Hostprofil mit aktivierter statusbehafteten Installation als Image bereitgestellt wurde, um andere ESXi-Hosts in einem Cluster bereitzustellen, schlägt der Vorgang fehl

  Wenn Sie ein Image eines ESXi-Hosts, das von einem Hostprofil mit aktivierter statusbehafteter Installation bereitgestellt wurde, extrahieren, um andere ESXi-Hosts in einem vSphere Lifecycle Manager-Cluster bereitzustellen, schlägt der Vorgang fehl. Im vSphere Client wird ein Fehler ähnlich dem folgenden angezeigt: A general system error occurred: Failed to extract image from the host: no stored copy available for inactive VIB VMW_bootbank_xxx. Extraction of image from host xxx.eng.vmware.com failed.

  Problemumgehung: Verwenden Sie einen anderen Host aus dem Cluster, um ein Image zu extrahieren.

• Beim Versuch, vSphere Lifecycle Manager-Images auf ESXi-Hosts mit einer früheren Version als 8.0 bereitzustellen, werden Fehlermeldungen angezeigt

  Ab ESXi 8.0 gibt es die Option, gewünschte Status-Images explizit bereitzustellen. Dabei werden Depotkomponenten aus dem vSphere Lifecycle Manager-Depot auf die ESXi-Hosts heruntergeladen, ohne die Software- und Firmware-Updates unmittelbar anzuwenden. Das Staging von Images wird jedoch nur auf einem ESXi-Host der Version 8.0 oder höher unterstützt. Der Versuch, ein vSphere Lifecycle Manager-Image auf ESXi-Hosts einer früheren Version als 8.0 bereitzustellen, führt zu Meldungen, die besagen, dass das Staging solcher Fehler fehlgeschlagen ist und die Hosts übersprungen wird. Dies entspricht dem erwarteten Verhalten und ist kein Anzeichen für eine Fehlfunktion, da alle ESXi-Hosts der Version 8.0 oder höher mit dem angegebenen gewünschten Image bereitgestellt werden.

  Problemumgehung: Keine. Nachdem Sie sich vergewissert haben, dass die betroffenen ESXi-Hosts eine frühere Version als 8.0 aufweisen, können Sie die Fehler ignorieren.

• Bei einer Wartungsaufgabe unter Verwendung von vSphere Lifecycle Manager tritt bei ESXi-Hosts mit DPUs eventuell gelegentlich ein Fehler auf

  Wenn Sie auf ESXi-Hosts mit DPUs eine Wartung von vSphere Lifecycle Manager starten, erfolgt beim Host wie erwartet ein Upgrade und Neustart. Nach dem Neustart und vor Abschluss der Wartungsaufgabe wird allerdings unter Umständen eine Fehlermeldung ähnlich der folgenden angezeigt:

  A general system error occurred: After host … remediation completed, compliance check reported host as 'non-compliant'. The image on the host does not match the image set for the cluster. Retry the cluster remediation operation.

  Dies ist ein selten auftretendes Problem, das verursacht wird durch eine gelegentlich auftretende Zeitüberschreitung bei der auf die Wartung folgenden Prüfung der DPU.

  Problemumgehung: Starten Sie den ESXi-Host neu und führen Sie die Konformitätsprüfung bei vSphere Lifecycle Manager erneut durch, zu der auch die auf die Wartung folgende Prüfung gehört.

Probleme mit VMware Host Client

• VMware Host Client zeigt möglicherweise falsche Beschreibungen für Schweregrad-Ereigniszustände an

  Wenn Sie im VMware Host Client nach den Beschreibungen der Schweregrad-Ereigniszustände eines ESXi-Hosts suchen, können sie sich von den Beschreibungen unterscheiden, die bei Verwendung von Intelligent Platform Management Interface (IPMI) oder Lenovo XClarity Controller (XCC) angezeigt werden. Beispielsweise kann im VMware Host Client die Beschreibung des Schweregrad-Ereigniszustands für die PSU-Sensoren Transition to Non-critical from OK lauten, während sie im XCC und IPMI Transition to OK lautet.

  Problemumgehung: Überprüfen Sie die Beschreibungen für Schweregrad-Ereigniszustände mithilfe des ESXCLI-Befehls esxcli hardware ipmi sdr list und Lenovo XCC.

Probleme bei Sicherheitsfunktionen

• Bei Verwendung einer RSA-Schlüsselgröße kleiner als 2048 Bit scheitert die RSA-Signaturerstellung

  Ab vSphere 8.0 verwendet ESXi den FIPS-Anbieter OpenSSL 3.0. Entsprechend der FIPS 186-4-Anforderung muss die RSA-Schlüsselgröße für jede Signaturerstellung mindestens 2048 Bit betragen, und die Signaturerstellung mit SHA1 wird nicht unterstützt.

  Problemumgehung: Verwenden Sie eine RSA-Schlüsselgröße größer als 2048.