Versionshinweise zu VMware ESXi 6.0 Update 1b

|

Aktualisiert am: 7. JANUAR 2016

ESXi 6.0 Update 1b | 7. Januar 2016 | ISO Build 3380124

Ü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

  • ESXi 6.0 Update 1b ermöglicht Unterstützung der TLS-Versionen 1.1und 1.2 für die meisten vSphere-Komponenten, ohne die zuvor unterstützte Kompatibilität/Interoperabilität zu unterbrechen. Einige der vSphere-Komponenten, die nach wie vor nur TLS Version 1.0 unterstützen, sind im Folgenden aufgelistet:
    • vSphere Client
    • Virtual SAN Observer auf vCenter Server Appliance (vCSA)
    • Syslog auf vCSA
    • Auto Deploy auf vCSA
    • Auto Deploy/iPXE

    Das ESXi 6.0 Update 1b unterstützt jetzt alle TLS-Versionen 1.0, 1.1 und 1.2 mit den oben aufgelisteten Ausnahmen. Im Knowledgebase-Artikel 2136185 finden Sie die Liste der unterstützten TLS-Protokolle.

  • Support für Advanced Encryption Standard (AES) mit128/256-Bit-Schlüssellänge wird für RPC-Kopfzeilenauthentifizierung im NFS 4.1 Client hinzugefügt.
    Hinweis: Im Abschnitt zu behobenen Sicherheitsproblemen finden Sie weitere Informationen.

  • In dieser Version von ESXi 6.0 Update 1b werden die im Abschnitt Behobene Probleme dokumentierten Probleme behandelt.

Vorherige Versionen von ESXi 6.0

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

Internationalisierung

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

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

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

Kompatibilität

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

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

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

Hardwarekompatibilität für ESXi

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

Gerätekompatibilität für ESXi

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

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

Kompatibilität von ESXi zu Drittanbieter-Switches

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

Kompatibilität von Gastbetriebssystemen für ESXi

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

Kompatibilität von virtuellen Maschinen für ESXi

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

Installation und Upgrades für diese Version

Installationshinweise für diese Version

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

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

Empfohlene Bereitstellungsmodelle für vSphere 6.0

VMware empfiehlt nur zwei Bereitstellungsmodelle:

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

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

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

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

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

Informationen zum vCenter-Host-Betriebssystem

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

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

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

Migration vom eingebetteten Platform Services Controller zum externen Platform Services Controller

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

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

Migrieren von Drittanbieter-Lösungen

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

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

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

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

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

Upgrade-Hinweise für diese Version

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

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

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

Hinweise zur Produktunterstützung

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

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

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

In dieser Version enthaltene Patches

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

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

ESXi600-201601401-BG: Aktualisiert ESXi 6.0 esx-base vib
ESXi600-201601402-BG: Aktualisiert ESXi 6.0 tools-light vib
ESXi600-201601403-BG: Aktualisiert ESXi 6.0 ehci-ehci-hcd, misc-drivers vib
ESXi600-201601404-BG: Aktualisiert ESXi 6.0 net-tg3 vib
ESXi600-201601405-BG: Aktualisiert ESXi 6.0 net-e1000e vib

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

ESXi600-201601101-SG: Aktualisiert ESXi 6.0 esx-base vib
ESXi600-201601102-SG: Aktualisiert ESXi 6.0 tools-light vib

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

ESXi-6.0.0-20160104001-standard
ESXi-6.0.0-20160104001-no-tools

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

ESXi-6.0.0-20160101001s-standard
ESXi-6.0.0-20160101001s-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.

Lizenzierungsprobleme
  • Versuche zum Erstellen des VFFS-Datenspeichers schlagen fehl
    vCenter Server verhindert die Erstellung des VFFS-Datenspeichers (Virtual Flash File System) mit einer Fehlermeldung wie der Folgenden:

    Die Lizenz zum Ausführen des Vorgangs ist nicht verfügbar. Funktion 'vSphere Flash Read Cache' ist für diese Edition nicht lizenziert

    Dieses Problem tritt aufgrund einer inkorrekten Prüfung der VFRC-Berechtigung (vSphere Flash Read Cache) auf.

    Dieses Problem wurde in der vorliegenden Version behoben.
