VMware ESXi™ 5.5 Update 1 | 11. März 2014 | Build 1623387

Letzte Aktualisierung: 25. März 2014

Ü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:

  • VMware Virtual SAN Virtual SAN 5.5 ist eine neue Speicherschicht, die mit einem Hypervisor kombiniert ist und vSphere Hypervisor erweitert, um serverseitige Magnetfestplatten (HDDs) und Solid-State-Laufwerke (SSDs) in einem Pool zusammenzufassen. Durch das Clustering von serverseitigen HDDs und SSDs erstellt Virtual SAN einen verteilten, gemeinsam genutzten Datenspeicher, der für virtuelle Umgebungen konzipiert und optimiert ist. Virtual SAN ist ein eigenständiges Produkt, das getrennt von vSphere verkauft wird und einen eigenen Lizenzschlüssel erfordert. 

  • 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 früherer Versionen von ESXi 5.5 finden Sie in den Versionshinweisen für VMware vSphere 5.5.

Internationalisierung

VMware vSphere 5.5 Update 1 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ätmatrix 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.1 bietet Unterstützung für die Versionen ESXi 5.5 Update 1 und vCenter Server 5.5 Update 1.
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 durch, bevor Sie Virtual SAN aktivieren. Auch vCenter Server sollte auf 5.5 Update 1 aktualisiert werden.

Testversionen von Virtual SAN
Ein Upgrade der Virtual SAN-Cluster von Virtual SAN Beta auf Virtual SAN 5.5 wird nicht unterstützt.
Deaktivieren Sie Virtual SAN Beta und führen Sie eine Neuinstallation von Virtual SAN 5.5 für Hosts mit ESXi 5.5 Update 1 aus. Wenn Sie Beta-Versionen von Virtual SAN getestet haben, wird empfohlen, die Daten, die Sie aus diesen Konfigurationen in vSphere 5.5 Update 1 beibehalten möchten, neu zu erstellen. Weitere Informationen finden Sie unter Beibehalten von virtuellen Maschinen eines Virtual SAN Beta-Clusters bei Upgrades auf vSphere 5.5 Update 1 (KB 2074147).

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 1 kompatibel sind, lesen Sie die Informationen zu ESXi 5.5 Update 1 im VMware-Kompatibilitätshandbuch.

Gerätekompatibilität für ESXi

Verwenden Sie die Informationen zu ESXi 5.5 Update 1 im VMware-Kompatibilitätshandbuch, um die Geräte zu ermitteln, die mit ESXi 5.5 Update 1 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 auf ESXi 5.5.x, aber das Gerät wird auf 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 Gastbetriebssystemen für ESXi

Verwenden Sie die Informationen zu ESXi 5.5 Update 1 im VMware-Kompatibilitätshandbuch, um die Gastbetriebssysteme zu ermitteln, die mit vSphere 5.5 Update 1 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 1 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 1 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 Drittanbieter-Lö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 ESXi-Hosts finden Sie im vSphere-Upgrade-Handbuch.

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

Upgrade-Lieferumfang

Unterstützte Upgrade-Tools

Unterstützte Upgrade-Pfade auf ESXi 5.5 Update 1

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

VMware-VMvisor-Installer-5.5.0.update01-1623387.x86_64.iso

 

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

Ja

Ja

Ja

Ja

Ja

update-from-esxi5.5-5.5_update01.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 1 mithilfe von update-from-esxi5.5-5.5_update01.zipwird 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 Thema ESXi 5.5.x Upgrade-Optionen im vSphere-Upgrade-Handbuch.

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

Informationen über Copyright und Lizenzen für die Open Source-Softwarekomponenten, die im Lieferumfang von vSphere 5.5 Update 1 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 zu 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.

Patch-Version ESXi550-Update01 enthält die folgenden einzelnen Bulletins:

ESXi550-201403201-UG: Aktualisiert ESXi 5.5 esx-base vib
ESXi550-201403202-UG: Aktualisiert ESXi 5.5 tools-light vib
ESXi550-201403203-UG: Aktualisiert ESXi 5.5 rste vib
ESXi550-201403204-UG: Aktualisiert ESXi 5.5 net-e1000e vib
ESXi550-201403205-UG: Aktualisiert ESXi 5.5 scsi-mpt2sas vib
ESXi550-201403206-UG: Aktualisiert ESXi 5.5 lsi-msgpt3 vib
ESXi550-201403207-UG: Aktualisiert ESXi 5.5 mtip32xx-native vib
ESXi550-201403208-UG: Aktualisiert ESXi 5.5 sata-ahci vib
ESXi550-201403209-UG: Aktualisiert ESXi 5.5 scsi-megaraid-sas vib
ESXi550-201403210-UG: Aktualisiert ESXi 5.5 net-igb vib
ESXi550-201403211-UG: Aktualisiert ESXi 5.5 net-tg3 vib

Patch-Version ESXi550-Update01 Security-onlyenthält die folgenden einzelnen Bulletins:

ESXi550-201403101-SG: Aktualisiert ESXi 5.5 esx-base vib
ESXi550-201403102-SG: Aktualisiert ESXi 5.5 tools-light vib

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

ESXi-5.5.0-20140302001-standard
ESXi-5.5.0-20140302001-no-tools

Patch-Version ESXi550-Update01 Security-onlyenthält die folgenden Image-Profile:

ESXi-5.5.0-20140301001s-standard
ESXi-5.5.0-20140301001s-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

  • IPMI-Sensordaten können nicht abgefragt werden
    Wenn Sie den Befehl exscli hardware ipmi sdr listausführen, wird möglicherweise für verbrauchte Ressourcen ein Fehler ähnlich dem folgenden angezeigt:
    Keine Datensätze oder inkompatible Version oder Lesen fehlgeschlagen

    Dieses Problem wurde in der vorliegenden Version behoben.
  • vmklinux_9:ipmi_thread von vmkapimod zeigt die CPU-Nutzung als 100% für eine Stunde
    Auf einem ESXi-Host zeigt der mklinux_9:ipmi_thread von vmkapimod beim Lesen der FRU (Field Replaceable Unit)-Inventardaten mithilfe des IPMI (Intelligent Platform Management Interface)-Tools die CPU-Nutzung fälschlicherweise als hundert Prozent an. Dies liegt daran, dass das IPMI-Tool den Befehl "Read FRU Data" mehrere Male dazu verwendet, große Inventardaten zu lesen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Schwache Schlüssel an CIM Port 5989 können nicht deaktiviert werden
    Um zwecks Konformität mit der Payment Card Industry (PCI) die Cipher Block Chaining (CBC)-Algorithmen zu deaktivieren, müssen Sie möglicherweise schwache Schlüssel am CIM Port 5989 deaktivieren. Dies ist nicht zulässig. Sie können die Konfiguration in sfcb.cfgaktualisieren, um schwache Schlüssel zu deaktivieren, indem Sie die folgenden Befehle ausführen:

    # vi /etc/sfcb/sfcb.cfg
    sslCipherList: HIGH:!DES-CBC3-SHA
    # /etc/init.d/sfcbd-watchdog restart

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Das Abfragen von CIM_System mithilfe von EMC PowerPath schlägt fehl
    Wenn PowerPath das CIM_System unter /VMware/esxv2/abfragt, schlägt der Vorgang fehl und der CIM-Server meldet einen Fehler. Der Fehler ähnelt dem folgenden:

    ThreadPool --- Failed to enqueue request. Too many queued requests already: vmwaLINUX
    ThreadPool --- Failed to enqueue request. Too many queued requests already: vmware_base, active 5, queued 11 .\TreeViewHostDiscovery.cpp 611

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Beim Aktualisieren von Sensordaten werden Core-Dumps vom Ethernet-Anbieter beobachtet
    Beim Aktualisieren von Sensordaten auf der Registerkarte "Hardwarestatus" auf einem IBM x3650M3-Server werden SFCB-Core-Dumps (Small Footprint CIM Broker) vom Ethernet-Anbieter beobachtet. Die Registerkarte Hardwarestatus zeigt auch nach mehreren Versuchen keine Daten an.

    Dieses Problem wurde in der vorliegenden Version behoben.

