Versionshinweise zu VMware ESXi 6.0 Update 2

|

Aktualisiert am: 4. Mai 2016

ESXi 6.0 Update 2 | 15. März 2016 | ISO-Build 3620759

Ü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

  • Ethernet-Verbindung mit hoher Geschwindigkeit: ESXi 6.0 Update 2 unterstützt 25 G- und 50 G-Ethernet-Verbindungsgeschwindigkeiten.

  • VMware Host Client: Der VMware Host Client ist ein HTML5-Client, der für die Verbindungsherstellung zu einzelnen ESXi-Hosts und deren Verwaltung verwendet wird. Hiermit können Administrationsaufgaben ausgeführt werden, um Hostressourcen, wie beispielsweise virtuelle Maschinen, Netzwerke und Speicher zu verwalten. Der VMware Host Client ist außerdem für die Fehlerbehebung von einzelnen virtuellen Maschinen oder Hosts hilfreich, wenn vCenter Server und der vSphere Web Client nicht verfügbar sind. Weitere Informationen zum VMware Host Client finden Sie unter Versionshinweise zu VMware Host Client 1.0.

  • VMware Virtual SAN 6.2: VMware Virtual SAN 6.2 beinhaltet ESXi 6.0 Update 2. Weitere Informationen zu Virtual SAN finden Sie in den Versionshinweisen zu VMware Virtual SAN 6.2.

    In Virtual SAN wurde das neue VIB vsan in das ESXi-Image aufgenommen. Das neue VIB führt dazu, dass eine neue Abhängigkeit zum VIB esx-base hinzugefügt wurde, sodass das VIB vsan auf dem Host der Version 6.0 Update 2 installiert werden muss. Weitere Informationen finden Sie im Knowledgebase-Artikel 2144595.

  • Verbesserung bei vSphere APIs für E/A-Filter (VAIO):

    • ESXi 6.0 Update 2 unterstützt den E/A-Filter VASA Provider in einer reinen IPv6-Umgebung. Zusätzliche Informationen finden Sie im Abschnitt Behobene Probleme.

    • ESXi 6.0 Update 2 unterstützt die VMIOF-Versionen 1.0 und 1.1. Zusätzliche Informationen finden Sie im Abschnitt Behobene Probleme.

  • ESXi 6.0 Update 2 behebt Probleme, die im Abschnitt Behobene Probleme dokumentiert wurden.

Vorherige Versionen von ESXi 6.0

Die Funktionen und bekannten Probleme von ESXi 6.0 werden in den entsprechenden Versionshinweisen beschrieben. Versionshinweise für frühere Versionen von ESXi 6.0:

Internationalisierung

VMware ESXi 6.0 ist in den folgenden Sprachen verfügbar:

  • Englisch
  • Französisch
  • Deutsch
  • Japanisch
  • Koreanisch
  • Vereinfachtes Chinesisch
  • Spanisch
  • Traditionelles Chinesisch

Die Eingabe von Nicht-ASCII-Zeichen ist bei den Komponenten von VMware vSphere 6.0 nicht zulässig. Hierzu zählen vCenter Server, ESXi, der vSphere Web Client und der vSphere Client.

Kompatibilität

ESXi, vCenter Server und vSphere Web Client – Versionskompatibilität

Die VMware-Produkt-Interoperabilitätsmatrix liefert Details zur Kompatibilität aktueller und vorheriger Versionen von VMware vSphere-Komponenten, einschließlich ESXi, VMware vCenter Server, vSphere Web Client und optionaler VMware-Produkte. Prüfen Sie die VMware-Produkt-Interoperabilitätsmatrix ebenfalls auf Informationen zu unterstützten Management- und Backup-Agenten, bevor Sie ESXi oder vCenter Server installieren.

Der vSphere Web Client ist im Lieferumfang von vCenter Server enthalten. Den vSphere Client können Sie über das AutoAusführen-Menü von VMware vCenter installieren, das Bestandteil der ISO-Datei der Module ist.

Hardwarekompatibilität für ESXi

Um eine Liste der Prozessoren, Speichergeräte, SAN-Arrays und E/A-Geräte anzuzeigen, die mit vSphere 6.0 kompatibel sind, lesen Sie die Informationen zu ESXi 6.0 im VMware-Kompatibilitätshandbuch.

Gerätekompatibilität für ESXi

Verwenden Sie die Informationen zu ESXi 6.0 im VMware-Kompatibilitätshandbuch, um herauszufinden, welche Geräte mit ESXi 6.0 kompatibel sind.

Einige Geräte sind veraltet und werden nicht mehr von ESXi 6.0 unterstützt. Während des Upgrade-Vorgangs wird der Gerätetreiber auf dem ESXi 6.0-Host installiert. Der Gerätetreiber kann möglicherweise weiterhin in ESXi 6.0 verwendet werden, allerdings wird das Gerät von ESXi 6.0 nicht unterstützt. Eine Aufstellung der veralteten Geräte, die unter ESXi 6.0 nicht mehr unterstützt werden, finden Sie in KB 2087970.

Kompatibilität von ESXi zu Drittanbieter-Switches

VMware unterstützt jetzt Cisco Nexus 1000V mit vSphere 6.0. Für vSphere ist mindestens NX-OS 5.2(1)SV3(1.4) erforderlich. Weitere Informationen zu Cisco Nexus 1000V erhalten Sie in den Versionshinweisen von Cisco. Wie in früheren Versionen von vSphere wird auch hier der AVS-Modus von Cisco Nexus 1000V nicht unterstützt.

Kompatibilität von Gastbetriebssystemen für ESXi

Verwenden Sie die ESXi 6.0-Informationen im VMware-Kompatibilitätshandbuch, um herauszufinden, welche Gastbetriebssysteme mit vSphere 6.0 kompatibel sind.

Kompatibilität von virtuellen Maschinen für ESXi

Virtuelle Maschinen, die mit ESX 3.x und höher (Hardwareversion 4) kompatibel sind, werden von ESXi 6.0 unterstützt. Virtuelle Maschinen, die mit ESX 2.x und höher (Hardwareversion 3) kompatibel sind, werden nicht unterstützt. Wenn Sie solche virtuellen Maschinen unter ESXi 6.0 verwenden möchten, führen Sie ein Upgrade der VM-Kompatibilität durch. Weitere Informationen finden Sie in der vSphere-Upgrade-Dokumentation.

Installation und Upgrades für diese Version

Installationshinweise für diese Version

Weitere Informationen zum Installieren und Konfigurieren von ESXi und vCenter Server finden Sie im Handbuch zur Installation und Einrichtung von vSphere.

Wenngleich die Installation unkompliziert ist, sind viele der nachfolgenden Konfigurationsschritte äußerst wichtig. Lesen Sie folgende Dokumente:

Empfohlene Bereitstellungsmodelle für vSphere 6.0

VMware empfiehlt nur zwei Bereitstellungsmodelle:

  • vCenter Server mit eingebettetem Platform Services Controller. Dieses Modell wird empfohlen, wenn eine oder mehrere eigenständige vCenter Server-Instanzen in einem Datencenter bereitgestellt werden müssen. Die Replizierung zwischen vCenter Server mit eingebettetem Platform Services Controller-Modellen wird nicht empfohlen.

  • vCenter Server mit externem Platform Services Controller. Dieses Modell wird nur empfohlen, wenn mehrere vCenter Server-Instanzen miteinander verbunden werden müssen oder ein geringerer Speicherplatzbedarf für Platform Services Controller im Datencenter gewünscht wird. Die Replizierung zwischen diesen vCenter Server mit externem Platform Services Controller-Modellen wird unterstützt.

Weitere Informationen zum Installieren und Konfigurieren von vCenter Server finden Sie im Handbuch zur Installation und Einrichtung von vSphere.

Weitere Informationen zu der richtigen Reihenfolge, in der vSphere-Komponenten aktualisiert werden sollten, finden Sie unter Aktualisierungssequenz für vSphere 6.0 und dessen kompatible VMware-Produkte.

Anweisungen zur Installation und Konfiguration von vCenter Server finden Sie auch im KB-Artikel 2108548.

Informationen zum vCenter-Host-Betriebssystem

Weitere Informationen hierzu finden Sie im Knowledgebase-Artikel KB 2091273.

Backup und Wiederherstellung für vCenter Server- und vCenter Server Appliance-Bereitstellungen, die einen externen Platform Services Controller verwenden

Im Handbuch zur Installation und Einrichtung von vSphere werden Sie angewiesen, keine Backups und Wiederherstellungen für vCenter Server- und vCenter Server Appliance-Bereitstellungen auszuführen, die einen externen Platform Services Controller verwenden. Diese Aufgabe können Sie jedoch wie im KB-Artikel 2110294 beschrieben durchführen.

Migration vom eingebetteten Platform Services Controller zum externen Platform Services Controller

vCenter Server mit eingebettetem Platform Services Controller kann nicht automatisch zu vCenter Server mit externem Platform Services Controller migriert werden. Die Tests für dieses Migrationsdienstprogramm sind noch nicht abgeschlossen.

Legen Sie vor der Installation von vCenter Server Ihre gewünschte Bereitstellungsoption fest. Wenn mehrere vCenter Server-Instanzen für die Replizierungskonfiguration erforderlich sind, stellen Sie stets vCenter mit externem Platform Services Controller bereit.

Migrieren von Drittanbieter-Lösungen

Weitere Informationen zum Upgrade mit Drittanbieter-Anpassungen finden Sie in der vSphere-Upgrade-Dokumentation. Weitere Informationen zur Verwendung von Image Builder zur Erstellung einer benutzerdefinierten ISO-Datei finden Sie im Installations- und Einrichtungshandbuch für vSphere.

Upgrades und Installationen nicht zulässig für nicht unterstützte CPUs

