ESXi 7.0 Update 1c | 17. Dezember 2020 | ISO-Build 17325551 Überprüfen Sie, ob Erweiterungen und Updates für diese Versionshinweise zur Verfügung stehen.

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

• Neuigkeiten
• Vorherige Versionen von ESXi 7.0
• In dieser Version enthaltene Patches
• Hinweise zu Produktunterstützung
• Behobene Probleme
• Bekannte Probleme

Neuigkeiten

• ESXi 7.0 Update 1c unterstützt vSphere Quick Boot auf folgenden Servern:
  • Cisco Systems Inc:
    • HX240C-M5SD
    • HXAF240C-M5SD
    • UCSC-C240-M5SD
  • Dell Inc:
    • PowerEdge C6420
    • PowerEdge C6525
    • PowerEdge FC640
    • PowerEdge M640
    • PowerEdge MX740c
    • PowerEdge MX840c
    • PowerEdge R540
    • PowerEdge R6515
    • PowerEdge R6525
    • PowerEdge R7515
    • PowerEdge R7525
    • PowerEdge R840
    • PowerEdge R930
    • PowerEdge R940
    • PowerEdge R940xa
  • HPE:
    • ProLiant DL385 Gen10

• ESXi 7.0 Update 1c fügt fünf Statistiken für physische Netzwerkkarten, droppedRx, droppedTx, errorsRx, RxCRCErrors und errorsTx, zur Datei hostd.log in /var/run/log/hostd.log hinzu, damit Sie nicht korrigierte Netzwerkfehler erkennen und die erforderlichen Korrekturmaßnahmen ergreifen können.

• Mit ESXi 7.0 Update 1c können Sie den Parameter --remote-host-max-msg-lenverwenden, um die maximale Länge von Syslog-Meldungen auf bis zu 16 KiB festzulegen, bevor sie aufgeteilt werden müssen. Standardmäßig beachtet der ESXi-Syslog-Daemon (vmsyslogd) strikt die von RFC 3164 festgelegte maximale Meldungslänge von 1 KiB. Längere Meldungen werden in mehrere Teile aufgeteilt. Legen Sie als maximale Meldungslänge die kleinste Länge fest, die von syslog-Empfängern oder -Relays in der syslog-Infrastruktur unterstützt wird.

• Mit ESXi 7.0 Update 1c können Sie die Startoption für das Installationsprogramm systemMediaSize verwenden, um die Größe der Systemspeicherpartitionen auf den Startmedien zu begrenzen. Wenn Ihr System einen geringen Speicherplatzbedarf hat, der nicht die maximale Größe von 138 GB Systemspeicher benötigt, können Sie ihn auf das Minimum von 33 GB begrenzen. Der Parameter systemMediaSize akzeptiert die folgenden Werte:

  Der ausgewählte Wert muss dem Zweck Ihres Systems entsprechen. Beispielsweise muss ein System mit 1 TB Arbeitsspeicher das Minimum von 69 GB für die Systemspeicherung verwenden. Informationen zum Festlegen der Startoption zur Installationszeit, z. B. systemMediaSize=small, finden Sie unter Eingeben von Startoptionen zum Starten eines Installations- oder Upgrade-Skripts. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 81166.

  • Minimum (33 GB, für einzelne Festplatte oder eingebettete Server)
  • Klein (69 GB, für Server mit mindestens 512 GB RAM)
  • Standardwert (138 GB)
  • Maximum (verbrauchen Sie den gesamten verfügbaren Speicherplatz, für Multi-Terabyte-Server)

Vorherige Versionen von ESXi 7.0

Die Funktionen sowie die gelösten und bekannten Probleme von ESXi werden in den entsprechenden Versionshinweisen beschrieben. Versionshinweise zu vorherigen Versionen von ESXi 7.0:

• VMware ESXi 7.0, Patch-Version ESXi 7.0 Update 1b
• VMware ESXi 7.0, Patch-Version ESXi 7.0 Update 1a
• VMware ESXi 7.0, Patch-Version ESXi 7.0 Update 1
• VMware ESXi 7.0, Patch-Version ESXi 7.0b

Informationen zu Internationalisierung, Kompatibilität und Open Source-Komponenten finden Sie in den Versionshinweisen zu VMware vSphere 7.0.

In dieser Version enthaltene Patches

Diese Version von ESXi 7.0 Update 1c stellt die folgenden Patches bereit:

Build-Details

Download-Dateiname:	VMware-ESXi-7.0U1c-17325551-depot.zip
Build:	17325551
Download-Größe:	523,2 MB
md5sum:	d1410e6c741ada23c3570e07b94bd8c7
sha1checksum:	a70defe8353b39f74339b158697ed1a12df6c55d
Neustart des Hosts erforderlich:	Ja
Migration oder Herunterfahren der virtuellen Maschine erforderlich:	Ja

WICHTIG:

• Ab vSphere 7.0 verwendet VMware Komponenten zum Verpacken von VIBs mit Bulletins. Die Bulletins „ESXi“ und esx-update bauen aufeinander auf. Schließen Sie immer beide in eine einzelne ESXi-Host-Patch-Baseline oder das Rollup-Bulletin in die Baseline ein, um Fehler während des Patchens von Hosts zu vermeiden.

• Beim Patchen von ESXi Hosts mithilfe von vSphere Lifecycle Manager von einer Version vor ESXi 7.0 Update 1 wird dringend empfohlen, das-Rollup-Bulletin in der Baseline „Patch“ zu verwenden. Wenn Sie das Rollup-Bulletin nicht verwenden können, stellen Sie sicher, dass alle der folgenden Pakete in der Patch-Baseline enthalten sind. Wenn die folgenden Pakete nicht in der Baseline enthalten sind, schlägt der Updatevorgang fehl:

  • VMware-vmkusb_0.1-1vmw.701.0.0.16850804 oder höher
  • VMware-vmkata_0.1-1vmw.701.0.0.16850804 oder höher
  • VMware-vmkfcoe_1.0.0.2-1vmw.701.0.0.16850804 oder höher
  • VMware-NVMeoF-RDMA_1.0.1.2-1vmw.701.0.0.16850804 oder höher

Komponenten

Komponente	Bulletin-ID	Kategorie	Schweregrad
ESXi	ESXi_7.0.1-0.25.17325551	Fehlerkorrektur	Kritisch
ESXi-Komponente „Installieren/Aktualisieren“	esx-update_7.0.1-0.25.17325551	Fehlerkorrektur	Kritisch
Treiber für VMware ATA-Speichercontroller	VMware-vmkata_0.1-1vmw.701.0.25.17325551	Fehlerkorrektur	Mäßig
Treiber für HPE Smart Array-Steuerung	HPE-nhpsa_70.0051.0.100-2vmw.701.0.25.17325551	Fehlerkorrektur	Mäßig
VMware-USB-Treiber	VMware-vmkusb_0.1-1vmw.701.0.25.17325551	Fehlerkorrektur	Mäßig
Treiber für Microsemi Storage Solution Smart Array-Speichercontroller	Microchip-smartpqi_70.4000.0.100-4vmw.701.0.25.17325551	Fehlerkorrektur	Mäßig
ESXi	ESXi_7.0.1-0.20.17325020	Sicherheit	Kritisch
ESXi-Komponente „Installieren/Aktualisieren“	esx-update_7.0.1-0.20.17325020	Sicherheit	Kritisch
Treiber für VMware ATA-Speichercontroller	VMware-vmkata_0.1-1vmw.701.0.20.17325020	Sicherheit	Wichtig
VMware NVMe over Fabric – RDMA-Treiber	VMware-NVMeoF-RDMA_1.0.1.2-1vmw.701.0.20.17325020	Sicherheit	Wichtig
Nativer Treiber für VMware Software FCoE	VMware-vmkfcoe_1.0.0.2-1vmw.701.0.20.17325020	Sicherheit	Wichtig
VMware-USB-Treiber	VMware-vmkusb_0.1-1vmw.701.0.20.17325020	Sicherheit	Wichtig

Rollup-Bulletin

Dieses Rollup-Bulletin enthält die neuesten VIBs mit allen Fixes nach der ersten Version von ESXi 7.0.

Bulletin-ID	Kategorie	Schweregrad
ESXi70U1c-17325551	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-7.0U1c-17325551-standard

ESXi-7.0U1c-17325551-no-tools

ESXi-7.0U1sc-17325020-standard

ESXi-7.0U1sc-17325020-no-tools

ESXi-Image

Name und Version	Datum der Veröffentlichung	Kategorie	Detail
ESXi70U1c-17325551	17.12.2020	Verbesserung	Image für Sicherheit und Fehlerbehebung
ESXi70U1sc-17325020	17.12.2020	Verbesserung	Image nur für Sicherheit

Informationen zu den einzelnen Komponenten und Bulletins finden Sie auf der Seite Produkt-Patches und im Abschnitt Behobene Probleme.

Patch-Download und -Installation

In vSphere 7.x wird das für die Verwaltung von vSphere Update Manager verwendete Update Manager-Plug-In durch das Lifecycle Manager-Plug-In ersetzt. Verwaltungsvorgänge für vSphere Update Manager stehen weiterhin mit neuen Funktionen für vSphere Lifecycle Manager im Lifecycle Manager-Plug-In zur Verfügung.
Die typische Methode zum Anwenden von Patches auf ESXi 7.x-Hosts besteht in der Verwendung des vSphere Lifecycle Manager. Weitere Informationen finden Sie unter Info zu vSphere Lifecycle Manager und vSphere Lifecycle Manager-Baselines und -Images.
Sie können ESXi-Hosts auch ohne das Lifecycle Manager-Plug-In aktualisieren und stattdessen ein Image-Profil verwenden. Dazu müssen Sie die ZIP-Datei des Patch-Offline-Pakets von der Seite VMware-Download oder der Seite Produkt-Patches manuell herunterladen und den Befehl esxcli software profile update verwenden.
Weitere Informationen finden Sie unter Aktualisieren von Hosts mithilfe von ESXCLI-Befehlen und im Handbuch VMware ESXi-Upgrade.

Hinweise zu Produktunterstützung

VMware Tools 9.10.x und 10.0.x haben das Ende der allgemeinen Unterstützung erreicht. Weitere Informationen finden Sie unter den in der VMware Product Lifecycle Matrix aufgeführten VMware Tools.

Behobene Probleme

Die behobenen Probleme werden in folgende Kategorien unterteilt.

• ESXi_7.0.1-0.25.17325551
• esx-update_7.0.1-0.25.17325551
• VMware-vmkata_0.1-1vmw.701.0.25.17325551
• HPE-nhpsa_70.0051.0.100-2vmw.701.0.25.17325551
• VMware-vmkusb_0.1-1vmw.701.0.25.17325551
• Microchip-smartpqi_70.4000.0.100-4vmw.701.0.25.17325551
• ESXi_7.0.1-0.20.17325020
• esx-update_7.0.1-0.20.17325020
• VMware-vmkata_0.1-1vmw.701.0.20.17325020
• VMware-NVMeoF-RDMA_1.0.1.2-1vmw.701.0.20.17325020
• VMware-vmkfcoe_1.0.0.2-1vmw.701.0.20.17325020
• VMware-vmkusb_0.1-1vmw.701.0.20.17325020
• ESXi-7.0U1c-17325551-standard
• ESXi-7.0U1c-17325551-no-tools
• ESXi-7.0U1sc-17325020-standard
• ESXi-7.0U1sc-17325020-no-tools
• ESXi Image - ESXi70U1c-17325551
• ESXi Image - ESXi7.0U1sc-17325020

ESXi_7.0.1-0.25.17325551

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
Enthaltene VIBs	VMware_bootbank_crx_7.0.1-0.25.17325551 VMware_bootbank_esx-xserver_7.0.1-0.25.17325551 VMware_bootbank_esx-base_7.0.1-0.25.17325551 VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.1-0.25.17325551 VMware_bootbank_native-misc-drivers_7.0.1-0.25.17325551 VMware_bootbank_vsan_7.0.1-0.25.17325551 VMware_bootbank_vsanhealth_7.0.1-0.25.17325551 VMware_bootbank_gc_7.0.1-0.25.17325551 VMware_bootbank_cpu-microcode_7.0.1-0.25.17325551 VMware_bootbank_vdfs_7.0.1-0.25.17325551
Behobene Probleme	2656093, 2652863, 2653874, 2643508, 2644189, 2652344, 2661064, 2667291, 2662512, 2644221, 2662606, 2661153, 2655181, 2657411, 2675442, 2657649, 2662558, 2661818, 2664084, 2625155, 2658647, 2659015, 2654686, 2664278, 2676632, 2647557, 2647557, 2628899, 2663717, 2633194, 2661808, 2670891, 2665031, 2644003, 2664045
CVE-Nummern	Nicht verfügbar

Die Bulletins „ESXi“ und „esx-update“ bauen aufeinander auf. Schließen Sie immer beide in eine einzelne ESXi-Host-Patch-Baseline oder das Rollup-Bulletin in die Baseline ein, um Fehler während des Patchens von Hosts zu vermeiden.

Aktualisiert die VIBs esx-dvfilter-generic-fastpath, vsanhealth, vdfs, vsan, esx-base, crx, native-misc-drivers, esx-xserver, gc und cpu-microcode, um die folgenden Probleme zu beheben:

• PR 2656093: Möglicherweise wird aufgrund eines Neustarts eines physischen Switches ein Verlust der Netzwerkkonnektivität angezeigt

  Der Parameter für die Netzwerk-Teaming-Failbackverzögerung auf ESXi-Hosts, Net.TeamPolicyUpDelay, ist zurzeit auf 10 Minuten festgelegt. In bestimmten Umgebungen kann ein physischer Switch jedoch länger als 10 Minuten benötigen, um nach einem Neustart Daten empfangen oder übertragen zu können. Dies führt möglicherweise zu einem Verlust der Netzwerkkonnektivität.

  Dieses Problem wurde in der vorliegenden Version behoben. Der Fix erhöht den Parameter Net.TeamPolicyUpDelay auf bis zu 30 Minuten. Sie können den Parameter festlegen, indem Sie den ESXi-Host auswählen und zu Konfigurieren > System > Erweiterte Systemeinstellungen > Net.TeamPolicyUpDelay navigieren. Alternativ dazu können Sie den folgenden Befehl verwenden: esxcfg-advcfg -s <value> /Net/TeamPolicyUpDelay.

• PR 2652863: Änderungen bei der Filterkonfiguration der verteilten Firewall (DFW) führen möglicherweise dazu, dass virtuelle Maschinen die Netzwerkkonnektivität verlieren

  Aktivitäten für die Neukonfiguration der DFW-Filter, wie z. B. das Hinzufügen oder Entfernen von Filtern, können dazu führen, dass einige Filter Pakete verlieren. Dies führt dazu, dass virtuelle Maschinen die Netzwerkkonnektivität verlieren, und Sie müssen die vmnic zurücksetzen, die Portgruppe ändern oder die virtuelle Maschine neu starten, um den Datenverkehr wiederherzustellen. In der Ausgabe des Befehls summarize-dvfilter wird state:  IOChain Detaching für den fehlgeschlagenen Filter angezeigt.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2653874: Eine virtuelle Maschine schlägt bei der 3D-Wiedergabe möglicherweise mit einem SIGSEGV-Fehler fehl

  Ein bei einigen Renderingvorgängen überlasteter Puffer führt möglicherweise dazu, dass eine 3D-aktivierte virtuelle Maschine während der Interaktion mit Grafikanwendungen, die 3D-Beschleunigung verwenden, mit einem SIGSEGV-Fehler fehlschlägt.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2643508: Wenn eine virtuelle Maschine während eines Hotplug-Vorgangs neu gestartet oder zurückgesetzt wird, können Protokolle dazu führen, dass der verfügbare Festplattenspeicher voll ist und die Maschine nicht mehr reagiert.

  Wenn eine virtuelle Maschine während eines Hotplug-Vorgangs neu gestartet oder zurückgesetzt wird, füllen Protokolle in der Datei vmware.log der virtuellen Maschine möglicherweise den verfügbaren Festplattenspeicher und führen dazu, dass die virtuelle Maschine nicht mehr reagiert. Die Protokollmeldungen sind identisch, wie z. B.: acpiNotifyQueue: Spurious ACPI event completion, data 0xFFFFFFFF.

  Dieses Problem wurde in der vorliegenden Version behoben. Wenn Sie diesen Patch nicht anwenden können, setzen Sie die virtuelle Maschine nicht zurück und starten Sie sie nicht neu, bevor Hotplug-Vorgänge oder Treiberinstallationen abgeschlossen sind. Falls Sie bereits mit dem Problem konfrontiert sind, schalten Sie die virtuelle Maschine aus und wieder ein.

