Versionshinweise zu VMware ESXi 6.0 Update 3

|

Aktualisiert am: 14. MÄRZ 2017

ESXi 6.0 Update 3 | 24. FEBRUAR 2017 | ISO-Build 5050593

Ü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

  • Aktualisierter ESXi-Hostclient: Im Lieferumfang von VMware ESXi 6.0 Update 3 befindet sich eine aktualisierte Version des ESXi-Hostclients, Version 1.14.0. Der aktualisierte Hostclient enthält Fehlerbehebungen und kommt so der Funktionalität des vSphere Clients wesentlich näher. Wenn Sie den Hostclient über ESXi 6.0-Patch-Versionen aktualisiert haben, installieren Sie die im Lieferumfang von ESXi 6.0 Update 3 enthaltene Version 1.14.0. Darüber hinaus werden neue Versionen des Hostclients weiterhin über die VMware Labs Flings-Website veröffentlicht. Diese Fling-Versionen werden jedoch offiziell nicht unterstützt und sind für Produktionsumgebungen nicht geeignet.

  • Unterstützung für TLS: Unterstützung für TLSv1.0, TLSv1.1 und TLSv1.2 ist standardmäßig aktiviert und kann für ESXi 6.0 Update 3 konfiguriert werden. Informationen zum Konfigurieren von TLSv1.0, TLSv1.1 und TLSv1.2 finden Sie im VMware-Knowledgebase-Artikel 2148819. Eine Liste der VMware-Produkte, die für die Deaktivierung von TLSv1.0 und die Verwendung von TLSv1.1/1.2 unterstützt werden, finden Sie im VMware-Knowledgebase-Artikel 2145796.

  • Leistung von Virtual SAN: Mehrere Fehlerbehebungen werden in VMware ESXi 6.0 Update 3 eingeführt, um E/A-Pfade für verbesserte Virtual SAN-Leistung in reinen Flash- und Hybrid-Konfigurationen zu optimieren:

    • Protokollverwaltungs- und Speicherverbesserungen wurden durchgeführt, sodass mehr Protokolle gespeichert werden können. Hiermit sollte die Leistung für schreibintensive Arbeitslasten deutlich gesteigert werden. Da es sich bei Virtual SAN um ein protokollbasiertes Dateisystem handelt, müssen Protokolleinträge effizient verwaltet werden, um eine stetige Ansammlung von Protokollen zu vermeiden.

    • Neben der Zunahme der Packungsdichte der Protokolleinträge liest Virtual SAN in Szenarien, in denen große Dateien bei eingeschalteten Datendiensten gelöscht werden, vorbeugend Daten auf die Kapazitätsschicht aus, wodurch das Protokollwachstum wirksam eingeschränkt wird.

    • Der Codepfad der Prüfsumme ist nun effizienter.

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

  • Site Recovery Manager: SRM-Versionen (Site Recovery Manager) vor SRM 6.5 bieten keine Unterstützung für IP-Anpassungs- und gastinterne Callout-Vorgänge für VMs, die auf ESXi 6.0 platziert werden und VMware Tools Version 10.1 und höher verwenden. Weitere Informationen finden Sie unter Probleme bei VMware Tools.

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-Update03 enthält die folgenden einzelnen Bulletins:

Patch-Version ESXi600-Update03 (nur Security-Build) enthält die folgenden einzelnen Bulletins:

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

Patch-Version ESXi600-Update03 (nur Security-Build) enthält die folgenden Image-Profile:

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
  • Nach dem Beenden des Sperrmodus funktioniert die VMware-Anbietermethode zum Überprüfen von Benutzerberechtigungen weder für Benutzernamen noch für Kennwörter
    Nachdem der Sperrmodus für den Server beendet wurde, gibt die VMware-Anbietermethode einen Wert zurück, der mit dem Wert vor Eintritt in den Sperrmodus nicht kompatibel ist. Dies führt dazu, dass die VMware-Anbietermethode zum Überprüfen von Benutzerberechtigungen nicht mit den Benutzernamen und Kennwörtern funktioniert, die vor Eintritt in den Sperrmodus verwendet wurden.

    Dieses Problem wurde in der vorliegenden Version behoben.

