vCenter Server 8.0 Update 1 | 18. April 2023 | GA ISO Build 21560480

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

Allgemeine Verfügbarkeit

Diese vCenter Server Version 8.0 Update 1 ist als Version mit allgemeiner Verfügbarkeit (GA) gekennzeichnet. Weitere Informationen zum vSphere 8.0 IA/GA-Versionsmodell von vSphere-Update-Versionen finden Sie unter Das vSphere 8-Versionsmodell entwickelt sich.

Neuigkeiten

  • vSphere Configuration Profiles: vSphere 8.0 Update 1 startet offiziell vSphere Configuration Profiles, mit denen Sie ESXi-Clusterkonfigurationen verwalten können, indem Sie eine gewünschte Hostkonfiguration auf Clusterebene angeben, die Prüfung von ESXi Hosts auf Konformität mit der angegebenen gewünschten Konfiguration automatisieren und jeden Host standardisieren können, der nicht konform ist. vSphere Configuration Profiles erfordern, dass Sie vSphere Lifecycle Manager-Images zum Verwalten des Clusterlebenszyklus, eine vSphere 8.0 Update 1-Umgebung und eine Enterprise Plus- oder vSphere+-Lizenz verwenden. Weitere Informationen finden Sie unter Verwenden von vSphere Configuration Profiles zur Verwaltung von Hostkonfiguration auf Clusterebene.

  • Mit vSphere 8.0 Update 1 bietet vSphere Distributed Services Engine Unterstützung für:

    • NVIDIA BlueField-2 DPUs zu Serverdesigns von Lenovo (Lenovo ThinkSystem SR650 V2).

    • 100G NVIDIA BlueField-2 DPUs zu Serverdesigns von Dell.

    • UPTv2 für NVIDIA BlueField-2 DPUs.

    • AMD Genoa CPU-basierte Serverdesigns von Dell.

  • Aufzeichnungsmöglichkeit für erforderliche Rechte für vCenter Server-Workflows: Mit vSphere 8.0 Update 1 können Sie die mindestens zum Ausführen eines vCenter Server-Workflows erforderlichen Rechte identifizieren, und Sie können die Workflows aufzeichnen und die erforderlichen Rechte speichern. Sie können die gespeicherten Daten verwenden, um bestimmte Rollen für Benutzer zu erstellen, die dieselben Workflows ausführen, ähnlich wie bei Vorlagen. Beim Durchsuchen der vCenter Server-Workflow-Aufzeichnungen können Sie Listen von Überprüfung von Rechten zusammen mit den entsprechenden Sitzungen, Benutzern, verwalteten Objekten und Vorgangs-IDs (opIDs) abrufen. Weitere Informationen finden Sie unter Performing Privilege Checks Operations.

  • Unterstützung für heterogene vGPU-Profile (Virtual Graphics Processing Unit) auf derselben GPU-Hardware: vSphere 8.0 Update 1 entfernt die Anforderung, dass alle vGPUs auf einer physischen GPU denselben Typ aufweisen müssen. Sie können unterschiedliche vGPU-Profile, wie z. B. Computing, Grafiken oder Arbeitslast der virtuellen Desktop-Infrastruktur, auf einer GPU festlegen, um Kosten durch eine höhere GPU-Nutzung und reduzierte Arbeitslastfragmentierung zu sparen.

  • Integration von VMware Skyline™ Health Diagnostics™ in vCenter: Ab vSphere 8.0 Update 1 können Sie Probleme in Ihrer vSphere-Umgebung mithilfe der Self-Service-Diagnoseplattform VMware Skyline Health Diagnostics erkennen und beheben, die in die vSphere Client integriert ist. Weitere Informationen finden Sie unter VMware Skyline Health Diagnostics für vSphere-Dokumentation.

  • Energieverbrauchsmetriken auf VM-Ebene: Ab vSphere 8.0 Update 1 können Sie als vSphere-Administrator den Energieverbrauch auf einer VM-Ebene verfolgen, um die ökologischen, sozialen und Governance-Ziele Ihrer Organisation zu unterstützen.

  • NVSwitch-Unterstützung: vSphere 8.0 Update 1 bietet Unterstützung für bis zu 8 GPUs mit NVSwitch-Verbindungen dazwischen auf einem einzelnen ESXi Host. Mit der NVSwitch-Technologie können Sie High Performance Computing (HPC) und KI-Anwendungen wie Deep Learning, wissenschaftliche Simulationen und Big Data-Analysen ausführen, die mehrere GPUs gleichzeitig erfordern.

  • Okta-Identitätsverbund für vCenter: Mit vSphere 8.0 Update 1 können Sie den vCenter Server-Identitätsanbieterverbund für Okta als externen Identitätsanbieter konfigurieren. Weitere Informationen finden Sie unter Konfigurieren des vCenter Server-Identitätsanbieterverbunds für Okta.

  • Unterstützung für Fault Tolerance von virtuellen Maschinen, die ein vTPM-Modul (Virtual TPM) verwenden: Mit vSphere 8.0 Update 1 können Sie FT für VMs mit einem vTPM-Modul verwenden, um kontinuierliche Verfügbarkeit und Sicherheit für Ihre unternehmenskritischen VMs zu gewährleisten.

  • Quick Boot Unterstützung für Server mit TPM 2.0-Chips: Mit vSphere 8.0 Update 1 müssen Sie TPM 2.0 für Quick Boot nicht mehr deaktivieren. Dadurch können Sie Zeit sparen und Sicherheitslücken beseitigen.

  • vSphere API for Storage Awareness (VASA) Version 5 für vSphere Virtual Volumes: VASA Version 5 für vSphere Virtual Volumes verbessert die Sicherheit, das Zertifizierungsmanagement für Bereitstellungen mit mehreren vCenter und den Benutzersupport. VASA Version 5 lehnt selbstsignierte Zertifikate als veraltet ab, bietet jedoch Abwärtskompatibilitätsunterstützung für frühere VASA-Versionen. Lesen Sie vor dem Upgrade auf ESXi 8.0 Update 1 VMware Knowledgebase-Artikel 91387 um sicherzustellen, dass vSphere Virtual Volumes Datenspeicher weiterhin verfügbar sind.

  • Sidecar-Dateien werden in Config-vVol zu regulären Dateien und nicht zu vSphere Virtual Volumes Objekten: Um die Skalierbarkeit und Leistung von vSphere Virtual Volumes zu verbessern, sind Sidecar-Dateien ab vSphere 8.0 Update 1 nicht mehr vSphere Virtual Volumes-Objekte, sondern reguläre Dateien in Config-vVol. Wenn Sidecar-Dateien als vSphere Virtual Volumes-Objekte erstellt werden, können sie für Lösungen wie First Class Disk (FCD), die eine große Anzahl kleiner Sidecar-Dateien erstellen, zu einem Overhead von VASA-Vorgängen führen, wie z. B. das Binden und Aufheben der Bindung der Volumes an einen Protokollendpunkt. Durch das Erstellen von Sidecar-Dateien im Stammverzeichnis Config-vVol wird dieser Overhead aus VASA und Speicher entfernt.

    Nach der Aktualisierung auf ESXi 8.0 Update 1 werden neue virtuelle Maschinen oder virtuelle Festplatten im Namespace Config-vVol auf ESXi Hosts früherer Versionen nicht unterstützt. Weitere Informationen und Lösungen finden Sie im VMware-Knowledgebase-Artikel 90791.

  • Erhöhte Standardkapazität für vSphere Virtual Volumes Objekte des Typs Config-vVol: Ab vSphere 8.0 Update 1 werden vSphere Virtual Volumes Objekte des Typs Config-vVol standardmäßig als Thin-bereitgestellte 255 GB (gegenüber 4 GB in früheren Versionen) erstellt, um die Verwendung von Ordnern über vSphere Virtual Volumes Datenspeicher als Inhalts-Repositorys zuzulassen. Außerdem verwenden Config-vVol-Objekte ab ESXi 8.0 Update 1 das Format VMFS-6 anstelle von VMFS-5.

  • NVMe over TCP-Unterstützung für vSphere Virtual Volumes: vSphere 8.0 Update 1 fügt NVMe over TCP-Unterstützung für vSphere Virtual Volumes hinzu.

  • Extended XCOPY (Erweiterte XCOPY)-Unterstützung: Mit vSphere 8.0 Update 1 können Sie EXTENDED COPY (XCOPY)-Befehle verwenden, um die Datenkopie zwischen VMFS-Datenspeichern zu optimieren, die sich in unterschiedlichen Speicher-Arrays befinden, und nicht nur zwischen Datenspeichern innerhalb desselben Arrays. XCOPY -Vorgänge über Speicher-Arrays hinweg werden nur für VMFS 6-Datenspeicher unterstützt. Sie können Arbeitslasten auslagern, migrieren und klonen. Während ESXi diese Funktion aktiviert, muss die eigentliche Datenmigration über die Arrays hinweg auf der Speicher-Array-Seite implementiert werden. Weitere Informationen zur Verwendung von SCSI-T10-Befehlen, finden Sie unter Verwalten von Hardwarebeschleunigung auf Blockspeichergeräten.

  • Neuer Dateityp für OSDATA-Volumes auf SSD-Geräten: vSphere 8.0 Update 1 fügt einen neuen Dateisystemtyp, VMFSOS, hinzu, speziell für die ESX-OSData-Systempartition auf lokalen SSD-Geräten, mit der Sie virtuelle Flash-Ressourcen weiterhin auf anderen Geräten verwenden können. Der neue Dateityp verhindert, dass Sie ein ESX-OSData-Volume auf einem lokalen SSD-Gerät formatieren, und fsType gibt eine Datei vom Typ VFFS (Virtual Flash File System) zurück. Dies führt dazu, dass das Festplatten-Backing des ESX-OSData-Volumes unter den vFlash-Ressourcen in vCenter aufgeführt wird, aber eine solche Festplatte gehört zum ESX-OSData-Volume und ist nicht Teil des vFlash-Ressourcenpools.

  • Verbesserungen der NFS-Datenverkehrsisolierung: Mit vSphere 8.0 Update 1 können Sie zum Isolieren des NFS-Datenverkehrs einen NFS3-Datenspeicher auf einer NFS-Freigabe über das Netzwerk an einen VM-Kerneladapter auf einem ESXi-Host aus einem Cluster binden. Die VMKNIC-Port-Bindung wird in dieser Version für vSphere Virtual Volumes Datenspeicher, die mit NFS3-Konfigurationen gestützt werden, nicht unterstützt. Weitere Informationen finden Sie unter Konfigurieren einer VMkernel-Bindung für NFS 3-Datenspeicher.

  • Vierfache Erhöhung der Kapazität des NVMe-oF-Namespace: Ab vSphere 8.0 Update 1 können Sie 32 Pfade (gegenüber 8 in früheren Versionen) zu einem NVMe-oF-Namespace verwenden.

  • Unterstützung für End-to-End-NVMe-Stack ohne Protokollübersetzung: Mit vSphere 8.0 Update 1 erweitert die Pluggable Storage Architecture (PSA) die NVMe-Funktionen, um End-to-End-NVMe-Stacks ohne Protokollübersetzung in einer der Schichten zu unterstützen.

    vSphere 8.0 Update 1 erweitert auch die NVMe-Funktionalität, indem Unterstützung für Multipathing-Plugins von Drittanbietern hinzugefügt wird, um NVMe-Arrays zu steuern und zu verwalten.

  • Erhöhter Maximalwert für Windows Server Failover-Cluster (WSFC): vSphere 8.0 Update 1 erhöht die maximale Anzahl von WSFC-Clustern pro ESXi Host von 3 auf 16.

  • Skalieren Sie der Anzahl der NVMe over TCP-Adapter: vSphere 8.0 Update 1 erhöht die Anzahl der NVMe over TCP-Speicheradapter pro ESXi Host von 2 auf 8, um mehr Redundanz und eine bessere Bandbreite zu ermöglichen.

  • Unterstützung des Hinzufügens und Entfernens von VMDirectPath I/O-Geräten im laufenden Betrieb: Mit vSphere 8.0 Update 1 können Sie mithilfe von vSphere API ein VMDirectPath I/O-Gerät hinzufügen oder entfernen, ohne VMs auszuschalten. Weitere Informationen finden Sie unter Unterstützung des Hinzufügens von VMDirectPath I/O-Geräten im laufenden Betrieb.

  • Erhöhte Anzahl der PCI-Passthrough-Geräte pro VM: Mit vSphere 8.0 Update 1 können Sie bis zu 64 PCI-Passthrough-Geräte pro VM hinzufügen (gegenüber 32 in früheren Versionen), um eine bessere Unterstützung für Virtualized Radio Access Network (vRAN)-Anwendungsfälle zu ermöglichen.

  • Außerkraftsetzungen des lokalen Depots für eigenständige Remote- und Zweigstellen (ROBO) ESXi-Hosts: Ab vSphere 8.0 Update 1 können Sie zur Erfüllung der Anforderungen bestimmter Geschäftsanwendungsbeispiele lokale Depot-Außerkraftsetzungen für eigenständige ROBO (Remote Office and Branch Office) ESXi-Hosts im vSphere Client und mithilfe der vSphere Automation API verwalten. Weitere Informationen finden Sie unter Verwalten von Depot-Außerkraftsetzungen für einen Cluster oder einen eigenständigen Host.

  • Erweiterte Filter im vSphere Client: Mit vSphere 8.0 Update 1 können Sie zusätzlich zur vorhandenen Schnellfilteroption erweiterte Filter für die meisten Bestandslistenobjekte im vSphere Client festlegen, z. B. für VM-Listen, Hosts und Cluster, Datenspeicher und verknüpfte vCenter. Sie können Zeichenfolgen wie Name, Status und Gastbetriebssystem sowie Enumerationen wie IP-Adresse verwenden. Um Ihre Filter zu verfeinern, können Sie verschiedene logische Operatoren und zwei Bedingungen verwenden.

  • Erhöhte maximale Anzahl von NFSv3-Datenspeichern, die mit mehreren Verbindungen bereitgestellt werden können: Ab vSphere 8.0 Update 1 können Sie bis zu 8 Verbindungen zu NFSv3-Datenspeichern auf einem ESXi-Host konfigurieren (gegenüber 1 in früheren Versionen) und bis zu 256 Verbindungen haben, die von den NFSv3-Datenspeichern auf dem Host verwendet werden, abhängig von der Kombination aus der Anzahl der Datenspeicher und der Anzahl der für jeden Datenspeicher konfigurierten Verbindungen. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 91481.

  • HTTP/JSON-basiertes Leitungsprotokoll als Alternative zu SOAP/XML: vSphere 8.0 Update 1 bietet Unterstützung für ein neues HTTP/JSON-basiertes Leitungsprotokoll als Alternative zu SOAP/XML. Das neue Protokoll wird mithilfe der Branchenstandard-OpenAPI-Spezifikation Version 3.0 beschrieben und kann für den Zugriff auf die verbreiteten VIM-APIs verwendet werden. Weitere Informationen finden Sie im OpenAPI-Schema und im Web Services-Programmierhandbuch im vSphere Management SDK.

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.