• PR 2644189: smpboot schlägt bei virtuellen Linux-Maschinen mit aktiviertem Secure Encrypted Virtualization-Encrypted State (SEV-ES) fehl

  Wenn eine virtuelle Linux-Maschine mit mehreren virtuellen CPUs und aktiviertem SEV-ES gestartet wird, sind alle CPUs mit Ausnahme von CPU0 offline. Die verbleibenden CPUs können nicht online geschaltet werden. Der Befehl dmesg gibt einen Fehler wie z. B. smpboot: do_boot_cpu failed(-1) to wakeup CPU#1 aus.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2652344: Wenn Sie in einem Verzeichnis der virtuellen Maschine über .vswp-Auslagerungsdateien verfügen, sehen Sie beim Prüfen aller Dateien im Verzeichnis Fehlermeldungen, die angeben, dass das Gerät oder die Ressource ausgelastet ist

  Wenn Sie in einem Verzeichnis der virtuellen Maschine über .vswp-Auslagerungsdateien verfügen, sehen Sie beim Prüfen aller Dateien im Verzeichnis Fehlermeldungen, die angeben, dass das Gerät oder die Ressource ausgelastet ist. Sie sehen außerdem zusätzlichen E/A-Flow auf vSAN Namespace-Objekten und eine Verlangsamung im hostd-Dienst.
  Dieses Problem tritt auf, wenn Sie versuchen, eine Datei mit .vswp-Erweiterung als Objektdeskriptor zu öffnen. Die Auslagerungsdateien des VMX-Prozesses und der Hauptarbeitsspeicher der virtuellen Maschine haben dieselbe Erweiterung .vswp, aber die Auslagerungsdateien des VMX-Prozesses dürfen nicht als Objektdeskriptoren geöffnet werden.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2661064: Der hostd-Dienst reagiert zeitweise nicht mehr

  In seltenen Fällen kann eine Racebedingung mehrerer Threads, die versuchen, eine Datei zu erstellen und das Verzeichnis im selben Verzeichnis zu entfernen, zu einem Deadlock führen, durch den der hostd-Dienst fehlgeschägt. Der Dienst wird erst nach einem Neustart des ESXi-Hosts wiederhergestellt. In den vmkernel-Protokollen werden Warnungen ähnlich der folgenden angezeigt:

  2020-03-31T05:20:00.509Z cpu12:4528223)ALERT: hostd detected to be non-responsive.

  Ein solcher Deadlock kann auch andere Dienste betreffen, aber das Fenster für die Racebedingung ist klein, und das Problem tritt nicht häufig auf.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2667291: Die Verschlüsselung virtueller Maschinen dauert lange und schlägt am Ende mit einem Fehler fehl

  Die Verschlüsselung virtueller Maschinen kann mehrere Stunden dauern und schlägt am Ende mit dem Fehler Die Datei ist bereits vorhanden in den hostd-Protokollen des hostd-Diensts fehl. Dieses Problem tritt auf, wenn eine verwaiste oder nicht verwendete Datei <vm name="">.nvram in den Konfigurationsdateien der VM vorhanden ist. Wenn die virtuellen Maschinen über einen Eintrag wie z. B. NVRAM = "nvram" in der .vmx-Datei verfügen, wird beim Verschlüsselungsvorgang eine verschlüsselte Datei mit der Dateierweiterung .nvram erstellt, die vom System als Duplikat der vorhandenen verwaisten Datei betrachtet wird.

  Dieses Problem wurde in der vorliegenden Version behoben. Falls Sie bereits mit dem Problem konfrontiert sind, löschen Sie die verwaiste Datei <vm name="">.nvram vor der Verschlüsselung manuell.

• PR 2662512: vSAN-Hostfehler beim Deaktivieren des großen Client-Caches

  Wenn vSAN versucht, einen Arbeitsspeichercache von mindestens 256 GB zu deaktivieren, führt der Vorgang möglicherweise zu einem ESXi-Hostfehler mit einem violetten Diagnosebildschirm.

  Dieses Problem wurde in der vorliegenden Version behoben. 

• PR 2644221: Wenn Sie LiveCoreDump als Option zum Erfassen von Systemprotokollen auf einem ESXi-Host aktivieren, reagiert der Host möglicherweise nicht mehr

  Wenn Sie LiveCoreDump als Option zum Erfassen von Systemprotokollen auf einem ESXi-Host aktivieren, reagiert der Host möglicherweise nicht mehr. Es wird ein Fehler wie #PF Exception 14 in world 2125468 auf einem violetten Diagnosebildschirm angezeigt.

  Dieses Problem wurde in der vorliegenden Version behoben. 

• PR 2662606: Nach dem Upgrade der Firmware von HPE Gen10-Servern sehen Sie Zustandsalarme für die Sensoreinheit ID 44

  Nach dem Upgrade der Firmwareversion auf HPE Gen10-Servern werden möglicherweise Zustandsalarme für die Sensoren ALOM_Link_P2 und NIC_Link_02P2 des E/A-Moduls 2 im Zusammenhang mit der Sensoreinheit ID 44.x angezeigt. Die Alarme weisen nicht auf ein tatsächliches Integritätsproblem hin, und Sie können Sie unabhängig von der Firmwareversion ignorieren.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2661153: Wenn Sie RC4 deaktivieren, schlägt die Active Directory-Benutzerauthentifizierung auf ESXi-Hosts möglicherweise fehl.

  Wenn Sie RC4 in Ihrer Active Directory-Konfiguration deaktivieren, schlägt die Benutzerauthentifizierung bei ESXi-Hosts möglicherweise mit einem Fehler beim Authentifizieren des Benutzers fehl.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2655181: Virtuelle Maschinen auf dem NFS 4.1-Datenspeicher reagieren möglicherweise nicht mehr, wenn ein Failover oder Failback des NFS-Servers durchgeführt wurde

  Wenn eine Zurückgewinnungsanforderung während eines Failover- oder Failback-Vorgangs des NFS-Servers wiederholt wird, schlägt die offene Zurückgewinnung fehl und bewirkt, dass virtuelle Maschinen auf NFS 4.1-Datenspeichern nicht mehr reagieren.

  Dieses Problem wurde in der vorliegenden Version behoben. Der Fix analysiert die Zurückgewinnungsantworten im Detail und erlaubt Versuche nur bei Bedarf.

• PR 2657411: Die Zeit, in der sich der Prozessor im Systemmodus (%SYS) befindet, erhöht sich für bestimmte E/A-Arbeitslasten auf der Festplatte in virtuellen Maschinen.

  Wenn virtuelle Maschinen nach der Migration mithilfe von vSphere vMotion über einen Snaphshot fortgesetzt werden, beobachten Sie möglicherweise beim Fortsetzen der einer angehaltenen virtuellen Maschine oder eines Hotplug-Vorgangs eine Zunahme der gemeldeten %SYS-Zeit für bestimmte E/A-Arbeitslasten auf der Festplatte. Das Problem tritt auf, weil der virtuelle PVSCSI-Speicheradapter möglicherweise aufhört, seine interne Warteschlange dynamisch an die Gast-Arbeitslast anzupassen. Dies führt dazu, dass der Treiber-Overhead bei hoher E/A-Aktivität zunimmt und bei bestimmten E/A-Arbeitslasten auf der Festplatte zu einer geringfügigen Erhöhung der %SYS-Zeit führen kann. Das Problem wirkt sich nicht auf die virtuellen NVMe- und LSI-Geräte aus.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2675442: Java-Anwendungen auf einem AMD-Host in einem Enhanced vMotion Compatibility (EVC)-Cluster können möglicherweise nicht gestartet werden, und es wird als Fehler gemeldet, dass SSE2 nicht unterstützt wird.

  Java-Anwendungen auf einem AMD-Host in einem EVC-Cluster werden möglicherweise nicht gestartet und es wird folgender Fehler gemeldet: Unbekannter x64-Prozessor: SSE2 wird nicht unterstützt. Das Problem tritt auf, weil das CPUID-Feld Familie (Blatt 1, EAX, Bits 11-8) einen falschen Wert aufweist. Infolgedessen können der Suchdienst und andere Java-basierte Dienste auf der vCenter Server Appliance nicht gestartet werden.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2657649: Nach dem Upgrade von HPE-Servern auf HPE Integrated Lights-Out 5 (iLO 5)-Firmwareversion 2.30 werden Arbeitsspeichersensor-Zustandswarnungen angezeigt

  Nach dem Upgrade von HPE-Servern, wie z. B. HPE ProLiant Gen10 und Gen10 Plus, auf iLO 5-Firmwareversion 2.30 werden im vSphere Client Zustandswarnungen für die Arbeitsspeichersensoren angezeigt. Dieses Problem tritt auf, weil das System für die Hardware-Statusüberwachung die Mem_Stat_*-Sensoren nicht entsprechend entschlüsselt, wenn die erste LUN nach dem Upgrade aktiviert wird.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2662558: Wenn eine SD-Karte nicht Lesekapazität 16 unterstützt, sehen Sie zahlreiche Fehler in den Protokollen

  Auf ESXi-Hosts, die ein VID:PID/0bda:0329 Realtek Semiconductor Corp USB 3.0-SD-Kartenlesegerät verwenden, das Lesekapazität 16 nicht unterstützt, werden möglicherweise zahlreiche Fehler in den VMkernel-Protokollen angezeigt, wie z. B.:
  2020-06-30T13:26:06.141Z cpu0:2097243)ScsiDeviceIO: 3449: Cmd(0x459ac1350600) 0x9e, CmdSN 0x2452e from world 0 to dev "mpx.vmhba32:C0:T0:L0" failed H:0x7 D:0x0 P:0x0 Invalid sense data: 0x0 0x6e 0x73.
  und
  2020-06-30T14:23:18.280Z cpu0:2097243)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "mpx.vmhba32:C0:T0:L0" state in doubt; requested fast path state update...

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2661818: Wenn die Namenseigenschaft numerischer Sensoren eine Nicht-UTF8-Zeichenfolge enthält, schlägt der vpxa-Dienst fehl

  Der vpxa-Dienst schlägt fehlt, wenn die Namenseigenschaft numerischer Sensoren eine Nicht-UTF8-Zeichenfolge enthält, und ESXi-Hosts trennen die Verbindung zum vCenter Server-System.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2664084: Der Browser für verwaltete Objekte zeigt möglicherweise einen falschen Status von CPU- und Arbeitsspeichersensoren an

  Aufgrund eines Fehlers bei der Verarbeitung von Sensoreinträgen können memoryStatusInfo- und cpuStatusInfo-Daten auch fälschlicherweise den Status für Nicht-CPU- und Nicht-Arbeitsspeichersensoren enthalten. Dies führt zu einem falschen Status für die CPU- und Arbeitsspeichersensoren im Browser für verwaltete Objekte.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2625155: ESXi-Installation schlägt möglicherweise auf Medien mit unformatierten oder beschädigten Datenspeichern fehl

  Die ESXi-Installation schlägt möglicherweise auf Medien mit Datenspeichern fehl, die nicht mounten können, da eine VMFS-Partition entweder beschädigt, nicht formatiert oder in anderweitigem Systembesitz ist. Das ESXi-Installationsprogramm entfernt während des Upgrades oder der Installation möglicherweise auch VMFS-Partitionen auf angeschlossenen USB-Bootmedien.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2658647: Überwachungsdatensätze, die für die Scratch-Partition konfiguriert sind, gehen beim Upgrade von 6.7 Update 2 und höher auf ESXi 7.x verloren

  Überwachungsdatensätze, die für das Scratch-Partition auf dem Startgerät konfiguriert sind, werden beim Upgrade von 6.7 Update 2 und höher auf ESXi 7.x nicht beibehalten. Die Zertifizierungsanforderungen gemäß der National Information Assurance Partnership (NIAP) für ESXi nach 6.7 Update 2 erfordern es, dass die in /scratch befindlichen Überwachungsdatensätze nach einem Upgrade bestehen bleiben.

  Dieses Problem wurde in der vorliegenden Version behoben. Für frühere ESXi 7.x-Versionen müssen Sie die Überwachungsdatensätze in /scratch vor dem Upgrade auf einem anderen Dateisystem oder einer anderen Partition sichern. 

• PR 2659015: Nach einem Sicherungsvorgang überfluten identische Fehlermeldungen die Datei hostd.log

  Nach einem Sicherungsvorgang kann es passieren, dass identische Fehlermeldungen, wie z. B. Block list: Cannot convert disk path <VMDK-Datei> to real path, skipping, die Datei hostd.log überfluten. Dieses Problem verhindert andere hostd-Dienstprotokolle und kann zu einem vollen Protokollspeicher führen.
  

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2654686: Der vSphere Virtual Volumes-Algorithmus verwendet möglicherweise nicht das erste Konfigurations-vVol, das ein ESXi-Host anfordert

  In einer vSphere HA-Umgebung verwendet der vSphere Virtual Volumes-Algorithmus UUID für die Auswahl, wenn mehrere ESXi-Hosts möglicherweise miteinander konkurrieren, um ein Konfigurations-vVol mit demselben Anzeigenamen gleichzeitig zu erstellen und zu mounten. Allerdings ist das von UUID gewählte Konfigurations-vVol möglicherweise nicht das erste, das der ESXi-Host anfordert, und dies könnte zu Problemen in den Datenspeichern der vSphere Virtual Volumes führen.

  Dieses Problem wurde in der vorliegenden Version behoben. Der vSphere Virtual Volumes-Algorithmus verwendet einen Zeitstempel anstelle einer UUID für die Auswahl, wenn mehrere ESXi-Hosts möglicherweise miteinander konkurrieren, um gleichzeitig ein Konfigurations-vVol mit demselben Anzeigenamen zu erstellen und zu mounten.

• PR 2664278: Im vSphere Client können Sie die Protokollebenenkonfiguration des vpxa-Dienstes nach einem Upgrade Ihres vCenter Server nicht ändern

  Im vSphere Client oder mit der API können Sie die Protokollebenenkonfiguration des vpxa-Dienstes auf einem ESX-Host aufgrund einer fehlenden oder ungültigen Vpx.Vpxa.config.log.level-Option nach einem Upgrade Ihres vCenter Server-Systems möglicherweise nicht ändern. 

  Dieses Problem wurde in der vorliegenden Version behoben. Der vpxa-Dienst legt automatisch einen gültigen Wert für die Option „Vpx.Vpxa.config.log.level“ fest und stellt ihn für den vSphere Client oder einen API-Aufruf bereit.

• PR 2676632: ESXi auf USB- oder FCoE-Geräten kann Startgerätepfade nicht finden

  Wenn ESXi auf einem langsamen Startgerät wie USB oder FCoE installiert ist, kann ESXi möglicherweise keinen Startgerätespeicherpfad erkennen. Infolgedessen werden die Bootbankpartition und andere Partitionen wie/scratch nicht identifiziert und Konfigurationsänderungen werden nicht gespeichert. Beim Starten von ESXi verweisen die symbolischen Verknüpfungen /bootbank und /scratch auf einen temporären Speicherpfad.

  Dieses Problem wurde in der vorliegenden Version behoben. Der Fix funktioniert jedoch für Startgeräte, die ESXi in weniger als 2 Minuten erkennt. In seltenen Fällen, wenn die Startgeräteerkennung länger als 2 Minuten dauert, müssen Sie die Schritte im VMware Knowledgebase-Artikel 2149444 befolgen, um die Startoption devListStabilityCount manuell festzulegen.

