-
ESXi 8.0c bietet einen Fix für ein Lizenzierungsproblem auf vSphere-Systemen mit aktivierter vSphere Distributed Services Engine-Funktion.
HINWEIS: Dieser Patch gilt nur für ESXi-Hosts, die für vSphere Distributed Services Engine aktiviert und mit Datenverarbeitungseinheiten (DPU) konfiguriert sind. Weitere Details finden Sie im Abschnitt Behobene Probleme.
| ESXi 8.0c | 30. März 2023 | Build 21493926 Überprüfen Sie, ob Erweiterungen und Updates für diese Versionshinweise zur Verfügung stehen. |
Neuigkeiten
In dieser Version enthaltene Patches
In dieser Version von ESXi 8.0c werden die folgenden Patches bereitgestellt:
Build-Details
| Download-Dateiname: |
VMware-ESXi-8.0c-21493926-depot |
| Build: |
21493926 |
| Download-Größe: |
604,0 MB |
| md5sum: |
53d1368d0ed6c7b15bf89f0f22e9f617 |
| sha256checksum: |
aabf02f457ce0db951f31f6a7f9ac6a5fc049fff094e5b9a59b310548602afe6 |
| Neustart des Hosts erforderlich: |
Ja |
| Migration oder Herunterfahren der virtuellen Maschine erforderlich: |
Ja |
Komponenten
| Komponente |
Bulletin |
Kategorie |
Schweregrad |
|---|---|---|---|
| ESXi-Komponente - ESXi-Kern-VIBs |
ESXi_8.0.0-1.25.21493926 |
Fehlerkorrektur |
Kritisch |
| ESXi-Komponente „Installieren/Aktualisieren“ |
esx-update_8.0.0-1.25.21493926 |
Fehlerkorrektur |
Kritisch |
| ESXi-Komponente „Installieren/Aktualisieren“ |
esxio-update_8.0.0-1.25.21493926 |
Fehlerkorrektur |
Kritisch |
Rollup-Bulletin
Dieses Rollup-Bulletin enthält die neuesten VIBs mit allen Fixes nach der ersten Version von ESXi 8.0.
| Bulletin-ID |
Kategorie |
Schweregrad |
| ESXi-80c-21493926 |
Fehlerkorrektur |
Kritisch |
Image-Profile
Patch- und Updateversionen von VMware enthalten allgemeine und kritische Image-Profile. Die Anwendung des allgemeinen Image-Profils der Version gilt für die neuen Fehlerkorrekturen.
| Name des Image-Profils |
| ESXi-8.0c-21493926-standard |
| ESXi-8.0c-21493926-no-tools |
ESXi-Image
| Name und Version |
Datum der Veröffentlichung |
Kategorie |
Detail |
|---|---|---|---|
| ESXi-80c-21493926 |
30.03.2023 |
Fehlerkorrektur |
Fehlerkorrektur-Image |
Informationen zu den einzelnen Komponenten und Bulletins finden Sie auf der Seite Produkt-Patches und im Abschnitt Behobene Probleme.
Patch-Download und -Installation
Weitere Informationen zu Updates und Upgrades durch vSphere Lifecycle Manager finden Sie unter Info zu vSphere Lifecycle Manager sowie unter vSphere Lifecycle Manager-Baselines und -Images. Sie können ESXi-Hosts auch ohne vSphere Lifecycle Manager mithilfe eines Image-Profils aktualisieren. Dazu müssen Sie die ZIP-Datei des Patch-Offline-Pakets manuell von VMware Customer Connect herunterladen. Wählen Sie im Dropdown-Menü Produkt auswählen die Option ESXi (eingebettet und installierbar) und im Dropdown-Menü Version auswählen die Option 8.0. Weitere Informationen finden Sie unter Aktualisieren von Hosts mithilfe von ESXCLI-Befehlen und im Handbuch VMware ESXi-Upgrade.
Behobene Probleme
- ESXi_8.0.0-1.25.21493926
- esx-update_8.0.0-1.25.21493926
- esxio-update_8.0.0-1.25.21493926
- ESXi-8.0c-21493926-standard
- ESXi-8.0c-21493926-no-tools
- ESXi-80c-21493926
ESXi_8.0.0-1.25.21493926
| Patch-Kategorie |
Fehlerkorrektur |
| Patch-Schweregrad |
Kritisch |
| Hostneustart erforderlich |
Ja |
| Migration oder Herunterfahren der virtuellen Maschine erforderlich |
Ja |
| Betroffene Hardware |
Nicht verfügbar |
| Betroffene Software |
Nicht verfügbar |
| Betroffene VIBs |
|
| Behobene Probleme |
3154255 |
| CVE-Nummern |
Nicht verfügbar |
Dieser Patch aktualisiert das VIB esx-base. Aufgrund ihrer Abhängigkeit vom VIB esx-base werden die folgenden VIBs mit Build-Nummer und Patch-Versionsänderungen aktualisiert, bieten jedoch keine Fixes: esxio-dvfilter-generic-fastpath, esxio-base, esx-xserver, esxio, drivervm-gpu, cpu-microcode, vsan, trx, bmcal, clusterstore, native-misc-drivers, native-misc-drivers-esxio, esx-dvfilter-generic-fastpath, vsanhealth, vdfs, bmcal-esxio, gc, crx, esxio-combiner, gc-esxio und esxio-combiner-esxio.
-
Auf vSphere-Systemen, auf denen VMware NSX installiert ist und die vSphere Distributed Services Engine-Funktion aktiviert ist, schlagen einige NSX-Konfigurationsvorgänge mit einem Fehler aufgrund einer abgelaufenen Lizenz fehl
Für die vSphere Distributed Services Engine-Funktion aktivierte ESXi-Hosts sind Server, die mit Datenverarbeitungseinheiten (DPUs) konfiguriert sind. In NSX Manager schlagen Transportknoten-Konfigurationsvorgänge auf solchen Hosts mit dem Fehlerstatus
Teilerfolgfehl. Fehlerdetails verweisen mit einer Meldung wie z. B.Die aktuelle Lizenz oder ESXi-Version lässt die Ausführung des angeforderten Vorgangs nicht zuauf den zugrunde liegenden Lizenzablauf. Dieser Fehler verhindert weitere NSX-Konfigurationsvorgänge auf den Knoten mit DPU. Dieses Problem tritt 60 Tage nach der ersten Installation von ESXi auf DPU auf, der standardmäßigen Evaluierungslizenz. vSphere Distributed Services Engine-Systeme mit DPUs benötigen keine separate ESXi-Lizenz für ESXi auf DPU. In bestimmten Szenarien kann jedoch ein Lizenzversions-Validator auf der DPU einen Fehler auslösen.Dieses Problem wurde in der vorliegenden Version behoben. Der Fix stellt sicher, dass Lizenzprüfungen in vSphere-Systemen mit DPUs auf dem ESXi-Host und nicht auf DPUs durchgeführt werden.
esx-update_8.0.0-1.25.21493926
| Patch-Kategorie |
Fehlerkorrektur |
| Patch-Schweregrad |
Kritisch |
| Hostneustart erforderlich |
Ja |
| Migration oder Herunterfahren der virtuellen Maschine erforderlich |
Ja |
| Betroffene Hardware |
Nicht verfügbar |
| Betroffene Software |
Nicht verfügbar |
| Betroffene VIBs |
|
| Behobene Probleme |
Nicht verfügbar |
| CVE-Nummern |
Nicht verfügbar |
Aufgrund ihrer Abhängigkeit vom VIB esx-base werden die folgenden VIBs mit Build-Nummer und Patch-Versionsänderungen aktualisiert, bieten jedoch keine Fixes: esx-update und loadesx.
esxio-update_8.0.0-1.25.21493926
| Patch-Kategorie |
Fehlerkorrektur |
| Patch-Schweregrad |
Kritisch |
| Hostneustart erforderlich |
Ja |
| Migration oder Herunterfahren der virtuellen Maschine erforderlich |
Ja |
| Betroffene Hardware |
Nicht verfügbar |
| Betroffene Software |
Nicht verfügbar |
| Betroffene VIBs |
|
| Behobene Probleme |
Nicht verfügbar |
| CVE-Nummern |
Nicht verfügbar |
Aufgrund ihrer Abhängigkeit vom VIB esx-base werden die folgenden VIBs mit Build-Nummer und Patch-Versionsänderungen aktualisiert, bieten aber keine Fixes: esxio-update und loadesxio.
ESXi-8.0c-21493926-standard
| Profilname |
ESXi-8.0c-21493926-standard |
| Build |
Build-Informationen finden Sie unter In dieser Version enthaltene Patches. |
| Anbieter |
VMware, Inc. |
| Datum der Veröffentlichung |
30. März 2023 |
| Akzeptanzebene |
Unterstützte Partner |
| Betroffene Hardware |
Nicht verfügbar |
| Betroffene Software |
Nicht verfügbar |
| Betroffene VIBs |
|
| Behobene Probleme |
3154255 |
| Verwandte CVE-Nummern |
Nicht verfügbar |
-
Dieser Patch enthält Updates zur Behebung des folgenden Problems:
-
Für die vSphere Distributed Services Engine-Funktion aktivierte ESXi-Hosts sind Server, die mit Datenverarbeitungseinheiten (DPUs) konfiguriert sind. In NSX Manager schlagen Transportknoten-Konfigurationsvorgänge auf solchen Hosts mit dem Fehlerstatus
Teilerfolgfehl. Fehlerdetails verweisen mit einer Meldung wie z. B.Die aktuelle Lizenz oder ESXi-Version lässt die Ausführung des angeforderten Vorgangs nicht zuauf den zugrunde liegenden Lizenzablauf. Dieser Fehler verhindert weitere NSX-Konfigurationsvorgänge auf den Knoten mit DPU. Dieses Problem tritt 60 Tage nach der ersten Installation von ESXi auf DPU auf, der standardmäßigen Evaluierungslizenz. vSphere Distributed Services Engine-Systeme mit DPUs benötigen keine separate ESXi-Lizenz für ESXi auf DPU. In bestimmten Szenarien kann jedoch ein Lizenzversions-Validator auf der DPU einen Fehler auslösen.
ESXi-8.0c-21493926-no-tools
| Profilname |
ESXi-8.0c-21493926-no-tools |
| Build |
Build-Informationen finden Sie unter In dieser Version enthaltene Patches. |
| Anbieter |
VMware, Inc. |
| Datum der Veröffentlichung |
30. März 2023 |
| Akzeptanzebene |
Unterstützte Partner |
| Betroffene Hardware |
Nicht verfügbar |
| Betroffene Software |
Nicht verfügbar |
| Betroffene VIBs |
|
| Behobene Probleme |
3154255 |
| Verwandte CVE-Nummern |
Nicht verfügbar |
-
Dieser Patch enthält Updates zur Behebung des folgenden Problems:
-
Für die vSphere Distributed Services Engine-Funktion aktivierte ESXi-Hosts sind Server, die mit Datenverarbeitungseinheiten (DPUs) konfiguriert sind. In NSX Manager schlagen Transportknoten-Konfigurationsvorgänge auf solchen Hosts mit dem Fehlerstatus
Teilerfolgfehl. Fehlerdetails verweisen mit einer Meldung wie z. B.Die aktuelle Lizenz oder ESXi-Version lässt die Ausführung des angeforderten Vorgangs nicht zuauf den zugrunde liegenden Lizenzablauf. Dieser Fehler verhindert weitere NSX-Konfigurationsvorgänge auf den Knoten mit DPU. Dieses Problem tritt 60 Tage nach der ersten Installation von ESXi auf DPU auf, der standardmäßigen Evaluierungslizenz. vSphere Distributed Services Engine-Systeme mit DPUs benötigen keine separate ESXi-Lizenz für ESXi auf DPU. In bestimmten Szenarien kann jedoch ein Lizenzversions-Validator auf der DPU einen Fehler auslösen.
ESXi-80c-21493926
| Name |
ESXi |
| Version |
ESXi-80c-21493926 |
| Datum der Veröffentlichung |
30. März 2023 |
| Kategorie |
Fehlerkorrektur |
| Betroffene Komponenten |
|
| Behobene Probleme |
3154255 |
| Verwandte CVE-Nummern |
Nicht verfügbar |
Bekannte Probleme aus vorherigen Versionen
- Installations-, Upgrade- und Migrationsprobleme
- Sonstige Probleme
- Netzwerkprobleme
- Speicherprobleme
- Probleme bei vCenter Server und dem vSphere Client
- VM-Verwaltungsprobleme
- Probleme bei vSphere Lifecycle Manager
- Probleme mit VMware Host Client
- Probleme bei Sicherheitsfunktionen
- Probleme mit dem Gastbetriebssystem
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:
Validierungsfehler bei Hostanpassungen.Problemumgehung: Deaktivieren Sie das Unterprofil Software FCoE-Konfiguration im Hostprofil.
-
Sie können ESXi-Hosts der Version 8.0 nicht als Referenzhost für vorhandene Hostprofile früherer ESXi-Versionen verwenden
Die Validierung vorhandener Hostprofile für ESXi-Versionen 7.x, 6.7.x und 6.5.x schlägt fehl, wenn nur ein 8.0-Referenzhost in der Bestandsliste verfügbar ist.
Problemumgehung: Stellen Sie sicher, dass Sie über einen Referenzhost der entsprechenden Version in der Bestandsliste verfügen. Verwenden Sie zum Beispiel einen ESXi 7.0 Update 2-Referenzhost, um ein ESXi 7.0 Update 2-Hostprofil zu aktualisieren oder zu bearbeiten.
-
VMNICs können nach einem Upgrade auf ESXi 8.0 ausfallen
Wenn der physische Peer-Switch einer VMNIC die automatische Medienerkennung nicht unterstützt oder die automatische Medienerkennung deaktiviert ist und der VMNIC-Link heruntergefahren und dann wieder hochgefahren wird, bleibt der Link nach dem Upgrade auf oder der Installation von ESXi 8.0 heruntergefahren.
Problemumgehung: Verwenden Sie eine der folgenden beiden Optionen:
-
Aktivieren Sie die Option
media-auto-detectin den BIOS-Einstellungen, indem Sie zum System-Setup-Hauptmenü navigieren, in der Regel durch Drücken von F2 oder Öffnen einer virtuellen Konsole. Dort gehen Sie dann zu Geräteeinstellungen > <spezifisches Broadcom NIC> > Gerätekonfigurationsmenü > Automatische Medienerkennung. Starten Sie den Host neu. -
Alternativ können Sie einen ESXCLI-Befehl ähnlich dem folgenden verwenden:
esxcli network nic set -S <Ihre Geschwindigkeit> -D full -n <Ihre 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, beispielsweisedevice_rss,drssundrss, sind in ESXi 8.0 veraltet, und alle von den Standardwerten abweichenden benutzerdefinierten Werte werden nach einem Upgrade auf ESXi 8.0 verworfen.Problemumgehung: Ersetzen Sie die Werte der Parameter
device_rss,drssundrsswie folgt:-
device_rss: Verwenden Sie den ParameterDRSS -
drss: Verwenden Sie den ParameterDRSS -
rss: Verwenden Sie den ParameterRSS
-
-
Zweite Phase des Wiederherstellungsvorgangs von vCenter Server friert bei 90 % ein
Wenn Sie das GUI-Installationsprogramm von vCenter Server oder die vCenter Server Appliance Management Interface (VAMI) verwenden, um ein vCenter aus einem dateibasierten Backup wiederherzustellen, bleibt der Wiederherstellungsworkflow unter Umständen bei 90 % mit der Fehlermeldung
401 Unable to authenticate userstehen, obwohl die Aufgabe im Back-End erfolgreich abgeschlossen wird. Das Problem tritt auf, wenn der eingesetzte Rechner auf eine andere Zeit eingestellt ist als der NTP-Server, sodass eine Zeitsynchronisierung erforderlich ist. Infolge der Zeitsynchronisierung kann die laufende Sitzung der GUI oder VAMI durch eine Taktverschiebung gestört werden.Problemumgehung: Wenn Sie das GUI-Installationsprogramm verwenden, können Sie den Wiederherstellungsstatus mit dem Befehl
restore.job.getin der Shellapplianceshabrufen. Wenn Sie die VAMI verwenden, aktualisieren Sie Ihren Browser.
Sonstige Probleme
-
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
vSwitchBMCmit Uplinkvusb0auf dem ESXi-Host erstellt. Auf einigen Servern ist dies angesichts der Einführung von Datenverarbeitungseinheiten (Data Processing Units, DPUs) zu erwarten; es kann dadurch allerdings zum Fehlschlagen des Bring-Up-Prozesses der VMware Cloud Foundation kommen.Problemumgehung: Deaktivieren Sie vor der Installation von vSphere 8.0 die USB-Schnittstelle in der von Ihnen verwendeten Remotemanagementanwendung. Richten Sie sich dazu nach der Dokumentation des Herstellers.
Verwenden Sie nach der Installation von vSphere 8.0 den ESXCLI-Befehl
esxcfg-advcfg -s 0 /Net/BMCNetworkEnable, um die Erstellung eines virtuellen SwitchesvSwitchBMCund zugehöriger Portgruppen beim nächsten Neustart des Hosts zu verhindern.Hier ein Skript als Beispiel:
~# esxcfg-advcfg -s 0 /Net/BMCNetworkEnableDer Wert von BMCNetworkEnable ist 0, und der Dienst ist deaktiviert.
~# rebootBeim Neustart des Hosts werden in Verbindung mit dem Netzwerk der Remotemanagementanwendung kein virtueller Switch, keine Portgruppe und keine VMKNIC im Host erstellt.
-
Wenn eine NVIDIA BlueField-DPU im Hardware-Offload-Modus deaktiviert ist, können virtuelle Maschinen mit konfigurierter virtueller SR-IOV-Funktion nicht eingeschaltet werden
NVIDIA BlueField-DPUs müssen im Hardware-Offload-Modus aktiviert sein, damit virtuelle Maschinen mit konfigurierter virtueller SR-IOV-Funktion eingeschaltet und betrieben werden können.
Problemumgehung: Verwenden Sie immer den standardmäßigen Hardware-Offload-Modus, der für NVIDIA BlueField-DPUs aktiviert ist, wenn Sie VMs mit konfigurierter virtueller SR-IOV-Funktion an einen virtuellen Switch angeschlossen haben.
-
In der Virtual Appliance Management Interface (VAMI) wird in der Phase vor dem Upgrade eine Warnung angezeigt
Durch die Umstellung der vSphere-Plug-Ins auf eine Remote-Plug-In-Architektur ist in vSphere 8.0 die Unterstützung für lokale Plug-Ins veraltet. Wenn in Ihrer vSphere 8.0-Umgebung lokale Plug-Ins vorhanden sind, können einige Änderungen an diesen Plug-Ins dazu führen, dass die vor dem Upgrade per VAMI durchgeführte Prüfung scheitert.
In der Ergebnisanzeige zu der dem Update vorausgehenden Prüfung wird eine Fehlermeldung ähnlich der folgenden angezeigt:
Warnmeldung: Die Kompatibilität von Plug-In-Paketen %s mit der neuen vCenter Server-Version kann nicht validiert werden. Nach einem vCenter Server-Upgrade funktionieren sie unter Umständen nicht ordnungsgemäß.Auflösung: Wenden Sie sich an den Plug-In-Anbieter und stellen Sie sicher, dass das Paket mit der neuen vCenter Server-Version kompatibel ist.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 werden Meldungen wie
Ungültige Konfiguration der virtuellen Maschine angezeigt. Virtuelle NUMA kann nicht konfiguriert werden, wenn das Hinzufügen von CPUs im laufenden Betrieb (Hot-Add) aktiviert ist.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.
-
Wenn Sie eine VM mit einer früheren HW-Version als 20 mit einer Anbietergerätegruppe konfigurieren, funktionieren diese VMs möglicherweise nicht wie erwartet
Anbietergerätegruppen, die die Bindung von Hochgeschwindigkeits-Netzwerkgeräten und der GPU ermöglichen, werden nur auf VMs mit HW-Version 20 und höher unterstützt. Sie werden jedoch nicht daran gehindert, eine VM mit einer HW-Version vor 20 mit einer Anbietergerätegruppe zu konfigurieren. Solche VMs funktionieren möglicherweise nicht wie erwartet: So schlägt beispielsweise das Einschalten fehl.
Problemumgehung: Stellen Sie sicher, dass die VM HW-Version 20 ist, bevor Sie eine Anbietergerätegruppe in dieser VM konfigurieren.
Netzwerkprobleme
-
Sie können die maximale Übertragungseinheit (MTU) auf einem VMware vSphere Distributed Switch nicht auf einen Wert größer als 9174 auf einer Pensando DPU einstellen
Wenn Sie die vSphere Distributed Services Engine-Funktion mit einer Pensando DPU auf Ihrem ESXi 8.0-System aktiviert haben, können Sie die maximale Übertragungseinheit (MTU) auf einem vSphere Distributed Switch nicht auf einen Wert größer als 9174 festlegen.
Problemumgehung: Keine.
-
Bei NICs, die den Treiber ntg3 der Version 4.1.3 und höher verwenden, tritt Link Flapping auf
Wenn zwei NICs, die den
ntg3-Treiber der Version 4.1.3 und höher verwenden, direkt und nicht mit einem physischen Switch-Port verbunden sind, kann Link Flapping auftreten. Das Problem tritt nicht beintg3-Treibern mit Versionen vor 4.1.3 oder demtg3-Treiber auf. Dieses Problem steht nicht im Zusammenhang mit dem gelegentlich auftretenden Energy Efficient Ethernet (EEE) Link Flapping bei solchen NICs. Die Lösung für das EEE-Problem besteht darin, einenntg3-Treiber der Version 4.1.7 oder höher zu verwenden oder EEE an physischen Switch-Ports zu deaktivieren.Problemumgehung: Aktualisieren Sie den
ntg3-Treiber auf Version 4.1.8 und setzen Sie den neuen ModulparameternoPhyStateSetauf1. Der ParameternoPhyStateSetist standardmäßig auf0gesetzt und wird in den meisten Umgebungen nicht benötigt, es sei denn, sie sind von dem Problem betroffen. -
Die Installation oder das Upgrade von VMware NSX in einer vSphere-Umgebung mit DPUs schlägt möglicherweise mit einem Konnektivitätsfehler fehl
Ein zeitweiliges Zeitproblem auf der ESXi-Hostseite kann dazu führen, dass die Installation oder das Upgrade von NSX in einer vSphere-Umgebung mit DPUs fehlschlägt. Die Datei
nsxapi.logenthält Protokolle wie etwaFehler beim Abrufen der SFHC-Antwort. 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:
-
Wenn ein VASA-Anbieter, der die VASA API-Version 4.0 unterstützt, bei einer früheren Version von VMware vCenter registriert ist, bleibt die VASA API-Version nach dem Upgrade auf VMware vCenter 8.0 unverändert. Wenn Sie beispielsweise ein VMware vCenter-System der Version 7.x mit einem registrierten VASA-Anbieter aktualisieren, der sowohl die VASA API-Versionen 3.5 als auch 4.0 unterstützt, ändert sich die VASA API-Version nicht automatisch auf 4.0, obwohl der VASA-Anbieter die VASA API-Version 4.0 unterstützt. Wenn Sie nach dem Upgrade zu vCenter Server > Konfigurieren > Speicheranbieter navigieren und die Registerkarte Allgemein des registrierten VASA-Anbieters erweitern, wird weiterhin die VASA API-Version 3.5 angezeigt.
-
Wenn Sie einen VASA-Anbieter, der die VASA API-Version 3.5 unterstützt, mit einem VMware vCenter 8.0-System registrieren und die VASA API-Version auf 4.0 aktualisieren, wird auch nach dem Upgrade weiterhin die VASA API-Version 3.5 angezeigt.
Problemumgehung: Heben Sie die Registrierung des VASA-Anbieters auf dem VMware vCenter 8.0-System auf und registrieren Sie ihn erneut.
-
-
vSphere Storage vMotion-Vorgänge könnten in einer vSAN-Umgebung aufgrund einer nicht authentifizierten Sitzung des NFC-Managers (Network File Copy) fehlschlagen
Migrationen in einen vSAN-Datenspeicher mithilfe von vSphere Storage vMotion von virtuellen Maschinen mit mindestens einem Snapshot und mehreren virtuellen Festplatten mit unterschiedlicher Speicherrichtlinie könnten fehlschlagen. Das Problem tritt aufgrund einer nicht authentifizierten Sitzung des NFC-Managers auf, da der Simple Object Access Protocol (SOAP)-Body die zulässige Größe überschreitet.
Problemumgehung: Migrieren Sie zuerst den VM-Start-Namespace und nur eine der virtuellen Festplatten. Führen Sie nach Abschluss des Vorgangs nur eine Festplattenmigration der verbleibenden beiden Festplatten durch.
-
Aufgrund eines im Content Based Read Cache (CBRC) auftretenden Fehlers im Zusammenhang mit einem Digest-Vorgang können keine Snapshots von virtuellen Maschinen erstellt werden
Eine seltene Racebedingung bei der Zuweisung einer Inhalts-ID während der Aktualisierung der CBRC-Digest-Datei kann zu einer Diskrepanz zwischen der Inhalts-ID auf der Datenfestplatte und der Digest-Festplatte führen. Infolgedessen können Sie keine VM-Snapshots erstellen. Im Backtrace wird ein Fehler vom Typ
Beim Speichern des Snapshots ist ein Fehler aufgetreten: Fehler bei Digest-Vorgangangezeigt. 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. Eine Fehlermeldung, wie z. B.
Fehler beim Extrahieren der angeforderten Daten, wird angezeigt. Einzelheiten finden Sie in den vSphere Client-Protokollen. + TypeError: NULL-Eigenschaften können nicht gelesen werden („cluster“ wird gelesen). Das Problem tritt nur auf, wenn Sie Volumes überprüfen, die von vCenter Server Version 7.x unter Verwendung des vSphere Client von vCenter Server Version 8.0 verwaltet werden.Problemumgehung: Melden Sie sich beim vSphere Client eines vCenter Server-Systems der Version 7.x an, um die Volume-Eigenschaften zu überprüfen.
-
ESXi-Hosts reagieren möglicherweise nicht mehr, und es wird eine vpxa-Dump-Datei angezeigt, weil in seltenen Fällen die Dateideskriptoren für die Anforderungswarteschlange auf vpxa nicht ausreichen
In seltenen Fällen kann es bei lange dauernden Anforderungen an den vpxa-Dienst, etwa beim Warten auf Zugang zu einem langsamen Datenspeicher, in der Anforderungswarteschlange auf vpxa zu einer Überschreitung des Limits der Dateideskriptoren kommen. Infolgedessen reagieren ESXi-Hosts dann unter Umständen kurzzeitig nicht mehr, und eine Datei
vpxa-zdump.00*wird im Verzeichnis/var/coreangezeigt. Die vpxa-Protokolle enthalten die ZeileToo many open files.Problemumgehung: Keine. Der vpxa-Dienst wird automatisch neu gestartet, um das Problem zu beheben.
-
Wenn Sie ein benutzerdefiniertes Update-Repository mit nicht vertrauenswürdigen Zertifikaten verwenden, schlägt das vCenter Server-Upgrade oder das Update mithilfe von vCenter Lifecycle Manager-Workflows auf vSphere 8.0 möglicherweise fehl
Wenn Sie ein benutzerdefiniertes Update-Repository mit selbstsignierten Zertifikaten verwenden, denen die VMware Certificate Authority (VMCA) nicht vertraut, kann vCenter Lifecycle Manager keine Dateien aus einem solchen Repository herunterladen. Dies führt dazu, dass vCenter Server-Upgrade- oder Aktualisierungsvorgänge mithilfe von vCenter Lifecycle Manager-Workflows mit dem Fehler
Failed to load the repository manifest data for the configured upgradefehlschlagen.Problemumgehung: Verwenden Sie zur Durchführung des Upgrades die CLI, das GUI-Installationsprogramm oder die Virtual Appliance Management Interface (VAMI). Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 89493.
VM-Verwaltungsprobleme
-
Beim Hinzufügen einer vorhandenen virtuellen Festplatte zu einer neuen virtuellen Maschine wird unter Umständen eine Fehlermeldung angezeigt, dass die VM-Konfiguration abgelehnt wird
Wenn Sie unter Verwendung des VMware Host Client einer neuen virtuellen Maschine eine vorhandene virtuelle Festplatte hinzufügen, scheitert der Vorgang eventuell mit einer Fehlermeldung ähnlich der folgenden:
Die VM-Konfiguration wurde abgelehnt. Weitere Informationen finden Sie in der Browserkonsole. Das Problem tritt auf, weil der VMware Host Client eventuell einige Eigenschaften, beispielsweise zum Festplattencontroller, nicht abrufen kann.Problemumgehung: Klicken Sie nach dem Auswählen einer Festplatte und Aufrufen der Seite Bereit zum Abschließen nicht auf die Schaltfläche Beenden. Wechseln Sie stattdessen zum vorherigen Schritt, warten Sie ab, bis die Seite geladen ist, und klicken Sie dann auf Weiter > Beenden.
Probleme bei vSphere Lifecycle Manager
-
Wenn Sie einen ESXi-Host verwenden, der aus einem Hostprofil mit aktivierter statusbehafteten Installation als Image bereitgestellt wurde, um andere ESXi-Hosts in einem Cluster bereitzustellen, schlägt der Vorgang fehl
Wenn Sie ein Image eines ESXi-Hosts, das von einem Hostprofil mit aktivierter statusbehafteter Installation bereitgestellt wurde, extrahieren, um andere ESXi-Hosts in einem vSphere Lifecycle Manager-Cluster bereitzustellen, schlägt der Vorgang fehl. Im vSphere Client wird ein Fehler ähnlich dem folgenden angezeigt:
Ein allgemeiner Systemfehler ist aufgetreten: Image konnte nicht aus Host extrahiert werden: Keine gespeicherte Kopie für inaktive VIB VMW_bootbank_xxx verfügbar. Extrahieren des Images von Host xxx.eng.vmware.com ist fehlgeschlagen.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:
Ein allgemeiner Systemfehler ist aufgetreten: Nachdem die Standardisierung von Host ... abgeschlossen wurde, meldete die Konformitätsprüfung den Host als „Nicht konform“. Das Image auf dem Host stimmt nicht mit dem Image-Satz für den Cluster überein. Wiederholen Sie den Vorgang zur Standardisierung des Clusters.Dies ist ein selten auftretendes Problem, das verursacht wird durch eine gelegentlich auftretende Zeitüberschreitung bei der auf die Wartung folgenden Prüfung der DPU.
Problemumgehung: Starten Sie den ESXi-Host neu und führen Sie die Konformitätsprüfung bei vSphere Lifecycle Manager erneut durch, zu der auch die auf die Wartung folgende Prüfung gehört.
Probleme mit VMware Host Client
-
VMware Host Client zeigt möglicherweise falsche Beschreibungen für Schweregrad-Ereigniszustände an
Wenn Sie im VMware Host Client nach den Beschreibungen der Schweregrad-Ereigniszustände eines ESXi-Hosts suchen, können sie sich von den Beschreibungen unterscheiden, die bei Verwendung von Intelligent Platform Management Interface (IPMI) oder Lenovo XClarity Controller (XCC) angezeigt werden. Beispielsweise kann im VMware Host Client die Beschreibung des Schweregrad-Ereigniszustands für die PSU-Sensoren
Transition to Non-critical from OKlauten, während sie im XCC und IPMITransition to OKlautet.Problemumgehung: Überprüfen Sie die Beschreibungen für Schweregrad-Ereigniszustände mithilfe des ESXCLI-Befehls
esxcli hardware ipmi sdr listund Lenovo XCC.
Probleme bei Sicherheitsfunktionen
-
Bei Verwendung einer RSA-Schlüsselgröße kleiner als 2048 Bit scheitert die RSA-Signaturerstellung
Ab vSphere 8.0 verwendet ESXi den FIPS-Anbieter OpenSSL 3.0. Entsprechend der FIPS 186-4-Anforderung muss die RSA-Schlüsselgröße für jede Signaturerstellung mindestens 2048 Bit betragen, und die Signaturerstellung mit SHA1 wird nicht unterstützt.
Problemumgehung: Verwenden Sie eine RSA-Schlüsselgröße größer als 2048.
Probleme mit dem Gastbetriebssystem
-
Das Gastbetriebssystem einer VM reagiert möglicherweise aufgrund eines Kommunikationsausfalls über die VMCI (Virtual Machine Communication Interface) nicht mehr
Unter sehr spezifischen Umständen kann es bei der Ausführung eines vSphere vMotion-Vorgangs auf einer virtuellen Maschine parallel zu einem Vorgang, der VMCI-Datagramme sendet, bei Diensten, die VMCI-Datagramme verwenden, zu einer unerwarteten Kommunikation oder einem Kommunikationsverlust kommen. Unter denselben Bedingungen kann das Problem auch beim Wiederherstellen eines Arbeitsspeicher-Snapshots, beim Fortsetzen einer angehaltenen VM oder beim Hinzufügen von CPUs im laufenden Betrieb auftreten. Dies führt dazu, dass das Gastbetriebssystem, das von Diensten abhängt, die über VMCI kommunizieren, möglicherweise nicht mehr reagiert. Das Problem kann sich auch auf Dienste auswirken, die vSockets über VMCI verwenden. Dieses Problem hat keine Auswirkungen auf VMware Tools. Das Problem ist spezifisch für VMs auf Hardwareversion 20 mit einer Linux-Distribution, die bestimmte Patches enthält, die im Linux-Kernel 5.18 für eine VMCI-Funktion eingeführt wurden, einschließlich, aber nicht beschränkt auf aktuelle Versionen von RHEL 8.7, Ubuntu 22.04 und 22.10 und SLES15 SP3 und SP4.
Problemumgehung: Setzen Sie die erweiterte Option
vmci.dmaDatagramSupportaufFALSE. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 89683. -
Das Linux-Gastbetriebssystem kann den Startvorgang nicht abschließen, wenn die Neuzuordnung von Direct Memory Access (DMA) aktiviert ist
Wenn die erweiterte Prozessoreinstellung
Enable IOMMU in this virtual machineauf einer virtuellen Maschine aktiviert ist und das Gastbetriebssystem die DMA-Neuzuordnung aktiviert hat, kann das Linux-Gastbetriebssystem den Startvorgang möglicherweise nicht abschließen. Dieses Problem betrifft VMs mit Hardwareversion 20 und einer Linux-Distribution, die bestimmte Patches enthält, die im Linux-Kernel 5.18 für eine VMCI-Funktion eingeführt wurden, einschließlich, aber nicht beschränkt auf aktuelle Versionen von RHEL 8.7, Ubuntu 22.04 und 22.10 und SLES15 SP3 und SP4.Problemumgehung: Setzen Sie die erweiterte Option
vmci.dmaDatagramSupportaufFALSEoder deaktivieren Sie die OptionEnable IOMMU in this virtual machine. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 89683.
