VMware ESXi 8.0 Update 3 | 25. Juni 2024 | ISO-Build 24022510

Überprüfen Sie, ob Erweiterungen und Updates für diese Versionshinweise zur Verfügung stehen.

Allgemeine Verfügbarkeit

Diese ESXi 8.0 Update 3-Version 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

In dieser Version wurden CVE-2024-37085 und CVE-2024-37086 behoben. Weitere Informationen zu diesen Schwachstellen und deren Auswirkungen auf VMware Produkte finden Sie unter VMSA-2024-0013.

Einen Überblick über die neuen Funktionen in vSphere 8.0 Update 3 finden Sie unter Neue Funktionen in vSphere 8 Update 3 und den folgenden Versionshinweisen:

Die folgende Liste enthält die wichtigsten neuen Funktionen und Verbesserungen für vSphere 8.0 Update 3:

  • DPU/SmartNIC

    • Hochverfügbarkeit mit VMware vSphere Distributed Services Engine: Ab ESXi 8.0 Update 3 bietet vSphere Distributed Services Engine Unterstützung für 2 Datenverarbeitungseinheiten (DPUs), um Hochverfügbarkeit bereitzustellen oder die Auslagerungskapazität pro ESXi-Host zu erhöhen. Systeme mit zwei DPUs können NVIDIA- oder Pensando-Geräte nutzen. In ESXi 8.0 Update 3 werden Systeme mit zwei DPUs von Lenovo-Serverdesigns unterstützt. Weitere Informationen finden Sie unter Hochverfügbarkeit mit VMware vSphere Distributed Services Engine.

  • vSphere IaaS Control Plane

    • Unterstützung der Ausführung von vSphere IaaS Control Plane auf vSAN Stretched Clustern: vSphere 8.0 Update 3 bietet Unterstützung für vSphere IaaS Control Plane, zuvor als vSphere with Tanzu bezeichnet, auf vSAN Stretched Clustern. Diese Funktion ist nur für Greenfield-Installationen von IaaS Control Plane auf vSAN Stretched Clustern verfügbar. Wenn Sie bereits IaaS Control Plane oder vSphere with Tanzu mit Inhaltsbibliothek verwenden, müssen Sie diese erneut bereitstellen, bevor Sie vSAN Stretched Cluster-Speicherrichtlinien verwenden.

      Bevor Sie diese Funktion konfigurieren, lesen Sie Running vSphere IaaS Control Plane on vSAN Stretched Cluster und folgen Sie den Inhalten auf https://core.vmware.com.

  • Verwalten von virtuellen Maschinen

    • Neue Computing-Richtlinie für virtuelle Maschinen für bestmögliche Evakuierung virtueller Maschinen: Mit vSphere 8.0 Update 3 wird eine Computing-Richtlinie für eine bestmögliche Evakuierung von virtuellen Maschinen auf ESXi-Hosts hinzugefügt, die in den Wartungsmodus wechseln. Wenn der Host in den Wartungsmodus wechselt, werden alle VMs heruntergefahren. Wenn das Herunterfahren fehlschlägt, werden die VMs ausgeschaltet. Wenn das Ausschalten fehlschlägt, müssen Sie die VMs evakuieren. Wenn sich die VMs bei Nutzung der neuen Funktion im ausgeschalteten Zustand befinden, versucht vCenter alle paar Minuten, die ausgeschalteten VMs auf dem besten verfügbaren ESXi-Host wieder einzuschalten. Diese Richtlinie hat Vorrang vor allen auf VM-Ebene festgelegten DRS-Außerkraftsetzungen, und die Hosts, auf denen die VMs eingeschaltet werden, unterscheiden sich möglicherweise vom ursprünglichen Host.

  • vSphere Cluster Service

    • Einführung des Embedded vSphere Cluster Service (vCLS): In vSphere 8.0 Update 3 wird Embedded vCLS als Neugestaltung von vCLS eingeführt, bei dem die vSphere Pod-Technologie genutzt wird. Die Bereitstellung und der Lebenszyklus dieser VMs werden innerhalb von ESXi und nicht mehr vom vSphere ESX Agent Manager (EAM) verwaltet. Frühere Versionen von vCLS werden als externer vCLS bezeichnet. Probleme, die zuvor mit externem vCLS aufgetreten sind, wurden in dieser Version von Embedded vCLS behoben. Während die vorhandene API-Kompatibilität beibehalten wird, sind möglicherweise kleinere Änderungen an Kundenskripts oder Automatisierungstools erforderlich. Andere Produkte und Lösungen, die eine Geschäftslogik im Zusammenhang mit externem vCLS definiert haben, funktionieren möglicherweise nicht mit Embedded vCLS. Informationen zur Unterstützung der Interoperabilität und den Auswirkungen finden Sie in der jeweiligen Produktdokumentation. Weitere Informationen finden Sie unter vSphere Cluster Services und den Inhalten, die bei vSphere Technical Marketing im Broadcom Support Portal verfügbar sind.

  • vSAN

  • Sicherheit

    • Unterstützung von TLS 1.3 und 1.2 mithilfe von TLS-Profilen: Ab vSphere 8.0 Update 3 können Sie TLS-Profile verwenden, um die Konfiguration von TLS-Parametern zu vereinfachen und die Unterstützungsfähigkeit in Ihrem vSphere-System zu verbessern. Mit vSphere 8.0 Update 3 erhalten Sie das TLS-Standardprofil COMPATIBLE auf ESXi- und vCenter Server-Hosts, das TLS 1.3 und einige TLS 1.2-Verbindungen unterstützt. Weitere Informationen finden Sie unter vSphere-TLS-Konfiguration.

    • PingFederate-Identitätsanbieter für vSphere: Mit vSphere 8.0 Update 3 können Sie PingFederate als externen Identitätsanbieter in Ihrem vSphere-System konfigurieren. Weitere Informationen finden Sie unter Konfigurieren des vCenter Server-Identitätsanbieters für PingFederate.

  • Speicher/Arbeitsspeicher

    • Mehrstufiger Arbeitsspeicher: vSphere 8.0 Update 3 führt in der Tech Preview die Funktion für mehrstufigen Arbeitsspeicher ein, mit der Sie NVMe-Geräte verwenden können, die Sie einem ESXi-Host lokal als mehrstufigen Arbeitsspeicher hinzufügen können. Mehrstufiger Arbeitsspeicher über NVMe optimiert die Arbeitsspeichernutzung, indem VM-Arbeitsspeicherzuteilungen entweder an NVMe-Geräte oder an einen schnelleren DRAM (Dynamic Random Access Memory) auf dem Host geleitet werden. Auf diese Weise können Sie den Arbeitsspeicherbedarf und die Arbeitslastkapazität erhöhen und gleichzeitig die Gesamtbetriebskosten (TCO) reduzieren. Weitere Informationen zur Tech Preview finden Sie unter KB 95944.

    • Unterstützung von Fabric Notification für SAN-Cluster: ESXi 8.0 Update 3 bietet jetzt Unterstützung für Fabric Performance Impact Notifications Link Integrity (FPIN-LI). Mit FPIN-LI kann die vSphere-Infrastrukturebene Benachrichtigungen von SAN-Switches oder -Zielen verwalten, herabgestufte SAN-Links identifizieren und sicherstellen, dass nur fehlerfreie Pfade für Speichergeräte verwendet werden. FPIN kann ESXi-Hosts auch über Überlastung und Fehler bei Speicherlinks benachrichtigen.

    • Unterstützung für Anfragen zur Speicherplatzrückforderung von Gastbetriebssystemen auf NVMe-gestützten vSphere Virtual Volumes-Datenspeichern und Config-vVol: ESXi 8.0 Update 3 bietet Unterstützung für Anfragen zur automatischen Speicherplatzrückforderung von Gastbetriebssystemen auf NVMe-gestützten vSphere Virtual Volumes-Datenspeichern. ESXi 8.0 Update 3 bietet auch Unterstützung für die befehlszeilenbasierte und automatische Aufhebung der Zuordnung für vSphere Virtual Volumes Objekte des Typs Config-vVol, die mit VMFS-6 formatiert sind. Weitere Informationen finden Sie unter Zurückgewinnen von Speicherplatz auf den vSphere Virtual Volumes-Datenspeichern.

    • Verwalten der UNMAP-Last von ESXi-Hosts auf VMFS-Datenspeicherebene: Ab ESXi 8.0 Update 3 können Sie die Unmap-Last auf Datenspeicherebene steuern, um Zeitverzögerungen bei der Speicherplatzrückforderung zu vermeiden und die gesamte Unmap-Last auf den Arrays in Ihrer Umgebung zu reduzieren. Weitere Informationen finden Sie unter Speicherplatzrückforderung auf VMFS-Datenspeichern in vSphere.

    • Verbesserungen bei Windows Server Failover Clustering (WSFC) auf vSphere Virtual Volumes: vSphere 8.0 Update 3 bietet Unterstützung für eine WSFC-Lösung für NVMe-gestützte Festplatten auf vSphere Virtual Volumes. Diese Funktion ermöglicht die Unterstützung von NVMe-Reservierungen in NVMe/TCP-Umgebungen, abgesehen von der Fibre-Channel-Unterstützung für WSFC auf vSphere Virtual Volumes. Virtuelle NVMe (vNVME)-Controller werden als Frontend für WSFC mit NVMe-gestützten Festplatten und nicht mit SCSI-gestützten Festplatten unterstützt. Weitere Informationen finden Sie unter Unterstützung von VMware vSphere® Virtual Volumes für WSFC.

    • Unterstützung von Aktiv/Aktiv-vSphere Metro Storage Cluster (vMSC) mit vSphere Virtual Volumes: Mit vSphere 8.0 Update 3 wird eine neue Version der VMware vSphere Storage APIs for Array Integration (VASA) eingeführt, um Aktiv/Aktiv-Stretched-Storage-Cluster mit vSphere Virtual Volumes mit Aktiv/Aktiv-Bereitstellungstopologien für den SCSI-Blockzugriff zwischen zwei Sites zu unterstützen. VASA Version 6 enthält eine neue Architektur und ein neues Design für die Unterstützung der Hochverfügbarkeit des VASA-Anbieters sowohl für Stretched als auch für Nicht-Stretched Storage-Cluster. Weitere Informationen finden Sie unter Verwenden von Stretched Storage Clustering mit Virtual Volumes.

    • VMkernel-Port-Bindung für NFS v4.1-Datenspeicher: Mit vSphere 8.0 Update 3 können Sie eine NFS 4.1-Verbindung an einen bestimmten VM-Kerneladapter binden. Wenn Sie Multipathing verwenden, können Sie mehrere vmknics für jede Verbindung bereitstellen, um Pfadisolierung und Sicherheit zu gewährleisten, indem Sie den NFS-Datenverkehr über ein bestimmtes Subnetz/VLAN leiten, sodass für den NFS-Datenverkehr keine anderen vmknics verwendet werden. Weitere Informationen finden Sie unter Konfigurieren einer VMkernel-Bindung für NFS 4.1-Datenspeicher.

    • Unterstützung für nConnect für NFS v4.1-Datenspeicher: ESXi 8.0 Update 3 bietet Unterstützung für mehrere TCP-Verbindungen für ein NFS v4.1-Volume, das auch als nConnect bezeichnet wird. Für NFS v4.1 werden mehrere TCP-Verbindungen für eine einzelne Sitzung erstellt, die von vielen Datenspeichern parallel gemeinsam verwendet werden kann. Sie kann mithilfe der vSphere API oder von ESXCLI direkt auf einem ESXi-Host konfiguriert werden. Weitere Informationen finden Sie unter Konfigurieren mehrerer TCP-Verbindungen für NFS (Configure Multiple TCP Connections for NFS).

    • Weniger Zeit zum Vergrößern von VMFS-Festplatten: Ab vSphere 8.0 Update 3 können Sie mit einer neuen VMFS-API eine per Thin Provisioning bereitgestellte Festplatte auf Eagerzeroedthick (EZT) vergrößern, während die Festplatte verwendet wird und bis zu 10 Mal schneller als vorherige alternative Methoden ist. Während der Vergrößerung werden alle Blöcke vollständig zugeteilt und im Voraus auf null gesetzt, um eine schnellere Laufzeitleistung zu ermöglichen. Weitere Informationen finden Sie unter Optionen für virtuelle Festplatten (Virtual Disk Options).

    • Verbesserte Widerstandsfähigkeit gegen Arbeitsspeicherbeschädigung auf RAM-intensiven ESXi-Hosts: vSphere 8.0 Update 3 bietet proaktive Maßnahmen, um Arbeitsspeicherfehler in Systemen mit VMs mit mehr als 1 TB zu verhindern, die einen vollständigen ESXi-Host zum Absturz bringen und die Ausfallzeit von Anwendungen erhöhen können.

    • Erweiterte Einstellung, mit der das Löschen und Entfernen von Festplatten für VMs mit Snapshots blockiert werden kann: ESX 8.0 Update 3 bietet die erweiterte Option blockDiskRemoveIfSnapshot pro Host, um zu verhindern, dass Festplatten von einer VM mit Snapshots entfernt werden, selbst wenn Sie Dateien löschen, was zu verwaisten Festplatten führen kann. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 94545.

    • Unterstützung für hardwarebeschleunigte Verschiebungen (Klonvorgänge) auf NVMe-Geräten: vSphere 8.0 Update 3 unterstützt den NVMe-Kopierbefehl für hardwarebeschleunigte Verschiebungen (auch als Klonblöcke oder Copy Offload bezeichnet) über NVMe-Namespaces hinweg oder innerhalb von NVMe-Namespaces, die zum selben NVMe-Subsystem gehören.

    • Präzise Überwachung der Zugriffsfähigkeit des VASA-Anbieters und des Authentifizierungsstatus der Zertifizierung auf ESXi-Hostebene: Mit vSphere 8.0 Update 3 können Sie den Verbindungsstatus überwachen und die ESXi-Authentifizierung mit VASA-Speicheranbietern vom vSphere Client aus überwachen und Hosts nach Bedarf erneut authentifizieren. Weitere Informationen finden Sie unter Reauthenticate VASA Client in ESXi.

  • Gast-BS

    • Die Gastanpassung unterstützt das RHEL NetworkManager-Keyfile-Format: In vSphere 8.0 Update 3 bietet die Gastanpassung Unterstützung für das RHEL NetworkManager-Keyfile-Format, und Sie können die Netzwerkkonfiguration sowohl im Keyfile- als auch im ifcfg-Format speichern.

  • Treiber/Netzwerk

    • Unterstützung für Fibre Channel Extended Link Services (FC-ELS): Mit vSphere 8.0 Update 3 können Sie den Befehl esxcli storage fpin info set -e= <true/false> verwenden, um die Fabric Performance Impact Notification (FPIN) zu aktivieren oder zu deaktivieren. Der Befehl speichert die FPIN-Aktivierung sowohl in ConfigStore als auch in der VMkernel-Systemschnittstellen-Shell und wird auch bei ESXi-Neustarts beibehalten. Dies wird durch die lpfc-Treiber von Broadcom und die qlnativefc-Treiber von Marvel ermöglicht.

    • Unified Enhanced Networking Stack (UENS)-Treiber für den Elastic Network Adapter (ENA): vSphere 8.0 Update 3 unterstützt jetzt einen UENS-Treiber für ENA, der Konnektivität zur AWS-Underlay-Virtual Private Cloud (VPC) bereitstellt.

    • Overlay-Filter unterstützen den Tunnel-Endpunkt (Tunnel Endpoint, TEP): vSphere 8.0 Update 3 verbessert die i40en-, qedentv- und sfvmk-Netzwerkkartentreiber, indem Funktionen hinzugefügt werden, die Overlay-Filter verfügbar machen und die TEP-Funktionalität unterstützen.

    • Broadcom-Treiber-Updates: 

      • Broadcom bnxtnet-Treiber: Unterstützt NetQ RSS, um die zukünftige Unterstützung von Unified Enhanced Networking Stack (UENS) zu erleichtern.

    • Intel-Treiber-Updates: 

      • Intel i40en-Treiber: Die Anzahl der Warteschlangen pro RSS-Engine wurde von 4 auf 8 erhöht. Im ENS-Modus werden bis zu 16 Warteschlangen unterstützt.

      • Intel icen-Treiber: Fügt RoCE-Unterstützung auf 1000-GbE-Netzwerkkarte hinzu.

      • Intel irdman-Treiber: Fügt RoCE-Unterstützung auf 1000-GbE-Netzwerkkarte hinzu.

    • Marvell-Treiber-Updates:

      • Marvell qedentv-Treiber: Die maximale Anzahl der Warteschlangen für die Standard-RSS-Engine wurde im ENS-Modus von 4 auf 16 erhöht.

    • Mellanox-Treiber-Updates:

      • Mellanox nmlx5-Treiber: Fügt Unterstützung für Hardware-LRO (Large Receive Offload) im Modus „Erweiterter Datenpfad“ hinzu, um den eingehenden Durchsatz von Netzwerkverbindungen mit hoher Bandbreite durch Reduzierung des CPU-Overheads zu erhöhen.

      • Bietet Unterstützung für Server mit zwei DPUs.

    • Pensando-Treiber-Updates:

      • Pensando ionic_en-Treiber: Bietet Unterstützung für Server mit zwei DPUs.

    • Routine-Updates und Fehlerkorrekturen für mitgelieferte Treiber

      • Broadcom bcm_mpi3 

      • Broadcom lpfc

      • Cisco nfnic

      • Marvell qlnativefc

      • Microchip smartpqi

  • CPU

    • PCIe-Hotplug wurde für Server-Plattformen aktualisiert, die AMD Genoa- und Intel Sapphire Rapid-CPUs der neueren Generation verwenden: Ab vSphere 8.0 Update 3 wird Kernel-Hotplug für CPUs der neueren Generation wie AMD Genua und Intel Sapphire Rapids unterstützt.

    • Unterstützung für Prozessoren der Intel Xeon Max-Serie mit integriertem High Bandwidth Memory (HBM): vSphere 8.0 Update 3 bietet Unterstützung für Prozessoren der Intel Xeon Max-Serie (früher mit dem Codenamen Sapphire Rapids HBM) mit 64 GB integriertem HBM, mit dem Ziel, die Leistung für Arbeitslasten wie Hochleistungs-Computing-Apps, künstliche Intelligenz (KI) und maschinelles Lernen (ML) zu verbessern.

    • CPU-C-Status-Leistungsvirtualisierung: Mit vSphere 8.0 Update 3 können Sie für Anwendungsbeispiele wie Virtualized Radio Access Network (vRAN)-Arbeitslasten die C-Status-Leistung der physischen CPUs, die für vRAN-VMs vorgesehen sind, über den vSphere Client konfigurieren und steuern.

    • Clusterweite Option zum Beibehalten der virtuellen NUMA-Topologie: In vSphere 8.0 Update 3 wird eine Einstellung hinzugefügt, um die vorkonfigurierte vNUMA-Topologie auch dann beizubehalten, wenn die VM verschoben wird, wodurch eine bessere Abstimmung der NUMA-Topologie für VMs auf allen Hosts im Cluster ermöglicht wird. Dies ist die erweiterte vCenter Server-Einstellung VPXD_PersistVnuma zur Beibehaltung der virtuellen NUMA-Topologie auf einer Clusterebene unter Konfigurieren > Erweiterte Einstellungen im vSphere Client.

  • Analysen und Metriken

    • Grüne vSphere-Metriken mit RAPL-Technologie (Running Average Power Limit): Ab vSphere 8.0 Update 3 können Sie in den erweiterten Leistungsdiagrammen im vSphere Client RAPL-Daten auf ESXi-Hosts sehen, die normalerweise nicht den Energieverbrauch einzelner Subsysteme, wie z. B. CPU und Arbeitsspeicher, sondern nur den allgemeinen Stromverbrauch auf Hostebene melden. Mit Berichten zum Energieverbrauch einzelner Subsysteme können Sie detaillierter planen, um Ihr Energie- und Kühlungsbudget zu berücksichtigen.

    • Festlegen von VM-Protokollebenen, ohne die VMs auszuschalten: Mit vSphere 8.0 Update 3 können Sie Protokollebenen zwischen VMW_LOG_TRIVIA und VMW_LOG_DEBUG_3 festlegen, um eine Protokollüberflutung in einer fehlerfrei ausgeführten VM zu vermeiden, ohne diese ein- und auszuschalten, indem Sie den SetLogLevel-Dienst in der vAPI-Infrastruktur verwenden.

  • GPU

    • Unterstützung für das Wechseln zwischen dem Time Sliced- und dem MIG-Modus (Multi-Instance GPU) für virtuelle NVIDIA-GPUs: Ab vSphere 8.0 Update 3 müssen Sie einen ESXi-Host nicht neu starten, um zwischen dem Time Sliced- und dem MIG-Modus für virtuelle NVIDIA-GPUs zu wechseln. vGPU-VMs können automatisch den richtigen Gerätemodus entsprechend ihrem vGPU-Typ festlegen.

    • Null-Kopie-Unterstützung für vGPUs zur Verbesserung der vSphere vMotion- und vSphere DRS-Aufgaben: vSphere 8.0 Update 3 bietet Null-Kopie-Unterstützung für vGPUs zur Unterstützung von vSphere vMotion- und vSphere DRS-Aufgaben durch Nutzung eines Durchsatzes von bis zu 100 GBit/s.

    • Unterstützung für heterogene vGPU-Profile auf physischen GPUs: Ab vSphere 8.0 Update 3 können Sie unterschiedliche Typen und Größen von vGPU-Profilen auf einer einzelnen physischen GPU festlegen, um mehr Flexibilität bei vGPU-Arbeitslasten und eine bessere Nutzung von GPU-Geräten zu erreichen. Weitere Informationen finden Sie unter Configuring vGPU Size.

  • vSphere Lifecycle Management

    • Unterstützung für paralleles Hardware- und Firmware-Upgrade mit vSphere Lifecycle Manager: Mit vCenter Server 8.0 Update 3 können Sie mithilfe einer Integration zwischen dem vSphere Lifecycle Manager und dem Hardware Support Manager eine parallele Hardware- und Firmware-Standardisierung ausführen.

    • VMware Photon™ 5.0-Unterstützung für Update Manager Download Service (UMDS): In vSphere 8.0 Update 3 wird VMware Photon™ 5.0 zu den unterstützten Linux-basierten Betriebssystemen für die Installation von UMDS hinzugefügt. Weitere Informationen finden Sie unter Installieren von UMDS.

    • Zusätzliche Lebenszyklus-Verwaltungsfunktionen für eigenständige ESXi-Hosts: Ab vSphere 8.0 Update 3 können Sie einem Datencenter oder einem Ordner einen eigenständigen Host hinzufügen, indem Sie ein Image von einem anderen ESXi-Host in die Bestandsliste der vCenter Server importieren oder das aktuelle Image auf dem Host verwenden. Weitere Informationen finden Sie unter Verwalten eigenständiger ESXi-Hosts mit vSphere Lifecycle Manager-Images. Wenn Sie einen Host aus einem Cluster, den Sie mit einem vSphere Lifecycle Manager-Image verwalten, in ein Datencenter oder einen Ordner verschieben, wird der Host eigenständig und kann das Image aus dem Cluster beibehalten. Weitere Informationen finden Sie unter Besonderheiten des Übergangsworkflows.

    • Lebenszyklusverwaltung eigenständiger ESXi-Hosts mit VMware NSX: Ab vSphere 8.0 Update 3 arbeiten NSX Manager und vSphere Lifecycle Manager zusammen, um die Standardisierung eigenständiger ESXi-Hosts mit VMware NSX zu koordinieren. Weitere Informationen finden Sie unter Using vSphere Lifecycle Manager Images for Standalone Hosts with NSX 4.2 and later.

    • Konvertieren von mit Baselines verwalteten Cluster zu Clustern, die mit einem einzelnen vSphere Lifecycle Manager-Image verwaltet werden: Ab vSphere 8.0 Update 3 können Sie zum Verwalten eines Clusters mit einem einzelnen vSphere Lifecycle Manager-Image das Image verwenden, das auf einem der ESXi Hosts innerhalb des Clusters installiert ist, der mit Baselines verwaltet wird. Weitere Informationen finden Sie unter Use an Image from a Host in the Cluster.

    • Patchen VMX-bezogener Sicherheitslücken ohne Unterbrechung Ihrer Arbeitslasten: Ab vSphere 8.0 Update 3 können Sie die Funktion Live Patch verwenden, um VMX-bezogene Sicherheitspatches und Fehlerkorrekturen auf ESXi-Hosts in einem Cluster anzuwenden, der mit einem vSphere Lifecycle Manager-Image verwaltet wird. Bei einer Vorabprüfung vor der Standardisierung werden alle geeigneten Hosts in einem Cluster aufgelistet. Nachdem Sie die Funktion LivePatch in den Standardisierungseinstellungen aktiviert haben, benötigen qualifizierte Hosts in einem Cluster während des Aktualisierungsvorgangs keinen Wartungsmodus, keinen Neustart oder keine VM-Migration. 

    • Anpassen der von vSphere Lifecycle Manager gewünschten Status-Images: Ab vSphere 8.0 Update 3 können Sie die Komponenten Host Client und VMware Tools aus dem Basisimage entfernen, unnötige Treiber aus Anbieter-Add-Ons und -Komponenten entfernen und vorhandene Treiber in einem gewünschten Image überschreiben. Weitere Informationen finden Sie unter Bearbeiten eines vSphere Lifecycle Manager-Image. 

    • Unterstützung für duale DPUs mit vSphere Lifecycle Manager: Ab vSphere 8.0 Update 3 können Sie duale DPUs auf ESXi-Hosts installieren und den vSphere Lifecycle Manager-Workflow für ein Upgrade des dualen DPU-Systems verwenden. 

    • Erweiterte Unterstützung für vSphere Configuration Profiles (VCP): Mit vSphere 8.0 Update 3 können Sie VCP mit den folgenden neuen Funktionen verwenden:

      • Unterstützung für mit Baselines verwaltete Cluster (früher als VUM-Cluster bezeichnet): Ein über Images verwalteter Cluster ist keine Voraussetzung mehr für die Verwendung von VCP. Sie können VCP verwenden, um entweder mit Baselines verwaltete Cluster oder mit Images verwaltete Cluster zu konfigurieren.

      • Unterstützung von vSphere Distributed Switch (VDS): VCP ist vollständig in VDS integriert und unterstützt Abweichungserkennung und Standardisierung von VDS-Konfigurationen auf Clusterebene.

      • Firewall-Regelsatzverwaltung: Sie können benutzerdefinierte Firewallregeln auf Clusterebene mithilfe von VCP verwalten.

      • ESXi Sperrmodus: vSphere-Administratoren können das Dokument für die gewünschte VCP-Konfiguration verwenden, um den Sperrmodus auf allen Hosts in einem Cluster zu erzwingen.

      • Unterstützung für SNMP- und PCI-Gerätekonfigurationen: Sie können SNMP- und PCI-Geräte mithilfe von VCP auf Clusterebene verwalten.

      Weitere Informationen finden Sie unter Verwenden von vSphere Configuration Profiles zum Verwalten der Hostkonfiguration auf Clusterebene.

  • vSphere Client und vCenter

    • Warnung bezüglich der maximalen Anzahl von Remote-HTTPS-Verbindungen für vCenter: Ab vSphere 8.0 Update 3 wird der HTTP-Fehlercode 503 Dienst nicht verfügbar und x-envoy-local-overloaded: true in den Antwortheadern angezeigt, um zu verhindern, dass ein vCenter-System aufgrund einer Überschreitung des Grenzwerts von 2048 HTTPS-Verbindungen nicht mehr reagiert.

    • Zusammenführen des vSAN Management SDK mit dem Python SDK für die VMware vSphere API: Ab vSphere 8.0 Update 3 ist das vSAN Management SDK für Python in das Python SDK für die VMware vSphere API (pyVmomi) integriert. Über den Python-Paketindex (PyPI) können Sie ein einzelnes Paket herunterladen, um vSAN, vCenter und ESXi zu verwalten. Durch diese Integration wird der Erkennungs- und Installationsvorgang optimiert, und es werden automatisierte Pipelines anstelle einer Reihe von manuellen Schritten ermöglicht.

    • Feld „vCenter Universally Unique Identifier (VC_UUID)“ im vSphere Client: Ab vSphere 8.0 Update 3 enthält die Eigenschaftstabelle unter VMs > Virtuelle Maschinen im vSphere Client eine neue Spalte, die die VC_UUID enthält. Dieser Bezeichner wird automatisch jeder virtuellen Maschine innerhalb einer vCenter-Instanz zugewiesen. Das Feld VC_UUID hilft dabei, die Korrelation zwischen der UUID der VM, die auf dem Fabric des Switches angezeigt wird, und dem VM-Namen in vCenter zu klären.

    • Komprimierung der standardmäßigen HTTP-Antwort: vSphere 8.0 Update 3 bietet standardmäßig Unterstützung für die HTTP-Antwortkomprimierung auf den Edge-Proxys von vCenter- und ESXi-Hosts, den Verwaltungsdatenverkehr zwischen vCenter und ESXi-Hosts sowie für ausgehende HTTP-Anforderungen auf Sidecar-Proxys. Die HTTP-Antwortkomprimierung reduziert den HTTP-Datenverkehr in einem vCenter Server-System, verringert die Seitenladezeit und beschleunigt API-Vorgänge. Sie können die HTTP-Antwortkomprimierung bei Bedarf deaktivieren. Die Funktion erfordert jedoch keine Änderungen in Ihrer Umgebung und ist abwärtskompatibel.

    • Entfernen Sie Einschränkungen für VM-Vorgänge aus dem vSphere Client: Ab vCenter Server 8.0 Update 3 können Sie im vSphere Client unter Virtuelle Maschine > Konfigurieren > Deaktivierte Methoden Einschränkungen für VM-Vorgänge wie z. B. die Migration aufheben. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel2044369.

      Einheitliches Management und Automation API-Sitzungen: Ab vCenter 8.0 Update 3 können Sie vSphere Management API (VIM)- und vSphere Automation API (vAPI)-Sitzungen kombinieren und so die Authentifizierung über SOAP- und REST-vCenter-Endpoints hinweg effektiv vereinheitlichen. Weitere Informationen finden Sie unter Unified Management and Automation Session.

    • Migration von SPBM-, SMS-, EAM- und VLSM-APIs zum HTTP/JSON-basierten Leitungsprotokoll: Ab vCenter Server 8.0 Update 3 werden die folgenden 4 SOAP/XML-Dienstschnittstellen zu einem HTTP/JSON-basierten Leitungsprotokoll migriert, wobei OpenAPI 3.0-Spezifikationen für jede Schnittstelle und die Integration mit der REST API-Dokumentation bereitgestellt werden:

      • Die Speicherrichtlinien-API (SPBM), die die Zuordnung von verfügbarem Speicher zu virtuellen Maschinen vereinfacht.

      • VMware vCenter Storage Monitoring Service (SMS), der den Zugriff auf alle vCenter Speicherinformationen im Zusammenhang mit VMware vCenter-Servern erleichtert.

      • vSphere ESX Agent Manager-API (EAM), die Zugriff auf die Objekte gewährt, die Lebenszyklusvorgänge in vSphere verwalten, überwachen und steuern.

      • Virtual Storage Lifecycle Management (VSLM)-API, mit der Sie First Class Disks (FCD) verwalten.

      Weitere Informationen finden Sie unter Neuerungen in vSphere Automation: vSphere APIs, JSON, OpenAPI (What’s New in vSphere Automation: vSphere APIs, JSON, OpenAPI).

  • Informationen zur vSphere Quick Boot-Unterstützung in ESXi 8.0 Update 3 finden Sie unter Understanding ESXi Quick Boot Compatibility.

  • ESXi 8.0 Update 3 bietet Unterstützung für vSphere Quick Boot für Marvel OCTEON Fusion CNF105xx-Treiber.

    Eine vollständige Liste der unterstützten Server und Treiber finden Sie im VMware-Kompatibilitätshandbuch.

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.