• PR 2647557: Der VMware vSphere High Availability-Agent reagiert möglicherweise aufgrund eines Speicherproblems nicht mehr.

  Im Rahmen der Cluster-Imageverwaltung von vSphere Lifecycle Manager kann der Lifecycle Manager-Agent möglicherweise keinen ESXi-Host kontaktieren, um eine Aufgabe wie z. B. die Installation zu starten. Folglich zeigt der vSphere Client einen Fehler an, z. B. Der vSphere HA-Agent ist vom vCenter Server aus nicht erreichbar. Der Fehler tritt auf, wenn die vSphere Lifecycle Manager-Aufgabenstatusdatenbank auf dem ESXi-Host nicht häufig bereinigt wird und der Lifecycle Manager-Agent nicht über genügend Speicher verfügt, um die Größe der Datenbankdatei zu verarbeiten.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2647557: Image-Konformitätsprüfungen für vSphere Lifecycle Manager schlagen möglicherweise mit einem unbekannten Fehler fehl

  Während eines Clusterimage-Verwaltungsvorgangs kann es vorkommen, dass der vSphere Lifecycle Manager den Lifecycle Manager-Agenten auf einem ESXi-Host nicht kontaktiert. Im vSphere Client wird ein Fehler angezeigt, z. B. Unbekannter Fehler beim Aufrufen der Host-API aufgetreten. Der Fehler tritt auf, wenn die vSphere Lifecycle Manager-Aufgabenstatusdatenbank auf dem ESXi-Host nicht häufig bereinigt wird und der Lifecycle Manager-Agent nicht über genügend Speicher verfügt, um die Größe der Datenbankdatei zu verarbeiten.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2628899: Die Aktivierung von vSphere HA schlägt mit einem Konfigurationsfehler fehl

  Im Rahmen der Cluster-Imageverwaltung von vSphere Lifecycle Manager kann der vSphere HA-Agent möglicherweise keinen ESXi-Host konfigurieren. Dies führt dazu, dass im vSphere Client sinngemäß folgende Fehlermeldung angezeigt wird:
  Fehler beim Konfigurieren des vSphere HA-Agenten auf dem Host. Beim Anwenden von HA-VIBs auf dem Cluster ist ein Fehler aufgetreten. 
  Der Fehler tritt auf, weil der Installationsvorgang des vSphere HA-Agenten auf dem ESXi-Host möglicherweise mehr Arbeitsspeicher verbraucht als das zugewiesene Kontingent.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2663717: Im vSphere Client wird die Warnmeldung zum Hardwarezustand mit dem Status „Unbekannt“ angezeigt

  Im vSphere Client wird für einige Sensoren auf ESXi-Hosts eine Warnung zum Hardwarezustand mit dem Status „Unbekannt“ angezeigt.

  Dieses Problem wurde in der vorliegenden Version behoben. Sensoren, die für die Decodierung nicht unterstützt werden, werden ignoriert und sind in Systemzustandsberichten nicht enthalten.

• PR 2633194: Wenn Sie nur das Dialogfeld „NTP-Einstellungen bearbeiten“ öffnen und schließen, schaltet sich die Option „Mit Host starten und beenden“ aus

  Wenn Sie nur das Dialogfeld NTP-Einstellungen bearbeiten öffnen und schließen, schaltet sich die Option Mit Host starten und beenden aus. Der NTP-Dienst wird nicht gestartet, wenn ein ESXi-Host eingeschaltet wird. Im vSphere Client wird der Auswahl entsprechend für die NTP-Dienststartrichtlinie die Option Mit Host starten und beenden angezeigt. Wenn Sie jedoch in der ESX-Shell den Befehl chkconfig –list ausführen, ist der NTP-Dienst deaktiviert.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2670891: Snapshot-Vorgänge für virtuelle Maschinen mit aktiviertem Change Block Tracking (CBT) schlagen fehl

  Wenn Sie einen FCoE-Softwareadapter als Mittel für den Zugriff auf Fibre Channel-Speicher deaktivieren, kann das CBT-Modul möglicherweise nicht geladen werden und ESXi kann möglicherweise kein Startgerät erkennen. Dies führt dazu, dass Snapshot-Vorgänge wie das Erstellen und Konsolidieren von Snapshots fehlschlagen.

  Dieses Problem wurde in der vorliegenden Version behoben.

• PR 2665031: Zeitüberschreitung des vSAN-Integritätsdiensts bei Problemen mit der Internetverbindung oder DNS-Auflösung

  Bei Verbindungsproblemen können vSAN-Statusprüfungen, die eine Verbindung zu VMware erfordern, zu einer Zeitüberschreitung führen. Im vSphere Client wird eine Fehlermeldung ähnlich der folgenden angezeigt:
  Fehler beim Abfragen der vSAN-Integritätsinformationen. Einzelheiten finden Sie in den vSphere Client-Protokollen.
  Dieses Problem kann sich auf Online-Statusprüfungen, HCL-Updates und vSphere Lifecycle Manager-Baseline-Empfehlungen auswirken. Wenn vCenter Server das Problem nicht beheben kann, können vSAN-Statusprüfungen bei der Abfrage von DNS-Einträgen zu einer Zeitüberschreitung führen.

  Dieses Problem wurde in der vorliegenden Version behoben. 

• PR 2644003: vSAN-Host fällt bei der Außerbetriebnahme einer Festplatte aus

  Während der Außerbetriebnahme einer Festplatte zum Entfernen schlägt ein ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm fehl. Backtrace enthält Einträge ähnlich den folgenden:

  2020-09-01T04:22:47.112Z cpu7:2099790)@BlueScreen: Fehlgeschlagen bei bora/modules/vmkernel/lsomcommon/ssdlog/ssdopslog.c:398 -- NICHT ERREICHT
2020-09-01T04:22:47.112Z cpu7:2099790)Code start: 0x418037400000 VMK uptime: 0:00:39:25.026
2020-09-01T04:22:47.112Z cpu7:2099790)0x451a8049b9e0:[0x41803750bb65]PanicvPanicInt@vmkernel#nover+0x439 stack: 0x44a00000001
2020-09-01T04:22:47.112Z cpu7:2099790)0x451a8049ba80:[0x41803750c0a2]Panic_vPanic@vmkernel#nover+0x23 stack: 0x121
2020-09-01T04:22:47.113Z cpu7:2099790)0x451a8049baa0:[0x4180375219c0]vmk_PanicWithModuleID@vmkernel#nover+0x41 stack: 0x451a8049bb00
2020-09-01T04:22:47.113Z cpu7:2099790)0x451a8049bb00:[0x41803874707a]SSDLOG_FreeLogEntry@LSOMCommon#1+0x32b stack: 0x800000
2020-09-01T04:22:47.113Z cpu7:2099790)0x451a8049bb70:[0x4180387ae4d1][email protected]#0.0.0.1+0x2e stack: 0x712d103
2020-09-01T04:22:47.114Z cpu7:2099790)0x451a8049bbe0:[0x4180387dd08d][email protected]#0.0.0.1+0x72 stack: 0x431b19603150
2020-09-01T04:22:47.114Z cpu7:2099790)0x451a8049bcd0:[0x4180387dd2d3][email protected]#0.0.0.1+0x80 stack: 0x4318102ba7a0
2020-09-01T04:22:47.115Z cpu7:2099790)0x451a8049bd00:[0x4180387dabb5][email protected]#0.0.0.1+0x2ce stack: 0x800000
2020-09-01T04:22:47.115Z cpu7:2099790)0x451a8049beb0:[0x4180386de2db][email protected]#0.0.0.1+0x590 stack: 0x43180fe83380
2020-09-01T04:22:47.115Z cpu7:2099790)0x451a8049bf90:[0x4180375291ce]vmkWorldFunc@vmkernel#nover+0x4f stack: 0x4180375291ca
2020-09-01T04:22:47.116Z cpu7:2099790)0x451a8049bfe0:[0x4180377107da]CpuSched_StartWorld@vmkernel#nover+0x77 stack: 0x0

  Dieses Problem wurde in der vorliegenden Version behoben.

esx-update_7.0.1-0.25.17325551

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
Enthaltene VIBs	VMware_bootbank_loadesx_7.0.1-0.25.17325551 VMware_bootbank_esx-update_7.0.1-0.25.17325551
Behobene Probleme	Nicht verfügbar
CVE-Nummern	Nicht verfügbar

Aktualisiert die VIBs loadesx und esx-update.

VMware-vmkata_0.1-1vmw.701.0.25.17325551

Patch-Kategorie	Fehlerkorrektur
Patch-Schweregrad	Mäßig
Hostneustart erforderlich	Ja
Migration oder Herunterfahren der virtuellen Maschine erforderlich	Ja
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Enthaltene VIBs	VMW_bootbank_vmkata_0.1-1vmw.701.0.25.17325551
Behobene Probleme	Nicht verfügbar
CVE-Nummern	Nicht verfügbar

Aktualisiert das VIB vmkata.

HPE-nhpsa_70.0051.0.100-2vmw.701.0.25.17325551

Patch-Kategorie	Fehlerkorrektur
Patch-Schweregrad	Mäßig
Hostneustart erforderlich	Ja
Migration oder Herunterfahren der virtuellen Maschine erforderlich	Ja
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Enthaltene VIBs	VMW_bootbank_nhpsa_70.0051.0.100-2vmw.701.0.25.17325551
Behobene Probleme	2655992
CVE-Nummern	Nicht verfügbar

Aktualisiert das VIB nhpsa zur Behebung des folgenden Problems:

• Update für den nhpsa-Treiber

  Das Plug-In für die Betriebsbereitschaft von Festplatten des nativen ESXi-Treibers für HPE Smart Array-Steuerungen, nhpsa, wurde auf Version 70.0051.0.100 aktualisiert, um mehrere bekannte Probleme zu beheben.

VMware-vmkusb_0.1-1vmw.701.0.25.17325551

Patch-Kategorie	Fehlerkorrektur
Patch-Schweregrad	Mäßig
Hostneustart erforderlich	Ja
Migration oder Herunterfahren der virtuellen Maschine erforderlich	Ja
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Enthaltene VIBs	VMW_bootbank_vmkusb_0.1-1vmw.701.0.25.17325551
Behobene Probleme	Nicht verfügbar
CVE-Nummern	Nicht verfügbar

Aktualisiert das VIB vmkusb.

Microchip-smartpqi_70.4000.0.100-4vmw.701.0.25.17325551

Patch-Kategorie	Fehlerkorrektur
Patch-Schweregrad	Mäßig
Hostneustart erforderlich	Ja
Migration oder Herunterfahren der virtuellen Maschine erforderlich	Ja
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Enthaltene VIBs	VMW_bootbank_smartpqi_70.4000.0.100-4vmw.701.0.25.17325551
Behobene Probleme	2661584
CVE-Nummern	Nicht verfügbar

Aktualisiert das VIB smartpqi zur Behebung des folgenden Problems:

• Update für den smartpqi-Treiber

  Das Plug-In für die Betriebsbereitschaft von Festplatten des nativen ESXi-SCSI-Treibers für Microsemi Smart Family-Steuerungen, smartpqi, wurde auf Version 70.4000.0.100-5 aktualisiert, um mehrere fehlende Geräte-IDs zurückzusetzen.

ESXi_7.0.1-0.20.17325020

Patch-Kategorie	Sicherheit
Patch-Schweregrad	Kritisch
Hostneustart erforderlich	Ja
Migration oder Herunterfahren der virtuellen Maschine erforderlich	Ja
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Enthaltene VIBs	VMware_bootbank_crx_7.0.1-0.20.17325020 VMware_bootbank_esx-xserver_7.0.1-0.20.17325020 VMware_bootbank_esx-base_7.0.1-0.20.17325020 VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.1-0.20.17325020 VMware_bootbank_native-misc-drivers_7.0.1-0.20.17325020 VMware_bootbank_vsan_7.0.1-0.20.17325020 VMware_bootbank_vsanhealth_7.0.1-0.20.17325020 VMware_bootbank_gc_7.0.1-0.20.17325020 VMware_bootbank_cpu-microcode_7.0.1-0.20.17325020 VMware_bootbank_vdfs_7.0.1-0.20.17325020
Behobene Probleme	2661006, 2671485, 2636149
CVE-Nummern	CVE-2020-3999

Die Bulletins „ESXi“ und „esx-update“ bauen aufeinander auf. Schließen Sie immer beide in eine einzelne ESXi-Host-Patch-Baseline oder das Rollup-Bulletin in die Baseline ein, um Fehler während des Patchens von Hosts zu vermeiden.

Aktualisiert die VIBs esx-dvfilter-generic-fastpath, vsanhealth, vdfs, vsan, esx-base, crx, native-misc-drivers, esx-xserver, gc und cpu-microcode, um die folgenden Probleme zu beheben:

• ESXi 7.0 Update 1c behebt eine Denial-of-Service-Schwachstelle aufgrund falscher Eingabevalidierung in GuestInfo-Variablen. Ein böswilliger Akteur mit normalen Benutzerzugriffsrechten auf eine virtuelle Maschine kann zu einem Ausfall des VMX-Prozesses der virtuellen Maschine führen, was zu einer Denial-of-Service-Bedingung führt. Im Projekt "Common Vulnerabilities and Exposures" (CVE) (cve.mitre.org) wurde diesem Problem die Bezeichnung CVE-2020-3999 zugewiesen. Weitere Informationen finden Sie unter VMSA-2020-0029.

• Update für die SQLite-Datenbank

  Die SQLite-Datenbank wurde auf Version 3.33.0 aktualisiert.

• Update der OpenSSL-Bibliothek

  Die userworld-OpenSSL-Bibliothek von ESXi wurde auf die Version openssl-1.0.2w aktualisiert.

• Update von OpenSSH

  Die OpenSSH-Version wurde auf Version 8.3p1 aktualisiert.

• Update des NTP-Daemons (Network Time Protocol)

  Der NTP-Daemon wurde auf Version ntp-4.2.8p15 aktualisiert.

• Update der libcurl-Bibliothek

  Die userworld-libcurl-Bibliothek von ESXi wurde auf Version 7.72.0 aktualisiert.

• Die folgenden VMware Tools-ISO-Images werden mit ESXi 7.0 Update 1c gebündelt:

  • windows.iso: VMware Tools 11.1.5 unterstützt Windows 7 SP1 oder Windows Server 2008 R2 SP1 oder höher.
  • linux.iso: VMware Tools 10.3.22-ISO-Image für das Linux-Betriebssystem mit glibc 2.5 oder höher.

  Die folgenden VMware Tools-ISO-Images stehen zum Download zur Verfügung:

  • VMware Tools 10.0.12:
    • winPreVista.iso: für Windows 2000, Windows XP und Windows 2003.
    • linuxPreGLibc25.iso: für Linux-Betriebssysteme mit einer glibc-Version unter 2.5.
       
  • VMware Tools 11.0.6
    • windows.iso: für Windows Vista (SP2) und Windows Server 2008 Service Pack 2 (SP2).
  • solaris.iso: VMware Tools-Image für Solaris.
  • darwin.iso: VMware Tools-Image für OSX.

  Befolgen Sie die in den folgenden Dokumenten aufgeführten Vorgehensweisen, um VMware Tools für Plattformen, die nicht mit ESXi gebündelt sind, herunterzuladen:

  • Versionshinweise zu VMware Tools 11.1.5
  • Frühere Versionen von VMware Tools
  • Wichtige Informationen zu VMware Tools für Administratoren
  • VMware Tools für Hosts, die mit Auto Deploy bereitgestellt wurden
  • Aktualisieren von VMware Tools

esx-update_7.0.1-0.20.17325020

Patch-Kategorie	Sicherheit
Patch-Schweregrad	Kritisch
Hostneustart erforderlich	Ja
Migration oder Herunterfahren der virtuellen Maschine erforderlich	Ja
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Enthaltene VIBs	VMware_bootbank_esx-update_7.0.1-0.20.17325020 VMware_bootbank_loadesx_7.0.1-0.20.17325020
Behobene Probleme	Nicht verfügbar
CVE-Nummern	Nicht verfügbar

