Versionshinweise zu VMware VirtualCenter 2.5 Update 3

Kontakt zum Vertrieb

Installationsprogramm für VMware Infrastructure Management | 3. Oktober 2008
VirtualCenter 2.5 Server Update 3 | 3. Oktober 2008
Virtual Infrastructure-Client | 3. Oktober 2008

 

Weitere Informationen finden Sie unter Auswählen des geeigneten Installationsprogramms für VMware Infrastructure Management.

 

Letzte Dokumentaktualisierung: 16. Oktober 2008

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

 

Diese Versionshinweise decken die folgenden Themen ab:

Hinweis: In vielen öffentlich verfügbaren Dokumenten wird auf VMware ESX Server 3.5 nun mit dem Namen VMware ESX 3.5 Bezug genommen und VMware ESX Server 3i Version 3.5 wird als VMware ESXi 3.5 bezeichnet Diese Versionshinweise folgen der bisherigen Namenskonvention, damit eine mit den Produktoberflächen und der Dokumentation konsistente Namensgebung vorliegt. In künftigen Versionen werden die Produktnamen aktualisiert.

Neuigkeiten

In dieser Version wurden mehrere Probleme behoben. Weitere Informationen finden Sie im Abschnitt Behobene Probleme.

Seitenanfang

Vorgängerversionen von VMware Infrastructure 3

Funktionen und bekannte Probleme der Vorgängerversionen von VMware Infrastructure 3, zu denen ESX Server 3.x- und VirtualCenter 2.x-Versionen zählen, werden in den jeweiligen Versionshinweisen beschrieben. Zur Anzeige der Versionshinweise für Vorgängerversionen von VMware Infrastructure 3-Komponenten klicken Sie auf einen der folgenden Links:

ESX Server-Versionen

VirtualCenter-Versionen

Seitenanfang

Bevor Sie beginnen

Hinweis: Wenn Sie diese Version von einer anderen Quelle als dem physischen DVD-Medium installieren, finden Sie im Knowledgebase-Artikel Filenames over 64 characters in ESX Server ISO image may get truncated during content extraction (KB 1005283) wichtige Informationen zu einem bekannten Installationsproblem.

Kompatibilität von ESX Server, VirtualCenter und Virtual Infrastructure-Client

Die Kompatibilitätstabellen für ESX Server, VirtualCenter und Virtual Infrastructure -Client liefern Details zur Kompatibilität aktueller und früherer Versionen von VMware Infrastructure 3-Komponenten, einschließlich ESX Server, VirtualCenter und VI-Client.

Lesen Sie vor der Installation dieser Software die Kompatibilitätshandbücher zu ESX Server. Sie müssen sicherstellen, dass Server, E/A, Speicher, Gastbetriebssystem, Verwaltungsagent und Sicherungssoftware kompatibel sind. In diesen Handbüchern finden Sie ferner Informationen zu den für diese Version geltenden Mindestanforderungen und Skalierungseinschränkungen. Klicken Sie auf einen der folgenden Links, um das entsprechende Handbuch anzuzeigen:

  • Systems Compatibility Guide for ESX Server 3.5 and ESX Server 3i ( PDF)
  • I/O Compatibility Guide for ESX Server 3.5 and ESX Server 3i ( PDF)
  • Storage/SAN Compatibility Guide for ESX Server 3.5 and ESX Server 3i ( PDF)
  • Backup Software Compatibility Guide for ESX Server 3.5 and ESX Server 3i ( PDF)

Installation und Aktualisierung

Im Installationshandbuch finden Sie Schritt-für-Schritt-Anleitungen zur Installation und Konfiguration von ESX Server und VirtualCenter.

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

Installation unter Verwendung des Installationsprogramms für VMware Infrastructure Management und physischer Medien

Neu: Bei dieser Version benötigt das Installationsprogramm für VMware Infrastructure Management ein DVD-Laufwerk, sofern Sie physische Medien zum Installieren der VMware Infrastructure-Software verwenden.

Auswählen des geeigneten Installationsprogramms für VMware Infrastructure Management

Es stehen zwei Builds vom VMware Infrastructure Management-Installationsprogramm zum Herunterladen zur Verfügung. Wählen Sie eine der folgenden Optionen:

  • VMware-VIMSetup-2.5.0-U3-English.isooder VMware-VIMSetup-2.5.0-U3-English.zip– Diese Dateien enthalten nur eine englische Version des VI-Clients, der unabhängig von der Sprache des Windows-Systems in Englisch ausgeführt wird. Mit diesem Installationsprogramm können Sie einen VI-Client installieren, der auf einer chinesischen, deutschen oder japanischen Version des Windows-Betriebssystems in Englisch ausgeführt wird.
  • VMware-VIMSetup-2.5.0-U3-localized.isooder VMware-VIMSetup-2.5.0-U3-localized.zip– Diese Dateien enthalten ein lokalisiertes Installationsprogramm, das alle zur Ausführung in Englisch, Chinesisch, Deutsch oder Japanisch erforderlichen Dateien installiert. Der zur Laufzeit verwendete VI-Client entspricht dem Gebietsschema des aktuellen Windows-Betriebssystems, wenn das Gebietsschema für Chinesisch, Deutsch oder Japanisch verwendet wird. Auf Windows-Betriebssystemen mit anderen Gebietsschemen als Chinesisch, Deutsch oder Japanisch wird die englische Version des VI-Clients verwendet.

Änderungen am Virtual Infrastructure-Client-Installationsprogramm

Das eigenständige VI-Client-Installationsprogramm (von ESX Server Web Access verfügbar) ermöglicht auch die Installation des VMware Infrastructure Update-Dienstes, der für das Aktualisieren und das Patchen von ESX Server 3i-Hosts erforderlich ist. Das eigenständige VI-Client-Installationsprogramm wurde so verbessert, dass eine optionale Installation des VMware Infrastructure Update-Dienstes möglich ist, sodass auf eine unnötige Verbreitung dieses Tools verzichtet werden kann. Beachten Sie, dass das einheitliche VirtualCenter-Installationsprogramm (verfügbar als Komponente des VirtualCenter 2.5 Update 3-Downloads) jetzt den VMware Infrastructure Update-Dienst installiert, wenn Sie die Installationsoption VI-Client wählen.

Upgrade oder Migration auf VirtualCenter 2.5 Update 3

Diese Version bietet Unterstützung für eine Aktualisierung von VirtualCenter 1.4.1, VirtualCenter 2.0.2 (einschließlich Update 1, Update 2, Update 3, Update 4 und Update 5), VirtualCenter 2.5, VirtualCenter 2.5 Update 1 oder VirtualCenter 2.5 Update 2 auf VirtualCenter 2.5 Update 3. Detaillierte Anweisungen und Richtlinien zu Upgrade und Migration finden Sie im Upgrade-Handbuch.

