Versionshinweise zu VMware ESX Server 3i Version 3.5 Update 5 Installable

Kontakt zum Vertrieb
 

VMware ESX Server 3i Version 3.5 Update 5 Installable | 3. Dezember 2009 | Build 207095

Letzte Dokumentaktualisierung: 03 Dez. 2009

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 den bisherigen Bezeichnungen, um mit den Produktoberflächen und Dokumentationen übereinzustimmen. In künftigen Versionen werden die Produktnamen aktualisiert.

Neuigkeiten

Anmerkungen:

  1. Nicht alle Kombinationen von VirtualCenter- und ESX Server-Version werden unterstützt. Alle diese vorgestellten Funktionen stehen nur dann zur Verfügung, wenn Sie VirtualCenter 2.5 Update 5 zusammen mit ESX Server 3.5 Update 5 verwenden. Weitere Informationen zur Kompatibilität finden Sie in den Kompatibilitätstabellen für ESX Server, VirtualCenter und VMware Infrastructure-Client.
  2. Es wird empfohlen, VMware Tools für diese Version des ESX Server zu aktualisieren.

Sie erhalten nachstehend Informationen zu einigen der wichtigsten Verbesserungen in der vorliegenden Version von VMwareESX Server:

Aktivierung der Intel Xeon 3400-Prozessorserie – Die Intel Xeon 3400-Prozessorserie wird jetzt unterstützt. Erweiterte VMotion-Funktionen werden auch unterstützt. Weitere Informationen über vorherige Prozessorfamilien, die von Enhanced VMotion unterstützt werden, finden Sie unter Unterstützte Prozessoren für Enhanced VMotion Compatibility (EVC) (KB 1003212).

Treiber-Update für den Broadcom bnx2-Netzwerk-Controller – Der Treiber für bnx2-Controller wurde auf Version 1.6.9 aktualisiert. Dieser Treiber unterstützt das bootcode-Upgrade auf bnx2-Chipsets und erfordert ein Upgrade der bmapilnx- und lnxfwnx2-Tools von Broadcom. Dieser Treiber bietet auch Unterstützung für den Netzwerk-Controller - Sideband-Schnittstelle (NC-SI) für SOL (Serial Over LAN) anwendbar auf Broadcom NetXtreme 5709- und 5716-Chipsets.

Treiber-Update für LSI SCSI- und SAS-Controller – Der Treiber für LSI SCSI- und SAS-Controller wurde auf Version 2.06.74 aktualisiert. Diese Version des Treibers wird benötigt, um die Unterstützung für gemeinsam genutzte SAS-Umgebungen zu verbessern.

Neu unterstützte Gastbetriebssysteme – Die Unterstützung für folgende Gastbetriebssysteme wurde speziell für diese Version hinzugefügt:

Vollständigere Informationen über von dieser Version unterstützte Gastbetriebssysteme finden Sie im "VMware-Kompatibilitätshandbuch": www.vmware.com/resources/compatibility/search.php.

  • Windows 7 Enterprise (32- und 64-Bit)
  • Windows 7 Ultimate (32- und 64-Bit)
  • Windows 7 Professional (32- und 64-Bit)
  • Windows 7 Home Premium (32- und 64-Bit)
  • Windows 2008 R2 Standard Edition (64-Bit)
  • Windows 2008 R2 Enterprise Edition (64-Bit)
  • Windows 2008 R2 Datacenter Edition (64-Bit)
  • Windows 2008 R2 Web Server (64-Bit)
  • Ubuntu Desktop 9.04 (32- und 64-Bit)
  • Ubuntu Server 9.04 (32- und 64-Bit)

Neu unterstützte Management-Agenten – Aktuelle Informationen zu unterstützten Management-Agenten finden Sie unter Vom VMware ESX Server unterstützte Hardware-Lifecycle-Management-Agenten.

Neu unterstützte Netzwerkkarten – In dieser Version von ESX Server wird der HP NC375T (NetXen) PCI Express Quad Port Gigabit Server-Adapter unterstützt.

Neu unterstützte SATA-Controller – In dieser Version von ESX Server wird der Intel Ibex Peak SATA AHCI-Controller unterstützt.

Hinweis:
  • Es gelten einige Einschränkungen hinsichtlich der Unterstützung von SATA-Controllern. Weitere Informationen finden Sie unter Unterstützung von SATA-Controllern in ESX 3.5. (KB 1008673)
  • Das Speichern von VMFS-Datenspeichern auf nativen SATA-Laufwerken wird nicht unterstützt.

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:

Seitenanfang

Bevor Sie beginnen

Kompatibilität für ESX Server, VirtualCenter und VMware Infrastructure-Client

Das Dokument Kompatibilitätstabellen für ESX Server, VirtualCenter und VMware Infrastructure-Client liefert Details zur Kompatibilität aktueller und früherer Versionen von VMware Infrastructure 3-Komponenten, einschließlich ESX Server, VirtualCenter und des VI-Clients.

Hardwarekompatibilität

  • Erfahren Sie mehr über Hardwarekompatibilität: <br/>

    Die Listen zur Hardwarekompatibilität stehen nun in einem webbasierten Kompatibilitätshandbuch unter www.vmware.com/guides zur Verfügung. Dieses neue Format bietet eine zentrale Quelle für alle VMware-Kompatibilitätshandbücher. Die vorherigen PDF-Versionen werden nicht mehr aktualisiert. Das webbasierte Kompatibilitätshandbuch ermöglicht das Durchsuchen der Handbücher und das Speichern der Suchergebnisse im PDF-Format.<br/> Um über Updates des Kompatibilitätshandbuchs benachrichtigt zu werden, können Sie sich registrieren unter Dies ist das RSS-Bild, das als Link auf einen RSS-Feed dient.

  • Erfahren Sie mehr über die VMware Infrastructure-Kompatibilität: <br/>

    VMware Infrastructure-Kompatibilitätstabellen ( PDF)

Dokumentation

Die gesamte Dokumentation für ESX Server 3i Version 3.5 Update 4 Installable gilt auch für ESX Server 3i Version 3.5 Update 5 Installable. Eine vollständige Liste der Handbücher und zusätzlicher Dokumentation finden Sie in der VMware Infrastructure 3-Dokumentation.

Seitenanfang

Installation und Upgrade

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

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

Upgrade oder Migration auf ESX Server 3i Version 3.5 Update 5

 

Diese Version unterstützt die Migration virtueller Maschinen von ESX Server 2.x (und höheren Versionen einschließlich ESX Server 3.0.x) auf ESX Server 3i. Weitere Informationen zu Installations- und Upgrade-Methoden finden Sie im Upgrade-Handbuch.<br/>

Hinweis: Das Upgrade von ESX Server 3i Version 3.5 Update 5 Installable auf ESXi 4.0 Installable wird nicht unterstützt. Sie können allerdings auf ESXi 4.0 Update 1 Installable aktualisieren.

Duchführen eines Updates der VMware Tools

Es wird empfohlen, VMware Tools für diese Version des ESX Server zu aktualisieren. Die VMware Tools-Version sollte 7.4.8 sein. Der Windows-SVGA-Treiber wurde auf Version 11.4.3.3 aktualisiert.

Kostenlose Lizenz für ESX Server 3i Version 3.5

Ab der Update 2-Version von ESX Server 3i Version 3.5 Installable und ESX Server 3i Version 3.5 Embedded können Sie Ihre Software kostenlos herunterladen und lizenzieren. Weitere Informationen zur Verwendung der kostenlosen Lizenz mit der Software finden Sie unter KB 1006481. Beachten Sie, dass die kostenlose Lizenz für vorherige Versionen von ESX Server 3i nicht unterstützt wird.

Seitenanfang

In dieser Version enthaltene Patches

Zusätzlich zu ISO-Images wird ESX Server 3i Version 3.5 Update 5 Installable als Patch verteilt, der auf vorhandene Installationen der ESX Server 3i Version 3.5 Installable-Software angewendet werden kann. Dieser Patch kann von der Download-Website für ESX Server 3i-Patches heruntergeladen werden oder unter Verwendung von VMware Update Manager angewendet werden. Wenn der Patch von der Website heruntergeladen wird, wird er unter der Bezeichnung ESXe350-200911201-O-UG verteilt. Das Patchpaket ESXe350-200911201-O-UG enthält die folgenden einzelnen Pakete, bei denen es sich um dieselben Pakete handelt, die in VMware Update Manager angezeigt werden:

  • ESXe350-200911201-I-UG: Aktualisiert Firmware
  • ESXe350-200911202-T-UG: Aktualisiert VMware Tools
  • ESXe350-200911203-C-UG: Aktualisiert VMware-Client

Diese Version enthält zudem alle Patches für die ESX Server-Software, die vor dem Veröffentlichungsdatum dieses Produkts zur Verfügung standen. Weitere Informationen zu den einzelnen Patches finden Sie auf der Download-Website für ESX Server 3i-Patches.

