Versionshinweise zu VMware vSphere 4.1 – ESXi Edition

Kontakt zum Vertrieb
 

ESXi 4.1 Installable | 13. Juli 2010 | Build 260247

ESXi 4.1 Embedded | 13. Juli 2010 | Build 260247

vCenter Server 4.1 | 13. Juli 2010 | Build 259021

Letzte Aktualisierung: 15. September 2010

Überprüfen Sie, ob Erweiterungen und Updates für diese Versionshinweise zur Verfügung stehen.

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

Neuigkeiten

VMware vSphere™ 4.1 enthält VMware ESXi™ 4.1 Installable, VMware ESXi™ 4.1 Embedded und VMware vCenter Server™ 4.1. Weitere Informationen über die neuen und erweiterten Funktionen in dieser Version finden Sie unter Neuheiten bei VMware vSphere 4.1.

Internationalisierung

VMware vSphere 4.1 ist in den folgenden Sprachen verfügbar:

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

Erzwingen des Gebietsschemas von vSphere-Client

In vSphere 4.1 können Sie VMware vSphere Client™ so konfigurieren, dass alle Texte der Benutzerschnittstelle auf Englisch erscheinen, auch für den Fall, dass für die Maschine, auf der er läuft, eine andere Sprache eingerichtet ist. Diese Konfiguration kann durch Angabe eines Befehlszeilenparameters für die Dauer einer einzelnen Sitzung erfolgen. Diese Konfiguration gilt für die Texte der Benutzerschnittstelle. Sie gilt nicht für andere Einstellungen des Gebietsschemas, z. B. für Datum und Uhrzeit oder für das Formatieren von numerischen Angaben.

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

vpxClient -locale en_US

Kompatibilität und Installation

ESXi, vCenter Server und vSphere Client – Versionskompatibilität

Die Kompatibilitätstabellen für vSphere liefern Details zur Kompatibilität aktueller und früherer Versionen von VMware vSphere-Komponenten, einschließlich ESXi, vCenter Server, dem vSphere-Client und wahlweise anderer VMware-Produkte. Überprüfen Sie außerdem die "Kompatibilitätstabellen für vSphere 4.1" auf Informationen zu unterstützten Verwaltungs- und Sicherungsagenten, bevor Sie ESXi oder vCenter Server installieren.

Hardwarekompatibilität für ESXi

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

vSphere-Client-Verbindungen zu Umgebungen im verknüpften Modus mit vCenter Server 4.1

vCenter Server 4.1 kann sich im verknüpften Modus zusammen mit anderen Instanzen von vCenter Server 4.1 oder vCenter Server 4.0 und höher befinden. Wenn der vSphere-Client, der der Version des vCenter Server entspricht, zu dem Sie eine Verbindung herstellen möchten, auf Ihrem System nicht installiert ist, werden Sie aufgefordert, die entsprechende Version des vSphere-Clients herunterzuladen und zu installieren. Nachdem beide Versionen des vSphere-Clients installiert sind, haben Sie mit jedem der Clients Zugriff auf die mit dem vCenter Server verknüpften Objekte. Für Umgebungen im verknüpften Modus mit vCenter Server 4.0 und vCenter Server 4.1 benötigen Sie vSphere-Client 4.0 Update 1 und vSphere-Client 4.1. Sie können vSphere-Client 4.0 Update 1 unter Download VMWare vSphere 4 herunterladen.

vSphere 4.1 und VMware View-Kompatibilität

Informationen zu vSphere-Konfigurationen, die mit VMware View 4.0.x unterstützt werden, finden Sie unter Produkt-Support-Center für VMware View.

Installationshinweise für diese Version

Im ESXi Installable und vCenter Server-Handbuch zur Einrichtung finden Sie Schritt-für-Schritt-Anleitungen zur Installation und Konfiguration von ESXi Installable und vCenter Server. Genaue Anleitungen zur Einrichtung von ESXi Embedded und vCenter Server finden Sie im ESXi Embedded und vCenter Server-Handbuch zur Einrichtung.

Nach der erfolgreichen Installation von ESXi Installable oder dem erfolgreichen Starten von ESXi Embedded sind einige weitere Konfigurationsschritte erforderlich. Insbesondere sind Lizenzierungs-, Netzwerk- und Sicherheitskonfigurationen erforderlich. Beachten Sie die folgenden Handbücher in der vSphere-Dokumentation für weitere Informationen zu diesen Konfigurationsaufgaben.

vCenter Server 4.1 unterstützt nur die Installation auf 64-Bit-Plattformen von Windows. Wenn VMware 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.

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

vCenter Server 4.1 enthält zum vCenter Server gehörende MIB-Dateien (MIB, Management Information Base). Sie können MIB-Dateien, die sich auf ESXi beziehen, von der VMware-Website unter http://downloads.vmware.com/de/d/info/datacenter_downloads/vmware_vsphere_4/4#drivers_tools herunterladen.

Upgrades für diese Version

vCenter Server-Upgrades

Der vCenter Server 4.1 muss auf einem 64-Bit-System installiert werden. Wenn das System ein 64-Bit-System ist, können Sie ein Upgrade von vCenter Server 4.0 auf vCenter Server 4.1 durchführen. Stellen Sie beim Aktualisieren zuerst sicher, dass Ihre Datenbank mit vCenter Server 4.1 unterstützt wird, und sichern Sie Ihre unterstützte Datenbank, die SSL-Zertifikate und die vCenter Server-Konfiguration. Führen Sie anschließend das vCenter Server-Installationsprogramm aus. Das Installationsprogramm stellt fest, dass sich auf dem Computer eine frühere Version von vCenter Server befindet, und teilt Ihnen mit, dass sie aktualisiert wird.

Ein Upgrade von VirtualCenter Server 2.5 oder vCenter Server 4.0, der sich auf einem 32-Bit-System befindet, auf vCenter Server 4.1, der sich auf einem 64-Bit-System befindet, ist möglich, indem Sie vCenter Server 4.1 auf einem 64-Bit-System installieren und die Datenbank vom VirtualCenter Server 2.5 oder vCenter Server 4.0 System behalten. Zur Migration der vCenter Server-Konfiguration von einem 32-Bit- auf das 64-Bit-System können Sie das Datenmigrations-Tool verwenden. Weitere Informationen finden Sie im vSphere-Upgrade-Handbuch.

ESXi-Upgrades

vSphere 4.1 bietet die folgenden Tools für Upgrades von ESXi-Hosts:

Wenn Sie über ESXi 3.5 verfügen, jedoch nicht über vCenter Update Manager 4.1, müssen Sie mithilfe von vSphere Host Update Utility 4.0 oder vCenter Update Manager 4.0 ein Upgrade auf ESXi 4.0 oder auf eine Update-Version von ESXi 4.0 durchführen. Anschließend können Sie mit vCenter Update Manager 4.1 oder dem Dienstprogramm "vihostupdate" ein Upgrade auf ESXi 4.1 durchführen. Ausführliche Anweisungen finden Sie im vSphere-Upgrade-Handbuch.

Testversionen von vSphere 4.1

Upgrades von vSphere 4.1 Beta und den vSphere 4.1 Release Candidate-Versionen auf vSphere 4.1 werden nicht unterstützt. Deinstallieren Sie ESXi 4.1 Beta bzw. den Release-Kandidaten und vCenter Server 4.1 Beta oder den Release-Kandidaten und führen Sie eine Neuinstallation von vCenter Server 4.1 und ESXi 4.1 durch. Sofern Sie Beta- oder Release-Kandidat-Versionen von vSphere 4.1 getestet haben, wird empfohlen, die Daten, die Sie aus den Konfigurationen auf vSphere 4.1 beibehalten möchten, neu zu erstellen.

Migrationen von virtuellen Maschinen unter Verwendung von VMotion von einem Beta- oder einem Release-Kandidat-Host auf einen vSphere 4.1-Host werden nicht unterstützt.

VMware vSphere SDKs

VMware vSphere bietet SDKs für Webservices und Gastbetriebssysteme:

  • vSphere Web Services SDK. Diese Version des vSphere Web Services SDK bietet die Unterstützung für die in ESX 4.1- und vCenter Server 4.1-Serversystemen verfügbaren neuen Funktionen. Sie können dieses SDK auch mit vorherigen Versionen von ESX und vCenter Server verwenden. Weitere Informationen finden Sie in der VMware vSphere Web Services SDK-Dokumentation.

  • vSphere Guest SDK. Das VMware vSphere Guest SDK 4.0 wird auf ESX 4.1 unterstützt. Weitere Informationen finden Sie in der VMware vSphere Guest SDK-Dokumentation.

Open Source-Komponenten für vSphere