Hinweis:Vorgängerversionen von VMware Update Manager sind nicht mit VirtualCenter 2.5 Update 3 kompatibel und müssen während des Installationsvorgangs auf VMware Update Manager 1.0 Update 3 aktualisiert werden.

 

Plug-In-Updates

Diese Version des VMware Infrastructure 3-Softwarepakets umfasst außerdem:

Seitenanfang

 

Behobene Probleme

 

 

In dieser Version werden Probleme in den folgenden Bereichen behoben:

Sonstige Probleme

  • FLEX-Lizenzserver-Upgrade
    Diese Version von VirtualCenter aktualisiert den FLEX-Lizenzserver auf Version 10.8.6, wodurch bekannte Probleme mit Vorgängerversionen des Lizenzservers behoben und erweiterte Debugging-Funktionen zur Verfügung gestellt werden. Der neue FLEX-Lizenzserver wird im Rahmen des VMware Infrastructure Management-Installationsprogramms installiert. Neuere Installationen des Lizenzservers verwenden die neue Version, aber der Lizenzserver wird nicht automatisch aktualisiert, wenn zum Aktualisieren einer vorhandenen Installation das VMware Infrastructure Management-Installationsprogramm verwendet wird. Verwenden Sie zum Aktualisieren einer vorhandenen Lizenzserverinstallation das eigenständige Installationsprogramm ( VMware-licenseserver.exe), das sich im Ordner /vpxder Installationsverzeichnisstruktur befindet.

Sicherheit

  • WebAccess-Komponenten-JRE wurde auf Version 1.5.0_16 aktualisiert
    Die aktuell installierte Version der JRE hängt von Ihrem Patch-Bereitstellungsverlauf ab.
    Weitere Informationen über Sicherheitsprobleme, die in den Versionen 1.5.0_16 und früher behoben wurden,
    finden Sie in den JRE-Versionshinweisen unter java.sun.com/j2se/1.5.0/ReleaseNotes.html.
    Eine Liste der CVE-Bezeichner mit den in JRE 1.5.0_16 behobenen Problemen finden Sie unter Secunia Advisories an folgender Adresse: secunia.com/advisories/31010.

  • VMware VirtualCenter-Kennwort wird möglicherweise im Fehlerfenster angezeigt
    Das Problem, dass das Kennwort eines Benutzers auf dem Anmeldebildschirm in Klartext angezeigt wird, ist in dieser Version behoben. Bei der Anmeldung bei VirtualCenter Server 2.0 mit Virtual Infrastructure Client 2.5 wird das Benutzerkennwort auf dem VI-Client in einem Dialogfeld in Klartext angezeigt, falls die Anmeldung fehlschlägt. Das Dialogfeld, das den Benutzer über die fehlgeschlagene Anmeldung informiert, ist möglicherweise unter anderen Fenstern verborgen.
    Der Standard "Common Vulnerabilities and Exposures" (CVE) (cve.mitre.org) hat diesem Problem die Bezeichnung CVE-2008-4278 zugewiesen.

Serverkonfiguration

  • Benutzerdefinierte IP-Adresseinstellung für vpxa-Server funktiniert nicht
    In dieser Version ist ein Problem bei Vorgängerversionen behoben, wobei Änderungen an der <serverIP>-Option von vpxa nicht wirksam wurden. Der vpxa-Agent sendet keine Taktsignale an die in <serverIP> angegebene IP-Adresse.Stattdessen sendet er sie an die in der Host-Synchroniserung angegebene IP-Adresse.
    Ändern Sie zum Aktiveren dieser Funktion auf ESX Server 3.5 die Datei vpxa.cfg, indem Sie ihr folgende Zeile hinzufügen:
         <preserveServerIp> true </preserveServerIp>
    Wenn diese Funktion aktiviert ist, sieht die Datei vpxa.cfgähnlich dem folgenden Beispiel aus:
         <config>
              <vpxa>
                   **** vorhandener Inhalt *****
                   <preserveServerIp> true </preserveServerIp>
              </vpxa>
              **** vorhandener Inhalt *****
         </config>
  • DNS-Konfiguration des Hosts nimmt keine Domäneneinträge ohne Suffix an
    In früheren Version von VirtualCenter konnten Hosts nicht mit einem Domäneneintrag konfiguriert werden, der kein Suffix enthält. Beispiel: Ein Host namens host123 kann nicht als "host123" konfiguriert werden, vielmehr benötigte er einen Domäneneintrag wie z. B. host123.com oder host123.net. In dieser Version wird das Problem behoben, sodass Hosts mit Domäneneinträgen ohne Suffix konfiguriert werden können.

Aktualisierung und Installation

  • Das Herstellen einer Verbindung mit einem ESX Server 3.5-Host über VirtualCenter aktualisiert einen lokalisierten VI-Client nicht
    In dieser Version ist das Problem behoben, dass wenn Sie eine Verbindung mit einem ESX Server 3.5-Host über die globalisierte Version von VirtualCenter (nicht die englische Version) herstellen, der verwendete lokalisierte VI-Client nicht auf die Update 2-Version aktualisiert wird.
  • Statistikereignisse und -aufgaben werden nicht aus der Datenbank gelöscht
    Wenn in Vorgängerversionen das VMware Infrastructure Management-Installationsprogramm zum Aktualisieren einer vorhandenen VirtualCenter-Installation verwendet wurde, konnten Sie auswählen, ob die Aufgaben und Ereignisse bzw. die Leistungsdaten beibehalten werden sollen. Die Verwendung der Option zum Verwerfen der Daten führte nicht dazu, dass Daten aus der Datenbank entfernt wurden. Alle Statistikdaten wurden beibehalten. In dieser Version führt die Verwendung der Option zum Verwerfen der Daten dazu, dass die ausgewählten Daten aus der Datenbank entfernt werden.
  • VI-Client bestätigt die installierten Plug-In korrekt
    Wenn in Vorgängerversionen das Plug-In-Manager-Fenster geschlossen wird, bevor die Plug-Ins aktiviert oder vollständig installiert wurden, und wenn das Plug-In-Manager-Fenster erneut gestartet wird, werden auf der Registerkarte Installiert möglicherweise die installierten Plug-Ins nicht bestätigt und auf der Registerkarte Verfügbar wird möglicherweise die Schaltfläche Herunterladen und installieren angezeigt, obwohl die Plug-Ins installiert sind. In dieser Version ist das Problem behoben.
  • Die Installation des VI-Clients schlägt fehl, wenn die Installationsdatei von der VirtualCenter 2.5 Update 2-Webschnittstelle aus heruntergeladen wird
    Die von der VirtualCenter 2.5 Update 2-Webschnittstelle heruntergeladene Installationsdatei für den VI-Client ist möglicherweise unvollständig und die Dateigröße ist evtl. jedes Mal unterschiedlich, wenn Sie die Datei herunterladen. Wenn Sie die heruntergeladene Installationsdatei ausführen, schlägt die Installation des VI-Clients möglicherweise mit einer Fehlermeldung ähnlich der Folgenden fehl:
    Setup-Initialisierungsfehler
    In dieser Version ist das Problem behoben.

