Versionshinweise zu VMware ESXi 5.5 Update 2

|

VMware ESXi™ 5.5 Update 2 | 9. September 2014 | Build 2068190

Letzte Aktualisierung: 2. Juli 2015

Überprüfen Sie, ob Erweiterungen und Updates für diese Versionshinweise zur Verfügung stehen.

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

Neuigkeiten

Die vorliegende Version von VMware ESXi weist folgende Verbesserungen auf:

  • Unterstützung für Hosts mit 6 TB RAM – vSphere 5.5 Update 2 unterstützt jetzt Hosts mit 6 TB RAM.
  • VMware vShield Endpoint Thin Agent wurde in Guest Introspection umbenannt (VMware Tools-Plug-In) – Der in VMware Tools enthaltene vShield Endpoint-Treiber heißt jetzt Guest Introspection.
  • Behobene Probleme Diese Version enthält zahlreiche Fehlerkorrekturen, die im Abschnitt Behobene Probleme dokumentiert sind.

Vorherige Versionen von ESXi 5.5

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

Internationalisierung

VMware vSphere 5.5 Update 2 gibt es in den folgenden Sprachen:

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

Kompatibilität und Installation

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.

vCenter Server ISO enthält den vSphere Client und den vSphere Web Client. Mithilfe des VMware vCenter™-Installationsassistenten können Sie einen oder beide Clients installieren.

ESXi, vCenter Server und VDDK-Kompatibilität

Virtual Disk Development Kit (VDDK) 5.5.3 bietet Unterstützung für die Versionen ESXi 5.5 Update 2 und vCenter Server 5.5 Update 2.
Weitere Informationen zu VDDK finden Sie unter http://www.vmware.com/support/developer/vddk/.

Kompatibilität von ESXi und Virtual SAN

Virtual SAN unterstützt keine Cluster, die mit ESXi-Hosts vor 5.5 Update 1 konfiguriert sind. Führen Sie für alle Hosts im Virtual SAN-Cluster ein Upgrade auf ESXi 5.5 Update 1 oder höher durch, bevor Sie Virtual SAN aktivieren. Auch vCenter Server sollte auf 5.5 Update 1 oder höher aktualisiert werden.

Hardwarekompatibilität für ESXi

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

Gerätekompatibilität für ESXi

Verwenden Sie die Informationen zu ESXi 5.5 Update 2 im VMware-Kompatibilitätshandbuch, um die Geräte zu ermitteln, die mit ESXi 5.5 Update 2 kompatibel sind.

Einige Geräte sind veraltet und werden nicht mehr von ESXi 5.5 und höher unterstützt. Während des Upgrade-Vorgangs wird der Gerätetreiber auf dem ESXi 5.5.x-Host installiert. Er funktioniert möglicherweise auch unter ESXi 5.5.x, aber das Gerät wird unter ESXi 5.5.x nicht unterstützt. Eine Aufstellung der veralteten Geräte, die nicht mehr von ESXi 5.5.x unterstützt werden, finden Sie im VMware-Knowledgebase-Artikel Veraltete Geräte und Warnungen während des Upgrade-Vorgangs von ESXi 5.5.

Kompatibilität von ESXi zu Drittanbieter-Switches

VMware unterstützt Cisco Nexus 1000V mit vSphere 5.5. 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 nicht unterstützt.

Kompatibilität von Gastbetriebssystemen für ESXi

Verwenden Sie die Informationen zu ESXi 5.5 Update 2 im VMware-Kompatibilitätshandbuch, um die Gastbetriebssysteme zu ermitteln, die mit vSphere 5.5 Update 2 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 mit ESXi 5.5 Update 2 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 5.5 Update 2 verwenden möchten, führen Sie ein Upgrade der VM-Kompatibilität durch. Weitere Informationen finden Sie in der vSphere-Upgrade-Dokumentation.

vSphere Client-Verbindungen zu Umgebungen im verknüpften Modus mit vCenter Server 5.x

vCenter Server 5.5 kann sich nur zusammen mit anderen Instanzen von vCenter Server 5.5 im verknüpften Modus befinden.

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:

Migrieren von Drittanbieterlösungen

Sie können bei einem Host-Upgrade keine Lösungen von Drittanbietern, die auf einem ESX- oder ESXi-Host installiert sind, direkt migrieren. Architektonische Änderungen zwischen ESXi 5.1 und ESXi 5.5 führen zu einem Verlust von Drittanbieter-Komponenten und einer möglichen Systeminstabilität. Zur Ausführung solcher Migrationen können Sie mit Image Builder eine benutzerdefinierte ISO-Datei erstellen. Weitere Informationen zum Upgrade Ihres Hosts 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 5.5.x unterstützt nur CPUs mit LAHF- und SAHF-Befehlssätzen. Bei einer Installation oder einem Upgrade prüft das Installationsprogramm die Kompatibilität der Host-CPU mit vSphere 5.5.x. Wenn Ihre Hosthardware nicht kompatibel ist, erscheint ein violetter Bildschirm mit einer entsprechenden Meldung. Sie können vSphere 5.5.x weder installieren noch ein Upgrade darauf durchführen.

Upgrades für diese Version

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

Unterstützte Upgrade-Pfade für das Upgrade auf ESXi 5.5 Update 2:

Upgrade-Lieferumfang

Unterstützte Upgrade-Tools

Unterstützte Upgrade-Pfade auf ESXi 5.5 Update 2

ESX/ESXi 4.0:
Enthält
ESX/ESXi 4.0 Update 1
ESX/ESXi 4.0 Update 2

ESX/ESXi 4.0 Update 3
ESX/ESXi 4.0 Update 4

ESX/ESXi 4.1:
Enthält
ESX/ESXi 4.1 Update 1
ESX/ESXi 4.1 Update 2

ESX/ESXi 4.1 Update 3

ESXi 5.0:
Enthält
ESXi 5.0 Update 1

ESXi 5.0 Update 2
ESXi 5.0 Update 3

ESXi 5.1
Enthält
ESXi 5.1 Update 1
ESXi 5.1 Update 2

ESXi 5.5:
Enthält
ESXi 5.5 Update 1

VMware-VMvisor-Installer-5.5.0.update02-2068190.x86_64.iso

 

  • VMware vCenter Update Manager
  • CD-Upgrade
  • Skriptbasiertes Upgrade

Ja

Ja

Ja

Ja

Ja

update-from-esxi5.5-5.5_update02.zip
  • VMware vCenter Update Manager
  • ESXCLI
  • VMware vSphere-CLI

Nein

Nein

Ja*

Ja*

Ja

Verwendung von Patch-Definitionen, die vom VMware-Portal (online) heruntergeladen werden VMware vCenter Update Manager mit Patch-Baseline

Nein

Nein

Nein

Nein

Ja


*Hinweis: Ein Upgrade von ESXi 5.0.x oder ESXi 5.1.x auf ESXi 5.5 Update 2 mithilfe von update-from-esxi5.5-5.5_update02.zip wird nur in ESXCLI unterstützt. Sie müssen den Befehl esxcli software profile update --depot=<depot_location> --profile=<profile_name> ausführen, um das Upgrade durchzuführen. Weitere Informationen finden Sie im vSphere-Upgrade-Handbuch im Abschnitt ESXi 5.5.x Upgrade-Optionen.

Open Source-Komponenten für VMware vSphere 5.5 Update 2

Informationen über Copyright und Lizenzen für die Open Source-Softwarekomponenten, die im Lieferumfang von vSphere 5.5 Update 2 enthalten sind, finden Sie unter http://www.vmware.com/download/vsphere/open_source.html auf der Registerkarte „Open Source“. Sie können 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 erfordern.

Hinweise zur Produktunterstützung

  • vSphere Web Client. Linux-Plattformen werden von Adobe Flash nicht mehr unterstützt, weshalb der vSphere Web Client unter dem Linux-Betriebssystem nicht unterstützt wird. Drittanbieter-Browser, die die Unterstützung für Adobe Flash unter dem Linux-Desktop-Betriebssystem hinzufügen, sind möglicherweise weiterhin funktionsfähig.

    VMware vCenter Server Appliance. In vSphere 5.5 hält die VMware vCenter Server Appliance durch Erzwingen der DISA Security Technical Information Guidelines (STIG) strenge Compliance-Standards ein. Vor der Bereitstellung der VMware vCenter Server Appliance sollten Sie im VMware Hardened Virtual Appliance Operations Guide die Informationen zu den neuen Sicherheitsstandards für die Bereitstellung nachlesen, um den erfolgreichen Betrieb sicherzustellen.

  • vCenter Server-Datenbank. In vSphere 5.5 wird IBM DB2 nicht mehr als vCenter Server-Datenbank unterstützt.

  • VMware Tools. Ab vSphere 5.5 werden alle Informationen zum Installieren und Konfigurieren von VMware Tools in vSphere mit der restlichen vSphere-Dokumentation zusammengefasst. Informationen zur Verwendung von VMware Tools in vSphere finden Sie in der vSphere-Dokumentation. Installieren und Konfigurieren von VMware Tools ist für vSphere 5.5 und höher nicht relevant.

  • VMware Tools. Ab vSphere 5.5 gibt es in VMware Tools keine ThinPrint-Funktionen mehr.

  • vSphere Data Protection. vSphere Data Protection 5.1 ist aufgrund der geänderten Funktionsweise des vSphere Web Client nicht mit vSphere 5.5 kompatibel. Benutzer von vSphere Data Protection 5.1, die ein Upgrade auf vSphere 5.5 durchführen, müssen auch vSphere Data Protection aktualisieren, falls sie vSphere Data Protection weiterhin verwenden möchten.

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

ESXi550-201409201-UG: Aktualisiert ESXi 5.5 esx-base vib
ESXi550-201409202-UG: Aktualisiert ESXi 5.5 tools-light vib
ESXi550-201409203-UG: Aktualisiert ESXi 5.5 net-tg3 vib
ESXi550-201409204-UG: Aktualisiert ESXi 5.5 sata-ahci vib
ESXi550-201409205-UG: Aktualisiert ESXi 5.5 scsi-megaraid-sas vib
ESXi550-201409206-UG: Aktualisiert ESXi 5.5 mi sc-drivers vib
ESXi550-201409207-UG: Aktualisiert ESXi 5.5 stomata vib

a

Patch-Version ESXi550-Update02 Security-only enthält die folgenden einzelnen Bulletins:

ESXi550-201409101-SG: Aktualisiert ESXi 5.5 esx-base vib

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

ESXi-5.5.0-20140902001-standard
ESXi-5.5.0-20140902001-no-tools

Patch-Version ESXi550-Update02 Security-only enthält die folgenden Image-Profile:

ESXi-5.5.0-20140901001s-standard
ESXi-5.5.0-20140901001s-no-tools

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

Behobene Probleme

In diesem Abschnitt werden in dieser Version gelöste Probleme beschrieben:

