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

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

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

        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:

                  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:

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

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