Open Source-Komponenten und ihre jeweiligen Lizenzen für die neueste verfügbare Version von vSphere sind unter http://downloads.vmware.com/de/d/info/datacenter_downloads/vmware_vsphere_4/4#open_source auf der Registerkarte Open Source verfügbar. Indem Sie auf diesen Link klicken, können Sie für die neueste verfügbare Version von vSphere auch die Quelldateien der Teile herunterladen, die unter GPL oder LGPL oder einer anderen Lizenz veröffentlicht wurden, die es erfordert, den Quellcode oder Änderungen des Quellcodes zur Verfügung zu stellen.

Hinweise zur vSphere 4.1 Produkt-, Funktions- und Plattform-Unterstützung

VMware vSphere 4.1 ist die letzte Version für die folgenden Produkte, Funktionen und Plattformen. VMware bietet weiterhin technischen Support für diese Funktionen und Plattformen bis zum Ende der Supportdauer an.

  • VMware ESX. VMware vSphere 4.1 und dessen nachfolgenden Update- und Patch-Versionen sind die letzten Versionen, die sowohl ESX- als auch ESXi-Hypervisor-Architekturen enthalten. Zukünftige Hauptversionen von VMware vSphere enthalten nur die VMware ESXi-Architektur.

    • Den Kunden wird empfohlen, bei der Bereitstellung von VMware vSphere 4.1 mit dem Übergang zur ESXi-Architektur zu beginnen.
    • VMware bietet weiterhin technischen Support für VMware ESX entsprechend den VMware vSphere Supportrichtlinien auf der Seite VMware Enterprise Infrastructure Support.
    • Weitere Informationen zur ESXi-Architektur und zur Migration von ESX nach ESXi finden Sie im VMware ESX to ESXi Upgrade Center.

  • VMware vCenter Converter-Plug-In. VMware vSphere 4.1 und die nachfolgenden Update- und Patch-Versionen sind die letzten Versionen für das VMware vCenter Converter-Plug-In für vSphere-Client. VMware bietet weiterhin Updates und Unterstützung für das kostenlose Converter Standalone-Produkt an, das Konvertierungen aus Quellen wie physischen Maschinen, VM-Formaten von VMware und Microsoft und bestimmten Festplatten-Image-Formaten von Drittanbietern ermöglicht.

  • VMware vCenter Guided Consolidation. VMware vSphere 4.1 und die nachfolgenden Update- und Patch-Versionen sind die letzten größeren Versionen für VMware Guided Consolidation. Kunden, die ihre physischen Server konsolidieren möchten, haben folgende VMware vSphere Serviceoptionen:
    • VMware vSphere mit P2V Migration Jumpstart
    • VMware Virtualization Assessment
    • VMware P2V Accelerator Services

  • Funktionen des VMware vCenter Update Manager. vCenter Update Manager 4.1 und die nachfolgenden Updates stellen die letzten Versionen dar, die die Prüfung und Standardisierung von Patches für Windows- und Linux-Gastbetriebssysteme sowie von in einer virtuellen Maschine ausgeführten Anwendungen unterstützen. Die Möglichkeiten, VM-Vorgänge auszuführen, wie z. B. ein Upgrade von VMware Tools oder der VM-Hardware, werden weiter unterstützt und verbessert.

  • VMware Consolidated Backup. VMware hat das Ende der Verfügbarkeit für VCB verlängert und VCB-Support für vSphere 4.1 hinzugefügt. VMware bietet weiterhin Support für VCB 1.5 Update 2 für vSphere 4.1 und die nachfolgenden Update- und Patch-Versionen bis zum Ende ihres Lebenszyklus. Der Support wird in Übereinstimmung mit den VMware-Support-Richtlinien für die VMware Infrastructure 3 Plattform erweitert. Neue Haupt- oder Nebenversionen der vSphere-Plattform nach vSphere 4.1 werden mit VCB nicht unterstützt.

  • Support für paravirtualisierte VMI-Gastbetriebssysteme. vSphere 4.1 ist die letzte Version, die die Paravirtualisierungsschnittstelle für das VMI-Gastbetriebssystem unterstützt. Weitere Informationen zum Migrieren von VMI-fähigen virtuellen Maschinen, sodass sie auf künftigen Versionen von vSphere lauffähig sind, finden Sie im Knowledgebase-Artikel 1013842.

  •  

    vSphere Web Access. vSphere 4.1 ist die letzte Produktversion für vSphere Web Access. Als Best Practice empfiehlt VMware, dass Sie den vSphere-Client verwenden, der die gesamte Funktionalität von Web Access enthält. vSphere Web Access wird nicht mehr weiterentwickelt, aber Unterstützung für dieses Produkt wird dennoch nach besten Kräften gewährleistet.

  • Anpassung von Linux-Gastbetriebssystemen. vSphere 4.1 ist die letzte Version, die die Anpassung für folgende Linux-Gastbetriebssysteme unterstützt:

    • RedHat Enterprise Linux (AS/ES) 2.1
    • RedHat Desktop 3
    • RedHat Enterprise Linux (AS/ES) 3.0
    • SUSE Linux Enterprise Server 8
    • Ubuntu 8.04
    • Ubuntu 8.10
    • Debian 4.0
    • Debian 5.0

    VMware bietet weiterhin die Anpassung für neuere Versionen von Linux-Gastbetriebssystemen der Server-Familien von RedHat Enterprise Linux und SUSE Linux Enterprise an.

  • Microsoft Windows 2000 MSCS. MSCS mit Windows 2000 wird in vSphere 4.1 nicht unterstützt. Weitere Informationen finden Sie auf der Microsoft-Website.

Weitere Informationen zu den VMware-Supportrichtlinien für die vSphere-Plattform auf der Seite VMware Enterprise Infrastructure Support.

Bekannte Probleme

Der Abschnitt "Bekannte Probleme" befasst sich mit Funktionalitätsproblemen und stellt eine Liste der bekannten Probleme zur Verfügung.

Funktionalitätsprobleme

 

IPv6 standardmäßig deaktiviert. IPv6 ist bei der Installation von ESXi 4.1 standardmäßig deaktiviert.

 

Hardware-iSCSI. Broadcom Hardware-iSCSI unterstützt keine Jumbo-Frames oder IPv6. Abhängige Hardware-iSCSI unterstützt nicht den iSCSI-Zugriff auf dieselbe LUN, wenn ein Host abhängige und unabhängige Hardware-iSCSI-Adapter simultan nutzt.

Liste der bekannten Probleme

Die folgenden bekannten Probleme wurden beim Testen der Software erkannt. Sie helfen Ihnen, das Verhalten, auf das Sie in dieser Version treffen, besser zu verstehen. Diese Liste der Probleme gilt nur für diese Version von vSphere 4.1. Einige bekannte Probleme von vorherigen Versionen betreffen möglicherweise auch diese Version. Wenn ein Problem auftritt, das nicht in der Liste der bekannten Probleme aufgeführt ist, prüfen Sie die Liste der bekannten Probleme früherer Versionen, suchen Sie in der VMware-Knowledgebase oder teilen Sie uns das Problem durch Ihr Feedback mit.

Funktionen und bekannte Probleme der vorherigen Versionen von vSphere 4.0, zu denen ESX/ESXi 4.0 und vCenter Server 4.0 zählen, werden in den jeweiligen Versionshinweisen beschrieben. Die Versionshinweise zu Sphere 4.0 und die nachfolgenden Update-Versionen finden Sie auf der VMware vSphere 4.0 Dokumentationsseite.

Die bekannten Probleme gliedern sich in folgende Gruppen:

Installationsprobleme

  • Die DNS-Server-Einstellungen gehen nach dem zweiten ESXi-Neustart verloren
    Nachdem ESXi unter Verwendung der Skriptinstallationsmethode installiert wurde, gehen die DNS-Server-Einstellungen verloren, wenn ESXi zum zweiten Mal neu gestartet wird. Die Einstellungen sind nach dem ersten Neustart nach der Installation vorhanden, gehen aber nach dem zweiten Neustart verloren.

    Umgehung: Legen Sie /etc/resolv.conf unter Verwendung des Kickstart-Befehls %firstboot fest, wenn Sie die Skriptinstallation von ESXi ausführen. Wenn Sie über viele Hosts verfügen, ist dies möglicherweise die bevorzugte Methode. Alternativ dazu können Sie den DNS über die Benutzerschnittstelle der direkten Konsole für jede ESXi-Instanz zurücksetzen.

  • Die Installation schlägt fehl, wenn Sie vCenter Server deinstallieren und erneut installieren
    Die Installation schlägt mit der Fehlermeldung vCenter Server-Verzeichnisdienste können nicht erstellt werden fehl, wenn vCenter Server auf demselben System deinstalliert und erneut installiert wird.

    Umgehung: Nachdem Sie vCenter Server deinstalliert haben, starten Sie das System neu, bevor Sie vCenter Server erneut installieren.

  • Wenn Sie den vCenter Server 4.1 deinstallieren, ohne den vCenter Server-Service zu stoppen, wird die lokale ADAM-Instanz mitunter nicht entfernt
    Sie müssen den vCenter Server Service stoppen, bevor Sie den vCenter Server 4.1 deinstallieren, anderenfalls verbleibt die ADAM-Instanz möglicherweise im System. Das gilt sowohl für vCenter Server 4.1-Installationen als auch für Upgrades sowie für eigenständige oder verknüpfte vCenter Server-Systeme.

    Umgehung: Stoppen Sie den "VMware VirtualCenter Server"-Service, bevor Sie den vCenter Server 4.1 deinstallieren.

  • vCenter Server-Instanzen, die eine DB2-Datenbank v9.5.0 verwenden, erlauben Ihnen nicht das Hinzufügen eines Hosts
    Wenn Sie ein vCenter Server-System mit einem IBM DB2 v9.5.0 64-Bit-ODBC-Treiber verwenden, können Sie keine Hosts für den vCenter Server verwalten.

    Umgehung: Installieren Sie DB2 9.5 Fix Pack 5.

  • Mit der Installation oder dem Upgrade von vCenter Server werden die Einstellungen des Microsoft SQL Server unbemerkt geändert, sodass Named Pipes aktiviert werden
    Wenn Sie die Installation von vCenter Server 4.1 oder das Upgrade von vCenter Server 4.0.x auf vCenter Server 4.1 auf einem Hostsystem durchführen, das Microsoft SQL Server mit der Einstellung "Nur TCP/IP verwenden" verwendet, ändert das Installationsprogramm diese Einstellung auf "TCP/IP und Named Pipes verwenden", ohne Sie über diese Änderung zu benachrichtigen.

    Umgehung: Die Änderung der Einstellung in "TCP/IP und Named Pipes verwenden" stört nicht den ordnungsgemäßen Betrieb des vCenter Server. Allerdings können Sie mit den folgenden Schritten die Standardeinstellung "Nur TCP/IP verwenden" wiederherstellen.

    1. Wählen Sie Start > Programme > Microsoft SQL Server 2005 > Configuration Tools > SQL Server Surface Area Configuration.
    2. Wählen Sie Surface Area Configuration for Services and Connections.
    3. Unter der SQL Server-Instanz, die Sie für vCenter Server verwenden, wählen Sie die Option Remote Connections.
    4. Ändern Sie die Option unter "Local and Remote Connections" und klicken Sie auf Übernehmen.

  • Die Installation von vCenter Server schlägt mit der Fehlermeldung "Setup kann die Instanz für die vCenter-Verzeichnisdienste nicht erstellen" fehl
    Die Installation von vCenter Server schlägt mit der Fehlermeldung Setup kann die Instanz für die vCenter-Verzeichnisdienste nicht erstellen fehl, wenn die Berechtigung "Jeder" aus der Registrierung unter HKLM entfernt wurde.

    Umgehung: Fügen Sie die Berechtigung "Jeder" in die HKLM-Registrierung ein:

    1. Geben Sie dazu in der Kommandozeile von Windows regedit ein.
    2. Klicken Sie im Registrierungseditor mit der rechten Maustaste auf HKEY_LOCAL_MACHINE und wählen Sie Berechtigungen.
    3. Klicken Sie auf Hinzufügen.
    4. Klicken Sie auf Erweitert.
    5. Wählen Sie die Option Jeder in der Liste und klicken Sie auf OK.
    6. Klicken Sie auf Übernehmen und anschließend auf OK.

  • Die Installation des vSphere-Client schlägt möglicherweise mit der Fehlermeldung "Das Installationsprogramm Microsoft Visual J# 2.0 Second Edition hat den Fehlercode '4113' zurückgegeben" fehl
    Wenn Sie den vSphere-Client installieren, kann es sein, dass das Installationsprogramm versucht, eine veraltete Laufzeitumgebung für Microsoft Visual J# zu aktualisieren. Das Upgrade wird nicht erfolgreich sein und die Installation von vSphere-Client schlägt fehl.

    Umgehung: Deinstallieren Sie alle vorherigen Versionen von Microsoft Visual J# und installieren Sie den vSphere-Client. Die Installation enthält ein aktualisiertes Microsoft Visual J#-Paket.

  • Die Installation von vCenter Server 4.1 unter Verwendung einer vorhandenen IBM DB2-Datenbank schlägt manchmal fehl mit einer DB2 Fehlermeldung
    Wenn Sie vCenter Server 4.1 unter Verwendung einer vorhandenen vCenter Server DB2-Datenbank installieren, erhalten Sie mitunter eine Fehlermeldung ähnlich der Folgenden:

    Es ist ein Datenbankfehler aufgetreten: "ODBC-Fehler: (5UA01) - [IBM][CLI Driver][DB2/NT64] SQL20453N Die Aufgabe "RULE_TOPN1_DB2USER1" kann nicht entfernt werden, da er gerade ausgeführt wird. SQLSTATE=5UA01" wird bei der Ausführung der SQL-Anweisung "CALL CREATE_TOPN_JOB1_PROC()" zurückgegeben

    Diese Meldung wird angezeigt, wenn DB2 ein IBM bekanntes Problem auftritt. Sie bedeutet, dass eine DB2-Aufgabe ausgeführt wird und das vCenter Server-Installationsprogramm die vCenter-Datenbank nicht initialisieren kann.

    Umgehung: Um den Konflikt zu lösen und vCenter Server zu installieren, gehen Sie wie folgt vor:

    1. Wenn vCenter Server ausgeführt wird, fahren Sie ihn kontrolliert herunter.
    2. Verwenden Sie "Systemsteuerung - Verwaltung - Dienste", um den Service "db2" anzuhalten und neu zu starten.
    3. Starten Sie den Installationsvorgang erneut und achten Sie darauf, die Option zum Überschreiben der bestehenden Datenbank auszuwählen.

  • Die vCenter Server-Installation schlägt fehl, wenn das Benutzerkonto, das zur Installation von vCenter Server und zum Überschreiben einer vorhandenen DB2-Datenbank verwendet wird, nicht in der db2user-Gruppe oder der db2admin-Gruppe ist
    Fehler 25003: Repository kann nicht erstellt werden wird angezeigt, wenn das Benutzerkonto, das zur Installation von vCenter Server und zum Überschreiben einer vorhandenen DB2-Datenbank verwendet wird, nicht in der db2user-Gruppe oder der db2admin-Gruppe ist. Klicken Sie auf OK. Das schließt das Dialogfeld mit der Fehlermeldung und macht die Installation rückgängig.

    Umgehung: Nehmen Sie den Datenbank-Benutzer in die Gruppe db2user bzw. db2admin auf. Fragen Sie Ihren Datenbankadministrator.

  • Möglicherweise startet der vCenter Server nicht, nachdem Sie die Installation oder ein Upgrade auf vCenter Server 4.1 mit einer Oracle-Datenbank unter Verwendung eines Oracle 64-Bit-ODBC-Treibers versucht haben
    Wenn Sie eine Neuinstallation oder ein Upgrade auf vCenter Server 4.1 mit einer Oracle-Datenbank unter Verwendung eines Oracle 64-Bit-ODBC-Treibers durchgeführt haben, kann es sein, dass Sie die Fehlermeldung erhalten Datenbankversion id "0" ist nicht mit dieser Version von VirtualCenter kompatibel. Infolgedessen wird der Start des vCenter Server-Services fehlschlagen.

    Umgehung: Aktualisieren Sie auf den Oracle 64-Bit-ODBC-Treiber der Version 10.2.0.4 bzw. 11.1.

