Versionshinweise zu VMware ESXi 6.0 Update 1a

|

Aktualisiert am: 6. Oktober 2015

ESXi 6.0 Update 1a | 6. Oktober 2015 | ISO Build 3073146

Ü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

Die vorliegende Version von VMware ESXi weist folgende Verbesserungen auf:

  • E/A-Filter: vSphere APIs für E/A-Filter (VAIO) liefern ein Framework, mit dessen Hilfe Drittanbieter als E/A-Filter bezeichnete Softwarekomponenten erstellen können. Die Filter können auf ESXi-Hosts installiert werden und können virtuellen Maschinen zusätzliche Datendienste anbieten, indem E/A-Anforderungen verarbeitet werden, die zwischen dem Gastbetriebssystem einer virtuellen Maschine und virtuellen Festplatten verschoben werden.

  • Exklusive Affinität zu zusätzlichen Systemkontexten im Zusammenhang mit einer virtuellen Maschine mit niedriger Latenz: Neu in dieser Version ist die VMX-Option sched.cpu.latencySensitivity.sysContexts, um Probleme in vSphere 6.0 zu beheben, wo es sich bei Systemkontexten noch weitgehend um Worldlets handelt. Der Scheduler nutzt die Option sched.cpu.latencySensitivity.sysContexts für jede virtuelle Maschine, um eine Systemkontextgruppe, die möglicherweise an den latenzempfindlichen Arbeitslasten beteiligt ist, automatisch zu identifizieren. Für jeden Systemkontext wird die exklusive Affinität zu einem eigens dafür vorgesehenen physischen Kern hergestellt. Die VMX-Option sched.cpu.latencySensitivity.sysContexts gibt an, wie viele exklusive Kerne für eine virtuelle Maschine mit niedriger Latenz für die Systemkontexte möglich sind.

  • ESXi-Authentifizierung für Active Directory:Änderungen an ESXi haben dazu geführt, dass nur noch AES256-CTS/AES128-CTS/RC4-HMAC-Verschlüsselung für die Kerberos-Kommunikation zwischen ESXi und Active Directory unterstützt wird.

  • Unterstützung für SSLv3: Unterstützung für SSLv3 wurde standardmäßig deaktiviert. Weitere Details finden Sie im Knowledgebase-Artikel 2121021.

  • Dying Disk Handling (DDH): Die Funktion Dying Disk Handling bietet ein Framework zur Latenzüberwachung im Kernel, einen Daemon zum Erkennen von Phasen hoher Latenz und einen Mechanismus zum Unmounten einzelner Festplatten und Festplattengruppen.

  • Ausgeweitete Cluster: Virtual SAN 6.0 Update 1 unterstützt ausgeweitete Cluster, die sich über zwei geografisch getrennte Standorte erstrecken, um Daten vor Site-Ausfällen und dem Verlust der Netzwerkverbindung zu schützen.

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.

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

ESXi600-201510401-BG: Aktualisiert ESXi 6.0 esx-base vib

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

ESXi-6.0.0-20151004001-standard
ESXi-6.0.0-20151004001-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
  • ServerView-CIM-Anbieter kann den Hardwarestatus nicht überwachen, wenn der Emulex-CIM-Anbieter auf demselben ESXi-Host installiert ist
    Wenn der ServerView-CIM-Anbieter und der Emulex-CIM-Anbieter auf demselben ESXi-Host installiert sind, reagiert der Emulex-CIM-Anbieter (sfcb-emulex_ucn) möglicherweise nicht, weshalb der Hardwarestatus nicht überwacht werden kann.

    Dieses Problem wurde in der vorliegenden Version behoben.
Gastbetriebssystem-Probleme
  • Ein über EFI gestartetes Linux-Gastbetriebssystem reagiert möglicherweise nicht auf Tastatur- und Mauseingaben
    Ein auf einer EFI-Firmware gestartetes Linux-Gastbetriebssystem reagiert möglicherweise nicht auf Tastatur- und Mauseingaben, wenn eine Mausbewegung während der kurzen EFI-Startzeit stattfindet.

    Dieses Problem wurde in der vorliegenden Version behoben.