Installation und Upgrades für diese Version

Bevor Sie ein Upgrade auf VASA Version 5 durchführen, lesen Sie VMware Knowledgebase-Artikel 91387, um sicherzustellen, dass Ihre vSphere Virtual Volumes-Datenspeicher weiterhin verfügbar sind.

Kompatibilität

Neu erstellte virtuelle Maschinen oder virtuelle Festplatten der Version ESXi 8.0 Update 1 im Config-vVol-Namespace von vSphere Virtual Volumes werden auf ESXi-Hosts früherer Versionen nicht unterstützt. Weitere Informationen und Lösungen finden Sie im VMware-Knowledgebase-Artikel 90791.

Hinweise zu Produktunterstützung

  • Da der SHA-1-Signaturalgorithmus in vSphere 8.0 nicht mehr unterstützt wird, dürfen Sie, wenn Sie den erweiterten verknüpften Modus (ELM) verwenden, um vCenter Systeme der Versionen 7.0x und 8.0x zu verbinden, während Upgrades kein vertrauenswürdiges SHA-1-Stammzertifikat zur 7.0x-vCenter-Instanz hinzufügen, da das SHA-1-Zertifikat möglicherweise an das 8.0x-vCenter weitergegeben wird und unerwartete Ergebnisse verursacht, z. B. das Trennen von ESXi Hosts.

    Wenn Sie bereits über 7.0x vCenter-Instanzen verfügen, die mit ELM verbunden sind und ein vertrauenswürdiges SHA-1-Stammzertifikat verwenden, fügen Sie der Gruppe keine 8.0x vCenter-Instanz hinzu, da das SHA-1-Zertifikat möglicherweise auf die 8.0x-Instanz repliziert wird.