Aktualisiert die VIBs loadesx und esx-update.

VMware-vmkata_0.1-1vmw.701.0.20.17325020

Patch-Kategorie	Sicherheit
Patch-Schweregrad	Wichtig
Hostneustart erforderlich	Ja
Migration oder Herunterfahren der virtuellen Maschine erforderlich	Ja
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Enthaltene VIBs	VMW_bootbank_vmkata_0.1-1vmw.701.0.20.17325020
Behobene Probleme	Nicht verfügbar
CVE-Nummern	Nicht verfügbar

Aktualisiert das VIB vmkata.

VMware-NVMeoF-RDMA_1.0.1.2-1vmw.701.0.20.17325020

Patch-Kategorie	Sicherheit
Patch-Schweregrad	Wichtig
Hostneustart erforderlich	Ja
Migration oder Herunterfahren der virtuellen Maschine erforderlich	Ja
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Enthaltene VIBs	VMW_bootbank_nvmerdma_1.0.1.2-1vmw.701.0.20.17325020
Behobene Probleme	Nicht verfügbar
CVE-Nummern	Nicht verfügbar

Aktualisiert das VIB nvmerdma.

VMware-vmkfcoe_1.0.0.2-1vmw.701.0.20.17325020

Patch-Kategorie	Sicherheit
Patch-Schweregrad	Wichtig
Hostneustart erforderlich	Ja
Migration oder Herunterfahren der virtuellen Maschine erforderlich	Ja
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Enthaltene VIBs	VMW_bootbank_vmkfcoe_1.0.0.2-1vmw.701.0.20.17325020
Behobene Probleme	Nicht verfügbar
CVE-Nummern	Nicht verfügbar

Aktualisiert das VIB vmkfcoe.

VMware-vmkusb_0.1-1vmw.701.0.20.17325020

Patch-Kategorie	Sicherheit
Patch-Schweregrad	Wichtig
Hostneustart erforderlich	Ja
Migration oder Herunterfahren der virtuellen Maschine erforderlich	Ja
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Enthaltene VIBs	VMW_bootbank_vmkusb_0.1-1vmw.701.0.20.17325020
Behobene Probleme	Nicht verfügbar
CVE-Nummern	Nicht verfügbar

Aktualisiert das VIB vmkusb.

ESXi-7.0U1c-17325551-standard

Profilname	ESXi-7.0U1c-17325551-standard
Build	Build-Informationen finden Sie unter In dieser Version enthaltene Patches.
Anbieter	VMware, Inc.
Datum der Veröffentlichung	17. Dezember 2020
Akzeptanzebene	PartnerSupported
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Betroffene VIBs	VMware_bootbank_crx_7.0.1-0.25.17325551 VMware_bootbank_esx-xserver_7.0.1-0.25.17325551 VMware_bootbank_esx-base_7.0.1-0.25.17325551 VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.1-0.25.17325551 VMware_bootbank_native-misc-drivers_7.0.1-0.25.17325551 VMware_bootbank_vsan_7.0.1-0.25.17325551 VMware_bootbank_vsanhealth_7.0.1-0.25.17325551 VMware_bootbank_gc_7.0.1-0.25.17325551 VMware_bootbank_cpu-microcode_7.0.1-0.25.17325551 VMware_bootbank_vdfs_7.0.1-0.25.17325551 VMware_bootbank_loadesx_7.0.1-0.25.17325551 VMware_bootbank_esx-update_7.0.1-0.25.17325551 VMware_bootbank_loadesx_7.0.1-0.25.17325551 VMware_bootbank_esx-update_7.0.1-0.25.17325551 VMW_bootbank_nhpsa_70.0051.0.100-2vmw.701.0.25.17325551 VMW_bootbank_vmkusb_0.1-1vmw.701.0.25.17325551 VMW_bootbank_smartpqi_70.4000.0.100-4vmw.701.0.25.17325551
Behobene Probleme	2656093, 2652863, 2653874, 2643508, 2644189, 2652344, 2661064, 2667291, 2662512, 2644221, 2662606, 2661153, 2655181, 2657411, 2675442, 2657649, 2662558, 2661818, 2664084, 2625155, 2658647, 2659015, 2654686, 2664278, 2676632, 2647557, 2647557, 2628899, 2663717, 2633194, 2661808, 2670891, 2665031, 2644003, 2664045, 2655992, 2661584
Verwandte CVE-Nummern	CVE-2020-3999

• Dieser Patch enthält Updates zur Behebung der folgenden Probleme:

  • Der Parameter für die Netzwerk-Teaming-Failbackverzögerung auf ESXi-Hosts, Net.TeamPolicyUpDelay, ist zurzeit auf 10 Minuten festgelegt. In bestimmten Umgebungen kann ein physischer Switch jedoch länger als 10 Minuten benötigen, um nach einem Neustart Daten empfangen oder übertragen zu können. Dies führt möglicherweise zu einem Verlust der Netzwerkkonnektivität.

  • Aktivitäten für die Neukonfiguration der DFW-Filter, wie z. B. das Hinzufügen oder Entfernen von Filtern, können dazu führen, dass einige Filter Pakete verlieren. Dies führt dazu, dass virtuelle Maschinen die Netzwerkkonnektivität verlieren, und Sie müssen die vmnic zurücksetzen, die Portgruppe ändern oder die virtuelle Maschine neu starten, um den Datenverkehr wiederherzustellen. In der Ausgabe des Befehls summarize-dvfilter wird state:  IOChain Detaching für den fehlgeschlagenen Filter angezeigt.

  • Ein bei einigen Renderingvorgängen überlasteter Puffer führt möglicherweise dazu, dass eine 3D-aktivierte virtuelle Maschine während der Interaktion mit Grafikanwendungen, die 3D-Beschleunigung verwenden, mit einem SIGSEGV-Fehler fehlschlägt.

  • Wenn eine virtuelle Maschine während eines Hotplug-Vorgangs neu gestartet oder zurückgesetzt wird, füllen Protokolle in der Datei vmware.log der virtuellen Maschine möglicherweise den verfügbaren Festplattenspeicher und führen dazu, dass die virtuelle Maschine nicht mehr reagiert. Die Protokollmeldungen sind identisch, wie z. B.: acpiNotifyQueue: Spurious ACPI event completion, data 0xFFFFFFFF.

  • Wenn eine virtuelle Linux-Maschine mit mehreren virtuellen CPUs und aktiviertem SEV-ES gestartet wird, sind alle CPUs mit Ausnahme von CPU0 offline. Die verbleibenden CPUs können nicht online geschaltet werden. Der Befehl dmesg gibt einen Fehler wie z. B. smpboot: do_boot_cpu failed(-1) to wakeup CPU#1 aus.

  • Wenn Sie in einem Verzeichnis der virtuellen Maschine über .vswp-Auslagerungsdateien verfügen, sehen Sie beim Prüfen aller Dateien im Verzeichnis Fehlermeldungen, die angeben, dass das Gerät oder die Ressource ausgelastet ist. Sie sehen außerdem zusätzlichen E/A-Flow auf vSAN Namespace-Objekten und eine Verlangsamung im hostd-Dienst.
    Dieses Problem tritt auf, wenn Sie versuchen, eine Datei mit .vswp-Erweiterung als Objektdeskriptor zu öffnen. Die Auslagerungsdateien des VMX-Prozesses und der Hauptarbeitsspeicher der virtuellen Maschine haben dieselbe Erweiterung .vswp, aber die Auslagerungsdateien des VMX-Prozesses dürfen nicht als Objektdeskriptoren geöffnet werden.

  • In seltenen Fällen kann eine Racebedingung mehrerer Threads, die versuchen, eine Datei zu erstellen und das Verzeichnis im selben Verzeichnis zu entfernen, zu einem Deadlock führen, durch den der hostd-Dienst fehlgeschägt. Der Dienst wird erst nach einem Neustart des ESXi-Hosts wiederhergestellt. In den vmkernel-Protokollen werden Warnungen ähnlich der folgenden angezeigt:

    2020-03-31T05:20:00.509Z cpu12:4528223)ALERT: hostd detected to be non-responsive.

    Ein solcher Deadlock kann auch andere Dienste betreffen, aber das Fenster für die Racebedingung ist klein, und das Problem tritt nicht häufig auf.

  • Die Verschlüsselung virtueller Maschinen kann mehrere Stunden dauern und schlägt am Ende mit dem Fehler Die Datei ist bereits vorhanden in den hostd-Protokollen des hostd-Diensts fehl. Dieses Problem tritt auf, wenn eine verwaiste oder nicht verwendete Datei <vm name="">.nvram in den Konfigurationsdateien der VM vorhanden ist. Wenn die virtuellen Maschinen über einen Eintrag wie z. B. NVRAM = "nvram" in der .vmx-Datei verfügen, wird beim Verschlüsselungsvorgang eine verschlüsselte Datei mit der Dateierweiterung .nvram erstellt, die vom System als Duplikat der vorhandenen verwaisten Datei betrachtet wird.

  • Wenn vSAN versucht, einen Arbeitsspeichercache von mindestens 256 GB zu deaktivieren, führt der Vorgang möglicherweise zu einem ESXi-Hostfehler mit einem violetten Diagnosebildschirm.

  • Wenn Sie LiveCoreDump als Option zum Erfassen von Systemprotokollen auf einem ESXi-Host aktivieren, reagiert der Host möglicherweise nicht mehr. Es wird ein Fehler wie #PF Exception 14 in world 2125468 auf einem violetten Diagnosebildschirm angezeigt.

  • Nach dem Upgrade der Firmwareversion auf HPE Gen10-Servern werden möglicherweise Zustandsalarme für die Sensoren ALOM_Link_P2 und NIC_Link_02P2 des E/A-Moduls 2 im Zusammenhang mit der Sensoreinheit ID 44.x angezeigt. Die Alarme weisen nicht auf ein tatsächliches Integritätsproblem hin, und Sie können Sie unabhängig von der Firmwareversion ignorieren.

  • Wenn Sie RC4 in Ihrer Active Directory-Konfiguration deaktivieren, schlägt die Benutzerauthentifizierung bei ESXi-Hosts möglicherweise mit einem Fehler beim Authentifizieren des Benutzers fehl.

  • Wenn eine Zurückgewinnungsanforderung während eines Failover- oder Failback-Vorgangs des NFS-Servers wiederholt wird, schlägt die offene Zurückgewinnung fehl und bewirkt, dass virtuelle Maschinen auf NFS 4.1-Datenspeichern nicht mehr reagieren.

  • Wenn virtuelle Maschinen nach der Migration mithilfe von vSphere vMotion über einen Snaphshot fortgesetzt werden, beobachten Sie möglicherweise beim Fortsetzen der einer angehaltenen virtuellen Maschine oder eines Hotplug-Vorgangs eine Zunahme der gemeldeten %SYS-Zeit für bestimmte E/A-Arbeitslasten auf der Festplatte. Das Problem tritt auf, weil der virtuelle PVSCSI-Speicheradapter möglicherweise aufhört, seine interne Warteschlange dynamisch an die Gast-Arbeitslast anzupassen. Dies führt dazu, dass der Treiber-Overhead bei hoher E/A-Aktivität zunimmt und bei bestimmten E/A-Arbeitslasten auf der Festplatte zu einer geringfügigen Erhöhung der %SYS-Zeit führen kann. Das Problem wirkt sich nicht auf die virtuellen NVMe- und LSI-Geräte aus.

  • Java-Anwendungen auf einem AMD-Host in einem EVC-Cluster werden möglicherweise nicht gestartet und es wird folgender Fehler gemeldet: Unbekannter x64-Prozessor: SSE2 wird nicht unterstützt. Das Problem tritt auf, weil die CPUID-Feldfamilie (Blatt 1, EAX, Bits 11-8) einen falschen Wert hat. Infolgedessen können der Suchdienst und andere Java-basierte Dienste auf der vCenter Server Appliance nicht gestartet werden.

  • Nach dem Upgrade von HPE-Servern, wie z. B. HPE ProLiant Gen10 und Gen10 Plus, auf iLO 5-Firmwareversion 2.30 werden im vSphere Client Zustandswarnungen für die Arbeitsspeichersensoren angezeigt. Dieses Problem tritt auf, weil das System für die Hardware-Statusüberwachung die Mem_Stat_*-Sensoren nicht entsprechend entschlüsselt, wenn die erste LUN nach dem Upgrade aktiviert wird.

  • Auf ESXi-Hosts, die ein VID:PID/0bda:0329 Realtek Semiconductor Corp USB 3.0-SD-Kartenlesegerät verwenden, das Lesekapazität 16 nicht unterstützt, werden möglicherweise zahlreiche Fehler in den VMkernel-Protokollen angezeigt, wie z. B.:
    2020-06-30T13:26:06.141Z cpu0:2097243)ScsiDeviceIO: 3449: Cmd(0x459ac1350600) 0x9e, CmdSN 0x2452e from world 0 to dev "mpx.vmhba32:C0:T0:L0" failed H:0x7 D:0x0 P:0x0 Invalid sense data: 0x0 0x6e 0x73.
    und
    2020-06-30T14:23:18.280Z cpu0:2097243)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "mpx.vmhba32:C0:T0:L0" state in doubt; requested fast path state update...

  • Der vpxa-Dienst schlägt fehlt, wenn die Namenseigenschaft numerischer Sensoren eine Nicht-UTF8-Zeichenfolge enthält, und ESXi-Hosts trennen die Verbindung zum vCenter Server-System.

  • Aufgrund eines Fehlers bei der Verarbeitung von Sensoreinträgen können memoryStatusInfo- und cpuStatusInfo-Daten auch fälschlicherweise den Status für Nicht-CPU- und Nicht-Arbeitsspeichersensoren enthalten. Dies führt zu einem falschen Status für die CPU- und Arbeitsspeichersensoren im Browser für verwaltete Objekte.

  • Die ESXi-Installation schlägt möglicherweise auf Medien mit Datenspeichern fehl, die nicht mounten können, da eine VMFS-Partition entweder beschädigt, nicht formatiert oder in anderweitigem Systembesitz ist. Das ESXi-Installationsprogramm entfernt während des Upgrades oder der Installation möglicherweise auch VMFS-Partitionen auf angeschlossenen USB-Bootmedien.

  • Überwachungsdatensätze, die für das Scratch-Partition auf dem Startgerät konfiguriert sind, werden beim Upgrade von 6.7 Update 2 und höher auf ESXi 7.x nicht beibehalten. Die Zertifizierungsanforderungen gemäß der National Information Assurance Partnership (NIAP) für ESXi nach 6.7 Update 2 erfordern es, dass die in /scratch befindlichen Überwachungsdatensätze nach einem Upgrade bestehen bleiben.

  • Nach einem Sicherungsvorgang kann es passieren, dass identische Fehlermeldungen, wie z. B. Block list: Cannot convert disk path <VMDK-Datei> to real path, skipping, die Datei hostd.log überfluten. Dieses Problem verhindert andere hostd-Dienstprotokolle und kann zu einem vollen Protokollspeicher führen.

  • In einer vSphere HA-Umgebung verwendet der vSphere Virtual Volumes-Algorithmus UUID für die Auswahl, wenn mehrere ESXi-Hosts möglicherweise miteinander konkurrieren, um ein Konfigurations-vVol mit demselben Anzeigenamen gleichzeitig zu erstellen und zu mounten. Allerdings ist das von UUID gewählte Konfigurations-vVol möglicherweise nicht das erste, das der ESXi-Host anfordert, und dies könnte zu Problemen in den Datenspeichern der vSphere Virtual Volumes führen.

  • Im vSphere Client oder mit der API können Sie die Protokollebenenkonfiguration des vpxa-Dienstes auf einem ESX-Host aufgrund einer fehlenden oder ungültigen Vpx.Vpxa.config.log.level-Option nach einem Upgrade Ihres vCenter Server-Systems möglicherweise nicht ändern. 

  • Wenn ESXi auf einem langsamen Startgerät wie USB oder FCoE installiert ist, kann ESXi möglicherweise keinen Startgerätespeicherpfad erkennen. Infolgedessen werden die Bootbankpartition und andere Partitionen wie /scratch nicht identifiziert und Konfigurationsänderungen werden nicht gespeichert. Beim Starten von ESXi verweisen die symbolischen Verknüpfungen /bootbank und /scratch auf einen temporären Speicherpfad.

  • Im Rahmen der Cluster-Imageverwaltung von vSphere Lifecycle Manager kann der Lifecycle Manager-Agent möglicherweise keinen ESXi-Host kontaktieren, um eine Aufgabe wie z. B. die Installation zu starten. Folglich zeigt der vSphere Client einen Fehler an, z. B. Der vSphere HA-Agent ist vom vCenter Server aus nicht erreichbar. Der Fehler tritt auf, wenn die vSphere Lifecycle Manager-Aufgabenstatusdatenbank auf dem ESXi-Host nicht häufig bereinigt wird und der Lifecycle Manager-Agent nicht über genügend Speicher verfügt, um die Größe der Datenbankdatei zu verarbeiten.

  • Während eines Clusterimage-Verwaltungsvorgangs kann es vorkommen, dass der vSphere Lifecycle Manager den Lifecycle Manager-Agenten auf einem ESXi-Host nicht kontaktiert. Im vSphere Client wird ein Fehler angezeigt, z. B. Unbekannter Fehler beim Aufrufen der Host-API aufgetreten. Der Fehler tritt auf, wenn die vSphere Lifecycle Manager-Aufgabenstatusdatenbank auf dem ESXi-Host nicht häufig bereinigt wird und der Lifecycle Manager-Agent nicht über genügend Speicher verfügt, um die Größe der Datenbankdatei zu verarbeiten.

  • Im Rahmen der Cluster-Imageverwaltung von vSphere Lifecycle Manager kann der vSphere HA-Agent möglicherweise keinen ESXi-Host konfigurieren. Dies führt dazu, dass im vSphere Client sinngemäß folgende Fehlermeldung angezeigt wird:
    Fehler beim Konfigurieren des vSphere HA-Agenten auf dem Host. Beim Anwenden von HA-VIBs auf dem Cluster ist ein Fehler aufgetreten. 
    Der Fehler tritt auf, weil der Installationsvorgang des vSphere HA-Agenten auf dem ESXi-Host möglicherweise mehr Arbeitsspeicher verbraucht als das zugewiesene Kontingent.

  • Im vSphere Client wird für einige Sensoren auf ESXi-Hosts eine Warnung zum Hardwarezustand mit dem Status „Unbekannt“ angezeigt.

  • Wenn Sie nur das Dialogfeld NTP-Einstellungen bearbeiten öffnen und schließen, schaltet sich die Option Mit Host starten und beenden aus. Der NTP-Dienst wird nicht gestartet, wenn ein ESXi-Host eingeschaltet wird. Im vSphere Client wird der Auswahl entsprechend für die NTP-Dienststartrichtlinie die Option Mit Host starten und beenden angezeigt. Wenn Sie jedoch in der ESX-Shell den Befehl chkconfig –list ausführen, ist der NTP-Dienst deaktiviert.

  • Wenn Sie einen FCoE-Softwareadapter als Mittel für den Zugriff auf Fibre Channel-Speicher deaktivieren, kann das CBT-Modul möglicherweise nicht geladen werden und ESXi kann möglicherweise kein Startgerät erkennen. Dies führt dazu, dass Snapshot-Vorgänge wie das Erstellen und Konsolidieren von Snapshots fehlschlagen.

  • Bei Verbindungsproblemen können vSAN-Statusprüfungen, die eine Verbindung zu VMware erfordern, zu einer Zeitüberschreitung führen. Im vSphere Client wird eine Fehlermeldung ähnlich der folgenden angezeigt:
    Fehler beim Abfragen der vSAN-Integritätsinformationen. Einzelheiten finden Sie in den vSphere Client-Protokollen.
    Dieses Problem kann sich auf Online-Statusprüfungen, HCL-Updates und vSphere Lifecycle Manager-Baseline-Empfehlungen auswirken. Wenn vCenter Server das Problem nicht beheben kann, können vSAN-Statusprüfungen bei der Abfrage von DNS-Einträgen zu einer Zeitüberschreitung führen.

  • Während der Außerbetriebnahme einer Festplatte zum Entfernen schlägt ein ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm fehl. Backtrace enthält Einträge ähnlich den folgenden:

    2020-09-01T04:22:47.112Z cpu7:2099790)@BlueScreen: Fehlgeschlagen bei bora/modules/vmkernel/lsomcommon/ssdlog/ssdopslog.c:398 -- NICHT ERREICHT
    2020-09-01T04:22:47.112Z cpu7:2099790)Code start: 0x418037400000 VMK uptime: 0:00:39:25.026
    2020-09-01T04:22:47.112Z cpu7:2099790)0x451a8049b9e0:[0x41803750bb65]PanicvPanicInt@vmkernel#nover+0x439 stack: 0x44a00000001
    2020-09-01T04:22:47.112Z cpu7:2099790)0x451a8049ba80:[0x41803750c0a2]Panic_vPanic@vmkernel#nover+0x23 stack: 0x121
    2020-09-01T04:22:47.113Z cpu7:2099790)0x451a8049baa0:[0x4180375219c0]vmk_PanicWithModuleID@vmkernel#nover+0x41 stack: 0x451a8049bb00
    2020-09-01T04:22:47.113Z cpu7:2099790)0x451a8049bb00:[0x41803874707a]SSDLOG_FreeLogEntry@LSOMCommon#1+0x32b stack: 0x800000
    2020-09-01T04:22:47.113Z cpu7:2099790)0x451a8049bb70:[0x4180387ae4d1][email protected]#0.0.0.1+0x2e stack: 0x712d103
    2020-09-01T04:22:47.114Z cpu7:2099790)0x451a8049bbe0:[0x4180387dd08d][email protected]#0.0.0.1+0x72 stack: 0x431b19603150
    2020-09-01T04:22:47.114Z cpu7:2099790)0x451a8049bcd0:[0x4180387dd2d3][email protected]#0.0.0.1+0x80 stack: 0x4318102ba7a0
    2020-09-01T04:22:47.115Z cpu7:2099790)0x451a8049bd00:[0x4180387dabb5][email protected]#0.0.0.1+0x2ce stack: 0x800000
    2020-09-01T04:22:47.115Z cpu7:2099790)0x451a8049beb0:[0x4180386de2db][email protected]#0.0.0.1+0x590 stack: 0x43180fe83380
    2020-09-01T04:22:47.115Z cpu7:2099790)0x451a8049bf90:[0x4180375291ce]vmkWorldFunc@vmkernel#nover+0x4f stack: 0x4180375291ca
    2020-09-01T04:22:47.116Z cpu7:2099790)0x451a8049bfe0:[0x4180377107da]CpuSched_StartWorld@vmkernel#nover+0x77 stack: 0x0

  • Wenn auf einem NVMe-Gerät mehrere Namespaces konfiguriert sind, kann sich die Unterstützung für sichere vSAN-Festplattenlöschvorgänge je nach der Anzahl der Namespaces dynamisch ändern. Wenn ein neuer Namespace konfiguriert wird, während ein sicherer Löschvorgang ausgeführt wird, z. B. in VxRail oder der Google Cloud Platform, kann das dazu führen, dass die Daten auf dem neu hinzugefügten Namespace gelöscht werden.

  • Das Plug-In für die Betriebsbereitschaft von Festplatten des nativen ESXi-Treibers für HPE Smart Array-Steuerungen, nhpsa, wurde auf Version 70.0051.0.100 aktualisiert, um mehrere bekannte Probleme zu beheben.

  • Das Plug-In für die Betriebsbereitschaft von Festplatten des nativen ESXi-SCSI-Treibers für Microsemi Smart Family-Steuerungen, smartpqi, wurde auf Version 70.4000.0.100-5 aktualisiert, um mehrere fehlende Geräte-IDs zurückzusetzen.

