vCenter Server 8.0 Update 3 | 25. Juni 2024 | GA ISO-Build 24022515

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

Allgemeine Verfügbarkeit

Diese vCenter Server 8.0 Update 3-Version ist als Version mit allgemeiner Verfügbarkeit (General Availability, 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 wurde CVE-2024-37087 behoben. Weitere Informationen zu dieser Schwachstelle 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 Speicherleistung, 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).

Vorherige Versionen von vCenter Server 8.0

Die Funktionen, die gelösten und bekannten Probleme von vCenter Server werden in den entsprechenden Versionshinweisen beschrieben. Versionshinweise für frühere Versionen von vCenter Server 8.0:

Informationen über Internationalisierung, Kompatibilität, Installation, Upgrade, Open Source-Komponenten und Hinweise zur Produktunterstützung finden Sie unter VMware vSphere 8.0 Versionshinweise.

Weitere Informationen zu von vCenter Server unterstützten Upgrade- und Migrationspfaden finden Sie im VMware-Knowledgebase-Artikel 67077.

Hinweise zu Produktunterstützung

  • 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 wird die Anzahl der unterstützten Lokalisierungssprachen reduziert. Folgende drei Sprachen werden unterstützt:

    • Japanisch

    • Spanisch

    • Französisch

    Die folgenden Sprachen werden nicht mehr unterstützt:

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

    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.

  • 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

Patch für VMware vCenter Server 8.0 Update 3

Produkt-Patch für vCenter Server mit VMware-Software-Fixes.

Dieser Patch gilt für vCenter Server.

Download-Dateiname

VMware-vCenter-Server-Appliance-8.0.3.00000-24022515-patch-FP.iso

Build

24022515

Größe des Downloads

8507,3 MB

sha256checksum

f611bba1fca57bfc81a021b0de2433a1df284b5283e0750f49eb2272fdd908ed

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.

  1. Hängen Sie die Datei VMware-vCenter-Server-Appliance-8.0.3.00000-24022515-patch-FP.iso an das vCenter Server-CD- oder -DVD-Laufwerk an.

  2. Melden Sie sich bei der Appliance-Shell als Benutzer mit Super-Administratorrechten (z. B. root) an und führen Sie die folgenden Befehle aus:

    • So stellen Sie das ISO-Image bereit:

      software-packages stage --iso

    • So zeigen Sie den bereitgestellten Inhalt an:

      software-packages list --staged

    • So installieren Sie die bereitgestellten RPMs:

      software-packages install --staged

Weitere Informationen zur Verwendung der vCenter Server-Shells finden Sie im VMware-Knowledgebase-Artikel 2100508.

Weitere Informationen zum Patchen von vCenter Server finden Sie unter Patchen und Aktualisieren von vCenter Server 8.0-Bereitstellungen.

Weitere Informationen zum Bereitstellen von Patches finden Sie unter Aktualisieren der vCenter Server Appliance.

Behobene Probleme