VirtualCenter, VI-Client und Web Access

  • VirtualCenter Server reagiert weiter auf den VI-Client
    In dieser Version wurden VirtualCenter-Datenbank-SQL-Skripts geändert, um Probleme zu beheben, die dazu führten, dass die VirtualCenter Server nicht mehr auf die VI-Clients reagieren, wodurch es zu mehreren Zeitüberschreitungen kommt und sich Benutzer nicht mehr beim VirtualCenter Server anmelden können.
  • Das Starten und Stoppen der NTP- und SSH-Dienste in der ESX Server-Servicekonsole wird im VI-Client nicht widergespiegelt
    In dieser Version ist das Problem behoben, dass das Starten oder Stoppen von Diensten auf der ESX Server-Servicekonsole in Bezug auf die NTP-Client- und SSH-Server-Dienste nicht im VI-Client widergespiegelt wird.
  • Beim Öffnen der Konsole für eine virtuelle Maschine vom VI-Client aus tritt Assert-Fehler 1319 auf
    In dieser Version ist ein Problem behoben, bei dem ein Fehler ähnlich folgendem Fehler auftritt: VMware VirtualCenter nicht behebbarer Fehler: (mks) ASSERT C:/ob/bora-59306/bora/lib/left/pollLeft.c:1420 bugNr=1319, wenn ein Konsolenfenster für eine virtuelle Maschine geöffnet wird.
  • QueryPerf-Abfragevorgang gibt Leistungsstatistiken der virtuellen Maschine zurück, die verbunden bleibt
    In dieser Version ist das Problem behoben, dass ein QueryPerf-Vorgang, der auf mehr als einer virtuellen Maschine ausgeführt wird, fehlschlägt, wenn eine virtuelle Maschine entfernt wird, während die Leistungsstatistiken abgerufen werden.
    Wenn in dieser Version eine virtuelle Maschine entfernt wird, während die Leistungsstatistiken abgerufen werden, gibt die QueryPerf-Abfrage die Leistungsstatistiken der virtuellen Maschinen zurück, die verbunden bleiben.
  • VirtualCenter Server reagiert auch noch bei mehr als 2400 virtuellen Maschinen in einer Ordnerstruktur
    In dieser Version ist folgendes Problem behoben: Wenn sich mehr als 2400 virtuelle Maschinen in einer einzelnen Ordnerstruktur befinden und SQL Server 2005 oder SQL Server 2000 als externer Datenbankserver verwendet wird, reagiert VirtualCenter Server bei Auswahl der Registerkarten "Aufgaben" und "Ereignisse" möglicherweise nicht mehr und es wird eine Fehlermeldung ähnlich der Folgenden angezeigt:
    Datenbank vorübergehend nicht verfügbar oder es liegen Netzwerkprobleme vor
  • Beim Entfernen von Ordnern mit virtuellen Maschinen werden keine virtuellen Maschinen vom ESX Server-Host-Datenspeicher gelöscht
    Ab dieser Version werden in der VirtualMachines-Ansicht und Vorlagenansicht beim Entfernen eines Ordners mit virtuellen Maschinen keine virtuellen Maschinen aus dem Host-Datenspeicher gelöscht. Virtuelle Maschinen, die sich auf einem verwalteten Host befinden, verbleiben auf dem Host, aber sie werden von VirtualCenter Server nicht mehr verwaltet.
  • Berechtigungen können für einzelne virtuelle Maschinen und Ressourcenpools im VI-Client konfiguriert werden
    Wenn in dieser Version der VI-Client direkt mit einem Host verbunden ist, auf dem ESX Server 3.5 oder höher ausgeführt wird, ist die Registerkarte Berechtigungen für einzelne virtuelle Maschinen und Ressourcenpools verfügbar.
  • VirtualCenter Server startet neu, selbst wenn ein Ressourcenpool mit dem Namen "Resources" erstellt wird
    Wenn in Vorgängerversionen ein Ressourcenpool mit dem Namen "Resources" in VirtualCenter Server erstellt und der VMware VirtualCenter-Serverdienst neu gestartet wird, schlägt das Starten von VirtualCenter Server möglicherweise mit einer Fehlermeldung ähnlich der Folgenden fehl:
    VMware VirtualCenter-Serverdienst konnte auf lokalem Computer nicht gestartet werden.
    Fehler 1067: Der Prozess wurde unerwartet abgebrochen.
    In dieser Version ist das Problem behoben.
  • Sysprep funktioniert nicht auf virtuellen Maschinen oder Vorlagen von VirtualCenter 2.5 Update 2 auf ESX Server 3.0.x-Hosts
    Bei virtuellen Maschinen oder Vorlagen mit Anpassungsspezifikationen, die in VirtualCenter 2.5 Update 2 erstellt wurden, funktioniert sysprep nicht, wenn eine virtuelle Maschine auf einem ESX Server 3.0.x-Host bereitgestellt wird. Die virtuelle Maschine wird bereitgestellt, aber Sysprep wird nicht ausgeführt und es gibt einen Klon der virtuellen Maschine mit demselben NETBIOS-Namen wie das Original, das zum Erstellen der Anpassungseinstellungen verwendet wurde. Der Klon tritt der angegebenen Domäne nicht bei oder führt andere Teile des Anpassungsskripts aus. In dieser Version ist dieses Problem behoben.
  • Die Außerkraftsetzung von Gruppenberechtigungen führt nicht dazu, dass Gruppennamen in unterschiedlicher Groß-/Kleinschreibung zurückgegeben werden
    Diese Version behebt das Problem, dass bei der Außerkraftsetzung von Gruppenberechtigungen, die für ein verwaltetes Element definiert wurden, auf der Registerkarte Berechtigungen in VirtualCenter Server Gruppennamen möglicherweise zweimal in unterschiedlicher Groß-/Kleinschreibung angezeigt werden.

