ESXi 7.0 Update 2c | 24. August 2021 | Build 18426014

Überprüfen Sie, ob Erweiterungen und Updates für diese Versionshinweise zur Verfügung stehen.

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

Neuigkeiten

  • ESXi 7.0 Update 2c enthält Fehler- und Sicherheitskorrekturen, die im Abschnitt Behobene Probleme dokumentiert sind.

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.

Weitere Informationen zu ESXi-Versionen, die ein Upgrade auf ESXi 7.0 Update 2c unterstützen, finden Sie im VMware-Knowledgebase-Artikel 67077.

In dieser Version enthaltene Patches

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

Build-Details

Download-Dateiname: VMware-ESXi-7.0U2c-18426014-depot
Build: 18426014
Download-Größe: 580,8 MB
md5sum: a6b2d1e3a1a071b8d93a55d7a7fc0b63
sha1checksum: 829da0330f765b4ae46c2fb5b90a8b60f90e4e5b
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.2-0.20.18426014 Fehlerkorrektur Kritisch
Emulex FC-Treiber Broadcom-ELX-lpfc_12.8.298.3-2vmw.702.0.20.18426014 Fehlerkorrektur Kritisch
Broadcom NetXtreme-E-Netzwerk- und ROCE/RDMA-Treiber für VMware ESXi Broadcom-bnxt-Net-RoCE_216.0.0.0-1vmw.702.0.20.18426014 Fehlerkorrektur Wichtig
QLogic FastLinQ 10/25/40/50/100 GbE-Ethernet- und RoCE/RDMA-Treiber für VMware ESXi MRVL-E4-CNA-Driver-Bundle_1.0.0.0-1vmw.702.0.20.18426014 Fehlerkorrektur Wichtig
ESXi-Komponente „Installieren/Aktualisieren“ esx-update_7.0.2-0.20.18426014 Fehlerkorrektur Kritisch
Netzwerktreiber für Intel(R) X710/XL710/XXV710/X722-Adapter Intel-i40en_1.8.1.137-1vmw.702.0.20.18426014 Fehlerkorrektur Kritisch
USB-Treiber VMware-vmkusb_0.1-4vmw.702.0.20.18426014 Fehlerkorrektur Kritisch
ESXi-Komponente - ESXi-Kern-VIBs ESXi_7.0.2-0.15.18295176 Sicherheit Kritisch
USB-Treiber VMware-vmkusb_0.1-1vmw.702.0.15.18295176 Sicherheit Mäßig
ESXi Tools-Komponente VMware-VM-Tools_11.2.6.17901274-18295176 Sicherheit Kritisch
ESXi-Komponente „Installieren/Aktualisieren“ esx-update_7.0.2-0.15.18295176 Sicherheit Kritisch

WICHTIG:

  • Um die ZIP-Datei des Offline-Depots des ESXi 7.0 Update 2c-Patch von VMware Customer Connect herunterzuladen, müssen Sie zu Produkte und Konten > Produkt-Patches navigieren. 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.
  • 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
ESXi-7.0U2c-18426014 Fehlerkorrektur Kritisch Fehlerbehebung und Sicherheit
ESXi-7.0U2sc-18295176 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.0U2c-18426014-standard
ESXi-7.0U2c-18426014-no-tools
ESXi-7.0U2sc-18295176-standard
ESXi-7.0U2sc-18295176-no-tools

ESXi-Image

Name und Version Datum der Veröffentlichung Kategorie Detail
ESXi70U2c-18426014 24.08.2021 Fehlerkorrektur Fehlerbehebungs- und Sicherheits-Image
ESXi70U2sc-18295176 24.08.2021 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.0.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.0.x-Hosts besteht in der Verwendung des vSphere Lifecycle Manager. Weitere Informationen finden Sie unter Info zu vSphere Lifecycle Manager und vSphere Lifecycle Manager-Baselines und -Images.
Sie können ESXi-Hosts auch ohne das Lifecycle Manager-Plug-In aktualisieren und stattdessen ein Image-Profil verwenden. Dazu müssen Sie die ZIP-Datei des Patch-Offline-Pakets von der Seite Produkt-Patches manuell herunterladen und den Befehl esxcli software profile update verwenden.
Weitere Informationen finden Sie unter Aktualisieren von Hosts mithilfe von ESXCLI-Befehlen und im Handbuch VMware ESXi-Upgrade.

Hinweise zu Produktunterstützung

  • Einstellung des Trusted Platform Module (TPM) 1.2 in einer zukünftigen Hauptversion von vSphere: VMware beabsichtigt, in einer zukünftigen Hauptversion von vSphere die Unterstützung von TPM 1.2 und zugehörigen Funktionen wie TPM 1.2 mit TXT einzustellen. Um die vSphere-Funktionen vollständig nutzen zu können, können Sie TPM 2.0 anstelle von TPM 1.2 verwenden. Die Unterstützung für TPM 1.2 wird in allen vSphere 7.0.x-Versionen, -Updates und -Patches fortgeführt. Allerdings wird während der Installation oder der Updates von 7.0.x-Versionen keine Warnung zur veralteten Version TPM 1.2 angezeigt.

  • SLP-Dienst (Service Location Protocol) ist standardmäßig deaktiviert: Ab ESX 7.0 Update 2c ist der SLP-Dienst standardmäßig deaktiviert, um potenzielle Sicherheitsschwachstellen zu vermeiden. Der SLP-Dienst wird auch nach Upgrades auf ESX 7.0 Update 2c automatisch deaktiviert. Sie können den SLP-Dienst manuell mit dem Befehl esxcli system slp set --enable true aktivieren. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 76372.

Behobene Probleme

Die behobenen Probleme werden in folgende Kategorien unterteilt.

ESXi_7.0.2-0.20.18426014
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_vsanhealth_7.0.2-0.20.18426014
  • VMware_bootbank_vsan_7.0.2-0.20.18426014
  • VMware_bootbank_gc_7.0.2-0.20.18426014
  • VMware_bootbank_esx-xserver_7.0.2-0.20.18426014
  • VMware_bootbank_clusterstore_7.0.2-0.20.18426014
  • VMware_bootbank_vdfs_7.0.2-0.20.18426014
  • VMware_bootbank_native-misc-drivers_7.0.2-0.20.18426014
  • VMware_bootbank_cpu-microcode_7.0.2-0.20.18426014
  • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.2-0.20.18426014
  • VMware_bootbank_esx-base_7.0.2-0.20.18426014