In dieser Version enthaltene Patches

Patch für VMware vCenter Server 8.0 Update 1

Der Produkt-Patch für vCenter Server enthält VMware-Softwarekorrekturen, Sicherheitskorrekturen und Korrekturen für Drittanbieterprodukte.

Dieser Patch gilt für vCenter Server.

Download-Dateiname

VMware-vCenter-Server-Appliance-8.0.1.00000-21560480-patch-FP.iso

Build

21560480

Größe des Downloads

7965,6 MB

sha256checksum

1016f37c466e46957879f4084e176e62d96803fb0d1ad16cb1b8f6fc0e852b24

Download und Installation

Um diesen Patch von VMware Customer Connect herunterzuladen, müssen Sie zu Produkte und Konten > Produkt-Patches navigieren. Wählen Sie im Dropdown-Menü Produkt auswählen die Option VC und im Dropdown-Menü Version auswählen die Option 8.0.1 aus.

  1. Hängen Sie die Datei VMware-vCenter-Server-Appliance-8.0.1.00000-21560480-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

Probleme bei Sicherheitsfunktionen

  • Das Aktivieren von TLS 1.0 auf ESXi 8.0-Hosts führt zu Verbindungsunterbrechungen

    ESXi 8.0 unterstützt OpenSSL 3.0, und das einzige standardmäßig aktivierte TLS-Protokoll ist TLS 1.2. Wenn Sie versuchen, TLS 1.0 in /UserVars/ESXiVPsDisabledProtocols unter Verwendung von ESXCLI-Befehlen zu aktivieren, kommt es zu Verbindungsunterbrechungen.

    Dieses Problem wurde in der vorliegenden Version behoben.