VMware High Availability (HA)

  • HA-Netzwerkübereinstimmungsprüfung
    Während der HA-Konfiguration in VirtualCenter 2.5 Update 2 zeigen die Registerkarten "Aufgabe" und "Ereignisse"möglicherweise die folgende Fehlermeldung und Empfehlung an:
    Der HA-Agent auf <esxhostname> im Cluster <clustername> in <datacenter> weist einen Fehler auf - Nicht kompatibles HA-Netzwerk:
    Verwenden Sie die erweiterten Cluster-Einstellungen "das.allowNetwork" zum Steuern der Netzwerknutzung.
    Ab VirtualCenter 2.5 Update 2 verfügt HA über eine erweiterte Netzwerkübereinstimmungsprüfung zum Erhöhen der Clusterzuverlässigkeit. Diese erweiterte Netzwerkübereinstimmungsprüfung sorgt für ordnungsgemäße clusterübergreifende Taktsignal-Netzwerkpfade. VirtualCenter 2.5 Update 3 ermöglicht das Umgehen dieser Prüfung, damit Probleme bei der HA-Konfiguration vermieden werden. Wenn Sie die Prüfung umgehen möchten, fügen Sie in den erweiterten HA-Einstellungen die Option das.bypassNetCompatCheck=trueein.
  • In einem HA-DRS-Cluster kommt es zu einem Stillstand der Aufgabe "In den Wartungsmodus wechseln" und virtuelle Maschinen werden nicht migriert
    In früheren Versionen von VirtualCenter konnte es passieren, dass virtuelle Maschinen auf einem Host, der gerade in den Wartungsmodus wechselt, nicht automatisch migriert wurden, wenn nicht ausreichend Failover-Kapazitäten in einem HA-DRS-Cluster zur Verfügung stand. Die Aufgabe "In den Wartungsmodus wechseln" kommt bei 2 % zum Stillstand und wird auch dann nicht abgeschlossen, wenn die HA-Zugangssteuerung deaktiviert ist. In dieser Version wurde dieses Problem behoben, indem Evakuierungen erlaubt werden, wenn die HA-Zugangssteuerung deaktiviert ist. Beachten Sie, dass die Zugangssteuerung standardmäßig aktiviert ist. Weitere Informationen finden Sie unter Implications of enabling or disabling VMware HA strict admission control when using DRS and VMware DPM (KB 1007006). Beachten Sie, dass die Aufgabe möglicherweise auch dann angehalten wird, wenn die virtuellen Maschinen aus anderen Gründen nicht entfernt werden können.
  • Nach dem Erstellen können erweiterte HA-Einstellungen nicht gelöscht werden
    In Vorgängerversionen konnten erweiterte Einstellungen, die auf der Seite "Erweiterte Optionen" erstellt wurden, nicht gelöscht werden. Versuche, die erweiterte Einstellung zu löschen, führen zu einem Objektreferenzfehler. In dieser Version wird das Problem behoben. Erweiterte Einstellungen können normal gelöscht werden.
  • In einem DRS-Cluster mit Benutzerberechtigungen für virtuelle Maschinen kann die virtuelle Maschine nicht eingeschaltet werden
    In dieser Version ist das Problem behoben, dass Benutzer mit den Benutzerberechtigungen für virtuelle Maschinen eine virtuelle Maschine in einem DRS-Cluster nicht einschalten können, wenn DRS auf Manuell gesetzt ist.
  • Ein erhöhter Arbeitsspeicherverbrauch des VMware-HA-Agenten führt dazu, dass der ESX Server-Host nicht mehr reagiert
    In dieser Version ist das Problem behoben, dass der hohe Arbeitsspeicherverbrauch des VMware-HA-Agenten dazu führt, dass ein ESX Server-Host in einem HA-fähigen Cluster nicht mehr reagiert.
    Wenn der ESX Server-Host nicht mehr reagiert, werden Meldungen ähnlich der Folgenden in die Protokolldateien eingetragen:
    <Protokollierungsdatum> 01:01:39 <Host-Name> kernel: size-32 367 754 64 13 13 1
    <Protokollierungsdatum> 01:01:39 <Host-Name> kernel: Out of Memory: Killed process <Prozess-ID>(<Prozessname>).
    <Protokollierungsdatum> 01:17:52 <Host-Name> syslogd 1.4.1: restart.
  • VI-Client gibt möglicherweise an, dass ESX Server-Hosts während HA-DRS-Clustervorgängen nicht reagieren
    In dieser Version ist das Problem behoben, dass der VI-Client während HA-DRS-Clustervorgängen, wie z. B. dem Hinzufügen oder Entfernen eines Hosts von einem DRS-Cluster, dem Übernehmen von DRS-Empfehlungen, dem Migrieren virtueller Maschinen über Ressourcenpools hinweg oder dem Ein- bzw. Ausschalten virtueller Maschinen in einem Ressourcenpool, möglicherweise anzeigt, dass der ESX Server-Host Keine Antwortgibt, selbst wenn die Host-IP-Adresse erreichbar ist.
    Hinweis:Dieses Update bietet in Verbindung mit dem Patch ESXe350-200809401-I-SG für den ESX Server 3i-Host und dem Patch ESX350-200809404-SG für den ESX Server-Host eine vollständige Lösung dieses Problems.
  • Unterdrücken der Warnmeldung "Keine Verwaltungsnetzwerkredundanz"
    In dieser Version gibt es eine neue Option zum Unterdrücken der Warnmeldung "Der Host xxx verfügt momentan über keine Verwaltungsnetzwerkredundanz" bei einem Host, der als Knoten in einem HA-Cluster konfiguriert ist. Setzen Sie die erweiterte Option "das.ignoreRedundantNetWarning" auf "true", um die Warnmeldung auf Hosts zu unterdrücken, die nicht in einem HA-Cluster konfiguriert sind. Wenn die Warnung für Hosts erscheint, die bereits in einem Cluster konfiguriert sind, setzen Sie die Option und konfigurieren Sie HA auf diesem Host neu, um das Konfigurationsproblem zu beheben.
  • VMware HA kann unabhängig von der Groß-/Kleinschreibung des Namens des ESX Server-Hosts auf einem Cluster konfiguriert werden
    In der VirtualCenter Update 2-Version kann das Konfigurieren von VMware HA auf einem Cluster fehlschlagen, auf dem sich ESX Server-Hosts mit Hostnamen in Großbuchstaben befinden, wobei eine Fehlermeldung ähnlich der Folgenden angezeigt wird:
    Kontaktieren eines primären HA-Agenten im Cluster xxx nicht möglich
    In dieser Version ist dieses Problem behoben und VMware HA kann unabhängig von der Groß-/Kleinschreibung des Namens des ESX Server-Hosts auf einem Cluster konfiguriert werden.

Seitenanfang

Bekannte Probleme

 

