Versionshinweise zu VMware ESXi 6.0 Update 3a

|

ESXi 6.0 Update 3 | 11. JULI 2017 | ISO-Build 5572656

Ü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

  • In dieser Version von ESXi 6.0 Update 3a wurden Probleme behoben, die im Abschnitt Behobene Probleme dokumentiert sind.

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

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

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

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

Behobene Probleme

Die behobenen Probleme werden in folgende Kategorien unterteilt.

Sicherungsprobleme
  • Wenn Sie während des laufenden Betriebs eine bestehende oder eine neue virtuelle Festplatte zu einer virtuellen Maschine (VM) mit aktiviertem CBT (Changed Block Tracking) auf dem VVOL-Datenspeicher hinzufügen, reagiert das Gastbetriebssystem möglicherweise nicht mehr

    Wenn Sie während des laufenden Betriebs eine bestehende oder eine neue virtuelle Festplatte zu einer virtuellen Maschine (VM) mit aktiviertem CBT auf dem VVOL-Datenspeicher hinzufügen, reagiert das Gastbetriebssystem möglicherweise erst wieder, wenn das Hinzufügen im laufenden Betrieb abgeschlossen ist. Die Reaktion der VM ist abhängig von der Größe der hinzuzufügenden virtuellen Festplatte. Die virtuelle Maschine wird automatisch wiederhergestellt, sobald das Hinzufügen im laufenden Betrieb abgeschlossen ist.

    Dieses Problem wurde in der vorliegenden Version behoben.

CIM- und API-Probleme
  • Der SNMP-Agent meldet falsche Indikatorwerte für ifOutErrors und ifOutOctets

    Der SNMP-Agent (Simple Network Management Protocol) meldet denselben Wert für ifOutErrors- und ifOutOctets-Indikatoren, obwohl diese sich unterscheiden sollten.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • IPMI-Stack reagiert nach einem harten BMC-Reset nicht mehr

    Der IPMI-Stack (Intelligent Platform Management Interface) reagiert nach einem harten BMC-Reset (Baseboard Management Controller) nicht mehr.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • DDR4-Speichermodule werden auf der Statusseite zur Hardwareintegrität in vCenter Server als unbekannt angezeigt

    Die DDR4-Speichermodule von Dell 13G-Servern werden auf der Statusseite zur Hardwareintegrität in vCenter Server als unbekannt angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben.

Gastbetriebssystem-Probleme
  • Beim Ausfall eines Hosts wird ein violetter Diagnosebildschirm mit VMKPCIPassthru_SetupIntrProxy angezeigt, wenn Sie den PCI-Passthrough-Modus verwenden

    Wenn Sie den den PCI-Passthrough-Modus bei Geräten verwenden, die MSI-X und neuere Linux-Kernels nutzen, erscheint ein violetter Diagnosebildschirm und zeigt VMKPCIPassthru_SetupIntrProxy an. Dieses Problem tritt aufgrund des Codes in PCIPassthruChangeIntrSettings auf.

    Dieses Problem wurde in der vorliegenden Version behoben.

Probleme mit Hostprofilen und der automatischen Bereitstellung
  • Sie können sich nicht bei einem ESXi-Host anmelden, der mithilfe von vSphere Authentication Proxy einer Active Directory-Domäne mit Auto Deploy hinzugefügt wurde

    Nach der Nutzung von vSphere Auto Deploy zum Hinzufügen von Hosts zu einer Active Directory-Domäne mithilfe von vSphere Authentication Proxy können Sie sich nicht mit Active Directory-Anmeldeinformationen beim Host anmelden.

    Dieses Problem wurde in der vorliegenden Version behoben.

Internationalisierungsprobleme
  • Nicht lateinische Zeichen werden in den Namen des VM-Speicherprofils möglicherweise falsch angezeigt

    UTF-8-Zeichen werden nicht ordnungsgemäß behandelt, bevor sie nicht einem VVol-Vasa-Anbieter übergeben wurden. Als Folge werden VM-Speicherprofile, die internationale Zeichen verwenden, nicht vom Vasa-Anbieter erfasst oder bearbeitet, oder sie werden vom Vasa-Anbieter nicht richtig angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben.