CIM- und API-Probleme

  • Auf dem ESXi-Host kann eine hohe E/A-Latenz auftreten
    Wenn an den LSI-SMI-S-Anbieter auf einem ESXi-Host umfangreiche CIM-Anforderungen gesendet werden, kann auf dem ESXi-Host aufgrund von unzureichendem Speicherplatz eine hohe E/A-Latenz auftreten.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • vCenter Server zeigt möglicherweise den Status der Stromversorgungsinformationen als unbekannt an
    Nach dem Installieren eines ESXi-Hosts und Herstellen der Verbindung mit vCenter Server werden auf der vCenter Server-Registerkarte Hardwarestatus die Stromversorgungsinformationen möglicherweise als unbekannt angegeben.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der sfcbd-Dienst kann nicht beendet oder neu gestartet werden
    Wenn Sie den Hardware-Überwachungsdienst (sfcbd) in vCenter Server beenden und starten, um den Hardwarestatus des Hosts zu überwachen, reagiert der sfcbd-Prozess möglicherweise nicht mehr und in der Datei syslog wird ein Fehler ähnlich dem folgenden ausgegeben:

    sfcbd: Sending TERM signal to sfcbd
    sfcbd-watchdog: Sleeping for 20 seconds
    sfcbd: Sending TERM signal to sfcbd
    sfcbd-watchdog: Sleeping for 20 seconds
    sfcbd-watchdog: Waited for 3 20 second intervals, SIGKILL next
    sfcbd: Stopping sfcbd
    sfcbd-watchdog: Sleeping for 20 seconds
    sfcbd-watchdog: Providers have terminated, lets kill the sfcbd.
    sfcbd-watchdog: Reached max kill attempts. watchdog is exiting


    Dieses Problem wurde in der vorliegenden Version behoben.
  • sfcb antwortet möglicherweise mit falschem Methodenanbieter
    Wenn Sie auf einem ESXi-Host zwei verschiedene Methodenanbieter bei der gleichen CIM-Klasse mit unterschiedlichen Namespaces registrieren, antwortet der sfcb auf Anfrage immer mit dem Anbieter, der am weitesten oben in „providerRegister“ aufgelistet ist. Dabei kann es sich um einen falschen Methodenanbieter handeln.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Hostd antwortet möglicherweise nicht, wenn Sie den Systemzustand eines ESXi-Hosts anzeigen
    Wenn Sie vSphere Client mit einem ESXi-Host verbinden, um den Systemzustand anzuzeigen, antwortet der hostd-Dienst möglicherweise nicht. In hostd.log wird ein Eintrag ähnlich dem folgenden geschrieben:

    YYYY-MM-DDThh:mm:ss.344Z [5A344B90 verbose \\\'ThreadPool\\\'] usage : total=22 max=74 workrun=22 iorun=0 workQ=0 ioQ=0 maxrun=30 maxQ=125 cur=W

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Hardware-Statusüberwachung reagiert möglicherweise nicht
    Die Hardware-Statusüberwachung reagiert möglicherweise nicht, und CIM-Anbieter zeigen möglicherweise Fehlermeldungen ähnlich den folgenden an:

    2014-02-25T02:15:34Z sfcb-CIMXML-Processor[233738]: PAM unable to dlopen(/lib/security/$ISA/pam_passwdqc.so): /lib/security/../../lib/security/pam_passwdqc.so: cannot open shared object file: Too many open files2014-02-25T02:15:34Z sfcb-CIMXML-Processor[233738]: PAM adding faulty module: /lib/security/$ISA/pam_passwdqc.so2014-02-25T02:15:34Z sfcb-CIMXML-Processor[233738]: PAM unable to dlopen(/lib/security/
    The SFCB service might also stop responding.


    Dieses Problem wurde in der vorliegenden Version behoben.
  • WBEM-Abfragen (Web Based Enterprise Management) schlagen möglicherweise fehl, wenn Sie versuchen, den Hardwarestatus eines ESXi-Hosts zu überwachen
    WBEM-Abfragen schlagen möglicherweise fehl, wenn Sie versuchen, den Hardwarestatus eines ESXi-Hosts zu überwachen. Eine Fehlermeldung ähnlich der folgenden wird in die syslog-Datei geschrieben:

    Timeout error accepting SSL connection exiting.

    Um dieses Problem zu beheben, wird die neue Konfiguration httpSelectTimeout hinzugefügt, die Ihnen das Festlegen des Zeitüberschreitungswerts ermöglicht.

  • Auf einem WSMAN-Client kann ein XML-Analysefehler auftreten
    Auf einem WSMAN-Client (Web Server Manager) kann ein XML-Analysefehler auftreten, wenn der Rückgabewert eines CIM-Methodenaufrufs vom ESXi WSMAN-Agenten (openwsman) XML-reservierte Zeichen wie linke spitze Klammer (<) oder kaufmännisches Und-Zeichen (&) enthält.

    Dieses Problem wurde in der vorliegenden Version behoben.

Gastbetriebssystem-Probleme

  • Das Bearbeiten mit der Anwendung VideoReDo bewirkt möglicherweise, dass ein Video mehrmals angezeigt wird und dass außerdem verzerrte Bilder angezeigt werden
    Wenn Sie versuchen, mit VideoReDo ein Video zu bearbeiten, wird das Video möglicherweise mehrmals angezeigt. Außerdem werden Bilder beim Bearbeiten des Videos eventuell verzerrt dargestellt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Vergrößern der Festplattenpartition unter Verwendung von Mac OS X als Gastbetriebssystem mit Disk Utility ist auf einem ESXi-Host möglicherweise nicht möglich
    Sie können unter Verwendung von Mac OS X als Gastbetriebssystem die Festplattenpartition mit Disk Utility auf einem ESXi-Host nicht vergrößern. Dieses Problem tritt nicht auf, wenn Sie versuchen, die Vergrößerung mit VMware Fusion vorzunehmen.

    Dieses Problem wurde in der vorliegenden Version durch das Ändern der Header in der GUID-Partitionstabelle (GPT) nach Vergrößerung der Festplatte behoben.
  • Die Option zum Erzwingen des BIOS-Setups kann möglicherweise nicht angewendet werden
    Die Konfigurationsoption für virtuelle Maschinen BIOS-Setup erzwingen kann auf dem vSphere Client möglicherweise nicht durchgeführt werden, und es wird eine Fehlermeldung ähnlich der folgenden angezeigt:

    Der versuchte Vorgang kann im aktuellen Zustand (Eingeschaltet) nicht durchgeführt werden

    Dieses Problem wurde in der vorliegenden Version behoben.

Sonstige Probleme

  • ESXi-Host fällt möglicherweise mit violettem Diagnosebildschirm aus, nachdem eine virtuelle Maschine mit PCI-Passthrough-Gerät Emulex Quad Port LPE12004 eingeschaltet wurde
    Der ESXi-Host fällt möglicherweise mit einem violetten Diagnosebildschirm aus, nachdem eine virtuelle Maschine mit dem PCI-Passthrough-Gerät Emulex Quad Port LPE12004 eingeschaltet wurde.
    Der folgende Fehler wird angezeigt:

    cpu20:32852)@BlueScreen: #PF Exception 14 in world 32852:helper1-1 IP 0x41803baf7319 addr 0x410800fd3fa0
    PTEs:0x13f1f1023;0x208569d063;0x0;
    cpu20:32852)Code start: 0x41803ba00000 VMK uptime: 0:02:15:58.810
    cpu20:32852)0x4123c151de50:[0x41803baf7319]BackMap_Lookup@vmkernel#nover+0x35 stack: 0xffffffff00000000
    cpu20:32852)0x4123c151df00:[0x41803ba69483]IOMMUDoReportFault@vmkernel#nover+0x133 stack: 0x500000701
    cpu20:32852)0x4123c151df30:[0x41803ba69667]IOMMUProcessFaults@vmkernel#nover+0x1f stack: 0x0
    cpu20:32852)0x4123c151dfd0:[0x41803ba60f8a]helpFunc@vmkernel#nover+0x6b6 stack: 0x0
    cpu20:32852)0x4123c151dff0:[0x41803bc53242]CpuSched_StartWorld@vmkernel#nover+0xfa stack: 0x0
    cpu20:32852)base fs=0x0 gs=0x418045000000 Kgs=0x0

    Die Protokolldatei vmkernel.log enthält Einträge ähnlich den folgenden:

    cpu0:1097177)WARNING: IOMMUIntel: 2436: DMAR Fault IOMMU Unit #1: R/W=W, Device 0000:07:00.1 Faulting addr = 0xfd3fa000 Fault Reason = 0x05 -> PTE not set to allow Write.^[[0m
    cpu0:1097177)WARNING: IOMMUIntel: 2493: IOMMU context entry dump for 0000:07:00.1 Ctx-Hi = 0x302 Ctx-Lo = 0x14ac52001^[[0m


    Dieses Problem wurde in der vorliegenden Version behoben.

  • Die USB-Geräteinformationen für ESXi 5.5 sind möglicherweise nicht korrekt
    Die unter /etc/vmware/usb.ids verfügbaren USB-Geräteinformationen enthalten möglicherweise falsche Anbieterinformationen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Virtuelle Maschinen werden möglicherweise nicht gestartet, wenn Sie PCI-Geräte mit einer BAR-Größe von weniger als 4 KB als Passthrough-Gerät hinzufügen
    Virtuelle Maschinen werden möglicherweise nicht gestartet, wenn Sie PCI-Geräte mit einer BAR-Größe (Basisadressregister, Base Address Register) von weniger als 4 KB als Passthrough-Gerät hinzufügen.
    Eine Fehlermeldung ähnlich der folgenden wird in die Datei vmware.log geschrieben:

    PCIPassthru: Device 029:04.0 barIndex 0 type 2 realaddr 0x97a03000 size 128 flags 0
    PCIPassthru: Device 029:04.0 barIndex 1 type 2 realaddr 0x97a01000 size 1024 flags 0
    PCIPassthru: Device 029:04.0 barIndex 2 type 2 realaddr 0x97a02000 size 128 flags 0
    PCIPassthru: Device 029:04.0 barIndex 3 type 2 realaddr 0x97a00000 size 1024 flags 0
    PCIPassthru: 029:04.0 : barSize: 128 is not pgsize multiple
    PCIPassthru: 029:04.0 : barSize: 1024 is not pgsize multiple
    PCIPassthru: 029:04.0 : barSize: 128 is not pgsize multiple
    PCIPassthru: 029:04.0 : barSize: 1024 is not pgsize multiple>

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Unter ESXi 5.x ausgeführte virtuelle Maschinen mit Windows 2008 R2 und Solaris 10 (64-Bit) fallen mit einem blauen Bildschirm aus
    Auf einer virtuellen Maschine mit Windows 2008 R2 oder Solaris 10 (64-Bit) können die folgenden Symptome auftreten:

    • VMs mit Windows 2008 R2  fallen mit einem blauen Bildschirm und Ereignissen ähnlich den folgenden aus:
      0x0000000a - IRQL_NOT_LESS_OR_EQUAL
      0x0000001a - MEMORY_MANAGEMENT
      0x000000fc - ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY
      0x0000004e - PFN_LIST_CORRUPT
      0x00000050 - PAGE_FAULT_IN_NONPAGED_AREA
      0x0000003B- SYSTEM_SERVICE_EXCEPTION


    • VMs mit Solaris 10 (64-Bit) fallen mit Kernel Panic aus.
      Weitere Informationen finden Sie im Knowledgebase-Artikel 2073791.

    Dieses Problem wurde in der vorliegenden Version behoben.

Netzwerkprobleme

  • ESXi-Host fällt während Uplink-Instabilität möglicherweise mit violettem Bildschirm aus
    Bei instabilem Uplink fällt der ESXi-Host möglicherweise mit einem violetten Bildschirm aus, und es wird ein Fehler ähnlich dem folgenden angezeigt:

    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]UplinkRxQueuesLoadBalance@vmkernel#nover+0xnnn stack: 0xnnnnnnnnnnnn
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]UplinkLB_LoadBalanceCB@vmkernel#nover+0x8e stack: 0xnnnnnnnnnnnn, 0x
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]UplinkAsyncProcessCallsHelperCB@vmkernel#nover+0x223 stack: 0x0, 0x4
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]helpFunc@vmkernel#nover+0x6b6 stack: 0x0, 0x0, 0x0, 0x0, 0x0
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]CpuSched_StartWorld@vmkernel#nover+0xfa stack: 0x0, 0x0, 0x0, 0x0, 0


    Wenn Sie für die Netzwerkkarte einen Qlogic-UCNA-Treiber verwenden, ist der Status des Uplink-Ports auf einem ESXi 5.5-Host instabil, und in die Datei vmkernel.log wird ein Fehler ähnlich dem folgenden geschrieben:

    vmnic3:qlcnic_issue_cmd:372:Failed card response err_code: 0xn
    vmnic3:qlcnic_fw_cmd_destroy_tx_ctx:827:Failed to destroy tx ctx in firmware, err_code : 8
    vmnic3:qlcnic_dev_request_reset:6879:Changed the adapter dev_state to NEED_RESET.
    vmnic3:qlcnic_check_health:7485:Adapter not in operational state(Heartbit Failure), resetting adapter.
    <6>qlcnic 0000:04:00.1:
    vmnic3:qlcnic_check_peg_halt_status:6722:PEG_HALT_STATUS1: 0xnnnnnnnn, PEG_HALT_STATUS2: 0xnnnnnn.
    vmnic3:qlcnic_detach:2337:Deleted Tx and Rx loopback filters.
    vmnic3:qlcnic_disable_bus_master:1042:Disabled bus mastering.
    vmnic3:qlcnic_free_rx_irq:2008:Freed vmnic3_rx[0] irq.
    vmnic3:qlcnic_ctx_free_tx_irq:1859:Freed vmnic3_txq[0] irq #85.


    Dieses Problem wurde in der vorliegenden Version behoben.
  • vApp-Startzeit wird möglicherweise erhöht, wenn eine große Anzahl dvPort-Gruppen mit vCenter Server verbunden ist
    Die Startzeit von vApp wird möglicherweise erhöht, wenn die Anzahl der mit vCenter Server verbundenen dvPort-Gruppen zunimmt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • SLP kann keine UDP-Netzwerkpakete für Abfragen senden, wenn mehrere VMkernel-Schnittstellen konfiguriert sind
    Wenn Sie mehrere vmkernel-Pakete konfigurieren, kann SLP (Service Location Protocol) keine UDP-Netzwerkpakete für Abfragen senden. Dies führt dazu, dass die Firewall die Antwortpakete blockiert.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Von Anwendungen gesendete Datenpaket-Bursts gehen möglicherweise aufgrund der beschränkten Warteschlangengröße auf einem vDS oder Standard-vSwitch verloren
    Auf einem vDS (vNetwork Distributed Switch) oder Standard-vSwitch mit aktiviertem Traffic-Shaping gehen von Anwendungen gesendete Datenpaket-Bursts möglicherweise aufgrund einer beschränkten Warteschlangengröße verloren.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Starten des ESXi-Hosts mit statusfreiem Cache-Image schlägt möglicherweise aufgrund eines falschen Nutzlast-Dateinamens fehl
    Sie können den ESXi-Host möglicherweise nicht mit dem statusfreien Cache-Image starten, wenn Auto Deploy den Host nicht starten kann.
    Beim Versuch, den Host mit dem im Cache befindlichen Image zu starten, wird eine Fehlermeldung ähnlich der folgenden angezeigt:

    Datei nicht gefunden. Schwerer Fehler: 15 (nicht gefunden)

    Dieses Problem tritt auf, wenn Sie Auto Deploy von ESXi 5.0 auf ESXi 5.x aktualisieren und in der neuen Auto Deploy-Umgebung das gleiche Image verwendet wird.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Bei der Durchführung einer VDS-Systemstatusprüfung (vSphere Distributed Switch) wird möglicherweise ein falsches Ergebnis der Systemstatusprüfung gemeldet
    Wenn Sie die VDS Web Client-Systemstatusprüfung verwenden, werden beim Überwachen des Systemstatus für VLAN-, MTU- und Gruppierungsrichtlinien möglicherweise falsche Ergebnisse gemeldet.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Stark beanspruchte Filter können dieselbe Rx-Netqueue belegen
    Die Rx-Verarbeitung wird möglicherweise nicht gleichmäßig auf die verfügbaren Rx-Netqueues verteilt, auch wenn leere Warteschlangen vorhanden sind. Aufgrund von bestimmten Lademustern, bei denen stark beanspruchte Filter in eine einzelne Warteschlange gepackt werden, kann eine Unternutzung der Bandbreite von physischen Netzwerkkarten auftreten.

    Dieses Problem wurde in der vorliegenden Version behoben.

Sicherheitsprobleme

  • Update der glibc-Pakete
    Das ESXi glibc-2.5-Paket wurde aktualisiert, um Sicherheitsprobleme zu beheben.
    Im Projekt „Common Vulnerabilities and Exposures“ (cve.mitre.org) wurden diesen Problemen die Bezeichnungen CVE-2013-0242 und CVE-2013-1914 zugewiesen.
     

