Versionshinweise zu VMware ESX Server 3.5 Update 5

Kontakt zum Vertrieb
 

VMware ESX Server 3.5 Update 5 | 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:

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

    VMware Infrastructure-Kompatibilitätstabellen ( PDF)

Dokumentation

Die gesamte Dokumentation für ESX Server 3.5 Update 4 gilt auch für ESX Server 3.5 Update 5. 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 3.5 Update 5

Diese Version von ESX Server 3.5 Update 5 ermöglicht ausschließlich Upgrades von zuvor unterstützten Versionen. Das Installationsprogramm von ESX  Server 3.5 Update 5 fordert Sie nur dann auf, ein Upgrade auszuführen, wenn eine zuvor unterstützte Version von ESX Server gefunden wurde. Informationen zu den Installationsanforderungen finden Sie im Installationshandbuch.

Für ein Upgrade Ihres ESX Server-Hosts auf ESX Server 3.5 Update 5, folgen Sie einen der folgenden unterstützten Upgrade-Pfaden:

Upgrade-Typ

ESX Server 3.0.1

ESX Server 3.0.2

ESX Server 3.0.3

ESX Server 3.5

ESX Server 3.5

Update 1

ESX Server 3.5

Update 2

ESX Server 3.5

Update 3

ESX Server 3.5

Update 4

Upgrade-ZIP

Nein

Nein

Nein

Ja

Ja

Ja

Ja

Ja

ISO-Image

Ja

Ja

Ja

Ja

Ja

Ja

Ja

Ja

 

Hinweis:

  • Bei Verwendung von ESX Server 2.5.x muss zunächst ein Upgrade auf ESX Server 3.0.1 oder höher durchgeführt werden, anschließend kann unter Verwendung eines ISO-Images ein Upgrade auf ESX Server 3.5 Update 5 erfolgen. Alternativ können Sie auf ESX Server 3.5 oder höher aktualisieren und anschließend mithilfe eines ISO-Images oder Upgrade-ZIP-Pakets auf ESX Server 3.5 Update 5 aktualisieren.

  • Bei Verwendung von ESX Server 3.0.0 muss zunächst ein Upgrade auf ESX Server 3.0.1 oder höher durchgeführt werden, anschließend kann unter Verwendung eines ISO-Images ein Upgrade auf ESX Server 3.5 Update 5 erfolgen. Alternativ können Sie auf ESX Server 3.5 aktualisieren und anschließend mithilfe eines ISO-Images oder Upgrade-ZIP-Pakets auf ESX Server 3.5 Update 5 aktualisieren.

  • Das Upgrade von ESX Server 3.5 Update 5 auf ESX Server 4.0 wird nicht unterstützt. Sie können allerdings auf ESX Server 4.0 Update 1 aktualisieren.

Weitere Informationen zu den Installations- und Upgrade-Methoden finden Sie im Upgrade-Handbuch.

Aktualisierte RPMs und Sicherheits-Fixes

Eine Liste der in ESX Server 3.5 Update 5 aktualisierten RPMs finden Sie unter Aktualisierte RPMs und Sicherheits-Fixes. Dieses Dokument gilt nicht für die ESX Server 3i-Produkte.

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.

Seitenanfang

In dieser Version enthaltene Patches

Diese Version enthält 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 3.5-Patches.

ESX Server 3.5 Update 5 enthält alle Fixes in ESX Server 3.5 Update 4 sowie die folgenden Patches, die nach ESX Server 3.5 Update 4 veröffentlicht wurden:

Zudem behebt ESX Server 3.5 Update 5 neue Probleme (weitere Informationen finden Sie im Abschnitt Behobene Probleme) und diese Probleme werden auch in den folgenden Paketen der einzelnen Patches behoben:

Seitenanfang

Behobene Probleme

In dieser Version werden Probleme in den folgenden Bereichen behoben:

 

 