Sonstige Probleme
  • Upgrade von VMware Tools auf mehreren VMs schlägt unter Umständen fehl
    Versuche, VMware Tools mithilfe von Update Manager gleichzeitig auf mehreren VMs zu aktualisieren, schlagen unter Umständen fehl. Nicht für alle VMs wird das Upgrade abgeschlossen.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Eine hohe Leselast der VMware Tools-ISO-Images kann zu einer Beschädigung der Flash-Medien führen
    In einer VDI-Umgebung kann die hohe Leselast der VMware Tools-Images zu einer Beschädigung der Flash-Medien führen.

    Dieses Problem wurde in der vorliegenden Version behoben.

    Sie können die gesamten VMware Tools-Daten auf eine eigene Ramdisk kopieren. Auf diese Weise können die Daten pro Startvorgang nur einmal aus den Flash-Medien gelesen werden. Alle anderen Lesevorgänge erfolgen auf der Ramdisk. vCenter Server Agent (vpxa) greift auf diese Daten über das Verzeichnis /vmimages zu, das symbolische Links enthält, die auf productLocker zeigen.

    Führen Sie zur Aktivierung dieser Funktion die folgenden Schritte durch:

    1. Verwenden Sie den Befehl, um die erweiterte Option ToolsRamdisk auf 1 festzulegen:
    2. esxcli system settings advanced set -o /UserVars/ToolsRamdisk -i 1

    3. Starten Sie den Host neu.
  • Die Datei syslog.log wird unter Umständen mit Fehlermeldungen vom Typ Unbekannt überflutet
    In ESXi 6.0 Update 2 kann die Datei syslog.log von Hosts mit einem Dell-CIM-Anbieter mit Fehlermeldungen vom Typ Unbekannt überflutet werden, wenn der Dell-CIM-Anbieter deaktiviert ist oder sich im Leerlauf befindet. Wenn der ESXi 6.0 Update 2-Host neu gestartet wird, werden in der Datei syslog.log in unregelmäßigen Abständen unter Umständen Fehlermeldungen mit Einträgen vom Typ Unbekannt aufgezeichnet.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Core-Dump-Fehler in Userworld
    Ein Userworld-Dump schlägt unter Umständen fehl, wenn für einen Benutzerprozess nicht genügend Arbeitsspeicher zur Verfügung steht. Die Fehlermeldung Es konnte kein Arbeitsspeicher zugeteilt werden wird angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben. Die Fehlerbehebung stellt globalen Arbeitsspeicher für die Heap-Zuteilung des Userworld-Core-Dumps bereit und wird verwendet, wenn für einen beliebigen Prozess nicht genügend Arbeitsspeicher vorhanden ist.

  • Versuche, Failover für eine VM ausführen, schlagen bei der Speichersynchronisierung mit einem Fehler fehl
    Versuche, Failover für eine VM auszuführen, schlagen während der Speichersynchronisierung unter Umständen mit einer Fehlermeldung ähnlich der folgenden fehl:

    Fehler beim Kommunizieren mit dem Remoteserver.

    Die folgenden Meldungen werden in der Datei HBRsrv.log protokolliert:

    YYYY-MM-DDT13:48:46.305Z info hbrsrv[nnnnnnnnnnnn] [Originator@6876 sub=Host] Heartbeat handler detected dead connection for host: host-9
    YYYY-MM-DDT13:48:46.305Z warning hbrsrv[nnnnnnnnnnnn] [Originator@6876 sub=PropertyCollector] Got WaitForUpdatesEx exception: Server closed connection after 0 response bytes read; 171:53410'>, >)>


    Auf dem ESXi-Host reagiert der hostd-Dienst unter Umständen nicht mehr, wobei Fehlermeldungen ähnlich der folgenden angezeigt werden:

    YYYY-MM-DDT13:48:38.388Z panic hostd[468C2B70] [Originator@6876 sub=Default]
    -->
    --> Panic: Assert Failed: "progress >= 0 && progress <= 100" @ bora/vim/hostd/vimsvc/HaTaskImpl.cpp:557
    --> Backtrace:
    -->

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Protokollmeldungen werden fortwährend alle 90 Sekunden in der Protokolldatei Hostd.log aufgezeichnet
    Auf Virtual SAN bezogene Protokollmeldungen ähnlich den folgenden werden alle 90 Sekunden in der Datei hostd.log protokolliert, selbst wenn Virtual SAN nicht aktiviert ist:

    { YYYY-MM-DDT06:50:01.923Z info hostd[nnnnnnnn] [Originator@6876 sub=Hostsvc opID=21fd2fe8] VsanSystemVmkProvider : GetRuntimeInfo: Complete, runtime info: (vim.vsan.host.VsanRuntimeInfo) {
    YYYY-MM-DDT06:51:33.449Z info hostd[nnnnnnnn] [Originator@6876 sub=Hostsvc opID=21fd3009] VsanSystemVmkProvider : GetRuntimeInfo: Complete, runtime info: (vim.vsan.host.VsanRuntimeInfo) {
    YYYY-MM-DDT06:53:04.978Z info hostd[nnnnnnnn] [Originator@6876 sub=Hostsvc opID=21fd3030] VsanSystemVmkProvider : GetRuntimeInfo: Complete, runtime info: (vim.vsan.host.VsanRuntimeInfo) {

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Upgrade von VMware Tools auf mehreren VMs schlägt unter Umständen fehl
    Versuche, VMware Tools mithilfe von Update Manager gleichzeitig auf mehreren VMs zu aktualisieren, schlagen unter Umständen fehl. Wenn dieses Problem auftritt, wird VMware Tools für bestimmte VMs unter Umständen nicht aktualisiert.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Enumeration von SMX-Anbieterklassen schlägt unter Umständen fehl
    Wenn Sie den HPE ESXi WBEM-Anbieter mit dem CIMPDK der Version 6.0 kompilieren und auf einem ESXi 6.0 U3-System installieren, schlägt die Enumeration von SMX-Anbieterklassen unter Umständen fehl.

    Dieser Fehler kann sich aus der Enumeration von unter anderen folgenden SMX-Klassen ergeben:

    • SMX_EthernetPort
    • SMX_Fan
    • SMX_PowerSupply
    • SMX_SAMediaAccessStatData

    Der folgende Fehler wird durch die Ausführung des sfcbd-Diensts für diese SMX-Klassen angezeigt:

    # enum_instances SMX_EthernetPort root/hpq error: enumInstances Server returned nothing (no headers, no data)

    Anbieter reagieren auf Enumerationsanfragen und stellen dem sfcbd-Dienst erfolgreich Antworten bereit. Es gibt keine Anbieterneustarts und keine Anbieter-Core-Dumps. Jede Enumeration erzeugt sfcbd- CIMXML-Core-Dumps, wie z. B. sfcb-CIMXML-Pro-zdump.000.

    Dieses Problem wurde in der vorliegenden Version behoben.

Netzwerkprobleme
  • ARP-Anforderungspakete werden unter Umständen verworfen
    ARP-Anforderungspakete zwischen zwei VMs werden unter Umständen verworfen, wenn eine VM mit VLAN-Kennzeichnung für Gäste und die andere VM mit VLAN-Kennzeichnung für virtuelle Switches konfiguriert und VLAN-Offload auf den VMs deaktiviert ist.

  • Die Konfiguration der ESXi-Firewall wird unter Umständen aufgrund eines skriptbasierten Upgrades deaktiviert
    Die Konfiguration der ESXi-Firewall ist nach einem skriptbasierten Upgrade von ESXi 6.0 Update 1 oder höher mithilfe der Kick Start-Datei über NFS oder FTP unter Umständen deaktiviert.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Selbst nach einem Neustart des Hosts wird die virtuelle MAC-Adresse 00:00:00:00:00:00 während der Kommunikation für eine neu hinzugefügte physische Netzwerkkarte verwendet
    Eine neu hinzugefügte physische Netzwerkkarte verfügt nach einem Neustart des Hosts unter Umständen nicht über den entsprechenden Eintrag in der Datei esx.conf. Dies hat zur Folge, dass die virtuelle MAC-Adresse 00:00:00:00:00:00 während der Kommunikation für die physische Netzwerkkarte aufgelistet wird.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Während der Startphase wird eine Fehlermeldung angezeigt
    Beim Lesen des Installationsskripts durch das ESXi-Installationsprogramm während der Startphase wird unter bestimmten Bedingungen eine Fehlermeldung ähnlich der folgenden angezeigt:

    VmkNicImpl::DisableInternal:: Deleting vmk0 Management Interface, so setting advlface to NULL

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Physischer Switch wird bei Verwendung von Citrix VDI per PXE-Startvorgang mit RARP-Paketen überflutet
    Wenn Sie eine virtuelle Maschine für Citrix VDI starten, wird der physische Switch mit RARP-Paketen (über 1000) überflutet. Dies kann dazu führen, dass Netzwerkverbindungen getrennt werden und ein kurzfristiger Ausfall erfolgt.

    Diese Version enthält die erweiterte Option /Net/NetSendRARPOnPortEnablement. Sie müssen den Wert für /Net/NetSendRARPOnPortEnablement auf 0 setzen, um dieses Problem zu beheben.

  • Ein ESXi-Host schlägt unter Umständen mit einem violetten Diagnosebildschirm fehl
    Ein ESXi-Host schlägt unter Umständen mit einem violetten Diagnosebildschirm fehl. Dies geschieht, wenn DVFilter_TxCompletionCB() aufgerufen wird, um ein freigegebenes dvfilter-Speicherpaket abzuschließen. Die im Paket gespeicherten vollständigen E/A-Daten werden freigegeben. In bestimmten Fällen wird diesem Datenmitglied jedoch der Wert 0 zugewiesen, wodurch es zu einer NULL-Zeiger-Ausnahme kommt. Eine Fehlermeldung ähnlich der folgenden wird angezeigt:

    YYYY-MM-DDT04:11:05.134Z cpu24:33420)@BlueScreen: #PF Exception 14 in world 33420:vmnic4-pollW IP 0x41800147d76d addr 0x28
    PTEs:0x587e436023;0x587e437023;0x587e438023;0x0;
    YYYY-MM-DDT04:11:05.134Z cpu24:33420)Code start: 0x418000800000 VMK uptime: 23:18:59:55.570
    YYYY-MM-DDT04:11:05.135Z cpu24:33420)0x43915461bdd0:[0x41800147d76d]DVFilterShmPacket_TxCompletionCB@com.vmware.vmkapi#v2_3_0_0+0x3d sta
    YYYY-MM-DDT04:11:05.135Z cpu24:33420)0x43915461be00:[0x41800146eaa2]DVFilterTxCompletionCB@com.vmware.vmkapi#v2_3_0_0+0xbe stack: 0x0
    YYYY-MM-DDT04:11:05.136Z cpu24:33420)0x43915461be70:[0x418000931688]Port_IOCompleteList@vmkernel#nover+0x40 stack: 0x0
    YYYY-MM-DDT04:11:05.136Z cpu24:33420)0x43915461bef0:[0x4180009228ac]PktListIOCompleteInt@vmkernel#nover+0x158 stack: 0x0
    YYYY-MM-DDT04:11:05.136Z cpu24:33420)0x43915461bf60:[0x4180009d9cf5]NetPollWorldCallback@vmkernel#nover+0xbd stack: 0x14
    YYYY-MM-DDT04:11:05.137Z cpu24:33420)0x43915461bfd0:[0x418000a149ee]CpuSched_StartWorld@vmkernel#nover+0xa2 stack: 0x0

    Dieses Problem wurde in der vorliegenden Version behoben.