Hinweise zu Produktunterstützung

  • Neu - Unterstützung für die 3D-Hardwarebeschleunigung mit Virtual Shared Graphics Acceleration (vSGA) wird auf veralteten NVIDIA-GPUs eingestellt: Ab vSphere 8.0 Update 3 wird die Unterstützung für die 3D-Hardwarebeschleunigung mithilfe von vSGA auf veralteten NVIDIA-GPUs eingestellt und in einer zukünftigen vSphere-Version entfernt. Weitere Informationen finden Sie im KB-Artikel 377624.

  • Hinweise zu Produktunterstützung aus GA:

    • Veraltete APIs für vCenter für die Migration von Windows auf Linux:

      Ab vSphere 8.0 Update 3 sind APIs von vSphere 6.7.x für die Migration von vCenter für Windows während des Upgrades auf Linux veraltet und werden in einer zukünftigen vSphere-Version entfernt. 

    • Veraltete VMkernel-API (vmkapi) Version 2.5:

      Ab vSphere 8.0 Update 3 wird vmkapi Version 2.5 nicht mehr unterstützt und wird in einer zukünftigen Hauptversion entfernt. Dies erfordert ein Update aller Drittanbieterkomponenten, die für vSphere 6.7 veröffentlicht wurden.

    • Entfernen der integrierten Windows-Authentifizierung (IWA):

      vSphere 8.0 Update 3 ist die letzte Version, die integrierte Windows-Authentifizierung unterstützt. IWA wurde in vSphere 7.0 eingestellt und wird in der nächsten Hauptversion entfernt. Um weiterhin sicheren Zugriff zu gewährleisten, migrieren Sie von IWA zu Active Directory über LDAPS oder zum Identitätsverbund mit Multifaktor-Authentifizierung. Weitere Informationen finden Sie unter vSphere-Authentifizierung mit vCenter Single Sign-On und Deprecation of Integrated Windows Authentication.

    • Entfernen des VMware Enhanced Authentication Plug-In (EAP): Ab vSphere 8.0 Update 3 können Sie EAP nicht mehr verwenden, um sich mit dem vSphere Client bei einem vCenter-System anzumelden. Weitere Informationen finden Sie unter Removing the deprecated VMware Enhanced Authentication Plugin (EAP) to address CVE-2024-22245 and CVE-2024-22250.

      Veraltete vCenter Service Lifecycle Management-API: Ab vSphere 8.0 Update 3 wird die Verwendung der vCenter Service Lifecycle Management (vmonapi service)-API nicht mehr unterstützt, und der Dienst ist nicht standardmäßig aktiv. Sie müssen ihn manuell aktivieren. Der Dienst wird in einer zukünftigen Version entfernt. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 80775.

    • Entfernen der internen Laufzeitoption execInstalledOnly: Ab ESXi 8.0 Update 3 wird die interne Laufzeitoption, die die Sicherheitsoption execInstalledOnly deaktiviert, nicht mehr unterstützt und wird in der nächsten Hauptversion entfernt. Die Startoption execInstalledOnly, die Hosts vor Ransomware-Angriffen schützt, wird auf ESXi-Hosts in der nächsten Hauptversion standardmäßig aktiviert.

    • Veralteter Storage DRS-Lastausgleichsdienst und Storage I/O Control (SIOC): Die Komponenten Storage DRS (SDRS)-E/A-Lastausgleichsdienst, auf SDRS-E/A-Reservierungen basierender Lastausgleichsdienst und vSphere Storage I/O Control werden in einer zukünftigen vSphere-Version nicht mehr unterstützt. Vorhandene 8.x- und 7.x-Versionen unterstützen diese Funktionalität weiterhin. Der E/A-latenzbasierte Lastausgleich und der auf E/A-Reservierungen basierende Lastausgleich zwischen Datenspeichern innerhalb eines Storage DRS-Datenspeicher-Clusters sind von der Einstellung der Unterstützung betroffen. Darüber hinaus werden die Aktivierung von SIOC auf einem Datenspeicher und die Festlegung von Reservierungen und Anteilen mithilfe von SPBM-Speicherrichtlinien nicht mehr weiter unterstützt. Die anfängliche Platzierung von Storage DRS und der Lastausgleich basierend auf Speicherplatzbeschränkungen und SPBM-Speicherrichtlinieneinstellungen für Grenzwerte sind von der Einstellung der Unterstützung nicht betroffen.

    • Veraltete vSphere Trust Authority (vTA):

      Ab vSphere 8.0 Update 3 wird vSphere Trust Authority eingestellt. vSphere bietet weiterhin erweiterte Arbeitslastnachweise in seiner Baseline-Funktionalität an.

    • Entfernen von Patch Manager-APIs: Patch Manager-APIs werden in vSphere 8.x unterstützt, aber die Unterstützung wird in einer zukünftigen Version von vSphere eingestellt. Anstelle der Patch Manager-APIs können Sie die neuesten vSphere APIs verwenden, die im Referenzhandbuch zur vSphere-API-Automatisierung dokumentiert sind.

    • Veraltete Gebietsschemas:

      Ab der nächsten Hauptversion werden wir die Anzahl der unterstützten Lokalisierungssprachen reduzieren. Folgende drei Sprachen werden unterstützt:

      • Japanisch

      • Spanisch

      • Französisch

      • Folgende Sprachen werden nicht mehr unterstützt:

        Auswirkung:

        • Benutzer, die die veralteten Sprachen verwendet haben, erhalten keine Updates oder keinen Support mehr in diesen Sprachen.

          Alle Benutzeroberflächen, Hilfedokumentationen und der Kundensupport sind nur in Englisch oder in den drei oben genannten unterstützten Sprachen verfügbar.

        • Italienisch, Deutsch, brasilianisches Portugiesisch, traditionelles Chinesisch, Koreanisch, vereinfachtes Chinesisch

    • Entfernen von vSphere Lifecycle Manager-Baselines:

      Die Unterstützung für die Verwaltung von Clustern mit vSphere Lifecycle Manager-Baselines und ‑Baselinegruppen (Legacy-Workflows von vSphere Update Manager) wird in einer zukünftigen vSphere-Version eingestellt. Anstelle von Baselines und Baselinegruppen können Sie mithilfe von vSphere Lifecycle Manager-Images Aufgaben auf einem eigenständigen Host oder auf Clusterebene ausführen, wie z. B. die Installation einer gewünschten ESXi-Version auf allen Hosts in einem Cluster, die Installation und Aktualisierung von Drittanbietersoftware, die Aktualisierung und das Upgrade von ESXi oder Firmware, die Erstellung von Empfehlungen und die Verwendung eines empfohlenen Images für Ihren Cluster.

