VMware ESXi 5.1 Update 2 | 16. Januar 2014 | Build 1483097

Letzte Aktualisierung: 16. Januar 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:

  • Unterstützung für weitere Gastbetriebssysteme In dieser Version wurde die Unterstützung für viele Gastbetriebssysteme aktualisiert.
    Eine vollständige Liste der von dieser Version unterstützten Gastbetriebssysteme finden Sie im VMware-Kompatibilitätshandbuch.

  • Behobene Probleme Diese Version enthält zahlreiche Fehlerkorrekturen, die im Abschnitt Behobene Probleme dokumentiert sind.

Vorherige Versionen von ESXi 5.1

Die Funktionen und bekannten Probleme von ESXi 5.1 werden in den entsprechenden Versionshinweisen beschrieben. Um Versionshinweise vorheriger Versionen von ESXi 5.1 anzuzeigen, siehe auch

Internationalisierung

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

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

Kompatibilität und Installation

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

Die VMware-Produkt-Interoperabilitätmatrix liefert Details zur Kompatibilität aktueller und vorheriger Versionen von VMware vSphere-Komponenten, einschließlich ESXi, VMware vCenter Server, vSphere Web Client und wahlweise anderer VMware-Produkte. Überprüfen Sie außerdem diese Site auf Informationen zu unterstützten Verwaltungs- und Sicherungsagenten, bevor Sie ESXi oder vCenter Server installieren.

Die ZIP-Datei mit vCenter Server und den Modulen enthält auch den vSphere Web Client und den vSphere-Client. Sie können mithilfe des VMware vCenter™-Installationsassistenten einen oder beide Clients installieren.

ESXi, vCenter Server und VDDK-Kompatibilität

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

Hardwarekompatibilität für ESXi

Um herauszufinden, welche Prozessoren, Speichergeräte, SAN-Arrays und E/A-Geräte mit vSphere 5.1 Update 2 kompatibel sind, lesen Sie die Informationen zu ESXi 5.1 Update 2 im VMware-Kompatibilitätshandbuch.

Die Liste der unterstützten Prozessoren wurde für diese Version erweitert. Informationen dazu, welche Prozessoren mit dieser Version kompatibel sind, finden Sie im VMware-Kompatibilitätshandbuch.

Kompatibilität von Gastbetriebssystemen für ESXi

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

Ab vSphere 5.1 wurden Support-Level-Änderungen für ältere Gastbetriebssysteme eingeführt. Beschreibungen der unterschiedlichen Support-Levels finden Sie im Knowledgebase-Artikel 2015161. Das VMware-Kompatibilitätshandbuch bietet detaillierte Informationen über alle Betriebssystem- und VMware-Produktversionen.

Die folgenden Gastbetriebssystemversionen, die von ihren jeweiligen Anbietern nicht weiter unterstützt werden, laufen aus. Künftige Versionen von vSphere werden diese Gastbetriebssysteme nicht unterstützen, obwohl vSphere 5.1 Update 2 sie noch unterstützt.

  • Windows NT
  • Alle 16-Bit-Versionen von Windows und DOS (Windows 98, Windows 95, Windows 3.1)
  • Debian 4.0 und 5.0
  • Red Hat Enterprise Linux 2.1
  • SUSE Linux Enterprise 8
  • SUSE Linux Enterprise 9 vor SP4
  • SUSE Linux Enterprise 10 vor SP3
  • SUSE Linux Enterprise 11 vor SP1
  • Ubuntu-Versionen 8.04, 8.10, 9.04, 9.10 und 10.10
  • Alle Versionen von Novell Netware
  • Alle Versionen von IBM OS/2

Kompatibilität von virtuellen Maschinen für ESXi

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

Installationshinweise für diese Version

Weitere Informationen zum Installieren und Konfigurieren von ESXi und vCenter Server finden Sie im Installations- und Einrichtungshandbuch für vSphere.

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

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.0 und ESXi 5.1 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 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.1 Update 2 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.1 Update 2. Wenn Ihre Hosthardware nicht kompatibel ist, erscheint ein violetter Bildschirm mit einer entsprechenden Meldung und Sie können weder vSphere 5.1 Update 1 installieren noch ein Update 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.

ESXi 5.1 Update 2 stellt die folgenden Tools für das Upgrade von ESX/ESXi-Hosts zur Verfügung:

  • Durchführen eines interaktiven Upgrades mithilfe eines ESXi-Installer-ISO-Images auf CD-ROM, DVD oder einem USB-Flash-Laufwerk. Sie können das ESXi 5.1 Update 2-Installationsprogramm von einer CD-ROM, DVD oder einem USB-Flash-Laufwerk aus starten, um ein interaktives Upgrade durchzuführen. Diese Methode eignet sich für eine kleine Anzahl an Hosts.
  • Durchführen eines skriptbasierten Upgrades. Sie können ein Upgrade oder eine Migration von ESX/ESXi 4.x-, ESXi 5.0.x und ESXi 5.1-Hosts auf ESXi 5.1 Update 2 durchführen, indem Sie ein Update-Skript aufrufen, das für ein effizientes, unbeaufsichtigtes Upgrade sorgt. Skriptbasierte Upgrades bieten zudem eine effiziente Möglichkeit zum Bereitstellen mehrerer Hosts. Sie können ein Skript zum Durchführen eines Upgrades von ESXi von einem CD-ROM- oder DVD-Laufwerk aus verwenden oder das Installationsprogramm per PXE-Startvorgang starten.

  • vSphere Auto Deploy. Wenn Ihr ESXi 5.x-Host mit vSphere Auto Deploy bereitgestellt wurde, können Sie Auto Deploy zum erneuten Bereitstellen des Hosts verwenden, indem Sie ihn mit einem neuen Image-Profil neu starten, das das ESXi-Upgrade enthält.

  • esxcli. Sie können mithilfe des esxcli-Befehlszeilendienstprogramms ESXi 5.1.x-Hosts aktualisieren und Patches darauf anwenden. Dies kann entweder von einem Download-Depot auf vmware.com oder von einer heruntergeladenen ZIP-Datei eines von einem VMware-Partner vorbereiteten Depots aus erfolgen. Sie können esxcli zum Durchführen eines Upgrades von ESX- oder ESXi-Hosts auf Version 5.1.x von ESX/ESXi-Versionen vor Version 5.1 verwenden.

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

Upgrade-Lieferumfang

Unterstützte Upgrade-Tools

Unterstützte Upgrade-Pfade auf ESXi 5.1 Update 2

ESX 4.0:
Umfasst
ESX 4.0 Update 1
ESX4.0 Update 2

ESX4.0 Update 3
ESX 4.0 Update 4

ESXi 4.0:
Umfasst
ESXi 4.0 Update 1
ESXi 4.0 Update 2

ESXi 4.0 Update 3
ESXi 4.0 Update 4

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

ESX 4.1 Update 3

 

ESXi 4,1 :
Enthält
ESXi 4.1 Update 1

ESXi 4.1 Update 2
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

VMware-VMvisor-Installer-5.1.0.update02-xxxxxxx.x86_64.iso

 

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

Ja

Ja

Ja

Ja

Ja

Ja

update-from-esxi5.1-5.1_update02.zip
  • VMware vCenter Update Manager
  • ESXCLI
  • VMware vSphere-CLI

Nein

Nein

Nein

Nein

Ja

Ja

Verwendung von Patch-Definitionen, die vom VMware-Portal (online) heruntergeladen werden

VMware vCenter Update Manager mit Patch-Baseline

Nein

Nein

Nein

Nein

Nein

Ja

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

Informationen über Copyright und Lizenzen für die Open Source-Softwarekomponenten, die im Lieferumfang von vSphere 5.1 enthalten sind, finden Sie unter http://www.vmware.com/download/open_source.html. Sie können auch die Quelldateien für jede GPL-, LGPL- oder vergleichbare Lizenz herunterladen, die es erfordert, den Quellcode oder Änderungen des Quellcodes für die neueste allgemein verfügbare Version von vSphere zur Verfügung zu stellen.

Hinweise zu Produktunterstützung

  • vSphere-Client. In vSphere 5.1 werden alle neuen vSphere-Funktionen nur über den vSphere Web Client zur Verfügung gestellt. Der herkömmliche vSphere-Client wird weiterhin betrieben und den gleichen Funktionsumfang wie vSphere 5.0 unterstützen, jedoch keine der neuen Funktionen in vSphere 5.1 freilegen.

    vSphere 5.1 und die nachfolgenden Update- und Patch-Versionen sind die letzten Versionen, die den herkömmlichen vSphere-Client enthalten. Zukünftige Hauptversionen von VMware vSphere enthalten nur den vSphere Web Client.

    Bei vSphere 5.1 sind die Fehlerkorrekturen für den herkömmlichen vSphere-Client auf sicherheitsrelevante und kritische Probleme beschränkt. Bei kritischen Fehlern handelt es sich um Abweichungen von der angegebenen Produktfunktionalität, die zur Beschädigung und zum Verlust von Daten, zu Systemausfällen oder zu wesentlichen Ausfällen von Kundenanwendungen führen, bei denen es keine Umgehung gibt, die implementiert werden kann.

  • VMware Toolbox. vSphere 5.1 ist die letzte Version, die Unterstützung für die grafische Benutzeroberfläche von VMware Tools, VMware Toolbox, bietet. VMware wird die Befehlszeilenschnittstelle (CLI) der Toolbox weiterhin aktualisieren und unterstützen, damit alle VMware Tools-Funktionen ausgeführt werden können.

  • VMI-Paravirtualisierung. vSphere 4.1 war die letzte Version, die die Paravirtualisierungsschnittstelle des VMI-Gastbetriebssystems unterstützt. Weitere Informationen zum Migrieren von VMI-fähigen virtuellen Maschinen, sodass sie auf künftigen Versionen von vSphere lauffähig sind, finden Sie im Knowledgebase-Artikel 1013842.

  • Anpassung von Windows-Gastbetriebssystemen. vSphere 5.1 ist die letzte Version, die die Anpassung von Windows 2000-Gastbetriebssystemen unterstützt. VMware wird weiterhin Anpassungen von neueren Versionen von Windows-Gastbetriebssystemen unterstützen.

  • VMCI-Sockets. Gastbetriebssystem-zu-Gastbetriebssystem-Kommunikationen (virtuelle Maschine zu virtuelle Maschine) sind in vSphere 5.1 auslaufend. Diese Funktionalität wird in der nächsten Hauptversion entfernt. VMware wird weiterhin die Host-zu-Gastbetriebssystem-Kommunikation unterstützen.

In dieser Version enthaltene Patches

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

Die Patch-Version ESXi510-Update02 enthält die folgenden einzelnen Bulletins:

ESXi510-201401201-UG: Aktualisiert ESXi 5.1 esx-base vib
ESXi510-201401202-UG: Aktualisiert ESXi 5.1 tools-light vib
ESXi510-201401203-UG: Aktualisiert ESXi 5.1 net-tg3 vib
ESXi510-201401204-UG: Aktualisiert ESXi 5.1 net-e1000e vib
ESXi510-201401205-UG: Aktualisiert ESXi 5.1 scsi-rste vib
ESXi510-201401206-UG: Aktualisiert ESXi 5.1 scsi-mpt2sas vib
ESXi510-201401207-UG: Aktualisiert ESXi 5.1 sata-ata-piix vib
ESXi510-201401208-UG: Aktualisiert ESXi 5.1 sata-ahci vib


Patch-Version ESXi510-Update01 Security-only enthält die folgenden einzelnen Bulletins:

ESXi510-201401101-SG: Aktualisiert ESXi 5.1 esx-base vib
ESXi510-201401102-SG: Aktualisiert ESXi 5.1 tools-light vib
ESXi510-201401103-SG: Aktualisiert ESXi 5.1 esx-xlibs vib

Patch Release ESXi510-Update02 enthält die folgenden Image-Profile:

ESXi-5.1.0-20140102001-standard
ESXi-5.1.0-20140102001-no-tools

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

ESXi-5.1.0-20140101001s-standard
ESXi-5.1.0-20140101001s-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

  • Der ESXi-Host wird vom vCenter Server getrennt, da sfcbd Inodes aufbraucht
    ESXi-Hosts trennen sich vom vCenter Server und können sich nicht erneut mit dem vCenter Server verbinden. Dieses Problem wird durch einen Hardware-Überwachungsdienst (sfcdb) verursacht, der das Verzeichnis /var/run/sfcbmit über 5000 Dateien füllt.

    Die hostd.log-Datei, die sich unter /var/log/befindet, zeigt an, dass der Host über keinen freien Speicherplatz mehr verfügt:
    VmkCtl Locking (/etc/vmware/esx.conf) : Unable to create or open a LOCK file. Failed with reason: No space left on device
    VmkCtl Locking (/etc/vmware/esx.conf) : Unable to create or open a LOCK file. Failed with reason: No space left on device


    Die vmkernel.log-Datei, die sich unter /var/lobefindet, zeigt an, dass keine Inodes mehr zur Verfügung stehen:
    cpu4:1969403)WARNING: VisorFSObj: 893: Cannot create file /etc/vmware/esx.conf.LOCK for process python because the visorfs inode table is full.
    cpu11:1968837)WARNING: VisorFSObj: 893: Cannot create file /etc/vmware/esx.conf.LOCK for process hostd because the visorfs inode table is full.
    cpu5:1969403)WARNING: VisorFSObj: 893: Cannot create file /etc/vmware/esx.conf.LOCK for process python because the visorfs inode table is full.
    cpu11:1968837)WARNING: VisorFSObj: 893: Cannot create file /etc/vmware/esx.conf.LOCK for process hostd because the visorfs inode table is full.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • CIM-Anbieter zeigen möglicherweise falsche Fehlermeldungen an
    CIM-Anbieter zeigen möglicherweise falsche Fehlermeldungen ähnlich der folgenden an:
    \"Request Header Id (886262) != Response Header reqId (0) in request to provider 429 in process 5. Drop response.\"

    Dieses Problem wurde in der vorliegenden Version durch das Aktualisieren des Fehlerprotokolls und durch den Neustart des sfcbd-Management-Agenten behoben, um die richtigen Fehlermeldungen ähnlich der folgenden anzuzeigen:
    Header Id (373) Request to provider 1 in process 0 failed. Fehler:Zeitüberschreitung (oder anderer Socketfehler) beim Senden der Anforderung an den Anbieter.
  • Der Hardware-Überwachungsdienst stoppt und die Registerkarte "Hardwarestatus" zeigt nur eine Fehlermeldung an
    Die Registerkarte Hardwarestatus zeigt nicht die Systemstatus sondern eine Fehlermeldung ähnlich der folgenden an:
    Der Hardware-Überwachungsdienst auf diesem Host antwortet nicht oder ist nicht verfügbar.

    Der Hardware-Überwachungsdienst (sfcdb) stoppt und die syslog-Datei enthält möglicherweise Einträge ähnlich der folgenden:

    sfcb-smx[xxxxxx]: spRcvMsg Receive message from 12 (return socket: 6750210)
    sfcb-smx[xxxxxx]: --- spRcvMsg drop bogus request chunking 6 payLoadSize 19 chunkSize 0 from 12 resp 6750210
    sfcb-smx[xxxxxx]: spRecvReq returned error -1. Skipping message.
    sfcb-smx[xxxxxx]: spRcvMsg Receive message from 12 (return socket: 4)
    sfcb-smx[xxxxxx]: --- spRcvMsg drop bogus request chunking 220 payLoadSize 116 chunkSize 104 from 12 resp 4
    ...
    ...
    sfcb-vmware_int[xxxxxx]: spGetMsg receiving from 40 419746-11 Resource temporarily unavailable
    sfcb-vmware_int[xxxxxx]: rcvMsg receiving from 40 419746-11 Resource temporarily unavailable
    sfcb-vmware_int[xxxxxx]: Zeitüberschreitung oder anderer Socketfehler



    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die WS-Management GetInstance ()-Aktion liefert möglicherweise den Fehler wsa:DestinationUnreachable auf einigen ESXi-Servern
    WS-Management GetInstance ()-Aktion für http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_SoftwareIdentity?InstanceID=46.10000liefert möglicherweise den Fehler wsa:DestinationUnreachableauf einigen ESXi-Servern. Der OMC_MCFirmwareIdentity-Objektpfad ist nicht für CIM gi/ei/ein-Vorgänge auf dem System mit dem Baseboard Management Controller-Sensor (BMC) des Intelligent Platform Management Interface (IPMI) konsistent. Infolgedessen liefert die WS-Management GetInstance ()-Aktion den Fehler wsa:DestinationUnreachableauf dem ESXi-Server.

    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 vmklinux_9:ipmi_threadvon vmkapimodbeim 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 Datamehrere Male dazu verwendet, die Inventardaten zu lesen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Überwachung des Hardwarestatus des ESXi-Hosts nicht möglich
    Wenn der SFCBD-Dienst im Trace-Modus aktiviert ist und der Dienst nicht mehr ausgeführt wird, meldet die Registerkarte Hardwarestatus für einen ESXi-Host möglicherweise einen Fehler. Tools von Drittanbietern sind möglicherweise nicht in der Lage, den Hardwarestatus des ESXi-Hosts zu überwachen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Systemereignisprotokoll (SEL, System Event Log) des IPMI (Intelligent Platform Management Interface) auf dem ESXi-Host kann nicht gelöscht werden
    Das IPMI-Systemereignisprotokoll wird in einer Cluster-Umgebung nicht gelöscht. Dieses Problem wurde gelöst, indem eine CLI-Unterstützung hinzugefügt wurde,um die IPMI SEL zu löschen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der LSI-CIM-Anbieter legt Dateideskriptoren offen
    Der LSI-CIM-Anbieter (einer der sfcb-Prozesse) legt Dateideskriptoren offen. Das bewirkt möglicherweise, dass sfcb-hhrc angehalten und sfcbd neu gestartet wird. Die syslog-Protokolldatei enthält möglicherweise Meldungen ähnlich den folgenden:
    sfcb-LSIESG_SMIS13_HHR[ ]: Error opening socket pair for getProviderContext: Zu viele offene Dateien
    sfcb-LSIESG_SMIS13_HHR[ ]: Failed to set recv timeout (30) for socket -1. Errno = 9
    ...
    ...
    sfcb-hhrc[ ]: Zeitüberschreitung oder anderer Socket-Fehler
    sfcb-hhrc[ ]: TIMEOUT DOING SHARED SOCKET RECV RESULT ( )


    Dieses Problem wurde in der vorliegenden Version behoben.
  • Schwache Schlüssel an CIM Port 5989 können nicht deaktiviert werden
    Um die Cipher Block Chaining (CBC)-Algorithmen für die Richtlinieneinhaltung der Payment Card Industry (PCI) zu deaktivieren, müssen Sie möglicherweise schwache Schlüssel am CIM Port 5989deaktivieren. Das ist nicht zulässig.  

    Dieses Problem wurde in der vorliegenden Version behoben. Sie können die Konfiguration in sfcb.cfg aktualisieren, um schwache Schlüssel zu deaktivieren, indem Sie die folgenden Befehle verwenden:
    # vi /etc/sfcb/sfcb.cfg
    sslCipherList: HIGH:!DES-CBC3-SHA
    # /etc/init.d/sfcbd-watchdog restart
  • Der ESXi-Host fällt mit einem sfcb-CIMXML-Pro-zdump-Fehler aus
    Der ESXi-Host fällt mit einem sfcb-CIMXML-Pro-zdump-Fehler aus, wenn der sfcb-Subprozess für die http-Verarbeitung fälschlicherweise atexit und exit nach einer Befehlsverzweigung aufruft.

    Dieses Problem wurde in der vorliegenden Version behoben.