Upgrade- und Installationsprobleme
  • Das Anwenden eines Hostprofils bei aktiviertem statusfreiem Caching auf dem statusfreien ESXi-Host dauert möglicherweise sehr lange
    Das Anwenden eines Hostprofils auf einem statusfreien ESXi-Host mit einer großen Anzahl von Speicher-LUNs dauert möglicherweise sehr lange, wenn Sie das statusfreie Caching mit esx als Argument für die erste Festplatte aktivieren. Dies passiert, wenn Sie ein Hostprofil manuell oder während des Neustarts des Hosts anwenden.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Die Installation von bzw. das Upgrade auf VMware Tools 9.10.0 ist für die niederländische Version von Windows Server 2008 R2 nicht möglich
    Versuche, eine Installation von bzw. ein Upgrade auf VMware Tools 9.10.0 (im Lieferumfang von ESXi 6.0 enthalten) durchzuführen, schlagen für die niederländische Version von Windows Server 2008 R2 möglicherweise fehl. Eine Fehlermeldung ähnlich der folgenden wird angezeigt:

    VMware Tools-Setup-Assistent wurde vorzeitig beendet

    Dieses Problem wurde in der vorliegenden Version behoben.

  • VIB-Bereitstellungsvorgang führt möglicherweise nach dem Neustart eines ESXi-Hosts zum Verlust der VIB-Installation oder Konfigurationsänderung
    Wenn VIBs im System installiert sind, erstellt „esxupdate“ ein neues Image in /altbootbank und ändert den zu aktualisierenden Boot-Status für /altbootbank boot.cfg. Wenn ein installierbares Live-VIB installiert ist, wird die Konfigurationsänderung in /altbootbank gespeichert. Der Bereitstellungsvorgang löscht den Inhalt von /altbootbank, außer Sie führen im Anschluss an den Bereitstellungsvorgang einen Standardisierungsvorgang aus. Die VIB-Installation geht möglicherweise verloren, wenn Sie den Host im Anschluss an einen Bereitstellungsvorgang neu starten.

    Dieses Problem wurde in der vorliegenden Version behoben.

Netzwerkprobleme
  • Versuche, eine vmnic zu einem ESXi-Host auf VDS hinzuzufügen, schlagen mit der Fehlermeldung „Nicht unterstützte Adressfamilie“ fehl
    Nachdem Sie ein Upgrade von ESXi 5.5 auf ESXi 6.0 durchgeführt haben, schlagen möglicherweise Versuche fehl, eine vmnic zu einem mit einem vSphere Distributed Switch (VDS) verbundenen VMware ESXi-Host hinzuzufügen. Dieses Problem tritt auf, wenn ipfix aktiviert und IPv6 deaktiviert ist.

    Die Protokolldatei /var/log/vmkernel.log auf dem betroffenen ESXi-Host enthält solche oder ähnliche Einträge:

    cpu10:xxxxx opID=xxxxxxxx)WARNING: Ipfix: IpfixActivate:xxx: Activation failed for 'DvsPortset-1': Nicht unterstützte Adressfamilie
    cpu10:xxxxx opID=xxxxxxxx)WARNING: Ipfix: IpfixDVPortParamWrite:xxx: Configuration failed for switch DvsPortset-1 port xxxxxxxx: Nicht unterstützte Adressfamilie
    cpu10:xxxxx opID=xxxxxxxx)WARNING: NetDVS: xxxx: failed to init client for data com.vmware.etherswitch.port.ipfix on port xxx
    cpu10:xxxxx opID=xxxxxxxx)WARNING: NetPort: xxxx: failed to enable port 0x4000002: Nicht unterstützte Adressfamilie
    cpu10:xxxxx opID=xxxxxxxx)NetPort: xxxx: disabled port 0x4000002
    cpu10:xxxxx opID=xxxxxxxx)Uplink: xxxx: vmnic2: Failed to enable the uplink port 0x4000002: Nicht unterstützte Adressfamilie

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Virtuelle Maschinen, die den virtuellen VMXNET3-Adapter verwenden, schlagen möglicherweise beim Starten von iPXE fehl
    Virtuelle Maschinen, die den virtuellen VMXNET3-Adapter verwenden, können möglicherweise nicht von iPXE (Open Source-Boot-Firmware) gestartet werden.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Failover wird nicht gestartet, wenn bei Verwendung des Lastausgleichs basierend auf der physischen Netzwerkkartenauslastung ein Uplink getrennt oder heruntergefahren wird
    Wenn bei Verwendung des Lastausgleichs basierend auf der physischen Netzwerkkartenauslastung auf VDS 6.0 einer der Uplinks getrennt oder heruntergefahren wird, erfolgt kein Failover.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Wenn vmk10 oder höher für vMotion aktiviert ist, wird möglicherweise beim Neustart vMotion für vmk1 aktiviert
    Die Aktivierung von vMotion auf vmk10 oder höher bewirkt möglicherweise, dass für vmk1 beim Neustart des ESXi-Hosts vMotion aktiviert wird. Dieses Problem kann zu hohem Datenverkehr über vmk1 und zu Netzwerkproblemen führen.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Datenmetriken der Netzwerkleistung für eine virtuelle Maschine sind für eine VM, für die ein mit einem Standard-vSwitch verbundener VMXNET3-Adapter konfiguriert ist, nicht verfügbar
    Das Echtzeit-Leistungsdiagramm für das Netzwerk einer virtuellen Maschine, für die ein VMXNET3-Adapter in VMware vSphere Client 6.0 konfiguriert ist, kann nicht angezeigt werden, da die Option in der Dropdown-Liste Wechseln zu nicht verfügbar ist.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Netzwerkkonnektivität wird beim Anwenden des Hostprofils während der Ausführung von Auto Deploy unterbrochen
    Beim Anwenden des Hostprofils während der Ausführung von Auto Deploy wird möglicherweise die Netzwerkkonnektivität unterbrochen, da die VTEP-Netzwerkkarte (VXLAN Tunnel Endpoint) als Verwaltungs-vmknic gekennzeichnet wird.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Die Verbindung eines verschachtelten ESXi-Hosts wird möglicherweise unterbrochen und die virtuelle Netzwerkkarte e1000e wird möglicherweise zurückgesetzt
    Die Verbindung eines verschachtelten ESXi-Hosts wird möglicherweise zeitweise unterbrochen und die virtuelle Netzwerkkarte e1000e wird möglicherweise zurückgesetzt. Eine All Paths Down (APD)-Bedingung für NFS-Volumes kann auch auftreten. Eine Fehlermeldung ähnlich der folgenden wurde in die Datei vmkernel.log geschrieben:

    Der Paketübertragungsabschluss bleibt hängen, der Vorgang wird zurückgesetzt

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Neues Problem Probleme mit der Netzwerkkonnektivität nach dem Upgrade von ESXi 5.x auf ESXi 6.0
    Nachdem Sie ein Upgrade von ESXi 5.x auf ESXi 6.0 ausgeführt haben, können folgende Probleme auftreten:

    • Die Verbindung des ESXi 6.0-Host wird möglicherweise zeitweise unterbrochen.

    • Der ESXi 6.0-Host reagiert nicht mehr und kann ohne einen Neustart nicht mehr verwaltet werden.

    • Nach dem Neustart ist das Problem vorübergehend behoben, es tritt nach einer willkürlichen Zeitspanne jedoch wieder auf.

    • Vom NETDEV WATCHDOG-Dienst auf dem ESXi-Host werden häufig Zeitüberschreitungen bei der Übertragung protokolliert. Die Datei /var/log/vmkernel.log enthält solche oder ähnliche Einträge:

      cpu0:33245)WARNING: LinNet: netdev_watchdog:3678: NETDEV WATCHDOG: vmnic0: transmit timed out
      cpu0:33245)WARNING: at vmkdrivers/src_92/vmklinux_92/vmware/linux_net.c:3707/netdev_watchdog() (inside vmklinux)

    • Das Problem kann Auswirkungen auf mehrere Netzwerkadaptertypen verschiedener Hardwareanbieter haben. Der genaue Wortlaut der Protokollierung bei einer Zeitüberschreitung während der Übertragung kann je nach Karte variieren.

    Dieses Problem wurde in der vorliegenden Version behoben.