ESX Server 3i Version 3.5 Update 5 Installable enthält alle Fixes, die in ESX Server 3i Version 3.5 Update 4 Installable enthalten sind, sowie die folgenden Patches, die nach der Veröffentlichung von ESX Server 3i Version 3.5 Update 4 Installable veröffentlicht wurden:

  • ESXe350-200910401-O-SG: Aktualisiert Firmware und Tools
  • ESXe350-200908401-O-BG: Aktualisiert Firmware und Tools
  • ESXe350-200907401-O-SG: Aktualisiert Firmware und Tools
  • ESXe350-200906401-O-BG: Firmware-Update
  • ESXe350-200905401-O-BG: Firmware-Update
  • ESXe350-200904401-O-SG: Firmware-Update
  • ESXe350-200904201-O-SG: Firmware-Update

Weitere Informationen zu den Inhalten der Patches finden Sie in der Dokumentation, die auf der Download-Seite aufgeführt wird.

Seitenanfang

Behobene Probleme

In dieser Version werden Probleme in den folgenden Bereichen behoben:

CIM und API

  • In früheren Versionen von ESX Server weist die Eigenschaft NumberOfBlocksfür die OMC_Memory-Instanz bei mancher Dell MLK-Hardware einen Wert von 0 auf.

  • Funktionelle Vorgänge, die unter Verwendung des CIM-Clients durchgeführt werden, sind im Sperrmodus möglich
    Wenn sich ein ESX Server 3i-Host im Sperrmodus befindet, können Sie Vorgänge, die Schreibzugriffe erfordern, mithilfe des CIM-Clients erfolgreich durchführen. Nichtsdestotrotz treten die folgenden Probleme mit CIMOM auf, wenn sich der ESXi-Host im Sperrmodus befindet:

    • Die Methode PowerManagementService.RequestPowerStateChangemeldet einen erfolgreichen Abschluss, wenn nicht neu gestartet wurde. Es wird keine Fehlermeldung angezeigt.
    • Die Methode RecordLog.ClearLogist erfolgreich, wenn sie mit einer Fehlermeldung fehlschlagen müsste.
    • Im Sperrmodus führt CIMOM Systemaufrufe in einer Schleife aus. Damit steigt die CPU-Nutzung auf 100 %.
    • Authentifizierungsfehlermeldungen werden aufgrund von wiederholten Systemaufrufen in die Systemprotokolle geschrieben.

  • LSI-Anbieter protokollieren wiederholt die Meldung failed to get TopLevelSystemim Systemprotokoll von ESX Server-Hosts, die über keine LSI-Controller verfügen. In dieser Version wird die Meldung nicht protokolliert, wenn keine LSI-Controller vorhanden sind.

  • Das Protokoll ist mit storelib Physical Device Device ID-Meldungen gefüllt<br/> In manchen Fällen protokollieren Anbieter, die LSI Logic-Treiber (megaraid2, megaraid_sas, mptscsi) verwenden, wiederholt Meldungen wie z. B. storelib Physical Device Device IDund füllen die Protokolldatei /var/log/messagesauf. Diese Meldungen sind Teil des Debug-Codes. In dieser Version werden diese Debug-Code-Meldungen nicht an dieser Stelle protokolliert.

  • Eine Debug-Meldung wird alle zwei Minuten im Systemprotokoll protokolliert<br/> Die folgende Debug-Meldung wird alle zwei Minuten in der Datei /var/log/messagesprotokolliert:<br/> trying to open /sbin/modprobe edd 2>&1

Gastbetriebssysteme

  • Erhöhter E/A-Zeitüberschreitungswert für Linux-Gastbetriebssysteme mit einer Kernelversion von 2.6.13 oder höher<br/> Ab ESX 3.5 Update 5 installiert VMware Tools eine udev-Regeldatei auf Linux-Betriebssystemen mit einer Kernelversion von 2.6.13 oder höher. Diese Regeldatei ändert den Standardzeitüberschreitungswert von virtuellen VMware-Festplatten auf 180 Sekunden. Dies erhöht die Überlebenschancen des Gastbetriebssystems während eines Failover-Szenarios.

  • Der Arbeitsspeicher-Scrubber-Dienst in Solaris ruft den Arbeitsspeicher-Balloon auf<br/> Der Arbeitsspeicher-Scrubber-Dienst in Solaris ruft den Arbeitsspeicher-Balloon auf, indem er auf die Arbeitsspeicherseiten zugreift, die von dem Balloon-Treiber reserviert sind. In dieser Version ist der Arbeitsspeicher-Scrubber-Dienst deaktiviert, wenn der Balloon-Treiber geladen ist, um so die Pop-Rate des Arbeitsspeicher-Balloons zu reduzieren.

  • Der Balloon-Treiber auf virtuellen Solaris-Maschinen wird häufig zurückgesetzt<br/> Manche virtuelle Solaris-Maschinen setzen den Balloon-Treiber häufig zurück. In dieser Version wurden zwei neue Parameter eingeführt, anhand derer Sie das Ballooning deaktivieren können. Diese Parameter sind:

    • sched.mem.balloon.resetlimit: Anzahl der Balloon-Zurücksetzungen, nach der die Ballooning-Funktion deaktiviert wird. Der Standardwert ist 12.
    • sched.mem.balloon.decayperiod: Anzahl der Sekunden, nach der der Wert des Zurücksetzungszählers halbiert wird. Der Standardwert beträgt 43200 Sekunden (12 Stunden).

    Diese Parameter können in der .vmx-Datei konfiguriert werden. Wenn der Parameter sched.mem.balloon.resetlimitden Wert 0 erreicht, wird das Ballooning deaktiviert. Wurde auf einer virtuellen Maschine das Ballooning deaktiviert, kann es nur durch einen Neustart der virtuellen Maschine wieder aktiviert werden.

  • Anwendungen, die die Datei "msvcp71.dll" benötigen, werden nicht geöffnet, wenn die VSS-Komponente deinstalliert wird<br/> Wenn Sie VMware Tools oder die VSS-Komponenten von VMware Tools deinstallieren, werden Anwendungen, die die Datei msvcp71.dllbenötigen, nicht geöffnet, wenn die virtuelle Maschine neu gestartet wird. Dieses Problem wurde in der vorliegenden Version behoben.

  • Die Registerkarte Virtuelle Maschinen in VirtualCenter zeigt virtuelle Windows 2008 Server-Maschinen als virtuelle Windows Vista-Maschinen an.

  • Die Arbeitsspeicherauslastung des Gastbetriebssystems wird überschätzt und verursacht somit ausgelöste Arbeitsspeicheralarme in VirtualCenter Server<br/> Die Arbeitsspeicherauslastung von Gastbetriebssystemen wird möglicherweise auf Intel-Systemen überschätzt, welche die EPT-Technologie unterstützen, oder auf AMD-Systemen, welche die RVI-Technologie unterstützen. Dies könnte dazu führen, dass die Arbeitsspeicheralarme des VirtualCenter Server auch dann ausgelöst werden, wenn das Gastbetriebssystem nicht aktiv auf große Arbeitsspeichermengen zugreift.

  • Beim Installieren der VMware Tools wird auf virtuellen Windows XP Embedded-Maschinen nach der Datei "i8042prt.sys" gefragt<br/> Beim Installieren der VMware Tools wird auf virtuellen Windows XP Embedded-Maschinen nach der Datei i8042prt.sysgefragt. Sie müssen diese Datei manuell aus dem Verzeichnis C:\Windows\system32\driversauswählen und auf OK.<br/> klicken Hinweis: Es wird in diesem Fall davon ausgegangen, dass sich der Ordner \Windows\system32\driversauf Laufwerk C:befindet.

  • Virtuelle Windows-Maschinen schlagen mit einem blauen Bildschirm fehl, wenn auf sie über RDP-Sitzungen zugegriffen werden.<br/> Manche virtuelle Windows-Maschinen schlagen möglicherweise mit einem Fehler auf dem blauen Bildschirm fehl, wenn auf sie über eine RDP-Sitzung (Remote Desktop Protocol) zugegriffen wird.

  • Java-Anwendungen, die in virtuellen SMP-Maschinen (Symmetric Multi-Processing) mit aktiviertem VMI ausgeführt werden, schlagen möglicherweise fehl.

  • Das automatische Upgrade von VMware Tools auf einer virtuellen Windows-Maschine erfordert den manuellen Benutzerzugriff.<br/> Bei einem automatischen Upgrade von VMware Tools auf einer virtuellen Windows-Maschine über den VI-Client zeigt das Installationsprogramm möglicherweise ein Dialogfeld mit einer Eingabeaufforderung an. Sie müssen sich zum Anschließen des Upgrade-Prozesses bei der virtuellen Maschine anmelden und auf das Dialogfeld reagieren. Das Problem wurde in dieser Version behoben, sodass das automatische Upgrade ohne manuellen Benutzerzugriff abgeschlossen wird.

  • Bei virtuellen Maschinen, die das Virtual Machine Interface (VMI) verwenden, dauert der Startvorgang möglicherweise sehr lange.

  • Eine virtuelle Maschine, die das Virtual Machine Interface (VMI) verwendet, antwortet möglicherweise nicht mehr. Dieses Problem wurde in der ESX Server 3.5 Update 5-Version behoben.

  • Bei virtuellen SMP-Maschinen, die die RVI-Funktion (Rapid Virtualization Indexing) von AMD verwenden, wird möglicherweise ein schwarzer Bildschirm für bis zu 30 Sekunden nach dem Einschalten angezeigt.

  • VMware Tools überschreibt den SVGA-Treiber, ohne die Version des vorhandenen SVGA-Treibers zu prüfen.

  • Das Reparieren oder Ändern von VMware Tools schlägt mit einem schwerwiegenden Fehler fehl<br/> Wenn Sie VMware Tools auf einer virtuellen Maschine über die Menüfolge Systemsteuerung > Software reparieren oder ändern, schlägt das Installationsprogramm fehl und führt ein Rollback mit dem Fehler Schwerwiegender Fehler während der Installationdurch. In dieser Version wurde die Option zum Reparieren über die Menüfolge Systemsteuerung > Software entfernt. Stattdessen müssen Sie setup.exedirekt von dem Originalmedium ausführen, das für eine Neuinstallation verwendet wurde.