Sicherung

  • Der Befehl vcbSnapAllschlägt möglicherweise mit einem Fehler fehl, wenn das backup_destinationals scpfestgelegt ist. Dieses Problem wurde in ESX Server 3.5 Update 5 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.

  • Das Protokoll ist mit storelib Physical Device Device ID-Meldungen gefüllt
    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
    Die folgende Debug-Meldung wird alle zwei Minuten in der Datei /var/log/messagesprotokolliert:
    trying to open /sbin/modprobe edd 2>&1

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

  • vSphere-Client zeigt den Status des Hostarbeitsspeichers als "Unbekannt" auf Servern an, auf denen ESX Server 3.5 Update 4 ausgeführt wird
    Auf Servern, auf denen ESX Server 3.5 Update 4 ausgeführt wird, zeigen die DIMM-Module (Dual In-Line Memory Module) den Arbeitsspeicherstatus als "Unbekannt" an, wohingegen die DIMMs auf anderen Systemen den potenziell falschen Status als "OK" angeben.

  • Systemstatus und speicherverwandte Informationen auf dem VI-Client werden nach einem Upgrade auf ESX Server 3.5 Update 4 geändert
    Nach einem Upgrade auf ESX Server 3.5 Update 4 werden der Systemstatus und speicherverwandte Informationen auf dem VI-Client geändert. Wenn Sie zudem mithilfe des CIM-Clients eine EI-Operation auf einige der Klassen durchführen, z. B. auf VMWARE_StorageExtent, erhalten Sie eine Fehlermeldung ähnlich der Folgenden:

    /var/pegasus/bin/cimcli CIMException: Cmd= enumerateInstances Object= VMWARE_StorageExtent
    ProviderLoadFailure: (/var/pegasus/lib/libvmwprovider.so) Provider is not a CMPI style provider. Cannot find VMware_StorageExtent_Create<mi-type>MI symbol.

Gastbetriebssysteme

  • Erhöhter E/A-Zeitüberschreitungswert für Linux-Gastbetriebssysteme mit einer Kernelversion von 2.6.13 oder höher
    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
    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
    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
    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
    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
    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.
    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.
    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.
    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
    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 aktiviert bei VMware HA-Datenverkehr, VMotion-, Klon- oder Patch-Vorgängen automatisch die Firewall
    Bei Ausführung bestimmter Vorgänge auf dem ESX-Host, wie z. B. VMotion, Klonen, HA-Konfiguration oder Patchen, wird die Firewall des Betriebssystems der ESX-Konsole möglicherweise auf eine zuvor gespeicherte Konfiguration zurückgesetzt. Diese Zurücksetzung tritt auf, wenn Sie die Firewall-Konfiguration mit einem anderen Tool als dem unterstützten Befehl esxcfg-firewallgeändert haben.
    Deaktivieren Sie die Firewall nicht, indem Sie chkconfig firewall offausführen oder indem Sie das Firewall-Startskript blockieren. Deaktivieren Sie die Firewall, indem Sie dem Datenverkehr keine Einschränkungen auferlegen. Führen Sie dazu den Befehl esxcfg-firewall --allowIncoming --allowOutgoingaus.
    Ändern Sie die aktive Firewall-Konfiguration nicht, indem Sie den iptables-Befehl oder andere Linux-Befehle zur Firewall-Verwaltung ausführen. Verwalten Sie die Firewall-Konfiguration des Konsolenbetriebssystems ausschließlich mit dem Befehl esxcfg-firewall, mit vSphere oder dem VI-Client.
    So verwalten Sie mit dem vSphere-Client die Firewall-Konfiguration des Konsolenbetriebssystems:

    1. Wählen Sie den Host im Bestandslistenfenster aus.
    2. Wählen Sie die Registerkarte Konfiguration (Configuration).
    3. Klicken Sie auf Sicherheitsprofil.
    4. Klicken Sie auf den Link Eigenschaften.
    5. Bearbeiten Sie die Konfigurationsinformationen im Fenster "Eigenschaften".

    Wenn Sie eine neue Firewall-Dienstdefinition hinzufügen möchten, erstellen Sie eine zusätzliche XML-Datei im Verzeichnis /etc/vmware/firewall. Sie können den neuen Dienst anschließend mit dem Befehl esxcfg-firewall -e <Name_des_neuen_Diensts>verwenden.
    Wenn Sie einen von ESX angebotenen Dienst erweitern möchten, kopieren Sie dessen XML-Definition von der Originaldatei in das Verzeichnis /etc/vmware/firewall(verwenden Sie services.xmloder eine der anderen Dateien). Geben Sie dem neuen Dienst einen eindeutigen Namen, der sich vom Namen der Originaldatei (die unter dem alten Namen weiterhin zur Verfügung steht) unterscheiden muss. Deaktivieren Sie anschließend den alten und aktivieren Sie den neuen Dienst. Beispiel: esxcfg-firewall -d ftpClient -e myFtpClient.
    Ändern Sie nicht die ursprünglich von ESX bereitgestellten Firewall-XML-Dateien. Diese Dateien werden möglicherweise später einmal durch einen Patch oder ein Upgrade ersetzt, wobei Ihre Änderungen verloren gehen.