vSphere 6.0 unterstützt nur nach dem Juni 2006 (drittes Quartal) veröffentlichte Prozessoren. Im Vergleich zu den von vSphere 5.x unterstützten Prozessoren werden die folgenden Prozessoren von vSphere 6.0 nicht mehr unterstützt:

  • AMD Opteron 12xx-Serie
  • AMD Opteron 22xx-Serie
  • AMD Opteron 82xx-Serie

Während einer Installation oder eines Upgrades wird eine Prüfung auf die Kompatibilität der Host-CPU mit vSphere 6.0 durchgeführt. Falls Ihre Hosthardware nicht kompatibel ist, wird ein violetter Bildschirm mit einer Inkompatibilitätsmeldung angezeigt und der Installationsvorgang für vSphere 6.0 wird beendet.

Upgrade-Hinweise für diese Version

Informationen zur Durchführung eines Upgrades von vCenter Server und ESX/ESXi-Hosts finden Sie im vSphere-Upgrade-Handbuch.

Open Source-Komponenten für VMware vSphere 6,0

Informationen zu Copyright und Lizenzen für die Open Source-Softwarekomponenten, die im Lieferumfang von vSphere 6.0 enthalten sind, finden Sie unter http://www.vmware.com. Sie müssen sich bei Ihrem My VMware-Konto anmelden. Anschließend wählen Sie im Menü Downloads die Option vSphere aus. Auf der Registerkarte Open Source können Sie auch die Quelldateien für jede GPL-, LGPL- oder vergleichbare Lizenz herunterladen, die die Verfügbarkeit des Quellcodes bzw. dessen Modifizierung für die jeweils neueste vorliegende vSphere-Version erfordert.

Hinweise zur Produktunterstützung

  • vCenter Server-Datenbank: Oracle 11g und 12c als externe Datenbank für vCenter Server Appliance wird in vSphere 6.0 nicht mehr unterstützt. VMware unterstützt auch weiterhin Oracle 11g und 12c als externe Datenbank in vSphere 6.0. VMware wird Orace 11g und 12c in einer zukünftigen Hauptversion nicht mehr als externe Datenbank für vCenter Server Appliance unterstützen.

  • vSphere Web Client: Die Option Speicherberichte auf der Registerkarte Überwachen ist im vSphere 6.0 Web Client nicht mehr verfügbar.

  • vSphere Client: Die Registerkarte Speicheransichten ist im vSphere 6.0 Web Client nicht mehr verfügbar.

In dieser Version enthaltene Patches

Diese Version enthält alle Bulletins für ESXi, die vor dem Veröffentlichungsdatum dieses Produkts zur Verfügung standen. Weitere Informationen zu den einzelnen Bulletins finden Sie auf der VMware-Seite Patches herunterladen.

Patch-Version ESXi600-Update02 enthält die folgenden einzelnen Bulletins:

ESXi600-201603201-UG: Aktualisiert esx-base, vsanhealth, vsan vib
ESXi600-201603202-UG: Aktualisiert misc-drivers, xhci-xhci, andere
ESXi600-201603203-UG: Aktualisiert ESXi 6.0 esx-tboot vib
ESXi600-201603204-UG-BG: Aktualisiert ESXi 6.0 tools-light vib
ESXi600-201603205-UG-BG: Aktualisiert ESXi 6.0 esx-ui vib
ESXi600-201603206-UG-BG: Aktualisiert ESXi 6.0 nvme vib
ESXi600-201603207-UG-BG: Aktualisiert ESXi 6.0 net-vmxnet3 vib
ESXi600-201603208-UG-BG: Aktualisiert ESXi 6.0 sata-ahci vib

Patch-Version ESXi600-Update02 (Security-only build) enthält die folgenden einzelnen Bulletins:

ESXi600-201603101-SG: Aktualisiert ESXi 6.0 esx-base vib
ESXi600-201603102-SG: Aktualisiert ESXi 6.0 tools-light vib

Patch-Version ESXi600-Update02 enthält die folgenden Image-Profile:

ESXi-6.0.0-20160302001-standard
ESXi-6.0.0-20160302001-no-tools

Patch-Version ESXi600-Update02 (Security-only build) enthält die folgenden Image-Profile:

ESXi-6.0.0-20160301001s-standard
ESXi-6.0.0-20160301001s-no-tools

Weitere Informationen zur Klassifizierung von Patches und Updates finden Sie unter KB 2014447.

Behobene Probleme

Die behobenen Probleme werden in folgende Kategorien unterteilt.



CIM- und API-Probleme
  • Überwachung der Hardware schlägt bei Verwendung der Drittanbietersoftware ServerView RAID Manager möglicherweise fehl
    Es kann sein, dass die Überwachung des Hardwarestatus fehlschlägt, wenn Sie die Drittanbietersoftware ServerView RAID Manager verwenden. Aufgrund einer Wettlaufsituation reagiert sfcb-vmware_aux nicht mehr.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Registerkarte „Hardwarestatus“ reagiert nicht mehr und es wird eine Fehlermeldung angezeigt
    Die Registerkarte „Hardwarestatus“ reagiert möglicherweise nicht mehr, wenn in Word auf das FRU-Gerät zugegriffen wird und der Wert read_cnt größer oder gleich 1 ist. Eine Fehlermeldung ähnlich der folgenden wird in die Protokolldatei syslog.log geschrieben:

    Dropped response operation details -- nameSpace: root/cimv2, className: OMC_RawIpmiEntity, Type: 0\

    Dieses Problem wurde in der vorliegenden Version behoben.

Sonstige Probleme
  • Hostd reagiert nicht mehr, wenn esxcli-Befehle mit PowerCLI ausgeführt werden
    Hostd reagiert möglicherweise nicht mehr, wenn Sie esxcli-Befehle mit PowerCLI ausführen. Dies führt zu Arbeitsspeicherverlust und Arbeitsspeichernutzung über den festgelegten Grenzwert hinaus. Eine Fehlermeldung ähnlich der folgenden wird in die Protokolldatei hostd.log geschrieben:

    YYYY-MM-DDTHH:MM:SS.135Z [nnnnnnnn error 'UW Memory checker'] Current value 646016 exceeds hard limit 643993. Shutting down process.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Auf dem ESXi-Host tritt ein violetter Diagnosebildschirm mit mehreren CMCI-Meldungen (Correctable Machine Check Interrupt) auf

    Der ESXi-Host schlägt möglicherweise mit einem violetten Diagnosebildschirm aufgrund einer nicht reagierenden CPU als Ergebnis von mehreren CMCIs in der Datei vmkernel.log innerhalb einer kurzen Zeit fehl. Auf dem violetten Diagnosebildschirm werden Einträge angezeigt, die den folgenden ähneln:

    PCPU <N>: no heartbeat (2/2 IPIs received)
    0xXXXXXXXXXXXX:[0xXXXXXXXXXXXX]MCEReapMCABanks@vmkernel#nover+0x195
    0xXXXXXXXXXXXX:[0xXXXXXXXXXXXX]MCEHandleCMCI@vmkernel#nover+0xb4
    0xXXXXXXXXXXXX:[0xXXXXXXXXXXXX]IRQ_DoInterrupt@vmkernel#nover+0x33e
    0xXXXXXXXXXXXX:[0xXXXXXXXXXXXX]IDT_IntrHandler@vmkernel#nover+0x12b 0xXXXXXXXXXXXX:[0xXXXXXXXXXXXX]gate_entry@vmkernel#nover+0x64
    0xXXXXXXXXXXXX:[0xXXXXXXXXXXXX]LFQueue_Dequeue@vmkernel#nover+0x59
    0xXXXXXXXXXXXX:[0xXXXXXXXXXXXX]MCEBottomHalf@vmkernel#nover+0x39
    0xXXXXXXXXXXXX:[0xXXXXXXXXXXXX]BH_DrainAndDisableInterrupts@vmkernel#nover+0xf3
    0xXXXXXXXXXXXX:[0xXXXXXXXXXXXX]VMMVMKCall_Call@vmkernel#nover+0x2c6


    In der Datei vmkernel.log werden Einträge ähnlich den folgenden protokolliert:

    cpu1:33127)MCE: 1118: cpu1: MCA error detected via CMCI (Gbl status=0x0): Restart IP: invalid, Error IP: invalid, MCE in progress: no.
    cpu1:33127)MCE: 231: cpu1: bank9: MCA recoverable error (CE): "Memory Controller Scrubbing Error on Channel 0."
    cpu1:33127)MCE: 222: cpu1: bank9: status=0xXXXXXXXXXXXXXXXX: (VAL=1, OVFLW=0, UC=0, EN=0, PCC=0, S=0, AR=0), ECC=no, Addr:0xXXXXXXXXXXXXXXXX (valid), Misc:0x8c3589300 (valid)

    Dieses Problem wurde in der vorliegenden Version behoben.