Serverkonfigurationsprobleme

  • Das ethtool-Dienstprogramm meldet möglicherweise einen falschen Kabeltyp für Emulex 10-GBit Ethernet Adapter (10GbE)554FLR-SFP
    Das ethtool-Dienstprogramm meldet möglicherweise einen falschen Kabeltyp für Emulex 10-GBit Ethernet Adapter (10GbE)554FLR-SFP. Der Grund dafür ist, dass ethtool den Porttyp DAC (Direct Attached Copper) nicht unterstützt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die ESXi-Installation in einer Remote-iSCSI-LUN schlägt möglicherweise fehl
    Die Installation von ESXi in einer Remote-iSCSI-LUN schlägt möglicherweise mit dem folgenden Fehler fehl:

    2 Bootbanks erwartet, 0 gefunden

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Virtuelle Maschinen weisen möglicherweise eine lange E/A-Reaktionszeit auf
    Eine oder mehrere virtuelle Maschinen auf einem ESXi-Host mit aktiviertem E/A-Scheduler nutzen für einen langen Zeitraum die maximale E/A-Bandbreite des Geräts, und dies verursacht ein IOPS-Ungleichgewicht. Dies wird durch eine im standardmäßigen ESXi-E/A-Scheduler identifizierte Racebedingung verursacht.

    Dieses Problem wurde in der vorliegenden Version behoben, indem eine gleichmäßige IOPS der VMs auf einem ESXi-Host sichergestellt wird. 
  • Versuche, mehr als 16 TB VMFS5-Datenspeicher auf einem Speichergerät zu erstellen, schlagen fehl
    Ein ESXi-Host fällt möglicherweise aus, wenn Sie mehr als 16 TB VMFS5-Datenspeicher auf einem Speichergerät erstellen. Ein Fehler ähnlich dem folgenden wird in die Datei vmkernel.log geschrieben:

    WARNING: LVM: 10032: Invalid firstPE 3758096383
    WARNING: LVM: 10039: Invalid lastPE 3758096383
    WARNING: LVM: 5242: Error detected for vol 526f639f-93de6438-940e-d48cb5bc414c, dev naa.60000970000195700908533037393545:1
    2013-11-05T09:50:56.997Z cpu10:34259)LVM: 7133: Device scan failed for <1> : Invalid metadata
    FSS: 5051: No FS driver claimed device 'naa.60000970000195700908533037393545:1': Not supported
    VC: 1958: Device rescan time 24 msec (total number of devices 9)
    VC: 1961: Filesystem probe time 56 msec (devices probed 7 of 9)
    VC: 1963: Refresh open volume time 0 msec
    LVM: 7525: Initialized naa.60000970000195700908533037393545:1, devID 5278bf81-af41c8bd-3c21-d48cb5bc414c
    LVM: 7613: Zero volumeSize specified: using available space (30786340240896).
    LVM: 13082: One or more LVM devices have been discovered.
    LVM: 7689: Error "No space left on device" creating volume 5278bf81-82937d98-3734-d48cb5bc414c on device naa.60000970000195700908533037393545:1.</1>


    Dieses Problem wurde in der vorliegenden Version behoben.
  • Versuche, die Datei „endpoints.conf“ in einem VI-Editor im VMware vSphere WebService-SDK zu bearbeiten, schlagen fehl
    Wenn Sie versuchen, die Datei /etc/vmware/rhttpproxy/endpoints.conf in einem VI-Editor zu bearbeiten, wird möglicherweise eine Fehlermeldung ähnlich der folgenden angezeigt:

    Vorgang nicht zulässig

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Einer vSphere Distributed Switch 5.5-Portgruppe, auf die Regeln zum Filtern des Datenverkehrs angewendet werden, kann keine virtuelle Maschine hinzugefügt werden
    Wenn Sie Regeln zum Filtern des Datenverkehrs für einen vSphere 5.5 Distributed Switch (VDS) konfigurieren, treten die folgenden beiden Probleme auf:
    • Beim Verbinden einer virtuellen Maschine mit einer Distributed Switch-Portgruppe, auf die Regeln zum Filtern des Datenverkehrs angewendet werden, wird im vSphere Client oder vSphere Web Client der folgende Fehler angezeigt:

      DVPort {Portnummer} von VDS {DVS} kann auf dem Host {Host} nicht erstellt werden
      Ein allgemeiner Systemfehler ist aufgetreten.

    • Wenn Sie versuchen, eine in einer Portgruppe vorhandene Regel zum Filtern des Datenverkehrs zu ändern, wird der folgende Fehler angezeigt:

      Der Vorgang für einen vSphere Distributed Switch kann für ein oder mehrere Hostmitglieder nicht abgeschlossen werden.
      vDS-Vorgang auf dem Host {Hostname} fehlgeschlagen. Fehler – SOAP-Antwortfehler von [ TCP:Hostname:443>]: invokeHostTransactionCall
      Fehler – SOAP-Antwortfehler von [ ]: invokeHostTransactionCall
      Ein allgemeiner Systemfehler ist aufgetreten: Ausnahme (vmodl.fault.SystemError) erhalten

    Die Datei hostd.log (in /var/log/ auf dem ESXi-Zielhost) enthält Einträge ähnlich dem folgenden:

    YYYY-02-07T17:57:21.859Z [FF90D5B0 error 'Default' opID=577f035c-5f user=vpxuser] AdapterServer caught unexpected exception: Not a valid netmask

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Der Host kann der Domäne nicht beitreten, wenn er aus dem lokalen Cache gestartet wird
    Wenn der ESXi-Host während des Systemneustarts Auto Deploy nicht erreichen kann und aus dem lokalen Cache gestartet werden muss, bleiben die Einstellungen möglicherweise nicht erhalten und der ESXi-Host wird beim Neustart aus Active Directory (AD) entfernt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Beim Installieren oder Durchführen eines Upgrades von ESXi wird möglicherweise auf unterstützten 4-GB- und 6-GB-USB-Flash-Laufwerken keine 2,5-GB-Core-Dump-Partition erstellt
    Wenn Sie ESXi-Hosts installieren oder aktualisieren, wird auf unterstützten 4-GB- und 6-GB-USB-Laufwerken möglicherweise keine 2,5-GB-Core-Dump-Partition erstellt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Aufgrund hoher Speicherlast können ESXCLI-Befehle möglicherweise nicht mehr auf dem Cisco UCS Blade-Server ausgeführt werden
    Aufgrund hoher Speicherlast können ESXCLI-Befehle möglicherweise nicht mehr auf dem Cisco UCS Blade-Server ausgeführt werden. Möglicherweise werden Fehlermeldungen ähnlich der folgenden in die Protokolldatei hostd.log geschrieben:

    2013-12-13T16:24:57.402Z [3C5C9B90 verbose 'ThreadPool'] usage : total=20 max=62 workrun=18 iorun=2 workQ=78 ioQ=0 maxrun=31 maxQ=79 cur=I
    2013-12-13T16:24:57.403Z [3C5C9B90 verbose 'ThreadPool'] usage : total=20 max=62 workrun=18 iorun=2 workQ=78 ioQ=0 maxrun=31 maxQ=79 cur=I
    2013-12-13T16:24:57.404Z [3BEBEB90 verbose 'ThreadPool'] usage : total=21 max=62 workrun=18 iorun=3 workQ=78 ioQ=0 maxrun=31 maxQ=79 cur=I
    2013-12-13T16:24:58.003Z [3BEBEB90 verbose 'ThreadPool'] usage : total=21 max=62 workrun=18 iorun=3 workQ=78 ioQ=0 maxrun=31 maxQ=79 cur=I
    2013-12-13T16:24:58.282Z [3C9D4B90 verbose 'ThreadPool'] usage : total=22 max=62 workrun=18 iorun=4 workQ=78 ioQ=0 maxrun=31 maxQ=79 cur=I

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Beim Ausführen von X-vMotion fallen ESXi-Hosts möglicherweise mit violettem Bildschirm aus
    Beim Ausführen von X-vMotion fallen ESXi-Hosts möglicherweise mit einem violetten Bildschirm und Fehlermeldungen ähnlich der folgenden aus:

    #PF Exception 14 in world 301646:vpxa-worker IP 0x41801c281c03 addr 0x0
    PTEs:0x1aabaa027;0x1c7a86027;0x0;
    2014-01-16T09:36:52.171Z cpu0:301646)Code start: 0x41801b600000 VMK uptime: 1:03:55:02.989
    2014-01-16T09:36:52.180Z cpu0:301646)0x41242939d430:[0x41801c281c03]XVMotion_FreeBlocks@esx#nover+0x1f stack: 0x41801ba34b3d
    2014-01-16T09:36:52.192Z cpu0:301646)0x41242939d4a0:[0x41801c23abc2]SVMAsyncIOReadDone@svmVMware#0+0x1d2 stack: 0x412ed091a740
    2014-01-16T09:36:52.204Z cpu0:301646)0x41242939d4d0:[0x41801b62d29f]AsyncPopCallbackFrameInt@vmkernel#nover+0xe7 stack: 0x412eca9d6ac0

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Verwaltungssystem von SNMP gibt möglicherweise für große Dateisysteme eine falsche ESXi-Datenträgergröße an
    Wenn Sie ESXi mit SNMP oder Verwaltungssoftware, die SNMP verwendet, überwachen, gibt das SNMP-Verwaltungssystem beim Abrufen der Datenträgergröße möglicherweise eine falsche ESXi-Datenträgergröße für große Dateisysteme an. Ab dieser Version ist ein neuer Switch verfügbar, der große Dateisysteme unterstützt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der sfcb-Dienst kann möglicherweise die ESXi-Firewall für die CIM-Indication-Übermittlung nicht öffnen, wenn mehrere Ziele die Indication an unterschiedlichen Ports überwachen
    Der sfcb-Server erstellt eine Firewallregel für jeden Port, an den CIM-Indications gesendet werden. Das Ziel überwacht die Indication an diesem Port. Der sfcb-Dienst kann die ESXi-Firewall für die CIM-Indication-Übermittlung nicht öffnen, wenn mehrere Ziele die Indication an unterschiedlichen Ports überwachen.
    Dieses Problem tritt auf, wenn der sfcb-Dienst nicht mehrere Regeln für mehrere Ports erstellen kann, da er einen festen Namen für die Firewallregeln verwendet und doppelte Regelnamen in einem einzelnen Regelsatz nicht zulässig sind.

    Dieses Problem wurde in der vorliegenden Version behoben, indem die Portnummer als Suffix des Regelnamens verwendet wird, sodass die Namen für unterschiedliche Firewallregeln keinen Konflikt verursachen.
  • Das Überprüfen auf Übereinstimmung auf einem ESXi-Host kann eine Fehlermeldung verursachen
    Wenn Sie auf einem ESXi-Host eine Übereinstimmungsüberprüfung durchführen, wird möglicherweise im vSphere Client eine Fehlermeldung ähnlich der folgenden angezeigt:

    Found extra CIM-XML Indication Subscription on local system for query u'select * from CIM_AlertIndication' sent to destination u'https://IP:port'

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Nach einem Neustart des ESXi-Hosts sind möglicherweise keine Berechtigungen für einen AD-Benutzer oder eine AD-Gruppe vorhanden
    Wenn Sie auf einem ESXi-Host mit Hostprofil Berechtigungen für einen Active Directory (AD)-Benutzer oder eine Active Directory-Gruppe festlegen, werden die Einstellungen nach dem Neustart des ESXi-Hosts mit Auto Deploy möglicherweise nicht beibehalten.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Auf der Registerkarte „Hardwarestatus“ in vCenter Server werden möglicherweise Arbeitsspeicherwarnungen und -warnmeldungen angezeigt
    Wenn in das IPMI-Systemereignisprotokoll (System Event Log, SEL) ein Assert- oder Deassert-Eintrag für die Zeile „Memory Presence Detected“ geschrieben wird, werden auf der Registerkarte Hardwarestatus in vCenter Server möglicherweise Arbeitsspeicherwarnungen und -warnmeldungen angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Abfrage von CIM-Instanzen vom WSMAN-Client auf dem ESXi-Host verursacht möglicherweise einen XML-Analysefehler
    Wenn Sie CIM-Instanzen vom WSMAN-Client (Web Server Manager) auf einem ESXi-Host abfragen und eine der Eigenschaften Sonderzeichen enthält, tritt möglicherweise ein XML-Analysefehler auf.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Trend Micro Deep Security Manager kann keinen ESXi 5.5-Host vorbereiten
    Wenn Sie auf der Trend Micro Deep Security Manager-Benutzeroberfläche den Assistenten zum Vorbereiten von ESX Server ausführen, schlägt die Ausführung des Assistenten beim Installieren des Filtertreibers auf einem ESXi 5.5-Host fehl. Der folgende Fehler wird angezeigt:

    Die Installationstransaktion ist fehlgeschlagen

    Die Datei esxupdate.log (in /var/log/ auf dem ESXi-Host) enthält Einträge ähnlich den folgenden:

    YYYY-01-09T06:21:32Z esxupdate: BootBankInstaller.pyc: INFO: /altbootbank/boot.cfg: bootstate changed from 3 to 3
    YYYY-01-09T06:21:32Z esxupdate: esxupdate: ERROR: An esxupdate error exception was caught:
    YYYY-01-09T06:21:32Z esxupdate: esxupdate: ERROR: Traceback (most recent call last):
    YYYY-01-09T06:21:32Z esxupdate: esxupdate: ERROR: File "/usr/sbin/esxupdate", line 216, in main
    YYYY-01-09T06:21:32Z esxupdate: esxupdate: ERROR: cmd.Run()
    fckLR YYYY-01-09T06:21:32Z esxupdate: esxupdate: ERROR: File "/build/mts/release/bora-1331820/bora/build/esx/release/vmvisor/sys-boot/lib/python2.6/site-packages/vmware/esx5update/Cmdline.py", line 144, in Run
    YYYY-01-09T06:21:32Z esxupdate: esxupdate: ERROR: File "/build/mts/release/bora-1331820/bora/build/esx/release/vmvisor/sys-boot/lib/python2.6/site-packages/vmware/esximage/Transaction.py", line 245, in InstallVibsFromSources
    YYYY-01-09T06:21:32Z esxupdate: esxupdate: ERROR: File "/build/mts/release/bora-1331820/bora/build/esx/release/vmvisor/sys-boot/lib/python2.6/site-packages/vmware/esximage/Transaction.py", line 347, in _installVibs
    YYYY-01-09T06:21:32Z esxupdate: esxupdate: ERROR: File "/build/mts/release/bora-1331820/bora/build/esx/release/vmvisor/sys-boot/lib/python2.6/site-packages/vmware/esximage/Transaction.py", line 390, in _validateAndInstallProfile
    YYYY-01-09T06:21:32Z esxupdate: esxupdate: ERROR: File "/build/mts/release/bora-1331820/bora/build/esx/release/vmvisor/sys-boot/lib/python2.6/site-packages/vmware/esximage/HostImage.py", line 692, in Stage
    YYYY-01-09T06:21:32Z esxupdate: esxupdate: ERROR: File "/build/mts/release/bora-1331820/bora/build/esx/release/vmvisor/sys-boot/lib/python2.6/site-packages/vmware/esximage/HostImage.py", line 478, in _download_and_stage
    YYYY-01-09T06:21:32Z esxupdate: esxupdate: ERROR: InstallationError: ('Trend_bootbank_dvfilter-dsa_9.0.0-2636', '[Errno 4] Socket Error: [Errno 1] _ssl.c:1332: error:0906D06C:PEM routines:PEM_read_bio:no start line')


    Dieses Problem wurde in der vorliegenden Version behoben.
  • Nach dem Ausführen einer Veeam-Sicherung wird die Verbindung der ESXi-Hosts mit vCenter Server möglicherweise getrennt
    Nachdem Sie eine Veeam-Sicherung ausgeführt haben, wird die Verbindung des ESXi-Hosts mit vCenter Server möglicherweise getrennt.
    Dieses Problem tritt auf, wenn Veaam versucht, einen Snapshot der virtuellen Maschine zu erstellen.
    Fehlermeldungen ähnlich der folgenden werden in die Protokolldatei hostd.log geschrieben:

    --> Crash Report build=1312873
    --> Signal 11 received, si_code -128, si_errno 0
    --> Bad access at 735F6572

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Erstellen und Bereitstellen eines Hostprofils von einem ESXi-Host in vCenter Server beansprucht möglicherweise viel Zeit oder schlägt fehl, wenn der Host mit mehreren Speichergeräten konfiguriert ist
    Das Erstellen und Bereitstellen eines Hostprofils von einem ESXi-Host in vCenter Server beansprucht möglicherweise viel Zeit oder schlägt fehl, wenn der Host mit mehreren Speichergeräten konfiguriert ist und der Host-Cache SSD-fähig ist.
    In vSphere Client wird eine Fehlermeldung ähnlich der folgenden angezeigt:

    Fehler: Die Antwortzeit des Servers war zu lang. Fehlerstapel: Aufruf von "HostProfileManager.CreateProfile" für Objekt "HostProfileManager" auf vCenter Server "your.vcenter.server.fqdn" fehlgeschlagen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • ESXi-Host fällt aus und gibt Seitenfehlerausnahme an
    Ein ESXi-Host reagiert nicht mehr und zeigt einen violetten Diagnosebildschirm an, auf dem angegeben wird, dass eine Seitenfehlerausnahme aufgetreten ist.
    Es wird eine Rückverfolgung ähnlich der folgenden angezeigt:

    @BlueScreen: #PF Exception 14 in world 33020:reset-handle IP 0x418007961885 addr 0x14
    PTEs:0xnnnnnnnnn;0xnnnnnnnnn;0xnnnnnnnnn;0x0;
    Code start: 0xnnnnnnnnnnnn VMK uptime: 3:23:09:37.928

    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VFlashAbortMatchingObjectAsyncIO@com.vmware.vmkapi#v2_2_0_0+0xc1 sta
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]vmk_VFlashIoctl@com.vmware.vmkapi#v2_2_0_0+0x83 stack: 0x417fc6e6014
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VFlashAbortMatchingDeviceAsyncIO@com.vmware.vmkapi#v2_2_0_0+0x248 st
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VFlash_Ioctl@com.vmware.vmkapi#v2_2_0_0+0x247 stack: 0x412383f1ded0
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]DevFSFileResetCommand@vmkernel#nover+0x1b5 stack: 0x412383f1df20
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSCSI_FSResetTarget@vmkernel#nover+0x3a stack: 0x0
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSCSIResetWorldFunc@vmkernel#nover+0x459 stack: 0x0
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]CpuSched_StartWorld@vmkernel#nover+0xfa stack: 0x0


    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Anwenden eines Hostprofils kann das Fehlschlagen der Übereinstimmungsüberprüfung für Hosts verursachen, die mit statusfreiem Caching bereitgestellt werden
    Wenn Sie im Dropdown-Menü Profileinstellungen für System-Image-Cache die Option Statusfreies Caching für eine USB-Festplatte auf dem Host aktivieren auswählen, um ein Hostprofil für die Verwendung von statusfreiem Caching zu konfigurieren, schlägt die Übereinstimmungsüberprüfung auf den Hosts möglicherweise fehl.
    Dieses Problem tritt auf, wenn durch das Ignorieren lokaler SAS-Geräte Übereinstimmungsfehler für lokale Geräte verursacht werden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Auf dem ESXi-Host wird während der Hypervisor-Auslagerung möglicherweise ein violetter Bildschirm angezeigt
    Nach dem Upgrade des ESXi-Hosts auf ESXi 5.5 Update 1 auf einem NUMA-Server, auf dessen erstem NUMA-Knoten kein Arbeitsspeicher zugeteilt ist, wird auf dem Host möglicherweise ein violetter Bildschirm mit einer Rückverfolgung ähnlich der folgenden angezeigt:

    Backtrace for current CPU #X, worldID=X, ebp=0xnnnnnnnnnnn
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]MemNode_MPN2ID@vmkernel#nover+0x1a stack: 0xnnnnnnnnn, 0xnnnnnn


    Dieses Problem wurde in der vorliegenden Version behoben.
  • Statusänderung der LSI MegaRaid-Festplatte wird möglicherweise nicht oder verzögert angegeben
    Wenn Sie einen LSI SMI-S-Anbieter mit einem MegaRaid SAS-Gerätetreiber auf einem ESXi 5.x-Host verwenden und den Befehl enum_instances LSIESG_PhysicalDrive lsi/lsimr13 ausführen, wird die Statusänderung der LSI MegaRaid-Festplatte möglicherweise nicht angegeben oder verzögert angegeben.

    Im folgenden Beispiel wird gezeigt, dass sich der Wert von „PowerState“ nicht ändert oder sich verzögert ändert, wenn der Energiesparmodus der LSI MegaRaid-Festplatte geändert wird:

    LSILSIESG_PhysicalDrive.Tag="500605B004F93CF0_252_36",CreationClassName="LSIESG_PhysicalDrive"
    CreationClassName = LSIESG_PhysicalDrive
    Tag = 500605B004F93CF0_252_36
    UserDataBlockSize = 512
    PiType = 0
    PiEligible = 0
    PiFomatted = 0
    PowerState = 0 ---> No change in status
    Vendor = (NULL)
    FRUNumber = (NULL)
    DiskDrive_DeviceID = 252_36


    Dieses Problem wurde in der vorliegenden Version behoben.
  • Möglicherweise wird eine falsche Warnmeldung ausgegeben, obwohl im System eine gültige Scratch-Partition konfiguriert ist
    Wenn sich die konfigurierte Scratch-Partition nicht im Stammverzeichnis des Datenspeichers (/vmfs/volumes/ /) befindet, wird möglicherweise aufgrund der falschen Identifizierung der Scratch-Konfiguration eine falsche Warnmeldung ähnlich der folgenden ausgegeben:

    Es wurde keine Scratch-Partition konfiguriert.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Verzögerung beim Laden der Liste der LUNs (Logical Unit Number) in den Assistenten zum Hinzufügen von Speicher
    Wenn Sie einem neuen Datenspeicher schreibgeschützte LUNs hinzufügen, um 200 VMFS-Replikate zu erstellen, wird die Liste der Volumes im Assistenten zum Hinzufügen von Speicher möglicherweise nach 30 Minuten angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Ein Hostprofils kann aufgrund eines Übereinstimmungsfehlers nicht angewendet werden
    Beim Anwenden des Hostprofils oder nach dem Anwenden des Hostprofils werden die folgenden Übereinstimmungsfehler angezeigt:
     
    Der Spezifikationsstatus fehlt für den Host: Status des Geräts 'datastore' muss auf 'on' festgelegt werden
    Der Hoststatus stimmt mit der Spezifikation nicht überein: Gerät 'datastore' muss zurückgesetzt werden
    Der Spezifikationszustand fehlt für den Host: Die Pfadauswahlrichtlinie für das Gerät 'datastore' muss auf 'VMW_PSP_FIXED' festgelegt werden
    Der Hostzustand stimmt mit der Spezifikation nicht überein: Die Pfadauswahlrichtlinie des Geräts 'device' muss zum Beanspruchen von SATP auf 'Standard' festgelegt werden


    Dieses Problem tritt auf, wenn ein gespeichertes Hostprofil von einem Referenzhost ein SCSI-Gerät als potenziell gemeinsam genutztes Gerät erfasst. Wenn das SCSI-Gerät jedoch ein lokales Gerät ist, kann eine Übereinstimmungsüberprüfung nach dem Anwenden des Hostprofils auf einen Host fehlschlagen. Dieses Problem kann beispielsweise auftreten, wenn Host1 über ein SAS-Gerät mit GUID1 und Host2 über ein anderes SAS-Gerät mit GUID2 verfügt. Ausschließlich lokale SCSI-Geräte sind beispielsweise bestimmte lokale RAID-Controller und SAS-Festplatten.

    Obwohl die Systemhardware vergleichbar ist, wird ein Übereinstimmungsfehler angezeigt, da ähnliche Geräte mit verschiedenen Geräte-IDs in der Form „naa.UID“ statt in der generischen Form „mpx.pathname“ eindeutig benannt werden. Bei der daraus resultierenden Profilübereinstimmungsprüfung wird erkannt, dass einige Geräte entfernt wurden, während andere hinzugefügt wurden, ohne dass sie im gespeicherten Profil angezeigt werden.

    Dieses Problem wurde in ESXi 5.5 Update 2 für alle SATA-basierten SSD-Geräte hinter SAS-Controllern behoben. Diese Geräte werden von ESXi als lokale Geräte markiert. Weiterhin ignorieren Speicher-Hostprofile lokale SAS- und USB-Geräte mit Ausnahme von USB CD-ROMs, obwohl die bei den SAS- und USB-Geräten erkannten Übereinstimmungsfehler behoben wurden.
  • Nach der Verwendung von Auto Deploy für statusfreies Caching oder statusorientierte Installationen auf USB werden Nichtübereinstimmungsmeldungen angezeigt
    Nachdem ein Hostprofil bearbeitet wurde, um das statusfreie Caching auf dem USB-Datenträger des Hosts zu aktivieren, werden für das Hostprofil beim Standardisieren Übereinstimmungsfehler angezeigt. Der Host wird neu gestartet und das Caching abgeschlossen. Nach der Übereinstimmungsprüfung werden möglicherweise die folgenden Übereinstimmungsfehler gemeldet:

    Spezifikation stimmt mit Host nicht überein: device.mpx.vmhbaXX:C0:T0:L0-Parameter müssen zurückgesetzt werden
    Spezifikation stimmt mit Host nicht überein: device.mpx.vmhbaXX:C0:T0:L0-Pfadauswahlrichtlinie muss zum Beanspruchen von SATP auf 'Standard' festgelegt werden


    In den Meldungen oben kann XX eine Ganzzahl größer oder gleich 32 sein (z. B. 34).

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der hostd-Dienst fällt möglicherweise aus, wenn ein Stilllegungs-Snapshot-Vorgang während einer LWD-Übertragung fehlschlägt
    Wenn ein Stilllegungs-Snapshot-Vorgang während einer LWD-Übertragung fehlschlägt, fällt der hostd-Dienst möglicherweise aus, und eine Fehlermeldung ähnlich der folgenden wird in die Protokolldatei hostd.log geschrieben:

    Panic: Assert Failed: "false" @ bora/vim/hostd/hbrsvc/ReplicationGroup.cpp:5123

    Dieses Problem wurde in der vorliegenden Version behoben.