Sonstige Probleme

  • Die RAM-Disk für SNMP-Trap-Dateien wird beim Neustarten des Hosts nicht erstellt
    Die RAM-Disk für SNMP-Traps wird nicht erstellt, wenn der Host neu gestartet wird oder wenn die Verwaltungs-Agenten auf einem ESXi-Host von der Benutzerschnittstelle der direkten Konsole aus neu gestartet werden. Wenn in /var/spool/snmpauf dem ESXi-Host ein Objekt (Verzeichnis, Datei, Link oder anderes Objekt) erstellt wird, wird beim Starten des SNMP-Dienstes die RAM-Disk für SNMP-Traps nicht erstellt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Der VMX-Prozess schlägt möglicherweise mit einer Fehlermeldung fehl, wenn eine virtuelle Maschine ausgeschaltet wird
    Der VMX-Prozess schlägt möglicherweise fehl, wenn Sie versuchen, eine virtuelle Maschine auszuschalten.
    Möglicherweise wird eine Fehlermeldung ähnlich der folgenden in die Datei vmware.loggeschrieben:

    Unerwartetes Signal: 11

    Dieses Problem wurde in der vorliegenden Version behoben.
  • JavaFX-Anwendungselemente werden in einer 3D-fähigen virtuellen Maschine nicht ordnungsgemäß angezeigt
    Wenn 3D in den Einstellungen der virtuellen Maschine aktiviert ist, werden die Komponenten der Benutzerschnittstelle der JavaFX-Anwendung nicht ordnungsgemäß angezeigt.

  • Dieses Problem wurde in der vorliegenden Version behoben.
  • Mehrere virtuelle Festplatten, die in einem virtuellen lsilogic-Adapter konfiguriert sind, reagieren möglicherweise nicht, wenn der Adapter darauf wartet, dass E/A-Vorgänge auf allen verfügbaren Zielen abgeschlossen werden
    Wenn der virtuelle lsilogic-Adapter einen Befehl zum Zurücksetzen eines SCSI-Ziels ausführt, wartet er darauf, dass die E/A-Vorgänge auf allen Zielen, die im virtuellen Adapter verfügbar sind, abgeschlossen werden. Dies kann dazu führen, dass virtuelle Maschinen mit mehreren virtuellen Festplatten, die im virtuellen lsilogic-Adapter konfiguriert sind, nicht mehr reagieren.

    Dieses Problem wurde in der vorliegenden Version behoben.