Upgrade-Probleme

  • Das Upgrade von vCenter Server wird trotz Änderung des HTTP- or HTTPS-Ports der Webservices unter Verwendung des eingerichteten Ports fortgesetzt
    Beim Ändern der HTTP- bzw. HTTPS-Ports der Webservices durch Verwendung eines eingerichteten Ports auf der Seite Ports konfigurieren wird das Upgrade von vCenter Server ohne Fehlermeldung fortgesetzt.

    Umgehung: Keine.

  • Wenn Sie einen ESXi 4.0-Host auf ESXi 4.1 aktualisieren und anschließend ein Rollback des Hosts auf ESXi 4.0 durchführen, verbleiben die ESXi 4.1-Versionen von VMware Tools und dem vSphere-Client auf dem Host
    Wenn Sie einen Host von ESXi 4.0 auf ESXi 4.1 aktualisieren, werden VMware Tools und der vSphere-Client für ESXi 4.0 entfernt und durch die ESXi 4.1-Version dieser Komponenten ersetzt. Wenn Sie ein Rollback des Hosts auf ESXi 4.0 durchführen, werden die ESXi 4.0-Versionen von VMware Tools und dem vSphere-Client nicht wiederhergestellt.

    Umgehung:

    Für ESXi Embedded:

    1. Sichern Sie die ESXi-Konfiguration mithilfe des Befehls vicfg-cfgbackup.
    2. Spielen Sie eine saubere Kopie von ESXi 4.0 auf den USB-Stick auf.
    3. Stellen Sie die Konfiguration mithilfe des Befehls vicfg-cfgbackup wieder her.
    4. Registrieren Sie die virtuellen Maschinen erneut.

    Für ESXi Installable:

    1. Sichern Sie die ESXi-Konfiguration mithilfe des Befehls vicfg-cfgbackup.
    2. Sichern Sie die VMFS-Datenspeicher.
    3. Installieren Sie ESXi 4.0 neu.
    4. Stellen Sie die Konfiguration mithilfe des Befehls vicfg-cfgbackup wieder her.
    5. Stellen Sie die VMFS-Datenspeicher wieder her.
    6. Registrieren Sie die virtuellen Maschinen erneut.

  • Wenn Sie einen ESXi-Host nach einem erfolgreichen Upgrade auf Version 4.1 neu starten, wird eine Fehlermeldung angezeigt
    Wenn Sie den ESXi-Host nach einem erfolgreichen Upgrade, das vom Dienstprogramm "vihostupdate" ausgeführt wurde, neu starten, wird möglicherweise die folgende Fehlermeldung angezeigt: Das neue Upgrade-Image ist offenbar beschädigt, das Upgrade schlägt möglicherweise fehl.

    Dies tritt nur bei einem Upgrade von der ESXi-Version 4.0 oder 4.0 U1 auf die Version 4.1 auf. Dies gilt nicht für Upgrades von der Version 4.0 U2.

    Umgehung: Sie können diese Fehlermeldung ignorieren und mit dem Neustart fortfahren. Das Upgrade wird erfolgreich ausgeführt.

Netzwerkprobleme

  • Konflikte bei MAC-Adresse der virtuellen Maschine
    Jedes vCenter Server-System verfügt über eine vCenter Server-Instanz-ID. Diese ID ist eine Zahl zwischen 0 und 63, die während der Installation per Zufallsgenerator erzeugt wird, aber nach der Installation neu konfiguriert werden kann.

    vCenter Server verwendet die vCenter-Instanz-ID zum Generieren von MAC-Adressen und UUIDs für virtuelle Maschinen. Wenn zwei vCenter Server-Systeme über dieselbe vCenter-Instanz-ID verfügen, generieren Sie möglicherweise identische MAC-Adressen für virtuelle Maschinen. Dies kann zu Konflikten führen, wenn sich die virtuellen Maschinen auf demselben Netzwerk befinden, was Paketverluste und andere Probleme zur Folge hat.

    Umgehung: Wenn Sie virtuelle Maschinen von mehreren vCenter Server-Systemen auf demselben Netzwerk bereitstellen, müssen Sie sicherstellen, dass diese vCenter Server-Systeme über eindeutige Instanz-IDs verfügen.

    So zeigen Sie die vCenter Server-Instanz-ID an oder ändern sie:

    1. Melden Sie über den vSphere-Client am vCenter Server an und wählen Sie Verwaltung > vCenter Server-Einstellungen.
    2. Wählen Sie "Laufzeiteinstellungen".
      Das Textfeld "Eindeutige vCenter Server-ID" zeigt die aktuelle vCenter Server-Instanz-ID an.
    3. Wenn diese ID nicht eindeutig ist, geben Sie einen neuen Wert zwischen 0 und 63 in das Textfeld "Eindeutige vCenter Server-ID" ein und klicken Sie auf OK.
    4. Wenn Sie die vCenter Server-Instanz-ID geändert haben, müssen Sie vCenter Server neu starten, damit die Änderung wirksam wird.

    Wenn es vorhandene virtuelle Maschinen mit in Konflikt stehenden MAC-Adressen gibt, ändern Sie die MAC-Adressen, damit sie eindeutig sind:

    1. Stellen Sie sicher, dass die virtuelle Maschine ausgeschaltet ist.
    2. Klicken Sie mit der rechten Maustaste in der Bestandsliste des vSphere-Clients auf die virtuelle Maschine und wählen Sie Einstellungen bearbeiten.
    3. Wählen Sie auf der Registerkarte "Hardware" den virtuellen Netzwerkadapter für die virtuelle Maschine aus.
    4. Wählen Sie unter "MAC-Adresse" die Option Manuell aus und geben Sie eine eindeutige MAC-Adresse ein.
    5. Klicken Sie auf OK.

    Alternativ können Sie vCenter Server so einstellen, dass eine neue MAC-Adresse für den virtuellen Netzwerkadapter generiert wird. Konfigurieren Sie dazu den virtuellen Netzwerkadapter so, dass er eine manuelle MAC-Adresse verwendet, und ändern Sie anschließend die Konfiguration in "Automatisch".

  • Das Hinzufügen mehrerer Hosts an einem Cisco Nexus 1000v Switch im Batch-Modus schlägt möglicherweise fehl
    Wenn Sie versuchen, mehrere Hosts mit unterschiedlichen Patch- oder Update-Levels zu einem Cisco Nexus 1000v Switch hinzuzufügen, schlägt der Vorgang "Hosts hinzufügen" fehl.

    Umgehung: Fügen Sie Hosts mit unterschiedlichen Patch- bzw. Update-Levels einem Switch einzeln hinzu.

  • Virtuelle Maschinen verlieren die Netzwerkverbindung nach dem Hinzufügen bzw. Entfernen einer vmxnet3-NIC im laufenden Betrieb mit aktiviertem Wake-On-LAN
    Die Neukonfiguration einer vmxnet3-NIC bei aktiviertem Wake-on-LAN, wenn sich die virtuelle Maschine im Ruhezustand befindet, führt dazu, dass das Gerät nicht funktioniert, was zum Verlust der Netzwerkverbindung für diese Netzwerkkarte führt.

    Umgehung: Nehmen Sie die Änderungen an der Konfiguration für die vmxnet3-NIC nur dann vor, wenn die virtuelle Maschine aktiv ist.

  • Netzwerkverbindungsausfall und Systemabsturz bei der Ausführung von Steuerungsvorgängen für physische Netzwerkkarten
    In manchen Fällen, wenn mehrere X-Frame II s2io-Netzwerkkarten denselben PCI-X-Bus verwenden, verursacht die Ausführung von Steuerungsvorgängen für die physische Netzwerkkarte, wie z. B. das Ändern der MTU, eine Trennung der Netzwerkverbindung und einen Systemabsturz.

    Umgehung: Vermeiden Sie, mehrere X-Frame II s2io NICs in Steckplätze zu stecken, die sich denselben Pci-x-Bus teilen. Falls eine solche Konfiguration unumgänglich ist, vermeiden Sie es Kontrollvorgänge an physischen Netzwerkkarten durchzuführen, während in den virtuellen Maschinen Netzwerk-E/A-Vorgänge stattfinden.

  • Es treten Arbeitsspeicherprobleme auf, wenn ein Host mehr als 1016 dvPorts an einem vDS verwendet
    Die maximal zulässige Anzahl an dvPorts pro Host am vDS ist zwar 4096, es kann aber zu Arbeitsspeicherproblemen kommen, sobald die Zahl der dvPorts für einen Host sich 1600 nähert. Ist dies der Fall, können keine virtuellen Maschinen bzw. virtuellen Adapter mehr zum vDS hinzugefügt werden.

    Umgehung: Konfigurieren Sie eine Maximalzahl von 1016 dvPorts pro Host an einem vDS.

  • Klonvorgang für eine virtuelle Maschine mit ungültigem vDS-Backing schlägt fehl
    Wenn einer der Netzwerkadapter einer virtuellen Maschine mit einem ungültigen oder fehlenden vDS bzw. einer ungültigen dvPort-Gruppe verbunden ist, kann diese virtuelle Maschine nicht geklont werden.

    Umgehung: Stellen Sie sicher, dass alle Netzwerkadapter der virtuellen Maschine ein gültiges Backing haben, bevor die virtuelle Maschine geklont wird.

  • Kürzlich hinzugefügte Benutzer mit der Nur-Lesen-Rolle dürfen VMkernel-Netzwerkkarten zu ESX/ESXi-Hosts hinzufügen
    Kürzlich hinzugefügte Benutzer mit der Nur-Lesen-Rolle dürfen keine Änderungen an der Konfiguration von ESX/ESXi-Hosts vornehmen. Ausgenommen hiervon ist das Hinzufügen von VMkernel-Netzwerkkarten, das derzeit möglich ist.

    Umgehung: Keine. Verlassen Sie sich nicht auf dieses Verhalten, da Nur-Lesen-Benutzer künftig keine VMkernel-Netzwerkkarten mehr hinzufügen können.

  • Der Löschvorgang schlägt auf virtuellen Maschinen mit ungültigem vDS-Backing fehl
    Wenn eines der Geräte einer virtuellen Maschine mit einem ungültigen vDS verbunden ist, kann es sein, dass ein Löschvorgang nicht erfolgreich abgeschlossen wird. Die virtuelle Maschine wird auf dem Host gelöscht, verbleibt aber in der Bestandsliste des vSphere-Clients.

    Umgehung: Entfernen Sie die virtuelle Maschinen aus der vCenter-Bestandsliste, indem Sie mit der rechten Maustaste auf die einzelne virtuelle Maschine klicken und Aus Bestandsliste entfernen wählen.

  • Beim Weiterleiten von Datenpaketen (Traffic-Forwarding) virtueller Maschinen mit aktivierter LRO kann es zu TCP-Performance-Problemen kommen
    Einige Linux-Module können LRO-generierte Pakete nicht handhaben. Infolgedessen kann es zu TCP-Performance-Problemen bei einer Datenverkehr weiterleitenden virtuellen Maschine kommen, wenn LRO an einem VMXNET-2- bzw. VMXNET-3-Gerät aktiviert und Linux als Gastbetriebssystem ausgeführt wird. Bei diesen Geräten ist LRO standardmäßig aktiviert.

    Umgehung: Konfigurieren Sie für Datenverkehr weiterleitende virtuelle Maschinen mit Linux-Gastbetriebssystemen den Modulladezeit-Parameter für die VMXNET 2- bzw. VMXNET 3-Linux-Treiber so, dass disable_lro=1 verwendet wird.