Sonstige Probleme
  • Das Gastbetriebssystem wird möglicherweise ausgebremst oder verursacht eine CPU-Spitzenauslastung

    Ihr Gastbetriebssystem wird möglicherweise ausgebremst oder verursacht eine CPU-Spitzenauslastung, die verschwindet, sobald Sie im Gastbetriebssystem ASLR deaktivieren und einen FSR durchführen.

    Die folgenden Prozesse können zu einer solchen Reaktion führen:
    1. Ihr Übersetzungscache füllt sich mit Übersetzungen für zahlreiche CPUID/RDTSC-Anweisungen auf Benutzerebene, die an verschiedenen virtuellen Adressen im Gastbetriebssystem auftreten.
    2. Die Überwachung der virtuellen Maschine verwendet bei der Suche nach vorhandenen Übersetzungen eine Hash-Funktion mit schwacher Verteilung.

    Die Deaktivierung von ASLR behebt das Problem zeitweise, bis Sie ein Upgrade Ihres ESXi-Hosts auf eine Version durchführen, die die Korrektur enthält. Dieses Problem wurde in der vorliegenden Version behoben.

  • Wenn ein ESXi-Host fehlschlägt, wird dies entweder mit einem violetten Bildschirm angezeigt oder es erscheint eine Warnmeldung während der Vernichtung eines physisch fortlaufenden vmkernel-Heaps mit einer anfänglichen zugewiesenen Größe von 64 MB oder mehr

    Aufgrund einer falschen Berechnung des Overhead-Speichers wird ein fehlgeschlagener ESXi-Host mit einem violetten Bildschirm angezeigt oder es erscheint eine Warnmeldung zum Zeitpunkt des Entladens, wenn ein physisch fortlaufender vmkernel-Heap mit einer anfänglichen zugewiesenen Größe von 64 MB oder mehr vernichtet wird.

    Die folgende Warnmeldung wird angezeigt:

    Heap: 2781: Ein nicht leerer Heap (<heapName>) wird zerstört (<size> verfügbar, sollte <size> sein).

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Sie beobachten möglicherweise Fehlermeldungen für einen Sperrungskonflikt bei einer lunTimestamps.log-Datei in hostd-Protokollen

    Um den Zeitstempel der letzten Anzeige für jede LUN eines ESXi-Hosts zu aktualisieren, muss ein Prozess die Datei /etc/vmware/lunTimestamps.log für sich sperren. Die Sperre wird für länger als notwendig in jedem Prozess gehalten. Wenn zu viele solcher Prozesse versuchen, die Datei /etc/vmware/lunTimestamps.log zu aktualisieren, kann es bei dieser Datei zu einem Sperrungskonflikt kommen. Wenn hostd einer dieser Prozesse ist, die versuchen, die Datei für sich zu sperren, wird der ESXi-Host möglicherweise von vCenter Server getrennt oder reagiert nicht mehr und zeigt Sperrungskonfliktmeldungen (für die Datei lunTimestamps.log ) in den hostd-Protokollen an. Ihnen wird möglicherweise eine Fehlermeldung wie die Folgende angezeigt:

    Fehler beim Interagieren mit Konfigurationsdatei /etc/vmware/lunTimestamps.log: Zeitüberschreitung beim Warten auf die Freigabe der Sperre /etc/vmware/lunTimestamps.log.LOCK. Ein anderer Prozess hat diese Datei für mehr als 30 Sekunden gesperrt. Der Prozess, der die Sperre zurzeit besitzt, ist (). Es handelt sich wahrscheinlich um ein vorübergehendes Problem. Versuchen Sie den Vorgang erneut.

    Hinweis:

    • process_name ist der Prozess oder Dienst, der aktuell die Sperre für /etc/vmware/lunTimestamps.log besitzt. Zum Beispiel smartd, esxcfg-scsidevs, localcli usw.
    • PID ist die Prozess-ID für jeden dieser Dienste.

     

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Eine virtuelle Maschine schaltet sich möglicherweise selbst mit dem Fehler „MXUserAllocSerialNumber: zu viele Sperren“ ab

    Während des normalen VM-Betriebs stellen VMware Tools-Dienste (Version 9.10.0 und höher) vSocket-Verbindungen für den Austausch von Daten mit dem Hypervisor her. Wenn eine große Anzahl solcher Verbindungen hergestellt wurde, gehen dem Hypervisor womöglich die Seriennummern für die Sperre aus und die virtuelle Maschine schaltet sich ab und gibt eine Fehlermeldung aus.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Protokollüberflutung in den Systemprotokollen

    Jedes Mal, wenn die Kernel-API vmk_ScsiCmdGetVMUuid keine gültige VM-UUID beziehen kann, wird eine Fehlermeldung ähnlich der folgenden in den Systemprotokollen aufgezeichnet:

    2016-06-30T16:46:08.749Z cpu6:33528)WARNUNG: World: 0-Vm: 11020: vm nicht gefunden

    Das Problem wird in der vorliegenden Version durch ein bedingtes Aufrufen der Funktion World_GetVcUuid , welche die Protokollüberflutung der Kernel-API vmk_ScsiCmdGetVMUuid verursacht hat, behoben.