Netzwerkprobleme

  • VMXNET3-Adapter wird in Windows Server 2008 R2 aufgrund von häufigen Änderungen in RSS zurückgesetzt
    Wenn Receive Side Scaling auf virtuellen Windows-Maschinen mit mehreren vCPUs aktiviert ist, werden NetPort-Meldungen zu sich wiederholenden MAC-Adressen angezeigt, was bedeutet, dass Ports deaktiviert und dann reaktiviert werden. In der Datei vmkernel.logfinden Sie Meldungen ähnlich der folgenden:

    2013-07-08T06:11:58.158Z cpu4:337203)NetPort: 1424: disabled port 0x1000020
    2013-07-08T06:11:58.177Z cpu4:337203)NetPort: 1237: enabled port 0x1000020 with mac 00:50:56:9e:50:24
    2013-07-08T06:12:46.191Z cpu1:337203)NetPort: 1424: disabled port 0x1000020
    2013-07-08T06:12:46.211Z cpu7:337203)NetPort: 1237: enabled port 0x1000020 with mac 00:50:56:9e:50:24

    Die Datei vmware.logvon virtuellen Maschinen, die diese MAC-Adressen verwenden, enthält entsprechende Einträge ähnlich den folgenden:

    2013-07-08T06:18:20.175Z| vcpu-1| Ethernet4 MAC Address: 00:50:56:9e:50:24
    2013-07-08T06:18:20.199Z| vcpu-1| VMXNET3 user: Ethernet4 Driver Info: version = 833450 gosBits = 2 gosType = 2, gosVer = 24848, gosMisc = 212
    2013-07-08T06:18:36.165Z| vcpu-6| Ethernet4 MAC Address: 00:50:56:9e:50:24
    2013-07-08T06:18:36.187Z| vcpu-6| VMXNET3 user: Ethernet4 Driver Info: version = 833450 gosBits = 2 gosType = 2, gosVer = 24848, gosMisc = 212

    Dieses Problem wurde in der vorliegenden Version behoben. Der VMXNET3-Netzwerktreiber wurde in dieser Version aktualisiert.

  • Der ESXi 5.x-Host mit einer virtuellen Maschine, die einen E1000- oder E1000e-virtuellen Adapter verwendet, schlägt mit einem violetten Diagnosebildschirm fehl
    Auf dem ESXi-Host tritt ein violetter Diagnosebildschirm mit Fehlermeldungen für E1000PollRxRing und E1000DevRx, wenn sich der rx-Ring-Puffer füllt und der maximale rx-Ring auf mehr als 2 eingestellt ist. Das nächste empfangene rx-Paket, dass vom zweiten Ring verarbeitet wird, ist NULL, was einen Verarbeitungsfehler verursacht.
    Der violette Diagnosebildschirm zeigt Einträge ähnlich den folgenden:

    @BlueScreen: #PF Exception 14 in world 63406:vmast.63405 IP 0x41801cd9c266 addr 0x0
    PTEs:0x8442d5027;0x383f35027;0x0;
    Code start: 0x41801cc00000 VMK uptime: 1:08:27:56.829
    0x41229eb9b590:[0x41801cd9c266]E1000PollRxRing@vmkernel#nover+0xdb9 stack: 0x410015264580
    0x41229eb9b600:[0x41801cd9fc73]E1000DevRx@vmkernel#nover+0x18a stack: 0x41229eb9b630
    0x41229eb9b6a0:[0x41801cd3ced0]IOChain_Resume@vmkernel#nover+0x247 stack: 0x41229eb9b6e0
    0x41229eb9b6f0:[0x41801cd2c0e4]PortOutput@vmkernel#nover+0xe3 stack: 0x410012375940
    0x41229eb9b750:[0x41801d1e476f]EtherswitchForwardLeafPortsQuick@<None>#<None>+0xd6 stack: 0x31200f9
    0x41229eb9b950:[0x41801d1e5fd8]EtherswitchPortDispatch@<None>#<None>+0x13bb stack: 0x412200000015
    0x41229eb9b9c0:[0x41801cd2b2c7]Port_InputResume@vmkernel#nover+0x146 stack: 0x412445c34cc0
    0x41229eb9ba10:[0x41801cd2ca42]Port_Input_Committed@vmkernel#nover+0x29 stack: 0x41001203aa01
    0x41229eb9ba70:[0x41801cd99a05]E1000DevAsyncTx@vmkernel#nover+0x190 stack: 0x41229eb9bab0
    0x41229eb9bae0:[0x41801cd51813]NetWorldletPerVMCB@vmkernel#nover+0xae stack: 0x2
    0x41229eb9bc60:[0x41801cd0b21b]WorldletProcessQueue@vmkernel#nover+0x486 stack: 0x41229eb9bd10
    0x41229eb9bca0:[0x41801cd0b895]WorldletBHHandler@vmkernel#nover+0x60 stack: 0x10041229eb9bd20
    0x41229eb9bd20:[0x41801cc2083a]BH_Check@vmkernel#nover+0x185 stack: 0x41229eb9be20
    0x41229eb9be20:[0x41801cdbc9bc]CpuSchedIdleLoopInt@vmkernel#nover+0x13b stack: 0x29eb9bfa0
    0x41229eb9bf10:[0x41801cdc4c1f]CpuSchedDispatch@vmkernel#nover+0xabe stack: 0x0
    0x41229eb9bf80:[0x41801cdc5f4f]CpuSchedWait@vmkernel#nover+0x242 stack: 0x412200000000
    0x41229eb9bfa0:[0x41801cdc659e]CpuSched_Wait@vmkernel#nover+0x1d stack: 0x41229eb9bff0
    0x41229eb9bff0:[0x41801ccb1a3a]VmAssistantProcessTask@vmkernel#nover+0x445 stack: 0x0
    0x41229eb9bff8:[0x0]<unknown> stack: 0x0

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Die auf der DCUI angezeigte IP-Adresse ändert sich beim Zurücksetzen, wenn der Verwaltungsdatenverkehr auf mehreren VMkernel-Ports aktiviert ist
    Wenn Sie ein Verwaltungsnetzwerk zurücksetzen, bei dem der Verwaltungsdatenverkehr auf mehreren VMkernel-Ports aktiviert ist, ändert sich die IP-Adresse, die auf der Benutzerschnittstelle der direkten Konsole (DCUI) angezeigt wird.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESXi-Host zeigt einen violetten Diagnosebildschirm mit einem Ausnahme-14-Fehler
    ESXi-Hosts mit DvFilter-Modul zeigen möglicherweise einen violetten Diagnosebildschirm mit einer Rückverfolgung ähnlich der folgenden:

    2013-07-18T06:41:39.699Z cpu12:10669)0x412266b5bbe8:[0x41800d50b532]DVFilterDispatchMessage@com.vmware.vmkapi#v2_1_0_0+0x92d stack: 0x10
    2013-07-18T06:41:39.700Z cpu12:10669)0x412266b5bc68:[0x41800d505521]DVFilterCommBHDispatch@com.vmware.vmkapi#v2_1_0_0+0x394 stack: 0x100
    2013-07-18T06:41:39.700Z cpu12:10669)0x412266b5bce8:[0x41800cc2083a]BH_Check@vmkernel#nover+0x185 stack: 0x412266b5bde8, 0x412266b5bd88,

    Dieses Problem wurde in der vorliegenden Version behoben.

  • ESXi-Hosts schlagen aufgrund der Wettlaufsituationen im ESXi-TCP/IP-Stapel möglicherweise mit einem violetten Bildschirm fehl
    ESXi-Hosts schlagen möglicherweise mit einem violetten Bildschirm fehl und zeigen Fehlermeldungen ähnlich der folgenden an:

    2013-02-22T15:33:14.296Z cpu8:4104)@BlueScreen: #PF Exception 14 in world 4104:idle8 IP 0x4180083e796b addr 0x1
    2013-02-22T15:33:14.296Z cpu8:4104)Code start: 0x418007c00000 VMK uptime: 58:11:48:48.394
    2013-02-22T15:33:14.298Z cpu8:4104)0x412200207778:[0x4180083e796b]ether_output@<None>#<None>+0x4e stack: 0x41000d44f360
    2013-02-22T15:33:14.299Z cpu8:4104)0x4122002078b8:[0x4180083f759d]arpintr@<None>#<None>+0xa9c stack: 0x4100241a4e00

    Dieses Problem tritt aufgrund von Wettlaufsituationen im ESXi-TCP/IP-Stapel auf.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Intel e1000e-Netzwerkschnittstellentreiber reagiert möglicherweise nicht mehr auf empfangenen (RX) Datenverkehr
    Der Intel e1000e-Netzwerkschnittstellentreiber reagiert möglicherweise nicht mehr auf empfangenen (RX) Datenverkehr.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • ESXi-Hosts schlagen möglicherweise mit einem violetten Diagnosebildschirm fehl, wenn die Funktion für die Netzwerk-Systemstatusprüfung aktiviert ist
    Wenn die Funktion für die Netzwerk-Systemstatusprüfung aktiviert ist und zahlreiche Systemstatusprüfungspakete verarbeitet, kann die L2Echo-Funktion möglicherweise hohen Netzwerk-Datenverkehr nicht verarbeiten, und die ESXi-Hosts schlagen möglicherweise mit einem violetten Diagnosebildschirm und Meldungen ähnlich den folgenden fehl:

    2013-06-27T10:19:16.074Z cpu4:8196)@BlueScreen: PCPU 1: no heartbeat (2/2 IPIs received)
    2013-06-27T10:19:16.074Z cpu4:8196)Code start: 0x418024600000 VMK uptime: 44:20:54:02.516
    2013-06-27T10:19:16.075Z cpu4:8196)Saved backtrace from: pcpu 1 Heartbeat NMI
    2013-06-27T10:19:16.076Z cpu4:8196)0x41220781b480:[0x41802468ded2]SP_WaitLockIRQ@vmkernel#nover+0x199 stack: 0x3b
    2013-06-27T10:19:16.077Z cpu4:8196)0x41220781b4a0:[0x4180247f0253]Sched_TreeLockMemAdmit@vmkernel#nover+0x5e stack: 0x20
    2013-06-27T10:19:16.079Z cpu4:8196)0x41220781b4c0:[0x4180247d0100]MemSched_ConsumeManagedKernelMemory@vmkernel#nover+0x1b stack: 0x0
    2013-06-27T10:19:16.080Z cpu4:8196)0x41220781b500:[0x418024806ac5]SchedKmem_Alloc@vmkernel#nover+0x40 stack: 0x41220781b690...
    2013-06-27T10:19:16.102Z cpu4:8196)0x41220781bbb0:[0x4180247a0b13]vmk_PortOutput@vmkernel#nover+0x4a stack: 0x100
    2013-06-27T10:19:16.104Z cpu4:8196)0x41220781bc20:[0x418024c65fb2]L2EchoSendPkt@com.vmware.net.healthchk#1.0.0.0+0x85 stack: 0x4100000
    2013-06-27T10:19:16.105Z cpu4:8196)0x41220781bcf0:[0x418024c6648e]L2EchoSendPort@com.vmware.net.healthchk#1.0.0.0+0x4b1 stack: 0x0
    2013-06-27T10:19:16.107Z cpu4:8196)0x41220781bfa0:[0x418024c685d9]L2EchoRxWorldFn@com.vmware.net.healthchk#1.0.0.0+0x7f8 stack: 0x4122
    2013-06-27T10:19:16.108Z cpu4:8196)0x41220781bff0:[0x4180246b6c8f]vmkWorldFunc@vmkernel#nover+0x52 stack: 0x0


    Dieses Problem wurde in der vorliegenden Version behoben.
  • Nicht verwendete vSphere Distributed Switch (VDS)-Ports werden nicht aus dem .dvsData-Verzeichnis in den Datenspeichern gelöscht
    Während der Ausführung von vMotion auf einer virtuellen Maschine, deren vNIC mit dem VDS verbunden ist, werden Port-Dateien vom vMotion-Quellhost auch nicht nach einiger Zeit aus dem .dvsData-Verzeichnis gelöscht.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Die Rückgabewerte von net.throughput.usage im vCenter-Leistungsdiagramm und VMkernel widersprechen sich
    Im vCenter-Leistungsdiagramm ist der mit "net.throughput.usage" verbundene Wert in Kilobyte angegeben, aber derselbe Wert wird in VMkernel in Byte angegeben. Das führt zu einer falschen Wiedergabe der Werte im vCenter-Leistungsdiagramm.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • TSO-Funktion (TCP-Segmentierungs-Offload) von tg3-Netzwerkkarten führt möglicherweise zu einem Fehlschlagen der ESXi-Hosts
    Wenn die TSO-Funktion im tg3-Treiber aktiviert ist, werden die Daten, die über die tg3-Netzwerkkarten übertragen werden, möglicherweise beschädigt.

    Dieses Problem wurde in der vorliegenden Version behoben. Die TSO-Funktion ist für tg3-Netzwerkkarten deaktiviert.
  • Das Verwerfen von Netzwerkpaketen wird in esxtop zwischen zwei virtuellen Maschinen auf dem gleichen ESXi-Host und vSwitch nicht korrekt berichtet
    Wenn zwei virtuelle Maschinen mit dem e1000-Treiber auf dem gleichen vSwitch auf einem Host konfiguriert werden, dann berichtet der Netzwerkwerkdatenverkehr zwischen den zwei virtuellen Maschinen möglicherweise beträchtliche Mengen an verworfenen Paketen in esxtop. Dies geschieht, da aufgeteilte Pakete beim Berichten nicht berücksichtigt wurden, wenn TSO vom Gast aus aktiviert wird.

    Dieses Problem wurde in der vorliegenden Version behoben. Der VMXNET3-Netzwerktreiber wurde in dieser Version aktualisiert.