Sonstige Probleme

  • Einige 3D-Anwendungen zeigen eine fehlerhafte Geometrie, wenn der 3D-Support auf virtuellen Maschinen mit Windows 7 oder Windows 8 aktiviert ist
    Einige 3D-Anwendungen zeigen eine fehlerhafte Geometrie auf virtuellen Maschinen mit Windows 7 oder Windows 8, wenn die Option 3D-Unterstützung aktivieren ausgewählt ist.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Netlogond antwortet möglicherweise nicht mehr und der ESXi-Host verliert möglicherweise Active Directory-Funktionalität
    Netlogond belegt in der Active Directory-Umgebung mit mehreren nicht erreichbaren Domänencontrollern möglicherweise viel Arbeitsspeicher. Infolgedessen schlägt Netlogond möglicherweise fehl und der ESXi-Host verliert möglicherweise die Active Directory -Funktionalität.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der Befehl snmpwalk für eine spezifische snmp OID schlägt fehl
    Wenn Sie den Befehl snmpwalkfür ifHCOutOctets 1.3.6.1.2.1.31.1.1.1.10ausführen, wird eine Fehlermeldung ähnlich der folgenden angezeigt:

    Keine solche Instanz existiert momentan für diese OID für ifHCOutOctets 1.3.6.1.2.1.31.1.1.1.10

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der vSocket-Treiber auf einem ESXi-Host mit vShield Endpoint verursacht möglicherweise einen Deadlock
    Der vSocket-Treiber verursacht auf einer virtuellen Windows-Maschine auf einem ESXi-Host mit vShield Endpoint möglicherweise einen Deadlock. Ein blauer Diagnosebildschirm mit dem folgenden Protokoll wird angezeigt:
    esx-B15E102S-2013-07-01--09.54/vmfs/volumes/50477c5b-d5ad9a53-8e9c-047d7ba55d90/B15E030S/vmware.log:
    2013-06-27T20:44:05.812Z| vcpu-0| TOOLS installed legacy version 8384, available legacy version 8389
    2013-06-27T20:44:05.813Z| vcpu-0| Guest: toolbox: Version: build-515842
    ...
    2013-06-28T20:38:16.923Z| vcpu-1| Ethernet1 MAC Address: 00:50:56:bf:73:52
    2013-06-28T20:38:16.923Z| vcpu-0| Ethernet0 MAC Address: 00:50:56:bf:73:51
    2013-06-28T20:38:16.927Z| vcpu-1| Ethernet2 MAC Address: 00:50:56:bf:73:53
    2013-06-28T20:39:16.930Z| vcpu-0| Guest: vfile: vf-AUDIT: VFileAuditSvmConnectivity : Lost connectivity to SVM, irpStatus: 0xc0000001 ## disconnect SecureVM
    2013-06-28T20:41:06.185Z| vmx| GuestRpcSendTimedOut: message to toolbox timed out.
    2013-06-28T20:41:06.186Z| vmx| Vix: [4304191 guestCommands.c:2194]: Error VIX_E_TOOLS_NOT_RUNNING in VMAutomationTranslateGuestRpcError(): VMware Tools are not running in the guest
    2013-06-28T20:48:28.341Z| mks| MKS disabling SVGA
    2013-06-28T20:48:34.346Z| mks| WinBSOD: (30) `Dumping physical memory to disk: 30 '
    2013-06-28T20:48:43.349Z| mks| WinBSOD: (30) `Dumping physical memory to disk: 35 '
    2013-06-28T20:48:52.353Z| mks| WinBSOD: (30) `Dumping physical memory to disk: 40 '
    2013-06-28T20:49:01.357Z| mks| WinBSOD: (30) `Dumping physical memory to disk: 45 '
    2013-06-28T20:49:09.360Z| mks| WinBSOD: (30) `Dumping physical memory to disk: 50 '
    2013-06-28T20:49:19.366Z| mks| WinBSOD: (30) `Dumping physical memory to disk: 70 '
    2013-06-28T20:49:28.368Z| mks| WinBSOD: (30) `Dumping physical memory to disk: 80


    Dieses Problem wurde in der vorliegenden Version behoben.
  • Kein Rollback für vShield und andere Komponenten möglich
    Ein Rollback für vShield und andere Komponenten möglich, wenn die Installation abgebrochen wird.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Eine virtuelle Maschine antwortet aufgrund eines Signal 11-Fehlers während der Ausführung eines SVGA-Codes nicht
    Eine virtuelle Maschine antwortet aufgrund eines Signal 11-Fehlers nicht, während ein SVGA-Code in svga2_map_surface ausgeführt wird.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESXi-Host schlägt fehl, weil Tausende 0-Byte-.png-Dateien nicht aus dem Ordner /tmp gelöscht werden
    Der ESXi-Host schlägt fehl, weil Tausende 0-Byte- .png-Dateien nicht aus dem Ordner /tmpgelöscht werden. Dies geschieht, weil eine Image Utility-Funktion die tempFileName-Dateien nicht aus dem vCloud Director löschen kann. Das Löschen der aktuellen .png-Dateien aus dem Ordner templöst dieses Problem.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Hostd antwortet möglicherweise nicht mehr und erzeugt hostd-worker-Dump
    Nachdem Sie die Festplatte entfernt und versucht haben, die aktuellsten Informationen vom Host abzurufen, antwortet der ESXi 5.1-Host möglicherweise nicht mehr und erzeugt hostd-worker-Dump.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Virtuelle Maschinen können nicht auf remote gemounteten vSphere Storage Appliance-Datenspeicher erstellt werden
    Ein ESXi-Host, der VMs auf remote gemounteten VSA-Datenspeichern erstellt, antwortet möglicherweise nicht mehr. Das liegt daran, dass das VSA-NAS-Plug-In Netzwerkfehler nicht korrekt handhabt.

    Dieser Fehler tritt aufgrund von Kommunikationsfehlern und der zugrunde liegenden Funktion auf, die dem VSA-NSA-Plug-In NULL-Pointer zurückgibt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Während einer Zielzurücksetzung wartet der lsilogic-Adapter einer virtuellen Maschine auf Befehle von allen Zielen
    Wenn der virtuelle Adapter Isilogic eine Zielzurücksetzung durchführt, wartet er währenddessen auf Befehle für alle Ziele des Adapters. Das führt dazu, dass die Zielzurücksetzung die virtuelle Maschine für eine längere Zeit als eigentlich erforderlich blockiert.

    Dieses Problem wurde in der vorliegenden Version behoben.

Netzwerk

  • Mehrere ESXi 5.1-Hosts antworten möglicherweise nicht mehr, wenn Netflow-Monitoring auf einer verteilten Portgruppe aktiviert ist
    Wenn Netflow-Monitoring auf einer verteilten Portgruppe aktiviert ist, wird die Funktionalität IPFIX (Internet Protocol Flow Information Export) verwendet, um den Switch-Datenverkehr zu überwachen. In der IPFIX-Filterfunktion tritt möglicherweise eine Racebedingung auf, wenn Datensätze mit dem gleichen Schlüssel gemeinsam in der gleichen Hash-Tabelle existieren, so dass der ESXi-Host mit einer Rückverfolgung ähnlich der folgenden nicht mehr antwortet:

    cpu8:42450)Panic: 766: Notfallalarm von einem weiteren CPU (cpu 8, world 42450): ip=0x41801d47b266:
    #GP Exception 13 in world 42450:vmm0:Datacen @ 0x41801d4b7aaf
    cpu8:42450)Backtrace for current CPU #8, worldID=42450, ebp=0x41221749b390
    cpu8:42450)0x41221749b390:[0x41801d4b7aaf]vmk_SPLock@vmkernel#nover+0x12 stack: 0x41221749b3f0, 0xe00000000000
    cpu8:42450)0x41221749b4a0:[0x41801db01409]IpfixFilterPacket@ # +0x7e8 stack: 0x4100102205c0, 0x1, 0x
    cpu8:42450)0x41221749b4e0:[0x41801db01f36]IpfixFilter@ # +0x41 stack: 0x41801db01458, 0x4100101a2e58


    Dieses Problem wurde in der vorliegenden Version behoben.
  • USB-Controller verlieren ihre Konfiguration als DirectPath-E/A-Passthrough-Geräte, wenn ESXi-Hosts neu gestartet werden
    Wenn USB-Controller als Passthrough-Geräte für virtuelle Maschinen, konfiguriert mit DirectPath, hinzugefügt werden und wenn der Host, auf dem die virtuelle Maschine läuft, neu gestartet wird, dann verlieren die USB-Controller ihren Passthrough-Status und sind für den direkten Zugriff auf die virtuellen Maschinen nicht mehr verfügbar.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der VMXNET 3-Adapter wird in Windows Server 2012 mit 64-Wege-VCPU möglicherweise nicht geladen
    Der VMXNET 3-Adapter wird in Windows Server 2012 mit 64-Wege-VCPU nach einem Neustart möglicherweise nicht geladen.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Das Dienstprogramm tcpdump-uw kann nur Pakete erfassen, die kleiner als 8138 Byte sind
    Das tcpdump-uw-Frame-Catpure-Dienstprogramm in ESXi kann nur Pakete erfassen, die kleiner als 8138 Byte sind. Dieses Problem tritt aufgrund einer Socket-Puffergröße auf, die in der VMware-Implementierung von tcpdump-uw auf 8 KB eingestellt ist. Die Socket-Puffergröße ist auf 8192 Byte eingestellt und circa 54 Byte sind für Steuerdaten erforderlich, so dass 8138 Byte das Maximum sind, das erfasst werden kann.

    Die Standard-Puffergröße wurde auf 64 KB erhöht, um dieses Problem zu lösen.
  • Das Nicht-Vmk0 Management-Netzwerk-Interface ist standardmäßig auf Vmk0 gesetzt, nachdem Sie ein Upgrade von ESXi von 5.0 auf 5.1 durchgeführt haben
    Wenn ein Nicht-vmk0 vmknic auf ESXi 5.0 als Management-Netzwerk-Interface verwendet wird und Sie ein Upgrade von ESXi 5.0 auf ESXi 5.1 ausführen, wird das Management-Interface standardmäßig auf vmk0 gesetzt; dies ist das erste vmknic, das nach dem Neustart erstellt wird. Dies ist falsch.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • 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 Netzwerkdatenverkehr zwischen den zwei virtuellen Maschinen möglicherweise beträchtliche Mengen an verworfenen Paketen in esxtop. Dies geschieht, da es während des Berichtens keine Berücksichtigung von aufgeteilten Paketen gibt, wenn Sie TSO vom Gast aus aktivieren.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Linux-Befehle ip link oder ip addr zeigen den Verbindungszustand für VMXNET3-Adapter möglicherweise als „Unknown“ anstatt als „Up“ an
    Wenn Sie VMXNET3-Adapter auf dem Gastbetriebssystem erstellen, zeigen die Linux-Befehle ip link oder ip addr den Verbindungszustand als „Unknown“ anstatt als „Up“ an. Dieses Problem tritt auf, wenn der standardmäßige Verbindungszustand für die Adapter als carrier ok-Modus festgelegt ist und der operstate infolgedessen nicht aktualisiert wird.

    Dieses Problem wurde in der vorliegenden Version behoben, indem der standardmäßige Verbindungszustand für die Adapter auf den no carrier-Modus festgelegt wird.
  • Virtuelle Maschinen mit Solaris 10-Gastbetriebssystemen und VMXNET3-Treibern zeigen überfragmentierte Protokollmeldungen auf der Konsole
    Wenn Sie VMware-Tools auf virtuellen Maschinen mit Solaris 10 installieren und ein VMXNET3-Gerät auf dem Gastbetriebssystem erstellen, werden Protokollmeldungen ähnlich den folgenden auf der Konsole der virtuellen Maschine angezeigt:
    Apr 3 22:44:54 daxa020z last message repeated 274 times Apr 3 22:45:00 daxa020z vmxnet3s: [ID 450982 kern.notice] vmxnet3s:0: overfragmented mp (16)
    Apr 3 22:51:35 daxa020z last message repeated 399 times
    Apr 3 22:51:40 daxa020z vmxnet3s: [ID 450982 kern.notice] vmxnet3s:0: overfragmented mp (16)
    Apr 3 22:58:12 daxa020z last message repeated 398 times
    Apr 3 22:58:20 daxa020z vmxnet3s: [ID 450982 kern.notice] vmxnet3s:0: overfragmented mp (16)
    Apr 3 23:04:53 daxa020z last message repeated 393 times
    Apr 3 23:05:00 daxa020z vmxnet3s: [ID 450982 kern.notice] vmxnet3s:0: overfragmented mp (16)

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Abrufen der dauerhaften MAC-Adresse für eine VMXNET3-Netzwerkkarte schlägt möglicherweise fehl
    Wenn Sie das ETHTOOL_GPERMADDR-ioctl verwenden, um die dauerhafte MAC-Adresse für eine VMXNET3-Netzwerkkarte abzurufen, und wenn es sich um eine Linux-Kernel-Version zwischen 2.6.13 und 2.6.23 handelt, werden keine Ergebnisse erzielt. Wenn es sich um eine Linux-Kernel-Version über 2.6.23 handelt, enthält die zurückgegebene MAC-Adresse nur Nullen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • 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 oder die Rückverfolgung enthält 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@ # +0xd6 stack: 0x31200f9
    0x41229eb9b950:[0x41801d1e5fd8]EtherswitchPortDispatch@ # +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] stack: 0x0

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Virtuelle Maschinen mit e1000 NIC fallen möglicherweise aus, wenn sie in den angehaltenen Modus versetzt werden
    Virtuelle Maschinen fallen möglicherweise aus und zeigen Fehlermeldungen in der Datei vmware.logähnlich der folgenden an, wenn das Gastbetriebssystem mit e1000 NIC-Treiber in den angehaltenen Modus versetzt wurde:

    2013-08-02T05:28:48Z[+11.453]| vcpu-1| I120: Msg_Post: Error
    2013-08-02T05:28:48Z[+11.453]| vcpu-1| I120: [msg.log.error.unrecoverable] VMware ESX unrecoverable error: (vcpu-1)
    2013-08-02T05:28:48Z[+11.453]| vcpu-1| I120+ Unerwartetes Signal: 11


    Dieses Problem tritt bei virtuellen Maschinen auf, die IP-Aliasing verwenden, wenn die Anzahl der IP-Adressen 10 überschreitet.

    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 DCUI (Direct Console User Interface) angezeigt wird.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESXi-Host zeigt einen violetten Diagnosebildschirm mit dem Fehler: #PF Exception 14 in world 10669:vmm1:TREND_M IP
    ESXi-Hosts mit DvFilter-Modul zeigen möglicherweise einen violetten Diagnosebildschirm. Eine Rückverfolgung ähnlich der folgenden wird angezeigt:

    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.
  • 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 im .dvsData-Verzeichnis gelöscht.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Intel e1000e-Netzwerkschnittstelle antwortet möglicherweise nicht mehr bei empfangenen (RX)-Datenverkehr.
    Die Intel e1000e-Netzwerkschnittstelle antwortet möglicherweise nicht mehr bei empfangenen (RX)-Datenverkehr.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Der ESXi-Host fällt möglicherweise mit einem violetten Diagnosebildschirm aufgrund eines Konflikts zwischen zwei DVFilter-Prozessen aus
    Wenn zwei DVFilter-Prozesse versuchen, gleichzeitig eine einzelne Konfigurationsvariable zu verwalten, während ein Prozess die Filterkonfiguration freigibt und der andere Prozess versucht, sie zu sperren, führt dies möglicherweise zu einem ESXi-Hostausfall.

    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.usageverbundene 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.
  • ESXi-Hosts reagieren möglicherweise nicht mehr, wenn die L2Echo-Funktion den Netzwerkwerk-Datenverkehr nicht mehr handhaben kann
    Wenn die Netzwerk-Systemstatusprüfungs-Funktion aktiviert ist, kann die L2Echo-Funktion möglicherweise hohen Netzwerk-Datenverkehr nicht handhaben und die ESXi-Hosts reagieren nicht mehr; ein violetter Diagnosebildschirm mit einer Rückverfolgung ähnlich der folgenden wird angezeigt:

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


    Dieses Problem wurde in der vorliegenden Version behoben.
  • VMXNET3 wird häufig zurückgesetzt, wenn Receive Side Scaling (RSS) auf einer virtuellen Maschine aktiviert ist
    Wenn Receive Side Scaling (RSS) auf einer virtuellen Maschine aktiviert ist, wird der VMXNET3-Netzwerk-Treiber häufig zurückgesetzt, was verursacht, dass die virtuelle Maschine für kurze Zeit die Netzwerkverbindung verliert.

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

Sicherheit

  • Update der OpenSSL-Bibliothek behebt mehrere Sicherheitsprobleme
    Die ESXi-userworld-OpenSSL-Bibliothek wird auf die Version openssl-0.9.8yaktualisiert, um mehrere Sicherheitsprobleme zu beheben.

    Im Projekt "Common Vulnerabilities and Exposures" (CVE) (cve.mitre.org) wurden diesem Problem die Bezeichnungen CVE-2013-0169 und CVE-2013-0166 zugewiesen.
  • Update der libxml2-Bibliothek behebt mehrere Sicherheitsprobleme
    Die ESXi-userworld-libxml2-Bibliothek wurde aktualisiert, um ein Sicherheitsproblem zu beheben.

    Im Projekt "Common Vulnerabilities and Exposures" (CVE) (cve.mitre.org) wurde diesem Problem die Bezeichnung CVE-2013-0338 zugewiesen.
  • Update auf X.Org-Komponenten
    Die ESXi X Windows System-Client-Bibliothek wurde aktualisiert.

Serverkonfiguration

  • NetApp hat eine Aktualisierung der SATP-Beanspruchungsregel angefordert, die verhindert, dass iSCSI in einen Zustand versetzt wird, in dem es nicht mehr antwortet NetApp hat eine Aktualisierung der SATP-Beanspruchungsregel angefordert, die Reservierungskonflikte für eine Logical Unit Number (LUN) verhindert. Die aktualisierte SATP-Beanspruchungsregel verwendet die Option zum Zurücksetzen, um die Reservierung aus der LUN zu löschen, und ermöglicht anderen Benutzern, das Festlegen der Reservierungsoption.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Wenn Sie von einem SAN aus starten, dauert es möglicherweise je nach Netzwerkbandbreite länger, bis das Startgerät erkannt wird Wenn Sie von einem SAN aus starten, dauert der Prozess zur Erkennung des Startgeräts möglicherweise länger. Das Übergeben eines Parameters für die Zeitüberschreitung der erneuten Prüfung an ESX-Befehlszeilen vor dem Startvorgang ermöglicht es den Benutzern, den Zeitüberschreitungswert zu konfigurieren, wodurch das Problem behoben wird.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Versuche, ein Hostprofil anzuwenden, schlagen möglicherweise während des Entfernes mehrerer NFS-Datenspeicher fehl
    Wenn Sie versuchen, mehrere NFS-Datenspeicher unter Verwendung der Option Host-Profil zu entfernen, tritt ein Fehler auf, da es einen Datenspeicher geben kann, der bereits gelöscht wurde.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die vSwitch Failback- und Failover-Reihenfolge-Einstellungen werden nicht in den Host kopiert, wenn Sie ein Hostprofil anwenden
    Wenn Sie ein Hostprofil an einen Host anhängen, werden vSwitch-Eigenschaften wie Failback und Failover-Reihenfolge, die von einem Referenz-Host extrahiert werden, nicht auf den Host angewendet.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESXi-Host berichtet eine falsche Anmeldezeit für ha-eventmgr in der Datei hostd.log
    Der ESXi-Host zeigt die letzte Anmeldezeit für den Stammordner möglicherweise nicht korrekt als 1970 an; diese Information wird für ha-eventmgrauf dem Web Client des ESXi-Hosts angezeigt. In dieser Version wird die Anmeldezeit mithilfe der Systemzeit berechnet, was das Problem gelöst hat.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Sicherungsdatei state.tgz kann auf dem Startgerät nicht gefunden werden, während versucht wird, ein Upgrade eines ESXi-Hosts durchzuführen
    Wenn Sie versuchen, ein Upgrade eines ESXi Hosts mit einem ISO-Image durchzuführen, können Sie möglicherweise die Sicherungsdatei state.tgz nicht auf dem Startgerät finden.

    Dieses Problem tritt auf, wenn die Sicherungsdatei state.tgz nicht aktualisiert wird, weil Sie Ihren Computer vor dem Durchführen des Upgrades nicht ordnungsgemäß heruntergefahren haben. Dies führt dazu, dass beim Zurücksetzen der ESXi-Lizenz die Ausnahmefehlermeldung No such a file angezeigt wird.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Der ESXi-Host fällt mit einem Hostprofil-Fehler aus, wenn die Netzwerk-Failover-Einstellung auf Signalprüfung umgestellt wird
    Während das Hostprofil auf einen ESXi-Host angewendet wird, wenn Sie versuchen, die Netzwerkwerk-Failover-Erkennung auf Signalprüfung umzustellen, fällt der ESXi-Host mit einer Fehlermeldung ähnlich der folgenden aus:
    Zugewiesenes Hostprofil enthält die Einstellungen für Fehlerkritierien von Netzwerkkarten, die sich nicht auf den Host anwenden lassen

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Statusfreies Caching aktualisiert das lokale Hostprofil im Cache nicht
    Wenn statusfreies Caching auf dem ESXi 5.1-Host aktiviert ist und das Hostprofil erneut auf das Image im Cache angewendet wird, werden die Ergebnisse im neu angelegten Hostprofil nicht beibehalten.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Wenn Sie ein Upgrade von Esxi 5.0.x auf Esxi 5.1.x durchführen, verliert der Host die NAS-Datenspeicher und andere Konfigurationen
    Wenn Sie ein Upgrade von Esxi 5.0.x via vCenter Update Manager auf Esxi 5.1.x durchführen, verliert der Host die NAS-Datenspeicher mit dem String Symantec. In dieser Version wurde das Script modifiziert, um unnötige Einträge aus den Konfigurationsdateien während des Upgrades zu entfernen, was dieses Problem löst.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Option bandwidthCap eines ESXi-Hosts funktioniert auf dem 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.
  • Wenn Sie den ESXi-Host über SNMP abfragen, berichtet der Host einen falschen CPU-Belastungs-Durchschnittswert
    Wenn Sie den ESXi-Host über SNMP nach der CPU-Durchschnittsbelastung abfragen, berechnet hrProcessorLoad anstelle der Belastung für die letzte Minute die Belastung für die gesamte Lebensdauer. Dies führt dazu, dass der CPU-Belastungs-Durchschnittswert vom Host falsch berichtet wird.
    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 ESXi-Host die falschen Werte zurück. Dieses Problem tritt bei einem vSphere-Client auf, der mit einem vCenter Server verbunden ist.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESXi-Host berichtet eine Nicht-Einhaltung der Richtlinien mit der Fehlermeldung "Option Annotations.WelcomeMessage entspricht nicht den x-Kriterien"
    Wenn Sie Text in Annotations.WelcomeMessage hinzufügen und ein ESXi-Hostprofil erstellen und das gleiche Hostprofil auf andere Hosts anwenden, erhalten Sie vom anderen Host eine Fehlermeldung ähnlich der folgenden:
    Die Option Annotations.WelcomeMessage entspricht nicht dem angegebenen Kriterien
    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Option bandwidthCap eines ESXi-Hosts funktioniert auf dem 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.
  • Mehrere ESXi-Hosts antworten möglicherweise nicht mehr, wenn Sie einen ESXi-Server zum vCenter Server hinzufügen
    Wenn Sie versuchen, einen ESXi-Server zum vCenter Server hinzuzufügen, antworten mehrere ESXi-Server möglicherweise nicht mehr und eine Fehlermeldung ähnlich der folgenden wird möglicherweise 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 tritt auf, wenn eine hohe Anzahl von HTTP-URL-Anfragen an hostd gesendet wird und der hostd-Dienst fehlschlägt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Die ESXi-Host-Dekodierung des MC5-Status ist möglicherweise nicht korrekt
    Die Fehlermeldungen des Arbeitsspeicher-Controllers werden möglicherweise falsch als TLB-Fehler angegeben, wenn ESXi-Hosts mit einem violetten Bildschirm ausfallen
    Wenn ESXi-Hosts mit einem violetten Bildschirm ausfallen, werden die Fehlermeldungen des Arbeitsspeicher-Controllers möglicherweise falsch als TLB-Fehlermeldungen (Translation Look-aside Buffer), Level 2 TLB Error angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Es ist nicht möglich, Berechtigungen von VI Client zu Active Directory-Benutzer oder -Gruppen zu einem ESXi-Host hinzuzufügen, der mit einer Active Directory-Domäne verbunden ist.
    Es ist eventuell nicht möglich, Berechtigungen zu AD-Benutzer oder -Gruppen hinzuzufügen, da der Domänenname im Dropdown-Menü Domäne nicht verfügbar ist.


    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 auf dem Server installiert sind, empfangen Sie möglicherweise keine SNMP-Traps. Meldungen ähnlich der folgenden werden im Syslog angezeigt:

    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 0
    2013-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.
  • Cluster-weite erneute Speicherprüfungen von vCenter Server bewirken, dass die ESXi/ESX-Hosts und virtuellen Maschinen nicht mehr reagieren
    Wenn Sie bestimmte Vorgänge ausführen, die direkt oder indirekt das VMFS (Virtual Machine File System) involvieren, meist in einer ESXi-Cluster-Umgebung mit gemeinsamen VMFS-Datenspeichern, dann treten möglicherweise die folgenden Probleme auf:
    • Der ESXi-Host antwortet zwischenzeitlich nicht mehr.
    • Der ESXi-Host wird vom vCenter Server getrennt.
    • Die virtuelle Maschine antwortet zwischenzeitlich nicht mehr.
    • Die virtuellen Maschinen, die Teil des Microsoft Cluster Service (MSCS) sind, reagieren nicht mehr, was zu Fehlfunktionen führt.
    • Host-Kommunikationsfehler während der Site Recovery Manager (SRM)-Datenwiederherstellung und der Failover-Tests

      Dieses Problem wurde in der vorliegenden Version behoben.
    • IPMI Sensordaten können nicht richtig abgefragt werden
      Wenn Sie den Befehl exscli hardware ipmi sdr list regelmäßig ausführen, funktioniert das IPMI-Daten-Repository möglicherweise nicht mehr korrekt.

Dieses Problem wurde in der vorliegenden Version behoben.

    • Die TCP, SSL-Remoteprotokollierung startet nach einer Netzwerkunterbrechung nicht automatisch neu
      Der VMware ESXi 5.x-Host, konfiguriert mit TCP/SSL-Remoteprotokollierung, sendet keine Systemprotokolle mehr, wenn die Netzwerkverbindung zum Remote-Protokollserver unterbrochen und wiederhergestellt wird.

      Dieses Problem wird gelöst, indem man ein Default Network Retry Timeouthinzufügt; und der Host versucht erneut, ein Systemprotokoll nach dem Default Network Retry Timeoutzu senden. Der Standardwert von Default Network Retry Timeoutbeträgt 180 Sekunden. Der Befehl esxcli system syslog config set --default-timeout=kann verwendet werden, um den Standardwert zu ändern.

      Dieses Problem wurde in der vorliegenden Version behoben.
    • Auf den VMFS-Datenspeicher oder einige Dateien kann nicht zugegriffen werden
      Ein VMS (Virtual Machine File System)-Datenspeicher (VMFS) fehlt möglicherweise in der Datenspeicher-Registerkarte von vCenter Server oder ein Ereignis ähnlich dem folgenden wird auf der Registerkarte Ereignisse angezeigt:
      XXX esx.problem.vmfs.lock.corruptondisk.v2 XXX oder Mindestens eine beschädigte Sperre (auf der Festplatte) wurde auf Volume mage:prio1.png]] ({2}) erkannt. 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$
      Sie sehen möglicherweise die folgende Meldung im vmkernel.log:
      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.
    • Der ESXi-Host reagiert nicht mehr; ein violetter Diagnosebildschirm mit der Meldung „PCPU XX hatte kein Taktsignal“ wird angezeigt
      Der ESXi-Host reagiert während VMotion möglicherweise nicht mehr mit einem Trace wie folgt:
       
      2013-07-18T17:55:06.693Z cpu24:694725)0x4122e7147330:[0x418039b5d12e]Migrate_NiceAllocPage@esx#nover+0x75 stack: 0x4122e7147350
      2013-07-18T17:55:06.694Z cpu24:694725)0x4122e71473d0:[0x418039b5f673]Migrate_HeapCreate@esx#nover+0x1ba stack: 0x4122e714742c
      2013-07-18T17:55:06.694Z cpu24:694725)0x4122e7147460:[0x418039b5a7ef]MigrateInfo_Alloc@esx#nover+0x156 stack: 0x4122e71474f0
      2013-07-18T17:55:06.695Z cpu24:694725)0x4122e7147560:[0x418039b5df17]Migrate_InitMigration@esx#nover+0x1c2 stack: 0xe845962100000001
      ...
      2013-07-18T17:55:07.714Z cpu25:694288)WARNING: Taktsignal: 646: PCPU 27 hatte 7 Sekunden lang kein Taktsignal; *kann* gesperrt sein.
      2013-07-18T17:55:07.714Z cpu27:694729)ALERT: NMI: 1944: NMI IPI received. Was eip(base):ebp:cs


      Dies tritt während der Ausführung von vMotion auf einem Host unter Speicherüberlastung auf.

      Dieses Problem wurde in der vorliegenden Version behoben.
    • Der ESXi-Host fällt mit einem violetten Diagnosebildschirm aus, wenn fdshandle in der Funktion DevFSFileClose auf Null gesetzt wird
      Wenn fdshandle auf Null gesetzt wird und die beiden Funktionen DevFSFileCloseund DevFSFileResetCommandversuchen, den fdshandle-Wert gleichzeitig zu ändern, fällt der ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm aus.

      Dieses Problem wurde in der vorliegenden Version behoben.
    • ESXi-Server kann nicht gestartet werden, wenn Sie die TXT-Funktion im BIOS-Modus aktivieren
      Wenn Sie TPM/TXT im System-BIOS (Version 1.41)-Modus eines ESXi-Hosts aktivieren, dann fahren Tboot und der ESXi-Host möglicherweise nicht mehr hoch Dieses Problem wurde auf dem IBM 3650 M4-Server beobachtet.

      Dieses Problem wurde in der vorliegenden Version behoben.
    • Der ESXi-Host fällt bei der Verarbeitung von ScsiMidlayerFrame bei SCSIPathTimeoutHandlerFn möglicherweise mit einem violetten Bildschirm aus
      Wenn Sie den Timer vor dem Initialisieren von ScsiMidlayerFramemit der vmkCmd-Option in der SCSI-Funktion festlegen, fällt der ESXi-Host möglicherweise mit einem violetten Bildschirm aus und eine Fehlermeldung ähnlich der folgenden wird möglicherweise angezeigt:
      PF14 in world 3045899:PathTaskmgmt IP 0x418003489e86 addr 0x48

      Dieses Problem wurde in der vorliegenden Version behoben.
    • Der ESXi-Host kann möglicherweise keine Konfigurationsprobleme melden, wenn die Core-Dump-Partition und der Core-Dump-Collector-Dienst nicht konfiguriert sind
      Wenn die Core-Dump-Partition und der Dump-Collector-Dienst eines ESXi-Hosts nicht konfiguriert sind, dann kann der Host möglicherweise keine Konfigurationsprobleme melden. Dieses Konfigurationsproblem wird in VI Client unterdrückt, wenn Sie die erweiterte Konfigurationsoption UserVars.SuppressCoredumpWarningfollowingauf 1 setzen.

      Dieses Problem wurde in der vorliegenden Version behoben.
    • Das Anwenden eines Hostprofils mit Einstellungen für den bevorzugten Pfad schlägt auf dem Zielhost mit dem Fehler "Ungültiger Pfadwert" fehl
      Konfigurieren Sie Host1 mit PSP, definieren Sie ihn als festgelegt, konfigurieren Sie einen bevorzugten Pfad, extrahieren Sie anschließend das Profil aus Host1 und wenden Sie das Profil auf Host2 an. Während der ersten Prüfung des Host2-Profils findet das Plug-In-Modul des Hostprofils möglicherweise den Fehler "Ungültiger Pfadwert" und meldet den "Ungültigen Pfadwert".

      Dieses Problem wurde in der vorliegenden Version behoben.

    Speicher

    • Der aus einem Gastbetriebssystem gesendete Befehl "Erkennung anfordern" gibt keine Daten zurück
      Wenn ein SCSI-Befehl Erkennung anfragenim physischen Modus aus einem Gastbetriebssystem an die Raw-Gerätezuordnung (RDM) gesendet wird, handelt es sich bei den zurückgegebenen Daten manchmal um "NULL" (genullt). Dieses Problem tritt nicht auf, wenn der Befehl vom ESXi-Host gesendet wird.

      Dieses Problem wurde in der vorliegenden Version behoben.
    • Das Klonen sowie die Cold-Migration von virtuellen Maschinen mit großen VMDKs und Snapshot-Dateien schlägt möglicherweise fehl
      Sie können möglicherweise keine virtuellen Maschinen mit einer großen VM-Festplattendatei (VMDK) und Snapshot-Dateien klonen bzw. sind nicht in der Lage, eine Cold-Migration dieser VM auf andere Datenspeicher durchzuführen. Dieses Problem tritt auf, wenn der vpxa-Prozess den Grenzwert für die Arbeitsspeicherzuteilung während der Cold-Migration überschreitet. Dies führt dazu, dass die Verbindung zwischen dem ESXi-Host und dem vCenter Server unterbrochen wird und die Migration fehlschlägt.

      Dieses Problem wurde in der vorliegenden Version behoben.
    • Wenn VMKlinux den Gerätestatus nicht ordnungsgemäß festlegt, können fälschlicherweise Statusmeldungen vom Typ "Gerät ist beschäftigt" (D:0x8) in den VMkernel-Protokolldateien angezeigt werden
      Wenn VMKlinux den Gerätestatus nicht ordnungsgemäß festlegt, werden in den VMkernel-Protokolldateien Statusmeldungen vom Typ "Gerät ist beschäftigt" (D:0x8) angezeigt, die den folgenden Meldungen ähneln:

      2013-04-04T17:56:47.668Z cpu0:4012)ScsiDeviceIO: SCSICompleteDeviceCommand:2311: Cmd(0x412441541f80) 0x16, CmdSN 0x1c9f from world 0 to dev "naa.600601601fb12d00565065c6b381e211" failed H:0x0 D:0x8 P:0x0 Possible sense data: 0x0 0x0 0x0

      Dies führt dazu, dass falsche Alarme generiert werden, da das Speicher-Array für SCSI-Befehle keine Statusmeldung vom Typ "Gerät ist beschäftigt" ausgibt.
      Dieses Problem wurde in der vorliegenden Version behoben, indem ordnungsgemäß auf die Statusmeldungen vom Typ "Hostbus ist beschäftigt" (H:0x2) verwiesen wird, wenn es um Probleme in den Gerätetreibern ähnlich den folgenden geht:

      2013-04-04T13:16:27.300Z cpu12:4008)ScsiDeviceIO: SCSICompleteDeviceCommand:2311: Cmd(0x4124819c2f00) 0x2a, CmdSN 0xfffffa80043a2350 from world 4697 to dev "naa.600601601fb12d00565065c6b381e211" failed H:0x2 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0

      Dieses Problem wurde in der vorliegenden Version behoben.
    • vCenter Server oder vSphere Client verlieren möglicherweise während der Erstellung des VMFS-Datenspeichers die Verbindung zum ESXi-Host
      vCenter Server oder vSphere Client verlieren möglicherweise während der Erstellung des VMFS-Datenspeichers die Verbindung zum ESXi-Host.

      Dieses Problem tritt auf, wenn hostd mit einer Fehlermeldung ähnlich der folgenden im hostd-Protokoll fehlschlägt:
      Panic: Assert Failed: "matchingPart != __null".

      Der hostd-Vorgang schlägt während der Erstellung des VMFS-Datenspeichers auf Festplatten mit einer bestimmten Partitionskonfiguration fehl, die die Ausrichtung der Partitionen erfordert.
    • Der Wert für den bereitgestellten Speicherplatz für den NFS-Datenspeicher wurde falsch berechnet und führt zu falschen Alarmen
      Unter bestimmten Bedingungen wird der bereitgestellte Speicherplatz für den NFS-Datenspeicher möglicherweise falsch berechnet, was zu falschen Alarmen führen kann.

      Dieses Problem wurde in der vorliegenden Version behoben.
    • Nach einem permanenten Geräteverlust können Datenbanken nicht wieder online geschaltet werden
      Nach einem permanenten Geräteverlust (PDL) können Datenbanken aufgrund einiger offener Datei-Handles auf dem Volume nicht wieder online geschaltet werden.

      Dieses Problem wurde in der vorliegenden Version behoben.
    • Das Laden des nfsclient-Moduls während des ESXi-Startvorgangs führt zum Fehler beim Laden anderer Module
      Während des ESXi-Startvorgangs sperrt das Laden des nfsclient-Moduls die esx.conf-Datei für längere Zeit, wenn eine Verzögerung in der Auflösung des Hostnamens für die Netzwerkdateisystem- Mount-Punkte (NFS) vorliegt. Dies kann zu einem Fehler beim Laden von Migrations-, IPMI- und anderen Modulen führen.

      Dieses Problem wurde in der vorliegenden Version behoben.
    • Kein Zugriff auf den VMFS-Dateispeicher bzw. einige Dateien
      Es fehlt möglicherweise 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 Protokollmeldung wird im VMkernel-Protokoll angezeigt:

      [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 wird die folgende Fehlermeldung in die Datei "vmkernel.log" geschrieben:

      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.
    • ESXi 5.1-Hosts fallen möglicherweise mit einem violetten Diagnosebildschirm und Fehlermeldungen aus, die mit der DevFSFileClose-Funktion verbunden sind
      Wenn mehrere Threads versuchen, dasselbe Gerät gleichzeitig zu schließen, fallen ESXi 5.1-Hosts möglicherweise mit einem violetten Diagnosebildschirm und einer Rückverfolgung ähnlich der folgenden aus:
      cpu1:16423)@BlueScreen: #PF Exception 14 in world 16423:helper1-0 IP 0x41801ac50e3e addr 0x18PTEs:0x0;
      cpu1:16423)Code start: 0x41801aa00000 VMK uptime: 00:09:28:51.434
      cpu1:16423)0x4122009dbd70:[0x41801ac50e3e]FDS_CloseDevice@vmkernel#nover+0x9 stack: 0x4122009dbdd0
      cpu1:16423)0x4122009dbdd0:[0x41801ac497b4]DevFSFileClose@vmkernel#nover+0xf7 stack: 0x41000ff3ca98
      cpu1:16423)0x4122009dbe20:[0x41801ac2f701]FSS2CloseFile@vmkernel#nover+0x130 stack: 0x4122009dbe80
      cpu1:16423)0x4122009dbe50:[0x41801ac2f829]FSS2_CloseFile@vmkernel#nover+0xe0 stack: 0x41000fe9a5f0
      cpu1:16423)0x4122009dbe80:[0x41801ac2f89e]FSS_CloseFile@vmkernel#nover+0x31 stack: 0x1
      cpu1:16423)0x4122009dbec0:[0x41801b22d148]CBT_RemoveDev@ # +0x83 stack: 0x41000ff3ca60
      cpu1:16423)0x4122009dbef0:[0x41801ac51a24]FDS_RemoveDev@vmkernel#nover+0xdb stack: 0x4122009dbf60
      cpu1:16423)0x4122009dbf40:[0x41801ac4a188]DevFSUnlinkObj@vmkernel#nover+0xdf stack: 0x0
      cpu1:16423)0x4122009dbf60:[0x41801ac4a2ee]DevFSHelperUnlink@vmkernel#nover+0x51 stack: 0xfffffffffffffff1
      cpu1:16423)0x4122009dbff0:[0x41801aa48418]helpFunc@vmkernel#nover+0x517 stack: 0x0
      cpu1:16423)0x4122009dbff8:[0x0] stack: 0x0
      cpu1:16423)base fs=0x0 gs=0x418040400000 Kgs=0x0
      cpu1:16423)vmkernel 0x0 .data 0x0 .bss 0x0
      cpu1:16423)chardevs 0x41801ae70000 .data 0x417fc0000000 .bss 0x417fc00008a0

      Dieses Problem wurde in der vorliegenden Version behoben.
    • Das Zurücksetzen der Logical Unit Number schlägt bei der Verarbeitung von FCP_RSP_INFO in der Funktion fc_fcp_resp fehl
      In einer LUN-Rücksetzungsüberprüfung mit NetApp-Zielen wurde beobachtet, dass die LUN-Rücksetzung fehlschlägt. fc_fcp_resp() schließt nicht die LUN-Rücksetzungsaufgabe, da fc_fcp_resp davon ausgeht, dass FCP_RSP_INFO 8 Byte groß ist und über 4 Byte für reserviertes Feld verfügt. NetApp-Ziele verfügen jedoch über FCP_RSP zur LUN-Rücksetzung mit nur 4 Byte von FCP_RSP_INFO. Dies führt zum fc_fcp_resp-Fehler, ohne dass die Aufgabe beendet wird. Möglicherweise führt dies dazu, dass eine LUN-Rücksetzung fehlschlägt.

      Dieses Problem wurde in der vorliegenden Version behoben.
    • Der ESXi-Benutzer kann den Fibre-Channel über Ethernet deaktivieren, der über kein Startgerät verfügt
      Wenn Sie in einem ESX-Host aus einem Fibre-Channel über Ethernet-SAN starten, kann der Benutzer FCoE möglicherweise nicht auf einem Port deaktivieren.

      Dieses Problem wurde in der vorliegenden Version behoben.
    • Software iSCSI-Parameter-Änderungen werden nicht in der Datei syslog.log protokolliert
      Erstmals werden in dieser Version iSCSI-Sitzungs- und Verbindungsparameter in der Datei syslog.log protokolliert, und diese enthält dann frühere und neue Parameterwerte.
    • Versuche, Snapshots von virtuellen Maschinen mit gemeinsam genutzten virtuellen Festplatten zu erstellen, schlagen möglicherweise fehl, wenn Oracle Clusterware verwendet wird
      Wenn die Multiwriter-Option auf gemeinsam genutzten virtuellen Festplatten zusammen mit der Oracle Real Application Cluster (RAC)-Option von Oracle Clusterware Software verwendet wird, schlagen Versuche, Snapshots von virtuellen Maschinen zu erstellen, möglicherweise fehl, und virtuelle Maschinen laufen nicht mehr. Die Protokolldateien enthalten möglicherweise Einträge ähnlich den folgenden:

      Resuming virtual disk scsi1:5 failed. The disk has been modified since a snapshot was taken or the virtual machine was suspended.

      Dieses Problem tritt möglicherweise auch mit anderen Cluster-Management-Software auf.

      Dieses Problem wurde in der vorliegenden Version behoben.

    Upgrade und Installation

    • Die Hoststandardisierung mit Bulletins, die ausschließlich Anweisungen zum Neustart enthalten, schlägt fehl
      Während des Standardisierungsvorgangs eines ESXi-Hosts mit einer Patch-Baseline, die aus Bulletins besteht, die ausschließlich Anweisungen zum Neustart enthalten, kann Update Manager die virtuellen Maschinen, die auf dem Host ausgeführt werden, nicht abschalten oder anhalten. Der Host kann somit nicht in den Wartungsmodus versetzt und die Standardisierung kann nicht abgeschlossen werden.

      Dieses Problem wurde in Bulletins behoben, die in der vorliegenden Version und für spätere Versionen erstellt wurden.

    vCenter Server, vSphere-Client und vSphere Web Client

    • Angepasstes Leistungsdiagramm enthält keine Option zum Anzeigen der gesamten Statistiken für die virtuelle Festplatte für Objekte der virtuellen Maschine
      Wenn Sie die Metrik der virtuellen Festplatte verwenden, um Leistungsdiagramme anzuzeigen, steht Ihnen nur die Option zum Anzeigen der Leistungsdiagramme der virtuellen Festplatte für die verfügbaren Objekte der virtuellen Festplatte zur Verfügung.

      In der vorliegenden Version können Sie auch Leistungsdiagramme der virtuellen Festplatte für die Objekte der virtuellen Maschine anzeigen. Das ist hilfreich, wenn Sie Alarme auslösen müssen, die auf der Nutzung der virtuellen Festplatte durch virtuelle Maschinen basieren.
    • Auf der Registerkarte "Übersicht" werden möglicherweise falsche Werte für den bereitgestellten Speicherplatz für Hosts mit VAAI NAS angezeigt*
      Wenn eine virtuelle Festplatte mit einem Thick-Provision Lazy-Zeroed-Format auf einem ESXi-Host mit VAAI NAS erstellt wird, kann in der Ansicht "Datenspeicher und Datenspeicher-Cluster" auf der Registerkarte Übersicht als bereitgestellter Speicherplatz das Doppelte des für die virtuelle Festplatte festgelegten bereitgestellten Speicherplatzes angezeigt werden.
      Wenn der bereitgestellte Speicher z. B. 75 GB beträgt, kann der angezeigte bereitgestellte Speicher bei etwa 150 GB liegen.

      Dieses Problem wurde in der vorliegenden Version behoben.
    • Auf der Registerkarte "Übersicht" werden möglicherweise falsche Werte für den bereitgestellten Speicherplatz für Hosts mit VAAI NAS angezeigt*
      Wenn eine virtuelle Festplatte mit einem Thick-Provision Lazy-Zeroed-Format auf einem ESXi-Host mit VAAI NAS erstellt wird, kann in der Ansicht "Datenspeicher und Datenspeicher-Cluster" auf der Registerkarte Übersicht als bereitgestellter Speicherplatz das Doppelte des für die virtuelle Festplatte festgelegten bereitgestellten Speicherplatzes angezeigt werden.
      Wenn der bereitgestellte Speicher z. B. 75 GB beträgt, kann der angezeigte bereitgestellte Speicher bei etwa 150 GB liegen.

      Dieses Problem wurde in der vorliegenden Version behoben.

    Verwaltung von virtuellen Maschinen

    • Die WPF-Anwendung zeigt Objekte in einer virtuellen Maschine falsch an, wenn die 3D-Software-Rendering-Option aktiviert ist
      Wenn Sie eine Windows-WPF-Anwendung auf einer virtuellen Maschine installieren und die 3D-Software-Rendering-Option aktiviert ist, weist die WPF-Anwendung während der Anzeige von Bildern möglicherweise Inkonsistenzen auf.

      Dieses Problem wurde in der vorliegenden Version behoben.
    • Das Gastbetriebssystem fällt mit dem Fehlerprüfcode PAGE_FAULT_IN_NONPAGED_AREA während der Installation eines Win2000 Servers mit 8 oder mehr virtuellen CPUs aus
      Wenn Sie einen Windows 2000 Server auf einer virtuellen Maschine installieren, fällt das Gastbetriebssystem mit einem violetten Diagnosebildschirm aus und eine PAGE_FAULT_IN_NONPAGED_AREA-Fehlermeldung wird angezeigt. Dieses Problem wurde in der virtuellen Windows 2000-Maschine mit acht oder mehreren virtuellen CPUs beobachtet.

      Dieses Problem wurde in der vorliegenden Version behoben.
    • Das Entfernen einer gemeinsam genutzten nicht dauerhaften Festplatte dauert lange aufgrund einer Schreibsperre der gemeinsam genutzten Festplatte
      Wenn Sie einer virtuellen Maschine gemeinsam genutzte nicht dauerhaften Festplatten über Unidesk APIs hinzufügen, reagiert die virtuelle Maschine möglicherweise nicht mehr. Dies geschieht, weil die virtuelle Maschine die schreibgeschützten Festplatten im exklusiven Modus öffnet.
      Dieses Problem wurde in der vorliegenden Version behoben.

    vMotion und Storage vMotion

    • Auf einer virtuellen Maschine mit aktiviertem CBT schlägt die inkrementelle Sicherung möglicherweise mit einem FileFault-Fehler für QueryChangedDiskAreas fehl, nachdem eine VM-Festplatte mithilfe von vMotion auf ein anderes Volume verschoben wurde
      Wenn Sie auf einer virtuellen Maschine mit Verfolgungsfunktionalität für geänderte Blöcke (Changed Block Tracking, CBT) QueryChangedDiskAreas ausführen, nachdem Sie mithilfe von vMotion eine VM-Festplatte
      (virtual machine disk, VMDK) auf ein anderes Volume verschoben haben, schlägt die inkrementelle Sicherung möglicherweise mit einem FileFault-Fehler ähnlich dem folgenden fehl:

      2012-09-04T11:56:17.846+02:00 [03616 info 'Default' opID=52dc4afb] [VpxLRO] -- ERROR task-internal-4118 -- vm-26512 --
      vim.VirtualMachine.queryChangedDiskAreas: vim.fault.InvalidVmConfig
      --> Result:
      --> (vim.fault.FileFault) {
      --> dynamicType = <unset>,
      --> faultCause = (vmodl.MethodFault) null, file =
      --> "/vmfs/volumes/4ff2b68a-8b657a8e-a151-3cd92b04ecdc/VM/VM.vmdk",
      --> msg = "Error caused by file
      /vmfs/volumes/4ff2b68a-8b657a8e-a151-3cd92b04ecdc/VM/VM.vmdk",
      --> }

      Um dieses Problem zu lösen, wird CBT (Changed Block Tracking) deaktiviert und erneut aktiviert, nachdem die VMDK mithilfe von Storage vMotion in einen anderen Datenspeicher verschoben wurde; danach müssen Sie alle geänderten Referenzen verwerfen und eine vollständige Sicherung durchführen, um CBT für weitere inkrementelle Sicherungen nutzen zu können.

      Dieses Problem tritt auf, wenn eine Bibliotheksfunktion die Festplattenänderungsverfolgung nicht richtig neu initialisiert.

      Dieses Problem wurde in der vorliegenden Version behoben.

    VMware HA und Fault Tolerance

    • Aktivieren eines High Availability-Clusters nicht möglich, nachdem ein einzelner Host in den Wartungsmodus versetzt wurde
      Sie können einen High Availability-Cluster (HA) nicht aktivieren, nachdem ein einzelner Host auf demselben HA-Cluster in den Wartungsmodus versetzt wurde. Dieses Problem tritt auf, wenn der Wert der Inode-Deskriptor-Nummer im ESX-Root-Dateisystem (VisorFS) nicht richtig eingestellt ist und infolgedessen die stat-Anrufe auf diesen Inodes fehlschlagen.

      Dieses Problem wurde in der vorliegenden Version behoben.

    VMware Tools

    • Das VMware Tools-Installationsprogramm installiert das vmhgfs-Modul nicht, wenn vmci und vsock hochgestreamt werden, nachdem Sie die vmhgfs-Installation aktiviert haben
      Wenn Sie versuchen, VMware Tools zu installieren, wenn vmci und vsock hochgestreamt werden, installiert das Installationsprogramm das vmhgfs-Modul nicht, wenn Sie die Installation dieses Moduls bereits installiert haben. Dieses Problem wurde auf Linux-Betriebssystem mit Kernel-Version 3.9 oder höher beobachtet.

      Dieses Problem wurde in der vorliegenden Version behoben.
    • Das Laden des Schnittstellen-Steuerelements der virtuellen Maschine schlägt auf Linux-Kernel 3.9 fehl, wenn VMCI und VSOCK hochgestreamt werden
      Wenn Sie den Befehl /etc/vmware-tools/service.sh restartausführen, um Dienste zu überprüfen, wenn vmci und vsock hochgestreamt und VMware Tools installiert werden, wird der Status des Schnittstellen-Steuerelements der virtuellen Maschine möglicherweise nicht angezeigt. Dieses Problem ist auf dem Linux-Betriebssystem mit der Kernel-Version 3.9 oder höher beobachtet worden.

      Dieses Problem wurde in der vorliegenden Version behoben.
    • Virtuelle Maschinen mit Windows-Betriebssytem zeigen möglicherweise Warnmeldungen an, wenn Sie ein Upgrade von VMware Tools durchführen
      Wenn Sie ein Upgrade von VMware-Tool auf einem ESXi 5.1-Host auf die Version 9.0 durchführen, zeigen die virtuellen Maschinen mit Windows-Betriebssystem eine Warnmeldung ähnlich der folgenden an:

      Failed registration of app type 2 (Signals) from plugin unity

      Dieses Problem wurde in der vorliegenden Version behoben.
    • open-vm-tools wurde vom Linux Tools-Installationsprogramm deinstalliert
      Wenn ein Benutzer das VMware Tools-Installationsprogramm auf vSphere in einem Betriebssystem ausführt, das open-vm-tools enthält, wird open-vm-tools automatisch deinstalliert und VMware Tools wird installiert.

      Dieses Problem wurde in der vorliegenden Version behoben.

    • Eine virtuelle Maschine mit dem Gastbetriebssystem Solaris 10 reagiert nicht mehr, wenn Sie VMware Tools von ESXi 5.1 installieren
      Wenn Sie VMware Tools von ESXi 5.1 auf einer virtuellen Maschine mit Solaris 10 als Gastbetriebssystem installieren, reagiert die virtuelle Maschine möglicherweise nicht mehr und zeigt eine Meldung ähnlich der folgenden an:
      Wait for the CDE desktop to start

      Dieses Problem wurde in der vorliegenden Version behoben.
    • Das Einrichten einer Filterregel, die den Laufwerksbuchstaben für einen Datenträger mit einem nicht unterstützten Dateisystem enthält, kann dazu führen, dass die virtuelle Maschine von Windows Server 2003 oder Windows XP mit einem blauen Bildschirm ausfällt
      Wenn Sie versuchen, eine Filterregel einzurichten, die den Laufwerksbuchstaben für einen Datenträger mit einem nicht unterstützten Dateisystem enthält, schlägt die virtuelle Maschine von Windows Server 2003 oder Windows XP möglicherweise mit einem blauen Bildschirm fehl, und es werden möglicherweise Fehlermeldungen ähnlich der folgenden angezeigt:
      Error code 1000007e, parameter1 c0000005, parameter2 baee5d3b, parameter3 baa69a64, parameter4 baa69760.

      Weitere Informationen finden Sie beim Help and Support Center unter http://go.microsoft.com/fwlink/events.asp.Data:

      0000: 53 79 73 74 65 6d 20 45 System E
      0008: 72 72 6f 72 20 20 45 72 rror Er
      0010: 72 6f 72 20 63 6f 64 65 ror code
      0018: 20 31 30 30 30 30 30 37 10000070020: 65 20 20 50 61 72 61 6d e Param
      0028: 65 74 65 72 73 20 63 30 eters c
      00030: 30 30 30 30 30 35 2c 20 000005,
      0038: 62 61 65 65 35 64 33 62 baee5d3b
      0040: 2c 20 62 61 61 36 39 61 , baa69a
      0048: 36 34 2c 20 62 61 61 36 64, baa6
      0050: 39 37 36 30 9760

      Dieses Problem tritt hauptsächlich auf, wenn der Laufwerksbuchstabe Q:\, der von der Microsoft App-V-Lösung erstellt wurde, in der Filterregel hinzugefügt wird. Dieses Problem wurde in der vorliegenden Version behoben.
    • VMware Tools wurde aktualisiert und enthält nun vorgefertigte Module für SUSE Linux Enterprise Server 11 SP3, Oracle Linux 5.x mit 2.6.39-200/300/400-Kernel
      und Oracle Linux 6.x mit 2.6.39-200/300/400-Kernel
    • Der vCenter-Schutzagent zeigt die Warnmeldung Registrierung des VSS-Treibers wird aufgehoben für eine nicht signierte ausführbare Datei in einem VMware Tools-Update
      Wenn Sie versuchen, eine Aktualisierung von VMware Tools auf einer VMware Workstation auszuführen, zeigt der vCenter-Schutzagent die Warnmeldung Registrierung des VSS-Treibers wird aufgehobenzur Verwendung einer nicht signierten ausführbaren Datei an. Das Einschließen der ausführbaren Datei zur Liste der Dateien, die in den Installationsordner kopiert wurden, behebt dieses Problem.

      Dieses Problem wurde in der vorliegenden Version behoben.
    • Einschließen des vnetflt.sys-Kernel-Treibers und verknüpfter Dateien in vShield MSM für Tools
      Schließen Sie den vnetflt.sys-Kernel-Treiber und verknüpfte Dateien in vShield MSM für Tools ein. Das Einschließen unterstützt das Ändern mehrerer VM-Installationsprogramm-APIs durch das Hinzufügen zusätzlicher Standardargumente. Diese Argumente können verwendet werden, um Tags für die Sortierung des Dienststarts innerhalb einer Gruppe zu erstellen.

      Dieses Problem wurde in der vorliegenden Version behoben.
    • VMware Tools können nicht gestartet werden wenn die vmci- und vsock-Treiber mit der Clobber-Option installiert sind
      Wenn Sie VMware Tools mit der Option --clobber-kernel-modules=vmci,vsockinstallieren, kann der VMware Tools Service nicht gestartet werden und eine Fehlermeldung ähnlich der folgenden wird angezeigt:

      Creating a new initrd boot image for the kernel.
      update-initramfs: Generating /boot/initrd.img-3.9.0-rc2-custom
      vmware-tools-thinprint start/running
      initctl: Job failed to start
      Unable to start services for VMware Tools

      Execution aborted.


      Dieses Problem wurde in der vorliegenden Version behoben. Die vmci- und vsock-Treiber können nach dem Upstreaming mit Linux-Kernel-Versionen höher als 3.9 installiert werden.
    • Deinstallieren der VMwareTools auf Windows Server 2003
      Wenn Sie versuchen, VMTools auf einem Windows Server 2003 zu deinstallieren, kann die VM die VMTools nicht deinstallieren und eine Fehlermeldung wird angezeigt.

      Dieses Problem wurde in der vorliegenden Version behoben.

    Bekannte Probleme

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

    Upgrade- und Installationsprobleme

    • Bestandslistenobjekte sind nach dem Upgrade einer mit der Postgres-Datenbank konfigurierten vCenter Server Appliance möglicherweise nicht sichtbar*
      Wenn eine mit der Postgres-Datenbank konfigurierte vCenter Server Appliance von 5.0 Update 2 auf 5.1 Update 1 aktualisiert wird, sind Bestandslistenobjekte wie zum Beispiel Datencenter, vDS usw., die vor dem Upgrade vorhanden waren, möglicherweise nicht mehr sichtbar. Dieses Problem tritt auf, wenn Sie unter Verwendung von vSphere Web Client eine Verbindung zur vCenter Server Appliance herstellen.

      Umgehung: Starten Sie nach dem Upgrade der vCenter Server Appliance den Inventory Service neu.

    • Bei der statusorientierten Auto Deploy-Installation kann das Argument "firstdisk" von ESX auf Systemen nicht verwendet werden, die ESX/ESXi bereits auf USB installiert haben
      Sie konfigurieren das Hostprofil für einen Host, den Sie für die statusorientierte Installation mit Auto Deploy einrichten möchten. Als Teil der Konfiguration wählen Sie USB als Festplatte und geben "esx" als erstes Argument ein. Auf dem Host ist derzeit ESX/ESXi auf USB installiert. Anstelle der Installation von ESXi auf USB installiert Auto Deploy ESXi auf der lokalen Festplatte.

      Umgehung: Keine.

    • Die Auto Deploy PowerCLI-cmdlets "Copy-DeployRule" und "Set-DeployRule" benötigen ein Objekt als Eingabe
      Wenn Sie das cmdlet Copy-DeployRuleoder Set-DeployRuleausführen und ihm den Namen eines Image-Profils oder ein Hostprofils übergeben, tritt ein Fehler auf.

      Umgehung: Übergeben Sie ihm das Image-Profil- bzw. Hostprofilobjekt.

    • 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

      Umgehung: Entfernen Sie die ESX-Software von der Festplatte oder wählen Sie eine andere Festplatte für die Verwendung des statusfreien Cachings aus.

    • vSphere Auto Deploy funktioniert nicht mehr, wenn die IP-Adresse der Maschine, die den Auto Deploy-Server hostet, geändert wurde
      Sie installieren Auto Deploy auf einer anderen Maschine als vCenter Server und ändern die IP-Adresse der Maschine, die den Auto Deploy-Server hostet. Nach der Änderung funktionieren die Auto Deploy-Befehle nicht mehr.

      Umgehung: Starten Sie den Auto Deploy-Server-Dienst neu.
      net start vmware-autodeploy-waiter
      Falls nach einem Neustart des Diensts das Problem nicht behoben wurde, müssen Sie möglicherweise den Auto Deploy-Server neu registrieren. Führen Sie den folgenden Befehl unter Angabe aller Optionen aus.
      autodeploy-register.exe -R -a vCenter-IP -p vCenter-Port -u user_name -w password -s setup-file-path

    • Auf HP DL980 G7 werden ESXi-Hosts nicht mit Auto Deploy gestartet, wenn Onboard-Netzwerkkarten verwendet werden
      Sie können ein HP DL980 G7-System mit Auto Deploy nicht starten, wenn das System die Onboard-Netzwerkkarten (LOM Netxen) für den Start per PXE verwendet.

      Umgehung: Installieren Sie auf dem Host eine von HP genehmigte Add-On-Netzwerkkarte, z. B. HP NC3 60T, und verwenden Sie diese Netzwerkkarte für den Start per PXE.

    • Ein Live-Update mit esxcli schlägt mit einem VibDownloadError fehl
      Ein Benutzer führt zwei Updates hintereinander folgendermaßen durch.

      1. Ein Live-Update mit dem esxcli-Softwareprofil-Update oder dem VIB-Update-Befehl esxcli.
      2. Ein Update, das einen Neustart erfordert.

      Die zweite Transaktion schlägt fehl. Eine häufige Ursache liegt in der Verifizierung der Signatur, die nur dann überprüft werden kann, nachdem das VIB heruntergeladen wurde.

      Umgehung: Der Fehler kann in zwei Schritten behoben werden.

      1. Starten Sie den ESXi-Host neu, um dessen Zustand zu bereinigen.
      2. Wiederholen Sie die Live-Installation.

    • ESXi-Skriptinstallation kann die Kickstart-Datei (ks) auf dem CD-ROM-Laufwerk nicht finden, wenn keine Netzwerkkarten mit der Maschine verbunden sind
      Wenn sich die Kickstart-Datei auf einem CD-ROM-Laufwerk eines Systems befindet, mit dem keine Netzwerkkarten verbunden sind, wird die folgende Fehlermeldung vom Installationsprogramm angezeigt: Kickstart-Datei auf CD-ROM mit Pfad < path_to_ks_file>wurde nicht gefunden.

      Umgehung: Verbinden Sie die Netzwerkkarten neu, um die Netzwerkverbindung herzustellen, und wiederholen Sie die Installation.

    • Skriptinstallation schlägt auf der SWFCoE-LUN fehl
      Wenn das ESXi-Installationsprogramm die Installation unter Verwendung der Kickstart-Datei (ks) durchführt, sind zu dem Zeitpunkt, an dem die Installation gestartet wird, noch nicht alle FCoE-LUNs geprüft und ausgefüllt worden. Dies führt dazu, dass die Skriptinstallation auf einer LUN fehlschlägt. Das Problem tritt auf, wenn das HTTPS-, HTTP- oder FTP-Protokoll für den Zugriff auf die Kickstart-Datei verwendet wird.

      Umgehung: Fügen Sie im Abschnitt %preder Kickstart-Datei eine sleep-Anweisung von zwei Minuten ein:
      %pre --interpreter=busybox
      sleep 120

    • Beim Durchführen eines Upgrades von vCenter Server ohne gleichzeitiges Upgrade des Auto Deploy-Servers können Probleme auftreten
      Wenn Sie ein Upgrade von vCenter Server durchführen, ersetzt vCenter Server den vSphere 5.0-HA-Agenten (vmware-fdm) auf jedem ESXi-Host durch einen neuen Agenten. Das Ersetzen wird bei jedem Neustart eines ESXi-Hosts vorgenommen. Wenn vCenter Server nicht zur Verfügung steht, können die ESXi-Hosts keinem Cluster beitreten.

      Umgehung: Führen Sie, falls möglich, ein Upgrade des Auto Deploy-Servers durch.
      Wenn ein Upgrade vom Auto Deploy-Server nicht möglich ist, können Sie Image Builder PowerCLI-cmdlets verwenden, die in vSphere PowerCLI enthalten sind, um ein ESXi 5.0-Image-Profil zu erstellen, das die neue vmware-fdm-VIB umfasst. Sie können Ihre Hosts mit diesem Imageprofil versehen.

      1. Fügen Sie das ESXi 5.0-Software-Depot und das Software-Depot hinzu, das das neue vmware-fdm-VIB enthält.
        Add-EsxSoftwareDepot C:\ Path\VMware-Esxi-5.0.0- buildnumber-depot.zip Add-EsxSoftwareDepot http:// vcenter server/vSphere-HA-depot
      2. Klonen Sie das vorhandene Image-Profil und fügen Sie das vmware-fdm-VIB hinzu.
        New-EsxImageProfile -CloneProfile "ESXi-5.0.0- buildnumber-standard" -name " Imagename" Add-EsxSoftwarePackage -ImageProfile " ImageName" -SoftwarePackage vmware-fdm
      3. Erstellen Sie eine neue Regel, die Ihren Hosts das neue Image-Profil zuweist, und fügen Sie die Regel dem Regelsatz hinzu.
        New-DeployRule -Name " Rule Name" -Item " Image Name" -Pattern " my host pattern" Add-DeployRule -DeployRule " Rule Name"
      4. Führen Sie einen Vorgang zum Testen und Reparieren von Übereinstimmungen für die Hosts durch.
        Test-DeployRuleSetCompliance Host_list

    • Wenn das statusfreie Caching aktiviert ist und der Auto Deploy-Server nicht zur Verfügung steht, startet der Host möglicherweise nicht automatisch mithilfe des gespeicherten Images
      In manchen Fällen startet ein Host, der für das statusfreie Caching mit Auto Deploy eingerichtet ist, nicht automatisch von der Festplatte, auf der sich das gespeicherte Image befindet, wenn der Auto Deploy-Server nicht zur Verfügung steht. Die kann auch dann passieren, wenn das gewünschte Startgerät in der logischen Startreihenfolge als Nächstes steht. Was sich tatsächlich ereignet, hängt von den BIOS-Einstellungen des Serveranbieters ab.

      Umgehung: Wählen Sie die Festplatte mit dem zwischengespeicherten Image als Startgerät manuell aus.

    • Bei einem Upgrade eines ESXi 5.0-Hosts auf ESXi 5.1 mit ESXCLI, vMotion und Fault Tolerance (FT) gehen die Protokollierungseinstellungen verloren
      Auf einem ESXi 5.0-Host aktivieren Sie vMotion und Fault Tolerance für eine Portgruppe. Sie führen den Befehl esxcli software profile update aus, um ein Upgrade des Hosts durchzuführen. Im Rahmen eines erfolgreichen Upgrades werden die vMotion-Einstellungen und die Protokollierungseinstellungen für Fault Tolerance auf die Standardeinstellungen zurückgesetzt, d. h., sie werden deaktiviert.

      Umgehung: Verwenden Sie vSphere Upgrade Manager, um ein Upgrade der Hosts durchzuführen, oder setzen Sie manuell vMotion und Fault Tolerance auf deren Einstellungen vor dem Upgrade zurück.

    Netzwerkprobleme
    • Auf einem SR-IOV-fähigen ESXi-Host werden virtuellen Funktionen zugeordnete VMs möglicherweise nicht gestartet
      Wenn SR-IOV auf ESXi 5.1-Hosts mit Intel ixgbe NICs aktiviert ist und in dieser Umgebung verschiedene virtuelle Funktionen aktiviert sind, werden einige virtuelle Maschinen möglicherweise nicht gestartet.
      In der Datei vmware.log werden Fehlermeldungen ähnlich der folgenden angezeigt:
      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.

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

    • Das System antwortet während einer TFTP/HTTP-Übertragung nicht mehr, wenn ESXi 5.1 oder 5.0 U1 mit Auto Deploy bereitgestellt wird
      Bei der Bereitstellung von ESXi 5.1 oder 5.0 U1 mit Auto Deploy auf Emulex 10GbE NC553i FlexFabric 2-Ports unter Verwendung der neuesten Open-Source gPXE antwortet das System während einer TFTP/HTTP-Übertragung nicht mehr.

      Emulex 10GbE PCI-E-Controller sind im Speicher abgebildete Controller. Der auf dem Controller laufende PXE/UNDI-Stack muss während der PXE TFTP/HTTP-Übertragung vom Real Mode in den Big Real Mode umschalten, um die gerätespezifischen Register zu programmieren, die sich über 1 MB befinden, damit Pakete über das Netzwerk gesendet und empfangen werden können. Während dieses Vorgangs werden CPU-Interrupts unbeabsichtigt aktiviert. Dies bewirkt, dass das System nicht mehr reagiert, wenn andere Geräte-Interrupts während der CPU-Modusumschaltung generiert werden.

      Umgehung: Führen Sie ein Upgrade der Firmware der Netzwerkkarte auf Build 4.1.450.7 oder höher durch.

    • Änderungen der Anzahl von Ports auf einem virtuellen Standard-Switch werden erst wirksam, wenn der Host neu gestartet wird
      Wenn Sie die Anzahl der Ports auf einem virtuellen Standard-Switch ändern, werden die Änderungen erst wirksam, wenn Sie den Host neu starten. Dies unterscheidet sich vom Verhalten bei einem verteilten virtuellen Switch, bei dem Änderungen der Anzahl von Ports sofort wirksam werden.

      Wenn Sie die Anzahl der Ports auf einem virtuellen Standard-Switch ändern, achten Sie darauf, dass die Gesamtanzahl der Ports auf dem Host, Standard-Switches und verteilte Switches zusammengenommen, nicht höher als 4096 ist.

      Umgehung: Keine.

    • Der administrative Zustand einer physischen Netzwerkkarte wird nicht ordnungsgemäß als "ausgefallen"gemeldet
      Das administrative Festlegen des Zustands einer physischen Netzwerkkarte auf "ausgefallen" entspricht nicht der IEEE-Norm. Wenn über den Befehl für virtuelle Switches eine physische Netzwerkkarte auf "ausgefallen" festgelegt wurde, treten zwei bekannte Probleme auf:

      • ESXi erfährt eine Zunahme des Datenverkehrsaufkommens, die es nicht bewältigen kann. Dies führt zu einer Verschwendung von Netzwerkressourcen am physischen Switch von ESXi sowie in den ESXi-Ressourcen selbst.

      • Die Netzwerkkarte verhält sich in unerwarteter Weise. Operatoren erwarten, dass die Netzwerkkarte ausgeschaltet ist, aber sie wird als aktiv angezeigt.

      Es wird empfohlen, den ESXCLI-Befehl -n vmnicN mit den folgenden Vorbehalten zu verwenden:
      • Dieser Befehl schaltet nur den Treiber aus. Die Netzwerkkarte wird nicht ausgeschaltet. Wenn der physische ESXi-Netzwerkadapter in der Verwaltungsschnittstelle des physischen Switches des ESXi-Systems angezeigt wird, scheint das Standard-Switch-Uplink noch aktiv zu sein.

      • Der administrative Zustand einer Netzwerkkarte ist in ESXCLI oder der UI nicht sichtbar. Denken Sie daran, beim Debuggen den Zustand zu überprüfen, indem Sie die Datei "/etc/vmware/esx.conf" untersuchen.

      • Der SNMP-Agent meldet den administrativen Zustand. Er meldet ihn jedoch nicht richtig, wenn der Zustand der Netzwerkkarte auf "ausgefallen" festgelegt wurde, als der Betriebszustand ohnehin "ausgefallen" lautete. Er meldet den administrativen Zustand ordnungsgemäß, wenn der Zustand der Netzwerkkarte auf "ausgefallen" festgelegt wurde, als der Betriebszustand "aktiv" war.

      Umgehung: Ändern Sie den administrativen Zustand auf dem physischen Switch des ESXi-Systems in "ausgefallen", anstatt den Befehl des virtuellen Switches zu verwenden.

    • Änderungen bei der Unterstützung von Linux-Treibern
      Gerätetreiber für virtuelle VMXNET2- oder VMXNET (Flexible)-Netzwerkkarten stehen für virtuelle Maschinen nicht zur Verfügung, auf denen die Linux-Kernelversion 3.3 und höher ausgeführt wird.

      Umgehung: Verwenden Sie für virtuelle Maschinen, auf denen die Linux-Kernelversion 3.3 und höher ausgeführt wird, eine virtuelle VMXNET3- oder e1000-Netzwerkkarte.

    • Die Zuteilung der Bandbreite für Network I/O Control von vSphere 5.0 wird nicht gerecht über mehrere Uplinks verteilt
      Wenn bei der Verwendung von Network I/O Control in vSphere 5.0 ein Grenzwert für die Netzwerkbandbreite eines Ressourcenpools festgelegt wurde, wird die Einhaltung dieses Grenzwerts über eine Gruppe von Uplinks auf Hostebene erzwungen. Dieser Bandbreitengrenzwert wird durch einen Token-Verteilungsalgorithmus implementiert, der nicht für die gerechte Verteilung der Bandbreite über mehrere Uplinks hinweg konzipiert wurde.

      Umgehung: Die Grenzwerte für Network I/O Control von vSphere 5.1 wurden auf eine pro Uplink-Basis beschränkt.

    • Die Einstellung "Länge des gespiegelten Pakets" könnte dazu führen, dass eine Remotespiegelungsquell-Sitzung nicht funktioniert
      Wenn Sie eine Remotespiegelungsquell-Sitzung mit festgelegter Option "Länge des gespiegelten Pakets"konfigurieren, empfängt das Ziel einige gespiegelte Pakete nicht. Wenn Sie die Option jedoch deaktivieren, werden die Pakete wieder empfangen.
      Wenn die Option "Länge des gespiegelten Pakets" festgelegt ist, werden Pakete gekürzt, die länger als die angegebene Länge sind, und Pakete werden verworfen. Ein Code auf niedriger Ebene sorgt nicht für das Fragmentieren und Neuberechnen der Prüfsumme der verworfenen Pakete. Es gibt zwei Ursachen für das Verwerfen von Paketen:

      • Die "Länge des gespiegelten Pakets" ist größer als die MTU (Maximum Transmission Unit)
        Wenn in Ihrer Umgebung TSO aktiviert ist, können die ursprünglichen Pakete sehr groß sein. Auch wenn sie aufgrund der angegebenen "Länge des gespiegelten Pakets" abgeschnitten wurden, sind sie immer noch größer als die MTU und werden daher von der physischen Netzwerkkarte verworfen.

      • Dazwischenliegende Switches führen die L3-Prüfung durch
        Einige abgeschnittene Pakete können die falsche Paketlänge und Prüfsumme aufweisen. Einige erweiterte physische Switches prüfen die L3-Informationen und verwerfen ungültige Pakete. Das Ziel empfängt die Pakete nicht.

      Umgehung:

      • Wenn TSO (TCP Segmentation Offload) aktiviert ist, deaktivieren Sie die Option "Länge des gespiegelten Pakets".

      • Sie können die L3-Prüfung auf einigen Switches, z. B. dem Ciscos Switch der Serie 4500, aktivieren oder deaktivieren. Wenn diese Switches verwendet werden, deaktivieren Sie die L3-Prüfung. Im Falle von Switches, die nicht konfiguriert werden können, deaktivieren Sie die Option "Länge des gespiegelten Pakets".

    • Das Aktivieren von mehr als 16 VMkernel-Netzwerkadaptern sorgt dafür, dass vSphere vMotion fehlschlägt
      vSphere 5.x hat eine Obergrenze von 16 VMkernel-Netzwerkadaptern, die für vMotion pro Host aktiviert sind. Wenn Sie für einen angegebenen Hosts mehr als 16 VMkernel-Netzwerkadapter für vMotion aktivieren, könnte das Durchführen von vMotion-Migrationen zu oder von diesem Host fehlschlagen. Eine Fehlermeldung in den VMkernel-Protokollen auf ESXi lautet Refusing request to initialize 17 stream ip entries, wobei die Zahl die Anzahl der VMkernel-Netzwerkadapter angibt, die Sie für vMotion aktiviert haben.

      Umgehung: Deaktivieren Sie vMotion VMkernel-Netzwerkadapter, bis insgesamt nur 16 davon für vMotion aktiviert sind.

    • Der vSphere-Netzwerk-Core-Dump funktioniert nicht, wenn in einer VLAN-Umgebung ein nx_nic-Treiber verwendet wird
      Wenn auf einem Host, der Teil eines VLANs ist, Netzwerk-Core-Dump konfiguriert wird, schlägt der Netzwerk-Core-Dump fehl, wenn die Netzwerkkarte einen QLogic Intelligent Ethernet Adapters-Treiber (nx_nic) verwendet. Empfangene Netzwerk-Core-Dump-Pakete werden nicht mit dem richtigen VLAN-Tag gekennzeichnet, wenn der Uplink-Adapter nx_nic verwendet.

      Umgehung: Verwenden Sie einen anderen Uplink-Adapter mit einem anderen Treiber, wenn Sie den Netzwerk-Core-Dump in einem VLAN konfigurieren.

    • Wenn die Kickstart-Datei einer Skriptinstallation eine Netzwerkkarte aufruft, die bereits verwendet wird, schlägt die Installation fehl
      Wenn Sie eine Kickstart-Datei verwenden, um nach der Installation ein Verwaltungsnetzwerk einzurichten, und Sie von der Kickstart-Datei aus eine Netzwerkkarte aufrufen, die bereits verwendet wird, wird die folgende Fehlermeldung angezeigt: Sysinfo-Fehler bei Vorgang, gemeldeter Status: Belegt. Detaillierte Fehlerinformationen finden Sie im VMkernel-Protokoll.

      Der Fehler tritt auf, wenn Sie eine Skriptinstallation auf einem System mit zwei Netzwerkkarten initiieren: eine Netzwerkkarte, die für SWFCoE/SWiSCSI konfiguriert ist, und eine für das Netzwerk konfigurierte Netzwerkkarte. Wenn Sie die Netzwerkkarte für das Netzwerk verwenden, um die Skriptinstallation zu initiieren, indem Sie bei den Startoptionen entweder netdevice=<nic> oder BOOTIF=<MAC der NIC> angeben, verwendet die Kickstart-Datei die andere Netzwerkkarte ( netdevice=<nic configured for SWFCoE / SWiSCSI>) in der Netzwerkzeile, um das Verwaltungsnetzwerk zu konfigurieren.

      Die Installation (Partitionierung der Festplatten) ist erfolgreich, aber, wenn das Installationsprogramm versucht, die in der Kickstart-Datei angegebenen Netzwerkparameter für das Konfigurieren des Verwaltungsnetzwerks für den Host zu verwenden, schlägt es fehl, da die Netzwerkkarte von SWFCoE/SWiSCSI verwendet wurde.

      Umgehung: Verwenden Sie in der Kickstart-Datei eine verfügbare Netzwerkkarte, um nach der Installation ein Verwaltungsnetzwerk einzurichten.

    • Virtuelle Maschinen, auf denen ESX läuft und die auch VMXNET3 als pNIC verwenden, können abstürzen
      Virtuelle Maschinen, auf denen ESX als Gast läuft und die auch VMXNET3 als pNIC verwenden, können abstürzen, weil sich die Unterstützung für VMXNET3 noch in der Versuchsphase befindet. Die Standard-Netzwerkkarte für eine virtuelle Maschine mit ESX ist e1000. Daher tritt dieses Problem nur auf, wenn Sie den Standard außer Kraft setzen und VMXNET3 wählen.

      Umgehung: Verwenden Sie e1000 oder e1000e als pNIC für die virtuelle Maschine mit ESX.

    • Eine Fehlermeldung wird angezeigt, wenn eine große Anzahl von dvPorts benutzt wird
      Wenn Sie eine virtuelle Maschine mit dvPort auf einem Host hochfahren, auf dem bereits eine große Anzahl von dvPorts genutzt wird, erscheint die Fehlermeldung Nicht genügend Arbeitsspeicher vorhandenoder Keine Ressourcen mehr frei. Dies kann auch auftreten, wenn Sie die Switches auf einem Host mit einem esxcli-Befehl auflisten.

      Umgehung: Erhöhen Sie den Wert für dvsLargeHeap.

      1. Ändern Sie die erweiterte Konfigurationsoption des Hosts:
        • esxcli-Befehl: esxcfg-advcfg -s /Net/DVSLargeHeapMaxSize 100
        • Virtual Center: Navigieren Sie zu Hostkonfiguration -> Software -> Erweiterte Einstellungen -> Ändern Sie unter "Netz" den Wert für DVSLargeHeapMaxSize von 80 auf 100.
        • vSphere 5.1 Web Client: Navigieren Sie zu Host verwalten -> Einstellungen -> Erweiterte Systemeinstellungen -> Filter. Ändern Sie den Wert für DVSLargeHeapMaxSize von 80 auf 100.
      2. Erfassen Sie ein Hostprofil aus dem Host. Weisen Sie das Profil dem Host zu und aktualisieren Sie die Antwortdatei.
      3. Starten Sie den Host neu, um zu bestätigen, dass der Wert angewendet wurde.

      Hinweis: Der maximale Wert für /Net/DVSLargeHeapMaxSize ist 128.

      Kontaktieren Sie den VMware Support, wenn bei einer größeren Bereitstellung nach der Änderung von /Net/DVSLargeHeapMaxSize auf 128 Probleme auftreten und die Protokolle eine der folgenden Fehlermeldungen enthalten:

      Unable to Add Port; Status(bad0006)= Limit exceeded (Port kann nicht hinzugefügt werden; Status (bad0006) = Grenzwert überschritten)

      Failed to get DVS state from vmkernel Status (bad0014)= Out of memory (DVS-Status konnte vom vmkernel-Status nicht bezogen werden (bad0014) = Kein Arbeitsspeicher mehr)

    • ESXi schlägt mit Emulex BladeEngine-3 10G NICs (be2net-Treiber) fehl
      ESXi kann bei Systemen fehlschlagen, die Emulex BladeEngine-3 10G-Netzwerkkarten haben, wenn ein vCDNI-gestützter Netzwerkpool mit VMware vCloud Director konfiguriert wurde. Sie müssen einen aktualisierten Gerätetreiber von Emulex installieren, wenn Sie mit diesem Gerät einen Netzwerkpool einrichten.

      Umgehung: Keine.

    Speicherprobleme

    • Bei der Migration virtueller Maschinen mit RDM-LUNs von einem VMFS-Datenspeicher nach einem NFS-Datenspeicher werden die RDM-LUNs von den VMs getrennt
      Wenn Sie mit dem vSphere Web Client virtuelle Maschinen mit RDM-LUNs von einem VMFS-Datenspeicher nach einem NFS-Datenspeicher migrieren, wird der Migrationsvorgang ohne Fehler- oder Warnmeldung abgeschlossen und die RMD-LUNs werden nach der Migration von der virtuellen Maschine getrennt. Allerdings wird bei der Migration eine VMDK-Datei derselben Größe wie die RDM-LUN auf dem NSF-Datenspeicher erstellt, um die RDM-LUN zu ersetzen.
      Bei Verwendung des vSphere-Clients wird eine entsprechende Fehlermeldung im Kompatibilitätsabschnitt des Migrations-Assistenten angezeigt.

      Umgehung: Keine
    • Das Erstellen eines VMFS5-Datenspeichers schlägt möglicherweise fehl, wenn Sie ein EMC Symmetrix VMAX/VMAXe-Speicher-Array einsetzen
      Wenn Ihr ESXi-Host mit einem VMAX/VMAXe-Array verbunden ist, können Sie möglicherweise keinen VMFS5-Datenspeicher auf einer LUN erstellen, die von dem Array präsentiert wird. Wenn dies der Fall ist, wird die folgende Fehlermeldung angezeigt: Während der Hostkonfiguration ist ein Fehler aufgetreten.. Der Fehler ist darauf zurückzuführen, dass die ATS (VAAI)-Portion des Symmetrix Enginuity Microcodes (VMAX 5875.x) einen neuen Datenspeicher auf einer vorher unbeschriebenen LUN verhindert.

      Umgehung:

      1. Deaktivieren Sie das hardwarebeschleunigte Sperren auf dem ESXi-Host.
      2. Erstellen Sie einen VMFS5-Datenspeicher.
      3. Reaktivieren Sie das hardwarebeschleunigte Sperren auf dem Host.

      Verwenden Sie die folgenden Aufgaben, um den Parameter für das hardwarebeschleunigte Sperren zu deaktivieren und anschließend zu reaktivieren.

      Im vSphere Web Client

      1. Navigieren Sie zum Host im Navigator von vSphere Web Client.
      2. Klicken Sie auf die Registerkarte Verwalten und anschließend auf Einstellungen.
      3. Klicken Sie unter "System" auf Erweiterte Systemeinstellungen.
      4. Wählen Sie "VMFS3.HardwareAcceleratedLocking" aus und klicken Sie auf das Symbol "Bearbeiten".
      5. Ändern Sie den Wert des Parameters "VMFS3.HardwareAcceleratedLocking":
        • 0 - deaktiviert
        • 1 - aktiviert

      Im vSphere-Client

      1. Wählen Sie im Bestandslistenbereich des vSphere-Clients den Host aus.
      2. Klicken Sie auf die Registerkarte Konfiguration und anschließend unter Software auf Erweiterte Einstellungen.
      3. Ändern Sie den Wert des Parameters "VMFS3.HardwareAcceleratedLocking":
        • 0 - deaktiviert
        • 1 - aktiviert

    • Versuche, eine GPT-Partition auf einer leeren Festplatte zu erstellen, schlagen möglicherweise bei der Verwendung von Storagesystem::updateDiskPartitions()
      fehl Sie können das API Storagesystem::computeDiskPartitionInfoverwenden, um die Festplattenspezifikation abzurufen, und anschließend die Festplattenspezifikation zum Beschriften der Festplatte und zum Erstellen einer Partition mit Storagesystem::updateDiskPartitions()verwenden. Wenn jedoch die Festplatte anfänglich leer und das Format der Zielfestplatte GPT ist, schlägt das Erstellen der Partition möglicherweise fehl.

      Umgehung: Verwenden Sie stattdessen DatastoreSystem::createVmfsDatastorezum Beschriften und Partitionieren einer leeren Festplatte sowie zum Erstellen eines VMFS5-Datenspeichers.

    • Versuche, eine Diagnosepartition auf einer GPT-Festplatte zu erstellen, schlagen möglicherweise fehl
      Wenn eine GPT-Festplatte keine Partitionen hat oder die Endportion der Platte leer ist, können Sie möglicherweise keine Diagnosepartition auf der Festplatte erstellen.

      Umgehung: Vermeiden Sie die Verwendung von GPT-formatierten Festplatten für Diagnosepartitionen. Wenn Sie für die Diagnosepartition, eine vorhandene leere GPT-Festplatte verwenden müssen, konvertieren Sie die Festplatte in das MBR-Format.

      1. Erstellen Sie einen VMFS3-Datenspeicher auf der Festplatte.
      2. Entfernt den Datenspeicher.

      Das Festplattenformat ändert sich von GPT in MBR.

    • ESXi kann nicht von einer FCoE-LUN starten, die größer als 2 TB ist und bei der der Zugriff über eine Intel FCoE-Netzwerkkarte erfolgt
      Wenn Sie ESXi auf einer FCoE-Start-LUN installieren, die größer als 2 TB ist und bei der der Zugriff über eine Intel FCoE-Netzwerkkarte erfolgt, gelingt die Installation möglicherweise. Wenn Sie jedoch versuchen, Ihren ESXi-Host zu starten, schlägt der Startvorgang fehl. Zum BIOS-Zeitpunkt sehen Sie die Fehlermeldungen: FEHLER: Keine passende Geometrie für diese Festplattenkapazität!und FEHLER: Verbindungsaufbau mit keiner konfigurierten Festplatte möglich!.

      Umgehung: Installieren Sie ESXi auf keiner FCoE-LUN, die größer als 2 TB ist, wenn es mit der für den FCoE-Start konfigurierten Intel FCoE-Netzwerkkarte verbunden ist. Installieren Sie ESXi auf einer FCoE-LUN, die kleiner als 2 TB ist.

    Serverkonfigurationsprobleme
    • Das Übernehmen von Hostprofilen schlägt möglicherweise fehl, wenn auf VMFS-Ordner über die Konsole zugegriffen wird
      Wenn ein Benutzer über die Konsole auf den VMFS-Datenspeicherordner zugreift, während gleichzeitig ein Hostprofil vom Host übernommen wird, schlägt der Standardisierungs- oder Übernahmevorgang möglicherweise fehl. Dieser Fehler tritt auf, wenn auf dem Hostprofil das statusfreie Caching aktiviert ist oder eine Auto Deploy-Installation durchgeführt wurde.

      Umgehung: Greifen Sie beim Standardisieren des Hostprofils nicht über die Konsole auf den VMFS-Datenspeicher zu.

    • Führende Weißraumzeichen im Anmelde-Banner verursachen einen Fehler bei der Übereinstimmung von Hostprofilen
      Wenn Sie ein Hostprofil bearbeiten und beim Ändern des Texts des Anmelde-Banners (Meldung des Tages) führende Weißraumzeichen hinzufügen, tritt beim Übernehmen des Profils ein Übereinstimmungsfehler auf. Der Übereinstimmungsfehler Der Anmelde-Banner wurde geändertwird angezeigt.

      Umgehung: Bearbeiten Sie das Hostprofil und entfernen Sie die führenden Weißraumzeichen aus dem Text des Anmelde-Banners.

    • Ein vom ESXi 5.0-Host extrahiertes Hostprofil kann vom ESX 5.1-Host nicht übernommen werden, wenn Active Directory aktiviert ist
      Das Anwenden eines Hostprofils mit aktiviertem Active Directory, das ursprünglich von einem ESXi 5.0-Host auf einen ESX 5.1-Host extrahiert wurde, schlägt fehl. Beim Festlegen der maximalen Arbeitsspeichergröße für den Likewise-Systemressourcenpool tritt möglicherweise ein Fehler auf. Wenn Active Directory aktiviert ist, verbrauchen die Dienste im Likewise-Systemressourcenpool mehr als den Standardgrenzwert für die maximale Arbeitsspeichergröße für ESXi 5.0, die in einem ESXi 5.0-Hostprofil erfasst wurde. Folglich schlägt das Anwenden eines ESXi 5.0-Hostprofils bei Versuchen fehl, den Grenzwert für die maximale Arbeitsspeichergröße auf ESXi 5.0-Niveau festzulegen.

      Umgehung: Führen Sie einen der folgenden Schritte durch:

      • Bearbeiten Sie das Hostprofil manuell, um den Grenzwert für die maximale Arbeitsspeichergröße für die Likewise-Gruppe zu erhöhen.
        1. Navigieren Sie vom Hostprofileditor zum Ordner Ressourcenpool und sehen Sie sich host/vim/vmvisor/plugins/likewise an.
        2. Ändern Sie die Einstellung Maximale Arbeitsspeichergröße (MB) von 20 (dem ESXi 5.0-Standardwert) auf 25 (den ESXi 5.1-Standardwert).
      • Deaktivieren Sie das Unterprofil für die Likewise-Gruppe. Führen Sie einen der folgenden Schritte aus:
        • Bearbeiten Sie im vSphere Web Client das Hostprofil und heben Sie die Aktivierung des Kontrollkästchens für den Ordner Ressourcenpool auf. Diese Aktion deaktiviert die Ressourcenpoolverwaltung. Sie können dies gezielt für das Element host/vim/vmvisor/plugins/likewise im Ressourcenpool-Ordner deaktivieren.
        • Klicken Sie mit der rechten Maustaste im vSphere-Client auf das Hostprofil und wählen Sie im Menü Profilkonfiguration aktivieren/deaktivieren...

    • Das Host-Gateway wird gelöscht und Übereinstimmungsfehler treten auf, wenn ein ESXi 5.0.x-Hostprofil neu auf einen statusorientierten ESXi 5.1-Host angewendet wird
      Wenn ein ESXi 5.0.x-Hostprofil auf einen neu installierten ESXi 5.1-Host angewendet wird, lautet der Profil-Übereinstimmungsstatus "Nicht übereinstimmend". Nachdem dasselbe Profil erneut angewendet wurde, wird die Gateway-IP des Hosts gelöscht und der Übereinstimmungsstatus wird weiterhin als "Nicht übereinstimmend" angezeigt. Die Statusmeldung lautet Die IP-Routenkonfiguration stimmt nicht mit der Spezifikation überein.

      Umgehung: Führen Sie eine der folgenden Umgehungen durch:

      • Melden Sie sich über die direkte Konsole (DCUI) beim Host an und fügen Sie das Standard-Gateway unter Verwendung des folgenden esxcli-Befehls manuell hinzu:
        esxcli network ip route ipv4 add --gateway xx.xx.xx.xx --network yy.yy.yy.yy
      • Extrahieren Sie ein neues Hostprofil vom ESX 5.1-Host, nachdem Sie das ESX 5.0-Hostprofil einmal angewendet haben. Migrieren Sie den ESX 5.1-Host auf das neue ESX 5.1-basierte Hostprofil.

    • Nach der Aktivierung von statusfreiem Caching auf einer USB-Festplatte treten möglicherweise Übereinstimmungsfehler auf
      Wenn auf einem Hostprofil das statusfreie Caching für USB-Festplatten aktiviert ist, treten nach der Standardisierung möglicherweise Übereinstimmungsfehler auf. Nach dem Neustart des Hosts zum Anwenden der standardisierten Änderungen ist das statusfreie Caching erfolgreich, aber Übereinstimmungsfehler treten weiterhin auf.

      Umgehung: Das Problem kann nicht umgangen werden.

    • Auf Hosts mit vielen Datenspeichern tritt beim Anwenden eines Hostprofils mit aktiviertem statusfreiem Caching eine Zeitüberschreitung ein
      Auf einem Host mit vielen Datenspeichern tritt beim Anwenden eines Hostprofils mit aktiviertem statusfreiem Caching eine Zeitüberschreitung ein.

      Umgehung: Verwenden Sie den vSphere-Client, um den Zeitüberschreitungswert zu erhöhen:

      1. Wählen Sie Administrator > vCenter Server-Einstellungen.
      2. Wählen Sie Zeitüberschreitungseinstellungen.
      3. Ändern Sie die Werte für "Normale Vorgänge" und "Lange Vorgänge" in 3600 Sekunden.

      1. Hostprofil kann nicht vom Host extrahiert werden, wenn auf vmknics IPv4 deaktiviert ist
        Wenn Sie alle IPv4-Adressen von allen vmknics entfernen, können Sie kein Hostprofil von diesem Host extrahieren. Diese Aktion betrifft vor allem Hosts, die mit Auto Deploy bereitgestellt wurden, da in dieser Umgebung die Hostkonfiguration nur über Hostprofile gespeichert werden kann.

        Umgehung: Weisen Sie einer IPv4-Adresse mindestens eine vmknic zu.

      2. Die Übernahme eines Hostprofils schlägt beim Anwenden eines von einem ESXi 4.1-Host extrahierten Hostprofils auf einen ESXi 5.1-Host fehl
        Wenn Sie einen Host mit ESXi 4.1 einrichten, ein Hostprofil von diesem Host (mit vCenter Server) extrahieren und versuchen, ein Profil an einem ESXi 5.1-Host anzuhängen, schlägt der Vorgang fehl, wenn Sie versuchen, das Profil anzuwenden. Möglicherweise wird die folgende Fehlermeldung angezeigt: NTP-Dienst ist deaktiviert.

        Der NTPD-Dienst wird möglicherweise auch dann ausgeführt (eingeschaltet), ohne dass in /etc/ntp.confein NTP-Server für ESXi 4.1 angegeben ist. ESXi 5.1 benötigt einen expliziten NTP-Server, damit der Dienst ausgeführt werden kann.

        Umgehung: Schalten Sie den NTP-Dienst ein, indem Sie zu /etc/ntp.confeinen gültigen NTP-Server hinzufügen, und starten Sie den NTP-Daemon auf dem 5.1-Host neu. Vergewissern Sie sich, dass nach dem Neustart der Dienst weiterhin ausgeführt wird. Dies Aktion gewährleistet, dass der NTP-Dienst für den Host und das Profil, das auf ihn angewendet wird, synchronisiert wurde.

      3. Das Hostprofil weist den Status "Nicht übereinstimmend" auf, nachdem das Profil erfolgreich übernommen wurde
        Dieses Problem tritt auf, wenn ein Hostprofil von einem ESXi 5.0-Host extrahiert und von einem ESXi 5.1-Host übernommen wurde, der ein lokales SAS-Gerät enthält. Selbst dann, wenn die Standardisierung des Hostprofils erfolgreich ist, wird die Übereinstimmung des Hostprofils als "Nicht übereinstimmend" angezeigt.

        Möglicherweise erhalten Sie Fehlermeldungen ähnlich der folgenden:

        • Der Spezifikationsstatus fehlt für den Host: Die Pfadauswahlrichtlinie des Geräts naa.500000e014ab4f70 muss auf VMW_PSP_FIXED festgelegt werden
        • Der Spezifikationsstatus fehlt für den Host: Geräteparameter naa.500000e014ab4f70 müssen auf State = "on" Queue Full Sample Size = "0" Queue Full Threshold = "0" festgelegt werden

        Das ESXi 5.1-Hostprofilspeicher-Plug-In filtert das lokale SAS-Gerät für die PSA- und NMP-Gerätekonfiguration heraus, während ESXi 5.0 solche Gerätekonfigurationen enthält. Dies führt dazu, dass ein Gerät fehlt, wenn das ältere Hostprofil von einem neueren Host übernommen wird.

        Umgehung: Bearbeiten Sie das Hostprofil manuell und entfernen Sie die PSA- und NMP-Gerätekonfigurationseinträge für alle lokalen SAS-Geräte. Sie können ermitteln, ob ein Gerät ein lokales SAS-Gerät ist, indem Sie den folgenden esxcli-Befehl eingeben:
        esxcli storage core device list

        Wenn die folgende Zeile zurückgegeben wird, handelt es sich bei dem Gerät um ein lokales SAS-Gerät:
        Ist lokales SAS-Gerät

      4. Standardmäßige Systemdienste starten immer auf ESXi-Hosts, die mit Auto Deploy bereitgestellt wurden
        Im Falle von ESXi-Hosts, die mit Auto Deploy bereitgestellt wurden, wird die Startrichtlinie für Dienste im Abschnitt "Dienstkonfiguration" des entsprechenden Hostprofils nicht ganz eingehalten. Insbesondere wenn einer der Dienste, die auf ESXi standardmäßig eingeschaltet sind, einen Wert für die Startrichtlinie von offaufweist, startet dieser Dienst nach wie vor zur Startzeit auf dem mit Auto Deploy bereitgestellten ESXi-Host.

        Umgehung: Stoppen Sie den Dienst manuell, nachdem Sie den ESXi-Host gestartet haben.

      5. Nach einem snmpd-Neustart erfolgt das Abrufen von Informationen von VMWARE-VMINFO-MIB nicht ordnungsgemäß
        Einige Informationen von VMWARE-VMINFO-MIB fehlen möglicherweise während SNMPWalk, nachdem Sie den snmpd-Daemon mithilfe von /etc/init.d/snmpd restartvon der ESXi Shell neu gestartet haben.

        Umgehung: Verwenden Sie /etc/init.d/snmpd restartnicht. Sie müssen zum Starten und Beenden des SNMP-Daemons den Befehl esxcli system snmp set --enableverwenden. Falls Sie /etc/init.d/snmpd restartverwendet haben, um snmpd von der ESXi Shell aus neu zu starten, starten Sie Hostd neu, entweder von der DCUI aus oder mithilfe von /etc/init.d/hostd restartvon der ESXi Shell aus.

      Probleme bei vCenter Server und dem vSphere-Client
      • Durch das Aktivieren oder Deaktivieren des View Storage Accelerator werden möglicherweise die Verbindungen von ESXi-Hosts mit vCenter Server unterbrochen
        Wenn VMware View mit vSphere 5.1 bereitgestellt wurde und ein View-Administrator View Storage Accelerator in einem Desktop-Pool aktiviert oder deaktiviert, werden möglicherweise die Verbindungen von ESXi 5.1-Hosts mit vCenter Server 5.1 unterbrochen.

        Die Funktion View Storage Accelerator wird auch "Content Based Read Caching" genannt. In der View Administrator-Konsole von View 5.1 wird diese Funktion als Host-Caching bezeichnet.

        Umgehung: Aktivieren oder deaktivieren Sie View Storage Accelerator nicht in mit vSphere 5.1 bereitgestellten View-Umgebungen.

      VM-Verwaltungsprobleme
      • Das Kompatibilitätsupgrade der virtuellen Maschine von ESX 3.x und höher (VM-Version 4) konfiguriert fälschlicherweise den Flexible-Adapter einer virtuellen Maschine unter Windows auf den Standardtreiber des Windows-Systems
        Wenn Sie ein Windows-Gastbetriebssystem mit einem Flexible-Netzwerkadapter haben, der für den VMware Accelerated AMD PCnet-Adaptertreiber konfiguriert ist, und ein Upgrade der Kompatibilität der virtuellen Maschine von ESX 3.x und höher (VM-Version 4) auf eine spätere Kompatibilitätseinstellung durchführen, beispielsweise ESXi 4.x und später (VM-Version 7), konfiguriert Windows den Flexible-Adapter auf den Standardtreiber Windows AMD PCNET Family PCI Ethernet Adapter.
        Diese Fehlkonfiguration tritt auf, weil die VMware Tools-Treiber keine Signatur haben und Windows den Windows-Standardtreiber mit Signatur auswählt. Die Netzwerkeinstellungen des Flexible-Adapters, die vor dem Kompatibilitätsupgrade vorhanden waren, gehen verloren. Die Netzwerkgeschwindigkeit der Netzwerkkarte ändert sich von 1 GBit/s auf 10 MBit/s.

        Umgehung: Konfigurieren Sie die Flexible-Netzwerkadapter so, dass sie den VMXNET-Treiber des Windows-Gastbetriebssystems verwenden, wenn Sie ein Upgrade der Kompatibilität der virtuellen Maschine vornehmen. Wenn Ihr Gastbetriebssystem mit ESXi5.1 VMware Tools aktualisiert ist, wird der VMXNET-Treiber an folgendem Standort installiert: C:\Programme\Common Files\VMware\Drivers\vmxnet\.

      • Wenn Sie VMware Tools auf einer virtuellen Maschine installieren und einen Neustart durchführen, wird das Netzwerk unbrauchbar
        Auf virtuellen Maschinen mit dem CentOS 6.3-Betriebssystem oder dem Oracle Linux 6.3-Betriebssystem wird das Netzwerk unbrauchbar, wenn VMware Tools ordnungsgemäß installiert und die virtuelle Maschine neu gestartet wurde. Wenn Sie versuchen, die IP-Adresse von einem DHCP-Server manuell abzurufen oder eine statische IP-Adresse über die Befehlszeile festzulegen, wird die Fehlermeldung Es konnte kein Arbeitsspeicher zugeteilt werdenangezeigt.
        Das Problem ist, dass der Flexible-Netzwerkadapter, der standardmäßig verwendet wird, keine gute Wahl für diese Betriebssysteme ist.

        Umgehung: Ändern Sie den Netzwerkadapter von Flexible in E1000 oder VMXNET 3 wie folgt:

        1. Führen Sie den Befehl vmware-uninstall-tools.plaus, um VMware Tools zu deinstallieren.
        2. Schalten Sie die virtuelle Maschine aus.
        3. Klicken Sie im vSphere Web Client mit der rechten Maustaste auf die virtuelle Maschine und wählen Sie Einstellungen bearbeiten.
        4. Klicken Sie auf "Virtuelle Hardware" und entfernen Sie den aktuellen Netzwerkadapter, indem Sie auf das Symbol "Entfernen" klicken.
        5. Fügen Sie einen neuen Netzwerkadapter hinzu und wählen Sie den Adaptertyp E1000 oder VMXNET 3 aus.
        6. Schalten Sie die virtuelle Maschine ein.
        7. VMware Tools neu installieren.

      • Klon- oder Migrationsvorgänge unter Verwendung virtueller Nicht-VMFS-Festplatten auf ESXi schlagen mit einer Fehlermeldung fehl
        Unabhängig davon, ob Sie den vmkfstools-Befehl oder den Client verwenden, um einen Klon-, Kopier- oder Migrationsvorgang auf den virtuellen Laufwerken von gehosteten Formaten durchzuführen, schlägt der Vorgang mit der folgenden Fehlermeldung fehl: Das System kann die angegebene Datei nicht finden.

        Umgehung: Um einen Klon-, Kopier- oder Migrationsvorgang auf den virtuellen Festplatten der gehosteten Formate durchzuführen, müssen Sie das VMkernel-multiextent-Modul in ESXi laden.

        1. Melden Sie sich bei der ESXi Shell an und laden Sie das multiextent-Modul.
          # vmkload_mod multiextent
        2. Überprüfen Sie, ob Ihre VM-Festplatten vom Typ "gehostet" sind. Gehostete Festplatten enden mit der Erweiterung -s00x.vmdk.
        3. Konvertieren Sie alle virtuellen Festplatten im gehosteten Format in eines der VMFS-Formate.
          1. Klonen Sie die gehostete Quellfestplatte "test1.vmdk nach test2.vmdk".
            # vmkfstools -i test1.vmdk test2.vmdk -d zeroedthick|eagerzereodthick|thin
          2. Löschen Sie nach dem erfolgreichen Klonvorgang die gehostete Festplatte "test1.vmdk".
            # vmkfstools -U test1.vmdk
          3. Benennen Sie die geklonte VMFS-Festplatte "test2.vmdk" in "test1.vmdk" um.
            # vmkfstools -E test2.vmdk test1.vmdk
        4. Entladen Sie das multiextent-Modul.
          #vmkload_mod -u multiextent

      • Einer virtuellen Maschine ist keine IP-Adresse zugewiesen und sie erscheint nicht betriebsbereit
        Dieses Problem wird durch eine LUN-Rückstellungsanforderung bewirkt, die von einem Gastbetriebssystem ausgeht. Dieses Problem gilt speziell für das IBM XIV Fibre Channel-Array, wenn die Software FCoE in ESXi-Hosts konfiguriert ist. Virtuelle Maschinen, die in der LUN untergebracht sind, weisen folgende Probleme auf:

        • Den virtuellen Maschinen ist keine IP-Adresse zugewiesen.
        • Die virtuellen Maschinen können nicht ein- und ausgeschaltet werden.
        • In der Konsole wird kein Mauszeiger angezeigt. Daher kann die virtuelle Maschine im Gastbetriebssystem weder gesteuert noch bedient werden.

        Umgehung: Setzen Sie aus dem ESXi-Host die LUN zurück, auf der die virtuellen Maschinen untergebracht sind, die das Problem aufweisen.

        1. Führen Sie den folgenden Befehl aus, um die LUN-Informationen zu erhalten:
          # vmkfstools -P /vmfs/volumes/ DATASTORE_NAME
        2. Suchen Sie nach der folgenden Zeile in der Ausgabe, um die UID der LUN zu erhalten:
          Partitions spanned (on 'lvm'): eui.001738004XXXXXX:1
          eui.001738004XXXXXXist die Geräte-UID.
        3. Führen Sie den folgenden Befehl aus, um die LUN zurückzusetzen:
          # vmkfstools -L lunreset /vmfs/devices/disks/eui.001738004XXXXXX
        4. Wenn eine nicht reagierende virtuelle Maschine in einem Datenspeicher liegt, dem mehrere LUNs zugewiesen sind, beispielsweise hinzugefügte Erweiterungen, führen Sie die LUN-Rückstellung für alle Datenspeichererweiterungen durch.

      Migrationsprobleme
      • Versuche, Storage vMotion zum Migrieren von mehreren virtuellen Linked-Clone-Maschinen zu verwenden, schlagen fehl
        Dieser Fehler betrifft in der Regel virtuelle Linked-Clone-Maschinen. Dieser Fehler tritt auf, wenn die Größe von Delta-Festplatten 1 MB beträgt und die CBRC-Funktion (Content Based Read Cache) in ESXi-Hosts aktiviert wurde. Die folgende Fehlermeldung wird angezeigt: Die Quelle hat erkannt, dass das Ziel nicht fortgesetzt werden konnte.

        Umgehung: Verwenden Sie eine der folgenden Methoden, um Storage vMotion-Ausfälle zu vermeiden:

        • Verwenden Sie 4 KB als die Größe von Delta-Festplatten.

        • Anstatt Storage vMotion zu verwenden, migrieren Sie ausgeschaltete virtuelle Maschinen auf einen neuen Datenspeicher.

      VMware HA- und Fault Tolerance-Probleme
      • Fehlertolerante virtuelle Maschinen stürzen ab, wenn sie für das Erfassen von Statistikinformationen auf einem vCenter Server-Beta-Build eingerichtet sind
        Die vmx*3-Funktion ermöglicht es Benutzern, "stats vmx" zum Erfassen von Leistungsstatistiken für das Debuggen von Supportproblemen auszuführen. Wenn Fault Tolerance auf einem vCenter Server-Beta-Build aktiviert ist, ist "stats vmx" nicht kompatibel.

        Umgehung: Vergewissern Sie sich beim Aktivieren von Fault Tolerance, dass die virtuelle Maschine nicht für das Erfassen von Statistikinformationen auf einem vCenter Server-Beta-Build eingerichtet ist.

      Probleme bei unterstützter Hardware
      • Der PCI-Status Unbekannt Unbekanntwird in vCenter Server auf dem Apple Mac Pro-Server angezeigt
        Auf der Registerkarte "Hardwarestatus" in vSphere 5.1 wird für einige PCI-Geräte auf dem Apple Mac Pro Unbekannt Unbekanntangezeigt. Dies ist auf fehlende Hardwarebeschreibungen für diese PCI-Geräte auf dem Apple Mac Pro zurückzuführen. Der Anzeigefehler auf der Registerkarte "Hardwarestatus" hindert diese PCI-Geräte nicht daran, ordnungsgemäß zu funktionieren.

        Umgehung: Keine.

      • Der PCI-Status Unbekannt Unbekanntwird in vCenter Server auf dem AMD PileDriver angezeigt
        Auf der Registerkarte "Hardwarestatus" in vSphere 5.1 wird für einige PCI-Geräte auf dem AMD PileDriver Unbekannt Unbekanntangezeigt. Dies ist auf fehlende Hardwarebeschreibungen für diese PCI-Geräte auf dem AMD PileDriver zurückzuführen. Der Anzeigefehler auf der Registerkarte "Hardwarestatus" hindert diese PCI-Geräte nicht daran, ordnungsgemäß zu funktionieren.

        Umgehung: Keine.

      • DPM wird auf dem Apple Mac Pro-Server nicht unterstützt
        Die Distributed Power Management-Funktion (DPM) von vSphere 5.1 wird auf dem Apple Mac Pro nicht unterstützt. Fügen Sie den Apple Mac Pro nicht zu einem Cluster hinzu, bei dem DPM aktiviert ist. Wenn der Host in den Zustand "Standby" wechselt, kann er den Standby-Zustand nicht beenden, wenn der Befehl zum Einschalten ausgegeben wird, und zeigt die Fehlermeldung Zeitüberschreitung beim Vorgangan. Der Apple Mac Pro wird nicht wieder aktiviert, wenn der Softwarebefehl zum Ausschalten, der von vSphere zum Versetzen eines Hosts in den Standby-Zustand verwendet wird, ausgegeben wird.

        Umgehung: Wenn der Apple Mac Pro-Host in den Zustand "Standby" wechselt, müssen Sie den Host wieder einschalten, indem Sie den Schalter zum Einschalten betätigen.

      • IPMI wird auf dem Apple Mac Pro-Server nicht unterstützt
        Auf der Registerkarte "Hardwarestatus" in vSphere 5.1 werden die richtigen Daten nicht angezeigt oder Daten für einige der Hardwarekomponenten auf dem Apple Mac Pro fehlen. Dies liegt daran, dass IPMI nicht für den Apple Mac Pro unterstützt wird.

        Umgehung: Keine.

      Sonstige Probleme
      • Nach einer Netzwerk- oder Speicherunterbrechung starten syslog über TCP, syslog über SSL und die Speicherprotokollierung nicht automatisch neu
        Nach einer Netzwerk- oder Speicherunterbrechung startet der syslog-Dienst in bestimmten Konfigurationen nicht automatisch neu. Zu diesen Konfigurationen gehören syslog über TCP, syslog über SSL und der Interrupt "Speicherprotokollierung".

        Umgehung: Starten Sie syslog explizit neu, indem Sie den folgenden Befehl ausführen:
        esxcli system syslog reloadSie können auch syslog über UDP konfigurieren, was automatisch neu gestartet wird.

      • Windows Server 2012-Failover-Clustering wird nicht unterstützt
        Wenn Sie versuchen, einen Cluster für das Failover-Clustering in Windows Server 2012 zu erstellen, und angeben, dass Sie Validierungstests durchführen möchten, werden die Validierungstests mit Warnungen durchgeführt und danach werden die Validierungstests erneut durchgeführt. Der Assistent unter dem Gastbetriebssystem Windows Server 2012 setzt das Erstellen von Clustern nicht weiter fort.

        Umgehung: Keine.