ESXi-7.0U1c-17325551-no-tools

Profilname	ESXi-7.0U1c-17325551-no-tools
Build	Build-Informationen finden Sie unter In dieser Version enthaltene Patches.
Anbieter	VMware, Inc.
Datum der Veröffentlichung	17. Dezember 2020
Akzeptanzebene	PartnerSupported
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Betroffene VIBs	VMware_bootbank_crx_7.0.1-0.25.17325551 VMware_bootbank_esx-xserver_7.0.1-0.25.17325551 VMware_bootbank_esx-base_7.0.1-0.25.17325551 VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.1-0.25.17325551 VMware_bootbank_native-misc-drivers_7.0.1-0.25.17325551 VMware_bootbank_vsan_7.0.1-0.25.17325551 VMware_bootbank_vsanhealth_7.0.1-0.25.17325551 VMware_bootbank_gc_7.0.1-0.25.17325551 VMware_bootbank_cpu-microcode_7.0.1-0.25.17325551 VMware_bootbank_vdfs_7.0.1-0.25.17325551 VMware_bootbank_loadesx_7.0.1-0.25.17325551 VMware_bootbank_esx-update_7.0.1-0.25.17325551 VMware_bootbank_loadesx_7.0.1-0.25.17325551 VMware_bootbank_esx-update_7.0.1-0.25.17325551 VMW_bootbank_nhpsa_70.0051.0.100-2vmw.701.0.25.17325551 VMW_bootbank_vmkusb_0.1-1vmw.701.0.25.17325551 VMW_bootbank_smartpqi_70.4000.0.100-4vmw.701.0.25.17325551
Behobene Probleme	2656093, 2652863, 2653874, 2643508, 2644189, 2652344, 2661064, 2667291, 2662512, 2644221, 2662606, 2661153, 2655181, 2657411, 2675442, 2657649, 2662558, 2661818, 2664084, 2625155, 2658647, 2659015, 2654686, 2664278, 2676632, 2647557, 2647557, 2628899, 2663717, 2633194, 2661808, 2670891, 2665031, 2644003, 2664045, 2655992, 2661584
Verwandte CVE-Nummern	CVE-2020-3999

