| VMware ESXi 8.0 Update 2 | 21. September 2023 | GA ISO-Build 22380479 Überprüfen Sie, ob Erweiterungen und Updates für diese Versionshinweise zur Verfügung stehen. |
Allgemeine Verfügbarkeit
Diese ESXi-Version 8.0 Update 2 ist als Version mit allgemeiner Verfügbarkeit (GA) gekennzeichnet. Weitere Informationen zum vSphere 8.0 IA/GA-Versionsmodell von vSphere-Update-Versionen finden Sie unter Das vSphere 8-Versionsmodell entwickelt sich.
Neuigkeiten
Einen Überblick über die neuen Funktionen in vSphere 8.0 Update 2 finden Sie unter Neue Funktionen in vSphere 8 Update 2 und den folgenden Versionshinweisen:
Die folgende Liste enthält die wichtigsten neuen Funktionen und Verbesserungen von ESXi 8.0 Update 2:
-
Ab vSphere 8.0 Update 2 bietet vSphere Distributed Services Engine Unterstützung für:
-
NVIDIA BlueField-2 DPUs zu Serverdesigns von Fujitsu (Intel Sapphire Rapids).
-
-
ESXi 8.0 Update 2 bietet Unterstützung für vSphere Quick Boot für mehrere Server, einschließlich:
-
Dell
-
VxRail VD-4510c
-
VxRail VD-4520c
-
-
Fujitsu
-
PRIMERGY RX2540 M7
-
PRIMERGY RX2530 M7
-
-
Lenovo
-
ThinkSystem SR635 V3
-
ThinkSystem SR645 V3
-
ThinkSystem SR655 V3
-
ThinkSystem ST650 V3
Eine vollständige Liste der unterstützten Server finden Sie im VMware-Kompatibilitätshandbuch.
-
-
-
Unterstützung für In-Band Error-Correcting Code (IB ECC): Mit vSphere 8.0 Update 2 können Sie IB ECC auf Hardwareplattformen verwenden, die diese Option unterstützen, um Datenintegritätsprüfungen durchzuführen, ohne dass tatsächlicher DDR-Arbeitsspeicher vom Typ ECC erforderlich ist.
-
Unterstützung für Grafiken und KI-/ML-Arbeitslasten in Intel ATS-M: vSphere 8.0 Update 2 fügt Unterstützung für Grafiken und KI-/ML-Arbeitslasten in Intel ATS-M hinzu.
-
Verbesserter ESXi CPU-Scheduler: vSphere 8.0 Update 2 fügt Leistungsverbesserungen im ESXi CPU-Scheduler für Systeme der neueren Generation hinzu, die CPUs mit vielen Kernen verwenden, wie z. B. Intel Saphir Rapids mit bis zu 60 Kernen pro Socket.
-
Broadcom lpfc-Treiberaktualisierung: Mit vSphere 8.0 Update 2 kann der lpfc-Treiber Informationen zu FPIN-Berichten (Fibre Channel Port Identifier) generieren und bereitstellen.
-
Mellanox (nmlx5)-Treiberaktualisierung: Mit vSphere 8.0 Update 2 unterstützt der nmlx5-Treiber NVIDIA ConnectX-7 SmartNIC und verbessert die Leistung, z. B. Unterstützung für bis zu 8 Mellanox-Uplinks pro ESXi-Host, Offload-Unterstützung für bis zu 200G-Geschwindigkeiten, Hardware-Offloads für innere IPv4/IPv6-Prüfsummen-Offloads (CSO), TCP Segment Offloads (TSO) mit äußerem IPv6 für GENEVE und VXLAN sowie Aktivierung von NetQ Receive-Side Scaling (RSS).
-
Marvell (qedentv)-Treiberaktualisierung: Mit vSphere 8.0 Update 2 unterstützt der qedentv-Treiber NetQ Receive-Side Scaling (RSS) und Hardware Large Receive Offload (HW LRO) zur Verbesserung der Leistung, Skalierbarkeit und Effizienz.
-
Andere Treiberaktualisierungen:
-
Broadcom bcm_mpi3 – Fehlerkorrekturen
-
Broadcom bnxtnet – Akkumulierte bnxtnet-Treiberaktualisierungen vom asynchronen Treiber, einschließlich queueGetStats-Callback von vmk_UplinkQueueOps, verbessertes Debugging
-
Broadcom lsi_mr3 – Routinenaktualisierung
-
Intel icen – aktiviert die RSS-Funktion im nativen Modus für den icen-NIC-Gerätetreiber
-
Microchip smartpqi – Fehlerbehebungen und Hinzufügung von OEM-PCI-IDs
-
Pensando ionic_cloud: Unterstützung für Cloud-Anbieter
-
-
Verbesserungen beim IPv6-Treiber: Mit vSphere 8.0 Update 2 fügen ESXi-Treiber Offload-Funktionen für Leistungsverbesserungen mit IPv6 hinzu, wenn es als Overlay verwendet wird.
-
Unterstützung des Uniform Passthrough (UPT)-Modus im nvmxnet3-Treiber: vSphere 8.0 Update 2 fügt Unterstützung für UPT hinzu, um schnellere vSphere vMotion-Vorgänge in verschachtelten ESXi-Umgebungen zu ermöglichen.
-
Unterstützung von 8 Ports mit 100 G auf einem einzelnen Host mit Broadcom- und Mellanox-Netzwerkkarten: vSphere 8.0 Update 2 erhöht die Unterstützung für 100-GB-Netzwerkkartenports in ESXi für Broadcom und Mellanox von 4 auf 8.
-
CIM-Diensttickets für REST-Authentifizierung: Zusätzlich zur JWT-basierten Authentifizierung fügt vSphere 8.0 Update 2 die Option zur Authentifizierung beim ESXi-Host hinzu, indem CIM-Diensttickets mit der
acquireCimServicesTicket()-API für SREST-Plug-Ins verwendet werden. -
Aktualisierung der glibc-Bibliothek: Die glibc-Bibliothek wurde auf Version 2.28 aktualisiert, um die NIAP-Anforderungen zu erfüllen.
Gastplattform für Arbeitslasten:
-
Virtuelle Hardware Version 21: vSphere 8.0 Update 2 führt virtuelle Hardware Version 21 ein, um die Unterstützung für das neueste Gastbetriebssystem zu verbessern und die Maximalwerte für vGPU und vNVME wie folgt zu erhöhen:
-
16 vGPU-Geräte pro VM (siehe Konfigurieren von virtuellen Grafiken auf vSphere)
-
256 vNVMe-Festplatten pro VM (64 x 4 vNVMe-Adapter)
-
NVMe 1.3-Unterstützung für Windows 11 und Windows Server 2022
-
NVMe-Unterstützung für Windows Server Failover Cluster (WSFC)
-
-
Erweiterung von gemeinsam genutzten vSphere Virtual Volumes-Festplatten im laufenden Betrieb: vSphere 8.0 Update 2 unterstützt die Erweiterung von gemeinsam genutzten vSphere Virtual Volumes-Festplatten im laufenden Betrieb. Dadurch können Sie die Größe einer gemeinsam genutzten Festplatte ohne Deaktivieren des Clusters und ohne Ausfallzeit erhöhen. Dies ist hilfreich für VM-Clusteringlösungen wie Windows Server Failover Cluster (WSFC). Weitere Informationen finden Sie unter VMware vSphere Virtual Volumes-Unterstützung für WSFC und Sie können eine gemeinsam genutzte vVol-Festplatte im laufenden Betrieb erweitern.
-
Verwendung des vNVME-Controllers für WSFC: Mit vSphere 8.0 Update 2 können Sie den NVMe-Controller zusätzlich zu einem vorhandenen Paravirtual-Controller für WSFC mit Cluster-VMDK für Windows Server 2022 (BS-Build 20348.1547) und höher verwenden. Um NVMe-Controller-VM-Hardware verwenden zu können, muss die Hardwareversion 21 oder höher sein. Weitere Informationen finden Sie unter Setup für Windows Server Failover Clustering.
-
Verwendung es vNVME-Controllers für Festplatten im Multiwriter-Modus: Ab vSphere 8.0 Update 2 können Sie virtuelle NVMe-Controller für virtuelle Festplatten mit Multiwriter-Modus verwenden, die von Drittanbieter-Clusteranwendungen wie Oracle RAC verwendet werden.
-
USB 3.2-Unterstützung in virtueller eXtensible Host Controller Interface (xHCI): Mit vSphere 8.0 Update 2 ist der virtuelle xHCI-Controller mit 20 GBit/s kompatibel.
-
Schreibgeschützter Modus für angehängte virtuelle Festplatten: Mit vSphere 8.0 Update 2 können Sie eine virtuelle Festplatte schreibgeschützt an eine virtuelle Maschine anhängen, um temporäre Redo-Protokolle zu vermeiden und die Leistung für Anwendungsfälle wie VMware App Volumes zu verbessern.
-
Unterstützung von VM-Klon, wenn eine First Class Disk (FCD) angehängt ist: Mit vSphere 8.0 Update 2 können Sie die
cloneVM()-API zum Klonen einer VM mit angehängter FCD verwenden.
GPU
-
GPU-Treiber-VM für beliebige Passthrough-GPU-Karte: Mit vSphere 8.0 Update 2 erleichtert eine GPU-Treiber-VM die Unterstützung neuer GPU-Anbieter für das virtuelle SVGA-Gerät (vSGA).
Speicher
-
Unterstützung für mehrere TCP-Verbindungen auf einem einzelnen NFS v3-Volume: Mit vSphere 8.0 Update 2 wird die Funktion „nConnect“, die die Unterstützung mehrerer TCP-Verbindungen für ein einzelnes NFS v3-Volume mithilfe von ESXCLI ermöglicht, für lokale Umgebungen vollständig unterstützt. Weitere Informationen finden Sie in den VMware-Knowledgebase-Artikeln 91497 und 91479.
-
ESXCLI-Unterstützung für SCSI-UNMAP-Vorgänge für vSphere Virtual Volumes: Ab vSphere 8.0 Update 2 können Sie die Befehlszeile ESXCLI für SCSI-UNMAP-Vorgänge für vSphere Virtual Volumes verwenden.
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:
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 2
In dieser Version von ESXi 8.0 Update 2 werden die folgenden Patches bereitgestellt:
Build-Details
| Download-Dateiname: |
VMware-ESXi-8.0U2-22380479-depot.zip |
| Build: |
22380479 |
| Download-Größe: |
615,7 MB |
| sha256checksum: |
76dbd1f0077b20b765c8084e74a5fd012c0c485297f60530e1f9703bdf051b5c |
| Neustart des Hosts erforderlich: |
Ja |
| Migration oder Herunterfahren der virtuellen Maschine erforderlich: |
Ja |
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 |
| ESXi80U2-22380479 |
Verbesserung |
Wichtig |
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.0U2-22380479-standard |
| ESXi-8.0U2-22380479-no-tools |
ESXi-Image
| Name und Version |
Datum der Veröffentlichung |
Kategorie |
Detail |
|---|---|---|---|
| ESXi_8.0.2-0.0.22380479 |
21.09.2023 |
Allgemein |
Fehlerkorrektur-Image |
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. Hierzu müssen Sie die ZIP-Datei des Patch-Offline-Pakets von der Seite VMware-Download oder der Seite Produkt-Patches manuell herunterladen und den Befehl esxcli software profile update verwenden. Weitere Informationen finden Sie unter Vorgehensweise zum Herunterladen einer ZIP-Datei für ESXi-Patches und -Updates, Aktualisieren von Hosts mithilfe von ESXCLI-Befehlen und im Handbuch VMware ESXi-Upgrade.
Hinweise zu Produktunterstützung
-
Standardmäßige Einschränkung der Verwendung des ptrace-Systemaufrufs: Ab vSphere 8.0 Update 2 schränkt VMware die Verwendung des
ptrace-Systemaufrufs aufgrund von Sicherheitsbedenken standardmäßig ein. -
Das Internet Wide Area RDMA Protocol (iWARP) auf Intel X722-Netzwerkkartenhardware wird eingestellt: Mit vSphere 8.0 Update 2 wird iWARP auf Intel X722-Netzwerkkartenhardware nicht mehr unterstützt.
-
Veraltete SOAP API-Verträge: Mit vSphere 8.0 Update 2 sind WSDL-basierte SOAP API-Verträge von vSphere 5.5 und früheren Versionen veraltet und werden in einer zukünftigen vSphere-Version entfernt. Alle vSphere-Automatisierung auf der Grundlage von VMware- oder Drittanbietertools, die vSphere 5.5 oder frühere Verträge nutzen, müssen auf neuere Tools aktualisiert werden.
-
NVMe-Standardversion 1.3 für virtuelle Windows-Maschinen: Ab vSphere 8.0 Update 2 ist die NVMe-Version von virtuellen Windows Server 2022- oder Windows 11-Maschinen und höher mit Hardwareversion 21 und höher und einem virtuellen NVMe-Controller standardmäßig auf 1.3 festgelegt. Für das ordnungsgemäße Hinzufügen, Entfernen und Erweitern von NVMe im laufenden Betrieb müssen Sie Windows mindestens auf KB5029250 (BS-Version 20348.1906) für Windows Server 2022 und KB5028254 (BS-Build 22621.2070) für Windows 11 aktualisieren.
-
TLS 1.3-Unterstützung: vSphere 8.0 Update 2 führt partiellen Support für TLS 1.3 in ESXi ein. vCenter bleibt bei TLS 1.2.
-
Unterstützung von NVMe/TCP im ENS-Modus (Enhanced Networking Stack) für den qedentv-Treiber: Ab vSphere 8.0 Update 2 bietet der VMware-qedentv-Netzwerkkartentreiber von Marvell Unterstützung für NVMe/TCP im ENS-Modus.
Installations- und Upgrade-Hinweise für diese Version
-
Beim Aktualisieren von vSphere Distributed Service Engine-Hosts, die mit NVIDIA BlueField-2 (BF2)-DPUs konfiguriert sind, auf ESXi 8.0 Update 2 müssen Sie eine bestimmte Reihenfolge für das Upgrade der ESXi- und BF2-DPU-Firmware im selben Wartungsfenster befolgen:
-
Versetzen Sie den vSphere Distributed Service Engine-Host in den Wartungsmodus.
-
Stellen Sie sicher, dass die NIC- und ARM-Firmware der BF2-DPU nicht aktualisiert wird und weiterhin Firmware ausführen, die für ESXi-Versionen vor 8.0 Update 2 gilt, wie z. B. NIC-Firmware-Version 24.33.1246 und ARM-Firmware-Version 18.2.0.12580.
-
Aktualisieren Sie ESXi auf Version 8.0 Update 2.
-
Führen Sie ein Upgrade der BF2-DPU-ARM-Firmware (UEFI und ATF) auf Version 4.0.2.12722 durch, die für ESXi 8.0 Update 2 erforderlich ist.
-
Führen Sie ein Upgrade der BF2-DPU-Netzwerkkarten-Firmware auf 24.36.7506 durch. Dies ist die Firmware-Version, die für ESXi 8.0 Update 2-Treiber erforderlich ist.
-
Beenden Sie den Wartungsmodus für den vSphere Distributed Service Engine-Host.
Wenn Sie die Schritte nicht in dieser Reihenfolge ausführen, schlägt das ESXi-Rollback fehl, und Sie können die BF2-DPU-basierte vSphere Distributed Service Engine-Hostkonfiguration nicht wiederherstellen, wenn das Upgrade fehlschlägt.
-
-
Änderungen bei VMware Tools-Bündelung in ESXi 8.0 Update 2
-
Die folgenden VMware Tools-ISO-Images werden mit ESXi 8.0 Update 2 gebündelt:
-
windows.iso: VMware Tools 12.3.0 unterstützt Windows 7 SP1 oder Windows Server 2008 R2 SP1 oder höher.
-
linux.iso: VMware Tools 10.3.25-ISO-Image für das Linux-Betriebssystem mit glibc 2.11 oder höher.
Die folgenden VMware Tools-ISO-Images stehen zum Download zur Verfügung:
-
VMware Tools 11.0.6:
-
windows.iso: für Windows Vista (SP2) und Windows Server 2008 Service Pack 2 (SP2).
-
-
VMware Tools 10.0.12:
-
winPreVista.iso: für Windows 2000, Windows XP und Windows 2003.
-
linuxPreGLibc25.iso: unterstützt Linux-Gastbetriebssysteme vor Red Hat Enterprise Linux (RHEL) 5, SUSE Linux Enterprise Server (SLES) 11, Ubuntu 7.04 und andere Distributionen mit einer glibc-Version vor 2.5.
-
-
solaris.iso: VMware Tools-Image 10.3.10 für Solaris.
-
darwin.iso: Unterstützt Mac OS X-Versionen 10.11 und höher.
Befolgen Sie die in den folgenden Dokumenten aufgeführten Vorgehensweisen, um VMware Tools für Plattformen, die nicht mit ESXi gebündelt sind, herunterzuladen:
-
-
Behobene Probleme
- Sicherheitsprobleme
- Installations-, Upgrade- und Migrationsprobleme
- Sonstige Probleme
- Netzwerkprobleme
- Probleme bei vSphere Lifecycle Manager
Sicherheitsprobleme
-
ESXi 8.0 Update 2 enthält den folgenden Intel-Microcode:
Codename
FMS
PLT-ID
MCU-Rev.
MCU-Datum
Markennamen
Nehalem EP
0x106a5 (06/1a/5)
0x03
0x1d
5/11/2018
Intel Xeon 35xx-Reihe; Intel Xeon 55xx-Reihe
Clarkdale
0x20652 (06/25/2)
0x12
0x11
5/8/2018
Intel i3/i5 Clarkdale-Reihe; Intel Xeon 34xx Clarkdale-Reihe
Arrandale
0x20655 (06/25/5)
0x92
0x7
4/23/2018
Intel Core i7-620LE-Prozessor
Sandy Bridge DT
0x206a7 (06/2a/7)
0x12
0x2f
2/17/2019
Intel Xeon E3-1100-Reihe; Intel Xeon E3-1200-Reihe; Intel i7-2655-LE-Reihe; Intel i3-2100-Reihe
Westmere EP
0x206c2 (06/2c/2)
0x03
0x1f
5/8/2018
Intel Xeon 56xx-Reihe; Intel Xeon 36xx-Reihe
Sandy Bridge EP
0x206d6 (06/2d/6)
0x6d
0x621
3/4/2020
Intel Pentium 1400-Reihe; Intel Xeon E5-1400-Reihe; Intel Xeon E5-1600-Reihe; Intel Xeon E5-2400-Reihe; Intel Xeon E5-2600-Reihe; Intel Xeon E5-4600-Reihe
Sandy Bridge EP
0x206d7 (06/2d/7)
0x6d
0x71a
3/24/2020
Intel Pentium 1400-Reihe; Intel Xeon E5-1400-Reihe; Intel Xeon E5-1600-Reihe; Intel Xeon E5-2400-Reihe; Intel Xeon E5-2600-Reihe; Intel Xeon E5-4600-Reihe
Nehalem EX
0x206e6 (06/2e/6)
0x04
0xd
5/15/2018
Intel Xeon 65xx-Reihe; Intel Xeon 75xx-Reihe
Westmere EX
0x206f2 (06/2f/2)
0x05
0x3b
5/16/2018
Intel Xeon E7-8800-Reihe; Intel Xeon E7-4800-Reihe; Intel Xeon E7-2800-Reihe
Ivy Bridge DT
0x306a9 (06/3a/9)
0x12
0x21
2/13/2019
Intel i3-3200-Reihe; Intel i7-3500-LE/UE; Intel i7-3600-QE; Intel Xeon E3-1200-v2-Reihe; Intel Xeon E3-1100-C-v2-Reihe; Intel Pentium B925C
Haswell DT
0x306c3 (06/3c/3)
0x32
0x28
11/12/2019
Intel Xeon E3-1200-v3-Reihe; Intel i7-4700-EQ-Reihe; Intel i5-4500-TE-Reihe; Intel i3-4300-Reihe
Ivy Bridge EP
0x306e4 (06/3e/4)
0xed
0x42e
3/14/2019
Intel Xeon E5-4600-v2-Reihe; Intel Xeon E5-2600-v2-Reihe; Intel Xeon E5-2400-v2-Reihe; Intel Xeon E5-1600-v2-Reihe; Intel Xeon E5-1400-v2-Reihe
Ivy Bridge EX
0x306e7 (06/3e/7)
0xed
0x715
3/14/2019
Intel Xeon E7-8800/4800/2800-v2-Reihe
Haswell EP
0x306f2 (06/3f/2)
0x6f
0x49
8/11/2021
Intel Xeon E5-4600-v3-Reihe; Intel Xeon E5-2600-v3-Reihe; Intel Xeon E5-2400-v3-Reihe; Intel Xeon E5-1600-v3-Reihe; Intel Xeon E5-1400-v3-Reihe
Haswell EX
0x306f4 (06/3f/4)
0x80
0x1a
5/24/2021
Intel Xeon E7-8800/4800-v3-Serie
Broadwell H
0x40671 (06/47/1)
0x22
0x22
11/12/2019
Intel Core i7-5700EQ; Intel Xeon E3-1200-v4-Reihe
Avoton
0x406d8 (06/4d/8)
0x01
0x12d
16.09.2019
Intel Atom C2300-Reihe; Intel Atom C2500-Reihe; Intel Atom C2700-Reihe
Broadwell EP/EX
0x406f1 (06/4f/1)
0xef
0xb000040
5/19/2021
Intel Xeon E7-8800/4800-v4-Reihe; Intel Xeon E5-4600-v4-Reihe; Intel Xeon E5-2600-v4-Reihe; Intel Xeon E5-1600-v4-Reihe
Skylake SP
0x50654 (06/55/4)
0xb7
0x2007006
06.03.2023
Intel Xeon Platinum 8100-Reihe; Intel Xeon Gold 6100/5100, Silver 4100, Bronze 3100-Reihe; Intel Xeon D-2100-Reihe; Intel Xeon D-1600-Reihe; Intel Xeon W-3100-Reihe; Intel Xeon W-2100-Reihe
Cascade Lake B-0
0x50656 (06/55/6)
0xbf
0x4003604
17.03.2023
Intel Xeon Platinum 9200/8200-Reihe; Intel Xeon Gold 6200/5200; Intel Xeon Silver 4200/Bronze 3200; Intel Xeon W-3200
Cascade Lake
0x50657 (06/55/7)
0xbf
0x5003604
17.03.2023
Intel Xeon Platinum 9200/8200-Reihe; Intel Xeon Gold 6200/5200; Intel Xeon Silver 4200/Bronze 3200; Intel Xeon W-3200
Cooper Lake
0x5065b (06/55/b)
0xbf
0x7002703
21.03.2023
Intel Xeon Platinum 8300-Reihe; Intel Xeon Gold 6300/5300
Broadwell DE
0x50662 (06/56/2)
0x10
0x1c
17.06.2019
Intel Xeon D-1500-Reihe
Broadwell DE
0x50663 (06/56/3)
0x10
0x700001c
6/12/2021
Intel Xeon D-1500-Reihe
Broadwell DE
0x50664 (06/56/4)
0x10
0xf00001a
6/12/2021
Intel Xeon D-1500-Reihe
Broadwell NS
0x50665 (06/56/5)
0x10
0xe000014
9/18/2021
Intel Xeon D-1600-Reihe
Skylake H/S
0x506e3 (06/5e/3)
0x36
0xf0
11/12/2021
Intel Xeon E3-1500-v5-Reihe; Intel Xeon E3-1200-v5-Reihe
Denverton
0x506f1 (06/5f/1)
0x01
0x38
12/2/2021
Intel Atom C3000-Reihe
Ice Lake SP
0x606a6 (06/6a/6)
0x87
0xd0003a5
30.03.2023
Intel Xeon Platinum 8300-Reihe; Intel Xeon Gold 6300/5300-Reihe; Intel Xeon Silver 4300-Reihe
Ice Lake D
0x606c1 (06/6c/1)
0x10
0x1000230
27.01.2023
Intel Xeon D-2700-Reihe; Intel Xeon D-1700-Reihe
Snow Ridge
0x80665 (06/86/5)
0x01
0x4c000023
22.02.2023
Intel Atom P5000 Series
Snow Ridge
0x80667 (06/86/7)
0x01
0x4c000023
22.02.2023
Intel Atom P5000 Series
Tiger Lake U
0x806c1 (06/8c/1)
0x80
0xac
27.02.2023
Intel Core i3/i5/i7-1100-Reihe
Tiger Lake U Refresh
0x806c2 (06/8c/2)
0xc2
0x2c
27.02.2023
Intel Core i3/i5/i7-1100-Reihe
Tiger Lake H
0x806d1 (06/8d/1)
0xc2
0x46
27.02.2023
Intel Xeon W-11000E-Reihe
Sapphire Rapids SP HBM
0x806f8 (06/8f/8)
0x10
0x2c0001d1
14.02.2023
Intel Xeon Max 9400-Reihe
Sapphire Rapids SP
0x806f8 (06/8f/8)
0x87
0x2b000461
13.03.2023
Intel Xeon Platinum 8400-Reihe; Intel Xeon Gold 6400/5400-Reihe; Intel Xeon Silver 4400-Reihe; Intel Xeon Bronze 3400-Reihe
Kaby Lake H/S/X
0x906e9 (06/9e/9)
0x2a
0xf4
23.02.2023
Intel Xeon E3-1200-v6-Reihe; Intel Xeon E3-1500-v6-Reihe
Coffee Lake
0x906ea (06/9e/a)
0x22
0xf4
23.02.2023
Intel Xeon E-2100-Reihe; Intel Xeon E-2200-Reihe (4 oder 6 Kerne)
Coffee Lake
0x906eb (06/9e/b)
0x02
0xf4
23.02.2023
Intel Xeon E-2100-Reihe
Coffee Lake
0x906ec (06/9e/c)
0x22
0xf4
23.02.2023
Intel Xeon E-2100-Reihe
Coffee Lake Refresh
0x906ed (06/9e/d)
0x22
0xfa
27.02.2023
Intel Xeon E-2200-Reihe (8 Kerne)
Rocket Lake S
0xa0671 (06/a7/1)
0x02
0x59
26.02.2023
Intel Xeon E-2300-Reihe
-
ESXi 8.0 Update 2 enthält den folgenden Microcode für AMD-CPUs:
Codename
FMS
MCU-Rev.
MCU-Datum
Markennamen
Bulldozer
0x600f12 (15/01/2)
0x0600063e
07.02.2018
Serie Opteron 6200/4200/3200
Piledriver
0x600f20 (15/02/0)
0x06000852
06.02.2018
Serie Opteron 6300/4300/3300
Zen-Naples
0x800f12 (17/01/2)
0x0800126e
11.11.2021
Serie EPYC 7001
Zen2-Rome
0x830f10 (17/31/0)
0x0830107a
17.05.2023
Serie EPYC 7002/7Fx2/7Hx2
Zen3-Milan-B1
0xa00f11 (19/01/1)
0x0a0011d1
10.07.2023
Serie EPYC 7003/7003X
Zen3-Milan-B2
0xa00f12 (19/01/2)
0x0a001234
10.07.2023
Serie EPYC 7003/7003X
Installations-, Upgrade- und Migrationsprobleme
-
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.logenthält Protokolle wie etwaFailed to get SFHC response. MessageType MT_SOFTWARE_STATUS.Dieses Problem wurde in der vorliegenden Version behoben.
Sonstige Probleme
-
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 volume1Validation 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.
Dieses Problem wurde in der vorliegenden Version behoben.
-
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.
Dieses Problem wurde in der vorliegenden Version behoben.
-
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.
Dieses Problem wurde in der vorliegenden Version behoben.
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.
Dieses Problem wurde in der vorliegenden Version behoben.
-
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.
-
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.Dieses Problem wurde in der vorliegenden Version behoben.
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.Dieses Problem wurde in der vorliegenden Version behoben.
Bekannte Probleme
Sonstige Probleme
-
Wenn IPv6 deaktiviert ist, wird beim Starten des ESXi-Hosts möglicherweise der Fehler „Jumpstart plugin restore-networking activation failed“ angezeigt
In der ESXi-Konsole wird während der Startsequenz eines Hosts möglicherweise das Fehlerbanner
Jumpstart plugin restore-networking activation failedangezeigt. Das Banner wird nur angezeigt, wenn IPv6 deaktiviert ist, und gibt keinen tatsächlichen Fehler an.Problemumgehung: Aktivieren Sie IPv6 auf dem ESXi-Host oder ignorieren Sie die Meldung.
-
In einer HPP-Umgebung (High Performance Plug-In) kann ein Netzwerkausfall einen Hostausfall auslösen
In HPP-Umgebungen, die darauf abzielen, die Leistung von NVMe-Geräten auf ESXi-Hosts zu verbessern, treten bei einem Netzwerkausfall möglicherweise zwei Probleme auf:
-
Bei vom HPP beanspruchten lokalen SCSI-Geräten mit Mehrfachpfaden (Aktiv-Aktiv-Präsentation) schlagen VM-E/A-Vorgänge möglicherweise vorzeitig fehl, anstatt auf dem anderen Pfad wiederholt zu werden.
-
Wenn bei vom HPP beanspruchten lokalen SCSI-Geräten in einem APD-Szenario (All Paths Down, Keine Pfade verfügbar) eine vollständige erneute Speicherprüfung von vCenter ausgelöst wird, schlägt der ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm fehl.
Beide Probleme treten nur bei lokalen SCSI-Geräten oder beim Fehlschlagen von E/A-Vorgängen aufgrund eines fehlenden Netzwerks oder nicht vorhandener Pfade auf.
Problemumgehung: Fügen Sie Benutzer-Claimrules hinzu, um Geräte mit dem ESXi-NMP (Natives Multipathing-Plug-In) anstelle des HPP zu beanspruchen. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 94377.
-
-
TCP-Verbindungen werden auf einem ESXi-Host mit Enhanced Networking Stack zeitweise unterbrochen
Wenn sich die Absender-VM auf einem ESXi-Host mit Enhanced Networking Stack befindet, können Probleme mit der Interoperabilität der TCP-Prüfsumme zum Ausfall des Endsystems oder zur Verzögerung des TCP-Pakets führen, wenn der Wert der TCP-Prüfsumme in einem Paket als
0xFFFFberechnet wird.Problemumgehung: Deaktivieren Sie die TCP-Prüfsummenauslagerung auf der Absender-VM auf ESXi-Hosts mit Enhanced Networking Stack. Unter Linux können Sie den Befehl
sudo ethtool -K <interface> tx offverwenden.
Sicherheitsprobleme
-
Trotz deaktiviertem Sperrmodus auf einem ESXi-Host wird die Sperrung nach einem Neustart des Hosts weiterhin als aktiv gemeldet
Trotz deaktiviertem Sperrmodus auf einem ESXi-Host wird dieser nach einem Neustart des Hosts weiterhin als aktiv angezeigt.
Problemumgehung: Fügen Sie Benutzer
dcuiundvpxuserzur Liste der Sperrmodus-Ausnahmebenutzer hinzu und deaktivieren Sie den Sperrmodus nach dem Neustart. Weitere Informationen finden Sie unter Angeben von Sperrmodus-Ausnahmebenutzern und Angeben von Sperrmodus-Ausnahmebenutzern im VMware Host Client.
Netzwerkprobleme
-
Geringe Übertragungsgeschwindigkeit in IPv6-Umgebungen mit aktivem TCP-Segmentierungs-Offload
In Umgebungen mit aktivem IPv6-TCP-Segmentierungs-Offload (TSO) ist die Übertragungsgeschwindigkeit für virtuelle Windows-Maschinen mit einer virtuellen e1000e-Netzwerkkarte möglicherweise gering. In IPv4-Umgebungen tritt das Problem nicht auf.
Problemumgehung: Deaktivieren Sie TSO oder verwenden Sie einen vmxnet3-Adapter anstelle von e1000e.
-
Wenn Sie eine VM von einem ESXi-Host mit einem im SmartNIC-Modus (ECPF) betriebenen DPU-Gerät zu einem ESXi-Host mit einem DPU-Gerät im herkömmlichen Netzwerkkartenmodus migrieren, wird der Overlay-Datenverkehr möglicherweise unterbrochen
Bei Verwendung von vSphere vMotion zum Migrieren einer mit einem Overlay-gestützten Segment verbundenen VM von einem ESXi-Host mit einem vSphere Distributed Switch, der im Auslagerungsmodus (bei dem die Datenverkehrsweiterleitungslogik an die DPU ausgelagert wird) betrieben wird, zu einem ESXi-Host mit einem VDS im Nicht-Auslagerungsmodus (wobei DPUs als herkömmliche Netzwerkkarte verwendet werden) wird der Overlay-Datenverkehr nach der Migration unter Umständen unterbrochen.
Problemumgehung: Deaktivieren und aktivieren Sie die virtuelle Netzwerkkarte auf dem ESXi-Zielhost.
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:
-
Aktivieren Sie die Option
media-auto-detectin 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. -
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.
-
-
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, beispielsweisedevice_rss,drssundrss, 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,drssundrsswie folgt:-
device_rss: Verwenden Sie den ParameterDRSS -
drss: Verwenden Sie den ParameterDRSS -
rss: Verwenden Sie den ParameterRSS
-
-
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 userstehen, 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.getin der Shellapplianceshabrufen. 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
-
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-fzum Erzwingen eines Neustarts wird für ESXi-Installationen mit einer DPU nicht unterstützt. Obwohl ESXi 8.0 die Option-fzum Erzwingen eines Neustarts unterstützt, kann der erzwungene Neustart einen ungültigen Status verursachen, wenn Siereboot -fin 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
vSwitchBMCmit Uplinkvusb0auf 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 SwitchesvSwitchBMCund zugehöriger Portgruppen beim nächsten Neustart des Hosts zu verhindern.Hier ein Skript als Beispiel:
~# esxcfg-advcfg -s 0 /Net/BMCNetworkEnableDer Wert von BMCNetworkEnable ist 0, und der Dienst ist deaktiviert.
~# rebootBeim 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.
Netzwerkprobleme
-
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 beintg3-Treibern mit Versionen vor 4.1.3 oder demtg3-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, einenntg3-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 ModulparameternoPhyStateSetauf1. Der ParameternoPhyStateSetist standardmäßig auf0gesetzt und wird in den meisten Umgebungen nicht benötigt, es sei denn, sie sind von dem Problem betroffen. -
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:
-
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.
-
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
-
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.
-
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/coreangezeigt. Die vpxa-Protokolle enthalten die ZeileToo 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 upgradefehlschlagen.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
-
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 OKlauten, während sie im XCC und IPMITransition to OKlautet.Problemumgehung: Überprüfen Sie die Beschreibungen für Schweregrad-Ereigniszustände mithilfe des ESXCLI-Befehls
esxcli hardware ipmi sdr listund 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.