In dieser Version enthaltene Patches

VMware ESXi 8.0 Update 3

Build-Details

VMware vSphere Hypervisor-Image (ESXi ISO)

Download-Dateiname:

VMware-VMvisor-Installer-8.0U3-24022510.x86_64.iso

Build:

24022510

Download-Größe:

605,63 MB

SHA256-Prüfsumme:

05ce214069a3e23265881fbd7a949fb93a99aa13059c6cac31920196e97ba4a1

Neustart des Hosts erforderlich:

Ja

Migration oder Herunterfahren der virtuellen Maschine erforderlich:

Ja

VMware vSphere Hypervisor-Offline-Paket (ESXi)

Download-Dateiname:

VMware-ESXi-8.0U3-24022510-depot.zip

Build:

24022510

Download-Größe:

599 MB

SHA256-Prüfsumme:

82e963b196c9fca6ae2e25de2bfd353e221bf86f041f561b3ef42815e90eb604

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

ESXi80U3-24022510

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.0U3-24022510-standard

ESXi-8.0U3-24022510-no-tools

ESXi-Image

Name und Version

Datum der Veröffentlichung

Kategorie

Detail

ESXi_8.0.3-0.0.24022510

25.06.2024

Allgemein

Fehlerkorrektur-Image

Patch-Download und -Installation