VMware High Availability (HA)

  • ESX Server 3i-Installationen stehen keine Inodes mehr zur Verfügung und sie reagieren nicht mehr auf den VirtualCenter Server<br/> In vorherigen Versionen konnte es dazu kommen, dass es nach einer bestimmten Zeit möglicherweise keine freien Inodes mehr für den ESX Server 3i verfügbar sind und der ESXi Server 3i-Host möglicherweise nicht mehr auf den VirtualCenter Server und den VI-Client reagiert, wenn ein ESXi Server 3i-Host in einem HA-aktivierten Cluster vom VirtualCenter-Netzwerk isoliert und dann erneut mit diesem Netzwerk verbunden wird.

Migration

  • Virtuelle Maschine wird ausgeschaltet, wenn VMotion fehlschlägt<br/> Wenn aufgrund einer hohen arbeitsspeicherintensiven VM-Last oder eines ähnlichen Problems VMotion fehlschlägt, wird die virtuelle Maschine möglicherweise ausgeschaltet. Dieses Problem wurde in der vorliegenden Version behoben, damit virtuelle Maschinen auf dem Quellhost weiterhin funktionieren können, falls VMotion fehlschlägt.

Sonstiges

  • UserDuct_Open schlägt beim Crossdup mit VMK_WOULD_BLOCK oder mit "Waiters List Not Empty"-Warnungen fehl (KB 1004385)

  • ESX Server startet nicht und zeigt auf manchen ASUS-Systemen einen violetten Bildschirm an<br/> Gemäß ACPI-Spezifikation müssen Datenformate, die von den Methoden _PRSund _CRSzurückgegeben werden, für alle Interrupt-Link-Geräte übereinstimmen, von denen sie implementiert werden. Falls das BIOS fälschlicherweise unterschiedliche Formate implementiert, startet der ESX Server möglicherweise nicht und zeigt einen violetten Bildschirm an. Der Fix erkennt Inkonsistenzen in Datenformaten, ignoriert die fehlerhafte Informationen und lässt das System starten.

  • Dateiberechtigungsprobleme beim Lesen von Auslagerungsdateien unter NFS<br/> Die Dateiberechtigungsprobleme wurden in dieser Version behoben.

  • Arbeitsspeicher wird von im Leerlauf befindlichen virtuellen Maschinen zurückgewonnen, obwohl freier Arbeitsspeicher zur Verfügung steht<br/> In einer Konfiguration, die mehrere virtuellen Maschinen mit sehr viel Arbeitsspeicher enthält, wird Arbeitsspeicher von im Leerlauf befindlichen virtuellen Maschinen zurückgewonnen, obwohl freier Arbeitsspeicher zur Verfügung steht. Dieses Problem wurde in der vorliegenden Version behoben.

  • Konfigurationsdaten gehen bei einem Neustart verloren<br/> Wenn die /-Partition von ESX Server 3i Version 3.5 voll ist, gehen bei einer Änderung der Konfigurationsdatei esx.confdurch einen Befehl alle Konfigurationsdaten verloren. Wenn beispielsweise das Dateisystem voll ist, führen alle Versuche, die vSwitch-Konfiguration zu ändern, dazu, dass alle Konfigurationsdaten verloren gehen. Infolgedessen fällt nach einem Neustart das Netzwerk aus. In dieser Version von ESX Server 3i wurde das Problem behoben, sodass in einem solchen Fall keine Daten verloren gehen. Darüber hinaus wird eine Fehlermeldung angezeigt, die besagt, dass das Dateisystem voll ist.

Netzwerk

  • ESX Server erkennt keine CDP-Informationen auf Intel MT- oder PT-Netzwerkkarten nach einer nativen VLAN-Änderung (KB 1006379)

  • ESX-Host fällt aus, wenn seine verfügbaren TCP/IP-Sockets ausgeschöpft sind und ein NFS-Client ein gemountetes Verzeichnis hat.

  • TSO-Frames sind auf allen tg3-Netzwerkkarten deaktiviert<br/> Es gibt bei tg3-Netzwerkkarten schon lange Probleme mit TSO-Frames (TCP Segmentation Offload) und deren Implementierung bietet keine wesentliche Leistungssteigerung. Ab dieser Version sind auf allen tg3-Netzwerkkarten TSO-Frames deaktiviert.

  • ESX Server antwortet möglicherweise nicht, wenn die bnx2-Netzwerkkarte von NetWatchDog zurückgesetzt wird<br/> Wenn die bnx2-Netzwerkkarte von NetWatchDogzurückgesetzt wird, schlägt die bnx2-Initialisierung fehl. Diese Version von ESX Server enthält einen Fix, der das Zurücksetzen der Netzwerkkarte stoppt, wenn die Initialisierung nach fünf Versuchen von NetWatchDogfehlschlägt, und zeigt eine Meldung ähnlich der Folgenden an:<br/> Jul 15 10:17:09 prme-stg270 VMkernel: 0:00:12:51.090 cpu12:1127)<5>bnx2: giving up resetting vmnic1 initialization failed 4 times

  • Übermäßige serielle Protokollierung in großen PCPU-Systemen kann zu einem Ausfall von ESX Server-Hosts mit Meldungen auf einem violetten Bildschirm führen<br/> Im Falle einer übermäßigen seriellen Protokollierung in großen PCPU-Systemen kann es zu Ausfällen von ESX Server-Hosts und Meldungen auf einem violetten Bildschirm kommen. Diese Version von ESX Server ändert das Verhalten der seriellen Protokollierung von ESX Server-Hosts. Die serielle Protokollierung ist standardmäßig aktiviert. Die Option logSynchronouswurde in VirtualCenter Server entfernt. Diese Option finden Sie unter VirtualCenter > Konfiguration > Erweiterte Einstellungen > VMkernel > Starten > logSynchronous. Sie können die serielle Protokollierung jetzt aktivieren bzw. deaktivieren wie folgt:

    • Von VirtualCenter Server aus: Legen Sie den Wert der Option Misc.LogToSerialauf einen entsprechenden Wert fest. Diese Option finden Sie unter VirtualCenter > Konfiguration > Erweiterte Einstellungen > Sonstiges.
    • Von ESX Server aus: Führen Sie den folgenden Befehl von der Servicekonsole aus aus:
      esxcfg-advcfg –s <value> /Misc/LogToSerial

  • Systeme mit einer Intel igb-Karte generieren eine große Anzahl von Interrupts pro Sekunde<br/> In dieser Version wurde dieses Problem behoben. Mit diesem Fix werden Systeme mit Intel igb-Karten standardmäßig im dynamisch konservativen Modus ausgeführt und diese weisen eine niedrigere Rate von Interrupts pro Sekunde auf. Außerdem ist die TCP-Durchsatzleistung optimal.

  • Der Befehl esxcfg-firewallgibt einen Panikfehler aus, wenn beim Öffnen mehrerer Ports falsche Eingabe angegeben wird. Dieses Problem wurde in der vorliegenden Version behoben.

  • Neue Befehlsoptionen wurden eingeführt, um den Wert von maxActive-Uplinks festzulegen und abzurufen<br/> Mit dieser Version von ESX Server gibt es neue Optionen für den Befehl esxcfg-vswitch. Diese Optionen sind -Xund -xund ermöglichen das Setzen bzw. Abrufen des Werts für maxActive.

  • Ein ESX Server, der auf einem Dell 6650-Server mit BCM5700-Netzwerkkarten installiert ist, antwortet möglicherweise nicht und zeigt einen violetten Bildschirm an.

  • NetQueue ist standardmäßig deaktiviert in unm_nic<br/> In ESX Server 3.5 Update 5 ist NetQueue im NetXen-Treiber standardmäßig deaktiviert. VMware unterstützt NetQueue auf dem NetXen-Treiber zurzeit nicht.

  • Behebt ein Pufferbeschädigungsproblem, das in hostd auftritt, wenn gleichzeitig mehrere Clients eine Verbindung mit einem ESX Server-Host herstellen.

  • Linux-Gastbetriebssysteme verlieren die Netzwerkkonnektivität nach einem VMware Tools-Upgrade<br/> Wenn VMware Tools auf einem Linux-Gastbetriebssystem aktualisiert wird, verliert das Gastbetriebssystem die Netzwerkkonnektivität. Nach dem Upgrade stoppt das Gastbetriebssystem den Netzwerkdienst und startet den Dienst nicht automatisch neu. Dieses Problem tritt auch bei einem automatischen Upgrade von VMware Tools auf Linux-Gastbetriebssystemen auf.

  • Diese Version von ESX Server unterstützt den Befehl esxcfg-nic -afür BCM5715S-Netzwerkkarten in ESX Server 3.5

  • Der Firewall-Dienst wird gestoppt, wenn das System in den Einzelbenutzermodus versetzt wird<br/> Wenn das System im Einzelbenutzermodus ausgeführt wird, werden alle netzwerkverwandten Dienste, darunter auch die Firewall-Dienste, gestoppt. Der Firewall-Dienst und alle anderen netzwerkverwandten Dienste werden automatisch neu gestartet, wenn das System wieder in den Mehrbenutzermodus versetzt wird.

  • ESX Server fällt mit Exception 14in world vsi_traverseaus, wenn der Befehl vm-supportausgeführt wird.

