ESXi 7.0 Update 3f | 12. Juli 2022 | ISO-Build 20036589

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

WICHTIG: Wenn Ihr Quellsystem Hosts mit Versionen zwischen ESXi 7.0 Update 2 und Update 3c sowie Intel-Treiber enthält, lesen Sie vor dem Upgrade auf ESXi 7.0 Update 3f den Abschnitt Neuigkeiten der Versionshinweise zu VMware vCenter Server 7.0 Update 3c, da der gesamte Inhalt im Abschnitt auch für vSphere 7.0 Update 3f gilt. Weitere Informationen erhalten Sie auch in den verwandten VMware-Knowledgebase-Artikeln: 86447, 87258 und 87308. 

Neuigkeiten

  • In dieser Version werden die folgenden Schwachstellen behoben: CVE-2022-23816, CVE-2022-23825, CVE-2022-28693 und CVE-2022-29901. Weitere Informationen zu diesen Schwachstellen und deren Auswirkungen auf VMware-Produkte finden Sie unter VMSA-2022-0020.
  • ESXi 7.0 Update 3f unterstützt vSphere Quick Boot auf folgenden Servern:

    • Cisco Systems Inc:

      • UCSC-C220-M6N
      • UCSC-C225-M6N
      • UCSC-C240-M6L
      • UCSC-C240-M6N
      • UCSC-C240-M6SN
      • UCSC-C240-M6SX

    • Dell Inc:

      • PowerEdge XR11
      • PowerEdge XR12
      • PowerEdge XE8545
    • HPE:
      • Edgeline e920
      • Edgeline e920d
      • Edgeline e920t
      • ProLiant DL20 Gen10 Plus
      • ProLiant DL110 Gen10 Plus
      • ProLiant ML30 Gen10 Plus
    • Lenovo:
      • ThinkSystem SR 860 V2

Vorherige Versionen von ESXi 7.0

Neue 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 ESXi 7.0 Update 3f-Version stellt die folgenden Patches bereit:

Build-Details

Download-Dateiname: VMware-ESXi-7.0U3f-20036589-depot
Build: 20036589
Download-Größe: 575,2 MB
md5sum: 8543deb5d6d71bc7cc6d6c21977b1181
sha256checksum: b4cd253cbc28abfa01fbe8e996c3b0fd8b6be9e442a4631f35616eb34e9e01e9
Neustart des Hosts erforderlich: Ja
Migration oder Herunterfahren der virtuellen Maschine erforderlich: Ja

Komponenten

Komponente Bulletin Kategorie Schweregrad
ESXi-Komponente - ESXi-Kern-VIBs ESXi_7.0.3-0.50.20036589 Fehlerkorrektur Kritisch
ESXi-Komponente „Installieren/Aktualisieren“ esx-update_7.0.3-0.50.20036589 Fehlerkorrektur Kritisch
Broadcom NetXtreme-E-Netzwerk- und ROCE/RDMA-Treiber für VMware ESXi Broadcom-bnxt-Net-RoCE_216.0.0.0-1vmw.703.0.50.20036589 Fehlerkorrektur Kritisch
Netzwerktreiber für Intel(R) E810-Adapter Intel-icen_1.4.1.20-1vmw.703.0.50.20036589 Fehlerkorrektur Kritisch
Netzwerktreiber für Intel(R) X722- und E810-basierte RDMA-Adapter Intel-irdman_1.3.1.22-1vmw.703.0.50.20036589 Fehlerkorrektur Kritisch
Nativer iSER-Treiber von VMware VMware-iser_1.1.0.1-1vmw.703.0.50.20036589 Fehlerkorrektur Kritisch
Broadcom Emulex Connectivity Division lpfc-Treiber für FC-Adapter Broadcom-ELX-lpfc_14.0.169.26-5vmw.703.0.50.20036589 Fehlerkorrektur Kritisch
LSI NATIVE DRIVERS LSU-Verwaltungs-Plug-In Broadcom-lsiv2-drivers-plugin_1.0.0-12vmw.703.0.50.20036589 Fehlerkorrektur Kritisch
Netzwerktreiber für Adapter der Intel PRO/1000-Familie Intel-ne1000_0.9.0-1vmw.703.0.50.20036589 Fehlerkorrektur Kritisch
USB-Treiber VMware-vmkusb_0.1-7vmw.703.0.50.20036589 Fehlerkorrektur Kritisch
ESXi-Komponente - ESXi-Kern-VIBs ESXi_7.0.3-0.45.20036586 Sicherheit Kritisch
ESXi-Komponente „Installieren/Aktualisieren“ esx-update_7.0.3-0.45.20036586 Sicherheit Kritisch
VMware-VM-Tools VMware-VM-Tools_12.0.0.19345655-20036586 Sicherheit Kritisch

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 VMware Update Manager von einer Version vor ESXi 7.0 Update 2 wird dringend empfohlen, das Rollup-Bulletin in der Patch-Baseline 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

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 Details
ESXi70U3f-20036589 Fehlerkorrektur Kritisch Sicherheit und Fehlerbehebung
ESXi70U3sf-20036586 Sicherheit Kritisch Nur Sicherheit

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.0U3f-20036589-standard
ESXi-7.0U3f-20036589-no-tools
ESXi-7.0U3sf-20036586-standard
ESXi-7.0U3sf-20036586-no-tools

ESXi-Image

Name und Version Datum der Veröffentlichung Kategorie Detail
ESXi70U3f-20036589 12. JUL 2022 Fehlerkorrektur Image für Sicherheit und Fehlerbehebung
ESXi70U3sf-20036586 12. JUL 2022 Sicherheit 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 manuell von VMware Customer Connect herunterladen. Wählen Sie im Dropdown-Menü Produkt auswählen die Option ESXi (eingebettet und installierbar) und im Dropdown-Menü Version auswählen die Option 7.0. Weitere Informationen finden Sie unter Aktualisieren von Hosts mithilfe von ESXCLI-Befehlen und im Handbuch VMware ESXi-Upgrade.

Behobene Probleme

Die behobenen Probleme werden in folgende Kategorien unterteilt.

ESXi_7.0.3-0.50.20036589
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_esxio-combiner_7.0.3-0.50.20036589
  • VMware_bootbank_esx-ui_1.43.8-19798623
  • VMware_bootbank_esx-xserver_7.0.3-0.50.20036589
  • VMware_bootbank_cpu-microcode_7.0.3-0.50.20036589
  • VMware_bootbank_trx_7.0.3-0.50.20036589
  • VMware_bootbank_vsanhealth_7.0.3-0.50.20036589
  • VMware_bootbank_esx-base_7.0.3-0.50.20036589
  • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.3-0.50.20036589
  • VMware_bootbank_gc_7.0.3-0.50.20036589
  • VMware_bootbank_native-misc-drivers_7.0.3-0.50.20036589
  • VMware_bootbank_bmcal_7.0.3-0.50.20036589
  • VMware_bootbank_vsan_7.0.3-0.50.20036589
  • VMware_bootbank_vdfs_7.0.3-0.50.20036589
  • VMware_bootbank_crx_7.0.3-0.50.20036589