Melden Sie sich beim Broadcom Support Portal an, um diesen Patch herunterzuladen.

Anweisungen zum Herunterladen finden Sie unter Download Broadcom products and software.

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 manuell herunterladen. 

Weitere Informationen finden Sie unter Aktualisieren von Hosts mithilfe von ESXCLI-Befehlen und im Handbuch VMware ESXi-Upgrade.

Behobene Probleme

VM-Verwaltungsprobleme

  • PR 3237088: Ein vSphere-System mit EPYC-Prozessoren der Reihe 7002, 7Fx2, 7Hx2 und 7001 reagiert möglicherweise nach mehr als 1000 Tagen kontinuierlicher Betriebszeit nicht mehr

    Wenn aufgrund von AMD Erratum 1474 der Core-C6 (CC6)-Ruhezustand auf Ihren EPYC-Prozessoren der Reihe 7002, 7Fx2, 7Hx2 und 7001 aktiv ist, kann es vorkommen, dass ein Kern CC6 etwa 1044 Tagen nach dem letzten Zurücksetzen der Systemhardware nicht verlässt, wodurch Neustarts mit VMware QuickBoot ausgeschlossen werden. Dies kann dazu führen, dass Ihr vSphere-System nicht mehr reagiert.

    Dieses Problem wurde in der vorliegenden Version behoben. Durch den Fix wird CC6 automatisch bis zum nächsten Zurücksetzen der Hardware deaktiviert.

  • PR 3035321: 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.

    Dieses Problem wurde in der vorliegenden Version behoben.