Speicherprobleme

  • Wenn mehrere virtuelle Maschinen auf demselben ESXi-Host ausgeführt werden und denselben NFS-Datenspeicher verwenden, können virtuelle Festplatten eine hohe Latenz und eine geringe Leistung aufweisen
    In einer Umgebung, in der mehrere virtuelle Maschinen auf demselben ESXi-Host ausgeführt werden und denselben NFS-Datenspeicher verwenden, können virtuelle Festplatten eine hohe Latenz und eine geringe Leistung aufweisen, wenn Sie den IOPS-Grenzwert für eine virtuelle Maschine festlegen. Selbst wenn Sie unterschiedliche IOPS-Grenzwerte für unterschiedliche virtuelle Maschinen festlegen, wird der IOPS-Grenzwert für alle virtuellen Maschinen auf den niedrigsten Wert festgelegt, der einer virtuellen Maschine im NFS-Datenspeicher zugewiesen ist.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der Name des Festplattenbezeichners ist möglicherweise abgeschnitten
    Die Host-Ressourcen-MIB (RFC 2790) beschränkt den Umfang der formatierten Zeichenfolge auf 64. Der Name des Festplattenbezeichners oder eine beliebige formatierte Zeichenfolge wird möglicherweise abgeschnitten, wenn diese Obergrenze überschritten wird.

    Dieses Problem wurde in der vorliegenden Version durch das Entfernen redundanter Leerzeichen behoben, sodass der Name die gültigen Informationen enthält.
  • Der CNA 40G von Intel auf einem ESXi-Host zeigt den Verbindungsstatus möglicherweise als unterbrochen an
    Der Converged Network Adapter (CNA) 40G von Intel auf einem ESXi-Host zeigt den Verbindungsstatus möglicherweise als unterbrochen an.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Ausführen der Funktion zum erneuten Prüfen aller Speicheradapter über vCenter Server oder ESXCLI beansprucht möglicherweise viel Zeit
    Das Ausführen der Funktion „Alle Speicheradapter erneut auf neue Speichergeräte prüfen“, die Sie über vCenter Server oder ESXCLI ausführen, beansprucht möglicherweise viel Zeit, wenn der ESXi-Host über eine große Anzahl von VMFS-Datenspeichern verfügt.

    In dieser Version wird die Leistung verschiedener Speichervorgänge, z. B. das erneute Prüfen aller Speicheradapter und VMFS-Datenspeicher sowie das Auflisten von VMFS-Snapshots und -Geräten im Assistenten zum Erstellen von Datenspeichern, verbessert.
  • Verfolgungsfunktionalität für geänderte Blöcke wurde von Storage vMotion zurückgesetzt
    Bei der Durchführung von Storage vMotion-Vorgängen unter vSphere 5.x wird die Verfolgungsfunktionalität für geänderte Blöcke (CBT) zurückgesetzt.
    Weitere Informationen finden Sie im Knowledgebase-Artikel 2048201.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Größere vApp-Bereitstellungen schlagen hin und wieder aufgrund von „Lock Contention“ im NFS fehl
    Die vApp-Bereitstellung kann auf dem NFS bei Vorgängen mit verknüpften Klonen fehlschlagen, wenn in VCD die Option VAAI für schnelle Bereitstellung aktivieren gewählt ist. Eine Fehlermeldung ähnlich der folgenden wird in der Protokolldatei hostd.log angezeigt:

    Create child failed to mark parent read-only (25): Das System kann die angegebene Datei nicht finden

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Cluster-weite erneute Speicherprüfungen können dazu führen, dass die ESXi-Hosts und die virtuellen Maschinen nicht mehr reagieren
    Während der VMFS-Aktualisierung reagieren die virtuellen Maschinen möglicherweise für eine längere Zeit nicht mehr auf Ping-Anfragen. Weitere Informationen finden Sie im Knowledgebase-Artikel 1039088.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Neue Beanspruchungsregel-Option für IBM hinzugefügt
    Für das IBM Speicherarray-Modell 2145 wurde ESXi 5.5 die neue Beanspruchungsregel-Option reset_on_attempted_reserve hinzugefügt.
  • VM-Vorgänge können fehlschlagen, wenn CBT mit Virtual SAN verwendet wird
    Wenn CBT mit Virtual SAN verwendet wird, können in bestimmten Fällen einige Komponenten der vmdk verlorengehen, was zu einem Fehlschlagen von VM-Vorgängen führen kann.

    Dieses Problem wurde in der vorliegenden Version behoben.

Upgrade- und Installationsprobleme

  • Das Installieren eines ESXi 5.5-Hosts führt möglicherweise dazu, dass Fehlermeldungen in syslog.log-Dateien geschrieben werden
    Nachdem Sie einen ESXi-Host installiert haben, werden beim Überwachen des Hosts durch einen SNMP-Überwachungsserver möglicherweise Fehlermeldungen ähnlich der folgenden in die Protokolldatei syslog.log geschrieben:

    snmpd: fetch_fixed_disk_status: fetch VSI_NODE_storage_scsifw_devices_smart_healthStatus(naa.6090a048e059642f5ac6d489e7faed03) failed Not supported, reporting unknown status

    Dieses Problem tritt nur auf Hosts mit Festplatten auf, die Self Monitoring Analysis and Reporting Technology (SMART) nicht unterstützen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Während der Installation von virtuellen Maschinen mit RHEL mithilfe der Kickstart-Datei zeigen OSPs möglicherweise Fehlermeldungen an
    Wenn Sie versuchen, virtuelle Maschinen mit RHEL mithilfe der Kickstart-Datei zu installieren, zeigen die betriebssystemspezifischen Pakete (Operating System Specific Packages, OSPs) möglicherweise eine Fehlermeldung ähnlich der folgenden an:

    'load modules.dep' konnte nicht geladen werden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Hinzufügen eines ESXi-Hosts zu vCenter Server schlägt nach dem Upgrade von ESX 4.1 auf ESXi 5.5 möglicherweise fehl
    Nach dem Upgrade von ESX 4.1 auf ESXi 5.5 wird die Datei nsswitch.conf des Hosts möglicherweise nicht ordnungsgemäß migriert. Dies führt dazu, dass Sie den Host möglicherweise nicht zum vCenter Server hinzufügen können.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Upgrade von ESX 4.1 auf ESXi 5.5 OEM schlägt möglicherweise fehl
    Upgrades von ESX 4.1.x auf ESXi 5.5.x OEM schlagen möglicherweise aufgrund eines nicht unterstützten vsish-Befehls auf dem ESX 4.1-Host fehl. Es wird u. U. eine Fehlermeldung ähnlich der folgenden angezeigt:

    Das Upgrade wird auf der Hosthardware nicht unterstützt. Das Upgrade-ISO-Image enthält HP-VIBs (oder solche anderer Anbieter), die die Anbieter-Kompatibilitätsprüfung für die Hosthardware nicht bestanden haben. VIBs von HP werden auf dem vom Anbieter hergestellten Hosthardware-Modell Hewlett-Packard Company nicht unterstützt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Upgrade von ESXi 5.1 auf ESXi 5.5 führt möglicherweise zu einem Ausfall des hostd-Dienstes, und der ESXi-Host trennt möglicherweise die Verbindung zu vCenter Server
    Beim Upgrade von ESXi 5.1 auf ESXi 5.5 fällt der hostd-Dienst möglicherweise aus. Das führt dazu, dass der ESXi-Host möglicherweise die Verbindung zu vCenter Server verliert. Dieses Problem kann außerdem dazu führen, dass der Betrieb von Veaam Backup fehlschlägt. Möglicherweise werden Fehlermeldungen ähnlich der folgenden in die Protokolldatei hostd.log geschrieben:

    2014-01-17T11:15:29.069Z [704ADB90 error 'UW Memory checker'] Current value 644848 exceeds hard limit 643993. Shutting down process.2014-01-17T11:15:29.069Z [704ADB90 panic 'Default']
    -->
    --> Panic: Memory exceeds hard limit. Panic
    --> Backtrace:
    --> backtrace[00] rip 142c26a3 Vmacore::System::Stacktrace::CaptureFullWork(unsigned int)
    --> backtrace[01] rip 140e6a48 Vmacore::System::SystemFactoryImpl::CreateBacktrace(Vmacore::Ref <:system::backtrace> &)
    --> backtrace[02] rip 142b9803 /lib/libvmacore.so [0x142b9803]
    --> backtrace[03] rip 142b9bd1 Vmacore::PanicExit(char const*)
    --> backtrace[04] rip 140f3b6c Vmacore::System::ResourceChecker::DoCheck()
    --> backtrace[05] rip 140f423d boost::detail::function::void_function_obj_invoker <void,0
    </:system::backtrace>
    Dieses Problem tritt aufgrund übermäßig hoher Arbeitsspeichernutzung durch hostd auf.

    Dieses Problem wurde in der vorliegenden Version behoben.

Probleme bei vCenter Server und beim vSphere Web Client

  • Der ESXi-Host wird möglicherweise von vCenter Server getrennt, nachdem der hostd-Dienst ausgefallen ist
    Der ESXi-Host wird möglicherweise von vCenter Server getrennt, wenn der hostd-Dienst ausfällt. Dieses Problem tritt auf, wenn die Registrierung der virtuellen Maschine aufgehoben wird. Der ESXi-Host kann erst nach einem Neustart des vpxa-Dienstes mit vCenter verbunden werden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Im Leistungsdiagramm werden möglicherweise falsche Durchsatznutzungswerte für vCenter Server-Bestandslistenobjekte angezeigt
    Im Leistungsdiagramm werden falsche Durchsatznutzungswerte für die folgenden vCenter Server-Bestandslistenobjekte angezeigt:
    • Virtuelle Maschine > Virtuelle Festplatte
    • Virtuelle Maschine > Festplatte
    • Host > Festplatte
    • Host > Speicherpfad
    • Host > Speicheradapter
    Weitere Informationen finden Sie im Knowledgebase-Artikel 2064464.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die durchschnittlichen CPU-Nutzungswerte sind möglicherweise höher als die mit der Anzahl der Prozessoren multiplizierte Frequenz der Prozessoren
    Die durchschnittlichen CPU-Nutzungswerte, die in Power CLI angezeigt werden, sind möglicherweise höher als die mit der Anzahl der Prozessoren multiplizierte Frequenz der Prozessoren.

    Dieses Problem wurde in der vorliegenden Version durch Festlegen des richtigen Maximalwerts für die durchschnittliche CPU-Nutzung behoben.
  • Das Erstellen von Stilllegungs-Snapshots und das Hot-Klonen einer virtuellen Linux-Maschine schlagen möglicherweise fehl
    Das Erstellen von Stilllegungs-Snapshots und das Hot-Klonen einer virtuellen Linux-Maschine schlagen möglicherweise fehl, und Fehlermeldungen ähnlich der folgenden werden möglicherweise in die Datei vmware.log geschrieben:

     2013-12-12T00:09:59.446Z| vcpu-1| I120: [msg.snapshot.quiesce.vmerr] The guest OS has reported an error during quiescing.
     2013-12-12T00:09:59.446Z| vcpu-1| I120+ The error code was: 3
     2013-12-12T00:09:59.446Z| vcpu-1| I120+ The error message was: Error when enabling the sync provider.
     2013-12-12T00:09:59.446Z| vcpu-1| I120: ----------------------------------------
     2013-12-12T00:09:59.449Z| vcpu-1| I120: ToolsBackup: changing quiesce state: STARTED -> ERROR_WAIT
     2013-12-12T00:10:00.450Z| vcpu-1| I120: ToolsBackup: changing quiesce state: ERROR_WAIT -> IDLE
     2013-12-12T00:10:00.450Z| vcpu-1| I120: ToolsBackup: changing quiesce state: IDLE -> DONE
     2013-12-12T00:10:00.450Z| vcpu-1| I120: SnapshotVMXTakeSnapshotComplete: Done with snapshot 'clone-temp-1386910714682919': 0
     2013-12-12T00:10:00.450Z| vcpu-1| I120: SnapshotVMXTakeSnapshotComplete: Snapshot 0 failed: Failed to quiesce the virtual machine (40).


    Dieses Problem wurde in der vorliegenden Version behoben.

VM-Verwaltungsprobleme

  • Die virtuelle Maschine fällt beim Erstellen eines stillgelegten Snapshots möglicherweise aus
    Die virtuelle Maschine fällt möglicherweise aus, wenn vSphere Replication oder andere Dienste einen stillgelegten Snapshot erstellen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • ESXi-Host fällt möglicherweise mit violettem Bildschirm aus, wenn Sie mit dem AdvStats-Parameter benutzerdefinierte Skripts ausführen
    Der ESXi-Host fällt möglicherweise mit einem violetten Bildschirm aus, wenn Sie mit dem AdvStats-Parameter benutzerdefinierte Skripts ausführen, um die Festplattennutzung zu überprüfen.
    Möglicherweise wird eine Fehlermeldung ähnlich der folgenden in die Protokolldatei vmkernel.log geschrieben:

    VSCSI: 231: Creating advStats for handle 8192, vscsi0:0
    Der Host meldet eine Rückverfolgung ähnlich der folgenden:
    Histogram_XXX
    VSCSIPostIOCompletion
    AsyncPopCallbackFrameInt

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Wenn eine virtuelle Maschine aufgrund des DRS migriert wird, kann das Gastbetriebssystem möglicherweise nicht angepasst werden
    Wenn während der Anpassung des Gastbetriebssystems eine virtuelle Maschine aufgrund des DRS migriert wird, kann die Anpassung eventuell nicht durchgeführt werden, und die Datei Guestcust.log enthält möglicherweise eine Fehlermeldung ähnlich der folgenden:

    Unable to set customization status in vmx.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Ausführen eines Automatisierungscodes zum Kopieren einer virtuellen Maschine führt möglicherweise dazu, dass die Verbindung zwischen ESXi-Host und vCenter Server getrennt wird
    Wenn Sie einen Automatisierungscode ausführen, um eine virtuelle Maschine zu kopieren, wird die Verbindung zwischen ESXi-Host und vCenter Server möglicherweise getrennt. Dieses Problem tritt auf, wenn der hostd-Dienst ausfällt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der vSphere HA-Schutzzustand bleibt möglicherweise „Nicht geschützt“, wenn der HA-Cluster fälschlicherweise davon ausgeht, dass die virtuelle Maschine ausgeschaltet ist
    Der vSphere HA-Schutzzustand bleibt möglicherweise „Nicht geschützt“, wenn der HA-Cluster fälschlicherweise davon ausgeht, dass die virtuelle Maschine ausgeschaltet ist.
    Dieses Problem tritt auf, wenn für die Eigenschaft vm.runtime.cleanPowerOff fälschlicherweise der Wert „True“ festgelegt wurde und der HA-Cluster somit davon ausgeht, dass die virtuelle Maschine ausgeschaltet ist.
    Fehlermeldungen ähnlich der folgenden werden in die Protokolldateien geschrieben:

    vpxd-8.log:2013-11-21T20:44:49.902Z [7F69C7CF9700 info 'vmdasVm' opID=FdmWaitForUpdates-domain-c26-45712e7f] [VmMo::UpdateActualDasProtectStateLocked] actual protection state for VM vm-93 'unprotected' -> 'protected'
    vpxd-10.log:2013-11-22T00:03:01.731Z [7F69D4832700 info 'vmdasVm' opID=FdmWaitForUpdates-domain-c26-6b160bef] [VmMo::UpdateActualDasProtectStateLocked] actual protection state for VM vm-93 'protected' -> 'unprotected'


    Dieses Problem wurde in der vorliegenden Version behoben.

Probleme bei vMotion und Storage vMotion

  • Das Ausführen von vMotion zum Migrieren von ESXi 5.1 zu ESXi 5.5 kann dazu führen, dass ESXi-Hosts nicht mehr reagieren
    ESXi-Hosts antworten möglicherweise nicht mehr, wenn Sie vMotion zum Migrieren von ESXi 5.1 auf ESXi 5.5 ausführen.
    Weiterhin wird der Status der virtuellen Maschine möglicherweise als ungültig angezeigt, wenn Sie einen der folgenden Schritte ausführen:
    • Registrieren oder Aufheben der Registrierung einer virtuellen Maschine
    • Durchführen einer Cold-Migration einer virtuellen Maschine von ESXi 5.1 auf ESXi 5.5

    ESXi-Hosts antworten möglicherweise nicht mehr, wenn Sie vMotion zum Migrieren von ESXi 5.1 auf ESXi 5.5 ausführen.
    Möglicherweise werden Fehlermeldungen ähnlich der folgenden in die Protokolldatei hostd.log auf dem ESXi-Zielhost geschrieben:

    2013-12-18T15:21:52.455Z [FFBEFB70 verbose 'Vmsvc.vm:/vmfs/volumes/50d2f92b-bc57ec6f-f5c0-001c23d7ba27/migtest3/migtest3.vmx'] Get shared vigor fields message: CPUID register value () is invalid.
    --> CPUID register value () is invalid.
    --> CPUID register value () is invalid.
    --> CPUID register value () is invalid.
    --> CPUID register value () is invalid.
    --> CPUID register value () is invalid.
    --> CPUID register value () is invalid.
    --> CPUID register value () is invalid.
    -->
    2013-12-18T15:21:52.455Z [FFBEFB70 info 'Vmsvc.vm:/vmfs/volumes/50d2f92b-bc57ec6f-f5c0-001c23d7ba27/migtest3/migtest3.vmx'] Error encountered while retrieving configuration. Marking configuration as invalid: vim.fault.GenericVmConfigFault


    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Ausführen von vMotion kann zum automatischen Upgrade von VMware Tools und zum Neustart von virtuellen Maschinen führen
    Wenn Sie die Durchführung eines Upgrades von VMware Tools beim Aus- und Wiedereinschalten aktivieren und vMotion zum Migrieren eines ESXi-Hosts mit dem Image-Profil „no-tools“ zu einem anderen ESXi-Host mit dem ISO-Image für VMware Tools ausführen, erfolgen möglicherweise ein automatisches Upgrade von VMware Tools und ein Neustart der virtuellen Maschinen.

    Dieses Problem wurde in der vorliegenden Version behoben.

