ESXi 5.0 Update 3 | 17. Oktober 2013 | Build 1311175

Letzte Aktualisierung: 31. Okt. 2013

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

Neuigkeiten

Sie erhalten nachstehend Informationen zu einigen der Verbesserungen in der vorliegenden Version von VMware ESXi:

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

Vorherige Versionen von ESXi 5.0

Die Funktionen und bekannten Probleme von ESXi 5.0 werden in den entsprechenden Versionshinweisen beschrieben. Wenn Sie Versionshinweise vorheriger Versionen von ESXi 5.0 anzeigen möchten, klicken Sie auf einen der folgenden Links:

Internationalisierung

VMware vSphere 5.0 Update 3 gibt es in den folgenden Sprachen:

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

Erzwingen des Gebietsschemas vom vSphere-Client

Bei vSphere 5.0 Update 3 können Sie den VMware vSphere-Client so konfigurieren, dass der Text der Benutzerschnittstelle auf Englisch erscheint, selbst wenn der Computer, auf dem er läuft, nicht auf Englisch ist. Diese Konfiguration kann durch Angabe eines Befehlszeilenparameters für die Dauer einer einzelnen Sitzung erfolgen. Diese Konfiguration gilt für die Texte der Benutzerschnittstelle. Sie gilt nicht für andere Einstellungen des Gebietsschemas, wie z. B. für Datum und Uhrzeit oder für das Formatieren von numerischen Angaben.

Der folgende vSphere-Client-Befehl sorgt dafür, dass eine einzelne Sitzung auf Englisch erscheint:

vpxClient -locale en_US

Kompatibilität und Installation

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

Die VMware-Produkt-Interoperabilitätsmatrix liefert Details zur Kompatibilität aktueller und vorheriger Versionen von VMware vSphere-Komponenten, einschließlich ESXi, VMware vCenter Server, vSphere-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.0.3 bietet Unterstützung für die Versionen ESXi 5.0 Update 3 und vCenter Server 5.0 Update 3. Weitere Informationen zu VDDK finden Sie unter https://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.0 Update 3 kompatibel sind, lesen Sie die Informationen zu ESXi 5.0 Update 3 im VMware-Kompatibilitätshandbuch.

Upgrades und Installationen für unterstützte CPUs: vSphere 5.0 Update 3 unterstützt nur CPUs mit LAHF- und SAHF-Befehlssätzen. Während einer Installation oder eines Upgrades wird eine Prüfung auf die Kompatibilität der Host-CPU mit vSphere 5.0 Update 3 durchgeführt. Weitere Informationen zur CPU-Unterstützung finden Sie im VMware-Kompatibilitätshandbuch.

Kompatibilität von Gastbetriebssystemen für ESXi

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

Kompatibilität von virtuellen Maschinen für ESXi

Virtuelle Maschinen mit virtueller Hardware der Version 4.0 und höher werden von ESXi 5.0 Update 3 unterstützt. Die Hardwareversion 3 wird nicht mehr unterstützt. Wenn Sie virtuelle Maschinen der Hardwareversion 3 unter ESXi 5.0 Update 3 verwenden möchten, müssen Sie ein Upgrade der virtuellen Hardware durchführen. Weitere Informationen finden Sie in der Dokumentation vSphere-Upgrade.

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.

Nach der erfolgreichen Installation müssen Sie einige Lizenzierungs-, Netzwerk- und Sicherheitskonfigurationsaufgaben durchführen. Beachten Sie die folgenden Handbücher in der vSphere-Dokumentation für weitere Informationen zu diesen Konfigurationsaufgaben.

 

Migrieren von Drittanbieter-Lösungen

ESX/ESXi-Hosts enthalten möglicherweise Drittanbieter-Software, wie z. B. Cisco Nexus 1000V VEMs oder EMC PowerPath-Module. Die ESXi 5.0-Architektur hat sich seit ESX/ESXi 4.x geändert, sodass angepasste Software-Pakete von Drittanbietern (VIBs) nicht migriert werden können, wenn Sie ein Upgrade von ESX/ESXi 4.x auf ESXi 5.0 und höher durchführen.
Wenn Sie einen 4.x-Host mit benutzerdefinierten VIBs aktualisieren, die nicht in der Upgrade-ISO vorkommen, können Sie mit dem Upgrade fortfahren, erhalten allerdings eine Fehlermeldung, die die fehlenden VIBs auflistet. Für ein erfolgreiches Upgrade bzw. eine erfolgreiche Migration solcher Hosts müssen Sie Image Builder zum Erstellen eines benutzerdefinierten ESXi-ISO-Images mit den fehlenden VIBs verwenden. Wenn Sie ein Upgrade ohne die Drittanbieter-Software durchführen möchten, verwenden Sie die Option ForceMigrateoder wählen Sie die Option zum Entfernen von Drittanbieter-Softwaremodulen während des Standardisierungvorgangs im vSphere Update Manager. Weitere Informationen zur Erstellung einer benutzerdefinierten ISO-Datei mithilfe von Image Builder finden Sie im Installations- und Einrichtungshandbuch für vSphere. Informationen zur Durchführung von Upgrades mit Anpassungen von Drittanbietern finden Sie in den Handbüchern vSphere-Upgrade und Installieren und Verwalten von VMware vSphere Update Manager. Informationen zur Durchführung von Upgrades mit vSphere Update Manager finden Sie in den Handbüchern vSphere-Upgrade und Installieren und Verwalten von VMware vSphere Update Manager.

Auf L3 geroutete NFS-Speicherzugriffe

vSphere 5.0 Update 3 unterstützt L3-geroutete NFS-Speicherzugriffe, wenn Ihre Umgebung die folgenden Bedingungen erfüllt:
  • Das HSRP-Protokoll von Cisco (Hot Standby Router Protocol) wird im IP-Router verwendet. Falls Sie einen anderen Router als den von Cisco verwenden, stellen Sie sicher, dass Sie das VRRP-Protokoll (Virtual Router Redundancy Protocol) verwenden.
  • QoS (Quality of Service) wird für die Priorisierung des NFS L3-Datenverkehrs auf Netzwerken mit begrenzter Bandbreite oder auf überlasteten Netzwerken verwendet. Weitere Informationen hierzu finden Sie in der Dokumentation des Routers.
  • Befolgen Sie die von Ihrem Speicheranbieter empfohlenen Best Practices für NFS L3. Weitere Informationen erhalten Sie von Ihrem Speicheranbieter.
  • Deaktivieren der Netzwerk-E/A-Ressourcenverwaltung (NetIORM)
  • Falls Sie vorhaben, Systeme mit Top-of-Rack-Switches oder der Switch-abhängigen E/A-Gerätepartitionierung einzusetzen, wenden Sie sich bezüglich Kompatibilität und Unterstützung an Ihren Systemanbieter.
Für eine L3-Umgebung gelten die folgenden zusätzlichen Einschränkungen:
  • Die Umgebung unterstützt VMware Site Recovery Manager nicht.
  • Die Umgebung unterstützt nur das NFS-Protokoll. Verwenden Sie keine anderen Speicherprotokolle, wie z. B. FCoE, in demselben physischen Netzwerk.
  • Der NFS-Datenverkehr in dieser Umgebung unterstützt IPv6 nicht.
  • Der NFS-Datenverkehr in dieser Umgebung kann nur über ein LAN geleitet werden. Andere Umgebungen, wie z. B. WAN, werden nicht unterstützt.
  • Die Umgebung unterstützt keine verteilten virtuellen Switches.

Upgrades für diese Version

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

Aktualisieren der VMware Tools

VMware ESXi 5.0 Update 3 enthält die neueste Version von VMware Tools. VMware Tools ist eine Reihe von Dienstprogrammen, welche die Leistung des Gastbetriebssystems der virtuellen Maschine verbessern. Eine Liste der Probleme, die in dieser ESX-Version im Zusammenhang mit VMware Tools behoben wurden, finden Sie unter Behobene Probleme für VMware Tools.

Informationen zum Ermitteln der installierten VMware Tools-Version finden Sie in der Knowledgebase unter Verifizieren einer Build-Version der VMware Tools (KB 1003947).

ESX/ESXi-Upgrades

Sie haben verschiedene Möglichkeiten, ESX/ESXi-Hosts auf ESXi 5.0 Update 3 zu aktualisieren.

  • vSphere Update Manager. Wenn auf Ihrer Site vCenter Server eingesetzt wird, führen Sie mithilfe von vSphere Update Manager ein koordiniertes Host-Upgrade oder ein koordiniertes Upgrade von virtuellen Maschinen von ESX/ESXi 4.0, 4.1 und ESXi 5.0 durch. Weitere Informationen finden Sie im Handbuch vSphere-Upgrade. Eine umfassende Dokumentation zu vSphere Update Manager finden Sie im Handbuch Installieren und Verwalten von VMware vSphere Update Manager.

  • Durchführung eines interaktiven Upgrades mithilfe eines ESXi-Installations-ISO-Image auf CD-ROM oder DVD. Sie können das ESXi 5.0 Update 3-Installationsprogramm von einem CD-ROM- oder DVD-Laufwerk aus starten, um ein interaktives Upgrade durchzuführen. Diese Methode eignet sich für das Durchführen eines Upgrades für eine kleine Anzahl von Hosts.

  • Durchführen eines skriptbasierten Upgrades. Sie können ein Upgrade oder eine Migration von ESXi/ESX 4.x-Hosts auf ESXi 5.0 Update 3 durchführen, indem Sie ein Update-Skript ausführen. Dies ermöglicht ein effizientes, unbeaufsichtigtes Update. 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.

  • ESXCLI: Sie können mithilfe des esxcli-Befehlszeilendienstprogramms ESXi 5.x-Hosts aktualisieren und Patches anwenden. Es ist nicht möglich, esxcli zum Aktualisieren von ESX/ESXi 4.x-Hosts auf ESXi 5.0 Update 3 zu verwenden.
Unterstützte Upgrade-Pfade für das Upgrade auf ESXi 5.0 Update 3:

Upgrade-Lieferumfang

Unterstützte Upgrade-Tools

Unterstützte Upgrade-Pfade auf ESXi 5.0 Update 3

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:
Dazu gehören
ESX 4.1 Update 1
ESX 4.1 Update 2

ESX 4.1 Update 3

 

ESXi 4.1 :
Dazu gehören
ESXi 4.1 Update 1

ESXi 4.1 Update 2
ESXi 4.1 Update 3

ESXi 5.0:
Umfasst
ESXi 5.0 Update 1
ESXi 5.0 Update 2

VMware-VMvisor-Installer-5.0.0.update03-1311175.x86_64.iso

 

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

Ja

Ja

Ja

Ja

Ja*

update-from-esxi5.0-5.0_update03.zip
  • VMware vCenter Update Manager
  • ESXCLI
  • VMware vSphere-CLI

Nein

Nein

Nein

Nein

Ja

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

VMware vCenter Update Manager mit Patch-Baseline

Nein

Nein

Nein

Nein

Ja

* Hinweis: Das Upgrade von ESXi 5.0 mithilfe der Datei VMware-VMvisor-Installer-5.0.0.update03-1311175.x86_64.isomit VMware vCenter Update Manager wird nicht unterstützt. Sie müssen stattdessen das Upgrade mithilfe von update-from-esxi5.0-5.0_update03.zipund VMware vCenter Update Manager durchführen.

Der Lieferumfang von vSphere 5.0 Update 3 kann nicht für die Kompatibilität des Upgrade-Pfades von vSphere 5.1 gewährleistet werden.

VMware vSphere SDKs

VMware vSphere bietet einen Satz von SDKs für vSphere-Server- und Gastbetriebssystemumgebungen.

  • vSphere Management SDK. Eine Sammlung von Software Development Kits für die vSphere Management-Programmierumgebung. Das vSphere Management SDK enthält die folgenden vSphere-SDKs:

    • vSphere Web Services SDK. Enthält Unterstützung für neue Funktionen in ESXi 5.0 und höher sowie für die Serversysteme vCenter Server 5.0 und höher. Sie können dieses SDK auch mit vorherigen Versionen von ESX/ESXi und vCenter Server verwenden. Weitere Informationen finden Sie in der Dokumentation zu VMware vSphere Web Services SDK.

    • vSphere vCenter Storage Monitoring Service (SMS) SDK. SMS 2.0 wird von vCenter Server 5.0 unterstützt. Weitere Informationen finden Sie in der Dokumentation zu vCenter SMS SDK.

    • vSphere ESX Agent Manager (EAM) SDK. EAM 1.0 wird von ESXi 5.0 Update 3 unterstützt. Weitere Informationen finden Sie in der Dokumentation zu vSphere ESX Agent Manager.

  • vSphere Guest SDK. VMware vSphere Guest SDK 4.0 wird von ESXi 5.0 Update 3 unterstützt. Weitere Informationen finden Sie in der Dokumentation zu VMware vSphere Guest SDK.

  • VMware vSphere SDK for Perl. SDK for Perl 5.0 wird von vSphere 5.0 Update 3 unterstützt. Weitere Informationen finden Sie in der Dokumentation zu vSphere SDK for Perl.

Open Source-Komponenten für VMware vSphere

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

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

ESXi500-201310201-UG: Aktualisiert das ESXi 5.0 esx-base-Vib
ESXi500-201310202-UG: Aktualisiert das ESXi 5.0 tools-light-Vib
ESXi500-201310203-UG: Aktualisiert das ESXi 5.0 misc-drivers-Vib
ESXi500-201310204-UG: Aktualisiert das ESXi 5.0 scsi-hpsa vib

Patch-Version ESXi500-Update03 Security-only enthält die folgenden einzelnen Bulletins:

ESXi500-201310101-SG: Aktualisiert das ESXi 5.0 esx-base-Vib

ESXi500-201310102-SG: Aktualisiert das ESXi 5.0 net-bnx2x vib
ESXi500-201310103-SG: Aktualisiert das ESXi 5.0 misc-drivers vib

Die Patch-Version ESXi500-Update03 enthält die folgenden Image-Profile:

ESXi-5.0.0-20131002001-standard

ESXi-5.0.0-20131002001-no-tools

Die Patch-Version ESXi500-Update03 Security-only enthält die folgenden Image-Profile:

ESXi-5.0.0-20131001001s-standard
ESXi-5.0.0-20131001001s-no-tools


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

Behobene Probleme

In diesem Abschnitt werden die behobenen Probleme dieser Version unter den folgenden Themengebieten beschrieben:

CIM und API

  • Small-Footprint CIM Broker Daemon reagiert möglicherweise nicht mehr, wenn der CIM-Anbieter fehlschlägt
    Small-Footprint CIM Broker Daemon (sfcbd) reagiert möglicherweise auf einem ESXi-Host nicht mehr, wenn der CIM-Anbieter während der Zeitüberschreitung fehlschlägt.

    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. Dadurch reagiert sfcb-hhrcmöglicherweise nicht mehr, und sfcbdwird neu gestartet. Die syslog-Protokolldatei enthält möglicherweise Meldungen ähnlich den folgenden:

    sfcb-LSIESG_SMIS13_HHR[ ]: Error opening socket pair for getProviderContext: Too many open files
    sfcb-LSIESG_SMIS13_HHR[ ]: Failed to set recv timeout (30) for socket -1. Errno = 9
    ...
    ...

    sfcb-hhrc[ ]: Timeout or other socket error
    sfcb-hhrc[ ]: TIMEOUT DOING SHARED SOCKET RECV RESULT ( )


    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die WS-Management GetInstance ()-Aktion für "http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_SoftwareIdentity?InstanceID=46.10000" liefert möglicherweise den Fehler wsa:DestinationUnreachable auf einigen ESXi-Servern
    Die WS-Management GetInstance ()-Aktion für "http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_SoftwareIdentity?InstanceID=46.10000" liefert 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.
  • 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/logbefindet, 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.
  • 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 zeigt möglicherweise Einträge ähnlich der folgenden an:

    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]: Timeout or other socket error


    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der CIM-Server gibt einen falschen PerceivedSeverity-Wert für die Anzeige zurück
    Wenn IBM Systems Director (ISD) für das Überwachen des ESX-Servers verwendet wird, gibt der CIM-Server einen falschen PerceivedSeverity-Wert für die Anzeige an ISD zurück. Eine Korrektur des Sensortyps und des PerceivedSeverity-Rückgabewerts behebt das Problem.

    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.
  • 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. Error:Timeout (or other socket error) waiting for response from provider.

  • Dieses Problem wurde in der vorliegenden Version behoben.

Sonstige Probleme

  • Netlogond reagiert 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 Active Directory-Funktionalität.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Sie können möglicherweise keinen HA-Cluster (High Availability) aktivieren, nachdem ein einzelner Host desselben HA-Clusters 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.
  • Der ESXi-Host zeigt falsche Werte für den resourceCpuAllocMax-Systemindikator
    Wenn Sie versuchen, den Wert für die Systemindikatoren resourceCpuAllocMaxund resourceMemAllocMaxüber die Optionen Leistung >> Erweiterte Leistungsdiagramme >> Systemdiagramm 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.
  • 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 c0
    0030: 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.
  • Die Fehlermeldungen des Arbeitsspeicher-Controllers werden möglicherweise falsch als TLB-Fehler angegeben, wenn ESXi-Hosts mit einem violetten Bildschirm fehlschlagen
    Wenn ESXi-Hosts mit einem violetten Bildschirm fehlschlagen, werden die Fehlermeldungen des Arbeitsspeicher-Controllers möglicherweise falsch als TLB-Fehlermeldungen (Translation Look-aside Buffer), Level 2 TLB Errorangezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben.