Netzwerkprobleme
  • Die vSISH-Statistik enthält umfangreiche Paketausfälle
    Die VSISH-Statistik enthält umfangreiche falsch positive Paketausfälle aufgrund von Ganzzahlüberlauf.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Neu Ein ESXi-Host mit der in der VXLAN-Umgebung aktivierten NetFlow-Funktion schlägt möglicherweise fehl und führt zu einem violetten Diagnosebildschirm
    Ein ESXi-Host mit der in der VXLAN-Umgebung aktivierten NetFlow-Funktion schlägt möglicherweise fehl und führt zu einem violetten Diagnosebildschirm mit Einträgen ähnlich den folgenden:

    @BlueScreen: PANIC bora/vmkernel/main/dlmalloc.c:4923 - Nutzungsfehler in dlmalloc
    PTEs:0xnnnnnnnn;0xnnnnnnnn;0x0;
    0xnnnnnnnn:[0xnnnnnnnn]PanicvPanicInt@vmkernel#nover+0x37e
    ....
    ....
    0xnnnnnnnn:[0xnnnnnnnn]Net_AcceptRxList@vmkernel#nover+0x115


    Dieses Problem wurde in der vorliegenden Version behoben.
  • In einer vDS-Umgebung schlägt vMotion nach dem Entfernen einer Linkzusammenfassungsgruppe (LAG) fehl
    In einer vSphere Distributed Switch (vDS)-Umgebung schlägt vMotion nach dem Entfernen von Linkzusammenfassungsgruppen (Link Aggregation Groups, LAG) fehl. Der vMotion-Kompatibilitätsassistent zeigt eine Fehlermeldung an, die so oder ähnlich lautet:

    Aktuell verbundene Netzwerkschnittstelle 'Netzwerkadapter 1' verwendet Netzwerk 'DSwitchName', auf das nicht zugegriffen werden kann.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der FCoE-Link (Fibre Channel over Ethernet) wird beim Abrufen des ESXi-Protokollpakets möglicherweise unterbrochen
    Beim Abrufen des ESXi-Protokollpakets aktiviert der lldpnetmap-Befehl LLDP. LLDP kann allerdings nur auf den Modus „Beide“ festgelegt werden, und die LLDP-Pakete werden vom ESXi-Host gesendet. Die Pakete verursachen möglicherweise eine Unterbrechung des FCoE-Links.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Hostd-Protokolle werden mehrmals in schneller Abfolge mit einer Fehlermeldung überflutet
    Hostd-Protokolle werden mit einer Fehlermeldung, die so oder ähnlich lautet, mehrmals in schneller Abfolge überflutet, wodurch die Protokolle extrem anwachsen:

    Failed to get vsi stat set: Sysinfo error on operation returned status : Not found. Detaillierte Fehlerinformationen finden Sie im VMkernel-Protokoll.

    Dieses Problem wurde in der vorliegenden Version behoben.


Sicherheitsprobleme
  • Update des NTP-Pakets
    Das ESXi NTP-Paket wurde auf Version 4.2.8p4 aktualisiert.

  • Update der zlib-Version
    Die zlib-Version wurde auf Version 1.2.8 aktualisiert.

  • Update der libPNG-Bibliothek
    Die libPNG-Bibliothek wurde auf libpng-1.6.20 aktualisiert.

  • Update der OpenSSH-Version
    Die OpenSSH-Version wurde auf Version 7.1p1 aktualisiert.

  • E/A-Filter VASA Provider schließt Initialisierung aufgrund eines fehlenden Zeilenvorschubs in der Zertifikatsdatei nicht ab
    Der E/A-Filter VASA Provider liest und kombiniert die Dateien für das Zertifikat und den privaten Schlüssel zum Generieren der PEM-Datei. Wenn das Zertifikat nicht mit einer neuen Zeile endet, wird eine ungültige PEM-Datei erstellt, die von OpenSSL nicht erkannt wird. Dies führt wiederum zu einem Fehler, wodurch die Initialisierung von iofiltervp verhindert wird.

    Dieses Problem wurde in der vorliegenden Version behoben.

Serverkonfigurationsprobleme
  • Active Directory-Aktivitäten können nach dem Hinzufügen des ESXi-Hosts zu Active Directory nicht ausgeführt werden
    Nachdem Sie den ESXi-Host zu Active Directory hinzugefügt haben, können Sie möglicherweise Active Directory-Aktivitäten wie beispielsweise das Hinzufügen von Active Directory-Benutzern aufgrund der Berechtigung nach dem Hinzufügen von Benutzern aus verschiedenen vertrauenswürdigen Domänen, das Anmelden usw. nicht ausführen. In der Protokolldatei /var/log/likewise.log finden Sie Einträge ähnlich der folgenden:

    20150522181259:DEBUG:lsass:LsaJoinDomain():join.c:380: Error code: 40286 (symbol: LW_ERROR_LDAP_SERVER_DOWN)

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Neueste PCI-IDs hinzugefügt
    Die Datei „pci.ids“ wurde mit den neuesten PCI-IDs aktualisiert.

  • Der ESXi-Host wechselt bei einem Zuteilungsfehler des Ressourcenpools nicht in den Wartungsmodus
    Der ESXi-Host wechselt bei einem Zuteilungsfehler des Ressourcenpools nicht in den Wartungsmodus.

    Dieses Problem wurde in der vorliegenden Version behoben.

Speicherprobleme
  • ESXi-mClock-E/A-Scheduler funktioniert nicht wie erwartet
    Der ESXi-mClock-E/A-Scheduler begrenzt die E/As nicht mit einer geringeren Last, selbst nachdem Sie den IOPS-Wert der VM mit dem vSphere Client geändert haben.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Verzögerte Aktualisierung des Pfadstatus von vorhandenen LUNs
    Gelegentlich können geringfügige Verzögerungen bei der Aktualisierung des LUN-Pfadstatus auftreten, da eine interne API keinen Scanaufruf für die vorhandenen LUNs ausstellt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Versuche, mehrere Appstacks anzufügen, nehmen sehr viel Zeit in Anspruch
    Beim Versuch, einer virtuellen Maschine mehrere Appstacks oder beschreibbare Volumes hinzuzufügen, tritt bei der Neukonfiguration der virtuellen Maschine eine Verzögerung auf.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Eine Festplatte, die größer als 2 TB ist, kann auf Virtual Volumes unter Verwendung des VDDK HotAdd-Transportmodus nicht geöffnet werden
    Versuche, den VDDK HotAdd-Transportmodus (Virtual Disk Development Kit) zu verwenden und Festplatten mit einer Größe von mehr als 2 TB in einem Datenspeicher für Virtual Volumes im laufenden Betrieb hinzuzufügen und zu öffnen, schlagen fehl.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Beim Installieren von E/A-Filtern im Rahmen des IPv6-Setups werden die zugehörigen Funktionen nicht für VPXD veröffentlicht
    Nach der erfolgreichen Installation eines E/A-Filters über die VIM API kann der installierte Filter die Filterfunktionen nicht für VPXD veröffentlichen. Sie können das Filterprofil keinen Festplatten anfügen, da für die speicherrichtlinienbasierte Verwaltung (Storage Policy Based Management, SPBM) von VMware vSphere keine Funktionen veröffentlicht wurden.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • ESXi 6.0 Update 2 unterstützt VMIOF, Version 1.0 und 1.1

    ESXi 6.0 Update 2 unterstützt VMIOF, Version 1.0 und 1.1. Das VIB-Tag vmiof_1_1_0_0 wurde zur Liste der unterstützten VIB-Tags im ESXi-Basis-Image hinzugefügt. Dadurch können Sie Filter erstellen, die nur mit ESXi 6.0 Update 2 und höher kompatibel sind, da die in ESXi 6.0 Update 2 devkit erstellten Filter nur auf Hosts mit ESXi 6.0 Update 2 oder höher installiert werden.

    In ESXi 6.0 Update 2 erstellte Filter funktionieren auch mit Hosts mit ESXi 6.0 Update ohne Probleme.

  • Nach dem Upgrade von Hosts in einem Cluster mit Virtual SAN auf ESXi 6.0 Update 1b melden einige Hosts im Cluster inkorrekterweise eine Warnung
    Nach dem Upgrade der Virtual SAN-Umgebung auf ESXi 6.0 Update 1b meldet vCenter Server inkorrekterweise eine Warnung ähnlich der folgenden auf der Registerkarte Übersicht im vSphere Web Client, und der ESXi-Host zeigt ein Benachrichtigungsdreieck an:

    Der Host kann nicht mit allen anderen Knoten im Cluster mit aktiviertem Virtual SAN kommunizieren

    Dieses Problem wurde in der vorliegenden Version behoben.

Upgrade- und Installationsprobleme
  • Die skriptbasierte ESXi 6.x-Installation warnt fälschlicherweise davor, dass USB- oder SD-Medien VMFS nicht unterstützen, selbst wenn in der Kickstart-Datei der Parameter --novmfsondisk verwendet wird
    Wenn Sie die skriptbasierte Installation zum Installieren von ESXi 6.0 auf einem Datenträger verwenden, der als USB- oder SD-Medium erkannt wird, zeigt das Installationsprogramm möglicherweise die folgende Warnmeldung an:

    Die im Installationsprogramm angegebene Festplatte (<Festplatten-ID>) unterstützt VMFS nicht.

    Diese Meldung wird selbst dann angezeigt, wenn Sie den Parameter --novmfsondisk für den Befehl „install“ in der Kickstart-Datei angegeben haben.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Installiertes Live-VIB funktioniert möglicherweise nicht ordnungsgemäß und geht nach einem Neustart verloren
    Bei der Live-VIB-Installation werden jumpstart-Plug-Ins, rc-Skripte und Dienstskripte des Live-VIB ausgeführt. Diese Plug-Ins und Skripte melden möglicherweise einen Fehler bzw. eine Ausnahme. Die Fehler und/oder Ausnahmen beenden möglicherweise den Installationsvorgang und verursachen ein unerwartetes Verhalten, z. B. dass das Live VIB als im System installiert gemeldet wird, aber nicht ordnungsgemäß funktioniert. Das Live-VIB wird außerdem nach einem Neustart nicht gespeichert.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Live-VIB-Installation schlägt möglicherweise fehl
    Bei der Live-VIB-Installation erstellt esximage Staging-Daten für Live-VIB. Wenn Sie den Befehl esxcli-Befehl VIB get und list gleichzeitig ausführen, werden die Staging-Daten möglicherweise gelöscht und die Live-VIB-Installation schlägt fehl.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Versuche, vMotion auszuführen, schlagen nach einem Upgrade von ESXi 5.0 oder 5.1 auf 6.0 Update 1 und höheren Versionen möglicherweise fehl

    Versuche, vMotion auszuführen, schlagen nach einem Upgrade von ESXi 5.0 oder 5.1 auf 6.0 Update 1 oder höhere Versionen möglicherweise fehl. Eine Fehlermeldung ähnlich der folgenden wird in die Datei vmware.log geschrieben:

    failed to add memory page 0x201 to VM: Bad parameter

    Weitere Details finden Sie im Knowledgebase-Artikel 2143943.

    Dieses Problem wurde in der vorliegenden Version behoben.