Speicherprobleme
  • Der ESXi-Host schlägt möglicherweise mit einem violetten Diagnosebildschirm fehl, wenn einer VM-Festplatte mehrere vSCSI-Filter zugeordnet sind
    Ein ESXi 6.0-Host schlägt möglicherweise mit einem violetten Diagnosebildschirm fehl, wenn einer VM-Festplatte mehrere vSCSI-Filter zugeordnet sind. Der violette Diagnosebildschirm oder die Rückverfolgung enthält Einträge ähnlich den Folgenden:

    cpu24:nnnnnn opID=nnnnnnnn)@BlueScreen: #PF Exception 14 in world 103492:hostd-worker IP 0x41802c2c094d addr 0x30
    PTEs:0xnnnnnnnn;0xnnnnnnnnnn;0x0;
    cpu24:nnnnnn opID=nnnnnnnn)Code start: 0xnnnnnnnnnnnn VMK uptime: 21:06:32:38.296
    cpu24:nnnnnn opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSCSIFilter_GetFilterPrivateData@vmkernel#nover+0x1 stack: 0xnnnnnnn
    cpu24:nnnnnn opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSCSIFilter_IssueInternalCommand@vmkernel#nover+0xc3 stack: 0xnnnnnn
    cpu24:nnnnnn opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]CBRC_FileSyncRead@<None>#<None>+0xb1 stack: 0x0
    cpu24:nnnnnn opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]CBRC_DigestRecompute@<None>#<None>+0xnnn stack: 0xnnnn
    cpu24:nnnnnn opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]CBRC_FilterDigestRecompute@<None>#<None>+0x36 stack: 0x20
    cpu24:nnnnnn opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSI_SetInfo@vmkernel#nover+0x322 stack: 0xnnnnnnnnnnnn
    cpu24:nnnnnn opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]UWVMKSyscallUnpackVSI_Set@<None>#<None>+0xef stack: 0x41245111df10
    YYYY-MM-DD TIME cpu24:nnnnnn opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]User_UWVMKSyscallHandler@<None>#<None>+0x243 stack: 0xnnnnnnnnnnnn
    cpu24:nnnnnn opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]User_UWVMKSyscallHandler@vmkernel#nover+0x1d stack: 0xnnnnnnnn
    cpu24:nnnnnn opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]gate_entry@vmkernel#nover+0x64 stack: 0x0

    Dieses Problem wurde in der vorliegenden Version behoben.

  • ESXi-Host reagiert bei Speicherfluktuationen auf anderen als ATS VMFS-Datenspeichern nicht mehr und wird von vCenter Server getrennt
    Ein ESXi-Host reagiert möglicherweise nicht mehr und auf die virtuellen Maschinen kann nicht mehr zugegriffen werden. Darüber hinaus wird der ESXi-Host möglicherweise aufgrund eines Deadlocks bei Speicherfluktuationen auf anderen als ATS VMFS-Datenspeichern vom vCenter Server getrennt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • „Nicht freigegebener Speicher“ und „Verwendeter Speicher“ entsprechen nicht den erwarteten Werten für virtuelle Maschinen
    Wenn mehrere virtuelle Maschinen Speicherplatz gemeinsam nutzen, werden auf der Übersichtsseite des vSphere Client möglicherweise falsche Werte für Folgendes angezeigt:

    • Nicht freigegebener Speicher auf der VM-Zusammenfassungsseite

    • Bereitgestellter Speicherplatz auf der Datenzusammenfassungsseite

    • Verwendeter Speicherplatz auf der Registerkarte „VM“ des Hosts


    Dieses Problem wurde in der vorliegenden Version behoben.

  • vSphere erkennt möglicherweise nicht alle Laufwerke im System, selbst wenn sie im BIOS angezeigt werden
    vSphere erkennt möglicherweise nicht alle 18 Laufwerke im System, da der lsi_msgpt3-Treiber nicht ein einzelnes Laufwerk pro HBA erkennen kann, falls mehrere HBAs in einem System vorhanden sind.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • SAS-Laufwerke (Serial Attached SCSI) mit mehr als 2 TB werden vom lsi-mr3-Treiber nicht erkannt
    Der lsi_mr3-Treiber erkennt SAS-Laufwerke mit mehr als 2 TB nicht. Es werden Fehlermeldungen ähnlich den folgenden protokolliert:

    cpu35:33396)WARNUNG: ScsiDeviceIO: 8469: Plugin entry point isSSD() failed on device naa.5000c50057b932a7 from plugin NMP: Fehler
    cpu35:33396)ScsiDevice: 3025: Failing registration of device 'naa.5000c50057b932a7': failed to get device I/O error attributes.
    cpu35:33396)ScsiEvents: 545: Event Subsystem: Geräteereignisse, Zerstört!
    cpu35:33396)WARNUNG: NMP: nmp_RegisterDevice:673: Registration of NMP device with primary uid 'naa.5000c50057b932a7' failed. E/A-Fehler

    Der lsi_mr3-Treiber in dieser Version wurde aktualisiert, um dieses Problem zu beheben.

  • VMFS-Volume ist gesperrt
    Das VMFS-Volume auf einem ESXi-Host bleibt möglicherweise aufgrund fehlgeschlagener Metadatenvorgänge gesperrt. Eine Fehlermeldung ähnlich der Folgenden erscheint in der Protokolldatei vmkernel.log:

    WARNING: LVM: 12976: The volume on the device naa.50002ac002ba0956:1 locked, possibly because some remote host encountered an error during a volume operation and could not recover.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Versuche, Speicherrichtlinien für eine anhand von verknüpften Klonen (Linked Clones) erstellte virtuelle Maschine zu ändern, schlagen möglicherweise fehl
    Versuche, Speicherrichtlinien einer eingeschalteten virtuellen Maschine, die anhand von verknüpften Klonen erstellt wurde, zu ändern, schlagen in vCenter Server möglicherweise mit einer Fehlermeldung, die so oder ähnlich lautet, fehl:

    Fehler beim Ändern des Zeitplanungsparameters.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • LUNs, die ESXi 6.0-Hosts zugewiesen sind, verbleiben möglicherweise nach der Wiederherstellung der Pfade im Status „APD-Zeitüberschreitung“
    Wenn ein Ereignis „Keine Pfade verfügbar“ (All Paths Down, APD) auftritt, kann nach der Wiederherstellung der Pfade zu den LUNs möglicherweise weiterhin nicht auf die mit ESXi verbundenen LUNs zugegriffen werden. Die folgenden Ereignisse sind in dieser Reihenfolge in der Protokolldatei /var/log/vmkernel.log vorhanden:

    1. Gerät wechselt in APD-Status.
    2. Gerät beendet APD-Status.
    3. Taktsignalwiederherstellungs- und Dateisystemvorgänge auf dem Gerät schlagen aufgrund des Fehlers nicht gefunden fehl.
    4. Die APD-Zeitüberschreitung läuft ab, obwohl das Gerät zuvor den APD-Status beendet hat.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Aufgrund einer durch Virtual SAN ausgelösten unnötigen erneuten Prüfung reagieren der ESXi-Host und die virtuellen Maschinen möglicherweise nicht mehr
    Aufgrund einer durch Virtual SAN ausgelösten unnötigen regelmäßigen erneuten Prüfung der Geräte und des Dateisystems reagieren der ESXi-Host und die virtuellen Maschinen in der Umgebung möglicherweise nicht mehr.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Geringe Speicherleistung bei virtuellen Maschinen, die auf von VSA bereitgestelltem NFS-Speicher ausgeführt werden
    Eine geringe Leistung des NFS-Speichers ist bei virtuellen Maschinen zu verzeichnen, die auf von VSA bereitgestelltem NFS-Speicher ausgeführt werden. Dies ist auf verzögerte Quittierungen von der ESXi-Maschine auf NFS READ-Antworten zurückzuführen.

    Dieses Problem wurde in der vorliegenden Version durch die Deaktivierung verzögerter Quittierungen für LRO TCP-Pakete behoben.

  • Beim Klonen von virtuellen Maschinen zwischen verschiedenen Speichercontainern wird fälschlicherweise die Quell-VMId als Ausgangswert für die VVOL-VMId geklonter virtueller Maschinen festgelegt
    Wenn Sie eine virtuelle Maschine zwischen verschiedenen Speichercontainern klonen, wird die VMId der Quell-VVOL (Virtual Volumes) als Ausgangswert für die geklonte VVOL-VMID verwendet.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • WRITE SAME-Befehl ist auf lokalen Laufwerken deaktiviert
    WRITE SAME-Befehl ist für lokale Laufwerke in ESXi 6.0 Update 1 deaktiviert, da einige Festplattenlaufwerke die Write Same-Funktionen nicht vollständig implementieren. Dies führt zu einem fehlerhaften Verhalten. Alternativ können Sie den esxcli storage core device vaai status-Befehl verwenden, um VAAI auf lokalen Laufwerken zu aktivieren bzw. zu deaktivieren. Weitere Details finden Sie im Knowledgebase-Artikel 2131056.