Sonstige Probleme

  • Möglicherweise werden falsche Metadaten für den Löschvorgang eines vSphere Lifecycle Manager-Depots angezeigt, das Sie zum Erstellen eines Images zum Verwalten eines eigenständigen ESXi-Hosts verwenden

    Ab vSphere 8.0 können Sie ein Image basierend auf einem vSphere Lifecycle Manager-Depot online oder offline erstellen, um den Lebenszyklus eines beliebigen eigenständigen ESXi-Hosts zu verwalten, der Teil Ihrer vCenter Server-Bestandsliste ist. In seltenen Fällen sind die Metadaten für die Löschaufgabe möglicherweise nicht korrekt, wenn Sie ein solches Depot löschen. Beispielsweise werden die Details zur Host-ID und zur Host-IP unter „clusterName“ und „clusterID“ aufgefüllt, wie in folgendem Beispiel:

    clusterName = 10.161.153.136,

    clusterId = host-54,

    entityName = <null>,

    entityId = <null>,

    Dieses Problem tritt auch auf, wenn Sie ein Depot löschen, das mithilfe von VMware vSphere Update Manager Download Service (UMDS) heruntergeladen wurde und Teil des gewünschten Zustands eines eigenständigen Hosts ist. Das Problem hat keine Auswirkungen auf vSphere Lifecycle Manager-Vorgänge und betrifft nur Aufgabenmetadaten für eigenständige Hosts.

    Dieses Problem wurde in der vorliegenden Version behoben.

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

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

    Dieses Problem wurde in der vorliegenden Version behoben.