Netzwerkprobleme
  • Ein ESXi-Host reagiert möglicherweise nicht mehr, wenn Sie die Verbindung zu vCenter Server wiederherstellen

    Wenn Sie Ihren ESXi-Host von vCenter Server trennen und einige der virtuellen Maschinen auf diesem Host LAG verwenden, reagiert Ihr ESXi-Host möglicherweise nicht mehr, wenn Sie diesen nach einer erneuten Erstellung des gleichen LAG auf der vCenter Server-Seite wieder mit dem vCenter Server verbinden, und Ihnen wird möglicherweise eine Fehlermeldung wie die folgende angezeigt:
    0x439116e1aeb0:[0x418004878a9c]LACPScheduler@ # +0x3c stack: 0x417fcfa00040 0x439116e1aed0:[0x418003df5a26]Net_TeamScheduler@vmkernel#nover+0x7a stack: 0x43070000003c 0x439116e1af30:[0x4180044f5004]TeamES_Output@ # +0x410 stack: 0x4302c435d958 0x439116e1afb0:[0x4180044e27a7]EtherswitchPortDispatch@ # +0x633 stack: 0x0

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Die Netzwerkstatistik zeigt eine abnormale Paketzahl im Leistungsdiagramm des vCenter Server-Netzwerks

    Die Berechnung der Netzwerk-Paketanzahl kann von mehreren CPUs übernommen werden. Diese Berechnung kann möglicherweise zu einem Berechnungsfehler der Netzwerkstatistik führen und die falsche Anzahl im Leistungsdiagramm des Netzwerks anzeigen.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Für die Verwendung von EFI-Firmware konfigurierte virtuelle Maschinen scheitern in einigen DHCP-Umgebungen am PXE-Startvorgang

    Für die Verwendung von EFI-Firmware konfigurierte virtuelle Maschinen scheitern beim PXE-Startvorgang am Erfassen einer IP-Adresse, wenn die DHCP-Umgebung IP-Unicast zurückgibt. Die EFI-Firmware konnte keine vom IP-Unicast gesendete DHCP-Antwort empfangen.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Bei unzureichendem Arbeitsspeicher für den Еtherswitch-Heap geht die Verbindung aller VMs verloren

    Im Еtherswitch-Heap herrscht ein Arbeitsspeicherverlust der Größe 32 Bytes bis 63 Bytes vor. Wenn der Heap nicht über genügend Arbeitsspeicher verfügt, geht die Verbindung zu den VMs verloren.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Der ESXi-Host schlägt mit einem violetten Diagnosebildschirm auf DVFilter-vMotion-Ebene fehl und meldet den Fehler „PCPU 25: kein Taktsignal (3/3 IPIs empfangen)“

    Wenn Sie den ESXi-Host unter den folgenden Bedingungen neu starten, schlägt der Host möglicherweise fehl und zeigt einen violetten Diagnosebildschirm sowie den Fehler PCPU xxx: kein Taktsignal an.
     

    •  Sie verwenden die vSphere Network Appliance (DVFilter) in einer NSX-Umgebung
    •  Sie migrieren eine virtuelle Maschine mit vMotion bei einer DVFilter-Steuerung

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Virtuelle Maschinen (VMs), die Teil von VDI-Pools (Virtual Desktop Infrastructure) sind, in der die Instant-Clone-Technologie zum Einsatz kommt, verlieren die Verbindung zu Guest-Introspection-Diensten

    Vorhandene VMs mit Instant Clone und neue VMs, die mit oder ohne Instant Clone erstellt wurden, verlieren die Verbindung zum Guest Introspection-Hostmodul. Dies führt dazu, dass die virtuellen Maschinen nicht geschützt sind und keine neuen Guest Introspection-Konfigurationen zum ESXi-Host weitergeleitet werden können. Ihnen wird zudem in der vCenter Server-Benutzeroberfläche die Warnung „Guest Introspection nicht bereit“ angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Das VMkernel-Protokoll umfasst eine oder mehrere der Warnungen „Keep-Alive konnte nicht aktiviert werden“

    Die Warnungen „Keep-Alive konnte nicht aktiviert werden“ treten während der Kommunikation zwischen VMware NSX und Partnerlösungen über einen VMCI-Socket (vsock) auf. Das VMkernel-Protokoll blendet diese wiederholten Warnungen jetzt aus, da sie bedenkenlos ignoriert werden können.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Aufgrund eines Verlustes der Netzwerkkonnektivität für eine virtuelle Maschine mit e1000/e1000e-vNIC kann es zu einem Auftreten von Kernel-Panic kommen

    Bei einer VM mit e1000/e1000e-vNIC kann es zu einem Verlust der Konnektivität kommen und die VM geht in den Kernel-Panic-Zustand, wenn der e1000/e1000e-Treiber die e1000/e1000e-Vmkernel-Emulation anweist, einen Deskriptor zu überspringen (die Adresse und die Länge des Transmit-Deskriptors lauten 0).

    Dieses Problem wurde in der vorliegenden Version behoben.

  • vSphere vMotion schlägt fehl, wenn ein ESXi mit einem vSphere Distributed Switch verbunden ist, welcher mit LACP konfiguriert ist

    Wenn ein ESXi-Host mit einem vSphere Distributed Switch verbunden ist, welcher mit LACP konfiguriert wurde, und wenn LAG über Uplinks im Link-Down-Status verfügt, wenn Sie versuchen, vSphere vMotion zu verwenden, wird eine Warnung ähnlich der folgenden angezeigt: Aktuell verbundene Netzwerkschnittstelle 'Netzwerkadapter 1' verwendet Netzwerk 'DSwitchName', auf das nicht zugegriffen werden kann.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Ein ESXi-Host ist möglicherweise während des Herunterfahrens nicht verfügbar

    Bei der Verwendung einer IPv6-Adresse für einen ESXi-Host ist der Host während des Herunterfahrens möglicherweise nicht verfügbar

    Aktualisieren Sie Ihren ESXi-Host auf die Version 6.0 Update 3a.

Sicherheitsprobleme
  • Update der Pixman-Bibliothek

    Die Pixman-Bibliothek wurde auf Version 0.35.1 aktualisiert.

  • Likewise-Stack für ESXi ist nicht für den Support von SMBv2 aktiviert

    Der Domänencontroller von Windows 2012 unterstützt SMBv2, während der Likewise-Stack auf ESXi nur SMBv1 unterstützt.

    Ab dieser Version ist der Likewise-Stack auf ESXi in der Lage, SMBv2 zu unterstützen.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Aktualisierung von VMware Tools

    VMware Tools wurde auf Version 10.1.5 aktualisiert. Weitere Informationen finden Sie unter Versionshinweise zu VMware Tools 10.1.5.

    VMware Tools 10.1.5 behebt Sicherheitsprobleme in den Open-Source-Komponenten.

  • OpenSSL-Update

    Das OpenSSL-Paket wurde auf Version Openssl-1.0.2k aktualisiert, um CVE-2017-3731, CVE-2017-3730, CVE-2017-3732 und CVE-2016-7055 zu beheben.

  • Aktualisierung von Python

    Python wurde auf Version 2.7.13 aktualisiert, um CVE-2016-2183 und CVE-2016-1000110 zu beheben.

Serverkonfigurationsprobleme
  • Der vpxd-Dienst stürzt ab und die Benutzeroberfläche des vSphere Web Client kann weder eine Verbindung zum vCenter Server herstellen noch diesen aktualisieren

    Unter bestimmten Bedingungen wird der Profilpfad für das VMODL-Objekt nicht festgelegt. Dieser Zustand löst ein Serialisierungsproblem bei der Validierung der Antwortdatei für die Netzwerkkonfiguration aus, wodurch ein vpxd-Dienst abstürzt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Ein ESXi 6.x-Host kann über ein Hostprofil nicht Active Directory beitreten

    Wenn Sie versuchen, Host-Profile zu verwenden, um einen ESXi 6.x-Host mit einer Active Directory-Domäne zu kombinieren, bleibt die Anwendung hängen oder stürzt mit einer Fehlermeldung ab.

    Dieses Problem wurde in der vorliegenden Version behoben.