Sicherheitsprobleme

  • Aktualisierung von libxslt
    Das libxslt-Userworld-Paket von ESXi wurde aktualisiert.
  • Aktualisierung des NTP-Daemons
    Der NTP-Daemon wurde aktualisiert, um ein Sicherheitsproblem zu beheben.
    Im Projekt "Common Vulnerabilities and Exposures" (cve.mitre.org) wurde diesem Problem die Bezeichnung CVE-2013-5211 zugewiesen.
    Hinweis: Eine Umgehung für dieses Problem wird in KB 2070193 dokumentiert.
  • Aktualisierung der glibc-Pakete
    Das ESXi glibc-2.5-Paket wurde aktualisiert, um ein Sicherheitsproblem zu beheben.
    Der Standard "Common Vulnerabilities and Exposures" (CVE) (cve.mitre.org) hat diesem Problem den Namen CVE-2013-4332 zugewiesen.

Serverkonfigurationsprobleme

  • esxtop-Befehlszeilentool meldet inkonsistente CPU-Nutzung  
    Auf Maschinen mit aktiviertem Hyper-Threading verdoppelt sich die CPU-Kernauslastung des vSphere Client im Vergleich zu dem Wert der esxtop-Kernauslastung.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • Falsche Einheit beim Befehl esxcli network nic coalesce get
    Die bei Ausführung des Befehls esxcli network nic coalesce getempfangene Einheit ist Millisekunden. Die richtige Einheit ist Mikrosekunden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Kein Zugriff auf den VMFS-Datenspeicher oder auf einige Dateien
    Möglicherweise fehlt der VMFS-Datenspeicher in der Registerkarte Datenspeicher von vCenter Server, oder in der Registerkarte Ereignisse wird ein Ereignis ähnlich dem folgenden angezeigt:

    XXX esx.problem.vmfs.lock.corruptondisk.v2 XXX or At least one corrupt on-disk lock was detected on volume {1} ({2}). Other regions of the volume might be damaged too.

    Die folgende Meldung ist in der Datei vmkernel.logprotokolliert:

    [lockAddr 36149248] Invalid state: Owner 00000000-00000000-0000-000000000000 mode 0 numHolders 0 gblNumHolders 4294967295ESC[7m2013-05-12T19:49:11.617Z cpu16:372715)WARNING: DLX: 908: Volume 4e15b3f1-d166c8f8-9bbd-14feb5c781cf ("XXXXXXXXX") might be damaged on the disk. Corrupt lock detected at offset 2279800: [type 10c00001 offset 36149248 v 6231, hb offset 372ESC[0$

    Möglicherweise erscheint in der Protokolldatei vmkernel.logauch die folgende Fehlermeldung:

    2013-07-24T05:00:43.171Z cpu13:11547)WARNING: Vol3: ValidateFS:2267: XXXXXX/51c27b20-4974c2d8-edad-b8ac6f8710c7: Non-zero generation of VMFS3 volume: 1

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Lokale ESXi-Festplatten stehen nach der Installation von EMC PowerPath auf einem HP-Server nicht zur Verfügung
    Nach der Installation von EMC PowerPath werden lokale Datenspeicher von keinem Mehrfachpfad-Plug-In (MPP) beansprucht. Wenn die Beanspruchungsregeln ausgeführt werden und ein Pfad mit der Beanspruchungsregel übereinstimmt, wird dieser Pfad dem MPP angeboten. Wenn in vSphere 5.1 das MPP einen Fehler zurückgibt, wird dieser Pfad mit anderen Beanspruchungsregeln abgeglichen. Falls es eine Übereinstimmung gibt, wird der Pfad in diesen Beanspruchungsregeln dem MPP angeboten. Wenn der Pfad von keinem MPP beansprucht wird, wird er aufgrund der Beanspruchungsregel für alle anderen Fälle NMP angeboten.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Der ESXi-Host zeigt einen violetten Diagnosebildschirm mit einem Fehler
    Während eines VMkernel System Information (VSI)-Aufrufs vom userworld-Programm ps tritt im VMkernel ein Fehler auf, wenn die zum Kernel gesendete Instanzenliste beschädigt ist. Dieses Problem tritt auf, wenn numParamszu hoch ist und der Kernel versucht, auf das Array dieses Index zuzugreifen. Es wird ein violetter Diagnosebildschirm mit einer Rückverfolgung ähnlich der folgenden angezeigt:

    2013-09-06T00:35:49.995Z cpu11:148536)@BlueScreen: #PF Exception 14 in world 148536:ps IP 0x418004b31a34 addr 0x410019463308

    PTEs:0x4064ffe023;0x2080001023;0x100065023;0x0;

    2013-09-06T00:35:49.996Z cpu11:148536)Code start: 0x418004800000 VMK uptime: 2:11:35:53.448
    2013-09-06T00:35:49.996Z cpu11:148536)0x412250e1bd80:[0x418004b31a34]VSIVerifyInstanceArgs@vmkernel#nover+0xf3 stack: 0x410009979570
    2013-09-06T00:35:49.997Z cpu11:148536)0x412250e1bdd0:[0x418004b31bbb]VSI_CheckValidLeaf@vmkernel#nover+0xca stack: 0x8c8
    2013-09-06T00:35:49.998Z cpu11:148536)0x412250e1be40:[0x418004b32222]VSI_GetInfo@vmkernel#nover+0xb1 stack: 0x4100194612c0
    2013-09-06T00:35:49.999Z cpu11:148536)0x412250e1beb0:[0x418004ca7f31]UWVMKSyscallUnpackVSI_Get@<None>#<None>+0x244 stack: 0x412250e27000
    2013-09-06T00:35:50.000Z cpu11:148536)0x412250e1bef0:[0x418004c79348]User_UWVMKSyscallHandler@<None>#<None>+0xa3 stack: 0x0
    2013-09-06T00:35:50.001Z cpu11:148536)0x412250e1bf10:[0x4180048a8672]User_UWVMKSyscallHandler@vmkernel#nover+0x19 stack: 0xffea48d8
    2013-09-06T00:35:50.001Z cpu11:148536)0x412250e1bf20:[0x418004910064]gate_entry@vmkernel#nover+0x63 stack: 0x0
    2013-09-06T00:35:50.004Z cpu11:148536)base fs=0x0 gs=0x418042c00000 Kgs=0x0

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Der ESXi-Host reagiert nicht mehr und trennt die Verbindung zu vCenter Server
    Der ESXi-Host reagiert nicht mehr und trennt die Verbindung zu vCenter Server. Außerdem funktionieren die DCUI- und SSH-Anmeldungen auf dem Host aufgrund eines Arbeitsspeicherverlusts in lsassd, verursacht durch Offline-Domänen in der Active Directory-Umgebung, nicht mehr.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Zulassen, dass virtuelle Maschinen die physische Seriennummer von Hosts anzeigen
    Virtuelle Maschinen können die Seriennummern physischer ESXi-Hosts nicht angeben.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESXi-Host zeigt falsche Werte für den resourceCpuAllocMax-Systemindikator
    Wenn Sie versuchen, den Wert für die Systemindikatoren resourceCpuAllocMax und resourceMemAllocMax für das Hostsystem abzurufen, gibt der ESX-Host falsche Werte zurück. Dieses Problem tritt auf, wenn der vSphere Client mit vCenter Server verbunden ist.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Die Geschwindigkeit von Fibre-Channel-HBAs (Hostbusadaptern) wird falsch angezeigt
    Die Geschwindigkeit von Fibre-Channel-HBAs (Hostbusadaptern) wird für einige ESXi-Hosts im Managed Object Browser (MOB) immer fälschlicherweise als null angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Mehrere ESXi-Hosts antworten möglicherweise in vCenter Server nicht mehr
    Wenn zahlreiche parallele HTTP GET /folder-URL-Anfragen an hostd gesendet werden, schlägt der hostd-Dienst fehl. So wird verhindert, dass der Host wieder dem vCenter Server hinzugefügt wird. Möglicherweise wird folgende Fehlermeldung angezeigt:
     
    Der Zugriff auf den angegebenen Host ist nicht möglich, er ist nicht vorhanden, die Serversoftware reagiert nicht, oder es liegt ein Netzwerkproblem vor.
     
    Dieses Problem wurde in der vorliegenden Version behoben.
  • Virtuelle Maschinen mit einer Hardwareversion vor 10 können keine Verbindung zum NVS-Netzwerk herstellen
    Virtuelle Maschinen mit einer Hardwareversion vor 10 können keine Verbindung zum NVS-Netzwerk (NSX Virtual Switch) herstellen. Virtuelle Maschinen mit der Hardwareversion 4 oder höher können jedoch eine Verbindung zum NVS-Netzwerk herstellen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Hostd schlägt fehl und erzeugt hostd-worker-Dump
    Nachdem Sie eine iSCSI-Festplatte entfernt haben, die mit vmknic auf vDS verbunden ist, erzeugt der ESXi 5.5-Host möglicherweise einen hostd-worker-Dump. Dieses Problem tritt auf, wenn Sie versuchen, die aktuellen Informationen vom Host abzurufen.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Das Entfernen einer gemeinsam genutzten, nicht dauerhaften Festplatte im laufenden Betrieb dauert länger, wenn die Festplatte an eine andere eingeschaltete VM angeschlossen ist oder mit dieser gemeinsam genutzt wird
    Wenn Sie einer virtuellen Maschine eine gemeinsam genutzte, nicht dauerhafte, schreibgeschützte Festplatte hinzufügen, benötigt die virtuelle Maschine für das Entfernen der Festplatte möglichweise mehr Zeit.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Beim Bereitstellen und Anpassen einer virtuellen Maschine geht möglicherweise die Netzwerkverbindung verloren
    Wenn Sie eine virtuelle Maschine mithilfe einer Vorlage auf einer vDS mit Ephemeral Ports bereitstellen und anpassen, kann die virtuelle Maschine möglicherweise die Verbindung zum Netzwerk verlieren.

    Möglicherweise wird eine Fehlermeldung ähnlich der folgenden in die Protokolldateien geschrieben:

    2013-08-05T06:33:33.990Z| vcpu-1| VMXNET3 user: Ethernet1 Driver Info: version = 16847360 gosBits = 2 gosType = 1, gosVer = 0, gosMisc = 0
    2013-08-05T06:33:35.679Z| vmx| Msg_Post: Error
    2013-08-05T06:33:35.679Z| vmx| [msg.mac.cantGetPortID] Unable to get dvs.portId for ethernet0
    2013-08-05T06:33:35.679Z| vmx| [msg.mac.cantGetNetworkName] Unable to get networkName or devName for ethernet0
    2013-08-05T06:33:35.679Z| vmx| [msg.device.badconnect] Failed to connect virtual device Ethernet0.
    2013-08-05T06:33:35.679Z| vmx|

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Im ESXi-Host werden Trap-Dateien erstellt, wenn der SNMP-Agent gestoppt wird
    Das Simple Network Management Protocol (SNMP) erstellt im Ordner /var/spool/snmpdes ESXi-Hosts Trap-Dateien ( .trp), wenn der SNMP-Agent gestoppt wird. Wenn das Verzeichnis /var/spool/snmpbeim Stoppen des SNMP-Agenten nicht erfolgreich gelöscht wird, schreibt hostd Trap-Dateien (.trp) in /var/spool/snmp. Dies hat zur Folge, dass dem Host keine Inodes mehr zur Verfügung stehen, wodurch der Host in vCenter Server als nicht verbunden angezeigt wird. Sie können dann möglicherweise keine Aufgaben mehr auf dem Host ausführen.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • GuestNicInfo fehlt für eine eingeschaltete virtuelle Maschine auf einem von Preboot Execution Environment (PXE) gestarteten Host
    GuestNicInfo und GuestStackInfo stehen auf einer eingeschalteten virtuellen Maschine nicht zur Verfügung, wenn VMware Tools installiert ist und ausgeführt wird.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Das Ausführen von ESXCLI-Befehlen oder das Verwenden von Überwachungstools, die auf den SNMP-Agenten angewiesen sind, führen möglicherweise zu einem Verbindungsverlust mit dem ESXi-Host
    Wenn Sie ESXCLI-Befehle ausführen oder Überwachungstools verwenden, die auf Daten vom SNMP-Agenten in ESXi angewiesen sind, geht die Verbindung zum ESXi-Host möglicherweise aufgrund des Ausfalls des hostd-Dienstes verloren.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Die Optionen bandwidthCap und throughputCap eines ESXi-Hosts funktionieren auf einem Gastbetriebssystem möglicherweise nicht
    Auf einem ESXi-Host funktioniert die E/A-Throttling-Option möglicherweise nicht auf virtuellen Maschinen, wenn die Grenzwerte bandwidthCap und throughputCap gleichzeitig gesetzt werden. Dies geschieht durch inkorrekte logische Vergleiche während der Einstellung der Throttle-Option im SCSI-Scheduler.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • SNMP-Traps werden auf Hosts, auf denen SNMP aktiviert ist und CIM-Provider von Drittanbietern auf dem Server installiert sind, nicht empfangen
    Wenn der überwachte Hardware-Status auf einem ESXi-Host geändert wird, auf dem SNMP aktiviert ist und CIM-Provider von Drittanbietern installiert sind, empfangen Sie möglicherweise keine SNMP-Traps. Meldungen ähnlich den folgenden werden in der Datei syslogprotokolliert:

    2013-07-11T05:24:39Z snmpd: to_sr_type: unable to convert varbind type '71'
    2013-07-11T05:24:39Z snmpd: convert_value: unknown SR type value
    02013-07-11T05:24:39Z snmpd: parse_varbind: invalid varbind with type 0 and value: '2'
    2013-07-11T05:24:39Z snmpd: forward_notifications: parse file '/var/spool/snmp/1373520279_6_1_3582.trp' failed, ignored

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Hostd schlägt bei dem Versuch fehl, die CPU-ID-Maske auf einer virtuellen Maschine zurückzusetzen
    Beim Versuch, die CPU-ID-Maske auf einer virtuellen Maschine zurückzusetzen, stürzt hostd ab, wenn der Wert von SetRegisterInfoNULL oder eine leere Zeichenfolge ist.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • ESXi-Installation schlägt mit einem 'UnboundLocalError'-Fehler fehl
    Die ESXi-Installation schlägt mit folgendem Fehler fehl: "UnboundLocalError: local variable 'isLocalOnlyAdapter' referenced before assignment"

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Hostprofil kann das Network Attached Storage (NAS)-Profil zwischenzeitlich nicht anwenden
    Der Host kann NasStorageProfilenicht anwenden und ist nicht in der Lage, während des Anwendungsfehlers den Wartungsmodus zu verlassen.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Versuche, ein komplexes Hostprofil anzuwenden, führen möglicherweise zu einer Zeitüberschreitung
    Wenn Sie ein komplexes Hostprofil wie beispielsweise ein Profil mit einer großen Anzahl von Portgruppen und Datenspeichern anwenden, tritt bei dem Vorgang möglicherweise eine Zeitüberschreitung mit einer Fehlermeldung ähnlich der folgenden auf:

    2013-04-09T15:27:38.562Z [4048CB90 info 'Default' opID=12DA4C3C-0000057F-ee] [VpxLRO] -- ERROR task-302 -- -- vim.profile.host.profileEngine.HostProfileManager.applyHostConfig:

    vmodl.fault.SystemError:
    --> Result:
    --> (vmodl.fault.SystemError) {
    --> dynamicType = ,
    --> faultCause = (vmodl.MethodFault) null,
    --> reason = "",
    --> msg = "Ein allgemeiner Systemfehler ist aufgetreten: ",
    --> }

    Die standardmäßige hostd-Zeitüberschreitung beträgt 10 Minuten. Da applyHostConfig keine progressive Aufgabe ist, kann der hostd-Dienst während der hostd-Zeitüberschreitung nicht zwischen einer fehlgeschlagenen Aufgabe und einer Aufgabe mit langer Ausführungsdauer unterscheiden. Infolgedessen meldet der hostd-Dienst, dass applyHostConfig fehlgeschlagen ist.

    Dieses Problem wurde in der vorliegenden Version durch das Installieren einer 30-minütigen Zeitüberschreitung als Teil des verwalteten HostProfileManager-Objekts behoben. Dieses Problem tritt möglicherweise immer noch auf, wenn Sie versuchen, ein großes Hostprofil anzuwenden, und die Aufgabe überschreitet möglicherweise die Zeitgrenze von 30 Minuten. Um dieses Problem zu umgehen, wenden Sie das Hostprofil erneut an.

    Hinweis: Der tatsächliche Auslöser für die Zeitüberschreitung richtet sich nach der Komplexität des Hostprofils.
  • Der VMKernel schlägt fehl, wenn eine VM-Überwachungsfunktion eine ungültige Maschinen-Seitenzahl zurückgibt
    Wenn VMX einen VPN-Wert zum Lesen einer Seite weiterleitet, findet VMKernel keine gültige Maschinen-Seitenzahl für diesen VPN-Wert. Dies führt dazu, dass der Host mit einem violetten Diagnosebildschirm fehlschlägt.

    Dieses Problem wurde in der vorliegenden Version behoben.