Migration

  • Virtuelle Maschine wird ausgeschaltet, wenn VMotion fehlschlägt
    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

  • ESX Server-Host fällt möglicherweise beim Herunterfahren oder Neustart mit einem violetten Bildschirm aus, wenn die Dämonen pegasusund wsmannicht gestoppt werden. Dieses Problem wurde in der vorliegenden Version behoben.

  • ESX Server startet nicht und zeigt auf manchen ASUS-Systemen einen violetten Bildschirm an
    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
    Die Dateiberechtigungsprobleme wurden in dieser Version behoben.

  • Arbeitsspeicher wird von im Leerlauf befindlichen virtuellen Maschinen zurückgewonnen, obwohl freier Arbeitsspeicher zur Verfügung steht
    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
    Wenn die /-Partition der ESX Server-Servicekonsole 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 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
    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
    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:
    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
    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
    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
    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
    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
    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
    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

  • Gastbetriebssysteme können auf das SCSI CD-Laufwerk zugreifen (KB 1008673)

  • Unzureichender Arbeitsspeicher für COS verursacht einen Systemausfall mit einem violetten Bildschirm
    In ESX Server 3.5 Update 5 wurde der für das Console OS (COS) reservierte Arbeitsspeicher erhöht, was die Möglichkeit eines Serverausfalls wegen unzureichendem Arbeitsspeicher reduziert. Diese erhöhte Arbeitsspeicherreservierung steht nur dann zur Verfügung, wenn Sie eine Neuinstallation von ESX Server 3.5 Update 5 durchführen. Wenn Sie auf ESX Server 3.5 Update 5 von einer vorherigen Version von ESX Server aktualisieren, werden die Arbeitsspeichereinstellungen aus der vorherigen Version beibehalten. In diesem Fall, ist es empfehlenswert, je nach Ihren COS-Arbeitsspeicheranforderungen die Menge des reservierten Arbeitsspeichers zu erhöhen und die Auslagerungsdatei zu vergrößern. Sie können die Menge des reservierten Arbeitsspeichers erhöhen und die Auslagerungsdatei vergrößern, indem Sie die Anweisungen unter Reservierten physischen Arbeitsspeicher für COS und die Auslagerungsdatei erhöhen, um ESX Serverausfälle zu verhindern (KB 1013243) befolgen.

  • Diese Version von ESX Server enthält einen Fix, der einen Mechanismus bereitstellt, der die Leistung der ESX Server-Hosts erhöht, die wegen des IRQ-Sharings möglicherweise beeinträchtigt wurde. Weitere Informationen hierzu finden Sie unter Die Leistung von ESX Server 3.5 ist möglicherweise wegen des IRQ-Sharings beeinträchtigt (KB 1003710).

  • Ab dieser Version können Benutzer die NTP-Eigenschaften in der UTC-Zeitzone mithilfe des VI-Clients nach dem Installieren von ESX Server festlegen.