Sicherungsprobleme
  • Das Erstellen von Stilllegungs-Snapshots schlägt bei Linux-VMs fehl
    Wenn Sie einen Stilllegungs-Snapshot einer virtuellen Linux-Maschine erstellen, schlägt die VM nach dem Snapshot-Vorgang möglicherweise fehl. Die folgenden Fehlermeldungen werden in der Datei vmware.log protokolliert:

    <YYYY-MM-DD>T<TIME>Z| vmx| I120: SnapshotVMXTakeSnapshotComplete: done with snapshot 'smvi_UUID': 0
    <YYYY-MM-DD>T<TIME>Z| vmx| I120: SnapshotVMXTakeSnapshotComplete: Snapshot 0 failed: Failed to quiesce the virtual machine (40).
    <YYYY-MM-DD>T<TIME>Z| vmx| I120: GuestRpcSendTimedOut: message to toolbox timed out.
    <YYYY-MM-DD>T<TIME>Z| vmx| I120: Vix: [18631 guestCommands.c:1926]: Error VIX_E_TOOLS_NOT_RUNNING in MAutomationTranslateGuestRpcError(): VMware Tools are not running in the guest

    Dieses Problem wurde in der vorliegenden Version behoben.

Sicherheitsprobleme
  • Update des Python-Pakets
    Die Python-Drittanbieterbibliothek wurde auf Version 2.7.9 aktualisiert.
  • Update der libPNG-Bibliothek
    Die libPNG-Bibliothek wurde auf libpng-1.6.16 aktualisiert.
  • Update der OpenSSL-Bibliothek
    Die Userworld-Version der OpenSSL-Bibliothek von ESXi wurde auf openssl-1.0.1m aktualisiert.
  • Update der libxml2-Bibliothek
    Die userworld-libxml2-Bibliothek von ESXi wurde auf Version 2.9.2 aktualisiert.

  • Update der VMware Tools-Bibliotheken libPNG und libxml2
    Die VMware Tools-Bibliotheken libPNG und libxml2 wurden auf die Versionen 1.2.52 und 2.9.2 aktualisiert.
  • Update der VMware Tools OpenSSL-Bibliothek
    Die VMware Tools OpenSSL-Bibliothek wurde auf openssl-0.9.8zg aktualisiert.