Speicherprobleme
  • Der VM-Support-Befehl wird ausgeführt und führt zu einem nicht schwerwiegenden Fehler

    Der VM-Support-Befehl verwendet ein Skript namens smartinfo.sh, um SMART-Daten für jedes Speichergerät auf dem ESXi-Host zu erfassen. Der VM-Support-Befehl erzwingt für jeden Befehl, der Supportdaten erfasst, eine Pause von 20 Sekunden. smartinfo.sh benötigt jedoch länger als 20 Sekunden, wodurch der VM-Support-Befehl den folgenden Fehler anzeigt: Nach 20 Sekunden ist eine Zeitüberschreitung für den Befehl /usr/lib/vmware/vm-support/bin/smartinfo.sh aufgetreten, da während der letzten 10 Sekunden kein Fortschritt erzielt wurde (0 Bytes gelesen).

    Dieses Problem wurde in der vorliegenden Version behoben.

  • hostd stürzt aufgrund nicht initialisierter Bibliotheken ab

    Wenn Sie versuchen, erneut einen Host zu einem vCenter Server hinzuzufügen, stürzt hostd möglicherweise ab, wenn beim Host IOFilter aktiviert ist und sich VMs mit aktiviertem Changed Block Tracking (CBT) auf diesem Host befinden. Die Filterbibliothek verwendet die Abruf- und Worker-Bibliotheken. Wenn die Filterbibliothek vor den Abruf- und Worker-Bibliotheken initialisiert wird, kann sie nicht ordnungsgemäß arbeiten und stürzt ab.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Ein ESXi-Host reagiert möglicherweise nicht mehr, während eine virtuelle Maschine auf diesem Host auf einem SeSparse Snapshot ausgeführt wird

    Nachdem Sie einen Snapshot einer virtuellen Maschine aus einem SEsparse-Format erstellt haben, tritt möglicherweise ein seltener Race-Fehler auf, wenn erhebliche, aber unterschiedliche Schreib-IOPS für den Snapshot vorhanden sind. Dieser Race-Fehler kann dazu führen, dass der ESXi-Host nicht mehr reagiert.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Virtuelle Maschinen, die das SEsparse-Format für virtuelle Festplatten verwenden, reagieren während der Ausführung von bestimmten E/A-Arbeitslasten möglicherweise nicht

    Virtuelle Maschinen mit SEsparse-basierten Snapshots reagieren möglicherweise während der E/A-Vorgänge im Zusammenhang mit einem bestimmten Typ von E/A-Arbeitslast in mehreren Threads nicht.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Werden Änderungen nach einem Fehler während eines Änderungsvorgangs am Speicherprofil rückgängig gemacht, führt dies zu einer beschädigten Profil-ID

    Wenn ein VVol-VASA-Anbieter während einer Änderung des Speicherprofils einen Fehler zurückgibt, versucht vSphere, den Vorgang rückgängig zu machen, allerdings wird die Profil-ID während des Vorgangs beschädigt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Es wird eine fehlerhafte Lese-/Schreiblatenz im vSphere Web Client für VVol-Datenspeicher angezeigt

    Die für VVol-Datenspeicher im vSphere Web Client angezeigte Lese-/Schreiblatenz pro Host ist nicht korrekt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Hostprofilvorgänge schlagen in einer Umgebung mit automatischer Bereitstellung fehl

    Die Hostprofilvorgänge, wie z. B. das Prüfen der Übereinstimmung, die Wartung und das Klonen von Hostprofilen, schlagen in einer Umgebung mit automatischer Bereitstellung fehl.
    Die folgenden Szenarien können beobachtet werden:

    1. Während der Neuinstallation von ESXi-Hosts mit der automatischen Bereitstellung
      • Die Überprüfung der Übereinstimmung schlägt für Hostprofile mit einer Fehlermeldung ähnlich der folgenden fehl:
        Der Host ist zum Prüfen auf Übereinstimmung nicht verfügbar
      • Wartung des Hostprofils (Host-Profile anwenden) schlägt mit der folgenden Fehlermeldung fehl:
        Das Aufrufen von „HostProfileManager.GenerateConfigTaskList“ für Objekt „HostProfileManager“ ist auf vCenter Server <vCenter_hostname> fehlgeschlagen.
    2. Das Ändern des Referenzhosts eines Hostprofils schlägt mit der folgenden Fehlermeldung fehl:
      Das Aufrufen von „HostProfileManager.CreateProfile“ für Objekt „HostProfileManager“ ist auf vCenter Server <vCenter_hostname> fehlgeschlagen.
    3. Das Klonen des Hostprofils schlägt mit der folgenden Fehlermeldung fehl:
      Das Aufrufen von „HostProfileManager.CreateProfile“ für Objekt „HostProfileManager“ ist auf vCenter Server <vCenter_hostname> fehlgeschlagen. Das Profil hat keinen zugewiesenen Referenzhost.

    Die fehlgeschlagenen Vorgänge erscheinen in den Protokolldateien unter /var/log/syslog.log mit der folgenden Fehlermeldung:
    Fehler: profileData aus nur einer Profilinstanz in VerifyMyProfilesPolicies unterstützt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Ein ESXi-Host mit einer für VMware vFlash Read Cache (VFRC) konfigurierten virtuellen Maschine schlägt möglicherweise fehl und zeigt einen violetten Bildschirm an

    Ein ESXi-Host mit einer für VMware vFlash Read Cache (VFRC) konfigurierten virtuellen Maschine schlägt möglicherweise fehl und zeigt einen violetten Bildschirm an, wenn der Back-End-Speicher langsam ist oder nicht mehr darauf zugegriffen werden kann. Dieser Ausfall ist auf einen Sperrdefekt im VFRC-Code zurückzuführen.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • SESparse führt zu einem beschädigten Dateisystem des Gastbetriebssystems

    Die Verwendung von SESparse sowohl zum Erstellen von Snapshots als auch zum Klonen von virtuellen Maschinen führt möglicherweise zu einem beschädigten Dateisystem des Gastbetriebssystems.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Eine dynamische Änderung der Warteschlangentiefenparameter für Geräte führt zu einer Überflutung von hostd mit Ereignisbenachrichtigungen

    Wenn die SIOC (Storage I/O Control) den maximalen Warteschlangentiefenparameter der LUN verändert, wird eine Ereignisbenachrichtigung von der PSA (Pluggable Storage Architecture) an den hostd gesendet. Bei Installationen, in denen der Warteschlangentiefenparameter dynamisch geändert wird, werden eine Menge Ereignisbenachrichtigungen an den hostd gesendet; dies führt zu Leistungsproblemen, wie z. B. langsame vSphere-Aufgaben oder die Trennung des hostd vom vCenter Server.

    In der vorliegenden Version schickt PSA keine Ereignisbenachrichtigungen an hostd.

  • Die Neuberechnung des Digests für eine Festplatte mit aktiviertem CBRC (Content Based Read Cache) meldet nie eine in Prozent abgeschlossene Berechnung, sondern gibt stattdessen einen Systemfehler zurück

    Der CBRC-Filter verwendet eine 32-Bit-Berechnung und gibt den Fertigstellungswert für jede Anforderung zur erneuten Digest-Berechnung in Prozent an. Bei großen Festplatten ist die Anzahl der Hashes groß genug, die 32-Bit-Berechnung zu überfluten, was zu einem falschen Prozentwert bei der Fertigstellung führt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Der Nutzer muss die SATP-Regel für das Pure Storage-FlashArray-Modell manuell konfigurieren

    Bei einem Pure Storage-FlashArray-Gerät muss der Nutzer die SATP-Regel manuell hinzufügen, um gemäß Anforderung die SATP-, PSP- und IOP-Werte festzulegen.

    Das Problem wurde in der vorliegenden Version behoben; eine neue SATP-Regel wurde ESXi hinzugefügt, um für alle Pure-Storage-FlashArray-Modelle SATP auf VMW_SATP_ALUA, PSP auf VMW_PSP_RR und IOPs auf 1 zu setzen.

    Hinweis: Im Falle einer statusfreien ESXi-Installation werden die neuen Regeln nach dem Upgrade überschrieben, wenn ein altes Hostprofil angewendet wird.

  • Unmounten des Datenspeichers schlägt fehl

    Manche Versuche, den NFS-Datenspeicher von vCenter Server zu unmounten, schlagen möglicherweise mit der Fehlermeldung Unmounten des NFS-Datenspeichers fehlgeschlagen - Datenspeicher hat offene Dateien und kann daher den Unmount-Vorgang nicht durchführen fehl.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Bei Verwendung von Storage vMotion ändert sich die UUID einer virtuellen Festplatte möglicherweise

    Bei Verwendung von Storage vMotion beim Speichern des Typs „vSphere Virtual Volumes“ ändert sich die UUID einer virtuellen Festplatte möglicherweise. Die UUID identifiziert die virtuelle Festplatte; eine geänderte UUID lässt die virtuelle Festplatte als neuen und anderen Datenträger erscheinen. Die UUID ist auch für das Gastbetriebssystem sichtbar und kann zu einer falschen Identifikation von Laufwerken führen.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Ihnen werden während des ESXi-Starts oder dem Mounten von Festplattengruppen in vSAN Fehlermeldungen des Typs „Fehler beim Öffnen der Datei“ im vmkernel.log angezeigt

    Ihnen werden Fehlermeldungen des Typs „Fehler beim Öffnen der Datei“ in der Datei vmkernel.log angezeigt, wenn ein ESXi-Host mit aktiviertem vSAN gestartet wird oder während der manuellen Mountens einer Festplattengruppe in vSAN.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Eine Linked-Clone-VM mit dem Festplattentyp SESparse reagiert möglicherweise im Falle von E/A- oder Paketverwerfungen aufgrund von Problemen mit dem HBA-Treiber, dem Controller, der Firmware, der Konnektivität oder der Speichertopologie nicht mehr

    Wenn die E/A-Vorgänge aufgrund von Problemen mit dem HBA-Treiber, dem Controller, der Firmware, der Konnektivität oder der Speichertopologie nicht mehr reagieren oder verworfen werden, wird der blockierte E/A-Vorgang nicht abgebrochen, wodurch die VM nicht mehr reagiert.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Das System reagiert nicht mehr, und Sie empfangen möglicherweise die Fehlermeldung „Problem beim Löschen von Blöcken“ in der Protokolldatei vmkernel.log

    Wenn die Unmap-Befehle fehlschlagen, reagiert der ESXi-Host möglicherweise aufgrund eines Arbeitsspeicherverlustes im Fehlerpfad nicht mehr. Sie empfangen möglicherweise die folgende Fehlermeldung in der Protokolldatei vmkernel.log: FSDisk: 300: Blöcke blockieren fehlgeschlagen [sync:0], und der Host reagiert nicht.

    Dieses Problem wurde in der vorliegenden Version durch Vermeidung eines Arbeitsspeicherverlustes behoben.

  • Wenn Sie SEsparse verwenden und den Unmapping-Vorgang aktivieren, wird das Dateisystem des Gastbetriebssystems möglicherweise beschädigt

    Falls Sie SEsparse verwenden und den Unmapping-Vorgang aktivieren, um Snapshots und Klone von virtuellen Maschinen zu erstellen, ist das Dateisystem des Gastbetriebssystems nach dem Wipe-Vorgang (dem Aufheben der Speicherzuordnung) möglicherweise beschädigt. Der vollständige Klon der virtuellen Maschine arbeitet problemlos.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Das Ändern des IOPS-Grenzwerts von virtuellen Festplatten mit aktiviertem CBT (Changed Block Tracking) schlägt möglicherweise fehl

    Zum Definieren der Planungsrichtlinie des Speicher-E/A für eine virtuelle Maschine (VM) können Sie für jede VM-Festplatte den E/A-Durchsatz durch Modifizieren des IOPS-Grenzwerts konfigurieren. Wenn Sie den IOPS-Grenzwert bearbeiten und CBT für die virtuelle Maschine aktiviert ist, schlägt der Vorgang mit einer Fehlermeldung Änderung des Planungsparameters fehlgeschlagen fehl. Aufgrund dieses Problems können die Planungsrichtlinien der virtuellen Maschine nicht geändert werden. Die Fehlermeldung wird im vSphere-Bereich „Kürzlich ausgeführte Aufgaben“ angezeigt.

    In der Datei /var/log/vmkernel.log werden die folgenden Fehler angezeigt:

    2016-11-30T21:01:56.788Z cpu0:136101)VSCSI: 273: handle 8194(vscsi0:0):Input values: res=0 limit=-2 bw=-1 Shares=1000 2016-11-30T21:01:56.788Z cpu0:136101)ScsiSched: 2760: Invalid Bandwidth Cap Configuration 2016-11-30T21:01:56.788Z cpu0:136101)WARNING: VSCSI: 337: handle 8194(vscsi0:0):Failed to invert policy
     

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Der Abbruch einer Aufgabe zur Erstellung eines Snapshots wird nicht ordnungsgemäß ausgeführt

    Wenn Sie versuchen, die Aufgabe zur Erstellung eines Snapshots abzubrechen, der VASA-Anbieter aber die zugehörigen zugrundeliegenden Vorgänge auf einer VVoL-gestützten Festplatte nicht abbrechen kann, wird ein VVoL mit Snapshot erstellt und bleibt bis zur automatischen Speicherbereinigung bestehen.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Der Abbruch einer Aufgabe zur Erstellung eines Klons wird nicht ordnungsgemäß ausgeführt

    Wenn Sie versuchen, die Aufgabe zur Erstellung eines Klons abzubrechen, der VASA-Anbieter aber die zugehörigen zugrundeliegenden Vorgänge nicht abbrechen kann, erstellt vCenter Server eine neue VVoL, kopiert alle Daten und meldet, dass der Klonvorgang erfolgreich war.

    Dieses Problem wurde in der vorliegenden Version behoben.

