Die früheren bekannten Probleme gliedern sich in folgende Gruppen.
- Die Vorabprüfungen für vCenter-Upgrades/Migrationen schlagen mit „Unerwarteter Fehler 87“ fehl
Die Vorabprüfungen für vCenter Server-Upgrades/Migrationen schlagen fehl, wenn das Security Token Service-Zertifikat (STS) kein Feld für SAN (Subject Alternative Name) enthält. Diese Situation tritt auf, wenn Sie das vCenter 5.5 Single Sign-On-Zertifikat durch ein benutzerdefiniertes Zertifikat ohne SAN-Feld ersetzt haben und versuchen, ein Upgrade auf vCenter Server 7.0 durchzuführen. Das Upgrade betrachtet das STS-Zertifikat als ungültig, und die Vorabprüfungen verhindern, dass der Upgrade-Vorgang fortgesetzt wird.
Problemumgehung: Ersetzen Sie das STS-Zertifikat durch ein gültiges Zertifikat, das ein SAN-Feld enthält, und fahren Sie dann mit dem Upgrade/der Migration von vCenter Server 7.0 fort.
- Probleme beim Upgrade auf vSphere 7.0 mit vorhandenen CIM-Anbietern
Nach dem Upgrade funktionieren zuvor installierte 32-Bit-CIM-Anbieter nicht mehr, da ESXi 64-Bit-CIM-Anbieter benötigt. Kunden verlieren möglicherweise Verwaltungs-API-Funktionen im Zusammenhang mit CIMPDK, NDDK (natives DDK), HEXDK, VAIODK (E/A-Filter) und sehen Fehler im Zusammenhang mit uwglibc-Abhängigkeit.
Das Syslog meldet ein fehlendes Modul, „32 bit shared libraries not loaded“.
Problemumgehung: Für dieses Problem gibt es keine Umgehung. Die Lösung besteht darin, neue 64-Bit-CIM-Anbieter von Ihrem Anbieter herunterzuladen.
- Die Installation von 7.0 Update 1-Treibern auf ESXi 7.0-Hosts schlägt möglicherweise fehl
Sie können keine Treiber für ESXi 7.0 Update 1 auf Hosts installieren, auf denen ESXi 7.0 oder 7.0b ausgeführt wird.
Der Vorgang schlägt mit einer Fehlermeldung ähnlich der folgenden fehl:
VMW_bootbank_qedrntv_3.40.4.0-12vmw.701.0.0.xxxxxxx erfordert vmkapi_2_7_0_0, doch die Anforderung kann innerhalb des ImageProfile nicht erfüllt werden.
Weitere Informationen hierzu finden Sie in der Protokolldatei.
Problemumgehung: Aktualisieren Sie den ESXi-Host auf 7.0 Update 1. Wiederholen Sie die Treiberinstallation.
- Der UEFI-Neustart von ESXi-Hosts wird während eines Updates von einer früheren Version von ESXi 7.0 auf ESXi 7.0 Update 2 möglicherweise beendet
Wenn Sie versuchen, Ihre Umgebung von einer früheren Version von ESXi 7.0 auf Version 7.0 Update 2 zu aktualisieren und dabei vSphere Lifecycle Manager-Patch-Baselines verwenden, wird der UEFI-Neustart von ESXi-Hosts möglicherweise mit einem Fehler ähnlich dem folgenden beendet:
Laden von /boot.cfg
crypto64.efi konnte nicht geladen werden
Fatal error: 15 (nicht gefunden)
Problemumgehung: Weitere Informationen finden Sie in den VMware-Knowledgebase-Artikeln 83063 und 83107.
- Wenn Legacy-VIBs auf einem ESXi-Host verwendet werden, kann vSphere Lifecycle Manager eine gewünschte Softwarespezifikation für ein Seeding für einen neuen Cluster nicht extrahieren
Mit vCenter Server 7.0 Update 2 können Sie einen neuen Cluster erstellen, indem Sie die gewünschte Softwarespezifikation von einem einzelnen Referenzhost importieren. Wenn jedoch auf einem ESXi-Host Legacy-VIBs verwendet werden, kann vSphere Lifecycle Manager in der vCenter Server-Instanz, in der Sie den Cluster erstellen, keine Referenzsoftwarespezifikation von einem solchen Host extrahieren. In der Datei /var/log/lifecycle.log werden Meldungen ähnlich der folgenden angezeigt:
020-11-11T06:54:03Z lifecycle: 1000082644: HostSeeding:499 ERROR Extract depot failed: Checksum doesn't match. Calculated 5b404e28e83b1387841bb417da93c8c796ef2497c8af0f79583fd54e789d8826, expected: 0947542e30b794c721e21fb595f1851b247711d0619c55489a6a8cae6675e796 2020-11-11T06:54:04Z lifecycle: 1000082644: imagemanagerctl:366 ERROR Extract depot failed. 2020-11-11T06:54:04Z lifecycle: 1000082644: imagemanagerctl:145 ERROR [VibChecksumError]
Problemumgehung: Befolgen Sie die im VMware-Knowledgebase-Artikel 83042 beschriebenen Schritte.
- Nach jedem ESXi-Startvorgang wird in der Datei „syslog.log“ ein kurzer Anstieg von Protokollmeldungen verzeichnet
Nach der Aktualisierung auf ESXi 7.0 Update 2 wird im Anschluss an jeden Startvorgang unter Umständen ein kurzer Anstieg von Protokollmeldungen verzeichnet.
Solche Protokolle weisen nicht auf ein Problem mit ESXi hin. Die folgenden Meldungen können ignoriert werden. Beispiel:
2021-01-19T22:44:22Z watchdog-vaai-nasd: '/usr/lib/vmware/nfs/bin/vaai-nasd -f' exited after 0 seconds (quick failure 127) 1
2021-01-19T22:44:22Z watchdog-vaai-nasd: Executing '/usr/lib/vmware/nfs/bin/vaai-nasd -f'
2021-01-19T22:44:22.990Z aainasd[1000051135]: Log for VAAI-NAS Daemon for NFS version=1.0 build=build-00000 option=DEBUG
2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoadFile: No entries loaded by dictionary.
2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoad: Cannot open file "/usr/lib/vmware/config": No such file or directory.“
2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoad: Cannot open file "//.vmware/config": No such file or directory.“
2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoad: Cannot open file "//.vmware/preferences": No such file or directory.“
2021-01-19T22:44:22.990Z vaainasd[1000051135]: Switching to VMware syslog extensions
2021-01-19T22:44:22.992Z vaainasd[1000051135]: Loading VAAI-NAS plugin(s).
2021-01-19T22:44:22.992Z vaainasd[1000051135]: DISKLIB-PLUGIN : Not loading plugin /usr/lib/vmware/nas_plugins/lib64: Not a shared library.
Problemumgehung: Keine
- In Berichten zur vSphere Quick Boot-Kompatibilitätsprüfung werden Warnmeldungen zu fehlenden VIBs angezeigt
Wenn Sie nach einem Upgrade auf ESXi 7.0 Update 2 die vSphere Quick Boot-Kompatibilität Ihrer Umgebung mithilfe des Befehls /usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py überprüfen, werden möglicherweise einige Warnungen zu fehlenden VIBs in der Shell angezeigt. Beispiel:
VIB(s) wurde(n) ... in der angegebenen VIB-Sammlung nicht gefunden.
Fehlende reservierte VIB(s) wird/werden ignoriert..., sie werden aus den reservierten VIB-IDs entfernt.
Solche Warnungen weisen nicht auf ein Kompatibilitätsproblem hin.
Problemumgehung: Es ist sicher, die Meldungen zu fehlenden VIBs zu ignorieren. Dies wirkt sich nicht auf die vSphere Quick Boot-Kompatibilität aus. In der letzten Ausgabezeile des Befehls loadESXCheckCompat wird eindeutig angegeben, ob der Host kompatibel ist.
- Automatisches Bootstrapping eines Clusters, den Sie mit einem vSphere Lifecycle Manager-Image verwalten, schlägt mit einem Fehler fehl
Wenn Sie versuchen, für einen Cluster, den Sie mit einem vSphere Lifecycle Manager-Image verwalten, automatisches Bootstrapping zu verwenden, um eine statusbehaftete Installation und Überschreibung der VMFS-Partitionen durchzuführen, schlägt der Vorgang mit einer Fehlermeldung fehl. Im Support-Paket werden Meldungen ähnlich der folgenden angezeigt:
2021-02-11T19:37:43Z Host Profiles[265671 opID=MainThread]: FEHLER: EngineModule::ApplyHostConfig. Exception: [Errno 30] Schreibgeschütztes Dateisystem
Problemumgehung: Folgen Sie den Anweisungen des Anbieters, um die VMFS-Partition auf dem Zielhost zu bereinigen, und wiederholen Sie den Vorgang. Alternativ können Sie eine leere Festplatte verwenden. Weitere Informationen zum Dienstprogramm zur Festplattenpartitionierung auf ESXi finden Sie im VMware-Knowledgebase-Artikel 1036609.
- Upgrades von ESXi 6.5.x und 6.7.0 auf ESXi 7.x unter Verwendung von ESXCLI können aufgrund einer Speicherbeschränkung fehlschlagen
Upgrades auf von ESXi 6.5.x und 6.7.0 auf ESXi 7 mithilfe des ESXCLI-Befehls esxcli software profile update oder esxcli software profile install können fehlschlagen, da die ESXi-Bootbank möglicherweise die Größe des Image-Profils unterschreitet. In der ESXi Shell oder der PowerCLI Shell wird folgender Fehler angezeigt:
[InstallationError]
Die ausstehende Transaktion benötigt 244 MB freien Speicher, die maximal unterstützte Größe beträgt jedoch 239 MB.
Weitere Informationen hierzu finden Sie in der Protokolldatei.
Das Problem tritt auch auf, wenn Sie ein Upgrade des ESXi-Hosts mithilfe des ESXCLI-Befehls esxcli software vib update oder esxcli software vib install versuchen.
Problemumgehung: Sie können das Upgrade in zwei Schritten durchführen, indem Sie ESXi-Hosts mit dem Befehl esxcli software profile update erst auf ESXi 6.7 Update 1 oder höher und dann auf ESXi 7.0 Update 1c aktualisieren. Alternativ können Sie ein Upgrade mithilfe eines ISO-Images und des vSphere Lifecycle Manager ausführen.
- Sie können Linked Clones nicht über vCenter Server hinweg migrieren.
Wenn Sie einen Linked Clone über vCenter Server hinweg migrieren, schlagen Vorgänge wie Einschalten und Löschen für die virtuelle Quellmaschine möglicherweise mit dem Fehler Ungültiger Status der virtuellen Maschine fehl.
Problemumgehung: Behalten Sie Linked Clones auf demselben vCenter Server wie die Quell-VM bei. Alternativ können Sie den Linked Clone vor der Migration auf einen vollständigen Klon heraufstufen.
- Die Migration zwischen vCenter Servern von virtuellen Maschinen mit vielen virtuellen Festplatten und Snapshot-Ebenen zu einem Datenspeicher auf NVMe-over-TCP-Speicher schlägt möglicherweise fehl
Die Migration zwischen vCenter Servern von virtuellen Maschinen mit mehr als 180 virtuellen Festplatten und 32 Snapshot-Ebenen zu einem Datenspeicher auf NVMe-over-TCP-Speicher schlägt möglicherweise fehl. Der ESXi-Host schlägt präventiv mit einem Fehler wie Die Migration hat die maximale Umschaltzeit von 100 Sekunden überschritten fehl.
Problemumgehung: Keine
- Eine virtuelle Maschine mit aktivierten Virtual Performance Monitoring Counters (VPMC) kann möglicherweise nicht zwischen ESXi-Hosts migriert werden
Wenn Sie versuchen, eine virtuelle Maschine mit aktivierten VPMC mithilfe von vSphere vMotion zu migrieren, schlägt der Vorgang möglicherweise fehl, wenn der Zielhost einige der Indikatoren zum Berechnen des Arbeitsspeichers oder der Leistungsstatistiken verwendet. Der Vorgang schlägt mit einem Fehler wie Ein vom Gast verwendeter Leistungsindikator ist auf der Host-CPU nicht verfügbar fehl.
Problemumgehung: Schalten Sie die virtuelle Maschine aus und verwenden Sie die Cold-Migration. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 81191.
- Wenn ein Live-VIB-Installations-, Upgrade- oder Entfernungsvorgang unmittelbar vor einem interaktiven oder geskripteten Upgrade auf ESXi 7.0 Update 3 unter Verwendung der ISO-Datei des Installationsprogramms erfolgt, schlägt das Upgrade fehl.
Wenn ein VIB-Installations-, Upgrade- oder Entfernungsvorgang unmittelbar vor einem interaktiven oder geskripteten Upgrade auf ESXi 7.0 Update 3 unter Verwendung der ISO-Datei des Installationsprogramms erfolgt, behält der ConfigStore möglicherweise einige Konfigurationen des Upgrades nicht bei. Dies führt dazu, dass auf ESXi-Hosts nach dem Upgradevorgang nicht mehr zugegriffen werden kann, obwohl das Upgrade erfolgreich gewesen zu sein scheint. Um dieses Problem zu vermeiden, fügt das ESXi 7.0 Update 3-Installationsprogramm eine temporäre Prüfung hinzu, um solche Szenarien zu blockieren. In der Konsole des ESXi-Installationsprogramms wird die folgende Fehlermeldung angezeigt: Die Installation, das Upgrade oder die Entfernung von Live-VIB kann dazu führen, dass nachfolgende ESXi-Upgrades bei Verwendung des ISO-Installationsprogramms fehlschlagen.
Problemumgehung: Verwenden Sie eine alternative Upgrademethode, um das Problem zu vermeiden, z. B. die Verwendung von ESXCLI oder vSphere Lifecycle Manager.
- Die Smartcard- und RSA SecurID-Authentifizierung funktioniert nach dem Upgrade auf vCenter Server 7.0 möglicherweise nicht mehr
Wenn Sie vCenter Server für Smartcard- oder RSA SecurID-Authentifizierung konfiguriert haben, lesen Sie den VMware-Knowledgebase-Artikel unter https://kb.vmware.com/s/article/78057, bevor Sie den vSphere 7.0-Upgrade-Vorgang starten. Wenn Sie die Problemumgehung nicht wie in der KB beschrieben durchführen, werden möglicherweise die folgenden Fehlermeldungen angezeigt und die Smartcard- oder RSA SecurID-Authentifizierung funktioniert nicht.
„Die Smartcard-Authentifizierung funktioniert möglicherweise nicht mehr. Die Smartcard-Einstellungen werden möglicherweise nicht beibehalten, und die Smartcard-Authentifizierung funktioniert möglicherweise nicht mehr.“
oder
„Die RSA SecurID-Authentifizierung funktioniert möglicherweise nicht mehr. Die RSA SecurID-Einstellungen werden möglicherweise nicht beibehalten, und die RSA SecurID-Authentifizierung funktioniert möglicherweise nicht mehr.“
Problemumgehung: Lesen Sie vor dem Upgrade auf vSphere 7.0 den VMware-Knowledgebase-Artikel unter https://kb.vmware.com/s/article/78057.
- Das Upgrade eines vCenter Server mit einem externen Platform Services Controller von 6.7u3 auf 7.0 schlägt mit einem VMAFD-Fehler fehl
Wenn Sie eine vCenter Server-Bereitstellung mit einem externen Platform Services Controller aktualisieren, konvergieren Sie den Platform Services Controller in eine vCenter Server Appliance. Wenn das Upgrade mit dem Fehler install.vmafd.vmdir_vdcpromo_error_21 fehlschlägt, ist der Firstboot-Vorgang von VMAFD fehlgeschlagen. Beim Firstboot-Vorgang von VMAFD wird die VMware Directory Service-Datenbank (data.mdb) vom Platform Services Controller der Quelle und von der vCenter Server Appliance des Replikationspartners kopiert.
Problemumgehung: Deaktivieren Sie auf dem Ethernet-Adapter des Platform Services Controller der Quelle oder der vCenter Server Appliance des Replikationspartners TCP Segmentation Offload (TSO) und Generic Segmentation Offload (GSO), bevor Sie ein Upgrade eines vCenter Server mit einem externen Platform Services Controller durchführen. Weitere Informationen hierzu finden Sie im Knowledgebase-Artikel: https://kb.vmware.com/s/article/74678
- Smartcard- und RSA SecurID-Einstellungen werden während des vCenter Server-Upgrades möglicherweise nicht beibehalten
Die Authentifizierung mit RSA SecurID funktioniert nach dem Upgrade auf vCenter Server 7.0 nicht. Eine Fehlermeldung informiert Sie über dieses Problem, wenn Sie versuchen, sich mit Ihrer RSA SecurID-Anmeldung anzumelden.
Problemumgehung: Konfigurieren Sie die Smartcard oder RSA SecurID neu.
- Die Migration von vCenter Server für Windows auf vCenter Server Appliance 7.0 schlägt mit einer Netzwerkfehlermeldung fehl
Die Migration von vCenter Server für Windows auf vCenter Server Appliance 7.0 schlägt mit der Fehlermeldung IP ist bereits im Netzwerk vorhanden fehl. Dadurch wird verhindert, dass der Migrationsvorgang die Netzwerkparameter auf der neuen vCenter Server Appliance konfiguriert. Weitere Informationen finden Sie in der Protokolldatei: /var/log/vmware/upgrade/UpgradeRunner.log
Problemumgehung:
- Stellen Sie sicher, dass alle Windows Updates auf der vCenter Server für Windows-Quellinstanz abgeschlossen wurden, oder deaktivieren Sie automatische Windows Updates, bis die Migration beendet ist.
- Wiederholen Sie die Migration von vCenter Server für Windows zu vCenter Server Appliance 7.0.
- Wenn Sie die Anzahl der virtuellen Funktionen für ein SR-IOV-Gerät mithilfe des max_vfs-Modulparameters konfigurieren, werden die Änderungen möglicherweise nicht wirksam
In vSphere 7.0 können Sie die Anzahl der virtuellen Funktionen für ein SR-IOV-Gerät konfigurieren, indem Sie beispielsweise die Virtual Infrastructure Management-API (VIM-API) über den vSphere Client verwenden. Für die Aufgabe ist kein Neustart des ESXi-Hosts erforderlich. Wenn Sie nach der Verwendung der VIM-API-Konfiguration versuchen, die Anzahl der virtuellen SR-IOV-Funktionen mit dem max_vfs-Modulparameter zu konfigurieren, werden die Änderungen möglicherweise nicht wirksam, da sie von der VIM-API-Konfiguration überschrieben werden.
Problemumgehung: Keine. Um die Anzahl der virtuellen Funktionen für ein SR-IOV-Gerät zu konfigurieren, verwenden Sie jedes Mal dieselbe Methode. Verwenden Sie die VIM-API oder verwenden Sie den max_vfs-Modulparameter und starten Sie den ESXi-Host neu.
- Eine aktualisierte vCenter Server Appliance-Instanz behält nicht alle sekundären Netzwerke (NICs) der Quellinstanz bei.
Wenn bei einem Haupt-Upgrade die Quellinstanz der vCenter Server Appliance mit mehreren sekundären Netzwerken außer der VCHA NIC konfiguriert wird, behält der vCenter Server der Zielinstanz keine sekundären Netzwerke außer der VCHA NIC bei. Wenn die Quellinstanz mit mehreren NICs konfiguriert ist, die Teil von DVS-Portgruppen sind, wird die Konfiguration der NIC während des Upgrades nicht beibehalten. Konfigurationen für vCenter Server Appliance-Instanzen, die Teil der Standard-Portgruppe sind, werden beibehalten.
Problemumgehung: Keine. Konfigurieren Sie das sekundäre Netzwerk manuell in der Zielinstanz der vCenter Server Appliance.
- Nach dem Upgrade oder der Migration eines vCenter Server mit einem externen Platform Services Controller verlieren Benutzer, die sich über Active Directory authentifizieren, den Zugriff auf die soeben aktualisierte vCenter Server-Instanz
Wenn nach dem Upgrade oder der Migration eines vCenter Server mit einem externen Platform Services Controller der soeben aktualisierte vCenter Server nicht einer Active Directory-Domäne beitritt, verlieren Benutzer, die sich mit Active Directory authentifizieren, den Zugriff auf die vCenter Server-Instanz.
Problemumgehung: Stellen Sie sicher, dass die neue vCenter Server-Instanz einer Active Directory Domäne beigetreten ist. Weitere Informationen hierzu finden Sie im Knowledgebase-Artikel: https://kb.vmware.com/s/article/2118543
- Das Migrieren eines vCenter Server für Windows mit einem externen Platform Services Controller und Verwendung einer Oracle-Datenbank schlägt fehl
Wenn in der Tabelle der Oracle-Ereignisse und -Aufgaben Nicht-ASCII-Zeichenfolgen vorhanden sind, kann die Migration beim Exportieren von Ereignis- und Aufgabendaten fehlschlagen. Die folgende Fehlermeldung wird angezeigt: UnicodeDecodeError
Problemumgehung: Keine.
- Nach einem Upgrade des ESXi-Hosts wird bei der Konformitätsprüfung des Hostprofils der Status als nicht konform angezeigt und die Hoststandardisierungsaufgaben schlagen fehl
Der Status „Nicht konform“ bedeutet, dass eine Inkonsistenz zwischen dem Profil und dem Host besteht.
Diese Inkonsistenz kann eintreten, weil ESXi 7.0 keine doppelten Beanspruchungsregeln zulässt, das von Ihnen verwendet Profil jedoch doppelte Regeln enthält. Wenn Sie beispielsweise versuchen, das vom Host vor dem Upgrade von ESXi 6.5 oder ESXi 6.7 auf Version 7.0 extrahierte Hostprofil zu verwenden und das Hostprofil doppelte Beanspruchungsregeln von Systemstandardregeln enthält, treten die möglicherweise Probleme auf.
Problemumgehung:
- Entfernen Sie alle doppelten Beanspruchungsregeln von Systemstandardregeln aus dem Hostprofildokument.
- Überprüfen Sie den Übereinstimmungsstatus.
- Standardisieren Sie den Host.
- Wenn die vorherigen Schritte nicht helfen, starten Sie den Host neu.
- In der vCenter Server-Verwaltungsschnittstelle wird eine Fehlermeldung angezeigt.
Nach der Installation oder dem Upgrade auf vCenter Server 7.0 wird beim Navigieren zum Update-Bereich innerhalb der vCenter Server-Verwaltungsschnittstelle die Fehlermeldung „Überprüfen Sie die URL und versuchen Sie es erneut.“ angezeigt. Die Fehlermeldung verhindert nicht, dass Sie die Funktionen im Update-Bereich verwenden, und Sie können alle verfügbaren Updates anzeigen, bereitstellen und installieren.
Problemumgehung: Keine.
- VMFS-Datenspeicher werden nach dem Entfernen der Festplatte im laufenden Betrieb und dem Hinzufügen zu HPE Gen10-Servern mit SmartPQI Controller im laufenden Betrieb nicht automatisch gemountet
Wenn SATA-Festplatten auf HPE Gen10-Servern mit SmartPQI-Controllern ohne Erweiterung im laufenden Betrieb entfernt und wieder in einem anderen Festplattenschacht desselben Rechners eingefügt werden, oder wenn mehrere Festplatten im laufenden Betrieb entfernt und in einer anderen Reihenfolge wieder hinzugefügt werden, wird der Festplatte manchmal ein neuer lokaler Name zugewiesen. Der VMFS-Datenspeicher auf dieser Festplatte erscheint als Snapshot und wird nicht automatisch wieder gemountet, da sich der Gerätename geändert hat.
Problemumgehung: Keine. Der SmartPQI-Controller unterstützt keine ungeordneten Vorgänge zum Entfernen und Einfügen im laufenden Betrieb.
- ESXi kann aufgrund von Fehlern auf allen aktiven Pfaden E/A-Vorgänge zu NVMeOF-Geräten beenden
Gelegentlich werden aufgrund von Link-Problemen oder dem Controllerstatus für alle aktiven Pfade zum NVMeOF-Gerät E/A-Fehler registriert. Wenn sich der Status eines der Pfade in „Ausgefallen“ ändert, wählt das High Performance Plug-In (HPP) möglicherweise keinen anderen Pfad aus, wenn eine hohe Anzahl von Fehlern angezeigt wird. Dies führt dazu, dass der E/A fehlschlägt.
Problemumgehung: Deaktivieren Sie die Konfigurationsoption /Misc/HppManageDegradedPaths, um den E/A zu entsperren.
- Die VOMA-Überprüfung der auf NVMe basierenden VMFS-Datenspeichern schlägt fehl
Die VOMA-Überprüfung wird für NVMe basierende VMFS-Datenspeicher nicht unterstützt und schlägt mit folgendem Fehler fehl:
ERROR: Failed to reserve device. Function not implemented
Beispiel:
# voma -m vmfs -f check -d /vmfs/devices/disks/: <partition#>
Running VMFS Checker version 2.1 in check mode
Initializing LVM metadata, Basic Checks will be done
Checking for filesystem activity
Performing filesystem liveness check..|Scanning for VMFS-6 host activity (4096 bytes/HB, 1024 HBs).
ERROR: Failed to reserve device. Function not implemented
Aborting VMFS volume check
VOMA failed to check device : General Error
Problemumgehung: Keine. Wenn Sie die VMFS-Metadaten analysieren möchten, erfassen Sie sie mithilfe der Option -l und geben Sie sie an den VMware Kundensupport weiter. Der Befehl zum Erfassen des Dump lautet:
voma -l -f dump -d /vmfs/devices/disks/:<partition#>
- Bei Verwendung der API zum Neukonfigurieren von VMs kann das Anhängen einer verschlüsselten First Class Disk an eine verschlüsselte virtuelle Maschine fehlschlagen
Wenn eine FCD und eine virtuelle Maschine mit unterschiedlichen Verschlüsselungsschlüsseln verschlüsselt sind, schlägt das Anhängen der verschlüsselten FCD an die verschlüsselte VM mit der vm.Reconfigure-API möglicherweise mit der folgenden Fehlermeldung fehl:
Festplatte kann nicht entschlüsselt werden. Ungültiger Schlüssel oder ungültiges Kennwort
Problemumgehung: Verwenden Sie die attachDisk-API anstelle der vm.Reconfigure-API, um eine verschlüsselte FCD an eine verschlüsselte VM anzuhängen.
- Der ESXi-Host reagiert möglicherweise nicht mehr, wenn eine nicht übergeordnete Erweiterung seines übergreifenden VMFS-Datenspeichers in einen Status des dauerhaften Geräteausfalls (PDL) wechselt
Dieses Problem tritt nicht auf, wenn eine nicht übergeordnete Erweiterung des übergreifenden VMFS-Datenspeichers zusammen mit der übergeordneten Erweiterung fehlschlägt. In diesem Fällen kann auf den gesamten Datenspeicher nicht mehr zugegriffen werden, sodass keine E/A-Vorgänge mehr zulässig sind.
Im Gegensatz dazu scheint das Taktsignal des Datenspeichers normal zu sein, wenn nur eine nicht übergeordnete Erweiterung fehlschlägt, aber die übergeordnete Erweiterung erreichbar bleibt. Die E/A-Vorgänge zwischen dem Host und dem Datenspeicher werden fortgesetzt. Allerdings schlagen alle E/A-Vorgänge, die von der fehlgeschlagenen nicht übergeordneten Erweiterung abhängen, ebenfalls fehl. Andere E/A-Transaktionen können sich während des Wartens auf das Lösen von E/A-Vorgängen anhäufen und dazu führen, dass der Host nicht mehr reagiert.
Problemumgehung: Beheben Sie die PDL-Bedingung für die nicht übergeordnete Erweiterung, um dieses Problem zu beheben.
- Der virtuelle NVMe-Controller ist der Standard-Festplattencontroller für Windows 10-Gastbetriebssysteme
Der virtuelle NVMe-Controller ist der Standard-Festplattencontroller für die folgenden Gastbetriebssysteme bei der Verwendung der Hardwareversion 15 oder höher:
Windows 10
Windows Server 2016
Windows Server 2019
Einige Funktionen sind möglicherweise nicht verfügbar, wenn ein virtueller NVMe-Controller verwendet wird. Weitere Informationen finden Sie unter https://kb.vmware.com/s/article/2147714
Hinweis: Einige Clients verwenden die vorherige Standardeinstellung von LSI Logic SAS. Hierzu gehören der ESXi Host Client und PowerCLI.
Problemumgehung: Wenn Sie Funktionen benötigen, die für Virtual NVMe nicht verfügbar sind, wechseln Sie zu VMware Paravirtual SCSI (PVSCSI) oder LSI Logic SAS. Weitere Informationen zur Verwendung von VMware Paravirtual SCSI (PVSCSI) finden Sie unter https://kb.vmware.com/s/article/1010398
- Nach einem Upgrade des ESXi-Hosts auf vSphere 7.0 kann das Vorhandensein doppelter Core-Beanspruchungsregeln zu unerwartetem Verhalten führen
Beanspruchungsregeln legen fest, welches Multipathing-Plug-In (NMP, HPP usw.) Pfade zu einem bestimmten Speichergerät besitzt. ESXi 7.0 unterstützt keine doppelten Beanspruchungsregeln. Der ESXi 7.0-Host warnt Sie jedoch nicht, wenn Sie doppelte Regeln zu den vorhandenen Beanspruchungsregeln hinzufügen, die über ein Upgrade von einer Legacy-Version übernommen wurden. Als Folge der Verwendung von doppelten Regeln werden Speichergeräte möglicherweise durch unbeabsichtigte Plug-Ins beansprucht, was zu unerwarteten Ergebnissen führen kann.
Problemumgehung: Verwenden Sie keine doppelten Core-Beanspruchungsregeln. Bevor Sie eine neue Beanspruchungsregel hinzufügen, löschen Sie alle vorhandenen entsprechenden Beanspruchungsregeln.
- Eine CNS-Abfrage mit festgelegtem Konformitätsstatusfilter kann ungewöhnlich viel Zeit in Anspruch nehmen
Mit der CNS QueryVolume API können Sie Informationen zu den CNS-Volumes abrufen, wie z. B. den Datenträgerstatus und den Konformitätsstatus. Wenn Sie den Konformitätsstatus einzelner Volumes prüfen, werden die Ergebnisse schnell abgerufen. Wenn Sie jedoch die CNS QueryVolume API aufrufen, um den Konformitätsstatus von Dutzenden oder Hunderten Volumes zu prüfen, wird die Abfrage möglicherweise langsam ausgeführt.
Problemumgehung: Vermeiden Sie die Verwendung von umfangreichen Abfragen. Wenn Sie den Konformitätsstatus abrufen müssen, fragen Sie jeweils ein Volume ab oder begrenzen Sie die Anzahl der Volumes in der Abfrage-API auf 20 oder weniger. Vermeiden Sie bei der Verwendung der Abfrage die Ausführung anderer CNS-Vorgänge, um eine optimale Leistung zu erhalten.
- Ein VMFS-Datenspeicher, der von einem NVMe over Fabrics-Namespace oder -Gerät unterstützt wird, kann nach der Wiederherstellung von einem APD- oder PDL-Fehler dauerhaft unzugänglich werden
Wenn ein VMFS-Datenspeicher auf einem ESXi-Host von einem NVMe over Fabrics-Namespace oder -Gerät unterstützt wird, kann der Datenspeicher im Falle eines Fehler vom Typ „keine Pfade verfügbar (APD)“ oder „dauerhafter Geräteausfall (PDL)“ auch nach der Wiederherstellung unzugänglich sein. Sie können weder vom ESXi-Host noch vom vCenter Server-System auf den Datenspeicher zugreifen.
Problemumgehung: Führen Sie eine erneute Prüfung auf Host- oder Clusterebene durch, um diesen Zustand zu beheben. Weitere Informationen finden Sie unter Durchführen einer erneuten Speicherprüfung.
- Gelöschte CNS-Volumes werden möglicherweise vorübergehend als in der CNS-Benutzeroberfläche vorhanden angezeigt
Nachdem Sie eine FCD-Festplatte gelöscht haben, die ein CNS-Volume unterstützt, wird das Volume möglicherweise weiterhin in der CNS-Benutzeroberfläche als vorhanden angezeigt. Versuche, das Volume zu löschen, schlagen jedoch fehl. Es wird möglicherweise eine Fehlermeldung ähnlich der folgenden angezeigt:
Das Objekt oder Element, auf das Bezug genommen wurde, konnte nicht gefunden werden.
Problemumgehung: Bei der nächsten vollständigen Synchronisierung wird die Inkonsistenz behoben, und die CNS-Benutzeroberfläche wird ordnungsgemäß aktualisiert.
- Versuche, mehrere CNS-Volumes an denselben Pod anzuhängen, können gelegentlich mit einem Fehler fehlschlagen
Wenn Sie mehrere Volumes gleichzeitig an denselben Pod anhängen, kann der Anhängevorgang gelegentlich denselben Controller-Steckplatz auswählen. Dies führt dazu, dass nur einer der Vorgänge erfolgreich ausgeführt wird, während andere Volume-Einbindungen fehlschlagen.
Problemumgehung: Nachdem Kubernetes den fehlgeschlagenen Vorgang erneut versucht, wird der Vorgang erfolgreich ausgeführt, wenn ein Controller-Steckplatz auf der Knoten-VM verfügbar ist.
- Während ein CNS-Vorgang fehlschlägt, wird der Aufgabenstatus im vSphere Client unter bestimmten Umständen als erfolgreich angezeigt
Dies kann auftreten, wenn Sie beispielsweise eine nicht konforme Speicherrichtlinie verwenden, um ein CNS-Volume zu erstellen. Der Vorgang schlägt fehl, während der vSphere Client den Aufgabenstatus als erfolgreich anzeigt.
Problemumgehung: Wenn der Aufgabenstatus im vSphere Client als erfolgreich angezeigt wird, garantiert dies nicht, dass der CNS-Vorgang erfolgreich war. Um sicherzustellen, dass der Vorgang erfolgreich war, überprüfen Sie dessen Ergebnisse.
- Ein nicht erfolgreicher Löschvorgang für einen dauerhaften CNS-Datenträger führt möglicherweise dazu, dass der Datenträger als nicht gelöscht im vSphere-Datenspeicher verbleibt
Dieses Problem kann auftreten, wenn die CNS-Delete-API versucht, einen dauerhaften Datenträger zu löschen, der noch an einen Pod angehängt ist. Wenn Sie beispielsweise den Kubernetes-Namespace löschen, in dem der Pod ausgeführt wird. Infolgedessen wird der Datenträger aus CNS gelöscht, und der CNS-Abfragevorgang gibt den Datenträger nicht zurück. Allerdings befindet sich der Datenträger weiterhin im Datenspeicher und kann nicht über die wiederholten CNS-Delete-API-Vorgänge gelöscht werden.
Problemumgehung: Keine.
- Reduzierter Durchsatz bei der Netzwerkleistung auf Intel 82599/X540/X550-Netzwerkkarten
Die neue Funktion für Warteschlangenpaare, die dem ixgben-Treiber hinzugefügt wurde, um die Netzwerkleistung auf Intel-Netzwerkkarten der Serien 82599EB/X540/X550 zu verbessern, kann den Durchsatz unter einigen Arbeitslasten in vSphere 7.0 im Vergleich zu vSphere 6.7 verringern.
Problemumgehung: Um dieselbe Netzwerkleistung wie in vSphere 6.7 zu erreichen, können Sie das Warteschlangenpaar mit einem Modulparameter deaktivieren. Um das Warteschlangenpaar zu deaktivieren, führen Sie den folgenden Befehl aus:
# esxcli system module parameters set -p "QPair=0,0,0,0..." -m ixgben
Führen Sie nach dem Ausführen des Befehls einen Neustart aus.
- Mindestens ein E/A-Gerät generiert keine Interrupts, wenn die AMD IOMMU verwendet wird
Wenn die E/A-Geräte auf Ihrem ESXi-Host mehr als insgesamt 512 verschiedene Interrupt-Quellen bereitstellen, wird einigen Quellen fälschlicherweise ein Interrupt Remapping Table Entry (IRTE)-Index in der AMD IOMMU zugewiesen, der größer als der Maximalwert ist. Interrupts von einer solchen Quelle gehen verloren. Das entsprechende E/A-Gerät verhält sich also so, als ob Interrupts deaktiviert wären.
Problemumgehung: Verwenden Sie den ESXCLI-Befehl esxcli system settings kernel set -s iovDisableIR -v true, um den AMD IOMMU Interrupt-Remapper zu deaktivieren. Starten Sie den ESXi-Host neu, damit der Befehl wirksam wird.
- Wenn Sie automatische Aushandlung auf einem Netzwerkadapter festlegen, schlägt das Gerät möglicherweise fehl
Wenn Sie in bestimmten Umgebungen die Verbindungsgeschwindigkeit mithilfe des Befehls esxcli network nic set -a -n vmmicx auf automatische Aushandlung für Netzwerkadapter festlegen, schlagen die Geräte möglicherweise fehl und beim Neustart werden die Verbindungen nicht wiederhergestellt. Das Problem betrifft insbesondere eine Kombination aus bestimmten Netzwerkadaptern des Typs Intel X710/X722, einem SFP+-Modul und einem physischen Switch, bei denen eine ausgehandelte Geschwindigkeit bzw. ein Duplexszenario nicht unterstützt wird.
Problemumgehung: Stellen Sie sicher, dass Sie ein SFP+-Modul der Marke Intel verwenden. Alternativ können Sie ein DAC-Kabel (Direct Attach Copper) verwenden.
- Im 1x100G-Portmodus konfigurierte Netzwerkadapter vom Typ Solarflare x2542 und x2541 erreichen einen Durchsatz von bis zu 70 GBit/s in einer vSphere-Umgebung.
vSphere 7.0 Update 2 unterstützt Netzwerkadapter vom Typ Solarflare x2542 und x2541, die im 1x100G-Portmodus konfiguriert sind. Unter Umständen kommt es bei den Geräten jedoch zu einer Hardwarebeschränkung, wodurch der tatsächliche Durchsatz in einer vSphere-Umgebung bis zu 70 GBit/s beträgt.
Problemumgehung: Keine
- VLAN-Datenverkehr kann nach dem Zurücksetzen einer Netzwerkkarte fehlschlagen
Eine Netzwerkkarte mit der PCI-Geräte-ID 8086:1537 kann nach dem Zurücksetzen möglicherweise keine VLAN-gekennzeichneten Pakete mehr senden und empfangen, z. B. mit dem Befehl vsish -e set /net/pNics/vmnic0/reset 1.
Problemumgehung: Vermeiden Sie das Zurücksetzen der Netzwerkkarte. Wenn Sie bereits mit dem Problem konfrontiert sind, verwenden Sie die folgenden Befehle zum Wiederherstellen der VLAN-Funktion, z. B. bei vmnic0:
# esxcli network nic software set --tagging=1 -n vmnic0
# esxcli network nic software set --tagging=0 -n vmnic0
- Jede Änderung der NetQueue-Balancer-Einstellungen führt dazu, dass NetQueue nach dem Neustart eines ESXi-Hosts deaktiviert wird
Jede Änderung in den Einstellungen des NetQueue-Balancers mithilfe des Befehls esxcli/localcli network nic queue loadbalancer set -n <nicname>--<lb_setting> führt dazu, dass NetQueue (standardmäßig aktiviert) nach dem Neustart eines ESXi-Hosts deaktiviert wird.
Problemumgehung: Nach einer Änderung in den Einstellungen des NetQueue-Balancers und dem Neustart des Hosts verwenden Sie den Befehl configstorecli config current get -c esx -g network -k nics, um ConfigStore-Daten abzurufen und sicherzustellen, dass /esx/network/nics/net_queue/load_balancer/enable erwartungsgemäß funktioniert.
Nach dem Ausführen des Befehls wird eine Ausgabe ähnlich der folgenden angezeigt:
{
"mac": "02:00:0e:6d:14:3e",
"name": "vmnic1",
"net_queue": {
"load_balancer": {
"dynamic_pool": true,
"enable": true
}
},
"virtual_mac": "00:50:56:5a:21:11"
}
Bei nicht erwartungsgemäßer Ausgabe, wie z. B. "load_balancer": "enable": false", führen Sie folgenden Befehl aus:
esxcli/localcli network nic queue loadbalancer state set -n <nicname> -e true
- Paravirtuelle RDMA-Netzwerkadapter (PVRDMA) bieten keine Unterstützung für NSX-Netzwerkrichtlinien
Wenn Sie einen verteilten virtuellen NSX-Port für die Verwendung im PVRDMA-Datenverkehr konfigurieren, entspricht der RDMA-Protokolldatenverkehr über die PVRDMA-Netzwerkadapter nicht den NSX-Netzwerkrichtlinien.
Problemumgehung: Konfigurieren Sie keine verteilten virtuellen NSX-Ports für die Verwendung im PVRDMA-Datenverkehr.
- Die Wiederherstellung von einem konvergierten vSphere Distributed Switch (VDS) auf NSX-T VDS wird in vSphere 7.0 Update 3 nicht unterstützt
Eine Wiederherstellung von einem konvergierten VDS, der sowohl vSphere 7- als auch NSX-T 3-Datenverkehr auf demselben VDS unterstützt, auf einen N-VDS für NSX-T-Datenverkehr wird in vSphere 7.0 Update 3 nicht unterstützt.
Problemumgehung: Keine
- Wenn Sie den Parameter des „nmlx5“-Netzwerktreibermoduls nicht festlegen, schlagen die Netzwerkkonnektivität oder ESXi-Hosts möglicherweise fehl
Wenn Sie den Modulparameter supported_num_ports für den nmlx5_core-Treiber auf einem ESXi-Host mit mehreren Netzwerkadaptern der Versionen Mellanox ConnectX-4, Mellanox ConnectX-5 und Mellanox ConnectX-6 nicht festlegen, weist der Treiber möglicherweise nicht genügend Arbeitsspeicher für den Betrieb aller NIC-Ports für den Host zu. Dies kann dazu führen, dass ein Netzwerkverlust, ein ESXi-Hostfehler mit violettem Diagnosebildschirm oder beides auftritt.
Problemumgehung: Legen Sie den Wert des Moduls supported_num_ports im Netzwerktreiber nmlx5_core auf die Gesamtanzahl der Mellanox ConnectX-4-, Mellanox ConnectX-5- und Mellanox ConnectX-6-Netzwerkadapterports auf dem ESXi-Host fest.
- Bei virtuellen Maschinen mit hohem Durchsatz kann es zu einer Verschlechterung der Netzwerkleistung kommen, wenn Network I/O Control (NetIOC) aktiviert ist
Bei virtuellen Maschinen, die einen hohen Netzwerkdurchsatz erfordern, kann es beim Upgrade von vSphere 6.7 auf vSphere 7.0 mit aktiviertem NetIOC zu einer Verschlechterung des Durchsatzes kommen.
Problemumgehung: Passen Sie die Einstellung ethernetx.ctxPerDev an, um mehrere Worlds zu aktivieren.
- IPv6-Datenverkehr fließt nicht durch VMkernel-Ports, die IPsec verwenden
Wenn Sie VMkernel-Ports von einer Portgruppe zu einer anderen migrieren, fließt der IPv6-Datenverkehr nicht durch VMkernel-Ports, die IPsec verwenden.
Problemumgehung: Entfernen Sie die IPsec Security Association (SA) vom betroffenen Server und wenden Sie die SA dann erneut an. Informationen zum Festlegen und Entfernen einer IPsec SA finden Sie im Dokument vSphere-Sicherheit.
- Höhere ESX-Netzwerkleistung mit einem Teil der CPU-Auslastung
Die ESX-Netzwerkleistung kann mit einem Teil der CPU-Auslastung zunehmen.
Problemumgehung: Entfernen Sie die Netzwerkschnittstelle und fügen Sie sie mit nur 1 rx Übergabewarteschlange hinzu. Beispiel:
esxcli network ip interface remove --interface-name=vmk1
esxcli network ip interface add --interface-name=vmk1 --num-rxqueue=1
- Eine VM verliert nach Hinzufügen oder Entfernen im laufenden Betrieb oder Storage vMotion möglicherweise Ethernet-Datenverkehr
Eine VM empfängt nach Hinzufügen oder Entfernen im laufenden Betrieb oder Storage vMotion möglicherweise keinen Ethernet-Datenverkehr. Dieses Problem betrifft VMs, bei denen für den Uplink der virtuellen Netzwerkkarte SR-IOV aktiviert ist. Die virtuelle Netzwerkkarte PVRDMA weist dieses Problem auf, wenn für den Uplink des virtuellen Netzwerks eine Mellanox RDMA-fähige Netzwerkkarte und RDMA-Namespaces konfiguriert sind.
Problemumgehung: Sie können die betroffenen Ethernet-Netzwerkkarten der VM im laufenden Betrieb entfernen und wieder hinzufügen, um den Datenverkehr wiederherzustellen. Auf den Linux-Gastbetriebssystemen kann das Problem eventuell auch durch einen Neustart des Netzwerks gelöst werden. Wenn diese Problemumgehungen nicht funktionieren, können Sie die VM neu starten, um die Netzwerkkonnektivität wiederherzustellen.
- Die Änderung der IP-Adresse für eine mit statischer IP-Adresse bereitgestellte VCSA erfordert, dass Sie die DNS-Datensätze im Voraus erstellen
Mit der Einführung von DDNS funktioniert das Aktualisieren von DNS nur für VCSA, die mit einem mit DHCP konfigurierten Netzwerk bereitgestellt wurden. Beim Ändern der IP-Adresse von vCenter Server über VAMI wird der folgende Fehler angezeigt:
Die angegebene IP-Adresse wird nicht in den angegebenen Hostnamen aufgelöst.
Problemumgehung: Es gibt zwei mögliche Problemumgehungen.
- Erstellen Sie einen zusätzlichen DNS-Eintrag mit demselben FQDN und der gewünschten IP-Adresse. Melden Sie sich bei der VAMI an und befolgen Sie die Schritte zum Ändern der IP-Adresse.
- Melden Sie sich mithilfe von SSH bei der VCSA an. Führen Sie das folgende Skript aus:
./opt/vmware/share/vami/vami_config_net
Verwenden Sie die Option 6, um die IP-Adresse von eth0 zu ändern. Führen Sie nach der Änderung das folgende Skript aus:
./opt/likewise/bin/lw-update-dns
Starten Sie alle Dienste auf der VCSA neu, um die Informationen zur IP-Adresse auf dem DNS-Server zu aktualisieren.
- Es kann einige Sekunden dauern, bis die verteilte virtuelle Portgruppe von NSX (NSX DVPG) nach dem Löschen des entsprechenden logischen Switches in NSX Manager entfernt wird.
Bei zunehmender Anzahl logischer Switches kann es länger dauern, bis die NSX DVPG in vCenter Server entfernt wird, nachdem der entsprechende logische Switch in NSX Manager gelöscht wurde. In einer Umgebung mit 12000 logischen Switches dauert es ungefähr 10 Sekunden, bis eine NSX DVPG aus vCenter Server gelöscht wird.
Problemumgehung: Keine.
- Für hostd ist nicht genügend Arbeitsspeicher vorhanden und es schlägt fehl, wenn eine große Anzahl von verteilten virtuellen NSX-Portgruppen erstellt wird.
In vSphere 7.0 verbrauchen verteilte virtuelle NSX-Portgruppen wesentlich größere Mengen an Arbeitsspeicher als opake Netzwerke. Aus diesem Grund können verteilte virtuelle NSX-Portgruppen mit derselben Menge an Arbeitsspeicher nicht dieselbe Skalierung wie ein opakes Netzwerk unterstützen.
Problemumgehung: Um die Verwendung von verteilten virtuellen NSX-Portgruppen zu unterstützen, erhöhen Sie die Menge an Arbeitsspeicher in Ihren ESXi-Hosts. Wenn Sie sich vergewissert haben, dass Ihr System über ausreichend Arbeitsspeicher zur Unterstützung Ihrer VMs verfügt, können Sie den Arbeitsspeicher von hostd mit dem folgenden Befehl direkt erhöhen.
localcli --plugin-dir /usr/lib/vmware/esxcli/int/ sched group setmemconfig --group-path host/vim/vmvisor/hostd --units mb --min 2048 --max 2048
Beachten Sie, dass dadurch für hostd Arbeitsspeicher verwendet wird, der normalerweise für die VMs Ihrer Umgebung reserviert ist. Dies kann eine Reduzierung der Anzahl der VMs, die Ihr ESXi-Host unterstützen kann, zur Folge haben.
- DRS startet vMotion möglicherweise falsch, wenn die Netzwerkreservierung auf einer VM konfiguriert ist
Wenn die Netzwerkreservierung auf einer VM konfiguriert ist, wird erwartet, dass DRS die VM nur auf einen Host migriert, der die angegebenen Anforderungen erfüllt. Wenn in einem Cluster mit NSX-Transportknoten einige der Transportknoten der Transportzone über NSX-T Virtual Distributed Switch (N-VDS) und andere über vSphere Distributed Switch (VDS) 7.0 beitreten, kann DRS vMotion möglicherweise nicht korrekt starten. Dieses Problem kann in folgenden Fällen auftreten:
- Die VM stellt eine Verbindung zu einem logischen NSX-Switch her, der mit einer Netzwerkreservierung konfiguriert ist.
- Einige Transportknoten treten der Transportzone über N-VDS und andere über VDS 7.0 bei, oder die Transportknoten treten der Transportzone über verschiedene VDS 7.0-Instanzen bei.
Problemumgehung: Stellen Sie sicher, dass alle Transportknoten der Transportzone über N-VDS oder dieselbe VDS 7.0-Instanz beitreten.
- Beim Hinzufügen einer VMkernel-Netzwerkkarte (vmknic) zu einer NSX-Portgruppe meldet vCenter Server einen Fehler ähnlich dem folgenden: „Das Verbinden des VMkernel-Adapters mit einer NSX-Portgruppe auf einem statusfreien Host ist kein unterstützter Vorgang. Verwenden Sie stattdessen die verteilte Portgruppe.“
- Für statusfreie ESXi an einem verteilten virtuellen Switch (DVS) wird die vmknic in einer NSX-Portgruppe blockiert. Sie müssen stattdessen eine verteilte Portgruppe verwenden.
- Für statusorientierte ESXi auf DVS wird die vmknic in NSX-Portgruppen unterstützt, aber bei vSAN kann ein Problem auftreten, wenn die vmknic in einer NSX-Portgruppe verwendet.
Problemumgehung: Verwenden Sie eine verteilte Portgruppe auf demselben DVS.
- Das Aktivieren von SR-IOV über vCenter für QLogic 4x10GE QL41164HFCU CNA schlägt möglicherweise fehl
Wenn Sie zum Dialogfeld Einstellungen bearbeiten für physische Netzwerkadapter navigieren und versuchen, SR-IOV zu aktivieren, schlägt der Vorgang möglicherweise fehl, wenn QLogic 4x10GE QL41164HFCU CNA verwendet wird. Der Versuch, SR-IOV zu aktivieren, kann zu einem Netzwerkausfall des ESXi-Hosts führen.
Problemumgehung: Verwenden Sie den folgenden Befehl auf dem ESXi-Host, um SRI-OV zu aktivieren:
esxcfg-module
- vCenter Server schlägt fehl, wenn die Hosts in einem Cluster, in dem Distributed Resource Scheduler (DRS) verwendet wird, dem NSX-T-Netzwerk über einen anderen Virtual Distributed Switch (VDS) oder eine Kombination aus NSX-T Virtual Distributed Switch (NVDS) und VDS beitreten
Wenn in vSphere 7.0 das NSX-T-Netzwerk auf dem vSphere VDS mit einem DRS-Cluster verwendet wird und die Hosts der NSX-Transportzone nicht über denselben VDS oder NVDS beitreten, kann dies dazu führen, dass vCenter Server fehlschlägt.
Problemumgehung: Sorgen Sie dafür, dass die Hosts in einem DRS-Cluster der NSX-Transportzone über denselben VDS oder NVDS beitreten.
- Sie können kein NSX-T auf einem Cluster aktivieren, der bereits für die Verwaltung von Image-Einrichtung und -Updates auf allen Hosts zusammen aktiviert ist
NSX-T ist nicht mit den Funktionen des vSphere Lifecycle Manager für die Image-Verwaltung kompatibel. Wenn Sie einen Cluster für Image-Einrichtung und -Updates auf allen Hosts im Cluster zusammen aktivieren, können Sie NSX-T auf diesem Cluster nicht aktivieren. Sie können jedoch NSX Edges für diesen Cluster bereitstellen.
Problemumgehung: Verschieben Sie die Hosts in einen neuen Cluster, den Sie mit Baselines verwalten können, und aktivieren Sie NSX-T auf diesem neuen Cluster.
- vSphere Lifecycle Manager und vSAN-Dateidienste können auf einem vSAN-Cluster in vSphere 7.0 nicht gleichzeitig aktiviert werden
Wenn vSphere Lifecycle Manager auf einem Cluster aktiviert ist, können vSAN-Dateidienste nicht auf demselben Cluster aktiviert werden und umgekehrt. Um vSphere Lifecycle Manager auf einem Cluster zu aktivieren, auf dem vSAN-Dateidienste bereits aktiviert sind, deaktivieren Sie zunächst vSAN-Dateidienste und wiederholen Sie den Vorgang. Beachten Sie, dass bei einem Übergang zu einem Cluster, der von einem einzelnen Image verwaltet wird, vSphere Lifecycle Manager auf diesem Cluster nicht deaktiviert werden kann.
Problemumgehung: Keine.
- Wenn ein Hardware-Support-Manager nicht verfügbar ist, ist vSphere High Availability (HA) beeinträchtigt
Wenn ein Hardware-Support-Manager nicht für einen Cluster verfügbar ist, den Sie mit einem einzelnen Image verwalten, in dem ein Add-On für Firmware und Treiber ausgewählt und vSphere HA aktiviert ist, ist die vSphere HA-Funktionalität beeinträchtigt. Es können folgende Fehler auftreten.
- Das Konfigurieren von vSphere HA auf einem Cluster schlägt fehl.
- Fehler beim Konfigurieren des vSphere HA-Agenten auf einem Host:
Beim Anwenden von HA-VIBs auf dem Cluster ist ein Fehler aufgetreten.
- Das Standardisieren von vSphere HA schlägt fehl:
Ein allgemeiner Systemfehler ist aufgetreten: Abrufen der Zuordnung der effektiven Komponenten fehlgeschlagen.
- Deaktivieren von vSphere HA schlägt fehl: Aufgabe Lösung löschen ist fehlgeschlagen.
Ein allgemeiner Systemfehler ist aufgetreten: Hardware-Support-Paket wurde in Depot oder Hardware-Support-Manager nicht gefunden.
Problemumgehung:
- Wenn der Hardware-Support-Manager vorübergehend nicht verfügbar ist, führen Sie die folgenden Schritte aus.
- Verbinden Sie den Hardware-Support-Manager erneut mit vCenter Server.
- Wählen Sie im Menü „Hosts und Cluster“ einen Cluster aus.
- Wählen Sie die Registerkarte „Konfigurieren“ aus.
- Klicken Sie unter „Dienste“ auf „vSphere-Verfügbarkeit“.
- Aktivieren Sie vSphere HA erneut.
- Wenn der Hardware-Support-Manager dauerhaft nicht verfügbar ist, führen Sie die folgenden Schritte aus.
- Entfernen Sie den Hardware-Support-Manager und das Hardware-Support-Paket aus der Image-Spezifikation.
- Aktivieren Sie vSphere HA erneut.
- Wählen Sie im Menü „Hosts und Cluster“ einen Cluster aus.
- Wählen Sie die Registerkarte „Updates“ aus.
- Klicken Sie auf „Bearbeiten“.
- Entfernen Sie das Add-On für Firmware und Treiber und klicken Sie auf „Speichern“.
- Wählen Sie die Registerkarte „Konfigurieren“ aus.
- Klicken Sie unter „Dienste“ auf „vSphere-Verfügbarkeit“.
- Aktivieren Sie vSphere HA erneut.
- I/OFilter wird nach einem Standardisierungsprozess in vSphere Lifecycle Manager nicht aus einem Cluster entfernt
Das Entfernen von I/OFilter aus einem Cluster durch Standardisieren des Clusters in vSphere Lifecycle Manager schlägt mit der folgenden Fehlermeldung fehl: iofilter XXX already exists. Der E/A-Filter bleibt als installiert aufgelistet.
Problemumgehung:
- Rufen Sie die IOFilter-API
UninstallIoFilter_Task aus dem verwalteten Objekt von vCenter Server (IoFilterManager) auf.
- Standardisieren Sie den Cluster in vSphere Lifecycle Manager.
- Rufen Sie die IOFilter-API
ResolveInstallationErrorsOnCluster_Task aus dem verwalteten Objekt von vCenter Server (IoFilterManager) auf, um die Datenbank zu aktualisieren.
- Beim Standardisieren eines für vSphere HA aktivierten Clusters in vSphere Lifecycle Manager führt das Hinzufügen von Hosts zu einem vSphere HA-Fehlerzustand
Das Hinzufügen eines oder mehrerer ESXi-Hosts während eines Standardisierungsprozesses eines Clusters mit aktiviertem vSphere HA führt zu folgender Fehlermeldung: Beim Anwenden von HA-VIBs auf dem Cluster ist ein Fehler aufgetreten.
Problemumgehung: Wenn der Cluster-Standardisierungsvorgang abgeschlossen ist, führen Sie eine der folgenden Aufgaben aus.
- Klicken Sie mit der rechten Maustaste auf den ausgefallenen ESXi-Host und wählen Sie Für vSphere HA neu konfigurieren aus.
- Deaktivieren und Sie vSphere HA für den Cluster und aktivieren Sie es erneut.
- Beim Standardisieren eines für vSphere HA aktivierten Clusters in vSphere Lifecycle Manager verursacht die Deaktivierung und erneute Aktivierung von vSphere HA einen vSphere HA-Fehlerzustand
Das Deaktivieren und erneute Aktivieren von vSphere HA während des Standardisierungsprozesses eines Clusters kann zum Fehlschlagen des Standardisierungsprozesses führen, weil vSphere HA-Integritätsprüfungen melden, dass auf Hosts keine vSphere HA-VIBs installiert sind. Es kann eine Fehlermeldung ähnlich der folgenden angezeigt werden: Fehler beim Festlegen der gewünschten Image-Spezifikation für Cluster.
Problemumgehung: Wenn der Cluster-Standardisierungsvorgang abgeschlossen ist, deaktivieren Sie vSphere HA für den Cluster und aktivieren Sie es erneut.
- Die Prüfung auf empfohlene Images in vSphere Lifecycle Manager hat in großen Clustern eine langsame Leistung
In großen Clustern mit mehr als 16 Hosts kann die Aufgabe zur Empfehlungsgenerierung mehr als eine Stunde dauern oder zu hängen scheinen. Die Fertigstellungszeit für die Empfehlungsaufgabe hängt von der Anzahl der auf jedem Host konfigurierten Geräte und der Anzahl der geeigneten Images aus dem Depot ab, die vSphere Lifecycle Manager verarbeiten muss, bevor ein gültiges empfohlenes Image erhalten wird.
Problemumgehung: Keine.
- Die Prüfung auf Hardwarekompatibilität in vSphere Lifecycle Manager hat in großen Clustern eine langsame Leistung
In großen Clustern mit mehr als 16 Hosts kann es bis zu 30 Minuten dauern, bis die Aufgabe zur Erstellung des Validierungsberichts abgeschlossen ist, oder sie scheint zu hängen. Die Fertigstellungszeit hängt von der Anzahl der auf jedem Host konfigurierten Geräte und der Anzahl der im Cluster konfigurierten Hosts ab.
Problemumgehung: Keine
- Unvollständige Fehlermeldungen in nicht englischen Sprachen werden beim Standardisieren eines Clusters in vSphere Lifecycle Manager angezeigt
In der Benutzeroberfläche von vCenter Server können unvollständige Fehlermeldungen für lokalisierte Sprachen vorkommen. Die Meldungen werden angezeigt, nachdem ein Cluster-Standardisierungsprozess in vSphere Lifecycle Manager fehlgeschlagen ist. So kann z. B. die folgende Fehlermeldung auftreten.
Die Fehlermeldung in englischer Sprache: Virtual machine 'VMC on DELL EMC -FileServer' that runs on cluster 'Cluster-1' reported an issue which prevents entering maintenance mode: Unable to access the virtual machine configuration: Unable to access file[local-0] VMC on Dell EMC - FileServer/VMC on Dell EMC - FileServer.vmx
Die Fehlermeldung in französischer Sprache: La VM « VMC on DELL EMC -FileServer », située sur le cluster « {Cluster-1} », a signalé un problème empêchant le passage en mode de maintenance : Unable to access the virtual machine configuration: Unable to access file[local-0] VMC on Dell EMC - FileServer/VMC on Dell EMC - FileServer.vmx
Problemumgehung: Keine.
- Beim Importieren eines Images ohne Anbieter-Add-On, Komponenten oder Firmware- und Treiber-Add-On in einen Cluster, dessen Image derartige Elemente enthält, werden die Image-Elemente des vorhandenen Images nicht entfernt
Nur das ESXi-Basisimage wird durch das importierte Image ersetzt.
Problemumgehung: Nachdem der Importvorgang abgeschlossen ist, bearbeiten Sie das Image und entfernen Sie ggf. das Anbieter-Add-On, die Komponenten und das Firmware- und Treiber-Add-On.
- Wenn Sie einen Cluster, der Baselines verwendet, in einen Cluster konvertieren, der ein einziges Image verwendet, wird eine Warnung angezeigt, dass vSphere HA-VIBs entfernt werden.
Das Konvertieren eines für vSphere HA aktivierten Clusters, der Baselines verwendet, in einen Cluster, der ein einziges Image verwendet, kann dazu führen, dass eine Warnmeldung zur Entfernung einer vmware-fdm-Komponente angezeigt wird.
Problemumgehung: Diese Meldung kann ignoriert werden. Der Konvertierungsprozess installiert die vmware-fdm-Komponente.
- Wenn vSphere Update Manager für das Herunterladen von Patch-Aktualisierungen über einen Proxy-Server aus dem Internet konfiguriert ist, schlägt nach dem Upgrade auf vSphere 7.0, das Update Manager in vSphere Lifecycle Manager konvertiert, möglicherweise das Herunterladen von Patches aus dem VMware-Patch-Repository fehl
In früheren Versionen von vCenter Server konnten Sie unabhängige Proxy-Einstellungen für vCenter Server und vSphere Update Manager konfigurieren. Nach einem Upgrade auf vSphere 7.0 wird der vSphere Update Manager-Dienst Teil des vSphere Lifecycle Manager-Dienstes. Für den vSphere Lifecycle Manager-Dienst werden die Proxy-Einstellungen über die Einstellungen der vCenter Server Appliance konfiguriert. Wenn Sie Update Manager konfiguriert haben, um Patch-Aktualisierungen über einen Proxy-Server aus dem Internet herunterzuladen, aber die vCenter Server Appliance keine Konfiguration für die Proxy-Einstellungen hatte, kann der vSphere Lifecycle Manager nach einem vCenter Server-Upgrade auf Version 7.0 keine Verbindung zum VMware-Depot her herstellen und keine Patches oder Updates herunterladen.
Problemumgehung: Melden Sie sich bei der vCenter Server Appliance-Verwaltungsschnittstelle https://vcenter-server-appliance-FQDN-or-IP-address:5480 an, um die Proxy-Einstellungen für die vCenter Server Appliance zu konfigurieren, und aktivieren Sie vSphere Lifecycle Manager zur Verwendung des Proxys.
- Der VMkernel fährt möglicherweise virtuelle Maschinen aufgrund eines vCPU-Timer-Problems herunter
In seltenen Fällen geht der VMkernel davon aus, dass eine virtuelle Maschine nicht reagiert, weil sie kein ordnungsgemäßes PCPU-Taktsignal sendet, und fährt die VM herunter. In der Datei vmkernel.log werden Meldungen wie folgende angezeigt:
2021-05-28T21:39:59.895Z cpu68:1001449770)ALERT: Heartbeat: HandleLockup:827: PCPU 8 didn't have a heartbeat for 5 seconds, timeout is 14, 1 IPIs sent; *may* be locked up.
2021-05-28T21:39:59.895Z cpu8:1001449713)WARNING: World: 1001449713-Vm: PanicWork:8430: vmm3:VM_NAME:vcpu-3:Received VMkernel NMI IPI, possible CPU lockup while executing HV VT VM
Das Problem ist auf eine seltene Race-Bedingung in vCPU-Timern zurückzuführen. Da es sich um eine Race-Bedingung pro vCPU handelt, sind größere VMs dem Problem stärker ausgesetzt.
Problemumgehung: Deaktivieren Sie das PCPU-Taktsignal mit dem Befehl vsish -e set /reliability/heartbeat/status 0.
- Beim Anwenden eines Hostprofils mit Version 6.5 auf einen ESXi-Host mit Version 7.0 schlägt die Konformitätsprüfung fehl
Das Anwenden eines Hostprofils mit der Version 6.5 auf einen ESXi-Host mit Version 7.0 führt dazu, dass das Profil der Core-Dump-Datei als nicht konform mit dem Host gemeldet wird.
Problemumgehung: Es gibt zwei mögliche Problemumgehungen.
- Wenn Sie ein Hostprofil mit Version 6.5 erstellen, legen Sie eine erweiterte Konfigurationsoption „VMkernel.Boot.autoCreateDumpFile“ auf dem ESXi-Host als „false“ fest.
- Wenn Sie ein vorhandenes Hostprofil mit Version 6.5 anwenden, fügen Sie eine erweiterte Konfigurationsoption „VMkernel.Boot.autoCreateDumpFile“ zum Hostprofil hinzu, konfigurieren Sie die Option für eine feste Richtlinie und legen Sie den Wert auf „false“ fest.
- Für native Mellanox ConnectX-4- oder ConnectX-5-ESXi-Treiber kann der Durchsatz vermindert sein, wenn die Funktion Dynamic Receive Side Scaling (DYN_RSS) oder Generic RSS (GEN_RSS) aktiviert ist
Native Mellanox ConnectX-4- oder ConnectX-5-ESXi-Treiber weisen möglicherweise weniger als 5 Prozent Durchsatzverringerung auf, wenn DYN_RSS und GEN_RSS aktiviert sind, was normale Arbeitslasten wahrscheinlich nicht beeinträchtigt.
Problemumgehung: Sie können DYN_RSS und GEN_RSS mit den folgenden Befehlen deaktivieren:
# esxcli system module parameters set -m nmlx5_core -p "DYN_RSS=0 GEN_RSS=0"
# reboot
- RDMA-Datenverkehr zwischen zwei VMs auf demselben Host schlägt in einer PVRDMA-Umgebung möglicherweise fehl
In einer vSphere 7.0-Implementierung einer PVRDMA-Umgebung übergeben VMs den Datenverkehr über die HCA für die lokale Kommunikation, sofern eine HCA vorhanden ist. Das Loopback des RDMA-Datenverkehrs funktioniert jedoch auf dem qedrntv-Treiber nicht. Beispielsweise können RDMA-Warteschlangenpaare, die auf VMs ausgeführt werden und unter demselben Uplink-Port konfiguriert sind, nicht miteinander kommunizieren.
In vSphere 6.7 und früher wurde HCA für den lokalen RDMA-Datenverkehr verwendet, wenn SRQ aktiviert war. vSphere 7.0 verwendet HCA-Loopback mit VMs mithilfe von Versionen von PVRDMA, bei denen SRQ mit mindestens HW v14 mit RoCE v2 aktiviert ist.
Die aktuelle Version der Marvell FastLinQ-Adapter-Firmware unterstützt den Loopback-Datenverkehr zwischen QPs desselben PF oder Ports nicht.
Problemumgehung: Die erforderliche Unterstützung wird in dem für vSphere 7.0 zertifizierten, sofort einsatzbereiten Treiber hinzugefügt. Wenn Sie den Inbox-qedrntv-Treiber verwenden, müssen Sie eine 3-Host-Konfiguration verwenden und VMs auf den dritten Host migrieren.
- QP- Einschränkungen für Unreliable Datagramm-Datenverkehr im qedrntv-Treiber
Es gibt Einschränkungen für den Marvell FastLinQ qedrntv RoCE-Treiber und Unreliable Datagram (UD)-Datenverkehr. UD-Anwendungen mit Massendatenverkehr können mit dem qedrntv-Treiber fehlschlagen. Darüber hinaus können UD-QPs nur mit DMA Memory Regions (MR) arbeiten. Physische MRs oder FRMR werden nicht unterstützt. Anwendungen, die versuchen, physische MR oder FRMR zusammen mit UD-QP zu verwenden, können den Datenverkehr bei Verwendung mit dem qedrntv-Treiber nicht weitergeben. Bekannte Beispiele für solche Testanwendungen sind ibv_ud_pingpong und ib_send_bw.
Standardmäßige RoCE- und RoCEv2-Anwendungsbeispiele in einer VMware ESXi-Umgebung wie iSER, NVMe-oF (RoCE) und PVRDMA sind von diesem Problem nicht betroffen. Anwendungsbeispiele für den UD-Datenverkehr sind begrenzt. und dieses Problem wirkt sich auf eine kleine Reihe von Anwendungen aus, die UD-Massendatenverkehr benötigen.
Marvell FastLinQ-Hardware unterstützt die Auslagerung von RDMA UD-Datenverkehr nicht. Um die Anforderung von VMware PVRDMA zur Unterstützung von GSI QP zu erfüllen, wurde dem qedrntv-Treiber eine eingeschränkte Softwareimplementierung der UD QP-Unterstützung hinzugefügt. Das Ziel der Implementierung besteht in der Bereitstellung von Unterstützung für die GSI-Kommunikation des Steuerpfads. Es handelt sich nicht um eine vollständige Implementierung von UD QP zur Unterstützung von Massendatenverkehr und erweiterten Funktionen.
Da die UD-Unterstützung in der Software implementiert wird, hält die Implementierung möglicherweise hohem Datenverkehr nicht stand, und Pakete können verworfen werden. Dies kann zu Fehlern bei UD-Massendatenverkehr führen.
Problemumgehung: Der UD QP-Massendatenverkehr wird mit dem qedrntv-Treiber nicht unterstützt, und es gibt zurzeit keine Problemumgehung. VMware ESXi RDMA (RoCE)-Anwendungsfälle wie iSER, NVMe, RDMA und PVRDMA sind von diesem Problem nicht betroffen.
- Mit QLogic 578xx-Netzwerkkarte ausgestattete Server schlagen möglicherweise fehl, wenn häufig Verbindungen mit iSCSI LUNs hergestellt oder getrennt werden
Wenn Sie häufig innerhalb kurzer Zeit eine iSCSI-Verbindung der QLogic 578xx-Netzwerkkarte herstellen oder trennen, kann der Server aufgrund eines Problems mit dem qfle3-Treiber ausfallen. Dies wird durch einen bekannten Fehler in der Geräte-Firmware verursacht.
Problemumgehung: Keine.
- ESXi kann während des Treiberentlade- oder Controller-Trennvorgangs in einer Broadcom NVMe over FC-Umgebung ausfallen
In einer Broadcom NVMe over FC-Umgebung fällt ESXi möglicherweise während des Treiberentlade- oder Controller-Trennungsvorgangs fehl, und eine Fehlermeldung wie die Folgende wird angezeigt: @BlueScreen: #PF Exception 14 in world 2098707:vmknvmeGener IP 0x4200225021cc addr 0x19
Problemumgehung: Keine.
- ESXi zeigt auf einigen Dell-Servern keine OEM-Firmware-Versionsnummer von i350/X550-Netzwerkkarten an
Der Inbox-ixgben-Treiber erkennt nur die Firmware-Datenversion oder die Signatur für i350-/X550-Netzwerkkarten. Auf einigen Dell-Servern ist die OEM-Firmware-Versionsnummer in die OEM-Paketversion-Region programmiert, und der Inbox-ixgben-Treiber liest diese Information nicht. Es wird nur die 8-stellige Firmware-Signatur angezeigt.
Problemumgehung: Um die OEM-Firmware-Versionsnummer anzuzeigen, installieren Sie die asynchrone ixgben-Treiberversion 1.7.15 oder höher.
- X710- oder XL710-Netzwerkkarten schlagen möglicherweise in ESXi fehl
Wenn Sie bestimmte zerstörerische Vorgänge für X710- oder XL710-Netzwerkkarten initiieren, wie z. B. das Zurücksetzen der Netzwerkkarte oder die Bearbeitung der internen Gerätestruktur des VMkernel, kann die Hardware der Netzwerkkarte Daten aus einem Nichtpaket-Arbeitsspeicher lesen.
Problemumgehung: Setzen Sie die Netzwerkkarte nicht zurück bzw. bearbeiten Sie den internen Gerätezustand des VMkernel nicht.
- NVMe-oF garantiert nach dem Neustart des Systems keinen dauerhaften VMHBA-Namen
NVMe-oF ist eine neue Funktion in vSphere 7.0. Wenn Ihr Server über eine USB-Speicherinstallation verfügt, die vmhba30+ verwendet und auch eine NVMe over RDMA-Konfiguration aufweist, kann sich der VMHBA-Name nach einem Neustart des Systems ändern. Dies liegt daran, dass sich die Zuweisung des VMHBA-Namens für NVMe over RDMA von dem Verfahren für PCIe-Geräte unterscheidet. ESXi garantiert keine Persistenz.
Problemumgehung: Keine.
- Die Sicherung schlägt fehl, wenn die vCenter-Datenbankgröße 300 GB oder mehr beträgt
Wenn die vCenter-Datenbankgröße 300 GB oder mehr beträgt, schlägt die dateibasierte Sicherung mit einer Zeitüberschreitung fehl. Die folgende Fehlermeldung wird angezeigt: Zeitüberschreitung! Der Vorgang konnte nicht innerhalb von 72000 Sekunden abgeschlossen werden
Problemumgehung: Keine.
- Eine Wiederherstellung von vCenter Server 7.0, der von vCenter Server 6.x mit externem Platform Services Controller auf vCenter Server 7.0 aktualisiert wurde, schlägt möglicherweise fehl
Wenn Sie einen vCenter Server 7.0 wiederherstellen, der mit dem externen Platform Services Controller von vCenter Server 6.x auf 7.0 aktualisiert wurde, schlägt die Wiederherstellung möglicherweise fehl und die folgende Fehlermeldung wird angezeigt: Speicherliste der Appliance konnte nicht abgerufen werden
Problemumgehung: Erhöhen Sie in der ersten Phase des Wiederherstellungsvorgangs die Speicherebene des vCenter Server 7.0. Wenn beispielsweise der eingerichtete Speichertyp für den externen Platform Services Controller für vCenter Server 6.7 „small“ ist, wählen Sie für den Wiederherstellungsvorgang den Speichertyp „large“ aus.
- Der Konfigurationsparameter für aktivierte SSL-Protokolle wird während eines Hostprofil-Standardisierungsprozesses nicht konfiguriert
Der Konfigurationsparameter Aktivierte SSL-Zertifikate wird während der Standardisierung des Hostprofils nicht konfiguriert, und nur das Systemstandardprotokoll tlsv1.2 wird aktiviert. Dieses Verhalten wird für ein Hostprofil mit Version 7.0 und früher in einer vCenter Server 7.0-Umgebung beobachtet.
Problemumgehung: Um TLSV 1.0- oder TLSV 1.1-SSL-Protokolle für SFCB zu aktivieren, melden Sie sich über SSH bei einem ESXi-Host an und führen Sie den folgenden ESXCLI-Befehl aus: esxcli system wbem -P <protocol_name>
- Die Sperrmoduseinstellungen können nicht mithilfe von Hostprofilen konfiguriert werden
Der Sperrmodus kann nicht mithilfe eines Sicherheitshostprofils konfiguriert werden und kann nicht gleichzeitig auf mehrere ESXi-Hosts angewendet werden. Sie müssen jeden Host manuell konfigurieren.
Problemumgehung: In vCenter Server 7.0 können Sie den Sperrmodus konfigurieren und die Sperrmodusausnahme-Benutzerliste mithilfe eines Sicherheitshostprofils verwalten.
- Wenn ein Hostprofil auf einen Cluster angewendet wird, fehlen Enhanced vMotion Compatibility (EVC)-Einstellungen auf den ESXi-Hosts
Einige Einstellungen in der VMware-Konfigurationsdatei /etc/vmware/config werden nicht von Hostprofilen verwaltet und werden blockiert, wenn die Konfigurationsdatei geändert wird. Infolgedessen gehen die EVC-Einstellungen verloren, wenn das Hostprofil auf einen Cluster angewendet wird. Dies führt zu einem Verlust von EVC-Funktionen. Beispielsweise können nicht maskierte CPUs für Arbeitslasten offengelegt werden.
Problemumgehung: Konfigurieren Sie die entsprechende EVC-Baseline auf dem Cluster neu, um die EVC-Einstellungen wiederherzustellen.
- Die Verwendung eines Hostprofils, das eine Core-Dump-Partition in vCenter Server 7.0 definiert, führt zu einem Fehler
In vCenter Server 7.0 ist das Konfigurieren und Verwalten einer Core-Dump-Partition in einem Hostprofil nicht verfügbar. Der Versuch, ein Hostprofil anzuwenden, das eine Core-Dump-Partition definiert, führt zu folgendem Fehler: Keine gültige Coredump-Partition gefunden.
Problemumgehung: Keine. In vCenter Server 7.0 werden Hostprofile nur für dateibasierte Core-Dumps unterstützt.
- Wenn Sie den ESXCLI-Befehl ausführen, um das Firewall-Modul zu entladen, schlägt der hostd-Dienst fehl und ESXi-Hosts verlieren die Konnektivität
Wenn Sie die Firewall-Konfiguration in einer Umgebung automatisieren, die mehrere ESXi-Hosts umfasst, und den ESXCLI-Befehl esxcli network firewall unload ausführen, der Filter zerstört und das Firewall-Modul entlädt, schlägt der hostd-Dienst fehl und ESXi-Hosts verlieren die Konnektivität.
Problemumgehung: Das Entladen des Firewall-Moduls wird zu keinem Zeitpunkt empfohlen. Führen Sie die folgenden Schritte aus, wenn Sie das Firewall-Modul entladen müssen:
- Beenden Sie den hostd-Dienst mithilfe des Befehls:
/etc/init.d/hostd stop.
- Entladen Sie das Firewall-Modul mithilfe des Befehls:
esxcli network firewall unload.
- Führen Sie die erforderlichen Vorgänge aus.
- Laden Sie das Firewall-Modul mithilfe des Befehls:
esxcli network firewall load.
- Starten Sie den hostd-Dienst mithilfe des Befehls:
/etc/init.d/hostd start.
- 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.
- Änderungen an den Eigenschaften und Attributen von Geräten und Speicher auf einem ESXi-Host bleiben nach einem Neustart möglicherweise nicht erhalten
Wenn die Geräteerkennungsroutine während eines Neustarts eines ESXi-Hosts eine Zeitüberschreitung aufweist, erhält das Jumpstart-Plug-In möglicherweise nicht alle Konfigurationsänderungen von den Geräten und Speicher von allen registrierten Geräten auf dem Host. Infolgedessen setzt der Prozess die Eigenschaften einiger Geräte oder des Speichers nach dem Neustart möglicherweise auf die Standardwerte zurück.
Problemumgehung: Stellen Sie die Änderungen der Eigenschaften des betroffenen Geräts oder Speichers manuell wieder her.
- Wenn Sie einen Beta-Build von ESXi 7.0 verwenden, schlagen ESXi-Hosts während einiger Lebenszyklusvorgänge möglicherweise mit einem violetten Diagnosebildschirm fehl
Wenn Sie einen Beta-Build von ESXi 7.0 verwenden, schlagen ESXi-Hosts während einiger Lebenszyklusvorgänge wie dem Entladen eines Treibers oder dem Umschalten zwischen dem ENS-Modus und dem nativen Treibermodus möglicherweise mit einem violetten Diagnosebildschirm fehl. Wenn Sie zum Beispiel versuchen, den ENS-Modus zu ändern, wird im Backtrace folgende Fehlermeldung angezeigt: case ENS::INTERRUPT::NoVM_DeviceStateWithGracefulRemove hit BlueScreen: ASSERT bora/vmkernel/main/dlmalloc.c:2733. Dieses Problem tritt speziell bei Beta-Builds auf und hat keinen Einfluss auf Release-Builds wie ESXi 7.0.
Problemumgehung: Update auf ESXi 7.0 GA.
- Sie können aufgrund eines Fehlers, bei dem ein Digest-Vorgang fehlgeschlagen ist, keine Snapshots von virtuellen Maschinen erstellen
Eine seltene Race-Bedingung, bei der während der Aktualisierung der CBRC-Digest-Datei (Content Based Read Cache) ein APD-Status (All-Paths-Down) auftritt, verursacht unter Umständen Inkonsistenzen in der Digest-Datei. 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-Vorgang angezeigt.
Problemumgehung: Schalten Sie die virtuellen Maschinen ein/aus, um eine Neuberechnung der CBRC-Hashes auszulösen und die Inkonsistenzen in der Digest-Datei zu löschen.
- Wenn Sie ein Upgrade Ihrer ESXi-Hosts auf Version 7.0 Update 3 durchführen, Ihr vCenter Server jedoch eine frühere Version aufweist, schlägt der TPM-Nachweis (Trusted Platform Module) der ESXi-Hosts fehl
Wenn Sie ein Upgrade Ihrer ESXi-Hosts auf Version 7.0 Update 3 durchführen, Ihr vCenter Server jedoch eine frühere Version aufweist, und Sie TPM aktivieren, können ESXi-Hosts keinen Nachweis bestehen. In der vSphere Client wird die Warnung „Alarm für TPM-Hostnachweis“ angezeigt. Der mit ESXi 7.0 Update 3 eingeführte ECDSA-Algorithmus (Elliptic Curve Digital Signature Algorithm) verursacht das Problem, wenn vCenter Server nicht Version 7.0 Update 3 aufweist.
Problemumgehung: Führen Sie für Ihren vCenter Server ein Upgrade auf 7.0 Update 3 durch oder bestätigen Sie den Alarm.
- Auf dem Startladebildschirm werden Warnungen zu TPM-Asset-Tags angezeigt
Wenn auf einem TPM-aktivierten ESXi-Host kein Asset-Tag aktiviert ist, werden auf dem Startladebildschirm möglicherweise Leerlaufwarnmeldungen wie die folgende angezeigt:
Fehler beim Ermitteln der Tag-Größe des TPM-Assets: Puffer zu klein
Fehler beim Messen des Asset-Tags in TPM: Puffer zu klein
Problemumgehung: Ignorieren Sie die Warnungen oder legen Sie ein Asset-Tag mit dem Befehl $ esxcli hardware tpm tag set -d fest.
- Der sensord-Daemon kann Hardwarestatus des ESXi-Hosts nicht melden
Ein Logikfehler bei der IPMI-SDR-Validierung kann dazu führen, dass sensord keine Quelle für Stromversorgungsinformationen identifizieren kann. Wenn Sie daher den Befehl vsish -e get /power/hostStats ausführen, wird möglicherweise keine Ausgabe angezeigt.
Problemumgehung: Keine
- Wenn ein ESXi-Host mit einem violetten Diagnosebildschirm fehlschlägt, funktioniert der netdump-Dienst möglicherweise nicht mehr
Wenn ein ESXi-Host mit einem violetten Diagnosebildschirm fehlschlägt, schlägt der netdump-Dienst in seltenen Fällen möglicherweise mit einem Fehler wie NetDump FEHLGESCHLAGEN: Konnte nicht an den Dump-Server mit IP x.x.x.x angehängt werden fehl.
Problemumgehung: Konfigurieren Sie den VMkernel-Core-Dump für die Verwendung des lokalen Speichers.
- Sie sehen VMware Fault Domain Manager(FDM)-Core-Dumps häufig auf mehreren ESXi-Hosts
In einigen Umgebungen überschreitet die Anzahl der Datenspeicher möglicherweise die FDM-Dateideskriptorgrenze. Dies führt zu häufigen Core-Dumps auf mehreren ESXi-Hosts, die auf einen FDM-Fehler hinweisen.
Problemumgehung: Erhöhen Sie den FDM-Dateideskriptorgrenzwert auf 2048. Sie können die Einstellung das.config.fdm.maxFds in den erweiterten vSphere HA-Optionen im vSphere Client verwenden. Weitere Informationen finden Sie unter Erweiterte Optionen festlegen.
- Virtuelle Maschinen in einem vSAN-Cluster mit aktiviertem NSX-T und einem konvergierten vSphere Distributed Switch (CVDS) in einer VLAN-Transportzone können nach einem Ausschalten nicht eingeschaltet werden
Wenn die Festplatte einer sekundären Site zu 95 % voll ist und VMs vor der Simulation eines Ausfalls der sekundären Site ausgeschaltet werden, können einige der virtuellen Maschinen während der Wiederherstellung nicht eingeschaltet werden. Folglich reagieren virtuelle Maschinen nicht mehr. Das Problem tritt unabhängig davon auf, ob die Sitewiederherstellung das Hinzufügen von Festplatten, ESXi-Hosts oder CPU-Kapazität beinhaltet.
Problemumgehung: Wählen Sie die virtuellen Maschinen aus, die nicht eingeschaltet werden, und ändern Sie unter „Einstellungen bearbeiten“ im VM-Kontextmenü das Netzwerk in ein VM-Netzwerk.
- Wenn Sie den Parameter „netq_rss_ens“ des „nmlx5_core“-Treibers ändern, schlagen ESXi-Hosts möglicherweise mit einem violetten Diagnosebildschirm fehl
Wenn Sie versuchen, den Parameter netq_rss_ens zu aktivieren, während Sie einen erweiterten Datenpfad auf dem nmlx5_core-Treiber konfigurieren, schlagen ESXi-Hosts möglicherweise mit einem violetten Diagnosebildschirm fehl. Der Parameter netq_rss_ens, der NetQ RSS aktiviert, ist standardmäßig mit einem Wert von 0 deaktiviert.
Problemumgehung: Behalten Sie den Standardwert für den Modulparameter netq_rss_ens im Treiber nmlx5_core bei.
- Das Upgrade auf ESXi 7.0 Update 3 schlägt möglicherweise aufgrund eines geänderten Namens des i40enu-Inbox-Netzwerktreibers fehl
Ab vSphere 7.0 Update 3 wird der Name des i40enu-Inbox-Netzwerktreibers für ESXi in „i40en“ zurück geändert. Der i40en-Treiber wurde in vSphere 7.0 Update 2 in „i40enu“ umbenannt, aber die Namensänderung wirkte sich auf einige Upgradepfade aus. Beispielsweise schlägt das Rollup-Upgrade von ESXi-Hosts fehl, die Sie mit Baselines und Baselinegruppen von 7.0 Update 2 oder 2a bis 3 verwalten. In den meisten Fällen wird der i40enu-Treiber ohne zusätzliche Schritte auf ESXi 7.0 Update 3 aktualisiert. Wenn das Treiber-Upgrade jedoch fehlschlägt, können Sie keine ESXi-Hosts aktualisieren, die Sie mit Baselines und Baselinegruppen verwalten. Sie können auch kein Host-Seeding und kein einzelnes vSphere Lifecycle Manager-Image zum Verwalten der ESXi-Hosts verwenden. Wenn Sie bereits Änderungen in Bezug auf den i40enu-Treiber und die Geräte in Ihrem System vorgenommen haben, müssen Sie vor dem Upgrade auf ESXi 7.0 Update 3 das i40enu-VIB bzw. die Komponente auf ESXi deinstallieren oder zuerst ein Upgrade von ESXi auf ESXi 7.0 Update 2c durchführen.
Problemumgehung: Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 85982.
- Das Windows-Gastbetriebssystem einer virtuellen Maschine, die mit einem virtuellen NVDIMM kleiner als 16 MB konfiguriert ist, schlägt möglicherweise beim Initialisieren einer neuen Festplatte fehl
Wenn Sie eine Windows-VM mit einem NVDIMM kleiner als 16 MB konfigurieren, schlägt das Gastbetriebssystem beim Initialisieren einer neuen Festplatte entweder mit einem blauen Diagnosebildschirm oder eine Fehlermeldung in einem Popup-Fenster im Bildschirm „Festplattenverwaltung“ fehl. Das Problem, das den blauen Diagnosebildschirm verursacht, tritt bei Windows 10-, Windows Server 2022- und Windows 11 v21H2-Gastbetriebssystemen auf.
Problemumgehung: Vergrößern Sie das virtuelle NVDIMM auf 16 MB oder mehr.
- Wenn Sie einen vSphere Distributed Switch (VDS) vor Version 6.6 verwenden und den LAG-Hash-Algorithmus ändern, schlagen ESXi-Hosts möglicherweise mit einem violetten Diagnosebildschirm fehl
Wenn Sie einen VDS der Version vor 6.6 auf einem System mit vSphere 7.0 Update 1 oder höher verwenden und den LAG-Hash-Algorithmus ändern, z. B. von L3 in L2-Hashes, schlagen ESXi-Hosts möglicherweise mit einem violetten Diagnosebildschirm fehl.
Problemumgehung: Upgrade auf Version 6.6 oder höher.
- HTTP-Anforderungen von bestimmten Bibliotheken an vSphere können abgelehnt werden
Der HTTP-Reverse-Proxy in vSphere 7.0 erzwingt eine strengere Standardkonformität als in früheren Versionen. Dies kann bereits vorhandene Probleme in einigen Bibliotheken von Drittanbietern offenlegen, die von Anwendungen für SOAP-Aufrufe an vSphere verwendet werden.
Wenn Sie vSphere-Anwendungen entwickeln, die solche Bibliotheken verwenden oder Anwendungen einschließen, die sich auf diese Bibliotheken in Ihrem vSphere Stack stützen, treten möglicherweise Verbindungsprobleme auf, wenn diese Bibliotheken HTTP-Anforderungen an VMOMI senden. Beispielsweise können HTTP-Anforderungen, die von vijava-Bibliotheken ausgegeben werden, folgende Form aufweisen:
POST /sdk HTTP/1.1
SOAPAction
Content-Type: text/xml; charset=utf-8
User-Agent: Java/1.8.0_221
Die Syntax in diesem Beispiel verstößt gegen eine Voraussetzung für das HTTP-Protokoll-Kopfzeilenfeld, das einen Doppelpunkt nach einer SOAP-Aktion vorschreibt. Aus diesem Grund wird die Anforderung im laufenden Vorgang abgelehnt.
Problemumgehung: Entwickler, die nicht konforme Bibliotheken in ihren Anwendungen nutzen, können stattdessen eine Bibliothek verwenden, die den HTTP-Standards folgt. Beispielsweise können Entwickler, die die vijava-Bibliothek verwenden, stattdessen die neueste Version der yavijava-Bibliothek verwenden.
- Möglicherweise wird bei Verwendung der Broadcom-Treiber „lsi_msgpt3“, „lsi_msgpt35“ und „lsi_mr3“ eine Dump-Datei ausgegeben
Bei Verwendung der Controller „lsi_msgpt3“, „lsi_msgpt35“ und „lsi_mr3“ besteht ein potenzielles Risiko, dass die Dump-Datei „lsuv2-lsi-drivers-plugin-util-zdump“ ausgegeben wird. Beim Beenden der in diesem Plug-In-Dienstprogramm verwendeten storelib tritt ein Problem auf. Dies wirkt sich nicht auf ESXi-Vorgänge aus. Sie können die Dump-Datei ignorieren.
Problemumgehung: Sie können diese Meldung bedenkenlos ignorieren. Sie können „lsuv2-lsi-drivers-plugin“ mit dem folgenden Befehl entfernen:
esxcli software vib remove -n lsuv2-lsiv2-drivers-plugin
- Nach dem Konfigurieren von SR-IOV eines PCI-Geräts in vCenter, ist möglicherweise kein Neustart erforderlich, aber die Konfiguration, die durch Drittanbietererweiterungen vorgenommen wurden, gehen möglicherweise verloren und erfordern einen Neustart, damit sie erneut angewendet werden.
In ESXi 7.0 wird die SR-IOV-Konfiguration ohne Neustart angewendet und der Gerätetreiber wird erneut geladen. ESXi-Hosts weisen möglicherweise Drittanbietererweiterungen auf, die Gerätekonfigurationen durchführen, die ausgeführt werden müssen, nachdem der Gerätetreiber während des Starts geladen wurde. Für diese Drittanbietererweiterungen ist ein Neustart erforderlich, damit die Gerätekonfiguration erneut angewendet wird.
Problemumgehung: Sie müssen nach dem Konfigurieren von SR-IOV einen Neustart durchführen, damit Gerätekonfigurationen von Drittanbietern angewendet werden.