Netzwerkprobleme
  • Von VMware vShield App geschützte virtuelle Maschinen verlieren die Netzwerkkonnektivität auf den ESXi 6.0-Hosts
    Von VMware vShield App Firewall geschützte virtuelle Maschinen verlieren zeitweise die Netzwerkkonnektivität auf den ESXi 6.0-Hosts. In den vShield App Firewall-Protokollen werden Fehlermeldungen wie die Folgende angezeigt:

    YYYY-MM-DDTHH:MM:SS+00:00 vShield-FW-hostname.corp.local kernel: d0: tx hang
    YYYY-MM-DDTHH:MM:SS+00:00 vShield-FW-hostname.corp.local kernel: d0: resetting
    YYYY-MM-DDTHH:MM:SS+00:00 vShield-FW-hostname.corp.local kernel: d0: intr type 3, mode 0, 3 vectors allocated
    YYYY-MM-DDTHH:MM:SS+00:00 vShield-FW-hostname.corp.local kernel: RSS-Indirektionstabelle:

    Dieses Problem wurde in der vorliegenden Version behoben. Weitere Details finden Sie im Knowledgebase-Artikel 2128069.
  • Versuche, den Modus von Emulation zu UPT zu wechseln, können in ESXi 6.0 fehlschlagen
    Versuche, den Modus von Emulation zu Universal Pass-through (UPT) zu wechseln, können in ESXi 6.0 fehlschlagen. vCenter Server zeigt die folgende Meldung an, um anzugeben, dass DirectPath I/O deaktiviert ist:

    Die virtuelle Maschine verfügt nicht über die volle Arbeitsspeicherreservierung, die zum Aktivieren von DirectPath I/O erforderlich ist.

    Die folgende Meldung ist in der Datei vmkernel.log protokolliert:

    YYYY-MM-DDTHH:MM:SS.820Z cpu11:1000046564)Vmxnet3: VMKDevCanEnterPT:3193: port 0x3000007: memory reservation 0 smaller than guest memory size 262144

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Es dauert sehr lange, bis das VM-Supportprotokoll für einen ESXi-Host Protokolle erfasst
    Der Befehl vm-support benötigt für das Erfassen der Protokolle viel Zeit, da nicht benötigte .dvsData-Protokolle aus allen .dvsData-Ordnern aus allen zugreifbaren Datenspeichern erfasst werden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Hostd hält wiederholt an und antwortet mit einem Signal 11-Fehler
    Nach der Konfiguration von 4 NICs (Network Interface Controller) für dvSwitch reagiert hostd wiederholt nicht mehr mit dem Signal 11-Fehler.

    Dieses Problem wurde in der vorliegenden Version behoben.
Speicherprobleme
  • Das Starten des ESXi-Hosts dauert sehr lange, und das Modul „VMW_SATP_ALUA SATP“ wird nicht geladen
    Wenn das Starten eines ESXi-Hosts sehr lange dauert und das SATP-Modul (Storage Array Type Plug-In) „VMW_SATP_ALUA“ nicht geladen wird, kann dies an veralteten LUN-Einträgen in der Datei esx.conf der LUN liegen, die sich im Zustand eines dauerhaften Geräteverlusts (Permanent Device Loss, PDL) befinden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das esxtop-Dienstprogramm gibt für DAVG/cmd und KAVG/cmd auf VAAI-unterstützten LUNs falsche Statistiken an
    Das esxtop-Dienstprogramm gibt auf VAAI-unterstützten LUNs für DAVG/cmd (durchschnittliche Gerätelatenz per Befehl) und KAVG/cmd (durchschnittliche ESXi-VMkernel-Latenz per Befehl) aufgrund einer falschen Berechnung falsche Statistiken an.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Erweiterung von Eager-Zeroed-VMDK führt dazu, dass die VM unerreichbar ist
    In ESXi 6.0 werden VMDKs des Typs Eager-Zeroed im Eager-Zeroed-Format erweitert, was lange dauert und dazu führen kann, dass die VM unerreichbar ist.

    Dieses Problem wurde in der vorliegenden Version behoben.