Sicherheitsprobleme
  • Likewise Kerberos-Update
    Likewise Kerberos wurde auf Version 1.14 aktualisiert.
  • OpenSSL-Update
    OpenSSL wurde auf Version openssl-1.0.2j aktualisiert.
  • PAM-Update
    PAM wurde auf Version 1.3.0 aktualisiert.
  • Update der libPNG-Bibliothek
    Die libPNG-Bibliothek wurde auf libpng-1.6.26 aktualisiert.
  • Update des NTP-Pakets
    Das ESXi NTP-Paket wurde auf Version 4.2.8p9 aktualisiert.
  • Update der libcurl-Bibliothek
    Die libcurl-Bibliothek des ESXi-Benutzerbereichs wurde auf libcurl-7.51.0 aktualisiert.
Serverkonfigurationsprobleme

  • Die Verbindung zum ESXi-Host geht auf dem vCenter Server verloren, wenn das Hostprofil erneut auf einen statusfreien ESXi-Host angewendet wird
    Wenn ein Hostprofil mit vmknic-Adaptern in vSphere Standard Switch und vSphere Distributed Switch auf einen ESXi-Host angewendet wird, wird der vmknic-Adapter vmk0 (Verwaltungsschnittstelle) unter Umständen aus vSphere Standard Switch entfernt. Dies kann dazu führen, dass der Host vom vCenter Server getrennt wird.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Der hostd-Dienst schlägt unter Umständen fehl, wenn ein Stilllegungs-Snapshot erstellt wird
    Der hostd-Dienst schlägt unter Umständen fehl, wenn während der Replizierung ein Stilllegungs-Snapshot-Vorgang durchgeführt wird. Eine Fehlermeldung ähnlich der folgenden wird in der Datei „hostd.log“ angezeigt: 2016-06-10T22:00:08.582Z [37181B70 info 'Hbrsvc'] ReplicationGroup will retry failed quiesce attempt for VM (vmID=37) 2016-06-10T22:00:08.583Z [37181B70 panic 'Default'] --> -->Panic: Assert Failed: "0" @ bora/vim/hostd/hbrsvc/ReplicationGroup.cpp:2779

    Dieses Problem wurde in der vorliegenden Version behoben.

  • ESXi 6.0 Update 1-Hosts schlagen während der Erfassung von Statistiken unter Umständen mit einem violetten Diagnosebildschirm fehl
    ESXi-Hosts mit einer großen Anzahl an physischen CPUs reagieren während der Erfassung von Statistiken unter Umständen nicht mehr. Dieses Problem tritt auf, wenn bei der Erfassung auf Seiten zugegriffen wird, die außerhalb des anfänglich zugewiesenen Bereichs liegen.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Das Update des ESXi-Patchs schlägt unter Umständen mit einer Warnmeldung fehl, wenn das Image-Profil die festgelegte Größe überschreitet
    Die Installation eines ESXi-Patch-Updates schlägt unter Umständen fehl, wenn die Zielprofildatei größer als 239 MB ist. Dies kann passieren, wenn Sie das System unter Verwendung von ISO aktualisieren, wodurch Image-Profile mit mehr als 239 MB entstehen, ohne dass eine Warnmeldung ausgegeben wird. Hiermit wird verhindert, dass zusätzliche VIBs auf dem System installiert werden.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Die Datei vmkernel.log wird mit mehreren USB-Anhalte- und -Wiederaufnahmeereignissen überlastet
    Die Datei vmkernel.log wird durch mehrere USB-Anhalte- und -Wiederaufnahmeereignisse ähnlich den folgenden überlastet:

    YYYY-MM-DDT

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Die Benutzer- oder Gruppenliste für die Zuweisung von Berechtigungen wird auf der Registerkarte „Berechtigungen“ nicht angezeigt
    Die Benutzer- oder Gruppenliste für die Zuweisung von Berechtigungen wird auf der Registerkarte Berechtigungen nicht angezeigt, und die Authentifizierung für den Benutzer der vertrauenswürdigen Domäne schlägt unter Umständen fehl. Das Problem tritt auf, wenn sich der DNS-Domänenname einer Maschine vom DNS-Namen der AD-Domäne unterscheidet.

    Dieses Problem wurde in der vorliegenden Version behoben. Nach dem Upgrade des ESXi-Hosts auf ESXi 6.0 Update 3 müssen Sie den Host jedoch aus der AD-Domäne entfernen und derselben Domäne erneut hinzufügen.

  • Der ESXi-Host reagiert unter Umständen nicht mehr und zeigt einen violetten Diagnosebildschirm an
    Wenn die Dump-Dateigruppe mehrmals gleichzeitig mithilfe des Befehls esxcfg-dumppart oder anderer Befehle aufgerufen wird, reagiert ein ESXi-Host aufgrund einer Race-Bedingung während der Freigabe einer Dump-Blockzuordnung unter Umständen nicht mehr und zeigt einen violetten Diagnosebildschirm mit Einträgen ähnlich den folgenden an:

    @BlueScreen: PANIC bora/vmkernel/main/dlmalloc.c:4907 - Corruption in dlmalloc
    Code start: 0xnnnnnnnnnnnn VMK uptime: 234:01:32:49.087
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]PanicvPanicInt@vmkernel#nover+0x37e stack: 0xnnnnnnnnnnnn
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]Panic_NoSave@vmkernel#nover+0x4d stack: 0xnnnnnnnnnnnn
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]DLM_free@vmkernel#nover+0x6c7 stack: 0x8
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]Heap_Free@vmkernel#nover+0xb9 stack: 0xbad000e
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]Dump_SetFile@vmkernel#nover+0x155 stack: 0xnnnnnnnnnnnn
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]SystemVsi_DumpFileSet@vmkernel#nover+0x4b stack: 0x0
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSI_SetInfo@vmkernel#nover+0x41f stack: 0x4fc
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]UWVMKSyscallUnpackVSI_Set@ # +0x394 stack: 0x0
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]User_UWVMKSyscallHandler@ # +0xb4 stack: 0xffb0b9c8
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]User_UWVMKSyscallHandler@vmkernel#nover+0x1d stack: 0x0
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]gate_entry_@vmkernel#nover+0x0 stack: 0x0

    Dieses Problem wurde in der vorliegenden Version behoben.