Serverkonfigurationsprobleme

  • Das Ändern eines IOPS-Grenzwerts (Input/Output Operations Per Second) kann zu einem erheblichen Rückgang des E/A-Durchsatzes von virtuellen Maschinen führen

    Wenn Sie einen IOPS-Grenzwert basierend auf dem Storage I/O Control (SIOC) mithilfe einer SPBM-Richtlinie (Storage Policy Based Management) ändern, kann es zu einer deutlich langsameren VM-Leistung kommen. Wenn Sie eine SPBM-Richtlinie festlegen, werden IOPS-Grenzwerte normalerweise von einem E/A-Filter verarbeitet, während mClock, der Standard-E/A-Scheduler, Reservierungen und Anteile verarbeitet. Aufgrund eines Logikfehlers können E/A-Vorgänge beim mClock-Scheduler statt beim E/A-Filter gedrosselt werden, wenn Sie einen vorhandenen IOPS-Grenzwert ändern. Dies führt dazu, dass E/A-Vorgänge eine erhebliche Verzögerung beim E/A-Filter verursachen, was zu einem Rückgang des E/A-Durchsatzes von virtuellen Maschinen führt.

    Dieses Problem wurde in der vorliegenden Version behoben. Der Fix stellt sicher, dass IOPS-Grenzwerte vom E/A-Filter verarbeitet werden, während mClock die Reservierungen und Anteile verarbeitet. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 89951.