Netzwerk

  • Der ESXi-Host kann möglicherweise keine Konfigurationsprobleme melden, wenn die Core-Dump-Partition und der Core-Dump-Collector-Dienst nicht konfiguriert sind
    Wenn ein ESX-Host nicht mit einer Core-Dump-Partition konfiguriert ist und nicht so konfiguriert ist, dass er Core-Dumps auf einen Dump-Collector-Dienst weiterleitet, dann gehen möglicherweise wichtige Informationen zur Behandlung von Problemen verloren. Die Aufnahme einer Prüfung für die Konfiguration und Core-Dump-Partition beim Start des hostd-Dienstes behebt dieses Problem.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • ESXi-Hosts, die im statusfreien Modus gestartet wurden, werden mit dem Namen "localhost" in der syslog-Datei angezeigt
    Wenn ein statusfreier ESXi-Host erneut gestartet wurde und der Host konfiguriert wurde, um die DNS-Konfiguration und den Hostnamen von einem DHCP-Server zu erhalten, zeigt die syslog-Datei den Hostnamen als "localhost" an anstatt als Hostnamen, der vom DHCP-Server erhalten wurde. Infolgedessen scheinen alle ESXi-Hosts für einen Remote-Syslog Collector denselben Hostnamen zu haben.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESXi-Host schlägt möglicherweise mit einem violetten Bildschirm fehl und zeigt einen Ausnahmefehler für die Auslagerungsdatei an
    Wenn virtuelle Maschinen mit e1000-Netzwerkadaptern konfiguriert werden, schlagen ESXi-Hosts mit einem violetten Diagnosebildschirm fehl und zeigen Meldungen ähnlich der folgenden an:

    @BlueScreen: #PF Exception 14 in world 8229:idle37 IP 0x418038769f23 addr 0xc
    0x418038600000 VMK uptime: 1:13:10:39.757
    0x412240947898:[0x418038769f23]E1000FinalizeZeroCopyPktForTx@vmkernel#nover+0x1d6 stack: 0x41220000
    0x412240947ad8:[0x41803877001e]E1000PollTxRing@vmkernel#nover+0xeb9 stack: 0x41000c958000
    0x412240947b48:[0x418038771136]E1000DevAsyncTx@vmkernel#nover+0xa9 stack: 0x412240947bf8
    0x412240947b98:[0x41803872b5f3]NetWorldletPerVMCB@vmkernel#nover+0x8e stack: 0x412240947cc0
    0x412240947c48:[0x4180386ed4f1]WorldletProcessQueue@vmkernel#nover+0x398 stack: 0x0
    0x412240947c88:[0x4180386eda29]WorldletBHHandler@vmkernel#nover+0x60 stack: 0x2
    0x412240947ce8:[0x4180386182fc]BHCallHandlers@vmkernel#nover+0xbb stack: 0x100410000000000
    0x412240947d28:[0x4180386187eb]BH_Check@vmkernel#nover+0xde stack: 0xf2d814f856ba
    0x412240947e58:[0x4180387efb41]CpuSchedIdleLoopInt@vmkernel#nover+0x84 stack: 0x412240947e98
    0x412240947e68:[0x4180387f75f6]CpuSched_IdleLoop@vmkernel#nover+0x15 stack: 0x70
    0x412240947e98:[0x4180386460ea]Init_SlaveIdle@vmkernel#nover+0x13d stack: 0x0
    0x412240947fe8:[0x4180389063d9]SMPSlaveIdle@vmkernel#nover+0x310 stack: 0x0

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Standard-Gateway ist leer, wenn die Portgruppe, die das Standard-Gateway enthält, deaktiviert und dann erneut aktiviert wird
    Wenn Sie eine DHCP-aktivierte Portgruppe deaktivieren, die das Standard-Gateway enthält, ist das Standard-Gateway leer. Wenn Sie die Portgruppe erneut aktivieren, ist das Standard-Gateway leer.

    Dieses Problem wurde in der vorliegenden Version behoben. Das Standard-Gateway wird aktualisiert und ist nicht leer.
  • ESXi-Hosts schlagen möglicherweise mit einem violetten Bildschirm fehl, wenn der Netzwerkverkehr durch den bnx2x-Gerätetreiber läuft
    Wenn der Netzwerkverkehr durch den bnx2x-Gerätetreiber läuft und vmklinux generierte Pakete von Large Receive Offload (LRO) erhält, werden die Pakete im Netzwerk möglicherweise verworfen, was zu einem Fehler der ESXi-Hosts mit einem violetten Bildschirm führt.
    Bei den ESXi-Hosts tritt während der TSO-Teilung eine Ausnahme des Typs "Division durch null" auf und endet schließlich in einem Hostausfall.
    Dieses Problem tritt auf, wenn der bnx2x-Treiber das LRO-Paket mit einem MSS-Wert von TCP Segmentation Offload (TSO) sendet, der auf Null gesetzt ist.
    Der ESXi-Host schlägt auch fehl, wenn das empfangene Paket aus einem der nachfolgenden Gründe ungültig ist:
    • Wenn die GSO-Größe Null ist
    • Wenn der GSO-Typ nicht unterstützt wird
    • Wenn die vLAN-ID falsch ist

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESXi-Host fällt möglicherweise aufgrund eines Problems zwischen zwei DVFilter-Vorgängen mit einem violetten Diagnosebildschirm aus
  • Wenn zwei DVFilter-Prozesse versuchen, gleichzeitig eine einzelne Konfigurationsvariable zu verwalten, während ein Prozess die bestehende Filterkonfiguration freigibt und der andere Prozess versucht, sie zu sperren, führt dies möglicherweise zu einem ESXi-Hostausfall. Dieses Problem tritt auf, wenn Sie das Gastbetriebssystem während des DVFilter-Freigabevorgangs ausschalten.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • Ein Snapshot, der auf einer virtuellen Maschine mit vmxnet3-Netzwerkkarte erstellt wurde, hat falsche Netzwerkverkehrsstatistiken
    Wenn Sie einen Snapshot einer virtuellen Maschine mit vmxnet3-Netzwerkkarte erstellen, wird die Netzwerkschnittstelle der virtuellen Maschine getrennt und erneut verbunden, was den Broadcast-Indikator zurücksetzt und zu einer falschen Darstellung von Netzwerkstatistiken führt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • ESXi-Hosts schlagen aufgrund der Wettlaufsituationen im ESXi-TCP/IP-Stapel möglicherweise mit einem violetten Bildschirm fehl
    ESXi-Hosts schlagen möglicherweise mit einem violetten Bildschirm fehl und zeigen Fehlermeldungen ähnlich der folgenden an:
    2013-02-22T15:33:14.296Z cpu8:4104)@BlueScreen: #PF Exception 14 in world 4104:idle8 IP 0x4180083e796b addr 0x1
    2013-02-22T15:33:14.296Z cpu8:4104)Code start: 0x418007c00000 VMK uptime: 58:11:48:48.394
    2013-02-22T15:33:14.298Z cpu8:4104)0x412200207778:[0x4180083e796b]ether_output@ # +0x4e stack: 0x41000d44f360
    2013-02-22T15:33:14.299Z cpu8:4104)0x4122002078b8:[0x4180083f759d]arpintr@ # +0xa9c stack: 0x4100241a4e00

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

    Dieses Problem wurde in der vorliegenden Version behoben.
  • NFS-Datenspeicher, die über ein geroutetes Layer-3-Netzwerk verbunden sind, weisen möglicherweise eine hohe durchschnittliche Latenz des Gastbetriebssystems für virtuelle Maschinen auf, die darauf für geringe E/A-Vorgänge pro Sekunde ausgeführt werden
    Wenn NFS-Datenspeicher durch eine geroutete Layer-3-Schnittstelle verbunden sind und sich die NFS-vmknic in einem anderen Subnetz als die NFS-Dateien befindet, weisen die Datenspeicher möglicherweise eine hohe durchschnittliche Latenz des Gastbetriebssystems für virtuelle Maschinen auf, die darauf für geringe E/A-Vorgänge pro Sekunde ausgeführt werden. Dieses Problem tritt auf, wenn die E/A-Vorgänge für Sekunde gering sind. Für IOPS-Werte von 1 oder niedriger weisen die NFS-Datenspeicher möglicherweise eine hohe durchschnittliche Latenz des Gastbetriebssystems von 40 ms auf. Wenn eine hohe E/A-Arbeitslast gesendet wird, sinken die Werte der durchschnittlichen Latenz des Gastbetriebssystems für die NFS-Datenspeicher.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Versuche, die dauerhafte MAC-Adresse für eine VMXNET3-Netzwerkkarte abzurufen, schlagen möglicherweise fehl
    Wenn Sie das ETHTOOL_GPERMADDR-ioctl verwenden, um die dauerhafte MAC-Adresse für eine VMXNET3-Netzwerkkarte abzurufen, und 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.
  • Virtuelle Maschinen mit einem e1000-Netzwerkkartentreiber, die in den D3-Standbymodus versetzt werden, schlagen möglicherweise fehl
    Die virtuelle Maschine schlägt möglicherweise fehl und zeigt möglicherweise Fehlermeldungen in der Datei vmware.logähnlich der folgenden an, wenn das Gastbetriebssystem mit e1000-Netzwerkkartentreiber in den D3-Standbymodus versetzt wird:

    2013-08-20T10:14:35.121Z[+13.605]| vcpu-0| SymBacktrace[2] 000003ffff023be0 rip=000000000039d00f
    2013-08-20T10:14:35.121Z[+13.606]| vcpu-0| Unexpected 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.
  • Virtuelle Maschinen mit Solaris, die den vmxnet3-Netzwerkadapter verwenden, schreiben möglicherweise wiederholt Meldungen in die Protokolldateien
    Wenn eine Meldung von der virtuellen Solaris-Maschine über zu viele Fragmente verfügt, um in den TX-Ring zu passen, schreibt der vmxnet3-Netzwerkadapter folgende Meldungen wiederholt in die Protokolldateien:

    last message repeated 274 times
    vmxnet3s: [ID 450982 kern.notice] vmxnet3s:0: overfragmented mp (16)
    last message repeated 399 times
    vmxnet3s: [ID 450982 kern.notice] vmxnet3s:0: overfragmented mp (16)
    last message repeated 398 times
    vmxnet3s: [ID 450982 kern.notice] vmxnet3s:0: overfragmented mp (16)
    last message repeated 393 times
    vmxnet3s: [ID 450982 kern.notice] vmxnet3s:0: overfragmented mp (16)
    last message repeated 399 times
    vmxnet3s: [ID 450982 kern.notice] vmxnet3s:0: overfragmented mp (16)


    Dieses Problem wurde in der vorliegenden Version behoben.
  • Virtuelle Maschinen, die auf die CD-ROM des Clientgeräts zugreifen, antworten möglicherweise nicht mehr, wenn die Netzwerkverbindung des vSphere-Clients unterbrochen wird
    Wird die Netzwerkverbindung des vSphere-Clients unterbrochen, wenn eine virtuelle Maschine die CD-ROM eines Clientgeräts verwendet, antwortet die virtuelle Maschine möglicherweise nicht mehr und ist auf dem Netzwerk für einige Zeit nicht erreichbar.

    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 linkoder ip addrden Verbindungszustand als Unknownanstatt als Upan.
    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 werden möglicherweise vom Netzwerk getrennt, nachdem sie erneut gestartet oder migriert wurden
    Bei der Verwendung von vShield Endpoint und Deep Security führt ein Problem mit dem DVFilter-Modul möglicherweise zu einer Entleerung von netGPHeap und einem Arbeitsspeicherverlust. Dies führt möglicherweise dazu, dass virtuelle Maschinen vom Netzwerk getrennt werden, nachdem sie erneut gestartet oder durch die Verwendung von vMotion migriert wurden.
    Die Protokolldateien zeigen möglicherweise Meldungen wie folgende an:
    2012-11-30T11:29:06.368Z cpu18:923386)WARNING: E1000: 8526: failed to enable port 0x30001b6 on vSwitch1: Out of memory

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Virtuelle Maschinen überwachen möglicherweise nicht den ausgehenden Netzwerkverkehr, wenn virtuelle Netzwerkadapter im Promiscuous-Modus verwendet werden
    Wenn Sie virtuelle Netzwerkadapter im Promiscuous-Modus verwenden, um die Netzwerkaktivität zu verfolgen, kann ein bestimmtes Problem mit der Port-Mirroring-Funktion einen Mirror-Port deaktivieren und dazu führen, dass virtuelle Maschinen nicht mehr den ausgehenden Netzwerkverkehr verfolgen.

    Dieses Problem wurde in der vorliegenden Version behoben.

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.
  • Aktualisierung auf libxslt
    Das libxslt-Userworld-Paket von ESXi wurde aktualisiert.
  • VMware ESXi und ESX enthalten eine Schwachstelle in hostd-vmdb
    Um diese Schwachstelle auszunutzen, muss ein Angreifer den Management-Datenverkehr abfangen und ändern. Die Ausnutzung des Problems kann zu einem Denial-of-Service des hostd-vmdb-Diensts führen.
    Der Standard "Common Vulnerabilities and Exposures" (CVE) (cve.mitre.org) hat diesem Problem den Namen CVE-2013-5970 zugewiesen.

Serverkonfiguration

  • Leistungsdiagramme zeigen einen konstanten Stromverbrauch von 0 Watt für IBM System x iDataPlex dx360 M3-Server an
    Wenn Sie das Leistungsdiagramm zum Stromverbrauch für einen IBM System x iDataPlex dx360 M3-Server sehen, zeigt das Diagramm konstant 0 Watt. Dieses Problem tritt aufgrund einer Änderung der IDs des IPMI-Sensors auf, die von IBM System x iDataPlex dx360 M3-Servern verwendet werden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Eine virtuelle Maschine mit Red Hat Enterprise Linux 4.8 32-Bit zeigt verglichen mit ESX/ESXi 4.0 möglicherweise unter ESXi 5.0 einen höheren Lastdurchschnitt
    Eine virtuelle Maschine mit Red Hat Enterprise Linux 4.8 32-Bit mit einer Arbeitslast, die die meiste Zeit bei Null liegt und zeitweise oder gleichzeitig durch mehrere Aufgaben erhöht wird, weist möglicherweise unter ESXi 5.0 eine höhere durchschnittliche Last als unter ESX/ESXi 4.0 auf.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Mehrere ESXi-Server antworten während des Hinzufügens des ESXi-Servers zum vCenter Server möglicherweise nicht mehr
    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.
  • Virtuelle Maschinen, die von ESX/ESXi 3.5 auf ESXi 5.0 migriert wurden, starten möglicherweise nicht erneut
    Mehrere virtuelle Maschinen starten möglicherweise nicht erneut und generieren nach dem Neustart die VMX-Kerndatei. Dieses Problem tritt bei virtuellen Maschinen auf, die mithilfe von vMotion von ESX/ESXi 3.5-Hosts auf ESX/ESXi-Hosts mit den Versionen ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1 Update 2, ESXi 5.0 Update 2 und später migriert wurden.

    Dieses Problem wurde in der vorliegenden Version für ESXi 5.0-Hosts behoben.
  • Die Überprüfung der Host-Übereinstimmung schlägt mit einem Fehler fehl, der mit dem Extrahieren der Anzeigekonfiguration im Zusammenhang steht
    Wenn ein ungültiges CIM-Abonnement im System vorhanden ist und Sie eine Überprüfung der Richtlinieneinhaltung eines Hostprofils für einen Host durchführen, wird möglicherweise eine Fehlermeldung ähnlich der folgenden angezeigt:

    Fehler beim Extrahieren der Anzeigekonfiguration: (6, u'Das angeforderte Objekt wurde nicht gefunden')

    Sie können das Hostprofil nicht auf den Host anwenden.

    Dieses Problem wurde in der vorliegenden Version behoben. Sie können Hostprofile anwenden, sogar wenn eine ungültige Anzeige im Hostprofil vorhanden ist.
  • Der ESXi-Host reagiert nicht mehr, wenn Sie ihn über die Benutzerschnittstelle der Direktkonsole herunterfahren oder erneut starten
    Wenn Sie versuchen, einen ESXi-Host über die Benutzerschnittstelle der Direktkonsole (DCUI) herunterzufahren oder erneut zu starten, reagiert der Host nicht und der Benutzer kann den Vorgang des Herunterfahrens nicht beenden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Versuche, ein komplexes Hostprofil anzuwenden, führen möglicherweise zu einer Zeitüberschreitung
    Wenn Sie ein komplexes Hostprofil wie beispielsweise ein Profil mit einer großen Anzahl von Portgruppen und Datenspeichern anwenden, tritt bei dem Vorgang möglicherweise eine Zeitüberschreitung mit einer Fehlermeldung ähnlich der folgenden auf:
    2013-04-09T15:27:38.562Z [4048CB90 info 'Default' opID=12DA4C3C-0000057F-ee] [VpxLRO] -- ERROR task-302 -- -- vim.profile.host.profileEngine.HostProfileManager.applyHostConfig: vmodl.fault.SystemError:
    --> Result:
    --> (vmodl.fault.SystemError) {
    --> dynamicType = ,
    --> faultCause = (vmodl.MethodFault) null,
    --> reason = "",
    --> msg = "Ein allgemeiner Systemfehler ist aufgetreten: ",
    --> }
    Die standardmäßige hostd-Zeitüberschreitung beträgt 10 Minuten. Da applyHostConfig keine progressive Aufgabe ist, kann der hostd-Dienst während der hostd-Zeitüberschreitung nicht zwischen einer fehlgeschlagenen Aufgabe und einer Aufgabe mit langer Ausführungsdauer unterscheiden. Infolgedessen meldet der hostd-Dienst, dass applyHostConfig fehlgeschlagen ist.

    Dieses Problem wurde in der vorliegenden Version durch das Installieren einer 30-minütigen Zeitüberschreitung als Teil des verwalteten HostProfileManager-Objekts behoben. Dieses Problem tritt möglicherweise immer noch auf, wenn Sie versuchen, ein großes Hostprofil anzuwenden, und die Aufgabe überschreitet möglicherweise die Zeitgrenze von 30 Minuten. Um dieses Problem zu umgehen, wenden Sie das Hostprofil erneut an.
  • Der ESXi-Host wird möglicherweise vom vCenter Server getrennt, wenn hostd fehlschlägt
    ESXi-Hosts werden möglicherweise vom vCenter Server getrennt, wenn hostd mit Fehlermeldungen ähnlich der folgenden fehlschlägt:
    2013-06-04T11:47:30.242Z [6AF85B90 info 'ha-eventmgr'] Event 110 : /sbin/hostd crashed (1 time(s) so far) and a core file might have been created at/var/core/hostd-worker-zdump.000. Möglicherweise führte dies dazu, dass Verbindungen zum Host unterbrochen wurden.
    Dieses Problem tritt auf, wenn eine Überprüfung durchgeführt wird, um die korrekte Cache-Konfiguration sicherzustellen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Verbindung zum ESXi-Host geht möglicherweise verloren, wenn Sie ESXCLI-Befehle ausführen oder Überwachungstools verwenden, die auf den SNMP-Agenten angewiesen sind
    Wenn Sie ESXCLI-Befehle ausführen oder Überwachungstools verwenden, die auf Daten vom SNMP-Agenten in ESXi angewiesen sind, geht die Verbindung zum ESXi-Host möglicherweise aufgrund des Fehlers des hostd-Dienstes verloren.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Berechtigungen können keinen Active Directory-Benutzern und -Gruppen zugewiesen werden
    Nach dem Hinzufügen eines ESXi 5.0-Hosts zu einer Active Directory (AD)-Domäne schlägt der Versuch, AD-Benutzern und -Gruppen Berechtigungen zuzuweisen, möglicherweise fehl. Sie können die Domäne, der der Host beigetreten ist, im Dropdown-Menü für das Hinzufügen von Berechtigungen an AD-Benutzer und -Gruppen nicht anzeigen. Dieses Problem tritt auf, da der lsassd-Dienst auf dem Host stoppt. Die lsassd.log-Datei zeigt Einträge ähnlich der folgenden an:

    20111209140859:DEBUG:0xff92a440:[AD_DsEnumerateDomainTrusts() /build/mts/release/bora-396388/likewise/esxi-esxi/src/linux/lsass/server/auth-providers/ad-provider/adnetapi.c:1127] Failed to enumerate trusts at host.your.domain.name.net (error 59)
    20111209140859:DEBUG:0xff92a440:[AD_DsEnumerateDomainTrusts() /build/mts/release/bora-396388/likewise/esxi-esxi/src/linux/lsass/server/auth-providers/ad-provider/adnetapi.c:1141] Error code: 40096 (symbol: LW_ERROR_ENUM_DOMAIN_TRUSTS_FAILED)


    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESXi-Host schlägt mit einem violetten Diagnosebildschirm aufgrund des Pufferüberlaufs und der Kürzung im hpsc proc-Handler fehl
    Wenn Sie den cat-Befehl auf einem HP Smart Array-Controller mit 40 oder mehr LUNs ausführen, schlägt der ESXi-Host mit einem violetten Diagnosebildschirm fehl. Dies geschieht aufgrund des Pufferüberlaufs und der Datenkürzung im hpsc-Handler.

    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.
  • Der ESXi-Host protokolliert möglicherweise die Meldungen in den Protokolldateien aufgrund von Fehlern im Zusammenhang mit dem Arbeitsspeicher nicht mehr
    Eine unzureichende Arbeitsspeicherzuteilung für den Protokollierungs-Ressourcenpool führt möglicherweise dazu, dass ESXi Meldungen in Protokolldateien nicht mehr protokolliert. Es werden Meldungen ähnlich der folgenden in den Protokolldateien angezeigt:

    <TimeStamp> vmsyslog.main : ERROR ] Watchdog 2625 fired (child 2626 died with status 256)!
    <TimeStamp> vmsyslog : CRITICAL] vmsyslogd daemon starting (69267)
    <TimeStamp> vmsyslog.main : ERROR ] Watchdog 2625 exiting
    <TimeStamp> vmsyslog.loggers.file : ERROR ] Gzip logfile /scratch/log/hostd0.gz failed
    <TimeStamp> vmsyslog.main : ERROR ] failed to write log, disabling
    <TimeStamp> vmsyslog.main : ERROR ] failed to send vob: [Errno 28] No space left on device


    Dieses Problem wurde in der vorliegenden Version behoben. Der Grenzwert für den Protokollierungsspeicherpool wurde auf 48MB erhöht.
  • VMkernel-Netzwerkschnittstellen mit Ausnahme von vmk0 verlieren die IP-Bindungsaufhebung auf einem DHCP-Server
    Wenn eine VMkernel-Schnittstelle ihre IP-Lease von einem DHCP-Server in einem anderen Subnetz erhalten hat, werden vom DHCP-Server möglicherweise Fehlermeldungen angezeigt, die den folgenden Meldungen ähneln:
    2012-08-29T21:36:24Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:36:35Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:36:49Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:37:08Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:37:24Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:37:39Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:37:52Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:38:01Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:38:19Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:38:29Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:38:41Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:38:53Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:39:09Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:39:24Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67

    Das Problem wird behoben, indem Sie für den DHCP-Server eine Schnittstelle im Subnetz des VMkernel-Ports bereitstellen, um eine DHCP-Aktualisierung zuzulassen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der VMKernel schlägt fehl, wenn eine VM-Überwachungsfunktion eine ungültige Maschinen-Seitenzahl zurückgibt
    Wenn VMX einen VPN-Wert zum Lesen einer Seite weiterleitet, findet VMKernel keine gültige Maschinen-Seitenzahl für diesen VPN-Wert. Dies führt dazu, dass der Host mit einem violetten Diagnosebildschirm fehlschlägt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESX-Host schlägt möglicherweise aufgrund eines Arbeitsspeicherzuteilungsfehlers von einem World-Heap für das Aktivieren von Traces fehl
    ESX-Hosts schlagen möglicherweise aufgrund eines Arbeitsspeicherzuteilungsfehlers von einem World-Heap für das Aktivieren von Traces mit einem violetten Diagnosebildschirm fehl. Der World-Heap für das Aktivieren von Traces wird von vmkernel verwendet, um nach dem Schreiben von Traces auf Gastseiten neue Stapel zu erstellen. Dieses Problem tritt auf, wenn dieser Arbeitsspeicherzuteilungsfehler nicht ordnungsgemäß behandelt wird.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Ausführen von esxcfg-nas-Befehlen auf einem ESXi-Host führt zu einer PREF-Warnung
    Wenn Sie den Befehl esxcfg-nas -lausführen, zeigt der ESXi-Host eine Warnmeldung ähnlich der folgenden an:
    PREF-Warnung: PreferenceGet(libdir) vor Preference_Init, möchten Sie wirklich die Standardeinstellung verwenden?

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Ausführung von hostd-Leistungstests führt zu Regressionsproblemen
    Wenn Sie während der hostd-Leistungstests Vorgänge für virtuelle Maschinen wie der Erstellung von nVMs, der Neukonfiguration von nVMs oder der Bereinigung von nVMs durchführen, führt dies möglicherweise zu Regressionsproblemen. Dies geschieht, da ein Datenspeicheraktualisierungsaufruf für jede vdiskupdate-Meldung verarbeitet wird. Die Änderung der Datenspeicheraktualisierungslogik behebt dieses Problem.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESXi-Host zeigt speicherbezogene Nachrichten vom Typ "Unbekannt" in syslog.log-Dateien an
    Wenn vpxa syslog-Einträge mit mehr als 1024 Zeichen schreibt, wird der Nachrichtentext nach 1024 als "Unbekannt" klassifiziert und in der Protokolldatei syslog.loganstatt in der Datei vpxa.log filegespeichert. Dies führt dazu, dass der ESXi-Host speicherbezogene Nachrichten vom Typ "Unbekannt" in den syslog.log-Dateien anzeigt. In dieser Version wird die Zeilenpuffergrenze erhöht, um dieses Problem zu beheben.

    Dieses Problem wurde in der vorliegenden Version behoben.