Behobene Probleme 2916848, 2817702, 2937074, 2957732, 2984134, 2944807, 2985369, 2907963, 2949801, 2984245, 2911320 , 2915911, 2990593, 2992648, 2905357, 2980176, 2974472, 2974376, 2972059, 2973031, 2967359, 2860126, 2878245, 2876044, 2968157, 2960242, 2970238, 2966270, 2966783, 2963328, 2939395, 2966362, 2946550, 2958543, 2966628, 2961584, 2911056, 2965235, 2952427, 2963401, 2965146, 2963038, 2963479, 2949375, 2961033, 2958926, 2839515, 2951139, 2878224, 2954320, 2952432, 2961346, 2857932, 2960949, 2960882, 2957966, 2929443, 2956080, 2959293, 2944919, 2948800, 2928789, 2957769, 2928268, 2957062, 2792139, 2934102, 2953709, 2950686, 2953488, 2949446, 2955016, 2953217, 2956030, 2949902, 2944894, 2944521, 2911363, 2952205, 2894093, 2910856, 2953754, 2949777, 2925733, 2951234, 2915979, 2904241, 2935355, 2941263, 2912661, 2891231, 2928202, 2928268, 2867146, 2244126, 2912330, 2898858, 2906297, 2912213, 2910340, 2745800, 2912182, 2941274, 2912230, 2699748, 2882789, 2869031, 2913017, 2864375, 2925133, 2965277
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 esxio-combiner, esx-ui, esx-xserver, cpu-microcode, trx, vsanhealth, esx-base, esx-dvfilter-generic-fastpath, gc, native-misc-drivers, bmcal, vsan, vdfs und crx zur Behebung der folgenden Probleme:

  • NEU: PR 2965277: Virtuelle Windows-Maschinen, die verschachtelte Virtualisierung unterstützen und bei denen Virtualization-Based Security (VBS) aktiviert ist, können eine CPU-Nutzung von bis zu 100 % aufweisen.

    Unter bestimmten Bedingungen, z. B. bei einer Erhöhung der gemeinsamen Seitennutzung oder beim Deaktivieren der Nutzung großer Seiten auf VM- oder ESXi-Hostebene, kann die CPU-Nutzung von Windows-VMs, bei denen Virtualization-Based Security (VBS) aktiviert ist, bis zu 100 % erreichen.

    Dieses Problem wurde in der vorliegenden Version behoben. Der Fix verhindert die gemeinsame Seitennutzung in bestimmten Fällen, um das Problem zu vermeiden. 

  • PR 2839515: Python SDK (pyVmomi)-Aufruf von EnvironmentBrowser.QueryConfigOptionEx schlägt mit UnknownWsdlTypeError fehl.

    pyVmomi-Aufrufe der vSphere API EnvironmentBrowser.QueryConfigTargetEx schlagen möglicherweise mit UnknownWsdlTypeError fehl.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2911320: Der Status „Unbekannt“ wird für Sensoren des Typs „Systemereignis“ auf dem Bildschirm zur Überwachung der Hardwareintegrität im vSphere Client angezeigt

    Das Hardwareintegritätsmodul von ESXi kann möglicherweise einige Sensoren des Typs „Systemereignis“ nicht entschlüsseln, wenn ein physischer Server mit einem neuen Branding versehen wird. Infolgedessen wird im vSphere Client der Status „Unbekannt“ für Sensoren des Typs „Systemereignis“ unter Überwachung > Hardwareintegrität angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2910340: Wenn eine virtuelle Maschine während der Migration mit vmx.reboot.powerCycle=TRUE neu gestartet wird, schaltet sie sich möglicherweise nicht ein

    Wenn Sie die erweiterte Einstellung vmx.reboot.powerCycle auf einer virtuellen Maschine auf TRUE festlegen, schaltet sich die virtuelle Maschine aus und dann wieder ein, sobald das Gastbetriebssystem einen Neustart initiiert. Wenn jedoch während einer Migration mithilfe von vSphere vMotion ein Ein-/Ausschalten stattfindet, schlägt der Vorgang fehl, und die virtuelle Maschine auf dem Quellhost wird möglicherweise nicht wieder eingeschaltet.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2916848: ESXi-Hosts fallen möglicherweise aufgrund eines Datenrennens in den UNIX-Domänen-Sockets mit einem violetten Diagnosebildschirm aus

    Wenn bei einem Socket ein Verbindungsfehler auftritt, während er bei der internen Kommunikation zwischen UNIX-Domänen-Sockets abgefragt wird, kann es zu einem Datenrennen kommen. Infolgedessen greift der ESXi-Host in einigen Fällen auf einen ungültigen Arbeitsspeicherbereich zu und fällt mit einem violetten Diagnosebildschirm mit #PF Exception 14 und Fehlern wie UserDuct_PollSize() und UserSocketLocalPoll() aus.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2891231: Sie können kein Hostprofil von einem ESXi-Host erstellen, der einen Hardware-iSCSI-Adapter mit Pseudo-Netzwerkschnittstellenkarten verwendet

    Wenn ein Hardware-iSCSI-Adapter auf einem ESXi-Host in Ihrer Umgebung Pseudo-Netzwerkschnittstellenkarten verwendet, können Sie möglicherweise kein Hostprofil von einem solchen Host erstellen, da Pseudo-Netzwerkschnittstellenkarten nicht über die erforderliche PCI-Adresse und den Anbieternamen für ein Profil verfügen.

    Dieses Problem wurde in der vorliegenden Version behoben. Für Pseudo-Netzwerkschnittstellenkarten sind durch die Behebung keine PCI-Adressen- und PCI-Anbieternamenwerte mehr erforderlich.

  • PR 2898858: Virtuelle Maschinen reagieren möglicherweise aufgrund zugrunde liegender Speicherprobleme auf einem Software-iSCSI-Adapter nicht mehr

    Race-Bedingungen im iscsi_vmk-Treiber können zu blockierten E/A-Vorgängen oder Taktsignal-Zeitüberschreitungen bei einem VMFS-Datenspeicher führen. Dies kann dazu führen, dass einige virtuelle Maschinen nicht mehr reagieren.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2792139: Der Durchsatz mit Software-iSCSI-Adaptern ist aufgrund hartcodierter Sende- und Empfangspuffergrößen begrenzt

    Der Durchsatz mit Software-iSCSI-Adaptern ist aufgrund hartcodierter Sende- und Empfangspuffergrößen – 600 KB für Sende- bzw. 256 KB für Empfangspuffer – begrenzt. Dies führt dazu, dass die Leistung des iscsi_vmk-Adapters nicht optimal ist.

    Dieses Problem wurde in der vorliegenden Version behoben. Durch den Fix werden die Sende- und Empfangspuffergrößen für iSCSI-Verbindungen zu anpassbaren Parametern. Sie können die Größe des Sendepuffers mithilfe des ESXCLI-Befehls esxcli system settings advanced set -o /ISCSI/SocketSndBufLenKB -i <your size> mit einem Grenzwert von 6144 KB festlegen. Sie können die Größe des Empfangspuffers mithilfe des Befehls esxcli system settings advanced set -o /ISCSI/SocketRcvBufLenKB -i  <your size> mit einem Grenzwert von 6144 KB festlegen.

  • PR 2904241: Bei virtuellen Maschinen mit aktivierter virtueller NVIDIA-GPU (vGPU) werden beim Ausschalten der VM möglicherweise nicht alle GPU-Ressourcen mit mehreren Instanzen gelöscht

    Wenn mehrere NVIDIA vGPU-VMs gleichzeitig ausgeschaltet werden, werden gelegentlich einige GPU-Ressourcen (MIG) mit mehreren Instanzen nicht gelöscht. Dies kann dazu führen, dass das Einschalten der nachfolgenden vGPU-VM aufgrund der verbleibenden MIG-Ressourcen fehlschlägt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2944894: Virtuelle Maschinen auf NFSv4.1-Datenspeichern reagieren während eines Speicher-Failovers einige Sekunden lang nicht mehr

    Wenn ein NFSv4.1-Server während eines Speicher-Failovers einen vorübergehenden Fehler zurückgibt, können in seltenen Fällen virtuelle Maschinen 10 Sekunden lang nicht reagieren, bevor der Vorgang neu gestartet wird.

    Dieses Problem wurde in der vorliegenden Version behoben. Die Korrektur reduziert die Wartezeit für die Wiederherstellung während des Speicher-Failovers.

  • PR 2916980: Ein ESXi-Host fällt möglicherweise mit einem violetten Diagnosebildschirm aus, weil ein Paket an einem anderen Portset abgeschlossen wurde

    In seltenen Fällen kann es vorkommen, dass der Paketabschluss nicht am ursprünglichen Port oder Portset, sondern an einem anderen Portset erfolgt, was zu einer Schleife führen kann, die die Paketliste mit einem ungültigen Zeiger beschädigt. Infolgedessen fällt ein ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm aus. In den Protokollen wird beispielsweise folgender Fehler angezeigt: PF Exception 14 in world 61176327:nsx.cp.tx IP 0xxxxxx addr 0x3c.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2925733: In der vSphere API zählt das Feld „memoryRangeLength“ von „NumaNodeInfo“ nicht immer den gesamten Arbeitsspeicher im zugehörigen NUMA-Knoten des ESXi-Hosts

    Der Arbeitsspeicher im NUMA-Knoten eines ESXi-Hosts besteht möglicherweise aus mehreren physischen Bereichen. In ESXi-Versionen vor 7.0 Update 3f gibt das Feldpaar memoryRangeBegin, memoryRangeLength in NumaNodeInfo die physikalische Startadresse des Hosts und die Länge des Bereichs im NUMA-Knoten an, wobei alle zusätzlichen Bereiche ignoriert werden.

    Dieses Problem wurde in der vorliegenden Version behoben. Das Feld memoryRangeLength wird auf die Gesamtmenge des Arbeitsspeichers im NUMA-Knoten festgelegt, die über alle physischen Bereiche summiert wird. Das Feld memoryRangeBegin ist auf 0 festgelegt, da diese Informationen bei mehreren Bereichen nicht aussagekräftig sind. 

  • PR 2932736: Wenn Sie den schnellen Pfad für das Hochleistungs-Plug-In (High-Performance Plug-in, HPP) für 512e Software Emulated 4KN-Geräte aktivieren, schlagen E/A-Vorgänge möglicherweise fehl

    Wenn Sie den schnellen Pfad auf HPP für 512e Software Emulated 4KN-Geräte aktivieren, funktioniert er nicht wie erwartet, da der schnelle Pfad nicht mit Read-Modify-Write(R-M-W) umgehen kann, das den langsamen Pfad verwenden muss. Die Verwendung des schnellen Pfads auf 4KN-Geräten wird nicht unterstützt.

    Dieses Problem wurde in der vorliegenden Version behoben. Der Fix stellt sicher, dass die Einstellung auch dann ignoriert wird, wenn der schnelle Pfad für 512e Software Emulated 4KN-Geräte aktiviert ist und die E/A-Vorgänge den langsamen Pfad nehmen.

  • PR 2860126: Beim Löschen von Snapshots großer virtueller Festplatten wird eine ausgeführte VM möglicherweise vorübergehend eingefroren

    Wenn Sie über eine ausgeführte VM mit virtuellen Festplatten mit mehr als 1 TB verfügen und einen Snapshot der Festplatten auf dieser VM löschen, friert die VM möglicherweise für Sekunden oder sogar Minuten ein. Die VM wird letztendlich wiederhergestellt, bei VM-Arbeitslasten können jedoch Ausfälle auftreten. Das Problem tritt auf, weil der Löschvorgang die Konsolidierung von Snapshots im Hintergrund auslöst, was die Verzögerung verursacht. Das Problem tritt eher bei langsamerem Speicher auf, wie z. B. NFS.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2875070: ESXi-Hosts fallen möglicherweise aufgrund falsch verarbeiteter DVFilter-Pakete mit einem violetten Diagnosebildschirm aus

    DVFilter-Pakete werden möglicherweise fälschlicherweise an einen Netzwerkport übertragen, an dem der Paketabschlusscode nicht ausgeführt werden kann. Infolgedessen fallen ESXi-Hosts mit einem violetten Diagnosebildschirm und dem Fehler PF Exception 14 Vmxnet3VMKDevTxCompleteOne E1000DevTxCompleteOneWork aus.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2883317: Virtuelle Maschinen verlieren möglicherweise zeitweise die Konnektivität aufgrund eines seltenen Problems mit der verteilten Firewall (DFW)

    In seltenen Fällen sendet die DFW möglicherweise eine Paketliste an das falsche Portset. Dies kann dazu führen, dass der VMkernel-Dienst fehlschlägt und virtuelle Maschinen die Konnektivität verlieren. In der Datei vmkernel.log werden Fehler ähnlich dem Folgenden angezeigt:
    2021-09-27T04:29:53.170Z cpu84:xxxx)NetPort: 206: Fehler: lockModel[0] vs psWorldState->lockModel[0] there is no portset lock holding.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2944521: Sie können vom Hochleistungs-Plug-In (High-Performance Plug-In, HPP) beanspruchte Geräte nicht umbenennen

    Ab vSphere 7.0 Update 2 wird HPP das Standard-Plug-In für lokale NVMe- und SCSI-Geräte und ersetzt das native Multipathing-Plug-In (NMP) von ESX. In bestimmten Umgebungen führt die Änderung von NMP zu HPP jedoch dazu, dass auf einige Eigenschaften von Geräten, die von HPP beansprucht werden, wie z. B. den Anzeigenamen, nicht zugegriffen werden kann.

    Dieses Problem wurde in der vorliegenden Version behoben. 

  • PR 2945697: Auf einem ESXi-Host werden möglicherweise veraltete Pfadstatus zu ALUA-Geräten angezeigt

    Wenn in einem ALUA-Ziel die Zielportgruppen-IDs (TPGIDs) für eine LUN geändert werden, wird die vom SATP verwendete Antwort zur Geräteidentifikation im Cache möglicherweise nicht entsprechend aktualisiert. Dies führt dazu, dass ESXi möglicherweise nicht die korrekten Pfadstatus für das entsprechende Gerät wiedergibt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2946036: RTPG für alle Pfade zu einem Volume meldet denselben ALUA-Zugriffsstatus für Geräte, die mithilfe der NVMe-SCSI-Übersetzung auf einer LUN registriert wurden

    Wenn Sie den NVMe-SCSI-Übersetzungs-Stack zum Registrieren von NVMe-Geräten in Ihrem System verwenden, erhalten die Eigenschaften targetPortGroup und relativeTargetPortId die Controller-ID 0 für alle Pfade. Dies führt dazu, dass ein RTPG-Befehl denselben ALUA-Zugriffsstatus für alle Pfade des Namespace zurückgibt, da die tpgID jedes Pfads mit dem ersten Deskriptor übereinstimmt, der 0 ist.

    Dieses Problem wurde in der vorliegenden Version behoben. Wenn Sie Plug-Ins von Drittanbietern verwenden und in den tpg-Deskriptoren keine tpgID für den Pfad vorhanden ist (eine leere ANA-Seite für den Controller), müssen Sie den RTPG-Befehl in diesem bestimmten Pfad ausführen, um die ANA-Seite für diesen Controller aufzufüllen und den tpg-Deskriptor und ALUA-Status für den Pfad abzurufen.

  • PR-2943674: Die Integritätsprüfung des vSAN-Dateidiensts gibt eine Warnung aus, nachdem das Kennwort der AD-Benutzerdomäne geändert wurde: Dateiserver nicht gefunden

    Wenn das Kennwort für den Administrator des Dateidiensts auf dem Active Directory-Server geändert wird, stimmt das Kennwort in der Domänenkonfiguration des vSAN-Dateidiensts möglicherweise nicht überein. Wenn die Kennwörter nicht übereinstimmen oder das Konto gesperrt ist, kann möglicherweise auf einige Dateifreigaben nicht zugegriffen werden. Der vSAN-Integritätsdienst zeigt die folgende Warnung an: Dateidienst: Dateiserver nicht gefunden.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2944919: In vSphere Virtual Volumes-Datenspeichern werden VM-Festplatten (VMDK) mit veralteter Bindung angezeigt

    Wenn Sie einen ESXi-Host nach einem Ausfall neu installieren, bleiben veraltete Bindungen von VMDKs beim VASA-Anbieter und in den vSphere Virtual Volumes-Datenspeichern intakt, da die ausgefallene Instanz nie neu gestartet wird. Infolgedessen können Sie bei einer Neuinstallation des Hosts die VMDKs aufgrund der vorhandenen Bindung nicht löschen. Im Laufe der Zeit können sich viele solche VMDKs ansammeln und ungenutzten Speicherplatz verbrauchen.

    Dieses Problem wurde in der vorliegenden Version behoben. Sie müssen sich jedoch an VMware Global Support Services wenden, um die Aufgabe zu implementieren.

  • PR 2912213: Der hostd-Dienst schlägt möglicherweise wiederholt auf virtuellen Maschinen mit seriellen Geräten fehl, bei denen die Eigenschaft „fileName“ fehlt und die Eigenschaft „serial.autodetect“ auf „FALSE“ eingestellt ist.

    In seltenen Fällen verfügt ein serielles Gerät auf einer virtuellen Maschine nicht über die Eigenschaft serial<N>.fileName, während gleichzeitig die Eigenschaft serial<N>.autodetect auf FALSE festgelegt ist. Dies kann dazu führen, dass der hostd-Dienst wiederholt fehlschlägt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2951234: Wenn Sie eine Option des Traffic-Shaping-Richtlinien-Switches oder der Portgruppenebene mit einer Größe von mehr als 2147483 KBit/s festlegen, werden die Einstellungen nicht gespeichert

    Wenn Sie im vSphere Client eine der Traffic-Shaping-Optionen wie „Durchschnittliche Bandbreite“, „Spitzenbandbreite“ oder „Burstgröße“ auf einen Wert festlegen, der größer als 2147483 KBit/s ist, werden die Einstellungen nicht beibehalten.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR-2945707: vSphere vMotion-Vorgänge schlagen nach dem Upgrade auf ESXi 7.x für Umgebungen fehl, die mit vSphere APIs for Array Integration (VAAI) für Network-Attached Storage (NAS) konfiguriert sind

    Aufgrund der geringen Standardanzahl an Dateideskriptoren können einige Funktionen wie vSphere vMotion nach dem Upgrade auf ESXi 7.x in VAAI für NAS-Umgebungen wegen der unzureichenden Anzahl an VMDK-Dateien, die gleichzeitig ausgeführt werden können, fehlschlagen. In der Datei syslog.log werden Fehler wie Zu viele offene Dateien in den Protokollen des vaai-nas-Daemon angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben. Die Standardanzahl der Dateideskriptoren beträgt maximal 64.000 von derzeit 256.

  • PR 2952427: Virtuelle Maschinen reagieren aufgrund eines Deadlock-Problems auf einem VMFS6-Volume möglicherweise nicht mehr

    Wenn in seltenen Fällen eine E/A-Anforderung parallel mit einem vom Gastbetriebssystem ausgelösten Aufhebevorgang auf einer Thin-Provisioning-VM ausgeführt wird, kann es in manchen Fällen zu einem Deadlock auf einem VMFS6-Volume kommen. Folglich reagieren virtuelle Maschinen auf diesem Volume nicht mehr.

    Dieses Problem wurde in der vorliegenden Version behoben. 

  • PR-2876044: vSphere Storage vMotion- oder Hot-Add-Vorgänge (Hinzufügen im laufenden Betrieb) schlagen auf virtuellen Maschinen mit einer virtuellen Arbeitsspeichergröße von mehr als 300 GB möglicherweise fehl

    Bei vSphere Storage vMotion- oder Hot-Add-Vorgängen auf einer virtuellen Maschine mit mehr als 300 GB Arbeitsspeicher kann sich die Switchover-Zeit 2 Minuten nähern, was zu einem Zeitüberschreitungsfehler führt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2952003: Während des Startvorgangs können iSCSI-Konfigurationen möglicherweise nicht wiederhergestellt werden, und nach dem Start werden einige LUNs oder Datenspeicher nicht angezeigt

    Wenn Sie die Port-Bindung nicht entfernen, nachdem Sie eine VMkernel-Netzwerkkarte gelöscht haben, die an einen iSCSI-Adapter gebunden ist, kann die veraltete Port-Bindung Probleme nach einem Neustart des ESXi-Hosts verursachen. Während des Startvorgangs schlägt die Bindung der nicht vorhandenen VMkernel-Netzwerkkarte an den iSCSI-Adapter fehl, und iSCSI-Konfigurationen können während des Startvorgangs nicht wiederhergestellt werden. Infolgedessen werden nach Abschluss des Neustarts möglicherweise einige LUNs oder Datenspeicher nicht angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben. 

  • PR 2957062: NFSv4.1-Datenspeicher verbleibt nach einem Speicher-Failover im Status „Kein Zugriff“

    Nach einem Speicher-Failover erkennt der ESXi NFSv4.1-Client den NFS-Server fälschlicherweise als eine andere Einheit und überspringt die Wiederherstellung. Dies führt dazu, dass der NFSv4.1-Datenspeicher im Status Kein Zugriff verbleibt.

    Dieses Problem wurde in der vorliegenden Version behoben. Mit dem Fix wird sichergestellt, dass der NFSv4.1-Client den NFS-Server nach einem Failover erkennt.

  • PR 2961033: Wenn ein NVMe-Gerät eine kritische Warnung meldet, schlägt die Initialisierung bei ESXi fehl, und das Gerät wird offline geschaltet

    In einigen Fällen, z. B. wenn die Temperatur den Schwellenwert überschreitet, meldet ein NVMe-Gerät möglicherweise eine kritische Warnung, und der ESXi NVMe-Controller registriert das Gerät nicht und schaltet es offline.

    Dieses Problem wurde in der vorliegenden Version behoben. Mit dem Fix wird sichergestellt, dass NVMe-Geräte unabhängig von kritischen Warnungen beim ESXi NVMe-Controller registriert werden. Wenn sich das Gerät in einem fehlerhaften Zustand und nicht in einem vorübergehenden Zustand befindet, beispielsweise hohe Temperatur, muss die Firmware des NVMe-Controllers bei der Verarbeitung eines E/A-Admin-Befehls entsprechende Fehlercodes senden.

  • PR 2928202: Sie können im vSAN-Dateidienst auf einige Freigaben nicht zugreifen, und es werden Warnungen vom VDFS-Daemon angezeigt

    Ein seltenes Problem, bei dem der verwendete Block-Cache den reservierten Cache überschreitet, kann zu Reservierungsproblemen im vSAN-Dateidienst führen. Infolgedessen können Sie einige Dateifreigaben nicht erreichen, und die Integritätsprüfung zeigt den Fehler VDFS-Daemon wird nicht ausgeführt. Im vdfsd-server-Protokoll werden Fehler ähnlich dem Folgenden angezeigt:
    PANIC: NOT_IMPLEMENTED bora/vdfs/core/VDFSPhysicalLog.cpp:621
    PANIC: NOT_IMPLEMENTED bora/vdfs/core/VDFSPhysicalLog.cpp:626

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2949902: OVF-Dateien werden möglicherweise unerwartet geändert, und virtuelle Maschinen können nicht importiert werden

    In seltenen Fällen können Suchabfragen im Hintergrund, die von vCenter Server auf einem ESXi-Host mit Zugriff auf die VMDK-Dateien virtueller in ein OVF-Format exportierter Maschinen ausgeführt werden, die Dateien versehentlich ändern. Infolgedessen können Sie die virtuellen Maschinen nicht importieren.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2963401: Sie können keine Multipathing-PSA-Beanspruchungsregel mithilfe des JumpStart-Tools hinzufügen

    Aufgrund eines Komponentenlastproblems schlägt das Hinzufügen einer Multipathing-PSA-Beanspruchungsregel zum Satz von Beanspruchungsregeln auf einem vCenter Server-System unter Verwendung des JumpStart-Tools möglicherweise fehl.

    Dieses Problem wurde in der vorliegenden Version behoben. Mit dem Fix wird sichergestellt, dass alle erforderlichen Komponenten geladen werden, um die Verwendung des JumpStart-Tools zu aktivieren.

  • PR 2965235: LUN-Trespasses können in ALUA-Arrays (Asymmetric Logical Unit Access) beim Herunterfahren oder Starten von ESXi 7-Hosts auftreten

    Nach einem kontrollierten Herunterfahren oder Starten eines Servers in einem Cluster von ESXi-Servern, die mit einem ALUA-Array verbunden sind, werden alle LUNs, auf die dieser Server Zugriff hat, möglicherweise auf einen Speicherprozessor im Array übertragen. Infolgedessen verschlechtert sich die Leistung der anderen ESXi-Server, die auf die LUNs zugreifen.

    Dieses Problem wurde in der vorliegenden Version behoben. Durch die Behebung wird eine Prüfung hinzugefügt, bevor der letzte Pfad auf dem Ziel während der Abschaltphase aktiviert wird, um LUN-Trespassing zu verhindern.

  • PR 2966783: ESXi-Host fällt möglicherweise aufgrund eines seltenen Fehlers bei der Arbeitsspeicherzuteilung durch PSA mit einem violetten Diagnosebildschirm aus

    Bei einer hohen Arbeitsspeicherbelastung eines ESXi-Hosts verarbeitet PSA in seltenen Fällen Fehler bei der Arbeitsspeicherzuteilung nicht ordnungsgemäß. Infolgedessen fällt der ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm und einem Fehler wie #PF Exception 14 in world 2098026:SCSI path sc IP / SCSI path scan helpers aus.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2984134: Wenn eine virtuelle Maschine neu gestartet wird, während ein Snapshot gelöscht wird, fällt die VM möglicherweise mit einem Core-Dump aus

    Wenn eine ausgeführte virtuelle Maschine während eines Snapshot-Löschvorgangs neu gestartet wird, werden die VM-Festplatten möglicherweise während der Snapshot-Konsolidierung nicht ordnungsgemäß neu geöffnet und geschlossen. Infolgedessen fällt die VM möglicherweise aus. Dies ist jedoch ein Zeitproblem, das versehentlich auftritt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2929443: Das Mounten von VMFS6-Datenspeichern mit aktivierter Cluster-VMDK-Unterstützung schlägt möglicherweise zufällig fehl

    Während der Geräteerkennung kann ein Reservierungskonflikt dazu führen, dass ATS fälschlicherweise als nicht unterstützt gemeldet wird. Aus diesem Grund verwendet ESXi die SCSI-2-Reservierung anstelle von ATS. Dies führt dazu, dass das Mounten von VMFS6-Datenspeichern mit aktivierter Cluster-VMDK-Unterstützung möglicherweise zufällig fehlschlägt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR-2957732: vSAN-Dateidienstserver können nach einer Host-UUID-Änderung nicht gestartet werden

    Bei einigen Vorgängen kann die Host-UUID geändert werden. Wenn Sie beispielsweise ESXi-Software neu installieren oder den Host zwischen Clustern verschieben, kann sich die Host-UUID gegebenenfalls ändern. Wenn sich die Host-UUID während des Ausfalls des vSAN-Dateidiensts ändert, können vSAN-Dateidienstserver nicht gestartet werden.

    Dieses Problem wurde in der vorliegenden Version behoben. 

  • PR-2955688: Der vSAN-Dateidienst funktioniert möglicherweise nicht wie erwartet, nachdem er deaktiviert und erneut aktiviert wurde

    Wenn Sie den vSAN-Dateidienst ohne vorhandene Dateifreigaben deaktivieren, entfernt vSAN die Dateidienstdomäne. Ein Entfernungsfehler eines Servers unterbricht möglicherweise den Prozess und hinterlässt einige Metadaten. Wenn Sie den Dateidienst erneut aktivieren, funktioniert der Dateidienst aufgrund der alten Metadaten möglicherweise nicht wie erwartet.

    Dieses Problem wurde in der vorliegenden Version behoben. 

  • PR 2965146: Der vom Befehl „Zielportgruppen des SCSI-Berichts“ zurückgegebene Wert IMPLIZITE ÜBERGANGSZEIT ist möglicherweise nicht korrekt

    Der Befehl „Zielportgruppen des Berichts“ gibt möglicherweise im Feld IMPLIZITE ÜBERGANGSZEIT einen falschen Wert zurück, was sich auf die SCSI-zu-NVMe-Übersetzungsschicht auswirkt. In Fällen wie der Migration mehrerer Appliances ist die Zeit für den ALUA-Übergang für Multipathing-Software, beispielsweise PowerPath, zur Durchführung korrekter Vorgänge von entscheidender Bedeutung.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2992648: Hohe Latenzen nach Neustart oder erneutem Mounten der Festplattengruppe beobachtet

    Kleine ausstehende Zuordnungsaufhebungen werden möglicherweise blockiert, wenn Sie einen Host neu starten oder eine Festplattengruppe erneut mounten. Die ausstehenden Zuordnungsaufhebungen können zu einer Protokollüberlastung führen, die E/A-Latenz zur Folge hat.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2964856: Pfad zum Verzeichnis /productLocker auf einem Datenspeicher wird nach dem Patchen von ESXi 7.x gekürzt

    Nach dem ersten Upgrade oder Update Ihres Systems auf ESXi 7.x findet bei jedem nachfolgenden Update, das auch als Patch bezeichnet wird, möglicherweise eine Kürzung der Angaben im Pfad zum Verzeichnis /productLocker in einem Datenspeicher statt. Wenn Ihr erster Patch auf ESXi 7.x beispielsweise von 7.0 Update 2 zu 7.0 Update 3 führt, ist das Verzeichnis /productLocker ursprünglich dem Verzeichnis /vmfs/volumes/xxx/VMware-Tools/productLocker/ ähnlich. Für jeden nachfolgenden Patch, z. B. von 7.0 Update 3 auf 7.0 Update 3c, ähnelt der Pfad jedoch /VMware-Tools/productLocker/.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2963038: Nicht zugängliches Objekt in einem vSAN Stretched Cluster oder einem Cluster mit zwei Knoten

    In einem vSAN Stretched Cluster oder einem Cluster mit zwei Knoten werden quorumbasierte Entscheidungen für Objekte mit PFTT von 1 und SFTT von 1 oder mehr möglicherweise nicht ordnungsgemäß verteilt. Wenn eine Site ausfällt und ein zusätzlicher Host oder eine zusätzliche Festplatte auf der aktiven Site ausfällt, verliert das Objekt möglicherweise das Quorum, und es kann nicht mehr darauf zugegriffen werden.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2961832: ESXi-Hosts fallen möglicherweise beim Ändern der Größe einer nicht auf 512 Byte ausgerichteten VMDK aus

    Eine Anforderung zur Größenänderung eines Objekts kann fehlschlagen, wenn die neue Größe nicht auf 512 Byte ausgerichtet ist. Dieses Problem kann dazu führen, dass ein ESXi-Host mit einem violetten Diagnosebildschirm ausfällt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2935355: Möglicherweise wird auf einem ESXi-Host ein erhöhter CPU-Verbrauch aufgrund eines Verlusts des Dienstprogramms PacketCapture (pktcap-uw) angezeigt

    In einigen Fällen, z. B. beim Neustart einer virtuellen Maschine, kann eine laufende SSH-Sitzung, die das Dienstprogramm „pktcap-uw“ zur Überwachung und Validierung von Switch-Konfigurationen auf dem ESXi-Host verwendet, beendet werden. Das Dienstprogramm „pktcap-uw“ versucht möglicherweise weiterhin, Pakete zu verarbeiten. Dies führt dazu, dass das Dienstprogramm mehr CPU verbraucht als normal. Mit dem Befehl esxtop -a können Sie die CPU-Leistung nachverfolgen.

    Dieses Problem wurde in der vorliegenden Version behoben. Der Fix verhindert Verluste durch das Dienstprogramm pktcap-uw, die zu einem erhöhten CPU-Verbrauch führen. Mit dem Befehl ps -u | grep pktcap können Sie feststellen, ob ein Prozess des Dienstprogramms „pktcap-uw“ im Hintergrund ausgeführt wird, obwohl sich dies nicht auf die CPU-Leistung auswirkt. Wenn ein Zombie-Prozess weiterhin ausgeführt wird, können Sie den Befehl kill -9 verwenden, um ihn zu beenden.

  • PR-2973031: vSAN-Integritätsprüfung zeigt ein zertifiziertes NVMe-Gerät als nicht zertifiziert an

    Auf einem vCenter Server unter 7.0 Update 3 kann ein zertifiziertes NVMe-Gerät die folgende Warnung für die Integritätsprüfung aufweisen: NVMe-Gerät ist nicht für VMware zertifiziert. Möglicherweise wird auch die folgende Integritätsprüfungswarnung angezeigt: NVMe-Gerät kann nicht identifiziert werden.

    Dieses Problem wurde in der vorliegenden Version behoben. 

  • PR 2968157: Der ESXCLI-Befehl „hardware ipmi bmc get“ gibt die IPv6-Adresse eines IPMI Baseboard Management Controllers (BMC) nicht zurück

    Der ESXCLI-Befehl hardware ipmi bmc get gibt aufgrund einer falschen Analyse die IPv6-Adresse eines BMC nicht zurück.

    Dieses Problem wurde in dieser Version behoben.

  • PR 2963328: Der Assistent zum Herunterfahren fällt für einen vSAN Stretched Cluster oder einen vSAN-Cluster mit zwei Knoten mit dem folgenden Fehler aus: Getrennter Host von Orch gefunden

    Wenn der Zeugenhost von Clusterhosts nicht erreicht werden kann, fällt der Assistent zum Herunterfahren des vSAN-Clusters für einen Stretched Cluster oder einen Cluster mit zwei Knoten möglicherweise aus. Dieses Problem tritt auf, wenn für den vSAN-Datenverkehr und den Zeugen-Datenverkehr verschiedene vmknics verwendet werden. Im vSphere Client wird die folgende Fehlermeldung auf der Seite „vSAN-Dienste“ angezeigt: Getrennter Host von Orch gefunden <Zeugen-IP>. Wenn vCenter im Cluster gehostet wird, ist der vSphere Client beim Herunterfahren nicht verfügbar, und die Fehlermeldung wird auf dem Host Client angezeigt, auf dem sich die vCenter-VM befindet.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2882789: Beim Durchsuchen eines vSphere Virtual Volumes-Datenspeichers wird die UUID einiger virtueller Maschinen anstelle ihres Namens angezeigt

    Wenn Sie im vSphere Client mit der rechten Maustaste klicken, um einen Datenspeicher zu durchsuchen, wird anstelle der Namen möglicherweise die UUID einiger virtueller Maschinen in einem vSphere Virtual Volumes-Datenspeicher angezeigt, wie z. B. naa.xxxx. Dieses Problem tritt nur selten in großen Umgebungen mit einer großen Anzahl von Containern und VMs in einem vSphere Virtual Volumes-Datenspeicher auf. Das Problem hat keine funktionalen Auswirkungen, wie z. B. Auswirkungen auf VM-Vorgänge, Sicherungen oder andere Elemente als die VM-Anzeige im vSphere Client.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2928268: Ein seltenes Problem im Zusammenhang mit der ESXi-Infrastruktur kann dazu führen, dass ESXi-Hosts nicht mehr reagieren

    Aufgrund eines seltenen Problems im Zusammenhang mit der ESXi-Infrastruktur kann ein langsamer VASA-Anbieter eine Situation auslösen, in der auf die vSphere Virtual Volumes-Datenspeicher nicht zugegriffen werden kann und der ESXi-Host nicht mehr reagiert.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2946550: Wenn Sie einen ESXi-Host herunterfahren, wird er nicht ausgeschaltet, und es wird eine Fehlermeldung angezeigt

    Wenn Sie in bestimmten Umgebungen einen ESXi-Host herunterfahren, wird dieser nicht ausgeschaltet, und es wird ein Bildschirm mit der Meldung Dieses System wurde angehalten angezeigt. Mit der Schaltfläche zum Zurücksetzen oder zum Ein-/Ausschalten kann ein sicherer Neustart durchgeführt werden.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2949777: Wenn die Einstellung LargeBAR eines vmxnet3-Geräts auf ESX 7.0 Update 3 und höher aktiviert ist, verlieren virtuelle Maschinen möglicherweise die Konnektivität

    Die Einstellung LargeBAR, die das Basisadressregister (Base Address Register, BAR) auf einem vmxnet3-Gerät erweitert, unterstützt einheitliches Passthrough (Uniform Passthrough, UPT). UPT wird jedoch unter ESX 7.0 Update 3 und höher nicht unterstützt, und wenn der vmxnet3-Treiber auf eine Version vor 7.0 herabgestuft wird und die Einstellung LargeBAR aktiviert ist, verlieren die virtuellen Maschinen möglicherweise die Konnektivität.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2984245: Redundante Redo-Protokolldateien belegen erheblichen Speicherplatz

    Wenn Sie unabhängige, nicht dauerhafte Festplatten im laufenden Betrieb von einer virtuellen Maschine entfernen, für die der Konfigurationsparameter vmx.reboot.PowerCycle aktiviert ist, speichert ESXi eine Redo-Protokolldatei. Wenn es sich bei einer solchen VM um eine Sicherungs-Proxy-VM handelt, werden möglicherweise viele redundante Redo-Protokolldateien angezeigt, die einen erheblichen Teil des Speichers in Anspruch nehmen.

    Problemumgehung: Deaktivieren Sie den Parameter vmx.reboot.PowerCycle auf den Backup-Proxy-VMs entweder durch Ein-/Ausschalten der VM oder mit dem Cmdlet PowerCLI Set-AdvancedSetting. Löschen Sie die redundanten Redo-Protokolldateien.

  • PR 2939395: ESXi-Hosts fallen zeitweise mit einem violetten Diagnosebildschirm mit einem Speicherabbild aus, das die J3_DeleteTransaction- und J6ProcessReplayTxnList-Fehler anzeigt

    Wenn ein ESXi-Host versucht, über einen Ressourcenpool-Cache auf einen nicht im Cache enthaltenen Eintrag zuzugreifen, fällt der Host zeitweise mit einem violetten Diagnosebildschirm PF Exception 14 und einer Core-Dump-Datei aus. In der Dump-Datei werden Fehler für die Module J3_DeleteTransaction und J6ProcessReplayTxnList angezeigt, die auf das Problem hinweisen.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2952432:  ESXi-Hosts reagieren möglicherweise aufgrund eines seltenen Problems mit VMFS, das zu einem hochgradigen Sperrungskonflikt bei hostd-Dienst-Threads führt, nicht mehr

    Ein seltenes Problem im Zusammenhang mit VMFS kann bei grundlegenden Dateisystemaufrufen wie open, access oder rename zu hochgradigen Sperrungskonflikten bei hostd-Dienst-Threads oder sogar zu Deadlocks führen. Folglich reagiert der ESXi-Host nicht mehr.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2960882: Wenn MD5 als Authentifizierungsprotokoll in einer ESXi-SNMP-Agent-Konfiguration verwendet wird, schlagen Upgrades auf ESXi 7.x möglicherweise fehl

    Da das MD5-Authentifizierungsprotokoll ab ESXi 7.x nicht mehr unterstützt wird, schlagen Upgrades auf ESXi 7.x fehl, wenn für eine ESXi-SNMP-Agent-Konfiguration das MD5-Authentifizierungsprotokoll verwendet wird.

    Dieses Problem wurde in der vorliegenden Version behoben. Mit dem Fix wird das MD5-Authentifizierungsprotokoll entfernt, und es wird eine VOB-Meldung (VMkernel Observation) angezeigt, wie z. B. Upgrade hat ein schwaches Verschlüsselungsprotokoll (MD5) erkannt und entfernt. Generieren Sie v3-Benutzer neu.

  • PR 2957966: Leerzeichen im Parameter „Syslog.global.logHost“ haben möglicherweise zur Folge, dass Upgrades auf ESXi 7.x fehlschlagen

    In ESXi 7.x toleriert der Parameter Syslog.global.logHost, der eine kommagetrennte Liste von Remote-Hosts und Spezifikationen für Nachrichtenübertragungen definiert, keine Leerzeichen nach dem Komma. ESXi-Versionen vor 7.x tolerieren im Parameter Syslog.global.logHost ein Leerzeichen nach dem Komma. Dies kann dazu führen, dass Upgrades auf ESXi 7.x fehlschlagen.

    Dieses Problem wurde in der vorliegenden Version behoben. Der Fix lässt Leerzeichen nach dem Komma zu.

  • PR 2967359: Möglicherweise wird ein logischer, konsistenzbasierter E/A-Fehler für virtuelle Maschinen angezeigt, die in einem Snapshot ausgeführt werden

    Ein Problem im Zusammenhang mit der probabilistischen Datenstruktur „Bloom-Filter“, die die Lese-E/A für in einem Snapshot ausgeführte VMs optimieren soll, kann zu einem logischen, konsistenzbasierten E/A-Fehler führen, wenn die VM auf einem Snapshot ausgeführt wird. Das Problem ist begrenzt und tritt nur auf, wenn Sie SQL Server in einem Snapshot ausführen.

    Dieses Problem wurde in der vorliegenden Version behoben. Der Fix deaktiviert die Verwendung des Bloom-Filters, bis die Hauptursache des Problems behoben ist.

  • PR 2974376: ESXi-Hosts fallen aufgrund einer seltenen CPU-Sperre mit einem violetten Diagnosebildschirm mit einem NMI-Fehler aus

    Ein Problem mit dem Prozess, der Datenspeicher zur Unterstützung von Dateiblockzuteilungen für Thin-Dateien prüft, kann in bestimmten Fällen zu einer CPU-Sperre führen. Dies führt dazu, dass der ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm und einer Fehlermeldung ähnlich der folgenden ausfällt: PSOD - @BlueScreen: NMI.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2905357: In den hostd-Protokolldateien werden ungewöhnlich viele Meldungen vom Typ „Task Created“ und „Task Completed“ angezeigt

    Die Protokolldateien des hostd-Diensts erhalten möglicherweise eine ungewöhnlich hohe Anzahl von Meldungen des Typs Task Created und Task Completed für unsichtbare Aufgaben, was wiederum die Aufbewahrungszeit für Protokolle verringern kann. 

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2956080: Lese- und Schreibvorgänge in einem vSphere Virtual Volumes-Datenspeicher schlagen möglicherweise fehl

    Wenn ein SCSI-Befehl für einen Protokollendpunkt eines vSphere Virtual Volumes-Datenspeichers fehlschlägt, erhält der Endpoint möglicherweise den Status „Nicht unterstützt“, der möglicherweise zwischengespeichert wird. Dies führt dazu, dass die folgenden an diesen Protokollendpunkt gerichteten SCSI-Befehle mit einem Fehlercode wie 0x5 0x20 fehlschlagen und Lese- und Schreibvorgänge in einem vSphere Virtual Volumes-Datenspeicher fehlschlagen.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2985369: Wenn der NVMe-Controller den Status FEHLGESCHLAGEN meldet, geht möglicherweise die Konnektivität zu ESXi-Hosts verloren

    In einigen Fällen, z. B. bei einem Portausfallfehler, verlieren ESXi-Hosts möglicherweise die Konnektivität zum NVMe-Controller, obwohl einige E/A-Warteschlangen weiterhin aktiv sind.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2892901: Wenn die Festplatte einer replizierten virtuellen Maschine nicht auf 512 ausgerichtet ist, kann die VM möglicherweise nicht eingeschaltet werden

    Wenn Sie eine virtuelle Maschine mithilfe von vSphere Replication replizieren, und die VM-Festplatte auf eine Zahl erhöht wird, die nicht auf 512 ausgerichtet ist, kann die VM nicht eingeschaltet werden.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2912230: Wenn die Anzahl der CPUs kein Vielfaches der Anzahl der Kerne pro Socket in der Konfiguration einer virtuellen Maschine ist, kann die VM nicht eingeschaltet werden

    Wenn die Anzahl der CPUs, die Sie mit dem Parameter ConfigSpec#numCPUs konfigurieren, kein Vielfaches der Kerne pro Socket ist, die Sie in der Konfiguration einer virtuellen Maschine mit dem Parameter ConfigSpec#numCoresPerSocket definieren, lässt sich die VM nicht einschalten.

    Dieses Problem wurde in der vorliegenden Version behoben. Der Fix hindert Sie daran, einen Wert für numCPUs festzulegen, der kein Vielfaches des Werts numCoresPerSocket ist.

  • PR-2949375: vSAN-Host im Stretched Cluster kann nicht mit dem Modus „Zugriff sicherstellen“ in den Wartungsmodus wechseln

    Dieses Problem betrifft Hosts in Stretched Clustern mit den Richtlinieneinstellungen locality=None, HFT=0, SFT=1 und SFT=2. Wenn Sie einen Host mit „Zugriff sicherstellen“ in den Wartungsmodus versetzen, bleibt der Vorgang möglicherweise für einen langen Zeitraum bei 100 % oder schlägt nach 60 Minuten fehl.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2950686: Häufige vSAN-Netzwerklatenz-Alarme nach Upgrade auf ESXi 7.0 Update 2

    Nach dem Upgrade eines ESXi-Hosts auf 7.0 Update 2 bemerken Sie möglicherweise häufige vSAN-Netzwerklatenz-Alarme für den Cluster, wenn der vSAN-Leistungsdienst aktiviert ist. Die Latenzergebnisse zeigen, dass die meisten Alarme vom primären vSAN-Knoten ausgegeben werden.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2928789: Nach dem Update von ESXi 7.0, 7.0 Update 1 oder 7.0 Update 2 auf 7.0 Update 3c ist der Zugriff auf NVMe over RDMA-Speicher nicht mehr möglich

    Aufgrund einer Größenänderung der standardmäßigen Admin-Warteschlange für NVMe over RDMA-Controller in ESXi 7.0 Update 3c kann es vorkommen, dass nach Updates von ESXi 7.0, 7.0 Update 1 oder 7.0 Update 2 auf 7.0 Update 3c nicht mehr auf NVMe over RDMA-Speicher zugegriffen werden kann.

    Dieses Problem wurde in der vorliegenden Version behoben. Wenn Sie ein Update auf ESXi 7.0 Update 3c durchführen müssen, können Sie das im VMware-Knowledgebase-Artikel 88938 angehängte Skript vor dem Update ausführen, um sicherzustellen, dass das Problem behoben wurde.

  • PR 2983089: Ein ESXi-Host schlägt möglicherweise aufgrund einer Race-Bedingung in Container-Ports mit einem violetten Diagnosebildschirm fehl

    Aufgrund einer seltenen Race-Bedingung beim Versuch eines Container-Ports, eine bereits abgerufene Sperre erneut abzurufen, kann ein ESXi-Host mit einem violetten Diagnosebildschirm fehlschlagen, wenn virtuelle Maschinen mit Container-Ports ausgeschaltet werden oder eine Migration mit vSphere vMotion durchführen. Dieses Problem tritt aufgrund der Duplizierung von Port-IDs auf.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2925133: Wenn Sie vSphere Fault Tolerance deaktivieren oder anhalten, kommt es beim Pingen von virtuellen Maschinen möglicherweise zu einer Zeitüberschreitung

    Wenn Sie vSphere FT deaktivieren oder anhalten, verlieren virtuelle Maschinen möglicherweise vorübergehend die Konnektivität und reagieren nicht auf Ping- oder Netzwerkdatenverkehr. Beim Pingen von virtuellen Maschinen treten möglicherweise innerhalb eines kurzen Zeitraums nacheinander Zeitüberschreitungen auf, z. B. innerhalb von 20 Sekunden.

    Dieses Problem wurde in der vorliegenden Version behoben.