Serverkonfigurationsprobleme
  • Das Debugging-Protokoll kann festgelegt und die Trace-Protokollierung für das Hostprofilmodul aktiviert werden
    Das neue Hostprofil-Plug-In kann nun das DEBUG-Protokoll erfassen und die Trace-Protokollierung des ESXi-Hostprofilmoduls aktivieren, wenn der Host über Active Directory gestartet wird.

  • Versuche, eine große Anzahl von virtuellen Maschinen neu zu starten, schlagen bei Verwendung des NVIDIA GRID vGPU-Geräts möglicherweise fehl
    Bei der gleichzeitigen Zurücksetzung einer großen Anzahl von virtuellen Maschinen mithilfe des NVIDIA GRID vGPU-Geräts schlägt bei einigen virtuellen Maschinen möglicherweise der Neustart fehl. Möglicherweise wird eine Neustartfehlermeldung ähnlich der Folgenden angezeigt:

    VMIOP: Für vGPU grid_k100 ist keine Grafikkarte verfügbar.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Festlegen des CPU-Limits für die Auswirkung einer VM auf andere VMs
    Wenn Sie das CPU-Limit einer Uniprozessor-VM festlegen, kann die gesamte ESXi-Nutzung aufgrund eines Fehlers im ESXi-Scheduler abfallen. Dies ist darauf zurückzuführen, dass der ESXi-Scheduler davon ausgeht, dass die VMs mit dem CPU-Limit ausgeführt werden (wenn sie nicht ausgeführt werden) und Schätzungen über die CPU-Auslastung vornimmt. Dies führt zu einer falschen Entscheidung beim Lastausgleich. Weitere Details finden Sie im Knowledgebase-Artikel 2096897.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Beim Versuch, einen FIFO zu erstellen und Daten darauf zu schreiben, wird möglicherweise ein violetter Diagnosebildschirm angezeigt
    Wenn Sie eine FIFO erstellen und versuchen, Daten in das /tmp/dpafifo-Verzeichnis zu schreiben, wird unter bestimmten Bedingungen ein violetter Diagnosebildschirm angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Erweiterte Fehlerberichte sind bei Verwendung von Passthrough-Geräten deaktiviert
    Während die PCI-Informationen auf einem Gerät für Passthrough erfasst werden, sind Fehlerberichte für dieses Gerät deaktiviert.

    Dieses Problem wurde in der vorliegenden Version durch die Bereitstellung der VMkernel-Startoption pcipDisablePciErrReporting behoben, die PCI-Passthrough-Geräten die Fehlerberichterstattung ermöglicht. Standardmäßig ist diese Option auf TRUE festgelegt, d. h., die Fehlerberichterstattung ist deaktiviert.
  • Für eine virtuelle Maschine wird möglicherweise keine Warnmeldung angezeigt, wenn die CPU nicht vollständig reserviert ist
    Wenn Sie eine virtuelle Maschine erstellen, für sched.cpu.latencySensitivity den Wert „Hoch“ festlegen und die virtuelle Maschine einschalten, wird die exklusive Affinität für die vCPUs möglicherweise nicht aktiviert, falls die VM keine vollständige CPU-Reservierung aufweist.

    In früheren Versionen hat die VM keine Warnmeldung angezeigt, wenn die CPU nicht vollständig reserviert war.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der Befehl „esxcli system snmp set -p“ wurde aktualisiert
    Der SNMP-Agent wurde für die Überwachung eines benutzerdefinierten Ports mithilfe des Befehls esxcli system snmp set -p <port> konfiguriert. In ESXi 6.0 Update 1 wurden die TCP/UDP-Ports 32768 bis 40959 für die Nutzung durch Drittanbieter reserviert. Dieser Portbereich darf nicht mehr von anderen Ports verwendet werden.

    Nach dem Upgrade auf ESXi 6.0 Update 1 wird der SNMP-Agent nicht gestartet und zeigt einen Bereichsprüfungsfehler an, falls ein benutzerdefinierter Port in diesem Bereich festgelegt wird.
  • Hostprofile werden durch eine einfache Änderung der SNMP-Option „syscontact“ oder „syslocation“ inkompatibel
    Hostprofile werden inkompatibel, wenn eine einfache Änderung an der SNMP-Option „syscontact“ oder „syslocation“ vorgenommen wird. Dieses Problem tritt auf, wenn das SNMP-Hostprofil-Plug-In nur einen einzigen Wert auf alle an das Hostprofil angehängte Hosts anwendet. Es wird u. U. eine Fehlermeldung wie die folgende angezeigt:

    Konfiguration des SNMP-Agenten unterscheidet sich

    Dieses Problem wurde in der vorliegenden Version durch die Aktivierung von Werteinstellungen pro Host für bestimmte Parameter wie „syslocation“, „syscontact“, „v3targets“, „v3users“ und „engineid“ behoben.