Virtual SAN-Probleme
  • Verwaistes Virtual SAN-Objekt wird beibehalten, nachdem auf der SSD ein APD-Festplattenfehler auftritt
    Ein verwaistes Virtual SAN-Objekt wird möglicherweise beibehalten, nachdem auf der SSD (Solid State Disk) ein APD-Festplattenfehler (All Paths Down, keine Pfade verfügbar) auftritt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Festplattengruppen-Validierung schlägt möglicherweise aufgrund von ungültigen Metadaten auf der SSD/MD-Festplattenpartition fehl
    Versuche, eine Festplatte von einer Virtual SAN-Festplattengruppe zu entfernen, führen möglicherweise zur Anzeige eines violetten Diagnosebildschirms, da die Validierung der Festplattengruppe aufgrund von ungültigen Metadaten auf der SSD/MD-Festplattenpartition fehlschlägt. Fehlermeldungen ähnlich der folgenden werden in die Protokolldatei vmkernel.log geschrieben:

    YYYY-MM-DDTHH:MM:SS.772Z cpu13:xxxxx)PLOG: PLOGRelogCleanup:445: RELOG complete uuid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx lsn xxxxxxx numRelogged 0
    YYYY-MM-DDTHH:MM:SS.772Z cpu33:xxxxx opID=xxxxxxxx)World: 9728: PRDA 0xnnnnnnnnnnnn ss 0x0 ds 0x10b es 0x10b fs 0x0 gs 0x13b
    YYYY-MM-DDTHH:MM:SS.772Z cpu33:xxxxx opID=xxxxxxxx)World: 9730: TR 0xnnnn GDT 0xnnnnnnnnnnnn (0xnnnn) IDT 0xnnnnnnnnnnnn (0xfff)
    .
    .
    .

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Falscher Wert für Datenträgerkapazität wird angezeigt, wenn neuer Speicherplatz zu Thin-Komponentendateien während Komponenten-E/A-Vorgängen auf Virsto-Volumes hinzugefügt wird
    Während E/A-Vorgängen für eine Komponente kann Thin-Komponentendateien neuer Speicherplatz hinzugefügt werden. Für Komponentendateien auf Virsto-Volumes wird die Festplattenkapazität nicht neu berechnet, und der alte Wert wird bis zur Erstellung einer neuen Komponente veröffentlicht.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Schlechte VM-Leistung in einem Virtual SAN-Cluster wegen SSD-Protokollstau
    VMs in einem Virtual SAN-Cluster können wegen eines Protokollstauproblems bei der SSD (Solid-State Disk) schlechte Leistung erbringen. Die VMKernel System Information (VSI)-Knoten für die SSD geben an, dass sehr viel Protokollspeicherplatz belegt ist und nicht reduziert wird.

    Dieses Problem wurde in der vorliegenden Version behoben.
Sicherheitsprobleme
  • Support für Advanced Encryption Standard (AES) mit128/256-Bit-Schlüssellänge wird in NFS 4.1 Client für RPC-Kopfzeilenauthentifizierung hinzugefügt
    Support für Advanced Encryption Standard (AES) mit128/256-Bit-Schlüssellänge wird für RPC-Kopfzeilenauthentifizierung im NFS 4.1 Client hinzugefügt.
    Hinweis: DES_CBC_MD5-Verschlüsselung wird für den NFS 4.1 Client nicht mehr unterstützt. Wenn AES-Verschlüsselung nicht aktiviert ist oder die aktuelle Firmwareversion AES-Verschlüsselung nicht unterstützt, müssen Sie die Array-Firmware aktualisieren oder die AES-Verschlüsselung aktivieren, bevor Sie dieses Patch-Upgrade ausführen.
  • Das SSLv3-Protokoll ist auf dem ESXi-SSL-Syslog-Remoteclient deaktiviert
    Der ESXi-SSL-Syslog-Remoteclient verwendet das SSLv3-Protokoll, das als unsicher gilt. Dieses Problem wird in dieser Version behoben, indem SSLv3 standardmäßig deaktiviert und Unterstützung für die TLS-Versionen 1.0, 1.1 und 1.2 aktiviert wird.
  • Update der OpenSSL-Bibliothek
    Die Userworld-Version der OpenSSL-Bibliothek von ESXi wurde auf openssl-1.0.1p aktualisiert.