Probleme bei Sicherheitsfunktionen

  • PR 3373364: Der Firewall-Regelsatz CIMHttpServer bleibt auch dann aktiv, wenn Sie den CIM-Dienst beenden

    Der Firewall-Regelsatz CIMHttpServer, der für den internen Port 5988 gilt, bleibt möglicherweise auch dann aktiv, wenn Sie den CIM-Dienst beenden.

    Dieses Problem wurde in der vorliegenden Version behoben. Der Firewall-Regelsatz CIMHttpServer ist dauerhaft deaktiviert.

Sonstige Probleme

  • Neu - PR 3359237: Wenn ein NVMe/TCP-Treiber einen E/A-Befehl nicht verarbeiten kann, wird ein ESXi-Host möglicherweise von einem Speicher-Array getrennt

    Wenn Ihre ESXi-Hosts eine Verbindung mit Speicher-Arrays herstellen und Lese-/Schreibvorgänge mithilfe von NVMe/TCP-Verbindungen durchführen und ein NVMe/TCP-Treiber einen E/A-Befehl nicht verarbeiten kann, kann ESXi den Vorgang mit einem Abbruchbefehl abbrechen. Dies führt dazu, dass ein ESXi-Host möglicherweise von einem Speicher-Array getrennt wird und vorherige E/A-Warteschlangen beendet.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 3297607: Ein ESXi-Host schlägt möglicherweise mit einem violetten Diagnosebildschirm fehl, wenn eine Verbindung mit einem NVMe-over-TCP-Controller hergestellt wird

    Aufgrund eines seltenen Problems im nvmetcp-Treiber schlägt ein ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm fehl, wenn eine Verbindung zu einem NVMe-over-TCP-Controller hergestellt wird. In der Ablaufverfolgung sehen Sie eine Warnung wie die folgende:WARNING: NVMFDEV:xxxx Failed to connect controller.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 3355070: ESXi-Hosts reagieren möglicherweise aufgrund der Cachegröße des Zeigerblocks nicht mehr, nachdem VMFS Heap ausgeschöpft ist

    Die VMFS Heap-Kopie des Zeigerblock-Caches füllt möglicherweise den Heap-Arbeitsspeicher und verursacht Fehler bei der Arbeitsspeicherzuteilung bei anderen Vorgängen, die Arbeitsspeicher aus dem VMFS-Heap benötigen. Dies kann dazu führen, dass einige ESXi-Hosts nicht mehr reagieren. Das Problem tritt eher auf, wenn der Parameter maxAddressableSpaceTB auf einen höheren Wert als den Standardwert von 32 TB festgelegt ist, da die Zeit für die Cache-Aktualisierung zunimmt.

    Dieses Problem wurde in der vorliegenden Version behoben.