Speicher

  • Auf ESXi treten bei der Migration von Lazy-Zeroed-Thick-Festplatten möglicherweise Leistungsprobleme auf
    Die Migrationsraten einiger Lazy-Zeroed-Thick-Festplatten sind auf manchen ESXi möglicherweise geringer als die anderer Festplattenübertragungen der gleichen Größe. Dieses Problem tritt auf, wenn Arbeitsspeicherseiten für den Dateisystemcache (Puffercache) in den ersten 2 MB großen Speicherbereich fallen. Dies führt dazu, dass die Migrationsraten für ESXi sinken.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESXi-Host schlägt mit einem violetten Diagnosebildschirm fehl, wenn Sie einen neuen Host zu einem Cluster hinzufügen
    Wenn Sie einen neuen Host zum Cluster hinzufügen und High Availability neu konfigurieren, schlägt der ESXi-Host mit einem violetten Diagnosebildschirm fehl.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • ESXi-Host schlägt aufgrund einer Metadatenbeschädigung von LUNs möglicherweise mit einem violetten Diagnosebildschirm fehl
    Wenn Sie bestimmte Vorgänge auf einer virtuellen Maschine ausführen, kann es vorkommen, dass ein mit Metadatenbeschädigung von LUNs verbundener Fehler dazu führt, dass ein ESXi-Host mit einem violetten Diagnosebildschirm fehlschlägt und Fehlermeldungen ähnlich der folgenden angezeigt werden:
    @BlueScreen: #DE Exception 0 in world 4277:helper23-15 @ 0x41801edccb6e3:21:13:31.624 cpu7:4277)Code start: 0x41801e600000
    VMK uptime: 3:21:13:31.6243:21:13:31.625 cpu7:4277)0x417f805afed0:[0x41801edccb6e]Fil3_DirIoctl@esx:nover+0x389 stack:
    0x410007741f603:21:13:31.625 cpu7:4277)0x417f805aff10:[0x41801e820f99]FSS_Ioctl@vmkernel:nover+0x5c stack:
    0x2001cf5303:21:13:31.625 cpu7:4277)0x417f805aff90:[0x41801e6dcf03]HostFileIoctlFn@vmkernel:nover+0xe2 stack:
    0x417f805afff03:21:13:31.625 cpu7:4277)0x417f805afff0:[0x41801e629a5a]helpFunc@vmkernel:nover+0x501 stack: 0x03:21:13:31.626 cpu7:4277)0x417f805afff8:[0x0] stack: 0x0


    Dieses Problem wurde in der vorliegenden Version behoben. Eine Metadatenbeschädigung von LUNs führt nun zu einer Fehlermeldung.
  • 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 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.
  • Die Dateigröße einer mit Thick-Provisioning bereitgestellten VM-Festplatte mit einer tatsächlichen Größe von 2 TB wird im Datenspeicherbrowser mit 0 Byte angegeben.
  • Wenn Sie mithilfe des Thick-Provisioning eine VM-Festplattendatei (virtual machine disk file, VMDK) mit einer Größe von 2 TB erstellen, meldet der Datenspeicherbrowser fälschlicherweise eine Festplattengröße von 0,00 Byte.
    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.
  • Möglicherweise werden falsche Alarme generiert, wenn Werte für den bereitgestellten Speicherplatz für den NFS-Datenspeicher falsch berechnet werden
    Unter bestimmten Bedingungen wird der Wert für den bereitgestellten Speicherplatz für einen NFS-Datenspeicher möglicherweise falsch berechnet, was zu falschen Alarmen führt.

    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.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der Microsoft Failover-Cluster I/O wird von Storage Fault möglicherweise nicht genehmigt
    Der Microsoft Failover-Cluster I/O wird von Storage Fault Tolerance möglicherweise nicht genehmigt, und der I/O schlägt möglicherweise mit einem Reservierungskonflikt fehl. Dieses Problem tritt auf, wenn zwei Failover-Cluster-VMs auf zwei verschiedenen ESXi-Hosts platziert werden und der Speicher-Array mit einer ALUA-Konfiguration läuft.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Ein NFS-Datenspeicher mit einem Remotepfadnamen mit mindestens 115 Zeichen konnte nicht eingehängt werden
    Ein NFS-Datenspeicher, dessen Remotepfadname 115 Zeichen oder mehr enthält, kann möglicherweise nicht eingehängt werden: Eine Fehlermeldung ähnlich der folgenden wird angezeigt:
    Unable to get Console path for Mount

    Der ESXi-Host wartet das NAS-Volume als Kombination aus NFS-Server-IP-Adresse und dem kompletten Pfadnamen der exportierten Freigabe. Dieses Problem tritt auf, wenn diese Kombination 128 Zeichen überschreitet.

    Dieses Problem wird in der vorliegenden Version behoben, indem die Größe des NAS-Volume auf 1024 angehoben wird.
  • Der ESXi-Host reagiert möglicherweise nicht mehr vom vCenter Server, wenn eine große Anzahl an VMFS-Snapshot-Volumes neu signiert wird
    Ein ESXi-Host reagiert zeitweise nicht mehr oder die Verbindung des Hosts wird vom vCenter Server getrennt, wenn eine große Anzahl an VMFS-Snapshot-Volumes neu signiert wird.

    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.
  • Die Sicherungsdatei state.tgz konnte während des Versuchs, ein Upgrade für den ESXi-Host durchzuführen, auf dem Startgerät nicht gefunden werden
    Wenn Sie versuchen, unter Verwendung des ISO-Images ein Upgrade für den ESXi-Host durchzuführen, kann die Sicherungsdatei state.tgzauf dem Startgerät möglicherweise nicht gefunden werden.
    Dieses Problem tritt auf, wenn die Sicherungsdatei state.tgznicht 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 fileangezeigt wird.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der esxcli-Befehl kann Datenspeichernamen, die ein Leerzeichen oder Klammern enthalten, nicht ordnungsgemäß verarbeiten
    Datenspeichernamen, die ein Leerzeichen oder Klammern enthalten, werden vom esxcli-Befehl nicht ordnungsgemäß verarbeitet. Dieses Problem tritt auf, wenn der Benutzer versucht, mithilfe des esxcli-Befehls ein ESXi-Upgrade durchzuführen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Bei einem Upgrade von mehreren ESXi 4.x-Installationen auf ESXi 5.x wird die Syslog-Serverkonfiguration möglicherweise nicht auf die neuen Konfigurationen migriert
    Auf ESXi 4.x ist die Konfiguration des Pfads Syslog.Local.DatastorePathin der Datei /etc/syslog.confgespeichert.
    Auf ESXi 5.x ist die Datei /etc/syslog.confjedoch durch die Datei /etc/vmsyslog.confersetzt worden und die Konfiguration des Verzeichnisses Syslog.global.logDirist in der Datei /etc/vmsyslog.confgespeichert.
    Dies führt dazu, dass die Syslog-Serverkonfigurationen der Attribute logfileund loghostin der Datei /etc/syslog.confnicht auf die neu konfigurierten Attribute logdirund loghostin der neuen Datei /etc/vmsyslog.confmigriert werden. Daher müssen Sie, wenn Sie für mehrere ESXi 4.x-Server ein Upgrade auf ESXi 5.x-Server durchführen, das Verzeichnis Syslog.global.logDirnach jedem abgeschlossenen Upgrade manuell konfigurieren.

    Dieses Problem wurde in der vorliegenden Version behoben, indem die Attribute folgendermaßen aktualisiert wurden:
    1. Das Attribut loghostin der Datei /etc/syslog.confwird in der neuen Datei /etc/vmsyslog.confbeibehalten.
    2. Das Attribut logfileist nicht mehr gültig. Dieses Attribut wurde auf das Attribut logdirin der neuen Datei /etc/vmsyslog.confmigriert. Der Wert des Attributs logdirist der Verzeichnisname des alten Attributwerts logfile. Die Migration erfolgt nur, wenn das entsprechende Verzeichnis auch auf dem aktualisierten System weiterhin ein gültiges Verzeichnis ist.
  • Versuche, ein Upgrade für einen ESXi-Host in einem HA-Cluster durchzuführen, schlagen mit dem vCenter Update Manager möglicherweise fehl
    Ein Upgrade für einen ESXi-Host in einem High Availability-Cluster (HA-Cluster) schlägt im vCenter Update Manager (VUM) möglicherweise mit einer Fehlermeldung ähnlich der folgenden fehl:
    Der Host gibt den esxupdate-Fehlercode 7 zurück
    Dieses Problem tritt auf, wenn mehrere Bereitstellungsvorgänge mit unterschiedlichen Baselines in Update Manager durchgeführt werden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Eine skriptbasierte ESXi-Installation oder ein Upgrade von einem verbundenen USB-Laufwerk schlägt möglicherweise fehl, wenn der Dateisystemtyp auf einem der USB-Laufwerke weder Fat16 noch Fat32 ist
    Wenn mehrere USB-Flash-Laufwerke mit einem ESXi-Host verbunden sind, schlägt eine skriptbasierte ESXi-Installation oder ein Upgrade mit der Startoption ks=usbmöglicherweise mit einem Ausnahmefehler fehl, wenn der Dateisystemtyp auf einem der USB-Laufwerke mit MS-DOS-Partitionierung weder Fat16 noch Fat32 ist.

    Dieses Problem wurde in der vorliegenden Version behoben.

vCenter Server und vSphere-Client

  • Die Registerkarte "Übersicht" zeigt für den bereitgestellten Speicherplatz für virtuelle Maschinen und für NFS- oder NAS-Datenspeicher auf VAAI-aktivierten Hosts möglicherweise falsche Werte an
    Wenn eine virtuelle Festplatte im Format "Thick-Provision Lazy-Zeroed" auf einem VAAI-unterstützten NAS eines VAAI-aktivierten ESXi-Hosts erstellt wird, wird der bereitgestellte Speicherplatz für die zugehörige virtuelle Maschine und den entsprechenden Datenspeicher möglicherweise falsch angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Angepasstes Leistungsdiagramm enthält keine Option zum Anzeigen von Diagrammen 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 Festplattenobjekte 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.