Serverkonfigurationsprobleme
  • Der ESXi-Host wird unerwarteterweise neu gestartet, gefolgt von einer UMCE-Fehlermeldung (Uncorrectable Machine Check Exception)
    Nach dem Upgrade des ESXi-Hosts mit 1,5 TB Speicherplatz von Version 5.1 auf 6.0 auf einem HP-Server mit AMD-Prozessor kann es vorkommen, dass der Host unerwarteterweise nicht mehr reagiert oder neu gestartet wird. UMCEs (Uncorrectable Machine Check Exceptions) ähnlich wie die Folgenden werden in die IML-Datei (Integrated Management Log) geschrieben.

    Critical","CPU","##/##/2014 15:41","##/##/2014 15:41","1","Uncorrectable Machine Check Exception (Board 0, Processor 3, APIC ID 0x00000060, Bank 0x00000004, Status 0xF6000000'00070F0F, Address 0x00000050'61EA3B28, Misc 0x00000000'00000000)",
    Mode of failure: Unexpectedly reboot. IML displays UMCE occurred.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Ein ESXi-Host kann nicht für Active Directory-Authentifizierung konfiguriert werden
    Versuche des Beitritts eines ESXi-Hosts mit einer großen Anzahl CPUs zu einer Active Directory-Domäne können fehlschlagen.

    Dieses Problem wurde in der vorliegenden Version behoben. Weitere Details finden Sie im Knowledgebase-Artikel 2130395.
  • Interrupt nach Ungültiger-Vektor-Meldung als Systemwarnung angezeigt
    Nach Anwendung der ESXi-Patch-Version ESXi600-201510001 erhalten Sie möglicherweise Systemwarnmeldungen wie die Folgende aufgrund eines ungültigen Vektors, und es können mehrere Ereignisse in vCenter Server generiert werden.

    cpu48:88874)ALERT: IntrCookie: 3411: Interrupt received on invalid vector (cpu 48, vector 73); ignoring it.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • CBT-Funktionalität, QueryChangedDiskAreas-API, kann falsche Sektoren zurückgeben
    Wenn Sie in ESXi 6.0 Sicherungen für virtuelle Maschinen ausführen, die Changed Block Tracking (CBT) verwenden, kann der CBT-API-Aufruf QueryDiskChangedAreas() falsche geänderte Sektoren zurückgeben, was zu inkonsistenten inkrementellen Sicherungen der virtuellen Maschinen führt. Das Problem tritt auf, weil CBT die geänderten Blöcke auf den VMs mit E/A während der Snapshot-Konsolidierung nicht verfolgt.

    Dieses Problem wurde in der vorliegenden Version behoben. Weitere Details finden Sie im Knowledgebase-Artikel 2136854.