Probleme bei vCenter Server, vSphere Web Client und vSphere Client
  • Verbindung der VM-Konsole zu den eingeschalteten VMs kann in vSphere Web Access nicht hergestellt werden
    Wenn Sie einen ESXi-Host mit eingeschalteten VMs zu vCenter Server hinzufügen oder den Host auf einen anderen vCenter Server umstellen, kann vSphere Web Access die Verbindung zwischen der Konsole und den VMs nicht herstellen. Fehlermeldungen ähnlich der folgenden werden bei diesem Problem angezeigt:

    Fehlermeldung in der Webkonsole:

    Die Konsole wurde getrennt. Schließen Sie dieses Fenster und starten Sie die Konsole neu zum Neuverbinden.

    Fehlermeldung in der eigenständigen VMware Remote Console:

    Fehler beim Initialisieren der SSL-Sitzung mit dem Remotehost.

    Fehlermeldung in der VI Client-Konsole:

    Verbindung mit mks konnte nicht hergestellt werden: interner Fehler

    Fehlermeldung in der Protokolldatei vmware.log:

    SOCKET 6 (150) Error during authd-VNC negotiation: (1) Asyncsocket error.

    Dieses Problem wurde in der vorliegenden Version behoben.

VM-Verwaltungsprobleme
  • Hostd reagiert auf Hosts mit 3D-Beschleunigung gelegentlich nicht mehr
    Hostd reagiert möglicherweise auf ESXi-Hosts mit 3D-Beschleunigung gelegentlich nicht mehr. Meldungen ähnlich den folgenden werden in die Hostd-Protokolldatei geschrieben:

    Crash Report build=2809209
    Signal 11 received, si_code 1, si_errno 0
    Bad access at 34
    eip 0xnnnnnnn esp 0xnnnnnnnn ebp 0xnnnnnnnn
    eax 0xnnnnnnnn ebx 0xnnnnnnn ecx 0x47 edx 0x0 esi 0x30 edi 0xnnnnnnnn
    Dieses Problem wurde in der vorliegenden Version behoben.

  • Für von dauerhaftem Geräteverlust betroffene virtuelle Maschinen wird kein Failover durchgeführt
    Virtuelle Maschinen, die von einem dauerhaften Geräteverlust (Permanent Device Loss, PDL) betroffen sind, werden auf einem Failover-Host nicht eingeschaltet. Die VM verbleibt in einem ungültigen Zustand und es wird eine Warnmeldung angezeigt, dass die Hardwareversion 1 nicht erkannt wird, wenn bei einem der Speicher-VMs ein dauerhafter Geräteverlust vorliegt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Für den Leistungsindikator „cpu.system.summation“ einer VM wird stets „0“ angezeigt
    VM-Leistungsmesswerte werden nicht ordnungsgemäß angezeigt, da für den Leistungsindikator cpu.system.summation einer VM stets „0“ angezeigt wird.

    Dieses Problem wurde in der vorliegenden Version behoben.