Sicherheit

  • Diese Update-Version befasst sich nicht mit neuen Sicherheitsproblemen. Sie enthält alle bereits veröffentlichen Sicherheits-Fixes.

Serverkonfiguration

Speicher

  • Die aktualisierte RDM-Größe wird auf der virtuellen Maschine nicht angezeigt<br/> In früheren Versionen von ESX Server wurde die aktualisierte RDM-Größe nur dann auf virtuellen Maschinen angezeigt, nachdem der ESX Server neu gestartet wurde. Ab dieser Version wird die aktualisierte RDM-Größe in den virtuellen Maschinen angezeigt, indem eine erneute Prüfung der LUN durchgeführt wird. Der ESX Server muss nicht neu gestartet werden.

  • In dieser Version wird ein Problem behoben, bei dem während eines Snapshot-Vorgangs virtuelle Maschinen möglicherweise ausgeschaltet werden, wenn auf dem Speicher, wo sich die virtuellen Maschinen befinden, ein Pfad-Failover auftritt.

  • Ein Failover tritt möglicherweise bei Microsoft-Clustern in CIB-Konfiguration aufgrund der VMFS-Aktivität auf<br/> In einer CIB-Konfiguration (Cluster-in-a-box) tritt aufgrund von Reservierungskonflikten, die aus VMFS-Vorgängen entstehen, die von einem anderen Host durchgeführt werden, der dasselbe Volume gemeinsam nutzt, möglicherweise ein Failover auf. Wenn der Konflikt auftritt, werden im Windows-Ereignisprotokoll SCSI-Fehler protokolliert.

  • Eine Beschädigung des VMFS-Taktsignals tritt in den VMFS-Volumes auf und führt zu VM-Ausfällen<br/> Wenn in vorherigen Versionen eine Beschädigung des VMFS-Taktsignals in den VMFS-Volumes aufgetreten ist, konnten die virtuellen Maschinen möglicherweise nicht eingeschaltet werden. Die erwarteten Meldungen, die auf eine Beschädigung des VMFS-Taktsignals für das VMFS-Volume hindeuten, wurden jedoch nicht in den VMkernel-Protokolldateien protokolliert. In ESX 3.5 Update 5 werden Protokollmeldungen ähnlich den Folgenden in den VMkernel-Protokolldateien protokolliert:

    Mar 24 17:06:25 blr-2nd-1-dhcp274 vmkernel: 0:01:34:08.655 cpu4:1039)WARNING: FS3: ReadHostPulse:1017: FS 49c2390a-1976a3cb-1449-001aa0ae5b61 may be damaged.<br/> Mar 24 17:06:25 blr-2nd-1-dhcp274 vmkernel: 0:01:34:08.666 cpu4:1039)WARNING: FS3: ReadHostPulse:1028: Corrupt heartbeat detected at offset 0x3b9e00: [state 0 offset 0 gen 0 owner 00000000-00000000-0000-000000000000 journalAddr 0

    Wenden Sie sich an den VMware-Support, wenn Sie diese Protokollmeldungen klären möchten.

  • Wenn ein Benutzer die Zuordnung von einigen LUNs aus EMC Invista- oder EMC DGC-Speicher-Arrays aufhebt und die LUNs auf ESX-Hosts erneut prüft, wird die folgende Warnmeldung angezeigt: D:0x0/H:0x0 0x0 0x0 0x0. Diese Warnmeldung wurde in ESX 3.5 Update 5 behoben.

  • Die vport-Anzahl ist inkonsistent, wenn mehrere mehrfach-NPIV-konfigurierten virtuellen Maschinen gleichzeitig gestartet werden<br/> Dieses Problem tritt auf, weil die virtuellen Ports nicht für alle virtuellen Maschinen erstellt werden. In dieser Version von ESX Server wird die Inkonsistenz in der Anzahl der auf dem proc-Knoten erstellten virtuellen Ports behoben.

  • Eine Wettlaufsituation in der DentryCache-Initialisierung führt dazu, dass das System mit einem violetten Bildschirm ausfällt.

  • Zeitüberschreitung bei VMotion auf ESX Server-Hosts, die über eine große Anzahl von inaktiven VMFS-Volumes verfügen<br/> VMotion schlägt möglicherweise fehl auf ESX Server-Hosts, die viele inaktiven VMFS-Volumes haben. Zudem könnte es lange dauern, bis die virtuellen Maschinen auf solchen Hosts eingeschaltet werden.

  • Der aktive Pfad kann nicht als OFF markiert werden, wenn ein aktiver E/A-Vorgang auf dem Zielspeicher-Array durchgeführt wird<br/> In früheren Versionen von ESX Server können Sie jederzeit die aktiven Speicherpfade als OFF markieren, indem Sie den Befehl esxcfg-mpathvon der Servicekonsole des ESX Server-Hosts, dem VI-Client oder dem VirtualCenter Server ausführen. Ab ESX 3. 5 Update 5 kann der aktive Pfad nicht als OFF markiert werden, wenn ein aktiver E/A-Vorgang auf dem Zielspeicher-Array durchgeführt wird oder wenn es eine aktive Reservierung auf dem Speicherpfad gibt. Die nicht aktiven Pfade dürfen jedoch jederzeit als OFF markiert werden.

Upgrade und Installation

  • Die ESX Server 3i-DCUI (Direct Console User Interface) schlägt fehl, wenn Sie durch Drücken der ESC-Taste den Management-Netzwerktest unterbrechen und ihn dann wieder ausführen.

VirtualCenter, VI-Client und Web Access

  • "Angeforderter Registrierungszugriff ist nicht zulässig" wird angezeigt, wenn ein Benutzer ohne Administratorrechte versucht, den VI-Client zu starten (KB 1009284)

  • Das Konfigurieren einer Portgruppe zur Verwendung der Richtlinien "Anhand des IP-Hashs routen" und "Signalprüfung" verursacht doppelte Pakete<br/> Vor dieser Version führte das Konfigurieren einer Portgruppe zur Verwendung der Richtlinie "Anhand des IP-Hashs routen" für den Lastenausgleich sowie der Richtlinie "Signalprüfung" für die Netzwerk-Failover-Ermittlung zu doppelten Paketen. Ab dieser Version lässt der VI-Client eine solche Konfiguration nicht zu und zeigt die folgende Fehlermeldung an:<br/> Das gleichzeitige Einstellen der Netzwerk-Failover-Ermittlung auf "Signalprüfung" und des Lastenausgleichs auf "Anhand des IP-Hashs routen" ist keine gültige Konfiguration. Ändern Sie Ihre Einstellungen.<br/> Es gibt allerdings einige Ausnahmefälle, in denen eine Portgruppe eine Richtlinieneinstellung erben kann, und deshalb die Richtlinien "Anhand des IP-Hashs routen" und "Signalprüfung" gleichzeitig für die Portgruppe aktiviert sind.

  • Beim Download einer großen Datei mit dem Datenspeicherbrowser oder beim Exportieren einer virtuellen Appliance nach OVF tritt ein E/A-Fehler auf<br/> In früheren Versionen wurde beim Download oder Upload einer großen Datei unter Verwendung des Datenspeicherbrowsers möglicherweise ein E/A-Fehler angezeigt. Dieses Problem tritt auch auf, wenn eine virtuelle Appliance nach OVF exportiert wird.

  • VI Client zeigt eine große Anzahl an Protokollmeldungen an, die den Text "DiagnosticMgr.Browse" in den hostd-Protokollen enthalten<br/> Wenn Sie mit dem VI-Client eine direkte Verbidung zu einem ESX Server-Host herstellen und unter Verwaltung > Systemprotokolle auf Alle anzeigen klicken, wird in den hostd-Protokollen möglicherweise eine große Anzahl an Protokollmeldungen mit dem Text DiagnosticMgr.Browseangezeigt. Dieses Problem tritt aufgrund eines Fehlers in der Berechnung des Protokollendes durch den VI-Client auf. Dieses Problem wurde in dieser Version behoben.

Verwaltung von virtuellen Maschinen

  • In einem bestimmten Fall, wenn virtuelle Maschinen auf dem ESX Server-Host für autostart/autostop konfiguriert sind, antwortet der Host beim Herunterfahren möglicherweise nicht mehr. Das für das automatische Starten und Stoppen von virtuellen Maschinen zuständige Skript wurde in dieser Version von ESX Server geändert, um dieses Problem zu beheben.

  • In dieser Version von ESX Server wurde ein Problem behoben, wobei unmittelbar nach dem Verschieben von virtuellen Maschinen zwischen ESX Server-Hosts mithilfe von VMotion die Leistung der virtuellen Maschinen für kurze Zeit nachlässt.<br/> Dieses Problem könnte unter dem folgenden Szenario auftreten:

    • Ein Gastbetriebssystem verwendet häufig große Seitendateien
    • Virtuelle Maschinen lagern bereits Dateien ein und aus, bevor VMotion gestartet wird

Seitenanfang

Bekannte Probleme

In diesem Abschnitt werden bekannte Probleme dieser Version von ESX Server beschrieben. Diese Probleme sind in die folgenden Bereiche aufgegliedert:

CIM und API

  • Auf einem NEC Express 5800 140Ba-10-Server beansprucht der cimprovagt- oder der cimserver-Vorgang bis zu 99 % von CPU 0 auf dem COS. Dadurch können die verbleibenden Anwendungen, darunter auch snmpd, nicht ausgeführt werden.

  • 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 oder höher kann eine CallMethod-Abfrage auf einer CIM_RecordLog-Instanz manchmal fehlschlagen. Sie können jedoch das Systemereignisprotokoll über eine Remote-Managementkonsole oder -schnittstelle löschen.

  • Manche CIM-Klassen funktionieren nicht ordnungsgemäß auf IBM Multinode-Systemen
    Bei den folgenden Klassen gibt der Vorgang EnumerateInstances()eine Instanz weniger als der Vorgang EnumerateInstanceNames()zurück:

    • CIM_AssociatedSensor
    • CIM_MemberOfCollection

    Bei den folgenden Klassen schlägt der Vorgang GetInstance()bei einigen Instanzen fehl. Jedoch ist die Operation EnumerateInstances()erfolgreich:

    • CIM_HostedService
    • CIM_Sensor
    • CIM_SystemDevice
    • CIM_Slot
    • CIM_ElementConformsToProfile

    Die Operationen EnumerateInstances()und EnumerateInstanceNames()geben für die folgenden Klassen 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.
  • In ESX Server 3.5 wird die nachfolgende Fehlermeldung ausgegeben, wenn für numerische Stromversorgungssensoren die Operation Reset()aufgerufen wird:
    CIM_ERR_FAILED: index out of bounds
    Workaround: Verwenden Sie den Vorgang RequestStateChange(Reset).
  • 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.

  • InvokeMethod(RequestPowerStateChange)und InvokeMethod(RequestStateChange)schlagen fehl, wenn Sie das WS-Man-Protokoll verwenden

Gastbetriebssysteme

  • Solaris Update Manager startet nicht und zeigt im xterm-Fenster schriftartbezogene Fehler an. (KB 1013079)

  • VMware Tools installiert den SVGA-Treiber nicht automatisch im Windows XP Embedded Studio (KB 1015250)

  • Der XPDM-SVGA-Treiber von VMware Tools ist unter Windows 7 (32- und 64-Bit) und Windows 2008 R2 instabil. Daher wird dieser Treiber nicht auf virtuellen Maschinen installiert, die diese Gastbetriebssystemversionen ausführen. Wenn Sie auf diesen Betriebssystemen auf die aktuelle Version von VMware Tools aktualisieren, wird auch der SVGA-Treiber entfernt, sofern er vorhanden ist.

  • Die Energiesparoption in der Liste der Optionen für das Herunterfahren in Windows 7 ist nicht verfügbar<br/> In einer virtuellen Windows 7-Maschine steht die Energiesparoption in der Liste der Optionen für das Herunterfahren nicht zur Verfügung, weil der XPDM-SVGA-Treiber in diesen Gastbetriebssystemversionen von VMware Tools nicht installiert wird. Der Standard-Vesa-Treiber ist enthalten, aber dieser unterstützt die Energiesparfunktion nicht.

  • Windows-Gastbetriebssysteme werden möglicherweise aus dem Standby- oder Ruhezustandsstatus heraus nicht mehr fortgesetzt
    Virtuelle Maschinen mit auf Windows Server 2008 und Windows Server 2003 basierten Gastbetriebssystemen im Standby- oder Ruhezustandsstatus reagieren gegebenenfalls nicht mehr, wenn sie aus dem Standby- oder Ruhezustandsstatus heraus fortgesetzt werden sollen.
    Vgl. KB 946331 auf der Microsoft Support-Website.

  • Nach der Installation von VMware Tools auf SUSE Linux Enterprise Server 10 mit SP3 kann VMware Tools möglicherweise den schnellen vmxnet-Netzwerkdienst nicht starten.<br/> Umgehung:Führen Sie die folgenden Aufgaben aus:

    1. Beantworten Sie während der Installation von VMware Tools die folgende Frage mit NEIN:<br/> Vor der ersten Ausführung der VMware Tools müssen Sie diese mit dem folgenden Befehl konfigurieren: "/usr/bin/vmware-config-tools.pl". Soll dieses Programm jetzt den Befehl für Sie ausführen?

    2. Führen Sie nach der Installation der VMware Tools den folgenden Befehl aus:<br/> vmware-config-tools.pl --compile

  • Für x64-basierte Versionen von Windows Vista- und Windows Server 2008-Gastbetriebssystemen ist ein Microsoft-Hotfix erforderlich
    Bei x64-basierten Versionen von Windows Vista- und Windows Server 2008-Gastbetriebssystemen ohne Microsoft-Hotfix (http://support.microsoft.com/kb/950772) kann die Situation eintreten, dass das Gastbetriebssystem nicht mehr reagiert und den folgenden Fehler zurückgibt:
    MONITOR PANIC: vcpu-3:ASSERT vmcore/vmm/cpu/segment.c:430
  • Der Cursor verschwindet nach dem Konfigurieren von VMware Tools

    Dieses Problem ist bei ESX Server 3.5 Update 4 mit SUSE Linux Enterprise Server 8-Gastbetriebssystemen (mit und ohne SP4) aufgetreten. Nach dem Konfigurieren von VMware Tools ist der Mauszeiger sofort unsichtbar.

    Umgehung:Starten Sie die virtuelle Maschine neu.

Internationalisierung

 

Sämtliche Felder im VI-Client und in Web Access bieten 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. Anderenfalls schlägt die Installation von VirtualCenter Server fehl.
  • Verwenden Sie für alle Komponenten den im Installationsprogramm standardmäßig vorgegebenen Installationspfad. Nehmen Sie keine Pfadnamen mit Nicht-ASCII-Zeichen und Zeichen des erweiterten ASCII-Zeichensatzes in den Installationspfad auf.
  • Datenspeichernamen, Namen virtueller Netzwerke und Image-Dateinamen (CD, DVD und Diskettenlaufwerk) dürfen ausschließlich ASCII-Zeichen umfassen.
  • 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 Nicht-ASCII-Zeichen enthalten: Hostnamen, Arbeitsgruppennamen, Domänennamen, URLs, E-Mail-Adressen, SMTP-Servernamen und SNMP-Community-Namen.
  • 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 Guided Consolidation 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.

Weitere 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 Server möglicherweise nicht ordnungsgemäß angezeigt, wenn die Host-Betriebssystemsprachen von Virtual Infrastructure-Client und VirtualCenter Server/Datenbank nicht übereinstimmen.
  • In der Version von VI Web Access für "Chinesisch (vereinfacht)" wird der falsche Text auf der Schaltfläche Abbrechen angezeigt.
  • Das Herstellen einer Verbindung mit einem ESX Server 3.5 Update 2-Host über VirtualCenter aktualisiert einen lokalisierten VI-Client nicht
    Wenn Sie eine Verbindung mit einem ESX Server 3.5 Update 2-Host über VirtualCenter herstellen, wird der verwendete lokalisierte VI-Client nicht auf Update 2 aktualisiert.
  • 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.
    Im Assistenten für die Neuinstallation wird der folgende Text angezeigt:
    Der Installations-Assistent ermöglicht Ihnen, Virtual Infrastructure Client 2.5 zu reparieren oder zu entfernen.Stattdessen sollte der Assistent die folgende Meldung bringen: 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 VMware Web Access den Datenspeicher durchsuchen, indem Sie auf einen Link mit maschinengenerierten 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.
  • Die Namen von virtuellen Maschinen, die Nicht-ASCII-Zeichen enthalten, werden möglicherweise nicht korrekt angezeigt, wenn Web Access für den Zugriff auf den ESX Server verwendet wird.

Migration

  • Storage VMotion mit einer großen Anzahl von virtuellen Festplatten schlägt fehl
    Die gleichzeitige Migration einer großen Anzahl von virtuellen Festplatten mit Storage VMotion schlägt möglicherweise fehl. Folgende Fehlermeldung wird angezeigt:
    Received an error from the server: A general system error occurred: failed to reparent/commit disk(s) (vim.fault.Timedout)
    Umgehung:
    Um eine virtuelle Maschine mit einer großen Anzahl von virtuellen Festplatten zu migrieren, migrieren Sie die Festplatten wie folgt in Batches:
    1. Migrieren Sie die Konfigurationsdatei der virtuellen Maschine und eine Teilmenge der virtuellen Festplatten (nicht mehr als 5 gleichzeitig) vom ursprünglichen Speicherort zum Zielspeicherort.
    2. Migrieren Sie die Konfigurationsdatei der virtuellen Maschine wieder zurück zum ursprünglichen Speicherort.
    3. Wiederholen Sie die Schritte 1 bis 2, bis alle virtuellen Maschinenfestplatten und die Konfigurationsdatei der virtuellen Maschine zum Zielspeicherort migriert wurden.
  • Die Migration mit VMotion bei hoher Arbeitsspeichernutzung schlägt möglicherweise mit einer "Zeitüberschreitung" fehl
    Eine Migration mit VMotion auf einer virtuellen Maschine bei hoher Arbeitsspeichernutzung und bei Verwendung einer Auslagerungsdatei, die sich in einem alternativen Datenspeicher (einem anderen Datenspeicher als der für die virtuelle Maschine) befindet, funktioniert möglicherweise nicht immer und kann mit der VirtualCenter-Fehlermeldung Zeitüberschreitung.
    fehlschlagen

Sonstiges

  • Das Converter Enterprise Client-Plug-In muss nach dem Upgrade installiert und aktiviert sein
    VirtualCenter Server 2.5 Update 2 unterstützt nicht die früheren Versionen des Converter Enterprise Client-Plug-Ins. Deshalb müssen Sie das Converter Enterprise Client-Plug-In nach dem Upgrade auf VirtualCenter Server 2.5 Update 2 installieren und aktivieren. Um das Converter Enterprise Client-Plug-In zu installieren und aktivieren, wählen Sie im Menü Plug-Ins die Option Plug-Ins verwalten. Wählen Sie im Fenster Plug-In-Manager die Registerkarte Verfügbar und klicken Sie auf Herunterladen und installieren.
  • Systemstatus für einige IPMI-Sensoren zeigt "Unbekannt" an, wenn Multinode IBM System x3950 M2 Server mit hoher CPU-Nutzung ausgeführt wird
    Wenn ein Multinode IBM System x3950 M2 Server mit hoher CPU-Nutzung mehr als 80 virtuelle Maschinen hostet, wird einige Minuten lang für manche IPMI-Sensoren, wie z. B. Prozessor-, Arbeitsspeicher-, Speicher-, Betriebs-, System-, Gehäuse- und Watchdog-Sensoren, als Systemstatus "Unbekannt" angezeigt.
    Klicken Sie zum Anzeigen der Seite "Systemstatus" im VI-Client auf den Link Systemstatus unter der Registerkarte Konfiguration im VI-Client.
    Umgehung
    Klicken Sie zum Aktualisieren des Sensorstatus auf der Systemstatusseite auf den Link Aktualisieren. Die Aktualisierung dauert etwa 10 Minuten.
  • VI-Client zeigt den Systemstatus von IBM x Series-Servern mit LSI 1078 als "Alarm" an, wenn der Status der Sensoren nicht als "Alarm" angezeigt wird.
    VI-Client zeigt den Systemstatus von IBM System x3850 M2/x3950 M2-Servern mit dem LSI 1078 IR SAS-Controller in Rot ("Alarm") an, wenn die Sensoren und Unterkomponenten nicht rot angezeigt werden.
    Klicken Sie zum Anzeigen der Seite "Systemstatus" im VI-Client auf den Link Systemstatus unter der Registerkarte Konfiguration im VI-Client.
    Umgehung
    Installieren Sie die neueste, von IBM erhältliche Firmware (Version 01.25.82.00 oder höher) für den LSI 1078 IR SAS-Controller.
  • Eine ESX Server-Webschnittstelle zeigt den neuesten Datensatz des IPMI-Systemereignisprotokolls möglicherweise nicht an
    Wenn das IPMI-Systemereignisprotokoll bereinigt wird, sind die IPMI-Systemereignisprotokolleinträge, die über die ESX Server-Webschnittstelle unter https://<IP-Adresse des ESX Server-Hosts>/host/ipmi_selabgerufen werden, möglicherweise nicht die neuesten Datensätze des IPMI-Systemereignisprotokolls.

Netzwerk

  • Die Netzwerkkonnektivität geht auf manchen Intel-Netzwerkkarten nach einem Neustart des ESX Servers verloren (KB 1015620)

  • Wenn ESX Server mit einer Kickstart-Datei installiert wird, werden nach dem Neustart die Firewall-Regeln zurückgesetzt<br/> Wenn Sie ESX Server mit einer Kickstart-Datei installieren, in der Authentifizierungsserver, wie z. B. NIS und Active Directory, angegeben sind, werden die Firewall-Regeln für diese Server nicht gespeichert. Nach einem Neustart werden die Firewall-Regeln auf die Standardregeln zurückgesetzt. Eine Umgehung finden Sie unter KB 1001154.

  • ESX Server unterstützt nicht mehr als eine vmknic auf demselben Subnetz. (KB 1013077)

  • Link- und Unlink-Vorgänge auf dem vSwitch aktualisieren die Gruppierungsrichtlinie des vSwitches dort, wo sich die Portgruppe befindet, nicht ordnungsgemäß<br/> Wenn eine Portgruppe zusammen mit einer NIC-Gruppierungsrichtlinie angegeben wird (anstatt die Richtlinie von dem vSwitch zu übernehmen), wird ein Link- oder Unlink-Vorgang auf dem vSwitch (durch Ausführung des Befehls esxcfg-vswitch -L/-U <vmnicX> <vSwitchY>) die Gruppierungsrichtlinie des vSwitches, wo sich die Portgruppe befindet, nicht ordnungsgemäß aktualisieren. Der Status ("Aktiv" oder "Standby") der Uplinks wird im VI-Client möglicherweise nicht korrekt angezeigt. Die Anzahl der aktiven Links entspricht der in der Einstellung des ursprünglichen Gruppierungsrichtlinie der Portgruppe angegebenen Anzahl.

  • NetXen P2-Karten unterstützen maximal 128 GB RAM auf einer Maschine (KB 1009386)
  • Die ESX Server-Hosts reagieren bei einem Broadcast Storm im Netzwerk nicht mehr

    Wenn ein Broadcast Storm im Netzwerk auftritt, reagieren die ESX Server möglicherweise aufgrund eines Problems mit dem tg3-Netzwerktreiber nicht mehr. Während dieses Zeitraums verfügen Servicekonsolen oder virtuelle Maschinen, die den tg3-NIC verwenden, über keine Verbindung zum Netzwerk mehr. Durch einen Neustart des Computers oder durch das Ent- und Neuladen des Treibers kann die Verbindung wiedergeherstellt werden. Dies behebt aber nicht das Problem.

    ESX-Hosts mit dem tg3-Port können keine Pakete senden und empfangen, wenn Sie einem Broadcast Storm ausgesetzt waren. Folgende Fehlermeldungen werden in diesem Fall in VMkernel protokolliert:

    1. WARNING: Net: 1082: Rx storm on 1 queue 3501>3500, run 321>320
    2. VMNIX: WARNING: NetCos: 1086: virtual HW appears wedged (bug number 90831), resetting
  • Doppelte Pakete werden erstellt, wenn Signalprüfung mit VLAN-Typ 4095 verwendet wird
    Während eines Netzwerkvorgangs einer virtuellen Maschine, bei dem die VLAN-ID auf 4095 gesetzt wird und der dazugehörige vSwitch mit einer Signalprüfung konfiguriert ist, werden doppelte Pakete erstellt.
    Umgehung: Bei der Verwendung einer VLAN-ID von 4095, legen Sie für "Netzwerk-Failover-Ermittlung" die Option "Nur Verbindungsstatus" statt "Signalprüfung" fest. ( KB 1004373)
  • Die Informationen zur Netzwerkkonfiguration auf der direkten Konsole sind möglicherweise inkonsistent
    Wenn Sie auf ESX Server 3i-Hosts F2 > Network Adapter wählen, um die Informationen zur Netzwerkkonfiguration anzuzeigen, zeigt die Benutzerschnittstelle für eine Netzwerkkarte manchmal die MAC-Adresse und manchmal andere Identifizierungsinformationen für die Karte an.
  • Erweitertes netperf-Testen schlägt für IPv6 fehl
    Eine hohe Arbeitsbelastung über 12 Stunden hinweg unter Verwendung von "netperf" auf virtuellen Maschinen mit Internet Protocol Version 6 (IPv6) kann dazu führen, dass Sockets heruntergefahren werden. Folgende Sockets sind davon betroffen: TCP_STREAM, UDP_STREAM, TCP_RR und UDP_RR. Möglicherweise werden Fehlermeldungen ähnlich der Folgenden auf der Konsole der virtuellen Maschine angezeigt:

    send_tcp_rr: data recv error: Connection timed out
    netperf: cannot shutdown tcp stream socket: Transport endpoint is not connected
    Dies ist ein bekanntes Problem.
  • Wake-on-LAN (WOL) wird bei einigen NetXen-Netzwerkkarten nicht unterstützt

    Wake-on-LAN (WOL) wird bei einigen NetXen-Netzwerkkarten nicht unterstützt. Wenn jedoch der Befehl # ethtool vmnic*in der Servicekonsole ausgeführt wird, wird angezeigt, dass Wake-on-LAN für alle NetXen-Netzwerkkarten unterstützt wird.

    Umgehung:Verwenden Sie eine Netzwerkkarte, die WOL unterstützt.
  • Auch wenn ein NetXen-Gerät keinen Datenverkehr hat, zeigt es die Geschwindigkeit 65536 und Halbduplex an
    Dieses Problem tritt auf, wenn ein beschädigtes Tx-Paket empfangen wird: NetXen gibt den Statusfehler -1zurück und die Hardware, die Firmware oder beide werden abgebrochen. Dies ist ein bekanntes Problem im NetXen-Treiber.

    Umgehung: Entladen Sie den NetXen-Treiber und laden Sie ihn anschließend neu.
  • Die Netzwerkverbindung geht verloren, wenn die Geschwindigkeit der Netzwerkkarte auf einem NetXen-Treiber manuell konfiguriert wird

    Das manuelle Konfigurieren der Geschwindigkeit anhand von esxcfg-nicsoder eines anderen Befehls auf einer NetXen 3031-Netzwerkkarte kann dazu führen, dass die Netzwerkverbindung getrennt wird. NetXen-Netzwerkkarten unterstützen nicht das manuelle Einstellen der Geschwindigkeit. Die Geschwindigkeit muss durch automatische Aushandlung festgelegt werden.

Serverkonfiguration

  • Der ypbind-Dienst (NIS) startet nicht nach dem Startvorgang des Servers<br/> Der ypbind-Dienst startet nicht nach dem Starten des ESX Server, obwohl ypbindstandardmäßig aktiviert ist. Dies kann passieren, wenn entweder der portmap- oder der ypbind-Dienst nicht ordnungsgemäß konfiguriert ist, um zur Startzeit zu starten. Fehlerbehebungstipps und Lösungen finden Sie unter KB 1015289.

  • Fehlermeldung beim Starten der IBM x3850 M2- und x3950 M2-Server
    Auf den IBM x3850 M2- und x3950 M2-Servern wird beim Starten möglicherweise eine SysAlert-Fehlermeldung ähnlich der Folgenden angezeigt:
    0:00:01:02.384 cpu19:1291)USB Control/bulk timeout; usb device may not respond
    Sie erhalten möglicherweise eine Meldung von jedem Slave-Knoten.
    Dies ist ein bekanntes Problem. Die während des Startens generierten Fehler haben keine Auswirkungen auf die normale Funktionalität des Systems und können bedenkenlos ignoriert werden.
  • Virtuelle Maschinen antworten bei einer erneuten Prüfung des ESX Server 3i Version 3.5-Hosts nicht

    Bei der Durchführung einer erneuten Hostprüfung unter ESX Server 3i Version 3.5 antworten der Host und die virtuellen Maschinen möglicherweise nicht mehr, bis die erneute Prüfung abgeschlossen ist. Während dieser Zeit geht die Verbindung zu virtuellen Maschinen verloren, einschließlich SSH- und Clientverbindungen und die Kommunikation mit anderen Speichermodulen im Cluster. Die virtuellen Maschinen reagieren wieder, sobald die erneute Prüfung abgeschlossen wurde.

    Für dieses Problem gibt es keine Umgehung.

Speicher

  • Core-Dumps gehen verloren, wenn mehrere ESX-Hosts eine Dump-Partition teilen
    Wenn mehrere ESX-Hosts, die dieselbe Dump-Partition verwenden, ausfallen und gleichzeitig Core-Dumps speichern, können die Core-Dumps verloren gehen.
  • LSI-Aufgaben und nicht verknüpfte Speicherpools werden bei Starts nicht beibehalten
    Das von LSI implementierte dauerhafte Schema erstellt auf dem Hostbetriebssystem für jede Aufgabe und jeden nicht konkreten Speicherpool (ein Speicherpool, der nicht mit einem Speichervolumen verknüpft ist) eine neue Datei. Diese Dateien werden bei Starts nicht beibehalten. Aus diesem Grund sind nicht konkrete Speicherpools nicht mehr verfügbar, nachdem das Hostbetriebssystem neu gestartet wurde. Darüber hinaus werden alle ausgeführten Aufgaben vor dem Neustart nicht angezeigt.
    Unterstützung für 10GbE IP-Speicher (iSCSI und NFS) mit den Update-Versionen dient der Konnektivität. Die Gesamtleistung kann schwanken.
  • Das Anlegen einer großen Datei in einem übergreifenden VMFS-Datenspeicher schlägt möglicherweise fehl, wenn die erste Datenspeichererweiterung kleiner als 1 GB ist
    Wenn Sie versuchen, eine große virtuelle Festplattendatei in einem übergreifenden VMFS-Datenspeicher zu erstellen, schlägt dies möglicherweise fehl. Dieses Problem tritt üblicherweise auf, wenn die erste Datenspeichererweiterung zu klein ist, d. h. weniger als 1GB. Sie wird durch einen Mangel an Zeigerblocks verursacht.
    Umgehung: Falls möglich, erstellen Sie den Datenspeicher neu, indem Sie zunächst die größere Partition verwenden und anschließend die kleineren Erweiterungen hinzufügen.
  • SAS-Festplatten-Arrays (SAS, Serial Attached SCSI) können nicht als Raw-Device-Mapping-Festplatten unter Verwendung des VI-Clients hinzugefügt werden
    Wenn Sie den VI-Client zum Erstellen virtueller Maschinen auf Raw-Device-Mapping-Festplatten verwenden oder eine Festplatte zu einer virtuellen Maschine hinzufügen, wird die Option Raw-Device-Mapping im Assistenten für neue virtuelle Maschinen und im Assistenten zum Hinzufügen von Hardware deaktiviert.
    Umgehung:So fügen Sie SAS-Festplatten-Arrays als Raw-Device-Mapping-Festplatten hinzu:
    1. Führen Sie in der ESX Server-Servicekonsole folgenden Befehl mit der angegebenen Syntax aus:
    # vmkfstools -r <raw_device_path> -a <bus_type> <RDM_file_name>
    2. Fügen Sie mit dem Assistenten zum Hinzufügen von Hardware die neu erstellte virtuelle Festplatte als vorhandene Festplatte zur virtuellen Maschine hinzu.
  • Virtuelle Maschine kann nicht auf das physische CD-ROM-Laufwerk mit Intel I/O Controller Hub 9 (ICH9) oder Intel I/O Controller Hub 10 (ICH10) zugreifen
    Dieses Problem ist bislang auf ESX Server 3i Version 3.5 Update 4 Embedded und ESX Server 3i Version 3.5 Update 4 Installable aufgetreten. Sie können vom Gastbetriebssystem aus nicht auf das physische CD-ROM-Laufwerk des Hosts zugreifen. Dieses Problem tritt auf, wenn sich beim Starten des ESX Server-Hosts keine CD im CD-ROM-Laufwerk befand. Damit von einem Gastbetriebssystem aus auf das CD-ROM-Laufwerk zugegriffen werden kann, muss sich eine CD im Laufwerk befinden, wenn der ESX Server-Host gestartet wird.

    Umgehung: Prüfen Sie den Speicheradapter nach dem Einlegen der CD erneut, indem Sie die folgenden Schritte implementieren:
    1. Melden Sie sich über den VI-Client beim ESX Server-Host an.
    2. Klicken Sie auf die Registerkarte Konfiguration.
    3. Navigieren Sie zu Speicheradapter.
    4. Klicken Sie in der oberen rechten Ecke auf Erneut prüfen....
  • Die Kapazität einer zu einem Datenspeicher hinzugefügten LUN ist möglicherweise nicht sichtbar, wenn der VI-Client mit einem ESX Server-Host verbunden wird
    Sie können im Fenster "Speicher" der Registerkarte "Konfiguration" des VI-Clients die Eigenschaften eines Datenspeichers ändern. Wenn der VI-Client mit einem ESX Server-Host verbunden wird, wird im Fenster "Eigenschaften" die Kapazität für die hinzugefügte LUN möglicherweise nicht angezeigt, wenn Sie durch Klicken von Erweiterung hinzufügen im Fenster "Eigenschaften" des Datenspeichers LUNs zu einem Datenspeicher hinzufügen.
    Umgehung: Schließen Sie das Fenster "Eigenschaften", klicken Sie auf den Link Speicher auf der Registerkarte Konfiguration und öffnen Sie das Fenster "Eigenschaften" erneut.
  • Der ESX-Host zeigt beim Zugriff auf ein optisches Gerät eine nicht kritische Fehlermeldung an
    Beim Mounten oder Kopieren eines optischen Geräts zeigt der ESX Server-Host hda: lost interruptam Bildschirm an. Diese Fehlermeldung wird möglicherweise auch in /var/log/messagesgeschrieben. Dieses Problem führt zu keinem Datenverlust und kann ignoriert werden.

Upgrade und Installation

  • Auf Dell PowerEdge Servern werden beim Systemstart gelegentlich USB-bezogene Fehlermeldungen angezeigt
    Wenn ESX Server 3i Version 3.5 auf Dell-Systemen installiert wird, wird beim Starten möglicherweise eine SysAlert-Fehlermeldung angezeigt, die der Folgenden ähnelt:

    0.00.00.34.081 cpu4:1197)Usb control/bulk timeout; usb devices may not respond

    Die während des Startens generierten Fehler haben keine Auswirkungen auf die normale Funktionalität des Systems und können bedenkenlos ignoriert werden.
  • Lokale VMFS-Volumes werden nach dem Upgrade auf ESX Server 3.5 Update 3 nicht erkannt.
    Auf Servern, die im ATA-Modus konfigurierte ICH-7 SATA-Controller mounten, erkennt der ESX Server-Host nach dem Upgrade auf ESX Server 3.5 Update 3 möglicherweise die lokalen VMFS-Volumes nicht mehr, was dazu führt, dass auf die virtuellen Maschinen, die sich auf diesen Volumes befinden, nicht mehr zugegriffen werden kann.<br/> Hinweis: Das Speichern lokaler VMFS-Volumes mit ICH7- und HT1000-Controllern wird nicht unterstützt. Weitere Informationen hierzu finden Sie unter Lokale VMFS-Volumes werden nach dem Upgrade auf ESX Server 3.5 Update 3 nicht erkannt (KB 1007724).
  • Der ESX Server 3i Version 3.5-Host zeigt beim Starten von einer Wiederherstellungs-CD Sonderzeichen an

    Der ESX Server 3i Version 3.5-Host zeigt beim Starten von einer Wiederherstellungs-CD Sonderzeichen in der Fortschritts-Kontrollanzeige des Bootloaders an. Diese Zeichen sind ungefährlich und können ignoriert werden.