Speicherprobleme

  • Die Werte der esxtop-Leistungsdaten werden möglicherweise als 0 ausgegeben
    Wenn die Ausgabe der esxtop-Leistungsdaten in eine Datei im CSV-Format umgeleitet wird, ändern sich die Werte in esxtop.csv, die im Batch-Modus erfasst wurden, möglicherweise auf 0. In der Datei esxtop.csvwerden E/A-Werte möglicherweise wie folgt angezeigt:

    "09/04/2013 22:00:00","1251.43","4.89","7.12","1839.62","7.19","4.99","1273.05","4.97","7.08""09/04/2013
    22:00:10","1283.92","5.02","7.06","1875.14","7.32","4.89","1290.37","5.04","7.07""09/04/2013
    22:00:20","1286.49","5.03","7.03","1914.86","7.48","4.87","1320.55","5.16","6.90""09/04/2013
    22:00:31","1222.56","4.78","7.44","1775.23","6.93","5.21","1253.87","4.90","7.28""09/04/2013
    22:00:41","1269.87","4.96","7.15","1847.40","7.22","4.97","1267.62","4.95","7.13""09/04/2013
    22:00:51","1291.36","5.04","7.05","1857.97","7.26","4.96","1289.40","5.04","7.08""09/04/2013
    22:01:01","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00""09/04/2013
    22:01:11","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00""09/04/2013
    22:01:22","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00""09/04/2013
    22:01:32","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00""09/04/2013 22:01:42","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00"


    Dieses Problem tritt auf, wenn ungültige vSCSI-Meldungen standardmäßig auf Wahranstatt auf Falschfestgelegt werden.

    Dieses Problem wurde in der vorliegenden Version behoben.