Probleme bei vMotion und Storage vMotion
  • Hostd reagiert möglicherweise nicht mehr, wenn der ESXi-Host mit 3D-Hardware in den Wartungsmodus versetzt wird, und vMotion wird ausgelöst
    Wenn Hostd auf einem ESXi-Host mit 3D-Hardware eine Änderung des Betriebszustands einer VM registriert, wird eine Funktion zum Überprüfen des VM-Status aufgerufen. Für vMotion wird die Quell-VM ausgeschaltet, bevor ihre Registrierung auf dem Quellhost aufgehoben wird, die ManagedObjectNotFound-Ausnahme wird angezeigt und Hostd reagiert möglicherweise nicht mehr.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • vMotion kann in Kombination mit VMs, die zwei virtuelle Festplatten mit 2 TB aufweisen, nicht ausgeführt werden
    Versuche, vMotion in Kombination mit ESXi 6.0-VMs auszuführen, die zwei in ESXi 5.0 erstellte virtuelle Festplatten mit 2 TB aufweisen, schlagen mit Fehlermeldungen ähnlich der folgenden fehl, die in die Protokolldatei vpxd.log geschrieben werden:

    2015-09-28T10:00:28.721+09:00 info vpxd[xxxxx] [Originator@6876 sub=vpxLro opID=xxxxxxxx-xxxxxxxx-xx] [VpxLRO] -- BEGIN task-919 -- vm-281 -- vim.VirtualMachine.relocate -- xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx(xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
    2015-09-28T10:00:28.727+09:00 info vpxd[xxxxx] [Originator@6876 sub=vpxLro opID=xxxxxxxx-xxxxxxxx-xx-xx] [VpxLRO] -- BEGIN task-internal-343729 -- -- VmprovWorkflow --
    ....

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Bei Ausführung von Storage vMotion nur für eine Festplatte reagiert die virtuelle Maschine nicht mehr oder wechselt in den ausgeschalteten Status
    Wenn Sie Storage vMotion nur für eine Festplatte ausführen, reagiert die virtuelle Maschine möglicherweise nicht mehr oder wechselt in den ausgeschalteten Status, da mehrere Threads auf dieselben Daten zuzugreifen versuchen.

    Dieses Problem wurde in der vorliegenden Version behoben.

Probleme bei VMware Tools

Bekannte Probleme

Die bekannten Probleme in ESXi 6.0 werden wie folgt gruppiert:

Neue bekannte Probleme, die in dieser Version dokumentiert werden, werden als Neues Problem hervorgehoben.

Installationsprobleme
  • DNS-Suffix wird möglicherweise selbst nach einer Änderung der Standardkonfiguration in DCUI beibehalten
    Ein ESXi-Host wird möglicherweise automatisch beim ersten Starten mit der Standard-DNS + DNS-Suffix konfiguriert, wenn er auf einem von einem DHCP-Server bedienten Netzwerk bereitgestellt wird. Wenn Sie versuchen, das DNS-Suffix zu ändern, entfernt die DCUI das vorhandene DNS-Suffix nicht, sondern fügt einfach das neue angegebene Suffix hinzu.

    Problemumgehung: Legen Sie beim Konfigurieren des DNS-Hostnamens der Zeugen-OVF den vollqualifizierten Domänennamen „DNS-Hostname“ so fest, dass das korrekte DNS-Suffix angehängt wird. Dann können Sie nicht erwünschte DNS-Suffixe im Feld „Benutzerdefiniertes DNS-Suffix“ entfernen.

  • Die Benutzerprozesse des VMware Tools-Diensts werden nach der Installation des neuesten VMware Tools-Pakets möglicherweise nicht unter dem Linux-Betriebssystem ausgeführt
    Unter dem Linux-Betriebssystem treten möglicherweise Upgrade-/Installationsprobleme mit VMware Tools auf oder die Benutzerprozesse des VMware Tools-Diensts (vmtoolsd) werden möglicherweise nach der Installation des neuesten VMware Tools-Pakets nicht ausgeführt. Dieses Problem tritt auf, wenn Sie eine ältere glibc-Version als Version 2.5 verwenden, wie beispielsweise SLES10sp4.

    Problemumgehung: Führen Sie ein Upgrade von Linux-glibc auf Version 2.5 oder höher durch.

Upgrade-Probleme

Lesen Sie auch den Abschnitt „Installationsprobleme“ in den Versionshinweisen. Viele Installationsprobleme können sich auch auf den Upgrade-Vorgang auswirken.

  • Neues Problem Versuche, mit dem Befehl „esxcli software vib update“ von ESXi 6.x auf 6.0 Update 2 zu aktualisieren, schlagen fehl
    Versuche, mit dem Befehl esxcli software vib update von ESXi 6.x auf 6.0 Update 2 zu aktualisieren, schlagen mit Fehlermeldungen ähnlich den folgenden fehl:

    „[DependencyError]
    VIB VMware_bootbank_esx-base_6.0.0-2.34.xxxxxxx requires vsan << 6.0.0-2.35, but the requirement cannot be satisfied within the ImageProfile.
    VIB VMware_bootbank_esx-base_6.0.0-2.34.xxxxxxx requires vsan >= 6.0.0-2.34, but the requirement cannot be satisfied within the ImageProfile."


    Das Problem tritt aufgrund der Einführung eines neuen Virtual SAN VIB auf, das eine gegenseitige Abhängigkeit mit dem esx-base VIB aufweist. Der Befehl esxcli software vib update aktualisiert nur die bereits im System installierten VIBs.

    Problemumgehung: Führen Sie zur Umgehung dieses Problems den Befehl esxcli software profile update aus, wie im folgenden Beispiel gezeigt:

    esxcli software profile update -d /vmfs/volumes/datastore1/update-from-esxi6.0-6.0_update02.zip -p ESXi-6.0.0-20160302001-standard

  • Neues Problem Versuche, ein Upgrade für ESXi durchzuführen, schlagen möglicherweise fehl, wenn die ESXi-Partitionstabelle eine Coredump-Partition enthält
    Wenn ESXi auf einer SD-Karte anhand des Befehls 'dd' bereitgestellt wird (Bereitstellung von ESXi mit dem .dd-Image, das über den VMware-Befehl esxiso2dd erstellt wurde), wird während des ersten Startvorgangs von ESXi eine Coredump-Partition als eine zweite Partition erstellt. Aus diesem Grund schlägt das ESXi-Upgrade fehl.

    Problemumgehung: Um dieses Problem zu beheben, müssen Sie die zweite Coredump-Partition manuell entfernen. Weitere Informationen hierzu finden Sie im Knowledgebase-Artikel 2144074.

  • Aktualisiert SSLv3 bleibt nach dem Upgrade einer früheren Version von vSphere 6.0 auf vSphere 6.0 Update 1 oder höher auf Auto Deploy aktiviert
    Wenn Sie ein Upgrade von einer früheren vSphere 6.0-Version auf vSphere 6.0 Update 1 oder höher ausführen, bleibt das SSLv3-Protokoll auf Auto Deploy aktiviert.

    Problemumgehung: Führen Sie die folgenden Schritte aus, um SSLv3 mithilfe von PowerCLI-Befehlen zu deaktivieren:

    1. Führen Sie den folgenden Befehl aus, um eine Verbindung mit vCenter Server herzustellen:

      PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> Connect-VIServer -Server <FQDN_hostname or IP Address of vCenter Server>

    2. Führen Sie den folgenden Befehl aus, um den aktuellen sslv3-Status zu überprüfen:

      PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> Get-DeployOption

    3. Führen Sie den folgenden Befehl aus, um sslv3 zu deaktivieren:

      PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> Set-DeployOption disable-sslv3 1

    4. Starten Sie den Auto Deploy-Dienst neu, um die Änderung zu übernehmen.

  • Die Gerätenummer des Fibre-Channel-HBA wird nach dem Upgrade von ESXi 5.5.x auf 6.0 möglicherweise geändert

    Beim Upgrade von ESXi 5.5.x auf 6.0 kommt es gelegentlich vor, dass die Gerätenummer des Fibre-Channel-Hostbus-Adapters geändert wird. Dies passiert, wenn Sie den Befehl esxcli storage core adapter list verwenden.

    Beispiel: Vor dem ESXi-Upgrade sehen die Gerätenummern eines Fibre-Channel-HBA etwa so aus:

    HBA-Name
    ––––––––
    vmhba3
    vmhba4
    vmhba5
    vmhba66

    Nach dem ESXi-6.0-Upgrade können sie so aussehen:

    HBA-Name
    ––––––––
    vmhba64
    vmhba65
    vmhba5
    vmhba6

    Das Beispiel verdeutlicht die willkürliche Änderung, die auftreten kann, wenn Sie den Befehl esxcli storage core adapter list verwenden: Die Gerätealiasnummern „vmhba2“ und „vmhba3“ werden in „vmhba64“ und „vmhba65“ geändert, während die Gerätenummern „vmhba5“ und „vmhba6“ nicht geändert werden. Mit dem Befehl esxcli hardware pci list werden die Gerätenummern beim Upgrade allerdings nicht geändert.

    Dieses Problem wird nicht von VMware verursacht und betrifft Sie möglicherweise auch gar nicht. ESXi zeigt die Aliasnamen von Geräten zwar an, greift aber für keine Vorgänge darauf zurück. Sie können einen Geräte-Aliasnamen jederzeit im Hostprofil zurücksetzen. Informationen dazu finden Sie in der Produktdokumentation und den Knowledgebase-Artikeln von VMware.

    Problemumgehung: Keine.

  • Active Directory-Einstellungen werden nach dem Upgrade nicht beibehalten
    Die auf dem ESXi-Host vor dem Upgrade konfigurierten Active Directory-Einstellungen werden nach dem Upgrade des Hosts auf ESXi 6.0 nicht beibehalten.

    Problemumgehung: Fügen Sie den Host nach dem Upgrade zur Active Directory-Domäne hinzu, falls es sich vor dem Upgrade um die ESXi-Version 5.1 oder höher handelt. Fügen Sie den Host nach dem Upgrade nicht zur Active Directory-Domäne hinzu, falls es sich vor dem Upgrade um die ESXi-Version 5.0.x handelt.

  • Nach dem Upgrade der ESXi-Hosts auf Version 6.0 sind die zuvor zur Domäne hinzugefügten Hosts nicht mehr in der Domäne vorhanden
    Beim erstmaligen Upgrade von vSphere 5.5 auf vSphere 6.0 wird die Active Directory-Konfiguration nicht beibehalten.

    Problemumgehung: Fügen Sie die Hosts nach dem Upgrade erneut zur vCenter Server-Domäne hinzu:

    1. Fügen Sie die Hosts zu vCenter Server hinzu.

    2. Fügen Sie die Hosts zur Domäne hinzu (z. B. „example.com“).

    3. Führen Sie ein Upgrade für alle Hosts auf ESXi 6.0 durch.

    4. Fügen Sie einen Host, für den gerade ein Upgrade durchgeführt wurde, manuell zur Domäne hinzu.

    5. Extrahieren Sie das Hostprofil und deaktivieren Sie alle anderen Profile mit Ausnahme von „Authentifizierung“.

    6. Wenden Sie das manuell hinzugefügte Hostprofil auf die anderen Hosts an, für die gerade ein Upgrade durchgeführt wurde.

  • Zuvor ausgeführter VMware ESXi Dump Collector-Dienst wird nach dem Upgrade von vCenter Server für Windows standardmäßig auf „Deaktiviert“ zurückgesetzt
    Beim Upgrade-Vorgang wird VMware vSphere ESXi Dump Collector 6.0 im Rahmen einer Gruppe optionaler Dienste für vCenter Server installiert. Sie müssen den VMware vSphere ESXi Dump Collector-Dienst manuell aktivieren, um ihn in Verbindung mit vCenter Server 6.0 für Windows verwenden zu können.

    Problemumgehung: Lesen Sie in der VMware-Dokumentation nach oder suchen Sie in der VMware-Knowledgebase nach Informationen zum Aktivieren und Ausführen optionaler Dienste in vCenter Server 6.0 für Windows.

    Aktivieren Sie den VMware vSphere ESXi Dump Collector-Dienst im Betriebssystem:

    1. Wählen Sie in der Systemsteuerung Verwaltung aus und doppelklicken Sie auf Dienste.

    2. Klicken Sie mit der rechten Maustaste auf VMware vSphere ESXi Dump Collector und wählen Sie Starttyp bearbeiten aus.

    3. Legen Sie Starttyp auf Automatisch fest.

    4. Klicken Sie mit der rechten Maustaste auf VMware vSphere ESXi Dump Collector und wählen Sie Starten aus.

    Dienst-Starttyp ist auf „Automatisch“ festgelegt, und der Dienst wird ausgeführt.

Probleme bei vCenter Single Sign-On und der Zertifikatsverwaltung
  • Kein Zugriff auf die VM-Konsole nach dem Upgrade des SSL-Zertifikats des ESXi-Hosts
    Ein Zertifikatvalidierungsfehler kann auftreten, wenn Sie ein Upgrade des von einem ESXi-Host verwendeten SSL-Zertifikats durchführen und anschließend auf die VM-Konsole einer beliebigen VM zuzugreifen versuchen, die beim Ersetzen des Zertifikats ausgeführt wurde. Dies liegt daran, dass das alte Zertifikat zwischengespeichert wird und jede neue Konsolenverbindung aufgrund dieser Nichtübereinstimmung abgelehnt wird.
    Die Konsolenverbindung kann möglicherweise hergestellt werden, beispielsweise wenn das alte Zertifikat anderweitig überprüft werden kann, aber die Konsolenverbindung kann nicht garantiert werden. Vorhandene VM-Konsolenverbindungen sind davon nicht betroffen. Dieses Problem kann jedoch auftreten, wenn die Konsole während der Zertifikatsersetzung ausgeführt wurde, beendet wurde und dann neu gestartet wurde.

    Problemumgehung: Versetzen Sie den Host in den Wartungsmodus oder halten Sie alle VMs an bzw. schalten Sie alle VMs aus. Nur ausgeführte VMs sind davon betroffen. Es empfiehlt sich, alle Upgrades von SSL-Zertifikaten auszuführen, nachdem Sie den Host in den Wartungsmodus versetzt haben.

Netzwerkprobleme

  • IPv6 wird von bestimmten vSphere-Funktionen nicht unterstützt
    Sie können IPv6 für alle Knoten und Komponenten mit Ausnahme der folgenden Funktionen aktivieren:

    • IPv6-Adressen für ESXi-Hosts und vCenter Server, die nicht vollqualifizierten Domänennamen (Fully Qualified Domain Names, FQDNs) auf dem DNS-Server zugeordnet sind.
      Problemumgehung: Verwenden Sie FQDNs oder stellen Sie sicher, dass die IPv6-Adressen FQDNs auf den DNS-Servern für das Reverse-Lookup von Namen zugeordnet sind.

    • Virtuelle Volumes (VVOL)

    • PXE-Starts im Rahmen von Auto Deploy und Hostprofilen
      Problemumgehung: Starten Sie einen ESXi-Host über IPv4 per PXE und konfigurieren Sie mithilfe von Hostprofilen IPv6 für den Host.

    • Verbindung von ESXi-Hosts und vCenter Server Appliance mit Active Directory
      Problemumgehung: Verwenden Sie Active Directory über LDAP als Identitätsquelle in vCenter Single Sign-On.

    • NFS 4.1-Speicher mit Kerberos
      Problemumgehung: Verwenden Sie NFS 4.1 mit AUTH_SYS.

    • Authentifizierungs-Proxy

    • Verbindung von vSphere Management Assistant und vSphere Command-Line Interface mit Active Directory.
      Problemumgehung: Stellen Sie die Verbindung mit Active Directory über LDAP her.

    • Aktivieren von IPv6 für vSphere-Funktionen mit dem vSphere Client
      Problemumgehung: Verwenden Sie den vSphere Web Client, um IPv6 für vSphere-Funktionen zu aktivieren.

  • Rekursive Kernel-Panic kann bei Verwendung von ESXi Dump Collector auftreten
    Rekursive Kernel-Panic ist möglich, wenn sich der Host im Panic-Zustand befindet, während der violette Diagnosebildschirm angezeigt wird und der Core-Dump über das Netzwerk an den ESXi Dump Collector geschrieben wird. Möglicherweise ist eine VMkernel-zdump-Datei nicht für die Fehlerbehebung auf dem ESXi Dump Collector in vCenter Server verfügbar.

    Bei einer rekursiven Kernel-Panic wird im violetten Diagnosebildschirm auf dem Host die folgende Meldung angezeigt:
    2014-09-06T01:59:13.972Z cpu6:38776)Starting network coredump from host_ip_address to esxi_dump_collector_ip_address.
    [7m2014-09-06T01:59:13.980Z cpu6:38776)WARNING: Net: 1677: Check what type of stack we are running on [0m
    Recursive panic on same CPU (cpu 6, world 38776, depth 1): ip=0x418000876a27 randomOff=0x800000:
    #GP Exception 13 in world 38776:vsish @ 0x418000f0eeec
    Secondary panic trap frame registers:
    RAX:0x0002000001230121 RCX:0x000043917bc1af80 RDX:0x00004180009d5fb8 RBX:0x000043917bc1aef0
    RSP:0x000043917bc1aee8 RBP:0x000043917bc1af70 RSI:0x0002000001230119 RDI:0x0002000001230121
    R8: 0x0000000000000038 R9: 0x0000000000000040 R10:0x0000000000010000 R11:0x0000000000000000
    R12:0x00004304f36b0260 R13:0x00004304f36add28 R14:0x000043917bc1af20 R15:0x000043917bc1afd0
    CS: 0x4010 SS: 0x0000 FS: 0x4018 GS: 0x4018 IP: 0x0000418000f0eeec RFG:0x0000000000010006
    2014-09-06T01:59:14.047Z cpu6:38776)Backtrace for current CPU #6, worldID=38776, rbp=0x43917bc1af70
    2014-09-06T01:59:14.056Z cpu6:38776)0x43917bc1aee8:[0x418000f0eeec]do_free_skb@com.vmware.driverAPI#9.2+0x4 stack: 0x0, 0x43a18b4a5880,
    2014-09-06T01:59:14.068Z cpu6:38776)Recursive panic on same CPU (cpu 6, world 38776): ip=0x418000876a27 randomOff=0x800000:
    #GP Exception 13 in world 38776:vsish @ 0x418000f0eeec
    Halt$Si0n5g# PbC8PU 7.

    Eine rekursive Kernel-Panic kann auftreten, wenn beim VMkernel ein Notfallalarm ausgelöst wird, während hoher Datenverkehr über den physischen Netzwerkadapter übertragen wird, der auch zum Senden der Core-Dumps an den Collector in vCenter Server konfiguriert ist.

    Problemumgehung: Führen Sie eine der folgenden Problemumgehungen durch:

    • Verwenden Sie einen physischen Netzwerkadapter ausschließlich für die Übertragung von Core-Dumps, um die Auswirkungen des System- und VM-Datenverkehrs zu reduzieren.

    • Deaktivieren Sie den ESXi Dump Collector auf dem Host, indem Sie den folgenden ESXCLI-Konsolenbefehl ausführen:
      esxcli system coredump network set --enable false