Probleme bei VMware Tools

  • Die Kompilierung des Arbeitsspeicher-Balloon-Treibers (VMMEMCTL) schlägt in FreeBSD Version 10 und höher fehl
    Die Kompilierung des Arbeitsspeicher-Balloon-Treibers (vmmemctl) schlägt in FreeBSD Version 10.0 und höher möglicherweise fehl. Eine Fehlermeldung ähnlich der folgenden wird in die Protokolldatei geschrieben:

    os.c:300:22: error: implicit declaration of function 'kmem_alloc_nofault' is
    invalid in C99[-Werror,-Wimplicit-function-declaration]
    vm_offset_t res = kmem_alloc_nofault(kernel_map, PAGE_SIZE);
    ^
    os.c:357:14: error: incompatible pointer types passing 'vm_map_t' (aka
    'struct vm_map ') to parameter of type 'struct vmem ' [-Werror,-Wincompatible-pointer-types]
    kmem_free(kernel_map, (vm_offset_t)mapping, PAGE_SIZE);
    ^~~~~~~~~~
    @/vm/vm_extern.h:59:29: note: passing argument to parameter here
    void kmem_free(struct vmem *, vm_offset_t, vm_size_t);

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESXi-Host antwortet bei der Anmeldung möglicherweise verzögert, wenn MOVE Agentless 3.0 auf einer virtuellen Maschine ausgeführt wird
    Bei der Ausführung von MOVE Agentless 3.0 auf einem ESXi-Host kann es zu einer Verzögerung von 40 Sekunden oder mehr kommen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Beim Installieren von VMware Tools 5.1 auf einer virtuellen Windows-Maschine werden in Windows-Ereignisprotokollen Unity-Warnungen angezeigt
    Nach dem Installieren von VMware Tools 5.1 auf einer virtuellen Windows-Maschine werden im Windows-Anwendungsereignisprotokoll des Gastbetriebssystems Warnungen ähnlich der folgenden angezeigt:

    [ warning] [vmusr:vmusr] vmware::tools::UnityPBRPCServer::Start: Failed to register with the host!
    [ warning] [vmusr:vmtoolsd] Failed registration of app type 2 (Signals) from plugin unity.
    [ warning] [vmusr:vmusr] Error in the RPC receive loop: RpcIn: Unable to send.
    [ warning] [vmusr:vmusr] socket count not create new socket, error 10047: An address incompatible with the requested protocol was used
    [ warning] [vmusr:vmusr] Channel restart failed [1]


    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der MOB für das Datenobjekt „GuestInfo.ipAddress“ wird möglicherweise nicht ordnungsgemäß aufgefüllt, wenn mehr als vier Netzwerkkarten verbunden sind
    Der Managed Object Browser (MOB) für das Datenobjekt GuestInfo.ipAddress wird möglicherweise nicht ordnungsgemäß aufgefüllt, und als Wert des Datenobjekts GuestInfo.ipAddress wird nicht unset angezeigt, wenn mehr als vier Netzwerkkarten verbunden sind.
    Dieses Problem tritt auf, wenn VMware Tools keine gültige IP-Adresse des Gastbetriebssystems bestimmen kann.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Virtuelle Windows-Maschinen fallen beim Upgrade von VMware Tools möglicherweise mit einem blauen Bildschirm aus
    Nach dem Upgrade von VMware Tools fallen virtuelle Maschinen möglicherweise mit einem blauen Bildschirm aus oder reagieren nicht mehr. Dieses Problem ist auf eine Speicherbeschädigung zurückzuführen, wenn TCP-Verbindungen im vShield Endpoint TDI Manager-Treiber vnetflt.sys nicht ordnungsgemäß verarbeitet werden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Datei ist nach Upgrade von VMware Tools nicht mehr vorhanden
    Die Datei deployPkg.dll, die sich in der Regel im Verzeichnis C:\Programme\Vmware\Vmware Tools\ befindet, wird nach dem Upgrade von VMware Tools auf Version 5.5 Update 1 möglicherweise nicht gefunden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Installation von VMware Tools kann möglicherweise dazu führen, dass in der Windows-Ereignisanzeige eine Warnmeldung angezeigt wird
    Nachdem Sie VMware Tools installiert haben, wird in der Windows-Ereignisanzeige eine Warnung ähnlich der folgenden angezeigt:

    Eine Zeile von 'C:\Programme\VMware\VMware Tools\messages\es\hgfsUsability.vmsg' kann nicht gelesen werden: Ungültige Bytesequenz in der Konvertierungseingabe.

    Dieses Problem wurde insbesondere bei der Installation von VMware Tools auf Betriebssystemen mit spanischem Gebietsschema festgestellt.

    Dieses Problem wurde in der vorliegenden Version behoben.

Bekannte Probleme

Behobene Probleme, die früher nicht dokumentiert wurden, werden mit einem Sternchen (*) markiert. Die bekannten Probleme gliedern sich in folgende Gruppen:

Upgrade- und Installationsprobleme

  • Versuche, alle Image-Profile bei der Ausführung des Get-EsxImageProfile-Befehls in vSphere PowerCLI abzurufen, schlagen möglicherweise fehl*
    Wenn Sie den Get-EsxImageProfile-Befehl mit vSphere PowerCLI ausführen, um alle Image-Profile abzurufen, wird ein Fehler ähnlich dem Folgenden angezeigt:

    PowerCLI C:\Windows\system32> Get-EsxImageProfile
    Get-EsxImageProfile : Der Parameter 'name' darf keine leere Zeichenfolge sein.
    Parametername: name
    At line:1 char:20
    + Get-EsxImageProfile <<<<
    + CategoryInfo : NotSpecified: (:) [Get-EsxImageProfile], ArgumentException
    + FullyQualifiedErrorId : System.ArgumentException,VMware.ImageBuilder.Commands.GetProfiles


    Problemumgehung: Führen Sie den Befehl Get-EsxImageProfile -name "ESXi-5.x*" aus, der die Option -name enthält und alle während der PowerCLI-Sitzung erstellten Image-Profile anzeigt.

    Beispiel: Beim Ausführen des Befehls Get-EsxImageProfile -name "ESXi-5.5.*" werden alle 5.5-Image-Profile ähnlich dem folgenden angezeigt:

    PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> Get-EsxmageProfile -name "ESXi-5.5.*"

    Name Vendor Last Modified Acceptance Level
    ---- ------ ------------- ----------------
    ESXi-5.5.0-20140701001s-no-... VMware, Inc. 8/23/2014 6:... PartnerSupported
    ESXi-5.5.0-20140302001-no-t... VMware, Inc. 8/23/2014 6:... PartnerSupported
    ESXi-5.5.0-20140604001-no-t... VMware, Inc. 8/23/2014 6:... PartnerSupported
    ESXi-5.5.0-20140401020s-sta... VMware, Inc. 8/23/2014 6:... PartnerSupported
    ESXi-5.5.0-20131201001s-sta... VMware, Inc. 8/23/2014 6:... PartnerSupported
  • Die einfache Installation schlägt unter Windows Server 2012 fehl
    Die einfache Installation schlägt unter Windows Server 2012 fehl, wenn das Betriebssystem eine per DHCP zugewiesene IP-Adresse verwendet.

    Problemumgehung: Konfigurieren Sie Windows 2012 Server so, dass eine statische IP-Adresse verwendet wird.

  • Wenn die Beibehaltung von VMFS in Kombination mit Auto Deploy für statusfreies Caching oder statusorientierte Installationen verwendet wird, wird keine Core-Dump-Partition erstellt
    Wenn Sie Auto Deploy für statusfreies Caching oder statusorientierte Installationen auf einer leeren Festplatte verwenden, wird eine MSDOS-Partitionstabelle erstellt. Eine Core-Dump-Partition wird jedoch nicht erstellt.

    Problemumgehung: Wenn Sie die Option für statusfreies Caching oder statusorientierte Installationen in Hostprofilen aktivieren, wählen Sie VMFS überschreiben aus, selbst wenn Sie die Installation auf einer leeren Festplatte durchführen. Dadurch wird eine Core-Dump-Partition mit 2,5 GB erstellt.

  • Während der Skriptinstallation wird ESXi auf einer SSD-Festplatte installiert, obwohl die Option "--ignoressd" für den Befehl "installorupgrade" verwendet wird
    In ESXi 5.5 wird die Option --ignoressd nicht für den Befehl installorupgrade unterstützt. Falls Sie die Option --ignoressd mit dem Befehl installorupgrade verwenden, zeigt das Installationsprogramm eine Warnmeldung an, dass es sich um eine ungültige Kombination handelt. Das Installationsprogramm installiert ESXi jedoch weiterhin auf der SSD, anstatt die Installation abzubrechen und eine Fehlermeldung anzuzeigen.

    Problemumgehung: Verwenden Sie den Befehl install anstelle des Befehls installorupgrade, um die Option --ignoressd in einer Skriptinstallation von ESXi zu verwenden.

  • Durch die Verzögerung beim Löschen des Auto Deploy-Cache wird möglicherweise ein gelöschtes Hostprofil angewendet
    Nachdem ein Hostprofil gelöscht wurde, wird es nach einer Weile aus dem Auto Deploy-Cache gelöscht. Solange das Hostprofil im Cache vorhanden ist, wendet Auto Deploy dieses Hostprofil an. Alle Regeln, die das Profil anwenden, schlagen erst dann fehl, wenn das Profil aus dem Cache gelöscht wird.

    Problemumgehung: Mithilfe des PowerCLI-Cmdlets Get-DeployRuleSet können Sie ermitteln, ob es Regeln gibt, die gelöschte Hostprofile verwenden. Das Cmdlet zeigt in der itemlist der Regel die Zeichenfolge deleted. Anschließend können Sie das Cmdlet Remove-DeployRule ausführen, um diese Regel zu entfernen.

  • Das Anwenden eines Hostprofils, das für die Verwendung von Auto Deploy mit statusfreiem Caching eingerichtet ist, schlägt fehl, wenn ESX auf der ausgewählten Festplatte installiert ist
    Sie verwenden Hostprofile, um Auto Deploy mit aktiviertem statusfreiem Caching einzurichten. Sie wählen im Hostprofil eine Festplatte aus, auf der eine Version von ESX (nicht ESXi) installiert ist. Wenn Sie das Hostprofil anwenden, wird eine Fehlermeldung mit dem folgenden Text angezeigt.
    2 Bootbanks erwartet, 0 gefunden

    Problemumgehung: Wählen Sie eine andere Festplatte für die Verwendung des statusfreien Cachings aus oder entfernen Sie die ESX-Software von der Festplatte. Wenn Sie die ESX-Software entfernen, ist sie nicht mehr verfügbar.

  • Die Installation oder der Start von ESXi 5.5.0 schlägt auf Servern von Oracle America (Sun)-Herstellern fehl
    Wenn Sie auf Servern von Oracle America (Sun)-Herstellern eine Neuinstallation von ESXi 5.5.0 durchführen oder eine vorhandene ESXi 5.5.0-Installation starten, zeigt die Serverkonsole während des Installationsvorgangs oder beim Starten des vorhandenen ESXi 5.5.0-Builds einen leeren Bildschirm an. Dies ist darauf zurückzuführen, dass für Server von Oracle America (SUN)-Herstellern das Flag HEADLESS in der Tabelle ACPI FADT gesetzt wurde, obwohl es sich dabei nicht um monitorlos laufende Plattformen handelt.

    Problemumgehung: Übergeben Sie beim Installieren oder Starten von ESXi 5.5.0 die Startoption ignoreHeadless="TRUE".

  • Bei Verwendung der ESXCLI-Befehle für das Upgrade eines ESXi-Hosts mit weniger als 4 GB physischem RAM ist das Upgrade zwar erfolgreich, aber beim Neustart schlagen einige ESXi-Vorgänge fehl
    ESXi 5.5 benötigt mindestens 4 GB an physischem RAM. Das ESXCLI-Befehlszeilentool prüft vor dem Upgrade nicht, ob die erforderlichen 4 GB Arbeitsspeicher vorhanden sind. Mit ESXCLI führen Sie zwar das Upgrade eines Hosts mit zu wenig Arbeitsspeicher erfolgreich durch, aber wenn Sie den aktualisierten ESXi 5.5-Host mit weniger als 4 GB Arbeitsspeicher starten, schlagen einige Vorgänge möglicherweise fehl.

    Problemumgehung: Keine. Stellen Sie sicher, dass auf dem ESXi-Host mindestens 4 GB an physischem RAM vorhanden sind, bevor Sie mit dem Upgrade auf Version 5.5 fortfahren.

  • Nach der Durchführung eines Upgrades von vCenter Server Appliance 5.0.x auf 5.5 schlägt der Start vCenter Server fehl, wenn eine externe vCenter Single Sign-On-Instanz verwendet wird
    Wenn der Benutzer eine externe vCenter Single Sign-On-Instanz verwenden will, während er das Upgrade der vCenter Server Appliance von 5.0.x auf 5.5 durchführt, schlägt der Start des vCenter Server nach dem Upgrade fehl. In der Appliance-Verwaltungsschnittstelle ist die vCenter Single Sign-On-Instanz als nicht konfiguriert aufgelistet.

    Problemumgehung: Führen Sie die folgenden Schritte aus:

    1. Öffnen Sie die vCenter Server Appliance-Verwaltungsschnittstelle in einem Webbrowser (https://Appliance-Adresse:5480).
    2. Klicken Sie auf der Seite "vCenter Server/Übersicht" auf die Schaltfläche Server anhalten.
    3. Füllen Sie auf der vCenter Server/SSO-Seite das Formular mit den entsprechenden Einstellungen aus und klicken Sie auf Einstellungen speichern.
    4. Kehren Sie zur Übersichtsseite zurück und klicken Sie auf Server starten.
  • Beim Upgrade eines ESXi-Hosts der Version 4.x oder 5.0.x auf Version 5.1 oder 5.5 mithilfe von ESXCLI gehen die Einstellungen für vMotion und die Fault Tolerance-Protokollierung (FT Logging) aller VMkernel-Portgruppen nach dem Upgrade verloren
    Wenn Sie den Befehl esxcli software profile update <Optionen> für das Upgrade eines ESXi-Hosts der Version 4.x oder 5.0.x auf Version 5.1 oder 5.5 verwenden, ist zwar das Upgrade erfolgreich, aber die Einstellungen für vMotion und die Fault Tolerance-Protokollierung aller VMkernel-Portgruppen gehen verloren. Deshalb wird für vMotion und die Fault Tolerance-Protokollierung die Standardeinstellung (Deaktiviert) wiederhergestellt.

    Problemumgehung: Führen Sie ein interaktives oder skriptbasiertes Upgrade durch, oder verwenden Sie vSphere Update Manager für das Upgrade der Hosts. Wenn Sie den Befehl esxcli verwenden, müssen Sie die Einstellungen für vMotion und die Fault Tolerance-Protokollierung nach dem Upgrade manuell auf die betroffene VMkernel-Portgruppe anwenden.

  • Beim Upgrade von vSphere 5.0.x oder früher auf Version 5.5 werden die manuell festgelegten Werte für die Zuteilung von Systemressourcen auf den Standardwert zurückgesetzt
    In vSphere 5.0.x und früher müssen Einstellungen in der Benutzeroberfläche für die Zuteilung von Systemressourcen als vorübergehende Umgehung des Problems geändert werden. Diese Einstellungen können nicht auf den Standardwert zurückgesetzt werden, ohne ESXi neu zu installieren. In vSphere 5.1 und höher wird das Systemverhalten geändert, sodass die Beibehaltung von benutzerdefinierten Einstellungen für die Zuteilung von Systemressourcen Werte ergeben könnte, deren Verwendung nicht sicher ist. Beim Upgrade werden all diese Werte zurückgesetzt.

    Problemumgehung: Keine.

  • IPv6-Einstellungen der virtuellen Netzwerkschnittstellenkarte vmk0 werden nach dem Upgrade von ESX 4.x auf ESXi 5.5 nicht beibehalten
    Wenn für einen ESX 4.x-Host mit aktivierter IPv6-Adresse ein Upgrade auf ESXi 5.5 mithilfe der Option --forcemigrate durchgeführt wird, wird die IPv6-Adresse der virtuellen Netzwerkschnittstellenkarte (NIC) vmk0 nach dem Upgrade nicht beibehalten.

    Problemumgehung: Keine.

Probleme bei vCenter Single Sign-On
  • Während eines Upgrades des vSphere Web Client von Version 5.1 Update 1a auf 5.5 wird Fehler 29107 angezeigt
    Während eines Upgrades eines vSphere Web Client von Version 5.1 Update U1a auf Version 5.5 wird der Fehler 29107 angezeigt, wenn der vCenter Single Sign-On-Dienst, der vor dem Upgrade verwendet wurde, als High-Availability-Single Sign On konfiguriert ist.

    Problemumgehung: Führen Sie das Upgrade erneut durch. Sie können das Installationsprogramm ausführen und die benutzerdefinierte Installation wählen, um nur ein Upgrade des vSphere Web Client durchzuführen.

  • Das Kennwort für "administrator@vsphere.local" kann im Pulldown-Menü des vSphere Web Client nicht geändert werden
    Wenn Sie sich aus vSphere Web Client beim vCenter Single Sign-On-Server anmelden, können Sie im Pulldown-Menü Ihr Kennwort ändern. Melden Sie sich allerdings als "administrator@vsphere.local" an, ist die Option Kennwort ändern abgeblendet.

    Problemumgehung:

    1. Klicken Sie auf der Registerkarte Verwalten auf vCenter Single Sign-On > Benutzer und Gruppen.
    2. Klicken Sie mit der rechten Maustaste auf den Administratorbenutzer und wählen Sie Benutzer bearbeiten.
    3. Ändern Sie das Kennwort.

Netzwerkprobleme

  • Verwendung von PCNet32-Netzwerkadapter mit opakem NSX-Netzwerk nicht möglich*
    Wenn der flexible PCNet32-Netzwerkadapter mit der opaken NSX-Netzwerksicherung konfiguriert ist, bricht die Verbindung zum Adapter beim Einschalten der VM ab.
  • Problemumgehung: Keine

  • Beim Upgrade auf ESXi 5.5 wird die IGMP-Konfiguration auf dem TCP/IP-Stack für die Verwaltung von Multicast-Gruppen möglicherweise geändert*
    Die Standard-IGMP-Version der Verwaltungsschnittstellen wird für ESXi 5.5-Hosts für die Verwaltung von Multicast-Gruppen von IGMP V2 in IGMP V3 geändert. Dies führt dazu, dass die Verwaltungsschnittstelle beim Upgrade auf ESXi 5.5 möglicherweise von IGMP V3 auf IGMP V2 zurückgesetzt wird, wenn sie eine IGMP-Abfrage einer früheren Version erhält, und Fehlermeldungen über nicht übereinstimmende IGMP-Versionen angezeigt werden.

    Problemumgehung: Bearbeiten Sie die IGMP-Standardversion, indem Sie das IGMP-Intervall für den erneuten Beitritt unter Verwendung der Option Erweiterte Konfiguration für TCP/IP ändern.
  • Statische Routen, die vmknic-Schnittstellen und dynamischen IP-Adressen zugeordnet sind, werden nach einem Neustart möglicherweise nicht angezeigt
    Nach einem Neustart des Hosts werden statische Routen, die der VMkernel-Netzwerkschnittstelle (vmknic) und dynamischen IP-Adressen zugeordnet sind, möglicherweise nicht angezeigt.
    Dieses Problem entsteht durch eine Racebedingung zwischen dem DHCP-Client und dem Befehl zum Wiederherstellen von Routen. Der DHCP-Client kann das Abrufen einer IP-Adresse für vmknics möglicherweise nicht abschließen, wenn der Host während des Neustarts versucht, benutzerdefinierte Routen wiederherzustellen. Deshalb wird das Gateway möglicherweise nicht eingerichtet, und die Routen werden nicht wiederhergestellt.

    Problemumgehung: Führen Sie den Befehl esxcfg-route –r aus, um die Routen manuell wiederherzustellen.
  • Ein ESXi-Host reagiert nicht mehr, nachdem er über seine IPv6-Adresse zu vCenter Server hinzugefügt wurde
    Wenn Sie einen ESXi-Host über seine verbindungslokale IPv6-Adresse im Format fe80::/64 zu vCenter Server hinzugefügt haben, wird der Hostname nach kurzer Zeit abgeblendet und reagiert nicht mehr auf vCenter Server.

    Problemumgehung: Verwenden Sie eine gültige IPv6-Adresse, bei der es sich nicht um eine verbindungslokale Adresse handelt.

  • Es wird keine Fehlermeldung angezeigt, obwohl Sie in vSphere Web Client mehr virtuelle Funktionen konfigurieren können, als von der physischen Netzwerkkarte unterstützt werden
    In den SR-IOV-Einstellungen eines physischen Adapters können Sie mehr virtuelle Funktionen konfigurieren, als vom Adapter unterstützt werden. Beispielsweise können Sie 100 virtuelle Funktionen für eine Netzwerkkarte konfigurieren, die nur 23 virtuelle Funktionen unterstützt, und es wird dennoch keine Fehlermeldung angezeigt. Sie werden in einer Meldung aufgefordert, den Host neu zu starten, damit die SR-IOV-Einstellungen angewendet werden. Nach dem Neustart des Hosts ist für die Netzwerkschnittstellenkarte die vom Adapter unterstützte Anzahl von virtuellen Funktionen konfiguriert. In diesem Beispiel sind dies 23 virtuelle Funktionen. Die Meldung, in der Sie zum Neustart des Hosts aufgefordert werden, wird weiterhin angezeigt, obwohl dies nicht der Fall sein sollte.

    Problemumgehung: Keine

  • Auf einem SR-IOV-fähigen ESXi-Host können virtuellen Funktionen zugeordnete virtuelle Maschinen möglicherweise nicht gestartet werden
    Wenn SR-IOV auf einem ESXi 5.1-Host oder höher mit Intel ixgbe-Netzwerkkarten aktiviert ist und in der Umgebung verschiedene virtuelle Funktionen aktiviert sind, werden einige virtuelle Maschinen möglicherweise nicht gestartet.
    Die Datei vmware.log enthält Meldungen, die so oder ähnlich lauten:
    2013-02-28T07:06:31.863Z| vcpu-1| I120: Msg_Post: Error
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.log.error.unrecoverable] VMware ESX unrecoverable error: (vcpu-1)
    2013-02-28T07:06:31.863Z| vcpu-1| I120+ PCIPassthruChangeIntrSettings: 0a:17.3 failed to register interrupt (error code 195887110)
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.haveLog] A log file is available in "/vmfs/volumes/5122262e-ab950f8e-cd4f-b8ac6f917d68/VMLibRoot/VMLib-RHEL6.2-64-HW7-default-3-2-1361954882/vmwar
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.requestSupport.withoutLog] You can request support.
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.requestSupport.vmSupport.vmx86]
    2013-02-28T07:06:31.863Z| vcpu-1| I120+ To collect data to submit to VMware technical support, run "vm-support".
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.response] We will respond on the basis of your support entitlement.

    Problemumgehung: Verringern Sie die Anzahl der virtuellen Funktionen, die der betroffenen virtuellen Maschine zugeordnet sind, bevor Sie die VM starten.

  • Auf einem physischen Emulex BladeEngine 3-Netzwerkadapter kann ein durch eine virtuelle Funktion unterstützter VM-Netzwerkadapter einen VMkernel-Adapter nicht erreichen, der die physische Funktion als Uplink verwendet
    Datenverkehr wird nicht zwischen einer virtuellen Funktion und der zugehörigen physischen Funktion übertragen. Beispielsweise kann auf einem durch die physische Funktion unterstützten Switch eine virtuelle Maschine, die eine virtuelle Funktion auf demselben Port verwendet, einen VMkernel-Adapter auf demselben Switch nicht kontaktieren. Dies ist ein bekanntes Problem bei den physischen Emulex BladeEngine 3-Adaptern. Weitere Informationen erhalten Sie von Emulex.

    Problemumgehung: Deaktivieren Sie den systemeigenen Treiber für Emulex BladeEngine 3-Geräte auf dem Host. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 2044993.

  • ESXi Dump Collector kann die ESXi-Kerndatei nicht an den Remoteserver senden
    ESXi Dump Collector kann die ESXi-Kerndatei nicht senden, falls für den VMkernel-Adapter, der den Datenverkehr des Dump Collector verarbeitet, eine verteilte Portgruppe konfiguriert ist, für die eine Linkzusammenfassungsgruppe (LAG) als aktiver Uplink festgelegt ist. Auf dem physischen Switch ist ein LACP-Portkanal konfiguriert.

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

    • Verwenden Sie einen vSphere Standard-Switch zum Konfigurieren des VMkernel-Adapters, der den Datenverkehr für den ESXi Dump Collector mit dem Remoteserver verarbeitet.
    • Verwenden Sie eigenständige Uplinks für den Datenverkehr der verteilten Portgruppe, in welcher der VMkernel-Adapter konfiguriert ist.
  • Wenn Sie mithilfe von vSphere Client die Anzahl der Ports eines vSphere Standard Switch oder vSphere Distributed Switch auf einem Host ändern, wird die Änderung selbst nach einem Neustart nicht wirksam
    Wenn Sie mithilfe von vSphere Client die Anzahl der Ports eines vSphere Standard Switch oder vSphere Distributed Switch auf einem ESXi 5.5-Host ändern, wird die Portanzahl selbst nach einem Neustart nicht geändert.

    Beim Neustart eines Hosts mit ESXi 5.5 werden die Ports der virtuellen Switches dynamisch hoch- oder herunterskaliert. Die Anzahl der Ports orientiert sich an der Anzahl der virtuellen Maschinen, die auf dem Host ausgeführt werden können. Auf Hosts dieser Art müssen Sie die Anzahl der Switch-Ports nicht selbst konfigurieren.

    Problemumgehung: Keine in vSphere Client.