ESX Server-Upgrade und -Installation

  • Das ESX Server-Installationsprogramm akzeptiert ungültige Subnetzmaske und fährt mit der Installation fort
    Wenn Sie beim Installieren von ESX Server mit dem textbasierten Modus eine ungültige Subnetzmaske eingeben, fährt das Installationsprogramm mit der Installation fort, ohne dass eine Fehlermeldung zurückgegeben wird. Im grafischen Modus der Installation zeigt das Installationsprogramm nur dann eine Fehlermeldung an, wenn der numerische Wert der eingegebenen Subnetzmaske 255 Zeichen überschreitet.

Andere Upgrade- und Installationsprobleme

  • Die Schaltfläche zum Ausschalten funktioniert manchmal in Web Access nicht
    In einigen Fällen ist die Schaltfläche zum Ausschalten für eine virtuelle Maschine nicht verfügbar oder reagiert nicht, wenn darauf geklickt wird.
    Umgehung:Aktualisieren Sie das Browserfenster. Anschließend sollte die Schaltfläche zum Ausschalten ordnungsgemäß funktionieren.
  • Upgrade von VirtualCenter und VMware Update Manager schlägt möglicherweise beim Aktualisieren der Update Manager-Datenbank fehl
    Sie können mit dem einheitlichen Installationsprogramm VirtualCenter und VMware Update Manager gleichzeitig aktualisieren, dabei können jedoch Probleme mit benutzerdefinierten Datenbankkonfigurationen auftreten. VirtualCenter und VMware Update Manager können Informationen in einer einzigen Datenbank oder in getrennten Datenbanken speichern. Wenn Ihre Bereitstellung getrennte Datenbanken aufweist und Sie während des Upgrades die Option "Benutzerdefiniert" nicht verwendet haben, wird die VMware Update Manager-Datenbank möglicherweise nicht aktualisiert. Stattdessen kann eine der folgenden zwei Situationen eintreten:
    • Wenn in der VirtualCenter-Datenbankinstanz keine Update Manager-Datenbank vorhanden ist, wird eine neue Update Manager-Datenbank erstellt.
    • Wenn eine bestehende, aber nicht genutzte Update Manager-Datenbank vorhanden ist, wird diese aktualisiert. Ungenutzte Update Manager-Datenbanken können auftreten, wenn die erste Installation abgeschlossen ist und anschließend eine separate Update Manager-Datenbank erstellt wird.
    In beiden Fällen wird die benutzerdefinierte Update Manager-Datenbank, die verwendet wurde, nicht aktualisiert. Nach dem Upgrade verwendet das System die falsche Datenbank, die das einheitliche Installationsprogramm entweder aktualisiert oder erstellt hat.

    Um dieses Problem zu vermeiden, wählen Sie die benutzerdefinierte Installation, und legen Sie die von Ihrer Bereitstellung verwendete Update Manager-Datenbank fest.