Sicherung

 

  • Consolidate Helper-Snapshots werden möglicherweise nicht automatisch entfernt
    In ESX Server 3.5 Update 2 werden Consolidate Helper-Snapshots iterativ erstellt, um den Zeitraum, in dem eine virtuelle Maschine während der Snapshot-Erstellung inaktiv ist, zu minimieren. Consolidate Helper-Snapshots werden jetzt deshalb als Consolidate Helper-XXX und nicht nur als Consolidate Helper bezeichnet. Bei der Verwendung von VMware Consolidated Backup 1.1 mit ESX Server 3.5 Update 2 kann der vorübergehende Snapshot ignoriert werden, wenn vcbMounter während eines Vorgangs zum Löschen eines Snapshots einen Fehler erkennt. Durch den Befehl vbCleanup.bat wird dieser Snapshot Consolidate Helper-XXX nicht gelöscht. Der Snapshot muss mithilfe des VI-Clients manuell gelöscht werden. Dieser Fehler tritt bei VMware Consolidated Backup 1.5 nicht auf.
  • Anwendungen, die auf der virtuellen Maschine laufen, geben möglicherweise beim Erstellen eines Snapshots eines stillgelegten Prozesses einen Fehler aus
    Das Erstellen von Snapshots einer stillgelegter virtuellen Maschine erfordert Interaktion mit den Anwendungen, die auf ihr laufen. Wenn eine Anwendung eine hohe Last aufweist, kann sie beim Erstellen eines Snapshots der stillgelegten Anwendung Probleme verursachen. Bei diesen Problemen kann es sich um Anwendungsfehler, z. B. einen Fehler bei Schreiben der Daten auf die Festplatte, oder um Fehler beim Erstellen des Snapshots handeln.
    Sie können eine eingeschaltete virtuelle Maschine klonen. Dies erfordert allerdings das Erstellen eines Snapshots der stillgelegten VM und Sie erhalten möglicherweise Fehler, wenn eine Anwendung unter hoher Last auf der virtuellen Maschine ausgeführt wird.
    Hinweis:Sie können als Teil der Erstellung dieser Snapshots benutzerdefinierte Skripts auf der virtuellen Maschine ausführen. Diese Skripts können dann zum Herunterfahren und erneutem Starten der Anwendung nach der Snapshot-Erstellung verwendet werden. Weitere Informationen über benutzerdefinierte Skripts finden Sie im Kapitel zu VMware Consolidated Backup im "Sicherheitshandbuch für virtuelle Maschinen" des VMware Infrastructure-Dokumentationssatzes.

CIM und API

 

  • VI-Client zeigt auf HP-Servern einen falschen Namen für den Redundanzsensor zur Stromversorgung an
    Bei einer Verbindung einer ESX Server-Installation mit einem HP Serversystem über den VI-Client zeigt der VI-Client den Namen des Redundanzsensors für die Stromversorgung auf dem Server fälschlicherweise als physische Stromquelle an. Beispielsweise zeigt der VI-Client bei einem HP Server mit einem Redundanzsensor mit zwei physischen Stromversorgungen den Redundanzsensor als Stromversorgungen für die Stromversorgung 3 an.
  • Ausführen einer CallMethod-Abfrage auf einer CIM_RecordLog-Instanz schlägt möglicherweise fehl
    In ESX Server 3.5 Update 2 kann eine CallMethod-Abfrage (CM) auf einer CIM_RecordLog-Instanz fehlschlagen. Sie können jedoch das Systemereignisprotokoll über eine Remote-Managementkonsole oder -schnittstelle löschen.
  • Die obligatorische Eigenschaft MaxReadable, NominalReading, NormalMax, NormalMin und PollingInterval in der Klasse CIM_NumericSensor zeigt falsche Werte an
    Die Instanzen von CIM_NumericSensor verfügen über den folgenden Eigenschaftssatz: MaxReadable, NominalReading, NormalMax, NormalMin. Wenn der tatsächliche Sensor keine Werte dieser Eigenschaften unterstützt, werden sie in CIM-Antworten als 0 angezeigt und nicht als unspezifiziert.
  • Einige CIM-Klassen funktionieren nicht ordnungsgemäß auf IBM Multinode-Systemen
    Die folgenden Anomalien werden angezeigt. Die Operation "EnumerateInstance" gibt in den folgenden Klassen eine Instanz weniger als die Operation "Enumerate InstanceNames" zurück:
    • CIM_AssociatedSensor
    • CIM_MemberOfCollection
    • Bei den folgenden Klassen schlägt die Operation "GetInstance" für einige Instanzen fehl. Jedoch ist die Operation "EnumerateInstances" erfolgreich.
    • CIM_HostedService
    • CIM_Sensor
    • CIM_SystemDevice
    • CIM_Slot
    • CIM_ElementConformsToProfile
    Die Operationen "EnumerateInstances" und "EnumerateInstanceNames" geben keine Ergebnisse zurück:
    • CIM_OwningCollectionElement
    • CIM_RedundancySet
  • Änderungen des Sensorschwellenwerts werden nicht sofort übernommen
    Wenn Sie mithilfe von CIM den Sensorschwellenwert ändern, gibt die Sensoraufzählung möglicherweise nicht sofort die neuen Eigenschaftswerte zurück. Die Änderungen werden ungefähr eine Minute später übernommen.
  • Die Operation RequestStateChange(RestoreDefaultThresholds) gibt einen Fehler aus
    Die Operation "RequestStateChange(RestoreDefaultThresholds)" auf ESX Server 3.5 führt bei einigen Sensoren zu einer Fehlermeldung:
    CIM_ERR_FAILED: index out of bounds

    Trotz der Fehlermeldung stellt CIMOM die Schwellenwerte wieder her.
  • InvokeMethod(RequestStateChange) für Sensor und SEL schlägt fehl, wenn Sie das WS-Man-Protokoll verwenden.
  • InvokeMethod(RequestPowerStateChange) schlägt fehl, wenn Sie das WS-Man-Protokoll verwenden.
  • Firewall auf ESX Server 3.5 führt zu Konflikten mit CIM Indication-Unterstützung
  • Ausgehende HTTP-Verbindungen werden von der Firewall auf ESX Server 3.5 geblockt. Dies führt dazu, dass Indication-Ereignisse nicht den Indication-Verbraucher erreichen.
    Lösung: Öffnen Sie in der Servicekonsole einen ausgehenden Port für Verbindungen zum Indication-Verbraucher mit dem folgenden Befehl:
    esxcfg-firewall -o <port-number>,tcp,out,http
    So schließen Sie einen Port für http in der Firewall:
    esxcfg-firewall -c <port-number>,tcp,out,http
  • Auf HP 380 G5-Rechnern, auf denen ESX Server 3.5 Update 2 ausgeführt wird, wird als Antwort auf CIM_IPProtocolEndpoint-Abfragen die IP-Adresse der IPMI-Karte nicht zurückgegeben.
  • In ESX Server Version 3.5 wird die nachfolgende Fehlermeldung ausgegeben, wenn für numerische Stromversorgungssensoren die Operation Reset() aufgerufen wird:
    CIM_ERR_FAILED: Index außerhalb des zulässigen Bereichs
    Verwenden Sie stattdessen die Operation RequestStateChange(Reset), um dieses Problem zu umgehen.
  • Bei ESX Server 3.5 Update 2 zeigen Instanzen von VMware_Account (eine Unterklasse von CIM_Account) eine SystemName-Eigenschaft mit dem Wert "0". Die SystemName-Eigenschaft sollte die BIOS-UUID des Servers aufweisen.
  • Bei einigen Servern werden die Messungen des PECI-Temperatursensors falsch angezeigt. Falsche Werte werden für Prozessorsensoren im VI-Client und in der Eigenschaft "NominalReading" von CIM_Sensor-Instanzen für CPU PECI tic angezeigt.
  • Auf Servern, auf denen ESX Server 3.5 Update 2 Installiert ist, meldet SLP die Verfügbarkeit von "service:wbem" auf HTTP-Port 5888. Allerdings verhindern die standardmäßigen Firewall-Einstellungen den Zugriff auf Port 5888. Heben Sie die Blockierung des Ports in der Firewall-Konfiguration auf, um den Zugriff auf den Port zu ermöglichen.
  • Indication-Ereignisse auf ESX Server 3.5 Update 2 funktionieren nicht bei Verwendung des WS-Man-Protokolls. Auf IBM Athena-Hardware verfügen einige OMC_DiscreteSensor-Instanzen über falsche Geräte-IDs (-1 erscheint als letztes Segment der Geräte-ID).
  • Aufrufe von ModifyInstance() zum Ändern des Sensorschwellenwerts schlagen fehl, wenn Sie das WS-Man-Protokoll verwenden.
  • IBM Athena-Server verfügen nicht über eine Gehäuseeingriffanzeige.
  • Bei einem ESX Server 3.5-Host, der auf ESX Server 3.5 Update 2 aktualisiert wurde, werden CIM_AssociatedSensor-Instanzen falsch gemeldet. Abfragen vom Typ EnumerateInstance()und Association()für CIM_AssociatedSensorliefern keine Instanzen zurück. Um dieses Problem zu umgehen, installieren Sie ESX Server 3.5 Update 2 neu bzw. installieren Sie ESX Server 3.5 U1 neu und aktualisieren Sie auf ESX Server 3.5 Update 2.
  • Bei mancher Dell MLK-Hardware weist die Eigenschaft "NumberOfBlocks" für die OMC_Memory-Instanz einen Wert von 0 auf. Dieses Problem wird zurzeit untersucht.