Serverkonfigurationsprobleme

  • Problem bei der Menünavigation, wenn der Zugriff auf die Benutzerschnittstelle der direkten Konsole (DCUI) über eine serielle Konsole erfolgt
    Wenn der Zugriff auf die Benutzerschnittstelle der direkten Konsole über eine serielle Konsole erfolgt, funktionieren die Aufwärts- und Abwärtspfeile bei der Navigation zum Menü nicht, und der Benutzer wird zwangsweise vom DCUI-Konfigurationsbildschirm abgemeldet.

    Problemumgehung: Stoppen Sie den DCUI-Prozess. Der DCUI-Prozess wird automatisch neu gestartet.

  • Nach einem Upgrade von ESXi-Hosts auf 5.5 Update 2 und anschließenden Änderungen der Hostkonfiguration werden Hostprofile möglicherweise fälschlicherweise als übereinstimmend angezeigt
    Wenn ein ESXi-Host, der mit einem Hostprofil übereinstimmt, auf ESXi 5.5 Update 2 aktualisiert wird und wenn anschließend einige Änderungen an der Hostkonfiguration vorgenommen werden, wird das Profil bei einer erneuten Überprüfung der Übereinstimmung zwischen Host und Hostprofil fälschlicherweise als übereinstimmend gemeldet.

    Problemumgehung:
    • Navigieren Sie im vSphere Client zu dem Hostprofil, bei dem das Problem auftritt, und führen Sie Profil aus Referenzhost aktualisieren aus.
    • Navigieren Sie im vSphere Web Client zu dem Hostprofil, bei dem das Problem auftritt, klicken Sie auf Einstellungen vom Host kopieren, wählen Sie den Host aus, von dem Sie die Konfigurationseinstellungen kopieren möchten, und klicken Sie dann auf OK.
  • Beim vSphere Distributed Switch schlägt die Standardisierung des Hostprofils fehl
    Bei der Anwendung eines Hostprofils mit einem vSphere Distributed Switch können Standardisierungsfehler auftreten, wenn sich eine virtuelle Maschine mit Fault Tolerance auf einem Host, der den Distributed Switch im betreffenden Hostprofil verwendet, im ausgeschalteten Zustand befindet.

    Problemumgehung: Verschieben Sie die ausgeschalteten virtuellen Maschinen auf einen anderen Host, damit das Hostprofil angewendet werden kann.

  • Für das Hostprofil werden Übereinstimmungsfehler zu den Firewalleinstellungen angezeigt, wenn Sie ein ESX 4.0- oder ESX 4.1-Profil auf einen ESXi 5.5.x-Host anwenden
    Wenn Sie ein Hostprofil von einem ESX 4.0- oder ESX 4.1-Host extrahieren und versuchen, es auf einen ESXi 5.5.x-Host anzuwenden, wird das Profil erfolgreich standardisiert. Bei der Übereinstimmungsprüfung werden Fehler zu Firewalleinstellungen gemeldet, wie beispielsweise:

    Regelsatz LDAP nicht gefunden
    Regelsatz LDAPS nicht gefunden
    Regelsatz TSM nicht gefunden
    Regelsatz VCB nicht gefunden
    Regelsatz activeDirectorKerberos nicht gefunden

    Problemumgehung: Es ist keine Umgehung erforderlich. Dies wird erwartet, weil die Firewalleinstellungen für einen ESX 4.0- oder ESX 4.1-Host von denen für einen ESXi 5.5.x-Host abweichen.

  • Änderungen der BIOS-Geräteeinstellungen für einen ESXi-Host führen möglicherweise zu ungültigen Gerätenamen
    Änderungen der BIOS-Geräteeinstellungen für einen ESXi-Host führen möglicherweise zu ungültigen Gerätenamen, wenn die Änderung eine Verschiebung der <segment:bus:device:function>-Werte verursacht, die den Geräten zugeordnet sind. Beispielsweise verschiebt die Aktivierung einer vorher deaktivierten, integrierten Netzwerkkarte möglicherweise die <segment:bus:device:function>-Werte, die anderen PCI-Geräten zugeordnet sind. Dies führt dazu, dass ESXi die diesen Netzwerkkarten zugewiesenen Namen ändert. Anders als bei vorherigen Versionen von ESXi versucht ESXi 5.5 Gerätenamen durch <segment:bus:device:function>-Änderungen zu erhalten, falls das Host-BIOS spezifische Gerätestandortinformationen bereitstellt. Wegen eines Bugs in dieser Funktion werden manchmal ungültige Namen wie "vmhba1" und "vmnic32" generiert.

    Problemumgehung: Ein einmaliger oder zweimaliger Neustart des ESXi-Hosts entfernt möglicherweise die ungültigen Gerätenamen und stellt die ursprünglichen Namen wieder her. Führen Sie keinen ESXi-Host aus, der ungültige Gerätenamen besitzt.