Verwaltung von virtuellen Maschinen

  • Das VMware Tools-Symbol wird in der Systemsteuerung von 64-Bit-Gastbetriebssystemen von Windows Vista und Windows 2008 nicht angezeigt
    Für VMware Tools auf Windows Vista- und Windows 2008-Gastbetriebssystemen ist nur die 32-Bit-Systemsteuerung verfügbar. Deshalb wird das Symbol für VMware Tools nicht in der Systemsteuerung von 64-Bit-Betriebssystemen angezeigt.

    Umgehung: Verwenden Sie das Applet der Systemsteuerung der 32-Bit-Version, das in der Taskleiste von VMware zur Verfügung steht, sowie unter C:\Programme (x86)\VMware\VMware Tools\VMControlPanel.cploder in <Installationspfad von VMware Tools>\VMControlPanel.cpl.
  • Benutzerdefiniertes VMware Tools-Skript wird für Ereignisse "Anhalten" oder "Herunterfahren" nicht ausgeführt (KB 1004390)
  • E/A kann auf virtuellen Maschinen während des Firmware-Upgrades verzögert werden
    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 Standardkonfiguration 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 entweder auf 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 unter "VMware HA" Optionen für virtuelle Maschinen. Wählen Sie im Popup-Menü "Isolierungsreaktion" für die bestimmte virtuelle Maschine entweder VM eingeschaltet lassen oder VM ausschalten.