VM-Verwaltungsprobleme
  • Der Befehl „esxcli vm process list“ zeigt möglicherweise den alten VM-Namen an, nachdem eine eingeschaltete VM umbenannt wurde
    Wenn Sie nach dem Umbenennen einer eingeschalteten virtuellen Maschine den Befehl esxcli vm process list ausführen, um vom Host eine Liste der ausgeführten VMs abzurufen, zeigt die Liste möglicherweise den alten VM-Namen an.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • vCenter Server reagiert möglicherweise nicht mehr, wenn der ESXi-Host die Konnektivität zum Syslog-Remoteserver verliert
    Wenn ein ESXi-Host Konnektivität zum Syslog-Remoteserver verliert, werden für die Ereignisse GeneralHostWarningEvent und AlarmStatusChangedEvent für unbestimmte Zeit zu viele Warnmeldungen protokolliert. Infolgedessen wird die vCenter-Datenbank durch die Tabellen „vpx_event“ und „vpx_event_arg“ überfüllt. Das Problem verursacht eine hohe vCenter-Latenz und führt dazu, dass der vCenter Server nicht mehr reagiert.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • VMX schlägt bei Windows 10 VM fehl
    Der vmx-Prozess für Windows 10-VMs schlägt mit einer Fehlermeldung wie der Folgenden in der Datei vmware.log fehl:

    NOT_REACHED bora/devices/ahci/ahci_user.c:1530

    Dieses Problem wurde in der vorliegenden Version behoben.
  • VMX schlägt möglicherweise beim Ausführen einiger 3D-Anwendungen fehl
    VMX schlägt möglicherweise beim Ausführen einiger 3D-Anwendungen fehl. Fehlermeldungen ähnlich der Folgenden werden in die Protokolldatei vmware.log geschrieben:

    xxxx-xx-xxTxx:xx:xx.xxxZ| svga| I120: [msg.log.error.unrecoverable] VMware ESX unrecoverable error: (svga)
    xxxx-xx-xxTxx:xx:xx.xxxZ| svga| I120+ NOT_REACHED bora/mks/hostops/shim/shimOps.c:674

    Dieses Problem wurde in der vorliegenden Version behoben.
Probleme bei vMotion und Storage vMotion
  • Virtuelle Maschine reagiert während der Snapshot-Konsolidierung auf ESXi 6.0 nicht mehr
    Beim Konsolidieren eines auf einem ESXi 6.0-Host gehosteten Snapshots einer virtuellen Maschine hält die VM an und erstellt eine vmx-zdump-Datei im Arbeitsverzeichnis der VM. Die Datei vmkernel.log unter /var/log/vmkernel.log zeigt Meldungen wie die Folgende an:

    cpu17:xxxxxxxx)SVM: xxxx: Error destroying device xxxxxxxx-xxxxxxxx-svmmirror (Busy)
    cpu2:xxxxx)FSS: xxxx: No FS driver claimed device 'xxxxxxxx-xxxxxxxx-svmmirror': No filesystem on the device
    cpu2:xxxxx)FSS: xxxx: No FS driver claimed device 'control': No filesystem on the device

    Dieses Problem wurde in der vorliegenden Version behoben. Weitere Details finden Sie im Knowledgebase-Artikel 2135631.
  • Storage vMotion einer virtuellen Maschine, deren Name mit „core“ beginnt, schlägt fehl
    Versuche, Storage vMotion oder eine Cold-Migration einer VM durchzuführen, deren Name mit „core“ beginnt, können fehlschlagen. vSphere Web Client zeigt Fehlermeldungen ähnlich der Folgenden:

    Verlagern der virtuellen Maschine core01 Vorgang kann nicht abgeschlossen werden, weil die Datei oder der Ordner
    ds:///vmfs/volumes/xxxxxxxx-xxxxxxxx-xxxx-xxxxxxxxxxxx/core01/core01-xxxxxxxx.hlog bereits vorhanden ist
    Zieldateien werden auf Konflikte hin überprüft Administrator vCenter_Server_name

    Dieses Problem wurde in der vorliegenden Version behoben. Weitere Details finden Sie im Knowledgebase-Artikel 2130819.
VMware HA- und Fault Tolerance-Konfigurationsprobleme
  • Virtuelle Maschinen starten nach einem High Availability Failover nicht
    Nach einem ESXi-Hostfehler reagieren manche VMs beim Neustart möglicherweise nicht mehr, wenn HA versucht, die betroffenen VMs auf anderen Hosts zu starten.

    Dieses Problem wurde in der vorliegenden Version behoben.