Speicherprobleme

  • ESXi-Hosts mit HBA-Treibern reagieren möglicherweise nicht mehr, wenn die VMFS-Taktsignale für die Datenspeicher ablaufen*
    ESXi-Hosts mit HBA-Treibern reagieren möglicherweise nicht mehr, wenn VMFS-Taktsignale für die Datenspeicher mit Fehlermeldungen ähnlich den Folgenden ablaufen:

    mem>2014-05-12T13:34:00.639Z cpu8:1416436)VMW_SATP_ALUA: satp_alua_issueCommandOnPath:651: Path "vmhba2:C0:T1:L10" (UP) command 0xa3 failed with status Timeout. H:0x5 D:0x0 P:0x0 Possible sense data: 0x5 0x20 0x0.2014-05-12T13:34:05.637Z cpu0:33038)VMW_SATP_ALUA: satp_alua_issueCommandOnPath:651: Path "vmhba2:C0:T1:L4" (UP) command 0xa3 failed with status Timeout. H:0x5 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0.

    Dieses Problem tritt bei dem HBA-Treiber auf, wenn eine hohe Festplatten-E/A im Datenspeicher mit dem ESXi-Host verbunden und Multipathing nicht auf der HBA-Ebene, sondern auf der Zielebene aktiviert ist.

    Problemumgehung: Ersetzen Sie den HBA-Treiber durch den neuesten Async-HBA-Treiber.
  • Versuche, Storage vMotion für virtuelle Maschinen mit RDM-Festplatten im Live-Modus durchzuführen, schlagen möglicherweise fehl
    Storage vMotion-Vorgänge für virtuelle Maschinen mit RDM-Festplatten schlagen möglicherweise fehl, und virtuelle Maschinen werden möglicherweise als ausgeschaltet angezeigt. Versuche, die virtuelle Maschine einzuschalten, schlagen mit dem folgenden Fehler fehl:

    Datei konnte nicht gesperrt werden

    Problemumgehung: Keine.
  • Umbenannte Tags werden im Assistenten „VM-Speicherrichtlinie bearbeiten“ als fehlend angezeigt
    Eine Speicherrichtlinie für virtuelle Maschinen kann Regeln basierend auf Datenspeicher-Tags enthalten. Wenn Sie ein Tag umbenennen, wird es von der VM-Speicherrichtlinie, die auf dieses Tag verweist, nicht automatisch aktualisiert und als fehlend angezeigt.

    Problemumgehung: Entfernen Sie das als fehlend gekennzeichnete Tag aus der VM-Speicherrichtlinie und fügen Sie das umbenannte Tag hinzu. Wenden Sie die Speicherrichtlinie auf alle veralteten Elemente an.

  • Virtuelle Maschinen können nicht eingeschaltet werden, wenn für deren Flash-Lesecache eine Blockgröße von 16 KB, 256 KB, 512 KB oder 1024 KB festgelegt ist
    Virtuelle Maschinen, für die der Flash-Lesecache und eine Blockgröße von 16 KB, 256 KB, 512 KB oder 1024 KB konfiguriert sind, können nicht eingeschaltet werden. Der Flash-Lesecache unterstützt eine Cachegröße von mindestens 4 MB und höchstens 200 GB sowie eine Blockgröße von mindestens 4 KB und höchstens 1 MB. Beim Einschalten der virtuellen Maschine schlägt der Vorgang mit folgenden Fehlermeldungen fehl:

    Beim ESX-Host ist ein Fehler beim Einschalten der virtuellen Maschine aufgetreten.

    Das Starten der virtuellen Maschine ist fehlgeschlagen.

    Einschalten des Moduls 'DiskEarly' fehlgeschlagen.

    Die Festplatte 'scsi0:0' konnte nicht konfiguriert werden.

    Mit einer nicht konfigurierten Festplatte kann die virtuelle Maschine nicht eingeschaltet werden. vFlash-Cache kann nicht angehängt werden: msg.vflashcache.error.VFC_FAILURE

    Problemumgehung: Konfigurieren Sie die Größe und die Blockgröße des Flash-Lesecache für die virtuelle Maschine.

    1. Klicken Sie mit der rechten Maustaste auf die virtuelle Maschine und wählen Sie Einstellungen bearbeiten.
    2. Erweitern Sie auf der Registerkarte Virtuelle Hardware die Option Festplatte, um die Festplattenoptionen anzuzeigen.
    3. Klicken Sie neben dem Feld vFlash-Lesecache auf Erweitert.
    4. Erhöhen Sie den Wert für die zu reservierende Cachegröße, oder reduzieren Sie die Blockgröße.
    5. Klicken Sie auf OK, um Ihre Änderungen zu speichern.
  • Benutzerdefinierte Erweiterungen einer gespeicherten Ressourcenpoolstruktur-Datei können in vSphere Web Client nicht geladen werden
    Auf der Hostübersichtsseite wird eine DRS-Fehlermeldung angezeigt.

    Beim Deaktivieren von DRS in vSphere Web Client werden Sie aufgefordert, die Ressourcenpoolstruktur zu speichern, damit sie in Zukunft erneut geladen werden kann. Die Standarderweiterung dieser Datei lautet .snapshot, aber Sie können auch eine andere Erweiterung für diese Datei auswählen. Wenn die Datei eine benutzerdefinierte Erweiterung aufweist, wird sie beim Laden als deaktiviert angezeigt. Dieses Verhalten tritt nur bei OS X auf.

    Problemumgehung: Ändern Sie die Erweiterung in .snapshot, damit die Datei in vSphere Web Client unter OS X geladen werden kann.

  • Auf der Übersichtsseite des Hosts wird eine DRS-Fehlermeldung ausgegeben
    Auf der Übersichtsseite des Hosts wird folgende DRS-Fehlermeldung anzeigt:

    DRS-Ressourceneinstellungen können nicht auf dem Host angewendet werden. Der Vorgang ist im aktuellen Zustand nicht zulässig. Dies kann die Effektivität von DRS erheblich beeinträchtigen.

    Bei manchen Konfigurationen kann aufgrund einer Racebedingung eine Fehlermeldung im Protokoll erstellt werden, die nicht sinnvoll ist und die ignoriert werden kann. Diese Fehlermeldung kann darauf zurückzuführen sein, dass die Registrierung einer virtuellen Maschine zum selben Zeitpunkt aufgehoben wird, zu dem DRS-Ressourceneinstellungen angewendet werden.

    Problemumgehung: Sie können diese Fehlermeldung ignorieren.

  • Die Konfiguration des vFlash-Lesecache für VMDKs mit mehr als 16 TB führt zu einer Fehlermeldung
    Der vFlash-Lesecache unterstützt keine virtuellen Maschinen mit mehr als 16 TB. Konfigurationsversuche derartiger Festplatten schlagen fehl.

    Problemumgehung: Keine

  • Virtuelle Maschinen werden beim Neukonfigurieren der Cachegröße möglicherweise ausgeschaltet
    Wenn Sie den vFlash-Lesecache auf einer virtuellen Maschine falsch konfigurieren, beispielsweise durch Zuweisung eines ungültigen Werts, wird die virtuelle Maschine möglicherweise ausgeschaltet.

    Problemumgehung: Halten Sie sich an die Empfehlungen für die Cachegröße in der Dokumentation zu vSphere Storage.

  • Die Neukonfiguration einer virtuellen Maschine mit aktiviertem vFlash Read Cache kann mit der Fehlermeldung Zeitüberschreitung beim Vorgang fehlschlagen
    Neukonfigurationsvorgänge benötigen sehr viel E/A-Bandbreite. Falls das System stark ausgelastet ist, kann bei derartigen Vorgängen vor dem Abschluss eine Zeitüberschreitung auftreten. Dieses Verhalten kann auch auftreten, wenn auf dem Host LUNs vorhanden sind, die einen APD-Zustand (All Paths Down, keine Pfade verfügbar) aufweisen.

    Problemumgehung: Korrigieren Sie alle APD-Zustände des Hosts und wiederholen Sie den Vorgang mit einer geringeren E/A-Last auf LUN und Host.

  • DRS führt für virtuelle Maschinen mit vFlash-Lesecache aus Gründen des Lastausgleichs keinen vMotion-Vorgang aus
    DRS führt für virtuelle Maschinen mit vFlash-Lesecache aus Gründen des Lastausgleichs keinen vMotion-Vorgang aus.

    Problemumgehung: DRS empfiehlt die Ausführung von vMotion für diese virtuellen Maschinen nur in folgenden obligatorischen Fällen:

    • Zum Evakuieren eines Hosts, für den der Benutzer den Wartungs- oder Standby-Modus angefordert hat
    • Zum Beheben von DRS-Regelverstößen.
    • Die Ressourcennutzung des Hosts weist den Status "Rot" auf.
    • Mindestens ein Host ist überlastet, und der Bedarf der virtuellen Maschine wird nicht erfüllt.
      Hinweis: Sie können optional festlegen, dass DRS diesen Grund ignoriert.
  • Hosts werden in den Standby-Modus versetzt, wenn bei virtuellen Maschinen der aktive Arbeitsspeicher niedrig, aber der belegte Arbeitsspeicher hoch ist
    In ESXi 5.5 gibt es eine Änderung beim Standardverhalten von DPM, um diese Funktion weniger aggressiv zu gestalten. Dadurch kann die Leistungsbeeinträchtigung für virtuelle Maschinen verhindert werden, wenn der aktive Arbeitsspeicher niedrig, aber der belegte Arbeitsspeicher hoch ist. Die Formel für DPM lautet X%*IdleConsumedMemory + active memory. Die Variable X% kann angepasst werden und ist standardmäßig auf 25 % festgelegt.

    Problemumgehung: Sie können auf das aggressive Verhalten von DPM aus früheren Versionen von ESXi zurückgreifen, indem Sie in den erweiterten Optionen PercentIdleMBInMemDemand=0 einstellen.

  • Von DRS initiierte vMotion-Vorgänge schlagen möglicherweise fehl
    In Fällen, in denen DRS für virtuelle Maschinen mit einer vFlash-Lesecache-Reservierung einen vMotion-Vorgang empfiehlt, kann vMotion fehlschlagen, da auf dem Zielhost nicht genügend Arbeitsspeicher (RAM) zum Verwalten der Flash-Lesecache-Reservierung der virtuellen Maschinen vorhanden ist.

    Problemumgehung: Halten Sie sich an die Konfigurationsempfehlungen für den Flash-Lesecache in der Dokumentation zu vSphere Storage.
    Falls vMotion fehlschlägt, führen Sie die folgenden Schritte aus:

    1. Konfigurieren Sie die Blockgröße der virtuellen Maschinen auf dem Zielhost und die eingehenden virtuellen Maschinen neu, um die allgemeine Zielnutzung des VMkernel-Arbeitsspeichers auf dem Zielhost zu reduzieren.
    2. Verschieben Sie die virtuelle Maschine mithilfe von vMotion manuell auf den Zielhost, um sicherzustellen, dass dieses Problem nicht mehr auftritt.
  • Probleme, die während der vFlash-Konfiguration von einzelnen SSD-Geräten auftreten, werden nicht angezeigt
    Die Konfiguration von vFlash-Ressourcen ist eine Aufgabe, die anhand einer Liste von SSD-Geräten ausgeführt wird. Nach Abschluss der Aufgabe für alle Objekte meldet vSphere Web Client die erfolgreiche Durchführung, möglicherweise ohne über eventuelle Probleme bei der Konfiguration einzelner SSD-Geräte zu informieren.

    Problemumgehung: Führen Sie eine der folgenden Aufgaben aus:

    • Doppelklicken Sie im Fenster "Kürzlich bearbeitete Aufgaben" auf die abgeschlossene Aufgabe.
      Etwaige Konfigurationsfehler werden im Abschnitt "Verknüpfte Ereignisse" des Dialogfelds "Aufgabendetails" angezeigt.
    • Sie können auch folgende Schritte ausführen:
      1. Wählen Sie den Host in der Bestandsliste aus.
      2. Klicken Sie auf die Registerkarte Überwachen, und klicken Sie auf Ereignisse.
  • Es können keine SMART-Informationen für Micron PCIe SSDs auf dem ESXi-Host abgerufen werden
    Ihre Versuche, den Befehl esxcli storage core device smart get -d zu verwenden, um Statistiken für das Micron PCIe SSD-Gerät anzuzeigen, schlagen fehl. Die folgende Fehlermeldung wird angezeigt:
    Fehler beim Abrufen von Smart-Parametern: Das Gerät kann nicht geöffnet werden

    Problemumgehung: Keine. In dieser Version werden Micron PCIe-SSDs von diesem Befehl esxcli storage core device smart nicht unterstützt.

  • ESXi wendet den Grenzwert für die Bandbreite, der für eine virtuelle SCSI-Festplatte in der Konfigurationsdatei einer virtuellen Maschine konfiguriert ist, nicht an
    Die Grenzwerte für die Bandbreite und den Durchsatz einer virtuellen SCSI-Festplatte werden mithilfe eines Parametersatzes in der Konfigurationsdatei der virtuellen Maschine (.vmx) konfiguriert. Beispielsweise könnte die Konfigurationsdatei die folgenden Grenzwerte für die virtuelle Festplatte scsi0:0 enthalten:
    sched.scsi0:0.throughputCap = "80IOPS"
    sched.scsi0:0.bandwidthCap = "10MBps"
    sched.scsi0:0.shares = "normal"

    ESXi wendet den Grenzwert sched.scsi0:0.bandwidthCap nicht auf die virtuelle Festplatte scsi0:0 an.

    Problemumgehung: Setzen Sie auf eine frühere Version des Festplatten-E/A-Schedulers zurück, indem Sie den vSphere Web Client oder den Befehl "esxcli system settings advanced set" verwenden.

    • Bearbeiten Sie im vSphere Web Client in der Liste "Erweiterte Systemeinstellungen" für den Host den Parameter Disk.SchedulerWithReservation.
      1. Navigieren Sie zum Host.
      2. Klicken Sie auf der Registerkarte Verwalten auf Einstellungen und wählen Sie Erweiterte Systemeinstellungen.
      3. Suchen Sie den Parameter Disk.SchedulerWithReservation, beispielsweise mithilfe der Textfelder Filter oder Suchen.
      4. Klicken Sie auf Bearbeiten, und legen Sie den Parameter auf "0" fest.
      5. Klicken Sie auf OK.
    • Führen Sie in der ESXi Shell für den Host den folgenden Konsolenbefehl aus:
      esxcli system settings advanced set -o /Disk/SchedulerWithReservation -i=0
  • Bei einer Migration können virtuelle Maschinen mit konfiguriertem Flash-Lesecache nicht aus dem Host entfernt werden, wenn im Cache ein Fehler vorliegt
    Bei virtuellen Maschinen mit konfiguriertem Flash-Lesecache können Migrationsfehler auftreten, wenn der Cache fehlerhaft oder nicht verwendbar ist. Dieser Fehler verhindert die Migration dieser virtuellen Maschinen.

    Problemumgehung:

    1. Konfigurieren Sie die betroffenen virtuellen Maschinen neu und deaktivieren Sie den Cache.
    2. Führen Sie die Migration aus.
    3. Aktivieren Sie den Cache erst nach Abschluss der Migration.

    Sie können die virtuelle Maschine auch erst ab- und dann wieder einschalten, um den Fehler im Cache zu beheben.

  • Sie können das VFFS-Volume nach dem Upgrade eines Hosts von ESXi 5.5 Beta nicht löschen
    Sie können das VFFS-Volume nicht löschen, nachdem für einen Host ein Upgrade von ESXi 5.5 Beta durchgeführt wurde.

    Problemumgehung: Dies tritt nur auf, wenn Sie ein Upgrade von ESXi 5.5 Beta auf ESXi 5.5 durchführen. Installieren Sie ESXi 5.5 anstelle eines Upgrades, um dieses Problem zu vermeiden. Beim Upgrade von ESXi 5.5 Beta löschen Sie das VFFS-Volume vor dem Upgrade.

  • Die erwarteten Verbesserungen der Latenzzeit treten nicht ein, wenn der vFlash-Lesecache auf virtuellen Maschinen mit älteren Windows- und Linux-Gastbetriebssystemen aktiviert ist
    Der vFlash-Lesecache bietet optimale Leistung, wenn die Cache-Größe mit jener des Ziel-Working-Sets übereinstimmt und die Dateisysteme des Gastbetriebssystems mindestens an einer 4-KB-Grenze ausgerichtet sind. Der Flash-Lesecache filtert falsch ausgerichtete Blöcke aus, um die Zwischenspeicherung von Teilblöcken im Cache zu vermeiden. Dieses Verhalten ist typisch, wenn der vFlash-Lesecache für VMDKs von virtuellen Maschinen mit Windows XP sowie Linux-Distributionen vor 2.6. konfiguriert ist. In diesen Fällen tritt eine niedrige Cachezugriffsrate mit einer niedrigen Cache-Belegung auf, die eine Verschwendung der Cachereservierung für diese VMDKs bedeutet. Dieses Verhalten trifft nicht auf virtuelle Maschinen zu, auf denen Windows 7, Windows 2008 oder Linux ab Distribution 2.6 ausgeführt wird. Diese Betriebssysteme richten ihre Dateisysteme an einer 4-KB-Grenze aus, um eine optimale Leistung zu erzielen.

    Problemumgehung: Um die Cachezugriffsrate und die optimale Verwendung der Cachereservierung für jede VMDK zu verbessern, stellen Sie sicher, dass das auf der VMDK installierte Gastbetriebssystem mindestens an einer 4-KB-Grenze ausgerichtet ist.

Virtual SAN

  • Ein ESXi-Host mit mehreren VSAN-Festplattengruppen zeigt die Magnetfestplattenstatistik bei Ausführung des vsan.disks_stats-Befehls möglicherweise nicht an*
    Ein ESXi-Host mit mehreren VSAN-Festplattengruppen zeigt die Magnetfestplattenstatistik bei Ausführung des RVC (Ruby vSphere Console)-Befehls vsan.disks_stats möglicherweise nicht an. Der Host zeigt nur die SSD (Solid-State Drive)-Informationen an.

    Problemumgehung: Keine
  • VM-Verzeichnisse enthalten doppelte Auslagerungsdateien (.vswp)
    Dieses Problem tritt möglicherweise auf, wenn die virtuellen Maschinen, die im Virtual SAN ausgeführt werden, nicht ordnungsgemäß heruntergefahren werden und wenn Sie eine Neuinstallation von ESXi und vCenter Server ausführen, ohne die Daten von den Virtual SAN-Festplatten zu löschen. Dies führt dazu, dass alte Auslagerungsdateien (.vswp) sich in den Verzeichnissen für die virtuellen Maschinen befinden, die nicht ordnungsgemäß heruntergefahren wurden.

    Problemumgehung: Keine

  • Versuche, einer Virtual SAN-Festplattengruppe mehr als sieben Magnetfestplatten hinzuzufügen, schlagen möglicherweise mit einer falschen Fehlermeldung fehl
    Virtual SAN-Festplattengruppen unterstützen maximal eine SSD-Festplatte und sieben HDD-Magnetfestplatten. Versuche, eine weitere Magnetfestplatte hinzuzufügen, schlagen möglicherweise mit einer falschen Fehlermeldung ähnlich der folgenden fehl:

    Die Anzahl der Festplatten ist nicht ausreichend.

    Problemumgehung: Keine
  • Erneute Prüfung schlägt beim Hinzufügen einer Virtual SAN-Festplatte fehl
    Wenn Sie eine Virtual SAN-Festplatte hinzufügen, schlägt die erneute Prüfung wegen eines Testfehlers in Bezug auf einen non-Virtual SAN-Datenträger fehl.

    Problemumgehung: Sie können den Fehler ignorieren, da alle Festplatten richtig registriert werden.
  • Ein Festplattenlaufwerk (HDD), das nach dem zugehörigen Solid-State-Laufwerk (SSD) entfernt wird, wird möglicherweise weiterhin als Speicherfestplatte aufgelistet, die von Virtual SAN beansprucht wird
    Wenn zuerst ein SSD- und dann das zugehörige HDD-Laufwerk von einem Virtual SAN-Datenspeicher entfernt wird und Sie den Befehl esxcli vsan storage list ausführen, wird das bereits entfernte HDD-Laufwerk immer noch als von Virtual SAN beanspruchte Speicherfestplatte aufgelistet. Wenn das HDD-Laufwerk anschließend in einen anderen Host eingelegt wird, wird es möglicherweise als Komponente von zwei verschiedenen Hosts angezeigt.

    Problemumgehung: Wenn SSD und HDD beispielsweise aus dem ESXi-Host x entfernt und in den ESXi-Host y eingelegt werden, führen Sie die folgenden Schritte aus, um zu verhindern, dass das HDD-Laufwerk als Komponente von ESXi-Host x und ESXi-Host y angezeigt wird:
    1. Legen Sie die SSD- und HDD-Laufwerke, die aus dem ESXi-Host x entfernt wurden, in den ESXi-Host y ein.
    2. Nehmen Sie das SSD-Laufwerk auf dem ESXi-Host x außer Betrieb.
    3. Führen Sie den Befehl esxcfg-rescan -A aus.
       Die HDD- und SSD-Laufwerke werden nun nicht mehr auf dem ESXi-Host x aufgelistet.
  • Der Abschnitt Arbeiten mit Virtual SAN der vSphere Storage-Dokumentation gibt an, dass die maximale Anzahl der HDD-Festplatten pro Festplattengruppe 6 beträgt. Die maximal zulässige Anzahl von HDD-Festplatten beträgt jedoch 7.
  • Nach einem Fehlschlag in einem Virtual SAN-Cluster meldet vSphere HA möglicherweise mehrere zum Teil irreführende Ereignisse, bevor eine virtuelle Maschine neu gestartet wird
    Der vSphere HA-Master-Agent versucht mehrfach, eine auf Virtual SAN ausgeführte virtuelle Maschine neu zu starten, nachdem sie anscheinend ausgefallen war. Wenn die virtuelle Maschine nicht sofort neu gestartet werden kann, überwacht der Master-Agent den Clusterzustand und unternimmt einen weiteren Versuch, sofern die Bedingungen darauf hindeuten, dass ein Neustart erfolgreich sein könnte. Für virtuelle Maschinen, die auf Virtual SAN ausgeführt werden, verfügt der vSphere HA-Master-Agent über eine spezielle Anwendungslogik, die erkennt, wenn sich die Zugriffsfähigkeit auf Objekte einer virtuellen Maschine möglicherweise geändert hat, und versucht, sie neu zu starten, wenn eine Änderung der Zugriffsfähigkeit wahrscheinlich ist. Der Master-Agent unternimmt einen erneuten Versuch nach jeder möglichen Änderung der Zugriffsfähigkeit sowie in den Fällen, bei denen die virtuelle Maschine nicht erfolgreich eingeschaltet werden konnte und auf die nächste mögliche Änderung der Zugriffsfähigkeit gewartet werden muss.

    Nach jedem gescheiterten Versuch meldet vSphere HA ein Ereignis, das angibt, dass das Failover fehlgeschlagen ist. Nach fünf Fehlschlägen meldet vSphere HA, dass keine weiteren Versuche zum Neustarten der virtuellen Maschine unternommen werden, da die maximale Anzahl der Failover-Versuche erreicht wurde. Selbst nachdem gemeldet wurde, dass der vSphere HA-Master-Agent keine weiteren Versuche unternimmt, wird bei der nächsten möglichen Änderung der Zugriffsfähigkeit dennoch ein weiterer Versuch unternommen.

    Problemumgehung: Keine.

  • Durch das Ausschalten eines Virtual SAN-Hosts wird die Ansicht der Speicheranbieter im vSphere Web Client länger als erwartet aktualisiert
    Wenn Sie einen Virtual SAN-Host ausschalten, wird die Ansicht der Speicheranbieter möglicherweise ohne Inhalt angezeigt. Die Schaltfläche "Aktualisieren" dreht sich weiter, obwohl keine Informationen angezeigt werden.

    Problemumgehung: Warten Sie mindestens 15 Minuten, bis die Ansicht der Speicheranbieter wieder ausgefüllt wird. Die Ansicht wird auch dann aktualisiert, wenn Sie den Host einschalten.

  • Virtual SAN meldet eine fehlgeschlagene Aufgabe als abgeschlossen
    Möglicherweise meldet Virtual SAN bestimmte Aufgaben als abgeschlossen, obwohl sie intern fehlgeschlagen sind.

    Nachfolgend finden Sie Bedingungen und entsprechende Gründe für Fehler:

    • Bedingung: Benutzer versuchen, eine neue Festplattengruppe zu erstellen oder eine neue Festplatte zu einer bereits vorhandenen Festplattengruppe hinzuzufügen, nachdem die Virtual SAN-Lizenz bereits abgelaufen ist.
      Fehlerstapel: Ein allgemeiner Systemfehler ist aufgetreten: Festplatte kann nicht hinzugefügt werden Virtual SAN ist nicht auf diesem Host lizenziert.
    • Bedingung: Benutzer versuchen, eine Festplattengruppe mit einer Anzahl von Platten zu erstellen, die höher als die maximal unterstützte Anzahl ist. Oder sie versuchen, neue Festplatten zu einer bereits vorhandenen Festplattengruppe hinzuzufügen, sodass die Gesamtzahl der Festplatten die unterstützte maximale Anzahl der Festplatten pro Festplattengruppe überschreitet.
      Fehlerstapel: Ein allgemeiner Systemfehler ist aufgetreten: Zu viele Festplatten.
    • Bedingung: Benutzer versuchen, eine Festplatte zur Festplattengruppe mit Fehlern hinzuzufügen.
      Fehlerstapel: Ein allgemeiner Systemfehler ist aufgetreten: Es konnte keine Partitionstabelle erstellt werden.

    Problemumgehung: Nachdem der Grund für einen Fehler identifiziert wurde, beheben Sie diesen und führen Sie die Aufgabe erneut aus.

  • Virtual SAN-Datenspeicher können keine lokalen Host- und Systemauslagerungsdateien speichern
    In der Regel können Sie die System- oder die lokale Hostauslagerungsdatei auf einem Datenspeicher ablegen. Der Virtual SAN-Datenspeicher unterstützt jedoch keine System- oder lokalen Hostauslagerungsdateien. Folglich steht die UI-Option, die es Ihnen ermöglicht, den Virtual SAN-Datenspeicher als Speicherort für die System- bzw. die lokale Hostauslagerungsdatei auszuwählen, nicht zur Verfügung.

    Problemumgehung: Verwenden Sie in einer Virtual SAN-Umgebung andere unterstützte Optionen zum Speichern der lokalen Host- und Systemauslagerungsdateien.

  • Eine Virtual SAN-VM in einem vSphere HA-Cluster wird als vSphere HA-geschützt gemeldet, obwohl sie ausgeschaltet wurde
    Dies kann passieren, wenn Sie eine virtuelle Maschine ausschalten, deren Home-Objekt sich in einem Virtual SAN-Datenspeicher befindet und der Zugriff auf das Objekt nicht möglich ist. Dieses Problem tritt auf, wenn die Wahl eines HA-Master-Agenten erfolgt, nachdem der Zugriff auf das Objekt nicht mehr möglich ist.

    Problemumgehung:

    1. Vergewissern Sie sich, dass auf das Home-Objekt wieder zugegriffen werden kann, indem Sie die Übereinstimmung des Objekts mit der angegebenen Speicherrichtlinie überprüfen.
    2. Schalten Sie die virtuelle Maschine ein und dann wieder aus.

    Der Status ändert sich in "Nicht geschützt".

  • Das VM-Objekt behält den Status "Veraltet" auch dann bei, wenn die Aktion "Neu anwenden" ausgelöst und erfolgreich abgeschlossen wurde
    Wenn Sie aufgrund der neuen Speicheranforderungen das vorhandene Profil einer virtuellen Maschine bearbeiten, erhalten die zugeordneten VM-Objekte (Home oder Festplatte) möglicherweise den Status "Veraltet". Dies passiert, wenn die aktuelle Umgebung keine Neukonfiguration der VM-Objekte unterstützt. Durch Verwendung der Aktion Neu anwenden wird der Status nicht geändert.

    Problemumgehung: Fügen Sie zusätzliche Ressourcen, Hosts oder Festplatten zum Virtual SAN-Cluster hinzu und führen Sie die Aktion Neu anwenden erneut aus.

  • Die automatisch Beanspruchung von Festplatten funktioniert bei Virtual SAN nicht wie erwartet, wenn Sie Virtual SAN nach Aktivieren dieser Funktion lizenzieren
    Wenn Sie Virtual SAN im automatischen Modus aktivieren und anschließend eine Lizenz zuweisen, beansprucht Virtual SAN keine Festplatten.

    Problemumgehung: Ändern Sie den Modus in Manuell und anschließend zurück in Automatisch. Virtual SAN beansprucht dann die Festplatten ordnungsgemäß.

  • vSphere High Availability (HA) kann eine virtuelle Maschine nicht neu starten, wenn das Virtual SAN-Netzwerk partitioniert ist
    Dies tritt auf, wenn Virtual SAN für die Internode-Kommunikation VMkernel-Adapter verwendet, die sich in demselben Subnetz wie andere VMkernel-Adapter eines Clusters befinden. Eine solche Konfiguration kann zu einem Netzwerkausfall führen und die Internode-Kommunikation von Virtual SAN unterbrechen, wohingegen die Internode-Kommunikation von vSphere HA davon nicht berührt wird.

    In dieser Situation erkennt der HA-Master-Agent möglicherweise den Ausfall einer virtuellen Maschine, kann diese aber nicht neu starten. Dieses Problem kann beispielsweise auftreten, wenn der Host, auf dem der Master-Agent ausgeführt wird, keinen Zugriff auf die Objekte der virtuellen Maschine besitzt.

    Problemumgehung: Stellen Sie sicher, dass die von Virtual SAN verwendeten VMkernel-Adapter kein Subnetz gemeinsam mit den VMkernel-Adaptern nutzen, die zu anderen Zwecken verwendet werden.

  • VM-Verzeichnisse enthalten doppelte Auslagerungsdateien (.vswp)   
    Dieses Problem tritt möglicherweise auf, wenn die virtuellen Maschinen, die im Virtual SAN ausgeführt werden, nicht ordnungsgemäß heruntergefahren werden und wenn Sie eine Neuinstallation von ESXi und vCenter Server ausführen, ohne die Daten von den Virtual SAN-Festplatten zu löschen. Dies führt dazu, dass alte Auslagerungsdateien (.vswp) sich in den Verzeichnissen für die virtuellen Maschinen befinden, die nicht ordnungsgemäß heruntergefahren wurden.

    Problemumgehung: Keine

  • Virtuelle Maschinen sind möglicherweise aufgrund hoher Netzwerklatenz nicht mehr verfügbar
    Wenn in einem Virtual SAN-Cluster die Netzwerklatenz hoch ist, ist in vCenter Server möglicherweise kein Zugriff mehr auf einige virtuelle Maschinen möglich und Sie können die virtuellen Maschinen nicht einschalten oder auf sie zugreifen.

    Problemumgehung: Führen Sie den RVC-Befehl vsan.check_state -e -r aus.
  • Bei VM-Vorgängen tritt möglicherweise aufgrund von hoher Netzwerklatenz eine Zeitüberschreitung ein
    Wenn Speichercontroller mit geringen Warteschlangentiefen verwendet werden, kann eine hohe Netzwerklatenz eine Zeitüberschreitung von Vorgängen virtueller Maschinen verursachen.

    Problemumgehung: Wiederholen Sie die Vorgänge, wenn die Netzwerkauslastung geringer ist.
  • Virtuelle Maschinen werden möglicherweise in eine verkürzte Version ihres VMX-Dateipfads umbenannt
    Wenn vorübergehend kein Zugriff auf die VMX-Datei einer virtuellen Maschine möglich ist, wird die virtuelle Maschine in eine verkürzte Version des VMX-Dateipfads umbenannt. Beispiel für die Umbenennung einer virtuellen Maschine: /vmfs/volumes/vsan:52f1686bdcb477cd-8e97188e35b99d2e/236d5552-ad93. Durch das Abschneiden des Dateipfads wird möglicherweise die Hälfte der UUID des Stammverzeichnisses der virtuellen Maschine gelöscht, sodass es schwierig ist, die umbenannte virtuelle Maschine anhand ihres Namens der ursprünglichen virtuellen Maschine zuzuordnen.

    Problemumgehung: Führen Sie den RVC-Befehl vsan.fix_renamed_vms aus.