Verwaltung von virtuellen Maschinen

  • Virtuelle Maschinen können nicht eingeschaltet werden, wenn auf ihre VMDK-Dateien nicht zugegriffen werden kann
    Auf einem ESXi-Host kann eine virtuelle Maschine nicht eingeschaltet werden, wenn auf ihre VMDK-Datei nicht zugegriffen werden kann und wenn für die VMX-Datei disk.powerOnWithDisabledDiskauf TRUEund answer.msg.disk.notConfiguredauf Yesgesetzt sind. Die folgende Fehlermeldung wird angezeigt:
    Das System kann die angegebene Datei nicht finden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Nach dem Erstellen des Stilllegungs-Snapshots einer virtuellen Maschine wird die VMX-Datei nicht aktualisiert
    Wenn Sie einen Stilllegungs-Snapshot einer virtuellen Maschine erstellen, wird die VMX-Datei erst aktualisiert, wenn Sie die virtuelle Maschine wieder einschalten. Die vmx-Konfiguration ist veraltet und verweist auf die ursprüngliche VMDK. Wenn die virtuelle Maschine zwischen dem Erstellen des Snapshots und dem nächsten Einschalten ausfällt, führte dies bislang zu Datenverlust und einer verwaisten VMDK. 

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Versuche, Linux auf einer virtuellen Maschine zu installieren, schlagen möglicherweise fehl
    Wenn ein Disketten-Image mit der virtuellen Maschine verbunden ist, schlägt der Versuch, das Betriebssystem Linux zu installieren, möglicherweise fehl.
    Die Datei vmware.logenthält dann möglicherweise Einträge ähnlich den folgenden:

    RemoteFloppyVMX: Remote cmd uid 0 timed out.
    | vcpu-3| Caught signal 11 -- tid 115057
    | vcpu-3| SIGNAL: eip 0x1f5c2eca esp 0xcaf10da0 ebp 0xcaf10e00
    | vcpu-3| SIGNAL: eax 0x0 ebx 0x201826a0 ecx 0x593faa10 edx 0x201d63b0 esi 0x0 edi 0x593faa00
    | vcpu-3| r8 0x593faa00 r9 0x0 r10 0x1fd79f87 r11 0x293 r12 0x2022d000 r13 0x0 r14 0x0 r15 0x1fd6eba0
    | vcpu-3| Backtrace:
    | vcpu-3| Backtrace[0] 00000000caf109a0 rip=000000001f8caf9e rbx=000000001f8cad70 rbp=00000000caf109c0 r12=0000000000000000 r13=00000000caf198c8 r14=00000000caf10b50 r15=0000000000000080
    ....
    | vcpu-3| SymBacktrace[2] 00000000caf10ad0 rip=000000000038c00f
    | vcpu-3| Unexpected signal: 11.
    | vcpu-3| Writing monitor corefile "/vmfs/volumes/519f119b-e52d3cf3-6825-001999db3236/EMS/vmmcores.gz"


    Dieses Problem wurde in der vorliegenden Version behoben.
  • Ein Seitenfehler in der VM-Überwachungsfunktion führt zu einem ESXi-Hostfehler
    Ein Seitenfehler in der VM-Überwachungsfunktion verursacht möglicherweise im ESXi-Host einen Fehler mit einem violetten Diagnosebildschirm und meldet einen Ausnahmefehler zum Seitenfehler ähnlich dem folgenden in vmware.log:
    2013-05-15T12:48:25.195Z| vcpu-1| W110: A core file is available in "/vmfs/volumes/5088c935-f71201bf-d750-90b11c033174/BF-TS5/vmx-zdump.000" 2013-05-15T12:48:25.196Z| vcpu-1| I120: Msg_Post: Error 2013-05-15T12:48:25.196Z| vcpu-1| I120: [msg.log.error.unrecoverable] VMware ESX unrecoverable error: (vcpu-1) 2013-05-15T12:48:25.196Z| vcpu-1| I120+ vcpu-1:VMM fault 14: src=MONITOR rip=0xfffffffffc243748 regs=0xfffffffffc008e98 2013-05-15T12:48:25.196Z| vcpu-1| I120: [msg.panic.haveLog] A log file is available in "/vmfs/volumes/5088c935-f71201bf-d750-90b11c033174/BF-TS5/vmware.log". 2013-05-15T12:48:25.196Z| vcpu-1| I120: [msg.panic.requestSupport.withoutLog] You can request support. 2013-05-15T12:48:25.196Z| vcpu-1| I120: [msg.panic.requestSupport.vmSupport.vmx86] 2013-05-15T12:48:25.196Z| vcpu-1| I120+ To collect data to submit to VMware technical support, run "vm-support". 2013-05-15T12:48:25.196Z| vcpu-1| I120: [msg.panic.response] We will respond on the basis of your support entitlement. 2013-05-15T12:48:25.196Z| vcpu-1| I120:


    Dieses Problem wurde in der vorliegenden Version behoben.


  • Virtuelle Maschinen schlagen möglicherweise fehl, wenn Sie Vorgänge zu virtuellen Festplatten durchführen
    E/A-Vorgänge zu virtuellen Festplatten, speziell jene mit wiederholten CDROM-Zugriffsversuchen, rufen möglicherweise Fehler in virtuellen Maschinen hervor.
    Die Protokolldateien enthalten möglicherweise Einträge ähnlich den folgenden:
    <Time_Stamp> vmx| [msg.vmxaiomgr.retrycontabort.rudeunplug] The operation on file "/vmfs/volumes/16b2bd7c-1d66d7ef/VMware/VMware-VIMSetup-all-5.1.0-947939.iso" failed.
    <Time_Stamp> vmx| --> If the file resides on a remote file system, make sure that the network connection and the server where this disk resides are functioning properly. If the file resides on removable media, reattach the media.
    <Time_Stamp> vmx| --> Select Retry to attempt the operation again.
    ...
    Followed by:

    <Time_Stamp> vmx| MsgQuestion: msg.vmxaiomgr.retrycontabort.rudeunplug reply=0
    <Time_Stamp> vmx| VMXAIOMGR: Reopening /vmfs/volumes/16b2bd7c-1d66d7ef/VMware/VMware-VIMSetup-all-5.1.0-947939.iso and retrying outstanding IOs
    ...


    Dieses Problem wurde in der vorliegenden Version behoben.

  • Versuche, eine virtuelle Maschine als OVF zu exportieren, schlagen mit einem Zeitüberschreitungsfehler fehl
    Wenn Sie versuchen, eine virtuelle Maschine in einem OVF-Format (Open Virtualization Format) zu exportieren, und die virtuelle Maschine große Bereiche an leeren Blöcken auf der Festplatte (beispielsweise 210 GB oder darüber) aufweist und zusätzlich das Dateisystem ext2 oder ext3 verwendet wird, meldet der Vorgang ein Zeitüberschreitung.

    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 QueryChangedDiskAreasfehl, nachdem eine VM-Festplatte mithilfe von vMotion auf ein anderes Volume verschoben wurde
    Wenn Sie die Verfolgungsfunktionalität für geänderte Blöcke (Changed Block Tracking, CBT) auf einer virtuellen Maschine aktivieren und QueryChangedDiskAreasausfü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 = ,
    --> 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",
    --> }

    Dieses Problem tritt auf, wenn eine Bibliotheksfunktion die Komponente für die Festplattenänderungsverfolgung nicht ordnungsgemäß erneut initialisiert.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Storage vMotion schlägt auf einer virtuellen Maschine mit 2 TB Speicherplatz möglicherweise fehl
    Wenn Sie Storage vMotion für die Migration von virtuellen Maschinen mit einem Speicherplatz von 2 TB, d. h. mit 2 Festplatten mit je 1 TB Speicherplatz verwenden, wird möglicherweise eine Fehlermeldung ähnlich der folgenden angezeigt:
    Ein allgemeiner Systemfehler ist aufgetreten: Die Quelle hat erkannt, dass das Ziel nicht fortgesetzt werden konnte.


    Die virtuelle Maschine kann auf dem Zielhost nicht gestartet werden. Es wird eine Fehlermeldung ähnlich der folgenden angezeigt:
    Error: "VMware ESX nicht behebbarer Fehler: (vmx) Unerwartetes Signal 8".

    Dieses Problem wurde in der vorliegenden Version behoben.

VMware HA und Fault Tolerance

  • Failover einer virtuellen Maschine zu einem designierten Failover-Host schlägt für einen ESXi-Host, auf dem HA aktiviert ist, möglicherweise fehl
    Wenn auf dem ESXi-Host bei aktivierter High Availability (HA) vMotion ausgeführt wird, schlägt der Failover einer virtuellen Maschine zu einem designierten Failover-Host möglicherweise fehl.
    Dieses Problem tritt auf, wenn die Auslagerungsdateien der virtuellen Maschine (.vswp-Dateien) gesperrt sind. Dies führt dazu, dass die FDM-Agenten (Fault Domain Manager) für HA den Failover der virtuellen Maschine zum designierten Host nicht durchführen können.

    Dieses Problem wurde in der vorliegenden Version behoben.

VMware Tools

  • Die VMCI-Treiber (Virtual Machine Communication Interface) lassen sich auf Linux-Kernel 3.8.0-rc3+ nicht kompilieren
    Wenn Sie VMware Tools auf Linux-Kernel 3.8.0-rc3+ installieren, lassen sich die VMCI-Treiber nicht kompilieren. Das Entfernen einiger Linux-Treiber aus dem Kernel behebt dieses Problem.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Nach der Installation von VMware Tools auf einer virtuellen CentOS 6.4 32-Bit-Maschine wird das System wiederholt neu gestartet
    Nach der Installation von VMware Tools auf einer virtuellen CentOS 6.4 32-Bit-Maschine und dem Neustart der virtuellen Maschine wird diese wiederholt neu gestartet. Dieses Problem tritt aufgrund der Kernel-Inkompatibilität auf.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • SMVI ist möglicherweise nicht in der Lage, die Maschine nach einem Upgrade von VMware Tools zu sichern
    Nach einem Upgrade von VMware Tools ist der NetApp SnapManager for Virtual Infrastructure (SMVI) möglicherweise nicht dazu in der Lage, eine Sicherung der Maschine vorzunehmen. Außerdem schlägt die Erstellung eines Stilllegungs-Snapshots möglicherweise mit einer Fehlermeldung ähnlich der folgenden fehl:
    Es kann kein Snapshot eines stillgelegten Prozesses erstellt werden, weil beim Erstellen des Snapshots das Zeitlimit für das Zurückhalten von E/A in der stillgelegten virtuellen Maschine überschritten wurde.

    Dieses Problem tritt bei virtuellen Maschinen mit Windows Server 2008, Windows Server 2008 R2 und Windows Server 2012 auf. Dieses Problem tritt nicht bei virtuellen Maschinen mit Windows 2003 auf.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Auf einigen virtuellen Maschinen werden von der prefixLength-Eigenschaft des Datenobjekts NetIpConfigInfoIpAddress möglicherweise falsche Daten zur Subnetzmaske angezeigt
    Das Datenobjekt NetIpConfigInfoIpAddress stellt die Daten zu einer bestimmten IP-Adresse bereit. Auf einigen virtuellen Maschinen zeigt die prefixLength-Eigenschaft des Datenobjekts NetIpConfigInfoIpAddress, mit dem die Länge des Präfixes einer generischen Internet-Netzwerkadresse angegeben wird, möglicherweise falsche Daten zur Subnetzmaske an.
    Dieses Problem tritt auf, wenn das Endianness-Attribut der IP-Adresse, das die Byte-Reihenfolge innerhalb des Arbeitsspeichers des Computers bestimmt, in der Subnetzmaskenberechnung nicht korrekt angegeben wird.
    Dieses Problem ist bei virtuellen Maschinen mit Windows Server 2008 R2 (64-Bit) und Windows Server 2003 zu beobachten.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der standardmäßige SVGA-Treiber führt möglicherweise dazu, dass virtuelle Maschinen mit Windows Server 2008 nach der Installation von VMware Tools nicht mehr reagieren
    Nach der Installation von VMware Tools reagieren virtuelle Maschinen mit Windows Server 2008 beim darauffolgenden Neustart von der Systemanmeldeseite aus möglicherweise nicht mehr. Dieses Problem tritt auf, wenn die mit VMware Tools installierten Standardeinstellungen für die SVGA-Treiber nicht ordnungsgemäß sind. Die virtuellen Maschinen reagieren möglicherweise auch dann nicht mehr, wenn Sie den Mauszeiger bewegen und während des Neustarts eine beliebige Taste drücken.

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

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Versuche, VMware Tools zu installieren, schlagen in Verbindung mit der Linux-Kernel-Version 3.7 und höher möglicherweise fehl
    VMware Tools-Treiber werden nicht kompiliert, da unter Linux-Kernel-Version 3.7 und höher sowie unter Version 3.8 die VMware Tools-Installationsskripts den neuen Kernel-Header-Pfad nicht identifizieren können. Dadurch schlagen Versuche, VMware Tools zu installieren, möglicherweise fehl.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der VMware Tools-Dienst schlägt fehl, wenn der Registry-Schlüssel InstallPath fehlt
    Während der Deinstallation von VMware Tools ist zu beobachten, dass der vmusr-Prozess möglicherweise fehlschlägt. Dies geschieht, da der Deinstallationsprozess beginnt, noch bevor der vmusr-Prozess abgeschlossen ist. Genauer gesagt, löscht der Deinstallationsprozess einen Registry-Schlüssel, der der vmusr-Prozess später versucht auszulesen, wodurch ein VMware Tools-Dienst fehlschlägt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der vCenter-Schutzagent zeigt eine Warnmeldung 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 eine Popup-Meldung zur Verwendung einer nicht signierten ausführbaren Datei an. Durch die Aufnahme der Datei in das signierte Formular wird dieses Problem behoben.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Namen und Beschreibungen der Leistungsindikatoren für den VM-Prozessor oder VM-Arbeitsspeicher können auf Gastbetriebssystemen wie Windows Vista oder höher nicht angezeigt werden
    Wenn als Benutzer mit Administratorberechtigungen ein Remoteleistungsprotokoll auf Gastbetriebssystemen wie Windows Vista oder höher konfiguriert ist, werden die Namen und Beschreibungen der Leistungsindikatoren für den VM-Prozessor und den VM-Arbeitsspeicher möglicherweise nicht in der Konsole des Windows-Systemmonitors (perfmon) angezeigt.
    Dies geschieht, wenn das Gebietsschema für Windows-Gastbetriebssystem nicht en_us oder de ist. Dieses Problem tritt in Verbindung mit VMware Tools Version 8.3.1.2 auf.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die PBMs UEK2-200 und UEK-400 sind im Tools-Installationsprogramm für Linux für Oracle 5.x-Kernel möglicherweise nicht vorhanden
    Die vorgefertigten Kernel-Module UEK2-200 und UEK-400 (pre-built kernel modules, PBMs) sind im Tools-Installationsprogramm für Linux für Oracle 5.9 2.6.39-200/400-Kernel möglicherweise nicht vorhanden.

    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 und Oracle Linux 6.4

Bekannte Probleme

Die folgenden bekannten Probleme wurden beim Testen der Software erkannt. Sie helfen Ihnen, das Verhalten, auf das Sie in dieser Version treffen, besser zu verstehen. Die nachfolgende Liste der Probleme gilt nur für diese Version von ESXi 5.0 Update 3, ESXi 5.0 Update 2, ESXi 5.0 Update 1 und ESXi 5.0. Einige bekannte Probleme von vorherigen Versionen betreffen möglicherweise auch diese Version. Wenn ein Problem auftritt, das nicht in der Liste der bekannten Probleme aufgeführt ist, prüfen Sie die Liste der bekannten Probleme früherer Versionen, suchen Sie in der VMware-Knowledgebase oder teilen Sie uns das Problem durch Ihr Feedback mit. Behobene Probleme, die früher nicht dokumentiert wurden, werden mit einem Sternchen (*) markiert.

Liste bekannter Probleme

Die Probleme gliedern sich wie folgt:

Installation
  • Nach der Installation von ESXi 5.0 Update 3 wird eine überflüssige netzwerkbezogene Warnmeldung angezeigt
    Nach der Installation von ESXi 5.0 Update 3 wird auf der ESXi-Benutzerschnittstelle der direkten Konsole (DCUI) eine Warnmeldung ähnlich der folgenden angezeigt:

    Warnung: DHCP-Suche fehlgeschlagen. Möglicherweise können Sie erst auf das System zugreifen, wenn Sie dessen Netzwerkkonfiguration angepasst haben


    Der Host erhält jedoch DHCP-IP und kann andere Hosts anpingen.

    Umgehung: Diese Fehlermeldung ist ungefährlich und kann ignoriert werden. Die Fehlermeldung wird nicht mehr angezeigt, wenn Sie die Eingabetaste drücken.

  • Im Falle von Installationen, die per Skript durchgeführt wurden, wendet das ESXi-Installationsprogramm die Option --fstype< für den part-Befehl in der ks-Datei an
    Die Option --fstypefür den Befehl partist in ESXi 5.0 veraltet. Das Installationsprogramm akzeptiert die Option --fstypeohne Fehlermeldung, es erstellt jedoch nicht den von der Option --fstypefestgelegten Partitionstyp. In ESXi 5.0 erstellt das Installationsprogramm standardmäßig immer VMFS5-Partitionen. Sie können keinen anderen Partitionstyp mit der Option --fstypefür den part-Befehl festlegen.

  • Regelinformationen fehlen, wenn das Image Builder-cmdlet zum Anzeigen eines geänderten Image-Profils in PowerShell 1.0 ausgeführt wird
    Nachdem Sie vSphere PowerCLI auf Microsoft PowerShell 1.0 installieren und ein OEM-Softwarepaket zu einem Image-Profil hinzufügen, fehlen die Informationen zur Rules-Eigenschaft beim Auflisten des Image-Profils.

    Umgehung: Sie können auf die Regelinformationen zugreifen, indem Sie die Rules-Eigenschaft des Image-Profilobjekts anzeigen.

  • Eine skriptbasierte ESXi-Installation oder ein Upgrade von CD oder DVD schlägt fehl, es sei denn, Großbuchstaben werden beim Übergeben des Namens der Skriptdatei an den Startbefehl verwendet
    Wenn Sie eine skriptbasierte Installation oder ein Upgrade von einem ESXi 5.0-Installer-ISO-Image aus, das auf CD oder DVD gebrannt wurde, zusammen mit dem Installations- bzw. Upgrade-Skript (Kickstart-Datei) durchführen, wird der Name der Kickstart-Datei nur dann erkannt, wenn dieser in Großbuchstaben angegeben wird, auch wenn der Name der Datei nur aus Kleinbuchstaben besteht. Wenn z. B. der Name der Kickstart-Datei ks.cfglautet und Sie den Startbefehl ks=cdrom:/ks.cfgzum Angeben des Speicherorts der Kickstart-Datei verwenden, schlägt die Installation fehl mit einer Fehlermeldung ähnlich der Folgenden: HandledError: Fehler (weitere Informationen finden Sie in der Protokolldatei): Kickstart-Datei auf CD-ROM mit Pfad -- /ks.cfg wurde nicht gefunden.

    Umgehung: Verwenden Sie Großbuchstaben im Startbefehl, um den Namen der Kickstart-Datei anzugeben, z. B.: ks=cdrom:/KS.CFG

  • Irreführende Fehlermeldung, wenn Sie versuchen, unter Angabe eines relativen Pfads VIBs zu installieren
    Wenn Sie mithilfe des Befehls esxcli software vib versuchen, ein Depot, ein VIB oder ein Profil zu installieren und Sie einen relativen Pfad angeben, schlägt der Vorgang mit folgender Fehlermeldung fehl: Datei oder Verzeichnis nicht vorhanden: '/var/log/vmware/a.vib'

    Umgehung: Geben Sie den absoluten Pfad an, wenn Sie die Installation durchführen.

  • Nach der Installation des vSphere Web Client wird ein Browser gestartet und eine leere Seite angezeigt
    Nach der Installation des vSphere-Clients wird ein Browser gestartet und eine leere Seite angezeigt, wenn Sie im Installationsassistenten auf Beenden klicken. Die Seite bleibt leer und der Browser stellt keine Verbindung zur vSphere Administration Application her.

    Umgehung: Beenden Sie den Browser und starten Sie die vSphere Administration Application-Seite vom Menü Start aus.