Sonstige Probleme
  • Universelle Sicherheitsgruppen werden in der ESXi-Benutzerschnittstelle zum Zuweisen von Berechtigungen nicht angezeigt
    Beim Zuweisen von Berechtigungen auf einem ESXi-Host werden nur die globalen Sicherheitsgruppen und nicht die universellen Sicherheitsgruppen in der Liste Benutzer und Gruppen auswählen angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • VMKernel-Protokolldatei wird mit Warnungen im VM-Seiten-Fehlerpfad überfüllt, was zum Fehlschlagen des Hosts führen kann
    Versuche, VMs mit höherer Bildschirmauflösung oder mehreren Monitoren einzuschalten, können dazu führen, dass mehrere Warnmeldungen wie die Folgende in die Datei vmkernel.log geschrieben werden, und der Host kann wegen zu großer Protokolllast fehlschlagen:

    XXXX-XX-XXTXX:XX:XX.XXXZ cpuXX:XXXXXXX)WARNING: VmMemPf: vm XXXXXXX: 654: COW copy failed: pgNum=0xXXXXX, mpn=0x3fffffffff
    XXXX-XX-XXTXX:XX:XX.XXXZ cpuXX:XXXXXXX)WARNING: VmMemPf: vm XXXXXXX: 654: COW copy failed: pgNum=0xXXXXX, mpn=0x3fffffffff

    Dieses Problem wurde in der vorliegenden Version behoben.
Probleme bei VMware Tools
  • Versuche, VMware Tools zu aktualisieren, schlagen mit einem Fehlercode 21009 fehl
    Wenn Sie versuchen, VMware Tools für eine virtuelle Maschine zu aktualisieren, die auf VMware ESXi 6.0 ausgeführt wird, schlägt das automatische Upgrade mit folgendem Fehler fehl:

    vix error code = 21009

    Das Problem tritt auf, wenn die folgenden Gastdateien in einer virtuellen Maschine vorhanden sind:

    C:\Windows\\Temp\\vmware-SYSTEM\\VMwareToolsUpgrader.exe

    Red Hat Enterprise Linux VM:

    /tmp/vmware-root

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Virtuelle Maschinen, die SAP ausführen, schlagen willkürlich fehl
    Virtuelle Maschinen, die SAP ausführen, können nach dem Zufallsprinzip in vmx.zdump fehlschlagen, wenn zu viele Statistikbefehle von VMware Tools in der VM ausgeführt werden. Eine Fehlermeldung ähnlich der Folgenden wird in die Protokolldatei vmware.log geschrieben:

    CoreDump error line 2160, error Cannot allocate memory.

    Dieses Problem wurde in der vorliegenden Version behoben. Weitere Details finden Sie im Knowledgebase-Artikel 2137310.

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 DNS-Suffix wird mögicherweise beibehalten, auch nachdem Sie die Standardkonfiguration in DCUI geändert haben
    Ein ESXi-Host wird möglicherweise automatisch beim ersten Starten mit der Standard-DNS + DNS-Suffix konfiguriert, wenn er auf einem von einem DHCP-Server bedienten Netzwerk bereitgestellt wird. Wenn Sie versuchen, das DNS-Suffix zu ändern, entfernt die DCUI das vorhandene DNS-Suffix nicht, sondern fügt einfach das neue angegebene Suffix hinzu.

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

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

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

Upgrade-Probleme

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

  • 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

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

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

  • 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
  • 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
  • Neues Problem Keine Verbindung des ESXi 6.0-Hosts, bei dem nur TLS-Version 1.1 und 1.2 aktiviert ist, zu vCenter Virtual Appliance 5.5 möglich
    Versuche, eine Verbindung des ESXi 6.0-Hosts, bei dem nur TLS-Version 1.1 und 1.2 aktiviert ist, zu vCenter Virtual Appliance (VCVA) 5.5 herzustellen, schlagen fehl, da VCVA nur SSLv3- und TLSv1.0-Protokolle unterstützt.

    Problemumgehung: Aktivieren Sie das SSLv3- oder TLS1.0-Protokoll auf dem ESXi 6.0-Host, um eine Verbindung zu vCenter Virtual Appliance 5.5 herzustellen.

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

>