• Dieser Patch enthält Updates zur Behebung der folgenden Probleme:

  • Der Parameter für die Netzwerk-Teaming-Failbackverzögerung auf ESXi-Hosts, Net.TeamPolicyUpDelay, ist zurzeit auf 10 Minuten festgelegt. In bestimmten Umgebungen kann ein physischer Switch jedoch länger als 10 Minuten benötigen, um nach einem Neustart Daten empfangen oder übertragen zu können. Dies führt möglicherweise zu einem Verlust der Netzwerkkonnektivität.

  • Aktivitäten für die Neukonfiguration der DFW-Filter, wie z. B. das Hinzufügen oder Entfernen von Filtern, können dazu führen, dass einige Filter Pakete verlieren. Dies führt dazu, dass virtuelle Maschinen die Netzwerkkonnektivität verlieren, und Sie müssen die vmnic zurücksetzen, die Portgruppe ändern oder die virtuelle Maschine neu starten, um den Datenverkehr wiederherzustellen. In der Ausgabe des Befehls summarize-dvfilter wird state:  IOChain Detaching für den fehlgeschlagenen Filter angezeigt.

  • Ein bei einigen Renderingvorgängen überlasteter Puffer führt möglicherweise dazu, dass eine 3D-aktivierte virtuelle Maschine während der Interaktion mit Grafikanwendungen, die 3D-Beschleunigung verwenden, mit einem SIGSEGV-Fehler fehlschlägt.

  • Wenn eine virtuelle Maschine während eines Hotplug-Vorgangs neu gestartet oder zurückgesetzt wird, füllen Protokolle in der Datei vmware.log der virtuellen Maschine möglicherweise den verfügbaren Festplattenspeicher und führen dazu, dass die virtuelle Maschine nicht mehr reagiert. Die Protokollmeldungen sind identisch, wie z. B.: acpiNotifyQueue: Spurious ACPI event completion, data 0xFFFFFFFF.

  • Wenn eine virtuelle Linux-Maschine mit mehreren virtuellen CPUs und aktiviertem SEV-ES gestartet wird, sind alle CPUs mit Ausnahme von CPU0 offline. Die verbleibenden CPUs können nicht online geschaltet werden. Der Befehl dmesg gibt einen Fehler wie z. B. smpboot: do_boot_cpu failed(-1) to wakeup CPU#1 aus.

  • Wenn Sie in einem Verzeichnis der virtuellen Maschine über .vswp-Auslagerungsdateien verfügen, sehen Sie beim Prüfen aller Dateien im Verzeichnis Fehlermeldungen, die angeben, dass das Gerät oder die Ressource ausgelastet ist. Sie sehen außerdem zusätzlichen E/A-Flow auf vSAN Namespace-Objekten und eine Verlangsamung im hostd-Dienst.
    Dieses Problem tritt auf, wenn Sie versuchen, eine Datei mit .vswp-Erweiterung als Objektdeskriptor zu öffnen. Die Auslagerungsdateien des VMX-Prozesses und der Hauptarbeitsspeicher der virtuellen Maschine haben dieselbe Erweiterung .vswp, aber die Auslagerungsdateien des VMX-Prozesses dürfen nicht als Objektdeskriptoren geöffnet werden.

  • In seltenen Fällen kann eine Racebedingung mehrerer Threads, die versuchen, eine Datei zu erstellen und das Verzeichnis im selben Verzeichnis zu entfernen, zu einem Deadlock führen, durch den der hostd-Dienst fehlgeschägt. Der Dienst wird erst nach einem Neustart des ESXi-Hosts wiederhergestellt. In den vmkernel-Protokollen werden Warnungen ähnlich der folgenden angezeigt:

    2020-03-31T05:20:00.509Z cpu12:4528223)ALERT: hostd detected to be non-responsive.

    Ein solcher Deadlock kann auch andere Dienste betreffen, aber das Fenster für die Racebedingung ist klein, und das Problem tritt nicht häufig auf.

  • Die Verschlüsselung virtueller Maschinen kann mehrere Stunden dauern und schlägt am Ende mit dem Fehler Die Datei ist bereits vorhanden in den hostd-Protokollen des hostd-Diensts fehl. Dieses Problem tritt auf, wenn eine verwaiste oder nicht verwendete Datei <vm name="">.nvram in den Konfigurationsdateien der VM vorhanden ist. Wenn die virtuellen Maschinen über einen Eintrag wie z. B. NVRAM = "nvram" in der .vmx-Datei verfügen, wird beim Verschlüsselungsvorgang eine verschlüsselte Datei mit der Dateierweiterung .nvram erstellt, die vom System als Duplikat der vorhandenen verwaisten Datei betrachtet wird.

  • Wenn vSAN versucht, einen Arbeitsspeichercache von mindestens 256 GB zu deaktivieren, führt der Vorgang möglicherweise zu einem ESXi-Hostfehler mit einem violetten Diagnosebildschirm.

  • Wenn Sie LiveCoreDump als Option zum Erfassen von Systemprotokollen auf einem ESXi-Host aktivieren, reagiert der Host möglicherweise nicht mehr. Es wird ein Fehler wie #PF Exception 14 in world 2125468 auf einem violetten Diagnosebildschirm angezeigt.

  • Nach dem Upgrade der Firmwareversion auf HPE Gen10-Servern werden möglicherweise Zustandsalarme für die Sensoren ALOM_Link_P2 und NIC_Link_02P2 des E/A-Moduls 2 im Zusammenhang mit der Sensoreinheit ID 44.x angezeigt. Die Alarme weisen nicht auf ein tatsächliches Integritätsproblem hin, und Sie können Sie unabhängig von der Firmwareversion ignorieren.

  • Wenn Sie RC4 in Ihrer Active Directory-Konfiguration deaktivieren, schlägt die Benutzerauthentifizierung bei ESXi-Hosts möglicherweise mit einem Fehler beim Authentifizieren des Benutzers fehl.

  • Wenn eine Zurückgewinnungsanforderung während eines Failover- oder Failback-Vorgangs des NFS-Servers wiederholt wird, schlägt die offene Zurückgewinnung fehl und bewirkt, dass virtuelle Maschinen auf NFS 4.1-Datenspeichern nicht mehr reagieren.

  • Wenn virtuelle Maschinen nach der Migration mithilfe von vSphere vMotion über einen Snaphshot fortgesetzt werden, beobachten Sie möglicherweise beim Fortsetzen der einer angehaltenen virtuellen Maschine oder eines Hotplug-Vorgangs eine Zunahme der gemeldeten %SYS-Zeit für bestimmte E/A-Arbeitslasten auf der Festplatte. Das Problem tritt auf, weil der virtuelle PVSCSI-Speicheradapter möglicherweise aufhört, seine interne Warteschlange dynamisch an die Gast-Arbeitslast anzupassen. Dies führt dazu, dass der Treiber-Overhead bei hoher E/A-Aktivität zunimmt und bei bestimmten E/A-Arbeitslasten auf der Festplatte zu einer geringfügigen Erhöhung der %SYS-Zeit führen kann. Das Problem wirkt sich nicht auf die virtuellen NVMe- und LSI-Geräte aus.

  • Java-Anwendungen auf einem AMD-Host in einem EVC-Cluster werden möglicherweise nicht gestartet und es wird folgender Fehler gemeldet: Unbekannter x64-Prozessor: SSE2 wird nicht unterstützt. Das Problem tritt auf, weil die CPUID-Feldfamilie (Blatt 1, EAX, Bits 11-8) einen falschen Wert hat. Infolgedessen können der Suchdienst und andere Java-basierte Dienste auf der vCenter Server Appliance nicht gestartet werden.

  • Nach dem Upgrade von HPE-Servern, wie z. B. HPE ProLiant Gen10 und Gen10 Plus, auf iLO 5-Firmwareversion 2.30 werden im vSphere Client Zustandswarnungen für die Arbeitsspeichersensoren angezeigt. Dieses Problem tritt auf, weil das System für die Hardware-Statusüberwachung die Mem_Stat_*-Sensoren nicht entsprechend entschlüsselt, wenn die erste LUN nach dem Upgrade aktiviert wird.

  • Auf ESXi-Hosts, die ein VID:PID/0bda:0329 Realtek Semiconductor Corp USB 3.0-SD-Kartenlesegerät verwenden, das Lesekapazität 16 nicht unterstützt, werden möglicherweise zahlreiche Fehler in den VMkernel-Protokollen angezeigt, wie z. B.:
    2020-06-30T13:26:06.141Z cpu0:2097243)ScsiDeviceIO: 3449: Cmd(0x459ac1350600) 0x9e, CmdSN 0x2452e from world 0 to dev "mpx.vmhba32:C0:T0:L0" failed H:0x7 D:0x0 P:0x0 Invalid sense data: 0x0 0x6e 0x73.
    und
    2020-06-30T14:23:18.280Z cpu0:2097243)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "mpx.vmhba32:C0:T0:L0" state in doubt; requested fast path state update...

  • Der vpxa-Dienst schlägt fehlt, wenn die Namenseigenschaft numerischer Sensoren eine Nicht-UTF8-Zeichenfolge enthält, und ESXi-Hosts trennen die Verbindung zum vCenter Server-System.

  • Aufgrund eines Fehlers bei der Verarbeitung von Sensoreinträgen können memoryStatusInfo- und cpuStatusInfo-Daten auch fälschlicherweise den Status für Nicht-CPU- und Nicht-Arbeitsspeichersensoren enthalten. Dies führt zu einem falschen Status für die CPU- und Arbeitsspeichersensoren im Browser für verwaltete Objekte.

  • Die ESXi-Installation schlägt möglicherweise auf Medien mit Datenspeichern fehl, die nicht mounten können, da eine VMFS-Partition entweder beschädigt, nicht formatiert oder in anderweitigem Systembesitz ist. Das ESXi-Installationsprogramm entfernt während des Upgrades oder der Installation möglicherweise auch VMFS-Partitionen auf angeschlossenen USB-Bootmedien.

  • Überwachungsdatensätze, die für das Scratch-Partition auf dem Startgerät konfiguriert sind, werden beim Upgrade von 6.7 Update 2 und höher auf ESXi 7.x nicht beibehalten. Die Zertifizierungsanforderungen gemäß der National Information Assurance Partnership (NIAP) für ESXi nach 6.7 Update 2 erfordern es, dass die in /scratch befindlichen Überwachungsdatensätze nach einem Upgrade bestehen bleiben.

  • Nach einem Sicherungsvorgang kann es passieren, dass identische Fehlermeldungen, wie z. B. Block list: Cannot convert disk path <VMDK-Datei> to real path, skipping, die Datei hostd.log überfluten. Dieses Problem verhindert andere hostd-Dienstprotokolle und kann zu einem vollen Protokollspeicher führen.

  • In einer vSphere HA-Umgebung verwendet der vSphere Virtual Volumes-Algorithmus UUID für die Auswahl, wenn mehrere ESXi-Hosts möglicherweise miteinander konkurrieren, um ein Konfigurations-vVol mit demselben Anzeigenamen gleichzeitig zu erstellen und zu mounten. Allerdings ist das von UUID gewählte Konfigurations-vVol möglicherweise nicht das erste, das der ESXi-Host anfordert, und dies könnte zu Problemen in den Datenspeichern der vSphere Virtual Volumes führen.

  • Im vSphere Client oder mit der API können Sie die Protokollebenenkonfiguration des vpxa-Dienstes auf einem ESX-Host aufgrund einer fehlenden oder ungültigen Vpx.Vpxa.config.log.level-Option nach einem Upgrade Ihres vCenter Server-Systems möglicherweise nicht ändern. 

  • Wenn ESXi auf einem langsamen Startgerät wie USB oder FCoE installiert ist, kann ESXi möglicherweise keinen Startgerätespeicherpfad erkennen. Infolgedessen werden die Bootbankpartition und andere Partitionen wie /scratch nicht identifiziert und Konfigurationsänderungen werden nicht gespeichert. Beim Starten von ESXi verweisen die symbolischen Verknüpfungen /bootbank und /scratch auf einen temporären Speicherpfad.

  • Im Rahmen der Cluster-Imageverwaltung von vSphere Lifecycle Manager kann der Lifecycle Manager-Agent möglicherweise keinen ESXi-Host kontaktieren, um eine Aufgabe wie z. B. die Installation zu starten. Folglich zeigt der vSphere Client einen Fehler an, z. B. Der vSphere HA-Agent ist vom vCenter Server aus nicht erreichbar. Der Fehler tritt auf, wenn die vSphere Lifecycle Manager-Aufgabenstatusdatenbank auf dem ESXi-Host nicht häufig bereinigt wird und der Lifecycle Manager-Agent nicht über genügend Speicher verfügt, um die Größe der Datenbankdatei zu verarbeiten.

  • Während eines Clusterimage-Verwaltungsvorgangs kann es vorkommen, dass der vSphere Lifecycle Manager den Lifecycle Manager-Agenten auf einem ESXi-Host nicht kontaktiert. Im vSphere Client wird ein Fehler angezeigt, z. B. Unbekannter Fehler beim Aufrufen der Host-API aufgetreten. Der Fehler tritt auf, wenn die vSphere Lifecycle Manager-Aufgabenstatusdatenbank auf dem ESXi-Host nicht häufig bereinigt wird und der Lifecycle Manager-Agent nicht über genügend Speicher verfügt, um die Größe der Datenbankdatei zu verarbeiten.

  • Im Rahmen der Cluster-Imageverwaltung von vSphere Lifecycle Manager kann der vSphere HA-Agent möglicherweise keinen ESXi-Host konfigurieren. Dies führt dazu, dass im vSphere Client sinngemäß folgende Fehlermeldung angezeigt wird:
    Fehler beim Konfigurieren des vSphere HA-Agenten auf dem Host. Beim Anwenden von HA-VIBs auf dem Cluster ist ein Fehler aufgetreten. 
    Der Fehler tritt auf, weil der Installationsvorgang des vSphere HA-Agenten auf dem ESXi-Host möglicherweise mehr Arbeitsspeicher verbraucht als das zugewiesene Kontingent.

  • Im vSphere Client wird für einige Sensoren auf ESXi-Hosts eine Warnung zum Hardwarezustand mit dem Status „Unbekannt“ angezeigt.

  • Wenn Sie nur das Dialogfeld NTP-Einstellungen bearbeiten öffnen und schließen, schaltet sich die Option Mit Host starten und beenden aus. Der NTP-Dienst wird nicht gestartet, wenn ein ESXi-Host eingeschaltet wird. Im vSphere Client wird der Auswahl entsprechend für die NTP-Dienststartrichtlinie die Option Mit Host starten und beenden angezeigt. Wenn Sie jedoch in der ESX-Shell den Befehl chkconfig –list ausführen, ist der NTP-Dienst deaktiviert.

  • Wenn Sie einen FCoE-Softwareadapter als Mittel für den Zugriff auf Fibre Channel-Speicher deaktivieren, kann das CBT-Modul möglicherweise nicht geladen werden und ESXi kann möglicherweise kein Startgerät erkennen. Dies führt dazu, dass Snapshot-Vorgänge wie das Erstellen und Konsolidieren von Snapshots fehlschlagen.

  • Bei Verbindungsproblemen können vSAN-Statusprüfungen, die eine Verbindung zu VMware erfordern, zu einer Zeitüberschreitung führen. Im vSphere Client wird eine Fehlermeldung ähnlich der folgenden angezeigt:
    Fehler beim Abfragen der vSAN-Integritätsinformationen. Einzelheiten finden Sie in den vSphere Client-Protokollen.
    Dieses Problem kann sich auf Online-Statusprüfungen, HCL-Updates und vSphere Lifecycle Manager-Baseline-Empfehlungen auswirken. Wenn vCenter Server das Problem nicht beheben kann, können vSAN-Statusprüfungen bei der Abfrage von DNS-Einträgen zu einer Zeitüberschreitung führen.

  • Während der Außerbetriebnahme einer Festplatte zum Entfernen schlägt ein ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm fehl. Backtrace enthält Einträge ähnlich den folgenden:

    2020-09-01T04:22:47.112Z cpu7:2099790)@BlueScreen: Fehlgeschlagen bei bora/modules/vmkernel/lsomcommon/ssdlog/ssdopslog.c:398 -- NICHT ERREICHT
    2020-09-01T04:22:47.112Z cpu7:2099790)Code start: 0x418037400000 VMK uptime: 0:00:39:25.026
    2020-09-01T04:22:47.112Z cpu7:2099790)0x451a8049b9e0:[0x41803750bb65]PanicvPanicInt@vmkernel#nover+0x439 stack: 0x44a00000001
    2020-09-01T04:22:47.112Z cpu7:2099790)0x451a8049ba80:[0x41803750c0a2]Panic_vPanic@vmkernel#nover+0x23 stack: 0x121
    2020-09-01T04:22:47.113Z cpu7:2099790)0x451a8049baa0:[0x4180375219c0]vmk_PanicWithModuleID@vmkernel#nover+0x41 stack: 0x451a8049bb00
    2020-09-01T04:22:47.113Z cpu7:2099790)0x451a8049bb00:[0x41803874707a]SSDLOG_FreeLogEntry@LSOMCommon#1+0x32b stack: 0x800000
    2020-09-01T04:22:47.113Z cpu7:2099790)0x451a8049bb70:[0x4180387ae4d1][email protected]#0.0.0.1+0x2e stack: 0x712d103
    2020-09-01T04:22:47.114Z cpu7:2099790)0x451a8049bbe0:[0x4180387dd08d][email protected]#0.0.0.1+0x72 stack: 0x431b19603150
    2020-09-01T04:22:47.114Z cpu7:2099790)0x451a8049bcd0:[0x4180387dd2d3][email protected]#0.0.0.1+0x80 stack: 0x4318102ba7a0
    2020-09-01T04:22:47.115Z cpu7:2099790)0x451a8049bd00:[0x4180387dabb5][email protected]#0.0.0.1+0x2ce stack: 0x800000
    2020-09-01T04:22:47.115Z cpu7:2099790)0x451a8049beb0:[0x4180386de2db][email protected]#0.0.0.1+0x590 stack: 0x43180fe83380
    2020-09-01T04:22:47.115Z cpu7:2099790)0x451a8049bf90:[0x4180375291ce]vmkWorldFunc@vmkernel#nover+0x4f stack: 0x4180375291ca
    2020-09-01T04:22:47.116Z cpu7:2099790)0x451a8049bfe0:[0x4180377107da]CpuSched_StartWorld@vmkernel#nover+0x77 stack: 0x0

  • Wenn auf einem NVMe-Gerät mehrere Namespaces konfiguriert sind, kann sich die Unterstützung für sichere vSAN-Festplattenlöschvorgänge je nach der Anzahl der Namespaces dynamisch ändern. Wenn ein neuer Namespace konfiguriert wird, während ein sicherer Löschvorgang ausgeführt wird, z. B. in VxRail oder der Google Cloud Platform, kann das dazu führen, dass die Daten auf dem neu hinzugefügten Namespace gelöscht werden.

  • Das Plug-In für die Betriebsbereitschaft von Festplatten des nativen ESXi-Treibers für HPE Smart Array-Steuerungen, nhpsa, wurde auf Version 70.0051.0.100 aktualisiert, um mehrere bekannte Probleme zu beheben.

  • Das Plug-In für die Betriebsbereitschaft von Festplatten des nativen ESXi-SCSI-Treibers für Microsemi Smart Family-Steuerungen, smartpqi, wurde auf Version 70.4000.0.100-5 aktualisiert, um mehrere fehlende Geräte-IDs zurückzusetzen.

ESXi-7.0U1sc-17325020-standard

Profilname	ESXi-7.0U1sc-17325020-standard
Build	Build-Informationen finden Sie unter In dieser Version enthaltene Patches.
Anbieter	VMware, Inc.
Datum der Veröffentlichung	17. Dezember 2020
Akzeptanzebene	PartnerSupported
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Betroffene VIBs	VMware_bootbank_crx_7.0.1-0.20.17325020 VMware_bootbank_esx-xserver_7.0.1-0.20.17325020 VMware_bootbank_esx-base_7.0.1-0.20.17325020 VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.1-0.20.17325020 VMware_bootbank_native-misc-drivers_7.0.1-0.20.17325020 VMware_bootbank_vsan_7.0.1-0.20.17325020 VMware_bootbank_vsanhealth_7.0.1-0.20.17325020 VMware_bootbank_gc_7.0.1-0.20.17325020 VMware_bootbank_cpu-microcode_7.0.1-0.20.17325020 VMware_bootbank_vdfs_7.0.1-0.20.17325020 VMware_bootbank_esx-update_7.0.1-0.20.17325020 VMware_bootbank_loadesx_7.0.1-0.20.17325020 VMW_bootbank_vmkata_0.1-1vmw.701.0.20.17325020 VMW_bootbank_nvmerdma_1.0.1.2-1vmw.701.0.20.17325020 VMW_bootbank_vmkfcoe_1.0.0.2-1vmw.701.0.20.17325020 VMW_bootbank_vmkusb_0.1-1vmw.701.0.20.17325020
Behobene Probleme	2661006, 2671485, 2636149
Verwandte CVE-Nummern	CVE-2020-3999