Speicherprobleme

  • Virtuelle Maschinen werden möglicherweise schreibgeschützt, wenn sie auf einem iSCSI-Datenspeicher mit EqualLogic-Speicher laufen
    Virtuelle Maschinen werden möglicherweise auf schreibgeschützt gesetzt, wenn Sie ein EqualLogic-Array mit einer älteren Firmware-Version verwenden. Die Firmware verliert gelegentlich E/A aus der Array-Warteschlange, was die virtuellen Maschinen veranlasst, die E/A als fehlgeschlagen zu kennzeichnen und auf Nur-Lesen zu wechseln.

    Umgehung: Aktualisieren Sie die EqualLogic Array Firmware auf Version 4.1.4 oder höher.

  • Nach dem Aktualisieren des Speicher-Arrays wechselt der Status der Hardwarebeschleunigung im vSphere-Client nach kurzer Verzögerung auf "unterstützt"
    Beim Aktualisieren der Firmware eines Speicher-Arrays auf eine Version, die die VAAI-Funktionalität unterstützt, registriert vSphere 4.1 die Änderung nicht sofort. Der vSphere-Client zeigt vorübergehend "Unbekannt" als Status für die Hardwarebeschleunigung an.

    Umgehung: Diese Verzögerung ist unbedenklich. Der Status der Hardwarebeschleunigung ändert sich nach kurzer Zeit auf "Unterstützt".

  • Große Anzahl Speicher-relevanter Meldungen in der Protokolldatei des vmkernel
    Wenn ESX bzw. ESXi auf einem Host mit mehreren physischen Pfaden zu Speichergeräten startet, zeichnet die vmkernel-Protokolldatei eine große Anzahl von Speicher-relevanten Meldungen ähnlich der Folgenden auf:

    Nov 3 23:10:19 vmkernel: 0:00:00:44.917 cpu2:4347)Vob: ImplContextAddList:1222: Vob add (@&!*@*@(vob.scsi.scsipath.add)Add path: %s) failed: VOB context overflow

    Das System protokolliert mitunter ähnliche Meldungen beim erneuten Prüfen des Speichers. Die Meldungen stellen das erwartete Verhalten dar und sind kein Hinweis auf einen Fehler. Sie sind unbedenklich und können ignoriert werden.

    Umgehung: Wenn Sie die Meldungen nicht sehen möchten, schalten Sie die Protokollierung aus.

  • Dauerhafte Reservierungskonflikte auf gemeinsam genutzten LUNs können zum verlangsamtem Starten von ESX- und ESXi-Hosts führen
    Es kann zu bedeutenden Verzögerungen beim Starten der Hosts kommen, die LUNs auf einem SAN gemeinsam nutzen. Das kann seine Ursache in Konflikten zwischen den LUN SCSI-Reservierungen haben.

    Umgehung: Um das Problem zu lösen und den Startvorgang zu beschleunigen, ändern Sie den Wert für die Zeitüberschreitung für synchrone Befehle während des Startvorgangs auf 10 Sekunden. Setzen Sie dazu den Parameter Scsi.CRTimeoutDuringBoot auf 10000.

    So Ändern Sie den Parameter vom vSphere-Client aus:

    1. Wählen Sie im Bestandslistenfenster des vSphere-Clients den Host, klicken Sie auf die Registerkarte Konfiguration und anschließend unter "Software" auf Erweiterte Einstellungen.
    2. Wählen Sie SCSI.
    3. Ändern Sie den Wert von Scsi.CRTimeoutDuringBoot auf 10000.
Serverkonfigurationsprobleme

  • Nach dem Aktualisieren der Richtlinie PnicsByName im Profil DvsProfile schlagen das Übernehmen von Profilen und das Prüfen der Profilübereinstimmung in Hostprofilen fehl
    Nach dem Aktualisieren der Richtlinie PnicsByName im Profil DvsProfile schlägt die Überprüfung der Anwendungen und der Richtlinieneinhaltung in Hostprofilen fehl. Dieses Problem tritt auf, wenn mehrere physische Netzwerkkarten eingegeben werden. Obwohl die Benutzerschnittstelle mehrere physische Netzwerkkarten ermöglicht, kann nur eine physische Netzwerkkarte für die PnicsByName-Richtlinie im DvsProfile hinzugefügt werden.

    Umgehung: Stellen Sie sicher, dass nur eine physische Netzwerkkarte für diese Richtlinie hinzugefügt wird.

