ESXi 5.0 Update 2 | 20. Dezember 2012 | Build 914586

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

  • Unterstützung für zusätzliche Gastbetriebssysteme. Diese Version bietet Unterstützung für die Gastbetriebssysteme Solaris 11, Solaris 11.1 und Mac OS X Server Lion 10.7.5.
    Eine vollständige Liste der Gastbetriebssysteme, die von dieser Version unterstützt werden, finden Sie im VMware-Kompatibilitätshandbuch.

  • Behobene Probleme. Diese Version enthält einige 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 2 gibt es in den folgenden Sprachen:

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

Erzwingen des Gebietsschemas von vSphere-Client

Bei vSphere 5.0 Update 2 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ätmatrix 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.2 bietet Unterstützung für die Versionen ESXi 5.0 Update 2 und vCenter Server 5.0 Update 2. 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 2 kompatibel sind, lesen Sie die Informationen zu ESXi 5.0 Update 2 im VMware-Kompatibilitätshandbuch.

Upgrades und Installationen für unterstützte CPUs: vSphere 5.0 Update 2 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 2 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 2 im VMware-Kompatibilitätshandbuch, um die Gastbetriebssysteme zu ermitteln, die mit vSphere 5.0 Update 2 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 2 unterstützt. Die Hardwareversion 3 wird nicht mehr unterstützt. Wenn Sie virtuelle Maschinen der Hardwareversion 3 unter ESXi 5.0 Update 2 verwenden möchten, müssen Sie ein Upgrade der virtuellen Hardware durchführen. Weitere Informationen finden Sie in der vSphere-Upgrade-Dokumentation.

Installationshinweise für diese Version

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

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 2 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 2 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 2 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 2-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 2 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. Sie können esxcli nicht verwenden, um ein Upgrade von ESX/ESXi 4.x-Hosts auf ESXi 5.0 Update 2 durchzuführen.
Unterstützte Upgrade-Pfade für das Upgrade auf ESXi 5.0 Update 2:

Upgrade-Lieferumfang

Unterstützte Upgrade-Tools

Unterstützte Upgrade-Pfade auf ESXi 5.0 Update 2

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

ESX4.0 Update 3
ESX 4.0 Update 4

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

ESXi 4.0 Update 3
ESXi 4.0 Update 4

ESX 4.1:
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:
Dazu gehört
ESXi 5.0 Update 1

VMware-VMvisor-Installer-5.0.0.update02-914586.x86_64.iso

 

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

Ja

Ja

Ja

Ja

Ja*

update-from-esxi5.0-5.0_update02.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.update02-914586.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_update02.zipund VMware vCenter Update Manager durchführen.

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 2 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 2 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 2 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 2 enthalten sind, finden Sie unter http://www.vmware.com/download/vsphere/open_source.html auf der Registerkarte Open Source. Sie können auch die Quelldateien für jede GPL-, LGPL- oder vergleichbare Lizenz herunterladen, die 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-Update02 enthält die folgenden einzelnen Bulletins:

ESXi500-201212201-UG: Aktualisiert das ESXi 5.0 esx-base-Vib
ESXi500-201212202-UG: Aktualisiert das ESXi 5.0 net-igb vib
ESXi500-201212203-UG: Aktualisiert das ESXi 5.0 tools-light-Vib
ESXi500-201212204-UG: Aktualisiert das ESXi 5.0 net-ixgbe vib
ESXi500-201212205-UG: Aktualisiert das ESXi 5.0 esx-tboot vib
ESXi500-201212206-UG: Aktualisiert die ESXi 5.0 scsi-lpfc820 vibs
ESXi500-201212207-UG: Aktualisiert das ESXi 5.0 net-bnx2x vib
ESXi500-201212208-UG: Aktualisiert das ESXi 5.0 net-e1000e-Vibs
ESXi500-201212209-UG: Aktualisiert das ESXi 5.0 misc-drivers-Vib
ESXi500-201212210-UG: Aktualisiert das ESXi 5.0 net-tg3 vib
ESXi500-201212211-UG: Aktualisiert das ESXi 5.0 ipmi-ipmi-si-drv vib


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

ESXi500-201212101-SG: Aktualisiert das ESXi 5.0 esx-base-Vib
ESXi500-201212102-SG: Aktualisiert das ESXi 5.0 tools-light vib

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

ESXi-5.0.0-20121202001-standard
ESXi-5.0.0-20121202001-no-tools

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

ESXi-5.0.0-20121201001s-standard
ESXi-5.0.0-20121201001s-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:

Eine Liste der behobenen Probleme, die möglicherweise auftreten können, wenn Sie ein Upgrade von vSphere 5.0 Update 2 auf vSphere 5.1 durchführen, finden Sie unter KB 2007404.

CIM und API

  • Der vSphere-Client erkennt möglicherweise einen nicht vorhandenen Stromversorgungssensor
    Für einige ESXi-Systeme zeigt der vSphere-Client möglicherweise Informationen zu einer nicht vorhandenen Stromversorgungsquelle an.

    Diese Version verbessert die Behandlung der Sensordaten vom IPMI-Sensor-Daten-Repository (SDR), um das Problem zu beheben.
  • Das Systemereignisprotokoll (System Event Log, SEL) für ESXi 5.0.x ist auf bestimmten Servern leer
    Beim Ausführen von ESXi 5.0 auf bestimmten physischen Servern ist das Systemereignisprotokoll (SEL) auf dem vSphere-Client möglicherweise leer.
    Die IPMI-Protokolle des ESX-Hosts ( /var/log/ipmi/0/sel) sind möglicherweise ebenfalls leer.
    Möglicherweise wird eine Fehlermeldung ähnlich der folgenden in /var/log/messagesgeschrieben:

    Dec 810:36:09 esx-200 sfcb-vmware_raw[3965]: IpmiIfcSelReadAll: failed call to IpmiIfcSelReadEntry cc = 0xff


    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die von ESXi 5.0-Hosts gemeldete SMBIOS-UUID unterscheidet sich möglicherweise von der tatsächlichen SMBIOS-UUID
    Wenn die SMBIOS-Version des ESXi 5.0-Systems Version 2.6 oder höher ist, unterscheidet sich die vom ESXi 5.0-Host gemeldete SMBIOS-UUID möglicherweise von der tatsächlichen SMBIOS-UUID. Die Byte-Reihenfolge der ersten drei Felder der UUID ist nicht korrekt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Anzahl an offenen Dateideskriptoren von sfcb-Prozessen kann nicht überprüft werden
    Diese Version fügt Protokolleinträge hinzu, um die maximale Anzahl an offenen Dateideskriptoren von sfcb-Prozessen zu überprüfen.
    Sie können die Grenzwerte für offene Dateideskriptoren in den cim-Protokollen überprüfen, indem Sie die folgenden Schritte ausführen:
    1. Legen Sie die CIM-Protokollierungsebene unter Verwendung des Befehls # esxcfg-advcfg -s 6 /UserVars/CIMLogLevelauf 6 fest.
    2. Starten Sie den sfcbd-Dienst unter Verwendung des Befehls # /etc/init.d/sfcbd-watchdog restartneu.
    3. Stellen Sie sicher, dass es im Ordner /var/log/messagesEinträge ähnlich der folgenden für die maximale Anzahl an offenen Dateideskriptoren gibt:
      sfcb-HTTP-Daemon[30847]: --- Limit of maximum open file descriptors: soft Limit - 512 Hard Limit - 1024

Sonstige Probleme

  • Das Dienstprogramm vm-support kann die Partitionstabellenliste mit VMFS 5-Datenträgern unter Verwendung von fdisk -lu nicht erfassen
    Das Dienstprogramm vm-supportwurde verbessert, um Ausgaben für partedUtil getptblund partedUtil getUsableSectorszu erfassen. Dies hilft beim Abrufen von Partitionsinformationen von VMFS 5-Datenträgen.

  • Das Skript vm-support erfasst keine Informationen über die Raw-Gerätezuordnung von VMDK-Dateien
    Wenn Sie das Dienstprogramm vm-supportverwenden, werden keine Informationen über die Raw-Gerätezuordnung der VMDK-Dateien von virtuellen Maschinen erfasst.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Visuelle Darstellung in Drittanbieteranwendungen ist bei Verwendung des VMware SVGA 3D-Treibers im 3D-Modus beschädigt
    Wenn Sie bei Verwendung des VMware SVGA 3D-Treibers den 3D-Modus aktivieren, werden die Textbezeichnungen in Gruppenfeldern in WPF-Anwendungen durch rechteckige Rahmen überschrieben. Dieses Problem wurde bei Atlas Client beobachtet, der in virtuellen Maschinen auf ESXi-Hosts läuft.

  • Dieses Problem wurde in der vorliegenden Version behoben.

  • Das Bandgerät IBM ULTRIUM-HH5 unterstützt keine SCSI-Befehle mit dem Ordered-Set-Attribut
    Das Bandgerät IBM ULTRIUM-HH5 unterstützt keine SCSI-Befehle mit dem Ordered-Set-Attribut und fällt möglicherweise mit dem SCSI-Gerätestatus Check Condition and sense key 0x05/0x49/0x00 INVALID MESSAGE ERROR
    aus, wenn SCSI-Anforderungen mit dem Ordered-Set-Attribut an das Gerät gesendet werden.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • VDDK API-Aufrufe unter Windows können unter Verwendung von UNC-Pfadnamen nicht auf große virtuelle Festplatten zugreifen
    Wenn Sie versuchen, unter Verwendung von VDDK APIs unter Windows eine virtuelle Festplatte zu lesen, die größer als 2 GB ist, schlagen die API-Aufrufe möglicherweise fehl. Die VDDK-Protokolldateien enthalten möglicherweise Fehlermeldungen ähnlichen den folgenden:
    DISKLIB-LINK: "<UNC-Pfadname>.vmdk": Fehler beim Öffnen (Die Datei ist zu groß).

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Ausführen der Befehle esxcfg-info, esxcfg-resgrp -l oder vm-support führt zu Fehlermeldungen in den Protokolldateien
    Wenn Sie die Befehle esxcfg-info, esxcfg-resgrp -loder vm-supportauf einem ESXi-Host unter Verwendung von ESXi Shell oder SSH ausführen, werden in der Datei syslog.logFehlermeldungen ähnlich der folgenden protokolliert:

    2012-08-01T09:40:12Z esxcfg-info: ResourceGroup: Skipping CPU times for: Vcpu Id 11777 Times due to error. max # of processors: 4 < 11777

    2012-07-03T00:57:28Z esxcfg-resgrp: ResourceGroup: Skipping CPU times for: Vcpu Id 55340 Times due to error. max # of processors: 1 < 55340

    Das Problem hat keine Auswirkungen auf den Betrieb ausgeführter virtueller Maschinen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Zeitüberschreitungsoption funktioniert nicht, wenn Sie die ESXi Shell bzw. die Secure Shell (SSH) reaktivieren
    Wenn Sie für SSH bzw. die ESXi Shell einen Zeitüberschreitungswert festlegen, der nicht null ist, werden SSH bzw. die ESXi Shell deaktiviert, wenn der Zeitüberschreitungswert erreicht wird. Wenn Sie jedoch SSH bzw. die ESXi Shell reaktivieren, ohne die Zeitüberschreitungseinstellung zu ändern, gibt es keine Zeitüberschreitung bei SSH bzw. der ESXi Shell.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESXi-Host schlägt mit einem violetten Diagnosebildschirm fehl, wenn Sie versuchen, über einen USB-Anschluss eine Tastatur oder eine Maus anzuschließen oder abzuziehen
    Wenn Sie versuchen, über einen USB-Anschluss eine Tastatur oder eine Maus anzuschließen oder abzuziehen, schlägt der ESXi-Host mit folgender Fehlermeldung fehl:
    PCPU## locked up. Failed to ack TLB invalidate.

    Weitere Informationen finden Sie unter KB 2000091.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die NTP-Synchronisierung schlägt möglicherweise auf dem Gastbetriebssystem Solaris 10 fehl
    Diese Version bietet Unterstützung für die Gast-Timer-Kalibrierung für Solaris 10-Gastbetriebssysteme. Damit kann das Gastbetriebssystem den TSC innerhalb der Toleranz von NTP ordnungsgemäß messen.

    In dieser Version ist das NTP-Synchronisierungsproblem behoben.
  • Der ESXi 5.0-Host fällt wegen Arbeitsspeicherverlusts bei einem World-Slot aus
    Wenn der ESXi-Host versucht, ein World-Gruppen-Heap zu erstellen, ohne den dem World-Slot zugeordneten Arbeitsspeicher freizugeben, schlägt der Vorgang aufgrund eines Arbeitsspeicherverlusts bei einem World-Slot fehl.

    Dieses Problem wurde behoben, indem der dem World-Slot zugeordnete Arbeitsspeicher freigegeben wird.

  • Der ESXi-Host fällt beim Durchführen einer Stilllegungs-Replizierung aus
    Wenn eine virtuelle Maschine für die Replizierung konfiguriert ist und sich ihr Zustand verändert, geht der HBR-Manager (Hostbasierte Replizierung) davon aus, dass alle VM-Festplatten denselben Stilllegungszustand haben. Wenn die virtuelle Maschine jedoch über mehr als eine Festplatte verfügt und wenn für einige der Festplatten die Replizierung beendet ist und für andere nicht, trifft dies nicht zu. In diesem Fall geht HBR fälschlicherweise von diesem Zustand aus und verursacht einen Ausfall des ESX-Hosts.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Irreführende Fehlermeldungen im hostd-Protokoll, wenn Sie eine VMware vSphere Hypervisor vRAM-Lizenz einem ESXi-Host mit einem pRAM über 32 GB zuweisen
    Wenn Sie versuchen, einen VMware vSphere Hypervisor Edition vRAM-Lizenzschlüssel einem ESXi-Host zuzuweisen, der eine physische RAM-Größe von über 32 GB hat, protokolliert der ESXi-Host möglicherweise falsche Fehlermeldungen ähnlichen den folgenden in /var/log/vmware/hostd:
    2012-08-08T16:39:18.593Z [2AA78B90 error 'Default' opID=HB-host-84@121-9c61c8e-a8] Unable to parse MaxRam value:
    2012-08-08T16:39:18.594Z [2AA78B90 error 'Default' opID=HB-host-84@121-9c61c8e-a8] Unable to parse MaxRamPerCpu value:
    2012-08-08T16:39:18.594Z [2AA78B90 error 'Default' opID=HB-host-84@121-9c61c8e-a8] Unable to parse MinRamPerCpu value:
    2012-08-08T16:39:18.594Z [2AA78B90 error 'Default' opID=HB-host-84@121-9c61c8e-a8] Unable to parse vram value:


    Dieses Problem wurde in der vorliegenden Version behoben.

  • Die Funktion CreateTemporaryFile InGuest() führt möglicherweise zu einer Ausnahme GuestPermissionDeniedFault
    Wenn Sie eine eingeschaltete virtuelle Maschine neu konfigurieren, um einen SCSI-Controller aufzunehmen, und versuchen, eine temporäre Datei auf dem Gastbetriebssystem zu erstellen, schlägt der Vorgang möglicherweise mit einer Ausnahme GuestPermissionDeniedFaultfehl.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Der vSphere-Netzwerk-Core-Dump erfasst keine vollständigen Daten
    Der vSphere-Netzwerk-Core-Dump erfasst keine vollständigen Daten, wenn der Festplatten-Dump aufgrund ungenügender Dump-Steckplatzgröße einige Daten nicht erfassen kann.

    Dieses Problem wurde in der vorliegenden Version behoben. Fehler aufgrund der Steckplatzgröße des Festplatten-Dumps haben keine Auswirkung auf den Netzwerk-Core-Dump mehr.

  • Virtuelle Maschinen mit Windows als Gastbetriebssystem auf einem ESXi-Host mit vShield Endpoint schlagen möglicherweise mit einem blauen Bildschirm fehl
    Ein fehlerhafter API-Aufruf in vShield Endpoint driver vsepflt.sysführt möglicherweise bei virtuellen Maschinen mit Windows als Gastbetriebssystem zu einem blauen Diagnosebildschirm.

    Dieses Problem wurde in der vorliegenden Version behoben.