• Dieser Patch enthält Updates zur Behebung der folgenden Probleme:

  • ESXi 7.0 Update 1c behebt eine Denial-of-Service-Schwachstelle aufgrund falscher Eingabevalidierung in GuestInfo-Variablen. Ein böswilliger Akteur mit normalen Benutzerzugriffsrechten auf eine virtuelle Maschine kann zu einem Ausfall des VMX-Prozesses der virtuellen Maschine führen, was zu einer Denial-of-Service-Bedingung führt. Im Projekt "Common Vulnerabilities and Exposures" (CVE) (cve.mitre.org) wurde diesem Problem die Bezeichnung CVE-2020-3999 zugewiesen. Weitere Informationen finden Sie unter VMSA-2020-0029.

  • Die SQLite-Datenbank wurde auf Version 3.33.0 aktualisiert.

  • Die userworld-OpenSSL-Bibliothek von ESXi wurde auf die Version openssl-1.0.2w aktualisiert.

  • Die OpenSSH-Version wurde auf Version 8.3p1 aktualisiert.

  • Der NTP-Daemon wurde auf Version ntp-4.2.8p15 aktualisiert.

  • Die userworld-libcurl-Bibliothek von ESXi wurde auf Version 7.72.0 aktualisiert.

  • Die folgenden VMware Tools-ISO-Images werden mit ESXi 7.0 Update 1c gebündelt:

    • windows.iso: VMware Tools 11.1.5 unterstützt Windows 7 SP1 oder Windows Server 2008 R2 SP1 oder höher.
    • linux.iso: VMware Tools 10.3.22-ISO-Image für das Linux-Betriebssystem mit glibc 2.5 oder höher.

    Die folgenden VMware Tools-ISO-Images stehen zum Download zur Verfügung:

    • VMware Tools 10.0.12:
      • winPreVista.iso: für Windows 2000, Windows XP und Windows 2003.
      • linuxPreGLibc25.iso: für Linux-Betriebssysteme mit einer glibc-Version unter 2.5.
         
    • VMware Tools 11.0.6
      • windows.iso: für Windows Vista (SP2) und Windows Server 2008 Service Pack 2 (SP2).
    • solaris.iso: VMware Tools-Image für Solaris.
    • darwin.iso: VMware Tools-Image für OSX.

    Befolgen Sie die in den folgenden Dokumenten aufgeführten Vorgehensweisen, um VMware Tools für Plattformen, die nicht mit ESXi gebündelt sind, herunterzuladen:

    • Versionshinweise zu VMware Tools 11.1.5
    • Frühere Versionen von VMware Tools
    • Wichtige Informationen zu VMware Tools für Administratoren
    • VMware Tools für Hosts, die mit Auto Deploy bereitgestellt wurden
    • Aktualisieren von VMware Tools

ESXi-7.0U1sc-17325020-no-tools

Profilname	ESXi-7.0U1sc-17325020-no-tools
Build	Build-Informationen finden Sie unter In dieser Version enthaltene Patches.
Anbieter	VMware, Inc.
Datum der Veröffentlichung	17. Dezember 2020
Akzeptanzebene	PartnerSupported
Betroffene Hardware	Nicht verfügbar
Betroffene Software	Nicht verfügbar
Betroffene VIBs	VMware_bootbank_crx_7.0.1-0.20.17325020 VMware_bootbank_esx-xserver_7.0.1-0.20.17325020 VMware_bootbank_esx-base_7.0.1-0.20.17325020 VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.1-0.20.17325020 VMware_bootbank_native-misc-drivers_7.0.1-0.20.17325020 VMware_bootbank_vsan_7.0.1-0.20.17325020 VMware_bootbank_vsanhealth_7.0.1-0.20.17325020 VMware_bootbank_gc_7.0.1-0.20.17325020 VMware_bootbank_cpu-microcode_7.0.1-0.20.17325020 VMware_bootbank_vdfs_7.0.1-0.20.17325020 VMware_bootbank_esx-update_7.0.1-0.20.17325020 VMware_bootbank_loadesx_7.0.1-0.20.17325020 VMW_bootbank_vmkata_0.1-1vmw.701.0.20.17325020 VMW_bootbank_nvmerdma_1.0.1.2-1vmw.701.0.20.17325020 VMW_bootbank_vmkfcoe_1.0.0.2-1vmw.701.0.20.17325020 VMW_bootbank_vmkusb_0.1-1vmw.701.0.20.17325020
Behobene Probleme	2661006, 2671485, 2636149
Verwandte CVE-Nummern	CVE-2020-3999

• Dieser Patch enthält Updates zur Behebung der folgenden Probleme:

  • ESXi 7.0 Update 1c behebt eine Denial-of-Service-Schwachstelle aufgrund falscher Eingabevalidierung in GuestInfo-Variablen. Ein böswilliger Akteur mit normalen Benutzerzugriffsrechten auf eine virtuelle Maschine kann zu einem Ausfall des VMX-Prozesses der virtuellen Maschine führen, was zu einer Denial-of-Service-Bedingung führt. Im Projekt "Common Vulnerabilities and Exposures" (CVE) (cve.mitre.org) wurde diesem Problem die Bezeichnung CVE-2020-3999 zugewiesen. Weitere Informationen finden Sie unter VMSA-2020-0029.

  • Die SQLite-Datenbank wurde auf Version 3.33.0 aktualisiert.

  • Die userworld-OpenSSL-Bibliothek von ESXi wurde auf die Version openssl-1.0.2w aktualisiert.

  • Die OpenSSH-Version wurde auf Version 8.3p1 aktualisiert.

  • Der NTP-Daemon wurde auf Version ntp-4.2.8p15 aktualisiert.

  • Die userworld-libcurl-Bibliothek von ESXi wurde auf Version 7.72.0 aktualisiert.

  • Die folgenden VMware Tools-ISO-Images werden mit ESXi 7.0 Update 1c gebündelt:

    • windows.iso: VMware Tools 11.1.5 unterstützt Windows 7 SP1 oder Windows Server 2008 R2 SP1 oder höher.
    • linux.iso: VMware Tools 10.3.22-ISO-Image für das Linux-Betriebssystem mit glibc 2.5 oder höher.

    Die folgenden VMware Tools-ISO-Images stehen zum Download zur Verfügung:

    • VMware Tools 10.0.12:
      • winPreVista.iso: für Windows 2000, Windows XP und Windows 2003.
      • linuxPreGLibc25.iso: für Linux-Betriebssysteme mit einer glibc-Version unter 2.5.
         
    • VMware Tools 11.0.6
      • windows.iso: für Windows Vista (SP2) und Windows Server 2008 Service Pack 2 (SP2).
    • solaris.iso: VMware Tools-Image für Solaris.
    • darwin.iso: VMware Tools-Image für OSX.

    Befolgen Sie die in den folgenden Dokumenten aufgeführten Vorgehensweisen, um VMware Tools für Plattformen, die nicht mit ESXi gebündelt sind, herunterzuladen:

    • Versionshinweise zu VMware Tools 11.1.5
    • Frühere Versionen von VMware Tools
    • Wichtige Informationen zu VMware Tools für Administratoren
    • VMware Tools für Hosts, die mit Auto Deploy bereitgestellt wurden
    • Aktualisieren von VMware Tools

ESXi Image - ESXi70U1c-17325551

Name	ESXi
Version	7.0 U1c-17325551
Datum der Veröffentlichung	17. Dezember 2020
Kategorie	Verbesserung
Betroffene Komponenten	ESXi ESXi-Komponente „Installieren/Aktualisieren“ Treiber für VMware ATA-Speichercontroller Treiber für HPE Smart Array-Steuerung VMware-USB-Treiber Treiber für Microsemi Storage Solution Smart Array-Speichercontroller
Behobene Probleme	2656093, 2652863, 2653874, 2643508, 2644189, 2652344, 2661064, 2667291, 2662512, 2644221, 2662606, 2661153, 2655181, 2657411, 2675442, 2657649, 2662558, 2661818, 2664084, 2625155, 2658647, 2659015, 2654686, 2664278, 2676632, 2647557, 2647557, 2628899, 2663717, 2633194, 2661808, 2670891, 2665031, 2644003, 2664045, 2655992, 2661584
Verwandte CVE-Nummern	CVE-2020-3999

ESXi Image - ESXi7.0U1sc-17325020

Name	ESXi
Version	7.0 U1sc-17325020
Datum der Veröffentlichung	17. Dezember 2020
Kategorie	Verbesserung
Betroffene Komponenten	ESXi ESXi-Komponente „Installieren/Aktualisieren“ Treiber für VMware ATA-Speichercontroller VMware NVMe over Fabric – RDMA-Treiber Nativer Treiber für VMware Software FCoE VMware-USB-Treiber
Behobene Probleme	2661006, 2671485, 2636149
Verwandte CVE-Nummern	CVE-2020-3999

Bekannte Probleme

Die bekannten Probleme gliedern sich in folgende Gruppen.

• Upgrade-Probleme
• Sonstige Probleme
• Bekannte Probleme aus früheren Versionen

Upgrade-Probleme

• Upgrades von ESXi 6.5x 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.

Sonstige Probleme

• Sichere vSAN-Festplattenlöschung auf NVMe-Geräten mit mehreren Namespaces wird nicht unterstützt

  Wenn auf einem NVME-Gerät mehrere Namespaces konfiguriert sind, werden sichere vSAN-Festplattenlöschvorgänge nicht unterstützt.
  Wenn ein neuer Namespace konfiguriert wird, während ein sicherer Löschvorgang durchgeführt wird, z. B. in VMware Tanzu Architecture for Dell EMC VxRail oder der Google Cloud Platform, kann das dazu führen, dass die Daten auf dem neu hinzugefügten Namespace gelöscht werden. Daher werden sichere vSAN-Festplattenlöschvorgänge nur für NVME-Geräte mit einem einzelnen Namespace unterstützt.

  Problemumgehung: Keine

Bekannte Probleme aus früheren Versionen

Um eine Liste früherer bekannter Probleme anzuzeigen, klicken Sie hier.

Die früheren bekannten Probleme gliedern sich in folgende Gruppen.

• Installations-, Upgrade- und Migrationsprobleme
• Probleme bei Sicherheitsfunktionen
• Netzwerkprobleme
• Speicherprobleme
• Probleme bei vCenter Server und dem vSphere Client
• VM-Verwaltungsprobleme
• vSphere HA- und Fault Tolerance-Probleme
• Probleme bei vSphere Lifecycle Manager
• Sonstige Probleme

Installations-, Upgrade- und Migrationsprobleme

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

• 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

• Beim Upgrade von vCenter Server mithilfe der Befehlszeilenschnittstelle (CLI) wird fälschlicherweise die TLS-Konfiguration (Transport Security Layer) für den vSphere Authentication Proxy-Dienst beibehalten

  Wenn der vSphere Authentication Proxy-Dienst (vmcam) für die Verwendung eines anderen TLS-Protokolls als des standardmäßigen TLS 1.2-Protokolls konfiguriert ist, wird diese Konfiguration während des CLI-Upgrade-Vorgangs beibehalten. Standardmäßig unterstützt vSphere das Verschlüsselungsprotokoll TLS 1.2. Wenn Sie die Protokolle TLS 1.0 und TLS 1.1 verwenden müssen, um Produkte oder Dienste zu unterstützen, die TLS 1.2 nicht unterstützen, können Sie das TLS-Konfigurationsprogramm verwenden, um die verschiedenen Versionen des TLS-Protokolls zu aktivieren oder zu deaktivieren.

  Problemumgehung: Verwenden Sie das TLS-Konfigurationsprogramm zum Konfigurieren des vmcam-Ports. Weitere Informationen zur Verwaltung der TLS-Protokollkonfiguration und zur Verwendung des TLS-Konfigurationsprogramms finden Sie in der Dokumentation zu VMware Security.

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

  1. 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.
  2. 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:

  1. Entfernen Sie alle doppelten Beanspruchungsregeln von Systemstandardregeln aus dem Hostprofildokument.
  2. Überprüfen Sie den Übereinstimmungsstatus.
  3. Standardisieren Sie den Host.
  4. 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.

Probleme bei Sicherheitsfunktionen

• Eine verschlüsselte virtuelle Maschine kann nicht eingeschaltet werden, wenn der für HA aktivierte vertrauenswürdige Cluster einen nicht bestätigten Host enthält

  Wenn Sie in VMware® vSphere Trust Authority™ HA im vertrauenswürdigen Cluster aktiviert haben und ein oder mehrere Hosts im Cluster nicht bestätigt werden, kann eine verschlüsselte virtuelle Maschine nicht eingeschaltet werden.

  Problemumgehung: Entfernen oder standardisieren Sie alle Hosts des vertrauenswürdigen Clusters, die nicht bestätigt werden konnten.

• Eine verschlüsselte virtuelle Maschine kann nicht eingeschaltet werden, wenn der für DRS aktivierte vertrauenswürdige Cluster einen nicht bestätigten Host enthält

  Wenn Sie in VMware® vSphere Trust Authority™ DRS im vertrauenswürdigen Cluster aktiviert haben und ein oder mehrere Hosts im Cluster nicht bestätigt werden können, versucht DRS möglicherweise, eine verschlüsselte virtuelle Maschine auf einem nicht bestätigten Host im Cluster einzuschalten. Durch diesen Vorgang wird die virtuelle Maschine in einen gesperrten Zustand versetzt.

  Problemumgehung: Entfernen oder standardisieren Sie alle Hosts des vertrauenswürdigen Clusters, die nicht bestätigt werden konnten.

• Das Migrieren oder Klonen von verschlüsselten virtuellen Maschinen über vCenter Server -Instanzen schlägt fehl, wenn dies mit dem vSphere Client versucht wird

  Wenn Sie versuchen, eine verschlüsselte virtuelle Maschine über vCenter Server-Instanzen hinweg mithilfe des vSphere Client zu migrieren oder zu klonen, schlägt der Vorgang mit folgender Fehlermeldung fehl: „Der Vorgang ist im aktuellen Zustand nicht zulässig.“

  Problemumgehung: Sie müssen die vSphere-APIs verwenden, um verschlüsselte virtuelle Maschinen über vCenter Server-Instanzen hinweg zu migrieren oder zu klonen.

Netzwerkprobleme

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

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

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

Speicherprobleme

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

• Nach dem Wiederherstellen nach APD- oder PDL-Bedingungen bleibt der VMFS-Datenspeicher mit aktivierter Unterstützung für virtuelle Festplatten im Cluster möglicherweise nicht zugänglich

  Dieses Problem kann nur in Datenspeichern auftreten, in denen die Unterstützung für virtuelle Festplatten in Clustern aktiviert ist. Wenn der Datenspeicher aus einem Zustand „keine Pfade verfügbar“ (APD) oder „dauerhafter Geräteausfall“ (PDL) wiederhergestellt wird, ist er weiterhin nicht erreichbar. Das VMkernel-Protokoll zeigt möglicherweise mehrere SCSI3 reservation conflict-Meldungen ähnlich der Folgenden an:

  2020-02-18T07:41:10.273Z cpu22:1001391219)ScsiDeviceIO: vm 1001391219: SCSIDeviceCmdCompleteCB:2972: Reservation conflict retries 544 for command 0x45ba814b8340 (op: 0x89) to device "naa.624a9370b97601e346f64ba900024d53"

  Das Problem kann eintreten, weil der ESXi-Host, der am Cluster teilnimmt, SCSI-Reservierungen für den Datenspeicher verliert und sie nach der Wiederherstellung des Datenspeichers nicht immer automatisch neu wiederherstellen kann.

  Problemumgehung: Registrieren Sie die Reservierung manuell mithilfe des folgenden Befehls:

  vmkfstools -L registerkey /vmfs/devices/disks/<device name>

  wobei der <device name> der Name des Geräts ist, auf dem der Datenspeicher erstellt wird.

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

Probleme bei vCenter Server und dem vSphere Client

• Anbieter gehen nach einer PNID-Änderung offline

  Wenn Sie die IP-Adresse von vCenter ändern (PNID-Änderung), gehen die registrierten Anbieter offline.

  Problemumgehung: Registrieren Sie die Anbieter erneut.

• Die vCenter-übergreifende Migration einer virtuellen Maschine schlägt mit einem Fehler fehl

  Wenn Sie vCenter vMotion zum Verschieben von Speicher und Host einer VM in eine andere vCenter Server-Instanz verwenden, erhalten Sie möglicherweise den Fehler Der Vorgang ist im aktuellen Status nicht zulässig. 

  Dieser Fehler wird im UI-Assistenten nach dem Schritt für die Hostauswahl und vor dem Schritt für die Datenspeicherauswahl angezeigt, wenn die VM über eine zugewiesene Speicherrichtlinie mit hostbasierten Regeln wie Verschlüsselung oder anderen E/A-Filterregeln verfügt.

  Problemumgehung: Weisen Sie die VM und ihre Festplatten einer Speicherrichtlinie ohne hostbasierte Regeln zu. Möglicherweise müssen Sie die VM entschlüsseln, wenn die Quell-VM verschlüsselt ist. Versuchen Sie dann erneut, die vCenter vMotion-Aktion zu starten.