Speicherprobleme

Probleme bei NFS, Version 4.1

  • Virtuelle Maschinen auf einem NFS 4.1-Datenspeicher schlagen nach der Wiederherstellung der NFS 4.1-Freigabe von einem Status „Keine Pfade verfügbar“ (All Paths Down, APD) fehl
    Wenn der NFS 4.1-Speicher in einen APD-Status wechselt und diesen nach einer Kulanzzeit wieder beendet, schlagen eingeschaltete virtuelle Maschinen, die auf dem NFS 4.1-Datenspeicher ausgeführt werden, fehl. Die Kulanzzeit hängt vom Array-Anbieter ab.
    Nach der Wiederherstellung der NFS 4.1-Freigabe aus dem APD-Status wird im vSphere Web Client auf der Seite mit der Übersicht über die virtuelle Maschine die folgenden Fehlermeldung angezeigt:
    Die Sperre, die VM.vmdk schützt, ging verloren, möglicherweise aufgrund zugrunde liegender Speicherprobleme. Wenn diese virtuelle Maschine für hohe Verfügbarkeit konfiguriert ist, stellen Sie sicher, dass die virtuelle Maschine auf einem anderen Host ausgeführt wird, bevor Sie auf 'OK' klicken.
    Nachdem Sie auf „OK“ geklickt haben, werden Absturzdateien generiert und die virtuelle Maschine wird ausgeschaltet.

    Problemumgehung: Keine.

  • Synchronsierung des NFS 4.1-Clients mit dem Server geht beim Erstellen neuer Sitzungen verloren
    Nach einem Zeitraum ununterbrochener Verbindung mit dem Server geht die Synchronisierung des NFS 4.1-Clients mit dem Server beim Erstellen neuer Sitzungen möglicherweise verloren. Wenn dieses Problem auftritt, enthält die Datei vmkernel.log eine gedrosselte Abfolge von Warnmeldungen mit dem Hinweis, dass eine NFS41 CREATE_SESSION-Anforderung mit NFS4ERR_SEQ_MISORDERED fehlgeschlagen ist.

    Problemumgehung: Führen Sie die folgenden Schritte aus.

    1. Versuchen Sie, die betroffenen Dateisysteme zu unmounten. Falls beim Unmounten keine Dateien geöffnet sind, wird dieser Vorgang erfolgreich ausgeführt und das NFS-Clientmodul bereinigt den internen Status. Anschließend können Sie die Dateisysteme erneut mounten und den normalen Betrieb wiederaufnehmen.

    2. Deaktivieren Sie die Netzwerkkarten, die mit den IP-Adressen der gemounteten Komponenten verbunden sind, und lassen Sie sie lange genug deaktiviert, sodass die Server-Leasedauer mehrmals abläuft. Fünf Minuten sollten ausreichen. Anschließend können Sie die Netzwerkkarten wieder aktivieren. Der normale Betrieb sollte wiederaufgenommen werden.

    3. Falls die vorherigen Schritte fehlschlagen, starten Sie den ESXi-Host neu.

  • Synchronsierung des NFS 4.1-Clients mit einem NFS-Server geht verloren und die Verbindung kann selbst durch Zurücksetzen der Sitzung nicht wiederhergestellt werden
    Nach einem Zeitraum ununterbrochener Verbindung mit dem Server geht die Synchronisierung des NFS 4.1-Clients mit dem Server verloren und die synchronisierte Verbindung mit dem Server kann nicht wiederhergestellt werden, selbst wenn die Sitzung zurückgesetzt wird. Dieses Problem wird durch einen EMC VNX-Serverfehler verursacht. Wenn dieses Problem auftritt, enthält die Datei vmkernel.log eine gedrosselte Abfolge von Warnmeldungen mit folgendem Hinweis zu NFS41: NFS41ProcessSessionUp:2111: resetting session with mismatched clientID; probable server bug

    Problemumgehung: Um die Sitzung zu beenden, unmounten Sie alle Datenspeicher und mounten sie dann erneut.

  • Auf ONTAP-Kerberos-Volumes ist kein Zugriff mehr möglich oder es treten VM-E/A-Fehler auf
    Ein NetApp-Server reagiert nicht, wenn er RPCSEC_GSS-Anforderungen in der falschen Reihenfolge empfängt. Der entsprechende E/A-Vorgang hängt deshalb, außer er wird beendet, und das Gastbetriebssystem kann hängen oder E/A-Fehler verzeichnen. Darüber hinaus sind für den Client laut RFC 2203 nur so viele ausstehende Anforderungen wie durch „seq_window“ festgelegt (32 für ONTAP) gemäß RPCSEC_GSS-Kontext zulässig und der Client muss abwarten, bis die niedrigste dieser ausstehenden Anforderungen durch den Server abgeschlossen wurde. Deshalb beantwortet der Server die RPCSEC_GSS-Anforderung in der falschen Reihenfolge nie, und der Client beendet das Senden von Anforderungen an den Server, sobald der maximal zulässige Wert für „seq_window“ an ausstehenden Anforderungen erreicht wird. Auf das Volume ist deshalb kein Zugriff mehr möglich.

    Problemumgehung: Keine. Suchen Sie in der neuesten Hardwarekompatibilitätsliste (Hardware Compatibility List, HCL) nach einem unterstützten ONTAP-Server, für den dieses Problem behoben wurde.

  • In EMC VNX kann eine virtuelle Festplatte mit einer Größe von mehr als 1 TB nicht auf einem NFS 4.1-Datenspeicher erstellt werden
    Ein NFS 4.1-Speicher von EMC VNX mit Firmware-Version 7.x unterstützt nur 32-Bit-Dateiformate. Dies verhindert das Erstellen von VM-Dateien mit einer Größe von mehr als 1 TB auf dem NFS 4.1-Datenspeicher.

    Problemumgehung: Aktualisieren Sie das EMC VNX-Array auf Version 8.x.

  • Bei Firmware-Upgrades ist auf NFS 4.1-Datenspeicher, die auf EMC VNX-Speicher basieren, kein Zugriff mehr möglich
    Wenn Sie ein Upgrade eines EMC VNX-Speichers auf eine neue Firmware durchführen, ist auf NFS 4.1-Datenspeicher, die auf dem ESXi-Host gemountet sind, kein Zugriff mehr möglich. Dies ist darauf zurückzuführen, dass die Hauptgerätenummer des VNX-Servers nach dem Firmware-Upgrade geändert wird. Der NFS 4.1-Client auf dem Host erwartet keine Änderung der Hauptgerätenummer, nachdem die Verbindung mit dem Server hergestellt wurde, weshalb auf die Datenspeicher dauerhaft nicht zugegriffen werden kann.

    Problemumgehung: Unmounten Sie alle NFS 4.1-Datenspeicher, die vom VNX-Server exportiert wurden, bevor Sie ein Upgrade der Firmware durchführen.

  • Wenn ESXi-Hosts unterschiedliche Sicherheitsmechanismen zum Mounten desselben NFS 4.1-Datenspeichers verwenden, treten möglicherweise Fehler bei virtuellen Maschinen auf
    Wenn verschiedene ESXi-Hosts denselben NFS 4.1-Datenspeicher mithilfe unterschiedlicher Sicherheitsmechanismen mounten (AUTH_SYS und Kerberos), treten bei auf diesem Datenspeicher platzierten virtuellen Maschinen möglicherweise Probleme und Fehler auf. Beispielsweise schlagen Versuche, die virtuellen Maschinen von Host1 zu Host2 zu migrieren, möglicherweise mit der Fehlermeldung, dass die Berechtigung abgelehnt wurde, fehl. Diese Fehler können auch beim Versuch auftreten, von Host2 aus auf eine virtuelle Maschine auf Host1 zuzugreifen.

    Problemumgehung: Stellen Sie sicher, dass alle Hosts, die ein NFS 4.1-Volume mounten, denselben Sicherheitstyp verwenden.

  • Versuche, schreibgeschützte Dateien mit Kerberos in einen NFS 4.1-Datenspeicher zu kopieren, schlagen fehl
    Dieser Fehler kann auftreten, wenn Sie Daten aus einer Quelldatei in eine Zieldatei zu kopieren versuchen. Die Zieldatei bleibt leer.

    Problemumgehung: Keine.

  • Beim Erstellen eines Datenspeicher-Clusters, ist die Einheitlichkeit der NFS 4.1-Sicherheitstypen nicht garantiert
    Beim Erstellen eines Datenspeicher-Clusters wird die Einheitlichkeit der NFS 4.1-Sicherheitstypen nicht von vSphere überprüft und erzwungen. Deshalb können in einem Cluster Datenspeicher vorhanden sein, die unterschiedliche Sicherheitstypen (AUTH_SYS und Kerberos) verwenden. Wenn Sie eine virtuelle Maschine von einem Datenspeicher mit Kerberos zu einem Datenspeicher mit AUTH_SYS migrieren, wird die Sicherheitsstufe für die virtuelle Maschine heruntergestuft.
    Dieses Problem betrifft Funktionen wie vMotion, Storage vMotion, DRS und Storage DRS.

    Problemumgehung: Falls die Kerberos-Sicherheit für Ihre virtuellen Maschinen erforderlich ist, stellen Sie sicher, dass alle NFS 4.1-Volumes, die zum selben Cluster gehören, nur den Kerberos-Sicherheitstyp verwenden. Schließen Sie keine NFS 3-Datenspeicher ein, da NFS 3 nur AUTH_SYS unterstützt.