Gastbetriebssysteme

 

Internationalisierung

Sämtliche Felder im VI-Client und in VI Web Access bieten ab sofort Unterstützung für die Eingabe von Nicht-ASCII-Zeichen, mit Ausnahme der folgenden Einschränkungen:

Einschränkungen in Bezug auf die Eingabe von Nicht-ASCII-Zeichen

 

  • Die Angabe eines Nicht-ASCII-Werts als Eingabe wird nicht von der Remote-Befehlszeilenschnittstelle (RCLI) unterstützt.
  • Der Name des Computers, auf dem VMware Infrastructure 3 oder eine der zugehörigen Komponenten installiert wird, darf keine Nicht-ASCII-Zeichen enthalten.
  • Der Name des Computers oder der virtuellen Maschine, auf dem/der der VirtualCenter Server installiert ist, darf keine Nicht-ASCII-Zeichen im Computernamen aufweisen, da anderenfalls die Installation von VirtualCenter Server fehlschlägt.
  • Verwenden Sie für alle Komponenten den im Installationsprogramm standardmäßig vorgegebenen Installationspfad. Nehmen Sie keine Änderung am Installationspfad vor, da das Installationsprogramm keine Pfadnamen unterstützt, die Nicht-ASCII-Zeichen und erweiterte ASCII-Zeichen enthalten.
  • Datenspeichernamen, Namen virtueller Netzwerke sowie Image-Dateinamen (CD-, DVD- und Diskettenlaufwerk) sind auf die Verwendung von ASCII-Zeichen beschränkt.
  • Die Meldung des Tages darf nur ASCII-Zeichen enthalten.
  • Bei der Anmeldung am VirtualCenter Server sind nur Benutzernamen mit ASCII-Zeichen erlaubt (Anmeldename unter Windows).
  • Die Image-Anpassung kann fehlschlagen, wenn Nicht-ASCII-Zeichen verwendet werden.
  • Benutzerdefinierte Attributnamen und -werte dürfen nur aus ASCII-Zeichen bestehen.
  • Zur Einhaltung der allgemeinen Internet- und Protokollstandards dürfen die folgenden Elemente keine ASCII-Zeichen enthalten: Hostnamen, Arbeitsgruppennamen, Domänennamen, URLs, E-Mail-Adressen, SMTP-Servernamen und SNMP-Community-Zeichenfolge.
  • Gastbetriebssystemanpassungen unter Verwendung der ASCII-Codierung werden unterstützt, die Anpassung mit UTF-8-codierten systemeigenen Zeichen aus dem Japanischen, Chinesischen oder Deutschen werden jedoch nur eingeschränkt unterstützt. Für Anpassungen mit Besitzer-, Organisations-, Benutzernamen und Kennwörtern, die Nicht-ASCII-Zeichen enthalten, müssen VirtualCenter und die Sysprep-Tools mit dem gleichen Gebietsschema verwaltet werden wie das Gastbetriebssystem. Dies schließt die Verwendung von UTF-8-codierten Antwortdateien ein.

Anzeigeeinschränkungen für Nicht-ASCII-Zeichen

 

  • Werden bei der Verwaltung eines VirtualCenter Servers mit dem VI-Client unterschiedliche Windows-Sprachversionen verwendet, kann es aufgrund der Unterschiede in Bezug auf die sprachspezifische Unterstützung in Windows zu einer fehlerhaften Darstellung einiger Zeichen kommen.
  • Wenn eine Fehlermeldung Protokollspeicherorte oder Benutzernamen mit Nicht-ASCII-Zeichen enthält, wird die Fehlermeldung in der lokalisierten Umgebung nicht richtig angezeigt.
  • Bei Verwendung des Import-Assistenten von VMware Converter stimmt das Datums- und Uhrzeitformat gelegentlich nicht mit dem aktuellen Gebietsschema überein.
  • Unicode-Zeichen werden in der Spalte "Status" und in den Aufgabendetails der Aufgabenansicht im japanischen Gebietsschema als Fragezeichen (???) angezeigt.
  • Der Abschnitt "Befehle" auf der Registerkarte "Übersicht" wird nicht ordnungsgemäß angezeigt.

Einschränkungen in Bezug auf die gesteuerte Konsolidierung

Die Registerkarte "Gesteuerte Konsolidierung" ist nur im Gebietsschema en_US verfügbar.

Übersetzungsprobleme