Speicher

  • Die aktualisierte RDM-Größe wird auf der virtuellen Maschine nicht angezeigt
    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.

  • Mehrere erneute Prüfungen von VMFS-Volumes auf den ESX Server-Maschinen führen zu einem violetten Bildschirm
    Wenn mehrere erneute Prüfungen von VMFS-Volumes auf den ESX Server-Maschienen mit mehreren installierten IBM Director-Agenten durchgeführt werden, könnte dies zu einem violetten Bildschirm führen.

  • 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
    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
    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.
    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
    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
    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
    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 Möglichkeit, den ESX Server mithilfe eines für TCP-Unterstützung konfigurierten NFS-Servers zu installieren (KB 1015512)

  • Beim Upgrade von ESX 3.5 auf ESX 3.5 Update 2 schlägt der Upgrade-Vorgang mit dem Fehler More than one vmkernel foundfehl. Dieses Problem tritt möglicherweise beim Upgrade von ESX 3.5 auf eine ESX 3.5-Update-Version vor ESX 3.5 Update 5 auf.

  • Der esxupdate-Befehl behält die benutzerdefinierten Einstellungen in "/etc/yum.conf" nicht bei
    Benutzerdefinierte Änderungen an der Datei /etc/yum.confwerden überschrieben, wenn ein Patch oder eine Update-Version installiert wurde, und die Änderungen gehen verloren. Dieses Problem wurde in der vorliegenden Version behoben.

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

  • Nach einem Upgrade auf ESX Server 3.5 Update 5 und einem Neustart des ESX Server wird während des Startvorgangs ein Pegasus-Installationswarteschlangenfehler generiert. (KB 1015294)

  • 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 Redundanzsensor 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, der über zwei physische Stromversorgungen verfügt, 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.

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

    Umgehung: Ö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

  • 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).
  • Indication-Ereignisse auf ESX Server 3.5 funktionieren nicht bei Verwendung des WS-Man-Protokolls.
  • 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
    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.
    Umgehung:Führen Sie die folgenden Aufgaben aus:

    1. Beantworten Sie während der Installation von VMware Tools die folgende Frage mit NEIN:
      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:
      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 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

  • Einige Dell-BIOS-Systeme weisen möglicherweise doppelte Interrupt-Routing-Einträge in der ACPI-Tabelle auf (KB 1013804)

  • Systemstatus unvollständig nach der Installation von HP Insight Manager (KB 1015607)

  • Die IBM Director Server 6.1.1.1-Web-Schnittstelle mit dem installierten IBM Director 6.1.2-Plattformagenten zeigt die MAC-Adresse des vmnic als den Namen der LAN-Verbindung an. Verwenden Sie zum Abrufen des Namens der LAN-Verbindung die Eigenschaft ElementName.

  • IBM Systems Director 6.1 kann auf ESX Server-Hosts nicht installiert werden
    Die Installation von IBM Systems Director 6.1 Server schlägt auf ESX Server-Hosts mit einer Meldung ähnlich der Folgenden fehl:
    Es konnte kein von IBM Systems Director unterstütztes Betriebssystem gefunden werden.

    IBM Systems Director 6.1 Server wird derzeit auf ESX Server 3.5 nicht unterstützt. IBM Director Server kann auf jeder Windows-Maschine installiert werden und der allgemeine IBM Director-Agent kann auf dem ESX Server 3.5-Host installiert werden.
  • 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
    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äß
    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)
  • 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
    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.
  • Der Befehl "poweroff" im Fehlerbehebungsmodus fährt den ESX Server herunter, aber die Stromzufuhr wird nicht unterbrochen
    Dieses Problem gilt für alle Versionen von ESX Server, darunter auch die aktuelle Version. Wenn der Host im Fehlerbehebungsmodus gestartet wird (nur Servicekonsole), wird bei Ausführung des Befehls "poweroff" die Stromzufuhr nicht unterbrochen. Das Hostbetriebssystem wird normal heruntergefahren und die Meldung "Power down" wird angezeigt Der Servicekonsole fehlt jedoch die ACPI-Unterstützung zum Abschließen des Ausschaltvorgangs.

    Umgehung:
    Nachdem die Meldung "Power down" angezeigt wurde, können Sie die Stromzufuhr manuell unterbrechen, wie z. B. durch die Verwendung einer Remote-Management-Konsole, durch Drücken des Netzschalters oder durch Ziehen des Stromkabels.
  • Die Installation auf einem HP ProLiant BL 280c G6-Server führt zu einer Zeitüberschreitungs-Meldung
    Die folgende Meldung wird ausgegeben, wenn ESX Server 3.5 Update 4 auf einem HP Proliant BL 280c G6-Server installiert wird:
    USB control / bulk_msg: timeout

    Diese Meldung wird von der Linux-Servicekonsole ausgegeben und zeigt an, dass ein USB-Hostcontroller eine Zeitüberschreitung auf einem angeschlossenen USB-Gerät erkannt hat. Der Hostcontroller kann entweder ein Hostcontroller mit hoher Geschwindigkeit (ehci) oder mit voller/niedriger Geschwindigkeit sein. Die Ursache kann der Verlust einer Verbindung zu einem beliebigen angeschlossenen Gerät sein; z. B. zu einem ILO-CD-ROM-Laufwerk, einer Tastatur oder einem USB-Flash-Laufwerk. Nach der Ausgabe dieser Meldung funktioniert das Gerät nicht, bis ein bestimmtes Ereignis für das Gerät stattgefunden hat, z. B. das Trennen und erneute Anhängen des Geräts oder ein Neustart des gesamten Systems. Ein Neustart kann diesen Zustand ändern oder auch nicht. Alternativ dazu kann der ehci-Hostcontroller mithilfe von rmmodentladen werden. Dies löst jedoch nur Probleme, die der Hochgeschwindigkeits-Hostcontroller erkannt hat.

    Diese Meldung kann bedenkenlos ignoriert werden. Wenn ein Gerät, z. B. eine USB-Tastatur, nicht reagiert, kann ein bestimmtes Ereignis für das Gerät durch das Trennen und erneute Anhängen des Geräts hervorgerufen werden (für ILO-Speichergeräte geschieht dies über die Registerkarte "Remotemedien"). Es ist keine weitere Auswirkung im Zusammenhang mit dieser Meldung auf das System bekannt.

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

  • Das System wird unbrauchbar, wenn für "esxupdate" kein Speicherplatz mehr zur Verfügung steht
    Wenn mit "esxupdate" ein Upgrade auf ESX Server 3.5 Update 3 durchgeführt wird, wird das System unbrauchbar, wenn für "esxupdate" kein Speicherplatz mehr auf der Partition /, /bootoder /usrzur Verfügung steht.
    Umgehung: Stellen Sie vor dem Aufspielen eines Patches sicher, dass genügend Speicherplatz auf den Partitionen /, /bootoder /usrzur Verfügung steht. Um zu ermitteln, ob genügend Speicherplatz für das Upgrade zur Verfügung steht, können Sie eine Testinstallation durchführen. Dieses Verfahren wird im ESX Server 3 Patch Management Guide beschrieben.