VM-Verwaltungsprobleme
  • Leistungsindikatoren für vSphere Flash Read Cache sind auf einer virtuellen Maschine möglicherweise nicht verfügbar
    Die vFlash-Cache-Leistungsindikatoren wie z. B. FlashCacheIOPs, FlashCacheLatency oder FlashCacheThroughput sind möglicherweise nicht verfügbar, wenn CBT für eine virtuelle Festplatte aktiviert ist. Möglicherweise sind in der Datei stats.log Fehlermeldungen ähnlich der Folgenden protokolliert:

    xxxx-xx-xxTxx:xx:xx.200Z [xxxxxxxx error 'Statssvc.vim.PerformanceManager'] CollectVmVdiskStats : Failed to get VFlash Cache stats for vscsi id scsi0:0 for vm 3
    xxxx-xx-xxTxx:xx:xx.189Z [xxxxxxxx error 'Statssvc.vim.PerformanceManager'] GetVirtualDiskVFCStats: Failed to get VFlash Cache stat values for vmdk scsi0:0. Exception VFlash Cache filename not found!

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Virtuelle Maschinen können nicht mit einer höheren Bildschirmauflösung und mehreren konfigurierten Monitoren gestartet werden
    Versuche, virtuelle Maschinen mit einer höheren Bildschirmauflösung und mehreren konfigurierten Monitoren über VDI mithilfe von PCoIP-Lösungen zu starten, schlagen möglicherweise fehl. Die virtuellen Maschinen können nicht gestartet werden und wechseln in den Status Ausschalten. In der Protokolldatei /var/log/vmkwarning.log finden Sie Einträge ähnlich der Folgenden:

    cpu3:xxxxxx)WARNUNG: World: vm xxxxxx: 12276: vmm0:VDI-STD-005:vmk: vcpu-0:p2m update buffer full
    cpu3:xxxxxx)WARNUNG: VmMemPf: vm xxxxxx: 652: COW copy failed: pgNum=0x3d108, mpn=0x3fffffffff
    cpu3:xxxxxx)WARNUNG: VmMemPf: vm xxxxxx: 2626: PhysPageFault failed Failure: pgNum=0x3d108, mpn=0x3fffffffff
    cpu3:xxxxxx)WARNUNG: UserMem: 10592: PF failed to handle a fault on mmInfo at va 0x60ee6000: Failure. Wird beendet...
    cpu3:xxxxxx)WARNUNG: World: vm xxxxxx: 3973: VMMWorld-Gruppenführer = 255903, Elemente = 1
    cpu7:xxxxxx)WARNUNG: World: vm xxxxxx: 3973: VMMWorld-Gruppenführer = 255903, Elemente = 1
    cpu0:xxxxx)WARNUNG: World: vm xxxxxx: 9604: Panic'd VMM world being reaped, but no core dumped.


    Dieses Problem wurde in der vorliegenden Version behoben.