vCenter Server und vSphere Web Client

  • ESXi-Host kann Active Directory-Domäne nicht hinzugefügt werden
    Beim Versuch, Berechtigungen zuzuweisen, wird der Active Directory-Domänenname möglicherweise nicht in der Dropdown-Liste "Domäne" unter der Option "Benutzer und Gruppen auswählen" angezeigt. Außerdem wird unter der Option "Authentifizierungsdiensteinstellungen" möglicherweise kein vertrauenswürdiger Domänen-Controller angezeigt, selbst wenn Active Directory über vertrauenswürdige Domänen verfügt.

    Problemumgehung:
    1. Starten Sie die netlogond-, lwiod- und lsassd-Daemons neu.
    2. Melden Sie sich über den vSphere Client beim ESXi-Host an.
    3. Klicken Sie auf der Registerkarte Konfiguration auf Authentifizierungsdiensteinstellungen.
    4. Aktualisieren Sie den Bildschirm, um die vertrauenswürdigen Domänen anzuzeigen.

VM-Verwaltungsprobleme

  • Cold-Migration und Storage vMotion können für eine virtuelle Maschine nicht ausgeführt werden, wenn der VMDK-Dateiname mit „core“ beginnt*
    Das Ausführen von Cold-Migration und Storage vMotion für eine virtuelle Maschine schlägt mit einer Fehlermeldung ähnlich der Folgenden fehl, wenn der VMDK-Dateiname mit „core“ beginnt:

    Ein allgemeiner Systemfehler ist aufgetreten: Fehler beim Benennen oder Umbenennen einer VM-Datei.

    Möglicherweise werden in der Protokolldatei vpxd.log Fehlermeldungen ähnlich der folgenden angezeigt:

    mem> 2014-01-01T11:08:33.150-08:00 [13512 info 'commonvpxLro' opID=8BA11741-0000095D-86-97] [VpxLRO] -- FINISH task-internal-2471 -- -- VmprovWorkflow --
    mem> 2014-01-01T11:08:33.150-08:00 [13512 info 'Default' opID=8BA11741-0000095D-86-97] [VpxLRO] -- ERROR task-internal-2471 -- -- VmprovWorkflow: vmodl.fault.SystemError:
    mem> --> Result:
    mem> --> (vmodl.fault.SystemError){
    mem> --> dynamicType = ,
    mem> --> faultCause = (vmodl.MethodFault) null,
    mem> --> reason = "Error naming or renaming a VM file.",
    mem> --> msg = "",
    mem> --> }

    Dieses Problem tritt auf, wenn der ESXi-Host VMDK-Dateien mit einem Dateinamen, der mit "core" beginnt, fälschlicherweise als Core-Datei und nicht als den erwarteten Festplattentyp klassifiziert.

    Problemumgehung: Stellen Sie sicher, dass der VMDK-Dateiname der virtuellen Maschine nicht mit "core" beginnt. Verwenden Sie außerdem zum Umbenennen der VMDK-Datei das Dienstprogramm vmkfstools, um sicherzustellen, dass der Dateiname nicht mit dem Wort "core" beginnt.
  • Bei virtuellen Maschinen mit Windows 7 Enterprise 64-Bit-Gastbetriebssystemen in französischer Sprache treten bei Klonvorgängen Probleme auf
    Falls Sie eine geklonte virtuelle Maschine unter einer französischen Version von Windows 7 Enterprise 64-Bit verwenden, wird die virtuelle Maschine vom Netzwerk getrennt und die Anpassungsspezifikation wird nicht angewendet. Dieses Problem tritt auf, wenn die virtuelle Maschine auf einem ESXi 5.1-Host ausgeführt wird, auf ESXi 5.5 geklont wird und die VMware Tools-Version auf die neueste für den ESXi 5.5-Host verfügbare Version aktualisiert wird.

    Problemumgehung: Führen Sie ein Upgrade der Kompatibilität der virtuellen Maschine auf ESXi 5.5 und höher durch, bevor Sie ein Upgrade auf die neueste verfügbare Version von VMware Tools vornehmen.

  • Das Vergrößern einer virtuellen Festplatte für eine ausgeführte virtuelle Maschine schlägt fehl
    Wenn Sie die virtuelle Festplatte vergrößern, während die virtuelle Maschine ausgeführt wird, wird möglicherweise folgende Fehlermeldung angezeigt:

    Der Vorgang wird bei diesem Gerätetyp nicht unterstützt.

    Dieser Fehler kann auftreten, wenn Sie die Festplatte auf über 2 TB vergrößern. Die Erweiterung im laufenden Betrieb unterstützt die Vergrößerung der Festplatte auf maximal 2 TB. Die Erweiterung im laufenden Betrieb wird von virtuellen SATA-Festplatten unabhängig von der Größe nicht unterstützt.

    Problemumgehung: Schalten Sie die virtuelle Maschine aus, um die virtuelle Festplatte auf mindestens 2 TB zu vergrößern.

VMware HA- und Fault Tolerance-Probleme
  • Bei der Auswahl eines ESX/ESXi 4.0-/4.1-Hosts in einem vSphere HA-Cluster für das Failover einer virtuellen Maschine wird die virtuelle Maschine möglicherweise nicht wie erwartet neu gestartet.
    Wenn vSphere HA eine virtuelle Maschine auf einem anderen ESX/ESXi 4.0-/4.1-Host als dem ursprünglichen Host neu startet, wird eine Abfrage ausgestellt, die nicht beantwortet wird. Die virtuelle Maschine wird auf dem neuen Host erst eingeschaltet, nachdem Sie die Abfrage manuell im vSphere Client beantwortet haben.

    Problemumgehung: Beantworten Sie die Abfrage im vSphere Client. Sie können eine Zeitüberschreitung (standardmäßig 15 Minuten) abwarten, nach der vSphere HA versucht, die virtuelle Maschine auf einem anderen Host neu zu starten. Wenn der Host ESX/ESXi Version 5.0 oder höher ausführt, wird die virtuelle Maschine neu gestartet.

  • Wenn ein vMotion-Vorgang ohne gemeinsam genutzten Speicher in einem vSphere HA-Cluster fehlschlägt, kann es sein, dass die virtuelle Zielmaschine auf einem unerwarteten Host registriert wird.
    Eine vMotion-Migration ohne gemeinsam genutzten Speicher kann fehlschlagen, weil die virtuelle Zielmaschine keine Handshakenachricht erhält, mit der die Übertragung der Kontrolle zwischen den beiden virtuellen Maschinen koordiniert wird. Das vMotion-Protokoll schaltet die virtuellen Quell- und Zielmaschinen aus. Wenn sich die Quell- und Zielhosts im selben Cluster befinden und vSphere HA aktiviert wurde, kann es vorkommen, dass die virtuelle Zielmaschine von vSphere HA auf einem anderen Host als dem Host, der als Ziel für die vMotion-Migration ausgewählt wurde, registriert wird.

    Problemumgehung: Wenn Sie die virtuelle Zielmaschine beibehalten und auf einem bestimmten Host registrieren möchten, verlagern Sie die virtuelle Zielmaschine auf den Zielhost. Es empfiehlt sich, diese Verlagerung vor dem Einschalten der virtuellen Maschine vorzunehmen.

Probleme bei unterstützter Hardware
  • Sensorwerte für Lüfter, Stromversorgung, Spannung und aktuelle Sensoren werden in der Gruppe "Andere" der Registerkarte "vCenter Server-Hardwarestatus" angezeigt
    Einige Sensorwerte werden in der Gruppe "Andere" anstatt der entsprechenden kategorisierten Gruppe aufgelistet.

    Problemumgehung: Keine.

  • Fehler bei IOMMU (I/O Memory Management Unit) können entstehen, wenn der Debugging-Mapper von DMA (Direct Memory Access) aktiviert ist
    Der Debugging-Mapper platziert Geräte in IOMMU-Domänen, um Arbeitsspeicherzugriffe von Geräten auf Adressen zu erfassen, die nicht explizit zugeordnet sind. Auf einigen Systemen von HP mit alter Firmware können Fehler bei IOMMU entstehen.

    Problemumgehung: Laden Sie Upgrades der Firmware von der HP-Website herunter und installieren Sie sie.

    • Führen Sie ein Upgrade der Firmware des HP iLO2-Controllers durch.
      Die im August 2011 veröffentlichte Version 2.07 löst das Problem.
    • Führen Sie ein Upgrade der Firmware des HP Smart Array durch.
      Die im Januar 2012 veröffentlichte Version 5.14 löst das Problem für das HP Smart Array P410.

Probleme bei VMware Tools

  • VMware Tools kann auf Linux-Gastbetriebssystemen durch Ausführen des Befehls „vmware-install.pl -d“ nicht installiert werden, wenn VMware Tools zuvor nicht installiert wurde*
    Wenn VMware Tools nicht auf Ihrem Linux-Gastbetriebssystem installiert ist, schlagen Versuche, eine Erstinstallation von VMware Tools anhand der Ausführung des Befehls vmware-install.pl -d durchzuführen, möglicherweise fehl.
    Dieses Problem tritt bei den folgenden Gastbetriebssystemen auf:
    • RHEL 7 und höher
    • CentOS 7 und höher
    • Oracle Linux 7 und höher
    • Fedora 19 und höher
    • SLES 12 und höher
    • SLED 12 und höher
    • openSUSE 12.2 und höher
    • Ubuntu 14.04 und höher
    • Debian 7 und höher

    Problemumgehung: Zur Zeit gibt es keine Lösung, damit der -default (-d)-Switch funktioniert. Sie können VMware Tools jedoch ohne den - default-Switch installieren.
    Wählen Sie Ja aus, wenn Sie vom Installationsprogramm mit der Option Möchten Sie dennoch mit diesem älteren Installationsprogramm fortfahren? dazu aufgefordert werden.

    Hinweis: In dieser Version wird ein neuer --force-install’(-f)-Switch zur Installation von VMware Tools eingeführt.
  • Datei ist nach Upgrade von VMware Tools nicht mehr vorhanden
    Die Datei deployPkg.dll in C:\Programme\Vmware\Vmware Tools\ wird nach dem Upgrade von VMware Tools nicht gefunden. Dieser Fall tritt bei einem Upgrade von Version 5.1 Update 2 auf Version 5.5 Update 1 oder höher und von Version 5.5 auf Version 5.5 Update 1 oder höher auf.

    Problemumgehung: Keine
  • Bei der Installation oder Deinstallation von VMware Tools mithilfe der betriebssystemspezifischen Pakete (OSPs) wird der Benutzer zwangsweise abgemeldet
    Bei der Installation oder Deinstallation von VMware Tools-Paketen auf virtuellen Maschinen mit RHEL (Red Hat Linux Enterprise) und CentOS, die mit den betriebssystemspezifischen Paketen installiert wurden, wird der aktuelle Benutzer zwangsweise abgemeldet. Dieses Problem tritt bei virtuellen Maschinen mit RHEL 6.5 64-Bit, RHEL 6.5 32-Bit, CentOS 6.5 64-Bit und CentOS 6.5 32-Bit auf.

    Problemumgehung:
    • Verwenden Sie Secure Shell (SSH) zur Installation oder Deinstallation von VMware Tools.
      oder
    • Der Benutzer muss sich erneut anmelden, um die VMware Tools-Pakete zu installieren oder zu deinstallieren.

Sonstige Probleme

  • SRM-Vorgang zur Testwiederherstellung schlägt möglicherweise mit einem Fehler fehl*
    Versuche, die SRM (Site Recovery Manager)-Testwiederherstellung durchzuführen, schlagen möglicherweise mit einer Fehlermeldung ähnlich der Folgenden fehl:
    'Fehler - Ein allgemeiner Systemfehler ist aufgetreten: VM nicht gefunden'.
    Wenn mehrere Vorgänge zur Testwiederherstellung gleichzeitig ausgeführt werden, nimmt die Wahrscheinlichkeit der Anzeige von Fehlermeldungen zu.

    Problemumgehung: Keine. Dies ist jedoch kein dauerhaftes Problem und es tritt möglicherweise nicht auf, wenn Sie den Vorgang zur SRM-Testwiederherstellung erneut ausführen.