Upgrade

  • ESXi 5.0 Update 3-VIBs können nicht über PowerCLI auf einem ESXi-Host, der über vCenter Server verbunden ist, übernommen werden
    Auf einem ESXi 5.0-Host, der von vCenter Server verwaltet wird, schlägt der Versuch, ESXi 5.0 Update 3-VIBs mithilfe von GET-ESXCLI-Befehlen auf PowerCLI zu übernehmen, mit Fehlermeldungen ähnlich den folgenden fehl:
    2011-11-18T09:53:50Z esxupdate: root: Fehler: Traceback (most recent call last):
    2011-11-18T09:53:50Z esxupdate: root: Fehler: File "/usr/lib/vmware/esxcli-software", line 441, in <module>
    2011-11-18T09:53:50Z esxupdate: root: Fehler: main()
    2011-11-18T09:53:50Z esxupdate: root: Fehler: File "/usr/lib/vmware/esxcli-software", line 432, in main
    2011-11-18T09:53:50Z esxupdate: root: Fehler: ret = CMDTABLE[command](options)
    2011-11-18T09:53:50Z esxupdate: root: Fehler: File "/usr/lib/vmware/esxcli-software", line 329, in VibInstallCmd
    2011-11-18T09:53:50Z esxupdate: root: Fehler: raise Exception("No VIBs specified with -n/--vibname or -v/--viburl.")
    2011-11-18T09:53:50Z esxupdate: root: Fehler: Exception: No VIBs specified with -n/--vibname or -v/--viburl.


    Umgehung: Keine
  • Ein Live-Update mit ESXCLI schlägt mit einer VibDownloadError -Fehlermeldung fehl
    Wenn Sie die folgenden Aufgaben sequentiell durchführen, schlägt die Transaktion "Neustart erforderlich" fehl und eine VibDownloadError-Fehlermeldung wird angezeigt.

    1. Ein Live-Update unter Verwendung des Befehls esxcli software profile updateoder esxcli vib update.
    2. Vor dem Neustart wird eine Transaktion ausgeführt, die nicht erfolgreich abgeschlossen wird. Eine mögliche häufige Ursache liegt in der Verifizierung der Signatur, die nur dann überprüft werden kann, nachdem das VIB heruntergeladen wurde.
    3. Versuchen Sie, ohne den Host neu zu starten, eine weitere Transaktion auszuführen, die einen Neustart erfordert. Die Transaktion schlägt mit einer VibDownloadError-Fehlermeldung fehl.

     

    Umgehung: Führen Sie zum Beheben des Problems die folgenden Schritte durch.

    1. Starten Sie den ESXi-Host neu, um dessen Zustand zu bereinigen.
    2. Wiederholen Sie die Live-Installation.
  • Während eines skriptbasierten Upgrades von ESX/ESXi 4.x auf ESXi 5.0 ändern sich die Namen der MPX- und VML-Festplattengeräte, was möglicherweise dazu führt, dass das Upgrade fehlschlägt
    Nach einem Neustart des Hosts werden die MPX- und VML-Festplattengerätenamen möglicherweise nicht beibehalten. Wenn sich während eines skriptbasierten Upgrades nach einem Neustart die Namen ändern, wird das Upgrade möglicherweise unterbrochen.

    Umgehung: Verwenden Sie nach Möglichkeit NAA-IDs (Network Address Authority Identifiers) für Festplattengeräte. Führen Sie bei Maschinen, die über keine Festplatten mit NAA-IDs verfügen, z. B. Hewlett Packard-Maschinen mit CCISS-Controllern, das Upgrade von einer CD oder DVD aus, auf der sich das ESXi-Installer-ISO-Image befindet. Alternativ können Sie bei einem skriptbasierten Upgrade die zu aktualisierende ESX- oder ESXi-Instanz angeben, indem Sie den Befehl upgradeunter Angabe des Parameters --firstdisk=verwenden. Weitere Informationen zu Installations- und Upgrade-Skriptbefehlen finden Sie im Installations- und Einrichtungshandbuch für vSphere sowie in der Dokumentation zum vSphere-Upgrade.

  • Die ESX-Konsole und der esxi_install.log-Bericht können während eines Upgrades keine DHCP-Adresse beziehen, wenn das ESX-System manuell zugewiesene IP-Adressen in einem Subnetz ohne den DHCP-Dienst verwendet
    Diese Situation tritt auf, wenn ein ESX-System mit manuell zugewiesenen IP-Adressen in einem Subnetz ohne DHCP-Server ausgeführt wird oder wenn die Kapazität des DHCP-Servers ausgeschöpft ist. In jedem Fall wird das System, wenn das ESX-System aktualisiert wird, bis zu eine Minute angehalten, wenn es versucht, eine IPv4-Adresse von einem DHCP-Server zu beziehen.

    Umgehung:Keine. Nachdem das System bis zu eine Minute angehalten wird, wird das Upgrade erfolgreich durchgeführt. Sie werden möglicherweise aufgefordert, die Eingabetaste zu drücken, um fortzufahren. Sie können entweder die Eingabetaste drücken oder die Eingabeaufforderung einfach ignorieren. In beiden Fällen fährt das System mit der Durchführung des Upgrades nach der Pause fort.

Netzwerk

  • Emulex be2net Netzwerkadapter mit Geräte-ID 0710 kann nicht in ESXi 5.0 getestet werden (KB 2041665 )

  • Ein von vCenter Server 4.x aus erstelltes Hostprofil mit vDS-Konfiguration wendet möglicherweise die Gateway-Einstellungen für statusfreie gestartete ESX 5.0-Hosts nicht an
    Bei der Verwendung von vSphere Auto Deploy mit einem 4.x-Hostprofil werden die Gateway-Einstellungen für statusfreie gestartete ESX 5.0-Hosts möglicherweise nicht angewendet. Infolgedessen werden die Netzwerkverbindungen für diese Hosts unterbrochen und sie werden nicht automatisch zu vCenter Server 5.0 hinzugefügt.

    Umgehung: Führen Sie die folgenden Schritte aus, um ein 4.x-Hostprofil mit vDS-Konfiguration für das Starten von statusfreien ESX 5.0-Hosts zu verwenden:

    1. Starten Sie einen mit Auto Deploy konfigurierten statusfreien ESX 5.0-Host, ohne ein 4.x-Hostprofil anzugeben.
    2. Wenden Sie das 4.x-Hostprofil an, nachdem der statusfreie Host zu vCenter Server 5.0 hinzugefügt wurde.
    3. Erstellen Sie anhand des statusfreien gestarteten ESX 5.0-Hosts ein neues Hostprofil. Verwenden Sie das neu erstellte Hostprofil mit vSphere Auto Deploy, um statusfreie ESX 5.0-Hosts zu starten.

    Verwenden Sie ein 4.x-Hostprofil ohne vDS-Einstellungen, um statusfreie ESX 5.0-Hosts ohne vDS-Konfiguration zu starten. Darüber hinaus können Sie wie folgt vDS-Einstellungen eines 4.x-Hostprofils deaktivieren oder entfernen:

    Deaktivieren Sie mithilfe der Option Profilkonfiguration aktivieren/deaktivieren unter Hostprofil > Netzwerkkonfiguration vDS und die ihm zugewiesenen Portgruppen im Hostprofil. Entfernen Sie mithilfe der Option Profil bearbeiten unter Hostprofil > Netzwerkkonfiguration vDS und die ihm zugewiesenen Portgruppen aus dem Hostprofil.

  • In den Assistenten "Host dem vSphere Distributed Switch hinzufügen" und "Hosts verwalten" werden keine Details zur Servicekonsole angezeigt
    Wenn Sie einen 4.x-ESX-Host zu einem Distributed Switch hinzufügen, werden die Details der Netzwerkadapter der Servicekonsole im Abschnitt "Details zum virtuellen Adapter" auf der Seite "Netzwerkkonnektivität" des Assistenten "Host hinzufügen" nicht angezeigt. Normalerweise sollten hier MAC-Adresse, IP-Adresse und Subnetzmaske angezeigt werden.

    Umgehung: Wenn Sie die Details zu einem Netzwerkadapter der Servicekonsole anzeigen möchten, beenden Sie den Assistenten "Hosts hinzufügen" bzw. "Hosts verwalten" und navigieren Sie dann im vSphere-Client zu "Host > Konfiguration > Netzwerk".

    Wenn der Netzwerkadapter der Servicekonsole auf einem Standard-Switch bereitgestellt wird:

    1. Suchen Sie den Switch.
    2. Klicken Sie auf "Eigenschaften...".
    3. Wählen Sie den Netzwerkadapter der Servicekonsole aus.
      Notieren Sie sich den Namen des Adapters, der im VSS-Diagramm angezeigt wird.

     

    Wenn der Netzwerkadapter der Servicekonsole auf einem Distributed Switch bereitgestellt wird:

    1. Navigieren Sie zur Registerkarte "vSphere Distributed Switch".
    2. Suchen Sie den Distributed Switch und wählen Sie "Virtuelle Adapter verwalten...".
    3. Suchen Sie den Netzwerkadapter der Servicekonsole und wählen Sie ihn aus.

     

  • Der ESXi Dump Collector-Server wird unbemerkt beendet
    Wenn der Port des ESXi Dump Collector-Servers mit einem ungültigen Wert konfiguriert wurde, wird er ohne Fehlermeldung unbemerkt beendet. Da dies der Port ist, über den der ESXi Dump Collector-Server Core-Dumps von ESXi-Hosts empfängt, verhindern diese unbemerkten Beendigungen, dass diese von ESXi-Hosts stammenden Core-Dumps erfasst werden. Da ESXi Dump Collector keine Fehlermeldungen an vCenter Server sendet, ist der vSphere-Administrator nicht über dieses Problem informiert. Falls es nicht behoben wird, werden die Unterstützungsmöglichkeiten bei Ausfällen auf einem ESXi-Host beeinträchtigt.

    Umgehung: Wählen Sie beim Konfigurieren des ESXi Dump Collector-Servers nur einen Port aus dem empfohlenen Portbereich aus, um dieses Problem zu vermeiden. Die Verwendung des Standardports wird empfohlen.

  • Die Verwendung einer 10G QLogic-Netzwerkkarte, Version QLE3142, mit einem nx_nic-Treiber führt dazu, dass Server während eines gPXE-Startvorgangs nicht funktionieren
    Wenn eine 10G QLogic-Netzwerkkarte, Version QLE3142, mit einem nx_nic-Treiber für einen gPXE-Startvorgang in die ESXi Stateless-Startkonfiguration verwendet wird, funktioniert der ESXi-Server nicht mehr und kann nicht gestartet werden.

    Umgehung: Verwenden Sie für den gPXE-Startvorgang andere Netzwerkkarten.

  • Das Aktivieren von mehr als 16 VMkernel-Netzwerkadaptern sorgt dafür, dass vSphere vMotion fehlschlägt
    vSphere 5.0 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 zu oder von diesem Host fehlschlagen. Die Fehlermeldung 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 höchstens 16 davon für vMotion aktiviert sind.

  • Unter ESXi 5.0 überschreibt Network I/O Control 802.1p-Tags in ausgehenden Paketen
    In ESXi 5.0 überbrückt Network I/O Control die Lücke zwischen dem QoS (Quality of Service) des virtuellen Netzwerks und dem QoS des physischen Netzwerks, sodass Sie ein 802.1p-Tag auf pro Ressourcenpool-Basis angeben können.
    Ein Nebeneffekt dieser Funktionalität ist, dass jeder Ressourcenpool mit einem Standard-802.1p-Tag (0) versehen wird, auch wenn der Tag nicht explizit festgelegt wurde. CoS-Bit-Tagging innerhalb einer virtuellen Maschine wird beim Verlassen des ESXi-Hosts überschrieben, wenn Network I/O Control aktiviert ist.

    Umgehung:Keine. Wahlweise können Sie Network I/O Control nicht verwenden.

  • VMkernel-Netzwerkadapterkonfigurationen, die nur IPv6 verwenden, werden im Hostprofil nicht unterstützt
    Wenn Sie den vSphere-Client zum Festlegen von IP-Konfigurationen für ein Hostprofil verwenden, können Sie nur IPv4-, nur IPv6- oder eine Kombination aus IPv4- und IPv6-Einstellungen für VMkernel-Netzwerkadapter festlegen. Allerdings werden Einstellungen, die nur IPv6 vorsehen, in Hostprofilen nicht unterstützt. Wenn Sie VMkernel-Netzwerkadapter mit Einstellungen konfigurieren, die nur IPv6 vorsehen, werden Sie aufgefordert, IPv4-Konfigurationen in der Hostprofil-Antwort-Datei anzugeben.

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

    • Verwenden Sie nur IPv6-Einstellungen, wenn Sie Ihre VMkernel-Netzwerkadapter über den vSphere-Client konfigurieren, und verwenden Sie kein Hostprofil.
    • Nehmen Sie sowohl IPv6- als auch IPv4-Konfigurationen für VMkernel-Netzwerkadapter auf, wenn Sie ein Hostprofil erstellen und anwenden, und deaktivieren Sie anschließend die IPv4-Konfigurationen für die VMkernel-Netzwerkadapter, nachdem Sie das Profil angewendet haben.

     

  • Bei einigen Cisco-Switches gehen Pakete mit gesetztem Prioritäts-Bit verloren
    VMware vSphere Network I/O Control ermöglicht Ihnen, den ausgehenden Datenverkehr mit 802.1p-Tags zu versehen. Bei einigen Cisco-Switches (4948 und 6509) gehen die Pakete verloren, wenn die mit Tags versehenen Pakete über das native VLAN (VLAN 0) übertragen werden.

    Umgehung:Keine.

  • Erhebliche Verzögerung des ESXi-Startvorgangs bei der VLAN-Konfiguration und dem Laden von Treibern
    Bei ESXi-Hosts mit BE2- oder BE3-Schnittstellen kommt es zu einer erheblichen Verzögerung beim Laden der Treiber und der VLAN-Konfiguration. Die Verzögerungsdauer steigt mit der Anzahl der BE2- und BE3-Schnittstellen auf dem Host. Die Verzögerung kann mehrere Minuten dauern.

    Umgehung:Keine.

  • Das Hinzufügen eines Netzwerkressourcenpools zu einem vSphere Distributed Switch schlägt mit der Fehlermeldung Der Vorgang für einen vSphere Distributed Switch kann für ein oder mehrere Hostmitglieder nicht abgeschlossen werden fehl
    Diese Fehlermeldung besagt, dass ein oder mehrere Hosts auf dem Distributed Switch bereits der maximalen Anzahl von Netzwerkressourcenpools zugeordnet wurde. Die für einen Host maximal zulässige Anzahl von Netzwerkressourcenpools beträgt 56.

    Umgehung:Keine.

  • Das Hinzufügen eines Netzwerkressourcenpools zu einem vSphere Distributed Switch schlägt mit der Fehlermeldung vim.fault.LimitExceeded fehl
    Diese Fehlermeldung besagt, dass der Distributed Switch bereits über die maximale Anzahl von Netzwerkressourcenpools verfügt. Die für einen vSphere Distributed Switch maximal zulässige Anzahl von Netzwerkressourcenpools beträgt 56.

    Umgehung:Keine.

  • LLDP zeigt keine Systemnamen für extreme Switches an
    Standardmäßig werden die Systemnamen von extremen Switches nicht veröffentlicht. Sofern nicht ausdrücklich festgelegt ist, dass der Systemname eines extremen Switches veröffentlicht wird, kann LLDP diese Informationen nicht anzeigen.

    Umgehung: Führen Sie den Befehl configure lldp ports <port ID> advertise system-name aus, um den Systemnamen des extremen Switches zu veröffentlichen.

  • Das Abschneiden von gespiegelten Paketen sorgt dafür, dass ESXi fehlschlägt
    Wenn die Länge eines gespiegelten Pakets die für die Portspiegelungssitzung festgelegte Länge für gespiegelte Pakete überschreitet ist, schlägt ESXi fehl. Andere Vorgänge, die Pakete abschneiden, sorgen möglicherweise auch dafür, dass ESXi fehlschlägt.

    Umgehung: Legen Sie für eine Portspiegelungssitzung keine Länge für gespiegelte Pakete fest.

  • Fault Tolerance ist nicht kompatibel mit vSphere DirectPath I/O mit vSphere vMotion
    Wenn auf einer virtuellen Maschine Fault Tolerance aktiviert ist, ist DirectPath I/O mit vMotion für alle virtuellen Adapter auf der virtuellen Maschine deaktiviert.

    Umgehung: Deaktivieren Sie Fault Tolerance und starten Sie die virtuelle Maschine neu, bevor Sie DirectPath I/O mit vMotion aktivieren.

  • vSphere DirectPath I/O mit vSphere vMotion wird von VMCI-basierten Anwendungen deaktiviert
    Wenn Sie eine VMCI-basierte Anwendung auf einem Cisco UCS-System verwenden, wird auf allen VM-Netzwerkadaptern DirectPath inaktiv.

    Umgehung: Beenden Sie alle VMCI-basierten Anwendungen und starten Sie die virtuelle Maschine neu, um vSphere DirectPath I/O wiederherzustellen.