Speicherprobleme
  • Veraltete Virtual Volume-Volumes und VMDK-Dateien können mithilfe des Befehls esxcli vvol abandonedvvol nicht entfernt werden
    Versuche, den Befehl esxcli storage vvol storagecontainer abandonedvvol zum Bereinigen des veralteten Virtual Volume-Volumes und der VMDK-Dateien zu verwenden, die auf dem Virtual Volume-Volume verbleiben, schlagen fehl.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Ein Abbruch der Snapshot-Erstellungsaufgabe für Virtual Volumes kann zu Datenverlust führen
    Versuche, die Snapshot-Erstellung für eine VM abzubrechen, deren VMDKs sich in Virtual Volumes-Datenspeichern befinden, haben unter Umständen zur Folge, dass ein Rollback der virtuellen Festplatten nicht ordnungsgemäß ausgeführt werden kann und es somit zu einem Datenverlust kommt. Diese Situation tritt auf, wenn eine virtuelle Maschine über mehrere VMDKs mit demselben Namen verfügt und diese aus verschiedenen Virtual Volumes-Datenspeichern stammen.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Das Rollback für VMDK wird nicht ordnungsgemäß ausgeführt, wenn die Snapshot-Erstellung für Virtual Volumes-VMs fehlschlägt
    Wenn die Snapshot-Erstellung für eine Virtual Volumes-VM fehlschlägt, wird die VMDK-Datei an ein falsches virtuelles Daten-Volume gebunden. Das Problem tritt nur dann auf, wenn die VMDK-Datei für die Virtual Volumes-VM aus mehreren Virtual Volumes-Datenspeichern stammt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • E/A-Vorgänge der VM kommen zum Stillstand oder werden abgebrochen, wenn der zugrunde liegende Speicher während periodischer VMFS-Taktsignale fälschlicherweise einen Vergleichsfehler zurückgibt.
    VMFS verwendet den SCSI-Befehl zum Vergleichen und Schreiben (auch als ATS bezeichnet) für periodische Taktsignale. Alle Vergleichsfehler während der ATS-Befehlsausführung werden als Taktsignalfehler behandelt und vom Datenspeicher wird eine Wiederherstellungsaktion initiiert. Um eine Beschädigung zu vermeiden, werden alle E/A-Vorgänge auf dem Gerät abgebrochen. Wenn der zugrunde liegende Speicher während der VMFS-Taktsignale fälschlicherweise Vergleichsfehler meldet, wird vom Datenspeicher eine unnötige Wiederherstellungsaktion initiiert.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • ESXi 6.x-Hosts reagieren nicht mehr, nachdem sie 85 Tage ausgeführt wurden
    Wenn dieses Problem auftritt, werden in der Protokolldatei /var/log/vmkernel Einträge ähnlich den folgenden angezeigt:

    YYYY-MM-DDTHH:MM:SS.833Z cpu58:34255)qlnativefc: vmhba2(5:0.0): Recieved a PUREX IOCB woh oo
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:34255)qlnativefc: vmhba2(5:0.0): Recieved the PUREX IOCB.
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674)qlnativefc: vmhba2(5:0.0): sizeof(struct rdp_rsp_payload) = 0x88
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674qlnativefc: vmhba2(5:0.0): transceiver_codes[0] = 0x3
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674)qlnativefc: vmhba2(5:0.0): transceiver_codes[0,1] = 0x3, 0x40
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674)qlnativefc: vmhba2(5:0.0): Stats Mailbox successful.
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674)qlnativefc: vmhba2(5:0.0): Sending the Response to the RDP packet
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674 0 1 2 3 4 5 6 7 8 9 Ah Bh Ch Dh Eh Fh
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674)--------------------------------------------------------------
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 53 01 00 00 00 00 00 00 00 00 04 00 01 00 00 10
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) c0 1d 13 00 00 00 18 00 01 fc ff 00 00 00 00 20
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 00 00 00 00 88 00 00 00 b0 d6 97 3c 01 00 00 00
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 0 1 2 3 4 5 6 7 8 9 Ah Bh Ch Dh Eh Fh
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674)--------------------------------------------------------------
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 02 00 00 00 00 00 00 80 00 00 00 01 00 00 00 04
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 18 00 00 00 00 01 00 00 00 00 00 0c 1e 94 86 08
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 0e 81 13 ec 0e 81 00 51 00 01 00 01 00 00 00 04
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 2c 00 04 00 00 01 00 02 00 00 00 1c 00 00 00 01
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 00 00 00 00 40 00 00 00 00 01 00 03 00 00 00 10
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 50 01 43 80 23 18 a8 89 50 01 43 80 23 18 a8 88
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 00 01 00 03 00 00 00 10 10 00 50 eb 1a da a1 8f

    Dieses Problem wird durch einen qlnativefc-Treiberfehler verursacht, der eine RDP-Antwort (Read Diagnostic Parameters) mit einer falschen Übertragungslänge an den HBA-Adapter sendet. Als Folge gibt die HBA-Adapter-Firmware den Speicher des Pufferpools nicht frei. Sobald der Pufferpool aufgebraucht ist, kann der HBA-Adapter keine weiteren Anfragen verarbeiten und steht dann nicht mehr zur Verfügung. Standardmäßig wird die RDP-Routine vom FC-Switch initiiert und einmal pro Stunde ausgeführt. Dies hat zur Folge, dass der Pufferpool unter normalen Umständen nach etwa 80 bis 85 Tagen aufgebraucht ist.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • In vSphere 6.0 stellt das Objekt HostMultipathStateInfoPath der Speicherrichtlinien-API den Pfadwert Run Time Name vmhbaX:CX:TX:LX bereit
    In ESXi 5.5 stellte das Objekt HostMultipathStateInfoPath Pfadinformationen in folgendem Format bereit: HostWWN-ArrayWWN-LUN_ID, z. B., sas.500605b0072b6550-sas.500c0ff1b10ea000-naa.600c0ff0001a20bd1887345701000000. In ESXi 6.0 wird der Pfadwert jedoch als vmhbaX:CX:TX:LX angezeigt, was Auswirkungen für Benutzer haben kann, die das Objekt HostMultipathStateInfoPath zum Abrufen von Informationen (z. B. HostWWN und ArrayWWN) verwenden.

    Dieses Problem wurde in der vorliegenden Version behoben. Im Objekt HostMultipathStateInfoPath werden die Pfadinformationen nun als „Run Time Name“ und HostWWN-ArrayWWN-LUN_ID angezeigt.

    Sie können auch den Befehl esxcli storage core path list verwenden, um die pfadbezogenen Informationen abzurufen. Dieser Befehl stellt die HostWWN- und ArrayWWN-Details bereit. Weitere Informationen finden Sie im Knowledgebase-Artikel 1003973.

  • Ein ESXi-Host schlägt unter Umständen mit einem violetten Diagnosebildschirm fehl
    Ein mit vFlash konfigurierter ESXi-Host schlägt unter Umständen mit einem violetten Diagnosebildschirm und einer Fehlermeldung ähnlich folgender fehl: PSOD: @BlueScreen: #PF Exception 14 in world 500252:vmx-vcpu-0:V.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • ESXi-Host schlägt aufgrund von Pfadbeanspruchungs-Konflikten mit einem violetten Diagnosebildschirm fehl
    Ein ESXi-Host zeigt einen violetten Diagnosebildschirm an, wenn er auf ein registriertes Gerät trifft, dessen Pfade von zwei Mehrfachpfad-Plug-Ins beansprucht werden, wie z. B. EMC PowerPath und dem NMP-Plug-In (Native Multipathing). Diese Art des Konflikts tritt auf, wenn eine Plug-In-Beanspruchungsregel den Pfad nicht beanspruchen kann und NMP den Pfad standardmäßig beansprucht. NMP versucht, das Gerät zu registrieren. Weil das Gerät aber bereits von dem anderen Plug-In registriert wurde, tritt eine Race-Bedingung auf, die wiederum den Ausfall des ESXi-Hosts auslöst.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Dateivorgänge in großen Dateien schlagen fehl, da auf dem Host nicht genügend Arbeitsspeicher zur Verfügung steht
    Wenn Sie Dateivorgänge durchführen, wie z. B. das Mounten großer in einem Datenspeicher enthaltener Dateien, schlagen diese Vorgänge auf einem ESXi-Host unter Umständen fehl. Diese Situation kann auftreten, wenn ein Arbeitsspeicherverlust im Puffer-Cache dazu führt, dass auf dem ESXi-Host nicht genügend Arbeitsspeicher zur Verfügung steht. Dies ist beispielsweise der Fall, wenn Puffer aufgrund einer Nicht-Null-Kopie von Daten nicht freigegeben werden. Auf der virtuellen Maschine wird eine Fehlermeldung ähnlich der folgenden angezeigt.

    Der Vorgang für Datei /vmfs/volumes/5f64675f-169dc0cb/CloudSetup_20160608.iso ist fehlgeschlagen. Wenn sich die Datei in einem Remote-Dateisystem befindet, stellen Sie sicher, dass die Netzwerkverbindung und der Server mit dem Datenträger ordnungsgemäß ausgeführt werden. Befindet sich die Datei auf einem Wechselmedium, schließen Sie das Medium erneut an. Wählen Sie „Wiederholen“ aus, um den Vorgang erneut auszuführen. Wählen Sie „Abbrechen“ aus, um diese Sitzung zu beenden. Wählen Sie „Fortsetzen“ aus, um den Fehler an das Gastbetriebssystem weiterzuleiten.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Der Horizon View-Neuzusammenstellungs-Vorgang schlägt unter Umständen für Desktop-VMs fehl, die sich in einem NFS-Datenspeicher befinden
    Der Horizon View-Neuzusammenstellungs-Vorgang schlägt unter Umständen für bestimmte Desktop-VMs, die sich in einem NFS-Datenspeicher befinden, mit dem Fehler Veraltetes NFS-Datei-Handle fehl.

    Dieses Problem wurde in der vorliegenden Version behoben.