Virtual SAN-Probleme

  • Sie können Speicherfestplatten, die vom Advance Host Controller Interface (AHCI)-Treiber beansprucht werden, nicht im laufenden Betrieb trennen, wenn die Festplatten Teil einer Virtual SAN-Festplattengruppe sind
    Der AHCI-Treiber beansprucht Daten oder SSD-Speicherfestplatten, die mit SATA-Ports auf der Hauptplatine oder über AHCI-fähige Speicheradapter verbunden sind. Falls die Festplatten vom AHCI-Treiber beansprucht werden und Teil einer Virtual SAN-Festplattengruppe sind, können Sie sie im laufenden Betrieb nicht vom ESXi-Host trennen. Falls Sie dies dennoch tun, erkennt der Host die Festplatten nicht mehr, wenn Sie sie wieder anzuschließen versuchen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Beim Trennen einer SSD-Festplatte im laufenden Betrieb tritt auf dem ESXi-Host möglicherweise ein Fehler auf.
    Wenn Sie versuchen, eine SSD-Festplatte im laufenden Betrieb zu trennen, stürzt Ihr ESXi-Host möglicherweise ab und fällt aus.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Virtual SAN erkennt die Festplatte möglicherweise nicht, die Sie im laufenden Betrieb trennen und wieder anschließen möchten
    Wenn Sie versuchen, eine SSD- oder Nicht-SSD-Festplatte im laufenden Betrieb zu trennen, ist Virtual SAN möglicherweise nicht in der Lage, die Festplatte nach dem Wiederanschließen im laufenden Betrieb zu erkennen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • ESXi-Host bildet einen Einzelknoten-Cluster und kann nicht zu einem vorhandenen Virtual SAN-Cluster hinzugefügt werden
    Dies tritt auf, wenn eine für Virtual SAN konfigurierte vmknic bei aktiviertem Virtual SAN über keine IP-Adresse verfügt. Falls hostd noch nicht gestartet wurde, wenn einer für Virtual SAN konfigurierten vmknic eine IP-Adresse zugewiesen wird, bildet der Host möglicherweise einen Einzelknoten-Cluster.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Ein Knoten kann mit der Option Alle Daten verlagernnicht in den Wartungsmodus versetzt werden, wenn aktuell mehr als 70 Prozent der Kapazität des Virtual SAN-Clusters genutzt wird
    Dies tritt auf, wenn das Entfernen eines Knotens aus dem Cluster dazu führt, dass die Kapazitätsnutzung des Virtual SAN-Clusters einen Wert von mehr als 70 Prozent aufweist. Die Clusterkapazität bezieht sich auf den Speicherplatz im Virtual SAN-Cluster.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Beim Klonen einer virtuellen Maschine mit einer Speicherrichtlinie wird die Speicherrichtlinie immer an die virtuelle Zielmaschine übertragen, selbst wenn Sie sie nicht benötigen.
    Wenn Sie eine virtuelle Maschine klonen, die einer Speicherrichtlinie unterliegt, und auswählen, dass die Speicherrichtlinie nicht der virtuellen Zielmaschine zugewiesen werden soll, verläuft der Klonvorgang erfolgreich. Allerdings wird die Speicherrichtlinie der ursprünglichen virtuellen Maschine für die Konfiguration der virtuellen Zielmaschine verwendet. Als Folge davon verwendet die virtuelle Zielmaschine möglicherweise unbeabsichtigt zusätzliche Ressourcen auf dem Virtual SAN-Datenspeicher.

    Dieses Problem wurde in der vorliegenden Version behoben.