Für diese Version sind folgende Übersetzungsprobleme bekannt:

 

  • Der Upgrade-Assistent ist nicht übersetzt.
  • Einige Fehlermeldungen, die vom ESX Server-Host stammen, sind nicht übersetzt.
  • Einige der lokalisierten Oberflächenlayouts sind noch nicht fertiggestellt.

Andere Internationalisierungsprobleme

Es wurden folgende zusätzliche Probleme festgestellt:

 

  • Die in der Aktion "Skript ausführen" für einen Alarm verwendeten Werte werden nach einem Neustart des VirtualCenter Servers möglicherweise nicht ordnungsgemäß angezeigt, wenn die Host-Betriebssystemsprachen von VMware Infrastructure-Client und VirtualCenter Server/Datenbank nicht übereinstimmen.
  • In der chinesischen (vereinfacht) Version von VI Web Access wird der falsche Text auf der Schaltfläche "Abbrechen" angezeigt.
  • Der VI-Client setzt möglicherweise die Spracheinstellung außer Kraft
    Der VI-Client setzt möglicherweise die Spracheinstellung außer Kraft und zeigt Meldungen in anderen Sprachen als in der Hauptsprache an. Der VI-Client kann Meldungen anzeigen, die vom Server (VirtualCenter Server und ESX Server) dynamisch in der auf dem Server festgelegten Hauptsprache erstellt werden. Dieses Problem tritt nicht auf, wenn alle Programme in der Sprache des eingestellten Gebietsschemas des Betriebssystems ausgeführt werden.
  • Assistent für eine Neuinstallation zeigt im deutschsprachigen VI-Client den falschen Text an
    Der Assistent für eine Neuinstallation zeigt im deutschsprachigen VI-Client den falschen Text an.
    Der Assistent für eine Neuinstallation zeigt den folgenden Text an:
    Der Installations-Assistent ermöglicht Ihnen, Virtual Infrastructure Client 2.5 zu reparieren oder zu entfernen.,anstatt: Der Installations-Assistent ermöglicht Ihnen, Virtual Infrastructure Client 2.5 zu entfernen.
  • Links mit von Maschinen erzeugten Namen von virtuellen Maschinen funktionieren nicht
    Wenn Sie unter Verwendung von WebAccess den Datenspeicher durchsuchen, indem Sie auf einen Link mit von Maschinen erzeugten Namen von virtuellen Maschinen (der Name beginnt im Allgemeinen mit einem Plus-Zeichen und endet mit einem Schrägstrich, z. B. +5paw55qE5qih5p2,/) klicken, gibt der Webbrowser eine leere Seite oder eine Seite mit dem Hinweis darauf aus, dass die Seite nicht gefunden wurde. Sie können jedoch auf solche virtuellen Maschinen mithilfe des VI-Clients zugreifen.
  • Abgeschnittener Text auf der Netzwerkzugriffsseite des Assistenten zum Hinzufügen eines Netzwerks während der Verwendung des japanischsprachigen VI-Clients
    Details zu Netzwerke (IP-Adresse), die auf der Netzwerkzugriffsseite angezeigt werden, werden beim Zugreifen auf VirtualCenter abgeschnitten, wenn der japanischsprachige VI-Client verwendet wird.
    Das Netzwerkzugriffsfenster wird im Assistenten zum Hinzufügen eines Netzwerks angezeigt, wenn Sie auf der Registerkarte "Konfiguration" als Netzwerkoption "Netzwerk hinzufügen" auswählen.
    Umgehung:Sie können die Netzwerkinformationen (IP-Adresse) auf der Seite "Netzwerkadapter" anzeigen. Wählen Sie Konfiguration> Netzwerk> Eigenschaften> Netzwerkadapter, um die Netzwerke anzuzeigen.

Migration mit VMotion

 

Sonstige Probleme

 

Netzwerke

 

Serverkonfiguration

 

Speicher

 

Aktualisierung und Installation

Andere Upgrade- und Installationsprobleme

 

Installation und Aktualisierung von VirtualCenter

 

Verwaltung von virtuellen Maschinen

 

  • Geklonte virtuelle Maschinen enthalten kein DNS-Suffix (KB 1004299)
  • Geklonte virtuelle Maschinen sehen die .vmdk-Datei der Quell-VM (KB 1004176)
  • Bereitstellung virtueller Maschinen anhand einer Vorlage schlägt mit einem Hinweis auf fehlende Berechtigungen fehl (KB 1004295)
  • Benutzer mit Berechtigung "Erstellen" kann keine virtuellen Maschinen erstellen(KB 1004417)
  • E/A wird auf virtuellen Maschinen während der Firmware-Aktualisierung verzögert
    Wenn virtuelle Maschinen auf einer gemeinsam genutzten LUN mit hoher E/A-Arbeitslast ausgeführt werden und wenn die Firmware mit dem Speicherverwaltungsdienstprogramm aktualisiert wird oder wenn der Speichercontroller neu gestartet wird, kann E/A auf jeder virtuellen Maschine verzögert werden.
    In der Datei vmkernel.log können den folgenden ähnliche Fehlermeldungen angezeigt werden:
    1:01:05:07.275 cpu2:1039)WARNING: FS3: 4785: Reservation error: Not supported
    SCSI: 4506: Cannot find a path to device vmhba1:0:125 in a good state. Trying path vmhba1:0:125.
    1:01:05:10.262 cpu3:1039)ALERT: SCSI: 4506: Cannot find a path to device vmhba1:0:125 in a good state. Trying path vmhba1:0:125.
    1:01:05:40.748 cpu1:1083)<6>mptbase: ioc0: LogInfo(0x30030108): Originator={IOP}, Code={Invalid Page}, SubCode(0x0108)
    1:01:05:40.930 cpu0:1024)Log: 472: Setting loglevel (via VSI) for module 'SCSI' to 5
  • Virtuelle Maschinen werden nach einem Failover möglicherweise nicht eingeschaltet, wenn der Host isoliert ist
    Virtuelle Maschinen werden nach einem Failover möglicherweise nicht eingeschaltet, wenn der Host isoliert ist und die Hostisolierungsreaktion auf "Herunterfahren des Gastes", der Standardkonfiguartion für einen Cluster, eingestellt ist. Dies tritt möglicherweise bei Clustern mit weniger als fünf Knoten und auf virtuellen Maschinen auf, die mehr Zeit zum Herunterfahren des Gastes benötigen.
    Umgehung
    Setzen Sie bei Clustern mit weniger als fünf Knoten die Isolierungsreaktion auf entweder "VM eingeschaltet lassen" oder "Ausschalten".
    Zum Festlegen der Isolierungsreaktion für eine virtuelle Maschine wählen Sie den Cluster aus, klicken Sie auf den Link "Einstellungen bearbeiten" und wählen Sie Optionen für virtuelle Maschinen unter "VMware HA". Wählen Sie im Popup-Menü "Isolierungsreaktion" für die bestimmte virtuelle Maschine entweder VM eingeschaltet lassen oder Ausschalten.
  • Benutzerdefiniertes VMware Tools-Skript wird für Ereignisse "Angehalten" oder "Herunterfahren" nicht ausgeführt (KB 1004390)
  • VirtualCenter Server wird nicht sofort initialisiert, wenn die neueste Version des VMware Capacity Planner-Dienstes nicht verwendet wird
    Falls der VMware Capacity Planner-Dienst für VirtualCenter Server 2.5 Update 2 nicht installiert ist, benötigt der VirtualCenter Server lange für die Initialisierung. Während dieser Zeit kann der VI-Client keine Verbindung zum Virtual Center Server herstellen. Außerdem steht die Konsolidierungsfunktion im VI-Client nicht zur Verfügung.
    Wenn Sie die Konsolidierungsfunktion verwenden möchten, deinstallieren Sie alle früheren Versionen des VMware Capacity Planner-Dienstes, installieren Sie den VMware Capacity Planner-Dienst für Virtual Center 2.5 Update 2 und starten Sie den VirtualCenter Server neu.
  • Auf der Seite "Einmaliges Ausführen" angegebene Befehle werden nicht ausgeführt
    Wenn auf der Seite "Einmaliges Ausführen" des Assistenten für die Gastanpassung des Virtual Infrastructure-Clients ein mit einem Anführungszeichen endender Befehl angegeben wird, schlägt der Befehl möglicherweise fehl, wenn sich ein Benutzer beim angepassten Gastbetriebssystem anmeldet.
    Umgehung: Verwenden Sie keine Anführungszeichen am Ende von Befehlen, die auf der Seite "Einmaliges Ausführen" angegeben werden.
  • Das Klonen von virtuellen Maschinen unter Windows 2000 und Windows 2003 schlägt fehl, wenn beim Anpassen des Gastbetriebssystems kein Lizenzschlüssel angegeben wird
    Wenn beim Klonen von virtuellen Maschinen unter Windows 2000 und Windows 2003 die Option Mit dem Assistenten für benutzerdefinierte Anpassungen bearbeiten auf der Seite "Option für die Anpassung des Gastbetriebssystems auswählen" ausgewählt wird und wenn das Kontrollkästchen Serverlizenzdaten verwenden auf der Seite "Windows-Lizenz" des Windows-Gastanpassungsassistenten des VMware Infrastructure-Client nicht markiert ist, schlägt der Klonvorgang mit einer Meldung ähnlich der Folgenden fehl:
    Benutzerdefinierte Anpassung fehlgeschlagen.