Netzwerk

  • Der ESXi-Host mit ungefähr 1024 dvPorts reagiert nicht mehr
    Wenn ein ESXi-Host mehr als ungefähr 1024 dvPorts verwendet, reagiert er nicht mehr.
    Die folgenden Warnmeldungen sind in der Protokolldatei vmkwarningzu sehen:
    WARNING: Heap: 2639: Heap dvsLargeHeap (65582032/67108864): Maximum allowed growth (1527808) too small for size (3719168)
    WARNING: Heap: 2900: Heap_Align(dvsLargeHeap, 3715488/3715488 bytes, 8 align) failed. caller: 0x418025d29338


    Dieses Problem wurde in der vorliegenden Version behoben, indem die maximale Standardgröße des dvsLargeHeaperhöht und eine erweiterte Konfigurationsoption (DVSLargeHeapMaxSize) hinzugefügt wurde, damit Administratoren die maximale Größe des dvsLargeHeapweiter erhöhen können.

  • Der ESXi-Host reagiert möglicherweise nicht mehr und zeigt einen violetten Bildschirm an, wenn die MTU mehrmals geändert wird
    Die mehrmalige Änderung der MTU führt möglicherweise zu einer Entleerung von netGPHeap und einem Arbeitsspeicherverlust, wobei der ESXi-Host aufgrund eines Problems mit dem async-Treiber ixgbevon Intel fehlschlägt.

    Die Datei vmkernel.logenthält möglicherweise Meldungen über aufgebrauchten Heap-Speicher ähnlich den folgenden:
    WARNING: Heap: 2525: Heap netGPHeap already at its maximum size. Cannot expand
    WARNING: Heap: 2900: Heap_Align(netGPHeap, 8192/8192 bytes, 64 align) failed. caller: 0x41802c10a03f
    WARNING: NetPort: 1244: failed to enable port 0x2000002: Out of memory
    NetPort: 1426: disabled port 0x2000002
    Uplink: 5240: vmnic2: Failed to enable the uplink port 0x2000002: Out of memory
    <3>ixgbe: vmnic2: ixgbe_alloc_tx_queue: allocated tx queue 1
    <3>ixgbe: vmnic2: ixgbe_alloc_tx_queue: allocated tx queue 2
    <3>ixgbe: vmnic2: ixgbe_alloc_tx_queue: allocated tx queue 3 <6>ixgbe 0000:03:00.0: vmnic2: changing MTU from 9000 to 1500


    Dieses Problem wurde in der vorliegenden Version behoben.
  • Nach dem Neukonfigurieren der DVMirror-Sitzungen funktioniert der Promiscuous-Modus möglicherweise nicht wie erwartet
    Bei Dvportgroup funktioniert ein Promiscuous-Port möglicherweise nicht im Promiscuous-Modus, wenn die DVMirror-Sitzungen neu konfiguriert werden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESXi-Host fällt möglicherweise mit einem violetten Diagnosebildschirm bei Kseg_ReleaseVA() oder Kseg_ReleasePtr() mit einem NULL "va" oder Zeiger aus
    Ein ESXi-Host fällt möglicherweise aufgrund eines nicht ordnungsgemäßen Ausnahmebehandlungscode-Pfads im ESXi-Netzwerk-Stack mit einem violetten Diagnosebildschirm bei Kseg_ReleaseVA() oder Kseg_ReleasePtr() mit einem NULL "va" oder Zeiger aus.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die IP-Virtualisierung für Remotedesktops funktioniert möglicherweise nicht auf einem Windows Server 2008 R2-System, das auf vSphere 4.0 Update 1 ausgeführt wird
    Die IP-Virtualisierung, die es Ihnen ermöglicht, RDP-Sitzungen eindeutige IP-Adressen zuzuteilen, funktioniert möglicherweise nicht auf einem Windows Server 2008 R2 64-Bit-System, das auf vSphere 4.0 Update 1 ausgeführt wird. Die IP-Virtualisierung funktioniert jedoch, wenn Sie Remotedesktopdienste auf einem physischen Windows Server 2008 R2-Computer konfigurieren oder wenn Sie eine virtuelle Windows Server 2008 R2-Maschine auf XenServer 5.5 Update 2 Dell OEM Edition ausführen.
    Dieses Problem tritt möglicherweise auf, wenn Sie VMware Tools nach der Installation der Remotedesktopdienste installieren.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Eine große Anzahl an UDP-Paketen geht verloren, wenn Sie den VMXNET3-Adapter verwenden
    Eine große Anzahl an UDP-Paketen geht verloren, wenn Sie den VMXNET3-Adapter mit einem Linux-Gastbetriebssystem verwenden, das auf einem ESXi 5.0-Host installiert ist.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Bei einer virtuellen RHEL 6-Maschine, die mit RDM-Geräten über den PVSCSI-Adapter konfiguriert ist, treten möglicherweise E/A-Fehler auf
    Bei einer virtuellen RHEL 6-Maschine, die mit RDM-Geräten (Raw Device Mapping) über den PVSCSI-Adapter (Paravirtualized SCSI) konfiguriert ist, treten möglicherweise nach einem Bus-Reset auf einem RDM-Gerät E/A-Fehler auf. Während des Resets gibt der PVSCSI-Adapter DID_RESET zurück, was zur Folge hat, dass der Linux SCSI-Layer den Befehl erneut versucht.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Netzwerkbandbreite wird nicht gleichmäßig unter den virtuellen Maschinen eines Netzwerk-Ressourcenpools verteilt
    Die Netzwerkbandbreite wird aufgrund von Einschränkungen in der derzeitigen Implementation nicht gleichmäßig auf alle virtuellen Maschinen eines Ressourcenpools verteilt.

    Dieses Problem wurde in der vorliegenden Version behoben. Der verbesserte Algorithmus teilt allen virtuellen Maschinen mit demselben Netzwerkressourcenpool optimal Bandbreite zu.
  • Netdump schlägt während einer Core-Dump-Erfassung fehl, nachdem ein violetter Diagnosebildschirm angezeigt wird
    Netdump schlägt während einer Core-Dump-Erfassung fehl, nachdem ein violetter Diagnosebildschirm angezeigt wird, wenn die vSwitch-Sicherheitsoption MAC-Adressenänderungenauf Ablehnen festgelegt ist.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Wenn Sie die Vereinigungsfunktion (Coalescing) auf ESXi deaktivieren, fällt der Host mit einem violetten Bildschirm aus
    Wenn bei ESXi VMXNET3 als vNIC in einigen virtuellen Maschinen verwendet wird und Sie die Paketvereinigung deaktivieren, fällt der ESXi-Host möglicherweise mit einem violetten Bildschirm aus, wenn die virtuelle Maschine gestartet wird.

    Dieses Problem wurde in der vorliegenden Version behoben, indem die Coalescing-Überprüfung und die Assertion-Logik korrigiert wurden.
  • Netzwerkkonnektivität zu einer für IPv6 konfigurierten virtuellen Maschine schlägt möglicherweise nach dem Installieren von VMware Tools fehl
    Die Netzwerkkonnektivität zu bestimmten Gastbetriebssystemen mit den Kernel-Versionen 2.6.34 und höher, die für die Verwendung mit IPv6 konfiguriert sind, funktioniert möglicherweise nicht, nachdem Sie VMware Tools installiert haben.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der vSphere-Client zeigt möglicherweise auf einigen Linux-Gastbetriebssystemen keine IPv6-Adressen an
    Auf Linux-Gastbetriebssystemen, die nicht mit IPv4-Adressen konfiguriert sind, werden möglicherweise die IPv6-Adressen im vSphere-Client oder mit dem Befehl vmware-vim-cmdnicht angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • IBM-Server fällt beim Versuch, Slow-Path-Pakete zu injizieren, mit einem violetten Bildschirm aus
    Wenn die in Zusammenhang mit Slow-Path-Paketen stehenden Metadaten kopiert werden, ohne dass überprüft wurde, ob genügend Daten zugeordnet wurden, werden die Metadaten in einen nicht zugeordneten Bereich verschoben und ein Seitenfehler tritt auf.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der Zeitüberschreitungswert für die iSCSI-Initiator-Anmeldung wird in ESXi 5.0 Update 1 nicht übernommen
    Der festgelegte Zeitüberschreitungswert für die iSCSI-Initiator-Anmeldung muss für die Erkennungsphase übernommen werden. Dies ist in ESXi 5.0 Update 1 nicht der Fall.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Lang laufende vMotion-Vorgänge führen möglicherweise zu einer Unicast-Überflutung
    Wenn bei Verwendung der Multiple-NIC vMotion-Funktion mit vSphere 5 vMotion-Vorgänge über einen langen Zeitraum ausgeführt werden, tritt bei allen Schnittstellen des physischen Switches eine Unicast-Überflutung auf. Wenn die vMotion-Funktion länger benötigt als die Verwendungsdauer der MAC-Adressentabelle, empfängt der Quell- und Zielhost große Mengen an Netzwerkverkehr.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Wenn VMXNET 3 als virtueller Netzwerkadapter verwendet wird, funktioniert die Netzwerkadressübersetzung (NAT, Network Address Translation) auf Windows 2008 R2 möglicherweise nicht
    Wenn Sie versuchen, über den NAT-Server auf einem Windows 2008 R2-Betriebssystem mit zwei virtuellen VMXNET 3-Netzwerkadaptern auf ESXi auf das Internet zuzugreifen, funktioniert der NAT-Server möglicherweise nicht.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Physische Netzwerkkarten, die auf "Automatisch aushandeln" festgelegt sind, können unter Verwendung der Hostprofile nicht auf "Fest" festgelegt werden, wenn dieselben Geschwindigkeits- und Duplex-Einstellungen vorhanden sind
    Es wird eine Hostprofil-Compliance-Prüfung zur Geschwindigkeit und der Duplex-Einstellung einer physischen Netzwerkkarte durchgeführt. Wenn die Geschwindigkeits- und Duplex-Einstellungen einer physischen Netzwerkkarte eines ESXi-Hosts mit den Werten im Hostprofil übereinstimmen, zeigt sie der ESXi-Host selbst dann als übereinstimmend an, wenn die physische Netzwerkkarte auf Automatisch aushandeln und das Hostprofil auf Fest festgelegt ist. Zudem können auf Automatisch aushandeln festgelegte physische Netzwerkkarten unter Verwendung von Hostprofilen nicht auf Fest geändert werden, wenn die Geschwindigkeits- und Duplex-Einstellungen des ESXi-Hosts und des Hostprofils identisch sind.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Update des tg3-Treibers auf Version 3.123b.v50.1
    Der mit ESXi 5.0 Update 2 mitgelieferte tg3-Treiber hat die Version 3.123b.v50.1.