Probleme bei Virtual Volumes

  • Fehler beim Erstellen virtueller Datenspeicher, da der VASA-Anbieter für Virtual Volumes ein falsches Zertifikat verwendet
    Es kann vorkommen, dass ein selbstsigniertes Zertifikat, das vom Virtual Volumes-VASA-Anbieter verwendet wird, die KeyUsage-Erweiterung fälschlicherweise als kritisch definiert, ohne das keyCertSign-Bit festzulegen. In diesem Fall wird die Registrierung des Anbieters erfolgreich durchgeführt. Sie können jedoch keinen virtuellen Datenspeicher anhand der vom VASA-Anbieter gemeldeten Speichercontainer erstellen.

    Problemumgehung: Selbstsignierte Zertifikate, die vom VASA-Anbieter zum Zeitpunkt der Anbieterregistrierung verwendet werden, sollten nicht die KeyUsage-Erweiterung als kritisch definieren, ohne das keyCertSign-Bit festzulegen.

Allgemeine Speicherprobleme

  • Neues Problem Auf Hosts mit ESXi 6.0 Update 2, die mit Speicher-Arrays verbunden sind, die eine bestimmte Firmware-Version aufweisen, kann es zu E/A-Zeitüberschreitungen und nachfolgenden Abbrüchen kommen
    Wenn Hosts mit ESXi 6.0 Update 2, die mit Speicher-Arrays verbunden sind, die eine bestimmte Firmware-Version aufweisen, Anforderungen für SMART-Daten an das Speicher-Array senden und wenn das Array mit einem PDL-Fehler antwortet, führt das Verhalten der PDL-Antwort in 6.0 Update 2 möglicherweise zu einem Zustand, in dem diese fehlgeschlagenen Befehle fortlaufend erneut versucht werden, wodurch andere Befehle blockiert werden. Dieser Fehler führt zu weitverbreiteten E/A-Zeitüberschreitungen und nachfolgenden Abbrüchen.

    Außerdem kann die Wiederherstellung der Verbindung der ESXi-Hosts mit vCenter Server nach einem Neustart sehr lang dauern, oder die Hosts wechseln möglicherweise in den Zustand Keine Antwort in vCenter Server. Das Abschließen von speicherbezogenen Aufgaben wie die erneute HBA-Prüfung kann sehr lang dauern.

    Problemumgehung: Informationen zum Beheben dieses Problems finden Sie im Knowledgebase-Artikel 2133286.

  • vSphere Web Client zeigt eine Speicherrichtlinie fälschlicherweise als angefügt an, wenn eine neue virtuelle Maschine anhand einer vorhandenen Festplatte erstellt wird
    Angenommen, Sie verwenden vSphere Web Client zum Erstellen einer neuen virtuellen Maschine anhand einer vorhandenen Festplatte und geben beim Einrichten der Festplatte eine Speicherrichtlinie an. In diesem Fall scheint der Filter angefügt zu sein, wenn Sie die neue virtuelle Maschine auswählen und dann auf VM-Richtlinien und VM-Speicherrichtlinie bearbeiten klicken. In Wirklichkeit ist der Filter jedoch nicht angefügt. Sie können anhand der .vmdk-Datei oder der Datei vmkfstools --iofilterslist <vmdk-file> überprüfen, ob der Filter angefügt ist.

    Problemumgehung: Fügen Sie nach dem Erstellen, aber vor dem Einschalten der neuen virtuellen Maschine den Filter zur vmdk-Datei hinzu, indem Sie auf VM-Richtlinien und dann auf VM-Speicherrichtlinie bearbeiten klicken.

  • NFS-Suchvorgang gibt NFS STALE-Fehler zurück
    Wenn Sie eine große Anzahl an VMs im NFS-Datenspeicher bereitstellen, schlägt die VM-Bereitstellung aufgrund eines Race-Fehlers mit einer Fehlermeldung ähnlich der folgenden fehl:

    Veraltetes NFS-Datei-Handle

    Problemumgehung: Starten Sie den Suchvorgang erneut. Weitere Details finden Sie im Knowledgebase-Artikel 2130593.

  • Versuche zum Erstellen eines VMFS-Datenspeichers auf Dell EqualLogic-LUNs schlagen bei Verwendung von QLogic iSCSI-Adaptern fehl
    Sie können keinen VMFS-Datenspeicher auf einem Dell EqualLogic-Speichergerät erstellen, das über QLogic iSCSI-Adapter ermittelt wird.
    Beim Fehlschlagen der Versuche wird die folgende Fehlermeldung in vCenter Server angezeigt: Dateisystem kann nicht erstellt werden. Weitere Details finden Sie im Protokoll: Zeitüberschreitung der Verbindung. Das VMkernel-Protokoll enthält wiederholt die Fehlermeldungen iscsi session blocked und iscsi session unblocked. Im Dell EqualLogic-Speicher-Array enthalten die Überwachungsprotokolle die Fehlermeldung protocol error in packet received from the initiator für die IQN-Namen des QLogic-Initiators.

    Dieses Problem tritt bei Verwendung der folgenden Komponenten auf:

    • Dell EqualLogic-Array-Firmware: V6.0.7

    • QLogic iSCSI-Adapter-Firmware-Versionen: 3.00.01.75

    • Treiberversion: 5.01.03.2-7vmw-debug

    Problemumgehung: Aktivieren Sie den Adapterparameter iSCSI ImmediateData auf dem QLogic iSCSI-Adapter. Dieser Parameter ist standardmäßig deaktiviert. Dieser Parameter kann nicht über den vSphere Web Client oder mithilfe von esxcli-Befehlen geändert werden. Verwenden Sie zum Ändern dieses Parameters die Software des Anbieters, wie z. B. QConvergeConsole CLI.

  • ESXi-Host mit Emulex OneConnect HBA kann nicht gestartet werden
    Wenn auf einem ESXi-Host der Emulex OneConnect HBA installiert ist, kann der Host möglicherweise nicht gestartet werden. Dieser Fehler ist auf ein Problem bei der Emulex-Firmware zurückzuführen.

    Problemumgehung: Wenden Sie sich zur Behebung dieses Problems wegen der neuesten Firmware für Ihren HBA an Emulex.

    Falls Sie weiterhin die alte Firmware verwenden, führen Sie die folgenden Schritte aus, um den Startfehler zu vermeiden:

    1. Drücken Sie beim Laden von ESXi Umschalt+O, bevor Sie den ESXi-Kernel starten.

    2. Lassen Sie die vorhandene Startoption unverändert und fügen Sie ein Leerzeichen gefolgt von dmaMapperPolicy=false hinzu.

  • E/A-Vorgänge werden im APD-Status von Flash Read Cache nicht beschleunigt
    Wenn die als vFlash-Ressource für Flash Read Cache konfigurierte Flash-Festplatte fehlerhaft ist oder kein Zugriff darauf möglich ist oder wenn vom Host aus nicht auf den Festplattenspeicher zugegriffen werden kann, sind die Flash Read Cache-Instanzen auf diesem Host ungültig und tragen nicht zur Beschleunigung der E/A-Vorgänge bei. Deshalb zeigen die Caches keine veralteten Daten an, nachdem die Verbindung zwischen dem Host und dem Speicher wiederhergestellt wurde. Der Verbindungsausfall kann temporär, ein APD-Problem (Keine Pfade verfügbar, All Paths Down), dauerhaft oder ein dauerhafter Geräteverlust (Permanent Device Loss, PDL) sein. Dieses Problem besteht, bis die virtuelle Maschine aus- und wieder eingeschaltet wird.

    Problemumgehung: Die virtuelle Maschine kann aus- und wieder eingeschaltet werden, um die E/A-Beschleunigung mithilfe von Flash Read Cache wiederherzustellen.

  • APD (All Paths Down, Keine Pfade verfügbar) oder Pfad-Failover verursachen möglicherweise einen Systemausfall
    In einer gemeinsam genutzten SAS-Umgebung verursachen APD- oder Pfad-Failover-Situationen möglicherweise einen Systemausfall, falls die Festplatten vom lsi_msgpt3-Treiber beansprucht werden und hohe E/A-Aktivitäten auftreten.

    Problemumgehung: Keine

  • Die häufige Verwendung der SCSI-Abbruchbefehle kann zu einem Systemausfall führen
    Bei hoher E/A-Aktivität können häufige SCSI-Abbruchbefehle zu einer sehr langsamen Reaktion des MegaRAID-Controllers führen. Eine unerwartete Unterbrechung bei Ressourcenreferenzen, die bereits in einem vorherigen Kontext veröffentlicht wurden, kann zu einem Systemausfall führen.

    Problemumgehung: Keine

  • Bei einer Änderung des IQN schlagen iSCSI-Verbindungen fehl und auf Datenspeicher ist kein Zugriff mehr möglich
    Dieses Problem kann auftreten, wenn Sie den IQN eines iSCSI-Adapters ändern, während noch iSCSI-Sitzungen auf dem Adapter aktiv sind.

    Problemumgehung: Wenn Sie den IQN eines iSCSI-Adapters ändern, sollte auf diesem Adapter keine Sitzung aktiv sein. Entfernen Sie alle iSCSI-Sitzungen und alle Ziele auf dem Adapter, bevor Sie den IQN ändern.

  • Online- und Offlinevorgänge von nvmecli werden möglicherweise nicht immer ausgeführt
    Wenn Sie nvmecli device online -A vmhba* ausführen, um ein NVMe-Gerät online zu schalten, scheint der Vorgang erfolgreich ausgeführt zu werden. Das Gerät verbleibt jedoch möglicherweise im Offlinestatus.

    Problemumgehung: Überprüfen Sie den Status von NVMe-Geräten durch Ausführen des Befehls nvmecli device list.