Bekannte Probleme

Installations-, Upgrade- und Migrationsprobleme

  • IP-Eigenschaften können nicht auf virtuellen Maschinen angeben, die mithilfe einer angepassten OVA auf vCenter 8.0 Update 1 bereitgestellt wurden

    Bei der Bereitstellung virtueller Maschinen mithilfe einer angepassten OVA-Datei auf einem vCenter 8.0 Update 1-System wird das Feld zur Angabe der IP-Eigenschaften der virtuellen Maschine möglicherweise nicht angezeigt, und Sie müssen IP-Eigenschaften nach der Bereitstellung manuell hinzufügen.

    Problemumgehung: Wenn die VM-Bereitstellung erfolgreich ist, können Sie die IP-Eigenschaften über die vApp-Optionen auf der Registerkarte Konfigurieren der neu bereitgestellten VM manuell festlegen. Wenn die VM-Bereitstellung fehlschlägt, müssen Sie zuerst die Eigenschaft ovf:required="false" den Eigenschaften mit dem Attribut vmw:qualifiers='Ip' in der OVF-Datei hinzufügen, bevor Sie die Problemumgehung anwenden. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 93677.

  • Upgrades auf vCenter Server 8.0 Update 1 schlagen mit einem Fehler fehl Ausnahme in postInstallHook

    Wenn eine vCenter Single Sign-On Domäne Groß-/Kleinschreibung wie [email protected] oder [email protected] enthält, können Upgrades auf vCenter Server 8.0 Update 1 mit der Fehlermeldung Exception occurred in postInstallHook fehlschlagen.

    Im vSphere Client wird ein Fehler ähnlich dem folgenden angezeigt: wcp service failed to start.

    In der Datei PatchRunner.log wird beispielsweise folgender Fehler angezeigt: An error occurred while starting service 'wcp'.

    In der Datei wcpsvc.log werden folgende Fehler angezeigt: Failed to parse VC JWKS: invalid character '<' looking for beginning of value oder Unable to get VC public key configuration : invalid character '<' looking for beginning of value.

    Nach einem solchen Fehler müssen Sie vCenter aus einer Sicherung oder einem Snapshot wiederherstellen.

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

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

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

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.

Netzwerkprobleme

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

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

Probleme bei vSphere Lifecycle Manager

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

Bekannte Probleme aus vorherigen Versionen

Installations-, Upgrade- und Migrationsprobleme

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

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

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

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

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

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

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

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

    Problemumgehung: Verwenden Sie eine der folgenden beiden Optionen:

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

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

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

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

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

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

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

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

    • device_rss: Verwenden Sie den Parameter DRSS

    • drss: Verwenden Sie den Parameter DRSS

    • rss: Verwenden Sie den Parameter RSS

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

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

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