Probleme bei vCenter Server und dem vSphere-Client

  • Performance-Daten älter als ein Tag stehen für einige Elemente nicht zur Verfügung, wenn vCenter Server auf die Verwendung von DB2 konfiguriert wurde
    Performance-Daten älter als ein Tag stehen für einige Elemente nicht zur Verfügung, wenn vCenter Server auf die Verwendung von DB2 konfiguriert wurde.

    HINWEIS: Arbeitsspeicher wird über den Parameter UTIL_HEAP_SZ zugeteilt. Der Parameter kann verwendet werden, um die Arbeitsspeicherzuteilung für DB2 zu erhöhen. Setzen Sie diaglevel auf 3 herab, um die Größe von diag.log zu reduzieren und die Generierung übermäßig großer Protokolldateien zu verhindern. Dies ermöglicht DB2, Aufgaben im Hintergrund zu verarbeiten. Weitere Informationen zu DB2-spezifischen Parametern finden Sie unter http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.admin.doc/doc/c0005389.htm.

    Umgehung: Wenn Sie DB2 in der Version 9.5 einsetzen, aktualisieren Sie auf DB2 9.5 Fix Pack 5.

  • Hot-Plug-Vorgänge schlagen nach dem Verlagern der Auslagerungsdatei fehl
    Hot-Plug-Vorgänge schlagen bei eingeschalteten virtuellen Maschinen in einem DRS-Cluster bzw. auf einem eigenständigen Host mit der Fehlermeldung Ziel konnte nicht fortgesetzt werden; VM wurde nicht gefunden fehl, nachdem der Speicherort der Auslagerungsdatei geändert wurde.

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

    • Starten Sie die betroffenen virtuellen Maschinen neu, um den neuen Speicherort der Auslagerungsdatei für diese Maschinen zu registrieren, und führen Sie anschließend die Hot-Plug-Vorgänge aus.
    • Migrieren Sie die betroffenen virtuellen Maschinen mithilfe von vMotion.
    • Halten Sie die betroffenen virtuellen Maschinen an.

  • Zeichen mit Akzenten und zusammengesetzte Zeichen werden im Index der französischen Online-Hilfe nicht angezeigt
    Zeichen mit Akzenten und zusammengesetzte Zeichen, wie z. B. Æ und Œ werden in den Indexeinträgen der französischen Sprachversionen der Online-Hilfe von vSphere-Client, der Online-Hilfe zu DRS-Fehlerbehebung, der Hilfe zu den Überblicksleistungsdiagrammen und der Online-Hilfe für den Webzugriff nicht angezeigt.

    Umgehung: Keine.

  • Unter Windows Vista wird immer die Standard-Hilfeseite von Update Manager geöffnet, wenn man auf einer Schaltfläche für die kontextbezogene Hilfe klickt
    Wenn Sie auf einer Windows Vista Maschine den Internet Explorer 7-Browser verwenden, wird die kontextbezogene Hilfe von vCenter Update Manager nicht angezeigt. Stattdessen wird die Seite "Einführung in Update Manager" angezeigt.

    Umgehung: Installieren Sie Service Pack 2 für Windows Vista. Weitere Informationen finden Sie im folgenden Microsoft Knowledgebase-Artikel http://support.microsoft.com/kb/942172.

  • Fehler beim Laden der Leistungsdiagrammdaten, wenn vCenter Server eine benutzerdefinierte SQL Server-Datenbank verwendet, für die einen benutzerdefinierten JDBC-Port konfiguriert wurde
    Wenn eine benutzerdefinierte SQL Server-Instanz mit vCenter Server installiert wird und diese für die Verwendung eines benutzerdefinierten JDBC-Port konfiguriert wurde, zeigt das System die Fehlermeldung Bei den Leistungsdiagrammen ist ein interner Fehler aufgetreten statt der Diagrammdaten an.

    Umgehung:

    1. Navigieren Sie im vCenter Server-System zu C:\Dokumente und Einstellungen\Alle Benutzer\Anwendungsdaten\VMware\VMware VirtualCenter.
    2. Öffnen Sie die Datei vcdb.properties.
    3. Kommentieren Sie die Zeichenfolge usevcdb = true aus.
    4. Stellen Sie sicher, dass die Werte für "url", "driver" und "dbtype" wie folgt lauten:
      url = jdbc:sqlserver://:;integratedSecurity=true
      driver = com.microsoft.sqlserver.jdbc.SQLServerDriver
      dbtype = mssql
    5. Setzen Sie den Parameter integratedSecurity auf true, wenn die Datenbank sich auf einer lokalen Maschine bzw. auf false, wenn sie sich auf einer Remotemaschine befindet.
    6. Starten Sie den Service "VMware VirtualCenter Management WebServices" neu.

     

    HINWEIS: Das Problem tritt nicht auf bei Oracle- oder DB2-Datenbanken, die mit benutzerdefinierten JDBC-Ports konfiguriert sind.

  • Das Datenspeicher-Leistungsdiagramm zeigt falsche Daten an
    Wenn Sie die Registerkarte Leistung in der Bestandslistenansicht des vSphere-Client-Datenspeichers öffnen, zeigt die Registerkarte vier Diagramme an. Die Titel dieser Diagramme sind nicht korrekt; sie müssen wie folgt lauten:

    • Max. Gerätelatenz pro Host
    • Max. Warteschlangentiefe pro Host
    • Anzahl der Lesevorgänge pro Host
    • Anzahl der Schreibvorgänge pro Host

    In einigen Fällen kann es sein, dass die Plots möglicherweise nicht alle Hosts anzeigen. Dies ist ein bekanntes Problem.

    Umgehung: Um die richtigen Daten für jeden zu dem Datenspeicher gehörenden Host zu betrachten, wechseln Sie zur Bestandslistenansicht "Hosts und Cluster", wählen die Registerkarte Leistung aus und betrachten den entsprechenden Indikator.

  • Probleme bei der Installation und beim Ausführen von vCenter Server, VMware Update Manager bzw. VMware Converter auf einem Betriebssystem mit tschechischem Gebietsschema
    Wenn Sie versuchen, vCenter Server, Update Manager oder VMware Converter auf einem Betriebssystem mit tschechischem Gebietsschema zu installieren, können Sie das Produkt nicht installieren oder sie haben funktionale Probleme beim Versuch, das Produkt zu verwenden.

    Umgehung: Zurzeit gibt es keine Möglichkeit, die Probleme mit Betriebssystemen mit tschechischem Gebietsschema zu umgehen. Verwenden Sie das Betriebssystem mit einem englischen Gebietsschema, um das Produkt zu testen.

  • Fehler beim Versuch, einer Instanz von vCenter Server beizutreten, die auf einem System gehostet wird, auf dem Windows Server 2008 mit aktivierter Benutzerkontensteuerung ausgeführt wird, die für eine Gruppe im verknüpften Modus aktiviert ist
    Wenn Sie einem Windows Server 2008 System beitreten oder ein Windows Server 2008 System isolieren, das über eine Benutzerkontensteuerung (UAC, User Account Control) für eine Gruppe im verknüpften Modus verfügt, schlägt der Vorgang ohne Fehlermeldung fehl.

    Umgehung: Führen Sie die folgenden Schritte aus:

    1. Schalten Sie die Benutzerkontensteuerung (UAC) vor dem Beitreten einer Gruppe im verknüpften Modus wie folgt aus:
      1. Öffnen Sie die Windows Systemsteuerung.
      2. Wählen Sie Start > Einstellungen > Systemsteuerung > Benutzerkonten.
      3. Klicken Sie auf Benutzerkontensteuerung ein- oder ausschalten.
      4. Deaktivieren Sie die Option Benutzerkontensteuerung verwenden, um zum Schutz des Computers beizutragen und klicken Sie auf OK.
      5. Starten Sie den Computer neu.

      2.  

    2. Starten Sie die Konfiguration für den verknüpften Modus wie folgt:
      1. Wählen Sie Start > Alle Programme > VMware > vCenter Server-Konfiguration für den verknüpften Modus und klicken Sie auf Weiter.
      2. Wählen Sie Konfiguration für den verknüpften Modus ändern und klicken Sie auf Weiter.
      3. 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.
      4. Geben Sie den Servernamen und die Informationen für den LDAP-Port an und klicken Sie auf Weiter.
      5. Klicken Sie auf Beenden.
      6. Klicken Sie auf Fortfahren und befolgen Sie die Installationsanweisungen.

      3.  

    3. Melden Sie sich bei einem der vCenter Server-Systeme an und vergewissern Sie sich, dass die Server verknüpft sind.
    4. Sind die vCenter Server verknüpft, schalten Sie die UAC ein.
      1. Wählen Sie Start > Einstellungen > Systemsteuerung > Benutzerkonten.
      2. Wählen Sie Benutzerkontensteuerung ein- oder ausschalten.
      3. Aktivieren Sie die Option Benutzerkontensteuerung verwenden, um zum Schutz des Computers beizutragen und klicken Sie auf OK.
      4. Starten Sie den Computer neu.

      5.  

  • Es tritt ein Fehler auf beim Versuch, den VMware VirtualCenter-Service bzw. den VMware-Webservice von der Windows Systemsteuerung aus neu zu starten
    Während Sie versuchen, den VMware VirtualCenter-Service bzw. den VMware-Webservice von der Windows-Systemsteuerung aus neu zu starten, wird folgende Fehlermeldung angezeigt:
    Fehler 1053: Der Dienst antwortete nicht rechtzeitig auf Anforderungen zum Starten oder Beenden.

    Umgehung: Ändern Sie zwei Registrierungsschlüsssel für den betroffenen vCenter Server-Host wie folgt:

    1. Starten Sie "regedit" und suchen Sie den folgenden Schlüssel in der Registrierung:

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\vctomcat\Parameters

    2. Fügen Sie folgende (DWORD-) Registrierungswerte hinzu:

      Wertname: WaitHintStart
      Wert: < Wartezeit zum Starten des Services in Millisekunden>

      Wertname: WaitHintStop
      Wert: < Wartezeit zum Stoppen des Services in Millisekunden>

      In beiden Fällen muss die Wartezeit größer als 40 Sekunden sein.

    3. Suchen Sie den folgenden Schlüssel in der Registrierung:

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\vpxd\Parameters

    4. Fügen Sie folgende (DWORD-) Registrierungswerte hinzu:

      Wertname: WaitHintStart
      Wert: < Wartezeit zum Starten des Services in Millisekunden>

      Wertname: WaitHintStop
      Wert: < Wartezeit zum Stoppen des Services in Millisekunden>

      In beiden Fällen muss die Wartezeit größer als 40 Sekunden sein.

  • Das Ändern der Netzwerkeinstellungen eines ESXi-Hosts verhindert, dass manche Software zur Überwachung des Hardwarestatus den Host automatisch erkennen kann
    Nach dem Ändern der Netzwerkeinstellungen eines 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 und dynamisch zu erkennen.

    Umgehung: Geben Sie den Hostnamen oder die IP-Adresse des Hosts manuell in das Drittanbieter-Management-Tool ein. Alternativ können Sie slpd und sfcbd-watchdog neu starten, indem Sie eine der folgenden Methoden verwenden:

    • Aktivieren Sie den Technical Support-Modus und führen Sie die folgenden Befehle aus:

      • /etc/init.d/slpd restart
      /etc/init.d/sfcbd-watchdog restart
    • 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.

  • Bei Verwendung von DB2, startet der vCenter Server-Service nicht automatisch neu, nachdem die Netzwerkverbindung wiederhergestellt wurde
    Wenn Sie eine Netzwerkverbindung zu einem vCenter Server-System verlieren, das mit einer IBM DB2 Datenbank konfiguriert ist, können Sie den vCenter Server-Service nach dem Wiederherstellen der Netzwerkverbindung nicht neu starten.

    Umgehung:

    1. Schließen Sie alle bestehenden Verbindungen in der vCenter Server-Maschine zu der IBM DB2-Datenbank mithilfe des Dienstprogramms "Anwendungsliste".
    2. Melden Sie sich an der DB2 UDB Datenbank als dbadm, als Besitzer der Instanz oder als Besitzer der Datenbank an.
    3. Führen Sie den folgenden Befehl aus, um Informationen über den Benutzer zu erhalten, den Sie von der Datenbank abmelden möchten: db2 list applications

      Es erscheint eine Meldung ähnlich der Folgenden:
      Auth Id         Application     Appl.           Application Id
                      Name            Handle
      --------        --------------  ----------      --------------------------
      VPX             db2bp.exe       3428            *LOCAL.DB2.100225221240
    4. Beachten Sie die Nummer "application handle" und verwenden Sie sie, um den folgenden Trennbefehl auszugeben: force application <application handle-Nummer>