VMware HA- und Fault Tolerance-Konfigurationsprobleme
  • Migration einer sekundären virtuellen Maschine schlägt bei einer hohen Arbeitslast möglicherweise fehl
    Versuche, eine sekundäre virtuelle Maschine mit aktivierter Fault Tolerance zu migrieren, schlagen möglicherweise fehl und die virtuelle Maschine reagiert bei einer hohen Arbeitslast möglicherweise nicht mehr.

    Dieses Problem wurde in der vorliegenden Version behoben.
Sonstige Probleme
  • Übermäßige Protokollierung von VmkAccess-Meldungen im VMkernel-Protokoll
    Auf HP-Systemen mit ESXi 6.0 erfolgt möglicherweise eine übermäßige Protokollierung von VmkAccess-Meldungen in der Protokolldatei vmkernel.log für die folgenden während der Laufzeit ausgeführten Systembefehle:

    • esxcfg-scsidevs
    • localcli storage core path list
    • localcli storage core device list


    Übermäßig viele Protokollmeldungen ähnlich den Folgenden werden in den VmkAccess-Protokollen protokolliert:

    cpu7:36122)VmkAccess: 637: localcli: access denied:: dom:appDom(2), obj:forkExecSys(88), mode:syscall_allow(2)
    cpu7:36122)VmkAccess: 922: VMkernel-Systemaufruf ungültig (1025)
    cpu7:36122)VmkAccess: 637: localcli: access denied:: dom:appDom(2), obj:forkExecSys(88), mode:syscall_allow(2)
    cpu7:36122)VmkAccess: 922: VMkernel-Systemaufruf ungültig (1025)
    cpu0:36129)VmkAccess: 637: esxcfg-scsidevs: access denied:: dom:appDom(2), obj:forkExecSys(88), mode:syscall_allow(2)

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Neues Problem Fehler beim Importieren des Python-Pakets
    Beim Importieren des Python-Pakets kann in der neueren Python-Version 2.7.9 ein Fehler auftreten. Das Problem tritt auf, weil die neuere Version von Python das Modul pkg_resources.py nicht finden kann, wodurch die Anweisung import pkg_resources fehlschlägt.

    Dieses Problem wurde in der vorliegenden Version behoben.