Upgrade- und Installationsprobleme
  • Das Upgrade von ESXi mit vSphere Update Manager schlägt fehl, wenn ESXi unter Verwendung von dd-Image auf USB bereitgestellt wurde und /altbootbank den Wert BOOT.CFG in Großbuchstaben enthält
    Ein ESXi-dd-Image, das in bestimmten RHEL-Versionen mithilfe des Dienstprogramms esxiso2dd erzeugt wurde, kann BOOT.CFG in Großbuchstaben in /altbootbank enthalten. Wenn BOOT.CFG in Großbuchstaben vorliegt, kann vSphere Update Manager den Host nicht aktualisieren, weil bei der Vorüberprüfung des Upgrades boot.cfg nur in Kleinbuchstaben akzeptiert wird.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Hostd schlägt fehl, wenn Sie ESXi 5.5.x-Hosts mit dem ESXi 6.0-Patch ESXi600-201611011 oder höher auf ESXi 6.0.x aktualisieren
    Sie können dieses Problem beobachten, wenn Sie einen asynchronen HPSA-Treiber installiert haben, der den HBA-Modus unterstützt. Obwohl ESXi das Abrufen von Informationen zum HPSA-Festplattenspeicherort im HBA-Modus unterstützt, kann es unter Umständen zu Problemen kommen, wenn eine der folgenden Bedingungen erfüllt ist:

    • Sie haben ein altes hpssacli-Dienstprogramm, Version 2.10.14.0 oder niedriger, installiert.
    • Sie haben ein externes Array für die Verbindung zum HPSA-Controller verwendet.

    Diese Probleme führen zu hostd-Ausfällen, wodurch vSphere Client und vCenter Server den Host nicht mehr erreichen können.

    Dieses Problem wurde in der vorliegenden Version behoben. Wenn Sie den esxcli-Befehl nun zum Abrufen der Informationen zum Festplattenspeicherort verwenden, schlägt hostd nicht fehl. Der esxcli-Befehl gibt eine Fehlermeldung ähnlich der folgenden zurück:

    # esxcli storage core device physical get -d naa.500003963c888808 Plugin lsu-hpsa-plugin cannot get information for device with name naa.500003963c888808. Error was: Invalid output for physicaldrive.

  • Das mit dd-Image auf USB gestartete vSphere Update Manager-Upgrade von ESXi schlägt unter Umständen fehl, wenn /altbootbank den Wert BOOT.CFG (Großbuchstaben) statt des Werts boot.cfg (Kleinbuchstaben) enthält
    Das auf verschiedenen RHEL-Versionen mithilfe des Dienstprogramms esxiso2dd erzeugte ESXi-dd-Image enthält BOOT.CFG(in Großbuchstaben)in /altbootbank. Das Vorhandensein von BOOT.CFG hat zur Folge, dass das vSPhere Update Manager-Upgrade von ESXi fehlschlägt, weil bei der Vorüberprüfung des Upgrades ausschließlich nach boot.cfg in Kleinbuchstaben gesucht wird.
  • Dieses Problem wurde in der vorliegenden Version behoben.

  • Nach dem Upgrade auf Version 6.0 wird der Name des Image-Profils auf der Registerkarte „Übersicht“ des Hosts nicht ordnungsgemäß aktualisiert
    Wenn Sie den Befehl esxcli software profile update ausführen, um ein neues Image-Profil anzuwenden, ändert sich der Name des Image-Profils nicht in den Namen des neuen Image-Profils. Wenn Sie das ISO-Image zum Durchführen des Upgrades verwenden, wird der Name des neuen Image-Profils nicht als Aktualisiert gekennzeichnet.

    Dieses Problem wurde in der vorliegenden Version behoben.