ESX Server-Upgrade und -Installation

  • Der Abfragebefehl "esxupdate -l" listet VMware-vpxa als ein neu installiertes RPM-Paket auf
    Beim Upgrade eines mit VirtualCenter Server verbundenen ESX Server-Hosts auf Version ESX Server 3.5 mit dem Dienstprogramm "esxupdate" listet der Befehl esxupdate - l queryVMware-vpxa als ein neu installiertes RPM-Paket auf, da der VirtualCenter-Client das Paket "VMware-vpxa rpm" installiert, wenn er zum ersten Mal mit dem ESX Server-Host verbunden wird.

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.
  • Geklonte virtuelle Maschinen enthalten kein DNS-Suffix (KB 1004299)
  • Geklonte virtuelle Maschinen sehen die .vmdk-Datei der virtuellen Quellmaschine (KB 1004176)
  • Benutzer mit Berechtigung "Erstellen" kann keine virtuellen Maschinen erstellen(KB 1004417)
  • 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
    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:
    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.
  • Zeitzonenbezeichnungen unterscheiden sich je nach Installationsart von ESX Server 3.5 Update 4
    Beim Erstellen einer Kickstartdatei ks.cfgunter Verwendung von Web Access ist Asia-Calcutta als Zeitzonenname im Dropdown-Menü verfügbar. Derselbe Name wird jedoch als Asia-Kolkata aufgelistet, wenn die Installation unter Verwendung der GUI oder von Text durchgeführt wird. Das Problem beschränkt sich auf die inkonsistente Benennung

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

Verwenden von Sprachpaketen auf dem ESX Server-Host

Wenn Sie eine deutsche, japanische oder chinesische (vereinfachtes Chinesisch) Sprachunterstützung für den Einsatz von Virtual Infrastructure Web Access oder dem VI-Client mit Ihrem ESX Server-Host wünschen, muss sich das Sprachpaket auf dem Host befinden und das Standardgebietsschema muss auf Ihre gewünschte Sprache gesetzt sein. Ab ESX Server 3.5 Update 3 werden die Sprachpaketdateien auf allen Hosts installiert und müssen nicht auf den Host kopiert werden, bevor das Gebietsschema geändert wird.

So legen Sie das Standardgebietsschema auf dem Host fest.

  1. Bearbeiten Sie die Datei /etc/vmware/hostd/config.xml, um die richtige Standardsprachumgebung zu aktivieren. Suchen Sie nach den folgenden Zeilen in der Datei config.xml:
       <locale>
          <DefaultLocale>en_US</DefaultLocale>
       </locale>

    Ersetzen Sie für Deutsch die Zeilen durch die folgenden Zeilen:

       <locale>
          <DefaultLocale>de_DE</DefaultLocale>
       </locale>

    Ersetzen Sie für Japanisch die Zeilen durch die folgenden Zeilen:

       <locale>
          <DefaultLocale>ja_JP</DefaultLocale>
       </locale>

    2. Ersetzen Sie für Chinesisch die Zeilen durch die folgenden Zeilen:

       <locale>
          <DefaultLocale>zh_CN</DefaultLocale>
       </locale>

  2. Geben Sie die folgenden Befehle ein, um VI Web Access und die Host-Agentendienste neu zu starten:

    service mgmt-vmware restart
    service vmware-VMware Web Access restart