Speicher
  • Der E/A-Latenz-Schwellenwert scheint 15 ms zu betragen, nachdem Sie die E/A-Metriken für einen Datenspeicher-Cluster deaktivieren
    Nachdem Sie die E/A-Metriken für einen Datenspeicher-Cluster deaktivieren, wird weiterhin auf der Seite "Übersicht" für den Datenspeicher-Cluster ein E/A-Latenz-Schwellenwert von 15 ms (Standardwert) angezeigt.

    Umgehung:Keine. Wählen Sie zum Anzeigen des richtigen Werts Datenspeicher-Cluster > Speicher.

  • Ein Link für den Wechsel in den SDRS-Wartungsmodus erscheint auf der Seite "Übersicht" eines eigenständigen Datenspeichers
    Nur Datenspeicher, die Teil eines Datenspeicher-Clusters sind, können erfolgreich in den Speicher-DRS-Wartungsmodus versetzt werden. Allerdings erscheint ein Link für den Wechsel in den SDRS-Wartungsmodus auf der Seite "Übersicht" eines Datenspeichers, der sich nicht in einem Datenspeicher-Cluster befindet. Wenn Sie auf In den SDRS-Wartungsmodus wechseln für einen eigenständigen Datenspeicher klicken, versucht der Datenspeicher, in den Wartungsmodus zu wechseln, und es scheint, als stehe die Aufgabe unendlich aus.

    Umgehung:Brechen Sie im Bereich "Kürzlich bearbeitete Aufgaben" des vSphere-Clients die Aufgabe "In den SDRS-Wartungsmodus wechseln" ab.

  • Der Zustand "Keine Pfade verfügbar" (APD) während Storage vMotion kann zu einem Kommunikationsfehler zwischen vCenter Server und dem ESXi-Host führen
    Wenn der Zustand "Keine Pfade verfügbar" (APD) eintritt, wenn Sie virtuelle Maschinen mithilfe von Storage vMotion migrieren, trennt vCenter Server den in Storage vMotion beteiligten Host von der vCenter Server-Bestandsliste. Dieser Zustand bleibt so lange bestehen, bis der Storage vMotion-Vorgang im Hintergrund abgeschlossen ist. Diese Aktion kann je nach Dauer des Storage vMotion-Vorgangs einige Minuten oder Stunden dauern. Während dieser Zeit kann vCenter Server keinen weiteren Vorgang für diesen bestimmten Host durchführen.

    Umgehung:Keine. Nach Abschluss des Storage vMotion-Vorgangs verbindet vCenter Server den Host wieder mit der Bestandsliste. Keine der laufenden virtuellen Maschinen auf nicht-APD-Datenspeichern sind von diesem Fehler betroffen.

  • Dem Datenspeicher hinzugefügte symbolische Links führen möglicherweise dazu, dass Datenspeicherinhalte im Datenspeicherbrowser falsch angezeigt werden
    Wenn Sie symbolische Links auf der obersten Ebene eines Datenspeichers hinzufügen, entweder extern in einem NFS-Server oder durch Anmelden beim Host, werden möglicherweise falsche Datenspeicherinformationen, wie z. B. dessen Dateien und Ordner, angezeigt, wenn Sie den Datenspeicher durchsuchen. Dieses Problem ist möglicherweise auf symbolische Links zurückzuführen, die auf die falschen Dateien und Ordner verweisen.

    Umgehung: Entfernen Sie die symbolischen Links. Verwenden Sie keine symbolischen Links in Datenspeichern.

  • Versuche, eine Erweiterung zu einem ATS-fähigen VMFS-Datenspeicher hinzuzufügen, schlagen fehl
    Sie können einen ATS-fähigen Datenspeicher nur über ein ATS-fähiges Gerät erweitern. Wenn Sie das Gerät, das ATS nicht unterstützt, auswählen, um den ATS-fähigen Datenspeicher zu erweitern, schlägt der Vorgang fehl. Der vSphere-Client zeigt die Meldung Während der Hostkonfiguration ist ein Fehler aufgetretenangezeigt. Möglicherweise erscheint in der Protokolldatei auch die folgende Fehlermeldung: Vorgang fehlgeschlagen, dem Dateisystem konnte keine Erweiterung hinzugefügt werden.

    Umgehung: Stellen Sie vor dem Hinzufügen einer Erweiterung zu einem ATS-Datenspeicher sicher, dass das Erweiterungsgerät ATS unterstützt, indem Sie den folgenden Befehl ausführen:
    esxcli storage core device vaai status get -d=Geräte-ID
    In der Ausgabe müssen die folgenden Informationen angezeigt werden:
    ATS Status: supported

  • Beim Ausgleichen der E/A-Last verhält sich Speicher-DRS möglicherweise nicht wie erwartet
    Wenn Sie IOMeter-Software zum Generieren einer E/A-Last, um Speicher-DRS zu testen, füllt IOMeter die Dateien standardmäßig nur mit Nullbytes. Diese Daten enthalten keine zufälligen Muster aus Einsen und Nullen, die in Echtzeitdaten vorhanden sind und von Speicher-DRS benötigt werden, um die E/A-Merkmale und die Leistung des Datenspeichers festzustellen.

    Umgehung: Verwenden Sie zum Testen der Lastausgleichsfunktionalität von Speicher-DRS reale Daten, um mindestens 20 Prozent des Speicherplatzes des Datenspeichers zu füllen. Wenn Sie IOMeter-Software zum Generieren einer E/A-Last verwenden, wählen Sie eine Version aus, die zufällige Muster aus Einsen und Nullen in Ihre Dateien schreibt.

  • Die Namen der Festplatten einer neuen virtuellen Maschine erscheinen nicht in den Empfehlungen von Speicher-DRS für die anfängliche Platzierung
    Beim Erstellen, Klonen oder Bereitstellen (von Vorlage) einer virtuellen Maschine auf einem Speicher-DRS-fähigen Datenspeicher-Cluster werden die Namen der Festplatten der neuen virtuellen Maschine weder in den Platzierungsempfehlungen noch im Fehlerdialogfeld aufgeführt. Im Dialogfeld wird Neue VM-Festplatte auf <Name des Datenspeichers> platzierenangezeigt.

    Umgehung:Keine. Beim Erstellen von virtuellen Maschinen werden die Namen der Festplatten erst dann zugewiesen, wenn die Festplatten platziert werden. Wenn die Festplatten der virtuellen Maschine unterschiedlich groß sind und auf verschiedenen Datenspeichern platziert werden, können Sie anhand der Speicherplatznutzungsstatistik abschätzen, welche Festplatte auf welchem Datenspeicher platziert wird.

  • Speicher-DRS scheint deaktiviert zu sein, wenn Sie den Assistenten für geplante Aufgaben verwenden, um eine virtuelle Maschine zu erstellen oder zu klonen
    Wenn Sie eine geplante Aufgabe erstellen, um eine virtuelle Maschine zu erstellen oder zu klonen, und einen Datenspeicher-Cluster als Speicherziel für die Dateien der virtuellen Maschine auswählen, ist das Kontrollkästchen "Speicher-DRS für diese virtuelle Maschine deaktivieren" immer aktiviert. Für die virtuelle Maschine können Sie das Kontrollkästchen "Speicher-DRS für diese virtuelle Maschine deaktivieren" im Assistenten für geplante Aufgaben nicht deaktivieren.

    Umgehung:Keine. Das Kontrollkästchen "Speicher-DRS für diese virtuelle Maschine deaktivieren" im Assistenten für geplante Aufgaben ist immer aktiviert. Nach der Ausführung der geplanten Aufgabe und dem Erstellen der virtuellen Maschine ist die Automatisierungsebene der virtuellen Maschine jedoch mit der Standard-Automatisierungsebene des Datenspeichers Clusters identisch.

  • vSphere-Client zeigt einen Fehler an, wenn Sie versuchen, ein Unmounten eines NFS-Datenspeichers durchzuführen, bei dem Storage I/O Control aktiviert ist
    Wenn Sie für einen NFS-Datenspeicher Storage I/O Control aktivieren, können Sie kein Unmounten dieses Datenspeichers durchführen. Die folgende Fehlermeldung erscheint: Die Ressource ist in Gebrauch.

    Umgehung: Deaktivieren Sie Storage I/O Control, bevor Sie versuchen, ein Unmounten des Datenspeichers durchzuführen.

  • ESXi kann nicht zwischen virtuellen Thick-Provision Lazy-Zeroed- und Thick-Provision Eager-Zeroed-Festplatten auf NFS-Datenspeichern mit Unterstützung für die Hardwarebeschleunigung unterscheiden
    Wenn Sie NFS-Datenspeicher verwenden, die die Hardwarebeschleunigung unterstützen, ermöglicht Ihnen der vSphere-Client das Erstellen von virtuellen Festplatten im Format "Thick-Provision Lazy-Zeroed" (zeroedthick) oder "Thick-Provision Eager-Zeroed" (eagerzeroedthick). Wenn Sie jedoch im Dialogfeld "Eigenschaften der virtuellen Maschine" den Festplattentyp überprüfen, wird unabhängig von dem Format, das Sie beim Erstellen der Festplatte ausgewählt haben, stets "Thick-Provision Eager-Zeroed" als Festplattenformat im Abschnitt "Festplattenbereitstellung" angezeigt. ESXi unterscheidet nicht zwischen virtuellen Lazy-Zeroed- und Eager-Zeroed-Festplatten auf NFS-Datenspeichern.

    Umgehung:Keine.

  • Nach der Migration wird der Modus einer IDE-RDM-Festplatte in physischer Kompatibilität nicht in "Unabhängig, dauerhaft" geändert
    Der Modus der IDE-RDM-Festplatte in physischer Kompatibilität ändert sich nicht in "Unabhängig, dauerhaft", nachdem Sie die virtuelle Maschine mit der Festplatte vom ESX/ESXi 4.x-Host auf ESXi 5.0 migriert haben.

    Umgehung:Verwenden Sie nach der Migration den vSphere-Client, um den Modus der Festplatte in "Unabhängig, dauerhaft" zu ändern.

  • Versuche, einer vorhandenen virtuellen Maschine eine RDM mit virtueller Kompatibilität mit einer untergeordneten Festplatte hinzuzufügen, schlagen fehl
    Wenn Sie versuchen, einer vorhandenen virtuellen Maschine eine RDM mit virtueller Kompatibilität, die über eine untergeordnete Festplatte verfügt, hinzuzufügen, schlägt der Vorgang fehl. Im vSphere-Client wird die folgende Fehlermeldung angezeigt: Neukonfiguration fehlgeschlagen: vim.fault.DeviceUnsupportedForVmPlatform.

    Umgehung: Entfernen Sie eine untergeordnete Festplatte, um die RDM mit virtueller Kompatibilität hinzufügen zu können.

  • Versuche, bei aktiviertem Software-FCoE Speicherzuordnungen anzuzeigen, schlagen mit einer Fehlermeldung fehl
    Dieses Problem betrifft nur diejenigen ESXi-Hosts, die ohne eine vorherige Software-FCoE-Konfiguration zu vCenter Server hinzugefügt wurden. Nachdem Sie Software-FCoE-Adapter auf diesen Hosts aktiviert haben, schlagen Versuche, Speicherzuordnungen im vSphere-Client anzuzeigen, fehl. Die folgende Fehlermeldung erscheint: Es ist ein interner Fehler aufgetreten: Antwort konnte nicht serialisiert werden.

    Umgehung: Konfigurieren Sie zuerst Software-FCoE auf dem ESXi-Host und fügen Sie anschließend den Host zu vCenter Server hinzu.

  • Ein NFS-Datenspeicher mit ausreichend Speicherplatz zeigt Fehlermeldungen an, die besagen, dass der Speicherplatz nicht ausreicht
    Dieses Problem tritt nur dann auf, wenn Sie Remote Procedure Calls (RPC) verwenden, Clients gemeinsam nutzen und mehrere NFS-Volumes von derselben NFS-Server-IP-Adresse mounten. Wenn bei dieser Konfiguration der Speicherplatz eines der NFS-Volumes ausgeschöpft wird, könnten andere NFS-Volumes, die denselben RPC-Client gemeinsam nutzen, auch melden, dass der Speicherplatz nicht ausreicht.

    Umgehung: Deaktivieren Sie die gemeinsame Nutzung des RPC-Clients auf Ihrem Host, indem Sie diese Aufgabe durchführen:

    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. Klicken Sie im linken Bereich auf NFS und scrollen Sie nach unten bis "NFS.MaxConnPerIP" (rechts).
    4. Ändern Sie den Standardwert in 128.

     

  • Nach einem Neustart erkennt ein statusfreier Host keine iSCSI-Datenspeicher
    Wenn ein statusfreier Host zu einem Cisco Nexus 1000V Series-Switch hinzugefügt und mit einem MTU-Wert von 9000 konfiguriert wird, kann der Host nach erfolgtem Neustart keine iSCSI-Datenspeicher erkennen, obwohl er die zugehörigen Geräte erkennen kann.

    Umgehung: Um die Datenspeicher sichtbar zu machen, klicken Sie auf dem Bildschirm Konfiguration > Speicher des vSphere-Clients auf Aktualisieren.

Serverkonfiguration
  • Eine Änderung der SATP-PSP-Regel für Hostprofile, die auf einen ESXi-Host angewendet wird, wird nach einem Neustart nicht auf dem Host widergespiegelt
    Nach einer SATP-PSP-Regel (SAN-Arraytyp-Plug-In-Pfadauswahlrichtlinie), dem Anwenden der Änderung und dem Neustart eines mit Auto Deploy bereitgestellten Hosts, wird diese neue Änderung nicht in der SATP-PSP für jedes dieser Geräte widergespiegelt. Im Falle von ESXi-Hosts, die nicht mit Auto Deploy bereitgestellt wurden, wird die SATP-PSP-Änderung ordnungsgemäß auf dem Host aktualisiert. Allerdings scheitert eine Überprüfung der Richtlinieneinhaltung des ESXi-Hosts mit dem Hostprofil.

    Umgehung: Löschen Sie nach dem Anwenden des Hostprofils auf dem ESXi-Host das Hostprofil und extrahieren Sie ein neues Hostprofil aus dem ESXi-Host. Hängen Sie dieses anschließend an den Host, bevor Sie den Host neu starten. Verwenden Sie dazu die Funktion "Profil aus Referenzhost aktualisieren" in der Hostprofil-Benutzeroberfläche. Diese Aufgabe löscht das Hostprofil und extrahiert ein neues Profil vom Host unter Beibehaltung der vorhandenen Anhänge.

    Verwenden Sie den esxcli-Befehl zum Bearbeiten der SATP-PSP auf dem Host selbst, bevor Sie das Hostprofil extrahieren. Verwenden Sie den Hostprofileditor zum Bearbeiten der SATP-PSP nicht.

  • Das Anwenden eines Hostprofils mit einer Dienststartrichtlinie "aus" sorgt nicht dafür, dass der Dienst deaktiviert wird
    Zum Erstellen eines Hostprofils wird als Referenzhost ein ESXi-Host verwendet, bei dem in der Konfiguration einige Dienste deaktiviert sind. Dieses Hostprofil wird dann auf einen Host angewendet, bei dem diese Dienste aktiviert sind. Beim Anwenden des Hostprofils werden die Dienste auf dem ESXi-Zielhost nicht deaktiviert. Diese Situation tritt in der Regel bei Benutzern ein, die die ESXShell- oder SSH-Dienste auf den ESXi-Zielhosts über das Sicherheitsprofil im vSphere-Client oder die Fehlerbehebungsoptionen in der DCUI aktiviert haben.

    Umgehung: Der Neustartvorgang deaktiviert die Dienste. Sie können im vSphere-Client die Dienste auch manuell beenden, indem Sie den Host konfigurieren. Führen Sie diesen Vorgang für jeden Dienst durch.

    1. Wählen Sie den Host in der Bestandsliste aus.
    2. Klicken Sie auf die Registerkarte Konfiguration.
    3. Klicken Sie im Abschnitt "Software" auf Sicherheitsprofil.
    4. Klicken Sie auf Eigenschaften und wählen Sie den Dienst aus.
    5. Klicken Sie auf Optionen.
    6. Klicken Sie auf Anhalten und anschließend auf OK.
  • Der Antwortdateistatus des Hostprofils wird beim Austauschen des angehängten Profils des Hosts nicht aktualisiert
    Beim Anhängen eines Hostprofils an einen Host, der vorher an ein anderes Hostprofil angehängt war, wird der Antwortdateistatus nicht aktualisiert. Wenn der Status der Antwortdatei "Abgeschlossen" lautet, wird er in der Hostprofilansicht immer noch als "Abgeschlossen" aufgeführt, nachdem ein anderes Hostprofil an den Host angehängt wurde. Allerdings wurde der tatsächliche Status möglicherweise in "Nicht abgeschlossen" geändert.

    Umgehung: Aktualisieren Sie den Status der Antwortdatei manuell, wenn Sie ein Hostprofil angehängt haben.

    1. Wählen Sie in der Bestandslistenansicht "Hostprofile" des vSphere-Clients das neu angehängte Profil aus.
    2. Klicken Sie auf die Registerkarte Hosts und Cluster.
    3. Klicken Sie mit der rechten Maustaste in der Liste "Elementname" auf den Host und wählen Sie Antwortdatei prüfen.

    Der Antwortdateistatus für das Hostprofil wird aktualisiert.

  • Mögliche Zeitüberschreitung beim manuellen Anwenden eines Hostprofils mit einer großen Konfiguration
    Beim Anwenden eines Hostprofils mit einer großen Konfiguration, wie z. B. einer großen Anzahl von vSwitches und Portgruppen, tritt möglicherweise eine Zeitüberschreitung ein, wenn der Zielhost entweder nicht oder nur teilweise konfiguriert ist. In solchen Fällen erscheint im vSphere-Client die Fehlermeldung Die Hostkonfiguration kann nicht übernommen werden, obwohl der zugrunde liegende Prozess auf ESXi, der die Konfiguration anwendet, möglicherweise weiterhin ausgeführt wird.

    Zudem enthalten syslog.log oder andere Protokolldateien möglicherweise Fehlermeldungen wie die folgenden:
    Fehler beim Interagieren mit Konfigurationsdatei /etc/vmware/esx.conf: Zeitüberschreitung beim Warten auf die Freigabe der Sperre /etc/vmware/esx.conf.LOCK. Ein anderer Prozess hat diese Datei für mehr als 20 Sekunden gesperrt. Der Prozess, der die Sperre zurzeit besitzt, ist hostd-worker(5055). Dies ist wahrscheinlich ein temporärer Zustand. Versuchen Sie es später erneut.

    Dieser Fehler wird durch ein Systemkonflikt verursacht, wenn mehrere Vorgänge versuchen, Informationen zur Systemkonfiguration abzurufen, während das Hostprofil die Konfiguration anwendet. Aufgrund dieser Fehler und anderer zeitüberschreitungsbezogenen Fehler wird die Konfiguration, die im Hostprofil erfasst wurde, möglicherweise auch nicht nach Abschluss des Anwendungsvorgangs des Hostprofils angewendet. Überprüfen Sie den Host auf Übereinstimmung, um die Teile der Konfiguration, die nicht angewendet wurden, zu ermitteln, und führen Sie einen Anwendungsvorgang durch, um diese aufgetretenen Probleme bei der Übereinstimmung zu beheben.

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

    • ESXi-Hosts, die nicht mit Auto Deploy bereitgestellt wurden

      1. Erhöhen Sie den Zeitüberschreitungswert für den Anwendungsvorgang, indem Sie den folgenden Eintrag zur Datei /etc/vmware/hostd/cmdMo.xml hinzufügen:

        <managedObject id="2">
        <type> vim.profile.host.profileEngine.HostProfileManager </type>
        <moId> ha-hostprofileengine-hostprofilemanager </moId>
        --> <timeOutInSeconds> xxxx </timeOutInSeconds> <--****
        <version> vim.version.dev </version>
        <cmd> /usr/bin/sh </cmd>
        <arg id="1"> -l </arg>
        <arg id="2"> -c </arg>
        <arg id="3"> /usr/lib/vmware/hostd/hmo/hostProfileEngine.py --cgi </arg>
        </managedObject>


        Wobei xxxx der Zeitüberschreitungswert in Sekunden ist. Der Zeitüberschreitungswert für den Anwendungsvorgang beträgt standardmäßig 10 Minuten. Sie können mit diesem Eintrag auch einen längeren Zeitüberschreitungswert festlegen. Beispielsweise erhöht ein Wert von 3600 den Zeitüberschreitungswert auf 1 Stunde. Der zu verwendende Wert kann je nach der Konfiguration des Hostprofils variieren. Nach Festlegung eines ausreichend hohen Werts erscheint der Zeitüberschreitungsfehler für den Anwendungsvorgang nicht mehr und die Aufgabe ist bis zu ihrem Abschluss im vSphere-Client sichtbar.
      2. Starten Sie hostd neu.
    • Hosts, die mit Auto Deploy bereitgestellt wurden

      1. Starten Sie den mit Auto Deploy bereitgestellten ESXi-Host neu.
      2. Stellen Sie bei ESXi-Hosts, die mit Auto Deploy bereitgestellt wurden, sicher, dass die Antwortdatei vollständig ist, indem Sie auf dem ESXi-Host den Vorgang "Antwortdatei aktualisieren" ausführen und anschließend den Host neu starten.

        Die Konfiguration im Hostprofil und der Antwortdatei wird während der Systeminitialisierung angewendet. Bei großen Konfigurationen kann der Neustart länger dauern. Dennoch ist es erheblich schneller als das manuelle Anwenden des Hostprofils über den vSphere-Client.
  • Die Überprüfung der Richtlinieneinhaltung eines Hostprofils für einen Referenzhost mit einem neu erstellten Profil schlägt fehl
    Eine Überprüfung der Richtlinieneinhaltung für ein neu konfiguriertes Hostprofil, z. B. mit iSCSI konfiguriert, schlägt möglicherweise fehl, wenn vor der Überprüfung die Antwortdatei nicht aktualisiert wurde.

    Umgehung:Aktualisieren Sie die Antwortdatei für das Profil, bevor Sie eine Überprüfung der Richtlinieneinhaltung durchführen.

  • Ein Hostprofil kann nicht angewendet werden, wenn das syslog-Protokollverzeichnis auf einen Datenspeicher ohne Pfad festgelegt wurde
    Wenn das syslog-Verzeichnis mit dem esxcli-Befehl oder mit dem vSphere-Client auf einen Datenspeicher ohne zusätzlichen Pfad festgelegt wird, kann ein aus diesem System extrahiertes Hostprofil nicht auf andere Hosts angewendet werden.

    Im nachfolgenden Beispiel wird das System auf eine Weise konfiguriert, die diesen Zustand hervorruft:
    esxcli system syslog config set --logdir /vmfs/volumes/datastore1

     

    Das Festlegen von "Syslog.global.logDir" auf "datastore1" im Dialogfeld "Erweiterte Einstellungen" der Registerkarte "Konfiguration" des Hosts führt ebenfalls zu diesem Problem.

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

    • Ändern Sie im Dialogfeld "Erweiterte Einstellungen" den Wert von "Syslog.global.logDir" von "DATASTORE_NAME" auf "DATASTORE_NAME /", bevor Sie das Hostprofil extrahieren.
    • Bearbeiten Sie das Hostprofil, damit die Option "Syslog.global.logDir" für die erweiterte Konfiguration an Stelle von "DATASTORE_NAME" den Wert "DATASTORE_NAME /" hat.

     

  • Durch das Anwenden eines Hostprofils werden möglicherweise vSwitches und Portgruppen neu erstellt
    Die vSwitches und Portgruppen eines Hosts werden möglicherweise neu erstellt, wenn ein Hostprofil angewendet wird. Dies kann selbst dann vorkommen, wenn der Host dem Hostprofil entspricht.

    Dieses Problem tritt auf, wenn für die Optionen der Portgruppenprofil-Richtlinie die Standardwerte verwendet werden. Diese Einstellung führt zu einem Problem, bei dem der Vergleich zwischen dem Profil und der Hostkonfiguration fälschlicherweise fehlschlägt, wenn das Profil angewendet wird. Zu diesem Zeitpunkt verläuft die Überprüfung der Richtlinieneinhaltung erfolgreich. Der Fehler beim Vergleich führt dazu, dass durch die Aktion zum Anwenden des Profils die vSwitches und Portgruppen neu erstellt werden. Dies betrifft alle Unterprofile im Portgruppenprofil.

    Umgehung: Ändern Sie die Profileinstellungen, damit sie den gewünschten Einstellungen entsprechen, anstatt die Standardeinstellungen zu verwenden.

  • Der in VMware eingebettete SNMP-Agent meldet ein falsches Datum für die Softwareinstallation über hrSWInstalledTablevon HOST-RESOURCES-MIB
    Wenn Sie anhand des in VMware eingebetteten SNMP-Agenten nach installierter Software (hrSWInstalledTable RFC 2790) suchen, ist das Installationsdatum für vom Benutzer installierte Software falsch, weil hrSWInstalledTablevon HOST-RESOURCES-MIBein falsches hrSWInstalledDatemeldet.

    Umgehung: Um das korrekte Installationsdatum abzurufen, verwenden Sie den esxcli-Befehl esxcli software vib list.