Probleme bei vCenter Server und beim vSphere Web Client

  • Die Leistungsstatistik-Berechnung des Durchsatzes der virtuellen Festplatte ist möglicherweise mit einem Faktor von 1024 fehlerhaft
    Bei der Leistungsstatistik-Berechnung wird der Durchsatz der virtuellen Festplatte fälschlicherweise in Byte pro Sekunde gemessen.

    Dieses Problem wurde in der vorliegenden Version behoben, indem die Maßeinheit in Kilobyte pro Sekunde geändert wurde.

VM-Verwaltungsprobleme

  • Virtuelle Maschine kann nicht von einer CD oder DVD gestartet werden, wenn die Legacy-Diskette im BIOS deaktiviert ist
    Die virtuelle Maschine kann möglicherweise nicht gestartet werden, wenn die Legacy-Diskette im BIOS deaktiviert ist. Dieses Problem tritt auf, wenn Sie die folgenden Schritte ausführen:
    1. Erstellen Sie eine virtuelle Maschine ohne Betriebssystem.
    2. Verwenden Sie die Einstellungen für virtuelle Maschine, um die CD oder DVD so zu konfigurieren, dass zur Installation des Gastbetriebssystems eine Verbindung mit einer ISO-Image-Datei oder mit einem physischen Laufwerk hergestellt wird.
    3. Deaktivieren Sie die Legacy-Diskette im BIOS.
    Nach dem Deaktivieren der Legacy-Diskette im BIOS gibt die virtuelle Maschine zwei akustische Signaltöne aus und kann nicht gestartet werden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Versuche, eine virtuelle Maschine als OVF zu exportieren, schlagen mit einem Zeitüberschreitungsfehler fehl
    Wenn Sie versuchen, eine virtuelle Maschine in das Open Virtualization Format (OVF) zu exportieren, und die virtuelle Maschine ein Ext 2- oder Ext 3-Dateisystem verwendet und große Bereiche an leeren Blöcken auf der Festplatte hat, beispielsweise eine leere sekundäre Festplatte mit 210 GB und höher, meldet der Vorgang eine Zeitüberschreitung.

    Dieses Problem wurde in der vorliegenden Version behoben.

VMware HA- und Fault Tolerance-Probleme

  • Der Versuch einer HA-Konfiguration schlägt möglicherweise fehl und eine Fehlermeldung weist darauf hin, dass der HA-Master-Agent nicht gefunden wurde
    High Availability (HA) kann möglicherweise nicht konfiguriert werden. Möglicherweise werden Fehlermeldungen ähnlich der folgenden in die Protokolldatei vpxd.loggeschrieben:

    vpxd-1967.log:2013-04-06T01:35:02.156+09:00 [07220 warning 'DAS'] [FdmManager::ReportMasterChange] VC couldn't find a master for cluster HA_GD for 120 seconds
    vpxd-1968.log:2013-04-06T05:02:55.991+09:00 [07320 warning 'DAS'] [FdmManager::ReportMasterChange] VC couldn't find a master for cluster HA_ID for 120 seconds


    Dieses Problem tritt auf, wenn die hostd-Funktion über keine Sitzungen mehr verfügt. Fehlermeldungen ähnlich der folgenden werden in die Protokolldatei hostd.loggeschrieben:

    SOAP session count limit reached.

    Dieses Problem wurde in der vorliegenden Version behoben.

Upgrade- und Installationsprobleme

  • ESXi-Installation schlägt mit einem UnboundLocalError-Fehler fehl
    Die ESXi-Installation schlägt mit folgendem Fehler fehl: UnboundLocalError: local variable 'isLocalOnlyAdapter' referenced before assignment

    Dieses Problem wurde in der vorliegenden Version behoben.