Sicherheit

  • Update der libPNG-Bibliothek
    Die libPNG-Bibliothek wurde auf Version libpng-1.2.49 aktualisiert. Libpng-1.2.49 enthält eine Korrektur für eine Sicherheitslücke. Es ist kein VMware-Produkt von diesem Problem betroffen.
    Im Projekt "Common Vulnerabilities and Exposures" ( cve.mitre.org) wurde diesem Problem die Bezeichnung CVE-2011-3048 zugewiesen.

Serverkonfiguration

  • Die Anwendung des Hostprofils führt möglicherweise zu einer unnötigen Warnmeldung
    Nach der Anwendung eines Hostprofils mit aktivierter ESXi-Firewall und blockierter Fault Tolerance-Regel wird möglicherweise eine unnötige Warnmeldung ähnlich der folgenden angezeigt:
    Regelsatz faultTolerance stimmt nicht mit der Spezifikation überein

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Erstellen des Hostprofils schlägt mit folgendem Fehler fehl: Nicht erkannter Pfad der festen PSP-Konfiguration
    Das Erstellen des Hostprofils schlägt fehl und der ESXi-Host protokolliert Meldungen ähnlich der folgenden in /var/log/vmware/hostd:
    Fehler: 'nmp.nmpProfile.FixedPspPolicy: Unrecognized Fixed PSP configured path iqn.2000-04.com.qlogic:qle4062c.yk10ny9cl5yk.1-00c0dd1c341f,iqn.1992-04.com.emc:cx.ckm00094800328.a2,t,1-naa.6006016090d0260071c460297bc1df11'
    Dieses Problem tritt auf, wenn Sie einen bevorzugten Pfad für iSCSI-LUNs mit einer Richtlinie für einen festen Pfad konfiguriert haben.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESXi 5.0-Host zeigt einen violetten Diagnosebildschirm mit den Fehlern auf einigen HP-Servern mit PCC-Unterstützung an
    Auf einigen HP-Servern kommt es zu einer Situation, bei der die PCC-Kommunikation ("Processor Clocking Control" oder "Collaborative Power Control") zwischen dem VMware ESXi-Kernel (VMkernel) und dem Server-BIOS nicht ordnungsgemäß funktioniert. Als Folge davon verbleiben eine oder mehrere PCPUs für etliche Sekunden im System Management Mode (SMM). Wenn der VMkernel erkennt, dass eine PCPU für einen längeren Zeitraum nicht verfügbar ist, wird ein violetter Diagnosebildschirm mit Fehlermeldungen ähnlich den folgenden angezeigt:

    PCPU 39 locked up. Failed to ack TLB invalidate (total of 1 locked up, PCPU(s): 39).
    0x41228efc7b88:[0x41800646cd62]Panic@vmkernel#nover+0xa9 stack: 0x41228efe5000
    0x41228efc7cb8:[0x4180064989af]TLBDoInvalidate@vmkernel#nover+0x45a stack: 0x41228efc7ce8


    @BlueScreen: PCPU 0: no heartbeat, IPIs received (0/1).
    ...
    0x4122c27c7a68:[0x41800966cd62]Panic@vmkernel#nover+0xa9 stack: 0x4122c27c7a98
    0x4122c27c7ad8:[0x4180098d80ec]Heartbeat_DetectCPULockups@vmkernel#nover+0x2d3 stack: 0x0
    ...
    NMI: 1943: NMI IPI received. Was eip(base):ebp:cs [0x7eb2e(0x418009600000):0x4122c2307688:0x4010](Src 0x1, CPU140)
    Heartbeat: 618: PCPU 140 didn't have a heartbeat for 8 seconds. *may* be locked up


    In dieser Version ist PCC deaktiviert, um dieses Problem zu beheben.
  • Virtuelle SMP-Maschine fällt bei Ausführung von kexec mit "Monitor Panic"-Meldung aus
    Wenn ein Linux-Kernel "abstürzt", dient die kexec-Funktion von Linux dazu, das Starten in einem speziellen kdump-Kernel zu ermöglichen und die Dump-Dateien zu dem Absturz zu sammeln. Während dieses Neustartvorgangs kann ein mit kexec konfiguriertes SMP-Linux-Gastbetriebssystem möglicherweise einen Fehlschlag der virtuellen Maschine mit "Monitor Panic"-Fehler verursachen. Fehlermeldungen ähnlich der folgenden werden möglicherweise protokolliert:
    vcpu-0| CPU reset: soft (mode 2)
    vcpu-0| MONITOR PANIC: vcpu-0:VMM fault 14: src=MONITOR rip=0xfffffffffc28c30d regs=0xfffffffffc008b50


    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESXi-Host protokolliert einen falschen C1E-Zustand
    In vmkernel.logund in der Ausgabe des Befehls dmesgwird möglicherweise eine Meldung ähnlich der folgenden C1E vom BIOS aktiviertangezeigt. Die Meldung wird möglicherweise selbst dann angezeigt, wenn C1E vom BIOS deaktiviert wurde, und wird möglicherweise dann nicht angezeigt, wenn C1E vom BIOS aktiviert wurde.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Hostprofil kann möglicherweise keinen MTU-Wert auf den vSwitches des Zielhosts anwenden
    Wenn Sie ein Hostprofil anwenden, das nur den MTU-Wert für einen Standard-vSwitch ändert, wird die neue MTU-Konfiguration nicht auf den vSwitches des neuen Zielhosts angewendet.

    Dieses Problem wurde in der vorliegenden Version behoben.

Speicher

  • Die ScsiDeviceIO-bezogene Fehlermeldung wird möglicherweise während der Geräteerkennung protokolliert
    Wenn ein optionaler SCSI-Befehl mit einer bestimmten Bedingung fehlschlägt, protokolliert der ESXi 5.0-Host während der Geräteerkennung möglicherweise optionale SCSI-Befehle im vmkernel-Protokoll.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • FCoE-Adapter (Fibre Channel over Ethernet) der VMware-Software funktioniert möglicherweise nicht mehr, wenn ESXi die VLAN-ID 4095 akzeptiert, die von einem FCoE-Switch zurückgegeben wird
    Der FCoE-Switch kann als Antwort auf die erste FIP VLAN-Erkennungsanforderung von einem ESXi-Server die VLAN-ID 4095 zurückgeben. Allerdings ist die VLAN-ID 4095 eine reservierte ID. Wenn ESXi die VLAN-ID 4095 von einem FCoE-Switch akzeptiert, stoppt ESXi die FIP VLAN-Erkennung und verwendet diese VLAN-ID, was dazu führt, dass die FCoE-Erkennung nicht mehr funktioniert.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Ein Speicherfehler führt möglicherweise zu inaktiven Datenspeichern in den LUNs der Speicher-Controller und zu einer virtuellen Maschine im vSphere-Client, auf die kein Zugriff besteht
    Die Datenspeicher in den LUNs der Speicher-Controller sind möglicherweise inaktiv und auf eine virtuelle Maschine besteht im vSphere-Client kein Zugriff, wenn Sie auf einen Speicherfehler stoßen. Die Datenspeicher werden erst wieder aktiv, wenn eine manuelle erneute Prüfung durchgeführt wurde. Dies geschieht, wenn der Management-Agent hostd die Meldung esx.clear.storage.redundancy.restored vobnicht ordnungsgemäß verarbeiten kann.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Wenn der Stilllegungs- Snapshot-Vorgang fehlschlägt, werden die Redo-Protokolle nicht konsolidiert
    Beim Versuch, einen Stilllegungs- Snapshoteiner virtuellen Maschine durchzuführen, wenn der Snapshot-Vorgang zum Ende hin fehlschlägt, werden die Redo-Protokolle, die als Teil des Snapshots erstellt wurden, nicht konsolidiert. Die Redo-Protokolle belegen möglicherweise beträchtlichen Datenspeicher.

    Dieses Problem wurde in der vorliegenden Version behoben. Wenn der Stilllegungs- Snapshot-Vorgang fehlschlägt, werden die Redo-Protokolldateien konsolidiert.

  • Der Befehl esxcfg-scsidev -a zeigt den physischen Verbindungszustand bei Fibre-Channel-over-Ethernet Converged-Network-Adaptern von Emulex an
    Wenn Sie den Befehl esxcfg-scsidev -aausführen, wird der physische Verbindungszustand bei Fibre-Channel-over-Ethernet (FCoE) Converged-Network-Adaptern (CNA) von Emulex angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben. Der Befehl esxcfg-scsidev -azeigt nun den virtuellen Verbindungszustand an.

  • Der ESXi-Host kann Geräte vom DS8300-Speicher-Array nicht entfernen
    Ein ESXi-Host bemerkt nicht zugewiesene LUNs vom DS8300-Speicher-Array nicht, markiert die Pfade nicht als nicht verfügbar und entfernt diese nicht zugewiesenen LUNs nicht. Befehle für nicht zugewiesene LUNs auf DS8300 schlagen mit der Meldung sense key 0x0bfehl, und der ESXi-Host kann keinen PDL-Zustand (Permanent Device Loss, permanenter Geräteverlust) aufzeichnen. PDL wird nun basierend auf ASC-Sense-Daten und nicht auf Basis des Erkennungsschlüssels erkannt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Beim Löschen einer virtuellen Maschine werden nicht verknüpfte virtuelle Festplatten, die Teil eines Snapshots einer virtuellen Maschine sind, entfernt
    Wenn eine virtuelle Maschine mit Snapshots gelöscht wird, werden unabhängige bzw. nicht unabhängige virtuelle Festplatten, die zuvor von der virtuellen Maschine getrennt wurden, aber Teil eines vorhandenen Snapshots sind, möglicherweise ebenfalls gelöscht.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Einige NFS-Datenspeicher werden nach einem Upgrade von ESX 4.x auf ESX 5.x möglicherweise nicht beibehalten
    Wenn der Name des NFS-Datenspeichers Leerzeichen enthält, wird der NFS-Datenspeicher nach einem Upgrade von ESX 4.x auf ESX 5.x möglicherweise nicht beibehalten. Nach einem Upgrade auf ESX 5.x werden alle NFS-Datenspeicher mit Leerzeichen im Namen gelöscht. Andere NFS-Datenspeicher sind nicht betroffen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Während des Taktsignal-Zurückgewinnungsvorgangs werden Warnmeldungen protokolliert
    VMFS veranlasst möglicherweise E/A-Vorgänge auf ein Volume, wenn ein VMFS-Taktsignal-Zurückgewinnungsvorgang ausgeführt oder eine virtuelle Zurücksetzung auf einem zugrunde liegenden Gerät durchgeführt wird. Als Folge davon werden Warnungen und Warnmeldungen ähnlich der folgenden protokolliert:

    ALERT: ScsiDeviceIO: SCSIAsyncDeviceCommand:3082: Failed command 0x2a to quiesced partition naa.xxxxxxxxxxx


    WARNING: ScsiDeviceIO: 2360: Failing WRITE command (requiredDataLen=512 bytes) to write-quiesced partition naa.xxxxxxxxxxx

    Wobei naa.xxxxxxxxxxfür die NaaID des Volumes steht.

    In dieser Version wurden Warnmeldungen entfernt und Warnungen in Protokollmeldungen geändert.
  • Der ESXi-Host reagiert nicht mehr, wenn das VMW_SATP_LSI-Modul über keinen Heap-Arbeitsspeicher mehr verfügt
    Dieses Problem tritt auf Servern auf, die Zugriff auf vom VMW_SATP_LSI-Modul beanspruchte LUNs haben. Ein im VMW_SATP_LSI-Modul auftretender Arbeitsspeicherverlust führt dazu, dass das Modul über keinen Arbeitsspeicher mehr verfügt. Fehlermeldungen ähnlich der folgenden werden in die Datei vmkernel.loggeschrieben:

    Feb 22 14:18:22 [host name] vmkernel: 2:03:59:01.391 cpu5:4192)WARNING: Heap: 2218: Heap VMW_SATP_LSI already at its maximumSize. Cannot expand.
    Feb 22 14:18:22 [host name] vmkernel: 2:03:59:01.391 cpu5:4192)WARNING: Heap: 2481: Heap_Align(VMW_SATP_LSI, 316/316 bytes, 8 align) failed. caller: 0x41800a9e91e5
    Feb 22 14:18:22 [host name] vmkernel: 2:03:59:01.391 cpu5:4192)WARNING: VMW_SATP_LSI: satp_lsi_IsInDualActiveMode: Out of memory.


    Der Arbeitsspeicherverlust im VMW_SATP_LSI-Modul wurde in dieser Version behoben.
  • Das Erstellen einer Diagnosepartition auf einer leeren Festplatte oder einer GPT-partitionierten Festplatte schlägt möglicherweise fehl
    Versuche, eine Diagnosepartition mit dem vSphere-Client zu erstellen, schlagen möglicherweise mit der folgenden Fehlermeldung fehl:
    Das Partitionsformat "Unbekannt" wird nicht unterstützt.
    Dieses Problem tritt auf, wenn Sie versuchen, eine Diagnosepartition auf einer leeren Festplatte (eine Festplatte ohne Partitionstabelle) oder einer GPT-partitionierten Festplatte mit am Ende verfügbarem freiem Speicherplatz zu erstellen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Versuche zum Aktivieren der Flusssteuerung auf dem Intel 82599EB Gigabit Ethernet Controller nicht möglich
    Wenn Sie versuchen, die Flusssteuerung auf dem Intel 82599EB Gigabit Ethernet Controller zu aktivieren, legt der ixgbe-Treiber fälschlicherweise den Flusssteuerungsmodus auf die prioritätsbasierte Flusssteuerung fest, in der die Flusssteuerung immer deaktiviert ist. Als Folge davon wird die Fehlermeldung Pausenparameter des Geräts können nicht festgelegt werden: Ungültiges Argumentangezeigt, wenn Sie versuchen, die Flusssteuerung zu aktivieren.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • ESXi-Hosts schlagen möglicherweise mit einem violetten Diagnosebildschirm im libata-Treiber fehl
  • Eine Wettlaufsituation im libata-Treiber kann zu einem Fehlschlagen der Funktion ata_hsm_movemit einem violetten Diagnosebildschirm führen. Der Stack-Trace ähnelt dem folgenden.
    BUG: failure at vmkdrivers/src_9/drivers/ata/libata-core.c:5833/ata_hsm_move()! (inside vmklinux) Panic_vPanic@vmkernel#nover+0x13 stack: 0x3000000010, 0x412209a87e00 vmk_PanicWithModuleID@vmkernel#nover+0x9d stack: 0x412209a87e20,0x4 ata_hsm_move@com.vmware.libata#9.2.0.0+0xa0 stack: 0x0, 0x410017c03e ata_pio_task@com.vmware.libata#9.2.0.0+0xa5 stack: 0x0, 0x0, 0x53fec vmklnx_workqueue_callout@com.vmware.driverAPI#9.2+0x11a stack: 0x0, helpFunc@vmkernel#nover+0x568 stack: 0x0, 0x0, 0x0, 0x0, 0x0

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Einspielen des VMFS-Journals schlägt möglicherweise für VMFS-3-Volumes auf einem ESXi 5.0-Host fehl
    Das Einspielen des VMFS-Journals schlägt möglicherweise auf einem ESXi 5.0-Host mit folgender Meldung fehl:

    J3: 3167: Failed to replay extended transaction on 4a1aa282-32d04c23-03a2-001517ab207b possibly pending online upgrade
    WARNING: HBX: 4336: Replay of journal on vol 'san1_vmfs3' failed: Bad parameter

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Hinzufügen einer neuen Festplatte zu einer virtuellen Maschine, die sich auf einem Speicher-DRS-fähigen Datenspeicher-Cluster befindet, führt möglicherweise zu dem Fehler, dass nicht ausreichend Festplattenspeicher vorhanden ist
    Wenn Sie eine virtuelle Festplatte zu einer virtuellen Maschine hinzufügen, die sich auf einem Speicher-DRS-fähigen Datenspeicher befindet, und die virtuelle Festplatte größer als der verfügbare freie Speicherplatz im Datenspeicher ist, migriert SDRS möglicherweise eine andere virtuelle Maschine aus dem Datenspeicher, damit genügend freier Speicherplatz zum Hinzufügen der virtuellen Festplatte zur Verfügung steht. Der Storage vMotion-Vorgang wird abgeschlossen, aber das nachfolgende Hinzufügen der virtuellen Festplatte zur virtuellen Maschine schlägt möglicherweise fehl, und eine Fehlermeldung ähnlich der folgenden wird angezeigt:
    Unzureichender Festplattenspeicher

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Wenn Sie versuchen, das Modul "Content-Based Read Cache" (CBRC) in ESX mit begrenztem Hauptspeicher zu laden, fällt der Host mit einem violetten Diagnosebildschirm aus
    Wenn Sie versuchen, das CBRC-Modul auf einem ESXi-Host mit begrenztem Hauptspeicher zu laden, fällt der ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm aus. Dieses Problem tritt auf, wenn zwei Arbeitsspeicherfunktionen versuchen, den Wert eines Arbeitsspeicherzählers zur gleichen Zeit zu ändern.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Zugriff auf beschädigte Metadaten auf dem VMFS-3-Volume führt möglicherweise zu einem Ausfall des ESXi-Hosts
    Wenn die Metadaten einer Datei auf einem VMFS-3-Volume beschädigt sind, fällt der ESXi-Host möglicherweise bei dem Versuch, auf eine solche Datei zuzugreifen, mit einem violetten Diagnosebildschirm aus. Eine Beschädigung der VMFS-Dateien ist äußerst selten, kann aber durch externe Speicherprobleme verursacht werden.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • Löschen von Dateien aus dem VMFS-Verzeichnis nicht möglich, nachdem eine oder mehrere Dateien in dieses verschoben wurden
    Nachdem (unter Verwendung des Befehls mvoder durch Kopieren und Einfügen mit dem vSphere-Client-Browser) eine oder mehrere Dateien in ein Verzeichnis verschoben wurden, schlägt ein Versuch, das Verzeichnis oder Dateien des Verzeichnisses zu löschen, möglicherweise fehl. In solch einem Fall enthält die Datei vmkernel.logEinträge ähnlich dem folgenden:
    2012-06-25T21:03:29.940Z cpu4:373534)WARNING: Fil3: 13291: newLength 85120 but zla 2
    2012-06-25T21:03:29.940Z cpu4:373534)Fil3: 7752: Corrupt file length 85120, on FD <281, 106>, not truncating


    Dieses Problem wurde in der vorliegenden Version behoben.

  • Der ESXi hostd-Agent verbraucht möglicherweise sehr viel CPU-Ressourcen, was zu einer Abnahme der Leistung führt
    Wenn vCloud Director den Screenshot des Desktops einer virtuellen Maschine vom ESXi-Host abruft, gerät der hostd-Agent möglicherweise in eine Endlosschleife, die zu einer 100 %-igen Auslastung der CPU führt; diese CPU-Auslastung wird erst wieder verringert, wenn hostd neu gestartet wird.

    Dieses Problem wurde in der vorliegenden Version behoben.