Probleme mit dem Gastbetriebssystem

  • PR 3091866: In den Protokollen von virtuellen Linux-Maschinen werden E/A-Fehler angezeigt

    In seltenen Fällen konkurrieren Anforderungen zum Aufheben der Zuordnung von einem Linux-Gastbetriebssystem mit anderen Workflows, die auf einem anderen Host ausgeführt werden, wie z. B. der Blockzuteilung im selben Ressourcencluster. Dies führt dazu, dass E/A-Fehler in den Protokollen von Linux-VMs angezeigt werden.

    Dieses Problem wurde in der vorliegenden Version behoben.

Bekannte Probleme

Speicherprobleme

  • Bei vSphere vMotion-Vorgängen für virtuelle Maschinen, die sich auf Pure-gestütztem vSphere Virtual Volumes Speicher befinden, kann eine Zeitüberschreitung auftreten

    vSphere vMotion-Vorgänge für VMs, die sich auf vSphere Virtual Volumes-Datenspeichern befinden, sind vom vSphere API for Storage Awareness (VASA)-Anbieter und dem Zeitplan der abzuschließenden VASA-Vorgänge abhängig. In seltenen Fällen und unter bestimmten Bedingungen, wenn der VASA-Anbieter stark ausgelastet ist, kann die Antwortzeit eines Pure VASA-Anbieters dazu führen, dass ESXi das Zeitüberschreitungslimit von 120 Sekunden für jede Phase der vSphere vMotion-Aufgaben überschreitet. In Umgebungen mit mehreren Stretched Storage-Containern kann es zu weiteren Verzögerungen bei der Antwort des Pure VASA-Anbieters kommen. Dies führt dazu, dass bei der Ausführung von vSphere vMotion-Aufgaben eine Zeitüberschreitung auftritt und der Vorgang nicht abgeschlossen werden kann.

    Problemumgehung: Reduzieren Sie parallele Workflows, insbesondere für Pure-Speicher auf vSphere Virtual Volumes-Datenspeichern, die vom gleichen VASA-Anbieter bereitgestellt werden, und wiederholen Sie die vSphere vMotion-Aufgabe.

  • In einer vSphere Virtual Volumes-Stretched-Storage-Clusterumgebung können einige VMs nach der Wiederherstellung aus einem clusterweiten APD möglicherweise nicht eingeschaltet werden

    In umfangreichen Virtual Volumes-Stretched-Storage-Clusterumgebungen kann es vorkommen, dass einige VMs nach der Wiederherstellung von einem clusterweiten APD aufgrund der hohen Last während der Wiederherstellung nicht eingeschaltet werden können, obwohl die Datenspeicher und Protokoll-Endpoints online und zugänglich sind.

    Problemumgehung: Migrieren Sie die betroffenen VMs zu einem anderen ESXi-Host und schalten Sie die VMs ein.

  • Für Aufgaben auf einer First Class Disk (FCD) wird der Fehler „Objekt oder Element, auf das Bezug genommen wurde, wurde nicht gefunden“ angezeigt

    Aufgrund eines seltenen Speicherproblems wird die Festplatte während der Erstellung eines Snapshots einer angehängten FCD möglicherweise aus dem Katalog der verwalteten virtuellen Festplatte gelöscht. Wenn Sie den Katalog der verwalteten virtuellen Festplatte nicht abgleichen, schlagen alle aufeinanderfolgenden Vorgänge auf einer solchen FCD mit dem Fehler Object or item referred not found fehl.

    Problemumgehung: Weitere Informationen finden Sie unter Reconciling Discrepancies in the Managed Virtual Disk Catalog.

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