Probleme bei VMware Tools

  • Beim Versuch, die Registrierung des VSS-Treibers aufzuheben, zeigt der vCenter-Schutzagent während der Aktualisierung von VMware Tools möglicherweise eine Warnmeldung an
    Wenn Sie versuchen, VMware Tools auf einem Windows-Gastbetriebssystem mit einem VMware Tools-Build zu aktualisieren, der eine nicht signierte Datei comreg.exehat, und dabei die Registrierung des VSS-Treibers aufheben, zeigt der vCenter-Schutzagent möglicherweise eine Warnmeldung ähnlich der folgenden an:

    Die Ausführung von comreg.exe wurde versucht

    Dieses Problem wurde in der vorliegenden Version behoben, indem eine Datei comreg.exemit VMware-Signatur hinzugefügt wurde.
  • Microsoft Office kann Dateien nicht in einem freigegebenen Verzeichnis speichern
    Wenn Sie Dateien von einer Microsoft Office 2007- oder Microsoft Office 2010-Anwendung in einem gemeinsam genutzten Verzeichnis auf einer virtuellen Maschine speichern möchten, die von VMware vShield Endpoint und einer Virenschutzlösung ohne Agent geschützt wird, werden Fehler ähnlich der folgenden angezeigt:

    Datei ist zurzeit in Gebrauch. Wiederholen Sie den Vorgang später.
    Die Datei kann nicht an diesem Speicherort gespeichert werden.

    Die in einer Freigabe gespeicherten Dateien sind leer und 0 KB groß.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Fehler beim Aktualisieren von VMware Tools auf RHEL 6.2
    Ein Fehler ähnlich dem folgenden wird möglicherweise angezeigt, wenn Sie auf einer virtuellen Maschine mit RHEL 6.2 (Red Hat Linux Enterprise) versuchen, mithilfe des RPM (Red Hat Package Manager) ein Update einer früheren Version von VMware Tools auf die Version 9.0.5 durchzuführen:

    Fehler: Paket: kmod-vmware-tools-vsock-9.3.3.0-2.6.32.71.el6.x86_64.3.x86_64 (RHEL6-isv)
    Benötigt: vmware-tools-vsock-common = 9.0.1
    Installiert: vmware-tools-vsock-common-9.0.5-1.el6.x86_64 (@/vmware-tools-vsock-common-9.0.5-1.el6.x86_64)
    vmware-tools-vsock-common = 9.0.5-1.el6
    Verfügbar: vmware-tools-vsock-common-8.6.10-1.el6.x86_64 (RHEL6-isv)
    vmware-tools-vsock-common = 8.6.10-1.el6
    Verfügbar: vmware-tools-vsock-common-9.0.1-3.x86_64 (RHEL6-isv)
    vmware-tools-vsock-common = 9.0.1-3

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Beim Abrufen von Informationen zur virtuellen Maschine mithilfe des Arguments --cmd schlägt der VMware Tools-Dienst fehl
    Wenn Sie eine vmtoolsd-Abfrage wie beispielsweise vmtoolsd --cmd "info-get guestinfo.ovfEnv"ausführen, schlägt der VMware Tools-Dienst möglicherweise fehl. Dieses Problem tritt bei den VMware Tools-Versionen 9.0.1 und 9.0.5 auf.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Vorgefertigte Kernel-Module fehlen für Oracle Linux 5.x
    VMware Tools wurde aktualisiert, damit für Oracle Linux 5.x vorgefertigte Kernel-Module des Typs 2.6.39-200/400zur Verfügung stehen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Installation von VMware Tools mithilfe der betriebssystemspezifischen Pakete (OSPs) führt zu einem Anstieg der Anzahl der vmware-db.pl*-Dateien im Verzeichnis /tmp/vmware-root
    Wenn Sie VMware Tools unter Verwendung der betriebssystemspezifischen Pakete installieren, führt dies zu einem Anstieg der Anzahl der Protokolldateien im Verzeichnis /tmp/vmware-root. Dieses Problem tritt bei virtuellen Maschinen unter SUSE Linux Enterprise Server 11 Service Pack 2 und Red Hat Enterprise Linux 6 auf.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der vSphere Web Client erkennt möglicherweise nicht, dass VMware Tools für Linux-Gastbetriebssysteme installiert ist
    Der vSphere Web Client erkennt möglicherweise nicht, dass VMware Tools für Linux-Gastbetriebssysteme installiert ist.
    Möglicherweise wird auf der Registerkarte Übersicht im vSphere Web Client eine Fehlermeldung ähnlich der folgenden angezeigt:
    VMware Tools ist auf dieser virtuellen Maschine nicht installiert.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Maxon Cinema 4D-Anwendung schlägt im vSGA-Modus möglicherweise fehl
    Wegen eines Problems mit dem VMware OpenGL-Treiber schlägt Maxon Cinema 4D im vSGA-Modus (Virtual Shared Graphics Acceleration) möglicherweise fehl, wenn Sie in der Anwendung auf ein Element der Benutzeroberfläche klicken.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Bei der Ausführung der Petrel 3D-Anwendung auf einer virtuellen Maschine treten möglicherweise Fehler in Bezug auf das Rendering auf
    Wegen eines Problems mit dem OpenGL-Grafiktreiber treten bei der Ausführung der Petrel 3D-Anwendung auf einer virtuellen Maschine möglicherweise Fehler beim Rendering auf.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Benutzer wird beim Upgrade von VMware Tools zwangsweise von virtuellen Windows 8- und Windows 8.1-Maschinen abgemeldet
    Beim Upgrade von VMware Tools auf virtuellen Windows 8- und Windows 8.1-Maschinen wird der Benutzer automatisch von den virtuellen Maschinen abgemeldet.

    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:

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

  • Die Installation auf einer Software-iSCSI-LUN schlägt mit dem Fehler "2 Bootbanks erwartet, 0 gefunden" fehl
    Die vollständige Fehlermeldung zu diesem Problem lautet:
    Fehler (weitere Informationen finden Sie in der Protokolldatei):
    2 Bootbanks erwartet, 0 gefunden.

    Dieses Problem tritt auf, wenn der erste Netzwerkadapter so konfiguriert ist, dass er von einem iBFT iSCSI startet. Die iBFT IP-Einstellungen werden verwendet, um den VMkernel-Netzwerkport zu konfigurieren, der für den Zugriff auf die iSCSI-Startfestplatte erstellt wird. In diesem Fall ist der Port der Verwaltungsnetzwerkport, da der erste Adapter für den Verwaltungsdatenverkehr verwendet wird.

    Wenn die Installation zu etwa 90 Prozent abgeschlossen ist, konfiguriert das Installationsprogramm die Verwaltungsschnittstelle mit DHCP neu. Infolgedessen gehen die iBFT IP-Einstellungen verloren, und die TCP-Verbindung zum iSCSI-Startziel wird unterbrochen.

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

    • Wenn mehrere Netzwerkadapter verfügbar sind, verwenden Sie den zweiten Netzwerkadapter für den Zugriff auf die iSCSI-Startfestplatte.
    • Wenn nur ein Netzwerkadapter verfügbar ist, konfigurieren Sie iBFT so, dass DHCP verwendet wird. Das iSCSI-Ziel sollte auf dem Verwaltungsnetzwerk vorhanden sein. Wenn sich das iSCSI-Ziel in einem anderen Subnetz befindet, kann das Standard-VMkernel-Gateway sowohl den Verwaltungs- als auch den iSCSI-Datenverkehr umleiten.

     

  • 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 --ignoressdnicht für den Befehl installorupgradeunterstützt. Falls Sie die Option --ignoressdmit dem Befehl installorupgradeverwenden, 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 installanstelle des Befehls installorupgrade, um die Option --ignoressdin 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-DeployRuleSetkönnen Sie ermitteln, ob es Regeln gibt, die gelöschte Hostprofile verwenden. Das Cmdlet zeigt in der itemlistder Regel die Zeichenfolge deleted. Anschließend können Sie das Cmdlet Remove-DeployRuleausfü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 HEADLESSin der Tabelle ACPI FADTgesetzt 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".

Upgrade-Probleme

  • Der Patch-Name für Patch-ID ESXi550-Update01 wird als "siehe Beschreibung" angezeigt*
    Bei Verwendung von vSphere Update Manager wird der Patch-Name für das Rollup-Paket von ESXi 5.5 Update 1, Patch-ID ESXi550-Update01, als siehe Beschreibung, (keine KB)angezeigt.
    Der fehlende Patch-Name wirkt sich nicht auf die Funktionalität aus. Einzelheiten zum Rollup-Paket finden Sie in KB 2065832.

    Problemumgehung: Keine
  • 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 esxcliverwenden, 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 --forcemigratedurchgefü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

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

    Umgehung: Führen Sie den Befehl esxcfg-route –raus, 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::/64zu 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.logenthä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 Umgehungen 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 1 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 1 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.

  • 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 wird der folgende Übereinstimmungsfehler gemeldet:
    Der Hostzustand stimmt mit der Spezifikation nicht überein

    Problemumgehung: Es ist keine Umgehung erforderlich. Diese Fehlermeldung stimmt nicht.

  • 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

  • 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-Lesecache kann mit der Fehlermeldung Zeitüberschreitung beim Vorgangfehlschlagen
    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=0einstellen.

  • 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 -dzu 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 smartnicht 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.bandwidthCapnicht 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

  • 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 listausfü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 -Aaus.
       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 wenn 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 automatische 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

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

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