ESXi 7.0 Update 2 | 9. März 2021 | ISO-Build 17630552

Ü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

  • vSphere Fault Tolerance unterstützt vSphere VM-Verschlüsselung: Ab vSphere 7.0 Update 2 unterstützt vSphere FT die VM-Verschlüsselung. Gastinterne und arraybasierte Verschlüsselung hängt nicht von der VM-Verschlüsselung ab oder stören diese nicht, aber wenn mehrere Verschlüsselungsebenen vorhanden sind, werden zusätzliche Computing-Ressourcen verwendet, was sich auf die Leistung der virtuellen Maschine auswirken können. Die Auswirkung variiert je nach Hardware sowie der Menge und dem Typ der E/A. Daher kann VMware sie nicht quantifizieren. Die Auswirkungen auf die Gesamtleistung sind für die meisten Arbeitslasten vernachlässigbar. Die Effektivität und die Kompatibilität von Back-End-Speicherfunktionen wie Deduplizierung, Komprimierung und Replizierung können auch von der VM-Verschlüsselung betroffen sein. Daher müssen Sie wahrscheinlich Kompromisse beim Speicher in Kauf nehmen. Weitere Informationen finden Sie unter Verschlüsselung virtueller Maschinen und Best Practices für die VM-Verschlüsselung.
     
  • ESXi 7.0 Update 2 unterstützt vSphere Quick Boot auf folgenden Servern:
    • Dell Inc.
      • PowerEdge M830
      • PowerEdge R830
    • HPE
      • ProLiant XL675d Gen10 Plus
    • Lenovo 
      • ThinkSystem SR 635
      • ThinkSystem SR 655
         
  • Bestimmte ESXi-Konfigurationsdateien sind nun schreibgeschützt: Ab ESXi 7.0 Update 2 befinden sich Konfigurationen, die zuvor in den Dateien /etc/keymap, /etc/vmware/welcome, /etc/sfcb/sfcb.cfg, /etc/vmware/snmp.xml, /etc/vmware/logfilters, /etc/vmsyslog.conf und /etc/vmsyslog.conf.d/*.conf gespeichert wurden, nun in der ConfigStore-Datenbank. Sie können diese Konfigurationen nur mithilfe von ESXCLI-Befehlen und nicht durch Bearbeitung von Dateien ändern. Weitere Informationen finden Sie in den VMware-Knowledgebase-Artikeln 82637 und 82638.
     
  • VMware vSphere Virtual Volumes für besseres Debugging: Mit ESXi 7.0 Update 2 können Sie Leistungsstatistiken für vSphere Virtual Volumes nachverfolgen, um schnell Probleme wie z. B. Latenz bei VASA-Anbieterantworten von Drittanbietern zu identifizieren. Mithilfe eines Befehlssatzes können Sie Statistiken für alle VASA-Anbieter in Ihrem System oder für einen bestimmten Namespace oder eine bestimmte Einheit im angegebenen Namespace erhalten oder die Statistiknachverfolgung für den gesamten Namespace aktivieren. Weitere Informationen finden Sie unter Erfassen statistischer Informationen für VVols.
     
  • Unterstützung der NVIDIA Ampere-Architektur: vSphere 7.0 Update 2 bietet zusätzliche Unterstützung für die NVIDIA Ampere-Architektur, mit der Sie Trainings für High-End-KI/ML und Arbeitslasten für ML-Rückschlüsse ausführen können, indem Sie die beschleunigte Kapazität der A100-GPU nutzen. Darüber hinaus unterstützt vSphere 7.0 Update 2 die MIG-Technologie (Multi-Instance GPU) und bietet damit eine verbesserte GPU-Freigabe und -Nutzung. Mit vSphere 7.0 Update 2 wurde auch die Leistung der Gerät-zu-Gerät-Kommunikation verbessert. Hierbei wird auf der vorhandenen NVIDIA GPUDirect-Funktion aufgebaut, indem Adressübersetzungsdienste (Address Translation Services, ATS) und Zugriffssteuerungsdienste (Access Control Services, ACS) auf der PCIe-Busebene im ESXi-Kernel ermöglicht werden.
     
  • Unterstützung für Mellanox ConnectX-6 200G-Netzwerkkarten: ESXi 7.0 Update 2 unterstützt 200G-Netzwerkkarten der Familien Mellanox Technologies MT28908 (ConnectX-6) und Mellanox Technologies MT2892 (ConnectX-6 Dx).
     
  • Leistungsverbesserungen für AMD Zen-CPUs: Mit ESXi 7.0 Update 2 kann die Leistung der AMD Zen-CPU mithilfe vorkonfigurierter Optimierungen um bis zu 30 % in verschiedenen Benchmarks erhöht werden. Der aktualisierte ESXi-Scheduler nutzt die AMD NUMA-Architektur vollumfänglich, um die am besten geeigneten Platzierungsentscheidungen für virtuelle Maschinen und Container zu treffen. AMD Zen-CPU-Optimierungen ermöglichen eine höhere Anzahl von VMs oder Containerbereitstellungen mit besserer Leistung.
     
  • Verringerte Rechen- und E/A-Latenz und Jitter für latenzempfindliche Arbeitslasten: Latenzempfindliche Arbeitslasten, wie z. B. in Finanz- und Telekommunikationsanwendungen, können erhebliche Leistungssteigerungen durch E/A-Latenz und Jitter-Optimierungen in ESXi 7.0 Update 2 erzielen. Die Optimierungen reduzieren Stör- und Jitter-Quellen, um eine konsistente Laufzeitumgebung bereitzustellen. Mit ESXi 7.0 Update 2 können Sie auch höhere Geschwindigkeiten bei der Interrupt-Zustellung für Passthrough-Geräte feststellen.
     
  • Vertrauliche vSphere-Pods in einem Supervisor-Cluster in vSphere with Tanzu: Ab vSphere 7.0 Update 2 können Sie vertrauliche vSphere-Pods in einem Supervisor-Cluster in vSphere with Tanzu ausführen, wobei der Arbeitsspeicher des Gastbetriebssystems verschlüsselt und vor dem Zugriff durch den Hypervisor geschützt bleibt. Sie können vertrauliche vSphere-Pods konfigurieren, indem Sie SEV-ES (Secure Encrypted Virtualization-Encrypted State) als zusätzliche Sicherheitsverbesserung hinzufügen. Weitere Informationen finden Sie unter Bereitstellen eines vertraulichen vSphere-Pods.
     
  • Schnelle vSphere Lifecycle Manager-Upgrades: Ab vSphere 7.0 Update 2 können Sie Upgrade-Dauer und Systemausfallzeit erheblich reduzieren und die Systemstartzeit minimieren, indem Sie angehaltene virtuelle Maschinen im Arbeitsspeicher ablegen und die Quick Boot-Funktion verwenden. Sie können vSphere Lifecycle Manager zum Ablegen angehaltener virtueller Maschinen im Arbeitsspeicher konfigurieren, statt die VMs beim Aktualisieren eines ESXi-Hosts zu migrieren, auszuschalten oder auf der Festplatte abzulegen. Weitere Informationen finden Sie unter Konfigurieren von vSphere Lifecycle Manager für schnelle Upgrades.
     
  • Verschlüsselter Fault Tolerance-Protokolldatenverkehr: Ab vSphere 7.0 Update 2 können Sie Fault Tolerance-Protokolldatenverkehr für verbesserte Sicherheit verschlüsseln. vSphere Fault Tolerance führt häufige Prüfungen zwischen den primären und sekundären VMs durch, um eine schnelle Wiederaufnahme ab dem letzten erfolgreichen Prüfpunkt zu ermöglichen. Der Prüfpunkt enthält den VM-Status, der seit dem vorherigen Prüfpunkt geändert wurde. Das Verschlüsseln des Protokolldatenverkehrs verhindert böswilligen Zugriff oder Netzwerkangriffe.

Vorherige Versionen von ESXi 7.0

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

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

In dieser Version enthaltene Patches

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

Build-Details

Download-Dateiname: VMware-ESXi-7.0U2-17630552-depot
Build: 17630552
Download-Größe: 390,9 MB
md5sum: 4eae7823678cc7c57785e4539fe89d81
sha1checksum: 7c6b70a0190bd78bcf118f856cf9c60b4ad7d4b5
Neustart des Hosts erforderlich: Ja
Migration oder Herunterfahren der virtuellen Maschine erforderlich: Ja

WICHTIG:

  • Im Lifecycle Manager-Plug-In des vSphere Clients wird der 17.02.2021 als Veröffentlichungsdatum für ESXi 7.0.2-Basisimage, -Profile und -Komponenten verwendet. Dies wird erwartet. Um sicherzustellen, dass Sie die korrekten Filter nach dem Veröffentlichungsdatum verwenden können, lautet nur das Veröffentlichungsdatum des Rollup-Bulletin 2021-03-09.
     
  • 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
ESXi70U2-17630552 Verbesserung Wichtig

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.0.2-17630552-standard
ESXi-7.0.2-17630552-no-tools

ESXi-Image

Name und Version Datum der Veröffentlichung Kategorie Detail
ESXi_7.0.2-0.0.17630552 09.03.2021 Allgemein Fehlerkorrektur-Image

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

Patch-Download und -Installation

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

Hinweise zu Produktunterstützung

  • Namensänderung für den i40en-Inbox-Netzwerktreiber: Mit vSphere 7.0 Update 2 wurde der Name des i40en-Inbox-Netzwerktreibers für ESXi in i40enu geändert.
  • Entfernen von SHA1 aus Secure Shell (SSH): In vSphere 7.0 Update 2 wird der kryptografische SHA-1-Hashing-Algorithmus aus der SSHD-Standardkonfiguration entfernt.
  • Veraltete REST APIs von vSphere 6.0 bis 6.7: VMware weist REST APIs von vSphere 6.0 bis 6.7 als veraltet aus; sie wurden unter /rest bereitgestellt und werden als alte REST APIs bezeichnet. Mit vSphere 7.0 Update 2 werden REST APIs unter /api bereitgestellt und als neue REST APIs bezeichnet. Weitere Informationen finden Sie im Blog vSphere 7 Update 2 - REST API Modernization und im vSphere-Knowledgebase-Artikel 83022.
  • Absicht, SHA-1 als veraltet auszuweisen: Der kryptografische Hashing-Algorithmus für SHA-1 wird in einer künftigen Version von vSphere veraltet sein. SHA-1 und der bereits veraltete MD5 weisen bekannte Schwächen auf, und praktische Angriffe auf sie wurden nachgewiesen.
  • Standardformate für Protokolldateien und Syslog-Übertragungen: VMware plant, die Formate aller ESXi-Protokolldateien und Syslog-Übertragungen in einer künftigen Hauptversion von ESXi zu standardisieren. Diese Standardisierung wirkt sich auf die Metadaten aus, die jeder Protokolldateizeile oder Syslog-Übertragung zugeordnet sind. Beispiel: Zeitstempel, programmgesteuerter Quellbezeichner, Schweregrad der Meldung und Daten des Vorgangsbezeichners. Weitere Informationen finden Sie unter https://core.vmware.com/esxi-log-message-formats. 

Behobene Probleme

Die behobenen Probleme werden in folgende Kategorien unterteilt.

Intel-Microcode-Updates
  • ESXi 7.0 Update 2 enthält die folgenden Microcode-Updates:
    Codename FMS PLT-ID MCU-Rev. MCU-Datum Markennamen
    Nehalem EP 0x106a5 0x03 0x0000001d 5/11/2018 Intel Xeon 35xx-Reihe;
    Intel Xeon 55xx-Reihe
    Lynnfield 0x106e5 0x13 0x0000000a 5/8/2018 Intel Xeon 34xx Lynnfield-Reihe
    Clarkdale 0x20652 0x12 0x00000011 5/8/2018 Intel i3/i5 Clarkdale-Reihe;
    Intel Xeon 34xx Clarkdale-Reihe
    Arrandale 0x20655 0x92 0x00000007 4/23/2018 Intel Core i7-620LE-Prozessor
    Sandy Bridge DT 0x206a7 0x12 0x0000002f 2/17/2019 Intel Xeon E3-1100-Reihe;
    Intel Xeon E3-1200-Reihe;
    Intel i7-2655-LE-Reihe;
    Intel i3-2100-Reihe
    Westmere EP 0x206c2 0x03 0x0000001f 5/8/2018 Intel Xeon 56xx-Reihe;
    Intel Xeon 36xx-Reihe
    Sandy Bridge EP 0x206d6 0x6d 0x00000621 3/4/2020 Intel Pentium 1400-Reihe;
    Intel Xeon E5-1400-Reihe;
    Intel Xeon E5-1600-Reihe;
    Intel Xeon E5-2400-Reihe;
    Intel Xeon E5-2600-Reihe;
    Intel Xeon E5-4600-Reihe
    Sandy Bridge EP 0x206d7 0x6d 0x0000071a 3/24/2020 Intel Pentium 1400-Reihe;
    Intel Xeon E5-1400-Reihe;
    Intel Xeon E5-1600-Reihe;
    Intel Xeon E5-2400-Reihe;
    Intel Xeon E5-2600-Reihe;
    Intel Xeon E5-4600-Reihe
    Nehalem EX 0x206e6 0x04 0x0000000d 5/15/2018 Intel Xeon 65xx-Reihe;
    Intel Xeon 75xx-Reihe
    Westmere EX 0x206f2 0x05 0x0000003b 5/16/2018 Intel Xeon E7-8800-Reihe;
    Intel Xeon E7-4800-Reihe;
    Intel Xeon E7-2800-Reihe
    Ivy Bridge DT 0x306a9 0x12 0x00000021 2/13/2019 Intel i3-3200-Reihe;
    Intel i7-3500-LE/UE;
    Intel i7-3600-QE;
    Intel Xeon E3-1200-v2-Reihe;
    Intel Xeon E3-1100-C-v2-Reihe;
    Intel Pentium B925C
    Haswell DT 0x306c3 0x32 0x00000028 11/12/2019 Intel Xeon E3-1200-v3-Reihe;
    Intel i7-4700-EQ-Reihe;
    Intel i5-4500-TE-Reihe;
    Intel i3-4300-Reihe
    Ivy Bridge EP 0x306e4 0xed 0x0000042e 3/14/2019 Intel Xeon E5-4600-v2-Reihe;
    Intel Xeon E5-2600-v2-Reihe;
    Intel Xeon E5-2400-v2-Reihe;
    Intel Xeon E5-1600-v2-Reihe;
    Intel Xeon E5-1400-v2-Reihe
    Ivy Bridge EX 0x306e7 0xed 0x00000715 3/14/2019 Intel Xeon E7-8800/4800/2800-v2-Reihe
    Haswell EP 0x306f2 0x6f 0x00000044 27/5/2020 Intel Xeon E5-4600-v3-Reihe;
    Intel Xeon E5-2600-v3-Reihe;
    Intel Xeon E5-2400-v3-Reihe;
    Intel Xeon E5-1600-v3-Reihe;
    Intel Xeon E5-1400-v3-Reihe
    Haswell EX 0x306f4 0x80 0x00000016 17.06.2019 Intel Xeon E7-8800/4800-v3-Serie
    Broadwell H 0x40671 0x22 0x00000022 11/12/2019 Intel Core i7-5700EQ;
    Intel Xeon E3-1200-v4-Reihe
    Avoton 0x406d8 0x01 0x0000012d 16.09.2019 Intel Atom C2300-Reihe;
    Intel Atom C2500-Reihe;
    Intel Atom C2700-Reihe
    Broadwell EP/EX 0x406f1 0xef 0x0b000038 18.06.2019 Intel Xeon E7-8800/4800-v4-Reihe;
    Intel Xeon E5-4600-v4-Reihe;
    Intel Xeon E5-2600-v4-Reihe;
    Intel Xeon E5-1600-v4-Reihe
    Skylake SP 0x50654 0xb7 0x02006a08 16/6/2020 Intel Xeon Platinum 8100-Reihe;
    Intel Xeon Gold 6100/5100, Silver 4100, Bronze 3100-Reihe;
    Intel Xeon D-2100-Reihe;
    Intel Xeon D-1600-Reihe;
    Intel Xeon W-3100-Reihe;
    Intel Xeon W-2100-Reihe
    Cascade Lake B-0 0x50656 0xbf 0x04003003 18/6/2020 Intel Xeon Platinum 9200/8200-Reihe;
    Intel Xeon Gold 6200/5200;
    Intel Xeon Silver 4200/Bronze 3200;
    Intel Xeon W-3200
    Cascade Lake 0x50657 0xbf 0x05003003 18/6/2020 Intel Xeon Platinum 9200/8200-Reihe;
    Intel Xeon Gold 6200/5200;
    Intel Xeon Silver 4200/Bronze 3200;
    Intel Xeon W-3200
    Cooper Lake 0x5065b 0xbf 0x0700001f 17/9/2020 Intel Xeon Platinum 8300-Reihe;
    Intel Xeon Gold 6300/5300
    Broadwell DE 0x50662 0x10 0x0000001c 17.06.2019 Intel Xeon D-1500-Reihe
    Broadwell DE 0x50663 0x10 0x07000019 17.06.2019 Intel Xeon D-1500-Reihe
    Broadwell DE 0x50664 0x10 0x0f000017 17.06.2019 Intel Xeon D-1500-Reihe
    Broadwell NS 0x50665 0x10 0x0e00000f 17.06.2019 Intel Xeon D-1600-Reihe
    Skylake H/S 0x506e3 0x36 0x000000e2 14/7/2020 Intel Xeon E3-1500-v5-Reihe;
    Intel Xeon E3-1200-v5-Reihe
    Denverton 0x506f1 0x01 0x00000032 7/3/2020 Intel Atom C3000-Reihe
    Snow Ridge 0x80665 0x01 0x0b000007 25/2/2020 Intel Atom P5000 Series
    Kaby Lake H/S/X 0x906e9 0x2a 0x000000de 26/5/2020 Intel Xeon E3-1200-v6-Reihe;
    Intel Xeon E3-1500-v6-Reihe
    Coffee Lake 0x906ea 0x22 0x000000de 25/5/2020 Intel Xeon E-2100-Reihe;
    Intel Xeon E-2200-Reihe (4 oder 6 Kerne)
    Coffee Lake 0x906eb 0x02 0x000000de 25/5/2020 Intel Xeon E-2100-Reihe
    Coffee Lake 0x906ec 0x22 0x000000de 3/6/2020 Intel Xeon E-2100-Reihe
    Coffee Lake Refresh 0x906ed 0x22 0x000000de 24/5/2020 Intel Xeon E-2200-Reihe (8 Kerne)
Speicherprobleme
  • Nach dem Wiederherstellen nach APD- oder PDL-Bedingungen bleibt der VMFS-Datenspeicher mit aktivierter Unterstützung für virtuelle Festplatten im Cluster möglicherweise nicht zugänglich

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

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

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

    Dieses Problem wurde in der vorliegenden Version behoben.

Auto Deploy-Probleme
  • PR 2710383: Wenn Sie einen ESXi-Host mithilfe der statusbehafteten vSphere Auto Deploy-Installation bereitstellen, gehen die auf die ConfigStore-Datenbank migrierten ESXi-Konfigurationen während des Upgrades verloren.

    Wenn Sie einen ESXi-Host mithilfe der Funktion für eine statusbehaftete Auto Deploy-Installation bereitstellen, wird eine Option zur Angabe des statusbehafteten Installationsstarts in der Datei boot.cfg nicht entfernt und kollidiert mit dem dauerhaften Zustand der ConfigStore-Datenbank. Folglich gehen ESXi-Konfigurationen, die auf die ConfigStore-Datenbank migriert wurden, während des Upgrades auf ESXi 7.x verloren.

    Dieses Problem wurde in der vorliegenden Version behoben.

Netzwerkprobleme
  • PR 2696435: VGT (Virtual Guest Tagging) kann in einer SR-IOV-Umgebung nicht standardmäßig verwendet werden.

    VGT kann mit dem i40enu-Treiber in ESXi 7.0 Update 2 nicht standardmäßig verwendet werden, um nicht vertrauenswürdige virtuelle SR-IOV-Funktionen an der Übertragung oder dem Empfang von Paketen zu hindern, die mit einer anderen VLAN-ID als dem Port-VLAN gekennzeichnet sind. 
    Sie müssen alle virtuellen Funktionen mithilfe des folgenden Modulparameters in den vertrauenswürdigen Modus versetzen:
    esxcli system module parameters set -a -m i40enu -p "trust_all_vfs=1,1,1,...

    Dieses Problem wurde in der vorliegenden Version behoben.

Sonstige Probleme
  • NEU: Wenn der Xorg-Prozess nicht neu gestartet werden kann, während ein ESXi-Host den Wartungsmodus verlässt, reagiert der hostd-Dienst möglicherweise nicht mehr

    Wenn der Xorg-Prozess nicht neu gestartet werden kann, während ein ESXi-Host den Wartungsmodus verlässt, reagiert der hostd-Dienst möglicherweise nicht mehr, da er den Beendigungsvorgang nicht abschließen kann.

    Dieses Problem wurde in der vorliegenden Version behoben.

Upgrade-Probleme
  • NEU: Wenn ein vCenter Server-System die Version 7.0 aufweist, schlagen ESXi-Host-Upgrades auf eine neuere Version mithilfe des vSphere Lifecycle Manager und eines ISO-Images fehl

    Wenn Sie ein ISO-Image verwenden, um ein Upgrade von ESXi-Hosts auf eine neuere Version als 7.0 unter Verwendung des vSphere Lifecycle Manager durchzuführen, und das vCenter Server-System noch die Version 7.0 aufweist, schlägt das Upgrade fehl. Im vSphere Client wird der Fehler Upgrade des Hosts wird nicht unterstützt angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben.

Bekannte Probleme

Die bekannten Probleme gliedern sich in folgende Gruppen.

Netzwerkprobleme
  • NEU: Nach einem Upgrade auf ESXi 7.0 Update 2 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 i40en-VIB entweder übersprungen oder auf den VMware-i40enu-Inbox-Treiber wiederhergestellt.

    Problemumgehung: Um das Upgrade auf ESXi 7.0 Update 2 abschließen zu können, müssen Sie ein benutzerdefiniertes Image erstellen, das die i40en-Komponentenversion 1.8.1.136-1vmw.702.0.0.17630552 durch die i40en-Komponentenversion Intel-i40en_1.10.9.0-1OEM.700.1.0.15525992 oder höher ersetzt. Weitere Informationen finden Sie unter Anpassen von Installationen mit vSphere ESXi Image Builder.

  • NEU: Wenn Sie automatische Aushandlung auf einem Netzwerkadapter festlegen, schlägt das Gerät möglicherweise fehl

    Wenn Sie in bestimmten Umgebungen die Verbindungsgeschwindigkeit mithilfe des Befehls esxcli network nic set -a -n vmmicx auf automatische Aushandlung für Netzwerkadapter festlegen, schlagen die Geräte möglicherweise fehl und beim Neustart werden die Verbindungen nicht wiederhergestellt. Das Problem betrifft insbesondere eine Kombination aus bestimmten Netzwerkadaptern des Typs Intel X710/X722, einem SFP+-Modul und einem physischen Switch, bei denen eine ausgehandelte Geschwindigkeit bzw. ein Duplexszenario nicht unterstützt wird.

    Problemumgehung: Stellen Sie sicher, dass Sie ein SFP+-Modul der Marke Intel verwenden. Alternativ können Sie ein DAC-Kabel (Direct Attach Copper) verwenden.

  • Paravirtuelle RDMA-Netzwerkadapter (PVRDMA) bieten keine Unterstützung für NSX-Netzwerkrichtlinien

    Wenn Sie einen verteilten virtuellen NSX-Port für die Verwendung im PVRDMA-Datenverkehr konfigurieren, entspricht der RDMA-Protokolldatenverkehr über die PVRDMA-Netzwerkadapter nicht den NSX-Netzwerkrichtlinien.

    Problemumgehung: Konfigurieren Sie keine verteilten virtuellen NSX-Ports für die Verwendung im PVRDMA-Datenverkehr.

  • Im 1x100G-Portmodus konfigurierte Netzwerkadapter vom Typ Solarflare x2542 und x2541 erreichen einen Durchsatz von bis zu 70 GBit/s in einer vSphere-Umgebung.

    vSphere 7.0 Update 2 unterstützt Netzwerkadapter vom Typ Solarflare x2542 und x2541, die im 1x100G-Portmodus konfiguriert sind. Unter Umständen kommt es bei den Geräten jedoch zu einer Hardwarebeschränkung, wodurch der tatsächliche Durchsatz in einer vSphere-Umgebung bis zu 70 GBit/s beträgt.

    Problemumgehung: Keine

  • VLAN-Datenverkehr kann nach dem Zurücksetzen einer Netzwerkkarte fehlschlagen

    Eine Netzwerkkarte mit der PCI-Geräte-ID 8086:1537 kann nach dem Zurücksetzen möglicherweise keine VLAN-gekennzeichneten Pakete mehr senden und empfangen, z. B. mit dem Befehl vsish -e set /net/pNics/vmnic0/reset 1.

    Problemumgehung: Vermeiden Sie das Zurücksetzen der Netzwerkkarte. Wenn Sie bereits mit dem Problem konfrontiert sind, verwenden Sie die folgenden Befehle zum Wiederherstellen der VLAN-Funktion, z. B. bei vmnic0:
    # esxcli network nic software set --tagging=1 -n vmnic0
    # esxcli network nic software set --tagging=0 -n vmnic0

  • Jede Änderung der NetQueue-Balancer-Einstellungen führt dazu, dass NetQueue nach dem Neustart eines ESXi-Hosts deaktiviert wird

    Jede Änderung in den Einstellungen des NetQueue-Balancers mithilfe des Befehls esxcli/localcli network nic queue loadbalancer set -n <nicname>--<lb_setting> führt dazu, dass NetQueue (standardmäßig aktiviert) nach dem Neustart eines ESXi-Hosts deaktiviert wird.

    Problemumgehung: Nach einer Änderung in den Einstellungen des NetQueue-Balancers und dem Neustart des Hosts verwenden Sie den Befehl configstorecli config current get -c esx -g network -k nics, um ConfigStore-Daten abzurufen und sicherzustellen, dass /esx/network/nics/net_queue/load_balancer/enable erwartungsgemäß funktioniert.

    Nach dem Ausführen des Befehls wird eine Ausgabe ähnlich der folgenden angezeigt:
    {
    "mac": "02:00:0e:6d:14:3e",
    "name": "vmnic1",
    "net_queue": {
      "load_balancer": {
        "dynamic_pool": true,
          "enable": true
      }
     },
     "virtual_mac": "00:50:56:5a:21:11"
    }

    Bei nicht erwartungsgemäßer Ausgabe, wie z. B. "load_balancer": "enable": false", führen Sie folgenden Befehl aus:
    esxcli/localcli network nic queue loadbalancer state set -n <nicname> -e true

Sicherheitsprobleme
  • Deaktivieren Sie den Service Location Protocol-Dienst (slpd) in ESXi, um mögliche Sicherheitsschwachstellen zu vermeiden

    Bestimmte Dienste in ESXi, die zusätzlich zum Hostbetriebssystem ausgeführt werden, darunter slpd, der CIM-Objekt-Broker, sfcbd und der verwandte openwsmand-Dienst, weisen nachgewiesene Sicherheitsschwachstellen auf. VMware hat alle bekannten Schwachstellen in VMSA-2019-0022 und VMSA-2020-0023 behoben. Die Fixes sind Bestandteil von vSphere 7.0 Update 2. Während sfcbd und openwsmand in ESXi standardmäßig deaktiviert sind, ist slpd standardmäßig aktiviert. Wenn slpd nicht benötigt wird, müssen Sie den Dienst ausschalten, um künftige Sicherheitsschwachstellen nach einem Upgrade zu vermeiden. 

    Problemumgehung: Führen Sie die folgenden PowerCLI-Befehle aus, um den slpd-Dienst auszuschalten:
    $ Get-VMHost | Get-VmHostService | Where-Object {$_.key -eq “slpd”} | Set-VMHostService -policy “off”
    $ Get-VMHost | Get-VmHostService | Where-Object {$_.key -eq “slpd”} | Stop-VMHostService -Confirm:$false

    Alternativ können Sie den Befehl chkconfig slpd off && /etc/init.d/slpd stop verwenden.

    Der openwsmand-Dienst befindet sich nicht in der Liste der ESXi-Dienste. Sie können den Dienststatus mithilfe der folgenden PowerCLI-Befehle überprüfen:
    $esx=(Get-EsxCli -vmhost xx.xx.xx.xx -v2)
    $esx.system.process.list.invoke() | where CommandLine -like '*openwsman*' | select commandline

    In der Liste der ESXi-Dienste wird der sfcbd-Dienst als sfcbd-watchdog angezeigt.

    Weitere Informationen finden Sie in den VMware-Knowledgebase-Artikeln 76372 und 1025757.

Sonstige Probleme
  • Sie können aufgrund eines Fehlers, bei dem ein Digest-Vorgang fehlgeschlagen ist, keine Snapshots von virtuellen Maschinen erstellen

    Eine seltene Race-Bedingung, bei der während der Aktualisierung der CBRC-Digest-Datei (Content Based Read Cache) ein APD-Status (All-Paths-Down) auftritt, verursacht unter Umständen Inkonsistenzen in der Digest-Datei. Infolgedessen können Sie keine VM-Snapshots erstellen. Im Backtrace wird ein Fehler vom Typ Beim Speichern des Snapshots ist ein Fehler aufgetreten: Fehler bei Digest-Vorgang angezeigt.

    Problemumgehung: Schalten Sie die virtuellen Maschinen ein/aus, um eine Neuberechnung der CBRC-Hashes auszulösen und die Inkonsistenzen in der Digest-Datei zu löschen.

  • 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

    Problemumgehung: Keine

Speicherprobleme
  • NEU: Wenn Sie ein USB-Gerät als Startgerät 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

    Problemumgehung: Keine.

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

    Problemumgehung: Führen Sie Hotplug-Vorgänge für einen Steckplatz erst durch, wenn der vorherige Hotplug-Vorgang für den Steckplatz abgeschlossen ist. Beispiel: Wenn Sie einen Vorgang zum Entfernen bei laufendem Betrieb nach einem Vorgang zum Hinzufügen bei laufendem Betrieb ausführen möchten, warten Sie, bis die HBAs erstellt und die LUNs erkannt wurden. Warten Sie im alternativen Szenario (Vorgang zum Hinzufügen bei laufendem Betrieb nach einem Vorgang zum Entfernen bei laufendem Betrieb) bis alle LUNs und HBAs entfernt wurden.

VM-Verwaltungsprobleme
  • UEFI HTTP-Startvorgang virtueller Maschinen auf ESXi-Hosts mit Versionen vor 7.0 Update 2 schlägt fehl

    Der UEFI HTTP-Startvorgang virtueller Maschinen wird nur auf ESXi 7.0 Update 2-Hosts und höher und VMs mit Hardwareversion 19 oder höher unterstützt.

    Problemumgehung: Verwenden Sie den UEFI HTTP-Startvorgang nur auf virtuellen Maschinen mit Hardwareversion 19 oder höher. Durch Verwendung der Hardwareversion 19 wird sichergestellt, dass die virtuellen Maschinen nur auf Hosts mit ESXi Version 7.0 Update 2 oder höher platziert werden.

vSAN-Probleme
  • Wenn Sie die bevorzugte Site in einem VMware vSAN Stretched Cluster ändern, werden bestimmte Objekte unter Umständen fälschlicherweise als konform angezeigt

    Wenn Sie die bevorzugte Site in einem Stretched Cluster ändern, können bestimmte Objekte fälschlicherweise als konform angezeigt werden, da ihre Richtlinieneinstellungen unter Umständen nicht automatisch geändert werden. Wenn Sie eine virtuelle Maschine beispielsweise zur Beibehaltung von Daten auf der bevorzugten Site konfigurieren, verbleiben die Daten beim Ändern der bevorzugten Site unter Umständen auf der nicht bevorzugten Site.

    Problemumgehung: Legen Sie die Einstellung ClomMaxCycleMinutes vor dem Ändern einer bevorzugten Site unter „Erweiterte Einstellungen“ auf 15 Minuten fest, um sicherzustellen, dass die Objektrichtlinien aktualisiert werden. Setzen Sie die Option ClomMaxCrawlCycleMinutes nach der Änderung auf den früheren Wert zurück.

Installations-, Upgrade- und Migrationsprobleme
  • Der UEFI-Neustart von ESXi-Hosts wird während eines Updates von einer früheren Version von ESXi 7.0 auf ESXi 7.0 Update 2 möglicherweise beendet

    Wenn Sie versuchen, Ihre Umgebung von einer früheren Version von ESXi 7.0 auf Version 7.0 Update 2 zu aktualisieren und dabei vSphere Lifecycle Manager-Patch-Baselines verwenden, wird der UEFI-Neustart von ESXi-Hosts möglicherweise mit einem Fehler ähnlich dem folgenden beendet:
    Laden von /boot.cfg
    crypto64.efi konnte nicht geladen werden
    Fatal error: 15 (nicht gefunden)

    Problemumgehung: Weitere Informationen finden Sie in den VMware-Knowledgebase-Artikeln 83063 und 83107.

  • Wenn Legacy-VIBs auf einem ESXi-Host verwendet werden, kann vSphere Lifecycle Manager eine gewünschte Softwarespezifikation für ein Seeding für einen neuen Cluster nicht extrahieren

    Mit vCenter Server 7.0 Update 2 können Sie einen neuen Cluster erstellen, indem Sie die gewünschte Softwarespezifikation von einem einzelnen Referenzhost importieren.  Wenn jedoch auf einem ESXi-Host Legacy-VIBs verwendet werden, kann vSphere Lifecycle Manager in der vCenter Server-Instanz, in der Sie den Cluster erstellen, keine Referenzsoftwarespezifikation von einem solchen Host extrahieren. In der Datei /var/log/lifecycle.log werden Meldungen ähnlich der folgenden angezeigt:
    020-11-11T06:54:03Z lifecycle: 1000082644: HostSeeding:499 ERROR Extract depot failed: Checksum doesn't match. Calculated 5b404e28e83b1387841bb417da93c8c796ef2497c8af0f79583fd54e789d8826, expected: 0947542e30b794c721e21fb595f1851b247711d0619c55489a6a8cae6675e796 2020-11-11T06:54:04Z lifecycle: 1000082644: imagemanagerctl:366 ERROR Extract depot failed. 2020-11-11T06:54:04Z lifecycle: 1000082644: imagemanagerctl:145 ERROR [VibChecksumError]

    Problemumgehung: Befolgen Sie die im VMware-Knowledgebase-Artikel 83042 beschriebenen Schritte.

  • Nach jedem ESXi-Startvorgang wird in der Datei „syslog.log“ ein kurzer Anstieg von Protokollmeldungen verzeichnet

    Nach der Aktualisierung auf ESXi 7.0 Update 2 wird im Anschluss an jeden Startvorgang unter Umständen ein kurzer Anstieg von Protokollmeldungen verzeichnet.
    Solche Protokolle weisen nicht auf ein Problem mit ESXi hin. Die folgenden Meldungen können ignoriert werden. Beispiel:
    ​2021-01-19T22:44:22Z watchdog-vaai-nasd: '/usr/lib/vmware/nfs/bin/vaai-nasd -f' exited after 0 seconds (quick failure 127) 1
    2021-01-19T22:44:22Z watchdog-vaai-nasd: Executing '/usr/lib/vmware/nfs/bin/vaai-nasd -f'
    2021-01-19T22:44:22.990Z aainasd[1000051135]: Log for VAAI-NAS Daemon for NFS version=1.0 build=build-00000 option=DEBUG
    2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoadFile: No entries loaded by dictionary.
    2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoad: Cannot open file "/usr/lib/vmware/config": No such file or directory.“
    2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoad: Cannot open file "//.vmware/config": No such file or directory.“
    2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoad: Cannot open file "//.vmware/preferences": No such file or directory.“
    2021-01-19T22:44:22.990Z vaainasd[1000051135]: Switching to VMware syslog extensions
    2021-01-19T22:44:22.992Z vaainasd[1000051135]: Loading VAAI-NAS plugin(s).
    2021-01-19T22:44:22.992Z vaainasd[1000051135]: DISKLIB-PLUGIN : Not loading plugin /usr/lib/vmware/nas_plugins/lib64: Not a shared library.

    Problemumgehung: Keine

  • In Berichten zur vSphere Quick Boot-Kompatibilitätsprüfung werden Warnmeldungen zu fehlenden VIBs angezeigt

    Wenn Sie nach einem Upgrade auf ESXi 7.0 Update 2 die vSphere Quick Boot-Kompatibilität Ihrer Umgebung mithilfe des Befehls /usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py überprüfen, werden möglicherweise einige Warnungen zu fehlenden VIBs in der Shell angezeigt. Beispiel:
    VIB(s) wurde(n) ... in der angegebenen VIB-Sammlung nicht gefunden.
    Fehlende reservierte VIB(s) wird/werden ignoriert..., sie werden aus den reservierten VIB-IDs entfernt.
    Solche Warnungen weisen nicht auf ein Kompatibilitätsproblem hin.

    Problemumgehung: Es ist sicher, die Meldungen zu fehlenden VIBs zu ignorieren. Dies wirkt sich nicht auf die vSphere Quick Boot-Kompatibilität aus. In der letzten Ausgabezeile des Befehls loadESXCheckCompat wird eindeutig angegeben, ob der Host kompatibel ist.

  • Automatisches Bootstrapping eines Clusters, den Sie mit einem vSphere Lifecycle Manager-Image verwalten, schlägt mit einem Fehler fehl

    Wenn Sie versuchen, für einen Cluster, den Sie mit einem vSphere Lifecycle Manager-Image verwalten, automatisches Bootstrapping zu verwenden, um eine statusbehaftete Installation und Überschreibung der VMFS-Partitionen durchzuführen, schlägt der Vorgang mit einer Fehlermeldung fehl. Im Support-Paket werden Meldungen ähnlich der folgenden angezeigt:
    2021-02-11T19:37:43Z Host Profiles[265671 opID=MainThread]: FEHLER: EngineModule::ApplyHostConfig. Exception: [Errno 30] Schreibgeschütztes Dateisystem

    Problemumgehung: Folgen Sie den Anweisungen des Anbieters, um die VMFS-Partition auf dem Zielhost zu bereinigen, und wiederholen Sie den Vorgang. Alternativ können Sie eine leere Festplatte verwenden. Weitere Informationen zum Dienstprogramm zur Festplattenpartitionierung auf ESXi finden Sie im VMware-Knowledgebase-Artikel 1036609.

  • Upgrades von ESXi 6.5.x und 6.7.0 auf ESXi 7.x unter Verwendung von ESXCLI können aufgrund einer Speicherbeschränkung fehlschlagen

    Upgrades auf von ESXi 6.5.x und 6.7.0 auf ESXi 7 mithilfe des ESXCLI-Befehls esxcli software profile update oder esxcli software profile install können fehlschlagen, da die ESXi-Bootbank möglicherweise die Größe des Image-Profils unterschreitet. In der ESXi Shell oder der PowerCLI Shell wird folgender Fehler angezeigt:

    [InstallationError]
 Die ausstehende Transaktion benötigt 244 MB freien Speicher, die maximal unterstützte Größe beträgt jedoch 239 MB.
 Weitere Informationen hierzu finden Sie in der Protokolldatei.

    Das Problem tritt auch auf, wenn Sie ein Upgrade des ESXi-Hosts mithilfe des ESXCLI-Befehls esxcli software vib update oder esxcli software vib install versuchen.

    Problemumgehung: Sie können das Upgrade in zwei Schritten durchführen, indem Sie ESXi-Hosts mit dem Befehl esxcli software profile update erst auf ESXi 6.7 Update 1 oder höher und dann auf ESXi 7.0 Update 1c aktualisieren. Alternativ können Sie ein Upgrade mithilfe eines ISO-Images und des vSphere Lifecycle Manager ausführen.

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