Upgrade und Installation

  • Der Cisco UCS-Blade (der über FCoE/iSCSI/FC SAN startet) verliert möglicherweise die Konfiguration nach einer Neuinstallation oder einem Upgrade auf ESXi 5.0 Update 1
    Dieses Problem tritt möglicherweise nach einem Upgrade auf ESXi 5.0 Update 1 auf, bei dem der erste Neustart erfolgreich verläuft; bei späteren Neustarts verliert der USC-Blade jedoch die Konfiguration und kehrt zu seinem vorherigen Zustand zurück.
    Nach einer Neuinstallation von ESXi 5.0 Update 1 gehen die Konfigurationsänderungen möglicherweise beim Neustart verloren.
    Ein ähnliches Problem tritt möglicherweise beim Durchführen einer der folgenden Aktionen auf:
    • Installieren von Drittanbietertreibern
    • Installieren von Sicherheits-Patches
    • Herunterfahren von ESXi 5.0 Update 1 zu Wartungszwecken
    • Neustart von ESXi 5.0 Update 1 zu Wartungszwecken
    • Herunterfahren von ESXi 5.0 Update 1 bei Problemen mit nicht geplanten Stromausfällen
  • Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Akzeptanzebene eines statusfreien ESXi-Hosts unterscheidet sich möglicherweise von der Akzeptanzebene des Image-Profils, von dem es startet
    Ein statusfreier ESXi-Host hat möglicherweise die PartnerSupported-Akzeptanzebene unabhängig von der Akzeptanzebene des Image-Profils, von dem es startet.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Der DNS wird möglicherweise nicht auf Hosts konfiguriert, die über Skripte installiert wurden, die die Verwendung von DHCP angegeben haben
    Wenn Sie ESXi auf einem Host mit einem Skript installieren, das denselben veranlasst, die Netzwerkeinstellungen über DHCP zu beziehen, ist der Host nach dem Starten nicht mit einem DNS konfiguriert. Die DNS-Einstellung steht auf manuell, und es ist keine Adresse angegeben.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Beim ersten Start eines ESXi-Hosts werden lokale, mit dem Host verbundene Festplatten möglicherweise als VMFS neu formatiert
    Wenn ein ESXi-Host zum ersten Mal startet, löscht die automatische Partitionierung alle lokalen Festplatten, die an den Host angeschlossen sind, und formatiert sie mit VMFS neu.

    Diese Version behebt dieses Problem, indem die automatische Partitionierung durch Festlegen der Standardoption auf False deaktiviert wird. Es wurde eine neue Startoption AutoPartition eingeführt, die die automatische Partitionierung aktiviert, wenn sie auf True gesetzt wurde.

  • Eine Neuinstallation von ESXi 5.0 entfernt nicht die Datenspeicherbezeichnung des lokalen VMFS einer früheren Installation
    Eine Neuinstallation von ESXi 5.0 auf einem bestehenden lokalen VMFS-Datenträger behält die Datenspeicherbezeichnung bei, selbst wenn der Benutzer die Option zum Überschreiben des Datenspeichers wählt, um den VMFS-Datenträger zu überschreiben.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • An virtuelle Solaris-Maschinen angehängte RDMs werden möglicherweise überschrieben, wenn ESXi-Hosts mit Update Manager aktualisiert werden
    Beim Upgrade auf ESXi 5.0.x mit Update Manager führt ein Fehler beim Ermitteln des Typs der Festplattenpartition dazu, dass die RDMs, die an virtuelle Solaris-Maschinen angehängt sind, überschrieben werden. Dies kann möglicherweise zu einem Datenverlust bei den RDMs führen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Ein Upgrade des ESX-Hosts ändert die Firewallregeln von "Deaktiviert" in "Aktiviert"
    Wenn Sie ein Upgrade des ESX-Hosts von Version 4.1 auf 5.0 Update 1 durchführen, werden die Firewallregeln von "Deaktiviert" in "Aktiviert" geändert. Dies tritt auf, nachdem Sie ein Hostprofil erstellt, es geändert und dann dasselbe Profil auf den Host angewendet haben.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • Nach einem Upgrade von ESXi 4.x auf ESXi 5.0.x können die aktualisierten Hosts möglicherweise keine erneute Verbindung zu vCenter Server herstellen
    Wenn Sie die Datei /etc/rc.localauf ESXi 4.1.x-Hosts ändern und ein Upgrade dieser ESXi 4.x-Hosts auf ESXi 5.0.x-Host durchführen, sind die aktualisierten Hosts möglicherweise aufgrund von Lizenzierungsproblemen nicht in der Lage, eine erneute Verbindung zu vCenter Server herzustellen. Es werden Fehlermeldungen angezeigt, die den folgenden Meldungen ähneln:
    Die nicht lizenzierte Lizenz für Host xxx enthält nicht VMware DRS. Aktualisieren Sie die Lizenz


    Die vpxd-Protokolldateien enthalten möglicherweise Einträge ähnlich der folgenden:

    012-04-26T11:58:37.069-04:00 [05420 warning 'Default' opID=C8581389-00000EF2] [LicMgr] Trying to remove licenses. Host was never registered with the license manager.
    012-04-26T11:58:37.069-04:00 [05420 trivia 'QueryServiceProvider' opID=C8581389-00000EF2] Clearing uncommitted generations on this thread for LicenseManager
    012-04-26T11:58:37.069-04:00 [05420 trivia 'VpxProfiler' opID=C8581389-00000EF2] Ctr: CheckVCLicense/TotalTime = 0 ms
    012-04-26T11:58:37.069-04:00 [05420 error 'Default' opID=C8581389-00000EF2] [LicMgr] feature drs not included in license assigned to host-129707.
    012-04-26T11:58:37.069-04:00 [05420 trivia 'VpxProfiler' opID=C8581389-00000EF2] Ctr: CheckingHostFeatures/TotalTime = 0 ms


    Dieses Problem wurde in der vorliegenden Version behoben.
  • Upgrades von ESX 4.1 mit Erweiterungen zum lokalen Dateispeicher auf ESXi 5.0 nicht zulassen
    Das Upgrade von ESX 4.1 mit Erweiterungen zum lokalen Datenspeicher auf ESXi 5.x ist kein unterstützter Nutzungsfall. Jedoch ermöglicht der aktuelle Upgrade-Vorgang dieses Upgrade-Verhalten und überträgt die Erweiterungen auf den lokalen Datenspeicher, ohne eine Fehler- oder Warnmeldung auszugeben.

    Dieses Problem wurde in dieser Version behoben, indem eine Prüfung zum Vorprüfungs-Skript hinzugefügt wurde, um eine solche Situation zu erkennen. Wird diese Situation erkannt, wird dem Benutzer eine Meldung angezeigt, um das Upgrade oder die Migration zu beenden.
  • Bei Verwendung von AutoDeploy tritt beim gPXE-Vorgang möglicherweise eine Zeitüberschreitung ein
    Wenn Sie AutoDeploy zum Starten von ESXi 5.0-Hosts verwenden, tritt beim gPXE-Vorgang möglicherweise eine Zeitüberschreitung ein, während versucht wird, eine IP-Adresse von DHCP-Servern abzurufen, und der AutoDeploy-Startvorgang wird abrupt beendet.

    Dieses Problem wurde in der vorliegenden Version behoben. Der Gesamtzeitraum zur Zeitüberschreitung wird von etwa 30 Sekunden auf 60 Sekunden erhöht.
  • Beim Installieren von Solaris 11 GA auf einem ESX-Host werden Warnmeldungen angezeigt
    Wenn Sie Solaris 11 GA von der Konsole der virtuellen Maschine aus auf einem ESX-Host installieren und es mit einem LSI Logic Parallel-Controller konfigurieren, zeigt der ESX-Host immer die folgenden Warnmeldungen an:
    unknown ioc_status = 4 and
    incomplete write – giving up


    Die Warnmeldungen beeinflussen oder blockieren nicht die Installation des Gastbetriebssystems. Sie können Solaris 11 GA nach wie vor verwenden. Dieses Problem wird jedoch auch beim Kopieren von Dateien en gros beobachtet.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die ESXi 5.x-Skriptinstallation warnt fälschlicherweise davor, dass USB- oder SD-Medien VMFS nicht unterstützen, obwohl der Parameter "--novmfsondisk" in der Kickstart-Datei verwendet wird
    Wenn Sie die Skriptinstallation zum Installieren von ESXi 5.0 auf einer Festplatte verwenden, die als USB- oder SD-Medium erkannt wird, zeigt das Installationsprogramm möglicherweise diese Warnmeldung an:
    Die im Installationsprogramm angegebene Festplatte (<Festplatten-ID>) unterstützt VMFS nicht.
    Diese Meldung wird selbst dann angezeigt, wenn Sie den Parameter --novmfsondiskfür den Befehl installin der Kickstart-Datei angegeben haben.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Probleme bei Nutzung der Microsoft Windows Deployment Services (WDS) für den PXE-Startvorgang virtueller Maschinen, die den VMXNet3-Netzwerkadapter verwenden
    Versuche, für virtuelle Maschinen, die den VMXNet3-Netzwerkadapter verwenden, unter Nutzung der Microsoft Windows Deployment Services (WDS) den PXE-Startvorgang durchzuführen, schlagen möglicherweise mit Fehlermeldungen ähnlich den folgenden fehl:

    Windows konnte nicht gestartet werden. Dies kann auf eine kürzlich durchgeführte Hardware- oder Softwareänderung zurückzuführen sein. So beheben Sie das Problem:
    1. Legen Sie die Windows-CD/DVD ein, und starten Sie den Computer neu.
    2. Wählen Sie die Spracheinstellungen aus, und klicken Sie dann auf "Weiter".
    3. Klicken Sie auf "Computer reparieren".
    Wenn Sie den Datenträger nicht besitzen, wenden Sie sich an den Systemadministrator oder den Computerhersteller.

    Status: 0xc0000001

    Info: Fehler bei Startauswahl. Zugriff auf ein erforderliches Gerät nicht möglich
    .

    Dieses Problem wurde in der vorliegenden Version behoben.