Sonstige Probleme

  • Der irdman-Treiber fällt möglicherweise aus, wenn Sie den Unreliable Datagram (UD)-Transportmodus ULP für RDMA over Converged Ethernet (RoCE)-Datenverkehr verwenden

    Wenn Sie aus einem beliebigen Grund das UD-Transportmodusprotokoll (ULP) für den RoCE-Verkehr verwenden, kann der irdman-Treiber ausfallen. Es ist unwahrscheinlich, dass dieses Problem auftritt, da der irdman-Treiber nur iSCSI-Erweiterungen für RDMA (iSER) unterstützt, das ULPs im RC-Modus (Reliable Connection) verwendet.

    Problemumgehung: Verwenden Sie ULPs mit dem RC-Transportmodus.

Netzwerkprobleme

  • Eine verbindungsintensive RDMA-Arbeitslast kann zu einem Verlust des Datenverkehrs auf Geräten der Intel Ethernet E810-Serie mit dem mitgelieferten Treiber irdman-1.4.0.1 führen

    Der mitgelieferte irdman-Treiber Version 1.4.0.1 unterstützt vSAN über RDMA offiziell nicht. Bei Tests mit 10.000 RDMA-Verbindungen, die für vSAN Umgebungen üblich sind, kann es gelegentlich vorkommen, dass der gesamte Datenverkehr auf Geräten der Intel Ethernet E810-Serie mit NVM-Version 4.2 und irdman-Treiber Version 1.4.0.1 verloren geht.

    Problemumgehung: Keine.

  • Die Erfassung von Netzwerkpaketen mithilfe des PacketCapture-Tools auf ESXi funktioniert nicht

    Aufgrund der Verschärfung der rhttpproxy-Sicherheitsrichtlinie können Sie das PacketCapture-Tool nicht mehr verwenden, wie unter Collecting network packets using the lightweight PacketCapture on ESXi beschrieben.

    Problemumgehung: Verwenden Sie das Tool pktcap-uw. Weitere Informationen finden Sie unter Erfassen und Nachverfolgen von Netzwerkpaketen unter Verwendung des Dienstprogramms pktcap-uw.