Sonstige Probleme

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

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

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

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

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

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

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

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

    Problemumgehung: Keine.

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

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

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

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

    Hier ein Skript als Beispiel:

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

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

    ~# reboot

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

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

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

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

  • Einige Uplinks des ionic_en-Treibers funktionieren möglicherweise nur mit einer einzigen Empfangswarteschlange und es tritt eine Leistungsbeeinträchtigung im nativen Modus ein

    Pensando DSC-Adapter (Distributed Services Platform) bieten zwei Hochgeschwindigkeits-Ethernet-Controller (beispielsweise vmnic6 und vmnic7) sowie einen Management-Controller (beispielsweise vmnic8):

    :~] esxcfg-nics -l

    vmnic6 0000:39:00.0 ionic_en_unstable Up 25000Mbps Full 00:ae:cd:09:c9:48 1500 Pensando Systems DSC-25 10/25G 2-port 4G RAM 8G eMMC G1 Services Card, Ethernet Controller

    vmnic7 0000:3a:00.0 ionic_en_unstable Up 25000Mbps Full 00:ae:cd:09:c9:49 1500 Pensando Systems DSC-25 10/25G 2-port 4G RAM 8G eMMC G1 Services Card, Ethernet Controller

    :~] esxcfg-nics -lS

    vmnic8 0000:3b:00.0 ionic_en_unstable Up 1000Mbps Full 00:ae:cd:09:c9:4a 1500 Pensando Systems DSC-25 10/25G 2-port 4G RAM 8G eMMC G1 Services Card, Management Controller

    Die Hochgeschwindigkeits-Ethernet-Controller vmnic6 und vmnic7 werden zuerst registriert; ihr Betrieb erfolgt mit RSS-Einstellung auf 16 Empfangswarteschlangen.

    :~] localcli --plugin-dir /usr/lib/vmware/esxcli/int networkinternal nic privstats get -n vmnic6…Num of RSS-Q=16, ntxq_descs=2048, nrxq_descs=1024, log_level=3, vlan_tx_insert=1, vlan_rx_strip=1, geneve_offload=1 }

    In seltenen Fällen kann es allerdings vorkommen, dass bei einer zuerst erfolgenden Registrierung des Management-Controllers vmnic8 beim vSphere Distributed Switch der Uplink des Hochgeschwindigkeits-Ethernet-Controllers vmnic6 oder vmnic7 mit RSS-Einstellung auf 1 Empfangswarteschlange betrieben wird.:~] localcli --plugin-dir /usr/lib/vmware/esxcli/int networkinternal nic privstats get -n vmnic6…Num of RSS-Q=1, ntxq_descs=2048, nrxq_descs=1024, log_level=3, vlan_tx_insert=1, vlan_rx_strip=1, geneve_offload=1 }

    Infolgedessen kann es zu einer Leistungsbeeinträchtigung im nativen Modus kommen.

    Problemumgehung: Laden Sie den ionic_en driver auf ESXi mit den folgenden Befehlen neu::~] esxcfg-module -u ionic_en:~] esxcfg-module ionic_en:~] localcli --plugin-dir /usr/lib/vmware/esxcli/int/ deviceInternal bind.

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

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

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

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

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

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

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

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

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

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

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

    Problemumgehung: Sie können die Anzahl der Kerne pro Socket mithilfe des vSphere-Clients manuell festlegen. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 89639.

Netzwerkprobleme

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

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

    Problemumgehung: Keine.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Problemumgehung: Keine.

Speicherprobleme

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

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

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

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

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

  • vSphere Storage vMotion-Vorgänge könnten in einer vSAN-Umgebung aufgrund einer nicht authentifizierten Sitzung des NFC-Managers (Network File Copy) fehlschlagen

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

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

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

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

    Problemumgehung: Wiederholen Sie die Snapshot-Erstellung.

Probleme bei vCenter Server und dem vSphere Client

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

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

    Problemumgehung: Klicken Sie auf das Aktualisierungssymbol.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

VM-Verwaltungsprobleme

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

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

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

Probleme bei vSphere Lifecycle Manager

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

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

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

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

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

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

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

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

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

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

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

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

Probleme mit VMware Host Client

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

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

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

Probleme bei Sicherheitsfunktionen

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

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

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

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