Probleme bei vCenter Server, vSphere Web Client und vSphere Client
  • Neues Problem vSphere Web Client führt bestimmte Vorgänge langsam aus
    Der Abschluss bestimmter Vorgänge im vSphere Web Client nimmt viel Zeit in Anspruch, und es werden Änderungen an der Konfiguration angezeigt. Dieses Problem kann auftreten, wenn Storage I/O Control für einige oder alle Datenspeicher in einer mittelgroßen bis großen vCenter Server-Bestandsliste aktiviert ist. Weitere Informationen zu dem Problem finden Sie unter KB 2146935.

    Dieses Problem wurde in der vorliegenden Version behoben.

VM-Verwaltungsprobleme
  • vSphere Update Manager sendet Neustarterinnerungen für VMware Tools, obwohl nach der Installation bereits ein Neustart stattgefunden hat
    Gemäß dem Fehlercode der VMware Tools-Installation muss ein Neustart durchgeführt werden, obwohl nach der Installation von VMware Tools bereits ein Neustart stattgefunden hat. Die Variable guestInfo.toolsInstallErrCode auf der VMX-Seite (Virtual Machine Executable) wird nicht gelöscht, wenn VMware Tools erfolgreich installiert und ein Neustart stattfindet. Hierdurch wird vSphere Update Manager veranlasst, falsche Erinnerungen zum Neustart von VMware Tools zu senden.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Hostd schlägt fehl, wenn ListProcesses auf dem Gastbetriebssystem ausgeführt werden
    Wenn auf einem Gastbetriebssystem ein große Anzahl an Prozessen vorhanden ist, wird der ListProcesses-Prozess mehrmals aufgerufen und die Daten aus VMware Tools treffen in mehreren Blöcken ein. Wenn mehrere ListProcesses-Aufrufe an das Gastbetriebssystem (einer pro Block) zusammengefasst werden, kommt es bei der Implementierung zu einem Konflikt. Mehrere ListProcesses werden identifiziert, wenn alle Daten eingetroffen sind, und rufen einen Callback-Handler auf. Zweimaliges Aufrufen des Handlers hat den Ausfall von hostd zur Folge.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Datenbeschädigung oder Datenverlust möglich, wenn ein Gastbetriebssystem SCSI-UNMAP-Befehle ausgibt und ein E/A-Filter den UNMAP-Vorgang verhindert
    Wenn die virtuelle Festplatte einer VM mit E/A-Filtern konfiguriert ist und das Gastbetriebssystem SCSI-UNMAP-Befehle ausgibt, werden diese unter Umständen erfolgreich ausgeführt, selbst wenn einer der konfigurierten E/A-Filter fehlschlägt. Folglich weicht der in der VMDK-Datei angezeigte Status von dem des E/A-Filters ab und Datenbeschädigung oder -verlust werden unter Umständen auf dem Gastbetriebssystem angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Ein ESXi-Host schlägt unter Umständen mit einem violetten Diagnosebildschirm fehl
    Wenn mit einem DVFilter_TxCompletionCB()-Vorgang versucht wird, ein freigegebenes dvfilter-Speicherpaket abzuschließen, wird das im Paket gespeicherte vollständige E/A-Datenmitglied freigegeben. In bestimmten Fällen wird diesem Datenmitglied der Wert 0 zugewiesen, wodurch es zu einer NULL-Zeiger-Ausnahme kommt. Eine Fehlermeldung ähnlich der folgenden wird angezeigt:

    YYYY-MM-DDT04:11:05.134Z cpu24:33420)@BlueScreen: #PF Exception 14 in world 33420:vmnic4-pollW IP 0x41800147d76d addr 0x28 PTEs:0x587e436023;0x587e437023;0x587e438023;0x0; YYYY-MM-DDT04:11:05.134Z cpu24:33420)Code start: 0x418000800000 VMK uptime: 23:18:59:55.570 YYYY-MM-DDT04:11:05.135Z cpu24:33420)0x43915461bdd0:[0x41800147d76d]DVFilterShmPacket_TxCompletionCB@com.vmware.vmkapi#v2_3_0_0+0x3d sta YYYY-MM-DDT04:11:05.135Z cpu24:33420)0x43915461be00:[0x41800146eaa2]DVFilterTxCompletionCB@com.vmware.vmkapi#v2_3_0_0+0xbe stack: 0x0 YYYY-MM-DDT04:11:05.136Z cpu24:33420)0x43915461be70:[0x418000931688]Port_IOCompleteList@vmkernel#nover+0x40 stack: 0x0 YYYY-MM-DDT04:11:05.136Z cpu24:33420)0x43915461bef0:[0x4180009228ac]PktListIOCompleteInt@vmkernel#nover+0x158 stack: 0x0 YYYY-MM-DDT04:11:05.136Z cpu24:33420)0x43915461bf60:[0x4180009d9cf5]NetPollWorldCallback@vmkernel#nover+0xbd stack: 0x14 YYYY-MM-DDT04:11:05.137Z cpu24:33420)0x43915461bfd0:[0x418000a149ee]CpuSched_StartWorld@vmkernel#nover+0xa2 stack: 0x0

    Dieses Problem wurde in der vorliegenden Version behoben.

  • ESXi-Host mit PCI-Passthrough reagiert unter Umständen nicht mehr und zeigt einen violetten Diagnosebildschirm an
    Wenn Sie eine VM mit PCI-Passthrough mehrmals neu starten, reagiert der ESXi-Host unter Umständen nicht mehr und zeigt einen violetten Diagnosebildschirm mit Meldungen ähnlich der folgenden in der Datei vmware.log an:

    XXXXXXXXXXXXXXX| vcpu-0| W110: A core file is available in " /vmx-debug-zdump.000"
    XXXXXXXXXXXXXXX| vcpu-0| I120: Msg_Post: Error
    XXXXXXXXXXXXXXX| vcpu-0| I120: [msg.log.error.unrecoverable] VMware ESX
    XXXXXXXXXXXXXXX| vcpu-0| unrecoverable error: (vcpu-0)
    XXXXXXXXXXXXXXX| vcpu-0| I120+ vcpu-7:ASSERT vmcore/vmm/intr/intr.c:459

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Der Hostd-Dienst schlägt während des Replizierungsvorgangs unter Umständen fehl
    Der hostd-Dienst schlägt unter Umständen fehl, wenn während der Replizierung ein Stilllegungs-Snapshot-Vorgang fehlschlägt. Eine Fehlermeldung ähnlich der folgenden wird unter Umständen in die Protokolldatei hostd.log geschrieben:

    YYYY-MM-DDT22:00:08.582Z [37181B70 info 'Hbrsvc'] ReplicationGroup will retry failed quiesce attempt for VM (vmID=37)
    YYYY-MM-DDT22:00:08.583Z [37181B70 panic 'Default']
    -->
    --> Panic: Assert Failed: "0" @ bora/vim/hostd/hbrsvc/ReplicationGroup.cpp:2779

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Der hostd-Dienst reagiert unter Umständen nicht mehr, wenn E/A-Fehler bei einer VM auftreten, die mit einem virtuellen LSI-SCSI-Controller bereitgestellt wird
    Ein ESXi-Host reagiert unter Umständen nicht mehr, wenn E/A-Speicherfehler bei einer mit einem virtuellen LSI-Controller bereitgestellten VM auftreten und der Arbeitsspeicher auf dem ESXi-Host überbelegt ist.

    Dieses Problem wurde in der vorliegenden Version behoben.