Probleme in VirtualCenter, VI-Client und Web Access

 

VMware High Availability (HA)

 

  • Die Migration von virtuellen Maschinen wird nicht empfohlen, wenn der ESX Server-Host in den Wartungs- oder Standby-Modus wechselt
    Die Migration von virtuellen Maschinen wird nicht empfohlen (oder wird im voll automatischen Modus nicht durchgeführt), wenn der Host in den Wartungs- oder Standby-Modus wechselt, da der VMware HA-Failover-Level beim Wechseln in den entsprechenden Modus verletzt werden kann. Diese Einschränkung gilt unabhängig davon, ob die strenge HA-Zugangssteuerung aktiviert ist oder nicht.
  • Die Statusüberwachung von VMware HA wird in der Konsole nach einem Host-Failover nicht mehr neu gestartet
    Die VMware-Konsolenanzeige zeigt nach einem Hostausfall ein leeres Fenster an, wenn für einen HA-Cluster die Statusüberwachung aktiviert wurde. Die Konsole zeigt den Neustart der virtuellen Maschine nicht an.
    Umgehung: Sie müssen eine neue Konsole öffnen, damit Sie den Neustart der virtuelle Maschinen nach dem Failover sehen können.
  • Während HA-DRS-Clustervorgängen zeigt der VI-Client möglicherweise an, dass der Host nicht antwortet
    Bei HA-DRS-Clustervorgängen, wie z. B. beim Hinzufügen bzw. Entfernen eines Hosts aus einem DRS-Cluster oder beim Übernehmen von DRS-Empfehlungen, zeigt der VI-Client möglicherweise an, dass der Host nicht antwortet. Dies geschieht auch dann, wenn die IP-Adresse des Hosts erreichbar ist.
    Umgehung: Trennen Sie den Host vom HA-DRS-Cluster und verbinden Sie ihn neu. Damit wird das System aktualisiert und der VI-Client wird die von Ihnen vorgenommenen Konfigurationsänderungen anzeigen. Sollte der VI-Client den Status des Hosts erneut als Antwortet nicht anzeigen, trennen Sie den Host vom HA-DRS-Cluster, entfernen Sie ihn und fügen Sie ihn wieder zu demselben Cluster hinzu.
  • Die Neukonfigurierung des HA-Agenten auf einem ESX Server-Host schlägt nach einem Upgrade von VirtualCenter Server fehl
    Wenn ein VirtualCenter Server, der ein HA-fähiges Cluster enthält, aktualisiert wird und ESX Server-Hosts erneut mit VirtualCenter verbunden werden, schlägt die Neukonfigurierung des HA-Agenten auf einem der ESX Server-Hosts mit einer HA-Agent-Fehlermeldung ähnlich der Folgenden fehl:
    Der HA-Agent auf <Hostname> im Cluster <Clustername> in <Datencentername> weist einen Fehler auf:
    cmd addnode fehlgeschlagen für primären Knoten: /opt/vmware/aam/bin/ft_startup fehlgeschlagen
    Umgehung: Deaktiveren Sie nach der Aktualisierung des VirtualCenter Servers HA auf dem Cluster und aktivieren Sie es neu.
  • HA-Netzwerkübereinstimmungsprüfung
    Während der HA-Konfiguration in VirtualCenter 2.5 Update 2 zeigen die Registerkarten "Aufgabe" und "Ereignisse" möglicherweise die folgende Fehlermeldung und Empfehlung an:

    Der HA-Agent auf <esxhostname> im Cluster <clustername> in <datacenter> weist einen Fehler auf - Nicht kompatibles HA-Netzwerk:
    Verwenden Sie die erweiterten Cluster-Einstellungen "das.allowNetwork" zum Steuern der Netzwerknutzung.

    Ab Virtual Center 2.5 Update 2 verfügt HA über eine erweiterte Netzwerkübereinstimmungsprüfung zum Erhöhen der Clusterzuverlässigkeit. Diese erweiterte Netzwerkübereinstimmungsprüfung sorgt für ordnungsgemäße clusterübergreifende Taktsignal-Netzwerkpfade. Weitere Informationen finden Sie unter KB 1006606.

 

 

Seitenanfang