Probleme bei VMware Tools
  • Update der FUSE-Bibliothek
    Die FUSE-Bibliothek wird auf libfuse 2.9.4 aktualisiert.

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
  • Neues Problem 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 SSLv3 bleibt auf Auto Deploy nach dem Upgrade einer früheren Version von ESXi 6.0 auf ESXi 6.0 Update 1 aktiviert
    Wenn Sie ein Upgrade von einer früheren ESXi 6.0-Version auf ESXi 6.0 Update 1 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 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.

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

    Problemumgehung: Keine.

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

Virtual SAN-Probleme
  • Neues Problem Durch Hinzufügen eines Hosts zu einem Virtual SAN-Cluster wird ein Installationsprogrammfehler ausgelöst
    Wenn Sie einen ESXi-Host zu einem Cluster mit aktiviertem HA- und Virtual SAN-Systemzustandsdienst hinzufügen, tritt möglicherweise aufgrund einer Racebedingung bei der VIB-Installation einer oder beide der folgenden Fehler auf:

    • In der Taskansicht schlägt die Aufgabe „vSphere HA wird konfiguriert“ möglicherweise mit einer Fehlermeldung ähnlich der folgenden fehl:

      Der vCenter Server-Agentendienst konnte nicht installiert werden. ‘Unbekannter Installationsfehler’

    • Die Aufgabe Agent aktivieren schlägt möglicherweise mit einer Fehlermeldung ähnlich der folgenden fehl:

      Der Vorgang kann nicht abgeschlossen werden. Weitere Informationen finden Sie im Ereignisprotokoll.

    Problemumgehung:

    • Um den HA-Konfigurationsfehler zu beheben, starten Sie den Host neu und konfigurieren HA erneut wie im Folgenden dargestellt:

      Ansicht „Hosts und Cluster“ -> klicken Sie auf den Namen des Clusters -> Registerkarte „Verwalten“ -> vSphere HA

    • Um den Fehler im Zusammenhang mit der Aufgabe „Agent aktivieren“ zu beheben, wechseln Sie zur Clusteransicht und wiederholen Sie die Aktivierung des VSAN-Systemzustandsdiensts wie im Folgenden dargestellt:

      Ansicht „Hosts und Cluster“ -> klicken Sie auf den Namen des Clusters -> Registerkarte „Verwalten“ -> „Status“ in der Virtual SAN-Kategorie und klicken Sie oben auf die Schaltfläche „Wiederholen“

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

Sonstige Probleme
  • Neues Problem Virtual SAN Observer unterstützt SSLv3-Verschlüsselung
    SSLv3 ist in ESXi 6.0 Update 1 standardmäßig deaktiviert. Der Virtual SAN Observer bietet aber nach wie vor Unterstützung für SSLv3.

    Problemumgehung: Keine.

Probleme bei VMware Tools
  • Neues Problem Das vmxnet-Kompilierungsmodul innerhalb von open-vm-tools 9.10 schlägt mit Kernel-Version 3.3.0 oder höher fehl
    Wenn Sie open-vm-tools 9.10 kompilieren oder installieren, treten möglicherweise mehrere Fehler auf, da vmxnet.c mit Kernel-Version 3.3.0 oder höher nicht kompiliert werden kann. Das Problem wurde für open-vm-tools 9.10.2 behoben und Sie können open-vm-tools 9.10.2 mit allen Kernel-Versionen installieren.

    Problemumgehung: Um open-vm-tools 9.10 zu installieren, bearbeiten Sie vmxnet unter Verwendung von ./configure oder --without-kernel-modules.

>