• Die Informationen zu Speichersensoren auf der Registerkarte „Hardwarestatus“ zeigen falsche Werte auf der Benutzeroberfläche von vCenter, des Hosts und MOB an

  Wenn Sie in der Benutzeroberfläche von vCenter zu Host > Überwachen > Hardwarestatus > Speichersensoren navigieren, werden in den Speicherinformationen entweder falsche oder unbekannte Werte angezeigt. Dasselbe Problem tritt auf der Benutzeroberfläche des Hosts und im MOB-Pfad „runtime.hardwareStatusInfo.storageStatusInfo“ auf.

  Problemumgehung: Keine.

• Die erweiterten Hosteinstellungen der vSphere-UI zeigen den aktuellen Speicherort des Produkt-Lockers als leer mit einem leeren Standardwert an

  Die erweiterten Hosteinstellungen der vSphere-UI zeigen den aktuellen Speicherort des Produkt-Lockers als leer mit einem leeren Standardwert an. Dies ist inkonsistent, da der aktuelle Produktspeicherort symlink erstellt und gültig ist. Dies kann den Benutzer verwirren. Der Standardwert kann nicht über die Benutzeroberfläche korrigiert werden.

  Problemumgehung: Der Benutzer kann den esxcli-Befehl auf dem Host verwenden, um den aktuellen Speicherort des Produkt-Lockers wie folgt zu korrigieren.

  1. Entfernen Sie die vorhandene Einstellung für den Speicherort des Produkt-Lockers mit: "esxcli system settings advanced remove -o ProductLockerLocation"

  2. Fügen Sie die Einstellung für den Speicherort des Produkt-Lockers erneut mit dem entsprechenden Standardwert hinzu:

        2.a.  Wenn es sich bei dem ESXi um eine vollständige Installation handelt, lautet der Standardwert "/locker/packages/vmtoolsRepo" export PRODUCT_LOCKER_DEFAULT="/locker/packages/vmtoolsRepo"

        2.b. Wenn der ESXi eine PXEboot-Konfiguration wie „autodeploy“ aufweist, lautet der Standardwert: "/vmtoolsRepo" export PRODUCT_LOCKER_DEFAULT="/vmtoolsRepo"

        Führen Sie den folgenden Befehl aus, um den Speicherort automatisch zu ermitteln: export PRODUCT_LOCKER_DEFAULT=`readlink /productLocker`

        Fügen Sie die Einstellung hinzu: esxcli system settings advanced add -d "Path to VMware Tools repository" -o ProductLockerLocation -t string -s $PRODUCT_LOCKER_DEFAULT

  Sie können alle oben aufgeführten Schritte in Schritt 2 kombinieren, indem Sie folgenden einzelnen Befehl ausführen:

  esxcli system settings advanced add -d "Path to VMware Tools repository" -o ProductLockerLocation -t string -s `readlink /productLocker`

• Verknüpfte vCenter Server-Instanzen mit Software-Defined Data Center (SDDC) werden im lokalen vSphere Client angezeigt, wenn ein vCenter Cloud Gateway mit dem SDDC verknüpft ist.

  Wenn ein vCenter Cloud Gateway in derselben Umgebung wie ein lokaler vCenter Server bereitgestellt und mit einem SDDC verknüpft ist, wird der SDDC-vCenter Server im lokalen vSphere Client angezeigt. Dies ist ein unerwartetes Verhalten, und der verknüpfte SDDC-vCenter Server sollte ignoriert werden. Alle Vorgänge, die den verknüpften SDDC-vCenter Server betreffen, sollten auf dem vSphere Client ausgeführt werden, der im vCenter Cloud Gateway ausgeführt wird.

  Problemumgehung: Keine.

VM-Verwaltungsprobleme

• Virtuelle Maschinen mit aktiviertem AMD Secure Encrypted Virtualization-Encrypted State (SEV-ES) können keine VMCI-Sockets (Virtual Machine Communication Interface) erstellen

  Leistung und Funktionalität von Funktionen, die VMCI erfordern, können auf virtuellen Maschinen mit aktiviertem AMD SEV-ES beeinträchtigt werden, da solche virtuellen Maschinen keine VMCI-Sockets erstellen können.

  Problemumgehung: Keine.

• Der Abschnitt „postcustomization“ des Anpassungsskripts wird vor der Gastanpassung ausgeführt

  Wenn Sie das Gastanpassungsskript für ein Linux-Gastbetriebssystem ausführen, wird der Abschnitt precustomization des in der Anpassungsspezifikation definierten Anpassungsskripts vor der Gastanpassung ausgeführt, und anschließend wird der Abschnitt postcustomization ausgeführt. Wenn Sie im Gastbetriebssystem einer virtuellen Maschine die Option „Cloud-Init“ aktivieren, wird der Abschnitt postcustomization aufgrund eines bekannten Problems in Cloud-Init vor der Anpassung ausgeführt.

  Problemumgehung: Deaktivieren Sie Cloud-Init und verwenden Sie die Standard-Gastanpassung. 

• Gruppenmigrationsvorgänge in vSphere vMotion, Storage vMotion und vMotion ohne gemeinsam genutzten Speicher schlagen mit einem Fehler fehl

  Wenn Sie Gruppenmigrationsvorgänge auf VMs mit mehreren Festplatten und Snapshots mit mehreren Ebene durchführen, schlagen die Vorgänge möglicherweise mit folgendem Fehler fehl: com.vmware.vc.GenericVmConfigFault Fehler beim Warten auf Daten Fehler 195887167. Verbindung von Remotehost geschlossen, möglicherweise aufgrund einer Zeitüberschreitung.

  Problemumgehung: Wiederholen Sie den Migrationsvorgang auf den fehlgeschlagenen VMs einzeln.

• Das Bereitstellen einer OVF- oder OVA-Vorlage über eine URL schlägt mit dem Fehler „403 – Verboten“ fehl

  Die URLs, die einen HTTP-Abfrageparameter enthalten, werden nicht unterstützt. Beispiele sind http://webaddress.com?file=abc.ovf oder die vorab signierten Amazon S3-URLs.

  Problemumgehung: Laden Sie die Dateien herunter und stellen Sie sie von Ihrem lokalen Dateisystem bereit.

• Das Importieren oder Bereitstellen lokaler OVF-Dateien, deren Namen Nicht-ASCII-Zeichen enthalten, schlägt möglicherweise mit einer Fehlermeldung fehl

  Wenn Sie lokale .ovf-Dateien mit Nicht-ASCII-Zeichen im Namen importieren, erhalten Sie möglicherweise den Fehler 400 – Ungültige Anforderung. Wenn Sie solche .ovf-Dateien verwenden, um eine virtuelle Maschine im vSphere Client bereitzustellen, wird der Bereitstellungsvorgang bei 0 % beendet. Dies kann dazu führen, dass Sie einen Fehler des Typs 400 – Ungültige Anforderung oder 500 – Interner Serverfehler erhalten.

  Problemumgehung:

  1. Entfernen Sie die Nicht-ASCII-Zeichen aus den Namen der .ovf- und .vmdk-Dateien.
     • Zum Bearbeiten der .ovf-Datei öffnen Sie einen Texteditor.
     • Suchen Sie nach dem .vmdk-Dateinamen mit Nicht-ASCII-Zeichen und ändern Sie diese zu ASCII-Zeichen.
  2. Sie können die gespeicherten Dateien erneut importieren oder bereitstellen. 
• Die dritte Ebene verschachtelter Objekte in einem VM-Ordner ist nicht sichtbar

  Führen Sie die folgenden Schritte aus:

  1. Navigieren Sie zu einem Datencenter und erstellen Sie einen VM-Ordner.
  2. Erstellen Sie im VM-Ordner einen verschachtelten VM-Ordner.
  3. Erstellen Sie im zweiten Ordner einen weiteren verschachtelten VM-Ordner, eine weitere verschachtelte virtuelle Maschine, vApp oder VM-Vorlage.

  Dies führt dazu, dass Sie in der Bestandslistenstruktur für VMs und Vorlagen die Objekte im dritten verschachtelten Ordner nicht sehen können.

  Problemumgehung: Um die Objekte im dritten verschachtelten Ordner anzeigen zu können, navigieren Sie zum zweiten verschachtelten Ordner und wählen Sie die Registerkarte „VMs“ aus.

vSphere HA- und Fault Tolerance-Probleme

• VMs in einem Cluster sind nach dem Wiederherstellen des Speicherzugriffs, wie z. B. nach einem clusterweiten APD, möglicherweise verwaist.

  Einige VMs befinden sich möglicherweise nach der Wiederherstellung aus dem clusterweiten APD im verwaisten Zustand, selbst wenn HA und VMCP auf dem Cluster aktiviert sind.

  Dieses Problem tritt möglicherweise auf, wenn die folgenden Bedingungen gleichzeitig eintreten:

  • Für alle Hosts im Cluster tritt APD ein, und sie werden erst wieder wiederhergestellt, wenn die VMCP-Zeitüberschreitung erreicht ist.
  • Der primäre HA-Agent initiiert ein Failover aufgrund von APD auf einem Host.
  • Das Einschalten der API beim HA-Failover schlägt aufgrund eines der folgenden Fehler fehl:
    • APD über den gleichen Host hinweg
    • Kaskadierender APD über den gesamten Cluster hinweg
    • Speicherprobleme
    • Nichtverfügbarkeit von Ressourcen
  • Die Aufhebung der FDM-Registrierung und VCs-Steal-VM-Logik können während eines Fensters initiiert werden, in dem FDM die Registrierung der fehlgeschlagenen VM nicht aufgehoben hat und die VC-Hostsynchronisierung antwortet, dass mehrere Hosts die gleiche VM melden. Sowohl FDM als auch VC heben die Registrierung der verschiedenen registrierten Kopien derselben VM von verschiedenen Hosts auf, wodurch die VM verwaist wird.

   

  Problemumgehung: Sie müssen die Registrierung der verwaisten VMs im Cluster nach der Wiederherstellung aus APD aufheben und sie erneut registrieren.

  Wenn Sie die verwaisten VMs nicht manuell neu registrieren, versucht HA das Failover der verwaisten VMs; dies kann jedoch zwischen 5 und 10 Stunden dauern, je nachdem, wann APD wiederhergestellt wird.

  Die Gesamtfunktionalität des Clusters ist in diesen Fällen nicht betroffen, und HA schützt die VMs weiterhin. Dies ist eine Anomalie in der Anzeige in VC für die Dauer des Problems.

Probleme bei vSphere Lifecycle Manager

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

• ESXi 7.0-Hosts können nicht mithilfe von vSphere Auto Deploy zu einem Cluster hinzugefügt werden, den Sie mit einem einzelnen Image verwalten

  Der Versuch, ESXi-Hosts zu einem Cluster, den Sie mit einem einzelnen Image verwalten, mithilfe des Workflows „Zur Bestandsliste hinzufügen“ in vSphere Auto Deploy hinzuzufügen, schlägt fehl. Der Fehler ist darauf zurückzuführen, dass keine Muster in einem vorhandenen Auto Deploy-Regelsatz übereinstimmen. Die Aufgabe schlägt im Hintergrund fehl und die Hosts verbleiben auf der Registerkarte „Erkannte Hosts“.

  Problemumgehung:

  1. Entfernen Sie die ESXi Hosts, die nicht mit dem Regelsatz übereinstimmten, von der Registerkarte „Erkannte Hosts“.
  2. Erstellen Sie eine Regel oder bearbeiten Sie eine vorhandene Auto Deploy-Regel, wobei der Zielspeicherort des Hosts ein von einem Image verwalteter Cluster ist.
  3. Starten Sie die Hosts neu.

   

  Die Hosts werden zu dem Cluster hinzugefügt, den Sie mit einem Image in vSphere Lifecycle Manager verwalten.

• 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.
  1. Verbinden Sie den Hardware-Support-Manager erneut mit vCenter Server.
  2. Wählen Sie im Menü „Hosts und Cluster“ einen Cluster aus.
  3. Wählen Sie die Registerkarte „Konfigurieren“ aus.
  4. Klicken Sie unter „Dienste“ auf „vSphere-Verfügbarkeit“.
  5. Aktivieren Sie vSphere HA erneut.
  • Wenn der Hardware-Support-Manager dauerhaft nicht verfügbar ist, führen Sie die folgenden Schritte aus.
  1. Entfernen Sie den Hardware-Support-Manager und das Hardware-Support-Paket aus der Image-Spezifikation.
  2. Aktivieren Sie vSphere HA erneut.
  3. Wählen Sie im Menü „Hosts und Cluster“ einen Cluster aus.
  4. Wählen Sie die Registerkarte „Updates“ aus.
  5. Klicken Sie auf „Bearbeiten“.
  6. Entfernen Sie das Add-On für Firmware und Treiber und klicken Sie auf „Speichern“.
  7. Wählen Sie die Registerkarte „Konfigurieren“ aus.
  8. Klicken Sie unter „Dienste“ auf „vSphere-Verfügbarkeit“.
  9. 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:

  1. Rufen Sie die IOFilter-API UninstallIoFilter_Task aus dem verwalteten Objekt von vCenter Server (IoFilterManager) auf.
  2. Standardisieren Sie den Cluster in vSphere Lifecycle Manager.
  3. 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.

Sonstige Probleme

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

  1. Wenn Sie ein Hostprofil mit Version 6.5 erstellen, legen Sie eine erweiterte Konfigurationsoption „VMkernel.Boot.autoCreateDumpFile“ auf dem ESXi-Host als „false“ fest.
  2. 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.

   

• Das Dropdown-Menü „Aktionen“ enthält keine Elemente, wenn Ihr Browser auf eine andere Sprache als Englisch festgelegt ist

  Wenn Ihr Browser auf eine andere Sprache als Englisch festgelegt ist und Sie auf die Schaltfläche Zur neuen Ansicht wechseln auf der Registerkarte Übersicht in der vSphere Client-Bestandsliste klicken, enthält das Dropdown-Menü Aktionen im Bereich Gastbetriebssystem keine Elemente.

  Problemumgehung: Wählen Sie das Dropdown-Menü Aktionen oben auf der Seite der virtuellen Maschine aus.

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

  1. Beenden Sie den hostd-Dienst mithilfe des Befehls:
     /etc/init.d/hostd stop.
  2. Entladen Sie das Firewall-Modul mithilfe des Befehls:
     esxcli network firewall unload.
  3. Führen Sie die erforderlichen Vorgänge aus.
  4. Laden Sie das Firewall-Modul mithilfe des Befehls:
     esxcli network firewall load.
  5. 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.

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

• Wenn Sie einen erweiterten Optionsparameter in einem Hostprofil bearbeiten und einen Wert auf „false“ festlegen, wird der Wert auf „true“ gesetzt

  Wenn Sie versuchen, einen Wert für einen erweiterten Optionsparameter in einem Hostprofil auf false festzulegen, wird in der Benutzeroberfläche ein nicht leerer Zeichenfolgenwert erstellt. Nicht leere Werte werden als true interpretiert, und der erweiterte Optionsparameter erhält im Hostprofil einen Wert von true.

  Problemumgehung: Es gibt zwei mögliche Problemumgehungen.

  • Legen Sie den erweiterten Optionsparameter auf einem ESXi-Referenzhost als false fest und kopieren Sie die Einstellungen von diesem Host in „Hostprofile“.
    Hinweis: Der Host muss mit dem Hostprofil konform sein, bevor der erweiterte Optionsparameter auf dem Host geändert werden kann.
  • Legen Sie den erweiterten Optionsparameter auf einem ESXi-Referenzhost auf false fest und erstellen Sie ein Hostprofil von diesem Host. Kopieren Sie anschließend die Hostprofileinstellungen aus dem neuen Hostprofil in das vorhandene Hostprofil.

   

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

Um die Liste früherer bekannter Probleme zu reduzieren, klicken Sie hier.