Probleme bei unterstützter Hardware
  • ESXi-Hosts, die mit einem ESXi600-201611001-Patch ausgeführt werden, schlagen möglicherweise mit einem violetten Diagnosebildschirm fehl, der durch nicht maskierbare Interrupts (NMI) auf HPE-ProLiant-Gen8-Servern hervorgerufen wurde

    Der ESXi600-201611001-Patch umfasst eine Änderung, die es ESXi ermöglicht, die Interrupt-Remapping-Funktion von Intel® IOMMU (auch bekannt als VT-d) zu deaktivieren. Auf HPE-ProLiant-Gen8-Servern führt die Deaktivierung dieser Funktion zu PCI-Fehlern. Als Folge dieser Fehler generiert die Plattform einen NMI, der zum Fehlschlagen des ESXi-Hosts mit einem violetten Diagnosebildschirm führt.

    Dieses Problem wurde in der vorliegenden Version behoben.

Upgrade- und Installationsprobleme
  • Für die Anmeldung beim ESXi-Host über SSH ist die erneute Eingabe des Kennworts notwendig

    Sie werden zwei Mal zur Eingabe des Kennworts aufgefordert, wenn Sie sich über SSH mit dem ESXi-Host verbinden und der ESXi-Host von vSphere Version 5.5 auf 6.0 aktualisiert wird und dabei Teil einer Domäne ist.

    Dieses Problem wurde in der vorliegenden Version behoben.

