ESX 4.0 Update 4 | 17. November 2011 | Build 504850

Letzte Dokumentaktualisierung: 17. November 2011


Diese Versionshinweise decken die folgenden Themen ab:

Neuigkeiten

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

Seitenanfang

Vorherige Versionen von ESX 4.0

Die Funktionen und bekannten Probleme der vorherigen Versionen von ESX 4.0 werden in den Versionshinweisen für die jeweilige Version beschrieben. Wenn Sie Versionshinweise vorheriger Versionen von ESX 4.0 anzeigen möchten, klicken Sie auf einen der folgenden Links:

Seitenanfang

Bevor Sie beginnen

ESX, 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 ESX, vCenter Server, vSphere-Client und weiterer VMware-Produkte.

Hardwarekompatibilität

  • Erfahren Sie mehr über Hardwarekompatibilität

    Die Listen zur Hardwarekompatibilität stehen in dem webbasierten Kompatibilitätshandbuch unter   http://www.vmware.com/resources/compatibility/search.php zur Verfügung. Das webbasierte Kompatibilitätshandbuch stellt eine zentrale Quelle für alle VMware-Kompatibilitätshandbücher dar und bietet die Möglichkeit zur Suche in den Handbüchern und zum Speichern der Suchergebnisse im PDF-Format. Anhand des Handbuchs können Sie z. B. sicherstellen, dass Server, E/A, Speicher und Gastbetriebssysteme kompatibel sind.

    Registrieren Sie sich hier, um über Updates zum Kompatibilitätshandbuch benachrichtigt zu werden: Dies ist das RSS-Bild, das als Link auf einen RSS-Feed dient.

  • Erfahren Sie mehr über die vSphere-Kompatibilität:

    VMware-Produkt-Interoperabilitätmatrix

Dokumentation

Die Dokumentation für VMware vSphere 4.0 Update 1 wurde aktualisiert und gilt für alle Update-Versionen von vSphere 4.0, einschließlich VMware vSphere 4.0 Update 4. Weitere Informationen hierzu finden Sie auf der Dokumentationsseite ESX 4.0 Update 1 und höher mit vCenter Server 4.0 Update 1 und höher.
Das Verfahren zum Generieren neuer Zertifikate für den ESX-Host und zum Ersetzen eines Standardzertifikats durch ein von einer Zertifizierungsstelle signiertes Zertifikat wurde im Handbuch zur Serverkonfiguration für ESX aktualisiert.

Installation und Upgrade

Detaillierte und Schritt-für-Schritt-Anweisungen zur Installation und Konfiguration von ESX und vCenter Server finden Sie im Installationshandbuch – ESX und vCenter Server.

Nach der erfolgreichen Installation sind einige weitere Konfigurationsschritte (insbesondere für die Lizenzierung, für Netzwerke und für die Sicherheitskonfiguration) erforderlich. Beachten Sie die folgenden Handbücher in der vSphere-Dokumentation für weitere Informationen zu diesen Konfigurationsaufgaben.

Künftige Versionen von VMware vSphere werden möglicherweise VMFS Version 2 (VMFS2) nicht unterstützen. Sie sollten auf VMFS Version 3 oder höher aktualisieren bzw. migrieren. Weitere Informationen finden Sie im vSphere-Upgrade-Handbuch .

Die Installation von künftigen Versionen von VMware vCenter Server auf 32-Bit-Windows-Betriebssystemen wird möglicherweise nicht unterstützt. Es wird empfohlen, vCenter Server auf einem 64-Bit-Windows-Betriebssystem zu installieren. Wenn VirtualCenter 2.x installiert ist, finden Sie im vSphere-Upgrade-Handbuch weitere Informationen über das Installieren von vCenter Server auf einem 64-Bit-Betriebssystem und das Beibehalten der VirtualCenter-Datenbank.

MIB-Dateien, die sich auf ESX beziehen, werden nicht zusammen mit vCenter Server mitgeliefert. Nur MIB-Dateien, die sich speziell auf vCenter Server beziehen, sind im Lieferumfang von vCenter Server 4.0.X enthalten. Alle MIB-Dateien können von der VMware-Website unter http://www.vmware.com/de/download heruntergeladen werden.

Durchführen eines Upgrades der VMware Tools

VMware ESX 4.0 Update 4 setzt ein Upgrade von VMware Tools voraus. Die VMware Tools sind 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 den VMware Tools behoben wurden, finden Sie unter Behobene Probleme für VMware Tools.

Das VMware Tools-RPM-Installationsprogramm, das im VMware Tools-ISO-Image für Linux-Gastbetriebssysteme zur Verfügung steht, ist veraltet. Es wird in einer künftigen ESX-Version entfernt. Verwenden Sie das tar.gz-Installationsprogramm zum Installieren der VMware Tools auf virtuellen Maschinen mit Linux-Gastbetriebssystemen.

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

Upgrade oder Migration auf ESX 4.0 Update 4

ESX 4.0 Update 4 bietet die folgenden Optionen für das Upgrade:

  • VMware vCenter Update Manager – Sie können ein Upgrade von ESX 3.5 Update 5a und ESX 4.0.x mithilfe von vCenter Update Manager 4.0 Update 4 durchführen. Weitere Informationen hierzu finden Sie im Administratorhandbuch zu VMware vCenter Update Manager .
  • vSphere Host Update Utility– Sie können ein Upgrade von ESX 3.5 Update 5a mithilfe von vSphere Host Update Utility 4.0 Update 4 durchführen. Weitere Informationen hierzu finden Sie im vSphere-Upgrade-Handbuch .
  • Skript "esxupgrade.sh" – Sie können ein Upgrade von einem ESX 3.5 Update 5a-Host ohne Netzwerkzugriff durchführen. Weitere Informationen finden Sie unter Durchführen eines Offline-Upgrades von ESX 3.x auf ESX 4.x (KB 1009440). Sofern der Host über Netzwerkzugriff verfügt, können Sie zum Durchführen des Upgrades das vSphere Host Update Utility oder den VMware vCenter Update Manager verwenden.
  • Befehl "vihostupdate" der VMware vSphere-Befehlszeilenschnittstelle (vSphere-CLI) –Sie können ein Upgrade von ESX 4.0.x mithilfe des Befehls vihostupdatedurchführen. Weitere Informationen hierzu finden Sie im vSphere-Upgrade-Handbuch und im Handbuch für die Patch-Verwaltung.
  • Befehlszeilenprogramm "esxupdate"–Sie können ein Upgrade von ESX 4.0.x mithilfe des Befehlszeilenprogramms esxupdatedurchführen. Informationen hierzu finden Sie im vSphere-Upgrade-Handbuch und im Handbuch für die Patch-Verwaltung.

Mehrere Upgrade-Tools, die in ESX 3.x-Versionen unterstützt wurden, werden in der aktuellen Version nicht mehr unterstützt. Diese Tools umfassen Upgrades mit grafischer Benutzeroberfläche von CD, Upgrades im Textmodus von CD, Tarball-Upgrades mithilfe der Servicekonsole, Upgrades im Skriptmodus von CD oder einem PXE-Server unter Verwendung von esxupdateund Upgrades im Skriptmodus von CD oder einem PXE-Server mithilfe von Kickstart-Befehlen.

Unterstützte Upgrade-Pfade für das Host-Upgrade auf ESX 4.0 Update 4:


Upgrade-Lieferumfang

Unterstützte Upgrade-Tools  

Unterstützte Upgrade-Pfade auf ESX 4.0 Update 4

ESX 3.5 Update 5a

ESX 4.0, einschließlich
ESX 4.0 Update 1, ESX 4.0 Update 2 und ESX 4.0 Update 3
ESX-4.0.0-update04-<xxxxxx>.iso
  • VMware vCenter Update Manager mit ESX-Host-Upgrade-Baseline
  • vSphere Host Update Utility

Ja

Nein
update-from-esx4.0-4.0_update04.zip
  • esxupdate
  • vihostupdate

Nein

Ja
Patch-Definitionen, die vom VMware-Portal (online) heruntergeladen werden VMware vCenter Update Manager mit Host-Patch-Baseline
Nein
Ja

Anmerkungen:

  • Direkte Upgrades von ESX 3.0.x oder früher auf ESX 3.5 Update 5a werden nicht unterstützt. Sie sollten zunächst ein Upgrade auf eine neuere unterstützte Version durchführen und anschließend ein Upgrade auf ESX 4.0 Update 4 durchführen.
  • Direkte Upgrades von ESX 2.5.x werden nicht unterstützt. Sie können mithilfe von Upgrade vMotion virtuelle ESX 2.5.5-Maschinen nach ESX 4.0 Update 4 migrieren. Weitere Informationen dazu finden Sie im vSphere-Upgrade-Handbuch .

 

Seitenanfang

Aktualisierte RPMs und Sicherheits-Fixes

Eine Liste der in ESX 4.0 Update 4 aktualisierten RPMs finden Sie unter Aktualisierte RPMs und Sicherheits-Fixes. Dieses Dokument gilt nicht für die ESXi-Produkte.

Aktualisieren von vSphere-Client

Nach dem Upgrade von vCenter Server oder dem ESX/ESXi-Host auf vSphere 4.0 Update 4 werden Sie aufgefordert, ein Upgrade des vSphere-Clients auf vSphere Client 4.0 Update 4 durchzuführen. Das Upgrade des vSphere-Clients ist obligatorisch. Sie dürfen nur den aktualisierten vSphere-Client zum Zugriff auf vSphere 4.0 Update 4 verwenden.
Hinweis: Sie müssen vSphere Client 4.0 Update 4 zum Zugriff auf vCenter Server verwenden, die Teil einer Gruppe im verknüpften Modus mit mindestens einer Instanz von vCenter Server 4.0 Update 4 sind.

In dieser Version enthaltene Patches

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

Patch-Version ESX400-Update04 enthält die folgenden einzelnen Bulletins:

ESX400-201109201-SG: Aktualisiert VMkernel, VMX, Hostd und Anwendungen

Weitere Informationen zu den Inhalten des Patches finden Sie in der Dokumentation, auf die auf der Download-Seite verwiesen wird.

Seitenanfang

Behobene Probleme

Diese Update-Version enthält alle zusammengefassten Fixes des ESX400-201110001-Patches und bietet eine Lösung der Probleme aus den folgenden Bereichen:


Sicherheit


    Seitenanfang

    Bekannte Probleme

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

    Sicherung

    • VMware Consolidated Backup (VCB) 1.5 Update 1 mit Windows 7 und Windows 2008 R2 x64
      VMware Consolidated Backup (VCB) 1.5 Update 1 unterstützt das Sichern und Wiederherstellen von Windows 7- und Windows 2008 R2 x64-Gastbetriebssystemen. Sicherungen auf Dateiebene werden bei Windows 7- oder Windows 2008 R2 x64-Gastbetriebssystemen jedoch nicht unterstützt.

    •   VMware Consolidated Backup (VCB) wird nicht mit Fehlertoleranz unterstützt
      Ein auf einer FT-aktivierten virtuellen Maschine durchgeführtes VCB-Backup schaltet sowohl die primären als auch die sekundären virtuellen Maschinen aus und führt möglicherweise dazu, dass die virtuellen Maschinen unbrauchbar werden.

      Umgehung: Keine

    CIM und API

    •  Einige VRM-Sensoren der Stromversorgung werden nicht auf der Registerkarte "vCenter-Hardwarestatus" für die Server IBM x3850 und x3950 M2 angezeigt
      Auf der Registerkarte Hardwarestatus von vCenter Server werden die Sensoren auf der Registerkarte Hardwarestatus für Server vom Typ IBM x3850 und x3950 M2 nicht für alle Statuszustände des PS VRM-Sensors angezeigt. Die CIM-Instanzen werden nicht entsprechend jedem Systemzustand des VRM-Sensors der Stromversorgung auf Servern vom Typ IBM x3850 und x3950 M2 erstellt. Der Grund ist ein Defekt in der IBM BMC-Firmware 4.5. Aus diesem Grund werden die Sensoren nicht auf der Registerkarte Hardwarestatus von "vCenter angezeigt.
    •  In Small Footprint CIM Broker wird eine falsche Versionsnummer aufgeführt
      Die vom SLP-Service aufgeführte Versionsnummer von Small Footprint CIM Broker ist falsch. Diese Version enthält die SFCB-Version 1.3.3, aber in den SLP-Abfrageinformationen wird die Version als 1.3.0 aufgeführt. Diese falsche Versionsnummer wirkt sich jedoch nicht auf die Nutzung des SLP-Dienstes aus. Für dieses Problem gibt es zurzeit keine Umgehung.
    •  Das CIM-Indication-Abonnement ist nach einem ESX-Update nicht mehr verfügbar
      Das CIM-Indication-Abonnement geht verloren, wenn Sie zwischen ESX-Updates aktualisieren oder Patches anwenden. Die Informationen zum Empfänger der Indication werden durch das Upgrade überschrieben und gehen so verloren.

      Umgehungen: Beide der folgenden Umgehungen haben sich als effektiv erwiesen. Wenden Sie die Methode an, die für Ihre Bereitstellung am besten geeignet ist.

      • Führen Sie eine erneute Subskription der CIM-Indications durch
        Möglicherweise ist es nicht möglich, diese Umgehung anzuwenden. In manchen Fällen ist ein erneutes Abonnement der CIM-Indications nicht möglich.

      • Kopieren sie die entsprechenden Dateien aus dem Backup-Repository in das neue Repository, wie in den nachfolgenden Teilschritten beschrieben.
        Bei dieser Umgehung werden die CIM XML-Indication-Abonnements wiederhergestellt.
        1. Verschieben Sie die folgenden Dateien aus dem Backup-Repository in das neue Repository:
          cim_indicationfilter
          cim_indicationfilter.idx
          cim_indicationhandlercimxml
          cim_indicationhandlercimxml.idx
          cim_indicationsubscription
          cim_indicationsubscription.idx
          cim_listenerdestinationcimxml
          cim_listenerdestinationcimxml.idx
          .
          Verschieben Sie beispielsweise die vorherigen Dateien aus dem Backup-Repository wie /var/lib/sfcb/registration/repository.previous/root/interopin das neue Repository wie
          /var/lib/sfcb/registration/repository/root/interop
        2. Starten Sie den Prozess sfcbd-watchdogneu.

    Gastbetriebssystem

    • Virtuelle Debian 5-Maschinen zeigen während Snapshot-Vorgängen eine Fehlermeldung an (KB 1037897)
    • Virtuelle Windows Server 2008 R2-Maschine mit VMXNET 3-Treiber schlägt fehl (KB 1037894)
    • Das Entfernen der Festplatte aus einer virtuellen Maschine mit einem RHEL3-Gastbetriebssystem, ohne dass das Gastbetriebssystem informiert wurde, führt dazu, dass die virtuelle Maschine nicht mehr funktioniert
      Wenn bei einem 32-Bit-System eine Festplatte einer virtuellen Maschine mit einem RHEL3-Gastbetriebssystem und einem BusLogic-Treiber bei laufendem Betrieb entfernt wird, ohne dass das Gastbetriebssystem darüber informiert wurde, funktioniert die virtuelle Maschine nicht mehr.

      Umgehung: Entfernen Sie die Festplatte explizit aus dem Gastbetriebssystem. Rufen Sie zuerst die Details über die Festplatte, die Sie entfernen möchten, aus /proc/scsi/scsi ab:

      1. Merken Sie sich die HOST CHAN ID und die LUN-Nummern des Geräts in /proc/scsi/scsi
      2. Führen Sie an der RHEL-Konsole den folgenden Befehl aus:

        echo "scsi remove-single-device HOST CHAN DEV LUN" > /proc/scsi/scsi

    • Virtuelle Maschine unter Solaris 10 U4 reagiert nicht mehr während eines Upgrades der VMware Tools
      Das Upgrade oder der Neustart der VMware Tools in einer virtuellen Maschine unter Solaris 10 U4 mit einem erweiterten vmxnet-Adapter kann möglicherweise dazu führen, dass das Gastbetriebssystem nicht mehr reagiert und die Installation nicht mehr fortgesetzt werden kann.

      Solaris 10 U5 und spätere Versionen sind von diesem Problem nicht betroffen.

      Umgehung: Bevor Sie VMware Tools installieren oder aktualisieren, sollten Sie vorübergehend den erweiterten vmxnet-Adapter neu konfigurieren, indem Sie entweder dessen Autokonfigurationsdateien in /etc/ entfernen oder die virtuelle Hardware entfernen.

    • Geräte, die im laufenden Betrieb an den BusLogic-Adapter angeschlossen werden, sind im Linux-Gastbetriebssystem nicht sichtbar
      Geräte, die an einen im laufenden Betrieb angeschlossenen BusLogic-Adapter angeschlossen werden, werden von einem Linux-Gastbetriebssystem nicht erkannt, wenn dieses zuvor über einen anderen BusLogic-Adapter verfügte. Außerdem schlägt möglicherweise das Entfernen des BusLogic-Adapters im laufenden Betrieb fehl. Dieses Problem tritt auf, weil der in Linux-Distributionen verfügbare BusLogic-Treiber keine Hot-Plug-APIs unterstützt. Dieses Problem betrifft nicht das Hinzufügen von Festplatten zum Adapter im laufenden Betrieb, sondern nur das Hinzufügen des Adapters selbst im laufenden Betrieb.

      Umgehung: Verwenden Sie zum Hinzufügen im laufenden Betrieb einen anderen Adapter, beispielsweise einen parallelen Adapter oder den SAS LSI Logic-Adapter. Wenn ein BusLogic-Adapter erforderlich ist, sollten Sie versuchen, den Adapter im laufenden Betrieb zu entfernen, nachdem Sie den BusLogic-Treiber im Gastbetriebssystem entladen haben. Sie können außerdem versuchen, den im laufenden Betrieb hinzugefügten Adapter zu steuern, indem Sie eine andere Instanz des BusLogic-Treibers laden. Sie können eine andere Instanz des BusLogic-Adapters laden, indem Sie den Befehl modprobe -o BusLogic1 BusLogic ausführen (wobei Sie für jede Hinzufügeaktion im laufenden Betrieb BusLogic1 durch BusLogic2, BusLogic2 durch BusLogic3 usw. ersetzen).

    • Bei virtuellen Maschinen mit Windows NT-Gastbetriebssystemen ist die Bestätigung einer Warnmeldung erforderlich, die generiert wird, wenn die virtuelle Maschine ein automatisches Upgrade der VMware Tools versucht
      Wenn Sie die Option festlegen, automatisch vor jedem Einschaltvorgang für Windows NT-Gastbetriebssysteme VMware Tools zu prüfen und zu aktualisieren, erscheint die folgende Warnmeldung:

      Automatische Installation des vmxnet-Treibers fehlgeschlagen. Dieser Treiber muss manuell installiert werden.

      Umgehung: Das Upgrade wird so lange angehalten, bis die Warnung bestätigt wird. Melden Sie sich beim Windows NT-Gastbetriebssystem an und bestätigen Sie die Warnmeldung, um das Upgrade abzuschließen.

    • Beim Erstellen einer virtuellen Maschine von Ubuntu 7.10 Desktop wird möglicherweise ein schwarzer Bildschirm angezeigt
      Wenn Sie die Installation für das Ubuntu 7.10 Desktop-Gastbetriebssystem auf einer virtuellen Maschine mit aktivierter Paravirtualisierung auf einem AMD-Host ausführen, bleibt der Bildschirm der virtuellen Maschine möglicherweise leer. Das korrekte Verhalten ist, dass das Installationsprogramm Ihnen die Anweisungen gibt, die CD aus dem Laufwerk zu entfernen und die Eingabetaste zu drücken.

      Umgehung: Drücken Sie die Eingabetaste. Die Installation wird fortgesetzt und die virtuelle Maschine neu gestartet. Außerdem tritt dieser Fehler nicht auf, wenn Sie die Installation auf einer virtuellen Maschine mit zwei oder mehr virtuellen Prozessoren starten.
    • Ein automatisches Upgrade der VMware Tools schlägt für eine virtuelle Maschine unter Red Hat Enterprise Linux 5.x möglicherweise fehl
      Ein automatisches Upgrade der VMware Tools schlägt schlägt möglicherweise für eine virtuelle Maschine unter Red Hat Enterprise Linux 5.x fehl, die mittels Cold-Migration von einem ESX 3.0.3-Host auf einen ESX/ESXi 4.0 Update 1-Host migriert wurde. Folgender Fehler tritt auf: Fehler beim Aktualisieren der VMware Tools.

      Umgehung: Upgrade Sie VMware Tools auf dem ESX 4.0 Update 1-Host manuell.

      Internationalisierung

      • Bei der Eingabe des Namens der Ausgabedatei der parallelen/seriellen Schnittstelle werden keine Nicht-ASCII-Zeichen akzeptiert und es wird eine Fehlermeldung angezeigt
        Beim Konfigurieren einer virtuellen Maschine werden Dateinamen, die Nicht-ASCII-Zeichen enthalten, mit einer Fehlermeldung abgelehnt. Die Validierung von Dateinamen berücksichtigt keine in nicht-englischen Sprachen üblichen Sonderzeichen und kann dazu führen, dass Dateinamen nicht angenommen werden. Dieses Problem betrifft Ausgabedateien für serielle und parallele Schnittstellen und kann auch ISO- und FLP-Namen sowie VMDK-Dateinamen betreffen.

        Umgehung: Beschränken Sie den kompletten Datenspeicherinhalt (Verzeichnisse und Dateinamen) auf ASCII-Zeichen.

      Lizenzierung

      • Ein Host mit einer einzelnen Serverlizenz, der nicht zu vCenter Server hinzugefügt werden kann, verfügt nicht über die Option, während eines nachfolgenden Vorgangs zum Hinzufügen eines Hosts die Lizenzierung entsprechend zu korrigieren
        Wenn ein ESX- oder ESXi-Host, der mit einer einzelnen Serverlizenz konfiguriert ist, zu einem lizenzierten vCenter Server hinzugefügt wird, zeigt vCenter Server eine Fehlermeldung an, die angibt, dass der Host nicht hinzugefügt werden kann.

        Umgehung: Entfernen Sie den nicht verbundenen Host und fügen Sie ihn mit einer Lizenz für mehrere Server erneut hinzu.

      • Virtuelle Maschinen können nicht eingeschaltet werden, wenn während einer Skript- oder einer interaktiven Installation bestimmte Lizenzen installiert werden
        Falls Sie beim Installieren von ESX/ESXi nicht über die richtigen Lizenz-Seriennummern für Ihre Hardware verfügen, tritt möglicherweise ein Lizenzierungsfehler auf. Dieses Problem tritt auf, weil während der Installation der Anbieter und die Ressource die Überprüfung der Validierung von Lizenzschlüsseln nicht durchführen. Nach der Validierung einer Lizenz mit lib/licensecheck ist ein anschließender Test erforderlich, um zu überprüfen, ob das installierte System den Lizenzbeschränkungen entspricht. Das Installationsprogramm führt jedoch die zweite Prüfung nicht durch.

        Umgehung: Wechseln Sie in den Bewertungsmodus und rufen Sie anschließen vom Portal die entsprechende Lizenz ab.

      • Erworbene Add-On-Lizenzen werden nicht in der Lizenzliste der Seite "Lizensierung" des vSphere-Clients angezeigt
        Wenn Sie auf der Seite "Lizensierung" des vSphere-Clients Ihre erworbenen Lizenzen ansehen, sehen Sie keinen eigenen Produkteintrag für Add-On-Editionen. Wenn Sie beispielsweise eine Lizenz für vSphere 4.0 Standard mit vMotion oder vSphere 4.0 Standard mit vMotion und Data Recovery erworben haben, erscheint nur die vSphere 4.0 Standard-Lizenz.

        Umgehung: Führen Sie zum Anzeigen der Produkt- und Add-On-Funktionen für einen Lizenzschlüssel die folgenden Schritte aus:

        1. Klicken Sie auf der vSphere-Startseite auf Lizenzierung.
        2. Klicken Sie zum Starten des Lizenzassistenten in der oberen rechten Ecke auf vSphere-Lizenzen verwalten .
        3. Klicken Sie auf Weiter, um zur Seite „Lizenz zuweisen“ zu wechseln.
        4. Bewegen Sie den Mauszeiger über den Hostlizenzschlüssel, um die verfügbaren Produkt- und Add-On-Funktionen anzuzeigen.

      Sonstige Probleme

      • Vom Benutzer erstellte Dateien im ESX-Verzeichnis /tmp werden nach jedem Neustart des Hosts gelöscht
        Wenn Sie oder die Benutzer, die Sie unterstützen, temporäre Dateien, wie z. B. anwendungsgenerierte Protokolldateien, im ESX-Verzeichnis /tmp speichern, gehen diese Dateien bei jedem Neustart des Hosts verloren.

        Umgehung: Verwenden Sie zum Speichern von benutzergenerierten Dateien und Verzeichnissen nicht das ESX-Verzeichnis /tmp.

      • Eine Datei, die nicht entpackt werden kann, könnte Diagnosedaten von vCenter enthalten
        Beim Extrahieren einer .tgz-Datei, die Diagnosedaten von vCenter enthält, wird ein Dialogfeld, in dem die Dateien aufgelistet sind, die nicht extrahiert werden können, sowie eine Fehlermeldung angezeigt:

        Symbolischer Link verweist auf fehlende Dateien.

        Umgehung: Keine

      • Der Linux-Befehl "rm -rf" schlägt möglicherweise in der Servicekonsole fehl
        Wenn Sie rm -rf in einem Verzeichnis mit mehr als 380 Dateien ausführen, schlägt der Befehl mit folgendem Fehler fehl:

        Verzeichnis nicht leer.

        Dieses Problem wird durch eine Einschränkung des Red Hat 2.6-Kernels verursacht.

        Umgehung: Führen Sie einen dieser Aufgaben aus:

        • Löschen Sie die Verzeichnisse unter Verwendung des vSphere-Client-Datenspeicherbrowsers.
        • Führen Sie rm -rf mehrfach aus, bis alle Einträge gelöscht sind. Bei jedem Aufruf von rm -rf werden höchstens 380 Einträge gelöscht.
      • ESX-Hosts mit einer TLS LDAP-Konfiguration erlauben es LDAP-Benutzern nicht, sich anzumelden
        ESX-Administratoren können in der Servicekonsole neben LDAP unter Verwendung des folgenden Befehls die TLS-Authentifizierung aktivieren:

        esxcfg-auth --enableldap --enableldapauth --enableldaptls --ldapserver=<Server IP/Name> --ldapbasedn="dc=<LDAP DC Name>"

        Nach dem Einschalten der Authentifizierung können Sie sich beim ESX-Host nicht mehr mit einem LDAP-Benutzernamen anmelden. Zudem können Sie den Speicherort der Zertifikatsdatei /etc/openldap/cacerts/client.pemnicht in der Befehlszeile angeben.

        Umgehung: Führen Sie die folgenden Schritte aus:

        1. Öffnen Sie die Datei /etc/ldap.confin einem Editor, fügen Sie Folgendes hinzu und speichern Sie die Datei:

          URI ldaps://linux-ldaptls/
        2. Öffnen Sie die Datei /etc/openldap/ldap.conf in einem Editor, fügen Sie Folgendes hinzu und speichern Sie die Datei:

          URI ldaps://linux-ldaptls/
          TLS_CACERT /etc/openldap/cacerts/client.pem
          BASE dc=ns,dc=suchi,dc=com
      • Einstellung der Core-Dump-Partition des ESX/ESXi-Hosts ist unter bestimmten Bedingungen nicht dauerhaft
        Wenn Sie den Speicherort /root der Core-Dump-Partition ändern und innerhalb einer Stunde nach dieser Änderung, aber bevor der Host neu gestartet wird, der ESX/ESXi-Host ausfällt, wird die Core-Dump-Partition auf ihre ursprüngliche Einstellung /root zurückgesetzt.

        Umgehung: Führen Sie nach dem Ändern der Core-Dump-Partition sofort esxcfg-boot aus.

      • Warnmeldung hinsichtlich "Execute Disable/No Execute CPU feature" an der lokalen Konsole empfangen
        Die Warnmeldung The Execute Disable/No Execute CPU feature is not enabled for this machine erscheint auf der lokalen Konsole, wenn entweder auf einem HP-System mit deaktivierter Option No-Execute Memory Protection im System-BIOS der Maschine oder auf einem Dell-System mit deaktivierter Option Execute Disable im System-BIOS der Maschine ESX 4.0 installiert ist.

        Umgehung: Aktivieren Sie No-Execute Memory Protection bzw. Execute Disable im BIOS der HP- bzw. der Dell-Maschine.

      • Das Beenden oder der Neustart des vCenter Server-Dienstes über das Windows Services Control MMC-Plug-In kann zu einer Fehlermeldung führen
        Unter bestimmten Bedingungen dauert das Starten des vCenter Server-Dienstes möglicherweise länger als gewöhnlich. Das Beenden und der Neustart des vCenter Server-Dienstes über das Windows Services Control MMC-Plug-In kann zur folgenden Fehlermeldung führen:

        Dienst konnte nicht in angemessener Zeit reagieren.

        Diese Meldung bedeutet, dass die für das Herunterfahren oder Starten von vCenter Server erforderliche Zeit den standardmäßig konfigurierten, systemweiten Zeitüberschreitungswert zum Beenden und Starten von Diensten überschritten hat.

        Umgehung: Aktualisieren Sie nach ein paar Minuten den Bildschirm für die Dienstesteuerung. Es sollte nun angezeigt werden, dass der Dienst ordnungsgemäß gestoppt und neu gestartet wurde.

      Netzwerk

      • Durch das Entfernen eines mit einem vDS konfigurierten ESX/ESXi-Hosts von einem vCenter Server-System wird der Netzwerkstatus auf dem Host inkonsistent
        Wenn Sie einen mit einem vDS konfigurierten ESX/ESXi-Host von einem vCenter Server-System entfernen, kann der Host die Verbindung mit dem vDS nicht wieder herstellen. Wenn Sie den Host wieder zum vCenter Server-System hinzufügen, wird eine Warnung ähnlich der Folgenden angezeigt:

        Der verteilte virtuelle Switch, der den Proxy-Switches d5 6e 22 50 dd f2 94 7b-a6 1f b2 c2 e6 aa 0f bf auf dem Host entspricht, ist nicht in vCenter vorhanden oder enthält diesen Host nicht.

        Die virtuellen Maschinen funktionieren nach wie vor auf ihren jeweiligen Ports, aber neue virtuelle Maschinen dürfen nicht eingeschaltet werden. Sie können mithilfe eines mit dem vCenter Server-System verbundenen vSphere-Clients die vDS-Einstellungen für diesen Host ändern.

        Umgehung: Führen Sie die folgenden Schritte aus:

        1. Verwenden Sie zum Herstellen einer direkten Verbindung zum ESX/ESXi-Host einen vSphere-Client. Diese Umgehung erfordert eine Direktverbindung.
        2. Migrieren Sie die virtuellen Maschinen nacheinander von den ungültigen vDS-Ports, indem Sie die Einstellungen der jeweiligen virtuellen Maschine bearbeiten. Dies hat eine länger andauernde Unterbrechung des Netzwerks für die virtuellen Maschinen zur Folge.
        3. Wählen Sie Host > Konfiguration > Netzwerk > Verteilter virtueller Switch und klicken Sie auf Entfernen.
        4. Aktualisieren Sie in einem vSphere-Client, der mit dem vCenter Server-System verbunden ist, die Netzwerkeinstellungen des Hosts. Die Fehler werden gelöscht.
        5. Fügen Sie den Host entweder manuell oder unter Verwendung eines Hostprofils wieder zum vDS hinzu.
        6. Migrieren Sie die virtuellen Maschinen zurück zu ihren jeweiligen Ports oder Portgruppen auf dem vDS. Klicken Sie dazu mit der rechten Maustaste auf den vDS und wählen Sie Netzwerk virtueller Maschinen migrieren. Dies hat auch eine länger andauernde Unterbrechung des Netzwerks für die virtuellen Maschinen zur Folge.
      • VLAN-Tagging funktioniert nicht in SLES10-Gastbetriebssystemen, wenn Oplin-Netzwerkkarten im Passthrough-Modus (FPT) verwendet werden
        Dieses Problem tritt auf, wenn ein Oplin 10GB-Adapter einer virtuellen Maschine zugewiesen wird, die das SUSE Enterprise Linux 10 (SLES10) 32-Bit- oder 64-Bit-Gastbetriebssystem als FPT-Gerät (fixed passthrough) ausführt, und das Gastbetriebssystem zur Durchführung von VLAN-Tagging konfiguriert ist. In einem solchen Fall verschlechtert sich der TCP-Verkehr und ein Aufruf von netperf wird vorzeitig mit einer Fehlermeldung beendet. Der ICMP-Verkehr geht noch durch und Sie können noch pingen.

        Umgehung: Führen Sie tcpdump aus, während der TCP-Verkehr noch aktiv ist. Durch das Ausführen von tcpdump wird die Netzwerkkarte in den Promiscuous-Modus versetzt. Dies stellt sicher, dass der Verkehr ordnungsgemäß fließt. Dabei werden aber sehr viele CPU-Zyklen auf dem Gastbetriebssystem konsumiert.

      • Die gemeinsame Nutzung eines Dual-Funktion-Adapters QLogic 2532 durch eine virtuelle Maschine und eine andere virtuelle Maschine oder den VMkernel bei VMDirectPath Gen I kann zu Datenverlusten führen
        Wenn Sie einen Dual-Funktion-Adapter QLogic 2532 für VMDirectPath IO konfigurieren und die erste PCI-Funktion einer virtuellen Maschine sowie die zweite einem VMkernel oder einer anderen virtuellen Maschine zuweisen, kann dies zu Datenverlust führen. Dies liegt daran, dass beide Ports die gleichen Daten zum Anmelden bei Fabric verwenden und über die gleichen Speichersichtbarkeit verfügen. VMware unterstützt diese Konfiguration für VMDirectPath IO nicht.

        Umgehung: Wenn der Dual-Funktion-Adapter von einer virtuellen Maschine und dem VMkernel gemeinsam genutzt werden muss, weisen Sie die erste PCI-Funktion der virtuellen Maschine und die zweite dem VMkernel zu. Die PCI-Funktionen können nicht zwischen zwei virtuellen Maschinen aufgeteilt werden.

      • Der ESX-Host wird getrennt, falls Sie die sekundäre Servicekonsole entfernen, wenn sich beide vSwitches in demselben Subnetz befinden
        Der Host wird mit einer Fehlermeldung getrennt, wenn Sie die folgenden Schritte durchführen:
        1. Eine sekundäre Servicekonsole hinzufügen
        2. Das Gateway-Gerät der Servicekonsole ändern
        3. Das Gateway-Gerät auf die primäre Servicekonsole zurücksetzen
        4. Die sekundäre Servicekonsole entfernen

        Umgehung: Keine

      • Verbindungsstatusprobleme mit Neterion-Netzwerkkarten treten möglicherweise bei Foundry Edgeiron 8X10G-Switches auf
        Wenn auf einem Foundry Edgeiron 8X10G-Switch ein aktiver Port über einen längeren Zeitraum wiederholt aktiviert und deaktiviert wird, führt dies möglicherweise dazu, dass der Port permanent in den Status Link deaktiviert versetzt wird.

        Umgehung: Starten Sie den Switch neu oder verwenden Sie einen anderen Switch-Port.

      • NetXen-Chipset bietet keine Hardwareunterstützung für VLANs
        Die NetXen-Netzwerkkarte zeigt keine Hardwareunterstützung für VMNET_CAP_HW_TX_VLAN und VMNET_CAP_HW_RX_VLAN an. Dies liegt daran, dass der NetXen-Chipset keine Hardwareunterstützung für VLANs bietet. NetXen-VLAN-Unterstützung ist auf Softwarebasis verfügbar.
      • Bei der benutzerdefinierten Erstellung einer virtuellen Maschine können maximal vier Netzwerkkarten hinzugefügt werden
        Während der Erstellung einer virtuellen Maschine mit der Option "Benutzerdefiniert" zeigt der vSphere-Client den Konfigurationsbildschirm "Netzwerk" an. Auf diesem Bildschirm werden Sie aufgefordert, die Anzahl an Netzwerkkarten anzugeben, die verbunden werden sollen. Im Dropdown-Menü können maximal vier Netzwerkkarten ausgewählt werden. Mit ESX/ESXi 4.0 Update 1 werden jedoch 10 Netzwerkkarten unterstützt.

        Umgehung: Sie können weitere Netzwerkkarten hinzufügen, indem Sie den folgenden Vorgang ausführen.
      1.  
        1. Navigieren Sie mithilfe des vSphere-Clients zu Home> Bestandsliste> VMs und Vorlagen.
        2. Klicken Sie bei ausgewählter Registerkarte "Erste Schritte" auf "VM-Einstellungen bearbeiten".
        3. Klicken Sie auf "Hinzufügen".
        4. Wählen Sie "Ethernet-Adapter" und klicken Sie auf "Weiter".
        5. Fahren Sie mit der Auswahl der geeigneten Einstellungen für Ihr Szenario fort.
      • Adressen können dem ESX-Servicekonsolenport nach einem Neustart nicht zugewiesen werden
        Wenn bei einem Servicekonsolenport weder statische IPv4/IPv6-Adressen konfiguriert noch automatische Konfigurationsmethoden (DHCP, DHCP6 oder AUTOCONF) aktiviert sind, befindet sich der Port nach einem Neustart in einem ungültigen Zustand und Sie können dieser Schnittstelle keine Adressen zuweisen.

        Umgehung: Konfigurieren Sie eine statische IP-Adresse (IPv4 oder IPv6) oder richten Sie einen Servicekonsolenport für die Verwendung der automatischen Adressgenerierungsmethode (z. B. DHCP, DHCP6 oder AUTOCONF) vor dem Neustart ein. Sie können auch nach einem Neustart den Servicekonsolenport neu erstellen.

      • Die VmwVmNetNum des VM-INFO MIB wird als Ethernet0 angezeigt, wenn "snmpwalk" ausgeführt wird
        Wenn "snmpwalk" für VM-INFO MIB auf einem ESX/ESXi-Host ausgeführt wird, wird die VmwVmNetNum des VM-INFO MIB als Ethernet0 statt Netzwerkadapter1 angezeigt, während die MOB-URL in der Beschreibung für VmwVmNetNum des VM-INFO als Netzwerkadapter1 angezeigt wird.

        Umgehung: Keine

      • Anwendungen, die VMCI-Sockets verwenden, schlagen nach der VM-Migration möglicherweise fehl
        Wenn Sie Anwendungen haben, die VMCI-Sockets (Virtual Machine Communication Interface) verwenden, schlagen die Anwendungen nach einer VM-Migration möglicherweise fehl, wenn die von der Anwendung verwendeten VMCI-Kontextbezeichner bereits auf dem Zielhost verwendet werden. In diesem Fall funktionieren die auf dem ursprünglichen Host erstellten VMCI-Stream- oder Datagram-Sockets nicht mehr ordnungsgemäß. Zudem wird es unmöglich, neue Stream-Sockets zu erstellen.

        Umgehung: Laden Sie bei Windows-Gastbetriebssystemen den Gast-VMCI-Treiber neu, indem Sie das Gastbetriebssystem neu starten oder das Gerät über den Gerätemanager aktivieren. Beenden Sie bei Linux-Gastbetriebssystemen alle Anwendungen, die VMCI-Sockets verwenden, entfernen und laden Sie das vsock-Kernelmodul neu und starten Sie die Anwendungen erneut.

      • Das Anwenden von Portgruppen mit mehreren statisch zugewiesenen VMKNICs oder VSWIFs führt zu wiederholten Aufforderungen zur Angabe einer IP-Adresse
        Das Anwenden einer vDS-Portgruppe mit mehreren statisch zugewiesenen VMKNICs oder VSWIFs führt dazu, dass der Benutzer wiederholt zur Angabe einer IP-Adresse aufgefordert wird. Über DHCP zugewiesene Schnittstellen sind davon nicht betroffen.

        Umgehung: Verwenden Sie nur eine statisch zugewiesene VMKNIC oder VSWIF pro Portgruppe. Wenn auf derselben vDS-Portgruppe mehrere statisch zugewiesene VMKNICs gewünscht werden, weisen Sie jede VMKNIC oder VSWIF einer eindeutigen Gruppe von Diensten (z. B. vMotion, Fehlertoleranz und anderen Diensten) zu.

      • Die Konsole für das Gastbetriebssystem fällt aus und Sie können über die Konsole nicht auf das Gastbetriebssystem zugreifen, wenn Sie für einen verteilten vNetwork-Switch oder einen vSwitch, der über die Servicekonsolen- oder die Verwaltungsnetzwerk-Portgruppe verfügt, den MTU-Wert auf weniger als 1500 festlegen
        Wenn Sie für den verteilten vNetwork-Switch oder den vSwitch, der die Servicekonsolen-Portgruppe für ESX oder die Verwaltungsnetzwerk-Portgruppe für ESXi Embedded enthält, den MTU-Wert auf weniger als 1500 festlegen, fällt die Konsole für das Gastbetriebssystem aus und Sie können über die Konsole nicht auf das Gastbetriebssystem zugreifen. Die Servicekonsolen-Portgruppe für ESX und die Verwaltungsnetzwerk-Portgruppe für ESXi Embedded müssen mit einem vSwitch oder einem verteilten vNetwork-Switch verbunden sein, dessen MTU-Einstellung 1500 oder höher ist.

        Umgehung: Legen Sie die für den verteilten vNetwork-Switch oder den vSwitch, der die Servicekonsolen-Portgruppe für ESX oder die Verwaltungsnetzwerk-Portgruppe für ESXi Embedded enthält, den MTU-Wert nicht auf weniger als 1500 fest.

      • Das Abrufen von DNS- und Hostnamensinformationen vom DHCP-Server kann verzögert oder verhindert werden
      •  Bei einem Upgrade von ESX 3.5-Hosts auf ESX 4.0 laden einige der Netzwerkgeräte den Treiber e1000e anstelle des Treibers e1000
        Wenn für Hosts vom Typ ESX 3.5 Update 4 oder ESX 3.5 Update 5 ein Upgrade auf ESX 4.0 oder höher durchgeführt wird, wird bei den folgenden Netzwerkgeräten der Treiber e1000e anstelle des Treibers e1000 geladen:
        • Intel 82571EB Gigabit Ethernet Controller (einschließlich 105e, 105f, 1060, 10a4, 10a5, 10bc)
        • Intel 82572EI Gigabit Ethernet Controller (einschließlich 107d, 107e, 107f, 10b9)
        • Intel 82573V Gigabit Ethernet Controller (einschließlich 108b)
        • Intel 82573E Gigabit Ethernet Controller (einschließlich 108c)
        • Intel 80003ES2LAN Gigabit Ethernet Controller (einschließlich 1096, 1098, 10ba, 10bb)
        • Intel 82573L Gigabit Ethernet Controller (einschließlich 109a)
      • Das Ändern der Netzwerkeinstellungen eines ESX/ESXi-Hosts verhindert, dass manche Software zur Überwachung des Hardwarestatus den Host automatisch erkennen kann
        Nach dem Ändern der Netzwerkeinstellungen eines ESX/ESXi-Hosts sind die Drittanbieter-Management-Tools, die auf der CIM-Schnittstelle basieren (in der Regel die Hardwarestatus-Überwachungs-Tools), nicht in der Lage, anhand des Service Location Protocol-Dienstes (SLP) den Host automatisch zu erkennen.
        Umgehung: Geben Sie den Hostnamen oder die IP-Adresse des Hosts manuell in das Drittanbieter-Management-Tool ein. Alternativ können Sie slpdund sfcbd-watchdogneu starten, indem Sie die entsprechende Methode verwenden:
        Auf ESXi:
        1. Aktivieren Sie den Technical Support-Modus.
        2. Starten Sie slpdneu, indem Sie den Befehl /etc/init.d/slpd restartausführen.
        3. Starten Sie sfcbd-watchdogneu, indem Sie den Befehl /etc/init.d/sfcbd-watchdog restartausführen.

        Starten Sie die Verwaltungsagenten im Direct Console User Interface (DCUI) neu. Dadurch werden zusätzlich zu den Agenten, die von diesem Defekt betroffen sind, weitere Agenten auf dem Host neu gestartet, was sich noch störender auswirken kann.
        Auf ESX: Führen Sie in der ESX-Servicekonsole die folgenden Befehle aus:
        /etc/init.d/slpd restart
        /etc/init.d/sfcbd-watchdog restart

      • Virtuelle Maschinen verlieren die Netzwerkkonnektivität, wenn sie auf einen ESX-Host mit der Standardanzahl von Ports migriert werden
        Standardmäßig wird die ESX-Servicekonsole mit einem virtuellen Switch mit nur 24 Ports installiert. Wenn virtuelle Maschinen auf einen Host migriert werden und die Anzahl der erforderlichen Ports die Standardanzahl übersteigt, verlieren manche virtuellen Maschinen möglicherweise die Netzwerkkonnektivität. Dieses Problem kann auftreten, wenn virtuelle Maschinen manuell migriert werden oder bei Notfallwiederherstellungsszenarien und Migrationen mit vMotion.

        Umgehung: Nach dem Installieren ändern Sie vSwitch0, sodass er eine große Anzahl von Ports hat, indem Sie die Switch-Eigenschaften bearbeiten. ESX 4.0 und höher unterstützen bis zu 56 Ports auf einem virtuellen Switch.

      Serverkonfiguration

      • Hostprofile erfassen und duplizieren keine Duplexinformationen von physischen Netzwerkkarten
        Wenn Sie ein neues Hostprofil erstellen, werden die Duplexinformationen der physischen Netzwerkkarte nicht erfasst. Dies ist das beabsichtigte Verhalten. Wenn daher das Profil des Referenzhosts verwendet wird, um andere Hosts zu konfigurieren, wird die Duplexkonfiguration pro physischer Netzwerkkarte ausgehandelt. Somit können Sie Hosts mit einer Vielzahl von Funktionen der physischen Netzwerkkarte generisch behandeln.

        Umgehung: Ändern Sie das Hostprofil, nachdem es erstellt wurde, und wenden Sie die Parameter neu an, um einheitlich über alle Netzwerkkarten und Hosts hinweg, die unter Verwendung des Referenz-Hostprofils konfiguriert werden sollen, den Duplexwert der physischen Netzwerkkarte festzulegen.

        Führen Sie zum Bearbeiten des Profils die folgenden Schritte aus.

        1. Klicken Sie auf der Startseite des vSphere-Clients auf Hostprofile.
        2. Wählen Sie das Hostprofil aus der Bestandsliste aus, klicken Sie auf die Registerkarte "Übersicht" und klicken Sie anschließend auf Profil bearbeiten.
        3. Wählen Sie Netzwerkkonfiguration > Konfiguration der physischen Netzwerkkarte > Bearbeiten.
        4. Wählen Sie im Dropdown-Menü "Feste Konfiguration der physischen Netzwerkkarte" aus und geben Sie die Geschwindigkeit und die Duplexinformationen ein.
      • Unter ESX tritt kein Fehler auf, wenn die SNMP-Agenten "net-snmp" und "hostd" so konfiguriert werden, dass sie beide auf demselben Port ausgeführt werden
        Wenn Sie den VMware SNMP-Daemon (hostd) demselben UDP-Port wie den SNMP-Daemon (snmpd) zuweisen, tritt kein Fehler auf, aber beim späteren Zugriff auf die SNMP-Funktionalität treten die folgenden Symptome auf:
        • Wenn "net-snmp" zuerst UDP/161 öffnet und versucht, "snmpwalk" für VMware Enterprise-MIB-Objekte unter enterprise.6876 auszuführen, geben GET-Anforderungen "noSuchErro" zurück und GETNEXT gibt den Wert nicht zurück.
        • Wenn UDP/161 zuerst von "hostd" geöffnet wird, stehen Verwaltungsobjekte von Drittanbietern und "net-snmp" nicht zur Verfügung.
        • Falls keiner der beiden Agenten UDP/161 öffnen kann, tritt eine Zeitüberschreitung ein.

        Umgehung: Führen Sie die folgenden Aufgaben in der angegebenen Reihenfolge aus.

        1. Stoppen Sie den Servicekonsolen-SNMP-Daemon (snmpd) mit diesem Befehl: service snmpd stop
        2. Starten Sie den VMware-SNMP-Daemon (hostd) mit diesem Befehl neu: service mgmt-vmware restart
      • Der Systemstatus der ESX/ESXi-Host-Serverkomponenten erscheint nicht auf der Registerkarte "Hardwarestatus"
        Wenn Sie die Nummer des HTTPS-Ports in der SFCB-Konfigurationsdatei ( sfcb.cfg) auf einen Port ändern, der nicht der Standardport ist, und den SFCB-Server (CIM) neu starten, erscheint der Systemstatus der Serverkomponenten des ESX/ESXi-Hosts nicht auf der Registerkarte "Hardwarestatus". Dieses Verhalten kommt zum Vorschein, wenn Sie sich direkt an einem ESX/ESXi-Host anmelden und auf die Registerkarte Konfiguration klicken, um den Systemstatus anzuzeigen. Statusinformationen für die Serverkomponenten erscheinen nicht. Dieses Problem tritt auf, weil vCenter Server und der SFCB-Server über verschieden Ports kommunizieren.

        Umgehung: Stellen Sie sicher, dass der SFCB-Server nur über den Standardport kommuniziert.

      • SNMP-PowerOn-Traps werden während eines Neustarts von "vmware_hostd" generiert
        Wenn Sie " vmware_hostd" neu starten, sollte standardmäßig nur die "Warm Start"-Trapmeldung generiert werden. Für alle auf Ihrem Host ausgeführten virtuellen Maschinen werden jedoch auch die PowerOn-Trapmeldungen generiert.

        Umgehung: Sie können die PowerOn-Trapmeldungen ignorieren.

      • ESX/ESXi schlägt möglicherweise beim Erkennen des zweiten Ports auf bestimmten IBM-Servern mit Dual-Port-FC-HBAs fehl
        Wenn Sie IBM x3650-Server mit Dual-Port-FC-HBAs verwenden, kann ESX/ESXi möglicherweise den zweiten Port nicht erkennen. Dieses Problem tritt möglicherweise auch auf anderen IBM-Servern mit derselben BIOS-Version auf.

        Umgehung: Führen Sie je nach Typ des von Ihrem Server verwendeten Adapters einen der folgenden Schritte aus:

        • Aktualisieren Sie für QLogic HBAs das IBM BIOS auf die neueste Version (Version 1.2).
        • Es gibt folgende Lösungen für Emulex HBAs:
          • Wenn Sie ESX von einer SAN aus starten, deaktivieren Sie die lokale Festplatte im BIOS des IBM-Servers.
          • Wenn Sie ESX von einer lokalen Festplatte oder ESXi starten, deaktivieren Sie BootBIOS für beide Ports auf dem Emulex HBA.

      Speicher

      • Auf ESX 4.0 und höher dauert es sehr lange, bis der Befehl "sg_inq" ausgeführt wird (KB 1029157)
      • Das Kopieren von großen Dateien von der ESX-Servicekonsole auf eine CIFS-gemountete Windows-Festplatte führt möglicherweise dazu, dass die Datei beschädigt wird
        Das Kopieren von großen Dateien von der ESX-Servicekonsole auf eine Windows-Festplatte, die unter Verwendung von CIFS gemountet wurde, führt möglicherweise dazu, dass die Datei beschädigt wird.

        Umgehung: Verwenden Sie beim Mounten von Windows-Festplatten in der Servicekonsole unter Verwendung von CIFS die Option forcedirection.

      • Während der ESX-Installation wird die ganze, für einen Datenspeicher ausgewählte physische Festplatte automatisch mit VMFS formatiert
        Sie können die Größe eines VMFS-Datenspeichers nicht ändern, auch dann nicht, wenn Sie während der Installation die erweiterte Partitionierung auswählen. Standardmäßig stellt das Installationsprogramm VMFS auf der ganzen physischen Festplatte bereit, die Sie für den Datenspeicher auswählen.

        Umgehung: Verwenden Sie eine Skriptinstallation, um Ihrem VMFS-Datenspeicher die erforderliche Größe zuzuweisen.

      • Die Eingabe von zusätzlichen statischen Erkennungszielen für Hardware-iSCSI schlägt möglicherweise fehl
        Der Versuch, beim Konfigurieren Ihres Hardware-iSCSI-Adapters zusätzliche statische Erkennungsziele einzugeben, schlägt möglicherweise fehl. Dies geschieht, wenn ein neues Ziel denselben iSCSI-Namen als das vorhandene Ziel aufweist, auch wenn sich ihre IP-Adressen unterscheiden.

        Umgehung: Verwenden Sie beim Konfigurieren von Hardware-iSCSI Statische Erkennungsziele mit verschieden iSCSI-Namen.

      • Der Pfadstatus für das CLARiiON iSCSI-Speichersystem ändert sich von "Ausgefallen" in "Aktiv" bzw. von "Aktiv" in "Ausgefallen", wenn mit dem Software-iSCSI-Initiator von ESX/ESXi auf das System zugegriffen wird
        Wenn Sie zum Zugreifen auf das CLARiiON iSCSI-Speichersystem den Software-iSCSI-Initiator verwenden, ändert sich der Pfadstatus häufig von "Ausgefallen" in "Aktiv" bzw. von "Aktiv" in "Ausgefallen". Dies liegt daran, dass CLARiiON den erweiterten Parameter "Verzögerte Quittierung (ACK)" nicht unterstützt, der standardmäßig auf Ihrem ESX/ESXi-Host aktiviert ist.

        Umgehung: Deaktivieren Sie auf Ihrem ESX/ESXi-Host den Parameter "Verzögerte Quittierung (ACK)", indem Sie die folgenden Schritte ausführen:

        1. Melden Sie sich am vSphere-Client an, und klicken Sie im Bestandslistenfenster auf den Host.
        2. Klicken Sie auf die Registerkarte Konfiguration und anschließend auf Speicheradapter.
        3. Wählen Sie den zu konfigurierenden Software-iSCSI-Initiator aus und klicken Sie auf Eigenschaften.
        4. Klicken Sie auf der Registerkarte "Allgemein" auf Erweitert.
        5. Heben Sie die Auswahl von Verzögerte Quittierung (ACK) auf.
      • Wenn Sie die PSP_RR-Pfadauswahlrichtlinie mit Failover-Clustering verwenden, treten Probleme bei gemeinsam genutzten Festplatten auf und der Cluster funktioniert möglicherweise nicht
        Das Failover-Clustering führt SCSI-3-Reservierungen auf gemeinsam genutzten Festplatten durch. Das Senden einer SCSI-3-Reservierung entlang eines Pfads erlaubt es dem Cluster, SCSI-3-Reservierungen nur auf diesem Pfad vorzunehmen. Wenn später PSP_RR auf einen anderen Pfad wechselt, kann das Failover-Clustering möglicherweise keine Reservierung vornehmen oder andere SCSI-3-Befehle verwenden, die von der Reservierung abhängen.

        Umgehung: Stellen Sie Geräte, die für gemeinsam genutzte Festplatten verwendet werden, nicht auf PSP_RR um. Verwenden Sie stattdessen je nach Standardwert für das Array die PSP_MRU- oder PSP_FIXED-Richtlinien.

      • Das Hinzufügen eines QLogic iSCSI-Adapters zu einem ESX/ESXi-System schlägt fehl, wenn ein vorhandenes Ziel mit demselben Namen, aber mit einer anderen IP-Adresse, vorhanden ist
        Das Hinzufügen eines statischen Ziels für einen QLogic Hardware-iSCSI-Adapter schlägt fehl, wenn ein Ziel mit demselben iSCSI-Namen bereits vorhanden ist, auch dann, wenn sich die IP-Adressen unterscheiden.

        Sie können einen Qlogic iSCSI-Adapter auf einem ESX/ESXi-System nur mit einem eindeutigen iSCSI-Namen für ein Ziel installieren, jedoch nicht mit einer Kombination aus IP und iSCSI-Namen. Zudem unterstützen der Treiber und die Firmware mehrere Sitzungen, die auf denselben Endpunkt zugreifen.

        Umgehung: Keine. Verwenden Sie nicht denselben iSCSI-Namen, wenn Sie Ziele hinzufügen.

      • Nach Eingabe des Servicekonsolenbefehls "fdisk" unter Angabe des absoluten Pfads der Festplatte erscheint eine Fehlermeldung
        Wenn Sie den Servicekonsolenbefehl fdisk ausführen und dabei den absoluten Pfad der Festplatte angeben (z. B. fdisk -l /vmfs/devices/disks/naa.600a0b80002a071c0000834248ca0b4f), wird folgende Fehlermeldung angezeigt:

        last_lba(): I don't know how to handle files with mode 8180

        Umgehung: Sie können diese Fehlermeldung ignorieren oder den folgenden Befehl ausführen:

        fdisk -l /dev/sdh

      • Das Starten von einer iSCSI-LUN ist möglicherweise zu langsam oder der Startvorgang schlägt fehl
        Falls iSCSI-Konfigurationsdaten vorhanden sind, bevor Sie beginnen, ein iSCSI-Startgerät über das QLogic-BIOS zu konfigurieren, können Sie doppelte iSCSI-Sitzungen für dasselbe Ziel erstellen. Wenn dies geschieht, sind E/A-Vorgänge möglicherweise sehr langsam oder sie schlagen fehl.

        Umgehung: Führen Sie die folgenden Schritte aus:

        1. Wählen Sie im BIOS zum Entfernen vorhandener iSCSI-Konfigurationsdaten die Option Dauerhafte Ziele löschen.
        2. Fügen Sie iSCSI-Startkonfigurationsdaten hinzu.
      • Die ESX-Servicekonsole erkennt keine Änderungen an, die zur Laufzeit an der LUN-Größe vorgenommen werden
        Wenn Änderungen an der Größe der LUN vorgenommen werden, die Ihrem ESX-Host zur Verfügung steht, wird die neue Größe vom VMkernel so erkannt, dass VMFS und virtuelle Maschinen die neue Größe verwenden können. Die Servicekonsole zeigt jedoch die alte Größe noch so lange an, bis Sie den Host neu gestartet haben. Dies liegt daran, dass die Servicekonsole die Gerätekapazität nur beim anfänglichen Gerätetest abruft.

        Umgehung: Starten Sie den ESX 3-Host neu. Falls Sie nicht neu starten möchten, führen Sie die folgenden Schritte aus:

        1. Stellen Sie sicher, dass die LUN nicht vom Host verwendet wird.
        2. Maskieren Sie die LUN vom Host aus.
        3. Prüfen Sie vom vSphere-Client aus den Speicheradapter erneut, den der Host zum Zugreifen auf die LUN verwendet.
        4. Heben Sie die Maskierung der LUN auf und sorgen Sie dafür, dass der Host auf sie zugreifen kann.
        5. Führen Sie eine erneute Prüfung des Speicheradapters durch.

        Jetzt zeigt die Servicekonsole die richtige LUN-Größe an.

      • Das Ändern des iSCSI-Parameters "Maximum Outstanding R2" auf Ihrem ESX/ESXi-Host in einen Wert größer als eins führt möglicherweise dazu, dass das Speichersystem der EMC CX3-Serie nicht ordnungsgemäß funktioniert
        Wenn Sie auf Ihrem ESX/ESXi-Host den Standardwert des iSCSI-Parameters "Maximum Outstanding R2" in einen Wert größer als eins ändern, funktioniert das Speichersystem der EMC CX3-Serie möglicherweise nicht richtig.

        Umgehung: Ändern Sie den Standardwert (1) für den Parameter "Maximal ausstehendes R2T" nicht.

      • ESX wird manchmal von einem Clariion-iSCSI-Speichersystem nicht gestartet
        Wenn Sie von iSCSI starten, startet Ihr ESX-Host möglicherweise nicht, wenn das Clariion-Speichersystem verwendet wird. Dies liegt daran, dass der QLogic Adapter SP versucht, von dem Standby-SP auf dem Clariion-Speicher zu starten, und den aktiven SP nicht korrekt erkennt.

        Umgehung: Stellen Sie sicher, dass die primären und die alternativem Start-LUNs im QLogic-BIOS auf unterschiedliche SPs auf dem Clariion-Speicher eingestellt sind. Falls dieses Problem weiterhin auftritt, ändern Sie die Reihenfolge der Start-LUNs.

      •   Die Portbindung kann in Zusammenhang mit IPv6-Ports nicht durchgeführt werden
        Die Portbindung ist ein Mechanismus zum Identifizieren von bestimmten VMkernel-Ports für die Verwendung durch den iSCSI-Speicherstack. Die Portbindung ermöglicht das Anwenden von Speicher-Multipathing-Richtlinien, wie z. B. VMware Round-Robin-Lastausgleich, MRU oder "fixed-path", auf iSCSI-Netzwerkkarten-Ports und Pfaden. Die Portbindung funktioniert nicht in Kombination mit IPv6. Wenn Benutzer die Portbindung konfigurieren, erwarten sie, dass sie zusätzliche Pfade für jede gebundene VMkernel-Netzwerkkarte sehen. Wenn Sie jedoch das Array unter einer globalen IPv6- Adresse konfigurieren, werden die zusätzlichen Pfade nicht eingerichtet. Benutzer sehen nur die Pfade, die auf einer IPv6-routbaren VMkernel-Netzwerkkarte eingerichtet wurden. Haben Benutzer beispielsweise zwei Zielportale und zwei VMkernel-Netzwerkkarten, so sehen sie bei Verwendung von IPv4 vier Pfade, aber nur zwei Pfade, wenn sie IPv6 verwenden. Weil es keine Pfade für Failover gibt, ist es nicht sinnvoll, eine Pfadrichtlinie einzurichten.

        Umgehung: Verwenden Sie IPv4 und die Portbindung, oder konfigurieren Sie das Speicher-Array und den ESX/ESXi-Host mit IPv6-Adressen des Typs "LOCAL SCOPE" auf demselben Subnetz (Switch-Segment). Zurzeit können Sie keine globale IPv6-Adressen zusammen mit der Portbindung verwenden.

      • Der ESX/ESXi-Host registriert keine Pfade, die von der Speicher-Manager-Anwendung hinzugefügt wurden
        Wenn Sie mithilfe der Speicher-Manager-Anwendung einen neuen Port zum Speichersystem hinzufügen, zeigt Ihr ESX/ESXi-Host keinen neuen Pfad zum Speichersystem an.

        Umgehung: Führen Sie die folgenden Schritte aus:

        1. Stellen Sie sicher, dass der ESX/ESXi-Host auf den Port zugreifen kann.
        2. Entfernen Sie die physische Verbindung für den neu hinzugefügten Port.
        3. Warten Sie, bis der Zeitgeber abläuft.
        4. Stellen Sie die physische Verbindung wieder her.
      • Das Anfordern des Pfads für ein Gerät kann nicht aufgehoben werden, wenn Sie die "autoclaiming"-Option deaktiviert haben
        Sie können das Anfordern eines Pfads für ein Gerät nicht aufheben, nachdem Sie die "autoclaiming"-Option auf Aus/Deaktiviert gesetzt haben.

        Umgehung: Die "autoclaiming"-Option wird in ESX/ESXi 4.0 nicht unterstützt.

      • In seltenen Fällen schlagen Vorgänge, die sich mit VMFS-Änderungen befassen, nach wiederholten SAN-Pfad-Failovern möglicherweise für alle ESX/ESXi-Hosts, die auf eine bestimmte LUN zugreifen, fehl.
        In seltenen Fällen schlagen nach wiederholten Pfad-Failovern auf eine bestimmte SAN-LUN möglicherweise Versuche fehl, auf allen ESX/ESXi-Hosts, die auf diese LUN zugreifen, Vorgänge durchzuführen, wie z. B. das Erstellen eines VMFS-Datenspeichers, vMotion usw. Folgende Warnungen erscheinen in den Protokolldateien aller betroffenen Hosts:
        • I/O failed due to too many reservation conflicts.
        • Reservation error: SCSI reservation conflict

        Falls Sie die Reservierungskonfliktmeldungen auf allen Hosts sehen, die auf die LUN zugreifen, bedeutet dies, dass das Problem durch die SCSI-Reservierungen für die LUN, die nicht vollständig aufgeräumt wurde, verursacht wird.

        Umgehung: Führen Sie von einem beliebigen System im Cluster aus den folgenden Befehl zum Zurücksetzen der LUN aus, um die SCSI-Reservierung zu entfernen:

        vmkfstools -L lunreset /vmfs/devices/disks/

      • vCenter Server kann die RDM nicht öffnen, nachdem die LUN des RDM geändert wurde
        VMware unterstützt keine LUN-Nummer-Änderungen (Positionsänderungen) innerhalb des Ziels. Wenn die LUN-Nummer geändert wird, kann vCenter Server die RDM, die auf der LUN basiert, nicht öffnen. Eine RDM-Datei (Raw Device Mapping) befindet sich auf dem VMFS-Datenspeicher und verweist auf eine LUN. Die LUN-Nummer zeigt die Position der LUN innerhalb des Ziels. Wenn sich diese Nummer (oder Position) ändert, ändert sich auch der vml-Bezeichner (vml_ID) für die RDM-Datei. Sie können beispielsweise VMFS-Datenspeicher nicht trennen und sie anschließend in einer anderen Reihenfolge neu verbinden. Dies ändert die Identifikation der LUN, sodass auf sie nicht mehr zugegriffen werden kann und vCenter Server verhindert, dass die virtuelle Maschine eingeschaltet wird. vSphere Client verwendet die vml_ID aus Gründen der Abwärtskompatibilität.

        Umgehung: Entfernen Sie die RDM und erstellen Sie sie neu. Eine neue vml_ID wird generiert, die die LUN erkennen kann.

      • vSphere-Client zeigt Laufwerksfehleralarme an, wenn auf ESX- und ESXi-Hosts mit IBM-Mehrknotensystemen das Laufwerk nicht vorhanden ist
        Auf manchen IBM-Mehrknotensystemen meldet die BMC-Firmware einen Laufwerksfehler für Laufwerkssteckplätze, wenn kein Laufwerk vorhanden ist. Der vSphere-Client meldet, dass der Laufwerksfehlersensor den Status "Alarm" hat. Die identischen Fehler werden in der IBM iLOM-Schnittstelle angezeigt.

        Umgehung: Keine. Ein Fehlerbericht wurde an IBM geschickt, um dieses Problem zu beschreiben.

      • NAS-Datenspeicher geben den verfügbaren Speicherplatz falsch wieder
        Wenn Sie den verfügbaren Speicherplatz für einen ESX/ESXi-Host mithilfe des Befehls df (ESXi) oder vdf (ESX) in der Host-Servicekonsole anzeigen lassen, handelt es sich bei dem gemeldeten Speicherplatz für ESX/ESXi-NAS-Datenspeicher um freien Speicherplatz und nicht um verfügbaren Speicherplatz. Der Speicherplatz von NFS-Volumes, der in der Spalte "Frei" angegeben wird, wenn Sie Speicher > Datenspeicher auf der Registerkarte Konfiguration des vSphere-Clients wählen, zeigt auch den freien Speicherplatz an, nicht den verfügbaren Speicherplatz. In beiden Fällen kann sich der freie von dem verfügbaren Speicherplatz unterscheiden.

        ESX-Dateisysteme unterscheiden nicht zwischen freien und verfügbaren Blöcken, sondern melden immer freie Blöcke für beide Blocktypen (genau genommen die Felder "f_bfree" und "f_bavail" der struct "statfs"). Freie und verfügbare Blöcke können sich bei NFS-Volumen unterscheiden.

        Umgehung: Sie können korrekte Informationen hinsichtlich des verfügbaren Speicherplatzes von NFS-Servern abrufen. Für ESX/ESXi gibt es keine Umgehung.

      • Harmlose Warnmeldungen zu Bereichskonflikten werden in den VMkernel-Protokollen für manche IBM-Server protokolliert
        Wenn der SATA/IDE-Controller im PCI-Konfigurationsbereich im Legacy-PCI-Modus arbeitet, wird möglicherweise eine Fehlermeldung ähnlich der Folgenden zu den VMkernel-Protokollen hinzugefügt:

        WARNING: vmklinux26: __request_region: Diese Meldung wurde einmal wiederholt: Region conflict @ 0x0 => 0x3

        Umgehung: Solche Fehlermeldungen sind harmlos und können bedenkenlos ignoriert werden.
      • Das Gewähren von Berechtigungen zum Ändern eines Datenspeichers ermöglicht Benutzern, systemverwandte Dateien zu ändern
        Durch das Gewähren aller Berechtigungen zum Ändern von Datenspeichern wird es Benutzern ermöglicht, die Systemdateien auf dem lokalen ESX-Datenspeicher zu ändern, einschließlich der Servicekonsolen-VMDK-Datei ( esxconsole.vmdk). Diese Datei befindet sich im Ordner /esxconsole-in einem Datenspeicher. Falls ein Benutzer den Ordner esxconsole oder die VMDK-Datei umbenennt, kann der ESX-Host nicht neu starten.

        Umgehung: Sorgen Sie dafür, dass nur Administratoren Datenspeicher ändern dürfen. Stellen Sie sicher, dass sich diejenigen Benutzer, die berechtigt sind, Datenspeicher zu ändern, über die Probleme, die auftreten können, wenn der Ordner esxconsole oder die Datei esxconsole.VMDK umbenannt wird, im Klaren sind.

      • Das Verwenden von Storage vMotion zum Verlagern einer virtuellen Maschine zurück in deren Quellvolume führt möglicherweise zu einem Fehler des Typs "Unzureichender Festplattenspeicher"
        Wenn Sie Storage vMotion zum Verschieben einer virtuellen Maschine in einen anderen Datenspeicher und anschließend zurück in deren Quellvolume verwenden, aktualisiert der vSphere-Client die Größe des Quelldatenspeichers nicht sofort, was zu einem Fehler führt.

        Umgehung: Aktualisieren Sie den Datenspeicher im vSphere-Client. Falls sich nach dem ersten Versuch die gemeldete Größe des Datenspeichers nicht ändert, warten Sie 30 Minuten und versuchen Sie es erneut.

      • Das Dienstprogramm "vmfs-undelete" steht ESX/ESXi 4.0 nicht zur Verfügung
        Bei ESX/ESXi 3.5 Update 4 wurde ein Dienstprogramm namens "vmfs-undelete" mitgeliefert, das zum Wiederherstellen von gelöschten .vmdk-Dateien verwendet wurde, sofern sie nicht auf Blockebene überschrieben wurden. Dieses Dienstprogramm steht ESX/ESXi 4.0 nicht zur Verfügung.

        Umgehung: Keine. Gelöschte .vmdk-Dateien können nicht wiederhergestellt werden.

      • Wenn der Speicherprozessor eines HP MSA2012fc-Speicher-Arrays zurückgesetzt wird, werden fälschlicherweise kritische Warnungen ausgegeben
        Beim Zurücksetzen des Speicherprozessors des HP MSA2012fc-Speicher-Arrays sendet das ESX/ESXi NMP-Modul (Native Multipathing) Warnungen oder kritische Einträge an die VMkernel-Protokolle. Diese Warnmeldungen geben an, dass das physische Medium für das Gerät geändert wurde. Diese Meldungen treffen jedoch nicht für alle LUN-Typen zu. Sie sind nur kritisch für Daten-LUNs, gelten jedoch nicht für Verwaltungs-LUNs.

        Umgehung: Das Problem kann nicht umgangen werden. In diesem Szenario können Sie beruhigt die protokollierten Warnungen ignorieren, sofern sie sich auf Verwaltungs-LUNs beziehen.
      • Eine virtuelle Maschine kann beim Zurücksetzen der SCSI-LUNs eine Endlosschleife verursachen, die das Herunterfahren der virtuellen Maschine verhindert
        Wenn SCSI-Treiber (entweder BusLogic oder LSI Logic) einer virtuellen Maschine die LUNs aus irgendwelchen Gründen zurücksetzen, kann dies eine Endlosschleife verursachen.
        Versuche, die virtuelle Maschine abzuschießen, verlaufen nicht erfolgreich.
      •  Das Gastbetriebssystem meldet E/A-Fehler in Bezug auf LSI-Controller
        Online-Upgrades der Controller-Firmware auf einem Array mit einem LSI-Controller können möglicherweise E/A-Ausfälle auf virtuellen Maschinen verursachen, die auf das Array zugreifen. Viele Arrays verwenden einen LSI-Controller. Bei der folgenden Liste handelt es sich beispielsweise um einige gängige Arrays, die LSI-Controller einsetzen:
        • IBM DS48xx Serie
        • IBM DS 3xxx Serie
        • Dell MD3xxx Serie
        • Sun STK Flexline Serie

        Umgehung: Bevor Sie die Firmware auf einem Speichercontroller aktualisieren, leiten Sie von Hand alle LUNs auf den anderen Speichercontroller um und stellen Sie sicher, dass der ESX/ESXi-Host keine E/A an den Speichercontroller sendet.

      •  Die Befehle der Servicekonsole liefern möglicherweise irreführende Informationen über die Cisco UCS Qlogic FCoE-Controller
        Auf Cisco Unified Computing-Systemen (UCS) mit einem Qlogic FCoE-Controller wird über die Befehle der Servicekonsole esxcfg-scsidevs -aund lspcimöglicherweise nicht der Controller als Qlogic FCoE-Controller, sondern als Fibre-Channel-Controller identifiziert.

        Beispielsweise werden in der Ausgabe der folgenden Befehle der Servicekonsole die Cisco UCS Qlogic FCoE-Controller nicht ausdrücklich als FCoE-Controller identifiziert.

        • Der Befehl lspcifür Cisco UCS Qlogic FCoE Controller:
          04:00.0 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03)
          04:00.1 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03)


        • Der Befehl esxcfg-scsidevs -afür Cisco UCS Qlogic FCoE-Controller:
          vmhba1 qla2xxx link-up fc.20010025b500000a:20000025b500001a (0:4:0.0) QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA
          vmhba2 qla2xxx link-up fc.20010025b500000a:20000025b500000a (0:4:0.1) QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA

      Unterstützte Hardware

      • Das Starten von VMware ESX schlägt möglicherweise auf Dell 2900-Servern fehl
        Wenn auf einem Server des Typs Dell 2900 ein älteres BIOS als 2.1.1 installiert ist, reagiert der VMkernel von ESX während des Starts möglicherweise nicht mehr. Dies ist auf einen Fehler im Dell BIOS zurückzuführen, der in der BIOS-Version 2.1.1 behoben ist.

        Umgehung: Aktualisieren Sie das BIOS auf die Version 2.1.1 oder später.

      • Es werden keine CIM-Alarme empfangen, wenn das Stromkabel und das Netzteil neu an HP-Server angeschlossen werden
        Es werden keine neuen SEL(IML)-Einträge für das erneute Anschließen des Stromkabels und des Netzteils auf HP-Servern erstellt, wenn eine unterbrochene Stromversorgung wiederhergestellt wird. Dies führt dazu, dass keine CIM-Alarme für diese Ereignisse generiert werden.

        Umgehung: Keine

      • Core-Dump schlägt mit einer Zeitüberschreitungsmeldung fehl
        Das Konfigurieren eines mit einem Perc 4/DC-Controller verbundenen Geräts als Core-Dump-Gerät, auf dem im Falle eines Systemabsturzes Crash-Dumps gespeichert werden, kann zu Zeitüberschreitungen und nicht gespeicherten Core-Dumps führen. Dieses Zeitüberschreitungsverhalten wurde bei verschiedenen Firmware-Versionen auf diesem Controller (z. B., 352B und 352D) und nur für Systemabstürze beobachtet. Es wurden keine Probleme beim E/A auf demselben Gerät beobachtet, wenn das System läuft.

        Umgehung: Konfigurieren Sie kein mit einem Perc 4/DC-Controller verbundenes Gerät als Core-Dump-Gerät für ESX/ESXi 4.0-Systeme.

      • ESX/ESXi auf der HP G6-Plattform mit P410i oder P410 Smart Array-Controller läuft während des Einschaltens der virtuellen Maschinen oder bei Festplatten-E/A-Vorgängen langsam
        Einige dieser Hosts laufen möglicherweise beim Einschalten von virtuellen Maschinen oder bei Festplatten-E/A-Vorgängen langsam. Die Hauptsymptom ist eine herabgestufte E/A-Leistung, wodurch viele Fehlermeldungen ähnlich der Folgenden in /var/log/messages protokolliert werden.

        Mar 25 17:39:25 vmkernel: 0:00:08:47.438 cpu1:4097)scsi_cmd_alloc returned NULL!
        Mar 25 17:39:25 vmkernel: 0:00:08:47.438 cpu1:4097)scsi_cmd_alloc returned NULL!
        Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)NMP: nmp_CompleteCommandForPath: Command 0x28 (0x410005060600) to NMP device
        "naa.600508b1001030304643453441300100" failed on physical path "vmhba0:C0:T0:L1" H:0x1 D:0x0 P:0x0 Possible sense data: 0x
        Mar 25 17:39:26 0 0x0 0x0.
        Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)WARNING: NMP: nmp_DeviceRetryCommand: Device
        "naa.600508b1001030304643453441300100": awaiting fast path state update for failoverwith I/O blocked. No prior reservation
        exists on the device.
        Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)NMP: nmp_CompleteCommandForPath: Command 0x28 (0x410005060700) to NMP device
        "naa.600508b1001030304643453441300100" failed on physical path "vmhba0:C0:T0:L1" H:0x1 D:0x0 P:0x0 Possible sense data: 0x
        Mar 25 17:39:26 0 0x0 0x0.

        Umgehung: Installieren Sie das 256 MB große Cache Upgrade-Modul der HP P-Serie.

      • Auf bestimmten Versionen des vSphere-Clients wird der Status des Akkus möglicherweise falsch als alarmierend angezeigt
        Wenn sich der Akku im Lernmodus befindet, wird im vSphere-Client auf der Registerkarte "Hardwarestatus" eine Alarmmeldung angezeigt, die angibt, dass der Status des Akkus nicht in Ordnung ist. Allerdings ist der Ladezustand des Akkus in Ordnung.

        Umgehung: Keine.
      • Die Meldung "Detected Tx Hang" wird in der VMkernel-Protokolldatei angezeigt
        Einige Varianten der e1000-Netzwerkkarten blockieren aufgrund von Hardwarefehlern unter Volllast. ESX/ESXi erkennt das Problem und setzt die Karte automatisch zurück. Dieses Problem steht im Zusammenhang mit Tx-Paketen, TCP-Arbeitslasten und TCP Segmentation Offloading (TSO).

        Umgehung: Sie können TSO deaktivieren, indem Sie in der Datei esx.confdie Option /adv/Net/UseHwTSOauf 0 setzen.

       

      •   Probleme mit dem TEAC DV-28E-V DVD-Laufwerk
        Wenn ein ESX/ESXi-Host physisch mit einem TEAC DV-28E-V DVD-Laufwerk mit alter Firmware (beispielsweise C.AB) verbunden ist, reagiert die virtuelle Maschine, der Host-Daemon oder der ESX/ESXi-Host möglicherweise nicht mehr. Das Problem tritt nicht immer auf, am ehesten wurde es bei virtuellen Windows-Maschinen beobachtet.

        Umgehung: Aktualisieren Sie die Firmware des DVD-Laufwerks auf die neueste Version oder ersetzen Sie das DVD-Laufwerk durch ein anderes Modell.

      Upgrade und Installation

      • Ein Upgrade von ESX 4.0 auf ESX 4.0.x oder ESX 4.x mithilfe des Befehls "esxupdate" führt zu einer Fehlermeldung (KB 1038732)
      • Der Datenbank-Upgrade-Assistent des vCenter Server-Systems schätzt während eines Upgrades von VirtualCenter 2.0.x auf vCenter Server 4.0 den erforderlichen Festplattenspeicher möglicherweise als zu hoch ein
        Während eines Upgrades von VirtualCenter 2.0.x auf vCenter Server 4.0 kann der Datenbank-Upgrade-Assistent einen falschen Wert für den erforderlichen Festplattenspeicher anzeigen. In der Regel ist die angezeigte Schätzung höher als der tatsächlich erforderliche Speicherplatz.

        Umgehung: Keine

      • Die Installation des vSphere-Clients schlägt möglicherweise mit dem Fehler 1603fehl, wenn Sie nicht über eine aktive Internetverbindung verfügen
        Sie können den vSphere-Client auf zwei Arten installieren: Vom vCenter Server-Medium aus oder indem Sie auf einen Link im ESX-, ESXi- oder vCenter Server-Begrüßungsbildschirm klicken. Das Installationsprogramm auf dem vCenter Server-Medium (.iso-Datei oder .zip-Datei) enthält zusätzlich zum vSphere-Client-Installationsprogramm ein vollständiges .NET-Installationsprogramm. Das Installationsprogramm, das über den Begrüßungsbildschirm aufgerufen wird, enthält ein vSphere-Client-Installationsprogramm, das die .NET-Installationsprogrammkomponenten aus dem Internet abruft.

        Wenn Sie nicht über eine Internetverbindung verfügen, schlägt die zweite vSphere-Client-Installationsmethode mit dem Fehler 1603fehl, es sei denn, .NET 3.0 SP1 ist bereits auf Ihrem System installiert.

        Umgehung: Richten Sie eine Internetverbindung ein, bevor Sie den Download versuchen, installieren Sie den vSphere-Client vom vCenter Server-Medium aus oder installieren Sie .NET 3.0 SP1, bevor Sie auf den Link auf dem Begrüßungsbildschirm klicken.

      • Öffnen von Leistungsdiagrammen nach einem Upgrade führt zu einer Fehlermeldung
        Nach Durchführung eines Upgrades unter Verwendung der Microsoft SQL Express Edition-Datenbank zeigt der vSphere-Client die Fehlermeldung Beim Leistungsdiagrammdienst ist ein interner Fehler aufgetreten an, wenn Sie Leistungsdiagramme öffnen. Dies liegt daran, dass das Installationsprogramm den Datenbankdienst nicht neu startet, wenn Änderungen an den Datenbankeinstellungen vorgenommen wurden.

        Umgehung: Führen Sie die folgenden Schritte aus:

        1. Halten Sie den VMware VirtualCenter Server-Dienst in Windows an.
        2. Starten Sie den Datenbankdienst neu.
        3. Starten Sie den VMware VirtualCenter Server-Dienst.
        4. Öffnen Sie eine neue vSphere-Client-Instanz und melden Sie sich beim vCenter Server an.
      • Einige Kickstart-Befehle für Skriptinstallationen von ESX 4.0 sind veraltet oder werden in dieser Version nicht unterstützt
        Falls Ihr Installationsskript nicht mit ESX 4.0 funktioniert, enthält es möglicherweise veraltete oder nicht unterstützte Befehle. Die folgenden Kickstart-Befehle sind veraltet:

        autostep
        clearpart --linux
        clearpart --exceptvmfs
        cmdline
        device
        deviceprobe
        firewall --enabled(wurde durch esxcfg-firewall --blockIncoming und esxcfg-firewall --blockOutgoing ersetzt)
        firewall --disabled(wurde durch esxcfg-firewall --allowIncomingund esxcfg-firewall --allowOutgoing ersetzt)
        firstboot
        harddrive
        ignoredisk
        interactive
        lang
        (Die Standardeinstellung wird verwendet.)
        langsupport
        (Die Standardeinstellung wird verwendet.)
        lilo
        lilocheck
        logvol
        mouse
        part --onvmdk
        raid
        skipx
        text
        vmaccepteula
        (heißt jetzt accepteula)
        vnc
        volgroup
        xconfig
        xdisplay
        %packages
        (packages.xml wird jetzt für das Anpassen von Paketen verwendet)
        %vmlicense_text

        Die nachfolgenden Red Hat Enterprise Linux 3-Befehle werden nicht unterstützt:

        autostep
        cmdline
        device
        deviceprobe
        firewall --blockIncoming
        firewall --blockOutgoing
        firstboot
        harddrive
        ignoredisk
        interactive
        lang
        langsupport
        lilo
        lilocheck
        logvol
        mouse
        raid
        skipx
        text
        vnc
        volgroup
        xconfig
        xdisplay

        Umgehung: Verwenden Sie nur die Kickstart-Befehle, die von VMware unterstützt werden. Eine detaillierte Liste der unterstützten Befehle finden Sie im Installationshandbuch – ESX und vCenter Server.

      • Falls Sie für die Servicekonsole einen gemeinsam genutzten Datenspeicher auswählen, gibt das Installationsprogramm bzw. das Upgrade-Tool keine Warnmeldung aus
        Im Falle von ESX 4.0 muss die Servicekonsole auf einem VMFS-Datenspeicher installiert werden, der sich auf einer lokalen Festplatte des Hosts oder auf einer SAN-Festplatte befindet, die maskiert und ausschließlich in die Zone dieses bestimmten Hosts eingeteilt ist. In dieser Version wird das Installieren der Servicekonsole auf einem Datenspeicher, der von mehreren Hosts gemeinsam genutzt wird, nicht unterstützt. Sie müssen beim Installieren von oder Aktualisieren auf ESX 4.0 den Speicherort eines VMFS-Datenspeichers ( esxconsole.vmdk) für die Servicekonsole auswählen. Wenn Sie einen Datenspeicher auswählen, der von mehreren Hosts gemeinsam genutzt wird, gibt das Installationsprogramm bzw. das Upgrade-Tool keine Warnmeldung aus.

        Umgehung: Installieren Sie die Servicekonsole nicht auf einem VMFS-Datenspeicher, der von mehreren Hosts gemeinsam genutzt wird.

      • Wenn SQL Native Client bereits installiert ist, können Sie vCenter mit der mitgelieferten SQL Server 2005 Express-Datenbank nicht installieren
        Wenn Sie vCenter mit der mitgelieferten SQL Server 2005 Express-Datenbank installieren und SQL Native Client bereits installiert ist, schlägt die Installation mit folgender Fehlermeldung fehl:

        Ein Installationspaket für das Produkt Microsoft SQL Native Client wurde nicht gefunden. Versuchen Sie, die Installation unter Verwendung einer gültigen Kopie des Installationspakets "sqlcli.msi" durchzuführen.

        Umgehung: Deinstallieren Sie SQL Native Client, sofern er nicht von einer anderen Anwendung verwendet wird. Installieren Sie anschließend vCenter mit der mitgelieferten SQL Server 2005 Express-Datenbank.

      • Der VMxnet-Treiber wird nicht automatisch installiert, wenn Sie VMware Tools installieren oder Upgrade
        Wenn Sie auf einer virtuellen Maschine, auf der das Gastbetriebssystem Windows NT ausgeführt wird, VMware Tools installieren oder Upgrade, wird der vmxnet-Treiber nicht automatisch installiert.

        Umgehung: Installieren Sie den VMxnet-Treiber manuell. Führen Sie dazu die folgenden Schritte aus:

        1. Melden Sie sich bei der virtuellen Maschine an und klicken Sie mit der rechten Maustaste auf Netzwerkumgebung.
        2. Klicken Sie auf Eigenschaften und wählen Sie die Registerkarte Adapter aus.
        3. Klicken Sie auf Diskette und geben Sie den Pfad für den Treiber ein:
          C:\Programme\VMware\VMware Tools\Drivers\vmxnet\
        4. Starten Sie die virtuelle Maschine neu.
      • Beim Starten von ESX auf einer Dell Precision T3400-Workstation wird das grafische Installationsprogramm nicht geladen
        Wenn Sie auf einer Dell Precision T3400-Workstation versuchen, das grafische Installationsprogramm zum Installieren von ESX zu verwenden, schlägt die Installation fehl.

        Umgehung: Verwenden Sie stattdessen das Textinstallationsprogramm.

      • Nach Abbrechen der Deinstallation von vSphere-Client 4.0 kann das Produkt weder neu installiert noch deinstalliert werden
        Wurde die Installation des vSphere-Clients abgebrochen, erscheint folgende Fehlermeldung, wenn erneut versucht wird, vSphere Client 4.0 zu installieren bzw. zu deinstallieren:

        Fehler beim Anwenden einer Transformation. Stellen Sie sicher, dass die angegebenen Transformationspfade gültig sind.

        Umgehung: Verwenden Sie das Windows-Dienstprogramm in der Systemsteuerung, um vSphere Client 4.0 zu deinstallieren.

      • Der VMware Web Access-Kickstart-Skriptgenerator wird nicht unterstützt
        Der VMware Web Access-Kickstart-Skriptgenerator steht in vSphere 4.0 für eine ESX-Skriptinstallation nicht zur Verfügung.

        Umgehung: Sie können das Kickstart-Skript verwenden, das automatisch nach einer interaktiven Installation generiert wird. Nach der ersten interaktiven Installation von ESX erstellt das Installationsprogramm ein /root/ks.cfg-Skript im ESX-Dateisystem. Dieses Skript enthält die Einstellungen, die Sie während der interaktiven Installation vorgenommen haben. Eine vollständige Liste der unterstützten Befehle und ein Beispielskript finden Sie im Installationshandbuch – ESX und vCenter Server.

      • Nach dem Deinstallieren des vSphere-Clients bleiben leere Verzeichnisse übrig
        Wenn Sie den vSphere-Client deinstallieren, bleiben leere Verzeichnisse übrig.

        Umgehung: Navigieren Sie in das Installationsverzeichnis und löschen Sie das Verzeichnis Virtual Infrastructure-Client.

      • Auf dem Startlaufwerk sind mindestens 650 MB an freiem Speicherplatz für die Installation von vCenter Server erforderlich
        Obwohl vCenter Server selbst nicht auf dem Startlaufwerk installiert werden muss, müssen einige erforderlichen Komponenten auf dem Startlaufwerk installiert werden. Um diese erforderlichen Komponenten sowie die temporären Dateien, die während der Installation verwendet werden, aufzunehmen, werden 650 MB an freiem Speicherplatz benötigt.

        Umgehung: Stellen Sie sicher, dass mindestens 650 MB freier Speicherplatz auf dem Startlaufwerk zur Verfügung stehen, bevor Sie vCenter Server installieren.

      • Beim Herunterladen des vSphere Client 4.0 tritt eine Zeitüberschreitung mit Fehlermeldung ein, wenn Sie einen VI Client 2.0.x auf einer Windows 2003-Maschine mit vCenter Server oder einem ESX/ESXi-Host verbinden
        Wenn Sie eine VI Client 2.0.x-Instanz mit vCenter Server 4.0 oder einem ESX/ESXi 4.0-Host verbinden, wird vSphere Client 4.0 automatisch auf die Windows-Maschine heruntergeladen, auf der sich der VI-Client befindet. Dieser Vorgang basiert auf Internet Explorer, um dieses Download durchzuführen. Auf Windows 2003-Systemen blockiert Internet Explorer standardmäßig das Download, wenn es sich bei der VI-Client-Instanz um VI Client 2.0.x handelt.

        Umgehung: Wählen Sie in Internet Explorer Extras > Internetoptionen > Erweitert und deaktivieren Sie die Option Verschlüsselte Seiten nicht auf der Festplatte speichern. Laden Sie alternativ den vSphere Client 4.0 manuell von vCenter Server 4.0 oder vom ESX/ESXi 4.0-Host herunter.

      • Die Installation von ESX/ESXi auf einer IBM x336-Maschine schlägt wegen der BIOS-Inkompatibilität möglicherweise fehl
        Auf einigen Computern des Typs IBM x336 kann es passieren, dass der ESX/ESXi-Installationsvorgang gestoppt wird. Dies ist auf einen Bug im BIOS der Maschine zurückzuführen.

        Umgehung: Upgrade Sie das BIOS der Maschine auf Version 1.15, bevor Sie ESX oder ESXi Installable installieren.

      • Wenn Sie zum Durchführen eines ESX-Host-Upgrades vSphere Host Update Utility verwenden, schlägt das Upgrade möglicherweise fehl
        Wenn Sie zum Durchführen eines ESX-Upgrades vSphere Host Update Utility verwenden, schlägt das Upgrade möglicherweise mit folgendem Fehler fehl:

        Während des Upgrades ist ein Fehler aufgetreten. Die Verbindung zum Upgrade-Agenten wurde unterbrochen.

        Dies geschieht, wenn das Upgrade zu 26 % abgeschlossen ist. Der Prozess hält in der Servicekonsole bei VMware ESX Server Management-Dienste werden gestoppt an.

        Umgehung: Starten Sie den ESX-Host manuell neu, indem Sie auf die Schaltfläche "Zurücksetzen" klicken. Das ESX-Upgrade setzt sich fort und wird erfolgreich abgeschlossen, aber vSphere Host Update Utility zeigt den Fortschritt nicht an. Klicken Sie zum Anzeigen des aktuellen Hoststatus von vSphere Host Update Utility auf Erneut versuchen.

      • Wenn Sie unter Verwendung der DVD ESX lokal installieren und dabei ein bestimmtes DVD-Modell benutzen, schlägt die ESX-Installation fehl
        Das lokale Installieren von ESX schlägt fehl, wenn Sie Folgendes verwenden: SONY AMAX 270 DVD RW AW-Q170A, Rev: 1.70. Die DVD wird nicht erkannt.

        Umgehung: Aktualisieren Sie die Firmware auf SONY DVD RW AW-Q170A, Rev: 1.74 und führen Sie die Installation erneut durch.

      • vCenter Server-Datenbank-Upgrade schlägt für Oracle 10gR2-Datenbanken mit bestimmten Benutzerberechtigungen fehl
        Wenn Sie VirtualCenter Server 2.x auf vCenter Server Version 4.0 Upgrade und Sie über die Berechtigungen "connect", "create view", "create any sequence", "create any table" und "execute on dbms_lock" für die Datenbank (Oracle 10gR2) verfügen, schlägt das Upgrade fehl. Die Datei VCDatabaseUpgrade.log zeigt folgenden Fehler:

        Fehler: Failed to execute SQL procedure. Got exception: ERROR [HY000] [Oracle][ODBC][Ora]ORA-01536: space quota exceeded for tablespace 'USERS'

        Umgehung: Vergrößern Sie als Datenbankadministrator den Benutzer-Tablespace oder gewähren Sie dem Benutzer, der das Upgrade durchführt, die Berechtigung "unlimited tablespace".

      • Das Installieren von vCenter Server unter Windows Server 2008 schlägt bei Verwendung eines Benutzerkontos, bei dem es sich nicht um ein Systemkonto handelt, fehl
        Wenn Sie während der Installation ein Benutzerkonto angeben, bei dem es sich nicht um ein Systemkonto handelt, schlägt die Installation von vCenter Server mit folgender Fehlermeldung fehl:

        Fehler beim Erstellen des vCenter-Repositorys

        Umgehung: Schalten Sie auf dem System, auf dem vCenter Server installiert wird, unter Systemsteuerung > Benutzerkonten die Option "Benutzerkontensteuerung" aus, bevor Sie vCenter Server installieren. Geben Sie während der vCenter Server-Installation den Nicht-Systembenutzer an.

      • Nach einem Upgrade auf vCenter Server 4.0 scheinen nicht kompatible Legacy-Plug-Ins im Plug-In-Manager des vSphere-Clients aktiviert zu sein
        Wenn VirtualCenter 2.5 zusammen mit VMware Update Manager 1.0 oder VMware Converter Enterprise für VirtualCenter 2.5 installiert ist und auf vCenter Server 4.0 aktualisiert wird, scheinen die Legacy-Plug-Ins im Plug-In-Manager des vSphere-Clients installiert und aktiviert zu sein. Frühere Versionen der Plug-In-Module sind jedoch nicht kompatibel mit vCenter Server 4.0. In solchen Fällen stehen die Plug-Ins möglicherweise zur Verfügung, diese sind jedoch nicht funktionsfähig.

        Umgehung: Aktualisieren Sie VMware Update Manager auf VMware vCenter Update Manager 4.0 und VMware Converter Enterprise auf VMware vCenter Converter (für vCenter Server 4.0) und installieren und aktivieren Sie anschließend die Plug-Ins.

      • Keine Anmeldung bei VirtualCenter Server 2.5 möglich, nachdem der VI Client 2.0.x, 2.5 und vSphere Client 4.0 auf einem Windows Vista-System installiert wurden und der VI Client 2.0.x deinstalliert wurde
        Nach dem Deinstallieren des VI Client 2.0.x auf einer Windows Vista-Maschine, auf der VI Client 2.0.x und 2.5 sowie vSphere Client 4.0 gleichzeitig vorhanden sind, ist keine Anmeldung bei vCenter Server 2.5 möglich. Die Anmeldung schlägt mit folgender Meldung fehl:

        Klasse nicht registriert (Ausnahme von HRESULT:0x80040154(REGDB_E_CLASSNOTREG))

        Umgehung: Deaktivieren Sie die Benutzerkontensteuerung auf dem System, auf dem VI Client 2.0.x, 2.5 und vSphere Client 4.0 zusammen installiert sind, oder deinstallieren Sie den VI Client 2.5 und installieren Sie ihn neu.

      • Das ESX/ESXi-Installationsprogramm führt die lokalen SAS-Speichergeräte im Abschnitt "Remotespeicher" auf
        Beim Anzeigen der Speicherorte, in denen ESX oder ESXi Installable installiert wird, führt das Installationsprogramm im Abschnitt "Remotespeicher" ein lokales SAS-Speichergerät auf. Dies liegt daran, dass ESX/ESXi nicht feststellen kann, ob das SAS-Speichergerät lokal oder remote ist. Es wird deshalb immer als remote angesehen.

        Umgehung: Keine

      • Wenn Sie auf manchen Dell-Servern ESX unter Verwendung der virtuellen DRAC5-CD-ROM-Methode installieren, schlägt die ESX-Installation fehl
        Die Verbindung des virtuellen Mediums wird getrennt, wenn Sie auf manchen Dell PowerEdge-Servern versuchen, unter Verwendung der virtuellen DRAC5-CD-ROM-Methode ESX zu installieren.

        Umgehung: Statt virtuelle Medien zu benutzen, installieren Sie ESX von dem lokalen CD-Laufwerk oder aktualisieren Sie die Firmware-Version auf Version 1.33 (08.03.10).

      • Wenn vSphere Host Update Utility die Netzwerkverbindung zum ESX-Host verliert, funktioniert das Host-Upgrade möglicherweise nicht
        Wenn Sie zum Durchführen eines ESX/ESXi-Host-Upgrades das vSphere Host Update Utility verwenden und die Verbindung des Dienstprogramms mit dem Host unterbrochen wird, wird der Host möglicherweise nicht vollständig aktualisiert. Wenn dies geschieht, reagiert das Dienstprogramm möglicherweise nicht mehr oder die folgende Fehlermeldung wird ausgegeben:

        Fehler beim Ausführen der Kompatibilitätsprüfung auf dem Host.

        Umgehung: Schließen Sie das Dienstprogramm, reparieren Sie die Netzwerkverbindung, starten Sie das Dienstprogramm neu und führen Sie das Upgrade erneut aus.

      • Das vCenter Server-Installationsprogramm gibt während der Installation bzw. des Upgrades falsche Warnmeldungen aus
        Während der Installation bzw. des Upgrades weist das vCenter Server-Installationsprogramm per Warnmeldung daraufhin, TCP/IP und Named Pipes für Remoteverbindungen zu aktivieren. Diese Meldung wird ausgegeben, wenn Sie eine lokale SQL Server-Datenbank verwenden und beim Erstellen des DSN nicht (local) oder "." als Servername eingeben.

        Umgehung: Ignorieren Sie diese Warnung und klicken Sie auf OK, um mit der Installation bzw. dem Upgrade fortzufahren.

      • vSphere-Client schlägt mit einem Microsoft Visual C++ Laufzeitbibliotheksfehler fehl
        In Umgebungen mit vSphere 4.0-Komponenten, VI Client Version 2.5 und VMware vCenter Converter schlägt der vSphere-Client möglicherweise mit einer Microsoft Visual C++ Laufzeitbibliotheksausnahme fehl.

        Umgehung: Löschen Sie libeay32.dll und ssleay32.dll im folgenden Pfad:
        C:\Programme\VMware\Infrastructure\Virtual Infrastructure Client\Launcher
        Als Alternative können Sie VI Client Version 2.5 deinstallieren.

      • Das Installieren von vCenter Server unter Windows Server 2008 mit einer Remote-SQL-Server-Datenbank kann unter Umständen fehlschlagen
        Wenn Sie vCenter Server auf einem Windows 2008-System mit einer Remote-SQL-Server-Datenbank mit Windows-Authentifizierung für SQL Server installieren und einen Domänenbenutzer für den DSN verwenden, der sich von dem vCenter Server-Systembenutzer unterscheidet, wird der Installationsvorgang nicht fortgesetzt und die folgende Fehlermeldung wird ausgegeben:

        25003.Setup failed to create the vCenter repository

        Umgehung: Verwenden Sie unter diesen Umständen dieselben Anmeldedaten für vCenter Server und den SQL Server-DSN.

      • Ein Upgrade der Hardwareversion von virtuellen Windows-Maschinen erfordert möglicherweise Treiber-Updates
        Das Upgrade der Hardwareversion einer virtuellen Windows-Maschine auf Hardwareversion 7 auf einem ESX 4.0-Host sorgt dafür, dass der Flexible-Netzwerkadapter fälschlicherweise den PCI Ethernet-Adapter-Treiber ( pcnetpci5.sys) der AMD PCNet-Familie verwendet und eine Geschwindigkeit von 10 MBit/s hat. Richtig ist der VMware Accelerated AMD PCnet Adapter-Treiber ( vmxnet.sys).

        Umgehung: Aktualisieren Sie manuell den Treiber für die Flexible-Netzwerkkarte auf den VMware Accelerated AMD PCnet Adapter-Treiber (vmxnet.sys), indem Sie von dem Windows-Gastbetriebssystem der virtuellen Maschine aus auf C:\Programme\VMware\VMware Tools\Drivers\vmxnet\vmware-nic.inf verweisen.

      • Die Ressourcenpooleinstellungen eines ESX-Hosts werden möglicherweise nach einem Upgrade von ESX Server 3.0.x oder ESX Server 3.5.x auf ESX 4.0 nicht beibehalten
        Wenn der ESX-Host so konfiguriert ist, dass alle, die meisten oder fast alle verfügbaren Hostkapazitäten in den Ressourcenpooleinstellungen für die CPU- und Arbeitsspeicherreservierung zugeteilt werden, werden nach einem Upgrade von ESX Server 3.0.x oder ESX 3.5.x auf ESX 4.0 die Einstellungen möglicherweise nicht beibehalten. Nach einem Upgrade werden die Reservierungseinstellungen auf Null gesetzt. Dieses Problem betrifft nur eigenständige Hosts. DRS-Cluster sind davon nicht betroffen.

        Umgehung: Teilen Sie in den Ressourcenpooleinstellungen für die CPU- und Arbeitsspeicherreservierung nicht alle oder nahezu alle verfügbaren Hostkapazitäten zu. Falls Sie es doch tun, notieren Sie vor dem Upgrade die Informationen über die Ressourcenpooleinstellungen auf Hostebene und nach dem Upgrade ändern Sie die Informationen manuell.

      • vSphere Host Update Utility gibt einen Fehler aus, wenn versucht wird, einen ESX-Host zu Upgrade, nachdem das erstmalige Upgrade fehlgeschlagen ist
        Wenn Sie versuchen, mithilfe der Option Wiederholen einen Host zu Upgrade, nachdem das erstmalige Upgrade fehlgeschlagen ist, gibt möglicherweise vSphere Host Update Utility folgenden Fehler aus:

        Upgrade-Agent-Fehler:1

        Umgehung: Schließen Sie das vSphere Host Update Utility und starten Sie es neu. Führen Sie anschließend das Upgrade des Hosts durch.

      • Der Wert für die nächste Ausführung einiger geplanter Aufgaben wird nach einem Upgrade von VirtualCenter 2.0.2.x auf vCenter Server 4.0 nicht beibehalten
        Wenn Sie VirtualCenter 2.0.2.x auf vCenter Server 4.0 Upgrade, wird für einige geplante Aufgaben der Wert für die Nächste Ausführungmöglicherweise nicht beibehalten und die Aufgaben werden möglicherweise unerwartet ausgeführt. Wenn z. B. eine Aufgabe so geplant ist, dass sie jeden Tag um 10 Uhr ausgeführt wird, wird sie nach dem Upgrade möglicherweise um 11.30 Uhr ausgeführt.

        Dieses Problem tritt auf, weil es Unterschiede zwischen den Methoden gibt, die VirtualCenter 2.0.2.x und vCenter Server 4.0 verwenden, um den Zeitpunkt der nächsten Ausführung zu berechnen. Dieses Verhalten ist nur unter den folgenden Bedingungen sichtbar:

        • Sie haben geplante Aufgaben, deren Zeitpunkte für die nächste Ausführung Sie geändert haben, nachdem sie ursprünglich geplant wurden. Sie weisen jetzt einen anderen Zeitpunkt für die Nächste Ausführung auf.
        • Der neu geplante Zeitpunkt für die Nächste Ausführung ist noch nicht eingetreten.

        Umgehung: Führen Sie die folgenden Schritte aus:

        1. Warten Sie, bis die Aufgaben zum Zeitpunkt ihrer Nächsten Ausführung ausgeführt werden, bevor Sie aktualisieren.
        2. Nach dem Upgrade von vCenter 2.0.x auf vCenter Server 4.0 bearbeiten und speichern Sie die geplante Aufgabe. Dieser Vorgang berechnet den Zeitpunkt der Nächsten Ausführung auf den korrekten Wert neu.
      • Virtuelle ESX Server 2.5-Maschinen mit nicht dauerhaften Festplatten, die auf ESX 4.0 aktualisiert wurden, werden möglicherweise in einem angehaltenen Status versetzt
        Wenn Sie die virtuelle Hardware einer virtuellen ESX Server 2.5-Maschine mit nicht dauerhaften Festplatten (erkennbar durch config version = 6, hardware version = 3) auf ESX 4.0 Upgrade, wird die virtuelle Maschine fälschlicherweise auf "autorevert" gesetzt. Wenn Sie in ESX 4.0 Snapshots von dieser virtuellen Maschine erstellen (erkennbar durch config version = 8, hardware version = 7), wird die virtuelle Maschine möglicherweise in einen angehaltenen Status versetzt, wenn ihre virtuellen Hardwaregeräte im ausgeschalteten Status neu konfiguriert werden.

        Umgehung: Entfernen Sie nach dem Upgrade der virtuellen Maschine den Eintrag snapshot.action = "autoRevert" manuell aus der Konfigurationsdatei.

      • Das Installieren oder Upgrade von vCenter Server 4.0 schlägt möglicherweise mit einem Festplattenspeicherfehler fehl
        Während der Installation von vCenter Server 4.0 schlägt die Installation möglicherweise fehl, wenn Sie die Menge an freiem Speicherplatz bereitstellen, die das Installationsprogramm geschätzt hat. Dabei wird die Fehlermeldung Nicht genügend Festplattenspeicher ausgegeben. Somit müssen Sie möglicherweise die Installation erneut durchführen.

        Umgehung: Stellen Sie mindestens 1 GB mehr an freiem Speicherplatz zur Verfügung als das Installationsprogramm empfiehlt.

      • Upgrades der Hardware der virtuellen Maschine von Version 4 auf Version 7 führen dazu, dass die Netzwerkeinstellungen von Solaris-Gastbetriebssystemen verloren gehen
        Upgrades der Hardware der virtuellen Maschine von Version 4 auf Version 7 ändern die Adresse des PCI-Bus der virtuellen Netzwerkadapter in Gastbetriebssystemen. Solaris erkennt die Adapter nicht und ändert die Nummerierung der Netzwerkschnittstellen (Beispielsweise wird e1000g0 zu e1000g1). Diese Änderung an der Nummerierung tritt ein, weil Solaris-IP-Einstellungen Schnittstellenamen zugeordnet sind, sodass es so aussieht, als ob die Netzwerkeinstellungen verloren gegangen sind und das Gastbetriebssystem nicht über eine ordnungsgemäße Konnektivität verfügt.

        Umgehung: Verwenden Sie den Befehl prtconf -D, um nach dem Upgrade der Hardware der virtuellen Maschine die neuen Schnittstellennamen zu ermitteln, und benennen Sie anschließend alle alten Konfigurationsdateien mit deren neuen Namen um. e1000g0 wird beispielsweise e1000g1, sodass jede /etc/*e1000g0-Datei in das /etc/*e1000g1-Äquivalent umbenannt wird.

      • Das vCenter Server-Installationsprogramm erkennt keine Service-Ports, wenn die Services nicht ausgeführt werden
        Wenn Sie vCenter Server installieren und die Standardports übernehmen, kann das Installationsprogramm die Ports nicht validieren, wenn sie von nicht ausgeführten Services verwendet werden. Die Installation schlägt fehl und je nach verwendetem Port wird möglicherweise eine Fehlermeldung ausgegeben.

        Dieses Problem betrifft keine IIS-Dienste. IIS-Services werden immer korrekt validiert, ob die Services ausgeführt werden oder nicht.

        Umgehung: Identifizieren Sie die Ports, die für nicht ausgeführte Services verwendet werden, bevor Sie mit der Installation beginnen, und vermeiden Sie sie.

      • Der vCenter Server-Dienst startet möglicherweise nicht, wenn vCenter Server als lokales Systemkonto auf einer lokalen Microsoft SQL Server-Datenbank mit integrierter Windows NT-Authentifizierung installiert wurde
        Wenn Sie eine Instanz von vCenter Server als ein lokales Systemkonto auf einer lokalen Microsoft SQL Server-Datenbank mit integrierter Windows NT-Authentifizierung installieren und Sie einen entsprechenden Benutzer zum lokalen Datenbankserver mit derselben Standarddatenbank als vCenter Server hinzufügen, startet vCenter Server möglicherweise nicht.

        Umgehung: Entfernen Sie den Benutzer mit integrierter Windows NT-Authentifizierung von dem lokalen SQL-Datenbankserver. Ändern Sie alternativ die Standarddatenbank für das lokale Systembenutzerkonto in die vCenter Server-Datenbank für die SQL Server-Benutzerkontokonfiguration.

      • Einige Befehle funktionieren möglicherweise nicht in den Abschnitten "%pre" und "%post" der Kickstart-Datei
        Einige Befehle, z. B. mount, die bei der Installation von vorherigen Versionen von ESX mithilfe von Kickstart-Dateien unterstützt wurden, funktionieren für Installationen von ESX 4.0 möglicherweise nicht in den Abschnitten "%pre" und "%post" der Kickstart-Datei.

        Umgehung: Ändern Sie die Abschnitte "%pre" und "%post" der in den Installationsskripts verwendeten Kickstart-Dateien.

      • Anwendbare Bulletins werden nicht aufgelistet, wenn die Hostmaschine mithilfe des Befehls "vihostupdate" geprüft wird
        Das Prüfen der Hostmaschine mithilfe des Befehls "vihostupdate" für die anwendbaren Bulletins führt dazu, dass nach dem Download der Paket-ZIP-Datei für ESX 4.0 Update 4 nicht alle Bulletins aufgelistet werden, die im Paket enthalten sind.

        Umgehung: Verwenden Sie das Dienstprogramm esxupdatezum Auflisten der verfügbaren Bulletins im ESX 4.0 Update 4-Paket. Weitere Informationen zum Dienstprogramm "esxupdate" finden Sie im Handbuch für die Patch-Verwaltung von ESX 4.
      •  Mit "esxupdate" wird die neueste Version eines VIB heruntergeladen, wenn die abhängige Version nicht in der Bulletin-Liste verfügbar ist
        Wenn Sie mit dem Befehl "esxupdate" einen Patch auf ESX installieren, lädt der Befehl die neueste Version eines VIB anstelle der speziellen Version herunter, die von der ESX-Installation verwendet wird. Ein derartiges Update wird ausgeführt, wenn die Installation eine bestimmte Version des VIB erfordert, diese Version des VIB jedoch nicht auf der Bulletin-Liste verfügbar ist.

      vCenter Server, vSphere-Client und vSphere Web Access

      • Alarme mit den Systemzustand betreffenden Auslösebedingungen werden nicht nach vSphere 4.0 migriert
        Die Alarmauslösefunktionalität von vSphere 4.0 wurde erweitert. Sie enthält zusätzliche Alarmauslöser für den Systemzustand des Hosts. Dabei wurde der generische Auslöser "Host-Zustand" entfernt. Daher stehen Alarme, die diesen Auslöser enthalten, in vSphere 4.0 nicht mehr zur Verfügung.

        Umgehung: Verwenden Sie den vSphere-Client, um die Alarme erneut zu erstellen. Sie können die folgenden vorkonfigurierten VMware-Alarme verwenden, um den Systemzustand des Hosts zu überwachen:

        • Batteriestatus des Hosts
        • Lüftungsstatus der Hosthardware
        • Betriebsstatus der Hosthardware
        • Temperaturstatus der Hosthardware
        • Status der Hauptplatine der Hosthardware
        • Spannung der Hosthardware
        • Arbeitsspeicherstatus des Hosts
        • Prozessorstatus des Hosts
        • Speicherstatus des Hosts

        Falls sich der Status, den Sie überwachen möchten, nicht unter den vorkonfigurierten Alarmen befindet, können Sie einen benutzerdefinierten Alarm erstellen, der den Ereignisauslöser "Hardwarestatus geändert" verwendet. Für diesen Ereignisalarm müssen Sie die Auslösebedingungen manuell festlegen. Darüber hinaus müssen Sie manuell einstellen, welche Aktion durchgeführt werden soll, wenn der Alarm ausgelöst wird.

        Hinweis: Für die vorkonfigurierten Alarme wurden bereits Standardauslöserbedingungen festgelegt. Sie brauchen nur noch einzustellen, welche Aktion bei Alarmauslösung durchgeführt werden soll.

      • Der Web Access-Dienst startet nach beendeter ESX-Installation nicht
        Wenn Sie Web Access verwenden, um eine Verbindung zu einem ESX-Host herzustellen, wird die folgende Meldung angezeigt:

        503 Service Unavailable

        Die Ursache liegt darin, dass der Web Access-Dienst nach Beenden der Installation von ESX nicht automatisch startet.

        Umgehung: Führen Sie folgenden Befehl aus, um den Web Access-Dienst auf dem ESX-Host zu starten: service vmware-webAccess start

      • Die Verwendung der Option "Alle löschen" des vSphere-Clients zum Entfernen von VM-Snapshots belässt möglicherweise die Snapshot-Festplattendateien im Ordner der virtuellen Maschine
        Dieses Verhalten tritt nur dann auf, wenn Sie bereits den Snapshot zum Erstellen von verknüpften Klonen verwendet und diese anschließend aus dem vCenter Server gelöscht haben. Wenn Sie versuchen, unter Verwendung der Option "Alle löschen" des Snapshot-Managers den Snapshot zu entfernen, wird der Snapshot gelöscht. Die Snapshot-Festplatte wird jedoch nicht mit der übergeordneten Festplatte konsolidiert und verbleibt in nicht gelöschtem Zustand im Ordner der virtuellen Maschine.

        Umgehung: Verwenden Sie zum Entfernen des Snapshots die Option "Löschen" an Stelle der Option "Alle löschen".

      • Bei der NTP-Konfiguration im vSphere-Client wird die Zeitzone im Host geändert
        Die Zeitzone des Hosts kann derzeit nicht über den vSphere-Client konfiguriert werden. Sie wird über die Servicekonsole konfiguriert. NTP-Einstellungen des Hosts können über den vSphere-Client konfiguriert werden. Wurde die Zeitzone des Hosts manuell geändert und wurden im Anschluss daran NTP-Einstellungen über den vSphere-Client konfiguriert, ersetzt der vSphere-Client die Zeitzone durch einen alten Wert.

        Umgehung: Nachdem Sie die Zeitzone des Hosts manuell geändert haben, schließen Sie alle verbundenen Clients und verbinden Sie sie erneut. Die Clients erhalten den neuen Zeitzonenwert.

      • Verfügt ein System über einen virtuellen Netzwerkadapter, kann es sein, dass Guided Consolidation für dieses System eine größere Anzahl von Netzwerkkarten berechnet, als tatsächlich vorhanden ist
        Die Anzahl an Netzwerkkarten, die von Guided Consolidation für ein System berechnet werden, kann größer sein, als die Zahl der vorhandenen Netzwerkkarten, falls das System über virtuelle Netzwerkadapter verfügt. In diesem Fall erhalten Sie möglicherweise während der Phase der Konsolidierungsplanung folgende Warnung: "Host verfügt nicht über die gewünschte Anzahl von VM-Netzwerken. Durch eine Konsolidierung werden mehrere Netzwerke des physischen Computers einem einzelnen VM-Netzwerk zugeordnet." Dies geschieht bei allen Maschinen mit virtuellen Netzwerkkarten (z. B. bei jeder virtuellen Maschine und jeder physischen oder virtuellen Maschine, auf der VMware Workstation oder eine andere gehostete Virtualisierungsplattform läuft).

        Umgehung: Dieses Problem muss nicht umgangen werden. Sie können die Warnung ignorieren.

      • Die Registerkarte "Hardwarestatus" zeigt die Hardwarestatusinformationen des ESX/ESXi-Host nicht an
        Die Registerkarte Hardwarestatus im vSphere-Client wird nicht mit den Hardwarestatusinformationen des ausgewählten ESX/ESXi-Host bestückt, wenn die vCenter Server-Maschine oder der ESX/ESXi-Host im reinen IPv6-Modus ausgeführt wird.

        Umgehung: Fügen Sie auf der vCenter Server-Maschine und dem ESX/ESXi-Host die IPv4-Schnittstelle hinzu und konfigurieren Sie sie.

      • Guided Consolidation kann keine Systeme importieren, auf denen vCenter Converter ausgeführt wird
        Bei den Importvorgängen von Guided Consolidation tritt ein Problem auf, wenn auf dem Quellsystem (d. h. auf dem importierten System) vCenter Converter ausgeführt wird. Guided Consolidation importiert das System und versucht, von dem Quellsystem vCenter Converter zu deinstallieren. Der Importvorgang gelingt, aber die folgende Fehlermeldung wird angezeigt, wenn Guided Consolidation versucht, vCenter Converter zu deinstallieren:

        VMware Converter-Agent-Installation ist fehlgeschlagen.

        Umgehung: Deinstallieren Sie vCenter Converter von den Quellsystemen, bevor Sie versuchen, sie unter Verwendung von Guided Consolidation zu importieren.

      • Webverknüpfungen zu virtuellen Maschinen mit ESX Server 3.5 funktionieren nach einem Upgrade auf ESX 4.0 nicht mehr
        Webverknüpfungen, die für virtuelle Maschinen mit ESX Server 3.5 erstellt wurden, sind für die Benutzer nicht mehr zugänglich, wenn Sie ein Upgrade auf ESX 4.0 durchgeführt haben. vSphere Web Access 4.0 unterstützt die URLs für ESX 3.5 nicht. Der Benutzer kann nicht über die URLs, die für ESX Server 3.5 erstellt wurden, auf die virtuellen Maschinen zugreifen.

        Umgehung: Verwenden Sie vSphere Web Access 4.0, um Webverknüpfungen zu erstellen, die für ESX 4.0 gültig sind, und verteilen Sie diese an Ihre Benutzer. Weitere Informationen über das Erstellen von Webverknüpfungen finden Sie im Administratorhandbuch für vSphere Web Access .

      • Die gemeinsame Nutzung eines Dual-Funktion-Adapters QLogic 2532 durch eine virtuelle Maschine und eine andere virtuelle Maschine oder den VMkernel bei VMDirectPath Gen I kann zu Datenverlusten führen
        Wenn Sie einen Dual-Funktion-Adapter QLogic 2532 für VMDirectPath IO konfigurieren und die erste PCI-Funktion einer virtuellen Maschine sowie die zweite einem VMkernel oder einer anderen virtuellen Maschine zuweisen, kann dies zu Datenverlust führen. Dies liegt daran, dass beide Ports die gleichen Daten zum Anmelden bei Fabric verwenden und über die gleichen Speichersichtbarkeit verfügen. VMware unterstützt diese Konfiguration für VMDirectPath IO nicht.

        Umgehung: Wenn der Dual-Funktion-Adapter von einer virtuellen Maschine und dem VMkernel gemeinsam genutzt werden muss, weisen Sie die erste PCI-Funktion der virtuellen Maschine und die zweite dem VMkernel zu. Die PCI-Funktionen können nicht zwischen zwei virtuellen Maschinen aufgeteilt werden.

      • Der vSphere-Client aktualisiert keine Sensoren, die physischen Ereignissen zugeordnet sind
        Der vSphere-Client aktualisiert Sensorstatus nicht in jedem Fall. Manche Ereignisse können eine Aktualisierung auslösen, z. B. ein fehlerhaftes Netzteil oder die Entfernung einer redundanten Festplatte. Andere Ereignisse, wie das Öffnen des Gehäuses oder das Entfernen eines Lüfters, lösen möglicherweise keine Aktualisierung des Sensorstatus aus.

        Umgehung: Keine

      • vCenter Server lässt es zu, dass dasselbe ESX/ESXi-System zweimal mit zwei verschiedenen IPv6-Adressen hinzugefügt wird
        Wenn Sie ein ESX/ESXi-System zur vCenter-Bestandsliste hinzufügen, das bereits unter einer anderen IP-Adresse in vCenter verwaltet wird, erkennt der vCenter Server dieses Problem nicht. Das ESX/ESXi-System erscheint mit einer neuen IP-Adresse und dem Status "Getrennt" in der Bestandsliste. Verbindungen zu dem ESX/ESXi-System, die die alte IP-Adresse verwenden, bleiben aktiv.

        Umgehung: Fügen Sie ein ESX/ESXi-System nicht zweimal hinzu.

      • Beim Neustart von "mgmt-vmware" wird "vmware-webAccess" nicht ebenfalls neu gestartet
        Wenn Sie den Dienst "mgmt-vmware" neu starten, wird der Dienst "vmware-webAccess" nicht neu gestartet. Stattdessen wird der Dienst nach einer Weile beendet, sodass Sie Web Access nicht für eine Verbindung zum ESX-Host verwenden können..

        Umgehung: Starten Sie den Dienst "vmware-webAccess" manuell. Führen Sie dazu folgenden Befehl an der ESX-Servicekonsole aus: service vmware-webAccess start

      • Unter Suse Enterprise Linux fehlt auf virtuellen Maschinen im Dropdown-Menü "Adaptertyp" die Option "vmxnet3"
        Auf einer virtuellen Maschine, auf der SLES 10 oder SLES 11 ausgeführt wird, und für die als Typ des Gastbetriebssystems "SLES" ausgewählt ist, ist vmxnet3 im Dropdown-Menü Adaptertyp nicht enthalten. Das Problem tritt am ehesten in virtuellen Maschinen auf, die von ESX Server 3.x auf ESX 4.x migriert wurden. Es kann aber auch unter anderen Umständen auftreten.

        Umgehung: Die Option vmxnet3 wird verfügbar, wenn Sie den Typ des Gastbetriebssystems von "SLES" in "SLES10" oder "SLES11" ändern.

        1. Schalten Sie die virtuelle Maschine aus.
        2. Klicken Sie mit der rechten Maustaste auf die virtuelle Maschine und wählen Sie Einstellungen bearbeiten.
        3. Klicken Sie auf der Registerkarte Optionenauf Allgemeine Optionen.
        4. Wählen Sie im Feld "Version" entweder SLES10 oder SLES11 aus.
      • Virtuelle Maschinen verschwinden aus dem Diagramm der virtuellen Switches in der Netzwerkansicht für die Hostkonfiguration
        Virtuelle Maschinen werden in der Netzwerkansicht auf der Registerkarte "Konfiguration" des vSphere-Clients für einen Host im Diagramm der virtuellen Switches dargestellt. Wenn Sie einen anderen Host auswählen und dann zur Registerkarte "Netzwerk" des ersten Hosts zurückkehren, verschwinden die virtuellen Maschinen möglicherweise aus dem Diagramm der virtuellen Switches.

        Umgehung: Wählen Sie auf der Registerkarte "Konfiguration" eine andere Ansicht, z. B. Netzwerkadapter, Speicher oder Speicheradapter, und kehren Sie zur Registerkarte "Netzwerk" zurück.

      • Das Verwenden von Sonderzeichen in den Namen virtueller Maschinen während deren Erstellung ergibt einen Fehler, wenn sie über vSphere Web Access mit vCenter Server verbunden sind
        Bei einer Verbindung zu vCenter Server mit vSphere Web Access löst die Verwendung von Sonderzeichen (z. B., "|\'{}[]-*^&@#!`~) im Namen der virtuellen Maschine währen der Erstellung den folgenden Fehler aus:
        Laufzeitfehler: Ein allgemeiner Systemfehler ist aufgetreten.

        Umgehung: Keine

      • vSphere Web Access zeigt die falsche CPU-Geschwindigkeit für die virtuelle Maschine an, nachdem die Anzahl der virtuellen Prozessoren erhöht wurde
        In vSphere Web Access werden im Abschnitt "Leistung" der Registerkarte "Übersicht" falsche Informationen zur CPU-Geschwindigkeit einer ausgewählten virtuellen Maschine angezeigt, nachdem die Anzahl der CPUs für die virtuelle Maschine erhöht wurde. Wenn beispielsweise die Anzahl der CPUs für eine virtuelle Maschine von 1 CPU mit einer Geschwindigkeit von 1,559 Mhz auf 2 CPUs erhöht wird, müsste vSphere Web Access die Anzahl der CPUs und ihre Geschwindigkeit als 2 x 1,559 Mhz anzeigen. Die CPU-Geschwindigkeit wird jedoch fälschlicherweise mit 3,117 (1,559 x 2) angezeigt.

        Umgehung: Keine

      • Wenn Sie die Nummer des HTTPS-Ports in der SFCB-Konfigurationsdatei ( sfcb.cfg) auf einen Port ändern, der nicht der Standardport ist, und den SFCB-Server (CIM) neu starten, erscheint der Systemstatus der Serverkomponenten des ESX/ESXi-Hosts nicht auf der Registerkarte "Hardwarestatus"
        Dasselbe passiert, wenn Sie sich direkt an einem ESX/ESXi-Host anmelden und auf die Registerkarte Konfiguration klicken, um den Systemstatus anzuzeigen. Statusinformationen für die Serverkomponenten erscheinen nicht.

        Dieses Problem tritt auf, weil vCenter Server und der SFCB-Server über verschieden Ports kommunizieren.

        Umgehung: Stellen Sie sicher, dass der SFCB-Server nur über den Standardport kommuniziert.

      • Starten oder Beenden des vctomcat-Webservice über die Windows-Eingabeaufforderung führt möglicherweise zu einer Fehlermeldung
        Wenn Sie auf Microsoft Windows-Betriebssystemen die Befehle net start und net stop verwenden, um den vctomcat-Webservice zu starten bzw. zu beenden, wird möglicherweise die folgende Fehlermeldung angezeigt:

        Der Dienst reagiert auf die Kontrollfunktion nicht.
        Weitere Informationen erhalten Sie, wenn Sie "NET HELPMSG 2186" eingeben.

        Umgehung: Sie können diese Fehlermeldung ignorieren. Wenn Sie möchten, dass die Fehlermeldung nicht mehr erscheint, bearbeiten Sie die Registrierung und erhöhen Sie den Zeitüberschreitungswert für den Service Control Manager (SCM). Weitere Informationen finden Sie in folgendem Microsoft-KB-Artikel: http://support.microsoft.com/kb/922918.

      • Überblicksleistungsdiagramme werden nach einem Upgrade von vCenter Server 2.5 mit mitgelieferter SQL Express-Datenbank nicht angezeigt
        Wenn Sie ein Upgrade von vCenter Server 2.5 auf vCenter Server 4.0 durchführen und dabei eine SQL Express-Datenbank involviert ist, werden die Überblicksleistungsdiagramme nicht angezeigt. Wenn Sie die Überblicksansicht auf der Registerkarte Leistung öffnen, wird folgender Fehler angezeigt:

        STATs Report service internal error

        Dieser Fehler tritt auf, weil das vCenter Server-Upgrade-Tool die vorhandene Datenbank nicht neu konfigurieren kann. Sie müssen die Konfiguration manuell durchführen.

        Umgehung:

        1. Wählen Sie Start > Programme > SQL Server Configuration Manager.
        2. Führen Sie im SQL Server Configuration Manager Folgendes aus:
          1. Wählen Sie Protocols for SQLEXP_VIM (Protokolle für SQLEXP_VIM).
          2. Wählen Sie TCP/IP.
          3. Wählen Sie unter "Enabled" True und unter "Listen All" Yes.
          4. Klicken Sie auf OK.
        3. Geben Sie in einem Befehlsfenster Services.msc ein, um den Dienst-Manager zu öffnen.
        4. Starten Sie in der Dienstliste die folgenden Dienste:
        • SQL Server 2005 Services: SQL Server (SQLEXP_VIM)
        • SQL Server 2005 Services: SQL-Browser (wenn der SQL-Browser-Dienst deaktiviert ist, markieren Sie ihn zum automatischen/manuellen Starten)
        • VMware vCenter-Dienst
        • VMware-Webservice
      • Ein Fehlermeldung erscheint, wenn Sie eine zweite virtuelle Festplatte zu einer virtuellen Maschine hinzufügen
        Angenommen, Sie erstellen eine virtuelle Maschine mit standardmäßigen Optionen, indem Sie Web Access verwenden, das mit ESX/ESXi 4.0 verbunden ist. Wenn Sie anschließend eine Verbindung von vSphere Web Access mit dem vCenter Server, der den ESX/ESXi-Host verwaltet, herstellen und mit der Option Neue virtuelle Festplatte erstellen derselben virtuellen Maschine eine zweite virtuelle Festplatte hinzufügen, erscheint die Fehlermeldung Die angegebene Datei ist bereits auf dem Server vorhanden.

        Umgehung: Verwenden Sie den vSphere-Client, um eine Verbindung zu vCenter Server herzustellen und der virtuellen Maschine eine zweite virtuelle Festplatte hinzuzufügen.

      • Der Befehl "vc-support" verwendet eine 64-Bit-DSN-Anwendung und kann keine Daten aus der vCenter Server-Datenbank abrufen
        Wenn Sie den VMware-Befehl cscript vc-support.wsf verwenden, um Daten aus der vCenter Server-Datenbank abzurufen, wird die Microsoft-Standardanwendung cscript.exe verwendet. Diese Anwendung verwendet einen 64-Bit-DSN und keinen 32-Bit-DSN, wie es für die vCenter Server-Datenbank erforderlich wäre. Demzufolge treten Fehler auf und es können keine Daten abgerufen werden.

        Umgehung: Übergeben Sie an der Eingabeaufforderung des Systems die Datei vc-support.wsf an die Anwendung cscript.exe (mit dem 32-Bit DSN) und führen Sie diese aus:

        %windir%\SysWOW64\cscript.exe vc-support.wsf

      • Das Menü "vSphere-Client-Rollen" zeigt für keine der vCenter Server-Systeme in einer Gruppe im verknüpften Modus Rollenzuweisungen an
        Wenn Sie auf einem vCenter Server-System in einer Gruppe im verknüpften Modus eine Rolle erstellen, werden die vorgenommenen Änderungen an alle anderen vCenter Server-Systeme der Gruppe weitergegeben. Die Rolle wird jedoch nur auf Systemen angezeigt, die über die mit der Rolle zugewiesenen Berechtigungen verfügen. Wenn Sie eine Rolle entfernen, prüft der Vorgang den Status der Rolle nur auf dem aktuell ausgewählten vCenter Server-System. Er entfernt die Rolle jedoch aus allen vCenter Server-Systemen in der Gruppe im verknüpften Modus, ohne dass eine Warnung ausgegeben wird, die darauf hinweist, dass die Rolle möglicherweise auf anderen Servern verwendet wird.

        Umgehung: Bevor Sie eine Rolle aus dem vCenter Server-System löschen, stellen Sie sicher, dass die Rolle nicht über andere vCenter Server-Systeme hinweg verwendet wird. Wechseln Sie zum Feststellen, ob eine Rolle verwendet wird, zur Ansicht "Rollen" und benutzen Sie die Navigationsleiste, um jedes vCenter Server-System in der Gruppe auszuwählen. Die Verwendung dieser Rolle wird für das ausgewählte vCenter Server-System angezeigt.

        Weitere Informationen über Best Practices für Benutzer und Gruppen sowie über das Festlegen von Rollen für vCenter Server-Gruppen im verknüpften Modus finden Sie im vSphere-Handbuch Grundlagen der Systemverwaltung .

      • Das Löschen von Snapshots und das Klonen von virtuellen Maschinen im laufenden Betrieb können bei hoher Arbeitslast der virtuellen Maschine lange dauern
        Das Löschen von Snapshots und das Klonen von virtuellen Maschinen im laufenden Betrieb können lange dauern, wenn die virtuelle Maschine eine hohe E/A-Arbeitslast zu bewältigen hat. Wenn die virtuelle Maschine beispielsweise auf ihre lokalen Festplatten schreibt, ist die E/A-Arbeitslast sehr hoch.

        Umgehung: Vermeiden Sie diese Vorgänge, wenn die virtuelle Maschine auf ihre lokalen Festplatten schreibt oder andere schwere E/A-Arbeitslasten ausführt. Dies kann dazu beitragen, die Durchführungszeiten zu reduzieren.

      • Unter Windows Server 2008 ist nach der Installation das Beitreten zu einer Gruppe im verknüpften Modus nicht erfolgreich, wenn die Benutzerkontensteuerung (UAC) aktiviert ist
        Wenn auf Windows Server 2008 mit einem 32- oder 64-Bit-Betriebssystem die Benutzerkontensteuerung (UAC) aktiviert ist und Sie versuchen, auf einem System, auf dem vCenter Server bereits ausgeführt wird, einer Gruppe im verknüpften Modus eine Maschine hinzuzufügen, ist die Verbindung nicht erfolgreich. Es wird jedoch keine Fehlermeldung angezeigt. In der Bestandsliste wird nur ein vCenter Server aufgeführt.

        Umgehung: Gehen Sie folgendermaßen vor.

        Führen Sie folgende Schritte durch, um die UAC auszuschalten, bevor Sie die Maschine einer Gruppe im verknüpften Modus hinzufügen:

        1. Wählen Sie Start > Einstellungen > Systemsteuerung > Benutzerkonten aus, um das Dialogfeld "Benutzerkonto" zu öffnen.
        2. Klicken Sie auf Benutzerkontosteuerung ein- oder ausschalten.
        3. Deaktivieren Sie die Option Benutzerkontensteuerung verwenden, um zum Schutz des Computers beizutragen und klicken Sie auf OK.
        4. Starten Sie die Maschine neu, wenn Sie dazu aufgefordert werden.

        Starten Sie die Konfiguration für den verknüpften Modus, wie nachfolgend beschrieben:

        1. Wählen Sie Start > Programme > VMware > vCenter Server-Konfiguration für den verknüpften Modus.
        2. Klicken Sie auf "Weiter".
        3. Wählen Sie Konfiguration für den verknüpften Modus ändern und klicken Sie auf Weiter.
        4. Klicken Sie auf vCenter Server-Instanz einer vorhandenen Gruppe für den verknüpften Modus oder einer anderen Instanz hinzufügenund klicken Sie auf Weiter.
        5. Geben Sie den Servernamen und die Informationen für den LDAP-Port an und klicken Sie auf Weiter.
        6. Klicken Sie auf Fortfahren, um die Installation abzuschließen.
        7. Klicken Sie auf Beenden, um den Verknüpfungsvorgang zu beenden.

        Melden Sie sich bei einem der vCenter Server-Systeme an und vergewissern Sie sich, dass die Server verknüpft sind. Sind die vCenter Server verknüpft, schalten Sie die UAC folgendermaßen wieder ein:

        1. Wählen Sie Start > Einstellungen > Systemsteuerung > Benutzerkonten aus, um das Dialogfeld "Benutzerkonto" zu öffnen.
        2. Klicken Sie auf Benutzerkontosteuerung ein- oder ausschalten.
        3. Aktivieren Sie die Option Benutzerkontensteuerung verwenden, um zum Schutz des Computers beizutragen und klicken Sie auf OK.
        4. Starten Sie die Maschine neu, wenn Sie dazu aufgefordert werden.

      • Durch das Entfernen eines aktiven virtuellen Switches einer virtuellen Maschine wird möglicherweise eine Fehlermeldung ausgegeben
        Falls Sie versuchen, einen virtuellen Switch zu entfernen, den eine eingeschaltete virtuelle Maschine verwendet, wird eine Fehlermeldung ausgegeben. Die Meldung dient dazu, Sie zu warnen, dass der virtuelle Switch verwendet wird und daher nicht entfernt werden kann. In einem solchen Fall kann das Entfernen des virtuellen Switches dazu führen, dass die virtuelle Maschine nicht mehr verwendet werden kann.

        Umgehung: Entfernen Sie keinen virtuellen Switch, der in Gebrauch ist.

      • Sie können die Symbolleiste in der Ansicht "Berichte" auf der Registerkarte "Speicheransichten" nicht wieder anzeigen, nachdem Sie sie ausgeblendet haben
        Zur Ansicht "Berichte" auf der Registerkarte Speicheransichten gehört eine Symbolleiste, die ein Menü für das Filtern von Objekten und ein Suchfeld enthält. Diese Steuerelemente ermöglichen es Ihnen, die Berichtstabellen basierend auf Objekttyp, Speicherattributen und Schlüsselwörtern zu filtern. Wenn Sie die Symbolleiste über die Option Ausblenden ihres Kontextmenüs ausblenden, fehlt eine adäquate Möglichkeit, die Symbolleiste wieder anzuzeigen.

        Umgehung: Schließen Sie den vSphere-Client und starten Sie ihn erneut.

      • Das Beitreten von zwei vCenter Server-Instanzen schlägt mit einer Fehlermeldung in der Datei "status.txt" über das Misslingen des Entfernens von VMwareVCMSDS fehl
        Das Beitreten einer vorhandenen eigenständigen vCenter Server-Instanz zu einer Gruppe im verknüpften Modus führt dazu, dass das vCenter Server-Installationsprogramm fehlschlägt. Wenn dies geschieht, wird vCenter Server nicht auf der Maschine gestartet, auf der Sie die Installation durchführen. Zudem werden Meldungen, die sich mit LDAP-Konnektivitäts- oder Unerreichbarkeitsproblemen befassen, in die Datei /status.txt geschrieben, wobei das auf dem Windows-System definierte temporäre Verzeichnis ist. Öffnen Sie zum zu Diagnostizieren dieses Problems die Datei status.txt und suchen Sie die folgende Meldung: [2009-03-06 21:44:55 SEVERE] Operation "Join instance VMwareVCMSDS" failed: : Action: Join Instance
        Action: Removal of standalone instance
        Action: Remove Instance
        Problem: Removal of instance VMwareVCMSDS failed: The removal wizard was not able to remove all of the components. To complete removal, run "Adamuninstall.exe /i: " after resolving the following error:

        Folder ' \VMwareVCMSDS' could not be deleted.
        Das Verzeichnis ist nicht leer.

        Umgehung: Führen Sie die folgenden Schritte aus:

        1. Wechseln Sie mit Administratorrechten von einer Eingabeaufforderung aus in das vCenter Server-Installationsverzeichnis.
        2. Löschen Sie das Verzeichnis VMwareVCMSDS.
        3. Stellen Sie die lokale LDAP-Instanz her, indem Sie jointool.bat recover eingeben.
      • vCenter Server 4.0 reagiert in großen Umgebungen nicht mehr, wenn er ESX Server 3.5-Hosts vor ESX 3.5 Patch 10 verwaltet
        vCenter Server 4.0 reagiert in großen Umgebungen nach 30 Tagen möglicherweise nicht mehr, wenn er ESX Server 3.5-Hosts vor ESX Server 3.5 Patch 10 verwaltet.

        Umgehung: Aktualisieren Sie auf ESX Server 3.5 Update 4, wenn Sie ESX Server 3.5 mit vCenter Server 4.0 ausführen.

      • Networking problems and errors might occur when analyzing machines with VMware Guided Consolidation
        Wird eine große Zahl von Maschinen für Guided Consolidation analysiert, kann die Guided Consolidation-Komponente vCenter Collector Provider Service von dem Betriebssystem, auf dem die Guided Consolidation-Funktionalität installiert ist, für einen Virus oder einen Wurm gehalten werden. Dies tritt auf, wenn der Analysevorgang eine große Zahl von Maschinen findet, deren IP-Adressen ungültig sind oder bei denen Probleme bei der Namensauflösung auftreten. Dabei kommt es zu einem Engpass im Netzwerk und es werden entsprechende Fehlermeldungen angezeigt.

        Umgehung: Fügen Sie keine Maschinen zur Analyse hinzu, die nicht erreichbar sind. Wenn Sie Maschinen über den Namen hinzufügen, stellen Sie sicher, dass der NetBIOS-Name aufgelöst werden kann und dass der Rechner erreichbar ist. Wenn Sie Maschinen über die IP-Adresse hinzufügen, stellen Sie sicher, dass es sich um eine statische IP-Adresse handelt.

      • Es werden mehrere SSL-Warnmeldungen angezeigt, wenn vCenter Server-Systeme einer Gruppe im verknüpften Modus beitreten
        Wenn mehrere vCenter Server-Systeme einer Gruppe im verknüpften Modus beitreten und Sie keine SSL-Zertifikate zur Authentifizierung verwenden, werden möglicherweise im vSphere-Client beim Anmelden mehrere SSL-Warnungen angezeigt.

        Umgehung: Reagieren Sie auf jede einzelne Warnung. Aktivieren Sie für jeden Host die Option Dieses Zertifikat immer ignorieren. Sie müssen vCenter Server für die Verwendung von SSL-Zertifikaten konfigurieren.

      • Keine Verbindung mit vSphere Web Access zu vCenter Server, wenn Sie den HTTP-Port vom vSphere-Client aus geändert haben
        Wenn Sie über den vSphere-Client eine Verbindung mit dem vCenter Server hergestellt haben, können Sie den HTTP-Port von vCenter Server ändern ( Verwaltung > vCenter Server-Einstellungen > Webservice > Ports > HTTP). Dieser Port ermöglicht die Verbindung mit vCenter Server über vSphere Web Access. Wenn Sie den HTTP-Port ändern, ist vSphere Web Access möglicherweise für alle Benutzer nicht mehr erreichbar.

        Umgehung: Führen Sie die folgenden Schritte aus, um die Porteinstellungen in den Konfigurationsdateien von vSphere Web Access zu ändern, damit Verbindungen über den von Ihnen angegebenen Port möglich sind.

        1. Melden Sie sich bei der vCenter Server-Maschine an und öffnen Sie folgendes Verzeichnis:

          C:\Programme\VMware\Infrastructure\tomcat\webapps\jslib-1.0.157180
          \modules\com.vmware.webaccess.app_1.0.0


          Wenn Sie vCenter Server in einem anderen Verzeichnis als C:\Programme\ installiert haben, wählen Sie den entsprechenden Pfad.
        2. Öffnen Sie die Datei WebAccess.properties und aktualisieren Sie wie folgt den Wert login_url mit der Portnummer, die Sie im vSphere-Client angegeben haben:

          Aktueller Wert: http://localhost:80/sdk
          Neuer Wert: http://localhost:[Neuer_Port]/sdk
        3. Klicken Sie mit der rechten Maustaste auf Arbeitsplatz und wählen Sie Verwalten.
        4. Wählen Sie unter Dienste und Anwendungen die Option Dienste, suchen Sie "VMware VirtualCenter Management Webservices" und starten Sie den Dienst neu.

          HINWEIS: Ein Neustart des Dienstes wirkt sich auf die Verbindungen mit vCenter Server-Systemen im verknüpften Modus sowie auf vorhandene vSphere Web Access-Verbindungen aus.
        5. Löschen Sie den Cache Ihres Browsers.
        6. Verwenden Sie http://localhost: /ui, zum Herstellen einer Verbindung mit vCenter Server über vSphere Web Access.
      • vSphere-Client zeigt falsche Informationen im Abschnitt "Allgemein" der Registerkarte "Übersicht" für Hosts an
        Bei großer Auslastung kann es vorkommen, dass das rechte Fenster des vSphere-Clients nicht aktualisiert wird und daher im Abschnitt Allgemein falsche Informationen anzeigt.

        Umgehung: Sie müssen möglicherweise den vSphere-Client manuell aktualisieren, indem Sie einen anderen Host auswählen und anschließend den ersten Host erneut auswählen.

      • Wenn Sie bei großen vCenter Server-Bestandslisten den vSphere-Client im verknüpften Modus öffnen und dabei die Bestandslisten aller vCenter Server-Systeme vollständig erweitert sind, reagiert der vSphere-Client möglicherweise für einige Minuten nicht
        vSphere-Client-Bestandslisten sind dann vollständig erweitert, wenn Cluster und Datencenter erweitert sind. Wenn Sie den vSphere-Client schließen, nachdem die Bestandslisten erweitert wurden, wird die erwartete Bestandslistenansicht beim nächsten Öffnen des Clients geladen. Als Folge davon reagiert der vSphere-Client möglicherweise für einige Minuten nicht mehr, abhängig von der Anzahl der vCenter Server-Systeme und der Anzahl der Objekte in den Bestandslisten der jeweiligen vCenter Server-Systeme. Der vSphere-Client reagiert wird, nachdem alle Bestandslistenobjekte geladen wurden.

        Umgehung: Es wird empfohlen, bei einer Gruppe im verknüpften Modus nicht die Knoten alle vCenter Server-Systeme in der Bestandsliste zu erweitern. Reduzieren Sie die Knoten, bevor Sie den vSphere-Client schließen, um das Laden der erweiterten Knoten beim Start zu vermeiden.

      • Der Hardwarestatusdienst unterstützt keine Hosts vor ESX Server 3.5 Update 4
        Hardwarestatusalarme werden für Hosts der Version ESX Server 3.5 Update 3 und früher nicht ausgelöst. Wenn Sie mit dem vSphere-Client die Registerkarte Hardwarestatus für einen Host anzeigen lassen, auf dem ESX Server 3.5 Update 3 oder früher ausgeführt wird, wird die Meldung angezeigt, dass für die Überwachung des Hardwaresystemstatus ESX Server 3.5 Update 4 oder höher oder ESXi erforderlich ist.

        Umgehung: Damit die Hardwarestatusüberwachung auf ESX Server 3.5 Update 3 oder früher unterstützt wird, installieren Sie Patch 11 für ESX Server 3.5 (ESX350-200901407-BG), der in ESX Server 3.5 Update 4 enthalten ist.

      • Deaktivierte Alarme für Bestandslistenobjekte werden aktiviert, wenn vCenter Server neu gestartet wird
        Wenn in vCenter Server ein Alarm für ein Bestandslistenobjekt, wie z. B. für einen Host, eine virtuelle Maschine, einen Datenspeicher usw., deaktiviert und vCenter Server neu gestartet wird, werden die Alarme nach Abschluss eines Neustarts von vCenter Server aktiviert.

        Umgehung: Deaktivieren Sie die Alarme für die entsprechenden Bestandslistenobjekte, wenn vCenter Server neu gestartet wurde.

      • Im gemeinsam genutzten Speicher gespeicherte VM-Vorlagen stehen nicht mehr zur Verfügung, nachdem DPM (Distributed Power Management) einen Host in den Standby-Modus versetzt oder wenn ein Host in den Wartungsmodus versetzt wird
        Der vSphere-Client weist VM-Vorlagen einem bestimmten Host zu. Wenn der Host, auf dem die VM-Vorlagen gespeichert sind, in den Wartungsmodus oder von DPM in den Standby-Modus versetzt wird, scheinen im vSphere-Client die Vorlagen deaktiviert zu sein. Dieses Verhalten tritt auch dann auf, wenn die Vorlagen im gemeinsam genutzten Speicher gespeichert werden.

        Umgehung: Deaktivieren Sie DPM auf dem Host, auf dem die VM-Vorlagen gespeichert sind. Befindet sich der Host im Wartungsmodus, verwenden Sie den Datenspeicherbrowser auf einem anderen Host, der sich nicht im Wartungs- oder Standby-Modus befindet und ebenfalls Zugriff auf den Datenspeicher hat, auf dem die Vorlagen gespeichert sind, um die VM-Vorlagen zu suchen. Sie können dann virtuelle Maschinen unter Verwendung dieser Vorlagen bereitstellen.

      • Bei der Neuinstallation der vSphere-CLI auf manchen Windows-Plattformen, z. B. Windows Vista Enterprise SP1 32 Bit, kann ein LibXML DLL-Modulladefehler auftreten
      • Fehlerhafte Links auf der ESX- und der ESXi-Begrüßungsseite
        Die Download-Links im vSphere Remote Command Line-Abschnitt, im vSphere Web Services SDK-Abschnitt sowie die Links zum Herunterladen der vSphere 4-Dokumentation und von VMware vCenter auf der Begrüßungsseite von ESX und ESXi sind falsch zugeordnet.
        Umgehung: Laden Sie die Produkte von der VMware-Website herunter.
      • Auf Nexus 1000v kann Distributed Power Management einen Host nicht in den Standby-Modus versetzen
        Wenn ein Host weder Integrated Lights-Out (iLO) noch Intelligent Platform Management Interface (IPMI) für Distributed Power Management (DPM) unterstützt, kann dieser Host weiterhin DPM verwenden, vorausgesetzt, alle physischen Netzwerkkarten auf dem Host, die zu Nexus 1000V DVS hinzugefügt werden, verfügen über Wake-On-LAN-Unterstützung. Selbst wenn nur eine der physischen Netzwerkkarten keine Wake-On-LAN-Unterstützung bietet, kann der Host nicht von DPM in den Standby-Modus versetzt werden.

        Umgehung: Keine.

      Verwaltung von virtuellen Maschinen

      • VMXNET 3-Netzwerkadapter werden während eines OVF-Exports von virtuellen Maschinen nicht mit exportiert
        Wenn Sie einen OVF-Export (Open Virtualization Format) über VirtualCenter durchführen, werden virtuelle Maschinen mit VMXNET 3-Netzwerkadaptern mit VMXNET-Netzwerkadaptern exportiert. Dies führt dazu, dass virtuelle Maschinen aus dieser Vorlage mit VMXNET-Netzwerkadaptern statt mit VMXNET 3-Netzwerkadaptern bereitgestellt werden. Dieses Problem tritt auf, wenn Sie eine Verbindung mit dem ESX-Host unter Verwendung des im Lieferumfang von vSphere 4.0 Update 4 enthaltenen vSphere-Clients herstellen.

        Umgehung: Keine.

      • Nach dem Upgrade einer virtuellen Maschine unter Windows 2000 von Hardwareversion 4 nach Hardwareversion 7 erscheint die Aufforderung, eine PCI Standard-PCI-zu-PCI-Brücke zu installieren
        Wenn Sie auf einer virtuellen Maschine unter Windows 2000 ein Upgrade von Hardwareversion 4 nach Hardwareversion 7 durchführen, kann es sein, dass einige Popup-Meldungen angezeigt werden, die Sie auffordern, eine PCI Standard-PCI-zu-PCI-Brücke zu installieren. Diese Meldungen können ignoriert werden.

        Umgehung: Akzeptieren Sie alle Aufforderungen, um das Upgrade der Hardwareversion abzuschließen.

      • Benutzerdefinierte Skripts, die in vmware-toolbox dem Ereignis "Anhalten" zugewiesen sind, werden nicht ausgeführt, wenn Sie die virtuelle Maschine vom vSphere-Client aus anhalten
        Wenn Sie in der Registerkarte Skript von vmware-toolbox dem Ereignis "Anhalten" ein benutzerdefiniertes Skript zugewiesen und die virtuelle Maschine so konfiguriert haben, dass, wenn Sie Anhalte-Skripts starten, VMware Tools-Skripts ausgeführt werden, geschieht dies nicht, falls Sie die virtuelle Maschine vom vSphere-Client aus anhalten.

        Umgehung: Keine

      • Wenn bei einem automatischen Upgrade der VMware Tools das Gastbetriebssystem eingeschaltet wird, wird das Gastbetriebssystem automatisch neu gestartet, ohne dass eine Neustartbenachrichtigung ausgegeben wird
        Wenn Sie angeben, dass auf einem Windows Vista- oder Windows 2008-Gastbetriebssystem die VMware Tools automatisch aktualisiert werden sollen, wenn das Betriebssystem eingeschaltet wird, werden VMware Tools aktualisiert und das Gastbetriebssystem automatisch neu gestartet, ohne dass eine Neustartbenachrichtigung ausgegeben wird.

        Umgehung: Keine

      • Ein Dialogfeld, in dem der Benutzer zur Eingabe von Sysprep-Dateiinformationen aufgefordert wird, erscheint möglicherweise beim Klonen und Anpassen von virtuellen Maschinen
        Wenn Sie eine virtuelle Maschine klonen und anpassen, wird der Vorgang möglicherweise nicht abgeschlossen und ein Sysprep-Dialogfeld fordert Sie möglicherweise auf, zusätzliche Dateien anzugeben.

        Umgehung: Führen Sie die folgenden Schritte aus:

        1. Beachten Sie die Liste der fehlenden Dateien, die das Mini-Setup von Windows nicht finden kann.
        2. Kopieren Sie die benötigten Dateien (beispielsweise c_20127.nls) von der Quellmaschine in den Ordner mit den Sysprep-Installationsdateien, c:\sysprep\i386. Die von Sysprep angeforderten Dateien befinden sich normalerweise an folgendem Speicherort auf der virtuellen Quellmaschine: C:\Windows\system32.
        3. Führen Sie das Klonen mit Anpassung durch.

        Hinweis:Das Sysprep-Verzeichnis wird entfernt, nachdem die virtuelle Maschine gestartet wurde und die Anpassung abgeschlossen ist.

      • Bei virtuellen Maschinen, die ein Windows NT-Gastbetriebssystem ausführen, muss nach einem Upgrade der virtuellen Hardware von Version 4 auf Version 7 der Netzwerkadaptertreiber neu installiert werden
        Nach einem Upgrade der virtuellen Hardware auf einem Windows NT-Gastbetriebssystem kann die virtuelle Maschine keine IP-Adressen abrufen, da Windows NT die Plug-und-Play-Spezifikation nicht voll unterstützt.

        Umgehung: Installieren Sie nach einem Upgrade der virtuellen Hardware von Version 4 auf Version 7 auf einer virtuellen Maschine, auf der Windows NT ausgeführt wird, den Netzwerkadaptertreiber neu, indem Sie die folgenden Schritte durchführen.

        1. Klicken Sie mit der rechten Maustaste auf Netzwerkumgebung und wählen Sie Eigenschaften aus.
        2. Wählen Sie die Registerkarte Adapter aus.
        3. Entfernen Sie den vorhandenen Adapter.
        4. Fügen Sie einen neuen Adapter hinzu.
        5. Wählen Sie bei einem AMD PCNet-Treiber AMD PCNET Family Ethernet adapter aus und geben Sie als Pfad C:\winnt\system32 an.
          Klicken Sie bei einem vmxnet-Treiber auf Diskette und geben Sie als Pfad C:\Programme\VMware\VMware Tools\Drivers\vmxnet\ an.
        6. Starten Sie die virtuelle Maschine neu.
      • Eine IDE-Festplatte, die einer virtuellen Maschine mit der Hardwareversion 7 hinzugefügt wurde, wird als Festplatte 1 definiert, auch wenn bereits eine SCSI-Festplatte vorhanden ist
        Wenn Sie einer virtuellen Maschine mit der Hardwareversion 7, die über eine als Festplatte 1 definierte SCSI-Festplatte verfügt, eine IDE-Festplatte hinzufügen, ändert die virtuelle Maschine die Plattennummerierung. Die IDE-Festplatte wird als Festplatte 1 definiert und die SCSI-Festplatte wird zu Festplatte 2.

        Umgehung: Keine. Verlassen Sie sich jedoch nicht ausschließlich auf die Plattennummer, wenn Sie sich entschließen, eine der Festplatten zu löschen. Überprüfen Sie stattdessen den Plattentyp, um sicherzustellen, dass Sie die richtige Platte löschen.

      • Das Wiederherstellen eines Snapshots funktioniert möglicherweise nicht, wenn Sie mittels Cold-Migration eine virtuelle Maschine mit einem Snapshot von einem ESX/ESXi 3.5-Host auf einen ESX/ESXi 4.0-Host verlagern
        Sie können mittels Cold-Migration eine virtuelle Maschine mit Snapshots von einem ESX/ESXi 3.5-Host auf einen ESX/ESXi 4.0-Host verlagern. Dennoch funktioniert das Wiederherstellen eines Snapshots nach der Migration möglicherweise nicht.

        Umgehung: Keine

      • Der vCenter Server schlägt fehl, wenn die Delta-Festplattentiefe einer virtuellen Maschine vom Typ "Verknüpfter Klon" größer ist als die unterstützte Tiefe von 32
        Wenn die Delta-Festplattentiefe eines verknüpften Klons größer ist als die unterstützte Tiefe von 32, schlägt der vCenter Server fehl. Folgende Fehlermeldung wird angezeigt:

        Win32-Ausnahme: Stapelüberlauf

        Unter diesen Umständen kann der vCenter Server erst dann neu gestartet werden, wenn Sie die virtuelle Maschine von dem Host entfernt oder die vCenter Server-Datenbank bereinigt haben. Erwägen Sie, die virtuelle Maschine von dem Host zu entfernen statt die vCenter Server-Datenbank zu bereinigen, da dies sicherer ist.

        Umgehung: Führen Sie die folgenden Schritte aus:

        1. Melden Sie sich beim vSphere-Client auf dem Host an.
        2. Zeigen Sie den Klon der virtuellen Maschine in der Bestandsliste an.
        3. Klicken Sie mit der rechten Maustaste auf die virtuelle Maschine und wählen Sie Von Festplatte löschen.
        4. Starten Sie den vCenter Server neu.

        Hinweis: Wenn nach dem Neustart von vCenter Server die virtuelle Maschine in der Bestandsliste im vSphere-Client angezeigt wird und die Option Aus Bestandsliste entfernen im Kontextmenü der virtuellen Maschine deaktiviert ist, müssen Sie den Eintrag für die virtuelle Maschine manuell aus der vCenter-Datenbank entfernen.

      • Das Erstellen einer neuen SCSI-Festplatte in einer virtuellen Maschine kann dazu führen, dass eine ungenaue Fehlermeldung ausgegeben wird
        Wenn Sie eine neue SCSI-Festplatte in einer virtuellen Maschine erstellen und den SCSI-Bus auf virtual setzen, wird folgende Fehlermeldung ausgegeben:

        Stellen Sie sicher, dass die virtuelle Festplatte unter Verwendung der Option "Thick" erstellt wurde.

        Allerdings ist Thickkeine gültige Option. Die korrekte Option lautet eagerzeroedthick.

        Umgehung: Erstellen Sie die SCSI-Festplatte mit dem Befehlszeilenbefehl vmkfstoolsund der Option eagerzeroedthick.
      • Die Optionen für den Installationsstartvorgang einer virtuellen Maschine werden nicht in das Open Virtualization Format (OVF) exportiert
        Wenn Sie auf einer virtuellen Maschine, auf der die Option "Installationsstartvorgang" aktiviert ist, ein OVF-Paket erstellen, wird diese Option während des Exports ignoriert. Daher fehlt im OVF-Deskriptor das Element InstallSection, das Informationen zum Installationsvorgang liefert. Wenn Sie ein OVF-Paket bereitstellen, wird das Element InstallSection ordnungsgemäß analysiert.

        Umgehung: Nachdem die virtuelle Maschine nach OVF exportiert wurde, erstellen Sie die InstallSection-Parameter manuell im OVF-Deskriptor. Ist eine Manifestdatei ( .mf) vorhanden, müssen Sie sie im Anschluss an die Änderung des OVF-Deskriptors regenerieren.

        Beispiel: Legt fest, dass ein Installationsstart notwendig ist.

        Die Aufnahme der InstallSection-Parameter in den Deskriptor informiert den Bereitstellungsvorgang darüber, dass für den Abschluss der Bereitstellung ein Installationsstartvorgang erforderlich ist. Das Attribut ovf:initialBootStopDelay definiert die Startverzögerung.

        Einzelheiten hierzu finden Sie in der OVF-Spezifikation.

      • Eine von einem Snapshot einer virtuellen Maschine mit einem LSI SAS-Controller geklonte virtuelle Maschine wird evtl. fälschlicherweise mit einem BusLogic-Controller konfiguriert
        Wenn Sie einen Snapshot einer virtuellen Maschine mit einem LSI SAS-Controller erstellen und anschließend von dem Snapshot eine virtuelle Maschine klonen, wird für die von dem Snapshot geklonte virtuelle Maschine möglicherweise ein BusLogic- statt eines LSI SAS-Controllers in den VM-Eigenschaften konfiguriert.

        Umgehung: Überprüfen Sie in der Eigenschaft "Snapshot.config" den Controllertyp der virtuellen Maschine, die Sie anhand eines Snapshots einer virtuellen Maschine, die über einen LSI SAS-Controller verfügt, geklont haben. Konfigurieren Sie nach Bedarf den Controllertyp für die geklonte virtuelle Maschine.

      •  Die virtuelle Maschine kann nicht gestartet werden, nachdem mit iLO ein virtuelles CD-ROM-Laufwerk ohne Medium als ein SCSI-Gerät hinzugefügt wurde
        Nachdem mit iLO (Integrated Lights-Out) ein virtuelles CD-ROM-Laufwerk ohne Medium als SCSI-Gerät zur virtuellen Maschine hinzugefügt wurde, kann die virtuelle Maschine nicht gestartet werden, wenn Sie versuchen, von der virtuellen CD-ROM zu starten.

        Es gibt drei Umgehungen für dieses Problem:
        • Stellen Sie sicher, dass das virtuelle iLO-CD-ROM-Laufwerk immer ein Medium enthält, wenn es angeschlossen ist und von einer beliebigen virtuellen Maschine verwendet wird.
        • Wenn das virtuelle CD-ROM-Laufwerk nicht zur Installation des Gastbetriebssystems auf der virtuellen Maschine verwendet wird, ändern Sie die Startreihenfolge im BIOS der virtuellen Maschine, sodass Festplatte, Diskettenlaufwerk und Netzwerkkarte vor dem CD-ROM-Laufwerk aufgeführt werden.
        • Verwenden Sie kein virtuelles iLO-CD-ROM-Laufwerk. ESX kann sowohl lokale als auch Remote-CD-ROM-Laufwerke und ISO-Images mit den virtuellen Maschinen verbinden, ohne die Einschränkung durchzusetzen, dass nur ein CD-ROM-Laufwerk von iLO auf einem System angezeigt wird.

      vMotion und Storage vMotion

      • Nach dem Neukonfigurieren und Verlagern der virtuellen Maschine kann das Wiederherstellen eines Snapshots fehlschlagen
        Wenn Sie die Eigenschaften einer virtuellen Maschine neu konfigurieren und sie auf einen anderen Host verschieben, kann das Wiederherstellen eines zuvor erstellten Snapshots fehlschlagen.

        Umgehung: Vermeiden Sie es, virtuelle Maschinen auf einen Host zu verschieben, dessen Eigenschaften sich sehr von denen des ursprünglichen Hosts unterscheiden (z. B. verschiedene Versionen, verschiedene CPU-Typen usw.)

      • Bei der Verwendung von Storage vMotion für die Migration einer virtuellen Maschine mit vielen Festplatten kann es zu Zeitüberschreitungen kommen
        Die Migration einer virtuellen Maschine mit vielen virtuellen Festplatten unter Verwendung von Storage vMotion kann möglicherweise nicht abgeschlossen werden. Der Storage vMotion-Vorgang benötigt während der abschließenden Kopierphase Zeit für das Öffnen, Schließen und Verarbeiten von Festplatten. Wegen dieses plattenbezogenen Overheads kann es bei Storage vMotion-Migrationen von virtuellen Maschinen mit vielen Festplatten zur Zeitüberschreitung kommen.

        Umgehung: Erhöhen Sie den Wert für die Storage vMotion-Einstellung fsr.maxSwitchoverSeconds in der Konfigurationsdatei der virtuellen Maschine. Die Standardeinstellung beträgt 100 Sekunden. Oder vermeiden Sie es, während der Storage vMotion-Migration auf den betroffenen Datenspeichern viele Bereitstellungsvorgänge, Migrationen oder Einschalt- und Abschaltvorgänge durchzuführen.

      • Storage vMotion unterstützt die Konvertierung von Quell-RDMs in Ziel-NFS-Volumes nicht
        Storage vMotion nur für Festplatten schlägt bei RDMs im virtuellen Modus fehl, wenn Sie auf NFS-Volumes Festplatten in die Formate "Flach" oder "Geringe Datendichte" konvertieren.

        Umgehung: Führen Sie zum Migrieren von RDMs im virtuellen Modus nach NFS-Volumes folgende Schritte aus:

        1. Verwenden Sie Storage vMotion, um über ein SAN, lokal oder über ein iSCSI-Volume eine RDM-VM-Festplatte in den Festplattentyp "Flach/Geringe Datendichte" zu konvertieren.
        2. Verwenden Sie Storage vMotion, um die konvertierten Festplatten von der SAN, lokal oder vom iSCSI-Laufwerk auf ein NFS-Laufwerk zu verlagern.
      • Storage vMotion eines NFS-Volumes wird möglicherweise von dem NFS-Serverfestplattenformat überschrieben
        Wenn Sie Storage vMotion zum Migrieren einer virtuellen Festplatte auf ein NFS-Volume oder für die Bereitstellung von virtuellen Maschinen, bei der NFS-Volumes einbezogen werden, verwenden, wird das Festplattenformat von dem NFS-Server bestimmt, auf dem sich das NFS-Volume befindet. Falls Sie eine Auswahl im Menü Festplattenformat getroffen haben, wird sie damit außer Kraft gesetzt.

        Umgehung: Keine

      • Wenn ESX/ESXi-Hosts ausfallen oder während Storage vMotion neu gestartet werden, kann der Vorgang fehlschlagen und die virtuellen Maschinen können verwaisen
        Wenn Hosts ausfallen oder während Storage vMotion neu gestartet werden, kann der vMotion-Vorgang fehlschlagen. Die virtuellen Festplatten der virtuellen Zielmaschine können nach einem Neustart des Hosts in der Bestandsliste als verwaist erscheinen. In der Regel wird der Status der virtuellen Maschine beibehalten, bevor der Host heruntergefahren wird.

        Überprüfen Sie, falls die virtuelle Maschine nicht mit dem Status "verwaist" aufgeführt wird, ob die Ziel-VMDK-Dateien vorhanden sind.

        Umgehung: Sie können die verwaiste virtuelle Zielmaschine manuell aus der vSphere-Bestandsliste löschen. Suchen Sie im Datenspeicher nach weiteren verwaisten Zielfestplatten und löschen Sie sie.

      • Storage vMotion steht mit Remote-CD/DVD- und Disketten-Geräteverbindungen in Konflikt
        CD/DVDs und Disketten werden von Storage vMotion nicht als Remote-Sicherungsgeräte unterstützt. Dennoch bleibt, wenn Sie Storage vMotion auf einer eingeschalteten, von ESX/ESXi 4.0 gehosteten virtuellen Maschine ausführen, das Symbol für den Aufbau und das Trennen der Verbindung zu CD/DVD- und Diskettenlaufwerken in der Symbolleiste aktiv und ermöglicht Ihnen, diese Geräte während der Laufzeit von Storage vMotion hinzuzufügen, obwohl dies Fehler verursachen könnte.

        Umgehung: Trennen Sie die bestehenden Verbindungen zu allen Remote-CD/DVD- und -Diskettenlaufwerken, bevor Sie Storage vMotion starten, indem Sie auf das entsprechende Symbol klicken.

      • Der Fehlermodus von Storage vMotion kann dazu führen, dass eine virtuelle Maschine ausgeschaltet wird
        Wenn Storage vMotion auf einem ESX/ESXi 4.0-Host verwendet wird und das Verschieben von Daten wegen eines flüchtigen Fehlers (z. B.: nicht genügend Arbeitsspeicher) fehlschlägt, ist es möglich, dass Storage vMotion nicht erfolgreich beendet wird, sich die Migrationsleistung verschlechtert oder die virtuelle Quellmaschine ausgeschaltet wird.

        Umgehung: Schalten Sie die virtuelle Maschine ein.

      • Auf ESX/ESXi 3.5-Hosts zeigt Storage vMotion nicht den korrekten Festplattentyp an, falls sich dieser während der Laufzeit von Storage vMotion ändert
        Der Storage vMotion-Assistent bietet eine Option an, mit der Festplattentypen für virtuelle Maschinen konvertiert werden können (von "Thick" zu "Thin" und umgekehrt). Dies gilt für alle ESX/ESXi-Host-Versionen. Nachdem eine Festplatte konvertiert wurde und Storage vMotion beendet ist, wird der Festplattentyp für ESX/ESXi 3.5-Hosts nicht ordnungsgemäß angezeigt. Der vSphere-Client zeigt immer noch den alten Festplattentyp an.

        Umgehung: Schalten Sie die virtuelle Maschine aus, heben Sie die Registrierung auf und registrieren Sie sie erneut.

      • Auf einer lokalen Datenspeicher gespeicherte virtuelle Maschinen werden nicht vom Host migriert, wenn sich der Host im Wartungsmodus befindet
        Auf einer lokalen Datenspeicher gespeicherte virtuelle Maschinen werden nicht vom Host migriert, wenn sich der Host im Wartungsmodus befindet.

        Umgehung: Verschieben Sie die virtuellen Maschinen auf lokalen Datenspeichern manuell auf einen anderen Host, falls sie weiterhin zur Verfügung stehen müssen, während sich der aktuell Host im Wartungsmodus befindet.

      • Das Verwenden von Storage vMotion zum Verlagern einer virtuellen Maschine zurück in deren Quellvolume führt möglicherweise zu einem Fehler des Typs "Unzureichender Festplattenspeicher"
        Wenn Sie Storage vMotion zum Verschieben einer virtuellen Maschine in einen anderen Datenspeicher und anschließend zurück in deren Quellvolume verwenden, aktualisiert der vSphere-Client die Größe des Quelldatenspeichers nicht sofort, was zu einem Fehler führt.

        Umgehung: Aktualisieren Sie den Datenspeicher im vSphere-Client. Falls sich nach dem ersten Versuch die gemeldete Größe des Datenspeichers nicht ändert, warten Sie 30 Minuten und versuchen Sie es erneut.

      VMware High Availability und Fault Tolerance

      • Failover auf sekundäre virtuelle VMware FT-Maschine führt zu Fehlermeldung auf dem Host-Client
        Wenn VMware-Fehlertoleranz ein Failover auf eine sekundäre virtuelle Maschine durchführt und der für die sekundäre virtuelle Maschine ausgewählte Host erst kürzlich neu gestartet wurde, betrachtet der Host-Client diesen Versuch als Fehlschlag und zeigt folgende Fehlermeldung an:

        Anmeldung fehlgeschlagen wegen eines ungültigen Benutzernamens oder Kennworts.

        Diese Fehlermeldung wird angezeigt, weil der Host kürzlich neu gestartet wurde und es möglich ist, dass er noch keinen SSL-Fingerabdruck von vCenter Server empfangen hat. Nachdem der Fingerabdruck an den Host gesendet wurde, verläuft das Failover erfolgreich. Diese Bedingung tritt nur dann auf, wenn alle Hosts in einem FT-aktivierten Cluster ausgefallen sind, was dazu führt, dass der Host mit der sekundären virtuellen Maschine neu gestartet wird.

        Umgehung: Keine. Das Failover verläuft nach einigen Versuchen erfolgreich.

      • Das Ändern der Systemzeit auf einem ESX/ESXi-Host führt zu einem VMware HA-Agent-Fehler
        Wenn Sie die Systemzeit auf einem ESX/ESXi-Host ändern, wird nach kurzer Zeit der folgende HA-Agent-Fehler angezeigt:

        Der HA-Agent auf < Server> in < Cluster> im < Datencenter> hat einen Fehler.

        Dieser Fehler wird sowohl im Ereignisprotokoll als auch auf der Host-Registerkarte Übersicht im vSphere-Client angezeigt.

        Umgehung: Korrigieren Sie die Systemzeit des Hosts und starten Sie "vpxa" mit dem Befehl service vmware-vpxa restart neu.

      • Der Versuch, das Festplattenformat einer FT-aktivierten virtuellen Maschine zu ändern, während sie von einem zu einem anderen Datenspeicher migriert wird, schlägt fehl
        Wenn Sie versuchen, das Festplattenformat einer ausgeschalteten, FT-aktivierten virtuellen Maschine zu ändern, während sie von einem zu einem anderen Datenspeicher migriert wird, zeigt der vSphere-Client eine InvalidArgument-Fehlermeldung an, die angibt, dass der Vorgang fehlgeschlagen ist. Das korrekte Verhalten des vSphere-Clients ist, die Option zum Ändern des Festplattenformats zu deaktivieren.

        Umgehung: Wählen Sie Format wie Quelle, die Standardoption, wenn Sie eine FT-aktivierte virtuelle Maschine in einen anderen Datenspeicher migrieren.

      • Die Funktion zur Überwachung virtueller Maschinen in VMware HA wird nicht für ESX- oder ESXi-Versionen vor ESX 3.5 U3 unterstützt
        Wenn VMware HA auf einem Cluster aktiviert ist, der von vCenter Server 4.0 verwaltet wird, funktioniert die VM-Überwachung nicht ordnungsgemäß auf ESX- oder ESXi-Hosts, die älter als ESX Server 3.5 Update 3 sind, und kann zu ungewollten Failover-Vorgängen von virtuellen Maschinen führen.

        Umgehung: Deaktivieren Sie die VM-Überwachungsfunktion für solche virtuelle Maschinen oder aktualisieren Sie den ESX/ESXi-Host auf ESX Server 3.5 Update 3 oder später.

      • Nicht reagierende sekundäre virtuelle Maschinen oder Kopien von virtuellen Maschinen, ggf. mit anderen Namen, verbleiben möglicherweise in der Hostbestandsliste, wenn das Einschalten von Fault Tolerance unterbrochen wurde
        Wenn Sie bei einer virtuellen Maschine, auf der VMware HA aktiviert ist, Fault Tolerance einschalten, kann es sein, dass der Bestandsliste des Clusters eine nicht reagierende sekundäre virtuelle Maschine hinzugefügt wird oder dass Sie mehrere Kopien der virtuellen Maschine mit unterschiedlichen Namen erhalten. Diese Situation tritt dann auf, wenn der Ziel-ESX/ESXi-Host auf der sekundären virtuellen Maschine, beispielsweise wegen eines Neustarts, Stromausfalls oder der Trennung vom Netzwerk, während der Erstellung der sekundären Kopie die Verbindung zu seinem verwaltenden vCenter Server verliert. Dies kann dazu führen, dass die Konfigurationseinstellungen auf der sekundären virtuellen Maschine nicht vollständig sind.

        Umgehung: Löschen Sie die nicht reagierende sekundäre virtuelle Maschine aus der Bestandsliste von vCenter Server.

      • Eine sekundäre virtuelle Maschine verbleibt in der Bestandsliste, nachdem die Fehlertoleranz für die primäre virtuelle Maschine ausgeschaltet wurde
        In einigen seltenen Fällen verläuft die Auswahl von Fehlertoleranz ausschalten im vSphere-Client für eine primäre virtuelle Maschine erfolgreich, aber die zugeordnete sekundäre virtuelle Maschine verbleibt in der Bestandsliste. Dies tritt gelegentlich ein, wenn gerade ein Failover-Vorgang aufgetreten ist und die neue sekundäre virtuelle Maschine noch nicht gestartet wurde. Es hat aber keine ernsthaften Folgen, da die Dateien der sekundären virtuellen Maschine bereits gelöscht wurden.

        Umgehung: Löschen Sie die sekundäre virtuelle Maschine manuell.

      • Beim Konfigurieren von VMware High Availability (HA) auf einem stark belasteten System erscheint möglicherweise eine Fehlermeldung
        Wenn Sie HA auf einem Host aktivieren, der aufgrund seiner Gast-VMs eine schwere Arbeitslast zu bewältigen hat, wird die HA-Konfiguration für den Host möglicherweise unterbrochen und eine Fehlermeldung ausgegeben:
        HA-Agent auf dem Host fehlgeschlagen

        Umgehung: Konfigurieren Sie HA für den Host neu, möglichst nachdem Sie die Last reduziert haben, indem Sie entweder virtuelle Maschinen ausschalten oder sie unter Verwendung von vMotion auf einen anderen Host im Cluster migrieren.

      • Bei angehaltenen virtuellen Maschinen mit unabhängigen, nicht dauerhaften Festplatten ist kein Failover auf VMware HA-Hosts möglich
        Wenn Sie auf einem Host virtuelle Maschinen angehalten oder ausgeschaltet haben und wenn die Festplatten der virtuellen Maschinen als unabhängig und nicht-dauerhaft konfiguriert sind, findet kein Failover statt. Diese Festplatten werden nicht auf einen anderen Host migriert, falls der Host ausfällt, ausgeschaltet wird oder in den Wartungsmodus versetzt wird. Das Migrieren dieser virtuellen Maschinen wird zurzeit für HA nicht unterstützt, weil die Maschinen mit keinem anderen Host im Cluster kompatibel sind.

        Umgehung: Heben Sie die Registrierung der virtuellen Maschine auf und registrieren Sie sie auf einem kompatiblen Host.

      • VMware HA meldet möglicherweise irreführende Zeitüberschreitungsfehler beim Einschalten oder Failover eines Hosts mit vielen VMs
        VMware HA-Zeitüberschreitungsfehler treten möglicherweise ein paar Minuten nach dem Einschalten oder Migrieren (unter Verwendung von VMware HA) eines Hosts mit vielen VMs (mehr als 70) auf. Dieser Zeitüberschreitungsfehler verschwindet, nachdem die meisten der VMs eingeschaltet wurden.

        Umgehung: Sie können ignoriert werden.

      • Die VMware-Fehlertoleranz unterstützt die IPv6-Adressierung nicht
        Wenn den VMkernel-Netzwerkkarten für die Fehlertoleranzprotokollierung oder für vMotion IPv6-Adressen zugewiesen werden, schlägt das Aktivieren der Fehlertoleranz auf virtuellen Maschinen fehl.

        Umgehung: Konfigurieren Sie die VMkernel-Netzwerkkarten anhand der IPv4-Adressen.
      • Das Hot-Plugging von Geräten wird nicht unterstützt, wenn die Fehlertoleranz auf virtuellen Maschinen deaktiviert ist
        Die Hot-Plugging-Funktion wird auf virtuellen Maschinen nicht unterstützt, wenn die VMware-Fehlertoleranz auf diesen virtuellen Maschinen aktiviert oder deaktiviert ist. Sie müssen die Fehlertoleranz vorübergehend ausschalten, bevor Sie ein Hot-Plugging für ein Gerät durchführen können. Nach dem Hot-Plugging können Sie die Fehlertoleranz wieder einschalten. Nach dem Entfernen eines Geräts bei laufendem Betrieb sollten Sie die virtuelle Maschine allerdings neu starten, um die Fehlertoleranz einzuschalten.

      VMware Tools

      • Die IP-Virtualisierung von Windows Server 2008 R2 (64-Bit) funktioniert auf vSphere 4.0 Update 1 möglicherweise nicht
        Die IP-Virtualisierung, die es Ihnen ermöglicht, RDP-Sitzungen eindeutige IP-Adressen zuzuteilen, funktioniert möglicherweise nicht auf einem Windows 2008 R2 Terminal Server, der unter vSphere 4.0 Update 1 ausgeführt wird. Die IP-Virtualisierung funktioniert jedoch, wenn Sie einen physischen Windows 2008 R2 Terminal Server konfigurieren oder eine virtuelle Windows 2008 R2-Maschine unter 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.

        Umgehung: Wählen Sie die Option für eine benutzerdefinierte Installation von VMware Tools und entfernen Sie VMCI aus der Liste der Treiber, die installiert werden sollen.

      •  Unter bestimmten Bedingungen reagieren Snapshots einer virtuellen Maschine nicht
        Versuche, einen Snapshot einer virtuellen Maschine zu erstellen, führen möglicherweise dazu, dass der Status Vorgang läuftangezeigt wird, wenn alle der folgenden Bedingungen zutreffen:
        • Die Option Snapshot des Arbeitsspeichers der virtuellen Maschine erstellen wurde nicht ausgewählt.
        • Die Option Gast-Dateisystem stilllegen wurde ausgewählt.
        • Ein VSS (Volume Shadow Copy Service) von einem Drittanbieter wurde installiert.
        In solchen Fällen wird der Status Vorgang läuftsolange angezeigt, bis für die Aufgabe eine Zeitüberschreitung eintritt. Darüber hinaus wird der Prozess fortgesetzt und verhindert somit, dass andere Snapshots erstellt werden.

      Seitenanfang

      ESX 4.0 Update 4 | 17. November 2011 | Build 504850

      Letzte Dokumentaktualisierung: 17. November 2011


      Diese Versionshinweise decken die folgenden Themen ab:

      Neuigkeiten

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

      Seitenanfang

      Vorherige Versionen von ESX 4.0

      Die Funktionen und bekannten Probleme der vorherigen Versionen von ESX 4.0 werden in den Versionshinweisen für die jeweilige Version beschrieben. Wenn Sie Versionshinweise vorheriger Versionen von ESX 4.0 anzeigen möchten, klicken Sie auf einen der folgenden Links:

      Seitenanfang

      Bevor Sie beginnen

      ESX, 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 ESX, vCenter Server, vSphere-Client und weiterer VMware-Produkte.

      Hardwarekompatibilität

      • Erfahren Sie mehr über Hardwarekompatibilität

        Die Listen zur Hardwarekompatibilität stehen in dem webbasierten Kompatibilitätshandbuch unter   http://www.vmware.com/resources/compatibility/search.php zur Verfügung. Das webbasierte Kompatibilitätshandbuch stellt eine zentrale Quelle für alle VMware-Kompatibilitätshandbücher dar und bietet die Möglichkeit zur Suche in den Handbüchern und zum Speichern der Suchergebnisse im PDF-Format. Anhand des Handbuchs können Sie z. B. sicherstellen, dass Server, E/A, Speicher und Gastbetriebssysteme kompatibel sind.

        Registrieren Sie sich hier, um über Updates zum Kompatibilitätshandbuch benachrichtigt zu werden: Dies ist das RSS-Bild, das als Link auf einen RSS-Feed dient.

      • Erfahren Sie mehr über die vSphere-Kompatibilität:

        VMware-Produkt-Interoperabilitätmatrix

      Dokumentation

      Die Dokumentation für VMware vSphere 4.0 Update 1 wurde aktualisiert und gilt für alle Update-Versionen von vSphere 4.0, einschließlich VMware vSphere 4.0 Update 4. Weitere Informationen hierzu finden Sie auf der Dokumentationsseite ESX 4.0 Update 1 und höher mit vCenter Server 4.0 Update 1 und höher.
      Das Verfahren zum Generieren neuer Zertifikate für den ESX-Host und zum Ersetzen eines Standardzertifikats durch ein von einer Zertifizierungsstelle signiertes Zertifikat wurde im Handbuch zur Serverkonfiguration für ESX aktualisiert.

      Installation und Upgrade

      Detaillierte und Schritt-für-Schritt-Anweisungen zur Installation und Konfiguration von ESX und vCenter Server finden Sie im Installationshandbuch – ESX und vCenter Server.

      Nach der erfolgreichen Installation sind einige weitere Konfigurationsschritte (insbesondere für die Lizenzierung, für Netzwerke und für die Sicherheitskonfiguration) erforderlich. Beachten Sie die folgenden Handbücher in der vSphere-Dokumentation für weitere Informationen zu diesen Konfigurationsaufgaben.

      Künftige Versionen von VMware vSphere werden möglicherweise VMFS Version 2 (VMFS2) nicht unterstützen. Sie sollten auf VMFS Version 3 oder höher aktualisieren bzw. migrieren. Weitere Informationen finden Sie im vSphere-Upgrade-Handbuch .

      Die Installation von künftigen Versionen von VMware vCenter Server auf 32-Bit-Windows-Betriebssystemen wird möglicherweise nicht unterstützt. Es wird empfohlen, vCenter Server auf einem 64-Bit-Windows-Betriebssystem zu installieren. Wenn VirtualCenter 2.x installiert ist, finden Sie im vSphere-Upgrade-Handbuch weitere Informationen über das Installieren von vCenter Server auf einem 64-Bit-Betriebssystem und das Beibehalten der VirtualCenter-Datenbank.

      MIB-Dateien, die sich auf ESX beziehen, werden nicht zusammen mit vCenter Server mitgeliefert. Nur MIB-Dateien, die sich speziell auf vCenter Server beziehen, sind im Lieferumfang von vCenter Server 4.0.X enthalten. Alle MIB-Dateien können von der VMware-Website unter http://www.vmware.com/de/download heruntergeladen werden.

      Durchführen eines Upgrades der VMware Tools

      VMware ESX 4.0 Update 4 setzt ein Upgrade von VMware Tools voraus. Die VMware Tools sind 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 den VMware Tools behoben wurden, finden Sie unter Behobene Probleme für VMware Tools.

      Das VMware Tools-RPM-Installationsprogramm, das im VMware Tools-ISO-Image für Linux-Gastbetriebssysteme zur Verfügung steht, ist veraltet. Es wird in einer künftigen ESX-Version entfernt. Verwenden Sie das tar.gz-Installationsprogramm zum Installieren der VMware Tools auf virtuellen Maschinen mit Linux-Gastbetriebssystemen.

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

      Upgrade oder Migration auf ESX 4.0 Update 4

      ESX 4.0 Update 4 bietet die folgenden Optionen für das Upgrade:

      • VMware vCenter Update Manager – Sie können ein Upgrade von ESX 3.5 Update 5a und ESX 4.0.x mithilfe von vCenter Update Manager 4.0 Update 4 durchführen. Weitere Informationen hierzu finden Sie im Administratorhandbuch zu VMware vCenter Update Manager .
      • vSphere Host Update Utility– Sie können ein Upgrade von ESX 3.5 Update 5a mithilfe von vSphere Host Update Utility 4.0 Update 4 durchführen. Weitere Informationen hierzu finden Sie im vSphere-Upgrade-Handbuch .
      • Skript "esxupgrade.sh" – Sie können ein Upgrade von einem ESX 3.5 Update 5a-Host ohne Netzwerkzugriff durchführen. Weitere Informationen finden Sie unter Durchführen eines Offline-Upgrades von ESX 3.x auf ESX 4.x (KB 1009440). Sofern der Host über Netzwerkzugriff verfügt, können Sie zum Durchführen des Upgrades das vSphere Host Update Utility oder den VMware vCenter Update Manager verwenden.
      • Befehl "vihostupdate" der VMware vSphere-Befehlszeilenschnittstelle (vSphere-CLI) –Sie können ein Upgrade von ESX 4.0.x mithilfe des Befehls vihostupdatedurchführen. Weitere Informationen hierzu finden Sie im vSphere-Upgrade-Handbuch und im Handbuch für die Patch-Verwaltung.
      • Befehlszeilenprogramm "esxupdate"–Sie können ein Upgrade von ESX 4.0.x mithilfe des Befehlszeilenprogramms esxupdatedurchführen. Informationen hierzu finden Sie im vSphere-Upgrade-Handbuch und im Handbuch für die Patch-Verwaltung.

      Mehrere Upgrade-Tools, die in ESX 3.x-Versionen unterstützt wurden, werden in der aktuellen Version nicht mehr unterstützt. Diese Tools umfassen Upgrades mit grafischer Benutzeroberfläche von CD, Upgrades im Textmodus von CD, Tarball-Upgrades mithilfe der Servicekonsole, Upgrades im Skriptmodus von CD oder einem PXE-Server unter Verwendung von esxupdateund Upgrades im Skriptmodus von CD oder einem PXE-Server mithilfe von Kickstart-Befehlen.

      Unterstützte Upgrade-Pfade für das Host-Upgrade auf ESX 4.0 Update 4:


      Upgrade-Lieferumfang

      Unterstützte Upgrade-Tools  

      Unterstützte Upgrade-Pfade auf ESX 4.0 Update 4

      ESX 3.5 Update 5a

      ESX 4.0, einschließlich
      ESX 4.0 Update 1, ESX 4.0 Update 2 und ESX 4.0 Update 3
      ESX-4.0.0-update04-<xxxxxx>.iso
      • VMware vCenter Update Manager mit ESX-Host-Upgrade-Baseline
      • vSphere Host Update Utility

      Ja

      Nein
      update-from-esx4.0-4.0_update04.zip
      • esxupdate
      • vihostupdate

      Nein

      Ja
      Patch-Definitionen, die vom VMware-Portal (online) heruntergeladen werden VMware vCenter Update Manager mit Host-Patch-Baseline
      Nein
      Ja

      Anmerkungen:

      • Direkte Upgrades von ESX 3.0.x oder früher auf ESX 3.5 Update 5a werden nicht unterstützt. Sie sollten zunächst ein Upgrade auf eine neuere unterstützte Version durchführen und anschließend ein Upgrade auf ESX 4.0 Update 4 durchführen.
      • Direkte Upgrades von ESX 2.5.x werden nicht unterstützt. Sie können mithilfe von Upgrade vMotion virtuelle ESX 2.5.5-Maschinen nach ESX 4.0 Update 4 migrieren. Weitere Informationen dazu finden Sie im vSphere-Upgrade-Handbuch .

       

      Seitenanfang

      Aktualisierte RPMs und Sicherheits-Fixes

      Eine Liste der in ESX 4.0 Update 4 aktualisierten RPMs finden Sie unter Aktualisierte RPMs und Sicherheits-Fixes. Dieses Dokument gilt nicht für die ESXi-Produkte.

      Aktualisieren von vSphere-Client

      Nach dem Upgrade von vCenter Server oder dem ESX/ESXi-Host auf vSphere 4.0 Update 4 werden Sie aufgefordert, ein Upgrade des vSphere-Clients auf vSphere Client 4.0 Update 4 durchzuführen. Das Upgrade des vSphere-Clients ist obligatorisch. Sie dürfen nur den aktualisierten vSphere-Client zum Zugriff auf vSphere 4.0 Update 4 verwenden.
      Hinweis: Sie müssen vSphere Client 4.0 Update 4 zum Zugriff auf vCenter Server verwenden, die Teil einer Gruppe im verknüpften Modus mit mindestens einer Instanz von vCenter Server 4.0 Update 4 sind.

      In dieser Version enthaltene Patches

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

      Patch-Version ESX400-Update04 enthält die folgenden einzelnen Bulletins:

      ESX400-201109201-SG: Aktualisiert VMkernel, VMX, Hostd und Anwendungen

      Weitere Informationen zu den Inhalten des Patches finden Sie in der Dokumentation, auf die auf der Download-Seite verwiesen wird.

      Seitenanfang

      Behobene Probleme

      Diese Update-Version enthält alle zusammengefassten Fixes des ESX400-201110001-Patches und bietet eine Lösung der Probleme aus den folgenden Bereichen:


      Sicherheit


        Seitenanfang

        Bekannte Probleme

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

        Sicherung

        • VMware Consolidated Backup (VCB) 1.5 Update 1 mit Windows 7 und Windows 2008 R2 x64
          VMware Consolidated Backup (VCB) 1.5 Update 1 unterstützt das Sichern und Wiederherstellen von Windows 7- und Windows 2008 R2 x64-Gastbetriebssystemen. Sicherungen auf Dateiebene werden bei Windows 7- oder Windows 2008 R2 x64-Gastbetriebssystemen jedoch nicht unterstützt.

        •   VMware Consolidated Backup (VCB) wird nicht mit Fehlertoleranz unterstützt
          Ein auf einer FT-aktivierten virtuellen Maschine durchgeführtes VCB-Backup schaltet sowohl die primären als auch die sekundären virtuellen Maschinen aus und führt möglicherweise dazu, dass die virtuellen Maschinen unbrauchbar werden.

          Umgehung: Keine

        CIM und API

        •  Einige VRM-Sensoren der Stromversorgung werden nicht auf der Registerkarte "vCenter-Hardwarestatus" für die Server IBM x3850 und x3950 M2 angezeigt
          Auf der Registerkarte Hardwarestatus von vCenter Server werden die Sensoren auf der Registerkarte Hardwarestatus für Server vom Typ IBM x3850 und x3950 M2 nicht für alle Statuszustände des PS VRM-Sensors angezeigt. Die CIM-Instanzen werden nicht entsprechend jedem Systemzustand des VRM-Sensors der Stromversorgung auf Servern vom Typ IBM x3850 und x3950 M2 erstellt. Der Grund ist ein Defekt in der IBM BMC-Firmware 4.5. Aus diesem Grund werden die Sensoren nicht auf der Registerkarte Hardwarestatus von "vCenter angezeigt.
        •  In Small Footprint CIM Broker wird eine falsche Versionsnummer aufgeführt
          Die vom SLP-Service aufgeführte Versionsnummer von Small Footprint CIM Broker ist falsch. Diese Version enthält die SFCB-Version 1.3.3, aber in den SLP-Abfrageinformationen wird die Version als 1.3.0 aufgeführt. Diese falsche Versionsnummer wirkt sich jedoch nicht auf die Nutzung des SLP-Dienstes aus. Für dieses Problem gibt es zurzeit keine Umgehung.
        •  Das CIM-Indication-Abonnement ist nach einem ESX-Update nicht mehr verfügbar
          Das CIM-Indication-Abonnement geht verloren, wenn Sie zwischen ESX-Updates aktualisieren oder Patches anwenden. Die Informationen zum Empfänger der Indication werden durch das Upgrade überschrieben und gehen so verloren.

          Umgehungen: Beide der folgenden Umgehungen haben sich als effektiv erwiesen. Wenden Sie die Methode an, die für Ihre Bereitstellung am besten geeignet ist.

          • Führen Sie eine erneute Subskription der CIM-Indications durch
            Möglicherweise ist es nicht möglich, diese Umgehung anzuwenden. In manchen Fällen ist ein erneutes Abonnement der CIM-Indications nicht möglich.

          • Kopieren sie die entsprechenden Dateien aus dem Backup-Repository in das neue Repository, wie in den nachfolgenden Teilschritten beschrieben.
            Bei dieser Umgehung werden die CIM XML-Indication-Abonnements wiederhergestellt.
            1. Verschieben Sie die folgenden Dateien aus dem Backup-Repository in das neue Repository:
              cim_indicationfilter
              cim_indicationfilter.idx
              cim_indicationhandlercimxml
              cim_indicationhandlercimxml.idx
              cim_indicationsubscription
              cim_indicationsubscription.idx
              cim_listenerdestinationcimxml
              cim_listenerdestinationcimxml.idx
              .
              Verschieben Sie beispielsweise die vorherigen Dateien aus dem Backup-Repository wie /var/lib/sfcb/registration/repository.previous/root/interopin das neue Repository wie
              /var/lib/sfcb/registration/repository/root/interop
            2. Starten Sie den Prozess sfcbd-watchdogneu.

        Gastbetriebssystem

        • Virtuelle Debian 5-Maschinen zeigen während Snapshot-Vorgängen eine Fehlermeldung an (KB 1037897)
        • Virtuelle Windows Server 2008 R2-Maschine mit VMXNET 3-Treiber schlägt fehl (KB 1037894)
        • Das Entfernen der Festplatte aus einer virtuellen Maschine mit einem RHEL3-Gastbetriebssystem, ohne dass das Gastbetriebssystem informiert wurde, führt dazu, dass die virtuelle Maschine nicht mehr funktioniert
          Wenn bei einem 32-Bit-System eine Festplatte einer virtuellen Maschine mit einem RHEL3-Gastbetriebssystem und einem BusLogic-Treiber bei laufendem Betrieb entfernt wird, ohne dass das Gastbetriebssystem darüber informiert wurde, funktioniert die virtuelle Maschine nicht mehr.

          Umgehung: Entfernen Sie die Festplatte explizit aus dem Gastbetriebssystem. Rufen Sie zuerst die Details über die Festplatte, die Sie entfernen möchten, aus /proc/scsi/scsi ab:

          1. Merken Sie sich die HOST CHAN ID und die LUN-Nummern des Geräts in /proc/scsi/scsi
          2. Führen Sie an der RHEL-Konsole den folgenden Befehl aus:

            echo "scsi remove-single-device HOST CHAN DEV LUN" > /proc/scsi/scsi

        • Virtuelle Maschine unter Solaris 10 U4 reagiert nicht mehr während eines Upgrades der VMware Tools
          Das Upgrade oder der Neustart der VMware Tools in einer virtuellen Maschine unter Solaris 10 U4 mit einem erweiterten vmxnet-Adapter kann möglicherweise dazu führen, dass das Gastbetriebssystem nicht mehr reagiert und die Installation nicht mehr fortgesetzt werden kann.

          Solaris 10 U5 und spätere Versionen sind von diesem Problem nicht betroffen.

          Umgehung: Bevor Sie VMware Tools installieren oder aktualisieren, sollten Sie vorübergehend den erweiterten vmxnet-Adapter neu konfigurieren, indem Sie entweder dessen Autokonfigurationsdateien in /etc/ entfernen oder die virtuelle Hardware entfernen.

        • Geräte, die im laufenden Betrieb an den BusLogic-Adapter angeschlossen werden, sind im Linux-Gastbetriebssystem nicht sichtbar
          Geräte, die an einen im laufenden Betrieb angeschlossenen BusLogic-Adapter angeschlossen werden, werden von einem Linux-Gastbetriebssystem nicht erkannt, wenn dieses zuvor über einen anderen BusLogic-Adapter verfügte. Außerdem schlägt möglicherweise das Entfernen des BusLogic-Adapters im laufenden Betrieb fehl. Dieses Problem tritt auf, weil der in Linux-Distributionen verfügbare BusLogic-Treiber keine Hot-Plug-APIs unterstützt. Dieses Problem betrifft nicht das Hinzufügen von Festplatten zum Adapter im laufenden Betrieb, sondern nur das Hinzufügen des Adapters selbst im laufenden Betrieb.

          Umgehung: Verwenden Sie zum Hinzufügen im laufenden Betrieb einen anderen Adapter, beispielsweise einen parallelen Adapter oder den SAS LSI Logic-Adapter. Wenn ein BusLogic-Adapter erforderlich ist, sollten Sie versuchen, den Adapter im laufenden Betrieb zu entfernen, nachdem Sie den BusLogic-Treiber im Gastbetriebssystem entladen haben. Sie können außerdem versuchen, den im laufenden Betrieb hinzugefügten Adapter zu steuern, indem Sie eine andere Instanz des BusLogic-Treibers laden. Sie können eine andere Instanz des BusLogic-Adapters laden, indem Sie den Befehl modprobe -o BusLogic1 BusLogic ausführen (wobei Sie für jede Hinzufügeaktion im laufenden Betrieb BusLogic1 durch BusLogic2, BusLogic2 durch BusLogic3 usw. ersetzen).

        • Bei virtuellen Maschinen mit Windows NT-Gastbetriebssystemen ist die Bestätigung einer Warnmeldung erforderlich, die generiert wird, wenn die virtuelle Maschine ein automatisches Upgrade der VMware Tools versucht
          Wenn Sie die Option festlegen, automatisch vor jedem Einschaltvorgang für Windows NT-Gastbetriebssysteme VMware Tools zu prüfen und zu aktualisieren, erscheint die folgende Warnmeldung:

          Automatische Installation des vmxnet-Treibers fehlgeschlagen. Dieser Treiber muss manuell installiert werden.

          Umgehung: Das Upgrade wird so lange angehalten, bis die Warnung bestätigt wird. Melden Sie sich beim Windows NT-Gastbetriebssystem an und bestätigen Sie die Warnmeldung, um das Upgrade abzuschließen.

        • Beim Erstellen einer virtuellen Maschine von Ubuntu 7.10 Desktop wird möglicherweise ein schwarzer Bildschirm angezeigt
          Wenn Sie die Installation für das Ubuntu 7.10 Desktop-Gastbetriebssystem auf einer virtuellen Maschine mit aktivierter Paravirtualisierung auf einem AMD-Host ausführen, bleibt der Bildschirm der virtuellen Maschine möglicherweise leer. Das korrekte Verhalten ist, dass das Installationsprogramm Ihnen die Anweisungen gibt, die CD aus dem Laufwerk zu entfernen und die Eingabetaste zu drücken.

          Umgehung: Drücken Sie die Eingabetaste. Die Installation wird fortgesetzt und die virtuelle Maschine neu gestartet. Außerdem tritt dieser Fehler nicht auf, wenn Sie die Installation auf einer virtuellen Maschine mit zwei oder mehr virtuellen Prozessoren starten.
        • Ein automatisches Upgrade der VMware Tools schlägt für eine virtuelle Maschine unter Red Hat Enterprise Linux 5.x möglicherweise fehl
          Ein automatisches Upgrade der VMware Tools schlägt schlägt möglicherweise für eine virtuelle Maschine unter Red Hat Enterprise Linux 5.x fehl, die mittels Cold-Migration von einem ESX 3.0.3-Host auf einen ESX/ESXi 4.0 Update 1-Host migriert wurde. Folgender Fehler tritt auf: Fehler beim Aktualisieren der VMware Tools.

          Umgehung: Upgrade Sie VMware Tools auf dem ESX 4.0 Update 1-Host manuell.

          Internationalisierung

          • Bei der Eingabe des Namens der Ausgabedatei der parallelen/seriellen Schnittstelle werden keine Nicht-ASCII-Zeichen akzeptiert und es wird eine Fehlermeldung angezeigt
            Beim Konfigurieren einer virtuellen Maschine werden Dateinamen, die Nicht-ASCII-Zeichen enthalten, mit einer Fehlermeldung abgelehnt. Die Validierung von Dateinamen berücksichtigt keine in nicht-englischen Sprachen üblichen Sonderzeichen und kann dazu führen, dass Dateinamen nicht angenommen werden. Dieses Problem betrifft Ausgabedateien für serielle und parallele Schnittstellen und kann auch ISO- und FLP-Namen sowie VMDK-Dateinamen betreffen.

            Umgehung: Beschränken Sie den kompletten Datenspeicherinhalt (Verzeichnisse und Dateinamen) auf ASCII-Zeichen.

          Lizenzierung

          • Ein Host mit einer einzelnen Serverlizenz, der nicht zu vCenter Server hinzugefügt werden kann, verfügt nicht über die Option, während eines nachfolgenden Vorgangs zum Hinzufügen eines Hosts die Lizenzierung entsprechend zu korrigieren
            Wenn ein ESX- oder ESXi-Host, der mit einer einzelnen Serverlizenz konfiguriert ist, zu einem lizenzierten vCenter Server hinzugefügt wird, zeigt vCenter Server eine Fehlermeldung an, die angibt, dass der Host nicht hinzugefügt werden kann.

            Umgehung: Entfernen Sie den nicht verbundenen Host und fügen Sie ihn mit einer Lizenz für mehrere Server erneut hinzu.

          • Virtuelle Maschinen können nicht eingeschaltet werden, wenn während einer Skript- oder einer interaktiven Installation bestimmte Lizenzen installiert werden
            Falls Sie beim Installieren von ESX/ESXi nicht über die richtigen Lizenz-Seriennummern für Ihre Hardware verfügen, tritt möglicherweise ein Lizenzierungsfehler auf. Dieses Problem tritt auf, weil während der Installation der Anbieter und die Ressource die Überprüfung der Validierung von Lizenzschlüsseln nicht durchführen. Nach der Validierung einer Lizenz mit lib/licensecheck ist ein anschließender Test erforderlich, um zu überprüfen, ob das installierte System den Lizenzbeschränkungen entspricht. Das Installationsprogramm führt jedoch die zweite Prüfung nicht durch.

            Umgehung: Wechseln Sie in den Bewertungsmodus und rufen Sie anschließen vom Portal die entsprechende Lizenz ab.

          • Erworbene Add-On-Lizenzen werden nicht in der Lizenzliste der Seite "Lizensierung" des vSphere-Clients angezeigt
            Wenn Sie auf der Seite "Lizensierung" des vSphere-Clients Ihre erworbenen Lizenzen ansehen, sehen Sie keinen eigenen Produkteintrag für Add-On-Editionen. Wenn Sie beispielsweise eine Lizenz für vSphere 4.0 Standard mit vMotion oder vSphere 4.0 Standard mit vMotion und Data Recovery erworben haben, erscheint nur die vSphere 4.0 Standard-Lizenz.

            Umgehung: Führen Sie zum Anzeigen der Produkt- und Add-On-Funktionen für einen Lizenzschlüssel die folgenden Schritte aus:

            1. Klicken Sie auf der vSphere-Startseite auf Lizenzierung.
            2. Klicken Sie zum Starten des Lizenzassistenten in der oberen rechten Ecke auf vSphere-Lizenzen verwalten .
            3. Klicken Sie auf Weiter, um zur Seite „Lizenz zuweisen“ zu wechseln.
            4. Bewegen Sie den Mauszeiger über den Hostlizenzschlüssel, um die verfügbaren Produkt- und Add-On-Funktionen anzuzeigen.

          Sonstige Probleme

          • Vom Benutzer erstellte Dateien im ESX-Verzeichnis /tmp werden nach jedem Neustart des Hosts gelöscht
            Wenn Sie oder die Benutzer, die Sie unterstützen, temporäre Dateien, wie z. B. anwendungsgenerierte Protokolldateien, im ESX-Verzeichnis /tmp speichern, gehen diese Dateien bei jedem Neustart des Hosts verloren.

            Umgehung: Verwenden Sie zum Speichern von benutzergenerierten Dateien und Verzeichnissen nicht das ESX-Verzeichnis /tmp.

          • Eine Datei, die nicht entpackt werden kann, könnte Diagnosedaten von vCenter enthalten
            Beim Extrahieren einer .tgz-Datei, die Diagnosedaten von vCenter enthält, wird ein Dialogfeld, in dem die Dateien aufgelistet sind, die nicht extrahiert werden können, sowie eine Fehlermeldung angezeigt:

            Symbolischer Link verweist auf fehlende Dateien.

            Umgehung: Keine

          • Der Linux-Befehl "rm -rf" schlägt möglicherweise in der Servicekonsole fehl
            Wenn Sie rm -rf in einem Verzeichnis mit mehr als 380 Dateien ausführen, schlägt der Befehl mit folgendem Fehler fehl:

            Verzeichnis nicht leer.

            Dieses Problem wird durch eine Einschränkung des Red Hat 2.6-Kernels verursacht.

            Umgehung: Führen Sie einen dieser Aufgaben aus:

            • Löschen Sie die Verzeichnisse unter Verwendung des vSphere-Client-Datenspeicherbrowsers.
            • Führen Sie rm -rf mehrfach aus, bis alle Einträge gelöscht sind. Bei jedem Aufruf von rm -rf werden höchstens 380 Einträge gelöscht.
          • ESX-Hosts mit einer TLS LDAP-Konfiguration erlauben es LDAP-Benutzern nicht, sich anzumelden
            ESX-Administratoren können in der Servicekonsole neben LDAP unter Verwendung des folgenden Befehls die TLS-Authentifizierung aktivieren:

            esxcfg-auth --enableldap --enableldapauth --enableldaptls --ldapserver=<Server IP/Name> --ldapbasedn="dc=<LDAP DC Name>"

            Nach dem Einschalten der Authentifizierung können Sie sich beim ESX-Host nicht mehr mit einem LDAP-Benutzernamen anmelden. Zudem können Sie den Speicherort der Zertifikatsdatei /etc/openldap/cacerts/client.pemnicht in der Befehlszeile angeben.

            Umgehung: Führen Sie die folgenden Schritte aus:

            1. Öffnen Sie die Datei /etc/ldap.confin einem Editor, fügen Sie Folgendes hinzu und speichern Sie die Datei:

              URI ldaps://linux-ldaptls/
            2. Öffnen Sie die Datei /etc/openldap/ldap.conf in einem Editor, fügen Sie Folgendes hinzu und speichern Sie die Datei:

              URI ldaps://linux-ldaptls/
              TLS_CACERT /etc/openldap/cacerts/client.pem
              BASE dc=ns,dc=suchi,dc=com
          • Einstellung der Core-Dump-Partition des ESX/ESXi-Hosts ist unter bestimmten Bedingungen nicht dauerhaft
            Wenn Sie den Speicherort /root der Core-Dump-Partition ändern und innerhalb einer Stunde nach dieser Änderung, aber bevor der Host neu gestartet wird, der ESX/ESXi-Host ausfällt, wird die Core-Dump-Partition auf ihre ursprüngliche Einstellung /root zurückgesetzt.

            Umgehung: Führen Sie nach dem Ändern der Core-Dump-Partition sofort esxcfg-boot aus.

          • Warnmeldung hinsichtlich "Execute Disable/No Execute CPU feature" an der lokalen Konsole empfangen
            Die Warnmeldung The Execute Disable/No Execute CPU feature is not enabled for this machine erscheint auf der lokalen Konsole, wenn entweder auf einem HP-System mit deaktivierter Option No-Execute Memory Protection im System-BIOS der Maschine oder auf einem Dell-System mit deaktivierter Option Execute Disable im System-BIOS der Maschine ESX 4.0 installiert ist.

            Umgehung: Aktivieren Sie No-Execute Memory Protection bzw. Execute Disable im BIOS der HP- bzw. der Dell-Maschine.

          • Das Beenden oder der Neustart des vCenter Server-Dienstes über das Windows Services Control MMC-Plug-In kann zu einer Fehlermeldung führen
            Unter bestimmten Bedingungen dauert das Starten des vCenter Server-Dienstes möglicherweise länger als gewöhnlich. Das Beenden und der Neustart des vCenter Server-Dienstes über das Windows Services Control MMC-Plug-In kann zur folgenden Fehlermeldung führen:

            Dienst konnte nicht in angemessener Zeit reagieren.

            Diese Meldung bedeutet, dass die für das Herunterfahren oder Starten von vCenter Server erforderliche Zeit den standardmäßig konfigurierten, systemweiten Zeitüberschreitungswert zum Beenden und Starten von Diensten überschritten hat.

            Umgehung: Aktualisieren Sie nach ein paar Minuten den Bildschirm für die Dienstesteuerung. Es sollte nun angezeigt werden, dass der Dienst ordnungsgemäß gestoppt und neu gestartet wurde.

          Netzwerk

          • Durch das Entfernen eines mit einem vDS konfigurierten ESX/ESXi-Hosts von einem vCenter Server-System wird der Netzwerkstatus auf dem Host inkonsistent
            Wenn Sie einen mit einem vDS konfigurierten ESX/ESXi-Host von einem vCenter Server-System entfernen, kann der Host die Verbindung mit dem vDS nicht wieder herstellen. Wenn Sie den Host wieder zum vCenter Server-System hinzufügen, wird eine Warnung ähnlich der Folgenden angezeigt:

            Der verteilte virtuelle Switch, der den Proxy-Switches d5 6e 22 50 dd f2 94 7b-a6 1f b2 c2 e6 aa 0f bf auf dem Host entspricht, ist nicht in vCenter vorhanden oder enthält diesen Host nicht.

            Die virtuellen Maschinen funktionieren nach wie vor auf ihren jeweiligen Ports, aber neue virtuelle Maschinen dürfen nicht eingeschaltet werden. Sie können mithilfe eines mit dem vCenter Server-System verbundenen vSphere-Clients die vDS-Einstellungen für diesen Host ändern.

            Umgehung: Führen Sie die folgenden Schritte aus:

            1. Verwenden Sie zum Herstellen einer direkten Verbindung zum ESX/ESXi-Host einen vSphere-Client. Diese Umgehung erfordert eine Direktverbindung.
            2. Migrieren Sie die virtuellen Maschinen nacheinander von den ungültigen vDS-Ports, indem Sie die Einstellungen der jeweiligen virtuellen Maschine bearbeiten. Dies hat eine länger andauernde Unterbrechung des Netzwerks für die virtuellen Maschinen zur Folge.
            3. Wählen Sie Host > Konfiguration > Netzwerk > Verteilter virtueller Switch und klicken Sie auf Entfernen.
            4. Aktualisieren Sie in einem vSphere-Client, der mit dem vCenter Server-System verbunden ist, die Netzwerkeinstellungen des Hosts. Die Fehler werden gelöscht.
            5. Fügen Sie den Host entweder manuell oder unter Verwendung eines Hostprofils wieder zum vDS hinzu.
            6. Migrieren Sie die virtuellen Maschinen zurück zu ihren jeweiligen Ports oder Portgruppen auf dem vDS. Klicken Sie dazu mit der rechten Maustaste auf den vDS und wählen Sie Netzwerk virtueller Maschinen migrieren. Dies hat auch eine länger andauernde Unterbrechung des Netzwerks für die virtuellen Maschinen zur Folge.
          • VLAN-Tagging funktioniert nicht in SLES10-Gastbetriebssystemen, wenn Oplin-Netzwerkkarten im Passthrough-Modus (FPT) verwendet werden
            Dieses Problem tritt auf, wenn ein Oplin 10GB-Adapter einer virtuellen Maschine zugewiesen wird, die das SUSE Enterprise Linux 10 (SLES10) 32-Bit- oder 64-Bit-Gastbetriebssystem als FPT-Gerät (fixed passthrough) ausführt, und das Gastbetriebssystem zur Durchführung von VLAN-Tagging konfiguriert ist. In einem solchen Fall verschlechtert sich der TCP-Verkehr und ein Aufruf von netperf wird vorzeitig mit einer Fehlermeldung beendet. Der ICMP-Verkehr geht noch durch und Sie können noch pingen.

            Umgehung: Führen Sie tcpdump aus, während der TCP-Verkehr noch aktiv ist. Durch das Ausführen von tcpdump wird die Netzwerkkarte in den Promiscuous-Modus versetzt. Dies stellt sicher, dass der Verkehr ordnungsgemäß fließt. Dabei werden aber sehr viele CPU-Zyklen auf dem Gastbetriebssystem konsumiert.

          • Die gemeinsame Nutzung eines Dual-Funktion-Adapters QLogic 2532 durch eine virtuelle Maschine und eine andere virtuelle Maschine oder den VMkernel bei VMDirectPath Gen I kann zu Datenverlusten führen
            Wenn Sie einen Dual-Funktion-Adapter QLogic 2532 für VMDirectPath IO konfigurieren und die erste PCI-Funktion einer virtuellen Maschine sowie die zweite einem VMkernel oder einer anderen virtuellen Maschine zuweisen, kann dies zu Datenverlust führen. Dies liegt daran, dass beide Ports die gleichen Daten zum Anmelden bei Fabric verwenden und über die gleichen Speichersichtbarkeit verfügen. VMware unterstützt diese Konfiguration für VMDirectPath IO nicht.

            Umgehung: Wenn der Dual-Funktion-Adapter von einer virtuellen Maschine und dem VMkernel gemeinsam genutzt werden muss, weisen Sie die erste PCI-Funktion der virtuellen Maschine und die zweite dem VMkernel zu. Die PCI-Funktionen können nicht zwischen zwei virtuellen Maschinen aufgeteilt werden.

          • Der ESX-Host wird getrennt, falls Sie die sekundäre Servicekonsole entfernen, wenn sich beide vSwitches in demselben Subnetz befinden
            Der Host wird mit einer Fehlermeldung getrennt, wenn Sie die folgenden Schritte durchführen:
            1. Eine sekundäre Servicekonsole hinzufügen
            2. Das Gateway-Gerät der Servicekonsole ändern
            3. Das Gateway-Gerät auf die primäre Servicekonsole zurücksetzen
            4. Die sekundäre Servicekonsole entfernen

            Umgehung: Keine

          • Verbindungsstatusprobleme mit Neterion-Netzwerkkarten treten möglicherweise bei Foundry Edgeiron 8X10G-Switches auf
            Wenn auf einem Foundry Edgeiron 8X10G-Switch ein aktiver Port über einen längeren Zeitraum wiederholt aktiviert und deaktiviert wird, führt dies möglicherweise dazu, dass der Port permanent in den Status Link deaktiviert versetzt wird.

            Umgehung: Starten Sie den Switch neu oder verwenden Sie einen anderen Switch-Port.

          • NetXen-Chipset bietet keine Hardwareunterstützung für VLANs
            Die NetXen-Netzwerkkarte zeigt keine Hardwareunterstützung für VMNET_CAP_HW_TX_VLAN und VMNET_CAP_HW_RX_VLAN an. Dies liegt daran, dass der NetXen-Chipset keine Hardwareunterstützung für VLANs bietet. NetXen-VLAN-Unterstützung ist auf Softwarebasis verfügbar.
          • Bei der benutzerdefinierten Erstellung einer virtuellen Maschine können maximal vier Netzwerkkarten hinzugefügt werden
            Während der Erstellung einer virtuellen Maschine mit der Option "Benutzerdefiniert" zeigt der vSphere-Client den Konfigurationsbildschirm "Netzwerk" an. Auf diesem Bildschirm werden Sie aufgefordert, die Anzahl an Netzwerkkarten anzugeben, die verbunden werden sollen. Im Dropdown-Menü können maximal vier Netzwerkkarten ausgewählt werden. Mit ESX/ESXi 4.0 Update 1 werden jedoch 10 Netzwerkkarten unterstützt.

            Umgehung: Sie können weitere Netzwerkkarten hinzufügen, indem Sie den folgenden Vorgang ausführen.
          1.  
            1. Navigieren Sie mithilfe des vSphere-Clients zu Home> Bestandsliste> VMs und Vorlagen.
            2. Klicken Sie bei ausgewählter Registerkarte "Erste Schritte" auf "VM-Einstellungen bearbeiten".
            3. Klicken Sie auf "Hinzufügen".
            4. Wählen Sie "Ethernet-Adapter" und klicken Sie auf "Weiter".
            5. Fahren Sie mit der Auswahl der geeigneten Einstellungen für Ihr Szenario fort.
          • Adressen können dem ESX-Servicekonsolenport nach einem Neustart nicht zugewiesen werden
            Wenn bei einem Servicekonsolenport weder statische IPv4/IPv6-Adressen konfiguriert noch automatische Konfigurationsmethoden (DHCP, DHCP6 oder AUTOCONF) aktiviert sind, befindet sich der Port nach einem Neustart in einem ungültigen Zustand und Sie können dieser Schnittstelle keine Adressen zuweisen.

            Umgehung: Konfigurieren Sie eine statische IP-Adresse (IPv4 oder IPv6) oder richten Sie einen Servicekonsolenport für die Verwendung der automatischen Adressgenerierungsmethode (z. B. DHCP, DHCP6 oder AUTOCONF) vor dem Neustart ein. Sie können auch nach einem Neustart den Servicekonsolenport neu erstellen.

          • Die VmwVmNetNum des VM-INFO MIB wird als Ethernet0 angezeigt, wenn "snmpwalk" ausgeführt wird
            Wenn "snmpwalk" für VM-INFO MIB auf einem ESX/ESXi-Host ausgeführt wird, wird die VmwVmNetNum des VM-INFO MIB als Ethernet0 statt Netzwerkadapter1 angezeigt, während die MOB-URL in der Beschreibung für VmwVmNetNum des VM-INFO als Netzwerkadapter1 angezeigt wird.

            Umgehung: Keine

          • Anwendungen, die VMCI-Sockets verwenden, schlagen nach der VM-Migration möglicherweise fehl
            Wenn Sie Anwendungen haben, die VMCI-Sockets (Virtual Machine Communication Interface) verwenden, schlagen die Anwendungen nach einer VM-Migration möglicherweise fehl, wenn die von der Anwendung verwendeten VMCI-Kontextbezeichner bereits auf dem Zielhost verwendet werden. In diesem Fall funktionieren die auf dem ursprünglichen Host erstellten VMCI-Stream- oder Datagram-Sockets nicht mehr ordnungsgemäß. Zudem wird es unmöglich, neue Stream-Sockets zu erstellen.

            Umgehung: Laden Sie bei Windows-Gastbetriebssystemen den Gast-VMCI-Treiber neu, indem Sie das Gastbetriebssystem neu starten oder das Gerät über den Gerätemanager aktivieren. Beenden Sie bei Linux-Gastbetriebssystemen alle Anwendungen, die VMCI-Sockets verwenden, entfernen und laden Sie das vsock-Kernelmodul neu und starten Sie die Anwendungen erneut.

          • Das Anwenden von Portgruppen mit mehreren statisch zugewiesenen VMKNICs oder VSWIFs führt zu wiederholten Aufforderungen zur Angabe einer IP-Adresse
            Das Anwenden einer vDS-Portgruppe mit mehreren statisch zugewiesenen VMKNICs oder VSWIFs führt dazu, dass der Benutzer wiederholt zur Angabe einer IP-Adresse aufgefordert wird. Über DHCP zugewiesene Schnittstellen sind davon nicht betroffen.

            Umgehung: Verwenden Sie nur eine statisch zugewiesene VMKNIC oder VSWIF pro Portgruppe. Wenn auf derselben vDS-Portgruppe mehrere statisch zugewiesene VMKNICs gewünscht werden, weisen Sie jede VMKNIC oder VSWIF einer eindeutigen Gruppe von Diensten (z. B. vMotion, Fehlertoleranz und anderen Diensten) zu.

          • Die Konsole für das Gastbetriebssystem fällt aus und Sie können über die Konsole nicht auf das Gastbetriebssystem zugreifen, wenn Sie für einen verteilten vNetwork-Switch oder einen vSwitch, der über die Servicekonsolen- oder die Verwaltungsnetzwerk-Portgruppe verfügt, den MTU-Wert auf weniger als 1500 festlegen
            Wenn Sie für den verteilten vNetwork-Switch oder den vSwitch, der die Servicekonsolen-Portgruppe für ESX oder die Verwaltungsnetzwerk-Portgruppe für ESXi Embedded enthält, den MTU-Wert auf weniger als 1500 festlegen, fällt die Konsole für das Gastbetriebssystem aus und Sie können über die Konsole nicht auf das Gastbetriebssystem zugreifen. Die Servicekonsolen-Portgruppe für ESX und die Verwaltungsnetzwerk-Portgruppe für ESXi Embedded müssen mit einem vSwitch oder einem verteilten vNetwork-Switch verbunden sein, dessen MTU-Einstellung 1500 oder höher ist.

            Umgehung: Legen Sie die für den verteilten vNetwork-Switch oder den vSwitch, der die Servicekonsolen-Portgruppe für ESX oder die Verwaltungsnetzwerk-Portgruppe für ESXi Embedded enthält, den MTU-Wert nicht auf weniger als 1500 fest.

          • Das Abrufen von DNS- und Hostnamensinformationen vom DHCP-Server kann verzögert oder verhindert werden
          •  Bei einem Upgrade von ESX 3.5-Hosts auf ESX 4.0 laden einige der Netzwerkgeräte den Treiber e1000e anstelle des Treibers e1000
            Wenn für Hosts vom Typ ESX 3.5 Update 4 oder ESX 3.5 Update 5 ein Upgrade auf ESX 4.0 oder höher durchgeführt wird, wird bei den folgenden Netzwerkgeräten der Treiber e1000e anstelle des Treibers e1000 geladen:
            • Intel 82571EB Gigabit Ethernet Controller (einschließlich 105e, 105f, 1060, 10a4, 10a5, 10bc)
            • Intel 82572EI Gigabit Ethernet Controller (einschließlich 107d, 107e, 107f, 10b9)
            • Intel 82573V Gigabit Ethernet Controller (einschließlich 108b)
            • Intel 82573E Gigabit Ethernet Controller (einschließlich 108c)
            • Intel 80003ES2LAN Gigabit Ethernet Controller (einschließlich 1096, 1098, 10ba, 10bb)
            • Intel 82573L Gigabit Ethernet Controller (einschließlich 109a)
          • Das Ändern der Netzwerkeinstellungen eines ESX/ESXi-Hosts verhindert, dass manche Software zur Überwachung des Hardwarestatus den Host automatisch erkennen kann
            Nach dem Ändern der Netzwerkeinstellungen eines ESX/ESXi-Hosts sind die Drittanbieter-Management-Tools, die auf der CIM-Schnittstelle basieren (in der Regel die Hardwarestatus-Überwachungs-Tools), nicht in der Lage, anhand des Service Location Protocol-Dienstes (SLP) den Host automatisch zu erkennen.
            Umgehung: Geben Sie den Hostnamen oder die IP-Adresse des Hosts manuell in das Drittanbieter-Management-Tool ein. Alternativ können Sie slpdund sfcbd-watchdogneu starten, indem Sie die entsprechende Methode verwenden:
            Auf ESXi:
            1. Aktivieren Sie den Technical Support-Modus.
            2. Starten Sie slpdneu, indem Sie den Befehl /etc/init.d/slpd restartausführen.
            3. Starten Sie sfcbd-watchdogneu, indem Sie den Befehl /etc/init.d/sfcbd-watchdog restartausführen.

            Starten Sie die Verwaltungsagenten im Direct Console User Interface (DCUI) neu. Dadurch werden zusätzlich zu den Agenten, die von diesem Defekt betroffen sind, weitere Agenten auf dem Host neu gestartet, was sich noch störender auswirken kann.
            Auf ESX: Führen Sie in der ESX-Servicekonsole die folgenden Befehle aus:
            /etc/init.d/slpd restart
            /etc/init.d/sfcbd-watchdog restart

          • Virtuelle Maschinen verlieren die Netzwerkkonnektivität, wenn sie auf einen ESX-Host mit der Standardanzahl von Ports migriert werden
            Standardmäßig wird die ESX-Servicekonsole mit einem virtuellen Switch mit nur 24 Ports installiert. Wenn virtuelle Maschinen auf einen Host migriert werden und die Anzahl der erforderlichen Ports die Standardanzahl übersteigt, verlieren manche virtuellen Maschinen möglicherweise die Netzwerkkonnektivität. Dieses Problem kann auftreten, wenn virtuelle Maschinen manuell migriert werden oder bei Notfallwiederherstellungsszenarien und Migrationen mit vMotion.

            Umgehung: Nach dem Installieren ändern Sie vSwitch0, sodass er eine große Anzahl von Ports hat, indem Sie die Switch-Eigenschaften bearbeiten. ESX 4.0 und höher unterstützen bis zu 56 Ports auf einem virtuellen Switch.

          Serverkonfiguration

          • Hostprofile erfassen und duplizieren keine Duplexinformationen von physischen Netzwerkkarten
            Wenn Sie ein neues Hostprofil erstellen, werden die Duplexinformationen der physischen Netzwerkkarte nicht erfasst. Dies ist das beabsichtigte Verhalten. Wenn daher das Profil des Referenzhosts verwendet wird, um andere Hosts zu konfigurieren, wird die Duplexkonfiguration pro physischer Netzwerkkarte ausgehandelt. Somit können Sie Hosts mit einer Vielzahl von Funktionen der physischen Netzwerkkarte generisch behandeln.

            Umgehung: Ändern Sie das Hostprofil, nachdem es erstellt wurde, und wenden Sie die Parameter neu an, um einheitlich über alle Netzwerkkarten und Hosts hinweg, die unter Verwendung des Referenz-Hostprofils konfiguriert werden sollen, den Duplexwert der physischen Netzwerkkarte festzulegen.

            Führen Sie zum Bearbeiten des Profils die folgenden Schritte aus.

            1. Klicken Sie auf der Startseite des vSphere-Clients auf Hostprofile.
            2. Wählen Sie das Hostprofil aus der Bestandsliste aus, klicken Sie auf die Registerkarte "Übersicht" und klicken Sie anschließend auf Profil bearbeiten.
            3. Wählen Sie Netzwerkkonfiguration > Konfiguration der physischen Netzwerkkarte > Bearbeiten.
            4. Wählen Sie im Dropdown-Menü "Feste Konfiguration der physischen Netzwerkkarte" aus und geben Sie die Geschwindigkeit und die Duplexinformationen ein.
          • Unter ESX tritt kein Fehler auf, wenn die SNMP-Agenten "net-snmp" und "hostd" so konfiguriert werden, dass sie beide auf demselben Port ausgeführt werden
            Wenn Sie den VMware SNMP-Daemon (hostd) demselben UDP-Port wie den SNMP-Daemon (snmpd) zuweisen, tritt kein Fehler auf, aber beim späteren Zugriff auf die SNMP-Funktionalität treten die folgenden Symptome auf:
            • Wenn "net-snmp" zuerst UDP/161 öffnet und versucht, "snmpwalk" für VMware Enterprise-MIB-Objekte unter enterprise.6876 auszuführen, geben GET-Anforderungen "noSuchErro" zurück und GETNEXT gibt den Wert nicht zurück.
            • Wenn UDP/161 zuerst von "hostd" geöffnet wird, stehen Verwaltungsobjekte von Drittanbietern und "net-snmp" nicht zur Verfügung.
            • Falls keiner der beiden Agenten UDP/161 öffnen kann, tritt eine Zeitüberschreitung ein.

            Umgehung: Führen Sie die folgenden Aufgaben in der angegebenen Reihenfolge aus.

            1. Stoppen Sie den Servicekonsolen-SNMP-Daemon (snmpd) mit diesem Befehl: service snmpd stop
            2. Starten Sie den VMware-SNMP-Daemon (hostd) mit diesem Befehl neu: service mgmt-vmware restart
          • Der Systemstatus der ESX/ESXi-Host-Serverkomponenten erscheint nicht auf der Registerkarte "Hardwarestatus"
            Wenn Sie die Nummer des HTTPS-Ports in der SFCB-Konfigurationsdatei ( sfcb.cfg) auf einen Port ändern, der nicht der Standardport ist, und den SFCB-Server (CIM) neu starten, erscheint der Systemstatus der Serverkomponenten des ESX/ESXi-Hosts nicht auf der Registerkarte "Hardwarestatus". Dieses Verhalten kommt zum Vorschein, wenn Sie sich direkt an einem ESX/ESXi-Host anmelden und auf die Registerkarte Konfiguration klicken, um den Systemstatus anzuzeigen. Statusinformationen für die Serverkomponenten erscheinen nicht. Dieses Problem tritt auf, weil vCenter Server und der SFCB-Server über verschieden Ports kommunizieren.

            Umgehung: Stellen Sie sicher, dass der SFCB-Server nur über den Standardport kommuniziert.

          • SNMP-PowerOn-Traps werden während eines Neustarts von "vmware_hostd" generiert
            Wenn Sie " vmware_hostd" neu starten, sollte standardmäßig nur die "Warm Start"-Trapmeldung generiert werden. Für alle auf Ihrem Host ausgeführten virtuellen Maschinen werden jedoch auch die PowerOn-Trapmeldungen generiert.

            Umgehung: Sie können die PowerOn-Trapmeldungen ignorieren.

          • ESX/ESXi schlägt möglicherweise beim Erkennen des zweiten Ports auf bestimmten IBM-Servern mit Dual-Port-FC-HBAs fehl
            Wenn Sie IBM x3650-Server mit Dual-Port-FC-HBAs verwenden, kann ESX/ESXi möglicherweise den zweiten Port nicht erkennen. Dieses Problem tritt möglicherweise auch auf anderen IBM-Servern mit derselben BIOS-Version auf.

            Umgehung: Führen Sie je nach Typ des von Ihrem Server verwendeten Adapters einen der folgenden Schritte aus:

            • Aktualisieren Sie für QLogic HBAs das IBM BIOS auf die neueste Version (Version 1.2).
            • Es gibt folgende Lösungen für Emulex HBAs:
              • Wenn Sie ESX von einer SAN aus starten, deaktivieren Sie die lokale Festplatte im BIOS des IBM-Servers.
              • Wenn Sie ESX von einer lokalen Festplatte oder ESXi starten, deaktivieren Sie BootBIOS für beide Ports auf dem Emulex HBA.

          Speicher

          • Auf ESX 4.0 und höher dauert es sehr lange, bis der Befehl "sg_inq" ausgeführt wird (KB 1029157)
          • Das Kopieren von großen Dateien von der ESX-Servicekonsole auf eine CIFS-gemountete Windows-Festplatte führt möglicherweise dazu, dass die Datei beschädigt wird
            Das Kopieren von großen Dateien von der ESX-Servicekonsole auf eine Windows-Festplatte, die unter Verwendung von CIFS gemountet wurde, führt möglicherweise dazu, dass die Datei beschädigt wird.

            Umgehung: Verwenden Sie beim Mounten von Windows-Festplatten in der Servicekonsole unter Verwendung von CIFS die Option forcedirection.

          • Während der ESX-Installation wird die ganze, für einen Datenspeicher ausgewählte physische Festplatte automatisch mit VMFS formatiert
            Sie können die Größe eines VMFS-Datenspeichers nicht ändern, auch dann nicht, wenn Sie während der Installation die erweiterte Partitionierung auswählen. Standardmäßig stellt das Installationsprogramm VMFS auf der ganzen physischen Festplatte bereit, die Sie für den Datenspeicher auswählen.

            Umgehung: Verwenden Sie eine Skriptinstallation, um Ihrem VMFS-Datenspeicher die erforderliche Größe zuzuweisen.

          • Die Eingabe von zusätzlichen statischen Erkennungszielen für Hardware-iSCSI schlägt möglicherweise fehl
            Der Versuch, beim Konfigurieren Ihres Hardware-iSCSI-Adapters zusätzliche statische Erkennungsziele einzugeben, schlägt möglicherweise fehl. Dies geschieht, wenn ein neues Ziel denselben iSCSI-Namen als das vorhandene Ziel aufweist, auch wenn sich ihre IP-Adressen unterscheiden.

            Umgehung: Verwenden Sie beim Konfigurieren von Hardware-iSCSI Statische Erkennungsziele mit verschieden iSCSI-Namen.

          • Der Pfadstatus für das CLARiiON iSCSI-Speichersystem ändert sich von "Ausgefallen" in "Aktiv" bzw. von "Aktiv" in "Ausgefallen", wenn mit dem Software-iSCSI-Initiator von ESX/ESXi auf das System zugegriffen wird
            Wenn Sie zum Zugreifen auf das CLARiiON iSCSI-Speichersystem den Software-iSCSI-Initiator verwenden, ändert sich der Pfadstatus häufig von "Ausgefallen" in "Aktiv" bzw. von "Aktiv" in "Ausgefallen". Dies liegt daran, dass CLARiiON den erweiterten Parameter "Verzögerte Quittierung (ACK)" nicht unterstützt, der standardmäßig auf Ihrem ESX/ESXi-Host aktiviert ist.

            Umgehung: Deaktivieren Sie auf Ihrem ESX/ESXi-Host den Parameter "Verzögerte Quittierung (ACK)", indem Sie die folgenden Schritte ausführen:

            1. Melden Sie sich am vSphere-Client an, und klicken Sie im Bestandslistenfenster auf den Host.
            2. Klicken Sie auf die Registerkarte Konfiguration und anschließend auf Speicheradapter.
            3. Wählen Sie den zu konfigurierenden Software-iSCSI-Initiator aus und klicken Sie auf Eigenschaften.
            4. Klicken Sie auf der Registerkarte "Allgemein" auf Erweitert.
            5. Heben Sie die Auswahl von Verzögerte Quittierung (ACK) auf.
          • Wenn Sie die PSP_RR-Pfadauswahlrichtlinie mit Failover-Clustering verwenden, treten Probleme bei gemeinsam genutzten Festplatten auf und der Cluster funktioniert möglicherweise nicht
            Das Failover-Clustering führt SCSI-3-Reservierungen auf gemeinsam genutzten Festplatten durch. Das Senden einer SCSI-3-Reservierung entlang eines Pfads erlaubt es dem Cluster, SCSI-3-Reservierungen nur auf diesem Pfad vorzunehmen. Wenn später PSP_RR auf einen anderen Pfad wechselt, kann das Failover-Clustering möglicherweise keine Reservierung vornehmen oder andere SCSI-3-Befehle verwenden, die von der Reservierung abhängen.

            Umgehung: Stellen Sie Geräte, die für gemeinsam genutzte Festplatten verwendet werden, nicht auf PSP_RR um. Verwenden Sie stattdessen je nach Standardwert für das Array die PSP_MRU- oder PSP_FIXED-Richtlinien.

          • Das Hinzufügen eines QLogic iSCSI-Adapters zu einem ESX/ESXi-System schlägt fehl, wenn ein vorhandenes Ziel mit demselben Namen, aber mit einer anderen IP-Adresse, vorhanden ist
            Das Hinzufügen eines statischen Ziels für einen QLogic Hardware-iSCSI-Adapter schlägt fehl, wenn ein Ziel mit demselben iSCSI-Namen bereits vorhanden ist, auch dann, wenn sich die IP-Adressen unterscheiden.

            Sie können einen Qlogic iSCSI-Adapter auf einem ESX/ESXi-System nur mit einem eindeutigen iSCSI-Namen für ein Ziel installieren, jedoch nicht mit einer Kombination aus IP und iSCSI-Namen. Zudem unterstützen der Treiber und die Firmware mehrere Sitzungen, die auf denselben Endpunkt zugreifen.

            Umgehung: Keine. Verwenden Sie nicht denselben iSCSI-Namen, wenn Sie Ziele hinzufügen.

          • Nach Eingabe des Servicekonsolenbefehls "fdisk" unter Angabe des absoluten Pfads der Festplatte erscheint eine Fehlermeldung
            Wenn Sie den Servicekonsolenbefehl fdisk ausführen und dabei den absoluten Pfad der Festplatte angeben (z. B. fdisk -l /vmfs/devices/disks/naa.600a0b80002a071c0000834248ca0b4f), wird folgende Fehlermeldung angezeigt:

            last_lba(): I don't know how to handle files with mode 8180

            Umgehung: Sie können diese Fehlermeldung ignorieren oder den folgenden Befehl ausführen:

            fdisk -l /dev/sdh

          • Das Starten von einer iSCSI-LUN ist möglicherweise zu langsam oder der Startvorgang schlägt fehl
            Falls iSCSI-Konfigurationsdaten vorhanden sind, bevor Sie beginnen, ein iSCSI-Startgerät über das QLogic-BIOS zu konfigurieren, können Sie doppelte iSCSI-Sitzungen für dasselbe Ziel erstellen. Wenn dies geschieht, sind E/A-Vorgänge möglicherweise sehr langsam oder sie schlagen fehl.

            Umgehung: Führen Sie die folgenden Schritte aus:

            1. Wählen Sie im BIOS zum Entfernen vorhandener iSCSI-Konfigurationsdaten die Option Dauerhafte Ziele löschen.
            2. Fügen Sie iSCSI-Startkonfigurationsdaten hinzu.
          • Die ESX-Servicekonsole erkennt keine Änderungen an, die zur Laufzeit an der LUN-Größe vorgenommen werden
            Wenn Änderungen an der Größe der LUN vorgenommen werden, die Ihrem ESX-Host zur Verfügung steht, wird die neue Größe vom VMkernel so erkannt, dass VMFS und virtuelle Maschinen die neue Größe verwenden können. Die Servicekonsole zeigt jedoch die alte Größe noch so lange an, bis Sie den Host neu gestartet haben. Dies liegt daran, dass die Servicekonsole die Gerätekapazität nur beim anfänglichen Gerätetest abruft.

            Umgehung: Starten Sie den ESX 3-Host neu. Falls Sie nicht neu starten möchten, führen Sie die folgenden Schritte aus:

            1. Stellen Sie sicher, dass die LUN nicht vom Host verwendet wird.
            2. Maskieren Sie die LUN vom Host aus.
            3. Prüfen Sie vom vSphere-Client aus den Speicheradapter erneut, den der Host zum Zugreifen auf die LUN verwendet.
            4. Heben Sie die Maskierung der LUN auf und sorgen Sie dafür, dass der Host auf sie zugreifen kann.
            5. Führen Sie eine erneute Prüfung des Speicheradapters durch.

            Jetzt zeigt die Servicekonsole die richtige LUN-Größe an.

          • Das Ändern des iSCSI-Parameters "Maximum Outstanding R2" auf Ihrem ESX/ESXi-Host in einen Wert größer als eins führt möglicherweise dazu, dass das Speichersystem der EMC CX3-Serie nicht ordnungsgemäß funktioniert
            Wenn Sie auf Ihrem ESX/ESXi-Host den Standardwert des iSCSI-Parameters "Maximum Outstanding R2" in einen Wert größer als eins ändern, funktioniert das Speichersystem der EMC CX3-Serie möglicherweise nicht richtig.

            Umgehung: Ändern Sie den Standardwert (1) für den Parameter "Maximal ausstehendes R2T" nicht.

          • ESX wird manchmal von einem Clariion-iSCSI-Speichersystem nicht gestartet
            Wenn Sie von iSCSI starten, startet Ihr ESX-Host möglicherweise nicht, wenn das Clariion-Speichersystem verwendet wird. Dies liegt daran, dass der QLogic Adapter SP versucht, von dem Standby-SP auf dem Clariion-Speicher zu starten, und den aktiven SP nicht korrekt erkennt.

            Umgehung: Stellen Sie sicher, dass die primären und die alternativem Start-LUNs im QLogic-BIOS auf unterschiedliche SPs auf dem Clariion-Speicher eingestellt sind. Falls dieses Problem weiterhin auftritt, ändern Sie die Reihenfolge der Start-LUNs.

          •   Die Portbindung kann in Zusammenhang mit IPv6-Ports nicht durchgeführt werden
            Die Portbindung ist ein Mechanismus zum Identifizieren von bestimmten VMkernel-Ports für die Verwendung durch den iSCSI-Speicherstack. Die Portbindung ermöglicht das Anwenden von Speicher-Multipathing-Richtlinien, wie z. B. VMware Round-Robin-Lastausgleich, MRU oder "fixed-path", auf iSCSI-Netzwerkkarten-Ports und Pfaden. Die Portbindung funktioniert nicht in Kombination mit IPv6. Wenn Benutzer die Portbindung konfigurieren, erwarten sie, dass sie zusätzliche Pfade für jede gebundene VMkernel-Netzwerkkarte sehen. Wenn Sie jedoch das Array unter einer globalen IPv6- Adresse konfigurieren, werden die zusätzlichen Pfade nicht eingerichtet. Benutzer sehen nur die Pfade, die auf einer IPv6-routbaren VMkernel-Netzwerkkarte eingerichtet wurden. Haben Benutzer beispielsweise zwei Zielportale und zwei VMkernel-Netzwerkkarten, so sehen sie bei Verwendung von IPv4 vier Pfade, aber nur zwei Pfade, wenn sie IPv6 verwenden. Weil es keine Pfade für Failover gibt, ist es nicht sinnvoll, eine Pfadrichtlinie einzurichten.

            Umgehung: Verwenden Sie IPv4 und die Portbindung, oder konfigurieren Sie das Speicher-Array und den ESX/ESXi-Host mit IPv6-Adressen des Typs "LOCAL SCOPE" auf demselben Subnetz (Switch-Segment). Zurzeit können Sie keine globale IPv6-Adressen zusammen mit der Portbindung verwenden.

          • Der ESX/ESXi-Host registriert keine Pfade, die von der Speicher-Manager-Anwendung hinzugefügt wurden
            Wenn Sie mithilfe der Speicher-Manager-Anwendung einen neuen Port zum Speichersystem hinzufügen, zeigt Ihr ESX/ESXi-Host keinen neuen Pfad zum Speichersystem an.

            Umgehung: Führen Sie die folgenden Schritte aus:

            1. Stellen Sie sicher, dass der ESX/ESXi-Host auf den Port zugreifen kann.
            2. Entfernen Sie die physische Verbindung für den neu hinzugefügten Port.
            3. Warten Sie, bis der Zeitgeber abläuft.
            4. Stellen Sie die physische Verbindung wieder her.
          • Das Anfordern des Pfads für ein Gerät kann nicht aufgehoben werden, wenn Sie die "autoclaiming"-Option deaktiviert haben
            Sie können das Anfordern eines Pfads für ein Gerät nicht aufheben, nachdem Sie die "autoclaiming"-Option auf Aus/Deaktiviert gesetzt haben.

            Umgehung: Die "autoclaiming"-Option wird in ESX/ESXi 4.0 nicht unterstützt.

          • In seltenen Fällen schlagen Vorgänge, die sich mit VMFS-Änderungen befassen, nach wiederholten SAN-Pfad-Failovern möglicherweise für alle ESX/ESXi-Hosts, die auf eine bestimmte LUN zugreifen, fehl.
            In seltenen Fällen schlagen nach wiederholten Pfad-Failovern auf eine bestimmte SAN-LUN möglicherweise Versuche fehl, auf allen ESX/ESXi-Hosts, die auf diese LUN zugreifen, Vorgänge durchzuführen, wie z. B. das Erstellen eines VMFS-Datenspeichers, vMotion usw. Folgende Warnungen erscheinen in den Protokolldateien aller betroffenen Hosts:
            • I/O failed due to too many reservation conflicts.
            • Reservation error: SCSI reservation conflict

            Falls Sie die Reservierungskonfliktmeldungen auf allen Hosts sehen, die auf die LUN zugreifen, bedeutet dies, dass das Problem durch die SCSI-Reservierungen für die LUN, die nicht vollständig aufgeräumt wurde, verursacht wird.

            Umgehung: Führen Sie von einem beliebigen System im Cluster aus den folgenden Befehl zum Zurücksetzen der LUN aus, um die SCSI-Reservierung zu entfernen:

            vmkfstools -L lunreset /vmfs/devices/disks/

          • vCenter Server kann die RDM nicht öffnen, nachdem die LUN des RDM geändert wurde
            VMware unterstützt keine LUN-Nummer-Änderungen (Positionsänderungen) innerhalb des Ziels. Wenn die LUN-Nummer geändert wird, kann vCenter Server die RDM, die auf der LUN basiert, nicht öffnen. Eine RDM-Datei (Raw Device Mapping) befindet sich auf dem VMFS-Datenspeicher und verweist auf eine LUN. Die LUN-Nummer zeigt die Position der LUN innerhalb des Ziels. Wenn sich diese Nummer (oder Position) ändert, ändert sich auch der vml-Bezeichner (vml_ID) für die RDM-Datei. Sie können beispielsweise VMFS-Datenspeicher nicht trennen und sie anschließend in einer anderen Reihenfolge neu verbinden. Dies ändert die Identifikation der LUN, sodass auf sie nicht mehr zugegriffen werden kann und vCenter Server verhindert, dass die virtuelle Maschine eingeschaltet wird. vSphere Client verwendet die vml_ID aus Gründen der Abwärtskompatibilität.

            Umgehung: Entfernen Sie die RDM und erstellen Sie sie neu. Eine neue vml_ID wird generiert, die die LUN erkennen kann.

          • vSphere-Client zeigt Laufwerksfehleralarme an, wenn auf ESX- und ESXi-Hosts mit IBM-Mehrknotensystemen das Laufwerk nicht vorhanden ist
            Auf manchen IBM-Mehrknotensystemen meldet die BMC-Firmware einen Laufwerksfehler für Laufwerkssteckplätze, wenn kein Laufwerk vorhanden ist. Der vSphere-Client meldet, dass der Laufwerksfehlersensor den Status "Alarm" hat. Die identischen Fehler werden in der IBM iLOM-Schnittstelle angezeigt.

            Umgehung: Keine. Ein Fehlerbericht wurde an IBM geschickt, um dieses Problem zu beschreiben.

          • NAS-Datenspeicher geben den verfügbaren Speicherplatz falsch wieder
            Wenn Sie den verfügbaren Speicherplatz für einen ESX/ESXi-Host mithilfe des Befehls df (ESXi) oder vdf (ESX) in der Host-Servicekonsole anzeigen lassen, handelt es sich bei dem gemeldeten Speicherplatz für ESX/ESXi-NAS-Datenspeicher um freien Speicherplatz und nicht um verfügbaren Speicherplatz. Der Speicherplatz von NFS-Volumes, der in der Spalte "Frei" angegeben wird, wenn Sie Speicher > Datenspeicher auf der Registerkarte Konfiguration des vSphere-Clients wählen, zeigt auch den freien Speicherplatz an, nicht den verfügbaren Speicherplatz. In beiden Fällen kann sich der freie von dem verfügbaren Speicherplatz unterscheiden.

            ESX-Dateisysteme unterscheiden nicht zwischen freien und verfügbaren Blöcken, sondern melden immer freie Blöcke für beide Blocktypen (genau genommen die Felder "f_bfree" und "f_bavail" der struct "statfs"). Freie und verfügbare Blöcke können sich bei NFS-Volumen unterscheiden.

            Umgehung: Sie können korrekte Informationen hinsichtlich des verfügbaren Speicherplatzes von NFS-Servern abrufen. Für ESX/ESXi gibt es keine Umgehung.

          • Harmlose Warnmeldungen zu Bereichskonflikten werden in den VMkernel-Protokollen für manche IBM-Server protokolliert
            Wenn der SATA/IDE-Controller im PCI-Konfigurationsbereich im Legacy-PCI-Modus arbeitet, wird möglicherweise eine Fehlermeldung ähnlich der Folgenden zu den VMkernel-Protokollen hinzugefügt:

            WARNING: vmklinux26: __request_region: Diese Meldung wurde einmal wiederholt: Region conflict @ 0x0 => 0x3

            Umgehung: Solche Fehlermeldungen sind harmlos und können bedenkenlos ignoriert werden.
          • Das Gewähren von Berechtigungen zum Ändern eines Datenspeichers ermöglicht Benutzern, systemverwandte Dateien zu ändern
            Durch das Gewähren aller Berechtigungen zum Ändern von Datenspeichern wird es Benutzern ermöglicht, die Systemdateien auf dem lokalen ESX-Datenspeicher zu ändern, einschließlich der Servicekonsolen-VMDK-Datei ( esxconsole.vmdk). Diese Datei befindet sich im Ordner /esxconsole-in einem Datenspeicher. Falls ein Benutzer den Ordner esxconsole oder die VMDK-Datei umbenennt, kann der ESX-Host nicht neu starten.

            Umgehung: Sorgen Sie dafür, dass nur Administratoren Datenspeicher ändern dürfen. Stellen Sie sicher, dass sich diejenigen Benutzer, die berechtigt sind, Datenspeicher zu ändern, über die Probleme, die auftreten können, wenn der Ordner esxconsole oder die Datei esxconsole.VMDK umbenannt wird, im Klaren sind.

          • Das Verwenden von Storage vMotion zum Verlagern einer virtuellen Maschine zurück in deren Quellvolume führt möglicherweise zu einem Fehler des Typs "Unzureichender Festplattenspeicher"
            Wenn Sie Storage vMotion zum Verschieben einer virtuellen Maschine in einen anderen Datenspeicher und anschließend zurück in deren Quellvolume verwenden, aktualisiert der vSphere-Client die Größe des Quelldatenspeichers nicht sofort, was zu einem Fehler führt.

            Umgehung: Aktualisieren Sie den Datenspeicher im vSphere-Client. Falls sich nach dem ersten Versuch die gemeldete Größe des Datenspeichers nicht ändert, warten Sie 30 Minuten und versuchen Sie es erneut.

          • Das Dienstprogramm "vmfs-undelete" steht ESX/ESXi 4.0 nicht zur Verfügung
            Bei ESX/ESXi 3.5 Update 4 wurde ein Dienstprogramm namens "vmfs-undelete" mitgeliefert, das zum Wiederherstellen von gelöschten .vmdk-Dateien verwendet wurde, sofern sie nicht auf Blockebene überschrieben wurden. Dieses Dienstprogramm steht ESX/ESXi 4.0 nicht zur Verfügung.

            Umgehung: Keine. Gelöschte .vmdk-Dateien können nicht wiederhergestellt werden.

          • Wenn der Speicherprozessor eines HP MSA2012fc-Speicher-Arrays zurückgesetzt wird, werden fälschlicherweise kritische Warnungen ausgegeben
            Beim Zurücksetzen des Speicherprozessors des HP MSA2012fc-Speicher-Arrays sendet das ESX/ESXi NMP-Modul (Native Multipathing) Warnungen oder kritische Einträge an die VMkernel-Protokolle. Diese Warnmeldungen geben an, dass das physische Medium für das Gerät geändert wurde. Diese Meldungen treffen jedoch nicht für alle LUN-Typen zu. Sie sind nur kritisch für Daten-LUNs, gelten jedoch nicht für Verwaltungs-LUNs.

            Umgehung: Das Problem kann nicht umgangen werden. In diesem Szenario können Sie beruhigt die protokollierten Warnungen ignorieren, sofern sie sich auf Verwaltungs-LUNs beziehen.
          • Eine virtuelle Maschine kann beim Zurücksetzen der SCSI-LUNs eine Endlosschleife verursachen, die das Herunterfahren der virtuellen Maschine verhindert
            Wenn SCSI-Treiber (entweder BusLogic oder LSI Logic) einer virtuellen Maschine die LUNs aus irgendwelchen Gründen zurücksetzen, kann dies eine Endlosschleife verursachen.
            Versuche, die virtuelle Maschine abzuschießen, verlaufen nicht erfolgreich.
          •  Das Gastbetriebssystem meldet E/A-Fehler in Bezug auf LSI-Controller
            Online-Upgrades der Controller-Firmware auf einem Array mit einem LSI-Controller können möglicherweise E/A-Ausfälle auf virtuellen Maschinen verursachen, die auf das Array zugreifen. Viele Arrays verwenden einen LSI-Controller. Bei der folgenden Liste handelt es sich beispielsweise um einige gängige Arrays, die LSI-Controller einsetzen:
            • IBM DS48xx Serie
            • IBM DS 3xxx Serie
            • Dell MD3xxx Serie
            • Sun STK Flexline Serie

            Umgehung: Bevor Sie die Firmware auf einem Speichercontroller aktualisieren, leiten Sie von Hand alle LUNs auf den anderen Speichercontroller um und stellen Sie sicher, dass der ESX/ESXi-Host keine E/A an den Speichercontroller sendet.

          •  Die Befehle der Servicekonsole liefern möglicherweise irreführende Informationen über die Cisco UCS Qlogic FCoE-Controller
            Auf Cisco Unified Computing-Systemen (UCS) mit einem Qlogic FCoE-Controller wird über die Befehle der Servicekonsole esxcfg-scsidevs -aund lspcimöglicherweise nicht der Controller als Qlogic FCoE-Controller, sondern als Fibre-Channel-Controller identifiziert.

            Beispielsweise werden in der Ausgabe der folgenden Befehle der Servicekonsole die Cisco UCS Qlogic FCoE-Controller nicht ausdrücklich als FCoE-Controller identifiziert.

            • Der Befehl lspcifür Cisco UCS Qlogic FCoE Controller:
              04:00.0 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03)
              04:00.1 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03)


            • Der Befehl esxcfg-scsidevs -afür Cisco UCS Qlogic FCoE-Controller:
              vmhba1 qla2xxx link-up fc.20010025b500000a:20000025b500001a (0:4:0.0) QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA
              vmhba2 qla2xxx link-up fc.20010025b500000a:20000025b500000a (0:4:0.1) QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA

          Unterstützte Hardware

          • Das Starten von VMware ESX schlägt möglicherweise auf Dell 2900-Servern fehl
            Wenn auf einem Server des Typs Dell 2900 ein älteres BIOS als 2.1.1 installiert ist, reagiert der VMkernel von ESX während des Starts möglicherweise nicht mehr. Dies ist auf einen Fehler im Dell BIOS zurückzuführen, der in der BIOS-Version 2.1.1 behoben ist.

            Umgehung: Aktualisieren Sie das BIOS auf die Version 2.1.1 oder später.

          • Es werden keine CIM-Alarme empfangen, wenn das Stromkabel und das Netzteil neu an HP-Server angeschlossen werden
            Es werden keine neuen SEL(IML)-Einträge für das erneute Anschließen des Stromkabels und des Netzteils auf HP-Servern erstellt, wenn eine unterbrochene Stromversorgung wiederhergestellt wird. Dies führt dazu, dass keine CIM-Alarme für diese Ereignisse generiert werden.

            Umgehung: Keine

          • Core-Dump schlägt mit einer Zeitüberschreitungsmeldung fehl
            Das Konfigurieren eines mit einem Perc 4/DC-Controller verbundenen Geräts als Core-Dump-Gerät, auf dem im Falle eines Systemabsturzes Crash-Dumps gespeichert werden, kann zu Zeitüberschreitungen und nicht gespeicherten Core-Dumps führen. Dieses Zeitüberschreitungsverhalten wurde bei verschiedenen Firmware-Versionen auf diesem Controller (z. B., 352B und 352D) und nur für Systemabstürze beobachtet. Es wurden keine Probleme beim E/A auf demselben Gerät beobachtet, wenn das System läuft.

            Umgehung: Konfigurieren Sie kein mit einem Perc 4/DC-Controller verbundenes Gerät als Core-Dump-Gerät für ESX/ESXi 4.0-Systeme.

          • ESX/ESXi auf der HP G6-Plattform mit P410i oder P410 Smart Array-Controller läuft während des Einschaltens der virtuellen Maschinen oder bei Festplatten-E/A-Vorgängen langsam
            Einige dieser Hosts laufen möglicherweise beim Einschalten von virtuellen Maschinen oder bei Festplatten-E/A-Vorgängen langsam. Die Hauptsymptom ist eine herabgestufte E/A-Leistung, wodurch viele Fehlermeldungen ähnlich der Folgenden in /var/log/messages protokolliert werden.

            Mar 25 17:39:25 vmkernel: 0:00:08:47.438 cpu1:4097)scsi_cmd_alloc returned NULL!
            Mar 25 17:39:25 vmkernel: 0:00:08:47.438 cpu1:4097)scsi_cmd_alloc returned NULL!
            Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)NMP: nmp_CompleteCommandForPath: Command 0x28 (0x410005060600) to NMP device
            "naa.600508b1001030304643453441300100" failed on physical path "vmhba0:C0:T0:L1" H:0x1 D:0x0 P:0x0 Possible sense data: 0x
            Mar 25 17:39:26 0 0x0 0x0.
            Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)WARNING: NMP: nmp_DeviceRetryCommand: Device
            "naa.600508b1001030304643453441300100": awaiting fast path state update for failoverwith I/O blocked. No prior reservation
            exists on the device.
            Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)NMP: nmp_CompleteCommandForPath: Command 0x28 (0x410005060700) to NMP device
            "naa.600508b1001030304643453441300100" failed on physical path "vmhba0:C0:T0:L1" H:0x1 D:0x0 P:0x0 Possible sense data: 0x
            Mar 25 17:39:26 0 0x0 0x0.

            Umgehung: Installieren Sie das 256 MB große Cache Upgrade-Modul der HP P-Serie.

          • Auf bestimmten Versionen des vSphere-Clients wird der Status des Akkus möglicherweise falsch als alarmierend angezeigt
            Wenn sich der Akku im Lernmodus befindet, wird im vSphere-Client auf der Registerkarte "Hardwarestatus" eine Alarmmeldung angezeigt, die angibt, dass der Status des Akkus nicht in Ordnung ist. Allerdings ist der Ladezustand des Akkus in Ordnung.

            Umgehung: Keine.
          • Die Meldung "Detected Tx Hang" wird in der VMkernel-Protokolldatei angezeigt
            Einige Varianten der e1000-Netzwerkkarten blockieren aufgrund von Hardwarefehlern unter Volllast. ESX/ESXi erkennt das Problem und setzt die Karte automatisch zurück. Dieses Problem steht im Zusammenhang mit Tx-Paketen, TCP-Arbeitslasten und TCP Segmentation Offloading (TSO).

            Umgehung: Sie können TSO deaktivieren, indem Sie in der Datei esx.confdie Option /adv/Net/UseHwTSOauf 0 setzen.

           

          •   Probleme mit dem TEAC DV-28E-V DVD-Laufwerk
            Wenn ein ESX/ESXi-Host physisch mit einem TEAC DV-28E-V DVD-Laufwerk mit alter Firmware (beispielsweise C.AB) verbunden ist, reagiert die virtuelle Maschine, der Host-Daemon oder der ESX/ESXi-Host möglicherweise nicht mehr. Das Problem tritt nicht immer auf, am ehesten wurde es bei virtuellen Windows-Maschinen beobachtet.

            Umgehung: Aktualisieren Sie die Firmware des DVD-Laufwerks auf die neueste Version oder ersetzen Sie das DVD-Laufwerk durch ein anderes Modell.

          Upgrade und Installation

          • Ein Upgrade von ESX 4.0 auf ESX 4.0.x oder ESX 4.x mithilfe des Befehls "esxupdate" führt zu einer Fehlermeldung (KB 1038732)
          • Der Datenbank-Upgrade-Assistent des vCenter Server-Systems schätzt während eines Upgrades von VirtualCenter 2.0.x auf vCenter Server 4.0 den erforderlichen Festplattenspeicher möglicherweise als zu hoch ein
            Während eines Upgrades von VirtualCenter 2.0.x auf vCenter Server 4.0 kann der Datenbank-Upgrade-Assistent einen falschen Wert für den erforderlichen Festplattenspeicher anzeigen. In der Regel ist die angezeigte Schätzung höher als der tatsächlich erforderliche Speicherplatz.

            Umgehung: Keine

          • Die Installation des vSphere-Clients schlägt möglicherweise mit dem Fehler 1603fehl, wenn Sie nicht über eine aktive Internetverbindung verfügen
            Sie können den vSphere-Client auf zwei Arten installieren: Vom vCenter Server-Medium aus oder indem Sie auf einen Link im ESX-, ESXi- oder vCenter Server-Begrüßungsbildschirm klicken. Das Installationsprogramm auf dem vCenter Server-Medium (.iso-Datei oder .zip-Datei) enthält zusätzlich zum vSphere-Client-Installationsprogramm ein vollständiges .NET-Installationsprogramm. Das Installationsprogramm, das über den Begrüßungsbildschirm aufgerufen wird, enthält ein vSphere-Client-Installationsprogramm, das die .NET-Installationsprogrammkomponenten aus dem Internet abruft.

            Wenn Sie nicht über eine Internetverbindung verfügen, schlägt die zweite vSphere-Client-Installationsmethode mit dem Fehler 1603fehl, es sei denn, .NET 3.0 SP1 ist bereits auf Ihrem System installiert.

            Umgehung: Richten Sie eine Internetverbindung ein, bevor Sie den Download versuchen, installieren Sie den vSphere-Client vom vCenter Server-Medium aus oder installieren Sie .NET 3.0 SP1, bevor Sie auf den Link auf dem Begrüßungsbildschirm klicken.

          • Öffnen von Leistungsdiagrammen nach einem Upgrade führt zu einer Fehlermeldung
            Nach Durchführung eines Upgrades unter Verwendung der Microsoft SQL Express Edition-Datenbank zeigt der vSphere-Client die Fehlermeldung Beim Leistungsdiagrammdienst ist ein interner Fehler aufgetreten an, wenn Sie Leistungsdiagramme öffnen. Dies liegt daran, dass das Installationsprogramm den Datenbankdienst nicht neu startet, wenn Änderungen an den Datenbankeinstellungen vorgenommen wurden.

            Umgehung: Führen Sie die folgenden Schritte aus:

            1. Halten Sie den VMware VirtualCenter Server-Dienst in Windows an.
            2. Starten Sie den Datenbankdienst neu.
            3. Starten Sie den VMware VirtualCenter Server-Dienst.
            4. Öffnen Sie eine neue vSphere-Client-Instanz und melden Sie sich beim vCenter Server an.
          • Einige Kickstart-Befehle für Skriptinstallationen von ESX 4.0 sind veraltet oder werden in dieser Version nicht unterstützt
            Falls Ihr Installationsskript nicht mit ESX 4.0 funktioniert, enthält es möglicherweise veraltete oder nicht unterstützte Befehle. Die folgenden Kickstart-Befehle sind veraltet:

            autostep
            clearpart --linux
            clearpart --exceptvmfs
            cmdline
            device
            deviceprobe
            firewall --enabled(wurde durch esxcfg-firewall --blockIncoming und esxcfg-firewall --blockOutgoing ersetzt)
            firewall --disabled(wurde durch esxcfg-firewall --allowIncomingund esxcfg-firewall --allowOutgoing ersetzt)
            firstboot
            harddrive
            ignoredisk
            interactive
            lang
            (Die Standardeinstellung wird verwendet.)
            langsupport
            (Die Standardeinstellung wird verwendet.)
            lilo
            lilocheck
            logvol
            mouse
            part --onvmdk
            raid
            skipx
            text
            vmaccepteula
            (heißt jetzt accepteula)
            vnc
            volgroup
            xconfig
            xdisplay
            %packages
            (packages.xml wird jetzt für das Anpassen von Paketen verwendet)
            %vmlicense_text

            Die nachfolgenden Red Hat Enterprise Linux 3-Befehle werden nicht unterstützt:

            autostep
            cmdline
            device
            deviceprobe
            firewall --blockIncoming
            firewall --blockOutgoing
            firstboot
            harddrive
            ignoredisk
            interactive
            lang
            langsupport
            lilo
            lilocheck
            logvol
            mouse
            raid
            skipx
            text
            vnc
            volgroup
            xconfig
            xdisplay

            Umgehung: Verwenden Sie nur die Kickstart-Befehle, die von VMware unterstützt werden. Eine detaillierte Liste der unterstützten Befehle finden Sie im Installationshandbuch – ESX und vCenter Server.

          • Falls Sie für die Servicekonsole einen gemeinsam genutzten Datenspeicher auswählen, gibt das Installationsprogramm bzw. das Upgrade-Tool keine Warnmeldung aus
            Im Falle von ESX 4.0 muss die Servicekonsole auf einem VMFS-Datenspeicher installiert werden, der sich auf einer lokalen Festplatte des Hosts oder auf einer SAN-Festplatte befindet, die maskiert und ausschließlich in die Zone dieses bestimmten Hosts eingeteilt ist. In dieser Version wird das Installieren der Servicekonsole auf einem Datenspeicher, der von mehreren Hosts gemeinsam genutzt wird, nicht unterstützt. Sie müssen beim Installieren von oder Aktualisieren auf ESX 4.0 den Speicherort eines VMFS-Datenspeichers ( esxconsole.vmdk) für die Servicekonsole auswählen. Wenn Sie einen Datenspeicher auswählen, der von mehreren Hosts gemeinsam genutzt wird, gibt das Installationsprogramm bzw. das Upgrade-Tool keine Warnmeldung aus.

            Umgehung: Installieren Sie die Servicekonsole nicht auf einem VMFS-Datenspeicher, der von mehreren Hosts gemeinsam genutzt wird.

          • Wenn SQL Native Client bereits installiert ist, können Sie vCenter mit der mitgelieferten SQL Server 2005 Express-Datenbank nicht installieren
            Wenn Sie vCenter mit der mitgelieferten SQL Server 2005 Express-Datenbank installieren und SQL Native Client bereits installiert ist, schlägt die Installation mit folgender Fehlermeldung fehl:

            Ein Installationspaket für das Produkt Microsoft SQL Native Client wurde nicht gefunden. Versuchen Sie, die Installation unter Verwendung einer gültigen Kopie des Installationspakets "sqlcli.msi" durchzuführen.

            Umgehung: Deinstallieren Sie SQL Native Client, sofern er nicht von einer anderen Anwendung verwendet wird. Installieren Sie anschließend vCenter mit der mitgelieferten SQL Server 2005 Express-Datenbank.

          • Der VMxnet-Treiber wird nicht automatisch installiert, wenn Sie VMware Tools installieren oder Upgrade
            Wenn Sie auf einer virtuellen Maschine, auf der das Gastbetriebssystem Windows NT ausgeführt wird, VMware Tools installieren oder Upgrade, wird der vmxnet-Treiber nicht automatisch installiert.

            Umgehung: Installieren Sie den VMxnet-Treiber manuell. Führen Sie dazu die folgenden Schritte aus:

            1. Melden Sie sich bei der virtuellen Maschine an und klicken Sie mit der rechten Maustaste auf Netzwerkumgebung.
            2. Klicken Sie auf Eigenschaften und wählen Sie die Registerkarte Adapter aus.
            3. Klicken Sie auf Diskette und geben Sie den Pfad für den Treiber ein:
              C:\Programme\VMware\VMware Tools\Drivers\vmxnet\
            4. Starten Sie die virtuelle Maschine neu.
          • Beim Starten von ESX auf einer Dell Precision T3400-Workstation wird das grafische Installationsprogramm nicht geladen
            Wenn Sie auf einer Dell Precision T3400-Workstation versuchen, das grafische Installationsprogramm zum Installieren von ESX zu verwenden, schlägt die Installation fehl.

            Umgehung: Verwenden Sie stattdessen das Textinstallationsprogramm.

          • Nach Abbrechen der Deinstallation von vSphere-Client 4.0 kann das Produkt weder neu installiert noch deinstalliert werden
            Wurde die Installation des vSphere-Clients abgebrochen, erscheint folgende Fehlermeldung, wenn erneut versucht wird, vSphere Client 4.0 zu installieren bzw. zu deinstallieren:

            Fehler beim Anwenden einer Transformation. Stellen Sie sicher, dass die angegebenen Transformationspfade gültig sind.

            Umgehung: Verwenden Sie das Windows-Dienstprogramm in der Systemsteuerung, um vSphere Client 4.0 zu deinstallieren.

          • Der VMware Web Access-Kickstart-Skriptgenerator wird nicht unterstützt
            Der VMware Web Access-Kickstart-Skriptgenerator steht in vSphere 4.0 für eine ESX-Skriptinstallation nicht zur Verfügung.

            Umgehung: Sie können das Kickstart-Skript verwenden, das automatisch nach einer interaktiven Installation generiert wird. Nach der ersten interaktiven Installation von ESX erstellt das Installationsprogramm ein /root/ks.cfg-Skript im ESX-Dateisystem. Dieses Skript enthält die Einstellungen, die Sie während der interaktiven Installation vorgenommen haben. Eine vollständige Liste der unterstützten Befehle und ein Beispielskript finden Sie im Installationshandbuch – ESX und vCenter Server.

          • Nach dem Deinstallieren des vSphere-Clients bleiben leere Verzeichnisse übrig
            Wenn Sie den vSphere-Client deinstallieren, bleiben leere Verzeichnisse übrig.

            Umgehung: Navigieren Sie in das Installationsverzeichnis und löschen Sie das Verzeichnis Virtual Infrastructure-Client.

          • Auf dem Startlaufwerk sind mindestens 650 MB an freiem Speicherplatz für die Installation von vCenter Server erforderlich
            Obwohl vCenter Server selbst nicht auf dem Startlaufwerk installiert werden muss, müssen einige erforderlichen Komponenten auf dem Startlaufwerk installiert werden. Um diese erforderlichen Komponenten sowie die temporären Dateien, die während der Installation verwendet werden, aufzunehmen, werden 650 MB an freiem Speicherplatz benötigt.

            Umgehung: Stellen Sie sicher, dass mindestens 650 MB freier Speicherplatz auf dem Startlaufwerk zur Verfügung stehen, bevor Sie vCenter Server installieren.

          • Beim Herunterladen des vSphere Client 4.0 tritt eine Zeitüberschreitung mit Fehlermeldung ein, wenn Sie einen VI Client 2.0.x auf einer Windows 2003-Maschine mit vCenter Server oder einem ESX/ESXi-Host verbinden
            Wenn Sie eine VI Client 2.0.x-Instanz mit vCenter Server 4.0 oder einem ESX/ESXi 4.0-Host verbinden, wird vSphere Client 4.0 automatisch auf die Windows-Maschine heruntergeladen, auf der sich der VI-Client befindet. Dieser Vorgang basiert auf Internet Explorer, um dieses Download durchzuführen. Auf Windows 2003-Systemen blockiert Internet Explorer standardmäßig das Download, wenn es sich bei der VI-Client-Instanz um VI Client 2.0.x handelt.

            Umgehung: Wählen Sie in Internet Explorer Extras > Internetoptionen > Erweitert und deaktivieren Sie die Option Verschlüsselte Seiten nicht auf der Festplatte speichern. Laden Sie alternativ den vSphere Client 4.0 manuell von vCenter Server 4.0 oder vom ESX/ESXi 4.0-Host herunter.

          • Die Installation von ESX/ESXi auf einer IBM x336-Maschine schlägt wegen der BIOS-Inkompatibilität möglicherweise fehl
            Auf einigen Computern des Typs IBM x336 kann es passieren, dass der ESX/ESXi-Installationsvorgang gestoppt wird. Dies ist auf einen Bug im BIOS der Maschine zurückzuführen.

            Umgehung: Upgrade Sie das BIOS der Maschine auf Version 1.15, bevor Sie ESX oder ESXi Installable installieren.

          • Wenn Sie zum Durchführen eines ESX-Host-Upgrades vSphere Host Update Utility verwenden, schlägt das Upgrade möglicherweise fehl
            Wenn Sie zum Durchführen eines ESX-Upgrades vSphere Host Update Utility verwenden, schlägt das Upgrade möglicherweise mit folgendem Fehler fehl:

            Während des Upgrades ist ein Fehler aufgetreten. Die Verbindung zum Upgrade-Agenten wurde unterbrochen.

            Dies geschieht, wenn das Upgrade zu 26 % abgeschlossen ist. Der Prozess hält in der Servicekonsole bei VMware ESX Server Management-Dienste werden gestoppt an.

            Umgehung: Starten Sie den ESX-Host manuell neu, indem Sie auf die Schaltfläche "Zurücksetzen" klicken. Das ESX-Upgrade setzt sich fort und wird erfolgreich abgeschlossen, aber vSphere Host Update Utility zeigt den Fortschritt nicht an. Klicken Sie zum Anzeigen des aktuellen Hoststatus von vSphere Host Update Utility auf Erneut versuchen.

          • Wenn Sie unter Verwendung der DVD ESX lokal installieren und dabei ein bestimmtes DVD-Modell benutzen, schlägt die ESX-Installation fehl
            Das lokale Installieren von ESX schlägt fehl, wenn Sie Folgendes verwenden: SONY AMAX 270 DVD RW AW-Q170A, Rev: 1.70. Die DVD wird nicht erkannt.

            Umgehung: Aktualisieren Sie die Firmware auf SONY DVD RW AW-Q170A, Rev: 1.74 und führen Sie die Installation erneut durch.

          • vCenter Server-Datenbank-Upgrade schlägt für Oracle 10gR2-Datenbanken mit bestimmten Benutzerberechtigungen fehl
            Wenn Sie VirtualCenter Server 2.x auf vCenter Server Version 4.0 Upgrade und Sie über die Berechtigungen "connect", "create view", "create any sequence", "create any table" und "execute on dbms_lock" für die Datenbank (Oracle 10gR2) verfügen, schlägt das Upgrade fehl. Die Datei VCDatabaseUpgrade.log zeigt folgenden Fehler:

            Fehler: Failed to execute SQL procedure. Got exception: ERROR [HY000] [Oracle][ODBC][Ora]ORA-01536: space quota exceeded for tablespace 'USERS'

            Umgehung: Vergrößern Sie als Datenbankadministrator den Benutzer-Tablespace oder gewähren Sie dem Benutzer, der das Upgrade durchführt, die Berechtigung "unlimited tablespace".

          • Das Installieren von vCenter Server unter Windows Server 2008 schlägt bei Verwendung eines Benutzerkontos, bei dem es sich nicht um ein Systemkonto handelt, fehl
            Wenn Sie während der Installation ein Benutzerkonto angeben, bei dem es sich nicht um ein Systemkonto handelt, schlägt die Installation von vCenter Server mit folgender Fehlermeldung fehl:

            Fehler beim Erstellen des vCenter-Repositorys

            Umgehung: Schalten Sie auf dem System, auf dem vCenter Server installiert wird, unter Systemsteuerung > Benutzerkonten die Option "Benutzerkontensteuerung" aus, bevor Sie vCenter Server installieren. Geben Sie während der vCenter Server-Installation den Nicht-Systembenutzer an.

          • Nach einem Upgrade auf vCenter Server 4.0 scheinen nicht kompatible Legacy-Plug-Ins im Plug-In-Manager des vSphere-Clients aktiviert zu sein
            Wenn VirtualCenter 2.5 zusammen mit VMware Update Manager 1.0 oder VMware Converter Enterprise für VirtualCenter 2.5 installiert ist und auf vCenter Server 4.0 aktualisiert wird, scheinen die Legacy-Plug-Ins im Plug-In-Manager des vSphere-Clients installiert und aktiviert zu sein. Frühere Versionen der Plug-In-Module sind jedoch nicht kompatibel mit vCenter Server 4.0. In solchen Fällen stehen die Plug-Ins möglicherweise zur Verfügung, diese sind jedoch nicht funktionsfähig.

            Umgehung: Aktualisieren Sie VMware Update Manager auf VMware vCenter Update Manager 4.0 und VMware Converter Enterprise auf VMware vCenter Converter (für vCenter Server 4.0) und installieren und aktivieren Sie anschließend die Plug-Ins.

          • Keine Anmeldung bei VirtualCenter Server 2.5 möglich, nachdem der VI Client 2.0.x, 2.5 und vSphere Client 4.0 auf einem Windows Vista-System installiert wurden und der VI Client 2.0.x deinstalliert wurde
            Nach dem Deinstallieren des VI Client 2.0.x auf einer Windows Vista-Maschine, auf der VI Client 2.0.x und 2.5 sowie vSphere Client 4.0 gleichzeitig vorhanden sind, ist keine Anmeldung bei vCenter Server 2.5 möglich. Die Anmeldung schlägt mit folgender Meldung fehl:

            Klasse nicht registriert (Ausnahme von HRESULT:0x80040154(REGDB_E_CLASSNOTREG))

            Umgehung: Deaktivieren Sie die Benutzerkontensteuerung auf dem System, auf dem VI Client 2.0.x, 2.5 und vSphere Client 4.0 zusammen installiert sind, oder deinstallieren Sie den VI Client 2.5 und installieren Sie ihn neu.

          • Das ESX/ESXi-Installationsprogramm führt die lokalen SAS-Speichergeräte im Abschnitt "Remotespeicher" auf
            Beim Anzeigen der Speicherorte, in denen ESX oder ESXi Installable installiert wird, führt das Installationsprogramm im Abschnitt "Remotespeicher" ein lokales SAS-Speichergerät auf. Dies liegt daran, dass ESX/ESXi nicht feststellen kann, ob das SAS-Speichergerät lokal oder remote ist. Es wird deshalb immer als remote angesehen.

            Umgehung: Keine

          • Wenn Sie auf manchen Dell-Servern ESX unter Verwendung der virtuellen DRAC5-CD-ROM-Methode installieren, schlägt die ESX-Installation fehl
            Die Verbindung des virtuellen Mediums wird getrennt, wenn Sie auf manchen Dell PowerEdge-Servern versuchen, unter Verwendung der virtuellen DRAC5-CD-ROM-Methode ESX zu installieren.

            Umgehung: Statt virtuelle Medien zu benutzen, installieren Sie ESX von dem lokalen CD-Laufwerk oder aktualisieren Sie die Firmware-Version auf Version 1.33 (08.03.10).

          • Wenn vSphere Host Update Utility die Netzwerkverbindung zum ESX-Host verliert, funktioniert das Host-Upgrade möglicherweise nicht
            Wenn Sie zum Durchführen eines ESX/ESXi-Host-Upgrades das vSphere Host Update Utility verwenden und die Verbindung des Dienstprogramms mit dem Host unterbrochen wird, wird der Host möglicherweise nicht vollständig aktualisiert. Wenn dies geschieht, reagiert das Dienstprogramm möglicherweise nicht mehr oder die folgende Fehlermeldung wird ausgegeben:

            Fehler beim Ausführen der Kompatibilitätsprüfung auf dem Host.

            Umgehung: Schließen Sie das Dienstprogramm, reparieren Sie die Netzwerkverbindung, starten Sie das Dienstprogramm neu und führen Sie das Upgrade erneut aus.

          • Das vCenter Server-Installationsprogramm gibt während der Installation bzw. des Upgrades falsche Warnmeldungen aus
            Während der Installation bzw. des Upgrades weist das vCenter Server-Installationsprogramm per Warnmeldung daraufhin, TCP/IP und Named Pipes für Remoteverbindungen zu aktivieren. Diese Meldung wird ausgegeben, wenn Sie eine lokale SQL Server-Datenbank verwenden und beim Erstellen des DSN nicht (local) oder "." als Servername eingeben.

            Umgehung: Ignorieren Sie diese Warnung und klicken Sie auf OK, um mit der Installation bzw. dem Upgrade fortzufahren.

          • vSphere-Client schlägt mit einem Microsoft Visual C++ Laufzeitbibliotheksfehler fehl
            In Umgebungen mit vSphere 4.0-Komponenten, VI Client Version 2.5 und VMware vCenter Converter schlägt der vSphere-Client möglicherweise mit einer Microsoft Visual C++ Laufzeitbibliotheksausnahme fehl.

            Umgehung: Löschen Sie libeay32.dll und ssleay32.dll im folgenden Pfad:
            C:\Programme\VMware\Infrastructure\Virtual Infrastructure Client\Launcher
            Als Alternative können Sie VI Client Version 2.5 deinstallieren.

          • Das Installieren von vCenter Server unter Windows Server 2008 mit einer Remote-SQL-Server-Datenbank kann unter Umständen fehlschlagen
            Wenn Sie vCenter Server auf einem Windows 2008-System mit einer Remote-SQL-Server-Datenbank mit Windows-Authentifizierung für SQL Server installieren und einen Domänenbenutzer für den DSN verwenden, der sich von dem vCenter Server-Systembenutzer unterscheidet, wird der Installationsvorgang nicht fortgesetzt und die folgende Fehlermeldung wird ausgegeben:

            25003.Setup failed to create the vCenter repository

            Umgehung: Verwenden Sie unter diesen Umständen dieselben Anmeldedaten für vCenter Server und den SQL Server-DSN.

          • Ein Upgrade der Hardwareversion von virtuellen Windows-Maschinen erfordert möglicherweise Treiber-Updates
            Das Upgrade der Hardwareversion einer virtuellen Windows-Maschine auf Hardwareversion 7 auf einem ESX 4.0-Host sorgt dafür, dass der Flexible-Netzwerkadapter fälschlicherweise den PCI Ethernet-Adapter-Treiber ( pcnetpci5.sys) der AMD PCNet-Familie verwendet und eine Geschwindigkeit von 10 MBit/s hat. Richtig ist der VMware Accelerated AMD PCnet Adapter-Treiber ( vmxnet.sys).

            Umgehung: Aktualisieren Sie manuell den Treiber für die Flexible-Netzwerkkarte auf den VMware Accelerated AMD PCnet Adapter-Treiber (vmxnet.sys), indem Sie von dem Windows-Gastbetriebssystem der virtuellen Maschine aus auf C:\Programme\VMware\VMware Tools\Drivers\vmxnet\vmware-nic.inf verweisen.

          • Die Ressourcenpooleinstellungen eines ESX-Hosts werden möglicherweise nach einem Upgrade von ESX Server 3.0.x oder ESX Server 3.5.x auf ESX 4.0 nicht beibehalten
            Wenn der ESX-Host so konfiguriert ist, dass alle, die meisten oder fast alle verfügbaren Hostkapazitäten in den Ressourcenpooleinstellungen für die CPU- und Arbeitsspeicherreservierung zugeteilt werden, werden nach einem Upgrade von ESX Server 3.0.x oder ESX 3.5.x auf ESX 4.0 die Einstellungen möglicherweise nicht beibehalten. Nach einem Upgrade werden die Reservierungseinstellungen auf Null gesetzt. Dieses Problem betrifft nur eigenständige Hosts. DRS-Cluster sind davon nicht betroffen.

            Umgehung: Teilen Sie in den Ressourcenpooleinstellungen für die CPU- und Arbeitsspeicherreservierung nicht alle oder nahezu alle verfügbaren Hostkapazitäten zu. Falls Sie es doch tun, notieren Sie vor dem Upgrade die Informationen über die Ressourcenpooleinstellungen auf Hostebene und nach dem Upgrade ändern Sie die Informationen manuell.

          • vSphere Host Update Utility gibt einen Fehler aus, wenn versucht wird, einen ESX-Host zu Upgrade, nachdem das erstmalige Upgrade fehlgeschlagen ist
            Wenn Sie versuchen, mithilfe der Option Wiederholen einen Host zu Upgrade, nachdem das erstmalige Upgrade fehlgeschlagen ist, gibt möglicherweise vSphere Host Update Utility folgenden Fehler aus:

            Upgrade-Agent-Fehler:1

            Umgehung: Schließen Sie das vSphere Host Update Utility und starten Sie es neu. Führen Sie anschließend das Upgrade des Hosts durch.

          • Der Wert für die nächste Ausführung einiger geplanter Aufgaben wird nach einem Upgrade von VirtualCenter 2.0.2.x auf vCenter Server 4.0 nicht beibehalten
            Wenn Sie VirtualCenter 2.0.2.x auf vCenter Server 4.0 Upgrade, wird für einige geplante Aufgaben der Wert für die Nächste Ausführungmöglicherweise nicht beibehalten und die Aufgaben werden möglicherweise unerwartet ausgeführt. Wenn z. B. eine Aufgabe so geplant ist, dass sie jeden Tag um 10 Uhr ausgeführt wird, wird sie nach dem Upgrade möglicherweise um 11.30 Uhr ausgeführt.

            Dieses Problem tritt auf, weil es Unterschiede zwischen den Methoden gibt, die VirtualCenter 2.0.2.x und vCenter Server 4.0 verwenden, um den Zeitpunkt der nächsten Ausführung zu berechnen. Dieses Verhalten ist nur unter den folgenden Bedingungen sichtbar:

            • Sie haben geplante Aufgaben, deren Zeitpunkte für die nächste Ausführung Sie geändert haben, nachdem sie ursprünglich geplant wurden. Sie weisen jetzt einen anderen Zeitpunkt für die Nächste Ausführung auf.
            • Der neu geplante Zeitpunkt für die Nächste Ausführung ist noch nicht eingetreten.

            Umgehung: Führen Sie die folgenden Schritte aus:

            1. Warten Sie, bis die Aufgaben zum Zeitpunkt ihrer Nächsten Ausführung ausgeführt werden, bevor Sie aktualisieren.
            2. Nach dem Upgrade von vCenter 2.0.x auf vCenter Server 4.0 bearbeiten und speichern Sie die geplante Aufgabe. Dieser Vorgang berechnet den Zeitpunkt der Nächsten Ausführung auf den korrekten Wert neu.
          • Virtuelle ESX Server 2.5-Maschinen mit nicht dauerhaften Festplatten, die auf ESX 4.0 aktualisiert wurden, werden möglicherweise in einem angehaltenen Status versetzt
            Wenn Sie die virtuelle Hardware einer virtuellen ESX Server 2.5-Maschine mit nicht dauerhaften Festplatten (erkennbar durch config version = 6, hardware version = 3) auf ESX 4.0 Upgrade, wird die virtuelle Maschine fälschlicherweise auf "autorevert" gesetzt. Wenn Sie in ESX 4.0 Snapshots von dieser virtuellen Maschine erstellen (erkennbar durch config version = 8, hardware version = 7), wird die virtuelle Maschine möglicherweise in einen angehaltenen Status versetzt, wenn ihre virtuellen Hardwaregeräte im ausgeschalteten Status neu konfiguriert werden.

            Umgehung: Entfernen Sie nach dem Upgrade der virtuellen Maschine den Eintrag snapshot.action = "autoRevert" manuell aus der Konfigurationsdatei.

          • Das Installieren oder Upgrade von vCenter Server 4.0 schlägt möglicherweise mit einem Festplattenspeicherfehler fehl
            Während der Installation von vCenter Server 4.0 schlägt die Installation möglicherweise fehl, wenn Sie die Menge an freiem Speicherplatz bereitstellen, die das Installationsprogramm geschätzt hat. Dabei wird die Fehlermeldung Nicht genügend Festplattenspeicher ausgegeben. Somit müssen Sie möglicherweise die Installation erneut durchführen.

            Umgehung: Stellen Sie mindestens 1 GB mehr an freiem Speicherplatz zur Verfügung als das Installationsprogramm empfiehlt.

          • Upgrades der Hardware der virtuellen Maschine von Version 4 auf Version 7 führen dazu, dass die Netzwerkeinstellungen von Solaris-Gastbetriebssystemen verloren gehen
            Upgrades der Hardware der virtuellen Maschine von Version 4 auf Version 7 ändern die Adresse des PCI-Bus der virtuellen Netzwerkadapter in Gastbetriebssystemen. Solaris erkennt die Adapter nicht und ändert die Nummerierung der Netzwerkschnittstellen (Beispielsweise wird e1000g0 zu e1000g1). Diese Änderung an der Nummerierung tritt ein, weil Solaris-IP-Einstellungen Schnittstellenamen zugeordnet sind, sodass es so aussieht, als ob die Netzwerkeinstellungen verloren gegangen sind und das Gastbetriebssystem nicht über eine ordnungsgemäße Konnektivität verfügt.

            Umgehung: Verwenden Sie den Befehl prtconf -D, um nach dem Upgrade der Hardware der virtuellen Maschine die neuen Schnittstellennamen zu ermitteln, und benennen Sie anschließend alle alten Konfigurationsdateien mit deren neuen Namen um. e1000g0 wird beispielsweise e1000g1, sodass jede /etc/*e1000g0-Datei in das /etc/*e1000g1-Äquivalent umbenannt wird.

          • Das vCenter Server-Installationsprogramm erkennt keine Service-Ports, wenn die Services nicht ausgeführt werden
            Wenn Sie vCenter Server installieren und die Standardports übernehmen, kann das Installationsprogramm die Ports nicht validieren, wenn sie von nicht ausgeführten Services verwendet werden. Die Installation schlägt fehl und je nach verwendetem Port wird möglicherweise eine Fehlermeldung ausgegeben.

            Dieses Problem betrifft keine IIS-Dienste. IIS-Services werden immer korrekt validiert, ob die Services ausgeführt werden oder nicht.

            Umgehung: Identifizieren Sie die Ports, die für nicht ausgeführte Services verwendet werden, bevor Sie mit der Installation beginnen, und vermeiden Sie sie.

          • Der vCenter Server-Dienst startet möglicherweise nicht, wenn vCenter Server als lokales Systemkonto auf einer lokalen Microsoft SQL Server-Datenbank mit integrierter Windows NT-Authentifizierung installiert wurde
            Wenn Sie eine Instanz von vCenter Server als ein lokales Systemkonto auf einer lokalen Microsoft SQL Server-Datenbank mit integrierter Windows NT-Authentifizierung installieren und Sie einen entsprechenden Benutzer zum lokalen Datenbankserver mit derselben Standarddatenbank als vCenter Server hinzufügen, startet vCenter Server möglicherweise nicht.

            Umgehung: Entfernen Sie den Benutzer mit integrierter Windows NT-Authentifizierung von dem lokalen SQL-Datenbankserver. Ändern Sie alternativ die Standarddatenbank für das lokale Systembenutzerkonto in die vCenter Server-Datenbank für die SQL Server-Benutzerkontokonfiguration.

          • Einige Befehle funktionieren möglicherweise nicht in den Abschnitten "%pre" und "%post" der Kickstart-Datei
            Einige Befehle, z. B. mount, die bei der Installation von vorherigen Versionen von ESX mithilfe von Kickstart-Dateien unterstützt wurden, funktionieren für Installationen von ESX 4.0 möglicherweise nicht in den Abschnitten "%pre" und "%post" der Kickstart-Datei.

            Umgehung: Ändern Sie die Abschnitte "%pre" und "%post" der in den Installationsskripts verwendeten Kickstart-Dateien.

          • Anwendbare Bulletins werden nicht aufgelistet, wenn die Hostmaschine mithilfe des Befehls "vihostupdate" geprüft wird
            Das Prüfen der Hostmaschine mithilfe des Befehls "vihostupdate" für die anwendbaren Bulletins führt dazu, dass nach dem Download der Paket-ZIP-Datei für ESX 4.0 Update 4 nicht alle Bulletins aufgelistet werden, die im Paket enthalten sind.

            Umgehung: Verwenden Sie das Dienstprogramm esxupdatezum Auflisten der verfügbaren Bulletins im ESX 4.0 Update 4-Paket. Weitere Informationen zum Dienstprogramm "esxupdate" finden Sie im Handbuch für die Patch-Verwaltung von ESX 4.
          •  Mit "esxupdate" wird die neueste Version eines VIB heruntergeladen, wenn die abhängige Version nicht in der Bulletin-Liste verfügbar ist
            Wenn Sie mit dem Befehl "esxupdate" einen Patch auf ESX installieren, lädt der Befehl die neueste Version eines VIB anstelle der speziellen Version herunter, die von der ESX-Installation verwendet wird. Ein derartiges Update wird ausgeführt, wenn die Installation eine bestimmte Version des VIB erfordert, diese Version des VIB jedoch nicht auf der Bulletin-Liste verfügbar ist.

          vCenter Server, vSphere-Client und vSphere Web Access

          • Alarme mit den Systemzustand betreffenden Auslösebedingungen werden nicht nach vSphere 4.0 migriert
            Die Alarmauslösefunktionalität von vSphere 4.0 wurde erweitert. Sie enthält zusätzliche Alarmauslöser für den Systemzustand des Hosts. Dabei wurde der generische Auslöser "Host-Zustand" entfernt. Daher stehen Alarme, die diesen Auslöser enthalten, in vSphere 4.0 nicht mehr zur Verfügung.

            Umgehung: Verwenden Sie den vSphere-Client, um die Alarme erneut zu erstellen. Sie können die folgenden vorkonfigurierten VMware-Alarme verwenden, um den Systemzustand des Hosts zu überwachen:

            • Batteriestatus des Hosts
            • Lüftungsstatus der Hosthardware
            • Betriebsstatus der Hosthardware
            • Temperaturstatus der Hosthardware
            • Status der Hauptplatine der Hosthardware
            • Spannung der Hosthardware
            • Arbeitsspeicherstatus des Hosts
            • Prozessorstatus des Hosts
            • Speicherstatus des Hosts

            Falls sich der Status, den Sie überwachen möchten, nicht unter den vorkonfigurierten Alarmen befindet, können Sie einen benutzerdefinierten Alarm erstellen, der den Ereignisauslöser "Hardwarestatus geändert" verwendet. Für diesen Ereignisalarm müssen Sie die Auslösebedingungen manuell festlegen. Darüber hinaus müssen Sie manuell einstellen, welche Aktion durchgeführt werden soll, wenn der Alarm ausgelöst wird.

            Hinweis: Für die vorkonfigurierten Alarme wurden bereits Standardauslöserbedingungen festgelegt. Sie brauchen nur noch einzustellen, welche Aktion bei Alarmauslösung durchgeführt werden soll.

          • Der Web Access-Dienst startet nach beendeter ESX-Installation nicht
            Wenn Sie Web Access verwenden, um eine Verbindung zu einem ESX-Host herzustellen, wird die folgende Meldung angezeigt:

            503 Service Unavailable

            Die Ursache liegt darin, dass der Web Access-Dienst nach Beenden der Installation von ESX nicht automatisch startet.

            Umgehung: Führen Sie folgenden Befehl aus, um den Web Access-Dienst auf dem ESX-Host zu starten: service vmware-webAccess start

          • Die Verwendung der Option "Alle löschen" des vSphere-Clients zum Entfernen von VM-Snapshots belässt möglicherweise die Snapshot-Festplattendateien im Ordner der virtuellen Maschine
            Dieses Verhalten tritt nur dann auf, wenn Sie bereits den Snapshot zum Erstellen von verknüpften Klonen verwendet und diese anschließend aus dem vCenter Server gelöscht haben. Wenn Sie versuchen, unter Verwendung der Option "Alle löschen" des Snapshot-Managers den Snapshot zu entfernen, wird der Snapshot gelöscht. Die Snapshot-Festplatte wird jedoch nicht mit der übergeordneten Festplatte konsolidiert und verbleibt in nicht gelöschtem Zustand im Ordner der virtuellen Maschine.

            Umgehung: Verwenden Sie zum Entfernen des Snapshots die Option "Löschen" an Stelle der Option "Alle löschen".

          • Bei der NTP-Konfiguration im vSphere-Client wird die Zeitzone im Host geändert
            Die Zeitzone des Hosts kann derzeit nicht über den vSphere-Client konfiguriert werden. Sie wird über die Servicekonsole konfiguriert. NTP-Einstellungen des Hosts können über den vSphere-Client konfiguriert werden. Wurde die Zeitzone des Hosts manuell geändert und wurden im Anschluss daran NTP-Einstellungen über den vSphere-Client konfiguriert, ersetzt der vSphere-Client die Zeitzone durch einen alten Wert.

            Umgehung: Nachdem Sie die Zeitzone des Hosts manuell geändert haben, schließen Sie alle verbundenen Clients und verbinden Sie sie erneut. Die Clients erhalten den neuen Zeitzonenwert.

          • Verfügt ein System über einen virtuellen Netzwerkadapter, kann es sein, dass Guided Consolidation für dieses System eine größere Anzahl von Netzwerkkarten berechnet, als tatsächlich vorhanden ist
            Die Anzahl an Netzwerkkarten, die von Guided Consolidation für ein System berechnet werden, kann größer sein, als die Zahl der vorhandenen Netzwerkkarten, falls das System über virtuelle Netzwerkadapter verfügt. In diesem Fall erhalten Sie möglicherweise während der Phase der Konsolidierungsplanung folgende Warnung: "Host verfügt nicht über die gewünschte Anzahl von VM-Netzwerken. Durch eine Konsolidierung werden mehrere Netzwerke des physischen Computers einem einzelnen VM-Netzwerk zugeordnet." Dies geschieht bei allen Maschinen mit virtuellen Netzwerkkarten (z. B. bei jeder virtuellen Maschine und jeder physischen oder virtuellen Maschine, auf der VMware Workstation oder eine andere gehostete Virtualisierungsplattform läuft).

            Umgehung: Dieses Problem muss nicht umgangen werden. Sie können die Warnung ignorieren.

          • Die Registerkarte "Hardwarestatus" zeigt die Hardwarestatusinformationen des ESX/ESXi-Host nicht an
            Die Registerkarte Hardwarestatus im vSphere-Client wird nicht mit den Hardwarestatusinformationen des ausgewählten ESX/ESXi-Host bestückt, wenn die vCenter Server-Maschine oder der ESX/ESXi-Host im reinen IPv6-Modus ausgeführt wird.

            Umgehung: Fügen Sie auf der vCenter Server-Maschine und dem ESX/ESXi-Host die IPv4-Schnittstelle hinzu und konfigurieren Sie sie.

          • Guided Consolidation kann keine Systeme importieren, auf denen vCenter Converter ausgeführt wird
            Bei den Importvorgängen von Guided Consolidation tritt ein Problem auf, wenn auf dem Quellsystem (d. h. auf dem importierten System) vCenter Converter ausgeführt wird. Guided Consolidation importiert das System und versucht, von dem Quellsystem vCenter Converter zu deinstallieren. Der Importvorgang gelingt, aber die folgende Fehlermeldung wird angezeigt, wenn Guided Consolidation versucht, vCenter Converter zu deinstallieren:

            VMware Converter-Agent-Installation ist fehlgeschlagen.

            Umgehung: Deinstallieren Sie vCenter Converter von den Quellsystemen, bevor Sie versuchen, sie unter Verwendung von Guided Consolidation zu importieren.

          • Webverknüpfungen zu virtuellen Maschinen mit ESX Server 3.5 funktionieren nach einem Upgrade auf ESX 4.0 nicht mehr
            Webverknüpfungen, die für virtuelle Maschinen mit ESX Server 3.5 erstellt wurden, sind für die Benutzer nicht mehr zugänglich, wenn Sie ein Upgrade auf ESX 4.0 durchgeführt haben. vSphere Web Access 4.0 unterstützt die URLs für ESX 3.5 nicht. Der Benutzer kann nicht über die URLs, die für ESX Server 3.5 erstellt wurden, auf die virtuellen Maschinen zugreifen.

            Umgehung: Verwenden Sie vSphere Web Access 4.0, um Webverknüpfungen zu erstellen, die für ESX 4.0 gültig sind, und verteilen Sie diese an Ihre Benutzer. Weitere Informationen über das Erstellen von Webverknüpfungen finden Sie im Administratorhandbuch für vSphere Web Access .

          • Die gemeinsame Nutzung eines Dual-Funktion-Adapters QLogic 2532 durch eine virtuelle Maschine und eine andere virtuelle Maschine oder den VMkernel bei VMDirectPath Gen I kann zu Datenverlusten führen
            Wenn Sie einen Dual-Funktion-Adapter QLogic 2532 für VMDirectPath IO konfigurieren und die erste PCI-Funktion einer virtuellen Maschine sowie die zweite einem VMkernel oder einer anderen virtuellen Maschine zuweisen, kann dies zu Datenverlust führen. Dies liegt daran, dass beide Ports die gleichen Daten zum Anmelden bei Fabric verwenden und über die gleichen Speichersichtbarkeit verfügen. VMware unterstützt diese Konfiguration für VMDirectPath IO nicht.

            Umgehung: Wenn der Dual-Funktion-Adapter von einer virtuellen Maschine und dem VMkernel gemeinsam genutzt werden muss, weisen Sie die erste PCI-Funktion der virtuellen Maschine und die zweite dem VMkernel zu. Die PCI-Funktionen können nicht zwischen zwei virtuellen Maschinen aufgeteilt werden.

          • Der vSphere-Client aktualisiert keine Sensoren, die physischen Ereignissen zugeordnet sind
            Der vSphere-Client aktualisiert Sensorstatus nicht in jedem Fall. Manche Ereignisse können eine Aktualisierung auslösen, z. B. ein fehlerhaftes Netzteil oder die Entfernung einer redundanten Festplatte. Andere Ereignisse, wie das Öffnen des Gehäuses oder das Entfernen eines Lüfters, lösen möglicherweise keine Aktualisierung des Sensorstatus aus.

            Umgehung: Keine

          • vCenter Server lässt es zu, dass dasselbe ESX/ESXi-System zweimal mit zwei verschiedenen IPv6-Adressen hinzugefügt wird
            Wenn Sie ein ESX/ESXi-System zur vCenter-Bestandsliste hinzufügen, das bereits unter einer anderen IP-Adresse in vCenter verwaltet wird, erkennt der vCenter Server dieses Problem nicht. Das ESX/ESXi-System erscheint mit einer neuen IP-Adresse und dem Status "Getrennt" in der Bestandsliste. Verbindungen zu dem ESX/ESXi-System, die die alte IP-Adresse verwenden, bleiben aktiv.

            Umgehung: Fügen Sie ein ESX/ESXi-System nicht zweimal hinzu.

          • Beim Neustart von "mgmt-vmware" wird "vmware-webAccess" nicht ebenfalls neu gestartet
            Wenn Sie den Dienst "mgmt-vmware" neu starten, wird der Dienst "vmware-webAccess" nicht neu gestartet. Stattdessen wird der Dienst nach einer Weile beendet, sodass Sie Web Access nicht für eine Verbindung zum ESX-Host verwenden können..

            Umgehung: Starten Sie den Dienst "vmware-webAccess" manuell. Führen Sie dazu folgenden Befehl an der ESX-Servicekonsole aus: service vmware-webAccess start

          • Unter Suse Enterprise Linux fehlt auf virtuellen Maschinen im Dropdown-Menü "Adaptertyp" die Option "vmxnet3"
            Auf einer virtuellen Maschine, auf der SLES 10 oder SLES 11 ausgeführt wird, und für die als Typ des Gastbetriebssystems "SLES" ausgewählt ist, ist vmxnet3 im Dropdown-Menü Adaptertyp nicht enthalten. Das Problem tritt am ehesten in virtuellen Maschinen auf, die von ESX Server 3.x auf ESX 4.x migriert wurden. Es kann aber auch unter anderen Umständen auftreten.

            Umgehung: Die Option vmxnet3 wird verfügbar, wenn Sie den Typ des Gastbetriebssystems von "SLES" in "SLES10" oder "SLES11" ändern.

            1. Schalten Sie die virtuelle Maschine aus.
            2. Klicken Sie mit der rechten Maustaste auf die virtuelle Maschine und wählen Sie Einstellungen bearbeiten.
            3. Klicken Sie auf der Registerkarte Optionenauf Allgemeine Optionen.
            4. Wählen Sie im Feld "Version" entweder SLES10 oder SLES11 aus.
          • Virtuelle Maschinen verschwinden aus dem Diagramm der virtuellen Switches in der Netzwerkansicht für die Hostkonfiguration
            Virtuelle Maschinen werden in der Netzwerkansicht auf der Registerkarte "Konfiguration" des vSphere-Clients für einen Host im Diagramm der virtuellen Switches dargestellt. Wenn Sie einen anderen Host auswählen und dann zur Registerkarte "Netzwerk" des ersten Hosts zurückkehren, verschwinden die virtuellen Maschinen möglicherweise aus dem Diagramm der virtuellen Switches.

            Umgehung: Wählen Sie auf der Registerkarte "Konfiguration" eine andere Ansicht, z. B. Netzwerkadapter, Speicher oder Speicheradapter, und kehren Sie zur Registerkarte "Netzwerk" zurück.

          • Das Verwenden von Sonderzeichen in den Namen virtueller Maschinen während deren Erstellung ergibt einen Fehler, wenn sie über vSphere Web Access mit vCenter Server verbunden sind
            Bei einer Verbindung zu vCenter Server mit vSphere Web Access löst die Verwendung von Sonderzeichen (z. B., "|\'{}[]-*^&@#!`~) im Namen der virtuellen Maschine währen der Erstellung den folgenden Fehler aus:
            Laufzeitfehler: Ein allgemeiner Systemfehler ist aufgetreten.

            Umgehung: Keine

          • vSphere Web Access zeigt die falsche CPU-Geschwindigkeit für die virtuelle Maschine an, nachdem die Anzahl der virtuellen Prozessoren erhöht wurde
            In vSphere Web Access werden im Abschnitt "Leistung" der Registerkarte "Übersicht" falsche Informationen zur CPU-Geschwindigkeit einer ausgewählten virtuellen Maschine angezeigt, nachdem die Anzahl der CPUs für die virtuelle Maschine erhöht wurde. Wenn beispielsweise die Anzahl der CPUs für eine virtuelle Maschine von 1 CPU mit einer Geschwindigkeit von 1,559 Mhz auf 2 CPUs erhöht wird, müsste vSphere Web Access die Anzahl der CPUs und ihre Geschwindigkeit als 2 x 1,559 Mhz anzeigen. Die CPU-Geschwindigkeit wird jedoch fälschlicherweise mit 3,117 (1,559 x 2) angezeigt.

            Umgehung: Keine

          • Wenn Sie die Nummer des HTTPS-Ports in der SFCB-Konfigurationsdatei ( sfcb.cfg) auf einen Port ändern, der nicht der Standardport ist, und den SFCB-Server (CIM) neu starten, erscheint der Systemstatus der Serverkomponenten des ESX/ESXi-Hosts nicht auf der Registerkarte "Hardwarestatus"
            Dasselbe passiert, wenn Sie sich direkt an einem ESX/ESXi-Host anmelden und auf die Registerkarte Konfiguration klicken, um den Systemstatus anzuzeigen. Statusinformationen für die Serverkomponenten erscheinen nicht.

            Dieses Problem tritt auf, weil vCenter Server und der SFCB-Server über verschieden Ports kommunizieren.

            Umgehung: Stellen Sie sicher, dass der SFCB-Server nur über den Standardport kommuniziert.

          • Starten oder Beenden des vctomcat-Webservice über die Windows-Eingabeaufforderung führt möglicherweise zu einer Fehlermeldung
            Wenn Sie auf Microsoft Windows-Betriebssystemen die Befehle net start und net stop verwenden, um den vctomcat-Webservice zu starten bzw. zu beenden, wird möglicherweise die folgende Fehlermeldung angezeigt:

            Der Dienst reagiert auf die Kontrollfunktion nicht.
            Weitere Informationen erhalten Sie, wenn Sie "NET HELPMSG 2186" eingeben.

            Umgehung: Sie können diese Fehlermeldung ignorieren. Wenn Sie möchten, dass die Fehlermeldung nicht mehr erscheint, bearbeiten Sie die Registrierung und erhöhen Sie den Zeitüberschreitungswert für den Service Control Manager (SCM). Weitere Informationen finden Sie in folgendem Microsoft-KB-Artikel: http://support.microsoft.com/kb/922918.

          • Überblicksleistungsdiagramme werden nach einem Upgrade von vCenter Server 2.5 mit mitgelieferter SQL Express-Datenbank nicht angezeigt
            Wenn Sie ein Upgrade von vCenter Server 2.5 auf vCenter Server 4.0 durchführen und dabei eine SQL Express-Datenbank involviert ist, werden die Überblicksleistungsdiagramme nicht angezeigt. Wenn Sie die Überblicksansicht auf der Registerkarte Leistung öffnen, wird folgender Fehler angezeigt:

            STATs Report service internal error

            Dieser Fehler tritt auf, weil das vCenter Server-Upgrade-Tool die vorhandene Datenbank nicht neu konfigurieren kann. Sie müssen die Konfiguration manuell durchführen.

            Umgehung:

            1. Wählen Sie Start > Programme > SQL Server Configuration Manager.
            2. Führen Sie im SQL Server Configuration Manager Folgendes aus:
              1. Wählen Sie Protocols for SQLEXP_VIM (Protokolle für SQLEXP_VIM).
              2. Wählen Sie TCP/IP.
              3. Wählen Sie unter "Enabled" True und unter "Listen All" Yes.
              4. Klicken Sie auf OK.
            3. Geben Sie in einem Befehlsfenster Services.msc ein, um den Dienst-Manager zu öffnen.
            4. Starten Sie in der Dienstliste die folgenden Dienste:
            • SQL Server 2005 Services: SQL Server (SQLEXP_VIM)
            • SQL Server 2005 Services: SQL-Browser (wenn der SQL-Browser-Dienst deaktiviert ist, markieren Sie ihn zum automatischen/manuellen Starten)
            • VMware vCenter-Dienst
            • VMware-Webservice
          • Ein Fehlermeldung erscheint, wenn Sie eine zweite virtuelle Festplatte zu einer virtuellen Maschine hinzufügen
            Angenommen, Sie erstellen eine virtuelle Maschine mit standardmäßigen Optionen, indem Sie Web Access verwenden, das mit ESX/ESXi 4.0 verbunden ist. Wenn Sie anschließend eine Verbindung von vSphere Web Access mit dem vCenter Server, der den ESX/ESXi-Host verwaltet, herstellen und mit der Option Neue virtuelle Festplatte erstellen derselben virtuellen Maschine eine zweite virtuelle Festplatte hinzufügen, erscheint die Fehlermeldung Die angegebene Datei ist bereits auf dem Server vorhanden.

            Umgehung: Verwenden Sie den vSphere-Client, um eine Verbindung zu vCenter Server herzustellen und der virtuellen Maschine eine zweite virtuelle Festplatte hinzuzufügen.

          • Der Befehl "vc-support" verwendet eine 64-Bit-DSN-Anwendung und kann keine Daten aus der vCenter Server-Datenbank abrufen
            Wenn Sie den VMware-Befehl cscript vc-support.wsf verwenden, um Daten aus der vCenter Server-Datenbank abzurufen, wird die Microsoft-Standardanwendung cscript.exe verwendet. Diese Anwendung verwendet einen 64-Bit-DSN und keinen 32-Bit-DSN, wie es für die vCenter Server-Datenbank erforderlich wäre. Demzufolge treten Fehler auf und es können keine Daten abgerufen werden.

            Umgehung: Übergeben Sie an der Eingabeaufforderung des Systems die Datei vc-support.wsf an die Anwendung cscript.exe (mit dem 32-Bit DSN) und führen Sie diese aus:

            %windir%\SysWOW64\cscript.exe vc-support.wsf

          • Das Menü "vSphere-Client-Rollen" zeigt für keine der vCenter Server-Systeme in einer Gruppe im verknüpften Modus Rollenzuweisungen an
            Wenn Sie auf einem vCenter Server-System in einer Gruppe im verknüpften Modus eine Rolle erstellen, werden die vorgenommenen Änderungen an alle anderen vCenter Server-Systeme der Gruppe weitergegeben. Die Rolle wird jedoch nur auf Systemen angezeigt, die über die mit der Rolle zugewiesenen Berechtigungen verfügen. Wenn Sie eine Rolle entfernen, prüft der Vorgang den Status der Rolle nur auf dem aktuell ausgewählten vCenter Server-System. Er entfernt die Rolle jedoch aus allen vCenter Server-Systemen in der Gruppe im verknüpften Modus, ohne dass eine Warnung ausgegeben wird, die darauf hinweist, dass die Rolle möglicherweise auf anderen Servern verwendet wird.

            Umgehung: Bevor Sie eine Rolle aus dem vCenter Server-System löschen, stellen Sie sicher, dass die Rolle nicht über andere vCenter Server-Systeme hinweg verwendet wird. Wechseln Sie zum Feststellen, ob eine Rolle verwendet wird, zur Ansicht "Rollen" und benutzen Sie die Navigationsleiste, um jedes vCenter Server-System in der Gruppe auszuwählen. Die Verwendung dieser Rolle wird für das ausgewählte vCenter Server-System angezeigt.

            Weitere Informationen über Best Practices für Benutzer und Gruppen sowie über das Festlegen von Rollen für vCenter Server-Gruppen im verknüpften Modus finden Sie im vSphere-Handbuch Grundlagen der Systemverwaltung .

          • Das Löschen von Snapshots und das Klonen von virtuellen Maschinen im laufenden Betrieb können bei hoher Arbeitslast der virtuellen Maschine lange dauern
            Das Löschen von Snapshots und das Klonen von virtuellen Maschinen im laufenden Betrieb können lange dauern, wenn die virtuelle Maschine eine hohe E/A-Arbeitslast zu bewältigen hat. Wenn die virtuelle Maschine beispielsweise auf ihre lokalen Festplatten schreibt, ist die E/A-Arbeitslast sehr hoch.

            Umgehung: Vermeiden Sie diese Vorgänge, wenn die virtuelle Maschine auf ihre lokalen Festplatten schreibt oder andere schwere E/A-Arbeitslasten ausführt. Dies kann dazu beitragen, die Durchführungszeiten zu reduzieren.

          • Unter Windows Server 2008 ist nach der Installation das Beitreten zu einer Gruppe im verknüpften Modus nicht erfolgreich, wenn die Benutzerkontensteuerung (UAC) aktiviert ist
            Wenn auf Windows Server 2008 mit einem 32- oder 64-Bit-Betriebssystem die Benutzerkontensteuerung (UAC) aktiviert ist und Sie versuchen, auf einem System, auf dem vCenter Server bereits ausgeführt wird, einer Gruppe im verknüpften Modus eine Maschine hinzuzufügen, ist die Verbindung nicht erfolgreich. Es wird jedoch keine Fehlermeldung angezeigt. In der Bestandsliste wird nur ein vCenter Server aufgeführt.

            Umgehung: Gehen Sie folgendermaßen vor.

            Führen Sie folgende Schritte durch, um die UAC auszuschalten, bevor Sie die Maschine einer Gruppe im verknüpften Modus hinzufügen:

            1. Wählen Sie Start > Einstellungen > Systemsteuerung > Benutzerkonten aus, um das Dialogfeld "Benutzerkonto" zu öffnen.
            2. Klicken Sie auf Benutzerkontosteuerung ein- oder ausschalten.
            3. Deaktivieren Sie die Option Benutzerkontensteuerung verwenden, um zum Schutz des Computers beizutragen und klicken Sie auf OK.
            4. Starten Sie die Maschine neu, wenn Sie dazu aufgefordert werden.

            Starten Sie die Konfiguration für den verknüpften Modus, wie nachfolgend beschrieben:

            1. Wählen Sie Start > Programme > VMware > vCenter Server-Konfiguration für den verknüpften Modus.
            2. Klicken Sie auf "Weiter".
            3. Wählen Sie Konfiguration für den verknüpften Modus ändern und klicken Sie auf Weiter.
            4. Klicken Sie auf vCenter Server-Instanz einer vorhandenen Gruppe für den verknüpften Modus oder einer anderen Instanz hinzufügenund klicken Sie auf Weiter.
            5. Geben Sie den Servernamen und die Informationen für den LDAP-Port an und klicken Sie auf Weiter.
            6. Klicken Sie auf Fortfahren, um die Installation abzuschließen.
            7. Klicken Sie auf Beenden, um den Verknüpfungsvorgang zu beenden.

            Melden Sie sich bei einem der vCenter Server-Systeme an und vergewissern Sie sich, dass die Server verknüpft sind. Sind die vCenter Server verknüpft, schalten Sie die UAC folgendermaßen wieder ein:

            1. Wählen Sie Start > Einstellungen > Systemsteuerung > Benutzerkonten aus, um das Dialogfeld "Benutzerkonto" zu öffnen.
            2. Klicken Sie auf Benutzerkontosteuerung ein- oder ausschalten.
            3. Aktivieren Sie die Option Benutzerkontensteuerung verwenden, um zum Schutz des Computers beizutragen und klicken Sie auf OK.
            4. Starten Sie die Maschine neu, wenn Sie dazu aufgefordert werden.

          • Durch das Entfernen eines aktiven virtuellen Switches einer virtuellen Maschine wird möglicherweise eine Fehlermeldung ausgegeben
            Falls Sie versuchen, einen virtuellen Switch zu entfernen, den eine eingeschaltete virtuelle Maschine verwendet, wird eine Fehlermeldung ausgegeben. Die Meldung dient dazu, Sie zu warnen, dass der virtuelle Switch verwendet wird und daher nicht entfernt werden kann. In einem solchen Fall kann das Entfernen des virtuellen Switches dazu führen, dass die virtuelle Maschine nicht mehr verwendet werden kann.

            Umgehung: Entfernen Sie keinen virtuellen Switch, der in Gebrauch ist.

          • Sie können die Symbolleiste in der Ansicht "Berichte" auf der Registerkarte "Speicheransichten" nicht wieder anzeigen, nachdem Sie sie ausgeblendet haben
            Zur Ansicht "Berichte" auf der Registerkarte Speicheransichten gehört eine Symbolleiste, die ein Menü für das Filtern von Objekten und ein Suchfeld enthält. Diese Steuerelemente ermöglichen es Ihnen, die Berichtstabellen basierend auf Objekttyp, Speicherattributen und Schlüsselwörtern zu filtern. Wenn Sie die Symbolleiste über die Option Ausblenden ihres Kontextmenüs ausblenden, fehlt eine adäquate Möglichkeit, die Symbolleiste wieder anzuzeigen.

            Umgehung: Schließen Sie den vSphere-Client und starten Sie ihn erneut.

          • Das Beitreten von zwei vCenter Server-Instanzen schlägt mit einer Fehlermeldung in der Datei "status.txt" über das Misslingen des Entfernens von VMwareVCMSDS fehl
            Das Beitreten einer vorhandenen eigenständigen vCenter Server-Instanz zu einer Gruppe im verknüpften Modus führt dazu, dass das vCenter Server-Installationsprogramm fehlschlägt. Wenn dies geschieht, wird vCenter Server nicht auf der Maschine gestartet, auf der Sie die Installation durchführen. Zudem werden Meldungen, die sich mit LDAP-Konnektivitäts- oder Unerreichbarkeitsproblemen befassen, in die Datei /status.txt geschrieben, wobei das auf dem Windows-System definierte temporäre Verzeichnis ist. Öffnen Sie zum zu Diagnostizieren dieses Problems die Datei status.txt und suchen Sie die folgende Meldung: [2009-03-06 21:44:55 SEVERE] Operation "Join instance VMwareVCMSDS" failed: : Action: Join Instance
            Action: Removal of standalone instance
            Action: Remove Instance
            Problem: Removal of instance VMwareVCMSDS failed: The removal wizard was not able to remove all of the components. To complete removal, run "Adamuninstall.exe /i: " after resolving the following error:

            Folder ' \VMwareVCMSDS' could not be deleted.
            Das Verzeichnis ist nicht leer.

            Umgehung: Führen Sie die folgenden Schritte aus:

            1. Wechseln Sie mit Administratorrechten von einer Eingabeaufforderung aus in das vCenter Server-Installationsverzeichnis.
            2. Löschen Sie das Verzeichnis VMwareVCMSDS.
            3. Stellen Sie die lokale LDAP-Instanz her, indem Sie jointool.bat recover eingeben.
          • vCenter Server 4.0 reagiert in großen Umgebungen nicht mehr, wenn er ESX Server 3.5-Hosts vor ESX 3.5 Patch 10 verwaltet
            vCenter Server 4.0 reagiert in großen Umgebungen nach 30 Tagen möglicherweise nicht mehr, wenn er ESX Server 3.5-Hosts vor ESX Server 3.5 Patch 10 verwaltet.

            Umgehung: Aktualisieren Sie auf ESX Server 3.5 Update 4, wenn Sie ESX Server 3.5 mit vCenter Server 4.0 ausführen.

          • Networking problems and errors might occur when analyzing machines with VMware Guided Consolidation
            Wird eine große Zahl von Maschinen für Guided Consolidation analysiert, kann die Guided Consolidation-Komponente vCenter Collector Provider Service von dem Betriebssystem, auf dem die Guided Consolidation-Funktionalität installiert ist, für einen Virus oder einen Wurm gehalten werden. Dies tritt auf, wenn der Analysevorgang eine große Zahl von Maschinen findet, deren IP-Adressen ungültig sind oder bei denen Probleme bei der Namensauflösung auftreten. Dabei kommt es zu einem Engpass im Netzwerk und es werden entsprechende Fehlermeldungen angezeigt.

            Umgehung: Fügen Sie keine Maschinen zur Analyse hinzu, die nicht erreichbar sind. Wenn Sie Maschinen über den Namen hinzufügen, stellen Sie sicher, dass der NetBIOS-Name aufgelöst werden kann und dass der Rechner erreichbar ist. Wenn Sie Maschinen über die IP-Adresse hinzufügen, stellen Sie sicher, dass es sich um eine statische IP-Adresse handelt.

          • Es werden mehrere SSL-Warnmeldungen angezeigt, wenn vCenter Server-Systeme einer Gruppe im verknüpften Modus beitreten
            Wenn mehrere vCenter Server-Systeme einer Gruppe im verknüpften Modus beitreten und Sie keine SSL-Zertifikate zur Authentifizierung verwenden, werden möglicherweise im vSphere-Client beim Anmelden mehrere SSL-Warnungen angezeigt.

            Umgehung: Reagieren Sie auf jede einzelne Warnung. Aktivieren Sie für jeden Host die Option Dieses Zertifikat immer ignorieren. Sie müssen vCenter Server für die Verwendung von SSL-Zertifikaten konfigurieren.

          • Keine Verbindung mit vSphere Web Access zu vCenter Server, wenn Sie den HTTP-Port vom vSphere-Client aus geändert haben
            Wenn Sie über den vSphere-Client eine Verbindung mit dem vCenter Server hergestellt haben, können Sie den HTTP-Port von vCenter Server ändern ( Verwaltung > vCenter Server-Einstellungen > Webservice > Ports > HTTP). Dieser Port ermöglicht die Verbindung mit vCenter Server über vSphere Web Access. Wenn Sie den HTTP-Port ändern, ist vSphere Web Access möglicherweise für alle Benutzer nicht mehr erreichbar.

            Umgehung: Führen Sie die folgenden Schritte aus, um die Porteinstellungen in den Konfigurationsdateien von vSphere Web Access zu ändern, damit Verbindungen über den von Ihnen angegebenen Port möglich sind.

            1. Melden Sie sich bei der vCenter Server-Maschine an und öffnen Sie folgendes Verzeichnis:

              C:\Programme\VMware\Infrastructure\tomcat\webapps\jslib-1.0.157180
              \modules\com.vmware.webaccess.app_1.0.0


              Wenn Sie vCenter Server in einem anderen Verzeichnis als C:\Programme\ installiert haben, wählen Sie den entsprechenden Pfad.
            2. Öffnen Sie die Datei WebAccess.properties und aktualisieren Sie wie folgt den Wert login_url mit der Portnummer, die Sie im vSphere-Client angegeben haben:

              Aktueller Wert: http://localhost:80/sdk
              Neuer Wert: http://localhost:[Neuer_Port]/sdk
            3. Klicken Sie mit der rechten Maustaste auf Arbeitsplatz und wählen Sie Verwalten.
            4. Wählen Sie unter Dienste und Anwendungen die Option Dienste, suchen Sie "VMware VirtualCenter Management Webservices" und starten Sie den Dienst neu.

              HINWEIS: Ein Neustart des Dienstes wirkt sich auf die Verbindungen mit vCenter Server-Systemen im verknüpften Modus sowie auf vorhandene vSphere Web Access-Verbindungen aus.
            5. Löschen Sie den Cache Ihres Browsers.
            6. Verwenden Sie http://localhost: /ui, zum Herstellen einer Verbindung mit vCenter Server über vSphere Web Access.
          • vSphere-Client zeigt falsche Informationen im Abschnitt "Allgemein" der Registerkarte "Übersicht" für Hosts an
            Bei großer Auslastung kann es vorkommen, dass das rechte Fenster des vSphere-Clients nicht aktualisiert wird und daher im Abschnitt Allgemein falsche Informationen anzeigt.

            Umgehung: Sie müssen möglicherweise den vSphere-Client manuell aktualisieren, indem Sie einen anderen Host auswählen und anschließend den ersten Host erneut auswählen.

          • Wenn Sie bei großen vCenter Server-Bestandslisten den vSphere-Client im verknüpften Modus öffnen und dabei die Bestandslisten aller vCenter Server-Systeme vollständig erweitert sind, reagiert der vSphere-Client möglicherweise für einige Minuten nicht
            vSphere-Client-Bestandslisten sind dann vollständig erweitert, wenn Cluster und Datencenter erweitert sind. Wenn Sie den vSphere-Client schließen, nachdem die Bestandslisten erweitert wurden, wird die erwartete Bestandslistenansicht beim nächsten Öffnen des Clients geladen. Als Folge davon reagiert der vSphere-Client möglicherweise für einige Minuten nicht mehr, abhängig von der Anzahl der vCenter Server-Systeme und der Anzahl der Objekte in den Bestandslisten der jeweiligen vCenter Server-Systeme. Der vSphere-Client reagiert wird, nachdem alle Bestandslistenobjekte geladen wurden.

            Umgehung: Es wird empfohlen, bei einer Gruppe im verknüpften Modus nicht die Knoten alle vCenter Server-Systeme in der Bestandsliste zu erweitern. Reduzieren Sie die Knoten, bevor Sie den vSphere-Client schließen, um das Laden der erweiterten Knoten beim Start zu vermeiden.

          • Der Hardwarestatusdienst unterstützt keine Hosts vor ESX Server 3.5 Update 4
            Hardwarestatusalarme werden für Hosts der Version ESX Server 3.5 Update 3 und früher nicht ausgelöst. Wenn Sie mit dem vSphere-Client die Registerkarte Hardwarestatus für einen Host anzeigen lassen, auf dem ESX Server 3.5 Update 3 oder früher ausgeführt wird, wird die Meldung angezeigt, dass für die Überwachung des Hardwaresystemstatus ESX Server 3.5 Update 4 oder höher oder ESXi erforderlich ist.

            Umgehung: Damit die Hardwarestatusüberwachung auf ESX Server 3.5 Update 3 oder früher unterstützt wird, installieren Sie Patch 11 für ESX Server 3.5 (ESX350-200901407-BG), der in ESX Server 3.5 Update 4 enthalten ist.

          • Deaktivierte Alarme für Bestandslistenobjekte werden aktiviert, wenn vCenter Server neu gestartet wird
            Wenn in vCenter Server ein Alarm für ein Bestandslistenobjekt, wie z. B. für einen Host, eine virtuelle Maschine, einen Datenspeicher usw., deaktiviert und vCenter Server neu gestartet wird, werden die Alarme nach Abschluss eines Neustarts von vCenter Server aktiviert.

            Umgehung: Deaktivieren Sie die Alarme für die entsprechenden Bestandslistenobjekte, wenn vCenter Server neu gestartet wurde.

          • Im gemeinsam genutzten Speicher gespeicherte VM-Vorlagen stehen nicht mehr zur Verfügung, nachdem DPM (Distributed Power Management) einen Host in den Standby-Modus versetzt oder wenn ein Host in den Wartungsmodus versetzt wird
            Der vSphere-Client weist VM-Vorlagen einem bestimmten Host zu. Wenn der Host, auf dem die VM-Vorlagen gespeichert sind, in den Wartungsmodus oder von DPM in den Standby-Modus versetzt wird, scheinen im vSphere-Client die Vorlagen deaktiviert zu sein. Dieses Verhalten tritt auch dann auf, wenn die Vorlagen im gemeinsam genutzten Speicher gespeichert werden.

            Umgehung: Deaktivieren Sie DPM auf dem Host, auf dem die VM-Vorlagen gespeichert sind. Befindet sich der Host im Wartungsmodus, verwenden Sie den Datenspeicherbrowser auf einem anderen Host, der sich nicht im Wartungs- oder Standby-Modus befindet und ebenfalls Zugriff auf den Datenspeicher hat, auf dem die Vorlagen gespeichert sind, um die VM-Vorlagen zu suchen. Sie können dann virtuelle Maschinen unter Verwendung dieser Vorlagen bereitstellen.

          • Bei der Neuinstallation der vSphere-CLI auf manchen Windows-Plattformen, z. B. Windows Vista Enterprise SP1 32 Bit, kann ein LibXML DLL-Modulladefehler auftreten
          • Fehlerhafte Links auf der ESX- und der ESXi-Begrüßungsseite
            Die Download-Links im vSphere Remote Command Line-Abschnitt, im vSphere Web Services SDK-Abschnitt sowie die Links zum Herunterladen der vSphere 4-Dokumentation und von VMware vCenter auf der Begrüßungsseite von ESX und ESXi sind falsch zugeordnet.
            Umgehung: Laden Sie die Produkte von der VMware-Website herunter.
          • Auf Nexus 1000v kann Distributed Power Management einen Host nicht in den Standby-Modus versetzen
            Wenn ein Host weder Integrated Lights-Out (iLO) noch Intelligent Platform Management Interface (IPMI) für Distributed Power Management (DPM) unterstützt, kann dieser Host weiterhin DPM verwenden, vorausgesetzt, alle physischen Netzwerkkarten auf dem Host, die zu Nexus 1000V DVS hinzugefügt werden, verfügen über Wake-On-LAN-Unterstützung. Selbst wenn nur eine der physischen Netzwerkkarten keine Wake-On-LAN-Unterstützung bietet, kann der Host nicht von DPM in den Standby-Modus versetzt werden.

            Umgehung: Keine.

          Verwaltung von virtuellen Maschinen

          • VMXNET 3-Netzwerkadapter werden während eines OVF-Exports von virtuellen Maschinen nicht mit exportiert
            Wenn Sie einen OVF-Export (Open Virtualization Format) über VirtualCenter durchführen, werden virtuelle Maschinen mit VMXNET 3-Netzwerkadaptern mit VMXNET-Netzwerkadaptern exportiert. Dies führt dazu, dass virtuelle Maschinen aus dieser Vorlage mit VMXNET-Netzwerkadaptern statt mit VMXNET 3-Netzwerkadaptern bereitgestellt werden. Dieses Problem tritt auf, wenn Sie eine Verbindung mit dem ESX-Host unter Verwendung des im Lieferumfang von vSphere 4.0 Update 4 enthaltenen vSphere-Clients herstellen.

            Umgehung: Keine.

          • Nach dem Upgrade einer virtuellen Maschine unter Windows 2000 von Hardwareversion 4 nach Hardwareversion 7 erscheint die Aufforderung, eine PCI Standard-PCI-zu-PCI-Brücke zu installieren
            Wenn Sie auf einer virtuellen Maschine unter Windows 2000 ein Upgrade von Hardwareversion 4 nach Hardwareversion 7 durchführen, kann es sein, dass einige Popup-Meldungen angezeigt werden, die Sie auffordern, eine PCI Standard-PCI-zu-PCI-Brücke zu installieren. Diese Meldungen können ignoriert werden.

            Umgehung: Akzeptieren Sie alle Aufforderungen, um das Upgrade der Hardwareversion abzuschließen.

          • Benutzerdefinierte Skripts, die in vmware-toolbox dem Ereignis "Anhalten" zugewiesen sind, werden nicht ausgeführt, wenn Sie die virtuelle Maschine vom vSphere-Client aus anhalten
            Wenn Sie in der Registerkarte Skript von vmware-toolbox dem Ereignis "Anhalten" ein benutzerdefiniertes Skript zugewiesen und die virtuelle Maschine so konfiguriert haben, dass, wenn Sie Anhalte-Skripts starten, VMware Tools-Skripts ausgeführt werden, geschieht dies nicht, falls Sie die virtuelle Maschine vom vSphere-Client aus anhalten.

            Umgehung: Keine

          • Wenn bei einem automatischen Upgrade der VMware Tools das Gastbetriebssystem eingeschaltet wird, wird das Gastbetriebssystem automatisch neu gestartet, ohne dass eine Neustartbenachrichtigung ausgegeben wird
            Wenn Sie angeben, dass auf einem Windows Vista- oder Windows 2008-Gastbetriebssystem die VMware Tools automatisch aktualisiert werden sollen, wenn das Betriebssystem eingeschaltet wird, werden VMware Tools aktualisiert und das Gastbetriebssystem automatisch neu gestartet, ohne dass eine Neustartbenachrichtigung ausgegeben wird.

            Umgehung: Keine

          • Ein Dialogfeld, in dem der Benutzer zur Eingabe von Sysprep-Dateiinformationen aufgefordert wird, erscheint möglicherweise beim Klonen und Anpassen von virtuellen Maschinen
            Wenn Sie eine virtuelle Maschine klonen und anpassen, wird der Vorgang möglicherweise nicht abgeschlossen und ein Sysprep-Dialogfeld fordert Sie möglicherweise auf, zusätzliche Dateien anzugeben.

            Umgehung: Führen Sie die folgenden Schritte aus:

            1. Beachten Sie die Liste der fehlenden Dateien, die das Mini-Setup von Windows nicht finden kann.
            2. Kopieren Sie die benötigten Dateien (beispielsweise c_20127.nls) von der Quellmaschine in den Ordner mit den Sysprep-Installationsdateien, c:\sysprep\i386. Die von Sysprep angeforderten Dateien befinden sich normalerweise an folgendem Speicherort auf der virtuellen Quellmaschine: C:\Windows\system32.
            3. Führen Sie das Klonen mit Anpassung durch.

            Hinweis:Das Sysprep-Verzeichnis wird entfernt, nachdem die virtuelle Maschine gestartet wurde und die Anpassung abgeschlossen ist.

          • Bei virtuellen Maschinen, die ein Windows NT-Gastbetriebssystem ausführen, muss nach einem Upgrade der virtuellen Hardware von Version 4 auf Version 7 der Netzwerkadaptertreiber neu installiert werden
            Nach einem Upgrade der virtuellen Hardware auf einem Windows NT-Gastbetriebssystem kann die virtuelle Maschine keine IP-Adressen abrufen, da Windows NT die Plug-und-Play-Spezifikation nicht voll unterstützt.

            Umgehung: Installieren Sie nach einem Upgrade der virtuellen Hardware von Version 4 auf Version 7 auf einer virtuellen Maschine, auf der Windows NT ausgeführt wird, den Netzwerkadaptertreiber neu, indem Sie die folgenden Schritte durchführen.

            1. Klicken Sie mit der rechten Maustaste auf Netzwerkumgebung und wählen Sie Eigenschaften aus.
            2. Wählen Sie die Registerkarte Adapter aus.
            3. Entfernen Sie den vorhandenen Adapter.
            4. Fügen Sie einen neuen Adapter hinzu.
            5. Wählen Sie bei einem AMD PCNet-Treiber AMD PCNET Family Ethernet adapter aus und geben Sie als Pfad C:\winnt\system32 an.
              Klicken Sie bei einem vmxnet-Treiber auf Diskette und geben Sie als Pfad C:\Programme\VMware\VMware Tools\Drivers\vmxnet\ an.
            6. Starten Sie die virtuelle Maschine neu.
          • Eine IDE-Festplatte, die einer virtuellen Maschine mit der Hardwareversion 7 hinzugefügt wurde, wird als Festplatte 1 definiert, auch wenn bereits eine SCSI-Festplatte vorhanden ist
            Wenn Sie einer virtuellen Maschine mit der Hardwareversion 7, die über eine als Festplatte 1 definierte SCSI-Festplatte verfügt, eine IDE-Festplatte hinzufügen, ändert die virtuelle Maschine die Plattennummerierung. Die IDE-Festplatte wird als Festplatte 1 definiert und die SCSI-Festplatte wird zu Festplatte 2.

            Umgehung: Keine. Verlassen Sie sich jedoch nicht ausschließlich auf die Plattennummer, wenn Sie sich entschließen, eine der Festplatten zu löschen. Überprüfen Sie stattdessen den Plattentyp, um sicherzustellen, dass Sie die richtige Platte löschen.

          • Das Wiederherstellen eines Snapshots funktioniert möglicherweise nicht, wenn Sie mittels Cold-Migration eine virtuelle Maschine mit einem Snapshot von einem ESX/ESXi 3.5-Host auf einen ESX/ESXi 4.0-Host verlagern
            Sie können mittels Cold-Migration eine virtuelle Maschine mit Snapshots von einem ESX/ESXi 3.5-Host auf einen ESX/ESXi 4.0-Host verlagern. Dennoch funktioniert das Wiederherstellen eines Snapshots nach der Migration möglicherweise nicht.

            Umgehung: Keine

          • Der vCenter Server schlägt fehl, wenn die Delta-Festplattentiefe einer virtuellen Maschine vom Typ "Verknüpfter Klon" größer ist als die unterstützte Tiefe von 32
            Wenn die Delta-Festplattentiefe eines verknüpften Klons größer ist als die unterstützte Tiefe von 32, schlägt der vCenter Server fehl. Folgende Fehlermeldung wird angezeigt:

            Win32-Ausnahme: Stapelüberlauf

            Unter diesen Umständen kann der vCenter Server erst dann neu gestartet werden, wenn Sie die virtuelle Maschine von dem Host entfernt oder die vCenter Server-Datenbank bereinigt haben. Erwägen Sie, die virtuelle Maschine von dem Host zu entfernen statt die vCenter Server-Datenbank zu bereinigen, da dies sicherer ist.

            Umgehung: Führen Sie die folgenden Schritte aus:

            1. Melden Sie sich beim vSphere-Client auf dem Host an.
            2. Zeigen Sie den Klon der virtuellen Maschine in der Bestandsliste an.
            3. Klicken Sie mit der rechten Maustaste auf die virtuelle Maschine und wählen Sie Von Festplatte löschen.
            4. Starten Sie den vCenter Server neu.

            Hinweis: Wenn nach dem Neustart von vCenter Server die virtuelle Maschine in der Bestandsliste im vSphere-Client angezeigt wird und die Option Aus Bestandsliste entfernen im Kontextmenü der virtuellen Maschine deaktiviert ist, müssen Sie den Eintrag für die virtuelle Maschine manuell aus der vCenter-Datenbank entfernen.

          • Das Erstellen einer neuen SCSI-Festplatte in einer virtuellen Maschine kann dazu führen, dass eine ungenaue Fehlermeldung ausgegeben wird
            Wenn Sie eine neue SCSI-Festplatte in einer virtuellen Maschine erstellen und den SCSI-Bus auf virtual setzen, wird folgende Fehlermeldung ausgegeben:

            Stellen Sie sicher, dass die virtuelle Festplatte unter Verwendung der Option "Thick" erstellt wurde.

            Allerdings ist Thickkeine gültige Option. Die korrekte Option lautet eagerzeroedthick.

            Umgehung: Erstellen Sie die SCSI-Festplatte mit dem Befehlszeilenbefehl vmkfstoolsund der Option eagerzeroedthick.
          • Die Optionen für den Installationsstartvorgang einer virtuellen Maschine werden nicht in das Open Virtualization Format (OVF) exportiert
            Wenn Sie auf einer virtuellen Maschine, auf der die Option "Installationsstartvorgang" aktiviert ist, ein OVF-Paket erstellen, wird diese Option während des Exports ignoriert. Daher fehlt im OVF-Deskriptor das Element InstallSection, das Informationen zum Installationsvorgang liefert. Wenn Sie ein OVF-Paket bereitstellen, wird das Element InstallSection ordnungsgemäß analysiert.

            Umgehung: Nachdem die virtuelle Maschine nach OVF exportiert wurde, erstellen Sie die InstallSection-Parameter manuell im OVF-Deskriptor. Ist eine Manifestdatei ( .mf) vorhanden, müssen Sie sie im Anschluss an die Änderung des OVF-Deskriptors regenerieren.

            Beispiel: Legt fest, dass ein Installationsstart notwendig ist.

            Die Aufnahme der InstallSection-Parameter in den Deskriptor informiert den Bereitstellungsvorgang darüber, dass für den Abschluss der Bereitstellung ein Installationsstartvorgang erforderlich ist. Das Attribut ovf:initialBootStopDelay definiert die Startverzögerung.

            Einzelheiten hierzu finden Sie in der OVF-Spezifikation.

          • Eine von einem Snapshot einer virtuellen Maschine mit einem LSI SAS-Controller geklonte virtuelle Maschine wird evtl. fälschlicherweise mit einem BusLogic-Controller konfiguriert
            Wenn Sie einen Snapshot einer virtuellen Maschine mit einem LSI SAS-Controller erstellen und anschließend von dem Snapshot eine virtuelle Maschine klonen, wird für die von dem Snapshot geklonte virtuelle Maschine möglicherweise ein BusLogic- statt eines LSI SAS-Controllers in den VM-Eigenschaften konfiguriert.

            Umgehung: Überprüfen Sie in der Eigenschaft "Snapshot.config" den Controllertyp der virtuellen Maschine, die Sie anhand eines Snapshots einer virtuellen Maschine, die über einen LSI SAS-Controller verfügt, geklont haben. Konfigurieren Sie nach Bedarf den Controllertyp für die geklonte virtuelle Maschine.

          •  Die virtuelle Maschine kann nicht gestartet werden, nachdem mit iLO ein virtuelles CD-ROM-Laufwerk ohne Medium als ein SCSI-Gerät hinzugefügt wurde
            Nachdem mit iLO (Integrated Lights-Out) ein virtuelles CD-ROM-Laufwerk ohne Medium als SCSI-Gerät zur virtuellen Maschine hinzugefügt wurde, kann die virtuelle Maschine nicht gestartet werden, wenn Sie versuchen, von der virtuellen CD-ROM zu starten.

            Es gibt drei Umgehungen für dieses Problem:
            • Stellen Sie sicher, dass das virtuelle iLO-CD-ROM-Laufwerk immer ein Medium enthält, wenn es angeschlossen ist und von einer beliebigen virtuellen Maschine verwendet wird.
            • Wenn das virtuelle CD-ROM-Laufwerk nicht zur Installation des Gastbetriebssystems auf der virtuellen Maschine verwendet wird, ändern Sie die Startreihenfolge im BIOS der virtuellen Maschine, sodass Festplatte, Diskettenlaufwerk und Netzwerkkarte vor dem CD-ROM-Laufwerk aufgeführt werden.
            • Verwenden Sie kein virtuelles iLO-CD-ROM-Laufwerk. ESX kann sowohl lokale als auch Remote-CD-ROM-Laufwerke und ISO-Images mit den virtuellen Maschinen verbinden, ohne die Einschränkung durchzusetzen, dass nur ein CD-ROM-Laufwerk von iLO auf einem System angezeigt wird.

          vMotion und Storage vMotion

          • Nach dem Neukonfigurieren und Verlagern der virtuellen Maschine kann das Wiederherstellen eines Snapshots fehlschlagen
            Wenn Sie die Eigenschaften einer virtuellen Maschine neu konfigurieren und sie auf einen anderen Host verschieben, kann das Wiederherstellen eines zuvor erstellten Snapshots fehlschlagen.

            Umgehung: Vermeiden Sie es, virtuelle Maschinen auf einen Host zu verschieben, dessen Eigenschaften sich sehr von denen des ursprünglichen Hosts unterscheiden (z. B. verschiedene Versionen, verschiedene CPU-Typen usw.)

          • Bei der Verwendung von Storage vMotion für die Migration einer virtuellen Maschine mit vielen Festplatten kann es zu Zeitüberschreitungen kommen
            Die Migration einer virtuellen Maschine mit vielen virtuellen Festplatten unter Verwendung von Storage vMotion kann möglicherweise nicht abgeschlossen werden. Der Storage vMotion-Vorgang benötigt während der abschließenden Kopierphase Zeit für das Öffnen, Schließen und Verarbeiten von Festplatten. Wegen dieses plattenbezogenen Overheads kann es bei Storage vMotion-Migrationen von virtuellen Maschinen mit vielen Festplatten zur Zeitüberschreitung kommen.

            Umgehung: Erhöhen Sie den Wert für die Storage vMotion-Einstellung fsr.maxSwitchoverSeconds in der Konfigurationsdatei der virtuellen Maschine. Die Standardeinstellung beträgt 100 Sekunden. Oder vermeiden Sie es, während der Storage vMotion-Migration auf den betroffenen Datenspeichern viele Bereitstellungsvorgänge, Migrationen oder Einschalt- und Abschaltvorgänge durchzuführen.

          • Storage vMotion unterstützt die Konvertierung von Quell-RDMs in Ziel-NFS-Volumes nicht
            Storage vMotion nur für Festplatten schlägt bei RDMs im virtuellen Modus fehl, wenn Sie auf NFS-Volumes Festplatten in die Formate "Flach" oder "Geringe Datendichte" konvertieren.

            Umgehung: Führen Sie zum Migrieren von RDMs im virtuellen Modus nach NFS-Volumes folgende Schritte aus:

            1. Verwenden Sie Storage vMotion, um über ein SAN, lokal oder über ein iSCSI-Volume eine RDM-VM-Festplatte in den Festplattentyp "Flach/Geringe Datendichte" zu konvertieren.
            2. Verwenden Sie Storage vMotion, um die konvertierten Festplatten von der SAN, lokal oder vom iSCSI-Laufwerk auf ein NFS-Laufwerk zu verlagern.
          • Storage vMotion eines NFS-Volumes wird möglicherweise von dem NFS-Serverfestplattenformat überschrieben
            Wenn Sie Storage vMotion zum Migrieren einer virtuellen Festplatte auf ein NFS-Volume oder für die Bereitstellung von virtuellen Maschinen, bei der NFS-Volumes einbezogen werden, verwenden, wird das Festplattenformat von dem NFS-Server bestimmt, auf dem sich das NFS-Volume befindet. Falls Sie eine Auswahl im Menü Festplattenformat getroffen haben, wird sie damit außer Kraft gesetzt.

            Umgehung: Keine

          • Wenn ESX/ESXi-Hosts ausfallen oder während Storage vMotion neu gestartet werden, kann der Vorgang fehlschlagen und die virtuellen Maschinen können verwaisen
            Wenn Hosts ausfallen oder während Storage vMotion neu gestartet werden, kann der vMotion-Vorgang fehlschlagen. Die virtuellen Festplatten der virtuellen Zielmaschine können nach einem Neustart des Hosts in der Bestandsliste als verwaist erscheinen. In der Regel wird der Status der virtuellen Maschine beibehalten, bevor der Host heruntergefahren wird.

            Überprüfen Sie, falls die virtuelle Maschine nicht mit dem Status "verwaist" aufgeführt wird, ob die Ziel-VMDK-Dateien vorhanden sind.

            Umgehung: Sie können die verwaiste virtuelle Zielmaschine manuell aus der vSphere-Bestandsliste löschen. Suchen Sie im Datenspeicher nach weiteren verwaisten Zielfestplatten und löschen Sie sie.

          • Storage vMotion steht mit Remote-CD/DVD- und Disketten-Geräteverbindungen in Konflikt
            CD/DVDs und Disketten werden von Storage vMotion nicht als Remote-Sicherungsgeräte unterstützt. Dennoch bleibt, wenn Sie Storage vMotion auf einer eingeschalteten, von ESX/ESXi 4.0 gehosteten virtuellen Maschine ausführen, das Symbol für den Aufbau und das Trennen der Verbindung zu CD/DVD- und Diskettenlaufwerken in der Symbolleiste aktiv und ermöglicht Ihnen, diese Geräte während der Laufzeit von Storage vMotion hinzuzufügen, obwohl dies Fehler verursachen könnte.

            Umgehung: Trennen Sie die bestehenden Verbindungen zu allen Remote-CD/DVD- und -Diskettenlaufwerken, bevor Sie Storage vMotion starten, indem Sie auf das entsprechende Symbol klicken.

          • Der Fehlermodus von Storage vMotion kann dazu führen, dass eine virtuelle Maschine ausgeschaltet wird
            Wenn Storage vMotion auf einem ESX/ESXi 4.0-Host verwendet wird und das Verschieben von Daten wegen eines flüchtigen Fehlers (z. B.: nicht genügend Arbeitsspeicher) fehlschlägt, ist es möglich, dass Storage vMotion nicht erfolgreich beendet wird, sich die Migrationsleistung verschlechtert oder die virtuelle Quellmaschine ausgeschaltet wird.

            Umgehung: Schalten Sie die virtuelle Maschine ein.

          • Auf ESX/ESXi 3.5-Hosts zeigt Storage vMotion nicht den korrekten Festplattentyp an, falls sich dieser während der Laufzeit von Storage vMotion ändert
            Der Storage vMotion-Assistent bietet eine Option an, mit der Festplattentypen für virtuelle Maschinen konvertiert werden können (von "Thick" zu "Thin" und umgekehrt). Dies gilt für alle ESX/ESXi-Host-Versionen. Nachdem eine Festplatte konvertiert wurde und Storage vMotion beendet ist, wird der Festplattentyp für ESX/ESXi 3.5-Hosts nicht ordnungsgemäß angezeigt. Der vSphere-Client zeigt immer noch den alten Festplattentyp an.

            Umgehung: Schalten Sie die virtuelle Maschine aus, heben Sie die Registrierung auf und registrieren Sie sie erneut.

          • Auf einer lokalen Datenspeicher gespeicherte virtuelle Maschinen werden nicht vom Host migriert, wenn sich der Host im Wartungsmodus befindet
            Auf einer lokalen Datenspeicher gespeicherte virtuelle Maschinen werden nicht vom Host migriert, wenn sich der Host im Wartungsmodus befindet.

            Umgehung: Verschieben Sie die virtuellen Maschinen auf lokalen Datenspeichern manuell auf einen anderen Host, falls sie weiterhin zur Verfügung stehen müssen, während sich der aktuell Host im Wartungsmodus befindet.

          • Das Verwenden von Storage vMotion zum Verlagern einer virtuellen Maschine zurück in deren Quellvolume führt möglicherweise zu einem Fehler des Typs "Unzureichender Festplattenspeicher"
            Wenn Sie Storage vMotion zum Verschieben einer virtuellen Maschine in einen anderen Datenspeicher und anschließend zurück in deren Quellvolume verwenden, aktualisiert der vSphere-Client die Größe des Quelldatenspeichers nicht sofort, was zu einem Fehler führt.

            Umgehung: Aktualisieren Sie den Datenspeicher im vSphere-Client. Falls sich nach dem ersten Versuch die gemeldete Größe des Datenspeichers nicht ändert, warten Sie 30 Minuten und versuchen Sie es erneut.

          VMware High Availability und Fault Tolerance

          • Failover auf sekundäre virtuelle VMware FT-Maschine führt zu Fehlermeldung auf dem Host-Client
            Wenn VMware-Fehlertoleranz ein Failover auf eine sekundäre virtuelle Maschine durchführt und der für die sekundäre virtuelle Maschine ausgewählte Host erst kürzlich neu gestartet wurde, betrachtet der Host-Client diesen Versuch als Fehlschlag und zeigt folgende Fehlermeldung an:

            Anmeldung fehlgeschlagen wegen eines ungültigen Benutzernamens oder Kennworts.

            Diese Fehlermeldung wird angezeigt, weil der Host kürzlich neu gestartet wurde und es möglich ist, dass er noch keinen SSL-Fingerabdruck von vCenter Server empfangen hat. Nachdem der Fingerabdruck an den Host gesendet wurde, verläuft das Failover erfolgreich. Diese Bedingung tritt nur dann auf, wenn alle Hosts in einem FT-aktivierten Cluster ausgefallen sind, was dazu führt, dass der Host mit der sekundären virtuellen Maschine neu gestartet wird.

            Umgehung: Keine. Das Failover verläuft nach einigen Versuchen erfolgreich.

          • Das Ändern der Systemzeit auf einem ESX/ESXi-Host führt zu einem VMware HA-Agent-Fehler
            Wenn Sie die Systemzeit auf einem ESX/ESXi-Host ändern, wird nach kurzer Zeit der folgende HA-Agent-Fehler angezeigt:

            Der HA-Agent auf < Server> in < Cluster> im < Datencenter> hat einen Fehler.

            Dieser Fehler wird sowohl im Ereignisprotokoll als auch auf der Host-Registerkarte Übersicht im vSphere-Client angezeigt.

            Umgehung: Korrigieren Sie die Systemzeit des Hosts und starten Sie "vpxa" mit dem Befehl service vmware-vpxa restart neu.

          • Der Versuch, das Festplattenformat einer FT-aktivierten virtuellen Maschine zu ändern, während sie von einem zu einem anderen Datenspeicher migriert wird, schlägt fehl
            Wenn Sie versuchen, das Festplattenformat einer ausgeschalteten, FT-aktivierten virtuellen Maschine zu ändern, während sie von einem zu einem anderen Datenspeicher migriert wird, zeigt der vSphere-Client eine InvalidArgument-Fehlermeldung an, die angibt, dass der Vorgang fehlgeschlagen ist. Das korrekte Verhalten des vSphere-Clients ist, die Option zum Ändern des Festplattenformats zu deaktivieren.

            Umgehung: Wählen Sie Format wie Quelle, die Standardoption, wenn Sie eine FT-aktivierte virtuelle Maschine in einen anderen Datenspeicher migrieren.

          • Die Funktion zur Überwachung virtueller Maschinen in VMware HA wird nicht für ESX- oder ESXi-Versionen vor ESX 3.5 U3 unterstützt
            Wenn VMware HA auf einem Cluster aktiviert ist, der von vCenter Server 4.0 verwaltet wird, funktioniert die VM-Überwachung nicht ordnungsgemäß auf ESX- oder ESXi-Hosts, die älter als ESX Server 3.5 Update 3 sind, und kann zu ungewollten Failover-Vorgängen von virtuellen Maschinen führen.

            Umgehung: Deaktivieren Sie die VM-Überwachungsfunktion für solche virtuelle Maschinen oder aktualisieren Sie den ESX/ESXi-Host auf ESX Server 3.5 Update 3 oder später.

          • Nicht reagierende sekundäre virtuelle Maschinen oder Kopien von virtuellen Maschinen, ggf. mit anderen Namen, verbleiben möglicherweise in der Hostbestandsliste, wenn das Einschalten von Fault Tolerance unterbrochen wurde
            Wenn Sie bei einer virtuellen Maschine, auf der VMware HA aktiviert ist, Fault Tolerance einschalten, kann es sein, dass der Bestandsliste des Clusters eine nicht reagierende sekundäre virtuelle Maschine hinzugefügt wird oder dass Sie mehrere Kopien der virtuellen Maschine mit unterschiedlichen Namen erhalten. Diese Situation tritt dann auf, wenn der Ziel-ESX/ESXi-Host auf der sekundären virtuellen Maschine, beispielsweise wegen eines Neustarts, Stromausfalls oder der Trennung vom Netzwerk, während der Erstellung der sekundären Kopie die Verbindung zu seinem verwaltenden vCenter Server verliert. Dies kann dazu führen, dass die Konfigurationseinstellungen auf der sekundären virtuellen Maschine nicht vollständig sind.

            Umgehung: Löschen Sie die nicht reagierende sekundäre virtuelle Maschine aus der Bestandsliste von vCenter Server.

          • Eine sekundäre virtuelle Maschine verbleibt in der Bestandsliste, nachdem die Fehlertoleranz für die primäre virtuelle Maschine ausgeschaltet wurde
            In einigen seltenen Fällen verläuft die Auswahl von Fehlertoleranz ausschalten im vSphere-Client für eine primäre virtuelle Maschine erfolgreich, aber die zugeordnete sekundäre virtuelle Maschine verbleibt in der Bestandsliste. Dies tritt gelegentlich ein, wenn gerade ein Failover-Vorgang aufgetreten ist und die neue sekundäre virtuelle Maschine noch nicht gestartet wurde. Es hat aber keine ernsthaften Folgen, da die Dateien der sekundären virtuellen Maschine bereits gelöscht wurden.

            Umgehung: Löschen Sie die sekundäre virtuelle Maschine manuell.

          • Beim Konfigurieren von VMware High Availability (HA) auf einem stark belasteten System erscheint möglicherweise eine Fehlermeldung
            Wenn Sie HA auf einem Host aktivieren, der aufgrund seiner Gast-VMs eine schwere Arbeitslast zu bewältigen hat, wird die HA-Konfiguration für den Host möglicherweise unterbrochen und eine Fehlermeldung ausgegeben:
            HA-Agent auf dem Host fehlgeschlagen

            Umgehung: Konfigurieren Sie HA für den Host neu, möglichst nachdem Sie die Last reduziert haben, indem Sie entweder virtuelle Maschinen ausschalten oder sie unter Verwendung von vMotion auf einen anderen Host im Cluster migrieren.

          • Bei angehaltenen virtuellen Maschinen mit unabhängigen, nicht dauerhaften Festplatten ist kein Failover auf VMware HA-Hosts möglich
            Wenn Sie auf einem Host virtuelle Maschinen angehalten oder ausgeschaltet haben und wenn die Festplatten der virtuellen Maschinen als unabhängig und nicht-dauerhaft konfiguriert sind, findet kein Failover statt. Diese Festplatten werden nicht auf einen anderen Host migriert, falls der Host ausfällt, ausgeschaltet wird oder in den Wartungsmodus versetzt wird. Das Migrieren dieser virtuellen Maschinen wird zurzeit für HA nicht unterstützt, weil die Maschinen mit keinem anderen Host im Cluster kompatibel sind.

            Umgehung: Heben Sie die Registrierung der virtuellen Maschine auf und registrieren Sie sie auf einem kompatiblen Host.

          • VMware HA meldet möglicherweise irreführende Zeitüberschreitungsfehler beim Einschalten oder Failover eines Hosts mit vielen VMs
            VMware HA-Zeitüberschreitungsfehler treten möglicherweise ein paar Minuten nach dem Einschalten oder Migrieren (unter Verwendung von VMware HA) eines Hosts mit vielen VMs (mehr als 70) auf. Dieser Zeitüberschreitungsfehler verschwindet, nachdem die meisten der VMs eingeschaltet wurden.

            Umgehung: Sie können ignoriert werden.

          • Die VMware-Fehlertoleranz unterstützt die IPv6-Adressierung nicht
            Wenn den VMkernel-Netzwerkkarten für die Fehlertoleranzprotokollierung oder für vMotion IPv6-Adressen zugewiesen werden, schlägt das Aktivieren der Fehlertoleranz auf virtuellen Maschinen fehl.

            Umgehung: Konfigurieren Sie die VMkernel-Netzwerkkarten anhand der IPv4-Adressen.
          • Das Hot-Plugging von Geräten wird nicht unterstützt, wenn die Fehlertoleranz auf virtuellen Maschinen deaktiviert ist
            Die Hot-Plugging-Funktion wird auf virtuellen Maschinen nicht unterstützt, wenn die VMware-Fehlertoleranz auf diesen virtuellen Maschinen aktiviert oder deaktiviert ist. Sie müssen die Fehlertoleranz vorübergehend ausschalten, bevor Sie ein Hot-Plugging für ein Gerät durchführen können. Nach dem Hot-Plugging können Sie die Fehlertoleranz wieder einschalten. Nach dem Entfernen eines Geräts bei laufendem Betrieb sollten Sie die virtuelle Maschine allerdings neu starten, um die Fehlertoleranz einzuschalten.

          VMware Tools

          • Die IP-Virtualisierung von Windows Server 2008 R2 (64-Bit) funktioniert auf vSphere 4.0 Update 1 möglicherweise nicht
            Die IP-Virtualisierung, die es Ihnen ermöglicht, RDP-Sitzungen eindeutige IP-Adressen zuzuteilen, funktioniert möglicherweise nicht auf einem Windows 2008 R2 Terminal Server, der unter vSphere 4.0 Update 1 ausgeführt wird. Die IP-Virtualisierung funktioniert jedoch, wenn Sie einen physischen Windows 2008 R2 Terminal Server konfigurieren oder eine virtuelle Windows 2008 R2-Maschine unter 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.

            Umgehung: Wählen Sie die Option für eine benutzerdefinierte Installation von VMware Tools und entfernen Sie VMCI aus der Liste der Treiber, die installiert werden sollen.

          •  Unter bestimmten Bedingungen reagieren Snapshots einer virtuellen Maschine nicht
            Versuche, einen Snapshot einer virtuellen Maschine zu erstellen, führen möglicherweise dazu, dass der Status Vorgang läuftangezeigt wird, wenn alle der folgenden Bedingungen zutreffen:
            • Die Option Snapshot des Arbeitsspeichers der virtuellen Maschine erstellen wurde nicht ausgewählt.
            • Die Option Gast-Dateisystem stilllegen wurde ausgewählt.
            • Ein VSS (Volume Shadow Copy Service) von einem Drittanbieter wurde installiert.
            In solchen Fällen wird der Status Vorgang läuftsolange angezeigt, bis für die Aufgabe eine Zeitüberschreitung eintritt. Darüber hinaus wird der Prozess fortgesetzt und verhindert somit, dass andere Snapshots erstellt werden.

          Seitenanfang

          PAGE_CORE_CONTENT::: HERO_CAROUSEL_CONTENT::: PROMO_CONTENT::: STATIC_LOCAL_NAV_CONTENT:::