Behobene Probleme 2717698, 2731446, 2515171, 2731306, 2751564, 2718934, 2755056, 2725886, 2725886, 2753231, 2728910, 2741111, 2759343, 2721379, 2751277, 2708326, 2755977, 2737934, 2777001, 2760932, 2731263, 2731142, 2760267, 2749688, 2763986, 2765534, 2766127, 2777003, 2778793, 2755807, 2760081, 2731644, 2749815, 2749962, 2738238, 2799408
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 crx, vsanhealth, vsan, gc, esx-xserver, clusterstore, vdfs, native-misc-drivers, cpu-microcode, esx-dvfilter-generic-fastpath und esx-base zur Behebung der folgenden Probleme:

  • PR 2717698: Ein ESXi-Host schlägt möglicherweise aufgrund einer seltenen Race-Bedingung im qedentv-Treiber mit einem violetten Diagnosebildschirm fehl

    Eine seltene Race-Bedingung im qedentv-Treiber führt möglicherweise dazu, dass ein ESXi-Host mit einem violetten Diagnosebildschirm fehlschlägt. Dieses Problem tritt auf, wenn es kurz nach dem Löschen eines GSI-Warteschlangenpaars (General Services Interface) zu einem vollständigen RX-Interrupt kommt, beispielsweise beim Entladen eines qedentv-Treibers oder Herunterfahren eines Systems. In diesem Fall greift der qedentv-Treiber unter Umständen auf eine bereits freigegebene QP-Adresse zu, was zu einer PF-Ausnahme führt. Dieses Problem kann bei ESXi-Hosts auftreten, die mit einem ausgelasteten physischen Switch mit starkem, nicht angefordertem GSI-Datenverkehr verbunden sind. Im Backtrace werden Meldungen ähnlich der folgenden angezeigt:

    cpu4:2107287)0x45389609bcb0:[0x42001d3e6f72]qedrntv_ll2_rx_cb@(qedrntv)#<None>+0x1be stack: 0x45b8f00a7740, 0x1e146d040, 0x432d65738d40, 0x0, 0x
    2021-02-11T03:31:53.882Z cpu4:2107287)0x45389609bd50:[0x42001d421d2a]ecore_ll2_rxq_completion@(qedrntv)#<None>+0x2ab stack: 0x432bc20020ed, 0x4c1e74ef0, 0x432bc2002000,
    2021-02-11T03:31:53.967Z cpu4:2107287)0x45389609bdf0:[0x42001d1296d0]ecore_int_sp_dpc@(qedentv)#<None>+0x331 stack: 0x0, 0x42001c3bfb6b, 0x76f1e5c0, 0x2000097, 0x14c2002
    2021-02-11T03:31:54.039Z cpu4:2107287)0x45389609be60:[0x42001c0db867]IntrCookieBH@vmkernel#nover+0x17c stack: 0x45389609be80, 0x40992f09ba, 0x43007a436690, 0x43007a43669
    2021-02-11T03:31:54.116Z cpu4:2107287)0x45389609bef0:[0x42001c0be6b0]BH_Check@vmkernel#nover+0x121 stack: 0x98ba, 0x33e72f6f6e20, 0x0, 0x8000000000000000, 0x430000000001
    2021-02-11T03:31:54.187Z cpu4:2107287)0x45389609bf70:[0x42001c28370c]NetPollWorldCallback@vmkernel#nover+0x129 stack: 0x61, 0x42001d0e0000, 0x42001c283770, 0x0, 0x0
    2021-02-11T03:31:54.256Z cpu4:2107287)0x45389609bfe0:[0x42001c380bad]CpuSched_StartWorld@vmkernel#nover+0x86 stack: 0x0, 0x42001c0c2b44, 0x0, 0x0, 0x0
    2021-02-11T03:31:54.319Z cpu4:2107287)0x45389609c000:[0x42001c0c2b43]Debug_IsInitialized@vmkernel#nover+0xc stack: 0x0, 0x0, 0x0, 0x0, 0x0
    2021-02-11T03:31:54.424Z cpu4:2107287)^[[45m^[[33;1mVMware ESXi 7.0.2 [Releasebuild-17435195 x86_64]^[[0m
    #PF Exception 14 in world 2107287:vmnic7-pollW IP 0x42001d3e6f72 addr 0x1c

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2731446: Während die vSphere Replication-Appliance eingeschaltet wird, schlägt der hostd-Dienst möglicherweise fehl und führt dazu, dass ESXi-Hosts vorübergehend nicht mehr auf vCenter Server reagieren

    In seltenen Fällen kann es vorkommen, dass der hostd-Dienst beim Einschalten der vSphere Replication-Appliance fehlschlägt und ESXi-Hosts vorübergehend nicht mehr auf vCenter Server reagieren. Der hostd-Dienst wird automatisch neu gestartet und die Konnektivität wiederhergestellt.

    Dieses Problem wurde in der vorliegenden Version behoben.

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

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

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2731306: ESXi-Hosts reagieren nicht mehr auf vCenter Server, und es werden wiederholte Meldungen für Zugangsfehler angezeigt

    ESXi-Hosts reagieren möglicherweise nicht mehr auf vCenter Server, selbst wenn auf die Hosts zugegriffen werden kann und diese ausgeführt werden. Dieses Problem tritt bei Anbieter-Images mit angepassten Treibern auf, bei denen ImageConfigManager mehr RAM als zugeteilt verbraucht. Infolgedessen führen wiederholte Fehler von ImageConfigManager dazu, dass ESXi-Hosts von vCenter Server getrennt werden.
    In den vmkernel-Protokollen werden sich wiederholende Fehler ähnlich den folgenden angezeigt:
    Zugangsfehler in Pfad: host/vim/vmvisor/hostd-tmp/sh.<pid1>:python.<pid2>:uw.<pid2>.
    In den hostd-Protokollen werden Meldungen ähnlich der folgenden angezeigt: Aufgabe erstellt : haTask-ha-host-vim.host.ImageConfigManager.fetchSoftwarePackages-<sequence>, gefolgt von: ForkExec(/usr/bin/sh) <pid1>, wobei <pid1> einen ImageConfigManager-Prozess identifiziert.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2751564: Wenn Sie den Wert der erweiterten Konfigurationsoption DiskMaxIOSize verringern, schlagen E/A-Vorgänge von ESXi-Hosts möglicherweise fehl

    Wenn Sie die erweiterte Konfigurationsoption DiskMaxIOSize in einen niedrigeren Wert ändern, werden E/A-Vorgänge mit großen Blockgrößen möglicherweise falsch aufgeteilt und am PSA-Pfad in die Warteschlange gestellt. Dies führt dazu, dass bei E/A-Vorgängen von ESXi-Hosts eine Zeitüberschreitung auftritt und sie fehlschlagen.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2718934: Ein- oder Ausschaltvorgänge von virtuellen Maschinen dauern zu lange

    Unter bestimmten Bedingungen kann das Ein- oder Ausschalten von virtuellen Maschinen bis zu 20 Minuten dauern. Das Problem tritt auf, wenn der zugrunde liegende Speicher der VMs einen Hintergrundvorgang ausführt, wie z. B. HBA-Neuprüf- oder APD-Ereignisse, und einige Sperren kontinuierlich beibehalten werden.

    Dieses Problem wurde in der vorliegenden Version behoben. Der Fix entfernt unnötige Sperren für Speicherressourcen und führt einen schnellen Mutex ein, um die Leistung des VM-Betriebsvorgangs zu verbessern.

  • PR 2755056: ESXi-Hosts schlagen aufgrund eines Unterschieds der Antwortgröße der Seite für wichtige Produktdaten (VPD) mit einem violetten Diagnosebildschirm fehl

    In seltenen Fällen, wenn die Antwortgröße der VPD-Seite vom Ziel-ESXi-Host auf verschiedenen Pfaden zum Host unterschiedlich ist, schreibt ESXi möglicherweise mehr Byte als die zugewiesene Länge für einen bestimmten Pfad. Folglich schlägt der ESXi-Host mit einem violetten Diagnosebildschirm und einer Meldung ähnlich der folgenden fehl:
    Panic Message: @BlueScreen: PANIC bora/vmkernel/main/dlmalloc.c:4878 - Corruption in dlmalloc

    Dieses Problem wurde in der vorliegenden Version behoben. Der Fix verfolgt die Größe der VPD-Seiten mithilfe eines separaten Felds, anstatt vom VPD-Antwort-Header abhängig zu sein.

  • PR 2725886: Seltene Sperrkonflikte können dazu führen, dass einige VM-Vorgänge fehlschlagen

    Ein seltener Sperrkonflikt kann dazu führen, dass VM-Vorgänge wie Failover oder Migration fehlschlagen.
    Meldungen zu Sperrfehlern sehen wie folgt aus:
    vol 'VM_SYS_11', lock at 480321536: [Req mode 1] Checking liveness:
    type 10c00003 offset 480321536 v 1940464, hb offset 3801088
    oder
    Res3: 2496: Rank violation threshold reached: cid 0xc1d00002, resType 2, cnum 5 vol VM_SYS_11

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2766036: Im vSphere Client werden falsche Zahlen für den bereitgestellten Speicherplatz von virtuellen Maschinen angezeigt

    Wenn Sie in komplexen Workflows, die zum Erstellen mehrerer virtueller Maschinen führen, zu VMs > Virtuelle Maschinen navigieren, werden in der Spalte Bereitgestellter Speicherplatz für einige VMs möglicherweise große Zahlen angezeigt. Beispiel: 2,95 TB anstelle des tatsächlich bereitgestellten Speicherplatzes von 25 GB.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2753231: Ein ESXi-Host schlägt aufgrund eines Aufruflistenfehlers im ESXi-Speicher-Stack mit einem violetten Diagnosebildschirm fehl

    Bei der Verarbeitung des SCSI-Befehls READ CAPACITY (10) kopiert ESXi möglicherweise überschüssige Daten aus der Antwort und beschädigt die Aufrufliste. Infolgedessen schlägt ein ESXi-Host mit einem violetten Diagnosebildschirm fehl.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2728910: ESX-Hosts schlagen möglicherweise mit einem violetten Diagnosebildschirm fehl, wenn virtuelle Maschinen eingeschaltet werden

    In sehr seltenen Fällen werden VMFS-Ressourcencluster, die in einer Journaltransaktion enthalten sind, möglicherweise nicht gesperrt. Dies führt dazu, dass beim Einschalten von virtuellen Maschinen mehrere ESXi-Hosts aufgrund von Ausnahme 14 in der VMFS-Schicht mit einem violetten Diagnosebildschirm fehlschlagen. Eine typische Meldung und eine Stapelüberwachung, die im VMkernel-Protokoll angezeigt werden, sind wie folgt:
    @BlueScreen: #PF Exception 14 in world 2097684:VSCSI Emulat IP 0x418014d06fca addr 0x0
    PTEs:0x16a47a027;0x600faa8007;0x0;
    2020-06-24T17:35:57.073Z cpu29:2097684)Code start: 0x418013c00000 VMK uptime: 0:01:01:20.555
    2020-06-24T17:35:57.073Z cpu29:2097684)0x451a50a1baa0:[0x418014d06fca]Res6MemUnlockTxnRCList@esx#nover+0x176 stack: 0x1 2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb10:[0x418014c7cdb6]J3_DeleteTransaction@esx#nover+0x33f stack: 0xbad0003
    2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb40:[0x418014c7db10]J3_AbortTransaction@esx#nover+0x105 stack: 0x0 2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb80:[0x418014cbb752]Fil3_FinalizePunchFileHoleTxnVMFS6@esx#nover+0x16f stack: 0x430fe950e1f0
    2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bbd0:[0x418014c7252b]Fil3UpdateBlocks@esx#nover+0x348 stack: 0x451a50a1bc78 2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bce0:[0x418014c731dc]Fil3_PunchFileHoleWithRetry@esx#nover+0x89 stack: 0x451a50a1bec8
    2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bd90:[0x418014c739a5]Fil3_FileBlockUnmap@esx#nover+0x50e stack: 0x230eb5 2020-06-24T17:35:57.076Z cpu29:2097684)0x451a50a1be40:[0x418013c4c551]FSSVec_FileBlockUnmap@vmkernel#nover+0x6e stack: 0x230eb5
    2020-06-24T17:35:57.076Z cpu29:2097684)0x451a50a1be90:[0x418013fb87b1]VSCSI_ExecFSSUnmap@vmkernel#nover+0x8e stack: 0x0 2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bf00:[0x418013fb71cb]VSCSIDoEmulHelperIO@vmkernel#nover+0x2c stack: 0x430145fbe070
    2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bf30:[0x418013ceadfa]HelperQueueFunc@vmkernel#nover+0x157 stack: 0x430aa05c9618 2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bfe0:[0x418013f0eaa2]CpuSched_StartWorld@vmkernel#nover+0x77 stack: 0x0
    2020-06-24T17:35:57.083Z cpu29:2097684)base fs=0x0 gs=0x418047400000 Kgs=0x0

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2741111: Wenn einige Intel-CPUs keine Debug-Ausnahme-Traps (#DB) weiterleiten, kann dies zu einem dreifachen Fehler der virtuellen Maschine führen

    In seltenen Fällen können einige Intel-CPUs #DB-Traps möglicherweise nicht weiterleiten, und wenn ein Timer-Interrupt während des Windows-Systemaufrufs auftritt, kann die virtuelle Maschine einen dreifachen Fehler verursachen.

    Dieses Problem wurde in der vorliegenden Version behoben. Der Fix leitet alle #DB-Traps von CPUs an das Gastbetriebssystem weiter, außer wenn der DB-Trap von einem Debugger stammt, der an die virtuelle Maschine angehängt ist.

  • PR 2759343: Der sfcbd-Dienst wird nicht gestartet, wenn Sie ESXi Management Agents über die DCUI (Direct Console User Interface) neu starten

    Wenn Sie ESXi Management Agents über DCUI neu starten, wird der sfcbd-Dienst nicht gestartet. Sie müssen den SFCB-Dienst manuell starten.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2721379: Der hostd-Dienst protokolliert alle 2 Minuten eine Warnung für null Stromversorgungssensoren

    Der hostd-Dienst protokolliert alle 2 Minuten die Meldung BuildPowerSupplySensorList hat 0 Stromversorgungssensoren erkannt. Dieses Problem tritt auf, wenn Sie ein Upgrade auf oder eine Neuinstallation von ESXi 7.0 Update 1 auf einem ESXi-Host durchführen.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2751277: ESXi-Hosts schlagen möglicherweise aufgrund eines Nullzeigerverweisfehlers mit einem violetten Diagnosebildschirm fehl

    In seltenen Fällen gibt der Kernel-Arbeitsspeicher-Allokator möglicherweise einen NULL-Zeiger zurück, der möglicherweise nicht ordnungsgemäß dereferenziert wird. Dies führt möglicherweise dazu, dass der ESXi-Host mit einem violetten Diagnosebildschirm mit einem Fehler wie #GP Exception 13 in world 2422594:vmm:overCom @ 0x42003091ede4 fehlschlägt. Im Backtrace werden Fehler ähnlich den folgenden angezeigt:
    #1 Util_ZeroPageTable
    #2 Util_ZeroPageTableMPN
    #3 VmMemPfUnmapped
    #4 VmMemPfInt
    #5 VmMemPfGetMapping
    #6 VmMemPf
    #7 VmMemPfLockPageInt
    #8 VMMVMKCall_Call
    #9 VMKVMM_ArchEnterVMKernel

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2708326: Wenn ein NVMe-Gerät innerhalb kurzer Zeit im laufenden Betrieb hinzugefügt und entfernt wird, schlägt der ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm fehl

    Wenn ein NVMe-Gerät innerhalb kurzer Zeit im laufenden Betrieb hinzugefügt und entfernt wird, kann der NVMe-Treiber den NVMe-Controller aufgrund einer Befehlszeitüberschreitung unter Umständen nicht initialisieren. Folglich kann der Treiber auf den Arbeitsspeicher zugreifen, der in einem Bereinigungsvorgang bereits freigegeben wurde. Im Backtrace wird eine Meldung angezeigt, wie z. B. WARNUNG: NVMEDEV: NVMEInitializeController:4045: Abrufen der Controller-Identifizierungsdaten fehlgeschlagen, Status: Zeitüberschreitung.
    Schließlich schlägt der ESXi-Host mit einem violetten Diagnosebildschirm und einer Fehlermeldung ähnlich der folgenden fehl: #PF Exception ... in world ...:vmkdevmgr.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2755977: ESXi-Hosts können beim Einschalten der virtuellen Maschine möglicherweise keine Thick-VMDK bereitstellen oder keine Auslagerungsdatei erstellen

    Wenn ein ESXi-Host keine freien großen Dateiblöcke (LFBs) zum Zuweisen hat, führt der Host die Thick-VMDK-Bereitstellung oder die Erstellung einer Auslagerungsdatei mit kleinen Dateiblöcken (SFBs) durch. In seltenen Fällen kann der Host jedoch auch gar keine SFBs zuteilen. Dies führt möglicherweise dazu, dass die Thick-VMDK-Bereitstellung oder die Erstellung einer Auslagerungsdatei fehlschlägt. Wenn versucht wird, virtuelle Maschinen einzuschalten, wird ein Fehler in den VMkernel-Protokollen angezeigt, wie z. B.:
     vmkernel.1:2021-01-08T19:13:28.341Z cpu20:2965260)Fil3: 10269: Max no space retries (10) exceeded for caller Fil3_SetFileLength (status 'No space left on device')

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2737934: Wenn Sie sehr große VMFS6-Datenspeicher verwenden, werden möglicherweise wiederholte CPU-Sperrfehler angezeigt, oder ESXi-Hosts können zeitweise ausfallen

    Wenn Sie sehr große VMFS6-Datenspeicher verwenden, kann die Zuteilung von Dateiblöcken für Thin-VMDKs in einem Ressourcencluster zu einer CPU-Sperre führen. Infolgedessen werden Meldungen zur CPU-Sperre angezeigt, und in seltenen Fällen können ESXi-Hosts ausfallen. Im Backtrace werden Meldungen ähnlich der folgenden angezeigt:
    2021-04-07T02:18:08.730Z cpu31:2345212)WARNING: Heartbeat: 849: PCPU 10 didn't have a heartbeat for 7 seconds; *may* be locked up.
    Der zugehörige Backtrace, der Res6AffMgr -Funktionen betrifft, ähnelt der folgenden:
    2021-01-06T02:16:16.073Z cpu0:2265741)ALERT: NMI: 694: NMI IPI: RIPOFF(base):RBP:CS [0x121d74d(0x42001a000000):0x50d0:0xf48] (Src 0x1, CPU0)
    2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b320:[0x42001b21d74c]Res6AffMgrComputeSortIndices@esx#nover+0x369 stack: 0x43119125a000
    2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b3b0:[0x42001b224e46]Res6AffMgrGetCluster@esx#nover+0xb1f stack: 0xd 2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b4b0:[0x42001b226491]Res6AffMgr_AllocResourcesInt@esx#nover+0x40a stack: 0x4311910f4890
    2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b680:[0x42001b2270e2]Res6AffMgr_AllocResources@esx#nover+0x1b stack: 0x0

    Dieses Problem wurde in der vorliegenden Version behoben. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 83473.

  • PR 2777001: ESXi-Hosts mit einer großen Anzahl an physischen CPUs schlagen während oder nach einem Upgrade auf ESXi 7.0 Update 2 möglicherweise mit einem violetten Diagnosebildschirm fehl

    Während oder nach einem Upgrade auf ESXi 7.0 Update 2 weist die ESX-Speicherebene möglicherweise nicht genügend Arbeitsspeicherressourcen für ESXi-Hosts mit einer großen physischen CPU-Anzahl und vielen mit den Hosts verbundenen Speichergeräten oder Pfaden zu. Infolgedessen schlagen solche ESXi-Hosts möglicherweise mit einem violetten Diagnosebildschirm fehl.

    Dieses Problem wurde in der vorliegenden Version behoben. Der Fix korrigiert die Arbeitsspeicherzuteilung für die ESX-Speicherebene.

  • PR 2760932: Virtuelle Maschinen mit Hardwareversion 18 schlagen während vSphere vMotion-Vorgängen möglicherweise zeitweise fehl

    Virtuelle Maschinen mit Hardwareversion 18 und VMware Tools 11.2.0 oder höher schlagen möglicherweise aufgrund eines Problems mit einem virtuellen Grafikgerät auf der Zielseite während eines vSphere vMotion- oder Storage vMotion-Vorgangs fehl.
    Im vmkernel.log wird eine Meldung ähnlich der folgenden angezeigt:
    PF failed to handle a fault on mmInfo at va 0x114f5ae0: Out of memory. Terminating...

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2731263: Nach der Aktualisierung auf Hardwareversion 18 wird in virtuellen Maschinen eine Kernel-Panik des Gastbetriebssystems angezeigt

    Nach der Aktualisierung auf Hardwareversion 18 schlagen einige Gastbetriebssysteme, z. B. CentOS 7, auf AMD-CPUs möglicherweise mit einer Kernel-Panik fehl, wenn Sie die virtuelle Maschine starten. Die Kernel-Panik-Meldung wird angezeigt, wenn Sie eine Webkonsole für die virtuelle Maschine öffnen.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2731142: Pakete mit der Option IPv6 Tunnel Encapsulation Limit gehen im Datenverkehr zwischen virtuellen Maschinen verloren

    Einige Linux-Kernel fügen die Option IPv6 Tunnel Encapsulation Limit zu IPv6-Tunnelpaketen hinzu, wie in RFC 2473, Par. 5.1 beschrieben. Dies führt dazu, dass IPv6-Tunnelpakete im Datenverkehr zwischen virtuellen Maschinen aufgrund des IPv6-Erweiterungs-Headers verworfen werden.

    Dieses Problem wurde in der vorliegenden Version behoben. Der Fix analysiert Pakete mit der Option IPv6 Tunnel Encapsulation Limit korrekt.

  • PR 2760267: In vmkernel-Protokollen werden mehrere Warnungen angezeigt, die auf einen Wechsel zum bevorzugten Pfad XXX im STANDBY-Zustand für Gerät XXX hinweisen

    Wenn virtuelle Medien, wie z. B. ein CD-Laufwerk, über einen integrierten Dell Remote Access Controller (iDRAC) mit Ihrer vSphere-Umgebung verbunden sind und dem Laufwerk keine Mediendatei zugeordnet ist, werden im vmkernel-Protokoll möglicherweise mehrere Warnmeldungen ähnlich der folgenden angezeigt:
    vmw_psp_fixed: psp_fixedSelectPathToActivateInt:439: Switching to preferred path vmhba32:C0:T0:L1 in STANDBY state for device mpx.vmhba32:C0:T0:L1.WARNING: vmw_psp_fixed: psp_fixedSelectPathToActivateInt:464: Selected current STANDBY path vmhba32:C0:T0:L1 for device mpx.vmhba32:C0:T0:L1 to activate. This may lead to path thrashing.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2749688: vCenter Server entfernt möglicherweise zeitweise interne NSX-gesteuerte, verteilte virtuelle Ports von ESXi-Hosts

    Während der 24-Stunden-Synchronisierungsworkflows des vSphere Distributed Switch entfernt vCenter Server möglicherweise zeitweise NSX-gesteuerte, verteilte virtuelle Ports wie den SPF-Port (Service Plane Forwarding) von ESXi-Hosts. Dies kann dazu führen, dass vSphere vMotion-Vorgänge virtueller Maschinen fehlschlagen. Es wird eine Fehlermeldung, z. B. Could not connect SPF port : Not found in den Protokollen angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2763986: Wenn Sie die Scratch-Partition im Root-Verzeichnis eines VMFS-Volumes konfigurieren, schlägt das Upgrade auf ESXi 7.0.x fehl und Sie verlieren möglicherweise Daten auf dem VMFS-Volume

    In ESXi 7.0 wurde die VMFS-L-basierte ESX-OSData-Partition eingeführt, die die Rolle der veralteten Scratch-Partition, der Locker-Partition für VMware Tools und des Core-Dump-Ziels übernimmt. Wenn Sie die Scratch-Partition im Root-Verzeichnis eines VMFS-Volumes während eines Upgrades auf ESXi 7.0.x konfigurieren, versucht das System, die VMFS-Dateien in das VMFS-L-Format zu konvertieren, um die OS-Data-Partitionsanforderungen zu erfüllen. Dies kann dazu führen, dass die OS-Data-Partition das VMFS-Volume überschreibt und Datenverlust verursacht.

    Dieses Problem wurde in der vorliegenden Version behoben. Der Fix fügt eine Prüfung hinzu, ob das Dateisystem VFAT ist, bevor es in OS-DATA konvertiert wird. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 83647.

  • PR 2765534: Der Kommunikationskanal-Systemstatus von ESXi-Hosts in NSX Data Center for vSphere-Clustern ist nach dem Upgrade auf ESXi 7.0 Update 2a inaktiv

    Aufgrund eines Problems mit der Protokollverarbeitung werden nach einem Upgrade auf ESXi 7.0 Update 2a beim Überprüfen des Systemzustands des Kommunikationskanals alle ESXi-Hosts mit dem Status „Inaktiv“ angezeigt, da NSX Manager keine Verbindung zum Firewall-Agent herstellen kann.

    Dieses Problem wurde in der vorliegenden Version behoben. Wenn das Problem bereits aufgetreten ist, beenden Sie den vsfwd-Dienst und wiederholen Sie den Upgrade-Vorgang.

  • PR 2766127: Wenn Sie ein Upgrade von ESXi-Hosts mithilfe von vSphere Quick Boot in einer FCoE-Umgebung durchführen, schlägt der physische Server möglicherweise mit einem violetten Diagnosebildschirm fehl

    Wenn ein ESXi-Host der Version 7.0 Update 2 auf einer FCoE-LUN installiert ist und den UEFI-Startmodus verwendet, schlägt der physische Server möglicherweise aufgrund eines Arbeitsspeicherfehlers mit einem violetten Diagnosebildschirm fehl, wenn Sie versuchen, den Host mithilfe von vSphere QuickBoot zu aktualisieren.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2777003: Wenn Sie ein USB-Gerät als Startgerät für ESXi 7.0 Update 2a verwenden, reagieren ESXi-Hosts möglicherweise nicht mehr, und es werden Warnungen angezeigt, dass der Host nicht reagiert und die Boot-Bank nicht gefunden wurde

    USB-Geräte haben eine geringe Warteschlangentiefe und aufgrund einer Race-Bedingung im ESXi-Speicher-Stack werden einige E/A-Vorgänge möglicherweise nicht auf das Gerät übertragen. Solche E/A-Vorgänge sitzen in der Warteschlange im ESXi-Speicher-Stack und verursachen schließlich eine Zeitüberschreitung. Folglich reagieren ESXi-Hosts nicht mehr.
    Im vSphere Client werden Warnungen wie Warnung: /bootbank nicht gefunden unter Pfad '/bootbank' und Host reagiert nicht angezeigt.
    In vmkernel-Protokollen werden Fehler ähnlich den folgenden angezeigt:
    2021-04-12T04:47:44.940Z cpu0:2097441)ScsiPath: 8058: Cancelled Cmd(0x45b92ea3fd40) 0xa0, cmdId.initiator=0x4538c859b8f8 CmdSN 0x0 from world 0 to path "vmhba32:C0:T0:L0". Cmd count Active:0 Queued:1.
    2021-04-12T04:48:50.527Z cpu2:2097440)ScsiDeviceIO: 4315: Cmd(0x45b92ea76d40) 0x28, cmdId.initiator=0x4305f74cc780 CmdSN 0x1279 from world 2099370 to dev "mpx.vmhba32:C0:T0:L0" failed H:0x5 D:0x0 P:0x0 Cancelled from path layer. Cmd count Active:1
    2021-04-12T04:48:50.527Z cpu2:2097440)Queued:4

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2778793: Die Startzeit von ESXi-Hosts wird nach dem Upgrade auf ESXi Update 2a länger

    Nach einem Upgrade auf ESXi Update 2a kann es zu längeren Startzeiten von ESXi-Hosts von bis zu 60 Minuten kommen.
    Das Problem betrifft keine Updates für ESXi Update 2a aus früheren Versionen von ESXi 7.0.x.
    Das Problem tritt nur auf, wenn Sie ein vSphere Lifecycle Manager-Image oder eine Baseline oder den Befehl esxcli software profile update verwenden, um den Upgrade-Vorgang durchzuführen. Wenn Sie ein ISO-Image oder eine Skriptinstallation verwenden, tritt das Problem nicht auf.
    Das Problem wirkt sich wahrscheinlich auf iSCSI-Konfigurationen aus, hängt aber mit dem ESXi-Algorithmus für die Bootbank-Erkennung zusammen und nicht mit der Verlangsamung externer Speicherziele.

    Dieses Problem wurde in der vorliegenden Version behoben. Der Fix erhöht die Toleranzgrenzen, wenn eine boot.cfg-Datei oder ein Speicher nicht sofort bereitgestellt wird.

  • PR 2755807: vSphere vMotion-Vorgänge auf einem ESXi-Host schlagen mit dem Fehler „Nicht genügend Arbeitsspeicher“ fehl

    Aufgrund eines Arbeitsspeicherverlusts im Portset-Heap schlagen vSphere vMotion-Vorgänge auf einem ESXi-Host möglicherweise mit dem Fehler „Nicht genügend Arbeitsspeicher“ fehl. Im vSphere Client wird ein Fehler ähnlich dem folgenden angezeigt:
    Fehler beim Reservieren des Ports: DVSwitch 50 18 34 d1 76 81 ec 9e-03 62 e2 d4 6f 23 30 ba port 1 39.
    Fehlerstatus: Nicht genügend Arbeitsspeicher.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2760081: Systemzustandswarnung des vSAN-Build-Empfehlungsmoduls nach dem Upgrade auf vSAN 7.0 Update 2

    Wenn vCenter Server vcsa.vmware.com nicht in eine IP-Adresse auflösen kann, kann der vSAN-Versionskatalog nicht hochgeladen werden. Bei der folgenden vSAN-Integritätsprüfung wird eine Warnung angezeigt: vSAN-Build-Empfehlungsmodul-Integrität.
    Es wird möglicherweise eine Fehlermeldung ähnlich der folgenden angezeigt:
    2021-04-12T11:40:59.435Z ERROR vsan-mgmt[32221] [VsanHttpRequestWrapper::urlopen opID=noOpId] Exception while sending request : Cannot resolve localhost or Internet websites.
    2021-04-12T11:40:59.435Z WARNING vsan-mgmt[32221] [VsanVumCoreUtil::CheckVumServiceStatus opID=noOpId] Failed to connect VUM service: Cannot resolve localhost or Internet websites.
    2021-04-12T11:40:59.435Z INFO vsan-mgmt[32221] [VsanVumIntegration::VumStatusCallback opID=noOpId] VUM is not installed or not responsive ​
    2021-04-12T11:40:59.435Z INFO vsan-mgmt[32221] [VsanVumSystemUtil::HasConfigIssue opID=noOpId] Config issue health.test.vum.vumDisabled exists on entity None

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2731644: Es wird eine höhere Bereinigungsaktivität als gewöhnlich auf vSAN beobachtet

    Ein Ganzzahlüberlauffehler kann dazu führen, dass vSAN DOM häufiger Bereinigungen als konfiguriert ausgibt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2749815: ESXi-Hosts schlagen mit einem violetten Diagnosebildschirm fehl, wenn eine Neusynchronisierung mit aktiven Gastschreibvorgängen abgebrochen wird

    Wenn eine Neusynchronisierung parallel zu Gastschreibvorgängen auf Objekten ausgeführt wird, die einem ESXi-Host gehören, schlägt der Host möglicherweise mit einem violetten Diagnosebildschirm fehl.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2749962: Es wird ein Syslog-Fehler „Fehler beim Schreiben der Kopfzeile beim Rotieren“ angezeigt

    Wenn die Datei cmmdstimemachineDump.log einen maximalen Grenzwert von 10 MB erreicht, erfolgt eine Rotation und eine neue Datei cmmdstimemachineDump wird erstellt. Während der Rotation wird jedoch in den vmsyslogd.err-Protokollen möglicherweise ein Fehler wie der folgende angezeigt:
    2021-04-08T03:15:53.719Z vmsyslog.loggers.file : ERROR ] Failed to write header on rotate. Ausnahme: [Errno 2] No such file or directory: '/var/run/cmmdstimemachineDumpHeader.txt'

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2738238: Die Reaktion auf die Aufgabe „Objektformatänderung“ dauert lange

    In einigen Fällen liefert der CMMDS (Cluster Monitoring, Membership, and Directory Service) keine korrekte Eingabe für die Aufgabe „Objektformatänderung“, und die Aufgabe benötigt viel Zeit, um zu reagieren.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2799408: Das Upgrade eines Stretched Clusters auf Version ESXi 7.0 Update 2 oder höher kann möglicherweise dazu führen, dass mehrere ESX-Hosts mit einem violetten Diagnosebildschirm fehlschlagen

    In seltenen Szenarien können mehrere ESX-Hosts auf einem Stretched Cluster mit einem violetten Diagnosebildschirm fehlschlagen, wenn der Zeugenhost während des Upgrade-Vorgangs ersetzt wird und kurz nach der Ersetzung eine Aufgabe zur Konvertierung des Festplattenformats ausgeführt wird.

    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.