vSphere Client- und vCenter-Probleme

  • PR 3308624: ESXi-Hosts können mit einem Fehler wie dem folgenden nicht gestartet werden: Image konnte nicht gestartet werden: Ungültiges Argument (http://ipxe.org/err/1c0de8)

    Wenn Sie nach einer Änderung der Stammzertifizierungsstelle in einer vCenter-Instanz vSphere Auto Deploy verwenden, um ESXi-Hosts zu starten, schlägt der TLS-Handshake mit dem vCenter möglicherweise fehl. Infolgedessen können die Hosts mit einer Meldung wie der Folgenden nicht gestartet werden: Could not boot image: Invalid argument (http://ipxe.org/err/1c0de8).

    Dieses Problem wurde in der vorliegenden Version behoben. Weitere Informationen finden Sie im KB-Artikel 96827.

  • PR-3210868: vCenter-Support-Pakete füllen die Partition /storage/log

    Aufgrund einer Änderung im vCenter-Berechtigungsmodell kann der vpxd-Dienst die vCenter-Support-Pakete, die er vorübergehend in der Partition /storage/log speichert, möglicherweise nicht löschen. Dies kann dazu führen, dass vCenter-Support-Pakete die Partition/storage/log füllen.

    Dieses Problem wurde in der vorliegenden Version behoben. Wenn Sie bereits mit dem Problem konfrontiert sind, können Sie solche Dateien sicher manuell löschen.

  • PR-2993755: 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.x 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.x verwaltet werden.

    Dieses Problem wurde in der vorliegenden Version behoben.

Sonstige Probleme

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

    Dieses Problem wurde in der vorliegenden Version behoben.

Probleme bei vSphere Lifecycle Manager

  • PR 3080596: Während der Generierung einer neuen Image-Empfehlung durch den vSphere Lifecycle Manager bricht der vpxd-Dienst aufgrund von ausgeschöpftem Arbeitsspeicher ab

    Wenn das gewünschte Status-Image in einem vSphere Lifecycle Manager Cluster über mehrere zusätzliche Komponenten verfügt und insbesondere wenn einige davon nicht auf dem neuesten Stand sind, kann der Arbeitsspeicher, der zum Berechnen aller möglichen Kombinationen von Komponenten mit neuen Versionen erforderlich ist, während der Generierung einer neuen Image-Empfehlung auf 85 % des Gesamtarbeitsspeichers des vpxd-Diensts anwachsen. Dies kann dazu führen, dass der Dienst mit coreDump.#####-Dateien abbricht. Im Protokoll /var/log/vmware/vmware-updatemgr/vum-server/vmware-vum-server.log werden Fehlermeldungen wie die folgenden angezeigt:

    2022-12-08T11:00:12.208 info vmware-vum-server[50005] [Originator@6876 sub=RecommendationEngine::ReUtil] [reUtil 108] GenerateImageUnitsCombination: Generating ImageUnit combinations

    2022-12-08T11:05:34.821 error vmware-vum-server[50005] [Originator@6876 sub=Default] Unable to allocate memory

    Dieses Problem wurde in der vorliegenden Version behoben.

Hochverfügbarkeits- und Fault Tolerance-Probleme

  • PR 3354058: Die erweiterte vSphere HA-Optionen das.respectVmVmAntiAffinityRules und das.respectVmVmAffinityRules funktionieren nicht wie erwartet

    In einigen Fällen funktionieren die erweiterten vSphere HA-Optionen das.respectVmVmAntiAffinityRules und das.respectVmVmAffinityRules möglicherweise nicht wie erwartet. Wenn Sie beispielsweise das.respectVmVmAntiAffinityRules auf FALSE festlegen und davon ausgehen, dass die VM-VM-Anti-Affinitätsregeln während eines vSphere HA-Failovers ignoriert werden, schlägt das Failover einiger VMs mit einem RuleViolation-Fehler fehl. In anderen Fällen erwarten Sie möglicherweise, dass die VM-VM-Anti-Affinitätsregel bei einem Failover beachtet wird, da das.respectVmVmAntiAffinityRules standardmäßig TRUE ist, aber einige VMs führen ein Failover durch, und gegen die Regel wird verstoßen.

    Dieses Problem wurde in der vorliegenden Version behoben.

Bekannte Probleme

Probleme bei vCenter Server und dem vSphere Client

  • Wenn Sie einen eigenständigen ESXi-Host zurück in einen Cluster verschieben, den Sie mit vSphere Lifecycle Manager-Images verwalten, wird möglicherweise eine Fehlermeldung im vSphere Client angezeigt

    Wenn Sie einen ESXi-Host aus einem Cluster verschieben, den Sie mit vSphere Lifecycle Manager-Images verwalten, wird er zu einem eigenständigen Host, der mit einer vCenter Server-Instanz verbunden, aber nicht Teil eines Clusters ist. Wenn Sie einen solchen Host zurück in einen Cluster verschieben, wird auf der Registerkarte Updates des vSphere Client möglicherweise ein Fehler wie The host [IP] is not a vLCM managed standalone host angezeigt. Diese Meldung weist nicht auf ein funktionsbezogenes Problem hin.

    Problemumgehung: Aktualisieren Sie die vSphere Client-Sitzung oder ändern Sie die Registerkarte und kehren Sie zur Registerkarte Updates zurück.

  • Derselbe Lizenzproduktname wird im vSphere Client mehrmals angezeigt

    Ab vSphere 8.0 Update 2b können Sie eine einzelne Lösungslizenz auf die Komponenten von VMware vSphere Foundation und VMware Cloud Foundation anwenden. Auf verschiedenen Bildschirmen im vSphere Client wird möglicherweise der Name des Lizenzprodukts multipliziert mit der Anzahl der Komponenten angezeigt, für die Sie die Lizenz verwenden. Wenn Sie beispielsweise eine vSphere 8 Enterprise Plus for VMware Cloud Foundation-Lizenz für 3 Komponenten verwenden, z. B. ESXi, vCenter und vSphere with Tanzu, wird der Name dreimal aufgeführt.

    Problemumgehung: Keine

  • Eine externe Gateway-Firewall blockiert möglicherweise vSphere Pod-Datenverkehr zu clusterIPs

    Wenn Sie Supervisor-Dienste auf vSphere Pods mit Supervisoren bereitstellen, die mit dem VDS-Stack konfiguriert sind, durchläuft der Datenverkehr vom vSphere Pod zu ClusterIPs das externe Gateway und kann von einer benutzerdefinierten Firewall blockiert werden.

    Problemumgehung: Weitere Informationen finden Sie unter vSphere Pod Traffic to ClusterIP Time-outs.

Probleme bei vSphere Lifecycle Manager

  • Im vSphere Client wird eine andere Anzahl von Komponenten in einem vSphere Lifecycle Manager-Image angezeigt

    Wenn Sie ein vSphere Lifecycle Manager-Image für einen Cluster oder einen eigenständigen ESXi-Host vorbereiten und Komponenten manuell hinzufügen oder entfernen, wird möglicherweise eine andere Anzahl der Komponenten in Updates > Hosts > Image->-Komponenten und in der Liste der Komponenten angezeigt, wenn Sie auf Details anzeigen klicken. Die Abweichung tritt auf, wenn der vSphere Lifecycle Manager in Erwägung zieht, einige der zusätzlichen Komponenten nicht zu verwenden, z. B. wenn ein Treiber veraltet ist oder wenn Sie eine Komponente wie VMware Tools oder Host Client entfernen.

    Problemumgehung: Keine. Sie können den Unterschied bei der Anzahl bedenkenlos ignorieren, da dies keine Auswirkungen auf die tatsächliche Liste der Komponenten hat, die vSphere Lifecycle Manager für die Image-Installation verwendet.

Installations-, Upgrade- und Migrationsprobleme

  • Wenn Sie Port 9087 in Ihrer Firewall zwischen ESXi-Hosts und vCenter nicht öffnen, schlagen Konformitätsprüfungen und vSphere HA nach einem vCenter-Update auf 8.0 Update 3 möglicherweise fehl

    Ab 8.0 Update 3 lädt der vSphere Lifecycle Manager Updates für ESXi-Hosts über eine HTTPS-Verbindung zur vCenter-Instanz auf Port 9087 herunter. Wenn Sie Port 9087 in Ihrer Firewall zwischen ESXi-Hosts und vCenter nicht öffnen, werden möglicherweise Fehler bei der Konformitätsprüfung angezeigt. In der Datei lifecycle.log sehen Sie beispielsweise Meldungen ähnlich der folgenden:

    <Timestamp> In(14) lifecycle[2112988]: Downloader:373 Opening https://<VC-FQDN>:9087/vum/repository/hostupdate/__micro-depot__vendor-DEL__DEL-ESXi-8.0-Addon-cumulative_metadata__index__.xml for download

    <Timestamp> Wa(12) lifecycle[2112988]: Downloader:210 Download failed: <urlopen error timed out>, 9 retry left...

    Darüber hinaus kann vSphere HA möglicherweise nicht gestartet werden.

    Problemumgehung: Öffnen Sie Port 9087 in Ihrer Firewall zwischen ESXi-Hosts und vCenter.

  • vSphere Lifecycle Manager-Baseline-Konformitätsprüfung schlägt auf ESXi-Hosts der Version 7.0 GA in einem vCenter 8.0 Update 3-System fehl

    Aufgrund einer Einschränkung des Arbeitsspeicherressourcenpools esxupdate auf 7.0 GA-ESXi-Hosts schlägt eine vSphere Lifecycle Manager-Baseline-Konformitätsprüfung auf einem ESXi-Host der Version 7.0 GA in einem vCenter 8.0 Update 3-System möglicherweise mit einem Fehler wie The host returns esxupdate error codes: -1 fehl.

    Die Datei esxupdate.log auf dem Host enthält einen Fehler ähnlich dem folgenden:

    <Timestamp> esxupdate: <PID>: esxupdate: ERROR: vmware.runcommand.RunCommandError:

    Error running command '['/sbin/smbiosDump']': [Errno 12] Cannot allocate memory

    Die Datei vmkernel.log enthält einen Fehler ähnlich dem folgenden:

    <Timestamp> cpu0:<PID>)Admission failure in path: host/vim/vmvisor/esxupdate/python.<PID>:python.<PID>:uw.<PID>

    Dieses Problem ist spezifisch für ESXi-Hosts der Version 7.0 GA, da die esxupdate-Arbeitsspeicherzuteilung in 7.0 Update 1 und höher erhöht wurde.

    Problemumgehung: Verwenden Sie eine ISO-Upgrade-Baseline, um für die 7.0 GA-ESXi-Hosts ein Upgrade auf eine 8.x-Version durchzuführen, oder setzen Sie das vCenter-System auf Version 7.0 zurück und führen Sie für die Hosts ein Upgrade auf Version 7.0 Update 1 und höher durch.

  • Wenn Sie auf WEITER klicken, bevor der Fortschrittsbalken bei einem vCenter Server Lifecycle Manager-Plug-In-Upgrade 100 % erreicht, schlägt der Server Lifecycle Manager-Dienst fehl

    Wenn Sie im Schritt Upgrade-Plug-In des vCenter Server Lifecycle Manager-Plug-In-Upgrade-Assistenten auf WEITER klicken, bevor der Fortschrittsbalken 100 % erreicht, schlägt der Server Lifecycle Manager-Dienst fehl.

    Problemumgehung: Warten Sie, bis der Fortschrittsbalken 100 % erreicht, bevor Sie auf WEITER klicken.

  • Nach einem vCenter-Upgrade wird eine Warnung vom Typ „vc.health.error.dbjob3“ angezeigt

    Im vSphere Client oder in der Verwaltungsschnittstelle der virtuellen Appliance wird nach einem vCenter-Upgrade möglicherweise die Warnung vc.health.error.dbjob3 angezeigt, obwohl der gesamte vCenter-Systemzustand grün ist. Dieses Problem wirkt sich nicht auf vCenter-Vorgänge aus. Es kann sich nur auf verlaufsbezogene Statistiken auswirken, wenn einige Daten länger als 72 Stunden nicht zusammengefasst werden.

    Problemumgehung: Informieren Sie sich unter Delete old tasks, events and statistics data in vCenter Server 5.x, 6.x, 7.x and 8.x, wie Sie Statistikdaten löschen, wenn sie nicht mehr relevant sind.

  • Das Update auf vCenter 8.0 Update 3 schlägt möglicherweise mit dem Fehler „Zielpfad '/storage/analytics/stage/...' ist bereits vorhanden“ fehl

    Ab vCenter 8.0 Update 3 speichert der Analysedienst Telemetrieprotokolldateien in einem neuen Verzeichnis.

    Wenn frühere Aktualisierungsversuche fehlgeschlagen sind und rückgängig gemacht wurden, schlägt in seltenen Fällen der Versuch, die Telemetrieprotokolldateien an den neuen Speicherort zu kopieren, beim Anwenden von Patches auf vCenter 8.0 Update 3 möglicherweise fehl, da diese Dateien bereits von einem früheren Patching-Versuch existieren. In der Datei patchrunner.log wird ein Fehler wie Destination path '/storage/analytics/stage/XXXXXX_processed_logs' already exists aufgeführt.

    Problemumgehung: Löschen Sie alle Dateien unter /storage/log/vmware/analytics/stage, /storage/log/vmware/analytics/prod, /storage/analytics/stage und /storage/analytics/prod und wiederholen Sie das Update.

Probleme bei vSphere Cluster Service

  • Im vSphere Client wird der vSphere HA-Status der eingebetteten vSphere Cluster Service-VMs als ungeschützt angezeigt

    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 solcher VMs werden jetzt innerhalb von ESXi und nicht mehr vom vSphere ESX Agent Manager (EAM) verwaltet. Auf der Registerkarte Übersicht im vSphere Client wird der vSphere HA-Status der eingebetteten vSphere Cluster Service-VMs als ungeschützt angezeigt. Dies wird jedoch erwartet, da vSphere HA eingebettete vSphere Cluster Service-VMs nicht verwaltet.

    Problemumgehung: Ignorieren Sie die Informationen auf der vSphere HA-Karte auf der Registerkarte Übersicht im vSphere Client. Weitere Informationen finden Sie unter vSphere Cluster Services.

Bekannte Probleme aus vorherigen Versionen

Installations-, Upgrade- und Migrationsprobleme

  • Während der Vorabprüfung eines vCenter-Upgrades wird eine Sicherheitswarnung für die ESX Agent Manager-Konfiguration angezeigt

    Während der Vorabprüfung eines vCenter-Updates oder -Upgrades wird im vSphere Client und in den Protokollen möglicherweise eine Fehlermeldung ähnlich der folgenden angezeigt:

    Source ESX Agent Manager Configuration contains URLs that are not trusted by the System! Please refer to https://kb.vmware.com/s/article/93526 to trust the URLs: <LIST_OF_URLs>

    oder

    Source vSphere ESX Agent Manager (EAM) upgrade failed to obtain EAM URLs to check against trusted certificates by the System! Verify that the ESX Agent Manager extension is running properly on the source vCenter Server instance and https://VC_IP/eam/mob presents correct data. If log in to the MOB is not successful, try resolving the issue with https://kb.vmware.com/s/article/94934.

    Problemumgehung: Weitere Informationen finden Sie in den VMware Knowledgebase-Artikeln 93526 und 94934.

  • In einer gemischten vSphere 7.x- und 8.x-Umgebung mit vSphere DRS verhindert eine inkompatible virtuelle Maschine möglicherweise den Wechsel eines ESXi-Hosts in den Wartungsmodus

    In einer gemischten vSphere 7.x- und 8.x-Umgebung mit DRS verhindert eine VM der Version 7.x, die nicht mit ESXi 8.0 Update 1 und höher kompatibel ist, dass ein ESXi 8.0 Update 1-Host in den Wartungsmodus versetzt wird. Das Problem tritt speziell bei virtuellen Maschinen mit VMDK in einem vSphere Virtual Volumes-Datenspeicher auf. Im vSphere Client wird eine Fehlermeldung ähnlich der folgenden angezeigt: Warten darauf, dass alle virtuellen Maschinen ausgeschaltet, angehalten oder migriert werden. Überprüfen Sie in einem DRS-Cluster die Seite „Fehler“ auf der Registerkarte „DRS“ für die Fehlerbehebung.

    Problemumgehung: Schalten Sie die inkompatible virtuelle Maschine aus.

  • Während des Updates auf vCenter Server 8.0 Update 1 wird in das Virtual Appliance Management Interface (VAMI) die Fehlermeldung Fehler beim Abrufen des CEIP-Status angezeigt

    Während eines Updates stoppt vCenter den VMDir-Dienst und startet ihn neu. Wenn Sie innerhalb dieses Intervalls versuchen, sich bei VAMI anzumelden, wird möglicherweise eine Fehlermeldung wie Failed to get ceip status angezeigt. Dies wird erwartet und weist nicht auf ein tatsächliches Problem mit dem vCenter-System hin.

    Problemumgehung: Warten Sie, bis der VMDir-Dienst neu gestartet und das Virtual Appliance Management Interface aktualisiert wurde.

  • vCenter-Upgrade oder -Update auf 8.0 Update 2a oder höher schlägt während der Vorabprüfung mit dem Fehler „Validierung des VMCA-Rootzertifikats fehlgeschlagen“ fehl

    Wenn Ihr vCenter-System über ein Legacy-VMCA-Rootzertifikat der Version 5.x verfügt, das nicht über die SKID-Erweiterung (Subject Key Identifier) verfügt, schlagen Upgrades und Updates auf vCenter 8.0 Update 2 und höher fehl, da OpenSSL-Version 3.0 in 8.0 Update 2 nicht mit Legacy-Stammzertifikaten kompatibel ist. vCenter Server 8.0 Update 2a fügt eine Vorabprüfung hinzu, um dieses Problem zu erkennen, und zeigt die Fehlermeldung Validierung des VMCA-Rootzertifikats fehlgeschlagen an, wenn das Quell-vCenter über ein VMCA-Rootzertifikat ohne SKID verfügt.

    Problemumgehung: Generieren Sie ein VMCA-Rootzertifikat neu, indem Sie die Schritte im VMware Knowledgebase-Artikel 94840 ausführen.

  • Ein Upgrade mit reduzierter Ausfallzeit (Reduced Downtime, RDU) auf einem vCenter-System schlägt möglicherweise fehl, wenn Sie Update Planner verwenden

    Wenn Sie während RDU Update Planner verwenden, wird im vSphere Client möglicherweise eine Fehlermeldung ähnlich der folgenden angezeigt: Update 8.0.2.00000 for component vlcm is not found.

    Problemumgehung: Weitere Informationen finden Sie in den VMware-Knowledgebase-Artikeln 94779 und 92659.

  • Eine fehlgeschlagene parallele Wartung mithilfe von vSphere Lifecycle Manager auf einem ESXi Host kann dazu führen, dass andere Hosts im Status „Neustart ausstehend“ verbleiben

    Ein versehentlicher Verlust der Netzwerkkonnektivität während einer parallelen Wartung mithilfe von vSphere Lifecycle Manager kann dazu führen, dass der Vorgang auf einem der ESXi Hosts fehlschlägt. Die Wartung auf anderen Hosts wird fortgesetzt, aber die Hosts können nicht neu gestartet werden, um die Aufgabe abzuschließen.

    Problemumgehung: Wenn ein ESXi-Host Wartungsversuch immer wieder fehlschlägt, lösen Sie manuell einen Neustart aus. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 91260.

  • Während der Vorabprüfung eines vCenter-Upgrades wird eine Sicherheitswarnung für die ESX Agent Manager-Konfiguration angezeigt

    Während der Vorabprüfung eines vCenter-Updates oder -Upgrades wird im vSphere Client und in den Protokollen möglicherweise eine Fehlermeldung ähnlich der folgenden angezeigt:

    Source ESX Agent Manager Configuration contains URLs that are not trusted by the System! Verify following URLs and their respective statuses and follow KB 93526.

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

  • Firmware-Konformitätsdetails fehlen in einem vSphere Lifecycle Manager-Image-Konformitätsbericht für einen eigenständigen ESXi-Host

    In zwei Fällen fehlen möglicherweise Firmware-Konformitätsdetails in einem vSphere Lifecycle Manager-Image-Konformitätsbericht für einen eigenständigen ESXi-Host:

    1. Sie führen einen Konformitätsbericht für einen eigenständigen Host, der mit einem vSphere Lifecycle Manager-Image verwaltet wird, aus vSphere Client aus und navigieren dann weg, bevor der Konformitätsbericht erstellt wird.

    2. Sie lösen eine Seitenaktualisierung aus, nachdem die Image-Konformitätsberichte generiert wurden.

    Selbst wenn das Firmware-Paket im gewünschten Zustand verfügbar ist, bleibt der Abschnitt „Firmware-Konformität“ in diesen Fällen leer, wenn Sie die vSphere Client-Browsersitzung erneut besuchen oder aktualisieren. Wenn Sie die GET-API für die Image-Konformität verwenden, fehlen Details zur Firmware-Konformität in der Antwort.

    Problemumgehung: Rufen Sie die Image-Konformitätsprüfung für einen eigenständigen Host, der mit einem vSphere Lifecycle Manager-Image verwaltet wird, mithilfe des vSphere Client auf, navigieren Sie nicht weg und aktualisieren Sie nicht den Browser. Verwenden Sie statt der GET-API die API zur Prüfung der Image-Konformität, um die Firmware-Details abzurufen.

  • Obwohl das Update von vCenter erfolgreich abgeschlossen wurde, wird als Status „Fehlgeschlagen“ angezeigt

    Eine seltene Race-Bedingung kann dazu führen, dass vCenter ein erfolgreiches Update als fehlgeschlagen meldet. Dieses Problem tritt auf, wenn während eines Neustarts von vCenter das Unmounten von /storage/core erfolgt, bevor das System den Status Installation abgeschlossen bestätigt. Infolgedessen schlägt das Update mit folgender Fehlermeldung fehl: No such file or directory: '/storage/core/software-update/install_operation'. In der Datei software-packages.logs werden Fehlermeldungen ähnlich dem folgenden angezeigt:

    2023-08-17T10:57:59.229 [15033]DEBUG:vmware.appliance.update.update_state:In State._get using state file /etc/applmgmt/appliance/software_update_state.conf

    2023-08-17T10:57:59.229 [15033]INFO:vmware.appliance.update.update_state:Found operation in progress /storage/core/software-update/install_operation

    2023-08-17T10:57:59.229 [15033]ERROR:vmware.appliance.update.update_functions:Can't read JSON file /storage/core/software-update/install_operation [Errno 2] No such file or directory: '/storage/core/software-update/install_operation'

    2023-08-17T10:57:59.229 [15033]DEBUG:vmware.appliance.update.update_state:Operation in progress is orphaned

    2023-08-17T10:57:59.229 [15033]DEBUG:vmware.appliance.update.update_state:Operation in progress is finished

    2023-08-17T10:57:59.229 [15033]DEBUG:vmware.appliance.update.update_state:Writing to state file from State._get

    2023-08-17T10:57:59.229 [15033]DEBUG:vmware.appliance.update.update_state:In State._writeInfo writing to state file /etc/applmgmt/appliance/software_update_state.conf

    2023-08-17T10:57:59.229 [15033]INFO:vmware.vherd.base.software_update:Installation failed. Please collect the VC support bundle.

    Problemumgehung: Überprüfen Sie, ob vCenter erfolgreich neu gestartet wird und ob der vCenter-Systemzustand grün ist. Ignorieren Sie den Fehlerbericht.

  • Patch-Anwendung auf vCenter 8.0 Update 2 schlägt in IPv6-Umgebungen ohne DNS-Server und Hostname fehl

    Wenn Sie Ihr vCenter-System von einer früheren Version von 8.x auf 8.0 Update 2 aktualisieren und Ihr System ein IPv6-Netzwerk ohne Hostnamen (z. B. PNID) und einen DNS-Server verwendet, wird in der Verwaltungsschnittstelle der VMware-Appliance möglicherweise ein Fehler wie Data conversion/Post install hook failed angezeigt.

    Problemumgehung: Aktualisieren Sie die /etc/hosts-Datei manuell mit dem fehlenden IPv6-Loopback-Eintrag: ::1 localhost ipv6-localhost ipv6-loopback und starten Sie das System neu.

    Siehe folgendes Beispiel:

    root@localhost []# cat /etc/hosts

    # Begin /etc/hosts (Netzwerkkartenversion)

    127.0.0.1 localhost.localdomain

    127.0.0.1 localhost

    ::1 localhost ipv6-localhost ipv6-loopback

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

  • Während eines Upgrades mit reduzierter Ausfallzeit (Reduced Downtime Upgrade, RDU) werden beim Konfigurieren der Netzwerkeinstellungen der Ziel-VM keine Netzwerkportgruppen angezeigt

    In sehr seltenen Fällen werden während eines Upgrades einer einzelnen selbstverwalteten vCenter-Instanz mit einer migrationsbasierten Methode im Assistenten für die Ziel-VM-Bereitstellung möglicherweise keine Netzwerkportgruppen angezeigt, wenn eine vCenter-Quell-VM für Festplatten Thin Provisioning verwendet und der vCenter-Zielcluster nicht über genug Speicherplatz verfügt, um den Speicherbedarf für den im Validierungsvorgang ausgewählten Standardmodus für Thick-Festplatten zu decken. Wenn Sie im vSphere Client im Assistenten für die Ziel-VM-Bereitstellung im Schritt Bereitstellungstyp die Option Gleiche Konfiguration auswählen, wird auf dem Bildschirm Netzwerkeinstellungen eine leere Fehlermeldung angezeigt und es sind keine Portgruppen verfügbar.

    Problemumgehung: Wählen Sie im Schritt Bereitstellungstyp des Assistenten Bereitstellung der Ziel-VM die Option Detaillierte Konfiguration aus.

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

  • Die URL-basierte Patch-Anwendung oder dateibasierte Sicherung von vCenter 8.0 Update 2 schlägt möglicherweise aufgrund der Nichtkonformität von OpenSSL mit den Bundesstandards für Informationsverarbeitung (Federal Information Processing Standards, FIPS) fehl

    In vCenter 8.0 Update 2 funktioniert OpenSSL nur mit Diffie-Hellman-Parametern, die mit NIST SP 800-56A und FIPS 140-2 kompatibel sind. Für URL-basiertes Patchen oder dateibasierte Sicherungen von vCenter 8.0 Update 2-Systemen müssen FTPS-Server in Ihrer Umgebung die folgenden Verschlüsselungen unterstützen:

    OpenSSL-Verschlüsselungs-Suite

    Name der AT-TLS-Verschlüsselungs-Suite

    Hexadezimalwert

    DHE-RSA-AES256-SHA

    TLS_DHE_RSA_WITH_AES_256_CBC_SHA

    39

    DHE-DSS-AES256-SHA

    TLS_DHE_DSS_WITH_AES_256_CBC_SHA

    38

    AES256-SHA

    TLS_RSA_WITH_AES_256_CBC_SHA

    35

    EDH-RSA-DES-CBC3-SHA

    TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA

    16

    EDH-DSS-DES-CBC3-SHA

    TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

    13

    DES-CBC3-SHA

    TLS_RSA_WITH_3DES_EDE_CBC_SHA

    0A

    DHE-RSA-AES128-SHA

    TLS_DHE_RSA_WITH_AES_128_CBC_SHA

    33

    DHE-DSS-AES128-SHA

    TLS_DHE_DSS_WITH_AES_128_CBC_SHA

    32

    AES128-SHA

    TLS_RSA_WITH_AES_128_CBC_SHA

    2F

    Problemumgehung: Stellen Sie sicher, dass Ihre Dateiserver FIPS-konform sind.

  • 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

  • Im Hybrid Linked Mode kann der Cloud-vCenter keine Plug-Ins erkennen, die auf einem lokalen vCenter

    Im Hybrid Linked Mode können Sie Ihre Cloud-vCenter Server-Instanz mit einer lokalen vCenter Single Sign-On Domäne verknüpfen. Das Cloud-vCenter kann jedoch möglicherweise keine Plug-Ins erkennen, die auf der lokalen Instanz bereitgestellt werden, da es nicht über die erforderlichen Berechtigungen verfügt.

    Problemumgehung: Installieren Sie das vCenter Cloud-Gateway in Ihrer lokalen Umgebung und durchsuchen Sie entweder die auf der lokalen Instanz bereitgestellten Plug-Ins über die VMware Cloud Console oder direkt über die vSphere Client auf dem lokalen vCenter.

  • Für per Thin Provisioning bereitgestellte virtuelle Festplatten wird ein falscher Wert für die maximale Größe angezeigt

    Wenn Sie sich im vSphere Client die Einstellungen einer VM mit einer per Thin Provisioning bereitgestellten virtuellen Festplatte ansehen, wird unter Maximale Größe ein Wert für die Festplatte angezeigt, der größer als die Kapazität des Datenspeichers ist, in dem sich die Festplatte befindet. Wenn die Datenspeicherkapazität beispielsweise 100 GB beträgt, von denen 90 GB verfügbar sind, und eine per Thin Provisioning bereitgestellte virtuelle Festplatte eine Kapazität von 50 GB aufweist, von denen nur 10 GB genutzt werden, wird unter Maximale Größe unter Umständen ein Wert von 140 GB angezeigt, wobei die verfügbare Datenspeicherkapazität zur gesamten Festplattenkapazität hinzugefügt wird, nicht aber deren tatsächliche Nutzung.

    Problemumgehung: Keine

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

  • Sie können die Konfiguration der Firewallregeln mit der Option „Nur Verbindungen von den folgenden Netzwerken zulassen“ auf ESXi Hosts nicht anpassen

    Ab vSphere 8.0 Update 2 können Sie die Konfiguration der Firewallregeln nicht mehr mit der Option Nur Verbindungen von den folgenden Netzwerken zulassen auf ESXi Hosts anpassen. Wenn Sie beispielsweise im VMware Host Client zu Netzwerk > Firewallregeln navigieren, auf DHCP-Client klicken, eine IP-Adresse angeben und die Option Nur Verbindungen von den folgenden Netzwerken zulassen aktivieren, schlägt der Vorgang mit einer Fehlermeldung wie Operation failed, diagnostics report: Invalid operation requested: Can not change allowed ip list this ruleset, it is owned by system service. fehl. Dieses Verhalten wird erwartet.

    Problemumgehung: Keine

  • 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

  • Überlappende Hot-Add- und Hot-Remove-Vorgänge für DirectPath I/O-Geräte schlagen möglicherweise fehl

    Mit vSphere 8.0 Update 1 können Sie mithilfe von vSphere API ein DirectPath I/O-Gerät hinzufügen oder entfernen, ohne VMs auszuschalten. Wenn Sie jedoch mehrere Vorgänge gleichzeitig ausführen, schlagen einige der sich überschneidenden Aufgaben möglicherweise fehl.

    Problemumgehung: Planen Sie 20 Sekunden Verarbeitungszeit zwischen jedem Hot-Add- oder Hot-Remove-Vorgang für DirectPath I/O-Geräte ein.

  • Das Hinzufügen und Entfernen von DirectPath I/O-Geräten im laufenden Betrieb wird auf virtuellen Maschinen nicht automatisch aktiviert

    Mit vSphere 8.0 Update 1 können Sie mithilfe von vSphere API ein DirectPath I/O-Gerät hinzufügen oder entfernen, ohne VMs auszuschalten. Wenn Sie die Hotplug-Funktionalität aktivieren, mit der Sie DirectPath I/O-Geräte im laufenden Betrieb zu einer VM hinzufügen und entfernen können, wird die Hotplug-Funktionalität der neuen VM möglicherweise nicht automatisch aktiviert, wenn Sie eine solche VM zum Erstellen einer OVF-Datei und zum Bereitstellen einer neuen VM verwenden.

    Problemumgehung: Aktivieren Sie die Hotplug-Funktionalität, wie in Hot-Add- und Hot-Remove-Unterstützung für VMDirectPath I/O-Geräte beschrieben.

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

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

    Problemumgehung: Keine.

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

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

    Problemumgehung: Aktualisieren Sie den ntg3-Treiber auf Version 4.1.8 und setzen Sie den neuen Modulparameter noPhyStateSet auf 1. Der Parameter noPhyStateSet ist standardmäßig auf 0 gesetzt und wird in den meisten Umgebungen nicht benötigt, es sei denn, sie sind von dem Problem betroffen.

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

  • Die Migration einer First Class Disk (FCD) schlägt möglicherweise fehl, und die FCD verbleibt in einem vorläufigen Zustand

    Wenn Sie in bestimmten Szenarien eine FCD zu einem anderen Datenspeicher migrieren, indem Sie die RelocateVStorageObject-API aufrufen, schlägt der Vorgang möglicherweise zeitweise fehl, und die FCD verbleibt in einem vorläufigen Zustand. Dies führt dazu, dass Sie keinen anderen Vorgang auf der FCD durchführen können. Wenn Sie beispielsweise eine weitere Migration durchführen, wird im Backlog die folgende Fehlermeldung angezeigt: com.vmware.vim.fcd.error.fcdAlreadyInTentativeState.

    Problemumgehung: Führen Sie die im VMware-Knowledgebase-Artikel 2147750 beschriebenen Schritte aus, um einen Abgleich des Quelldatenspeichers der FCD durchzuführen.

  • 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

  • Im Dialogfeld „Konfiguration für das Starten/Herunterfahren von virtuellen Maschinen bearbeiten“ werden überlappende Bezeichnungen für Parameter angezeigt

    Wenn Sie im vSphere Client einen ESXi-Host auswählen und auf Konfigurieren > Virtuelle Maschinen > Starten/Herunterfahren von virtuellen Maschinen > Bearbeiten klicken, werden überlappende Bezeichnungen für einige Parameter im daraufhin geöffneten Dialogfeld Konfiguration für das Starten/Herunterfahren von virtuellen Maschinen bearbeiten angezeigt. Die folgenden Bezeichnungen überschneiden sich:

    • Systemeinfluss: bezeichnet das Kontrollkästchen Virtuelle Maschinen zusammen mit dem System automatisch starten und beenden.

    • Verzögerung beim Starten: numerischer Wert, der angibt, wie lange ein Host wartet, bevor die nächste virtuelle Maschine in der Konfiguration für den automatischen Start eingeschaltet wird.

    • Verzögerung beim Herunterfahren: numerischer Wert, der die maximale Zeit definiert, die der ESXi Host auf die Ausführung eines Befehls zum Herunterfahren wartet, und die Option Fortfahren, wenn VMware Tools gestartet ist.

    • Aktion beim Herunterfahren: zum Beispiel „Herunterfahren des Gastes“, „Ausschalten“, „Anhalten“ und „Keine“.

    Problemumgehung: Keine. Die Reihenfolge der Bezeichnungen können Sie aus dem Screenshot ersehen:


  • VMware vCenter Lifecycle Manager kann möglicherweise die aktuellen Zertifikate nicht laden und eine Reihe von Aufgaben nicht ausführen

    VMware vCenter Lifecycle Manager kann möglicherweise die aktuellen Zertifikate nicht laden, wenn Sie unterbrechungsfreie Zertifikatserneuerung in vCenter 8.0 Update 2 ausgewählt haben. Folglich können alle Funktionen fehlschlagen, die auf dem vCenter Lifecycle Manager basieren, der die zugrunde liegende VMware vCenter Orchestrator-Plattform bereitstellt, wie z. B. der Update-Planer, der vSphere+ vCenter-Dienst für Lebenszyklusverwaltung sowie Upgrades mit reduzierten Ausfallzeiten für vCenter.

    Problemumgehung: Starten Sie den vCenter Lifecycle Manager neu, um die aktuellen Zertifikate abzurufen. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 2109887.

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

  • Die Option zum Weitergeben von Stammzertifikaten an vCenter Hosts wird nicht angezeigt

    Im vSphere Client auf dem Bildschirm Vertrauenswürdiges Root-Zertifikat hinzufügen auf der Registerkarte Zertifikatsverwaltung wird die Option Weitergabe von Stammzertifikaten an vCenter Hosts starten nicht angezeigt.

    Problemumgehung: Diese Änderung auf dem Bildschirm Vertrauenswürdiges Root-Zertifikat hinzufügen hängt mit der unterbrechungsfreien Zertifikatsverwaltungsfunktion zusammen, die mit vCenter 8.0 Update 2 eingeführt wurde, und ist erwartungsgemäß. Weitere Informationen finden Sie unter Unterbrechungsfreie Zertifikatsverwaltung.

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

  • Eine geplante Aufgabe schlägt fehl und plant keine weiteren Ausführungen

    Wenn bei vSphere 8.0 Update 2 ein vCenter-Benutzer nicht autorisiert oder nicht authentifiziert ist, schlagen alle geplanten Aufgaben, die er besitzt, fehl und können erst geplant werden, wenn die Benutzerrechte wiederhergestellt sind oder ein anderer vSphere-Benutzer die geplanten Aufgaben übernimmt. Im vSphere Client werden Meldungen zu fehlgeschlagenen Aufgaben mit Gründen für den Fehler angezeigt.

    Problemumgehung: Jeder vSphere-Benutzer mit ausreichenden Rechten zum Bearbeiten geplanter Aufgaben, einschließlich des aktuellen Aufgabenbesitzers mit wiederhergestellten Rechten, kann auf Bearbeiten klicken und die geplante Aufgabe übermitteln, ohne die geplante Aufgabe tatsächlich zu ändern. Weitere Informationen finden Sie unter Planen von vSphere-Aufgaben.

VM-Verwaltungsprobleme

  • Wenn Sie in einer gemischten vCenter-Umgebung eine an eine First Class Disk (FCD) angehängte VM klonen und sie löschen, wird die angehängte FCD in der geklonten VM ebenfalls gelöscht

    Wenn Sie in einer gemischten vCenter-Umgebung, in der vCenter die Version 8.0 Update 2 oder höher aufweist und ESXi maximal die Version 7.0 Update 3 aufweist, wird der Parameter KeepAfterDeleteVM beim Klonen einer VM mit FCD standardmäßig auf FALSE festgelegt. Folglich wird die angehängte geklonte FCD beim Löschen der geklonten VM ebenfalls gelöscht.

    Problemumgehung: In einer gemischten vCenter-Umgebung, in der vCenter die Version 8.0 Update 2 oder höher aufweist und ESXi maximal die Version 7.0 Update 3 aufweist, setzen Sie den Parameter KeepAfterDeleteVM mithilfe der FCD-API auf TRUE: setVStorageObjectControlFlags. Sie können die FCD-API auf https://<VC_IP>/mob/?moid=VStorageObjectManager&method=setVStorageObjectControlFlags aufrufen und das Steuerungs-Flag übergeben: KeepAfterDeleteVM.

Probleme bei vSphere Lifecycle Manager

  • Beim Eingeben von nicht numerischen Werten für eine gewünschte Clusterkonfigurationseinstellung im vSphere Client wird keine Warnung und kein Fehler angezeigt

    Wenn Sie die Hosteinstellungen der Entwurfskonfiguration für einen Cluster bearbeiten, der vSphere Configuration Profiles verwendet, können Sie nicht numerische Werte in ein Feld eingeben, in dem nur Zahlen erwartet werden, und es wird kein Fehler und keine Warnung angezeigt. Wenn Sie beispielsweise nicht numerische Zeichen in der Einstellung für Syslog-Rotationen, esx/syslog/global_settings/rotations, in denen eine Zahl erwartet wird, festlegen, wird das Dialogfeld Bearbeiten ohne Fehler geschlossen und es scheint, als wäre der Wert gespeichert worden, doch in der Einstellung bleibt tatsächlich der vorherige gültige Wert erhalten.

    Problemumgehung: Verwenden Sie numerische Werte in Feldern, die Zahlen erwarten. Verwenden Sie Zahlen in Texteingaben, die Zahlen erwarten.

  • Sie können die geplante Aufgabe „VMware vSphere Lifecycle Manager – Update-Download“ nicht bearbeiten

    Wenn Sie im vSphere Client zu einer vCenter Server-Instanz navigieren, Geplante Aufgaben auf der Registerkarte Konfigurieren auswählen, die Aufgabe VMware vSphere Lifecycle Manager – Update-Download auswählen und auf Bearbeiten klicken, können Sie die vorhandenen Einstellungen nicht ändern.

    Problemumgehung: Sie können die Aufgabe VMware vSphere Lifecycle Manager – Update-Download bearbeiten indem Sie die Schritte im Thema Konfigurieren der vSphere Lifecycle Manager-Aufgabe „Automatischer Download“ ausführen.

  • Manuell angewendete erweiterte Sicherheitsoptionen auf einem vCenter-System werden unter Umständen nicht über vSphere Lifecycle Manager-Vorgänge hinweg beibehalten

    Einige der manuell angewendeten erweiterten Sicherheitsoptionen auf einem vCenter-System werden unter Umständen nicht über vSphere Lifecycle Manager-Vorgänge hinweg beibehalten, wie z. B. Upgrade, Update, Sicherung oder Wiederherstellung.

    Problemumgehung: Wenden Sie die manuellen Einstellungen nach Abschluss der vSphere Lifecycle Manager-Aufgabe erneut an.

  • Wenn eine parallele Standardisierungsaufgabe fehlschlägt, wird nicht die richtige Anzahl an ESXi-Hosts angezeigt, die den Vorgang übergeben oder übersprungen haben

    Mit vSphere 8.0 können Sie vSphere Lifecycle Manager aktivieren, um alle Hosts, die sich im Wartungsmodus befinden, parallel statt nacheinander zu standardisieren. Wenn jedoch eine parallele Standardisierungsaufgabe fehlschlägt, sehen Sie im vSphere Client möglicherweise nicht die richtige Anzahl an Hosts, die den Vorgang bestanden, nicht bestanden oder übersprungen haben, oder sehen überhaupt keine solche Anzahl. Das Problem wirkt sich nicht auf die vSphere Lifecycle Manager-Funktionalität aus, sondern nur auf die Berichterstellung im vSphere Client.

    Problemumgehung: Keine.

  • In einer von mehreren verknüpften vCenter-Instanzen wird in der vSphere Lifecycle Manager-Startansicht ein Authentifizierungsfehler angezeigt

    Nach einem Update eines verknüpften vCenter-Systems kann der Zugriff auf die vSphere Lifecycle Manager-Startseite im vSphere Client über eine der verknüpften vCenter-Instanzen fehlschlagen. Wenn Sie auf Menü > Lifecycle Manager klicken, wird folgender Fehler angezeigt: Authentication failed, Lifecycle Manager server could not be contacted. Das Problem betrifft auch vSphere Lifecycle Manager-Baselineseiten und -Workflows. Workflows mit vSphere Lifecycle Manager-Images sind davon nicht betroffen.

    Problemumgehung: Melden Sie sich beim vSphere Client über eine andere vCenter-Instanz in der verknüpften Umgebung an oder starten Sie den Dienst vsphere-ui neu, um das Problem zu beheben.

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

  • Sie können virtuelle Maschinen nicht verschlüsseln, wenn sie mit einer vCenter-Version vor 8.0 Update 1 verbunden sind

    Wenn Sie den vSphere Client zum Herstellen einer Verbindung mit einem vCenter-System der Version 7.x oder vor 8.0 Update 1 verwenden und eine VM entweder im Assistenten Neue virtuelle Maschine oder im Dialogfeld Einstellungen bearbeiten einer vorhandenen VM verschlüsseln, werden Fehler ähnlich dem folgenden angezeigt: Operation failed! RuntimeFault.Summary and A general runtime error occurred. Key /default KMS cluster not found. Die Aufgabe wird erfolgreich abgeschlossen, wenn Sie sich mit dem vSphere Client bei einem vCenter-System der Version 8.0 Update 1 oder höher anmelden.

    Problemumgehung: Verwenden Sie den vSphere Client aus der vCenter-Instanz mit der Version vor 8.0 Update 1, um die VM zu verschlüsseln. Alternativ können Sie die VM-Verschlüsselung auf einer anderen vCenter-Instanz der Version 8.0 Update 1 und höher aktivieren und die bereits verschlüsselte VM zur vCenter-Instanz einer früheren Version migrieren.

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