Migrationsprobleme

  • Migrieren einer ausgeschalteten oder angehaltenen virtuellen ESX 3.x-Maschine mit Snapshots auf einen anderen Datenspeicher macht die virtuelle Zielmaschine möglicherweise unbrauchbar
    Wenn Sie versuchen, eine abgeschaltete oder angehaltene virtuelle ESX 3.x Maschine mit Snapshots auf einen anderen Datenspeicher zu migrieren, wird möglicherweise die folgende Warnmeldung angezeigt:
    Diese virtuelle Maschine verfügt über Snapshots. Das Verschieben auf einen anderen Datenspeicher macht die virtuelle Maschine möglicherweise unbrauchbar. Suchen Sie in der VMware-Knowledgebase nach weiterführenden Informationen.

    Nachdem Sie die Migration der virtuellen Maschine abgeschlossen haben, sehen Sie möglicherweise folgende Fehlermeldung bei dem Versuch, die virtuelle Maschine einzuschalten:
    Datei wurde nicht gefunden

    Umgehung: Weitere Informationen finden Sie unter KB 1020709.

  • Nachdem eine virtuelle Maschine migriert wurde, werden USB-Geräte auf dem Zielhost fälschlicherweise als der virtuellen Maschine zugewiesen angezeigt
    Nachdem Sie eine virtuelle Maschine mit den USB-Geräten, die mit dem Host verbunden sind, migriert haben und anschließend weitere USB-Geräte der migrierten virtuellen Maschine auf dem Zielhost hinzugefügt haben, erscheinen die USB-Geräte auf dem Zielhost möglicherweise als der virtuellen Maschine zugewiesen, obwohl sie ihr nicht zugewiesen sind.

    Umgehung: Weisen Sie die USB-Geräte einer lokalen virtuellen Maschine zu, die nicht von einem anderen Host migriert wurde, um zu verhindern, dass sie als der migrierten Maschine zugewiesen erscheinen. Es gibt keine Umgehung, um zu verhindern, dass diese Geräte der migrierten virtuellen Maschine zugewiesen werden.

VMware HA- und Fehlertoleranzprobleme

  • Der ESXi-Host meldet möglicherweise VMware HA-Fehler, wenn er innerhalb von 10 Minuten nach der HA-Konfiguration neu gestartet wird
    Beim Beibehalten des HA-Status liegt ein logischer Fehler vor. Wenn der Host kurz nach Abschluss der HA-Konfiguration neu gestartet wird, findet er die Cluster-Konfigurationsinformationen nicht und kann den HA-Agenten nicht starten.

    Umgehung: Warten Sie nach der Fertigstellung der HA-Konfigurationsaufgabe länger als 10 Minuten, bevor Sie den Host ausschalten.

Gastbetriebssystemprobleme

  • Das Kompilieren von VMware Kernel-Modulen wird nur für den laufenden Kernel unterstützt
    VMware unterstützt derzeit nur das Kompilieren von Kernel-Modulen für den gerade laufenden Kernel.

    Umgehung: Starten Sie den Kernel, bevor Sie Module für diesen Kernel kompilieren.

  • Die Signaturprüfung des RPM-Installationsprogramms für VMware Tools für RHEL3, RHEL4 und SLES9 schlägt beim Prüfen der Paketsignatur fehl
    Wenn Sie das RPM-Installationsprogramm verwenden, um VMware Tools für RHEL3, RHEL4 und SLES9 zu installieren, schlägt die Signaturprüfung mit der folgenden Fehlermeldung fehl V3 RSA/MD5 Signatur: NOKEY, Schlüssel-ID 66fd4949. Das Problem tritt auf, da ältere RPM-Versionen keine RSA-Signaturen prüfen können, die von neueren RPM-Versionen erzeugt wurden. Der Wegfall der Prüfung der Paketsignatur verhindert nicht, dass VMware Tools die Installation erfolgreich abschließt.

    Umgehung: Verwenden Sie RPM 4.4.2 oder höher zur Prüfung der Pakete.

  • Die Installation von Betriebssystem-spezifischen Paketen (OSPs) von VMware Tools auf SUSE Linux 9 führt zu einem Fehler bei der Bildschirmauflösung
    Wenn Sie die VMware Tools OSP in SUSE Linux 9 installieren, konfiguriert das Betriebssystem die Datei des X Window-Systems /etc/X11/XF86Config und ersetzt den Vesa-Videotreiber durch den VMware Videotreiber. Wenn Sie einen vom Vesa-Treiber abweichenden Videotreiber verwenden, ersetzt VMware Tools OSP diesen nicht. Versuche, die Bildschirmauflösung mithilfe der grafischen Benutzeroberfläche oder dem Linux-Befehl xrandr zu ändern, schlagen fehl.

    Umgehung: Um den VMware-Videotreiber zu verwenden, müssen Sie die Datei /etc/X11/XF86Config bearbeiten.

    1. Melden Sie sich im X Window-System als "root" an und bearbeiten Sie die Datei /etc/X11/XF86Config.
    2. Suchen Sie den Geräteabschnitt.
    3. Suchen Sie den Treibereintrag oder erstellen Sie den Eintrag, wenn er nicht existiert.
    4. Legen Sie den Treibereintrag auf vesa fest.
      Nach der Änderung erscheint der Treiber im Geräteabschnitt als Treiber vesa.
    5. Starten Sie das X Window-System neu, um die Änderungen zu speichern und die neuen Einstellungen zu übernehmen.

  • Das Installieren der VMware Tools OSP-Pakete auf SLES 11-Gastbetriebssystemen produziert die Fehlermeldung "Pakete nicht unterstützt"
    Die Installation von VMware Tools OSP-Pakten in einem SUSE Linux Enterprise Server 11 Gastbetriebssystem produziert die Fehlermeldung, Die folgenden Pakete werden von ihrem Anbieter nicht unterstützt.

    Umgehung: Ignorieren Sie die Meldung. Die OSP-Pakete enthalten keine Kennzeichnung, die sie als vom Anbieter unterstützt markiert. Die Pakete werden dennoch unterstützt.

  • Das Gastbetriebssystem antwortet nach dem Vergrößern des Arbeitsspeichers im Hot-Add-Modus (Vergrößern des Arbeitsspeichers im laufenden Betrieb) von weniger als 3 GB auf mehr als 3 GB nicht mehr
    Das Redhat5.4-64-Gastbetriebssystem antwortet möglicherweise nicht mehr, wenn es mit einem verbundenen IDE-Gerät gestartet wird und der Arbeitsspeicher von weniger als 3 GB auf mehr als 3 GB im Hot-Add-Modus vergrößert wird.

    Umgehung: Verwenden Sie nicht die Funktion "hot-add" zum Ändern der Größe der virtuellen Maschine von kleiner gleich 3072 MB auf über 3072 MB. Schalten Sie die virtuelle Maschine aus, um diese Neukonfiguration durchzuführen.

    Wenn das Gastbetriebssystem bereits nicht mehr antwortet, starten Sie die virtuelle Maschine neu. Das Problem tritt nur auf, wenn die 3-GB-Marke beim laufenden Betriebssystem überschritten wird.

  • Installationsfehler auf dem Windows NT-Gastbetriebssystem bei einer virtuellen Maschine mit Hardwareversion 7
    Wenn Sie Windows NT 3.51 in einer virtuellen Maschine mit der Hardwareversion 7 installieren, friert der Installationsvorgang ein. Das geschieht unmittelbar nach dem Erscheinen des blauen Startbildschirm, der bei Windows NT Version 3.51 angezeigt wird. Dies ist ein bekanntes Problem beim Windows NT 3.51 Kernel. Die virtuellen Maschinen der Hardwareversion 7 verfügen über mehr als 34 PCI-Busse und der Windows NT-Kernel unterstützt Hosts mit einer Obergrenze von 8 PCI-Bussen.

    Umgehung: Wenn es sich um eine Neuinstallation handelt, löschen Sie die vorhandene virtuelle Maschine und erstellen Sie eine neue. Bei der Erstellung der virtuellen Maschine wählen Sie Hardwareversion 4. Sie müssen den Assistenten für neue virtuelle Maschinen zum Auswählen eines benutzerdefinierten Pfads verwenden, um die Hardwareversion ändern zu können.

    Wenn Sie die virtuelle Maschine mit Hardwareversion 4 erstellt und auf Hardwareversion 7 aktualisiert haben, verwenden Sie den VMware vCenter Converter zum Herabstufen der virtuellen Maschine auf Hardwareversion 4.