vCenter Server und vSphere-Client

  • Unbekannter Gerätestatus auf der Registerkarte "Hardwarestatus" des vCenter Server
    In der Ansicht Sensoren der Registerkarte Hardwarestatus des vCenter Server wird der Status für einige PCI-Geräte als Unbekannt Unbekannt #<Nummer>angezeigt. Die neuesten PCI-IDs für einige Geräte sind in der Datei /usr/share/hwdata/pci.idsauf dem ESXi-Host nicht aufgelistet. vCenter Server listet Geräte mit fehlenden IDs als unbekannt auf.

    Der unbekannte Status ist nicht kritisch, und die Liste der PCI-IDs wird regelmäßig in Hauptversionen von vSphere aktualisiert.

  • Datenbankfehler beim erneuten Registrieren von AutoDeploy auf vCenter Virtual Appliance (VCVA) (KB 2014087).
  • Der Befehl "snmpwalk" generiert eine Fehlermeldung, wenn Sie ihn ohne die Option "-t" ausführen
    Wenn der Befehl snmpwalkohne die Optionen -tund -rzum Abfragen von SNMP-Daten ausgeführt wird, zeigt der eingebettete VMware-SNMP-Agent die Daten unvollständig an und generiert die Fehlermeldung Keine Antwort vom Host.

    Umgehung: Wenn Sie den Befehl snmpwalkausführen, verwenden Sie die Option -t, um das Zeitüberschreitungsintervall anzugeben, und die Option -r, um die Anzahl an Wiederholungen anzugeben. Beispiel: snmpwalk -m all -c public -v1 Hostname -r 2 -t 10 Name der Variablen.

  • Der vCLI-Befehl zum Löschen der eingebetteten Konfiguration des SNMP-Agenten setzt die Quelle der Indications zurück und löscht Trapfilter
    Der vCLI-Befehl vicfg-snmp -rzum Löschen der eingebetteten Konfiguration des SNMP-Agenten setzt die Quelle von Ereignissen oder Traps auf den Standardwert indicationszurück und löscht alle Trapfilter.

    Umgehung:Keine.

  • Das Aktivieren des eingebetteten SNMP-Agenten schlägt fehl mit der Fehlermeldung "Adresse wird bereits verwendet"
    Wenn Sie einen Port außer udp/161 für den eingebetteten SNMP-Agenten konfigurieren, währen der Agent nicht aktiviert ist, überprüft der Agent nicht, ob der Port verwendet wird. Dies könnte zu einem Portkonflikt führen, wenn Sie den Agenten aktivieren, und die Fehlermeldung Adresse wird bereits verwendetgenerieren.

    Umgehung: Aktivieren Sie den eingebetteten SNMP-Agenten, bevor Sie den Port konfigurieren.

Verwaltung von virtuellen Maschinen

  • Der Mauszeiger kann möglicherweise nicht aus der virtuellen Maschine mit Windows Server 2012 R2 oder Windows 8.1 herausbewegt werden, nachdem VMware Tools installiert wurde*
    Wenn Sie VMware Tools auf einer virtuellen Maschine mit Windows Server 2012 R2 oder Windows 8.1 installieren, kann der Mauszeiger möglicherweise nicht aus der virtuellen Maschine herausbewegt werden. Dieses Problem tritt auf, wenn Sie den USB 2.0-Controller vor der Installation von VMware Tools konfigurieren.

    Umgehung: Legen Sie die folgende Konfigurationsoption in der .vmx-Datei fest:
    mouse.vusb.enable = "FALSE"

  • Treiberverfügbarkeit für xHCI-Controller für USB 3.0-Geräte
    Virtuelle Hardwareversion 8 bietet Unterstützung für den xHCI-Controller und USB 3.0-Geräte. Allerdings steht für viele Betriebssysteme kein xHCI-Treiber zur Verfügung. Ohne einen im Gastbetriebssystem installierten Treiber können Sie keine USB 3.0-Geräte verwenden. Zurzeit sind keine Treiber für das Windows-Betriebssystem verfügbar. Wenden Sie sich an den Anbieter des Betriebssystems, um zu erfahren, wann ein Treiber zur Verfügung stehen wird. Wenn Sie virtuelle Maschinen mit Windows-Gastbetriebssystemen erstellen oder aktualisieren, können Sie den vorhandenen EHCI+UHCI-Controller, der USB 1.1- und 2.0-Geräte für die USB-Konfiguration von einem ESXi-Host oder einem Clientcomputer auf eine virtuelle Maschine unterstützt, weiterhin verwenden. Wenn Ihre virtuelle Windows-Maschine über xHCI- und EHCI+UHCI-USB-Controller verfügt, werden neu hinzugefügte USB 1.1- und USB 2.0-Geräte mit xHCI verbunden und nicht vom Gastbetriebssystem erkannt.

    Umgehung: Entfernen Sie den xHCI-Controller aus der Konfiguration der virtuellen Maschine, um USB-Geräte mit EHCI+UHCI zu verbinden.

  • Linux-Kernels früher als 2.6.27 melden keine Nicht-2er-Potenzen für Kerne pro Socket
    Ab ESXi 5.0 ermöglicht die Unterstützung von virtuellen CPUs mit mehreren Kernen Nicht-2er-Potenzen für Kerne pro Socket. Linux-Kernels vor 2.6.27 melden nur 2er-Potenz-Werte für Kerne pro Socket korrekt. Beispielsweise melden einige Linux-Gastbetriebssysteme möglicherweise keine Informationen zu physischen IDs, wenn Sie numvcpus = 6und cpuid.coresPerSocket = 3in der .vmx-Datei festlegen. Linux-Kernels 2.6.28 und höher melden die CPU- und Kerntopologie ordnungsgemäß.

    Umgehung: Keine

  • Wenn Sie virtuellen Maschinen mit Linux 64-Bit-, Windows 7- oder Windows 8 32-Bit-Gastbetriebssystemen im laufenden Betrieb Arbeitsspeicher hinzufügen, können Sie den vorhanden virtuellen Speicher nicht auf mehr als 3 GB erhöhen
    Beim Hinzufügen von Arbeitsspeicher im laufenden Betrieb zu virtuellen Maschinen mit Linux 64-Bit-, Windows 7 und Windows 8 32-Bit Gastbetriebssystemen gelten die folgenden Voraussetzungen.

    • Wenn die eingeschaltete virtuelle Maschine über weniger als 3 GB Arbeitsspeicher verfügt, können Sie nicht mehr als 3 GB Arbeitsspeicher im laufenden Betrieb hinzufügen.
    • Wenn die virtuelle Maschine über 1 GB Arbeitsspeicher verfügt, können Sie 2 GB hinzufügen.
    • Wenn die virtuelle Maschine über 2 GB Arbeitsspeicher verfügt, können Sie 1 GB hinzufügen.
    • Wenn die virtuelle Maschine über 3444 MB Arbeitsspeicher verfügt, können Sie 128 MB hinzufügen.
    • Wenn die eingeschaltete virtuelle Maschine über genau 3 GB Arbeitsspeicher verfügt, können Sie keinen Arbeitsspeicher im laufenden Betrieb hinzufügen.

     

    Wenn die eingeschaltete virtuelle Maschine über mehr als 3 GB Arbeitsspeicher verfügt, können Sie den Arbeitsspeicher der virtuellen Maschinen auf bis zu 16 Mal der anfänglichen, eingeschalteten Größe oder bis zu dem Hardwarelimit erhöhen, je nachdem, was kleiner ist. Die Hardwareversionsgrenze ist 255 GB für Hardwareversion 7 und 1011 GB für Hardwareversion 8.

    Linux 64-Bit- und Windows 7 und Windows 8 32-Bit-Gastbetriebssysteme hängen, wenn deren Arbeitsspeicher von 3 GB oder weniger auf mehr als 3 GB erhöht wird, während die virtuelle Maschine eingeschaltet ist. Diese vSphere-Einschränkung stellt sicher, dass Sie diesen Fehler im Gastbetriebssystem nicht auslösen.

    Umgehung:Keine.

  • Fehler beim Hinzufügen von CPUs im laufenden Betrieb auf virtuellen Maschinen der Hardwareversion 7
    Das Hinzufügen virtueller CPUs im laufenden Betrieb wird mit der virtuellen Mehrkern-CPU-Funktion für virtuelle Maschinen der Hardwareversion 8 unterstützt.
    Wenn Sie bei virtuellen Maschinen der Hardwareversion 7 mit mehr als einem Kern pro Socket im Dialogfeld "Eigenschaften der virtuellen Maschine" das Hinzufügen von CPUs im laufenden Betrieb aktivieren und versuchen, CPUs im laufenden Betrieb hinzuzufügen, schlägt der Vorgang fehl und die Fehlermeldung Das CPU-Hotplug wird für diese virtuelle Maschine nicht unterstützterscheint.

    Umgehung: Wenn Sie bei virtuellen Maschinen mit der Hardwareversion 7 die Funktion für das Hinzufügen von CPUs im laufenden Betrieb verwenden möchten, schalten Sie die virtuelle Maschine aus und legen Sie die Anzahl der Kerne pro Socket auf 1 fest.
    Die besten Ergebnisse erzielen Sie, wenn Sie virtuelle Maschinen der Hardwareversion 8 verwenden.

  • Das Hinzufügen von Arbeitsspeicher im laufenden Betrieb zu einem Windows 2003 32-Bit-System, das den LSISAS-Treiber vom 20. November 2007 verwendet, kann dazu führen, dass die virtuelle Maschine nicht mehr antwortet
    Der LSISAS-Treiber vom 20. November 2007 kann den Arbeitsspeicher über 3 GB nicht ordnungsgemäß adressieren, wenn diese Art von Arbeitsspeicher beim Systemstart nicht vorhanden ist. Wenn Sie Arbeitsspeicher im laufenden Betrieb zu einem System hinzufügen, das vor dem Vorgang über weniger als 3 GB Arbeitsspeicher, aber nach dem Vorgang über mehr als 3 GB Arbeitsspeicher verfügt, wird der Zustand von Windows beschädigt und Windows reagiert bald nicht mehr.

    Umgehung: Verwenden Sie den neuesten LSI SAS-Treiber, der auf der LSI-Website zur Verfügung steht. Verwenden Sie nicht den virtuellen LSISAS1068-Adapter für virtuelle Windows 2003-Maschinen.

  • Falsche IPv6-Adresse erscheint auf der Registerkarte "Übersicht" auf MacOS X Server 10.6.5 und höheren Gastbetriebssystemen
    Wenn Sie auf Alle anzeigen auf der Registerkarte Übersicht des vSphere-Clients klicken, enthält die Liste der IPv6-Adressen eine falsche Adresse für die lokale Verbindungsadresse. Sie sehen die falsche Adresse, wenn Sie ifconfigausführen und die Ausgabe des Befehls mit der Liste der Adresse im vSphere-Client vergleichen. Diese falsche Information erscheint auch dann, wenn Sie den Befehl vim-cmdausführen, um die GuestInfo-Daten abzurufen.

    Umgehung: Keine

  • Das gleichzeitige Erstellen einer großen Anzahl an virtuellen Maschinen sorgt dafür, dass Dateivorgänge fehlschlagen
    Wenn Sie gleichzeitig eine große Anzahl an virtuellen Maschinen erstellen, die sich innerhalb desselben Verzeichnisses befinden, wird das Speichersystem überfordert und infolgedessen schlagen einige Dateivorgänge fehl. Eine vim.fault.CannotAccessFile-Fehlermeldung erscheint und der Vorgang zum Erstellen der virtuellen Maschine schlägt fehl.

    Umgehung: Erstellen Sie zusätzliche virtuelle Maschinen in kleineren Bündeln, z. B. 64, oder versuchen Sie, virtuelle Maschinen in unterschiedlichen Datenspeichern oder innerhalb von unterschiedlichen Verzeichnissen desselben Datenspeichers zu erstellen.

  • USB-Geräte, die von einem ESXi-Host an eine virtuelle Maschine übergeben werden, werden während einer Migration mit vMotion möglicherweise getrennt
    Wenn ein USB-Gerät von einem ESXi-Host an eine virtuelle Maschine übergeben wird und das Gerät so konfiguriert ist, dass es während der Migration mit vMotion verbunden bleibt, wird das Gerät während des vMotion-Vorgangs möglicherweise getrennt. Die Geräte können auch getrennt werden, wenn DRS eine Migration auslöst. Wenn die Geräte getrennt werden, kehren sie zum Host zurück und sind nicht mehr mit der virtuellen Maschine verbunden. Dieses Problem tritt häufiger auf, wenn Sie virtuelle Maschinen mit mehreren verbundenen USB-Geräten migrieren. Es kann jedoch auch auftreten, wenn nur ein Gerät oder eine kleine Anzahl von Geräten verbunden sind.

    Umgehung:Führen Sie eine Migration der virtuellen Maschine zurück auf den ESXi-Host durch, an den die USB-Geräte physisch angeschlossen sind, und verbinden Sie die Geräte mit der virtuellen Maschine neu.

  • Eine virtuelle Maschine mit einem unzugänglichen SCSI-Passthrough-Gerät kann nicht eingeschaltet werden
    Wenn ein mit einer virtuellen Maschine verbundenes SCSI-Passthrough-Gerät über eine Geräteunterstützung verfügt, die vom Host der virtuellen Maschine unzugänglich ist, kann die virtuelle Maschine nicht eingeschaltet werden. Es erscheint zudem die folgende Fehlermeldung: Beim ESX-Host ist ein unerwarteter Fehler beim Einschalten der virtuellen Maschine aufgetreten..

    Umgehung: Führen Sie einen der folgenden Vorgänge durch:

    • Wenn der Host der virtuellen Maschine über ein physisches SCSI-Gerät verfügt, ändern Sie die Geräteunterstützung des SCSI-Passthrough-Geräts des Hosts und schalten Sie die virtuelle Maschine ein.
    • Verfügt der Host nicht über ein physisches SCSI-Gerät , entfernen Sie das SCSI-Passthrough-Gerät von der virtuellen Maschine und schalten Sie sie ein.

     

  • Das Taskleistensymbol von VMware Tools zeigt den Status möglicherweise als "Veraltet" an
    Wenn eine virtuelle Maschine VMware Tools verwendet, die mit vSphere 4.x installiert wurde, zeigt das Symbol in der Taskleiste des Gastbetriebssystems den Status möglicherweise als "Veraltet" an. Im vSphere 5.0-Client und vSphere Web Client wird auf der Registerkarte Übersicht für die virtuelle Maschine der Status als Veraltet (OK. Diese Version wird auf dem vorhandenen Host unterstützt, Sie müssen jedoch ein Upgrade durchführen, falls die neuen Funktionen nicht ordnungsgemäß ausgeführt werden können)angezeigt. VMware Tools, die mit vSphere 4.x installiert wurde, wird unterstützt. Ein Upgrade für die Verwendung mit vSphere 5.0 ist nicht zwingend erforderlich.

    Umgehungen: Verwenden Sie in vSphere 5.0 die Registerkarte Übersicht für die virtuelle Maschine im vSphere-Client oder in vSphere Web Client, um den Status von VMware Tools zu ermitteln. Wenn der Status "Veraltet" lautet und Sie kein Upgrade durchführen möchten, können Sie die folgenden Einstellungen zum Deaktivieren der Upgrade-Eingabeaufforderungen und des Warnsymbols im Gastbetriebssystem verwenden:

    • Wenn die virtuelle Maschine so eingestellt ist, dass ein automatisches Upgrade von VMware Tools durchgeführt wird, Sie aber möchten, dass die virtuelle Maschine auf der niedrigsten unterstützten Version verbleibt, setzen Sie die folgende Eigenschaft als erweiterten Konfigurationsparameter: Setzen Sie tools.supportedOld.autoupgradeauf FALSE. Diese Einstellung deaktiviert auch das Ausrufezeichensymbol des Gastbetriebssystems, das angibt, dass VMware Tools nicht unterstützt wird.
    • Wenn VMware Tools veraltet ist und Sie das Ausrufezeichensymbol deaktivieren möchten, das auf dem VMware Tools-Symbol in der Taskleiste erscheint, setzen Sie die folgende Eigenschaft als einen erweiterten Konfigurationsparameter: Setzen Sie tools.supportedOld.warnauf FALSE.

    Keine dieser Einstellungen beeinflusst das Verhalten von VMware Tools, wenn auf der Registerkarte "Übersicht" der Status als "Nicht unterstützt" oder "Fehler" angezeigt wird. In diesen Situationen erscheint das Ausrufezeichensymbol und ein Upgrade von VMware Tools wird auch dann automatisch durchgeführt (sofern diesbezüglich konfiguriert), wenn die erweiterten Konfigurationseinstellungen auf FALSEfestgelegt sind. Sie können erweiterte Konfigurationsparameter entweder durch Bearbeiten der .vmx-Konfigurationsdatei der virtuellen Maschine oder durch die Verwendung des vSphere-Clients oder von vSphere Web Client zum Bearbeiten der Einstellungen der VM festlegen. Wählen Sie auf der Registerkarte Optionen die Option Erweitert > Allgemein aus und klicken Sie auf Konfigurationsparameter.

  • Das Prüfen und Aktualisieren der Tools beim Aus- und erneutem Einschalten funktioniert nicht in ESXi 5.0 und höher
    In ESX/ESXi 4.1 stand die Option "Tools beim Aus- und erneutem Einschalten prüfen und aktualisieren" zum Durchführen eines Upgrades von VMware Tools zur Verfügung, wenn die virtuelle Maschine heruntergefahren war. Diese Funktion funktioniert nicht in ESXi 5.0 und höher. Ignorieren Sie alle dokumentierten Verfahren bezüglich dieser Funktion.

    Umgehung: Installieren Sie VMware Tools manuell.

  • Bei Mac OS X-Gastbetriebssystemen mit hoher CPU- und Arbeitsspeichernutzung tritt möglicherweise beim Anhalten oder Fortsetzen einer virtuellen Maschine oder während Migrationsvorgängen eine Kernelpanik auf
    Nach Vorgängen zum Anhalten oder Fortsetzen einer virtuellen Maschine oder während Migrationsvorgängen auf einem Host mit einer schweren CPU- und Arbeitsspeicherlast tritt möglicherweise eine Zeitüberschreitung bei der TLB-Invalidierungsanforderung ein. In solchen Fällen antwortet das Mac OS X-Gastbetriebssystem nicht mehr und eine Variante einer der folgenden Meldungen wird in die Datei "vmware.log" geschrieben:
    The guest OS panicked. The first line of the panic report is: Panic(CPU 0): Unresponsive processor
    The guest OS panicked. The first line of the panic report is: panic(cpu 0 caller 0xffffff8000224a10): "pmap_flush_tlbs()timeout: " "cpu(s) failing to respond to interrupts,pmap=0xffffff800067d8a0 cpus_to_respond=0x4"@/SourceCache/xnu/xnu-1504.7.4/osfmk/x86_64/pmap.c:2710

    Umgehung: Reduzieren Sie die CPU- und Arbeitsspeicherlast auf dem Host oder reduzieren Sie die Anzahl virtueller CPUs auf 1.

  • Vorgänge zum Klonen oder Verschieben einer virtuellen Maschine von ESXi 5.0 auf ESX/ESXi 4.1 schlagen fehl, wenn die Replizierung aktiviert ist
    Wenn Sie den Befehl hbr enablereplicationverwenden, um die Replizierung einer virtuellen Maschine zu aktivieren, die sich auf einem ESXi 5.0-Host befindet, und die virtuelle Maschine auf einen ESX/ESXi 4.1- oder früheren Host klonen, schlägt die Validierung mit einer Fehlermeldung ähnlich der Folgenden fehl: Vorgang wird nicht unterstützt. Das Klonen von virtuellen ESXi 5.0-Maschinen auf ESX/ESXi 4.1-Hosts wird nicht unterstützt.

    Umgehung:Wählen Sie eine der folgenden Umgehungen aus:

    • Klonen Sie die virtuelle Maschine auf einen ESXi 5.0-Host
    • Klonen oder verschieben Sie eine neue virtuelle Maschine auf einem ESX/ESXi 4.1-Host.
  • Benutzerdefinierte VMware Tools-Skripts können nicht über die VMware-Toolbox-Benutzeroberfläche in einem Linux-Gastbetriebssystem festgelegt werden, wenn die benutzerdefinierten Skripts Nicht-ASCII-Zeichen in ihren Pfaden enthalten
    In Linux-Gastbetriebssystemen werden im Fenster "VMware Tools - Eigenschaften" Nicht-ASCII-Zeichen als kleine Quadrate mit einem Xdargestellt, wenn das Systemgebietsschema zh_CN.gb18030, ja_JP.eucjpoder ko_KR.euckrist. In diesen Fällen können Sie keine benutzerdefinierten VMware Tools-Skripts festlegen.

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

    • Ändern Sie den Namen des Verzeichnisses, in dem sich die benutzerdefinierten VMware Tools-Skripts befinden, sodass sie nur ASCII-Zeichen enthalten.
    • Legen Sie die benutzerdefinierten VMware Tools-Skripts fest, indem Sie in einer Shell den Befehl vmware-toolbox-cmd scripteingeben.

     

  • Nicht-ASCII-DNS-Suffixe werden nach dem Anpassen von Windows XP und Windows 2003 nicht ordnungsgemäß gesetzt
    Wenn Sie den Assistenten zur Anpassung von Spezifikationen verwenden, um Windows XP oder Windows 2003 anzupassen, und auf der Registerkarte DNS der Netzwerkeigenschaften ein Nicht-ASCII-DNS-Suffix eingeben, wird die Anpassung als erfolgreich gemeldet, aber das Nicht-ASCII-DNS-Suffix wird nicht ordnungsgemäß gesetzt.

    Umgehung:Legen Sie unter Windows XP und Windows 2003 das DNS-Suffix manuell fest.

  • In VMware eingebetteter SNMP-Agent meldet für Prozessoren im hrDeviceStatus-Objekt des HOST-RESOURCES-MIB-Moduls einen falschen Status
    Beim Übermitteln der Systemdetails zeigt der in VMware eingebettete SNMP-Agent für Prozessoren einen falschen Status an. Der SNMP-Agent meldet den Prozessorstatus Unbekanntfür das hrDeviceStatus-Objekt in HOST-RESOURCES-MIB. Die ESX/net-snmp-Implementierung von HOST-RESOURCES-MIB gibt das hrDeviceStatus-Objekt nicht zurück, was dem Übermitteln des Status Unbekanntentspricht.

    Umgehung: Verwenden Sie entweder CIM-APIs oder SMBIOS-Daten zum Überprüfen des Prozessorstatus.

  • Der Snapshot-Festplattenpfad in der .vmsd-Snapshot-Datenbankdatei und der übergeordnete Pfad in der Delta-Festplattendeskriptordatei werden nach der Migration nicht aktualisiert
    Wenn snapshot.redoNotWithParentauf TRUEfestgelegt ist und Sie die Einstellung snapshotDirectorybeispielsweise von Datenbank A in Datenbank B ändern, erhalten Sie möglicherweise die Fehlermeldung Es wurde eine ungültige Snapshot-Konfiguration erkannt. Dieses Problem tritt auf, wenn beide der folgenden Bedingungen erfüllt sind:

    • Sie stellen einen vorherigen Snapshot in der Snapshot-Struktur wieder her und erstellen neue Snapshots von diesem Snapshot-Punkt aus. Dies führt zu einer nicht linearen Hierarchie in der Snapshot-Struktur.
    • Die Festplatten-Links in einer Festplattenkette umfassen mehrere Datenspeicher und enthalten sowohl den Quell- als auch den Zieldatenspeicher. Diese Situation tritt auf, wenn Sie die snapshotDirectory-Einstellungen mehrmals ändern, sodass sie auf verschiedene Datenspeicher verweisen, und Sie zwischen den snapshotDirectory-Änderungen Snapshots der virtuellen Maschine erstellen. Beispiel: Sie erstellen Snapshots einer virtuellen Maschine, wobei snapshotDirectoryauf Datenspeicher A festgelegt ist, stellen einen vorherigen Snapshot wieder her, ändern anschließend die snapshotDirectory-Einstellung auf Datenspeicher B und erstellen zusätzliche Snapshots. Dann migrieren Sie die virtuelle Festplatte von Datenspeicher B nach Datenspeicher A.

    Es ist Best Practice, die Standardeinstellung beizubehalten, mit der der übergeordnete und die untergeordneten Snapshots zusammen in dem Snapshot-Verzeichnis gespeichert werden. Sie sollten es vermeiden, die snapshotDirectory-Einstellungen zu ändern oder zwischen Datenspeicheränderungen Snapshots zu erstellen. Wenn Sie snapshot.redoNotWithParentauf TRUEfestlegen, führen Sie eine vollständige Speichermigration auf einen Datenspeicher durch, der zurzeit nicht von der virtuellen Maschine verwendet wird.

     

    Umgehung: Aktualisieren Sie die Festplattenpfadreferenzen in der Snapshot-Datenbankdatei und der Festplattendeskriptordatei manuell auf den korrekten Datenspeicherpfad.