Probleme bei vCenter Server, vSphere Web Client und vSphere Client
  • VMware Host Client kann nicht in Chrome 57 verwendet werden

    Wenn Sie versuchen, sich über Chrome 57 beim VMware Host Client anzumelden, meldet der VMware Host Client sofort einen Fehler. Der gemeldete Fehler ist ein Fehler des Typs „Digest in progress“ in Angular.

    Dieses Problem wurde in der vorliegenden Version behoben.

VM-Verwaltungsprobleme
  • Digest-VMDK-Dateien werden nicht aus dem VM-Ordner gelöscht, wenn Sie eine virtuelle Maschine löschen

    Wenn Sie einen verknüpften Klon aus einer Digest-VMDK-Datei erstellen, markiert vCenter Server die Digest-Festplattendatei als nicht löschbar. Wenn Sie also die entsprechende virtuelle Maschine löschen, wird die Digest-VMDK-Datei aufgrund des Eintrags „ddb.deletable = FALSE Ddb“ in der Deskriptordatei nicht aus dem VM-Ordner gelöscht.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Die virtuelle Maschine reagiert möglicherweise nicht

    Wenn Sie einen Snapshot von einer virtuellen Maschine erstellen, reagiert die virtuelle Maschine möglicherweise nicht mehr.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Die virtuelle Maschine reagiert möglicherweise aufgrund des Abfalls von aktivem Arbeitsspeicher nicht mehr

    Wenn der aktive Arbeitsspeicher einer virtuellen Maschine, die auf einem ESXi-Host ausgeführt wird, auf unter 1 % fällt und auf null sinkt, muss der Host möglicherweise Arbeitsspeicher zurückfordern, auch wenn der Host über ausreichend freien Arbeitsspeicher verfügt.

    Dieses Problem wurde in der vorliegenden Version behoben.

    1. Stellen Sie über den vSphere Web Client eine Verbindung zu vCenter Server her.
    2. Wählen Sie einen ESXi-Host aus der Bestandsliste aus.
    3. Schalten Sie alle virtuellen Maschinen auf dem ESXi-Host aus.
    4. Klicken Sie auf Einstellungen.
    5. Klicken Sie im Systembereich auf Erweiterte Systemeinstellungen.
    6. Suchen Sie nach der Einstellung Mem.SampleActivePctMin.
    7. Klicken Sie auf Bearbeiten.
    8. Ändern Sie den Wert in 1.
    9. Klicken Sie auf OK, um die Änderungen zu akzeptieren.
    10. Schalten Sie die virtuellen Maschinen ein.
  • Ein ESXi-Host wird möglicherweise von vCenter Server getrennt

    Aufgrund eines Arbeitsspeicherverlustes schlägt der hostd-Prozess möglicherweise mit der folgenden Fehlermeldung fehl: 

    Arbeitsspeicher überschreitet harte Grenze. Notfallalarm.

    Die hostd-Protokolle melden zahlreiche Fehler, wie z. B. Es kann kein dauerhafter Name aufgebaut werden.

    Diese Art von Arbeitsspeicherverlust führt dazu, dass der Host von vCenter Server getrennt wird.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Die virtuelle Maschine reagiert während der Snapshot-Konsolidierung nicht mehr

    Während der Snapshot-Konsolidierung wird möglicherweise eine präzise Berechnung durchgeführt, um den erforderlichen Speicherplatz für die Konsolidierung zu bestimmen. Diese präzise Berechnung kann dazu führen, dass die virtuelle Maschine nicht mehr reagiert, da sie viel Zeit in Anspruch nimmt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Eine vMotion-Migration einer virtuellen Maschine (VM) wird für einige Zeit angehalten und schlägt nach einer Zeitüberschreitung fehl

    Wenn eine virtuelle Maschine einen Treiber (insbesondere einen Grafiktreiber) oder eine Anwendung hat, die zu viel Arbeitsspeicher beansprucht, erstellt sie eine sog. Sticky Page in der VM. Wenn so eine virtuelle Maschine mit vMotion zu einem anderen Host migriert werden soll, wird der Migrationsvorgang angehalten und schlägt später aufgrund falscher ausstehender Eingangs-/Ausgangsberechnungen fehl.

    Dieses Problem wurde in der vorliegenden Version behoben.