Probleme bei unterstützter Hardware

  • Neu: Die Installation oder das Upgrade schlägt auf ESX-/ESXi-Hosts, die mit HP NC522SFP-Netzwerkkarten ausgerüstet sind, mit einem violetten Diagnosebildschirm fehl
    Auf einigen ESX-/ESXi-Hosts, die mit NC522SFP-Netzwerkkarten ausgerüstet sind, kann der mitgelieferte NetXen-Treiber die Firmware nicht laden, wodurch der Host während der ESX-/ESXi-Installation oder des Upgrade-Vorgangs mit einem violetten Diagnosebildschirm fehlschlägt. Der Host zeigt eine Meldung ähnlich der Folgenden an: 32.networking-drivers werden geladen.

    Umgehung: Führen Sie je nach Konfiguration das für Sie zutreffende Verfahren durch:

    • ESX. Wenn Sie während der Installation oder des Upgrades nach dem Treiber gefragt werden, installieren Sie den auf dieser Seite bereitgestellten async-Treiber: VMware ESX/ESXi 4.0 Treiber-CD für QLogic Intelligent Ethernet-Adapter. Sie sollten die Treiberversion 507 oder höher auswählen.

    • ESXi Embedded. Ein benutzerdefiniertes System-Image mit dem korrekten Treiber erhalten Sie von Ihrem Hostanbieter.

    • ESXi Installable. ESXi Installable unterstützt die NC522SFP-Karte nur dann, wenn der Host über mindestens eine andere Netzwerkkarte eines anderen Typs verfügt. Wenn Ihr Host dieses Kriterium erfüllt, führen Sie diese Schritte aus:

      1. Deaktivieren Sie die NC522SFP-Netzwerkkarte oder entfernen Sie sie vom Host.
      2. Installieren oder aktualisieren Sie ESXi Installable auf dem Host.
      3. Installieren Sie nach Beendigung der Installation oder des Upgrades den async-Treiber, der auf dieser Seite bereitgestellt wird: VMware ESX/ESXi 4.0 Treiber-CD für QLogic Intelligent Ethernet-Adapter. Sie sollten die Treiberversion 507 oder höher auswählen.
      4. Reaktivieren Sie die NC522SFP-Netzwerkkarte auf dem Host oder installieren Sie sie neu.

      Falls Ihr ESXi Installable-Host über keine andere Netzwerkkarte als die NC522SFP-Karte verfügt, kann dieses Problem nicht umgangen werden.

    Siehe auch KB 1026431.

  • PCI-Geräte-Zuordnungsfehler bei 370 G6 HP Server
    Wenn Sie E/A-Vorgänge auf dem 370 G6 HP Server durchführen, wird möglicherweise ein violetter Bildschirm oder es werden Warnungen zu "Lint1 Interrupt" bzw. NMI in der Konsole angezeigt. Der HP ProLiant DL370 G6 Server verfügt über zwei Intel I/O Hubs (IOH) und hat einen BIOS-Defekt in den Strukturdefinitionen des ACPI Direct Memory Access Remapping (DMAR). Dies führt bei einigen PCI-Geräten dazu, dass sie unter der falschen DMA-Remapping-Einheit nicht korrekt beschrieben werden. Jeder DMA-Zugriff durch solche falsch beschriebenen PCI-Geräte löst einen IOMMU-Fehler aus und das Gerät empfängt einen E/A-Fehler. Je nach Gerät führt dieser E/A-Fehler möglicherweise zu einem Lint1-Interrupt oder zu einer NMI-Warnmeldung in der Konsole oder das System friert mit einem violetten Bildschirm ein.

    Umgehung: Prüfen Sie auf der HP-Website, ob ein BIOS-Patch für den HP ProLiant DL370 G6 Server verfügbar ist. Wenn kein Patch verfügbar ist, deaktivieren Sie "Intel(R) VT-d" im BIOS, sodass das BIOS die DMAR-Strukturen nicht in den ACPI-Tabellen veröffentlicht.

  • ESXi-Installationen auf HP-Systemen benötigen den HP-NMI-Treiber
    ESXi 4.1-Instanzen auf HP-Systemen benötigen den HP-NMI-Treiber, um die ordnungsgemäße Verarbeitung von Non-maskable Interrupts (NMIs) sicherzustellen. Der NMI-Treiber stellt sicher, dass NMIs korrekt erkannt und protokolliert werden. Ohne diesen Treiber werden NMIs, die Hardware-Fehler signalisieren, auf HP-Systemen mit ESXi ignoriert.

    VORSICHT: Wenn dieser Treiber bei der Installation nicht installiert wird, führt dies möglicherweise unbemerkt zur Datenbeschädigung.

    Umgehung: Laden Sie den NMI-Treiber herunter und installieren Sie ihn. Der Treiber steht als Offline-Paket auf der HP-Website zur Verfügung. Siehe auch KB 1021609.

Internationalisierungsprobleme

  • Dropdown-Menüelemente für den DRS-Regel-Benutzerschnittstellenbildschirm falsch übersetzt.
    Wenn Sie mithilfe einer Benutzerschnittstelle in einer anderen Sprache als Englisch eine VM/Host-DRS-Regel erstellen, sind die Dropdown-Listen-Optionen unverständlich.

    Umgehung: Keine.

Probleme mit der vSphere-Befehlszeilenschnittstelle

  • Gruppen-ID-Länge in vSphere-Client kürzer als Gruppen-ID-Länge in vCLI. Wenn Sie eine Gruppen-ID mithilfe des vSphere-Clients angeben, sind nur neun Zeichen erlaubt. Dagegen können Sie bis zu zehn Zeichen angeben, wenn Sie die Gruppen-ID mithilfe von vicfg-user vCLI angeben.

    Umgehung: Keine.

  • Ausführen von "resxtop" über einen längeren Zeitraum führt zu Arbeitsspeicherproblemen
    Die Arbeitsspeichernutzung durch "resxtop" erhöht sich möglicherweise mit der Zeit, je nachdem, was auf dem überwachten ESX/ESXi-System passiert. Da "resxtop" darüber hinaus auf ESXi einen zusätzlichen CPU-Verbrauch verursacht, wird empfohlen, "resxtop" nicht über einen längeren Zeitraum (d. h. mehrere Wochen) auszuführen.

    Die Gesamtanzahl an Wiederholungen auf ESXi 4.1 (-n) ist auf den Standardwert 10.000 eingestellt. Nachdem "resxtop" 10.000 Anzeigen generiert hat, beendet es sich selbst. Dies bedeutet, dass "resxtop" sich bei Verwendung einer Standardverzögerung von 5 Sekunden zwischen zwei Anzeigen möglicherweise nach etwa 14 Stunden selbst abschaltet.

    Umgehung: Obwohl Sie die Option "-n" verwenden können, um die Gesamtzahl an Wiederholungen zu ändern, ist es besser, "resxtop" nur dann auszuführen, wenn Sie die Daten benötigen. Falls Sie "resxtop"-Statistiken über einen längeren Zeitraum hinweg erfassen müssen, beenden Sie "resxtop" in regelmäßigen Abständen und starten Sie es neu, statt eine "resxtop"-Instanz über Wochen oder Monate auszuführen.

Sonstige Probleme

  • DVM/Host-DRS-Regeln werden auch noch erzwungen, nachdem DRS deaktiviert ist
    Wenn Sie eine VM/Host-DRS-Regel für einen DRS-Cluster angeben, wenn DRS deaktiviert ist, bleibt diese Regel weiter gültig. Dementsprechend tritt möglicherweise ein Fehler auf, wenn Sie eine virtuelle Maschine manuell mit dieser Art Regel einschalten und dieser Vorgang die Regel verletzt.

    Umgehung: Deaktivieren Sie die Regel im Cluster-Dialogfeld Einstellungen.