esx-update_7.0.3-0.50.20036589
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_esx-update_7.0.3-0.50.20036589
  • VMware_bootbank_loadesx_7.0.3-0.50.20036589
Behobene Probleme  Nicht verfügbar
CVE-Nummern Nicht verfügbar

Aktualisiert die VIBs loadesx und esx-update.

    Broadcom-bnxt-Net-RoCE_216.0.0.0-1vmw.703.0.50.20036589
    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
    • VMW_bootbank_bnxtroce_216.0.58.0-23vmw.703.0.50.20036589
    • VMW_bootbank_bnxtnet_216.0.50.0-44vmw.703.0.50.20036589
    Behobene Probleme  Nicht verfügbar
    CVE-Nummern Nicht verfügbar

    Aktualisiert das VIB bnxtnet.

      Broadcom-ELX-lpfc_14.0.169.26-5vmw.703.0.50.20036589
      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
      • VMW_bootbank_lpfc_14.0.169.26-5vmw.703.0.50.20036589
      Behobene Probleme  2929821
      CVE-Nummern Nicht verfügbar

      Aktualisiert das VIB  lpfc zur Behebung des folgenden Problems:
      • PR 2929821: ESXi-Hosts verlieren nach dem Upgrade des lpfc-Treibers auf 14.0.x.x den Zugriff auf Dell EMC Unity-Speicher-Arrays

        ESXi-Hosts verlieren nach dem Upgrade des lpfc-Treibers auf 14.0.x.x möglicherweise den Zugriff auf Unity-Speicher-Arrays. In den Treiberprotokollen werden Fehler wie Protokollfehler bei der Verarbeitung von FCP-E/A erkannt und rspInfo3 x2 angezeigt.

        Dieses Problem wurde in der vorliegenden Version behoben.

      Broadcom-lsiv2-drivers-plugin_1.0.0-12vmw.703.0.50.20036589
      Patch-Kategorie Fehlerkorrektur
      Patch-Schweregrad Kritisch 
      Hostneustart erforderlich Ja
      Migration oder Herunterfahren der virtuellen Maschine erforderlich Nein
      Betroffene Hardware Nicht verfügbar
      Betroffene Software Nicht verfügbar

      Enthaltene VIBs
      • VMware_bootbank_lsuv2-lsiv2-drivers-plugin_1.0.0-12vmw.703.0.50.20036589
      Behobene Probleme  2960435
      CVE-Nummern Nicht verfügbar

      Aktualisiert das VIB  lsuv2-lsiv2-drivers-plugin.
      • PR 2960435: Es dauert lange, bis Änderungen am Festplattenspeicherort über den vSphere Client oder mithilfe von ESXCLI sichtbar werden

        Bei LSI-bezogenen Treibern kann es beim Hochfahren eines ESXi-Servers, wenn Sie eine Festplatte herausnehmen und in einen anderen Steckplatz auf demselben Host einsetzen, lange dauern, bis Änderungen am Speicherort der Festplatte über den vSphere Client oder mithilfe des ESXCLI-Befehls esxcli storage core device physical get -d sichtbar werden. Das Problem besteht speziell bei Treibern, die mit vielen Festplatten (150 und mehr) verbunden sind, und wird innerhalb von 5 Minuten behoben.

        Dieses Problem wurde in der vorliegenden Version behoben. Mit dem Fix wird ein Cache aller Geräte hinzugefügt, die zur Startzeit mit einem LSI-Controller verbunden sind, um sicherzustellen, dass Aufrufe an die fremde Bestandsliste schnell bedient werden.

      Intel-icen_1.4.1.20-1vmw.703.0.50.20036589
      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
      • VMW_bootbank_icen_1.4.1.20-1vmw.703.0.50.20036589
      Behobene Probleme 2965878
      CVE-Nummern Nicht verfügbar

      Aktualisiert das VIB icen.

      • Mit ESXi 7.0 Update 3f unterstützt der Intel-icen-Treiber Netzwerkfunktionen auf E822/E823-Netzwerkkarten für Intel Icelake-D-Plattformen. ENS- (Enhanced Network Stack) und RDMA-Funktionen auf solchen Geräten werden nicht unterstützt.

      Intel-irdman_1.3.1.22-1vmw.703.0.50.20036589
      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
      • VMW_bootbank_irdman_1.3.1.22-1vmw.703.0.50.20036589
      Behobene Probleme Nicht verfügbar
      CVE-Nummern Nicht verfügbar

      Aktualisiert das VIB irdman.

        Intel-ne1000_0.9.0-1vmw.703.0.50.20036589
        Patch-Kategorie Fehlerkorrektur
        Patch-Schweregrad Kritisch
        Hostneustart erforderlich Ja
        Migration oder Herunterfahren der virtuellen Maschine erforderlich Nein
        Betroffene Hardware Nicht verfügbar
        Betroffene Software Nicht verfügbar
        Enthaltene VIBs
        • VMW_bootbank_ne1000_0.9.0-1vmw.703.0.50.20036589
        Behobene Probleme 2957673
        CVE-Nummern Nicht verfügbar

        Aktualisiert das VIB ne1000.

        • ESXi 7.0 Update 3f aktualisiert den Treiber Intel-ne1000 zur Unterstützung von Intel I219-LM-Geräten, die für neuere Servermodelle erforderlich sind, wie z. B. die Intel Lac-S-Plattform. Der TCP-Segmentierungs-Offload für die I219-Geräte ist aufgrund von bekannten Problemen im Hardware-DMA deaktiviert.

        VMware-iser_1.1.0.1-1vmw.703.0.50.20036589
        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
        • VMW_bootbank_iser_1.1.0.1-1vmw.703.0.50.20036589
        Behobene Probleme 2921564
        CVE-Nummern Nicht verfügbar

        Aktualisiert das VIB iser.

        • PR 2921564: ESXi-Hosts mit iSER-Initiatoren, die mit IBM FlashSystem V9000-Arrays verbunden sind, fallen aufgrund eines seltenen Problems möglicherweise mit einem violetten Diagnosebildschirm fehl

          Ein sehr seltenes Problem aufgrund eines Nullzeigerfehlers kann dazu führen, dass ESXi-Hosts in IBM FlashSystem V9000-Arrays mit einem violetten Diagnosebildschirm und einem Fehler wie zum Beispiel #PF Exception 14 in world 2098414:CqWorld IP 0xxxxx addr 0xxxx ausfallen.

          Dieses Problem wurde in der vorliegenden Version behoben. Durch den Fix wird einem RDMA-Fehlerstatus für einen der SCSI-Verwaltungsbefehle eine spezielle Handhabung hinzugefügt.

        VMware-vmkusb_0.1-7vmw.703.0.50.20036589
        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
        • VMW_bootbank_vmkusb_0.1-7vmw.703.0.50.20036589
        Behobene Probleme Nicht verfügbar
        CVE-Nummern Nicht verfügbar

        Aktualisiert das VIB vmkusb.

          ESXi_7.0.3-0.45.20036586
          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_native-misc-drivers_7.0.3-0.45.20036586
          • VMware_bootbank_bmcal_7.0.3-0.45.20036586
          • VMware_bootbank_esx-ui_1.43.8-19798623
          • VMware_bootbank_vsanhealth_7.0.3-0.45.20036586
          • VMware_bootbank_esxio-combiner_7.0.3-0.45.20036586
          • VMware_bootbank_esx-xserver_7.0.3-0.45.20036586
          • VMware_bootbank_trx_7.0.3-0.45.20036586
          • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.3-0.45.20036586
          • VMware_bootbank_vdfs_7.0.3-0.45.20036586
          • VMware_bootbank_vsan_7.0.3-0.45.20036586
          • VMware_bootbank_cpu-microcode_7.0.3-0.45.20036586
          • VMware_bootbank_esx-base_7.0.3-0.45.20036586
          • VMware_bootbank_gc_7.0.3-0.45.20036586
          • VMware_bootbank_crx_7.0.3-0.45.20036586
          Behobene Probleme 2920287, 2946147, 2946217, 2946222, 2946671, 2946863, 2947156, 2951864, 2951866, 2972147, 2972151
          CVE-Nummern CVE-2004-0230, CVE-2020-7451, CVE-2015-2923, CVE-2015-5358, CVE-2013-3077, CVE-2015-1414, CVE-2018-6918, CVE-2020-7469, CVE-2019-5611, CVE-2020-7457, CVE-2018-6916, CVE-2019-5608, CVE-2022-23816, CVE-2022-23825, CVE-2022-28693, CVE-2022-29901

          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 native-misc-drivers, bmcal, esx-ui, vsanhealth, esxio-combiner, esx-xserver, trx, esx-dvfilter-generic-fastpath, vdfs, vsan, cpu-microcode, esx-base, gc und crx, um die folgenden Probleme zu beheben:

          • ESXi 7.0 Update 3f stellt die folgenden Sicherheits-Updates bereit:
            • Der XML-Parser Expat wurde auf Version 2.4.7 aktualisiert.
            • Die SQLite-Datenbank wurde auf Version 3.37.2 aktualisiert.
            • Die cURL-Bibliothek wurde auf Version 7.81.0 aktualisiert.
            • Das OpenSSL-Paket wurde auf Version openssl-1.0.2ze aktualisiert.
            • Die userworld-libxml2-Bibliothek von ESXi wurde auf Version 2.9.14 aktualisiert.
            • Das Python-Paket wurde auf 3.8.13 aktualisiert.
            • Die zlib-Bibliothek wurde auf 1.2.12 aktualisiert.
            • In dieser Version wurde CVE-2004-0230 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem niedrigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 3,7.
            • In dieser Version wurde CVE-2020-7451 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem mittleren Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 5,3.
            • In dieser Version wurde CVE-2015-2923 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem mittleren Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 6,5.
            • In dieser Version wurde CVE-2015-5358 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem mittleren Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 6,5.
            • In dieser Version wurde CVE-2013-3077 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem wichtigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 7,0.
            • In dieser Version wurde CVE-2015-1414 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem wichtigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 7,5.  
            • In dieser Version wurde CVE-2018-6918 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem wichtigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 7,5.
            • In dieser Version wurde CVE-2020-7469 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem wichtigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 7,5.
            • In dieser Version wurde CVE-2019-5611 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem wichtigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 7,5. 
            • In dieser Version wurde CVE-2020-7457 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem wichtigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 7,8. 
            • In dieser Version wurde CVE-2018-6916 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem wichtigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 8,1.
            • In dieser Version wurde CVE-2019-5608 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem wichtigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 8,1.

          • In dieser Version werden die folgenden Schwachstellen behoben: CVE-2022-23816, CVE-2022-23825, CVE-2022-28693 und CVE-2022-29901. Weitere Informationen zu diesen Schwachstellen und deren Auswirkungen auf VMware-Produkte finden Sie unter VMSA-2022-0020.

          esx-update_7.0.3-0.45.20036586
          Patch-Kategorie Sicherheit
          Patch-Schweregrad Kritisch
          Hostneustart erforderlich Nein
          Migration oder Herunterfahren der virtuellen Maschine erforderlich Nein
          Betroffene Hardware Nicht verfügbar
          Betroffene Software Nicht verfügbar
          Enthaltene VIBs
          • VMware_bootbank_esx-update_7.0.3-0.45.20036586
          • VMware_bootbank_loadesx_7.0.3-0.45.20036586
          Behobene Probleme Nicht verfügbar
          CVE-Nummern Nicht verfügbar

          Aktualisiert die VIBs loadesx und esx-update.

            VMware-VM-Tools_12.0.0.19345655-20036586
            Patch-Kategorie Sicherheit
            Patch-Schweregrad Kritisch
            Hostneustart erforderlich Nein
            Migration oder Herunterfahren der virtuellen Maschine erforderlich Nein
            Betroffene Hardware Nicht verfügbar
            Betroffene Software Nicht verfügbar
            Enthaltene VIBs
            • VMware_locker_tools-light_12.0.0.19345655-20036586
            Behobene Probleme Nicht verfügbar
            CVE-Nummern Nicht verfügbar

            Aktualisiert das VIB tools-light.

              ESXi-7.0U3f-20036589-standard
              Profilname ESXi-7.0U3f-20036589-standard
              Build Build-Informationen finden Sie unter In dieser Version enthaltene Patches.
              Anbieter VMware, Inc.
              Datum der Veröffentlichung 12. Juli 2022
              Akzeptanzebene PartnerSupported
              Betroffene Hardware Nicht verfügbar
              Betroffene Software Nicht verfügbar
              Betroffene VIBs
              • VMware_bootbank_esxio-combiner_7.0.3-0.50.20036589
              • VMware_bootbank_esx-ui_1.43.8-19798623
              • VMware_bootbank_esx-xserver_7.0.3-0.50.20036589
              • VMware_bootbank_cpu-microcode_7.0.3-0.50.20036589
              • VMware_bootbank_trx_7.0.3-0.50.20036589
              • VMware_bootbank_vsanhealth_7.0.3-0.50.20036589
              • VMware_bootbank_esx-base_7.0.3-0.50.20036589
              • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.3-0.50.20036589
              • VMware_bootbank_gc_7.0.3-0.50.20036589
              • VMware_bootbank_native-misc-drivers_7.0.3-0.50.20036589
              • VMware_bootbank_bmcal_7.0.3-0.50.20036589
              • VMware_bootbank_vsan_7.0.3-0.50.20036589
              • VMware_bootbank_vdfs_7.0.3-0.50.20036589
              • VMware_bootbank_crx_7.0.3-0.50.20036589
              • VMware_bootbank_esx-update_7.0.3-0.50.20036589
              • VMware_bootbank_loadesx_7.0.3-0.50.20036589
              • VMW_bootbank_bnxtroce_216.0.58.0-23vmw.703.0.50.20036589
              • VMW_bootbank_bnxtnet_216.0.50.0-44vmw.703.0.50.20036589
              • VMW_bootbank_lpfc_14.0.169.26-5vmw.703.0.50.20036589
              • VMware_bootbank_lsuv2-lsiv2-drivers-plugin_1.0.0-12vmw.703.0.50.20036589
              • VMW_bootbank_icen_1.4.1.20-1vmw.703.0.50.20036589
              • VMW_bootbank_irdman_1.3.1.22-1vmw.703.0.50.20036589
              • VMW_bootbank_ne1000_0.9.0-1vmw.703.0.50.20036589
              • VMW_bootbank_iser_1.1.0.1-1vmw.703.0.50.20036589
              • VMW_bootbank_vmkusb_0.1-7vmw.703.0.50.20036589
              • VMware_locker_tools-light_12.0.0.19345655-20036586
              Behobene Probleme 2916848, 2817702, 2937074, 2957732, 2984134, 2944807, 2985369, 2907963, 2949801, 2984245, 2915911, 2990593, 2992648, 2905357, 2980176, 2974472, 2974376, 2972059, 2973031, 2967359, 2860126, 2878245, 2876044, 2968157, 2960242, 2970238, 2966270, 2966783, 2963328, 2939395, 2966362, 2946550, 2958543, 2966628, 2961584, 2911056, 2965235, 2952427, 2963401, 2965146, 2963038, 2963479, 2949375, 2961033, 2958926, 2839515, 2951139, 2878224, 2954320, 2952432, 2961346, 2857932, 2960949, 2960882, 2957966, 2929443, 2956080, 2959293, 2944919, 2948800, 2928789, 2957769, 2928268, 2957062, 2792139, 2934102, 2953709, 2950686, 2953488, 2949446, 2955016, 2953217, 2956030, 2949902, 2944894, 2944521, 2911363, 2952205, 2894093, 2910856, 2953754, 2949777, 2925733, 2951234, 2915979, 2904241, 2935355, 2941263, 2912661, 2891231, 2928202, 2928268, 2867146, 2244126, 2912330, 2898858, 2906297, 2912213, 2910340, 2745800, 2912182, 2941274, 2912230, 2699748, 2882789, 2869031, 2913017, 2864375, 2929821, 2957673, 2921564, 2925133, 2965277
              Verwandte CVE-Nummern Nicht verfügbar
              • Dieser Patch enthält Updates zur Behebung der folgenden Probleme:

                • pyVmomi-Aufrufe der vSphere API EnvironmentBrowser.QueryConfigTargetEx schlagen möglicherweise mit UnknownWsdlTypeError fehl.

                • Das Hardwareintegritätsmodul von ESXi kann möglicherweise einige Sensoren des Typs „Systemereignis“ nicht entschlüsseln, wenn ein physischer Server mit einem neuen Branding versehen wird. Infolgedessen wird im vSphere-Client der Status „Unbekannt“ für Sensoren des Typs „Systemereignis“ unter Überwachung > Hardware-Integrität angezeigt.

                • Wenn Sie die erweiterte Einstellung vmx.reboot.powerCycle auf einer virtuellen Maschine auf TRUE festlegen, wird die virtuelle Maschine ausgeschaltet und dann wieder eingeschaltet, wenn das Gastbetriebssystem einen Neustart initiiert. Wenn jedoch während einer Migration mithilfe von vSphere vMotion ein Ein-/Ausschalten stattfindet, schlägt der Vorgang fehl, und die virtuelle Maschine auf dem Quellhost wird möglicherweise nicht wieder eingeschaltet.

                • Wenn bei einem Socket ein Verbindungsfehler auftritt, während er bei der internen Kommunikation zwischen UNIX-Domänen-Sockets abgefragt wird, kann es zu einem Datenrennen kommen. Infolgedessen greift der ESXi-Host in einigen Fällen auf einen ungültigen Arbeitsspeicherbereich zu und fällt mit einem violetten Diagnosebildschirm mit #PF Exception 14 und Fehlern wie UserDuct_PollSize() und UserSocketLocalPoll() aus.

                • Wenn ein Hardware-iSCSI-Adapter auf einem ESXi-Host in Ihrer Umgebung Pseudo-Netzwerkschnittstellenkarten verwendet, können Sie möglicherweise kein Hostprofil von einem solchen Host erstellen, da Pseudo-Netzwerkschnittstellenkarten nicht über die erforderliche PCI-Adresse und den Anbieternamen für ein Profil verfügen.

                • Race-Bedingungen im iscsi_vmk-Treiber können zu blockierten E/A-Vorgängen oder Taktsignal-Zeitüberschreitungen bei einem VMFS-Datenspeicher führen. Dies kann dazu führen, dass einige virtuelle Maschinen nicht mehr reagieren.

                • Der Durchsatz mit Software-iSCSI-Adaptern ist aufgrund hartcodierter Sende- und Empfangspuffergrößen – 600 KB für Sende- bzw. 256 KB für Empfangspuffer – begrenzt. Dies führt dazu, dass die Leistung des iscsi_vmk-Adapters nicht optimal ist.

                • Wenn mehrere NVIDIA vGPU-VMs gleichzeitig ausgeschaltet werden, werden gelegentlich einige GPU-Ressourcen (MIG) mit mehreren Instanzen nicht gelöscht. Dies kann dazu führen, dass das Einschalten der nachfolgenden vGPU-VM aufgrund der verbleibenden MIG-Ressourcen fehlschlägt.

                • Wenn ein NFSv4.1-Server während eines Speicher-Failovers einen vorübergehenden Fehler zurückgibt, können in seltenen Fällen virtuelle Maschinen 10 Sekunden lang nicht reagieren, bevor der Vorgang neu gestartet wird.

                • In seltenen Fällen kann es vorkommen, dass der Paketabschluss nicht am ursprünglichen Port oder Portset, sondern an einem anderen Portset erfolgt, was zu einer Schleife führen kann, die die Paketliste mit einem ungültigen Zeiger beschädigt. Infolgedessen fällt ein ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm aus. In den Protokollen wird beispielsweise folgender Fehler angezeigt: PF Exception 14 in world 61176327:nsx.cp.tx IP 0xxxxxx addr 0x3c.

                • Der Arbeitsspeicher im NUMA-Knoten eines ESXi-Hosts besteht möglicherweise aus mehreren physischen Bereichen. In ESXi-Versionen vor 7.0 Update 3f gibt das Feldpaar memoryRangeBegin, memoryRangeLength in NumaNodeInfo die physikalische Startadresse des Hosts und die Länge des Bereichs im NUMA-Knoten an, wobei alle zusätzlichen Bereiche ignoriert werden.

                • Wenn Sie den schnellen Pfad auf HPP für 512e Software Emulated 4KN-Geräte aktivieren, funktioniert er nicht wie erwartet, da der schnelle Pfad nicht mit Read-Modify-Write(R-M-W) umgehen kann, das den langsamen Pfad verwenden muss. Die Verwendung des schnellen Pfads auf 4KN-Geräten wird nicht unterstützt.

                • Wenn Sie über eine ausgeführte VM mit virtuellen Festplatten mit mehr als 1 TB verfügen und einen Snapshot der Festplatten auf dieser VM löschen, friert die VM möglicherweise für Sekunden oder sogar Minuten ein. Die VM wird letztendlich wiederhergestellt, bei VM-Arbeitslasten können jedoch Ausfälle auftreten. Das Problem tritt auf, weil der Löschvorgang die Konsolidierung von Snapshots im Hintergrund auslöst, was die Verzögerung verursacht. Das Problem tritt eher bei langsamerem Speicher auf, wie z. B. NFS.

                • DVFilter-Pakete werden möglicherweise fälschlicherweise an einen Netzwerkport übertragen, an dem der Paketabschlusscode nicht ausgeführt werden kann. Infolgedessen fallen ESXi-Hosts mit einem violetten Diagnosebildschirm und dem Fehler PF Exception 14 Vmxnet3VMKDevTxCompleteOne E1000DevTxCompleteOneWork aus.

                • In seltenen Fällen sendet die DFW möglicherweise eine Paketliste an das falsche Portset. Dies kann dazu führen, dass der VMkernel-Dienst fehlschlägt und virtuelle Maschinen die Konnektivität verlieren. In der Datei vmkernel.log werden Fehler ähnlich dem Folgenden angezeigt:
                  2021-09-27T04:29:53.170Z cpu84:xxxx)NetPort: 206: Fehler: lockModel[0] vs psWorldState->lockModel[0] there is no portset lock holding.

                • Ab vSphere 7.0 Update 2 wird HPP das Standard-Plug-In für lokale NVMe- und SCSI-Geräte und ersetzt das native Multipathing-Plug-In (NMP) von ESX. In bestimmten Umgebungen führt die Änderung von NMP zu HPP jedoch dazu, dass auf einige Eigenschaften von Geräten, die von HPP beansprucht werden, wie z. B. den Anzeigenamen, nicht zugegriffen werden kann.

                • Wenn in einem ALUA-Ziel die Zielportgruppen-IDs (TPGIDs) für eine LUN geändert werden, wird die vom SATP verwendete Antwort zur Geräteidentifikation im Cache möglicherweise nicht entsprechend aktualisiert. Dies führt dazu, dass ESXi möglicherweise nicht die korrekten Pfadstatus für das entsprechende Gerät wiedergibt.

                • Wenn Sie den NVMe-SCSI-Übersetzungs-Stack zum Registrieren von NVMe-Geräten in Ihrem System verwenden, erhalten die Eigenschaften targetPortGroup und relativeTargetPortId die Controller-ID 0 für alle Pfade. Dies führt dazu, dass ein RTPG-Befehl denselben ALUA-Zugriffsstatus für alle Pfade des Namespace zurückgibt, da die tpgID jedes Pfads mit dem ersten Deskriptor übereinstimmt, der 0 ist.

                • Wenn das Kennwort für den Administrator des Dateidiensts auf dem Active Directory-Server geändert wird, stimmt das Kennwort in der Domänenkonfiguration des vSAN-Dateidiensts möglicherweise nicht überein. Wenn die Kennwörter nicht übereinstimmen oder das Konto gesperrt ist, kann möglicherweise auf einige Dateifreigaben nicht zugegriffen werden. Der vSAN-Integritätsdienst zeigt die folgende Warnung an: Dateidienst: Dateiserver nicht gefunden.

                • Wenn Sie einen ESXi-Host nach einem Ausfall neu installieren, bleiben veraltete Bindungen von VMDKs beim VASA-Anbieter und in den vSphere Virtual Volumes-Datenspeichern intakt, da die ausgefallene Instanz nie neu gestartet wird. Infolgedessen können Sie bei einer Neuinstallation des Hosts die VMDKs aufgrund der vorhandenen Bindung nicht löschen. Im Laufe der Zeit können sich viele solche VMDKs ansammeln und ungenutzten Speicherplatz verbrauchen.

                • In seltenen Fällen verfügt ein serielles Gerät auf einer virtuellen Maschine nicht über die Eigenschaft serial<N>.fileName, während gleichzeitig die Eigenschaft serial<N>.autodetect auf FALSE festgelegt ist. Dies kann dazu führen, dass der hostd-Dienst wiederholt fehlschlägt.

                • Wenn Sie im vSphere Client eine der Traffic-Shaping-Optionen wie „Durchschnittliche Bandbreite“, „Spitzenbandbreite“ oder „Burstgröße“ auf einen Wert festlegen, der größer als 2147483 KBit/s ist, werden die Einstellungen nicht beibehalten.

                • Aufgrund der geringen Standardanzahl an Dateideskriptoren können einige Funktionen wie vSphere vMotion nach dem Upgrade auf ESXi 7.x in VAAI für NAS-Umgebungen wegen der unzureichenden Anzahl an VMDK-Dateien, die gleichzeitig ausgeführt werden können, fehlschlagen. In der Datei syslog.log werden Fehler wie Zu viele offene Dateien in den Protokollen des vaai-nas-Daemon angezeigt.

                • Wenn in seltenen Fällen eine E/A-Anforderung parallel mit einem vom Gastbetriebssystem ausgelösten Aufhebevorgang auf einer Thin-Provisioning-VM ausgeführt wird, kann es in manchen Fällen zu einem Deadlock auf einem VMFS6-Volume kommen. Folglich reagieren virtuelle Maschinen auf diesem Volume nicht mehr.

                • Bei vSphere Storage vMotion- oder Hot-Add-Vorgängen auf einer virtuellen Maschine mit mehr als 300 GB Arbeitsspeicher kann sich die Switchover-Zeit 2 Minuten nähern, was zu einem Zeitüberschreitungsfehler führt.

                • Wenn Sie die Port-Bindung nicht entfernen, nachdem Sie eine VMkernel-Netzwerkkarte gelöscht haben, die an einen iSCSI-Adapter gebunden ist, kann die veraltete Port-Bindung Probleme nach einem Neustart des ESXi-Hosts verursachen. Während des Startvorgangs schlägt die Bindung der nicht vorhandenen VMkernel-Netzwerkkarte an den iSCSI-Adapter fehl, und iSCSI-Konfigurationen können während des Startvorgangs nicht wiederhergestellt werden. Infolgedessen werden nach Abschluss des Neustarts möglicherweise einige LUNs oder Datenspeicher nicht angezeigt.

                • Nach einem Speicher-Failover erkennt der ESXi NFSv4.1-Client den NFS-Server fälschlicherweise als eine andere Einheit und überspringt die Wiederherstellung. Dies führt dazu, dass der NFSv4.1-Datenspeicher im Status Kein Zugriff verbleibt.

                • In einigen Fällen, z. B. wenn die Temperatur den Schwellenwert überschreitet, meldet ein NVMe-Gerät möglicherweise eine kritische Warnung, und der ESXi NVMe-Controller registriert das Gerät nicht und schaltet es offline.

                • Ein seltenes Problem, bei dem der verwendete Block-Cache den reservierten Cache überschreitet, kann zu Reservierungsproblemen im vSAN-Dateidienst führen. Infolgedessen können Sie einige Dateifreigaben nicht erreichen, und die Integritätsprüfung zeigt den Fehler VDFS-Daemon wird nicht ausgeführt. Im vdfsd-server-Protokoll werden Fehler ähnlich dem Folgenden angezeigt:
                  PANIC: NOT_IMPLEMENTED bora/vdfs/core/VDFSPhysicalLog.cpp:621
                  PANIC: NOT_IMPLEMENTED bora/vdfs/core/VDFSPhysicalLog.cpp:626

                • In seltenen Fällen können Suchabfragen im Hintergrund, die von vCenter Server auf einem ESXi-Host mit Zugriff auf die VMDK-Dateien virtueller in ein OVF-Format exportierter Maschinen ausgeführt werden, die Dateien versehentlich ändern. Infolgedessen können Sie die virtuellen Maschinen nicht importieren.

                • Aufgrund eines Komponentenlastproblems schlägt das Hinzufügen einer Multipathing-PSA-Beanspruchungsregel zum Satz von Beanspruchungsregeln auf einem vCenter Server-System unter Verwendung des JumpStart-Tools möglicherweise fehl.

                • Nach einem kontrollierten Herunterfahren oder Starten eines Servers in einem Cluster von ESXi-Servern, die mit einem ALUA-Array verbunden sind, werden alle LUNs, auf die dieser Server Zugriff hat, möglicherweise auf einen Speicherprozessor im Array übertragen. Infolgedessen verschlechtert sich die Leistung der anderen ESXi-Server, die auf die LUNs zugreifen.

                • Bei einer hohen Arbeitsspeicherbelastung verarbeitet PSA in seltenen Fällen Fehler bei der Arbeitsspeicherzuteilung nicht ordnungsgemäß. Infolgedessen fällt der ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm und einem Fehler wie #PF Exception 14 in world 2098026:SCSI path sc IP / SCSI path scan helpers aus.

                • Wenn eine ausgeführte virtuelle Maschine während eines Snapshot-Löschvorgangs neu gestartet wird, werden die VM-Festplatten möglicherweise während der Snapshot-Konsolidierung nicht ordnungsgemäß neu geöffnet und geschlossen. Infolgedessen fällt die VM möglicherweise aus. Dies ist jedoch ein Zeitproblem, das versehentlich auftritt.

                • Während der Geräteerkennung kann ein Reservierungskonflikt dazu führen, dass ATS fälschlicherweise als nicht unterstützt gemeldet wird. Aus diesem Grund verwendet ESXi die SCSI-2-Reservierung anstelle von ATS. Dies führt dazu, dass das Mounten von VMFS6-Datenspeichern mit aktivierter Cluster-VMDK-Unterstützung möglicherweise zufällig fehlschlägt.

                • Bei einigen Vorgängen kann die Host-UUID geändert werden. Wenn Sie beispielsweise ESXi-Software neu installieren oder den Host zwischen Clustern verschieben, kann sich die Host-UUID gegebenenfalls ändern. Wenn sich die Host-UUID während des Ausfalls des vSAN-Dateidiensts ändert, können vSAN-Dateidienstserver nicht gestartet werden.

                • Wenn Sie den vSAN-Dateidienst ohne vorhandene Dateifreigaben deaktivieren, entfernt vSAN die Dateidienstdomäne. Ein Entfernungsfehler eines Servers unterbricht möglicherweise den Prozess und hinterlässt einige Metadaten. Wenn Sie den Dateidienst erneut aktivieren, funktioniert der Dateidienst aufgrund der alten Metadaten möglicherweise nicht wie erwartet.

                • Der Befehl „Zielportgruppen des Berichts“ gibt möglicherweise im Feld IMPLIZITE ÜBERGANGSZEIT einen falschen Wert zurück, was sich auf die SCSI-zu-NVMe-Übersetzungsschicht auswirkt. In Fällen wie der Migration mehrerer Appliances ist die Zeit für den ALUA-Übergang für Multipathing-Software, beispielsweise PowerPath, zur Durchführung korrekter Vorgänge von entscheidender Bedeutung.

                • Kleine ausstehende Zuordnungsaufhebungen werden möglicherweise blockiert, wenn Sie einen Host neu starten oder eine Festplattengruppe erneut mounten. Die ausstehenden Zuordnungsaufhebungen können zu einer Protokollüberlastung führen, die E/A-Latenz zur Folge hat.

                • Nach dem ersten Upgrade oder Update Ihres Systems auf ESXi 7.x findet bei jedem nachfolgenden Update, das auch als Patch bezeichnet wird, möglicherweise eine Kürzung der Angaben im Pfad zum Verzeichnis /productLocker in einem Datenspeicher statt. Wenn Ihr erster Patch auf ESXi 7.x beispielsweise von 7.0 Update 2 zu 7.0 Update 3 führt, ist das Verzeichnis /productLocker ursprünglich dem Verzeichnis /vmfs/volumes/xxx/VMware-Tools/productLocker/ ähnlich. Für jeden nachfolgenden Patch, z. B. von 7.0 Update 3 auf 7.0 Update 3c, ähnelt der Pfad jedoch /VMware-Tools/productLocker/.

                • In einem vSAN Stretched Cluster oder einem Cluster mit zwei Knoten werden quorumbasierte Entscheidungen für Objekte mit PFTT von 1 und SFTT von 1 oder mehr möglicherweise nicht ordnungsgemäß verteilt. Wenn eine Site ausfällt und ein zusätzlicher Host oder eine zusätzliche Festplatte auf der aktiven Site ausfällt, verliert das Objekt möglicherweise das Quorum, und es kann nicht mehr darauf zugegriffen werden.

                • Eine Anforderung zur Größenänderung eines Objekts kann fehlschlagen, wenn die neue Größe nicht auf 512 Byte ausgerichtet ist. Dieses Problem kann dazu führen, dass ein ESXi-Host mit einem violetten Diagnosebildschirm ausfällt.

                • In einigen Fällen, z. B. beim Neustart einer virtuellen Maschine, kann eine laufende SSH-Sitzung, die das Dienstprogramm „pktcap-uw“ zur Überwachung und Validierung von Switch-Konfigurationen auf dem ESXi-Host verwendet, beendet werden. Das Dienstprogramm „pktcap-uw“ versucht möglicherweise weiterhin, Pakete zu verarbeiten. Dies führt dazu, dass das Dienstprogramm mehr CPU verbraucht als normal. Mit dem Befehl esxtop -a können Sie die CPU-Leistung nachverfolgen.

                • Auf einem vCenter Server unter 7.0 Update 3 kann ein zertifiziertes NVMe-Gerät die folgende Warnung für die Integritätsprüfung aufweisen: NVMe-Gerät ist nicht für VMware zertifiziert. Möglicherweise wird auch die folgende Integritätsprüfungswarnung angezeigt: NVMe-Gerät kann nicht identifiziert werden.

                • Der ESXCLI-Befehl hardware ipmi bmc get gibt aufgrund einer falschen Analyse die IPv6-Adresse eines BMC nicht zurück.

                • Wenn der Zeugenhost von Clusterhosts nicht erreicht werden kann, fällt der Assistent zum Herunterfahren des vSAN-Clusters für einen Stretched Cluster oder einen Cluster mit zwei Knoten möglicherweise aus. Dieses Problem tritt auf, wenn für den vSAN-Datenverkehr und den Zeugen-Datenverkehr verschiedene vmknics verwendet werden. Im vSphere Client wird die folgende Fehlermeldung auf der Seite „vSAN-Dienste“ angezeigt: Getrennter Host von Orch gefunden <Zeugen-IP>. Wenn vCenter im Cluster gehostet wird, ist der vSphere Client beim Herunterfahren nicht verfügbar, und die Fehlermeldung wird auf dem Host Client angezeigt, auf dem sich die vCenter-VM befindet.

                • Wenn Sie im vSphere Client mit der rechten Maustaste klicken, um einen Datenspeicher zu durchsuchen, wird anstelle der Namen möglicherweise die UUID einiger virtueller Maschinen in einem vSphere Virtual Volumes-Datenspeicher angezeigt, wie z. B. naa.xxxx. Dieses Problem tritt nur selten in großen Umgebungen mit einer großen Anzahl von Containern und VMs in einem vSphere Virtual Volumes-Datenspeicher auf. Das Problem hat keine funktionalen Auswirkungen, wie z. B. Auswirkungen auf VM-Vorgänge, Sicherungen oder andere Elemente als die VM-Anzeige im vSphere Client.

                • Aufgrund eines seltenen Problems im Zusammenhang mit der ESXi-Infrastruktur kann ein langsamer VASA-Anbieter eine Situation auslösen, in der auf die vSphere Virtual Volumes-Datenspeicher nicht zugegriffen werden kann und der ESXi-Host nicht mehr reagiert.

                • Wenn Sie in bestimmten Umgebungen einen ESXi-Host herunterfahren, wird dieser nicht ausgeschaltet, und es wird ein Bildschirm mit der Meldung Dieses System wurde angehalten angezeigt. Mit der Schaltfläche zum Zurücksetzen oder zum Ein-/Ausschalten kann ein sicherer Neustart durchgeführt werden.

                • Die Einstellung LargeBAR, die das Basisadressregister (Base Address Register, BAR) auf einem vmxnet3-Gerät erweitert, unterstützt einheitliches Passthrough (Uniform Passthrough, UPT). UPT wird jedoch unter ESX 7.0 Update 3 und höher nicht unterstützt, und wenn der vmxnet3-Treiber auf eine Version vor 7.0 herabgestuft wird und die Einstellung LargeBAR aktiviert ist, verlieren die virtuellen Maschinen möglicherweise die Konnektivität.

                • Wenn Sie unabhängige, nicht dauerhafte Festplatten im laufenden Betrieb von einer virtuellen Maschine entfernen, für die der Konfigurationsparameter vmx.reboot.PowerCycle aktiviert ist, speichert ESXi eine Redo-Protokolldatei. Wenn es sich bei einer solchen VM um eine Sicherungs-Proxy-VM handelt, werden möglicherweise viele redundante Redo-Protokolldateien angezeigt, die einen erheblichen Teil des Speichers in Anspruch nehmen.

                • Wenn ein ESXi-Host versucht, über einen Ressourcenpool-Cache auf einen nicht im Cache enthaltenen Eintrag zuzugreifen, fällt der Host zeitweise mit einem violetten Diagnosebildschirm PF Exception 14 und einer Core-Dump-Datei aus. In der Dump-Datei werden Fehler für die Module J3_DeleteTransaction und J6ProcessReplayTxnList angezeigt, die auf das Problem hinweisen.

                • Ein seltenes Problem im Zusammenhang mit VMFS kann bei grundlegenden Dateisystemaufrufen wie open, access oder rename zu hochgradigen Sperrungskonflikten bei hostd-Dienst-Threads oder sogar zu Deadlocks führen. Folglich reagiert der ESXi-Host nicht mehr.

                • Da das MD5-Authentifizierungsprotokoll ab ESXi 7.x nicht mehr unterstützt wird, schlagen Upgrades auf ESXi 7.x fehl, wenn für eine ESXi-SNMP-Agent-Konfiguration das MD5-Authentifizierungsprotokoll verwendet wird.

                • In ESXi 7.x toleriert der Parameter Syslog.global.logHost, der eine kommagetrennte Liste von Remote-Hosts und Spezifikationen für Nachrichtenübertragungen definiert, keine Leerzeichen nach dem Komma. ESXi-Versionen vor 7.x tolerieren im Parameter Syslog.global.logHost ein Leerzeichen nach dem Komma. Dies kann dazu führen, dass Upgrades auf ESXi 7.x fehlschlagen.

                • Ein Problem im Zusammenhang mit der probabilistischen Datenstruktur „Bloom-Filter“, die die Lese-E/A für in einem Snapshot ausgeführte VMs optimieren soll, kann zu einem logischen, konsistenzbasierten E/A-Fehler führen, wenn die VM auf einem Snapshot ausgeführt wird. Das Problem ist begrenzt und tritt nur auf, wenn Sie SQL Server in einem Snapshot ausführen.

                • Ein Problem mit dem Prozess, der Datenspeicher zur Unterstützung von Dateiblockzuteilungen für Thin-Dateien prüft, kann in bestimmten Fällen zu einer CPU-Sperre führen. Dies führt dazu, dass der ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm und einer Fehlermeldung ähnlich der folgenden ausfällt: PSOD - @BlueScreen: NMI.

                • Die Protokolldateien des hostd-Diensts erhalten möglicherweise eine ungewöhnlich hohe Anzahl von Meldungen des Typs Task Created und Task Completed für unsichtbare Aufgaben, was wiederum die Aufbewahrungszeit für Protokolle verringern kann. 

                • Wenn ein SCSI-Befehl für einen Protokollendpunkt eines vSphere Virtual Volumes-Datenspeichers fehlschlägt, erhält der Endpoint möglicherweise den Status „Nicht unterstützt“, der möglicherweise zwischengespeichert wird. Dies führt dazu, dass die folgenden an diesen Protokollendpunkt gerichteten SCSI-Befehle mit einem Fehlercode wie 0x5 0x20 fehlschlagen und Lese- und Schreibvorgänge in einem vSphere Virtual Volumes-Datenspeicher fehlschlagen.

                • In einigen Fällen, z. B. bei einem Portausfallfehler, verlieren ESXi-Hosts möglicherweise die Konnektivität zum NVMe-Controller, obwohl einige E/A-Warteschlangen weiterhin aktiv sind.

                • Wenn Sie eine virtuelle Maschine mithilfe von vSphere Replication replizieren, und die VM-Festplatte auf eine Zahl erhöht wird, die nicht auf 512 ausgerichtet ist, kann die VM nicht eingeschaltet werden.

                • Wenn die Anzahl der CPUs, die Sie mit dem Parameter ConfigSpec#numCPUs konfigurieren, kein Vielfaches der Kerne pro Socket ist, die Sie in der Konfiguration einer virtuellen Maschine mit dem Parameter ConfigSpec#numCoresPerSocket definieren, lässt sich die VM nicht einschalten.

                • Dieses Problem betrifft Hosts in Stretched Clustern mit den Richtlinieneinstellungen locality=None, HFT=0, SFT=1 und SFT=2. Wenn Sie einen Host mit „Zugriff sicherstellen“ in den Wartungsmodus versetzen, bleibt der Vorgang möglicherweise für einen langen Zeitraum bei 100 % oder schlägt nach 60 Minuten fehl.

                • Nach dem Upgrade eines ESXi-Hosts auf 7.0 Update 2 bemerken Sie möglicherweise häufige vSAN-Netzwerklatenz-Alarme für den Cluster, wenn der vSAN-Leistungsdienst aktiviert ist. Die Latenzergebnisse zeigen, dass die meisten Alarme vom primären vSAN-Knoten ausgegeben werden.

                • Aufgrund einer Größenänderung der standardmäßigen Admin-Warteschlange für NVMe over RDMA-Controller in ESXi 7.0 Update 3c kann es vorkommen, dass nach Updates von ESXi 7.0, 7.0 Update 1 oder 7.0 Update 2 auf 7.0 Update 3c nicht mehr auf NVMe over RDMA-Speicher zugegriffen werden kann.

                • Aufgrund einer seltenen Race-Bedingung beim Versuch eines Container-Ports, eine bereits abgerufene Sperre erneut abzurufen, kann ein ESXi-Host mit einem violetten Diagnosebildschirm fehlschlagen, wenn virtuelle Maschinen mit Container-Ports ausgeschaltet werden oder eine Migration mit vSphere vMotion durchführen. Dieses Problem tritt aufgrund der Duplizierung von Port-IDs auf.

                • ESXi-Hosts verlieren nach dem Upgrade des lpfc-Treibers auf 14.0.x.x möglicherweise den Zugriff auf Unity-Speicher-Arrays. In den Treiberprotokollen werden Fehler wie Protokollfehler bei der Verarbeitung von FCP-E/A erkannt und rspInfo3 x2 angezeigt.

                • Bei LSI-bezogenen Treibern kann es beim Hochfahren eines ESXi-Servers, wenn Sie eine Festplatte herausnehmen und in einen anderen Steckplatz auf demselben Host einsetzen, lange dauern, bis Änderungen am Speicherort der Festplatte über den vSphere Client oder mithilfe des ESXCLI-Befehls esxcli storage core device physical get -d sichtbar werden. Das Problem besteht speziell bei Treibern, die mit vielen Festplatten (150 und mehr) verbunden sind, und wird innerhalb von 5 Minuten behoben.

                • Mit ESXi 7.0 Update 3f unterstützt der Intel-icen-Treiber Netzwerkfunktionen auf E822/E823-Netzwerkkarten für Intel Icelake-D-Plattformen. ENS- (Enhanced Network Stack) und RDMA-Funktionen auf solchen Geräten werden nicht unterstützt.

                • ESXi 7.0 Update 3f aktualisiert den Treiber Intel-ne1000 zur Unterstützung von Intel I219-LM-Geräten, die für neuere Servermodelle erforderlich sind, wie z. B. die Intel Lac-S-Plattform. Der TCP-Segmentierungs-Offload für die I219-Geräte ist aufgrund von bekannten Problemen im Hardware-DMA deaktiviert.

                • Ein sehr seltenes Problem aufgrund eines Nullzeigerfehlers kann dazu führen, dass ESXi-Hosts in IBM FlashSystem V9000-Arrays mit einem violetten Diagnosebildschirm und einem Fehler wie zum Beispiel #PF Exception 14 in world 2098414:CqWorld IP 0xxxxx addr 0xxxx ausfallen.

                • Wenn Sie vSphere FT deaktivieren oder anhalten, verlieren virtuelle Maschinen möglicherweise vorübergehend die Konnektivität und reagieren nicht auf Ping- oder Netzwerkdatenverkehr. Beim Pingen von virtuellen Maschinen treten möglicherweise innerhalb eines kurzen Zeitraums nacheinander Zeitüberschreitungen auf, z. B. innerhalb von 20 Sekunden.

                • Unter bestimmten Bedingungen, z. B. bei einer Erhöhung der gemeinsamen Seitennutzung oder beim Deaktivieren der Nutzung großer Seiten auf VM- oder ESXi-Hostebene, kann die CPU-Nutzung von Windows-VMs, bei denen Virtualization-Based Security (VBS) aktiviert ist, bis zu 100 % erreichen.

              ESXi-7.0U3f-20036589-no-tools
              Profilname ESXi-7.0U3f-20036589-no-tools
              Build Build-Informationen finden Sie unter In dieser Version enthaltene Patches.
              Anbieter VMware, Inc.
              Datum der Veröffentlichung 12. Juli 2022
              Akzeptanzebene PartnerSupported
              Betroffene Hardware Nicht verfügbar
              Betroffene Software Nicht verfügbar
              Betroffene VIBs
              • VMware_bootbank_esxio-combiner_7.0.3-0.50.20036589
              • VMware_bootbank_esx-ui_1.43.8-19798623
              • VMware_bootbank_esx-xserver_7.0.3-0.50.20036589
              • VMware_bootbank_cpu-microcode_7.0.3-0.50.20036589
              • VMware_bootbank_trx_7.0.3-0.50.20036589
              • VMware_bootbank_vsanhealth_7.0.3-0.50.20036589
              • VMware_bootbank_esx-base_7.0.3-0.50.20036589
              • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.3-0.50.20036589
              • VMware_bootbank_gc_7.0.3-0.50.20036589
              • VMware_bootbank_native-misc-drivers_7.0.3-0.50.20036589
              • VMware_bootbank_bmcal_7.0.3-0.50.20036589
              • VMware_bootbank_vsan_7.0.3-0.50.20036589
              • VMware_bootbank_vdfs_7.0.3-0.50.20036589
              • VMware_bootbank_crx_7.0.3-0.50.20036589
              • VMware_bootbank_esx-update_7.0.3-0.50.20036589
              • VMware_bootbank_loadesx_7.0.3-0.50.20036589
              • VMW_bootbank_bnxtroce_216.0.58.0-23vmw.703.0.50.20036589
              • VMW_bootbank_bnxtnet_216.0.50.0-44vmw.703.0.50.20036589
              • VMW_bootbank_lpfc_14.0.169.26-5vmw.703.0.50.20036589
              • VMware_bootbank_lsuv2-lsiv2-drivers-plugin_1.0.0-12vmw.703.0.50.20036589
              • VMW_bootbank_icen_1.4.1.20-1vmw.703.0.50.20036589
              • VMW_bootbank_irdman_1.3.1.22-1vmw.703.0.50.20036589
              • VMW_bootbank_ne1000_0.9.0-1vmw.703.0.50.20036589
              • VMW_bootbank_iser_1.1.0.1-1vmw.703.0.50.20036589
              • VMW_bootbank_vmkusb_0.1-7vmw.703.0.50.20036589
              • VMware_locker_tools-light_12.0.0.19345655-20036586
              Behobene Probleme 2916848, 2817702, 2937074, 2957732, 2984134, 2944807, 2985369, 2907963, 2949801, 2984245, 2915911, 2990593, 2992648, 2905357, 2980176, 2974472, 2974376, 2972059, 2973031, 2967359, 2860126, 2878245, 2876044, 2968157, 2960242, 2970238, 2966270, 2966783, 2963328, 2939395, 2966362, 2946550, 2958543, 2966628, 2961584, 2911056, 2965235, 2952427, 2963401, 2965146, 2963038, 2963479, 2949375, 2961033, 2958926, 2839515, 2951139, 2878224, 2954320, 2952432, 2961346, 2857932, 2960949, 2960882, 2957966, 2929443, 2956080, 2959293, 2944919, 2948800, 2928789, 2957769, 2928268, 2957062, 2792139, 2934102, 2953709, 2950686, 2953488, 2949446, 2955016, 2953217, 2956030, 2949902, 2944894, 2944521, 2911363, 2952205, 2894093, 2910856, 2953754, 2949777, 2925733, 2951234, 2915979, 2904241, 2935355, 2941263, 2912661, 2891231, 2928202, 2928268, 2867146, 2244126, 2912330, 2898858, 2906297, 2912213, 2910340, 2745800, 2912182, 2941274, 2912230, 2699748, 2882789, 2869031, 2913017, 2864375, 2929821, 2957673, 2921564, 2925133, 2965277
              Verwandte CVE-Nummern Nicht verfügbar
              • Dieser Patch enthält Updates zur Behebung der folgenden Probleme:

                • pyVmomi-Aufrufe der vSphere API EnvironmentBrowser.QueryConfigTargetEx schlagen möglicherweise mit UnknownWsdlTypeError fehl.

                • Das Hardwareintegritätsmodul von ESXi kann möglicherweise einige Sensoren des Typs „Systemereignis“ nicht entschlüsseln, wenn ein physischer Server mit einem neuen Branding versehen wird. Infolgedessen wird im vSphere-Client der Status „Unbekannt“ für Sensoren des Typs „Systemereignis“ unter Überwachung > Hardware-Integrität angezeigt.

                • Wenn Sie die erweiterte Einstellung vmx.reboot.powerCycle auf einer virtuellen Maschine auf TRUE festlegen, wird die virtuelle Maschine ausgeschaltet und dann wieder eingeschaltet, wenn das Gastbetriebssystem einen Neustart initiiert. Wenn jedoch während einer Migration mithilfe von vSphere vMotion ein Ein-/Ausschalten stattfindet, schlägt der Vorgang fehl, und die virtuelle Maschine auf dem Quellhost wird möglicherweise nicht wieder eingeschaltet.

                • Wenn bei einem Socket ein Verbindungsfehler auftritt, während er bei der internen Kommunikation zwischen UNIX-Domänen-Sockets abgefragt wird, kann es zu einem Datenrennen kommen. Infolgedessen greift der ESXi-Host in einigen Fällen auf einen ungültigen Arbeitsspeicherbereich zu und fällt mit einem violetten Diagnosebildschirm mit #PF Exception 14 und Fehlern wie UserDuct_PollSize() und UserSocketLocalPoll() aus.

                • Wenn ein Hardware-iSCSI-Adapter auf einem ESXi-Host in Ihrer Umgebung Pseudo-Netzwerkschnittstellenkarten verwendet, können Sie möglicherweise kein Hostprofil von einem solchen Host erstellen, da Pseudo-Netzwerkschnittstellenkarten nicht über die erforderliche PCI-Adresse und den Anbieternamen für ein Profil verfügen.

                • Race-Bedingungen im iscsi_vmk-Treiber können zu blockierten E/A-Vorgängen oder Taktsignal-Zeitüberschreitungen bei einem VMFS-Datenspeicher führen. Dies kann dazu führen, dass einige virtuelle Maschinen nicht mehr reagieren.

                • Der Durchsatz mit Software-iSCSI-Adaptern ist aufgrund hartcodierter Sende- und Empfangspuffergrößen – 600 KB für Sende- bzw. 256 KB für Empfangspuffer – begrenzt. Dies führt dazu, dass die Leistung des iscsi_vmk-Adapters nicht optimal ist.

                • Wenn mehrere NVIDIA vGPU-VMs gleichzeitig ausgeschaltet werden, werden gelegentlich einige GPU-Ressourcen (MIG) mit mehreren Instanzen nicht gelöscht. Dies kann dazu führen, dass das Einschalten der nachfolgenden vGPU-VM aufgrund der verbleibenden MIG-Ressourcen fehlschlägt.

                • Wenn ein NFSv4.1-Server während eines Speicher-Failovers einen vorübergehenden Fehler zurückgibt, können in seltenen Fällen virtuelle Maschinen 10 Sekunden lang nicht reagieren, bevor der Vorgang neu gestartet wird.

                • In seltenen Fällen kann es vorkommen, dass der Paketabschluss nicht am ursprünglichen Port oder Portset, sondern an einem anderen Portset erfolgt, was zu einer Schleife führen kann, die die Paketliste mit einem ungültigen Zeiger beschädigt. Infolgedessen fällt ein ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm aus. In den Protokollen wird beispielsweise folgender Fehler angezeigt: PF Exception 14 in world 61176327:nsx.cp.tx IP 0xxxxxx addr 0x3c.

                • Der Arbeitsspeicher im NUMA-Knoten eines ESXi-Hosts besteht möglicherweise aus mehreren physischen Bereichen. In ESXi-Versionen vor 7.0 Update 3f gibt das Feldpaar memoryRangeBegin, memoryRangeLength in NumaNodeInfo die physikalische Startadresse des Hosts und die Länge des Bereichs im NUMA-Knoten an, wobei alle zusätzlichen Bereiche ignoriert werden.

                • Wenn Sie den schnellen Pfad auf HPP für 512e Software Emulated 4KN-Geräte aktivieren, funktioniert er nicht wie erwartet, da der schnelle Pfad nicht mit Read-Modify-Write(R-M-W) umgehen kann, das den langsamen Pfad verwenden muss. Die Verwendung des schnellen Pfads auf 4KN-Geräten wird nicht unterstützt.

                • Wenn Sie über eine ausgeführte VM mit virtuellen Festplatten mit mehr als 1 TB verfügen und einen Snapshot der Festplatten auf dieser VM löschen, friert die VM möglicherweise für Sekunden oder sogar Minuten ein. Die VM wird letztendlich wiederhergestellt, bei VM-Arbeitslasten können jedoch Ausfälle auftreten. Das Problem tritt auf, weil der Löschvorgang die Konsolidierung von Snapshots im Hintergrund auslöst, was die Verzögerung verursacht. Das Problem tritt eher bei langsamerem Speicher auf, wie z. B. NFS.

                • DVFilter-Pakete werden möglicherweise fälschlicherweise an einen Netzwerkport übertragen, an dem der Paketabschlusscode nicht ausgeführt werden kann. Infolgedessen fallen ESXi-Hosts mit einem violetten Diagnosebildschirm und dem Fehler PF Exception 14 Vmxnet3VMKDevTxCompleteOne E1000DevTxCompleteOneWork aus.

                • In seltenen Fällen sendet die DFW möglicherweise eine Paketliste an das falsche Portset. Dies kann dazu führen, dass der VMkernel-Dienst fehlschlägt und virtuelle Maschinen die Konnektivität verlieren. In der Datei vmkernel.log werden Fehler ähnlich dem Folgenden angezeigt:
                  2021-09-27T04:29:53.170Z cpu84:xxxx)NetPort: 206: Fehler: lockModel[0] vs psWorldState->lockModel[0] there is no portset lock holding.

                • Ab vSphere 7.0 Update 2 wird HPP das Standard-Plug-In für lokale NVMe- und SCSI-Geräte und ersetzt das native Multipathing-Plug-In (NMP) von ESX. In bestimmten Umgebungen führt die Änderung von NMP zu HPP jedoch dazu, dass auf einige Eigenschaften von Geräten, die von HPP beansprucht werden, wie z. B. den Anzeigenamen, nicht zugegriffen werden kann.

                • Wenn in einem ALUA-Ziel die Zielportgruppen-IDs (TPGIDs) für eine LUN geändert werden, wird die vom SATP verwendete Antwort zur Geräteidentifikation im Cache möglicherweise nicht entsprechend aktualisiert. Dies führt dazu, dass ESXi möglicherweise nicht die korrekten Pfadstatus für das entsprechende Gerät wiedergibt.

                • Wenn Sie den NVMe-SCSI-Übersetzungs-Stack zum Registrieren von NVMe-Geräten in Ihrem System verwenden, erhalten die Eigenschaften targetPortGroup und relativeTargetPortId die Controller-ID 0 für alle Pfade. Dies führt dazu, dass ein RTPG-Befehl denselben ALUA-Zugriffsstatus für alle Pfade des Namespace zurückgibt, da die tpgID jedes Pfads mit dem ersten Deskriptor übereinstimmt, der 0 ist.

                • Wenn das Kennwort für den Administrator des Dateidiensts auf dem Active Directory-Server geändert wird, stimmt das Kennwort in der Domänenkonfiguration des vSAN-Dateidiensts möglicherweise nicht überein. Wenn die Kennwörter nicht übereinstimmen oder das Konto gesperrt ist, kann möglicherweise auf einige Dateifreigaben nicht zugegriffen werden. Der vSAN-Integritätsdienst zeigt die folgende Warnung an: Dateidienst: Dateiserver nicht gefunden.

                • Wenn Sie einen ESXi-Host nach einem Ausfall neu installieren, bleiben veraltete Bindungen von VMDKs beim VASA-Anbieter und in den vSphere Virtual Volumes-Datenspeichern intakt, da die ausgefallene Instanz nie neu gestartet wird. Infolgedessen können Sie bei einer Neuinstallation des Hosts die VMDKs aufgrund der vorhandenen Bindung nicht löschen. Im Laufe der Zeit können sich viele solche VMDKs ansammeln und ungenutzten Speicherplatz verbrauchen.

                • In seltenen Fällen verfügt ein serielles Gerät auf einer virtuellen Maschine nicht über die Eigenschaft serial<N>.fileName, während gleichzeitig die Eigenschaft serial<N>.autodetect auf FALSE festgelegt ist. Dies kann dazu führen, dass der hostd-Dienst wiederholt fehlschlägt.

                • Wenn Sie im vSphere Client eine der Traffic-Shaping-Optionen wie „Durchschnittliche Bandbreite“, „Spitzenbandbreite“ oder „Burstgröße“ auf einen Wert festlegen, der größer als 2147483 KBit/s ist, werden die Einstellungen nicht beibehalten.

                • Aufgrund der geringen Standardanzahl an Dateideskriptoren können einige Funktionen wie vSphere vMotion nach dem Upgrade auf ESXi 7.x in VAAI für NAS-Umgebungen wegen der unzureichenden Anzahl an VMDK-Dateien, die gleichzeitig ausgeführt werden können, fehlschlagen. In der Datei syslog.log werden Fehler wie Zu viele offene Dateien in den Protokollen des vaai-nas-Daemon angezeigt.

                • Wenn in seltenen Fällen eine E/A-Anforderung parallel mit einem vom Gastbetriebssystem ausgelösten Aufhebevorgang auf einer Thin-Provisioning-VM ausgeführt wird, kann es in manchen Fällen zu einem Deadlock auf einem VMFS6-Volume kommen. Folglich reagieren virtuelle Maschinen auf diesem Volume nicht mehr.

                • Bei vSphere Storage vMotion- oder Hot-Add-Vorgängen auf einer virtuellen Maschine mit mehr als 300 GB Arbeitsspeicher kann sich die Switchover-Zeit 2 Minuten nähern, was zu einem Zeitüberschreitungsfehler führt.

                • Wenn Sie die Port-Bindung nicht entfernen, nachdem Sie eine VMkernel-Netzwerkkarte gelöscht haben, die an einen iSCSI-Adapter gebunden ist, kann die veraltete Port-Bindung Probleme nach einem Neustart des ESXi-Hosts verursachen. Während des Startvorgangs schlägt die Bindung der nicht vorhandenen VMkernel-Netzwerkkarte an den iSCSI-Adapter fehl, und iSCSI-Konfigurationen können während des Startvorgangs nicht wiederhergestellt werden. Infolgedessen werden nach Abschluss des Neustarts möglicherweise einige LUNs oder Datenspeicher nicht angezeigt.

                • Nach einem Speicher-Failover erkennt der ESXi NFSv4.1-Client den NFS-Server fälschlicherweise als eine andere Einheit und überspringt die Wiederherstellung. Dies führt dazu, dass der NFSv4.1-Datenspeicher im Status Kein Zugriff verbleibt.

                • In einigen Fällen, z. B. wenn die Temperatur den Schwellenwert überschreitet, meldet ein NVMe-Gerät möglicherweise eine kritische Warnung, und der ESXi NVMe-Controller registriert das Gerät nicht und schaltet es offline.

                • Ein seltenes Problem, bei dem der verwendete Block-Cache den reservierten Cache überschreitet, kann zu Reservierungsproblemen im vSAN-Dateidienst führen. Infolgedessen können Sie einige Dateifreigaben nicht erreichen, und die Integritätsprüfung zeigt den Fehler VDFS-Daemon wird nicht ausgeführt. Im vdfsd-server-Protokoll werden Fehler ähnlich dem Folgenden angezeigt:
                  PANIC: NOT_IMPLEMENTED bora/vdfs/core/VDFSPhysicalLog.cpp:621
                  PANIC: NOT_IMPLEMENTED bora/vdfs/core/VDFSPhysicalLog.cpp:626

                • In seltenen Fällen können Suchabfragen im Hintergrund, die von vCenter Server auf einem ESXi-Host mit Zugriff auf die VMDK-Dateien virtueller in ein OVF-Format exportierter Maschinen ausgeführt werden, die Dateien versehentlich ändern. Infolgedessen können Sie die virtuellen Maschinen nicht importieren.

                • Aufgrund eines Komponentenlastproblems schlägt das Hinzufügen einer Multipathing-PSA-Beanspruchungsregel zum Satz von Beanspruchungsregeln auf einem vCenter Server-System unter Verwendung des JumpStart-Tools möglicherweise fehl.

                • Nach einem kontrollierten Herunterfahren oder Starten eines Servers in einem Cluster von ESXi-Servern, die mit einem ALUA-Array verbunden sind, werden alle LUNs, auf die dieser Server Zugriff hat, möglicherweise auf einen Speicherprozessor im Array übertragen. Infolgedessen verschlechtert sich die Leistung der anderen ESXi-Server, die auf die LUNs zugreifen.

                • Bei einer hohen Arbeitsspeicherbelastung verarbeitet PSA in seltenen Fällen Fehler bei der Arbeitsspeicherzuteilung nicht ordnungsgemäß. Infolgedessen fällt der ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm und einem Fehler wie #PF Exception 14 in world 2098026:SCSI path sc IP / SCSI path scan helpers aus.

                • Wenn eine ausgeführte virtuelle Maschine während eines Snapshot-Löschvorgangs neu gestartet wird, werden die VM-Festplatten möglicherweise während der Snapshot-Konsolidierung nicht ordnungsgemäß neu geöffnet und geschlossen. Infolgedessen fällt die VM möglicherweise aus. Dies ist jedoch ein Zeitproblem, das versehentlich auftritt.

                • Während der Geräteerkennung kann ein Reservierungskonflikt dazu führen, dass ATS fälschlicherweise als nicht unterstützt gemeldet wird. Aus diesem Grund verwendet ESXi die SCSI-2-Reservierung anstelle von ATS. Dies führt dazu, dass das Mounten von VMFS6-Datenspeichern mit aktivierter Cluster-VMDK-Unterstützung möglicherweise zufällig fehlschlägt.

                • Bei einigen Vorgängen kann die Host-UUID geändert werden. Wenn Sie beispielsweise ESXi-Software neu installieren oder den Host zwischen Clustern verschieben, kann sich die Host-UUID gegebenenfalls ändern. Wenn sich die Host-UUID während des Ausfalls des vSAN-Dateidiensts ändert, können vSAN-Dateidienstserver nicht gestartet werden.

                • Wenn Sie den vSAN-Dateidienst ohne vorhandene Dateifreigaben deaktivieren, entfernt vSAN die Dateidienstdomäne. Ein Entfernungsfehler eines Servers unterbricht möglicherweise den Prozess und hinterlässt einige Metadaten. Wenn Sie den Dateidienst erneut aktivieren, funktioniert der Dateidienst aufgrund der alten Metadaten möglicherweise nicht wie erwartet.

                • Der Befehl „Zielportgruppen des Berichts“ gibt möglicherweise im Feld IMPLIZITE ÜBERGANGSZEIT einen falschen Wert zurück, was sich auf die SCSI-zu-NVMe-Übersetzungsschicht auswirkt. In Fällen wie der Migration mehrerer Appliances ist die Zeit für den ALUA-Übergang für Multipathing-Software, beispielsweise PowerPath, zur Durchführung korrekter Vorgänge von entscheidender Bedeutung.

                • Kleine ausstehende Zuordnungsaufhebungen werden möglicherweise blockiert, wenn Sie einen Host neu starten oder eine Festplattengruppe erneut mounten. Die ausstehenden Zuordnungsaufhebungen können zu einer Protokollüberlastung führen, die E/A-Latenz zur Folge hat.

                • Nach dem ersten Upgrade oder Update Ihres Systems auf ESXi 7.x findet bei jedem nachfolgenden Update, das auch als Patch bezeichnet wird, möglicherweise eine Kürzung der Angaben im Pfad zum Verzeichnis /productLocker in einem Datenspeicher statt. Wenn Ihr erster Patch auf ESXi 7.x beispielsweise von 7.0 Update 2 zu 7.0 Update 3 führt, ist das Verzeichnis /productLocker ursprünglich dem Verzeichnis /vmfs/volumes/xxx/VMware-Tools/productLocker/ ähnlich. Für jeden nachfolgenden Patch, z. B. von 7.0 Update 3 auf 7.0 Update 3c, ähnelt der Pfad jedoch /VMware-Tools/productLocker/.

                • In einem vSAN Stretched Cluster oder einem Cluster mit zwei Knoten werden quorumbasierte Entscheidungen für Objekte mit PFTT von 1 und SFTT von 1 oder mehr möglicherweise nicht ordnungsgemäß verteilt. Wenn eine Site ausfällt und ein zusätzlicher Host oder eine zusätzliche Festplatte auf der aktiven Site ausfällt, verliert das Objekt möglicherweise das Quorum, und es kann nicht mehr darauf zugegriffen werden.

                • Eine Anforderung zur Größenänderung eines Objekts kann fehlschlagen, wenn die neue Größe nicht auf 512 Byte ausgerichtet ist. Dieses Problem kann dazu führen, dass ein ESXi-Host mit einem violetten Diagnosebildschirm ausfällt.

                • In einigen Fällen, z. B. beim Neustart einer virtuellen Maschine, kann eine laufende SSH-Sitzung, die das Dienstprogramm „pktcap-uw“ zur Überwachung und Validierung von Switch-Konfigurationen auf dem ESXi-Host verwendet, beendet werden. Das Dienstprogramm „pktcap-uw“ versucht möglicherweise weiterhin, Pakete zu verarbeiten. Dies führt dazu, dass das Dienstprogramm mehr CPU verbraucht als normal. Mit dem Befehl esxtop -a können Sie die CPU-Leistung nachverfolgen.

                • Auf einem vCenter Server unter 7.0 Update 3 kann ein zertifiziertes NVMe-Gerät die folgende Warnung für die Integritätsprüfung aufweisen: NVMe-Gerät ist nicht für VMware zertifiziert. Möglicherweise wird auch die folgende Integritätsprüfungswarnung angezeigt: NVMe-Gerät kann nicht identifiziert werden.

                • Der ESXCLI-Befehl hardware ipmi bmc get gibt aufgrund einer falschen Analyse die IPv6-Adresse eines BMC nicht zurück.

                • Wenn der Zeugenhost von Clusterhosts nicht erreicht werden kann, fällt der Assistent zum Herunterfahren des vSAN-Clusters für einen Stretched Cluster oder einen Cluster mit zwei Knoten möglicherweise aus. Dieses Problem tritt auf, wenn für den vSAN-Datenverkehr und den Zeugen-Datenverkehr verschiedene vmknics verwendet werden. Im vSphere Client wird die folgende Fehlermeldung auf der Seite „vSAN-Dienste“ angezeigt: Getrennter Host von Orch gefunden <Zeugen-IP>. Wenn vCenter im Cluster gehostet wird, ist der vSphere Client beim Herunterfahren nicht verfügbar, und die Fehlermeldung wird auf dem Host Client angezeigt, auf dem sich die vCenter-VM befindet.

                • Wenn Sie im vSphere Client mit der rechten Maustaste klicken, um einen Datenspeicher zu durchsuchen, wird anstelle der Namen möglicherweise die UUID einiger virtueller Maschinen in einem vSphere Virtual Volumes-Datenspeicher angezeigt, wie z. B. naa.xxxx. Dieses Problem tritt nur selten in großen Umgebungen mit einer großen Anzahl von Containern und VMs in einem vSphere Virtual Volumes-Datenspeicher auf. Das Problem hat keine funktionalen Auswirkungen, wie z. B. Auswirkungen auf VM-Vorgänge, Sicherungen oder andere Elemente als die VM-Anzeige im vSphere Client.

                • Aufgrund eines seltenen Problems im Zusammenhang mit der ESXi-Infrastruktur kann ein langsamer VASA-Anbieter eine Situation auslösen, in der auf die vSphere Virtual Volumes-Datenspeicher nicht zugegriffen werden kann und der ESXi-Host nicht mehr reagiert.

                • Wenn Sie in bestimmten Umgebungen einen ESXi-Host herunterfahren, wird dieser nicht ausgeschaltet, und es wird ein Bildschirm mit der Meldung Dieses System wurde angehalten angezeigt. Mit der Schaltfläche zum Zurücksetzen oder zum Ein-/Ausschalten kann ein sicherer Neustart durchgeführt werden.

                • Die Einstellung LargeBAR, die das Basisadressregister (Base Address Register, BAR) auf einem vmxnet3-Gerät erweitert, unterstützt einheitliches Passthrough (Uniform Passthrough, UPT). UPT wird jedoch unter ESX 7.0 Update 3 und höher nicht unterstützt, und wenn der vmxnet3-Treiber auf eine Version vor 7.0 herabgestuft wird und die Einstellung LargeBAR aktiviert ist, verlieren die virtuellen Maschinen möglicherweise die Konnektivität.

                • Wenn Sie unabhängige, nicht dauerhafte Festplatten im laufenden Betrieb von einer virtuellen Maschine entfernen, für die der Konfigurationsparameter vmx.reboot.PowerCycle aktiviert ist, speichert ESXi eine Redo-Protokolldatei. Wenn es sich bei einer solchen VM um eine Sicherungs-Proxy-VM handelt, werden möglicherweise viele redundante Redo-Protokolldateien angezeigt, die einen erheblichen Teil des Speichers in Anspruch nehmen.

                • Wenn ein ESXi-Host versucht, über einen Ressourcenpool-Cache auf einen nicht im Cache enthaltenen Eintrag zuzugreifen, fällt der Host zeitweise mit einem violetten Diagnosebildschirm PF Exception 14 und einer Core-Dump-Datei aus. In der Dump-Datei werden Fehler für die Module J3_DeleteTransaction und J6ProcessReplayTxnList angezeigt, die auf das Problem hinweisen.

                • Ein seltenes Problem im Zusammenhang mit VMFS kann bei grundlegenden Dateisystemaufrufen wie open, access oder rename zu hochgradigen Sperrungskonflikten bei hostd-Dienst-Threads oder sogar zu Deadlocks führen. Folglich reagiert der ESXi-Host nicht mehr.

                • Da das MD5-Authentifizierungsprotokoll ab ESXi 7.x nicht mehr unterstützt wird, schlagen Upgrades auf ESXi 7.x fehl, wenn für eine ESXi-SNMP-Agent-Konfiguration das MD5-Authentifizierungsprotokoll verwendet wird.

                • In ESXi 7.x toleriert der Parameter Syslog.global.logHost, der eine kommagetrennte Liste von Remote-Hosts und Spezifikationen für Nachrichtenübertragungen definiert, keine Leerzeichen nach dem Komma. ESXi-Versionen vor 7.x tolerieren im Parameter Syslog.global.logHost ein Leerzeichen nach dem Komma. Dies kann dazu führen, dass Upgrades auf ESXi 7.x fehlschlagen.

                • Ein Problem im Zusammenhang mit der probabilistischen Datenstruktur „Bloom-Filter“, die die Lese-E/A für in einem Snapshot ausgeführte VMs optimieren soll, kann zu einem logischen, konsistenzbasierten E/A-Fehler führen, wenn die VM auf einem Snapshot ausgeführt wird. Das Problem ist begrenzt und tritt nur auf, wenn Sie SQL Server in einem Snapshot ausführen.

                • Ein Problem mit dem Prozess, der Datenspeicher zur Unterstützung von Dateiblockzuteilungen für Thin-Dateien prüft, kann in bestimmten Fällen zu einer CPU-Sperre führen. Dies führt dazu, dass der ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm und einer Fehlermeldung ähnlich der folgenden ausfällt: PSOD - @BlueScreen: NMI.

                • Die Protokolldateien des hostd-Diensts erhalten möglicherweise eine ungewöhnlich hohe Anzahl von Meldungen des Typs Task Created und Task Completed für unsichtbare Aufgaben, was wiederum die Aufbewahrungszeit für Protokolle verringern kann. 

                • Wenn ein SCSI-Befehl für einen Protokollendpunkt eines vSphere Virtual Volumes-Datenspeichers fehlschlägt, erhält der Endpoint möglicherweise den Status „Nicht unterstützt“, der möglicherweise zwischengespeichert wird. Dies führt dazu, dass die folgenden an diesen Protokollendpunkt gerichteten SCSI-Befehle mit einem Fehlercode wie 0x5 0x20 fehlschlagen und Lese- und Schreibvorgänge in einem vSphere Virtual Volumes-Datenspeicher fehlschlagen.

                • In einigen Fällen, z. B. bei einem Portausfallfehler, verlieren ESXi-Hosts möglicherweise die Konnektivität zum NVMe-Controller, obwohl einige E/A-Warteschlangen weiterhin aktiv sind.

                • Wenn Sie eine virtuelle Maschine mithilfe von vSphere Replication replizieren, und die VM-Festplatte auf eine Zahl erhöht wird, die nicht auf 512 ausgerichtet ist, kann die VM nicht eingeschaltet werden.

                • Wenn die Anzahl der CPUs, die Sie mit dem Parameter ConfigSpec#numCPUs konfigurieren, kein Vielfaches der Kerne pro Socket ist, die Sie in der Konfiguration einer virtuellen Maschine mit dem Parameter ConfigSpec#numCoresPerSocket definieren, lässt sich die VM nicht einschalten.

                • Dieses Problem betrifft Hosts in Stretched Clustern mit den Richtlinieneinstellungen locality=None, HFT=0, SFT=1 und SFT=2. Wenn Sie einen Host mit „Zugriff sicherstellen“ in den Wartungsmodus versetzen, bleibt der Vorgang möglicherweise für einen langen Zeitraum bei 100 % oder schlägt nach 60 Minuten fehl.

                • Nach dem Upgrade eines ESXi-Hosts auf 7.0 Update 2 bemerken Sie möglicherweise häufige vSAN-Netzwerklatenz-Alarme für den Cluster, wenn der vSAN-Leistungsdienst aktiviert ist. Die Latenzergebnisse zeigen, dass die meisten Alarme vom primären vSAN-Knoten ausgegeben werden.

                • Aufgrund einer Größenänderung der standardmäßigen Admin-Warteschlange für NVMe over RDMA-Controller in ESXi 7.0 Update 3c kann es vorkommen, dass nach Updates von ESXi 7.0, 7.0 Update 1 oder 7.0 Update 2 auf 7.0 Update 3c nicht mehr auf NVMe over RDMA-Speicher zugegriffen werden kann.

                • Aufgrund einer seltenen Race-Bedingung beim Versuch eines Container-Ports, eine bereits abgerufene Sperre erneut abzurufen, kann ein ESXi-Host mit einem violetten Diagnosebildschirm fehlschlagen, wenn virtuelle Maschinen mit Container-Ports ausgeschaltet werden oder eine Migration mit vSphere vMotion durchführen. Dieses Problem tritt aufgrund der Duplizierung von Port-IDs auf.

                • ESXi-Hosts verlieren nach dem Upgrade des lpfc-Treibers auf 14.0.x.x möglicherweise den Zugriff auf Unity-Speicher-Arrays. In den Treiberprotokollen werden Fehler wie Protokollfehler bei der Verarbeitung von FCP-E/A erkannt und rspInfo3 x2 angezeigt.

                • Bei LSI-bezogenen Treibern kann es beim Hochfahren eines ESXi-Servers, wenn Sie eine Festplatte herausnehmen und in einen anderen Steckplatz auf demselben Host einsetzen, lange dauern, bis Änderungen am Speicherort der Festplatte über den vSphere Client oder mithilfe des ESXCLI-Befehls esxcli storage core device physical get -d sichtbar werden. Das Problem besteht speziell bei Treibern, die mit vielen Festplatten (150 und mehr) verbunden sind, und wird innerhalb von 5 Minuten behoben.

                • Mit ESXi 7.0 Update 3f unterstützt der Intel-icen-Treiber Netzwerkfunktionen auf E822/E823-Netzwerkkarten für Intel Icelake-D-Plattformen. ENS- (Enhanced Network Stack) und RDMA-Funktionen auf solchen Geräten werden nicht unterstützt.

                • ESXi 7.0 Update 3f aktualisiert den Treiber Intel-ne1000 zur Unterstützung von Intel I219-LM-Geräten, die für neuere Servermodelle erforderlich sind, wie z. B. die Intel Lac-S-Plattform. Der TCP-Segmentierungs-Offload für die I219-Geräte ist aufgrund von bekannten Problemen im Hardware-DMA deaktiviert.

                • Ein sehr seltenes Problem aufgrund eines Nullzeigerfehlers kann dazu führen, dass ESXi-Hosts in IBM FlashSystem V9000-Arrays mit einem violetten Diagnosebildschirm und einem Fehler wie zum Beispiel #PF Exception 14 in world 2098414:CqWorld IP 0xxxxx addr 0xxxx ausfallen.

                • Wenn Sie vSphere FT deaktivieren oder anhalten, verlieren virtuelle Maschinen möglicherweise vorübergehend die Konnektivität und reagieren nicht auf Ping- oder Netzwerkdatenverkehr. Beim Pingen von virtuellen Maschinen treten möglicherweise innerhalb eines kurzen Zeitraums nacheinander Zeitüberschreitungen auf, z. B. innerhalb von 20 Sekunden.

                • Unter bestimmten Bedingungen, z. B. bei einer Erhöhung der gemeinsamen Seitennutzung oder beim Deaktivieren der Nutzung großer Seiten auf VM- oder ESXi-Hostebene, kann die CPU-Nutzung von Windows-VMs, bei denen Virtualization-Based Security (VBS) aktiviert ist, bis zu 100 % erreichen.

              ESXi-7.0U3sf-20036586-standard
              Profilname ESXi-7.0U3sf-20036586-standard
              Build Build-Informationen finden Sie unter In dieser Version enthaltene Patches.
              Anbieter VMware, Inc.
              Datum der Veröffentlichung 12. Juli 2022
              Akzeptanzebene PartnerSupported
              Betroffene Hardware Nicht verfügbar
              Betroffene Software Nicht verfügbar
              Betroffene VIBs
              • VMware_bootbank_native-misc-drivers_7.0.3-0.45.20036586
              • VMware_bootbank_bmcal_7.0.3-0.45.20036586
              • VMware_bootbank_esx-ui_1.43.8-19798623
              • VMware_bootbank_vsanhealth_7.0.3-0.45.20036586
              • VMware_bootbank_esxio-combiner_7.0.3-0.45.20036586
              • VMware_bootbank_esx-xserver_7.0.3-0.45.20036586
              • VMware_bootbank_trx_7.0.3-0.45.20036586
              • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.3-0.45.20036586
              • VMware_bootbank_vdfs_7.0.3-0.45.20036586
              • VMware_bootbank_vsan_7.0.3-0.45.20036586
              • VMware_bootbank_cpu-microcode_7.0.3-0.45.20036586
              • VMware_bootbank_esx-base_7.0.3-0.45.20036586
              • VMware_bootbank_gc_7.0.3-0.45.20036586
              • VMware_bootbank_crx_7.0.3-0.45.20036586
              • VMware_bootbank_esx-update_7.0.3-0.45.20036586
              • VMware_bootbank_loadesx_7.0.3-0.45.20036586
              • VMware_locker_tools-light_12.0.0.19345655-20036586
              Behobene Probleme

              2920287, 2946147, 2946217, 2946222, 2946671, 2946863, 2947156, 2951864, 2951866, 2972147, 2972151, 2816546
              Verwandte CVE-Nummern

              CVE-2004-0230, CVE-2020-7451, CVE-2015-2923, CVE-2015-5358, CVE-2013-3077, CVE-2015-1414, CVE-2018-6918, CVE-2020-7469, CVE-2019-5611, CVE-2020-7457, CVE-2018-6916, CVE-2019-5608, CVE-2022-23816, CVE-2022-23825, CVE-2022-28693, CVE-2022-29901
              • Dieser Patch enthält Updates zur Behebung der folgenden Probleme:
                  • Der XML-Parser Expat wurde auf Version 2.4.7 aktualisiert.
                  • Die SQLite-Datenbank wurde auf Version 3.37.2 aktualisiert.
                  • Die cURL-Bibliothek wurde auf Version 7.81.0 aktualisiert.
                  • Das OpenSSL-Paket wurde auf Version openssl-1.0.2ze aktualisiert.
                  • Die userworld-libxml2-Bibliothek von ESXi wurde auf Version 2.9.14 aktualisiert.
                  • Das Python-Paket wurde auf 3.8.13 aktualisiert.
                  • Die zlib-Bibliothek wurde auf 1.2.12 aktualisiert.
                  • In dieser Version wurde CVE-2004-0230 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem niedrigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 3,7.
                  • In dieser Version wurde CVE-2020-7451 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem mittleren Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 5,3.
                  • In dieser Version wurde CVE-2015-2923 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem mittleren Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 6,5.
                  • In dieser Version wurde CVE-2015-5358 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem mittleren Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 6,5.
                  • In dieser Version wurde CVE-2013-3077 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem wichtigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 7,0.
                  • In dieser Version wurde CVE-2015-1414 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem wichtigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 7,5.  
                  • In dieser Version wurde CVE-2018-6918 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem wichtigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 7,5.
                  • In dieser Version wurde CVE-2020-7469 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem wichtigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 7,5.
                  • In dieser Version wurde CVE-2019-5611 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem wichtigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 7,5. 
                  • In dieser Version wurde CVE-2020-7457 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem wichtigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 7,8. 
                  • In dieser Version wurde CVE-2018-6916 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem wichtigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 8,1.
                  • In dieser Version wurde CVE-2019-5608 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem wichtigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 8,1.

                • In dieser Version werden die folgenden Schwachstellen behoben: CVE-2022-23816, CVE-2022-23825, CVE-2022-28693 und CVE-2022-29901. Weitere Informationen zu diesen Schwachstellen und deren Auswirkungen auf VMware-Produkte finden Sie unter VMSA-2022-0020.

              ESXi-7.0U3sf-20036586-no-tools
              Profilname ESXi-7.0U3sf-20036586-no-tools
              Build Build-Informationen finden Sie unter In dieser Version enthaltene Patches.
              Anbieter VMware, Inc.
              Datum der Veröffentlichung 12. Juli 2022
              Akzeptanzebene PartnerSupported
              Betroffene Hardware Nicht verfügbar
              Betroffene Software Nicht verfügbar
              Betroffene VIBs
              • VMware_bootbank_native-misc-drivers_7.0.3-0.45.20036586
              • VMware_bootbank_bmcal_7.0.3-0.45.20036586
              • VMware_bootbank_esx-ui_1.43.8-19798623
              • VMware_bootbank_vsanhealth_7.0.3-0.45.20036586
              • VMware_bootbank_esxio-combiner_7.0.3-0.45.20036586
              • VMware_bootbank_esx-xserver_7.0.3-0.45.20036586
              • VMware_bootbank_trx_7.0.3-0.45.20036586
              • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.3-0.45.20036586
              • VMware_bootbank_vdfs_7.0.3-0.45.20036586
              • VMware_bootbank_vsan_7.0.3-0.45.20036586
              • VMware_bootbank_cpu-microcode_7.0.3-0.45.20036586
              • VMware_bootbank_esx-base_7.0.3-0.45.20036586
              • VMware_bootbank_gc_7.0.3-0.45.20036586
              • VMware_bootbank_crx_7.0.3-0.45.20036586
              • VMware_bootbank_esx-update_7.0.3-0.45.20036586
              • VMware_bootbank_loadesx_7.0.3-0.45.20036586
              Behobene Probleme 2920287, 2946147, 2946217, 2946222, 2946671, 2946863, 2947156, 2951864, 2951866, 2972147, 2972151, 2816546
              Verwandte CVE-Nummern CVE-2004-0230, CVE-2020-7451, CVE-2015-2923, CVE-2015-5358, CVE-2013-3077, CVE-2015-1414, CVE-2018-6918, CVE-2020-7469, CVE-2019-5611, CVE-2020-7457, CVE-2018-6916, CVE-2019-5608, CVE-2022-23816, CVE-2022-23825, CVE-2022-28693, CVE-2022-29901
              • Dieser Patch enthält Updates zur Behebung der folgenden Probleme:
                  • Der XML-Parser Expat wurde auf Version 2.4.7 aktualisiert.
                  • Die SQLite-Datenbank wurde auf Version 3.37.2 aktualisiert.
                  • Die cURL-Bibliothek wurde auf Version 7.81.0 aktualisiert.
                  • Das OpenSSL-Paket wurde auf Version openssl-1.0.2ze aktualisiert.
                  • Die userworld-libxml2-Bibliothek von ESXi wurde auf Version 2.9.14 aktualisiert.
                  • Das Python-Paket wurde auf 3.8.13 aktualisiert.
                  • Die zlib-Bibliothek wurde auf 1.2.12 aktualisiert.
                  • In dieser Version wurde CVE-2004-0230 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem niedrigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 3,7.
                  • In dieser Version wurde CVE-2020-7451 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem mittleren Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 5,3.
                  • In dieser Version wurde CVE-2015-2923 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem mittleren Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 6,5.
                  • In dieser Version wurde CVE-2015-5358 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem mittleren Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 6,5.
                  • In dieser Version wurde CVE-2013-3077 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem wichtigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 7,0.
                  • In dieser Version wurde CVE-2015-1414 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem wichtigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 7,5.  
                  • In dieser Version wurde CVE-2018-6918 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem wichtigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 7,5.
                  • In dieser Version wurde CVE-2020-7469 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem wichtigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 7,5.
                  • In dieser Version wurde CVE-2019-5611 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem wichtigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 7,5. 
                  • In dieser Version wurde CVE-2020-7457 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem wichtigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 7,8. 
                  • In dieser Version wurde CVE-2018-6916 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem wichtigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 8,1.
                  • In dieser Version wurde CVE-2019-5608 behoben. Nach der Auswertung von VMware liegt der Schweregrad dieses Problems in einem wichtigen Schweregradbereich mit einer maximalen CVSSv3-Basispunktzahl von 8,1.

                • In dieser Version werden die folgenden Schwachstellen behoben: CVE-2022-23816, CVE-2022-23825, CVE-2022-28693 und CVE-2022-29901. Weitere Informationen zu diesen Schwachstellen und deren Auswirkungen auf VMware-Produkte finden Sie unter VMSA-2022-0020.

              ESXi Image – ESXi70U3f-20036589
              Name ESXi
              Version ESXi70U3f-20036589
              Datum der Veröffentlichung 12. Juli 2022
              Kategorie Fehlerkorrektur
              Betroffene Komponenten
              • ESXi-Komponente - ESXi-Kern-VIBs
              • ESXi-Komponente „Installieren/Aktualisieren“
              • Broadcom NetXtreme-E-Netzwerk- und ROCE/RDMA-Treiber für VMware ESXi
              • Netzwerktreiber für Intel(R) E810-Adapter
              • Netzwerktreiber für Intel(R) X722- und E810-basierte RDMA-Adapter
              • Nativer iSER-Treiber von VMware
              • Broadcom Emulex Connectivity Division lpfc-Treiber für FC-Adapter
              • LSI NATIVE DRIVERS LSU-Verwaltungs-Plug-In
              • Netzwerktreiber für Adapter der Intel PRO/1000-Familie
              • USB-Treiber
              Behobene Probleme 

              2916848, 2817702, 2937074, 2957732, 2984134, 2944807, 2985369, 2907963, 2949801, 2984245, 2911320 , 2915911, 2990593, 2992648, 2905357, 2980176, 2974472, 2974376, 2972059, 2973031, 2967359, 2860126, 2878245, 2876044, 2968157, 2960242, 2970238, 2966270, 2966783, 2963328, 2939395, 2966362, 2946550, 2958543, 2966628, 2961584, 2911056, 2965235, 2952427, 2963401, 2965146, 2963038, 2963479, 2949375, 2961033, 2958926, 2839515, 2951139, 2878224, 2954320, 2952432, 2961346, 2857932, 2960949, 2960882, 2957966, 2929443, 2956080, 2959293, 2944919, 2948800, 2928789, 2957769, 2928268, 2957062, 2792139, 2934102, 2953709, 2950686, 2953488, 2949446, 2955016, 2953217, 2956030, 2949902, 2944894, 2944521, 2911363, 2952205, 2894093, 2910856, 2953754, 2949777, 2925733, 2951234, 2915979, 2904241, 2935355, 2941263, 2912661, 2891231, 2928202, 2928268, 2867146, 2244126, 2912330, 2898858, 2906297, 2912213, 2910340, 2745800, 2912182, 2941274, 2912230, 2699748, 2882789, 2869031, 2913017, 2864375, 2929821, 2957673, 2921564, 2925133, 2965277, 2980176
              Verwandte CVE-Nummern Nicht verfügbar
                ESXi Image – ESXi70U3sf-20036586
                Name ESXi
                Version ESXi70U3sf-20036586
                Datum der Veröffentlichung 12. Juli 2022
                Kategorie Sicherheit
                Betroffene Komponenten
                • ESXi-Komponente - ESXi-Kern-VIBs
                • ESXi-Komponente „Installieren/Aktualisieren“
                • VMware-VM-Tools
                Behobene Probleme  2920287, 2946147, 2946217, 2946222, 2946671, 2946863, 2947156, 2951864, 2951866, 2972147, 2972151
                Verwandte CVE-Nummern CVE-2004-0230, CVE-2020-7451, CVE-2015-2923, CVE-2015-5358, CVE-2013-3077, CVE-2015-1414, CVE-2018-6918, CVE-2020-7469, CVE-2019-5611, CVE-2020-7457, CVE-2018-6916, CVE-2019-5608, CVE-2022-23816, CVE-2022-23825, CVE-2022-28693, CVE-2022-29901

                  Bekannte Probleme

                  Die bekannten Probleme gliedern sich in folgende Gruppen.

                  Probleme in Bezug auf den vSphere Client
                  • BIOS-Hersteller wird im vSphere Client als „--“ angezeigt

                    Wenn Sie im vSphere Client einen ESXi-Host auswählen und zu Konfigurieren > Hardware > Firmware navigieren, wird anstelle des BIOS-Herstellernamens -- angezeigt.

                    Problemumgehung: Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 88937.

                  Sonstige Probleme
                  • USB-Geräte-Passthrough von ESXi-Hosts zu virtuellen Maschinen schlägt möglicherweise fehl

                    Ein USB-Modemgerät beansprucht möglicherweise gleichzeitig mehrere Schnittstellen durch den VMkernel und blockiert das Geräte-Passthrough zu VMs.
                    Problemumgehung: Sie müssen die erweiterte Konfiguration USB.quirks auf den ESXi-Host anwenden, um die NET-Schnittstelle von VMkernel zu ignorieren und das Passthrough des USB-Modems zu VMs zuzulassen. Sie können die Konfiguration auf drei verschiedene Arten anwenden:

                    1. Greifen Sie auf die ESXi-Shell zu und führen Sie den folgenden Befehl aus: esxcli system settings advanced set -o /USB/quirks -s 0xvvvv:0xpppp:0:0xffff:UQ_NET_IGNORE | |- Device Product ID |------- Device Vendor ID
                      Für das Gemalto M2M GmbH Zoom 4625-Modem (vid:pid/1e2d:005b) können Sie beispielsweise den folgenden Befehl verwenden
                      esxcli system settings advanced set -o /USB/quirks -s 0x1e2d:0x005b:0:0xffff:UQ_NET_IGNORE
                      Starten Sie den ESXi-Host neu.
                    2. Legen Sie die erweiterte Konfiguration über den vSphere Client oder den vSphere Web Client fest und starten Sie den ESXi-Host neu.
                    3. Verwenden Sie ein Hostprofil, um die erweiterte Konfiguration anzuwenden.

                    Weitere Informationen zu diesen Schritten finden Sie im VMware-Knowledgebase-Artikel 80416.

                  Bekannte Probleme aus vorherigen Versionen

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

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