Verwaltung von virtuellen Maschinen

  • Virtuelle Maschinen starten möglicherweise nicht, wenn der BIOS-Dateiname des virtuellen Geräts eine leere Zeichenfolge ist
    Wenn Sie die Konfigurationsoptionen der virtuellen Maschine bearbeiten und den BIOS-Dateinamen des virtuellen Geräts über die API auf eine leere Zeichenfolge setzen, startet die virtuelle Maschine nicht. Beispiel: lsibios.filename="".

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Die virtuelle Maschine fällt mit "Monitor Panic" aus, wenn das Paging deaktiviert wird
    Fehlermeldungen ähnlich den folgenden werden in vmware.loggeschrieben:

    vcpu-0| MONITOR PANIC: vcpu-1:VMM64 fault 14: src=MONITOR
    vcpu-0| rip=0xfffffffffc262277 regs=0xfffffffffc008c50


    Dieses Problem wurde in der vorliegenden Version behoben.
  • Stilllegungs-Snapshot kann nicht erstellt werden, nachdem eine unabhängige Festplatte aus einer virtuellen Maschine gelöscht wurde
    Wenn eine unabhängige Festplatte aus einer virtuellen Maschine gelöscht wurde, schlagen Versuche, einen Stilllegungs-Snapshot einer virtuellen Maschine zu erstellen, fehl, da die Daten des Festplattenmodus für einen bestimmten SCSI-Knoten möglicherweise veraltet sind. Möglicherweise wird folgende Fehlermeldung angezeigt:
    Status: Beim Stilllegen der virtuellen Maschine ist ein Fehler aufgetreten. Weitere Informationen finden Sie im Ereignisprotokoll der virtuellen Maschine.

    Die Protokolldateien enthalten möglicherweise Einträge ähnlich den folgenden:
    HotAdd: Adding scsi-hardDisk with mode 'independent-persistent' to scsi0:1

    ToolsBackup: changing quiesce state: STARTED -> DONE
    SnapshotVMXTakeSnapshotComplete done with snapshot 'back': 0
    SnapshotVMXTakeSnapshotComplete: Snapshot 0 failed: Das Stilllegen der virtuellen Maschine ist fehlgeschlagen. (40).


    Dieses Problem wurde in der vorliegenden Version behoben.

vMotion und Storage vMotion

  • Das Erstellen eines Stilllegungs-Snapshots von Microsoft Windows Server 2008 R2 schlägt möglicherweise auf einem ESXi 5.0-Host fehl
    Wenn Sie einen Stilllegungs-Snapshot einer virtuellen Microsoft Windows Server 2008 R2-Maschine erstellen und das Arbeitsverzeichnis angeben, schlägt der Snapshot-Vorgang möglicherweise mit der folgenden Fehlermeldung fehl:
    Snapshot des Gasts fehlgeschlagen: Das Stilllegen der virtuellen Maschine ist fehlgeschlagen.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Wenn Sie eine Live-Migration von virtuellen Windows 2008-Maschinen von ESX 4.0 auf ESXi 5.0 vornehmen und anschließend Storage vMotion durchführen, schlagen Stilllegungs-Snapshots fehl
    Ein Storage vMotion-Vorgang auf ESXi 5.0 legt für eine virtuelle Windows 2008-Maschine standardmäßig disk.enableUUIDauf "true" fest und aktiviert so die Anwendungsstilllegung. Der nachfolgende Stilllegungs-Snapshot-Vorgang schlägt so lange fehl, bis die virtuelle Maschine aus- und wieder eingeschaltet wird.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESXi-Host fällt während eines Storage vMotion-Vorgangs mit einem violetten Bildschirm aus
    Nach Abschluss eines Storage vMotion-Vorgangs trennt ESXi das Spiegelgerät, das es für den Vorgang erstellt hat. Allerdings wird unter bestimmten Bedingungen ein nicht initialisierter Zeiger referenziert, was dazu führen kann, dass der ESXi-Host mit einem violetten Bildschirm ausfällt.

    Dieses Problem wurde in der vorliegenden Version behoben.

VMware HA und Fault Tolerance

  • Eine sekundäre virtuelle FT-Maschine, die auf einem ESXi-Host ausgeführt wird, schlägt möglicherweise fehl
    Auf einem ESXi-Host schlägt eine mit einem VMXNET 3-Adapter installierte sekundäre virtuelle Fault Tolerance-Maschine möglicherweise fehl. Fehlermeldungen ähnlich den folgenden werden in die Protokolldatei vmware.loggeschrieben:

    Dec 15 16:11:25.691: vmx| GuestRpcSendTimedOut: message to toolbox timed out.
    Dec 15 16:11:25.691: vmx| Vix: [115530 guestCommands.c:2468]: Error VIX_E_TOOLS_NOT_RUNNING in VMAutomationTranslateGuestRpcError(): VMware Tools are not running in the guest
    Dec 15 16:11:30.287: vcpu-0| StateLogger::Commiting suicide: Statelogger divergence
    Dec 15 16:11:31.295: vmx| VTHREAD watched thread 4 "vcpu-0" died


    Dieses Problem tritt nicht auf einer virtuellen Maschine auf, die mit dem E1000-Adapter installiert wurde.

    Dieses Problem wurde in der vorliegenden Version behoben.

VMware Tools

  • Die Treiberüberprüfung bei virtuellen Windows 2008-Maschinen antwortet möglicherweise nicht
    Wenn die Option Treiberüberprüfung auf einer virtuellen Windows 2008-Maschine aktiviert ist, funktioniert die VMCI-Socket-Sperre nicht ordnungsgemäß.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Das Konfigurationsdienstprogramm VMware Tools führt Skripte in virtuellen Maschinen mit Windows 8 oder Windows Server 2012 möglicherweise nicht erfolgreich aus
    Das Konfigurationsdienstprogramm VMware Tools (VMwareToolboxCmd.exe) führt in virtuellen Maschinen mit Windows 8 oder Windows Server 2012 Skripte möglicherweise nicht aus und zeigt eine Fehlermeldung ähnlich der folgenden an:
    VMwareToolboxCmd.exe: Zum Ausführen von Skriptvorgängen sind Administratorberechtigungen erforderlich. Verwenden Sie eine Administrator-Eingabeaufforderung, um diese Aufgaben fertig zu stellen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Virtuelle Maschinen, die VESA-Treiber auf dem Windows 2008 R2-Betriebssystem verwenden, haben Leistungseinbußen zu verzeichnen
    VMware Tools installiert möglicherweise keinen Grafiktreiber auf dem Windows 2008 R2-Betriebssystem. Als Folge verwendet die virtuelle Maschine den Standard-VESA-Treiber. Dies führt zu Leistungseinbußen bei einigen Hardwaregeräten des Gastbetriebssystems.

    Dieses Problem wurde in der vorliegenden Version behoben. VMware Tools installiert standardmäßig den WDDM-Treiber, um die Leistung zu verbessern.
  • Wenn VMware Tools vom Paketmanager installiert wird, ändert es die Systemdatei-Zugriffsberechtigungen auf fehlerhafte Weise
    Wenn Sie VMware Tools unter Verwendung des Redhat Package Manager auf dem Centos 6-Betriebssystem installieren, werden die Systemdatei-Zugriffsberechtigungen auf fehlerhafte Weise geändert.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • VMware Tools auf einer virtuellen Linux-Maschine schlägt möglicherweise intermittierend fehl
    VMware Tools enthält eine gemeinsam genutzte Bibliotheksdatei mit dem Namen libdnet. Wenn eine andere Software, z. B. Dell OpenManage, installiert ist, gibt es eine gemeinsam genutzte Bibliothek auf dem Dateisystem mit demselben Namen. Wenn VMware Tools geladen wird, lädt es die Bibliothek libdnet.so.1der Dell OpenManage-Software anstatt libdnet.sovon VMware Tools. Die Informationen zum Gastbetriebssystem werden möglicherweise nicht auf der Registerkarte Übersicht des vSphere-Clients angezeigt und die Informationen zur Netzwerkkarte werden möglicherweise ebenfalls nicht angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • VMware Tools-Dienst schlägt möglicherweise mit einem nicht behebbaren VMware Tools-Fehler fehl
    Der VMware Tools-Dienst (vmtoolsd.exe) schlägt möglicherweise mit einem nicht behebbaren VMware Tools-Fehler-Stack aufgrund eines Null-Zeigersfehl.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Upgrade der VMware Tools ersetzt den VMCI-Treiber nicht, der für die IP-Virtualisierung des Remotedesktops erforderlich ist
    Wenn Sie ein Upgrade der VMware Tools durchführen, schlägt die IP-Virtualisierung fehl. Dies geschieht, weil der ESXi-Host nicht prüft, ob die neue Version des VMCI-Treibers vorhanden ist, und die vsock-DLL-Dateien nicht installieren kann.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • VMware Tools schlägt möglicherweise fehl, wenn mehr als 16 VLAN-Schnittstellen erstellt werden
    Wenn auf ESXi 5.0-Hosts mehr als 16 VLAN-Schnittstellen für eine virtuelle Maschine erstellt werden, reagiert VMware Tools möglicherweise nicht mehr.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Installation der VMware Tools auf einer virtuellen Solaris-Maschine ändert möglicherweise die MTU-Größe automatisch auf 9000
    Wenn Sie eine Installation oder ein Upgrade der mit ESXi 5.0 und ESXi 5.0 Update 1 verfügbaren VMware Tools auf virtuellen Solaris-Maschinen durchführen, wird die MTU-Größe möglicherweise automatisch auf 9000 geändert. Selbst wenn die MTU-Größe dann geändert wird, wird sie wieder auf 9000 gesetzt, wenn Sie das Gastbetriebssystem neu starten.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Installation oder Upgrade der VMware Tools auf Windows-Gastbetriebssystemen wird mit einer Fehlermeldung abgeschlossen
    Nachdem Sie die Installation oder das Upgrade der VMware Tools auf einer virtuellen Windows-Gastmaschine abgeschlossen haben, wird möglicherweise eine Fehlermeldung ähnlich der folgenden angezeigt:
    Im Laufwerk ist kein Datenträger eingelegt
    oder
    Kein Datenträger: Ausnahme beim Verarbeiten der Meldung c0000013

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die virtuelle Maschine schlägt möglicherweise bei einer Sicherung mit Stilllegungs-Snapshot fehl
    Die virtuelle Maschine schlägt bei einer Sicherung mit einem Stilllegungs-Snapshot fehl. Dies geschieht, weil der synchrone Kopiervorgang der Manifestdatei aufgrund einer Inkonsistenz im Callback-Vorgang fehlschlägt. Dadurch gerät das System in einen ungültigen Zustand.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Verwenden der Option zum Verhindern des Neustarts beim Installieren der VMware Tools hindert die virtuellen Maschinen nicht daran, auf Windows XP- und Windows 2003-Gästen neu zu starten
    Die Befehle setup.exe /S /v"/qn REBOOT=R"bzw. setup.exe /S /v"/qn REBOOTPROMPT=S"unterdrücken den Neustart virtueller Maschinen nach der Installation der VMware Tools. Bei der Installation der VMware Tools aus ESXi 5.0-Hosts wird die Visual C++ Runtime selbst dann installiert, wenn sie bereits installiert ist. Dies führt zu einer Reparatur der Visual C++ Runtime und macht einen Neustart der virtuellen Maschine erforderlich, auch wenn der Befehl zum Unterdrücken des Neustarts verwendet wird. Dies gilt speziell für Windows XP und Windows 2003 und vorherige Versionen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Nach der Installation der VMware Tools ändern sich möglicherweise die Dateizugriffsberechtigungen für "/etc/fstab"
    Wenn VMware Tools auf einer virtuellen Maschine, z. B. SUSE Linux Enterprise Server 11 SP1, installiert wird, ändert sich das Dateiberechtigungsattribut für /etc/fstabvon 644 auf 600.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Netzwerkschnittstellenkarte E1000 verliert nach einem Upgrade der VMware Tools ihre Einstellungen für die statische IP-Adresse
    Wenn der Benutzer auf einem Windows 2003-Betriebssystem ein Upgrade der VMware Tools versucht, gehen der Netzwerkschnittstellenkarte E1000 die Einstellungen für die statische IP-Adresse verloren und der Gastnetzwerkadapter wird auf DHCP gesetzt. Dies geschieht, nachdem Sie VMware Tools über Software deinstallieren.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Installation von OSPs für VMware Tools unter SUSE Linux Enterprise Server 11 SP 3 und SUSE Linux Enterprise Server 11 SP 4 schlägt fehl
    Der Versuch, OSPs für das VMware Tools-Paket unter SUSE Linux Enterprise Server 11 SP 3 und SUSE Linux Enterprise Server 11 SP 4 zu installieren, schlägt fehl, und die folgende Fehlermeldung wird angezeigt:
    FEHLER: Auflösung der Abhängigkeit fehlgeschlagen:
    Nicht aufgelöste Abhängigkeiten:
    Es gibt keine installierbaren Anbieter von vmware-tools-esx
    Dieser Auflösungsversuch wird als ungültig gekennzeichnet.

    Die Installation schlägt aufgrund einer nicht aufgelösten Abhängigkeit in vmware-tools-esx meta-packagefehl, was dazu führt, dass das Paket die Binärdatei vmmouse_drv.sosucht und nicht findet.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Ein Windows-Gastbetriebssystem, das auf einem ESXi 5.0-Host mit vShield Endpoint und VMware Tools ausgeführt wird, zeigt möglicherweise Zugriffsverletzungsfehler an
    In einer Umgebung mit einer mit VMware Tools gebundelten vShield Endpoint-Komponente zeigt ein Windows-Gastbetriebssystem auf einem ESXi 5.0-Host möglicherweise Zugriffsverletzungsfehler während des Zugriffs auf Netzwerkdateien. Eine Fehlermeldung ähnlich der folgenden wird möglicherweise angezeigt, wenn Sie versuchen, eine Netzwerkdatei zu öffnen:
    Fehler beim Öffnen des Dokuments. Diese Datei ist bereits geöffnet oder wird von einer anderen Anwendung verwendet.

    Dieses Problem wurde in der vorliegenden Version behoben.
     

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. Diese Liste der Probleme gilt nur für diese Version von 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.