esx-update_7.0.2-0.20.18426014
Patch-Kategorie Fehlerkorrektur
Patch-Schweregrad Kritisch
Hostneustart erforderlich Ja
Migration oder Herunterfahren der virtuellen Maschine erforderlich Ja
Betroffene Hardware Nicht verfügbar
Betroffene Software Nicht verfügbar
Enthaltene VIBs
  • VMware_bootbank_loadesx_7.0.2-0.20.18426014
  • VMware_bootbank_esx-update_7.0.2-0.20.18426014
Behobene Probleme 2722263, 2812906
CVE-Nummern Nicht verfügbar

Aktualisiert die VIBs loadesx und esx-update zur Behebung des folgenden Problems:

  • PR 2722263: Sie können Komponenten in einem benutzerdefinierten ESXi-Image nach dem Upgrade auf ESXi 7.0 Update 2a nicht entfernen

    Wenn Sie ein benutzerdefiniertes 7.0 Update 2a-Image mithilfe des ESXi-Paketkits erstellen, einige der Komponenten im Basisimage, z. B. Intel-ixgben:1.8.9.0-1OEM.700.1.0.15525992, überschreiben und dann ein Upgrade Ihrer ESXi 7.0.x-Hosts durchführen, können Sie die benutzerdefinierte Komponente nach dem Upgrade nicht entfernen. Außerdem fehlen möglicherweise einige VIBs aus den benutzerdefinierten Komponenten.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • PR 2812906: Metadaten von VMFS-Datenspeichern werden in bestimmten ESXi-Bereitstellungsszenarien aufgrund der Duplizierung von System-UUIDs (Universally Unique Identifiers) möglicherweise beschädigt

    Bestimmte Bereitstellungsszenarien wie das Klonen von ESXi-Bootbanks führen möglicherweise zu teilweise oder vollständig identischen UUIDs mehrerer ESXi-Hosts. Da UUIDs für VMFS-Heartbeat- und -Journal-Vorgänge verwendet werden, versuchen mehrere ESXi-Hosts bei Vorhandensein duplizierter UUIDs möglicherweise, nach dem Installations- oder Upgrade-Vorgang auf Metadatenregionen im selben VMFS-Datenspeicher zuzugreifen. Dies kann dazu führen, dass in einigen VMFS-Datenspeichern Metadaten beschädigt werden.
    In den vmkernel-Protokollen werden Meldungen ähnlich der folgenden angezeigt:
    vmkernel 608: VMFS volume DCS_HCFA_TEDS_Regulated_10032/5ba2905b-ac11166d-b145-0025b5920a02 on naa.60060e8012a34f005040a34f00000d64:1 has been detected corrupted.
    2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 319: FS3RCMeta 2245 200 21 105 0
    2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 326: 0 0 0 0 0 0 0 0 0 0 0 7 0 254 1 4 0 248 3 96 0 0 0 0 0
    2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 332: 0 0 0
    2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 338: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
    2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 346: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
    2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 346: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 

    Andere betroffene Bereitstellungsszenarien sind die Wiederverwendung von Hardwareprofilen, z. B. Blade-Systeme, die dieselbe MAC zum Bereitstellen einer neuen Instanz verwenden, und das Verschieben von Startfestplatten zwischen Servern.

    Problemumgehung: Keine. Weitere Informationen finden Sie in den VMware-Knowledgebase-Artikeln 84280 und 84349.

Broadcom-bnxt-Net-RoCE_216.0.0.0-1vmw.702.0.20.18426014
Patch-Kategorie Fehlerkorrektur
Patch-Schweregrad Wichtig
Hostneustart erforderlich Ja
Migration oder Herunterfahren der virtuellen Maschine erforderlich Ja
Betroffene Hardware Nicht verfügbar
Betroffene Software Nicht verfügbar
Enthaltene VIBs
  • VMW_bootbank_bnxtroce_216.0.58.0-20vmw.702.0.20.18426014
  • VMW_bootbank_bnxtnet_216.0.50.0-34vmw.702.0.20.18426014
Behobene Probleme Nicht verfügbar
CVE-Nummern Nicht verfügbar