vSAN-Probleme
  • Werte aus der bytsToSync-Berechnung im VC und RVC erscheinen möglicherweise für RAID 5/6-Objekte falsch

    Die aktuelle Berechnung der Neusynchronisierungs-Bytes überschätzt den vollständigen Neusynchronisierungsdatenverkehr für RAID 5/6-Konfigurationen. Dies kann unter einer der folgenden Bedingungen der Fall sein:

    • Der Knoten wird entweder mit dem Evakuierungsmodus „Vollständige Datenmigration“ oder „Erreichbarkeit sicherstellen“ in den Wartungsmodus versetzt.
    • Erstellen einer vollständigen Spiegelung einer Komponente nach deren Verlust aufgrund eines Fehlers im Cluster.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Das System zeigt zur Identifizierung von Speicherplatzproblemen möglicherweise eine generische Fehlermeldung anstelle einer spezifischen Meldung an

    In einigen Fällen zeigt das System zur Identifizierung von Speicherplatzproblemen möglicherweise eine generische Fehlermeldung anstelle einer spezifischen Meldung an. Wenn beispielsweise ein Fehler durch unzureichenden Festplattenspeicher verursacht wird, sehen Sie eine Fehlermeldung wie „Ändern der Speicherrichtlinie fehlgeschlagen: 12 (Arbeitsspeicher kann nicht zugeordnet werden)“.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Ein ESXi-Host schlägt möglicherweise mit einem violetten Bildschirm bei bora/modules/vmkernel/lsomcommon/ssdlog/ssdopslog.c:199 fehl

    Es kommt zu einigen Race-Fehlern zwischen mehreren internen LSOM-Codepfaden. Das zweimalige Freigeben einer Region auf der Caching-Ebene führt zu einer Stack-Spur und einem Notfallalarm-Fehler des folgenden Typs:

    PanicvPanicInt@vmkernel#nover+0x36b stack: 0x417ff6af0980, 0x4180368 2015-04-20T16:27:38.399Z cpu7:1000015002)0x439124d1a780:[0x4180368ad6b7]Panic_vPanic@vmkernel#nover+0x23 stack: 0x46a, 0x4180368d7bc1, 0x43a 2015-04-20T16:27:38.411Z cpu7:1000015002)0x439124d1a7a0:[0x4180368d7bc1]vmk_PanicWithModuleID@vmkernel#nover+0x41 stack: 0x439124d1a800, 0x4 2015-04-20T16:27:38.423Z cpu7:1000015002)0x439124d1a800:[0x418037cc6d46]SSDLOG_FreeLogEntry@LSOMCommon#1+0xb6e stack: 0x6, 0x4180368dd0f4, 0 2015-04-20T16:27:38.435Z cpu7:1000015002)0x439124d1a880:[0x418037d3c351]PLOGCommitDispatch@com.vmware.plog#0.0.0.1+0x849 stack: 0x46a7500, 0

    Zu den Race-Fehlern kommt es zwischen Workflows PLOG Relog, PLOG Probe und PLOG Decommission.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Bei einer hohen E/A-Arbeitslast besetzt ein vSAN-Prozess die CPU-Zyklen möglicherweise für eine lange Zeit, was zu einer kurzen PCPU-Sperre führt

    Bei einer hohen E/A-Arbeitslast besetzt ein vSAN-Prozess die CPU-Zyklen möglicherweise für eine lange Zeit, was zu einer kurzen PCPU-Sperre führt. Dies führt zu einem nicht maskierbaren Interrupt und einer Protokollüberflutung in den vmkernel-Protokolldateien.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Ein ESXi vSAN-fähiger Host schlägt möglicherweise mit PSOD fehl

    Ein ESXi vSAN-fähiger Host schlägt möglicherweise mit einem violetten Bildschirm mit der folgenden Backtrace auf dem Bildschirm fehl:

    2017-02-19T09:58:26.778Z cpu17:33637)0x43911b29bd20:[0x418032a77f83]Panic_vPanic@vmkernel#nover+0x23 stack: 0x4313df6720ba, 0x418032a944 2017-02-19T09:58:26.778Z cpu17:33637)0x43911b29bd40:[0x418032a944a9]vmk_PanicWithModuleID@vmkernel#nover+0x41 stack: 0x43911b29bda0, 0x4 2017-02-19T09:58:26.778Z cpu17:33637)0x43911b29bda0:[0x41803387b46c]vs_space_mgmt_svc_start@com.vmware.virsto#0.0.0.1+0x414 stack: 0x100 2017-02-19T09:58:26.778Z cpu17:33637)0x43911b29be00:[0x41803384266d]Virsto_StartInstance@com.vmware.virsto#0.0.0.1+0x68d stack: 0x4312df 2017-02-19T09:58:26.778Z cpu17:33637)0x43911b29bf00:[0x4180338f138f]LSOMMountHelper@com.vmware.lsom#0.0.0.1+0x19b stack: 0x43060d72b980, 2017-02-19T09:58:26.778Z cpu17:33637)0x43911b29bf30:[0x418032a502c2]helpFunc@vmkernel#nover+0x4e6 stack: 0x0, 0x43060d6a60a0, 0x35, 0x0, 2017-02-19T09:58:26.778Z cpu17:33637)0x43911b29bfd0:[0x418032c14c1e]CpuSched_StartWorld@vmkernel#nover+0xa2 stack: 0x0, 0x0, 0x0, 0x0, 0

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Die Verwendung von objtool auf einem vSAN-Witness-Server führt möglicherweise dazu, dass ein ESXi-Host mit einem violetten Bildschirm fehlschlägt

    Wenn Sie objtool auf einem Witness-Host verwenden, wird ein ioctl-Aufruf durchgeführt, der zu einer NULL-Zeiger-Dereferenzierung im vSAN ESXi-Witness-Host und zu einem Absturz des Hosts führt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Eine Außerbetriebnahme von deduplizierungs- und komprimierungsfähigen Festplatten, die fehlschlagende Datenträgerzugriffsbefehle aufweisen, kann zu einem Ausfall mit violettem Diagnosebildschirm im vSAN-Knoten führen

    Während der Außerbetriebnahme einer vSAN-Festplattengruppe mit aktivierter Deduplizierung und Komprimierung sollte diese Festplattengruppe über Festplatten mit Zugriffsbefehlsfehlern verfügen. Die Fehler können mit vmkernel-Protokollmeldungen überprüft werden, wie etwa:
    Partition: 914: Lesen des GPT-Header (hdrlba = 1) fehlgeschlagen bei „naa.55cd2e404c185332“ : E/A-Fehler.
    Dies führt zu einem Ausfall des vSAN-Hosts während der Außerbetriebnahme.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Sie erhalten möglicherweise einen Fehlalarm bei der vSAN-Systemstatusprüfung

    In manchen Fällen meldet die Benutzeroberfläche zum vSAN-Systemstatus möglicherweise einen falschen Status für die Netzwerk-Systemstatusprüfung des Typs „Für alle Hosts ist eine Virtual SAN-vmknic konfiguriert“, und dann wird ein falscher vCenter Server-Alarm ausgelöst.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Eine virtuelle Maschine reagiert möglicherweise nicht mehr oder ein Host wird von vCenter Server getrennt. Dies geht mit einem Protokollstau in Version 6.0 Update 2 oder einer Arbeitsspeicherüberlastung in Version 6.0 Update 3 einher

    Durch das Entfernen einer vSAN-Komponente, die sich in einem ungültigen Zustand eines vSAN-Clusters befindet, reagiert eine virtuelle Maschine möglicherweise nicht mehr oder ein Host wird von vCenter Server getrennt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Ein ESXi-Host schlägt möglicherweise mit einem violetten Bildschirm fehl

    Ein ESXi-Host schlägt möglicherweise aufgrund eines Race-Fehlers zwischen der Initialisierung des verteilten Objektmanager-Clients und den Codepfaden der VMkernel-Sysinfo-Schnittstelle des verteilten Objektmanagers fehl.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Eine SSD-Überlastung kann dazu führen, dass mehrere virtuelle Maschinen nicht mehr reagieren

    Abhängig von der Arbeitslast und der Anzahl an virtuellen Maschinen wechseln Festplattengruppen auf dem Host möglicherweise in den Zustand des permanenten Geräteverlustes (PDL). Dies führt dazu, dass die Festplattengruppen keine weiteren IOs zulassen und diese nicht verwendet werden können, bis ein manueller Eingriff erfolgt.
     

    Dieses Problem wurde in der vorliegenden Version behoben.

Bekannte Probleme

Die bekannten Probleme gliedern sich in folgende Gruppen.

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-ProblemeLesen 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

    • Benutzeroberfläche des Virtual SAN-Systemzustands 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.

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

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