Virtual SAN-Probleme
  • Neues Problem Eine virtuelle Maschine, die Virtual SAN-Speicher verwendet, wird möglicherweise langsam oder reagiert nicht mehr. Und es tritt möglicherweise ein Virtual SAN-Hostverwaltungsfehler auf, wenn der Host in den Wartungsmodus versetzt wird oder eine Richtlinie in einem Virtual SAN-Cluster neu konfiguriert wird
    Dieses Problem kann auftreten, wenn sich in der Cache-Schicht der Virtual SAN-Festplattengruppe Null-Daten ansammeln und die Verarbeitung der Null-Daten zu einem Protokollstau führt. Ein solcher Protokollstau kann bei virtuellen Maschinen, die Virtual SAN-Speicher verwenden, zu einer Verlangsamung der E/A-Vorgänge und zu einem Virtual SAN-Hostverwaltungsfehler führen. Dieses Problem tritt nur auf den vSAN-Clustern auf, für die Deduplizierung und Komprimierung aktiviert sind.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Periodisch auftretende Fehler im Zusammenhang mit der Bereitstellung in Virtual SAN-Clustervorgängen oder als Folge der Erstellung neuer Objekte
    Ein Arbeitsspeicherverlust im Cluster Level Object Manager Daemon (CLOMD) führt langfristig zu einem Speicherplatzmangel, wodurch der Daemon phasenweise nicht verfügbar ist.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • DOM-Modul kann nicht initialisiert werden
    Beschreibung: Der CLOMD (Cluster Level Object Manager Daemon)verwendet Virtual SAN unter Umständen nicht auf einem ESXi-Host mit zahlreichen physischen CPUs. Dieses Problem kann auftreten, wenn das Virtual SAN-DOM-Modul beim Beitritt zu einem Cluster nicht initialisiert werden kann.

    Eine Fehlermeldung ähnlich der folgenden wird in der Datei „clomd.log“ angezeigt:

    2016-12-01T22:34:49.446Z 2567759 Failed to run VSI SigCheck: Failure 2016-12-01T22:34:49.446Z 2567759 main: Clomd is starting 2016-12-01T22:34:49.446Z 2567759 main: Is in stretched cluster mode? No 2016-12-01T22:34:49.446Z 2567759 CLOMSetOptions: Setting forground to TRUE 2016-12-01T22:34:49.446Z 2567759 CLOMSetOptions: No default configuration specified. 2016-12-01T22:34:49.447Z 2567759 main: Starting CLOM trace 2016-12-01T22:34:49.475Z 2567759 Cannot open DOM device /dev/dom: No such file or directory 2016-12-01T22:34:49.475Z 2567759 Cannot connect to DOM: Failure 2016-12-01T22:34:49.475Z 2567759 CLOM_CleanupRebalanceContext: Cleaning up rebalancing state 2016-12-01T22:34:49.481Z 2567759 Failed to dump data 2016-12-01T22:34:49.481Z 2567759 2016-12-01T22:34:49.481Z 2567759 main: clomd exit

    Dieses Problem wurde in der vorliegenden Version behoben.

  • ESXi-Host kann dem VMware Virtual SAN-Cluster nach einem Neustart nicht erneut beitreten
    Versuche, dem VMware Virtual SAN-Cluster nach einen Neustart manuell erneut beizutreten, schlagen unter Umständen mit folgendem Fehler fehl:

    Fehler beim Beitreten des Hosts im VSAN-Cluster (vsantraced konnte nicht gestartet werden(Rückgabecode 2)

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Konstantes Aufrufen der VSAN-API kann unter Umständen zur Anzeige einer irreführenden Aufgabenmeldung führen:
    In einer Umgebung mit vCenter Server 6.0 Update 2 und Virtual SAN 6.2 führt das konstante Aufrufen der VSAN-API zur Erstellung von Aufgaben zum Registrieren eines Tickets für den Virtual SAN-VASA-Anbieter. Eine Meldung ähnlich der folgenden wird angezeigt:

    Ticket zum Registrieren des Virtual SAN-VASA-Anbieters abrufen

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Aufgabe zur Neuverteilung des Virtual SAN-Datenträgers stoppt seit mehr als 24 Stunden bei 5 %
    Der Virtual SAN Health Service gibt Warnungen zur Virtual SAN-Datenträgerverteilung im vSphere Web Client aus. Wenn Sie auf Datenträger neu verteilen klicken, scheint die Aufgabe seit mehr als 24 Stunden bei 5 % zu stoppen.

    Dieses Problem wurde in der vorliegenden Version behoben. Die Aufgabe Datenträger neu verteilen wird nach 24 Stunden als abgeschlossen angezeigt.

  • Der ESXi-Host reagiert unter Umständen nicht mehr und zeigt einen violetten Diagnosebildschirm an
    Ein ESXi-Host reagiert möglicherweise nicht mehr und zeigt einen violetten Diagnosebildschirm mit Meldungen ähnlich den folgenden an:

    YYYY-MM-DDT22:59:29.686Z cpu40:84493)@BlueScreen: #PF Exception 14 in world 84493:python IP 0xnnnnnnnnnnnn addr 0xfffffffffffffff0 PTEs:0x0;
    YYYY-MM-DDT22:59:29.686Z cpu40:84493)Code start: 0xnnnnnnnnnnnn VMK uptime: 07:15:08:48.373
    YYYY-MM-DDT22:59:29.686Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]DOMClient_IsTopObject@com.vmware.vsan#0.0.0.1+0x18 stack: 0xnnnnnnnn
    YYYY-MM-DDT22:59:29.687Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]DOMListUuidTopHierarchyCbk@com.vmware.vsan#0.0.0.1+0x69 stack: 0x900
    YYYY-MM-DDT22:59:29.687Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSANUUIDTable_Iterate@com.vmware.vsanutil#0.0.0.1+0x4b stack: 0x139d
    YYYY-MM-DDT22:59:29.687Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]DOMVsi_ListTopClients@com.vmware.vsan#0.0.0.1+0x5a stack: 0x66
    YYYY-MM-DDT22:59:29.688Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSI_GetListInfo@vmkernel#nover+0x354 stack: 0xnnnnnnnnnnnn
    YYYY-MM-DDT22:59:29.688Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]UWVMKSyscallUnpackVSI_GetList@#+0x216 stack: 0xnnnnnnnnn
    YYYY-MM-DDT22:59:29.688Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]User_UWVMKSyscallHandler@#+0xb4 stack: 0xnnnnnnn
    YYYY-MM-DDT22:59:29.689Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]User_UWVMKSyscallHandler@vmkernel#nover+0x1d stack: 0x0
    YYYY-MM-DDT22:59:29.689Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]gate_entry_@vmkernel#nover+0x0 stack: 0x0

    Dieses Problem wurde in der vorliegenden Version behoben.

  • ESXi-Hosts schlagen unter Umständen mit einem violetten Diagnosebildschirm fehl
    ESXi-Hosts in einem Virtual SAN-Cluster schlagen unter Umständen mit einem violetten Diagnosebildschirm fehl, wenn ein Vorgang zur Neusynchronisierung von Virtual SAN angehalten wird.

    Dieses Problem wurde in der vorliegenden Version behoben.