Probleme bei VirtualCenter, VI-Client und Web Access

  • Das Ein- oder Ausschalten einer virtuellen Maschine mithilfe von Web Access führt dazu, dass mehrere redundante Fehlermeldungen in hostd.log protokolliert werden<br/> Wenn Sie eine virtuelle Maschine mithilfe von Web Access ein- oder ausschalten, werden alle 2 bis 3 Sekunden Fehlermeldungen ähnlich der Folgenden in die Datei hostd.logim Verzeichnis /var/log/vmware/geschrieben:<br/> Throw vmodl.fault.ManagedObjectNotFound

  • 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 sehr lange für die Initialisierung. Während dieser Zeit kann der VI-Client keine Verbindung zum VirtualCenter 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 VirtualCenter 2.5 Update 2 und starten Sie den VirtualCenter Server neu.

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 von VMware DRS nicht empfohlen oder durchgeführt (wenn im vollautomatischen Modus), wenn der Host in den Wartungs- oder Standby-Modus wechselt, da es bei einem Wechsel in den entsprechenden Modus zu einem Verstoß gegen das VMware HA-Failover-Level kommen 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 die virtuellen Maschinen angezeigt werden, die nach einem Failover neu gestartet werden.
  • HA-Netzwerkübereinstimmungsprüfung
    Während der HA-Konfiguration in VirtualCenter 2.5 Update 2 zeigt die Registerkarte "Aufgaben & Ereignisse" möglicherweise die folgende Fehlermeldung und Empfehlung an:

    Der HA-Agent auf Host <ESX-Hostname> in Cluster <Clustername> in <Datencenter> 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. Weitere Informationen finden Sie unter KB 1006606.

Seitenanfang