Migration
  • Beim Übergang auf die Sommerzeit wird die Zeitachse auf den Leistungsdiagrammen nicht auf die neue Uhrzeit aktualisiert.
    Beispiel: Die lokalen Uhren in Gebieten, in denen die Uhren umgestellt werden, wurden am Sonntag, dem 27. März 2011 um 3 Uhr um eine Stunde vorgestellt. Die Markierungen auf der Zeitachse von Leistungsdiagrammen hätten ..., 2:00, 2:20, 2:40, 4:00, 4:20, ...lauten sollen, d. h. ohne Markierungen für die Stunde, die um 3 Uhr beginnt. In Wirklichkeit werden jedoch die Markierungen ..., 2:00, 2:20, 2:40, 3:00, 3:20, 3:40, 4:00, 4:20, ...angezeigt.

    Umgehung: Keine

  • Nach einem Storage vMotion-Vorgang, bei dem der Benutzer eine Datenträgerformatänderung angibt, behalten Festplatten virtueller Maschinen ihr ursprüngliches Format bei
    Wenn Sie während eines Storage vMotion-Vorgangs einer eingeschalteten virtuellen Maschine auf einem Host, auf dem ESX/ESXi 4.1 oder früher ausgeführt wird, versuchen, das Festplattenformat in "Thick-Provision Eager-Zeroed" zu ändern, erfolgt keine Konvertierung. Der Storage vMotion-Vorgang wird zwar erfolgreich durchgeführt, aber die Festplatten behalten das ursprüngliche Format bei. Dies ist auf eine Einschränkung von ESX/ESXi 4.1 und früher zurückzuführen. Wenn der gleiche Vorgang auf einer virtuellen Maschine auf einem ESXi 5.0-Host durchgeführt wird, erfolgt die Konvertierung ordnungsgemäß.

    Umgehung:Keine.

VMware HA und Fault Tolerance
  • Bei einem Hostausfall kann vSphere HA eine virtuelle Maschine nicht neu starten, die mit vMotion migriert wurde.
    Während des Migrierens einer virtuellen Maschine von einem Host auf einen anderen fällt der ursprüngliche Host möglicherweise aus, reagiert nicht mehr oder verliert den Zugriff auf den Datenspeicher, der die Konfigurationsdatei der virtuellen Maschine enthält. Wenn solch ein Ausfall auftritt und vMotion danach ebenfalls fehlschlägt, startet vSphere HA möglicherweise die virtuelle Maschine nicht neu und schützt sie möglicherweise nicht mehr.

    Umgehung: Wenn die virtuelle Maschine ausfällt und vSphere HA sie nicht wieder einschaltet, schalten Sie die virtuelle Maschine manuell ein. vSphere HA schützt dann die virtuelle Maschine wieder.

Gastbetriebssystem

  • USB 3.0-Geräte funktionieren möglicherweise nicht in virtuellen Maschinen mit Windows 8 oder Windows Server 2012
    Wenn Sie USB 3.0-Geräte in virtuellen Maschinen mit Windows 8 oder Windows Server 2012 verwenden, während Sie ein Windows- oder Linux-Betriebssystem als Client verwenden, werden möglicherweise Fehlermeldungen ähnlich den folgenden angezeigt:
    Port-Reset fehlgeschlagen
    Die "USB set SEL"-Anforderung ist fehlgeschlagen

    Umgehung: Keine

  • Wenn Sie RHEL 6 neu starten oder per PXE-Startvorgang starten, erscheint ein leerer Bildschirm
    Wenn Sie versuchen, den Red Hat-Bootloader zu verwenden, um RHEL 6 in einer virtuellen EFI-Maschine per PXE-Startvorgang zu starten, wird der Bildschirm leer, nachdem das Betriebssystem ausgewählt wird. Dieses Problem tritt auch dann auf, wenn Sie in einer normalen Installation von RHEL 6 die Direktive splashscreenaus der Datei "grub.conf" entfernen und die virtuelle Maschine neu starten.

    Umgehung: Stellen Sie sicher, dass die Direktive splashscreenvorhanden ist und auf eine Datei verweist, auf die der Bootloader Zugriff hat.

  • Mehrere vNICs werden bei einem Neustart von Mac OS X 10.6.x willkürlich getrennt
    Wenn Sie Mac OS X 10.6 neu starten, wird ein falscher Gastbetriebssystem-Verbindungsstatus für n >=3 e1000 vNICs angezeigt.

    Bei n(e1000)=3 lautet der Gastbetriebssystem-Verbindungsstatus: 2 (verbunden), 1 (getrennt).
    Bei n(e1000)=5 lautet der Gastbetriebssystem-Verbindungsstatus: 3 (verbunden), 2 (getrennt) usw.

    Umgehung: Verwenden Sie das Dienstprogramm "ifconfig", um die Adapter manuell zu aktivieren und zu deaktivieren. Die manuelle Aktivierung und Deaktivierung wird nach dem nächsten Neustartvorgang nicht beibehalten.

Unterstützte Hardware
  • IBM x3550 M2 Force Legacy Video on Boot muss deaktiviert werden
    IBM x3550 M2 hat eine Firmware-Option namens "Force Legacy Video on Boot", die INT10h-Videounterstützung beim Starten von der Unified Extensible Firmware Interface (UEFI) ermöglicht. Diese Option ist nicht kompatibel mit ESXi 5.0 und muss deaktiviert sein.

    Umgehung: Drücken Sie beim Starten von IBM x3550 M2 von UEFI F1, um in das Firmware-Setup zu gelangen, wählen Sie System Settings > Legacy Support > Force Legacy Video on Boot und klicken Sie auf Disable.

Sonstiges
  •  
    • Ungenaue Überwachung der Sensordaten im vCenter Server-Hardwarestatus (KB 2012998).

    • Der Speicherort der Protokolldateien hat sich von /var/login /var/run/loggeändert
      Die ESXi 5.0-Protokolldateien befinden sich im Verzeichnis /var/run/log. Um abwärtskompatibel zu sein, enthält die Protokolldatei Links von dem vorherigen Speicherort, /var/log, auf die neuesten Protokolldateien im aktuellen Speicherort, /var/run/log. Die Protokolldatei enthält keine Links auf rotierte Protokolldateien.

      Umgehung: Keine.

    • Nach der Deinstallation von VMware Tools mithilfe des TAR-Installationsprogramms können Sie auf virtuellen Linux-Maschinen keine OSPs installieren
      Nach der Deinstallation von VMware Tools, die mithilfe des TAR-Installationsprogramms auf einer virtuellen Linux-Maschine installiert wurden, verbleiben Dateien auf dem System. In dieser Situation können Sie keine OSPs installieren.

      Umgehung: Führen Sie den folgenden Befehl aus: rm -rf /usr/lib/vmware-tools /etc/vmware-tools
    • Wenn in den LAN-Einstellungen von Internet Explorer ein Proxy-Server aktiviert ist, kann PowerCLI manchmal kein Online-Depot hinzufügen
      Ein Online-Depot kann in PowerCLI mithilfe des cmdlets Add-ESXSoftwareDepothinzugefügt werden. Unter bestimmten Bedingungen, bei denen der Proxy-Server für die verwendete Maschine aktiviert ist, kann PowerCLI das Online-Depot in der Sitzung nicht hinzufügen.
      Dieser Fehler kann nur dann auftreten, wenn alle folgenden Bedingungen erfüllt sind.
      • Die Site des Kunden benötigt einen HTTP-Proxy-Server für den Zugriff auf das Web.
      • Der Kunde hostet ein Depot im internen Netzwerk.
      • Der Proxy-Server des Kunden kann keine Verbindung zum Depot im internen Netzwerk herstellen.

      Umgehung:
      1. Deaktivieren Sie den Proxy-Server in den LAN-Einstellungen von Internet Explorer.
      2. Fügen Sie das Online-Depot in PowerCLI hinzu.