VMware HA- und Fault Tolerance-Konfigurationsprobleme
  • Ein ESXi-Host schlägt unter Umständen fehl, wenn Fault Tolerance auf einer VM aktiviert wird
    Ein ESXi-Host schlägt unter Umständen mit einem violetten Diagnosebildschirm fehl, wenn eine sekundäre Fault Tolerance-VM nicht hochgefahren werden kann.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Das vSphere Gastanwendungs-Überwachungs-SDK schlägt für VMs mit aktivierter vSphere Fault Tolerance fehl
    Wenn vSphere FT auf einer vSphere HA-geschützten VM aktiviert ist, auf der die vSphere Gastanwendungs-Überwachung installiert ist, schlägt das Gastanwendungs-Überwachungs-SDK unter Umständen fehl.

    In dieser Version wird die Zunahme der Netzwerklatenz von VMs bei aktivierter Fault Tolerance erheblich reduziert.

  • Erhöhte Latenz, wenn SMP Fault Tolerance auf einer VM aktiviert ist
    Wenn SMP Fault Tolerance (Symmetric Multiprocessor) auf einer VM aktiviert ist, können Durchschnitt und Varianz der Netzwerklatenz der VM erheblich steigen. Erhöhte Latenz kann zu starken Leistungseinbußen oder Instabilität bei VM-Arbeitslasten führen, die empfindlich auf derartige Latenzsteigerungen reagieren.

    In dieser Version wird die Zunahme der Netzwerklatenz von VMs bei aktivierter Fault Tolerance erheblich reduziert.

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.

  • Versuche, mit dem Befehl „esxcli software vib update“ von ESXi 6.x auf 6.0 Update 2 und höher 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

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

Virtual SAN-Probleme

  • Neues Problem Systemzustands-UI von Virtual SAN wird aufgrund einer Zeitüberschreitung nicht angezeigt
    Wenn Sie unter Virtual SAN-Cluster > Monitor > Virtual SAN > Systemzustand auf die Systemzustands-UI von Virtual SAN zugreifen, wird die UI (Benutzeroberfläche) nicht angezeigt. Es ist möglich, dass vSphere ESX Agent Manager nicht mehr reagiert und es somit zu einer Zeitüberschreitung kommt. Öffnen Sie zur Bestätigung das Systemzustandsprotokoll von Virtual SAN unter /var/log/vmware/vsan-health/vmware-vsan-health-service.log und suchen Sie mithilfe der Zeichenfolge VsanEamUtil.getClusterStatus: nach Aufrufen des vSphere ESX Agent Manager-Diensts.

    Problemumgehung: Starten Sie den vSphere ESX Agent Manager-Dienst mithilfe des vSphere Web Client neu und aktualisieren Sie die Systemzustands-UI von Virtual SAN.

  • Neues Problem Virtual SAN-Festplatten sind nicht betriebsfähig, wenn lsi_msgpt3-Treiber von Drittanbietern verwendet werden
    Die Zustandsprüfung eines aus zwei oder drei Knoten bestehenden Virtual SAN-Clusters zeigt nach einem weiteren Hostfehler unter Virtual SAN-Cluster > Monitor > Virtual SAN > Systemzustand > Grenzwertintegrität Rot und löst ein falsches vCenter Server-Ereignis oder einen falschen Alarm aus, sobald die Speicherplatzbelegung 50 % überschreitet.

    Problemumgehung: Fügen Sie dem Virtual SAN-Cluster weitere Datenträger und mindestens einen Host hinzu, um die Speicherplatzbelegung des Clusters auf unter 50 % zu senken.

  • Neues Problem Die Überprüfung der Grenzwertintegrität eines aus zwei oder drei Knoten bestehenden Virtual SAN-Clusters zeigt Rot
    Das Plug-In für die Betriebsfähigkeit von Virtual SAN-Datenträgern, Lsu-lsi-lsi-msgpt3-plugin, unterstützt den Vorgang zum Abrufen des Gerätespeicherorts sowie zum Ein- und Ausschalten der Datenträger-LED. Der mitgelieferte VMware-Treiber lsi_msgpt3 unterstützt das Betriebsfähigkeits-Plug-In. Wenn Sie jedoch einen asynchronen Drittanbietertreiber verwenden, funktioniert das Plug-In nicht.

    Problemumgehung: Verwenden Sie den mitgelieferten VMware-Treiber lsi_msgpt3, Version 06.255.10.00-2vmw oder höher.

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

  • Auf Hosts mit ESXi 6.0 Update 2, die mit Speicher-Arrays mit einer bestimmten Firmware-Version verbunden sind, 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.