Aktualisiert das VIB bnxtroce.

    MRVL-E4-CNA-Driver-Bundle_1.0.0.0-1vmw.702.0.20.18426014
    Patch-Kategorie Fehlerkorrektur
    Patch-Schweregrad Wichtig
    Hostneustart erforderlich Ja
    Migration oder Herunterfahren der virtuellen Maschine erforderlich Ja
    Betroffene Hardware Nicht verfügbar
    Betroffene Software Nicht verfügbar
    Enthaltene VIBs
    • VMW_bootbank_qedrntv_3.40.5.53-17vmw.702.0.20.18426014
    • VMW_bootbank_qedentv_3.40.5.53-20vmw.702.0.20.18426014
    Behobene Probleme Nicht verfügbar
    CVE-Nummern Nicht verfügbar

    Aktualisiert das VIB qedrntv.

      Intel-i40en_1.8.1.137-1vmw.702.0.20.18426014
      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_i40enu_1.8.1.137-1vmw.702.0.20.18426014
      Behobene Probleme

      2750390
      CVE-Nummern Nicht verfügbar

      Aktualisiert das VIB i40enu zur Behebung des folgenden Problems:

      • PR 2750390: Nach einem Upgrade auf ESXi 7.0 Update 2a werden VIBs der asynchronen i40en-Netzwerktreiber für ESXi übersprungen oder auf den VMware-Inbox-Treiber i40enu wiederhergestellt

        Mit vSphere 7.0 Update 2 wurde der i40en-Inbox-Treiber in i40enu umbenannt. Wenn Sie versuchen, einen asynchronen i40en-Partnertreiber zu installieren, wird das VIB i40en entweder übersprungen oder auf den i40enu-Inbox-Treiber von VMware wiederhergestellt.

        Dieses Problem wurde in der vorliegenden Version behoben.

      Broadcom-ELX-lpfc_12.8.298.3-2vmw.702.0.20.18426014
      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_12.8.298.3-2vmw.702.0.20.18426014
      Behobene Probleme 2715138
      CVE-Nummern Nicht verfügbar

      Aktualisiert das VIB lpfc zur Behebung des folgenden Problems:

      • PR 2715138: ESXi-Hosts schlagen während der Installation des Dell EMC PowerPath-Plug-Ins möglicherweise mit einem violetten Diagnosebildschirm fehl

        Ein seltener Seitenfehler kann dazu führen, dass ESXi-Hosts während der Installation des Dell EMC PowerPath-Plug-Ins mit einem violetten Diagnosebildschirm fehlschlagen.

        Dieses Problem wurde in der vorliegenden Version behoben.

      VMware-vmkusb_0.1-4vmw.702.0.20.18426014
      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-4vmw.702.0.20.18426014
      Behobene Probleme 2753546
      CVE-Nummern Nicht verfügbar

      Aktualisiert das VIB vmkusb zur Behebung der folgenden Probleme:

      • PR 2753546: Wenn Sie ein USB-Startgerät verwenden, kann die Verbindung zur /bootbank-Partition unterbrochen werden oder die VMFS-L LOCKER-Partition wird beschädigt

        Wenn der USB-Host-Controller von Ihrem vSphere-System getrennt wird und eine Ressource auf dem Gerät, z. B. Dump-Dateien, noch von ESXi verwendet wird, kann der Gerätepfad nicht freigegeben werden, wenn das Gerät erneut eine Verbindung herstellt. Dies führt dazu, dass ESXi einen neuen Pfad zum USB-Gerät bereitstellt, der die Verbindung zur /bootbank-Partition unterbricht oder die VMFS-L LOCKER-Partition beschädigt.

        Dieses Problem wurde in der vorliegenden Version behoben. Der Fix verbessert den USB-Host-Controller-Treiber, um Zeitüberschreitungsfehler bei Befehlen zu tolerieren, damit ESXi ausreichend Zeit zum Freigeben von USB-Geräteressourcen hat.
        Es wird empfohlen, keine Dump-Partition auf einem USB-Speichergerät einzurichten. Weitere Informationen finden Sie in den VMware-Knowledgebase-Artikeln 2077516 und 2149257.

      ESXi_7.0.2-0.15.18295176
      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_vdfs_7.0.2-0.15.18295176
      • VMware_bootbank_esx-xserver_7.0.2-0.15.18295176
      • VMware_bootbank_esx-base_7.0.2-0.15.18295176
      • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.2-0.15.18295176
      • VMware_bootbank_crx_7.0.2-0.15.18295176
      • VMware_bootbank_native-misc-drivers_7.0.2-0.15.18295176
      • VMware_bootbank_cpu-microcode_7.0.2-0.15.18295176
      • VMware_bootbank_gc_7.0.2-0.15.18295176
      • VMware_bootbank_vsanhealth_7.0.2-0.15.18295176
      • VMware_bootbank_clusterstore_7.0.2-0.15.18295176
      • VMware_bootbank_vsan_7.0.2-0.15.18295176
      Behobene Probleme 2738816, 2738857, 2735594
      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 vdfs, esx-xserver, esx-base, esx-dvfilter-generic-fastpath, crx, native-misc-drivers, cpu-microcode, gc, vsanhealth, clusterstore, vsan und esx-base zum Beheben der folgenden Probleme:

      • Update von OpenSSH

        OpenSSH wird auf Version 8.5p1 aktualisiert.

      • Update der OpenSSL-Bibliothek

        Die OpenSSL-Bibliothek wird auf Version openssl-1.0.2y aktualisiert.

      • Update der Libarchive-Bibliothek

        Die Libarchive-Bibliothek wird auf Version 3.5.1 aktualisiert.

      esx-update_7.0.2-0.15.18295176
      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_loadesx_7.0.2-0.15.18295176
      • VMware_bootbank_esx-update_7.0.2-0.15.18295176
      Behobene Probleme Nicht verfügbar
      CVE-Nummern Nicht verfügbar

      Aktualisiert die VIBs loadesx und esx-update.

        VMware-VM-Tools_11.2.6.17901274-18295176
        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_11.2.6.17901274-18295176
        Behobene Probleme 2761942
        CVE-Nummern Nicht verfügbar

        Aktualisiert das VIB tools-light zur Behebung des folgenden Problems:

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

        Aktualisiert das VIB vmkusb.

          ESXi-7.0U2c-18426014-standard
          Profilname ESXi-7.0U2c-18426014-standard
          Build Build-Informationen finden Sie unter In dieser Version enthaltene Patches.
          Anbieter VMware, Inc.
          Datum der Veröffentlichung 24. August 2021
          Akzeptanzebene PartnerSupported
          Betroffene Hardware Nicht verfügbar
          Betroffene Software Nicht verfügbar
          Betroffene VIBs
          • VMware_bootbank_vsanhealth_7.0.2-0.20.18426014
          • VMware_bootbank_vsan_7.0.2-0.20.18426014
          • VMware_bootbank_gc_7.0.2-0.20.18426014
          • VMware_bootbank_esx-xserver_7.0.2-0.20.18426014
          • VMware_bootbank_clusterstore_7.0.2-0.20.18426014
          • VMware_bootbank_vdfs_7.0.2-0.20.18426014
          • VMware_bootbank_native-misc-drivers_7.0.2-0.20.18426014
          • VMware_bootbank_cpu-microcode_7.0.2-0.20.18426014
          • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.2-0.20.18426014
          • VMware_bootbank_esx-base_7.0.2-0.20.18426014
          • VMware_bootbank_loadesx_7.0.2-0.20.18426014
          • VMware_bootbank_esx-update_7.0.2-0.20.18426014
          • VMW_bootbank_bnxtroce_216.0.58.0-20vmw.702.0.20.18426014
          • VMW_bootbank_bnxtnet_216.0.50.0-34vmw.702.0.20.18426014
          • VMW_bootbank_qedrntv_3.40.5.53-17vmw.702.0.20.18426014
          • VMW_bootbank_qedentv_3.40.5.53-20vmw.702.0.20.18426014
          • VMW_bootbank_i40enu_1.8.1.137-1vmw.702.0.20.18426014
          • VMW_bootbank_lpfc_12.8.298.3-2vmw.702.0.20.18426014
          • VMW_bootbank_vmkusb_0.1-4vmw.702.0.20.18426014
          Behobene Probleme 2717698, 2731446, 2515171, 731306, 2751564, 2718934, 2755056, 2725886, 2725886, 2753231, 2728910, 2741111, 2759343, 2721379, 2751277, 2708326, 2755977, 2737934, 2777001, 2760932, 2731263, 2731142, 2760267, 2749688, 2763986, 2765534, 2766127, 2777003, 2778793, 2755807, 2760081, 2731644, 2749815, 2749962, 2738238, 2799408, 2722263, 2812906, 2750390, 2715138, 2753546
          Verwandte CVE-Nummern Nicht verfügbar

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

            • Eine seltene Race-Bedingung im qedentv-Treiber führt möglicherweise dazu, dass ein ESXi-Host mit einem violetten Diagnosebildschirm fehlschlägt. Dieses Problem tritt auf, wenn es kurz nach dem Löschen eines GSI-Warteschlangenpaars (General Services Interface) zu einem vollständigen RX-Interrupt kommt, beispielsweise beim Entladen eines qedentv-Treibers oder Herunterfahren eines Systems. In diesem Fall greift der qedentv-Treiber unter Umständen auf eine bereits freigegebene QP-Adresse zu, was zu einer PF-Ausnahme führt. Dieses Problem kann bei ESXi-Hosts auftreten, die mit einem ausgelasteten physischen Switch mit starkem, nicht angefordertem GSI-Datenverkehr verbunden sind. Im Backtrace werden Meldungen ähnlich der folgenden angezeigt:

              cpu4:2107287)0x45389609bcb0:[0x42001d3e6f72]qedrntv_ll2_rx_cb@(qedrntv)#<None>+0x1be stack: 0x45b8f00a7740, 0x1e146d040, 0x432d65738d40, 0x0, 0x
              2021-02-11T03:31:53.882Z cpu4:2107287)0x45389609bd50:[0x42001d421d2a]ecore_ll2_rxq_completion@(qedrntv)#<None>+0x2ab stack: 0x432bc20020ed, 0x4c1e74ef0, 0x432bc2002000,
              2021-02-11T03:31:53.967Z cpu4:2107287)0x45389609bdf0:[0x42001d1296d0]ecore_int_sp_dpc@(qedentv)#<None>+0x331 stack: 0x0, 0x42001c3bfb6b, 0x76f1e5c0, 0x2000097, 0x14c2002
              2021-02-11T03:31:54.039Z cpu4:2107287)0x45389609be60:[0x42001c0db867]IntrCookieBH@vmkernel#nover+0x17c stack: 0x45389609be80, 0x40992f09ba, 0x43007a436690, 0x43007a43669
              2021-02-11T03:31:54.116Z cpu4:2107287)0x45389609bef0:[0x42001c0be6b0]BH_Check@vmkernel#nover+0x121 stack: 0x98ba, 0x33e72f6f6e20, 0x0, 0x8000000000000000, 0x430000000001
              2021-02-11T03:31:54.187Z cpu4:2107287)0x45389609bf70:[0x42001c28370c]NetPollWorldCallback@vmkernel#nover+0x129 stack: 0x61, 0x42001d0e0000, 0x42001c283770, 0x0, 0x0
              2021-02-11T03:31:54.256Z cpu4:2107287)0x45389609bfe0:[0x42001c380bad]CpuSched_StartWorld@vmkernel#nover+0x86 stack: 0x0, 0x42001c0c2b44, 0x0, 0x0, 0x0
              2021-02-11T03:31:54.319Z cpu4:2107287)0x45389609c000:[0x42001c0c2b43]Debug_IsInitialized@vmkernel#nover+0xc stack: 0x0, 0x0, 0x0, 0x0, 0x0
              2021-02-11T03:31:54.424Z cpu4:2107287)^[[45m^[[33;1mVMware ESXi 7.0.2 [Releasebuild-17435195 x86_64]^[[0m
              #PF Exception 14 in world 2107287:vmnic7-pollW IP 0x42001d3e6f72 addr 0x1c

            • In seltenen Fällen kann es vorkommen, dass der hostd-Dienst beim Einschalten der vSphere Replication-Appliance fehlschlägt und ESXi-Hosts vorübergehend nicht mehr auf vCenter Server reagieren. Der hostd-Dienst wird automatisch neu gestartet und die Konnektivität wiederhergestellt.

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

            • ESXi-Hosts reagieren möglicherweise nicht mehr auf vCenter Server, selbst wenn auf die Hosts zugegriffen werden kann und diese ausgeführt werden. Dieses Problem tritt bei Anbieter-Images mit angepassten Treibern auf, bei denen ImageConfigManager mehr RAM als zugeteilt verbraucht. Infolgedessen führen wiederholte Fehler von ImageConfigManager dazu, dass ESXi-Hosts von vCenter Server getrennt werden.
              In den vmkernel-Protokollen werden sich wiederholende Fehler ähnlich den folgenden angezeigt:
              Zugangsfehler in Pfad: host/vim/vmvisor/hostd-tmp/sh.<pid1>:python.<pid2>:uw.<pid2>.
              In den hostd-Protokollen werden Meldungen ähnlich der folgenden angezeigt: Aufgabe erstellt : haTask-ha-host-vim.host.ImageConfigManager.fetchSoftwarePackages-<sequence>, gefolgt von: ForkExec(/usr/bin/sh) <pid1>, wobei <pid1> einen Prozess von ImageConfigManager identifiziert.

            • Wenn Sie die erweiterte Konfigurationsoption DiskMaxIOSize in einen niedrigeren Wert ändern, werden E/A-Vorgänge mit großen Blockgrößen möglicherweise falsch aufgeteilt und am PSA-Pfad in die Warteschlange gestellt. Dies führt dazu, dass bei E/A-Vorgängen von ESXi-Hosts eine Zeitüberschreitung auftritt und sie fehlschlagen.

            • Unter bestimmten Bedingungen kann das Ein- oder Ausschalten von virtuellen Maschinen bis zu 20 Minuten dauern. Das Problem tritt auf, wenn der zugrunde liegende Speicher der VMs einen Hintergrundvorgang ausführt, wie z. B. HBA-Neuprüf- oder APD-Ereignisse, und einige Sperren kontinuierlich beibehalten werden.

            • In seltenen Fällen, wenn die Antwortgröße der VPD-Seite vom Ziel-ESXi-Host auf verschiedenen Pfaden zum Host unterschiedlich ist, schreibt ESXi möglicherweise mehr Byte als die zugewiesene Länge für einen bestimmten Pfad. Folglich schlägt der ESXi-Host mit einem violetten Diagnosebildschirm und einer Meldung ähnlich der folgenden fehl:
              Panic Message: @BlueScreen: PANIC bora/vmkernel/main/dlmalloc.c:4878 - Corruption in dlmalloc

            • Ein seltener Sperrkonflikt kann dazu führen, dass VM-Vorgänge wie Failover oder Migration fehlschlagen.
              Meldungen zu Sperrfehlern sehen wie folgt aus:
              vol 'VM_SYS_11', lock at 480321536: [Req mode 1] Checking liveness:
              type 10c00003 offset 480321536 v 1940464, hb offset 3801088
              oder
              Res3: 2496: Rank violation threshold reached: cid 0xc1d00002, resType 2, cnum 5 vol VM_SYS_11

            • Wenn Sie in komplexen Workflows, die zum Erstellen mehrerer virtueller Maschinen führen, zu VMs > Virtuelle Maschinen navigieren, werden in der Spalte Bereitgestellter Speicherplatz für einige VMs möglicherweise große Zahlen angezeigt. Beispiel: 2,95 TB anstelle des tatsächlich bereitgestellten Speicherplatzes von 25 GB.

            • Bei der Verarbeitung des SCSI-Befehls READ CAPACITY (10) kopiert ESXi möglicherweise überschüssige Daten aus der Antwort und beschädigt die Aufrufliste. Infolgedessen schlägt ein ESXi-Host mit einem violetten Diagnosebildschirm fehl.

            • In sehr seltenen Fällen werden VMFS-Ressourcencluster, die in einer Journaltransaktion enthalten sind, möglicherweise nicht gesperrt. Dies führt dazu, dass beim Einschalten von virtuellen Maschinen mehrere ESXi-Hosts aufgrund von Ausnahme 14 in der VMFS-Schicht mit einem violetten Diagnosebildschirm fehlschlagen. Eine typische Meldung und eine Stapelüberwachung, die im VMkernel-Protokoll angezeigt werden, sind wie folgt:
              @BlueScreen: #PF Exception 14 in world 2097684:VSCSI Emulat IP 0x418014d06fca addr 0x0
              PTEs:0x16a47a027;0x600faa8007;0x0;
              2020-06-24T17:35:57.073Z cpu29:2097684)Code start: 0x418013c00000 VMK uptime: 0:01:01:20.555
              2020-06-24T17:35:57.073Z cpu29:2097684)0x451a50a1baa0:[0x418014d06fca]Res6MemUnlockTxnRCList@esx#nover+0x176 stack: 0x1 2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb10:[0x418014c7cdb6]J3_DeleteTransaction@esx#nover+0x33f stack: 0xbad0003
              2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb40:[0x418014c7db10]J3_AbortTransaction@esx#nover+0x105 stack: 0x0 2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb80:[0x418014cbb752]Fil3_FinalizePunchFileHoleTxnVMFS6@esx#nover+0x16f stack: 0x430fe950e1f0
              2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bbd0:[0x418014c7252b]Fil3UpdateBlocks@esx#nover+0x348 stack: 0x451a50a1bc78 2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bce0:[0x418014c731dc]Fil3_PunchFileHoleWithRetry@esx#nover+0x89 stack: 0x451a50a1bec8
              2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bd90:[0x418014c739a5]Fil3_FileBlockUnmap@esx#nover+0x50e stack: 0x230eb5 2020-06-24T17:35:57.076Z cpu29:2097684)0x451a50a1be40:[0x418013c4c551]FSSVec_FileBlockUnmap@vmkernel#nover+0x6e stack: 0x230eb5
              2020-06-24T17:35:57.076Z cpu29:2097684)0x451a50a1be90:[0x418013fb87b1]VSCSI_ExecFSSUnmap@vmkernel#nover+0x8e stack: 0x0 2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bf00:[0x418013fb71cb]VSCSIDoEmulHelperIO@vmkernel#nover+0x2c stack: 0x430145fbe070
              2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bf30:[0x418013ceadfa]HelperQueueFunc@vmkernel#nover+0x157 stack: 0x430aa05c9618 2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bfe0:[0x418013f0eaa2]CpuSched_StartWorld@vmkernel#nover+0x77 stack: 0x0
              2020-06-24T17:35:57.083Z cpu29:2097684)base fs=0x0 gs=0x418047400000 Kgs=0x0

            • In seltenen Fällen können einige Intel-CPUs #DB-Traps möglicherweise nicht weiterleiten, und wenn ein Timer-Interrupt während des Windows-Systemaufrufs auftritt, kann die virtuelle Maschine einen dreifachen Fehler verursachen.

            • Wenn Sie ESXi Management Agents über DCUI neu starten, wird der sfcbd-Dienst nicht gestartet. Sie müssen den SFCB-Dienst manuell starten.

            • Der hostd-Dienst protokolliert alle 2 Minuten die Meldung BuildPowerSupplySensorList hat 0 Stromversorgungssensoren erkannt. Dieses Problem tritt auf, wenn Sie ein Upgrade auf oder eine Neuinstallation von ESXi 7.0 Update 1 auf einem ESXi-Host durchführen.

            • In seltenen Fällen gibt der Kernel-Arbeitsspeicher-Allokator möglicherweise einen NULL-Zeiger zurück, der möglicherweise nicht ordnungsgemäß dereferenziert wird. Dies führt möglicherweise dazu, dass der ESXi-Host mit einem violetten Diagnosebildschirm mit einem Fehler wie #GP Exception 13 in world 2422594:vmm:overCom @ 0x42003091ede4 fehlschlägt. Im Backtrace werden Fehler ähnlich den folgenden angezeigt:
              #1 Util_ZeroPageTable
              #2 Util_ZeroPageTableMPN
              #3 VmMemPfUnmapped
              #4 VmMemPfInt
              #5 VmMemPfGetMapping
              #6 VmMemPf
              #7 VmMemPfLockPageInt
              #8 VMMVMKCall_Call
              #9 VMKVMM_ArchEnterVMKernel

            • Wenn ein NVMe-Gerät innerhalb kurzer Zeit im laufenden Betrieb hinzugefügt und entfernt wird, kann der NVMe-Treiber den NVMe-Controller aufgrund einer Befehlszeitüberschreitung unter Umständen nicht initialisieren. Folglich kann der Treiber auf den Arbeitsspeicher zugreifen, der in einem Bereinigungsvorgang bereits freigegeben wurde. Im Backtrace wird eine Meldung angezeigt, wie z. B. WARNUNG: NVMEDEV: NVMEInitializeController:4045: Abrufen der Controller-Identifizierungsdaten fehlgeschlagen, Status: Zeitüberschreitung.
              Schließlich schlägt der ESXi-Host mit einem violetten Diagnosebildschirm und einer Fehlermeldung ähnlich der folgenden fehl: #PF Exception ... in world ...:vmkdevmgr.

            • Wenn ein ESXi-Host keine freien großen Dateiblöcke (LFBs) zum Zuweisen hat, führt der Host die Thick-VMDK-Bereitstellung oder die Erstellung einer Auslagerungsdatei mit kleinen Dateiblöcken (SFBs) durch. In seltenen Fällen kann der Host jedoch auch gar keine SFBs zuteilen. Dies führt möglicherweise dazu, dass die Thick-VMDK-Bereitstellung oder die Erstellung einer Auslagerungsdatei fehlschlägt. Wenn versucht wird, virtuelle Maschinen einzuschalten, wird ein Fehler in den VMkernel-Protokollen angezeigt, wie z. B.:
               vmkernel.1:2021-01-08T19:13:28.341Z cpu20:2965260)Fil3: 10269: Max no space retries (10) exceeded for caller Fil3_SetFileLength (status 'No space left on device')

            • Wenn Sie sehr große VMFS6-Datenspeicher verwenden, kann die Zuteilung von Dateiblöcken für Thin-VMDKs in einem Ressourcencluster zu einer CPU-Sperre führen. Infolgedessen werden Meldungen zur CPU-Sperre angezeigt, und in seltenen Fällen können ESXi-Hosts ausfallen. Im Backtrace werden Meldungen ähnlich der folgenden angezeigt:
              2021-04-07T02:18:08.730Z cpu31:2345212)WARNING: Heartbeat: 849: PCPU 10 didn't have a heartbeat for 7 seconds; *may* be locked up.
              Der zugehörige Backtrace, der Res6AffMgr -Funktionen betrifft, ähnelt der folgenden:
              2021-01-06T02:16:16.073Z cpu0:2265741)ALERT: NMI: 694: NMI IPI: RIPOFF(base):RBP:CS [0x121d74d(0x42001a000000):0x50d0:0xf48] (Src 0x1, CPU0)
              2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b320:[0x42001b21d74c]Res6AffMgrComputeSortIndices@esx#nover+0x369 stack: 0x43119125a000
              2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b3b0:[0x42001b224e46]Res6AffMgrGetCluster@esx#nover+0xb1f stack: 0xd 2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b4b0:[0x42001b226491]Res6AffMgr_AllocResourcesInt@esx#nover+0x40a stack: 0x4311910f4890
              2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b680:[0x42001b2270e2]Res6AffMgr_AllocResources@esx#nover+0x1b stack: 0x0

            • Während oder nach einem Upgrade auf ESXi 7.0 Update 2 weist die ESX-Speicherebene möglicherweise nicht genügend Arbeitsspeicherressourcen für ESXi-Hosts mit einer großen physischen CPU-Anzahl und vielen mit den Hosts verbundenen Speichergeräten oder Pfaden zu. Infolgedessen schlagen solche ESXi-Hosts möglicherweise mit einem violetten Diagnosebildschirm fehl.

            • Virtuelle Maschinen mit Hardwareversion 18 und VMware Tools 11.2.0 oder höher schlagen möglicherweise aufgrund eines Problems mit einem virtuellen Grafikgerät auf der Zielseite während eines vSphere vMotion- oder Storage vMotion-Vorgangs fehl.
              Im vmkernel.log wird eine Meldung ähnlich der folgenden angezeigt:
              PF failed to handle a fault on mmInfo at va 0x114f5ae0: Out of memory. Terminating...

            • Nach der Aktualisierung auf Hardwareversion 18 schlagen einige Gastbetriebssysteme, z. B. CentOS 7, auf AMD-CPUs möglicherweise mit einer Kernel-Panik fehl, wenn Sie die virtuelle Maschine starten. Die Kernel-Panik-Meldung wird angezeigt, wenn Sie eine Webkonsole für die virtuelle Maschine öffnen.

            • Einige Linux-Kernel fügen die Option IPv6 Tunnel Encapsulation Limit zu IPv6-Tunnelpaketen hinzu, wie in RFC 2473, Par. 5.1 beschrieben. Dies führt dazu, dass IPv6-Tunnelpakete im Datenverkehr zwischen virtuellen Maschinen aufgrund des IPv6-Erweiterungs-Headers verworfen werden.

            • Wenn virtuelle Medien, wie z. B. ein CD-Laufwerk, über einen integrierten Dell Remote Access Controller (iDRAC) mit Ihrer vSphere-Umgebung verbunden sind und dem Laufwerk keine Mediendatei zugeordnet ist, werden im vmkernel-Protokoll möglicherweise mehrere Warnmeldungen ähnlich der folgenden angezeigt:
              vmw_psp_fixed: psp_fixedSelectPathToActivateInt:439: Switching to preferred path vmhba32:C0:T0:L1 in STANDBY state for device mpx.vmhba32:C0:T0:L1.WARNING: vmw_psp_fixed: psp_fixedSelectPathToActivateInt:464: Selected current STANDBY path vmhba32:C0:T0:L1 for device mpx.vmhba32:C0:T0:L1 to activate. This may lead to path thrashing.

            • Während der 24-Stunden-Synchronisierungsworkflows des vSphere Distributed Switch entfernt vCenter Server möglicherweise zeitweise NSX-gesteuerte, verteilte virtuelle Ports wie den SPF-Port (Service Plane Forwarding) von ESXi-Hosts. Dies kann dazu führen, dass vSphere vMotion-Vorgänge virtueller Maschinen fehlschlagen. Es wird eine Fehlermeldung, z. B. Could not connect SPF port : Not found in den Protokollen angezeigt.

            • In ESXi 7.0 wurde die VMFS-L-basierte ESX-OSData-Partition eingeführt, die die Rolle der veralteten Scratch-Partition, der Locker-Partition für VMware Tools und des Core-Dump-Ziels übernimmt. Wenn Sie die Scratch-Partition im Root-Verzeichnis eines VMFS-Volumes während eines Upgrades auf ESXi 7.0.x konfigurieren, versucht das System, die VMFS-Dateien in das VMFS-L-Format zu konvertieren, um die OS-Data-Partitionsanforderungen zu erfüllen. Dies kann dazu führen, dass die OS-Data-Partition das VMFS-Volume überschreibt und Datenverlust verursacht.

            • Aufgrund eines Problems mit der Protokollverarbeitung werden nach einem Upgrade auf ESXi 7.0 Update 2a beim Überprüfen des Systemzustands des Kommunikationskanals alle ESXi-Hosts mit dem Status „Inaktiv“ angezeigt, da NSX Manager keine Verbindung zum Firewall-Agent herstellen kann.

            • Wenn ein ESXi-Host der Version 7.0 Update 2 auf einer FCoE-LUN installiert ist und den UEFI-Startmodus verwendet, schlägt der physische Server möglicherweise aufgrund eines Arbeitsspeicherfehlers mit einem violetten Diagnosebildschirm fehl, wenn Sie versuchen, den Host mithilfe von vSphere QuickBoot zu aktualisieren.

            • USB-Geräte haben eine geringe Warteschlangentiefe und aufgrund einer Race-Bedingung im ESXi-Speicher-Stack werden einige E/A-Vorgänge möglicherweise nicht auf das Gerät übertragen. Solche E/A-Vorgänge sitzen in der Warteschlange im ESXi-Speicher-Stack und verursachen schließlich eine Zeitüberschreitung. Folglich reagieren ESXi-Hosts nicht mehr.
              Im vSphere Client werden Warnungen wie Warnung: /bootbank nicht gefunden unter Pfad '/bootbank' und Host reagiert nicht angezeigt.
              In vmkernel-Protokollen werden Fehler ähnlich den folgenden angezeigt:
              2021-04-12T04:47:44.940Z cpu0:2097441)ScsiPath: 8058: Cancelled Cmd(0x45b92ea3fd40) 0xa0, cmdId.initiator=0x4538c859b8f8 CmdSN 0x0 from world 0 to path "vmhba32:C0:T0:L0". Cmd count Active:0 Queued:1.
              2021-04-12T04:48:50.527Z cpu2:2097440)ScsiDeviceIO: 4315: Cmd(0x45b92ea76d40) 0x28, cmdId.initiator=0x4305f74cc780 CmdSN 0x1279 from world 2099370 to dev "mpx.vmhba32:C0:T0:L0" failed H:0x5 D:0x0 P:0x0 Cancelled from path layer. Cmd count Active:1
              2021-04-12T04:48:50.527Z cpu2:2097440)Queued:4

            • Nach einem Upgrade auf ESXi Update 2a kann es zu längeren Startzeiten von ESXi-Hosts von bis zu 60 Minuten kommen.
              Das Problem betrifft keine Updates für ESXi Update 2a aus früheren Versionen von ESXi 7.0.x.
              Das Problem tritt nur auf, wenn Sie ein vSphere Lifecycle Manager-Image oder eine Baseline oder den Befehl esxcli software profile update verwenden, um den Upgrade-Vorgang durchzuführen. Wenn Sie ein ISO-Image oder eine Skriptinstallation verwenden, tritt das Problem nicht auf.
              Das Problem wirkt sich wahrscheinlich auf iSCSI-Konfigurationen aus, hängt aber mit dem ESXi-Algorithmus für die Bootbank-Erkennung zusammen und nicht mit der Verlangsamung externer Speicherziele.

            • Aufgrund eines Arbeitsspeicherverlusts im Portset-Heap schlagen vSphere vMotion-Vorgänge auf einem ESXi-Host möglicherweise mit dem Fehler „Nicht genügend Arbeitsspeicher“ fehl. Im vSphere Client wird ein Fehler ähnlich dem folgenden angezeigt:
              Fehler beim Reservieren des Ports: DVSwitch 50 18 34 d1 76 81 ec 9e-03 62 e2 d4 6f 23 30 ba port 1 39.
              Fehlerstatus: Nicht genügend Arbeitsspeicher.

            • Wenn vCenter Server vcsa.vmware.com nicht in eine IP-Adresse auflösen kann, kann der vSAN-Versionskatalog nicht hochgeladen werden. Bei der folgenden vSAN-Integritätsprüfung wird eine Warnung angezeigt: vSAN-Build-Empfehlungsmodul-Integrität.
              Es wird möglicherweise eine Fehlermeldung ähnlich der folgenden angezeigt:
              2021-04-12T11:40:59.435Z ERROR vsan-mgmt[32221] [VsanHttpRequestWrapper::urlopen opID=noOpId] Exception while sending request : Cannot resolve localhost or Internet websites.
              2021-04-12T11:40:59.435Z WARNING vsan-mgmt[32221] [VsanVumCoreUtil::CheckVumServiceStatus opID=noOpId] Failed to connect VUM service: Cannot resolve localhost or Internet websites.
              2021-04-12T11:40:59.435Z INFO vsan-mgmt[32221] [VsanVumIntegration::VumStatusCallback opID=noOpId] VUM is not installed or not responsive ​
              2021-04-12T11:40:59.435Z INFO vsan-mgmt[32221] [VsanVumSystemUtil::HasConfigIssue opID=noOpId] Config issue health.test.vum.vumDisabled exists on entity None

            • Ein Ganzzahlüberlauffehler kann dazu führen, dass vSAN DOM häufiger Bereinigungen als konfiguriert ausgibt.

            • Wenn eine Neusynchronisierung parallel zu Gastschreibvorgängen auf Objekten ausgeführt wird, die einem ESXi-Host gehören, schlägt der Host möglicherweise mit einem violetten Diagnosebildschirm fehl.

            • Wenn die Datei cmmdstimemachineDump.log einen maximalen Grenzwert von 10 MB erreicht, erfolgt eine Rotation und eine neue Datei cmmdstimemachineDump wird erstellt. Während der Rotation wird jedoch in den vmsyslogd.err-Protokollen möglicherweise ein Fehler wie der folgende angezeigt:
              2021-04-08T03:15:53.719Z vmsyslog.loggers.file : ERROR ] Failed to write header on rotate. Ausnahme: [Errno 2] No such file or directory: '/var/run/cmmdstimemachineDumpHeader.txt'

            • In einigen Fällen liefert der CMMDS (Cluster Monitoring, Membership, and Directory Service) keine korrekte Eingabe für die Aufgabe „Objektformatänderung“, und die Aufgabe benötigt viel Zeit, um zu reagieren.

            • In seltenen Szenarien können mehrere ESX-Hosts auf einem Stretched Cluster mit einem violetten Diagnosebildschirm fehlschlagen, wenn der Zeugenhost während des Upgrade-Vorgangs ersetzt wird und kurz nach der Ersetzung eine Aufgabe zur Konvertierung des Festplattenformats ausgeführt wird.

            • Wenn Sie ein benutzerdefiniertes 7.0 Update 2a-Image mithilfe des ESXi-Paketkits erstellen, einige der Komponenten im Basisimage, z. B. Intel-ixgben:1.8.9.0-1OEM.700.1.0.15525992, überschreiben und dann ein Upgrade Ihrer ESXi 7.0.x-Hosts durchführen, können Sie die benutzerdefinierte Komponente nach dem Upgrade nicht entfernen. Außerdem fehlen möglicherweise einige VIBs aus den benutzerdefinierten Komponenten.

            • Wenn Sie ein ESXi-Startgerät klonen, erstellen Sie Instanzen mit identischen UUIDs. Da UUIDs für VMFS-Heartbeat- und Journal-Vorgänge verwendet werden, versuchen mehrere ESXi-Hosts bei duplizierten UUIDs nach dem Installations- oder Upgrade-Vorgang auf Metadatenregionen im selben VMFS-Datenspeicher zuzugreifen. Dies kann dazu führen, dass in VMFS-Datenspeichern auf mehreren ESXi-Hosts eine massive Metadatenbeschädigung auftritt.
              In den vmkernel-Protokollen werden Meldungen ähnlich der folgenden angezeigt:
              vmkernel 608: VMFS volume DCS_HCFA_TEDS_Regulated_10032/5ba2905b-ac11166d-b145-0025b5920a02 on naa.60060e8012a34f005040a34f00000d64:1 has been detected corrupted.
              2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 319: FS3RCMeta 2245 200 21 105 0
              2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 326: 0 0 0 0 0 0 0 0 0 0 0 7 0 254 1 4 0 248 3 96 0 0 0 0 0
              2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 332: 0 0 0
              2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 338: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
              2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 346: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
              2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 346: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 

            • Mit vSphere 7.0 Update 2 wurde der i40en-Inbox-Treiber in i40enu umbenannt. Wenn Sie versuchen, einen asynchronen i40en-Partnertreiber zu installieren, wird das VIB i40en entweder übersprungen oder auf den i40enu-Inbox-Treiber von VMware wiederhergestellt.

            • Ein seltener Seitenfehler kann dazu führen, dass ESXi-Hosts während der Installation des Dell EMC PowerPath-Plug-Ins mit einem violetten Diagnosebildschirm fehlschlagen.

            • Wenn der USB-Host-Controller von Ihrem vSphere-System getrennt wird und eine Ressource auf dem Gerät, z. B. Dump-Dateien, noch von ESXi verwendet wird, kann der Gerätepfad nicht freigegeben werden, wenn das Gerät erneut eine Verbindung herstellt. Dies führt dazu, dass ESXi einen neuen Pfad zum USB-Gerät bereitstellt, der die Verbindung zur /bootbank-Partition unterbricht oder die VMFS-L LOCKER-Partition beschädigt.

          ESXi-7.0U2c-18426014-no-tools
          Profilname ESXi-7.0U2c-18426014-no-tools
          Build Build-Informationen finden Sie unter In dieser Version enthaltene Patches.
          Anbieter VMware, Inc.
          Datum der Veröffentlichung 24. August 2021
          Akzeptanzebene PartnerSupported
          Betroffene Hardware Nicht verfügbar
          Betroffene Software Nicht verfügbar
          Betroffene VIBs
          • VMware_bootbank_vsanhealth_7.0.2-0.20.18426014
          • VMware_bootbank_vsan_7.0.2-0.20.18426014
          • VMware_bootbank_gc_7.0.2-0.20.18426014
          • VMware_bootbank_esx-xserver_7.0.2-0.20.18426014
          • VMware_bootbank_clusterstore_7.0.2-0.20.18426014
          • VMware_bootbank_vdfs_7.0.2-0.20.18426014
          • VMware_bootbank_native-misc-drivers_7.0.2-0.20.18426014
          • VMware_bootbank_cpu-microcode_7.0.2-0.20.18426014
          • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.2-0.20.18426014
          • VMware_bootbank_esx-base_7.0.2-0.20.18426014
          • VMware_bootbank_loadesx_7.0.2-0.20.18426014
          • VMware_bootbank_esx-update_7.0.2-0.20.18426014
          • VMW_bootbank_bnxtroce_216.0.58.0-20vmw.702.0.20.18426014
          • VMW_bootbank_bnxtnet_216.0.50.0-34vmw.702.0.20.18426014
          • VMW_bootbank_qedrntv_3.40.5.53-17vmw.702.0.20.18426014
          • VMW_bootbank_qedentv_3.40.5.53-20vmw.702.0.20.18426014
          • VMW_bootbank_i40enu_1.8.1.137-1vmw.702.0.20.18426014
          • VMW_bootbank_lpfc_12.8.298.3-2vmw.702.0.20.18426014
          • VMW_bootbank_vmkusb_0.1-4vmw.702.0.20.18426014
          Behobene Probleme 2717698, 2731446, 2515171, 731306, 2751564, 2718934, 2755056, 2725886, 2725886, 2753231, 2728910, 2741111, 2759343, 2721379, 2751277, 2708326, 2755977, 2737934, 2777001, 2760932, 2731263, 2731142, 2760267, 2749688, 2763986, 2765534, 2766127, 2777003, 2778793, 2755807, 2760081, 2731644, 2749815, 2749962, 2738238, 2799408, 2722263, 2812906, 2750390, 2715138, 2753546
          Verwandte CVE-Nummern Nicht verfügbar

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

            • Eine seltene Race-Bedingung im qedentv-Treiber führt möglicherweise dazu, dass ein ESXi-Host mit einem violetten Diagnosebildschirm fehlschlägt. Dieses Problem tritt auf, wenn es kurz nach dem Löschen eines GSI-Warteschlangenpaars (General Services Interface) zu einem vollständigen RX-Interrupt kommt, beispielsweise beim Entladen eines qedentv-Treibers oder Herunterfahren eines Systems. In diesem Fall greift der qedentv-Treiber unter Umständen auf eine bereits freigegebene QP-Adresse zu, was zu einer PF-Ausnahme führt. Dieses Problem kann bei ESXi-Hosts auftreten, die mit einem ausgelasteten physischen Switch mit starkem, nicht angefordertem GSI-Datenverkehr verbunden sind. Im Backtrace werden Meldungen ähnlich der folgenden angezeigt:

              cpu4:2107287)0x45389609bcb0:[0x42001d3e6f72]qedrntv_ll2_rx_cb@(qedrntv)#<None>+0x1be stack: 0x45b8f00a7740, 0x1e146d040, 0x432d65738d40, 0x0, 0x
              2021-02-11T03:31:53.882Z cpu4:2107287)0x45389609bd50:[0x42001d421d2a]ecore_ll2_rxq_completion@(qedrntv)#<None>+0x2ab stack: 0x432bc20020ed, 0x4c1e74ef0, 0x432bc2002000,
              2021-02-11T03:31:53.967Z cpu4:2107287)0x45389609bdf0:[0x42001d1296d0]ecore_int_sp_dpc@(qedentv)#<None>+0x331 stack: 0x0, 0x42001c3bfb6b, 0x76f1e5c0, 0x2000097, 0x14c2002
              2021-02-11T03:31:54.039Z cpu4:2107287)0x45389609be60:[0x42001c0db867]IntrCookieBH@vmkernel#nover+0x17c stack: 0x45389609be80, 0x40992f09ba, 0x43007a436690, 0x43007a43669
              2021-02-11T03:31:54.116Z cpu4:2107287)0x45389609bef0:[0x42001c0be6b0]BH_Check@vmkernel#nover+0x121 stack: 0x98ba, 0x33e72f6f6e20, 0x0, 0x8000000000000000, 0x430000000001
              2021-02-11T03:31:54.187Z cpu4:2107287)0x45389609bf70:[0x42001c28370c]NetPollWorldCallback@vmkernel#nover+0x129 stack: 0x61, 0x42001d0e0000, 0x42001c283770, 0x0, 0x0
              2021-02-11T03:31:54.256Z cpu4:2107287)0x45389609bfe0:[0x42001c380bad]CpuSched_StartWorld@vmkernel#nover+0x86 stack: 0x0, 0x42001c0c2b44, 0x0, 0x0, 0x0
              2021-02-11T03:31:54.319Z cpu4:2107287)0x45389609c000:[0x42001c0c2b43]Debug_IsInitialized@vmkernel#nover+0xc stack: 0x0, 0x0, 0x0, 0x0, 0x0
              2021-02-11T03:31:54.424Z cpu4:2107287)^[[45m^[[33;1mVMware ESXi 7.0.2 [Releasebuild-17435195 x86_64]^[[0m
              #PF Exception 14 in world 2107287:vmnic7-pollW IP 0x42001d3e6f72 addr 0x1c

            • In seltenen Fällen kann es vorkommen, dass der hostd-Dienst beim Einschalten der vSphere Replication-Appliance fehlschlägt und ESXi-Hosts vorübergehend nicht mehr auf vCenter Server reagieren. Der hostd-Dienst wird automatisch neu gestartet und die Konnektivität wiederhergestellt.

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

            • ESXi-Hosts reagieren möglicherweise nicht mehr auf vCenter Server, selbst wenn auf die Hosts zugegriffen werden kann und diese ausgeführt werden. Dieses Problem tritt bei Anbieter-Images mit angepassten Treibern auf, bei denen ImageConfigManager mehr RAM als zugeteilt verbraucht. Infolgedessen führen wiederholte Fehler von ImageConfigManager dazu, dass ESXi-Hosts von vCenter Server getrennt werden.
              In den vmkernel-Protokollen werden sich wiederholende Fehler ähnlich den folgenden angezeigt:
              Zugangsfehler in Pfad: host/vim/vmvisor/hostd-tmp/sh.<pid1>:python.<pid2>:uw.<pid2>.
              In den hostd-Protokollen werden Meldungen ähnlich der folgenden angezeigt: Aufgabe erstellt : haTask-ha-host-vim.host.ImageConfigManager.fetchSoftwarePackages-<sequence>, gefolgt von: ForkExec(/usr/bin/sh) <pid1>, wobei <pid1> einen Prozess von ImageConfigManager identifiziert.

            • Wenn Sie die erweiterte Konfigurationsoption DiskMaxIOSize in einen niedrigeren Wert ändern, werden E/A-Vorgänge mit großen Blockgrößen möglicherweise falsch aufgeteilt und am PSA-Pfad in die Warteschlange gestellt. Dies führt dazu, dass bei E/A-Vorgängen von ESXi-Hosts eine Zeitüberschreitung auftritt und sie fehlschlagen.

            • Unter bestimmten Bedingungen kann das Ein- oder Ausschalten von virtuellen Maschinen bis zu 20 Minuten dauern. Das Problem tritt auf, wenn der zugrunde liegende Speicher der VMs einen Hintergrundvorgang ausführt, wie z. B. HBA-Neuprüf- oder APD-Ereignisse, und einige Sperren kontinuierlich beibehalten werden.

            • In seltenen Fällen, wenn die Antwortgröße der VPD-Seite vom Ziel-ESXi-Host auf verschiedenen Pfaden zum Host unterschiedlich ist, schreibt ESXi möglicherweise mehr Byte als die zugewiesene Länge für einen bestimmten Pfad. Folglich schlägt der ESXi-Host mit einem violetten Diagnosebildschirm und einer Meldung ähnlich der folgenden fehl:
              Panic Message: @BlueScreen: PANIC bora/vmkernel/main/dlmalloc.c:4878 - Corruption in dlmalloc

            • Ein seltener Sperrkonflikt kann dazu führen, dass VM-Vorgänge wie Failover oder Migration fehlschlagen.
              Meldungen zu Sperrfehlern sehen wie folgt aus:
              vol 'VM_SYS_11', lock at 480321536: [Req mode 1] Checking liveness:
              type 10c00003 offset 480321536 v 1940464, hb offset 3801088
              oder
              Res3: 2496: Rank violation threshold reached: cid 0xc1d00002, resType 2, cnum 5 vol VM_SYS_11

            • Wenn Sie in komplexen Workflows, die zum Erstellen mehrerer virtueller Maschinen führen, zu VMs > Virtuelle Maschinen navigieren, werden in der Spalte Bereitgestellter Speicherplatz für einige VMs möglicherweise große Zahlen angezeigt. Beispiel: 2,95 TB anstelle des tatsächlich bereitgestellten Speicherplatzes von 25 GB.

            • Bei der Verarbeitung des SCSI-Befehls READ CAPACITY (10) kopiert ESXi möglicherweise überschüssige Daten aus der Antwort und beschädigt die Aufrufliste. Infolgedessen schlägt ein ESXi-Host mit einem violetten Diagnosebildschirm fehl.

            • In sehr seltenen Fällen werden VMFS-Ressourcencluster, die in einer Journaltransaktion enthalten sind, möglicherweise nicht gesperrt. Dies führt dazu, dass beim Einschalten von virtuellen Maschinen mehrere ESXi-Hosts aufgrund von Ausnahme 14 in der VMFS-Schicht mit einem violetten Diagnosebildschirm fehlschlagen. Eine typische Meldung und eine Stapelüberwachung, die im VMkernel-Protokoll angezeigt werden, sind wie folgt:
              @BlueScreen: #PF Exception 14 in world 2097684:VSCSI Emulat IP 0x418014d06fca addr 0x0
              PTEs:0x16a47a027;0x600faa8007;0x0;
              2020-06-24T17:35:57.073Z cpu29:2097684)Code start: 0x418013c00000 VMK uptime: 0:01:01:20.555
              2020-06-24T17:35:57.073Z cpu29:2097684)0x451a50a1baa0:[0x418014d06fca]Res6MemUnlockTxnRCList@esx#nover+0x176 stack: 0x1 2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb10:[0x418014c7cdb6]J3_DeleteTransaction@esx#nover+0x33f stack: 0xbad0003
              2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb40:[0x418014c7db10]J3_AbortTransaction@esx#nover+0x105 stack: 0x0 2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb80:[0x418014cbb752]Fil3_FinalizePunchFileHoleTxnVMFS6@esx#nover+0x16f stack: 0x430fe950e1f0
              2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bbd0:[0x418014c7252b]Fil3UpdateBlocks@esx#nover+0x348 stack: 0x451a50a1bc78 2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bce0:[0x418014c731dc]Fil3_PunchFileHoleWithRetry@esx#nover+0x89 stack: 0x451a50a1bec8
              2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bd90:[0x418014c739a5]Fil3_FileBlockUnmap@esx#nover+0x50e stack: 0x230eb5 2020-06-24T17:35:57.076Z cpu29:2097684)0x451a50a1be40:[0x418013c4c551]FSSVec_FileBlockUnmap@vmkernel#nover+0x6e stack: 0x230eb5
              2020-06-24T17:35:57.076Z cpu29:2097684)0x451a50a1be90:[0x418013fb87b1]VSCSI_ExecFSSUnmap@vmkernel#nover+0x8e stack: 0x0 2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bf00:[0x418013fb71cb]VSCSIDoEmulHelperIO@vmkernel#nover+0x2c stack: 0x430145fbe070
              2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bf30:[0x418013ceadfa]HelperQueueFunc@vmkernel#nover+0x157 stack: 0x430aa05c9618 2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bfe0:[0x418013f0eaa2]CpuSched_StartWorld@vmkernel#nover+0x77 stack: 0x0
              2020-06-24T17:35:57.083Z cpu29:2097684)base fs=0x0 gs=0x418047400000 Kgs=0x0

            • In seltenen Fällen können einige Intel-CPUs #DB-Traps möglicherweise nicht weiterleiten, und wenn ein Timer-Interrupt während des Windows-Systemaufrufs auftritt, kann die virtuelle Maschine einen dreifachen Fehler verursachen.

            • Wenn Sie ESXi Management Agents über DCUI neu starten, wird der sfcbd-Dienst nicht gestartet. Sie müssen den SFCB-Dienst manuell starten.

            • Der hostd-Dienst protokolliert alle 2 Minuten die Meldung BuildPowerSupplySensorList hat 0 Stromversorgungssensoren erkannt. Dieses Problem tritt auf, wenn Sie ein Upgrade auf oder eine Neuinstallation von ESXi 7.0 Update 1 auf einem ESXi-Host durchführen.

            • In seltenen Fällen gibt der Kernel-Arbeitsspeicher-Allokator möglicherweise einen NULL-Zeiger zurück, der möglicherweise nicht ordnungsgemäß dereferenziert wird. Dies führt möglicherweise dazu, dass der ESXi-Host mit einem violetten Diagnosebildschirm mit einem Fehler wie #GP Exception 13 in world 2422594:vmm:overCom @ 0x42003091ede4 fehlschlägt. Im Backtrace werden Fehler ähnlich den folgenden angezeigt:
              #1 Util_ZeroPageTable
              #2 Util_ZeroPageTableMPN
              #3 VmMemPfUnmapped
              #4 VmMemPfInt
              #5 VmMemPfGetMapping
              #6 VmMemPf
              #7 VmMemPfLockPageInt
              #8 VMMVMKCall_Call
              #9 VMKVMM_ArchEnterVMKernel

            • Wenn ein NVMe-Gerät innerhalb kurzer Zeit im laufenden Betrieb hinzugefügt und entfernt wird, kann der NVMe-Treiber den NVMe-Controller aufgrund einer Befehlszeitüberschreitung unter Umständen nicht initialisieren. Folglich kann der Treiber auf den Arbeitsspeicher zugreifen, der in einem Bereinigungsvorgang bereits freigegeben wurde. Im Backtrace wird eine Meldung angezeigt, wie z. B. WARNUNG: NVMEDEV: NVMEInitializeController:4045: Abrufen der Controller-Identifizierungsdaten fehlgeschlagen, Status: Zeitüberschreitung.
              Schließlich schlägt der ESXi-Host mit einem violetten Diagnosebildschirm und einer Fehlermeldung ähnlich der folgenden fehl: #PF Exception ... in world ...:vmkdevmgr.

            • Wenn ein ESXi-Host keine freien großen Dateiblöcke (LFBs) zum Zuweisen hat, führt der Host die Thick-VMDK-Bereitstellung oder die Erstellung einer Auslagerungsdatei mit kleinen Dateiblöcken (SFBs) durch. In seltenen Fällen kann der Host jedoch auch gar keine SFBs zuteilen. Dies führt möglicherweise dazu, dass die Thick-VMDK-Bereitstellung oder die Erstellung einer Auslagerungsdatei fehlschlägt. Wenn versucht wird, virtuelle Maschinen einzuschalten, wird ein Fehler in den VMkernel-Protokollen angezeigt, wie z. B.:
               vmkernel.1:2021-01-08T19:13:28.341Z cpu20:2965260)Fil3: 10269: Max no space retries (10) exceeded for caller Fil3_SetFileLength (status 'No space left on device')

            • Wenn Sie sehr große VMFS6-Datenspeicher verwenden, kann die Zuteilung von Dateiblöcken für Thin-VMDKs in einem Ressourcencluster zu einer CPU-Sperre führen. Infolgedessen werden Meldungen zur CPU-Sperre angezeigt, und in seltenen Fällen können ESXi-Hosts ausfallen. Im Backtrace werden Meldungen ähnlich der folgenden angezeigt:
              2021-04-07T02:18:08.730Z cpu31:2345212)WARNING: Heartbeat: 849: PCPU 10 didn't have a heartbeat for 7 seconds; *may* be locked up.
              Der zugehörige Backtrace, der Res6AffMgr -Funktionen betrifft, ähnelt der folgenden:
              2021-01-06T02:16:16.073Z cpu0:2265741)ALERT: NMI: 694: NMI IPI: RIPOFF(base):RBP:CS [0x121d74d(0x42001a000000):0x50d0:0xf48] (Src 0x1, CPU0)
              2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b320:[0x42001b21d74c]Res6AffMgrComputeSortIndices@esx#nover+0x369 stack: 0x43119125a000
              2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b3b0:[0x42001b224e46]Res6AffMgrGetCluster@esx#nover+0xb1f stack: 0xd 2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b4b0:[0x42001b226491]Res6AffMgr_AllocResourcesInt@esx#nover+0x40a stack: 0x4311910f4890
              2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b680:[0x42001b2270e2]Res6AffMgr_AllocResources@esx#nover+0x1b stack: 0x0

            • Während oder nach einem Upgrade auf ESXi 7.0 Update 2 weist die ESX-Speicherebene möglicherweise nicht genügend Arbeitsspeicherressourcen für ESXi-Hosts mit einer großen physischen CPU-Anzahl und vielen mit den Hosts verbundenen Speichergeräten oder Pfaden zu. Infolgedessen schlagen solche ESXi-Hosts möglicherweise mit einem violetten Diagnosebildschirm fehl.

            • Virtuelle Maschinen mit Hardwareversion 18 und VMware Tools 11.2.0 oder höher schlagen möglicherweise aufgrund eines Problems mit einem virtuellen Grafikgerät auf der Zielseite während eines vSphere vMotion- oder Storage vMotion-Vorgangs fehl.
              Im vmkernel.log wird eine Meldung ähnlich der folgenden angezeigt:
              PF failed to handle a fault on mmInfo at va 0x114f5ae0: Out of memory. Terminating...

            • Nach der Aktualisierung auf Hardwareversion 18 schlagen einige Gastbetriebssysteme, z. B. CentOS 7, auf AMD-CPUs möglicherweise mit einer Kernel-Panik fehl, wenn Sie die virtuelle Maschine starten. Die Kernel-Panik-Meldung wird angezeigt, wenn Sie eine Webkonsole für die virtuelle Maschine öffnen.

            • Einige Linux-Kernel fügen die Option IPv6 Tunnel Encapsulation Limit zu IPv6-Tunnelpaketen hinzu, wie in RFC 2473, Par. 5.1 beschrieben. Dies führt dazu, dass IPv6-Tunnelpakete im Datenverkehr zwischen virtuellen Maschinen aufgrund des IPv6-Erweiterungs-Headers verworfen werden.

            • Wenn virtuelle Medien, wie z. B. ein CD-Laufwerk, über einen integrierten Dell Remote Access Controller (iDRAC) mit Ihrer vSphere-Umgebung verbunden sind und dem Laufwerk keine Mediendatei zugeordnet ist, werden im vmkernel-Protokoll möglicherweise mehrere Warnmeldungen ähnlich der folgenden angezeigt:
              vmw_psp_fixed: psp_fixedSelectPathToActivateInt:439: Switching to preferred path vmhba32:C0:T0:L1 in STANDBY state for device mpx.vmhba32:C0:T0:L1.WARNING: vmw_psp_fixed: psp_fixedSelectPathToActivateInt:464: Selected current STANDBY path vmhba32:C0:T0:L1 for device mpx.vmhba32:C0:T0:L1 to activate. This may lead to path thrashing.

            • Während der 24-Stunden-Synchronisierungsworkflows des vSphere Distributed Switch entfernt vCenter Server möglicherweise zeitweise NSX-gesteuerte, verteilte virtuelle Ports wie den SPF-Port (Service Plane Forwarding) von ESXi-Hosts. Dies kann dazu führen, dass vSphere vMotion-Vorgänge virtueller Maschinen fehlschlagen. Es wird eine Fehlermeldung, z. B. Could not connect SPF port : Not found in den Protokollen angezeigt.

            • In ESXi 7.0 wurde die VMFS-L-basierte ESX-OSData-Partition eingeführt, die die Rolle der veralteten Scratch-Partition, der Locker-Partition für VMware Tools und des Core-Dump-Ziels übernimmt. Wenn Sie die Scratch-Partition im Root-Verzeichnis eines VMFS-Volumes während eines Upgrades auf ESXi 7.0.x konfigurieren, versucht das System, die VMFS-Dateien in das VMFS-L-Format zu konvertieren, um die OS-Data-Partitionsanforderungen zu erfüllen. Dies kann dazu führen, dass die OS-Data-Partition das VMFS-Volume überschreibt und Datenverlust verursacht.

            • Aufgrund eines Problems mit der Protokollverarbeitung werden nach einem Upgrade auf ESXi 7.0 Update 2a beim Überprüfen des Systemzustands des Kommunikationskanals alle ESXi-Hosts mit dem Status „Inaktiv“ angezeigt, da NSX Manager keine Verbindung zum Firewall-Agent herstellen kann.

            • Wenn ein ESXi-Host der Version 7.0 Update 2 auf einer FCoE-LUN installiert ist und den UEFI-Startmodus verwendet, schlägt der physische Server möglicherweise aufgrund eines Arbeitsspeicherfehlers mit einem violetten Diagnosebildschirm fehl, wenn Sie versuchen, den Host mithilfe von vSphere QuickBoot zu aktualisieren.

            • USB-Geräte haben eine geringe Warteschlangentiefe und aufgrund einer Race-Bedingung im ESXi-Speicher-Stack werden einige E/A-Vorgänge möglicherweise nicht auf das Gerät übertragen. Solche E/A-Vorgänge sitzen in der Warteschlange im ESXi-Speicher-Stack und verursachen schließlich eine Zeitüberschreitung. Folglich reagieren ESXi-Hosts nicht mehr.
              Im vSphere Client werden Warnungen wie Warnung: /bootbank nicht gefunden unter Pfad '/bootbank' und Host reagiert nicht angezeigt.
              In vmkernel-Protokollen werden Fehler ähnlich den folgenden angezeigt:
              2021-04-12T04:47:44.940Z cpu0:2097441)ScsiPath: 8058: Cancelled Cmd(0x45b92ea3fd40) 0xa0, cmdId.initiator=0x4538c859b8f8 CmdSN 0x0 from world 0 to path "vmhba32:C0:T0:L0". Cmd count Active:0 Queued:1.
              2021-04-12T04:48:50.527Z cpu2:2097440)ScsiDeviceIO: 4315: Cmd(0x45b92ea76d40) 0x28, cmdId.initiator=0x4305f74cc780 CmdSN 0x1279 from world 2099370 to dev "mpx.vmhba32:C0:T0:L0" failed H:0x5 D:0x0 P:0x0 Cancelled from path layer. Cmd count Active:1
              2021-04-12T04:48:50.527Z cpu2:2097440)Queued:4

            • Nach einem Upgrade auf ESXi Update 2a kann es zu längeren Startzeiten von ESXi-Hosts von bis zu 60 Minuten kommen.
              Das Problem betrifft keine Updates für ESXi Update 2a aus früheren Versionen von ESXi 7.0.x.
              Das Problem tritt nur auf, wenn Sie ein vSphere Lifecycle Manager-Image oder eine Baseline oder den Befehl esxcli software profile update verwenden, um den Upgrade-Vorgang durchzuführen. Wenn Sie ein ISO-Image oder eine Skriptinstallation verwenden, tritt das Problem nicht auf.
              Das Problem wirkt sich wahrscheinlich auf iSCSI-Konfigurationen aus, hängt aber mit dem ESXi-Algorithmus für die Bootbank-Erkennung zusammen und nicht mit der Verlangsamung externer Speicherziele.

            • Aufgrund eines Arbeitsspeicherverlusts im Portset-Heap schlagen vSphere vMotion-Vorgänge auf einem ESXi-Host möglicherweise mit dem Fehler „Nicht genügend Arbeitsspeicher“ fehl. Im vSphere Client wird ein Fehler ähnlich dem folgenden angezeigt:
              Fehler beim Reservieren des Ports: DVSwitch 50 18 34 d1 76 81 ec 9e-03 62 e2 d4 6f 23 30 ba port 1 39.
              Fehlerstatus: Nicht genügend Arbeitsspeicher.

            • Wenn vCenter Server vcsa.vmware.com nicht in eine IP-Adresse auflösen kann, kann der vSAN-Versionskatalog nicht hochgeladen werden. Bei der folgenden vSAN-Integritätsprüfung wird eine Warnung angezeigt: vSAN-Build-Empfehlungsmodul-Integrität.
              Es wird möglicherweise eine Fehlermeldung ähnlich der folgenden angezeigt:
              2021-04-12T11:40:59.435Z ERROR vsan-mgmt[32221] [VsanHttpRequestWrapper::urlopen opID=noOpId] Exception while sending request : Cannot resolve localhost or Internet websites.
              2021-04-12T11:40:59.435Z WARNING vsan-mgmt[32221] [VsanVumCoreUtil::CheckVumServiceStatus opID=noOpId] Failed to connect VUM service: Cannot resolve localhost or Internet websites.
              2021-04-12T11:40:59.435Z INFO vsan-mgmt[32221] [VsanVumIntegration::VumStatusCallback opID=noOpId] VUM is not installed or not responsive ​
              2021-04-12T11:40:59.435Z INFO vsan-mgmt[32221] [VsanVumSystemUtil::HasConfigIssue opID=noOpId] Config issue health.test.vum.vumDisabled exists on entity None

            • Ein Ganzzahlüberlauffehler kann dazu führen, dass vSAN DOM häufiger Bereinigungen als konfiguriert ausgibt.

            • Wenn eine Neusynchronisierung parallel zu Gastschreibvorgängen auf Objekten ausgeführt wird, die einem ESXi-Host gehören, schlägt der Host möglicherweise mit einem violetten Diagnosebildschirm fehl.

            • Wenn die Datei cmmdstimemachineDump.log einen maximalen Grenzwert von 10 MB erreicht, erfolgt eine Rotation und eine neue Datei cmmdstimemachineDump wird erstellt. Während der Rotation wird jedoch in den vmsyslogd.err-Protokollen möglicherweise ein Fehler wie der folgende angezeigt:
              2021-04-08T03:15:53.719Z vmsyslog.loggers.file : ERROR ] Failed to write header on rotate. Ausnahme: [Errno 2] No such file or directory: '/var/run/cmmdstimemachineDumpHeader.txt'

            • In einigen Fällen liefert der CMMDS (Cluster Monitoring, Membership, and Directory Service) keine korrekte Eingabe für die Aufgabe „Objektformatänderung“, und die Aufgabe benötigt viel Zeit, um zu reagieren.

            • In seltenen Szenarien können mehrere ESX-Hosts auf einem Stretched Cluster mit einem violetten Diagnosebildschirm fehlschlagen, wenn der Zeugenhost während des Upgrade-Vorgangs ersetzt wird und kurz nach der Ersetzung eine Aufgabe zur Konvertierung des Festplattenformats ausgeführt wird.

            • Wenn Sie ein benutzerdefiniertes 7.0 Update 2a-Image mithilfe des ESXi-Paketkits erstellen, einige der Komponenten im Basisimage, z. B. Intel-ixgben:1.8.9.0-1OEM.700.1.0.15525992, überschreiben und dann ein Upgrade Ihrer ESXi 7.0.x-Hosts durchführen, können Sie die benutzerdefinierte Komponente nach dem Upgrade nicht entfernen. Außerdem fehlen möglicherweise einige VIBs aus den benutzerdefinierten Komponenten.

            • Wenn Sie ein ESXi-Startgerät klonen, erstellen Sie Instanzen mit identischen UUIDs. Da UUIDs für VMFS-Heartbeat- und Journal-Vorgänge verwendet werden, versuchen mehrere ESXi-Hosts bei duplizierten UUIDs nach dem Installations- oder Upgrade-Vorgang auf Metadatenregionen im selben VMFS-Datenspeicher zuzugreifen. Dies kann dazu führen, dass in VMFS-Datenspeichern auf mehreren ESXi-Hosts eine massive Metadatenbeschädigung auftritt.
              In den vmkernel-Protokollen werden Meldungen ähnlich der folgenden angezeigt:
              vmkernel 608: VMFS volume DCS_HCFA_TEDS_Regulated_10032/5ba2905b-ac11166d-b145-0025b5920a02 on naa.60060e8012a34f005040a34f00000d64:1 has been detected corrupted.
              2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 319: FS3RCMeta 2245 200 21 105 0
              2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 326: 0 0 0 0 0 0 0 0 0 0 0 7 0 254 1 4 0 248 3 96 0 0 0 0 0
              2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 332: 0 0 0
              2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 338: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
              2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 346: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
              2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 346: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 

            • Mit vSphere 7.0 Update 2 wurde der i40en-Inbox-Treiber in i40enu umbenannt. Wenn Sie versuchen, einen asynchronen i40en-Partnertreiber zu installieren, wird das VIB i40en entweder übersprungen oder auf den i40enu-Inbox-Treiber von VMware wiederhergestellt.

            • Ein seltener Seitenfehler kann dazu führen, dass ESXi-Hosts während der Installation des Dell EMC PowerPath-Plug-Ins mit einem violetten Diagnosebildschirm fehlschlagen.

            • Wenn der USB-Host-Controller von Ihrem vSphere-System getrennt wird und eine Ressource auf dem Gerät, z. B. Dump-Dateien, noch von ESXi verwendet wird, kann der Gerätepfad nicht freigegeben werden, wenn das Gerät erneut eine Verbindung herstellt. Dies führt dazu, dass ESXi einen neuen Pfad zum USB-Gerät bereitstellt, der die Verbindung zur /bootbank-Partition unterbricht oder die VMFS-L LOCKER-Partition beschädigt.

          ESXi-7.0U2sc-18295176-standard
          Profilname ESXi-7.0U2sc-18295176-standard
          Build Build-Informationen finden Sie unter In dieser Version enthaltene Patches.
          Anbieter VMware, Inc.
          Datum der Veröffentlichung 24. August 2021
          Akzeptanzebene PartnerSupported
          Betroffene Hardware Nicht verfügbar
          Betroffene Software Nicht verfügbar
          Betroffene VIBs
          • VMware_bootbank_vdfs_7.0.2-0.15.18295176
          • VMware_bootbank_esx-xserver_7.0.2-0.15.18295176
          • VMware_bootbank_esx-base_7.0.2-0.15.18295176
          • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.2-0.15.18295176
          • VMware_bootbank_crx_7.0.2-0.15.18295176
          • VMware_bootbank_native-misc-drivers_7.0.2-0.15.18295176
          • VMware_bootbank_cpu-microcode_7.0.2-0.15.18295176
          • VMware_bootbank_gc_7.0.2-0.15.18295176
          • VMware_bootbank_vsanhealth_7.0.2-0.15.18295176
          • VMware_bootbank_clusterstore_7.0.2-0.15.18295176
          • VMware_bootbank_vsan_7.0.2-0.15.18295176
          • VMware_bootbank_loadesx_7.0.2-0.15.18295176
          • VMware_bootbank_esx-update_7.0.2-0.15.18295176
          • VMware_locker_tools-light_11.2.6.17901274-18295176
          • VMW_bootbank_vmkusb_0.1-1vmw.702.0.15.18295176
          Behobene Probleme 2738816, 2738857, 2735594, 2761942
          Verwandte CVE-Nummern Nicht verfügbar

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

            • OpenSSH wird auf Version 8.5p1 aktualisiert.

            • Die OpenSSL-Bibliothek wird auf Version openssl-1.0.2y aktualisiert.

            • Die Libarchive-Bibliothek wird auf Version 3.5.1 aktualisiert.

            • Die folgenden ISO-Images von VMware Tools 11.2.6 sind im ESXi-Paket enthalten:

              • windows.iso: VMware Tools-Image für Windows 7 SP1 oder Windows Server 2008 R2 SP1 oder höher
              • linux.iso: VMware Tools 10.3.23-Image für ältere Versionen des Linux-Betriebssystems mit glibc 2.5 oder höher

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

              • solaris.iso: VMware Tools-Image für Solaris
              • darwin.iso: VMware Tools-Image für Mac OS X 10.11 und höher.

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

          ESXi-7.0U2sc-18295176-no-tools
          Profilname ESXi-7.0U2sc-18295176-no-tools
          Build Build-Informationen finden Sie unter In dieser Version enthaltene Patches.
          Anbieter VMware, Inc.
          Datum der Veröffentlichung 24. August 2021
          Akzeptanzebene PartnerSupported
          Betroffene Hardware Nicht verfügbar
          Betroffene Software Nicht verfügbar
          Betroffene VIBs
          • VMware_bootbank_vdfs_7.0.2-0.15.18295176
          • VMware_bootbank_esx-xserver_7.0.2-0.15.18295176
          • VMware_bootbank_esx-base_7.0.2-0.15.18295176
          • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.2-0.15.18295176
          • VMware_bootbank_crx_7.0.2-0.15.18295176
          • VMware_bootbank_native-misc-drivers_7.0.2-0.15.18295176
          • VMware_bootbank_cpu-microcode_7.0.2-0.15.18295176
          • VMware_bootbank_gc_7.0.2-0.15.18295176
          • VMware_bootbank_vsanhealth_7.0.2-0.15.18295176
          • VMware_bootbank_clusterstore_7.0.2-0.15.18295176
          • VMware_bootbank_vsan_7.0.2-0.15.18295176
          • VMware_bootbank_loadesx_7.0.2-0.15.18295176
          • VMware_bootbank_esx-update_7.0.2-0.15.18295176
          • VMware_locker_tools-light_11.2.6.17901274-18295176
          • VMW_bootbank_vmkusb_0.1-1vmw.702.0.15.18295176
          Behobene Probleme 2738816, 2738857, 2735594, 2761942
          Verwandte CVE-Nummern Nicht verfügbar

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

            • OpenSSH wird auf Version 8.5p1 aktualisiert.

            • Die OpenSSL-Bibliothek wird auf Version openssl-1.0.2y aktualisiert.

            • Die Libarchive-Bibliothek wird auf Version 3.5.1 aktualisiert.

            • Die folgenden ISO-Images von VMware Tools 11.2.6 sind im ESXi-Paket enthalten:

              • windows.iso: VMware Tools-Image für Windows 7 SP1 oder Windows Server 2008 R2 SP1 oder höher
              • linux.iso: VMware Tools 10.3.23-Image für ältere Versionen des Linux-Betriebssystems mit glibc 2.5 oder höher

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

              • solaris.iso: VMware Tools-Image für Solaris
              • darwin.iso: VMware Tools-Image für Mac OS X 10.11 und höher.

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

          ESXi Image - ESXi70U2c-18426014
          Name ESXi
          Version ESXi70U2c-18426014
          Datum der Veröffentlichung 24. August 2020
          Kategorie Fehlerkorrektur
          Betroffene Komponenten
          • ESXi-Komponente - ESXi-Kern-VIBs
          • Emulex FC-Treiber
          • Broadcom NetXtreme-E-Netzwerk- und ROCE/RDMA-Treiber für VMware ESXi
          • QLogic FastLinQ 10/25/40/50/100 GbE-Ethernet- und RoCE/RDMA-Treiber für VMware ESXi
          • ESXi-Komponente „Installieren/Aktualisieren“
          • Netzwerktreiber für Intel(R) X710/XL710/XXV710/X722-Adapter
          • USB-Treiber
          Behobene Probleme  2717698, 2731446, 2515171, 731306, 2751564, 2718934, 2755056, 2725886, 2725886, 2753231, 2728910, 2741111, 2759343, 2721379, 2751277, 2708326, 2755977, 2737934, 2777001, 2760932, 2731263, 2731142, 2760267, 2749688, 2763986, 2765534, 2766127, 2777003, 2778793, 2755807, 2760081, 2731644, 2749815, 2749962, 2738238, 2799408, 2722263, 2812906, 2750390, 2715138, 2753546
          Verwandte CVE-Nummern Nicht verfügbar
            ESXi image - ESXi70U2sc-18295176
            Name ESXi
            Version ESXi70U2sc-18295176
            Datum der Veröffentlichung 24. August 2020
            Kategorie Sicherheit
            Betroffene Komponenten
            • ESXi-Komponente - ESXi-Kern-VIBs
            • USB-Treiber
            • ESXi Tools-Komponente
            • ESXi-Komponente „Installieren/Aktualisieren“
            Behobene Probleme  2738816, 2738857, 2735594, 2761942
            Verwandte CVE-Nummern Nicht verfügbar

              Bekannte Probleme

              Die bekannten Probleme gliedern sich in folgende Gruppen.

              Sonstige Probleme
              • Der sensord-Daemon kann Hardwarestatus des ESXi-Hosts nicht melden

                Ein Logikfehler bei der IPMI-SDR-Validierung kann dazu führen, dass sensord keine Quelle für Stromversorgungsinformationen identifizieren kann. Wenn Sie daher den Befehl vsish -e get /power/hostStats ausführen, wird möglicherweise keine Ausgabe angezeigt.

                Problemumgehung: Keine

              Installations-, Upgrade- und Migrationsprobleme
              • ESXi-Hosts verlieren möglicherweise nach dem Upgrade des brcmfcoe-Treibers auf Hitachi-Speicher-Arrays die Konnektivität

                Nach einem Upgrade des brcmfcoe-Treibers auf Hitachi-Speicher-Arrays können ESXi-Hosts möglicherweise nicht gestartet werden, und die Konnektivität wird unterbrochen.

                Problemumgehung: Keine.

              Bekannte Probleme aus früheren Versionen

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

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