Installations-, Upgrade- und Migrationsprobleme

  • Neu - Eine Neuinstallation oder das Erstellen von VMFS-Partitionen auf einem Micron 7500- oder Intel D5-P5336 NVMe-Laufwerk schlägt möglicherweise mit einem violetten Diagnosebildschirm fehl

    UNMAP-Befehle ermöglichen es ESXi-Hosts, Speicherplatz freizugeben, der den vom Host gelöschten Daten zugeordnet ist. In NVMe ist das Äquivalent von UNMAP-Befehlen eine DSM-Anforderung zur Aufhebung der Zuteilung. Micron 7500- und Intel D5-P5336-Geräte kündigen einen sehr hohen Wert in einem der Attribute für den Grenzwert der Aufhebung der Zuteilung, DMSRL, an. Dies ist die maximale Anzahl logischer Blöcke in einem einzelnen Bereich für einen Dataset-Management-Befehl. Dies führt zu einem Ganzzahlüberlauf, wenn der ESXi-Split-Code zum Aufheben der Zuordnung die Anzahl der Blöcke in die Anzahl der Byte konvertiert, was wiederum zu einem Fehler bei der Installation oder VMFS-Erstellung führen kann. Es wird ein violetter Diagnosebildschirm mit einem Fehler wie Exception 14 or corruption in dlmalloc angezeigt. Das Problem betrifft ESXi 8.0 Update 2 und höher.

    Problemumgehung: Installieren Sie bei einer Neuinstallation von ESXi zuerst ESXi 8.0, deaktivieren Sie UNMAP für die betroffene Festplatte mithilfe des Befehls esxcli storage core device vaai status set -D 0 -d <device-id> und führen Sie dann ein Upgrade auf 8.0 Update 3 durch. Zum Erstellen von VMFS-Partitionen deaktivieren Sie UNMAP für den betroffenen Datenträger mithilfe des Befehls esxcli storage core device vaai status set -D 0 -d <device-id>. Erstellen Sie VMFS anschließend wie gewohnt. Sie können UNMAP erneut aktivieren, nachdem Sie einen VMFS-Datenspeicher erstellt haben. Wenn Sie jedoch eine Partition löschen oder erstellen, muss UNMAP deaktiviert bleiben.

  • Die Option „Abbrechen“ in einer interaktiven ESXi-Installation funktioniert möglicherweise nicht wie erwartet

    Aufgrund eines Updates der Python-Bibliothek funktioniert die Option Abbrechen durch Drücken der Schaltfläche ESC in einer interaktiven ESXi-Installation möglicherweise nicht wie erwartet. Dieses Problem tritt nur bei interaktiven Installationen und nicht in Skript- oder Upgrade-Szenarien auf.

    Problemumgehung: Drücken Sie zweimal die ESC- und dann eine andere Taste, um die Option Abbrechen zu aktivieren.

  • Standard-Image-Profile für ESXi 8.0 Update 3 zeigen das Datum der letzten Änderung als Veröffentlichungsdatum an

    Im Feld Datum der Veröffentlichung des Standard-Image-Profils für ESXi 8.0 Update 3 wird der Wert Datum der letzten Änderung angezeigt. Das Problem betrifft nur die Image-Profile, die in Auto Deploy oder ESXCLI verwendet werden. Basisimages, die in vSphere Lifecyce Manager-Workflows verwendet werden, zeigen das Veröffentlichungsdatum korrekt an. Dieses Problem hat keine funktionalen Auswirkungen. Nebeneffekt: Wenn Sie nach Profilen nach Veröffentlichungsdatum suchen, wird das Profil nicht mit dem tatsächlichen Veröffentlichungsdatum angezeigt.

    Problemumgehung: Suchen Sie nach Version, z. B. 8.0.3.

Bekannte Probleme aus vorherigen Versionen

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.

  • Sie können kein Update auf ESXi 8.0 Update 2b mithilfe von „esxcli software vib“-Befehlen durchführen

    Ab ESXi 8.0 Update 2 wird ein Upgrade oder Update von ESXi mithilfe der Befehle esxcli software vib update oder esxcli software vib install nicht unterstützt. Wenn Sie esxcli software vib update oder esxcli software vib install verwenden, um Ihre ESXi 8.0 Update 2-Hosts auf 8.0 Update 2b oder höher zu aktualisieren, schlägt die Aufgabe fehl. In den Protokollen wird ein Fehler ähnlich dem folgenden angezeigt: 

    ESXi version change is not allowed using esxcli software vib commands.

    Please use a supported method to upgrade ESXi.       

     vib = VMware_bootbank_esx-base_8.0.2-0.20.22481015 Please refer to the log file for more details.

    Problemumgehung: Wenn Sie ein Upgrade oder Update von ESXi aus einem Depot-ZIP-Paket durchführen, das von der VMware-Website heruntergeladen wurde, unterstützt VMware nur den Update-Befehl esxcli software profile update --depot=<depot_location> --profile=<profile_name>. Weitere Informationen finden Sie unter Upgrade oder Update eines Hosts mit Image-Profilen.

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

  • 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

  • Beim Upgrade auf ESXi 8.0 Update 2b auf Servern mit aktiver TPM-Verschlüsselung (Trusted Platform Module) und vSphere Quick Boot werden möglicherweise Konformitätsfehler angezeigt

    Wenn Sie den vSphere Lifecycle Manager verwenden, um ein Upgrade Ihrer Cluster auf ESXi 8.0 Update 2b durchzuführen, werden im vSphere Client möglicherweise Konformitätsfehler für Hosts mit aktiver TPM-Verschlüsselung und vSphere Quick Boot angezeigt.

    Problemumgehung: Ignorieren Sie die Konformitätsfehler und setzen Sie das Upgrade fort.

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

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

  • 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 0xFFFF berechnet 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 off verwenden.

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

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.

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

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

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

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

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.

  • 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

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

  • 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 dcui und vpxuser zur 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.

check-circle-line exclamation-circle-line close-line
Scroll to top icon