Liste bekannter Probleme

Lesen Sie durch alle bekannten Probleme, um die Probleme zu finden, die Sie zutreffen. Behobene Probleme, die früher nicht dokumentiert wurden, werden mit einem Sternchen (*) markiert. Die Probleme gliedern sich wie folgt:

Installation
  • Nach der Installation von ESXi 5.0 Update 2 wird eine überflüssige netzwerkbezogene Warnmeldung angezeigt
    Nach der Installation von ESXi 5.0 Update 2 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.

  • Der vSphere-Client kann nicht in einem Ordner installiert werden, dessen Name Sonderzeichen enthält
    Wenn Sie den vSphere-Client in einem Ordner oder Verzeichnis installieren, dessen Name ein Semikolon (;), eine linke eckige Klammer ([), eine rechte eckige Klammer (]), ein Gleichheitszeichen (=), ein Pluszeichen (+), ein Komma (,) oder ein Rautezeichen (#) enthält, erscheint die folgende Fehlermeldung:

    Der Installationspfad enthält ein ';'-Zeichen. Wählen Sie ein Installationsverzeichnis ohne dieses Zeichen aus.

    Auch wenn der Ordnername kein Semikolon (;) enthält, können Sie den vSphere-Client im angegebenen Ordner nicht installieren. Wenn Sie außerdem den vSphere-Client in einem benutzerdefinierten Ordner installieren, dessen Name ein Rautezeichen enthält ( #), kann der Client keine Verbindung zu vCenter Server herstellen.

    Umgehung: Installieren Sie den vSphere-Client nicht in einem benutzerdefinierten Ordner, dessen Name ein Semikolon (;), eine linke eckige Klammer ([), eine rechte eckige Klammer (]), ein Gleichheitszeichen (=), ein Pluszeichen (+), ein Komma (,) oder ein Rautezeichen (#) enthält .

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

  • Lizenzierung
    • Die automatische Zuweisung eines vSphere-Lizenzschlüssels zu bestimmten ESX/ESXi-Hosts in einem Host-Container schlägt möglicherweise fehl und die Hosts bleiben im Testmodus
      vCenter Server 5.0 unterstützt die automatische Zuweisung von Lizenzschlüsseln zu ESX/ESXi-Hosts. Sie können einem Host-Container in vCenter Server, wie z. B. einem Datencenter oder einem Cluster, einen Lizenzschlüssel zuordnen. vCenter Server weist dann allen nicht lizenzierten Hosts, die Sie diesem Host-Container hinzuzufügen, den Lizenzschlüssel zu. Sie können einem Host-Container nur einen Lizenzschlüssel zuordnen. Wenn die Lizenz, die Sie einem Host-Container zuordnen, eine andere Version als die Hosts aufweist, die Sie diesem Host-Container hinzufügen, wird den Hosts die Lizenz nicht zugewiesen. Wenn Sie beispielsweise einem Cluster eine vSphere 5.x-Lizenz zuordnen und dem Cluster ESX/ESXi 4.x-Hosts hinzufügen, wird den ESX/ESXi 4.x-Hosts die Lizenz nicht zugewiesen, sodass sie im Testmodus verbleiben.

      Umgehung:Stellen Sie sicher, dass alle dem Host-Container hinzuzufügenden Hosts die gleiche Version wie die Lizenz aufweisen, die Sie demselben Container zuordnen. Wenn ein Host aus demselben Container eine Lizenz einer anderen Version benötigt, ordnen Sie dem Host die Lizenz direkt zu. Sie ordnen beispielsweise einem Cluster eine vSphere 5.x-Lizenz zu. Sie fügen dem Cluster ESXi 5.x-Hosts hinzu, denen die vSphere 5.x -Lizenz zugewiesen wird. Sie fügen demselben Cluster ESX/ESXi 4.x-Hosts hinzu und ordnen den Hosts eine vSphere 4.x-Lizenz zu. Sie verbinden die ESX/ESXi 4.x-Hosts zu vCenter Server neu und ihnen wird die vSphere 4.x-Lizenz zugewiesen.

    Sicherheit
    • Die Sitzungen der Datenspeicher-Weboberfläche werden nicht sofort beendet, wenn Sie das Browserfenster schließen
      Wenn Sie einen Webbrowser nach dem Zugriff auf die Datenspeicher-Weboberfläche schließen, wird die Sitzung auf der Serverseite nicht sofort beendet. VMware möchte Jason Jones von Inner Security für die Meldung dieses Problems danken.

      Umgehung:Bevor Sie das Browserfenster schließen, müssen Sie auf der Datenspeicher-Weboberfläche auf Abmelden klicken, um die Sitzung zu beenden.

    Netzwerk

    • Emulex be2net Netzwerkadapter mit Geräte-ID 0710 kann nicht 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.

    • vCenter Server Virtual Appliance unterstützt IPv6 nicht
      Obwohl die Webkonsole der virtuellen vCenter Server Appliance eine Option zum Konfigurieren von IPv6 bereitstellt, unterstützt die virtuelle vCenter Server Appliance das Konfigurieren von IPv6 nicht.

      Umgehung: Legen Sie die IPv6-Konfiguration auf der Webkonsole der virtuellen vCenter Server Appliance nicht fest und ändern Sie diese auch nicht.

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

    • Versuche, die Registrierung mehrerer Speicheranbieter gleichzeitig aufzuheben, schlagen möglicherweise mit einem Fehler fehl
      Wenn Sie versuchen, gleichzeitig die Registrierung mehrerer Speicheranbieter von vCenter Server aufzuheben, schlagen diese Versuche möglicherweise fehl. Die folgende Fehlermeldung wird angezeigt, obwohl die fehlgeschlagenen Anbieter in vCenter Server vorhanden sind: ManagedObjectNotFound. Die Datei "sms.log" zeigt möglicherweise die folgende Ausnahme an: ProviderUnregistrationFault.

      Umgehung: Heben Sie die Registrierung der Anbieter nach und nach einzeln manuell auf.

    • 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 and 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 Folgende:
      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überschreitungsbezogener 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).
    • Die im Lieferumfang der vCenter Server Appliance eingebettete Datenbank unterstützt eine Bestandsliste mit maximal 5 Hosts und 50 virtuellen Maschinen
      Die eingebettete Datenbank ist nicht zum Verwalten einer Bestandsliste konfiguriert, die mehr als 5 Hosts und 50 virtuelle Maschinen enthält. Das Überschreiten dieser Einschränkungen kann viele Probleme verursachen, z. B., dass vCenter Server nicht mehr antwortet, wenn Sie die eingebettete Datenbank mit der vCenter Server Appliance verwenden.

    • Die Seitenleiste "Alarme" von vSphere Web Client gibt nicht die richtige Anzahl der Alarme im System an
      Wenn im System mehr als 100 Alarme vorhanden sind, werden in der Seitenleiste "Alarme" von vSphere Web Client nur 100 Alarme angegeben.

      Umgehung:Keine.

    • Überblicksleistungsdiagramme für Datenspeicher-Cluster oder Datenspeicher erscheinen in großen Umgebungen nicht
      In einigen großen Umgebungen werden Überblicksleistungsdiagramme für Datenspeicher-Cluster oder Datenspeicher möglicherweise nicht angezeigt, weil für vSphere Management WebServices (Tomcat) nicht genügend freier Arbeitsspeicher zur Verfügung steht.

      Umgehung:Erhöhen Sie die Menge des verfügbaren Arbeitsspeichers für Tomcat.

    • Bei der Verwendung von vSphere Web Client werden Sie wiederholt aufgefordert, die Menge des für Adobe Flash zur Verfügung stehenden lokalen Speichers zu erhöhen
      vSphere Web Client verwendet lokalen Speicher auf dem System, das für den Zugriff auf den Client für das Speichern von Protokolldateien verwendet wird. Die Speicherlimits für die Protokolldateien werden von den Adobe Flash Player-Einstellungen vorgegeben. Wenn die Protokolldateien größer werden, erscheint ein Dialogfeld, in dem der Benutzer aufgefordert wird, den Grenzwert zu erhöhen. Sie werden immer wieder aufgefordert, den Grenzwert zu erhöhen, bis das Speicherlimit Unbegrenzt erreicht hat.

      Umgehung: So legen Sie die Speicherlimits für den Adobe Flash Player fest:

      1. Öffnen Sie den Bereich "Globale Speichereinstellungen", indem Sie in Ihrem Web-Browser die folgende URL öffnen: http://www.macromedia.com/support/documentation/de/flashplayer/help/settings_manager03.html
      2. Bewegen Sie den Schieberegler auf Unbegrenzt.
      3. Öffnen Sie den Bereich "Website-Speichereinstellungen", indem Sie in Ihrem Web-Browser die folgende URL öffnen: http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager07.html
      4. Wählen Sie die URL für vSphere Web Client unter "Besuchte Websites" aus.
      5. Bewegen Sie den Schieberegler auf Unbegrenzt.

    • In vSphere Web Client können mehrere Spalten für die Sortierung nicht ausgewählt werden
      In Tabellen in vSphere Web Client können Sie die primäre Spalte für die Sortierung auswählen, indem Sie auf die Spaltenkopfzeile klicken. Wenn Sie auf eine zweite Spaltenkopfzeile klicken, wird diese Spalte zur primären statt zur sekundären Sortierspalte.

      Umgehung: Führen Sie den folgenden Vorgang durch, wenn Sie nach mehreren Spalten in vSphere Web Client-Tabellen sortieren möchten:

      1. Klicken Sie auf eine Spaltenkopfzeile, um eine Spalte als primäre Sortierspalte festzulegen.
      2. Wählen Sie die sekundären und nachfolgenden Spalten für die Sortierung aus, indem Sie bei gedrückter Strg-Taste auf die jeweilige Spalte klicken.

    • Internet Explorer 7 kann vSphere Web Client-Seiten nicht laden
      Wenn in den Internet Explorer 7-Sicherheitseinstellungen about:internetund https://localhostnicht als vertrauenswürdige Sites aufgeführt werden, kann der Webbrowser keine vSphere Web Client-Seiten öffnen.

      Umgehung: Fügen Sie about:internetund https://localhostals vertrauenswürdige Sites hinzu:

      1. Wählen Sie in Internet Explorer 7 Extras > Internetoptionen.
      2. Klicken Sie auf die Registerkarte Sicherheit.
      3. Wählen Sie Vertrauenswürdige Sites.
      4. Klicken Sie auf Sites.
      5. Geben Sie im Textfeld Diese Website zur Zone hinzufügen die Site about:internet ein und klicken Sie auf Hinzufügen.
      6. Geben Sie im Textfeld Diese Website zur Zone hinzufügen die Site https://localhost ein und klicken Sie auf Hinzufügen.
      7. Klicken Sie auf OK.
      8. Schließen Sie Internet Explorer und starten Sie ihn neu.

    • Das Öffnen der vSphere Administration Application über eine Verknüpfung verursacht den Fehler: 'https://localhost:9443/admin-app' wurde nicht gefunden
      Wenn Firefox der Standard-Webbrowser ist und nicht ausgeführt wird, verursacht das Starten von vSphere Administration Application über eine Verknüpfung möglicherweise den Fehler: 'https://localhost:9443/admin-app' wurde nicht gefunden. Stellen Sie sicher, dass Sie den Namen korrekt eingegeben haben, und versuchen Sie es erneut.

      Umgehung:Dies ist ein bekanntes Problem mit Firefox auf manchen Windows-Systemen. Weitere Informationen hierzu finden Sie unter http://kb.mozillazine.org/Windows_error_opening_Internet_shortcut_or_local_HTML_file_-_Firefox.

    • vSphere Web Client lädt die vCenter Server-Bestandsliste nicht, wenn der Hostname von vCenter Server nicht aufgelöst werden kann
      Wenn vSphere Web Client den Hostnamen von vCenter Server nicht auflösen kann und vCenter Server über eine IP-Adresse mit dem vSphere-Client registriert ist, kann vSphere Web Client die Bestandslistenstruktur nicht laden.

      Umgehung: Stellen Sie sicher, dass der Hostname von vCenter Server aufgelöst werden kann, indem Sie einen der folgenden Schritte durchführen:

      • Fügen Sie das vCenter Server-System zu Ihrem Namensserver hinzu.
      • Fügen Sie das vCenter Server-System zur Datei C:\Windows\System32\drivers\etc\hostsauf dem System hinzu, auf dem vSphere Web Client ausgeführt wird.

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

    • Flash-Plug-In stürzt beim An- oder Abmelden bei vSphere Web Client unter Linux ab
      Wenn Sie sich unter Linux bei vSphere Web Client anmelden oder dort abmelden, stürzt das Flash-Plug-In möglicherweise ab.

      Umgehung:Laden Sie die Seite neu, um das Flash-Plug-In neu zu starten.

    • Auf das Verwaltungstool von vSphere Web Client kann nicht unter Verwendung einer lokalen IPv6-Adresse zugegriffen werden
      Wenn Sie versuchen, auf das Verwaltungstool von vSphere Web Client unter Verwendung einer lokalen IPv6-Adresse zuzugreifen, zeigt der Webbrowser die folgende Fehlermeldung an: Auf das vSphere Web Client-Verwaltungstool kann von einem Remotehost aus nicht zugegriffen werden.

      Umgehung: Verwenden Sie "localhost" anstelle der IPv6-Adresse für den Zugriff auf das Verwaltungstool. Verwenden Sie z. B. https://localhost:9443/admin-appanstelle einer Adresse wie https://[fc00:10:20:123:355c:1744:1b82:6716]:9443/admin-app.

    • Internet Explorer 7 kann auf keine vSphere-Client-Webseiten zugreifen, wenn der Client auf einem System installiert ist, das ausschließlich IPv6 verwendet
      Wenn vSphere Web Client auf einem System installiert ist, das ausschließlich IPv6 verwendet, können Sie Internet Explorer 7 nicht für den Zugriff auf vSphere Web Client verwenden.

      Umgehung:Verwenden Sie Firefox oder Internet Explorer 8 für den Zugriff auf vSphere Web Client.

    • Internet Explorer kann möglicherweise das Client-Integrations-Plug-In nicht herunterladen
      Wenn Sie Internet Explorer zum Herunterladen des Client-Integrations-Plug-Ins verwenden, erscheint möglicherweise die folgende Fehlermeldung: Internet Explorer kann vmware-vmcr-win32-x86.exe von localhost nicht herunterladen.Dies kann passieren, wenn bestimmte Sicherheitseinstellungen in Internet Explorer das Herunterladen des Client-Integrations-Plug-Ins verhindern.

      Umgehung: Verwenden Sie eine alternative Methode zum Herunterladen des Client-Integrations-Plug-Ins.

      • Verwenden Sie Firefox, um eine Verbindung zu vSphere Web Client herzustellen und das Client-Integrations-Plug-In herunterzuladen.

      • Verwenden Sie Internet Explorer, um eine direkte Verbindung zur Client-Integrations-Plug-In-Datei unter Verwendung des nicht sicheren Ports http:// IP-Adresse: Portnummer/vsphere-client/vmrc/vmware-vmrc-win32-x86.exe herzustellen. Beispiel: http://localhost:9090/vsphere-client/vmrc/vmware-vmrc-win32-x86.exe.

    • vSphere Web Client lädt und aktualisiert keine Daten
      Manchmal kann vSphere Web Client keine Daten laden und aktualisieren. Das Drehfeld-Steuerelement in der oberen rechten Ecke des Anwendungsfensters dreht sich weiter und die angeforderten Informationen werden nicht angezeigt.

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

      • Klicken Sie auf die Aktualisierungsschaltfläche des Browsers.
      • Wählen Sie ein anderes Objekt aus der Bestandslistenstruktur aus und klicken Sie auf die Aktualisierungsschaltfläche des Browsers.
      • Überprüfen Sie den Systemzustand von vCenter Server und dessen Diensten. Starten Sie alle Dienste neu, die angehalten wurden.

    • Beim Sichern von Daten des Bestandslistendiensts in vCenter Server Appliance tritt ein Fehler auf
      Wenn Sie das Skript /usr/lib/vmware-vpx/inventoryservice/scripts/backup.shausführen, um die Daten des Bestandslistendiensts in vCenter Server Appliance zu sichern, schlägt es möglicherweise fehl mit der folgenden Fehlermeldung: Java HotSpot(TM) 64-Bit-Server-VM - Warnung: Versuch der Zuteilung von Stack-Guard-Seiten fehlgeschlagen.Dieser Fehler tritt auf, wenn wenig freier Arbeitsspeicher für vCenter Server Appliance zur Verfügung steht und JVM nicht genügend Arbeitsspeicher zum Starten des Prozesses zuteilen kann.

      Umgehung: Erhöhen Sie den System-RAM für vCenter Server Appliance.

    • Ein Neustart von vpxd in vCenter Server Appliance schlägt mit einem Datenbankfehler fehl
      Ein Neustart von vpxdauf vCenter Server Appliance mit einer eingebetteten Datenbank schlägt möglicherweise fehl. Eine Fehlermeldung ähnlich der Folgenden erscheint in der Datei vpxd.log:
      Alert:false@ /build/mts/release/bora-336896/bora/vpx/vpxd/util/vpxdVdb.cpp:403

      Dieser Fehler tritt auf, wenn die Systemuhr auf vCenter Server Appliance auf einen Zeitpunkt zurückgesetzt wurde, der früher als der Zeitpunkt ist, zu dem die Datenbank erstellt wurde. Folglich weisen von vCenter Server Appliance erstellte Datenbankobjekte einen Zeitstempel auf, der eine Zeit in der Zukunft angibt. Dies führt dazu, dass Abfragen auf Datenbankobjekte fehlschlagen.

      Dieser Fehler tritt möglicherweise während der Active Directory-Konfiguration auf, wenn die Uhr auf dem Active Directory-Domänencontroller auf einen früheren Zeitpunkt als die Uhr auf vCenter Server Appliance gesetzt wurde, da während der Konfiguration die Uhr von vCenter Server Appliance mit der Uhr auf dem Active Directory-Domänencontroller synchronisiert wird.

      Umgehung: Setzen Sie nach dem Konfigurieren der eingebetteten Datenbank die Systemuhr auf vCenter Server Appliance nicht auf einen früheren Zeitpunkt. Stellen Sie beim Konfigurieren von Active Directory sicher, dass die Uhr auf dem Active Directory-Domänencontroller nicht auf einen Zeitpunkt gesetzt ist, der früher als der der Uhr auf vCenter Server Appliance ist.

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

    • Auf die Anmeldeseite von vSphere Web Client kann nicht von der vCenter Server-Begrüßungsseite aus zugegriffen werden
      Wenn Sie die URL "localhost" verwenden, um auf die vCenter Server-Begrüßungsseite zuzugreifen, wird ein Fehler generiert, wenn Sie auf "Bei vSphere Web Client anmelden" klicken.

      Umgehung: Verwenden Sie die IP-Adresse oder den Hostnamen des vCenter Server-Systems für den Zugriff auf die Begrüßungsseite.

    • Im Dialogfeld "Benutzer und Gruppen auswählen" des vSphere-Clients sind Benutzer- und Gruppennamen abgeschnitten
      Wenn Sie einem Bestandslistenobjekt im vSphere-Client eine Berechtigung hinzufügen, werden die Namen von Benutzern und Gruppen im Dialogfeld "Benutzer und Gruppen auswählen" möglicherweise abgeschnitten. Beispiel: Administrator wird möglicherweise als tor angezeigt. Benutzer und Gruppen können nur ausgewählt werden, wenn Sie den vollständigen, richtigen Namen eingeben.

      Dieses Problem tritt auf, wenn der Workstation-Dienst in Windows angehalten wurde.

      Umgehung: Starten Sie den Workstation-Dienst auf der vCenter Server-Maschine neu.

      1. Wählen Sie Start > Programme > Verwaltung > Dienste.
      2. Klicken Sie mit der rechten Maustaste auf Workstation und wählen Sie Starten.

    • Die exportierte Liste der virtuellen Maschinen ist möglicherweise unvollständig
      Wenn Sie ein Datencenter, einen Cluster, einen Host oder ein anderes Objekt in der vSphere-Client-Bestandsliste auswählen und eine Liste deren virtuellen Maschinen exportieren, enthält die Liste möglicherweise nicht alle virtuellen Maschinen. Dies geschieht, weil die Informationen in der Liste nicht immer für Objekte, die nicht sichtbar sind, gefüllt werden.

      Umgehung:Scrollen Sie vor dem Exportieren durch die Liste, um sicherzugehen, dass alle virtuellen Maschinen angezeigt werden.

    • Störende Fehlermeldungen erscheinen in den vSphere Web Client-Protokolldateien
      Aufgrund der Versionen von Tomcat und dm Server erscheinen einige störende Fehlermeldungen in den vSphere Web Client-Protokolldateien. Darunter sind einige INFO-Meldungen sowie die Meldung SEVERE: No global context defined for server.Sie können diese Meldungen ignorieren.

      Umgehung:Keine.

    • In der Online-Hilfe zu vSphere Web Client wird Firefox 3.5 fälschlicherweise als unterstützter Browser aufgeführt
      In der Online-Hilfe zu vSphere Web Client wird Firefox 3.5 fälschlicherweise als unterstützter Browser für vSphere Web Client und das Client-Integrations-Plug-In aufgeführt .

      Umgehung:Informationen zu den unterstützten Webbrowsern finden Sie im Installations- und Einrichtungshandbuch für vSphere.

    • Beim Versuch, VM-Speicherprofile anzuzeigen, wird im vSphere-Client eine Fehlermeldung angezeigt
      Wenn Sie den vSphere-Client mit vCenter Server verbinden und versuchen, das Speicherprofil einer virtuellen Maschine anzuzeigen, erscheint möglicherweise die Fehlermeldung VC kann keine Verbindung zum profilgesteuerten Speicherdienst unter http:///sps/sdk herstellen.

      Ein Portkonflikt tritt auf, wenn der Speicherprofildienst und ein weiterer Dienst für die Verwendung von Port 31000 konfiguriert sind. vSphere Web Client und vCenter Orchestrator können diesen Konflikt verursachen.

      Umgehung:Starten Sie den vSphere Web Client-Dienst und den vCenter Orchestrator-Konfigurationsdienst neu. Die Dienste wählen den nächsten verfügbaren Port aus, wenn sie neu gestartet werden. Wenn nur einer der Dienste auf der Maschine vorhanden ist oder ausgeführt wird, müssen Sie nur diesen Dienst neu starten.

      Verwaltung von virtuellen Maschinen
      • 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.

    • Die Inkompatibilität von vCenter Server 5.0 und ESX/ESXi-Hosts sorgt dafür, dass Migrationsvorgänge für virtuelle Maschinen mit Delta-Festplatten fehlschlagen
      Wenn vCenter Server 5.0 einen Host vor ESX/ESXi 4.0 Update 3 verwaltet, können Sie keine virtuellen Maschinen mit Snapshots oder Delta-Festplatten auf diesen Host migrieren. Beim Versuch, eine solche Migration durchzuführen, erscheint die folgende Systemfehlermeldung: Aufgrund einer Versionsinkompatibilität zwischen vCenter Server und ESX wird das Migrieren von virtuellen Maschinen mit Snapshots oder Delta-Festplatten nicht unterstützt . Führen Sie zum Fortfahren dieses Vorgangs ein Upgrade von Ihren ESX-Hosts auf ESX 4.0 Update 3 oder höher durch.
      Für ESX/ESXi 4.1 gilt dieselbe Einschränkung und eine ähnliche Fehlermeldung erscheint. ESX/ESXi 4.1 unterstützt das Migrieren von virtuellen Maschinen mit Delta-Festplatten nicht, wenn vCenter Server 5.0 den Host verwaltet.

      Umgehung:Führen Sie ein Upgrade des ESX/ESXi-Hosts auf ESX/ESXi 4.0 Update 3 oder höher durch oder führen Sie ein Upgrade auf ESX 4.1 Update 1 oder höher durch.

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

      • Eine Cold-Migration einer virtuellen Maschine mit einer virtuellen IDE-Festplatte von einem ESXi 5.0-Host auf einen ESX/ESXi 4.x-Host schlägt mit folgender Fehlermeldung fehl: Der Vorgang wird für dieses Objekt nicht unterstützt
        Wenn Sie vCenter Server 5.0 zum Durchführen einer Cold-Migration einer virtuellen Maschine, die eine oder mehrere virtuelle IDE-Festplatten hat, von einem ESXi 5.0-Host auf einen Host, auf dem ESX/ESXi 4.x ausgeführt wird, verwenden, schlägt die Migration mit der folgenden Fehlermeldung fehl: Der Vorgang wird für dieses Objekt nicht unterstützt.

        Umgehung: Führen Sie die folgenden Schritte aus.

        1. Wählen Sie auf dem ESXi 5.0-Host die virtuelle Maschine aus.
        2. Wenn sich die virtuelle Maschine auf einem nur für Hosts vorgesehenen Datenspeicher auf dem ESXi 5.0-Host befindet, verschieben Sie die .vmx- und .vmdk-Dateien auf eine gemeinsam genutzte LUN, auf die der ESXi 5.0- und der ESX/ESXi 4.x-Host zugreifen können.
        3. Führen Sie eine Cold-Migration der virtuellen Maschine auf den ESX/ESXi 4.x-Host mithilfe der Option Host ändern im Assistenten "Migrieren von virtuellen Maschinen" durch.
           
      • 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.

      • Das vCenter Server-Unterstützungspaket-Tool findet keine Protokolldaten, die in einem benutzerdefinierten Speicherort gespeichert sind
        Das vCenter Server-Unterstützungspaket-Tool findet keine Protokolldateien, die in einem benutzerdefinierten, nicht standardmäßigen Speicherort gespeichert sind. Das vCenter Server-Unterstützungspaket-Tool unterscheidet sich vom Erfassungs-Tool des vSphere-Clients.

        Umgehung: Verbinden Sie einen vSphere-Client mit vCenter Server und verwenden Sie die Funktion "Exportieren von Systemprotokollen", um die Protokolldaten abzurufen. Wählen Sie im vSphere-Client Verwaltung > Exportieren von Systemprotokollen.

        Falls Sie keine Verbindung zwischen einem vSphere-Client und vCenter Server herstellen können, müssen Sie die Dateien manuell in das Protokollpaket kopieren.

      • In vCenter Server 5.0 werden einige erweiterte Konfigurationsoptionen für vSphere HA nicht mehr unterstützt.
        Die folgenden Optionen werden nicht mehr unterstützt.

        das.consoleUser
        das.consoleNode
        das.consolePerm
        das.primaryCount
        das.checkVmStateDelay
        das.trace
        das.traceLevel
        das.traceOutput
        das.preferredPrimaries
        das.disableUWSwapRequirement
        das.sensorPollingFreq
        das.bypassNetCompatCheck
        das.defaultfailoverhost
        das.failureDetectionTime
        das.failureDetectionInterval

        Falls Sie versuchen, eine der nicht unterstützten Optionen festzulegen, meldet vCenter Server 5.0, dass die Option ungültig ist. Wenn Sie darüber hinaus ein Upgrade auf vCenter Server 5.0 von einer vorherigen Version durchführen, bei der eine oder mehrere dieser Optionen definiert sind, werden sie gelöscht und haben keine Auswirkung mehr.

        Umgehung:Keine.

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

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

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

      • Benutzer mit Benutzernamen, die Nicht-ASCII-Zeichen enthalten, können sich nicht über vSphere Web Client beim vCenter Server anmelden
        vSphere Web Client nimmt keine Benutzernamen an, die Nicht-ASCII-Zeichen enthalten. Benutzer mit Namen, die Nicht-ASCII-Zeichen enthalten, können vSphere Web Client zum Herstellen einer Verbindung mit vCenter Server nicht verwenden.

        Umgehung:Verwenden Sie den vSphere-Client zum Herstellen einer Verbindung mit vCenter Server.

      • Probleme in Zusammenhang mit der lokalisierten Suche und mit lokalisierten Suchbereichen in der Hilfe zu vSphere Web Client
        Zu den bekannten Problemen im Zusammenhang mit der lokalisierten Suche in der Hilfe zu vSphere Web Client gehören:

        • Suchen unter Verwendung erweiterter Zeichen anderer Sprachen als Englisch führen zu keinen Ergebnissen.
        • Wenn die Namen von Suchbereichen Nicht-ASCII-Zeichen enthalten, werden diese Zeichen nicht korrekt dargestellt.

        Umgehung: Bearbeiten Sie die Datei tomcat-server.xml, um UTF-8 als Zeichensatz für URIs anzugeben:

        1. Öffnen Sie die Datei Installationsverzeichnis_von_vSphere_Web_Client\springsource-dm-server-2.0.4\config\tomcat-server.xmlmithilfe eines Texteditors.
        2. Bearbeiten Sie den folgenden Abschnitt der Datei, um den Parameter URIEncoding="UTF-8"am Ende folgender Zeile hinzuzufügen: connectionTimeout="20000":

          <Connector port="9090" protocol="HTTP/1.1"
          connectionTimeout="20000"
          redirectPort="9443" emptySessionPath="true"/>


          9090 ist der Standardwert für den Connector-Port. Falls Sie diesen Wert während der Installation geändert haben, sehen Sie eine andere Portnummer. Ändern Sie die Portnummer nicht.

          Nach der Änderung sieht der Abschnitt wie folgt aus:

          <Connector port="9090" protocol="HTTP/1.1"
          connectionTimeout="20000" URIEncoding="UTF-8"
          redirectPort="9443" emptySessionPath="true"/>
        3. Bearbeiten Sie den folgenden Abschnitt der Datei, um den Parameter URIEncoding="UTF-8"am Ende folgender Zeile hinzuzufügen: keystoreFile="config/keystore":

          <Connector port="9443" protocol="HTTP/1.1" SSLEnabled="true"
          maxThreads="500" scheme="https" secure="true"
          clientAuth="false" sslProtocol="TLS"
          keystoreFile="config/keystore"
          keystorePass="changeit" emptySessionPath="true"/>


          9443 ist der Standardwert für den Connector-Port. Falls Sie diesen Wert während der Installation geändert haben, sehen Sie eine andere Portnummer. Ändern Sie die Portnummer nicht.

          Nach der Änderung sieht der Abschnitt wie folgt aus:

          <Connector port="9443" protocol="HTTP/1.1" SSLEnabled="true"
          maxThreads="500" scheme="https" secure="true"
          clientAuth="false" sslProtocol="TLS"
          keystoreFile="config/keystore" URIEncoding="UTF-8"
          keystorePass="changeit" emptySessionPath="true"/>
        4. Speichern Sie die Datei.
    • Migration VMware HA und Fault Tolerance

      Gastbetriebssystem

      Unterstützte Hardware Internationalisierung
    • Die Informationen auf der Registerkarte "Virtuelle Maschinen" werden möglicherweise nicht aktualisiert
      Manchmal werden die Informationen auf der Registerkarte Virtuelle Maschinen des vSphere-Clients nicht sofort aktualisiert. Wenn Sie beispielsweise eine große Anzahl an virtuellen Maschinen klonen oder registrieren, werden einige virtuelle Maschinen möglicherweise nicht auf der Registerkarte Virtuelle Maschinen angezeigt, obwohl sie in der Bestandslistenstruktur vorhanden sind. Wenn Sie eine große Anzahl an virtuellen Maschinen ein- oder ausschalten, werden die neuen Betriebszustände möglicherweise nicht auf der Registerkarte Virtuelle Maschinen angezeigt, obwohl sie in der Bestandslistenstruktur ordnungsgemäß angezeigt werden.

      Umgehung: Drücken Sie F5, um die Informationen auf dieser Registerkarte zu aktualisieren.

    • Die Webkonsole von VMware vCenter Server Appliance bietet Optionen für das Konfigurieren von IPv6, obwohl IPv6 nicht unterstützt wird
      Obwohl VMware vCenter Server Appliance IPv6 nicht unterstützt, steht auf der Registerkarte Netzwerk der Webkonsole von VMware vCenter Server Appliance eine Konfigurationsoption für IPv6 und eine IPv6-Adresse wird standardmäßig der Appliance zugewiesen, wenn sich ein DHCPv6-Server im Netzwerk befindet.

      Umgehung: Geben Sie eine ungültige statische IPv6-Adresse für VMware vCenter Server Appliance ein, um zu verhindern, dass die Appliance eine IPv6-Adresse über DHCP bezieht.

    • Unter Windows Server 2008 wird vSphere Web Client nicht in Internet Explorer 9 geladen
      Wenn Sie unter Windows Server 2008 versuchen, vSphere Web Client in Internet Explorer 9 zu laden, sehen Sie nur einen blauen Hintergrund im Fenster des Webbrowsers und es passiert nichts.

      Umgehung: Verwenden Sie unter Windows Server 2008 Internet Explorer 7 bzw. 8 oder Mozilla Firefox 3.6 oder höher für den Zugriff auf vSphere Web Client.

    • Der Zustand von vSphere Web Client wird zwischen Sitzungen nicht beibehalten
      Der Zustand von vSphere Web Client wird normalerweise zwischen Sitzungen beibehalten, sodass, wenn Sie sich erneut bei vSphere Web Client anmelden, dieselben Objekte und Registerkarten ausgewählt sind, die ausgewählt waren, als Sie sich von der vorherigen Sitzung abgemeldet haben. Wenn jedoch Ihre Webbrowser-Voreinstellungen so festgelegt sind, dass der Browser den Verlauf nicht speichert, oder die Website-Speichereinstellungen des Flash Players keinen Arbeitsspeicher für besuchte Sites zuteilen, speichert der Flash Player keine Daten von vSphere Web Client und der Zustand wird von Sitzung zu Sitzung nicht beibehalten.

      Umgehung: Führen Sie den folgenden Vorgang durch:

      1. Navigieren Sie zu http://www.macromedia.com/support/documentation/de/flashplayer/help/settings_manager07.html und stellen Sie sicher, dass die Menge des Arbeitsspeichers auf einen Wert anders als Keinen festgelegt ist.
      2. Wenn Sie den Firefox-Browser verwenden, legen Sie die Einstellungen für den Browserverlauf fest:
        1. Wählen Sie Extras > Einstellungen.
        2. Klicken Sie auf Datenschutz.
        3. Wählen Sie eine Option außer Niemals anlegen.

    • vSphere Web Client produziert in Abständen den Fehler 2406: Die geladene Datei verfügt über keine gültige Signatur
      Bei Verwendung von Mozilla Firefox 3.6.x auf SUSE Linux Enterprise Server 11 oder Red Hat Enterprise Linux 5 tritt in Abständen die folgende Fehlermeldung auf: Fehler 2406: Die geladene Datei verfügt über keine gültige Signatur.

      Starten Sie den Webbrowser neu und stellen Sie eine neue Verbindung zu vSphere Web Client her.

    • vCenter Server stürzt beim Exportieren von Systemprotokollen ab
      Wenn Sie Systemprotokolle von vCenter Server exportieren, verwendet vCenter Server den in der Windows-Umgebungsvariablen TEMPangegebenen Ordner. Standardmäßig wird diese Variable auf C:\Windows\Tempfestgelegt.

      Wenn vCenter Server zum Speichern einer großen Menge an Protokolldaten konfiguriert ist oder wenn Sie eine große Anzahl an Hosts auswählen, von denen Protokolle heruntergeladen werden sollen, kann es passieren, dass das in der TEMP-Variablen angegebene Laufwerk über keinen Speicherplatz mehr verfügt. Falls es sich bei diesem Laufwerk um dasselbe Laufwerk handelt, auf dem vCenter Server installiert ist, stürzt der VMware VirtualCenter Server-Dienst möglicherweise ab.

      Umgehung: Stellen Sie sicher, dass das in der Windows-Umgebungsvariable TEMPangegebene Laufwerk über genügend freien Speicherplatz für exportierte Protokolle verfügt. Ziehen Sie in Betracht, ein anderes Laufwerk als C:in der TEMP-Variablen zu verwenden, um eine Unterbrechung der Systemdienste zu verhindern.

    • Bei der Suche im vSphere-Client oder in vSphere Web Client werden veraltete Ergebnisse angezeigt oder es kommt zu einer Zeitüberschreitung
      Wenn Sie die Bestandsliste im vSphere-Client oder in vSphere Web Client durchsuchen, werden möglicherweise veraltete Informationen angezeigt. Bei der Verwendung von vSphere Web Client kann es außerdem zu einer Zeitüberschreitung kommen.

      Die folgende Fehlermeldung deutet auf einen unerwarteten Laufzeitfehler in der Protokolldatei ds.logdes Bestandslistendiensts hin:
      [2011-06-27 18:04:25,367 pool-14-thread-5 ERROR
      com.vmware.vim.query.server.provider.impl.ProviderManagerServiceImpl] Unexpected runtime exception:
      com.xhive.error.XhiveInterruptedException: INTERRUPTED

      Umgehung: Starten Sie den Inventory Service neu.

      Führen Sie für ein vCenter Server-System unter Windows die folgenden Schritte durch:

      1. Starten Sie Windows Service Manager:
        1. Wählen Sie Start > Ausführen.
        2. Geben Sie services.msc ein.
      2. Klicken Sie mit der rechten Maustaste auf den vCenter Inventory Service und wählen Sie Neustart.

      Führen Sie für vCenter Server Appliance die folgenden Schritte durch:
      1. Melden Sie sich bei der VMware vCenter Server Appliance Web-Konsole an.
      2. Wählen Sie auf der Registerkarte vCenter Server die Option Status aus.
      3. Klicken Sie auf vCenter beenden.
      4. Klicken Sie auf vCenter starten.

      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.