Serverkonfigurationsprobleme
  • Die Wartung schlägt fehl, wenn ein Hostprofil eines statusorientierten Hosts auf einen mit Auto Deploy bereitgestellten Host angewendet wird
    Wenn Sie ein Hostprofil eines als statusorientiert bereitgestellten Hosts auf einen mit Auto Deploy bereitgestellten Host (statusfreier Host) ohne lokalen Speicher anwenden, schlägt der Wartungsversuch mit einer der folgenden Fehlermeldungen fehl:

    • Das vmhba-Gerät an der PCI-Bus-Adresse sxxxxxxxx.xx ist auf Ihrem Host nicht vorhanden. Sie müssen den Rechner herunterfahren und dann eine Karte in den PCI-Steckplatz yy stecken. Der Typ der Karte sollte exakt mit dem der Karte im Referenzhost übereinstimmen.

    • Keine gültige Coredump-Partition gefunden.

    Problemumgehung: Deaktivieren Sie im Hostprofil das Plug-In, welches das Problem verursacht (z. B. „Konfiguration des Gerätealias“ oder „Core-Dump-Konfiguration“), und führen Sie dann eine Wartung des Hostprofils aus.

  • Die Anwendung eines Hostprofils mit statischer IP-Adresse auf einen Host führt zu einem Übereinstimmungsfehler
    Wenn Sie ein Hostprofil von einem Host mit einer DHCP-Netzwerkkonfiguration extrahieren und anschließend das Hostprofil bearbeiten, sodass eine statische IP-Adresse vorhanden ist, wird beim Anwenden des Hostprofils auf einen anderen Host der folgende Übereinstimmungsfehler gemeldet:

    Anzahl der IPv4-Routen stimmt nicht überein.

    Problemumgehung: Konfigurieren Sie vor dem Extrahieren des Hostprofils vom DHCP-Host den Host so, dass eine statische IP-Adresse vorhanden ist.

  • Beim Hinzufügen im laufenden Betrieb eines virtuellen Netzwerkadapters mit einer Überbelegung der Netzwerkressourcen wird die virtuelle Maschine möglicherweise ausgeschaltet
    Auf einem vSphere Distributed Switch mit aktivierter Network I/O Control wird für eine eingeschaltete virtuelle Maschine die Bandbreitenreservierung gemäß der Reservierung für VM-Systemdatenverkehr auf dem physischen Netzwerkadapter des Hosts konfiguriert. Sie fügen einen Netzwerkadapter im laufenden Betrieb zur virtuellen Maschine hinzu und legen die Netzwerkbandbreitenreservierung so fest, dass die auf den physischen Netzwerkadaptern des Hosts verfügbare Bandbreite überschritten wird.

    Beim Hinzufügen des Netzwerkadapters im laufenden Betrieb startet der VMkernel einen FSR-Prozess (Fast Suspend & Resume, schnelles Anhalten und Fortsetzen). Da die virtuelle Maschine mehr Netzwerkressourcen anfordert, als verfügbar sind, führt der VMkernel den Fehlerpfad des FSR-Prozesses aus. Ein Fehler in diesem Fehlerpfad bewirkt, dass die virtuelle Maschine ausgeschaltet wird.

    Problemumgehung: Konfigurieren Sie keine Bandbreitenreservierung, wenn Sie einer eingeschalteten virtuellen Maschine einen Netzwerkadapter hinzufügen.

VMware HA- und Fault Tolerance-Probleme
  • Fault Tolerance (FT)-Legacy-Version wird für die Plattformen Intel Skylake-DT/S, Broadwell-EP, Broadwell-DT und Broadwell-DE nicht unterstützt
    Für die Plattformen Intel Skylake-DT/S, Broadwell-EP, Broadwell-DT und Broadwell-DE werden FT-Legacy-Versionen nicht unterstützt. Versuche, eine virtuelle Maschine einzuschalten, schlagen fehl, nachdem Sie eine Fault Tolerance-Legacy-Version für einen einzelnen Prozessor aktiviert haben.

    Problemumgehung: Keine.

Gastbetriebssystem-Probleme
  • Versuche, den Passthrough-Modus auf NVMe PCIe SSD-Geräten zu ermöglichen, schlagen möglicherweise nach einem Hotplug-Vorgang fehl
    Um über den vSphere Web Client den Passthrough-Modus auf einem SSD-Gerät zu ermöglichen, wählen Sie einen Host aus, klicken dann auf die Registerkarte Verwalten und anschließend auf Einstellungen. Dann navigieren Sie zum Abschnitt Hardware, klicken auf PCI-Geräte > Bearbeiten, wählen ein Gerät aus der Liste der aktiven Geräte aus, für die der Passthrough-Modus aktiviert werden kann, und klicken dann auf OK. Wenn Sie allerdings ein neues NVMe-Gerät im laufenden Betrieb mit einem ESXi 6.0-Host verbinden, der nicht über ein PCIe NVMe-Laufwerk verfügt, kann das neue NVMe PCIe SSD-Gerät nicht für den Passthrough-Modus aktiviert werden und wird nicht in der Liste der verfügbaren Passthrough-Geräte angezeigt.

    Problemumgehung: Starten Sie den Host neu. Sie können den Befehl auch auf dem ESXi-Host ausführen.

    1. Melden Sie sich als Root-Benutzer an.

    2. Führen Sie den Befehl
      /etc/init.d/hostd start aus.

Probleme bei unterstützter Hardware
  • Der Abruf des Festplattenspeicherorts mit esxcli führt bei Avago-Controllern auf HP-Servern zu falschen Ergebnissen

    Bei der Ausführung von esxcli storage core device physical get für einen Avago-Controller auf einem HP-Server ist das Ergebnis nicht korrekt.

    Beispiel: Ausgeführter Befehl
    esxcli storage core device physical get -d naa.5000c5004d1a0e76
    Systemrückgabe:
    Physical Location: enclosure 0, slot 0

    Die tatsächliche Bezeichnung des Slots auf dem physischen Server lautet allerdings 1.

    Problemumgehung: Prüfen Sie die Slots auf HP-Servern sehr sorgfältig. Da die Slotnummern auf HP-Servern mit 1 beginnen, müssen Sie die vom Befehl zurückgegebene Slotnummer um 1 erhöhen, um die richtige Nummer zu ermitteln.

CIM- und API-Probleme
  • sfcb-vmware_raw schlägt möglicherweise fehl
    sfcb-vmware_raw schlägt möglicherweise fehl, da der maximale Speicher für die Ressourcengruppe des Standard-Plugins nicht ausreicht.

    Problemumgehung: Fügen Sie UserVars CIMOemPluginsRPMemMax für Arbeitsspeichergrenzwerte von sfcbd-Plug-Ins mithilfe des folgenden Befehls hinzu und starten Sie sfcbd neu, damit der neue Plug-In-Wert wirksam wird:

    esxcfg-advcfg -A CIMOemPluginsRPMemMax --add-desc 'Maximum Memory for plugins RP' --add-default XXX --add-type int --add-min 175 --add-max 500

    Dabei steht XXX für den Arbeitsspeichergrenzwert, den Sie zuteilen möchten. Dieser Wert sollte zwischen dem Mindestwert (175) und dem Höchstwert (500) liegen.