VMware

Versionshinweise zu VMware ESX Server 3.5 Update 4



VMware ESX Server 3.5 Update 4 | 30. März 2009 | Build 153875

Letzte Dokumentaktualisierung: 13. April 2009

Überprüfen Sie regelmäßig, ob Erweiterungen und Updates für diese Versionshinweise zur Verfügung stehen. Weitere Informationen finden Sie in den neuesten englischen Versionshinweisen.


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

Hinweise:

  1. Nicht jede beliebige Kombination der VirtualCenter- und ESX Server-Versionen wird unterstützt. Nicht jede der vorgestellten Funktionen ist verfügbar, es sei denn, Sie verwenden VirtualCenter 2.5 Update 4 mit ESX Server 3.5 Update 4. Weitere Informationen zur Kompatibilität finden Sie in den Kompatibilitätstabellen für ESX Server, VirtualCenter und VMware Infrastructure-Client.
  2. Diese Version von ESX Server setzt ein Upgrade von VMware Tools voraus.

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

Erweiterte Unterstützung für den erweiterten VMXNET-Adapter – Diese Version von ESX Server enthält eine aktualisierte Version des VMXNET-Treibers (VMXNET erweitert) für die folgenden Gastbetriebssysteme:

  • Microsoft Windows Server 2003, Standard Edition (32-Bit)
  • Microsoft Windows Server 2003, Standard Edition (64-Bit)
  • Microsoft Windows Server 2003, Web Edition
  • Microsoft Windows Small Business Server 2003
  • Microsoft Windows XP Professional (32-Bit)

Die neue VMXNET-Version verbessert die Netzwerkleistung von virtuellen Maschinen und erfordert ein Upgrade der VMware Tools.

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

Treiber-Update für QLogic Fibre-Channel-Adapter – Der Treiber und die Firmware für die QLogic Fibre-Channel-Adapter wurden auf Version 7.08-vm66 bzw. 4.04.06 aktualisiert. Diese Version behebt Interoperabilitätsprobleme für QLogic Management Tools für FC-Adapter und erweiterte NPIV-Unterstützung.

Treiber-Update für Emulex Fibre-Channel-Adapter – Der Treiber für Emulex Fibre-Channel-Adapter wurde auf Version 7.4.0.40 aktualisiert. Diese Version bietet Unterstützung für die HBAnyware 4.0 Emulex Verwaltungssuite.

Treiber-Update für LSI megaraid_sas und mptscsi Speicher-Controller – Die Treiber für LSI megaraid_sas und mptscsi Speicher-Controller wurden auf Version 3.19vmw bzw. 2.6.48.18 vmw aktualisiert. Das Upgrade verbessert die Leistung und erweitert die Ereignisbehandlungsmöglichkeiten für diese zwei Treiber.

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 "Handbuch für die Installation von Gastbetriebssystemen": www.vmware.com/pdf/GuestOS_guide.pdf.

  • SuSE Linux Enterprise Server 11 (32-Bit und 64-Bit)
  • SuSE Linux Enterprise Desktop 11 (32-Bit und 64-Bit)
  • Ubuntu 8.10 Desktop Edition und Server Edition (32-Bit und 64-Bit)
  • Windows Preinstallation Environment 2.0 (32-Bit und 64-Bit)

Darüber hinaus wurden in dieser Version vorgefertigte Kernel-Module (pre-built kernel modules, PBMs) für die folgenden Gastbetriebssysteme hinzugefügt:

  • Ubuntu 8.10
  • Ubuntu 8.04.2

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

Neu unterstützte E/A-Geräte – Integrierte Unterstützung für die folgenden On-Board-Prozessoren, E/A-Geräte und Speichersubsysteme:

SAS-Controller und SATA-Controller:

Die folgenden SATA-Controller werden jetzt auch unterstützt.

  • PMC 8011 (für SAS- und SATA-Laufwerke)
  • Intel ICH9
  • Intel ICH10
  • CERC 6/I SATA/SAS Integrated RAID Controller (für SAS- und SATA-Treiber)
  • HP Smart Array P700m Controller

    • Hinweise:

    1. 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).
    2. Das Speichern von VMFS-Datenspeichern auf nativen SATA-Laufwerken wird nicht unterstützt.

Netzwerkkarten: Die folgenden Netzwerkkarten werden jetzt unterstützt:

  • HP NC375i Integrated Quad Port Multifunction Gigabit Server Adapter
  • HP NC362i Integrated Dual port Gigabit Server Adapter
  • Intel 82598EB 10 Gigabit AT Network Connection
  • HP NC360m Dual 1 Gigabit/NC364m Quad 1 Gigabit
  • Intel Gigabit CT Desktop Adapter
  • Intel 82574L Gigabit Network Connection
  • Intel 10 Gigabit XF SR Dual Port Server Adapter
  • Intel 10 Gigabit XF SR Server Adapter
  • Intel 10 Gigabit XF LR Server Adapter
  • Intel 10 Gigabit CX4 Dual Port Server Adapter
  • Intel 10 Gigabit AF DA Dual Port Server Adapter
  • Intel 10 Gigabit AT Server Adapter
  • Intel 82598EB 10 Gigabit AT CX4 Network Connection
  • NetXtreme BCM5722 Gigabit Ethernet
  • NetXtreme BCM5755 Gigabit Ethernet
  • NetXtreme BCM5755M Gigabit Ethernet
  • NetXtreme BCM5756 Gigabit Ethernet

Erweiterte Unterstützung: Die E1000 Intel-Netzwerkkarte (NIC) steht jetzt für die Gastbetriebssysteme NetWare 5 und NetWare 6 zur Verfügung.

Onboard-Management-Prozessoren:

  • IBM System-Management-Prozessor (iBMC)

Speicher-Arrays:

  • SUN StorageTek 2530 SAS Array
  • Sun Storage 6580 Array
  • Sun Storage 6780 Array

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 von 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 VI-Client.

Hardwarekompatibilität

• Erfahren Sie mehr über Hardwarekompatibilität:

Die Listen zur Hardwarekompatibilität stehen nun in dem webbasierten Kompatibilitätshandbuch unter www.vmware.com/resources/compatibility 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äts handbuch ermöglicht das Durchsuchen der Handbücher und das Speichern der Suchergebnisse im PDF-Format.

Sie können sich unter registrieren lassen, um über Updates des Kompatibilitätshandbuchs benachrichtigt zu werden. Dies ist das RSS-Bild, das als Link auf einen RSS-Feed dient.

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

Tabellen zur VMware Infrastructure-Kompatibilität (PDF)

Dokumentation

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

Installation und Upgrade

Im Installationshandbuch finden Sie Schritt-für-Schritt-Anleitungen zur Installation und Konfiguration von ESX Server und 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 4

Diese Version von ESX Server 3.5 Update 4 ermöglicht ausschließlich Aktualisierungen von zuvor unterstützten Versionen. Das Installationsprogramm von ESX Server 3.5 Update 4 führt nur dann eine Aktualisierung aus, wenn eine zuvor unterstützte Version von ESX Server gefunden wird. Informationen zu den Installationsanforderungen finden Sie im Installationshandbuch.

Folgen Sie für eine Aktualisierung Ihres ESX Server-Hosts auf ESX Server 3.5 Update 4 den im folgenden aufgeführten unterstützten Aktualisierungspfaden:

Upgrade-Typ

ESX Server 2.5.4

und 2.5.51

ESX Server 3.0.1 2

ESX Server 3.0.22

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

Tarball

Nein

Nein

Nein

Nein

Ja

Ja

Ja

Ja

ISO-Image

Ja

Ja

Ja

Ja

Ja

Ja

Ja

Ja

 

  1. Bei Verwendung von ESX Server 2.5.1, ESX Server 2.5.2 und ESX Server 2.5.3 muss zunächst eine Aktualisierung auf ESX Server 2.5.4 durchgeführt werden, anschließend kann eine Aktualisierung auf ESX Server 3.5 Update 4 durchgeführt werden. Alternativ können Sie auf ESX Server 3.5 aktualisieren und dann eine Aktualisierung auf ESX Server 3.5 Update 4 durchführen.
  2. Bei Verwendung von ESX Server 3.0.0 muss zunächst eine Aktualisierung auf ESX Server 3.0.1 oder höher durchgeführt werden, anschließend kann unter Verwendung eines ISO-Images eine Aktualisierung auf ESX Server 3.5 Update 4 erfolgen. Alternativ können Sie auf ESX Server 3.5 aktualisieren und dann eine Aktualisierung auf ESX Server 3.5 Update 4 durchführen.

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 4 aktualisierten RPMs finden Sie unter Aktualisierte RPMs und Sicherheits-Fixes. Dieses Dokument gilt nicht für die ESX Server 3i-Produkte.

Duchführen eines Upgrades der VMware Tools

Diese Version von ESX Server setzt ein Upgrade von VMware Tools voraus.

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 erhalten Sie auf der Download-Seite für ESX Server 3.5-Patches oder, indem Sie auf den Namen eines Patches klicken.

ESX Server 3.5 Update 4 enthält die Fixes aus allen folgenden Patches:

Neue Patches in Update 4 (30. März 2009 | Build 153875)

Bereits veröffentlichte Patches

Seitenanfang

Behobene Probleme

In dieser Version werden Probleme in den folgenden Bereichen behoben:

Sicherung

  • Aktualisiert: Wenn die Katalogdatei umbenannt wird, schlägt das Wiederherstellen der virtuellen Maschine unter Verwendung von vcbResAll -a fehl
    Wenn Sie die Katalogdatei umbenennen und versuchen, virtuelle Maschinen mithilfe der Option -a des vcbResAll-Befehls wiederherzustellen, schlägt das Wiederherstellen fehl. Die folgende Fehlermeldung wird auf der Konsole angezeigt:
    Fehler: Katalogdatie kann nicht gelesen werden

    Umgehung
    Verwenden Sie den Befehl vcbRestore zum Wiederherstellen von virtuellen Maschinen. Weitere Informationen finden Sie im Abschnitt "Verwenden des Dienstprogramms vcbRestore zum Wiederherstellen virtueller Maschinen" im Sicherungshandbuch für virtuelle Maschinen.
    Die Verwendung des Befehls vcbResAll mit der Option -a wird ab dieser Version nicht mehr unterstützt.

CIM und API

  • Die obligatorischen Eigenschaften MaxReadable, NominalReading, NormalMax, NormalMin und PollingInterval in der Klasse CIM_NumericSensor zeigen falsche Werte an
    Die Instanzen von CIM_NumericSensor verfügen über diesen Eigenschaftssatz:
    MaxReadable, NominalReading, NormalMax, NormalMin. Wenn der tatsächliche Sensor keine Werte dieser Eigenschaften unterstützt, werden sie in CIM-Antworten als 0 angezeigt und nicht als unspezifiziert.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Bei ESX Server 3.5 zeigen Instanzen von VMware_Account (eine Unterklasse von CIM_Account) ab Update 2 eine SystemName-Eigenschaft mit dem Wert "0" an
    Die SystemName-Eigenschaft sollte die BIOS-UUID des Servers enthalten.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Auf IBM Athena-Hardware verfügen einige OMC_DiscreteSensor-Instanzen über falsche Geräte-IDs (-1 erscheint als letztes Segment der Geräte-ID)

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der OpenIPMI-Treiber wurde erweitert, um den HP IPMI-Controller über den PCI-Bus und Interrupts auszuführen und um die OEM-Meldungskanäle zu unterstützen
    Diese Änderungen sind für HP G6-Server erforderlich, die OEM-Nachrichten zum Melden von Arbeitsspeicherproblemen verwenden.
  • Mehrere falsche Meldungen über fehlerhafte Prüfsummen werden an die Protokolldateien gesendet.
    In bestimmten Situationen werden Meldungen ähnlich der Folgenden Protokolldateien "IpmiIfcFruBoard: Prüfsummenfehler..." werden an die Protokolldateien gesendet. Dies weist jedoch nicht auf einen tatsächlichen Fehler hin. Diese Meldungen können ignoriert werden.

    Dieses Problem wurde in der vorliegenden Version behoben. Solche falsche Meldungen zu fehlerhaften Prüfsummen werden nicht mehr protokolliert.
  • 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. "... cimprovagt: storelib Physical Device Device ID" und füllen damit das Protokoll "/var/log/messages". Diese Meldungen sind Teil des Debug-Codes und sollten nicht an dieser Stelle protokolliert werden.
    In dieser Version ist dieses Problem behoben.
  • Neu: Gelegentlich laden die CIM-Provider von HP ESX Server 3i Version 3.5 Update 3 nicht (KB 1009671)

Gastbetriebssysteme

  • Aktualisiert: Im ESX Server 3.5 Update 4 hat sich die vorgegebene virtuelle Netzwerkkarte geändert, die für Solaris 10 32-Bit und Solaris 9 32-Bit verwendet wird

    Die vorgegebene virtuelle Netzwerkkarte wurde für Solaris 10 32-Bit und Solaris 9 32-Bit zur Leistungssteigerung von vlance (Solaris-Treiber pcn) zu Intel E1000 (Solaris-Treiber e1000g) geändert.
  • Der BusLogic-SCSI-Adapter ist bei bestimmten Gastbetriebssystemen fälschlicherweise als unterstützt aufgeführt.
    Beim Verwenden des VI-Clients zum Anzeigen von verfügbaren Adaptern für die Windows Vista 32-Bit- oder Windows Server 2008 32-Bit-Gastbetriebssysteme wird der BusLogic SCSI-Adapter als unterstützt aufgeführt. Vielmehr wird dieser Adapter nicht empfohlen.

    Dieses Problem wurde in der vorliegenden Version behoben. Wenn Sie nun die SCSI-Controller-Einstellungen einer virtuellen Maschine ändern, die unter Windows Vista 32-Bit oder Windows Server 2008 32-Bit ausgeführt wird, wird BusLogic als "Nicht empfohlen" aufgelistet.
  • Vor ESX Server 3.5 Update 4 werden bestimmte Anwendungen, die Multithreading verwenden, auf 64-Bit SMP-Gastbetriebssystemen möglicherweise instabil ausgeführt.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Aktualisieren der japanischen Version von VMware Tools von ESX 3.0.2 U1 auf ESX Server 3.5 U1 auf dem Gastbetriebssystem schlägt möglicherweise fehl

    Dies führt zu einer Fehlermeldung ähnlich der Folgenden:

    Beim Konvertieren ist ein Fehler aufgetreten. Überprüfen Sie, ob der Pfad verfügbar ist

    Dieses Problem wurde in ESX Server 3.5 Update 4 behoben.
  • PAE-aktivierte Windows 2000-VMs antworten nicht
    PAE-aktivierte (PAE = Physical Address Extension, physische Adresserweiterung) Windows 2000-VMs reagieren bei einem Neustart möglicherweise nicht mehr oder schlagen fehl.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Ausführung von VMotion kann auf RVI-aktivierten AMD-Hosts vorübergehend einfrieren
    Beim Migrieren von virtuellen Maschinen mit VMotion auf RVI-aktivierten AMD-Hosts kann es vorkommen, dass die Ausführung von VMotion vorübergehend einzufrieren scheint, bevor der Vorgang abgeschlossen wird.
    Dieses Problem wurde in der vorliegenden Version behoben.

Netzwerk

  • Neu: Der PXE-Startvorgang einer virtuellen Maschine schlägt beim Neustart eines für die Verwendung eines virtuellen E1000-Geräts konfigurierten Gastbetriebssystems fehl
    Eine virtuelle Maschine, die für die Verwendung des virtuellen E1000-Geräts konfiguriert wurde, erhält nach dem Neustart keine IP-Adresse. Dieses Problem wurde in ESX Server 3.5 Update 4 gelöst.
  • Vor ESX Server 3.5 Update 4 wurde die Wake on LAN (WOL)-Unterstützung von Broadcom-bnx2-Netzwerkkarten manchmal nicht erkannt
    Obwohl eine Onboard-Broadcom-bnx2-Netzwerkkarte vorhanden ist, wird sie in einigen Fällen vom ESX Server 3.5 nicht als WOL-aktiviert erkannt. Dieses Problem wurde in der vorliegenden Version behoben.
  • Wenn der Watchdog-Timer eine Netzwerkkarte unter Verwendung des tg3-Treibers zurücksetzt, antwortet die Netzwerkkarte möglicherweise nicht mehr
    Wenn der Watchdog-Timer eine BCM5703-Karte mit HP NC7782 Gigabit Ethernet-Adapter unter Verwendung des tg3-Treibers zurücksetzt, wird der Vorgang möglicherweise nicht eingeleitet. Die Netzwerkkarte antwortet nicht mehr und die folgende Meldung wird in der vmkernel-Protokolldatei angezeigt:
    tg3_init_rings failed, err -12 for device vmnicx

    Dieses Problem wurde in der vorliegenden Version behoben.

Serverkonfiguration

  • Das Öffnen eines FTP-Client-Firewall-Dienstes ermöglicht keine FTP-Übertragungen
    Dieses Problem wurde in der vorliegenden Version insofern behoben, dass der FTP-Client-Firewall-Dienst den Passivmodus unterstützt.
  • Die Host-Sensorinformationen des ESX Server werden nicht im VI-Client angezeigt
    Die Host-Sensorinformationen des ESX Server werden möglicherweise nicht auf der Registerkarte Konfiguration > Status des VI-Clients angezeigt. Werden die Informationen nicht nach wenigen Minuten angezeigt, starten Sie Pegasus durch Eingabe des Befehls service pegasus restart in der Servicekonsole neu.
  • Neu: Wenn der COW (copy-on-write)-Heap in einer LabManager-Umgebung fast erschöpft ist, werden virtuelle Maschinen zwar eingeschaltet, jedoch sind möglicherweise nicht alle zugehörigen Festpaltten verknüpft.
    Diese Situation tritt auf, wenn virtuelle Maschinen unter Verwendung von LabManager eingeschaltet werden und der COW-Heap fast erschöpft ist. Wenn der COW-Heap zu einem bestimmten Zeitpunkt zu klein ist, um eine virtuelle Maschine einzuschalten, auf der alle ihr zugehörigen Festplatten geöffnet sind, wird die virtuelle Maschine zwar gestartet, jedoch nur mit der Anzahl an Festplatten, die der COW-Heap noch aufnehmen kann.
    Dieses Problem wurde in der vorliegenden Version behoben. Daher wird die virtuelle Maschine nicht eingeschaltet, wenn nicht alle mit einer bestimmten virtuellen Maschine verknüpften Festplatten geöffnet werden können, da der COW-Heap die angeforderten Festplatten nicht aufnehmen kann.

Speicher

  • Neu: Vor dieser Version wurden Änderungen der LUN-Eigenschaften oder -Attribute seitens des Speicher-Arrays von ESX Server nicht erkannt
    Das folgende Beispiel zeigt, wie dieses Problem auftreten kann. Ein VMFS-Volume wird auf der LUN "Symm7" erstellt, diese wird jedoch in "Symm6" geändert. In diesem Fall wird die Änderung an der LUN erkannt, die UUID der LUN wird jedoch falsch wiedergegeben.
    Dieses Problem wurde in der vorliegenden Version behoben.

  • ESX Server 3.5 zeigt falsche VMkernel-Warnmeldungen an
    ESX Server 3.5 zeigt möglicherweise falsche VMkernel-Warnmeldungen an, die darauf hindeuten, dass ein Gerät erkannt wurde, das das SCSI-3-Protokoll nicht unterstützt. Das Gerät sollte dennoch mit ESX Server 3.5 funktionieren. Die Meldungen ähneln den Folgenden:

    vmkwarning:Dec 12 14:57:11 [Hostname] vmkernel: 0:00:00:18.539 cpu5:1048)
    WARNUNG: ScsiUid: 550: Pfad 'vmhba2:C0:T0:L12' : unterstützt ANSI-Version 'SCSI-2'
    (0x2). Damit ein Gerät mit ESX verwendet werden kann, muss es das SCSI 3-Protokoll unterstützen.

    Dieses Problem wurde in der vorliegenden Version behoben. Die Lösung sieht vor, dass eine Warnmeldung, die der Folgenden ähnelt, in den VMkernel-Protokolldateien protokolliert wird, wenn ein Gerät, das das SCSI 3-Protokoll nicht unterstützt, erkannt wird:
    SCSI-2-Geräte werden möglicherweise in einer künftigen Version nicht unterstützt

  • Der Emulex-Treiber von ESX Server 3.5 Update 3 ist in einigen Fällen nicht kompatibel mit den Emulex Fibre-Channel-Adaptern

    Wenn der Emulex LPe1150 Fibre-Channel-Adapter mit Firmware-Version 1.00a5 oder niedriger mit dem Emulex-Treiber verwendet wird, der zum Lieferumfang des ESX Server 3.5 Update 3 gehört, kann der Treiber den Emulex Fibre-Channel-Adapter nicht beanspruchen.

    Dieses Problem wurde in der vorliegenden Version behoben. Der problembehaftete VMware-Treiber wurde in ESX Server 3.5 Update 4 aktualisiert. Der neue Treiber ist jetzt auch kompatibel mit Emulex Fibre-Channel-Adaptern, die Firmware-Versionen 1.00a5 und niedriger verwenden. Kurz gesagt, der aktualisierte Treiber funktioniert unabhängig von der Firmware-Version des Emulex Fibre-Channel-Adapters.
  • In VMware ESX Server 3.5 Update 4 wurde ein adaptiver Warteschlangentiefealgorithmus eingeführt, der die Tiefe der LUN-Warteschlange im VMkernel-E/A-Stack anpasst.
    Wenn eine Überlastung festgestellt wird, drosselt VMkernel die Tiefe der LUN-Warteschlange. VMkernel versucht dann, die Wartenschlangentiefe allmählich wiederherzustellen, wenn die Bedingungen, die zu der Überlastung geführt haben, nach und nach seltener auftreten. Standardmäßig ist dieser Algorithmus deaktiviert. Weitere Informationen über das Aktivieren dieses Algorithmus finden Sie unter Drosseln der LUN-Warteschlangentiefe in VMware ESX für 3PAR-Speicher-Arrays (KB 1008113).
  • Während Storage VMotion ausgeführt wird, schlägt das Verschieben der .vmx-Datei möglicherweise fehl mit der Fehlermeldung "Unzureichender Festplattenspeicher im Datenspeicher"
    Beim Versuch, eine .vmx-Datei von einem Datenspeicher in einen anderen zu verschieben, werden temporäre Snapshots für alle Festplatten im Quelldatenspeicher erstellt. In einigen Fällen verfügt der Quelldatenspeicher möglicherweise nicht über genügend Platz für alle temporären Snapshots. Als Ergebnis schlägt das Verschieben mit der Fehlemeldung "Unzureichender Festplattenspeicher im Datenspeicher" fehl, obwohl die Zielfestplatte über genügend Speicherplatz verfügt. Dieses Problem tritt auch dann auf, wenn mit dem Storage VMotion-Befehl nur eine Festplatte verschoben wird.
    Dieses Problem wurde in der vorliegenden Version behoben. Temporäre Snapshots werden nun nur für die Festplatten erstellt, die vom Storage VMotion-Befehl verschoben werden.
  • Gastbetriebssysteme und Speicher kommunizieren möglicherweise nicht im RDM-Modus
    Wenn im RDM-Modus (RDM = Raw Device Mapping) die vom Speicher an das Gastbetriebssystem gesendete Datenmenge einer SCSI-Abfrage größer als 36 Byte ist, kommunizieren das Gastbetriebssystem und der Speicher möglicherweise nicht ordnungsgemäß. Dieses Problem tritt möglicherweise mit Produkten wie z. B. Microsoft Virtual Shadow Copy Service (VSS) und NetApp SnapDrive auf. Dieser Fix behebt das Problem.
  • ESX Server-Host antwortet möglicherweise nicht mehr, wenn Emulex Fibre-Channel-Adapter verwendet werden
    ESX Server-Hosts, die Emulex Fibre-Channel-Adapter verwenden, antworten möglicherweise nicht mehr. In der vmkernel-Datei werden Einträge ähnlich dem Folgenden protokolliert:
    WARNING: SCSI: 2897: CheckUnitReady on vmhba1:1:0 returned Storage initiator error 0x0/0x0 sk 0x0 asc 0x0 ascq 0x0
    Diese Version verwendet einen aktualisierten Emulex-Treiber, wodurch das Problem behoben ist.
  • Neu: In ESX 3.5 Update 3 enthalten die vmkernel-Protokolle eine große Anzahl an Fehlermeldungen zu Reservierungskonflikten
    Dieses Problem wurde in der vorliegenden Version behoben. Fehlermeldungen zu Reservierungskonflikten werden in den vmkernel-Protokolldateien nicht mehr protokolliert. Wenn im System schwere Reservierungskonflikte auftreten, wird wie in vorherigen Versionen die folgende Meldung ausgegeben: Sync CR <count>.

Aktualisierung und Installation

  • Neu installierte RPMs werden bei einer Rollback der Systemzeit als falsch oder doppelt aufgelistet (KB 1006967)
  • Vor ESX Server 3.5 Update 4 konnte eine Installation unter Verwendung einer Kickstart-Datei in bestimmten Situationen zu Unterbrechungen führen
    Die ESX Server-Installation unter Verwendung einer Kickstart-Datei, die den initlabel-Befehl in Verbindung mit dem Schlüsselwort ignoredisk enthält, funktioniert nicht ordnungsgemäß. Dabei wurden nicht initialisierte Laufwerke, die mit dem Schlüsselwort ignoredisk angegeben wurden, nicht ignoriert. Dies führte zu einer Unterbrechung der automatischen Installation und die folgende Meldung wurde ausgegeben:

    Die Partitionstabelle des Geräts [DISK] war nicht lesbar. Diese muss zum Erstellen einer neuen Partition initialisiert werden, dabei gehen ALLE DATEN verloren

    Diese Problem wurde in ESX Server 3.5 Update 4 behoben. Alle Laufwerke, die mit dem Schlüsselwort ignoredisk angegeben werden, werden jetzt ohne Unterbrechung der Skriptinstallation ignoriert.

  • Vor ESX Server 3.5 Update 4 akzeptiert das Installationsprogramm ungültige Subnetzmasken und fährt mit der Installation fort
    Dieses Problem tritt bei ESX Server-Versionen vor Version 3.5 Update 4 auf. Wenn Sie bei der Installation von ESX Server unter Verwendung des Textmodus eine ungültige Subnetzmaske eingeben, fährt das Installationsprogramm mit der Installation fort, ohne eine Fehlermeldung auszugeben. Im grafischen Modus der Installation zeigt das Installationsprogramm nur dann eine Fehlermeldung an, wenn der numerische Wert der eingegebenen Subnetzmaske 255 Zeichen überschreitet.

    Dieses Problem wurde in der vorliegenden Version behoben (ESX Server 3.5 Update 4). Dieser Fix sorgt dafür, dass alle Netzwerkeinstellungen jetzt überprüft werden. Folglich werden in den folgenden Fällen Fehlermeldungen ausgegeben:

    • Der Wert für die Subnetzmaske ist ungültig. z. B. 255.255.255.253.
    • Die IP-Adresse und das Gateway befinden sich in unterschiedlichen Subnetzen (mit einer gültigen Submaske).
    • Die Gateway-Adresse ist mit der IP-Adresse identisch (mit einer gültigen Submaske).
    • Die IP-Adresse ist identisch mit der Broadcast-Adresse (mit einer gültigen Submaske und einem gültigen Gateway).
    • Die Gateway-Adresse ist identisch mit der Broadcast-Adresse (mit einer gültigen Submaske und IP-Adresse).
  • Vor ESX Server 3.5 Update 4 kam es bei Systemen, die Intel Xeon 5500-Prozessorserie verwenden, zu Blockierungen. Dieses Problem wurde in der vorliegenden Version behoben.
  • Unterbrechung der Konnektivität auf ESX Server 3.5 mit nForce Ethernet-Netzwerkkarte
    Der NVIDIA nForce-Ethernet-Chipsatz gibt nach Abschluss einer Paketübertragung möglicherweise keine Interrupts aus, sodass die Konnektivität unterbrochen wird. Die Konnektivität kann möglicherweise durch einen Neustart des Hosts wiederhergestellt werden, jedoch kann sie nach einiger Zeit wieder unterbrochen werden. Fehlermeldungen ähnlich der Folgenden werden möglicherweise in die VMkernel-Protokolldatei aufgenommen:

    Jan 1 12:00:00 esx vmkernel: 9:01:01:10.001 cpu1:1200)WARNUNG: LinNet: 4288: Watchdog-Zeitüberschreitung für Gerät vmnic0
    Jan 1 12:00:00 esx vmkernel: 9:01:01:10.001 cpu1:1200)<6>vmnic0: Got tx_timeout. irq: 00000020
    Jan 1 12:00:00 esx vmkernel: 9:01:01:10.001 cpu1:1200)<6>vmnic0: Ring at 6a02800: get 6a02a10 put 6a02a10
    Jan 1 12:00:00 esx vmkernel: 9:01:01:10.001 cpu1:1200)<6>vmnic0: Dump der tx-Register
    Dieses Problem wurde in der vorliegenden Version behoben.

  • Pegasus-Fehlermeldungen nach einem Upgrade oder einer Installation von ESX Server

    Wenn Sie ESX Server 2.x- oder 3.x-Systeme auf ESX Server 3.5 Update 1, Update 2 oder Update 3 aktualisiert oder eine Neuinstallation dieser ESX 3.5-Update-Versionen durchgeführt haben, schlägt der Pegasus-Dienst möglicherweise mit einer Fehlermeldung ähnlich der Folgenden fehl:
     
    Processing /var/pegasus/vmware/install_queue/1 [FAILED]
    ERROR: See log - /var/pegasus/vmware/install_queue/1.log
    Processing /var/pegasus/vmware/install_queue/1 [FAILED]
    ERROR: See log - /var/pegasus/vmware/install_queue/1.log
    Starting Pegasus CIMOM (cimserver)... [ OK ]
     
    Der Startstatus des Dienstes zeigt möglicherweise weitere Meldungen zu install_queue-Fehlschlägen während des Startvorgangs an.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Neu: Während der Installation werden vorherige Updates als fehlend aufgelistet
    Nach der VMware Update Manager-Installation (VUM-Installation) von ESX Server 3.5 Update 3 meldet VUM Update 1 und 2 als nicht übereinstimmend. Tatsächlich macht Update 3 die Updates 1 und 2 überflüssig. Dieses Szenario stellt also kein Problem dar und kann ignoriert werden. Wenn Sie Update 1, Update 2 oder beide auf ein Update 3-System aufsetzen möchten, wird die Patch-Datenbank aktualisiert, es werden aber keine ESX Server-Softwareänderungen auf dem System vorgenommen.

    Dieses Problem wurde in der vorliegenden Version dahin gehend behoben, dass vorherige Updates nicht mehr als fehlend aufgelistet werden.
  • Neu: Beim Installieren des Patchpakets schlägt das Starten des hostd-Dienstes fehl
    Dieses Problem wird durch folgende Ereignisse ausgelöst:
    1. Sie wenden ein Patchpaket an, für das der Neustart des ESX Server-Hosts erforderlich ist, aber Sie starten den Host nicht neu.
    2. Sie installieren ein Patchpaket, für das der Neustart des hostd-Dienstes erforderlich ist.
      Als Ergebnis schlägt das Starten des hostd-Dienstes fehl und eine Fehlermeldung ähnlich der Folgenden wird ausgegeben:
      Signature mismatch between VmkCtl (Jan 10 2009 18:47:26) and VMKernel (_Unknown_)

    Dieses Problem wurde in der vorliegenden Version behoben.
  • ESX Server Edition zeigt ESX als nicht lizenziert an, wenn die nicht bediente Lizenzdatei mit der Kickstart-Datei für die ESX-Skriptinstallation verfügbar ist
    Nach der Installation von ESX über eine Skriptinstallation zeigt der VI-Client ESX als "Nicht lizenziert" an, obwohl das Verzeichnis "/etc/vmware" eine gültige Lizenzdatei anzeigt.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • Legacy-Skripteinstellungen für vmware-toolbox werden nach einem Upgrade der VMware Tools auf die Standardeinstellungen zurückgesetzt (KB 1003047)
  • Fehlermeldung beim Aktualisieren von Update Manager auf U2: "Der Assistent wurde unterbrochen, bitte führen Sie die Installation erneut aus." (KB 1006583)

Verwaltung von virtuellen Maschinen

  • /proc/stat meldet die CPU-Nutzung der virtuellen Maschine nicht (KB 1007854)
  • ESX-Hosts können nicht in einem VirtualCenter Server registriert werden

    Netzwerkprobleme verhindern möglicherweise die Registrierung eines ESX Server-Hosts in einem VirtualCenter Server, der in einer virtuellen Maschine mit VMware Tools Version 3.5 auf einem ESX 3.0.x Server-Host ausgeführt wird. ESX Server-Hosts können registriert werden, sobald Sie VMware Tools herabstufen, damit es mit der Version des ESX Server-Hosts übereinstimmt, auf der die virtuelle Maschine ausgeführt wird. Möglicherweise wird eine Fehlermeldung ähnlich der Folgenden in die vpxd-Protokolle geschrieben:

    [2008-06-14 18:13:45.407 'App' 2296 error] [VpxVmdbCnx] Failed to connect to [Hostname]. Check that authd is running correctly (lib/connect error 11)

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Die Standardarbeitsspeichergröße für das Windows EBS 2008 64-Bit-Gastbetriebssystem ist nicht ausreichend
    Vor ESX Server 3.5 Update 4 hat das Windows Essential Business Server (EBS) 2008 64-Bit-Gastbetriebssystem standardmäßig nicht ausreichend Arbeitsspeicher zur Verfügung gestellt. Die Standardgröße des Hauptspeichers, 2048 MB, reicht nicht zum Laden der virtuellen Maschine aus. Dieses Problem wurde in der vorliegenden Version behoben. Die Standardgröße des Hauptspeichers für das Windows EBS 2008 64-Bit-Gastbetriebssystem beträgt für ESX Server 3.5 Update 4 4096 MB.
  • Aktualisiert: Der VMware Tools-Status wird nach der Ausführung von VMware Consolidated Backup als nicht ausgeführt angezeigt (KB 1008709)

Seitenanfang

Bekannte Probleme

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

Sicherung

  •   VMware Consolidated Backup wurde in dieser Version nicht aktualisiert
    ESX Server 3.5 Update 4 enthält keine aktualisierte Version von VMware Consolidated Backup. Diese Version wird mit Version 1.5.0 ausgeliefert und enthält keine Änderungen an VMware Consolidated Backup
     seit ESX Server 3.5 Update 2.

CIM und API

  • VI-Client zeigt auf HP-Servern einen falschen Namen für den Redundanzsensor zur Stromversorgung an

    Bei einer Verbindung einer ESX Server-Installation mit einem HP-Serversystem über den VI-Client zeigt der VI-Client den Namen des Redundanzsensors für die Stromversorgung auf dem Server fälschlicherweise als physische Stromquelle an. Beispielsweise zeigt der VI-Client bei einem HP Server mit einem Redundanzsensor mit zwei physischen Stromversorgungen den Redundanzsensor als Stromversorgungen für die Stromversorgung 3 an.
  • Ausführen einer CallMethod-Abfrage auf einer CIM_RecordLog-Instanz schlägt möglicherweise fehl
    In ESX Server 3.5 Update 2 oder höher könnte eine CallMethod-Abfrage auf einer CIM_RecordLog-Instanz fehlschlagen. Sie können jedoch das Systemereignisprotokoll über eine Remote-Managementkonsole oder -schnittstelle löschen.
  • Einige CIM-Klassen funktionieren nicht ordnungsgemäß auf IBM Multinode-Systemen
    Die folgenden Anomalien werden angezeigt. Die Operation EnumerateInstances() gibt für die folgenden Klassen eine Instanz weniger als die Operation EnumerateInstanceNames() zurück:
    • CIM_AssociatedSensor
    • CIM_MemberOfCollection
    Bei den folgenden Klassen schlägt die Operation GetInstance für einige Instanzen fehl. Jedoch ist die Operation EnumerateInstances() erfolgreich:
    • CIM_HostedService
    • CIM_Sensor
    • CIM_SystemDevice
    • CIM_Slot
    • CIM_ElementConformsToProfile
    Die Operationen EnumerateInstances() und EnumerateInstanceNames() geben 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.
  • Die Operation RequestStateChange(RestoreDefaultThresholds) gibt einen Fehler aus
    Die Operation RequestStateChange(RestoreDefaultThresholds) auf ESX Server 3.5 führt bei einigen Sensoren zu einer Fehlermeldung:
    CIM_ERR_FAILED: index out of bounds

    Trotz der Fehlermeldung stellt CIMOM die Schwellenwerte wieder her.

  • Firewall auf ESX Server 3.5 führt zu Konflikten mit CIM Indication-Unterstützung

    Ausgehende HTTP-Verbindungen werden von der Firewall auf ESX Server 3.5 geblockt. Dies führt dazu, dass Indication-Ereignisse nicht den Indication-Verbraucher erreichen.

    Lösung: Öffnen Sie in der Servicekonsole einen ausgehenden Port für Verbindungen zum Indication-Verbraucher mit dem folgenden Befehl:
    esxcfg-firewall -o <port-number>,tcp,out,http

    So schließen Sie einen Port für HTTP in der Firewall:
    esxcfg-firewall -c <port-number>,tcp,out,http

  • In ESX Server Version 3.5 wird die nachfolgende Fehlermeldung ausgegeben, wenn für numerische Stromversorgungssensoren die Operation Reset() aufgerufen wird:
    CIM_ERR_FAILED: index out of bounds
    Verwenden Sie stattdessen die Operation RequestStateChange(Reset), um dieses Problem zu umgehen.
  • Indication-Ereignisse auf ESX Server 3.5 Update 4 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.

  • Ein ESX Server 3.5-Host, der auf ESX Server 3.5 Update 4 aktualisiert wurde, liefert die CIM_AssociatedSensor-Instanzen nicht korrekt
    Die EnumerateInstance()- und Association()-Abfragen für CIM_AssociatedSensor geben keine Instanzen zurück.
    Umgehung: Führen Sie eine Erstinstallation von ESX Server 3.5 Update 4 durch.
  • Bei mancher Dell MLK-Hardware weist die Eigenschaft NumberOfBlocks für die OMC_Memory-Instanz einen Wert von 0 auf. Dieses Problem wird zurzeit untersucht.
  • Auf ESX Server 3.5 werden auf einigen HP-Systemen mit einem PROCHOT-Sensor fehlerhafte Systemzustandswarnungen ausgegeben (KB 1009137)
  • InvokeMethod(RequestPowerStateChange) und InvokeMethod(RequestStateChange) schlagen fehl, wenn Sie das WS-Man-Protokoll verwenden

Gastbetriebssysteme

  • 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.
  • VMware Tools-Upgrade auf Linux-Gästen erfordert manuellen Neustart des Netzwerkdienstes (KB 1004322)
  • Administrator kann sich nicht an geklonter virtueller Windows Vista-Maschine anmelden (KB 1004301)
  • Ubuntu 8.04 LTS und Ubuntu 7.10, 64-Bit SMP reagieren bei Ausführung, Installation oder Start auf einem Intel-Host möglicherweise nicht mehr (KB 1004384)
  • Deinstallationsprogramm der VMware Tools in Ubuntu-Gast führt nicht zum Entfernen des vmxnet-Moduls (KB 1004351)
  • 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
  • Die Linux-Gastbetriebssysteme verlieren ihre Verbindung zum Netzwerk nach einer automatischen Tool-Aktualisierung
    Wenn die Version der VMware Tools in einem Linux-Gastbetriebssystem veraltet ist und eine automatische Tool-Aktualisierung durchgeführt wird, geht für das Gastbetriebssystem die Verbindung zum Netzwerk verloren. Bei einer automatischen Tool-Aktualisierung stoppt das Gastbetriebssystem den Netzwerkdienst und startet den Dienst nicht automatisch neu, wenn das Upgrade beendet wurde.
    Umgehung: Starten Sie den Netzwerkdienst im Gastbetriebssystem manuell neu oder starten Sie das Gastbetriebssystem nach einer automatischen Tool-Aktualisierung neu.
  • vmx_svga-Treiber kann nicht in den Component Designer von Microsoft Windows Embedded Studio importiert werden

    vmx_svga-Treiber kann nicht in den Component Designer von Microsoft Windows Embedded Studio importiert werden. Eine Warnmeldung wird ausgegeben: C:\Programme\VMware\VMware Tools\Drivers\video\vmx_svga.inf: Fehler beim Abrufen des Abschnittsnamen der Herstellerliste.

    Umgehung:
    1. Öffnen Sie C:\Programme\VMware\VMware Tools\Drivers\video\vmx_svga.inf.
    2. Löschen Sie ", NTamd64.5.1, NTx86.6.0, NTamd64.6.0, NTia64" aus dem Abschnitt [Manufacturer] der Dateivmx_svga.inf.
    3. Importieren Sie den vmx_svga-Treiber in den Component Designer. Der vmx_svga-Treiber wurde erfolgreich in den Component Designer importiert.
    4. Speichern Sie den importierten Treiber als vmx_svga.sid.
    5. Importieren Sie vmx_svga.sid in die Komponentendatenbank.
  • 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.
  • Neu: Eine virtuelle Maschine, die das Virtual Machine Interface (VMI) verwendet, antwortet möglicherweise nicht mehr

    Umgehung: Wenn solch eine virtuelle Maschine nicht mehr reagiert, führen Sie die folgenden Schritte durch.
    1. Führen Sie den Befehl vm-support -x aus, um die World-ID dieser virtuellen Maschine zu ermitteln.
    2. Führen Sie den Befehl vmkload_app -k 9 wid aus, um die virtuelle Maschine vollständig zu beenden, damit sie neu gestartet werden kann. "wid" steht hierbei für die World-ID.

Internationalisierung

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

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

  • Die Angabe eines Nicht-ASCII-Werts als Eingabe wird nicht von der Remote-Befehlszeilenschnittstelle (RCLI) unterstützt.
  • Der Name des Computers, auf dem VMware Infrastructure 3 oder eine der zugehörigen Komponenten installiert wird, darf keine Nicht-ASCII-Zeichen enthalten.
  • Der Name des Computers oder der virtuellen Maschine, auf dem/der der VirtualCenter Server installiert ist, darf keine Nicht-ASCII-Zeichen im Computernamen aufweisen. 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 "Gesteuerte Konsolidierung" ist nur im Gebietsschema en_US verfügbar.

Übersetzungsprobleme

Für diese Version sind folgende Übersetzungsprobleme bekannt:

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

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

Migration mit VMotion

Sonstige Probleme

  • Der RPM-Name des QLogic-Treibers enthält eine irreführende Treiberversionsnummer
    Die Versionsnummern von Treibern halten sich an eine Namenskonvention, die es Ihnen ermöglicht, die RPM-Versionsnummer festzustellen, z. B.: VMware-esx-driver-<Treiber>-<Version #>

    In ESX Server 3.5 Update 4 verwendet das RPM-Paket des QLogic FC-Treibers jedoch den falschen Wert für die Treiberversion. Der RPM-Nme fü den Qlogic FC-Treiber lautet: VMware-esx-drivers-scsi-qla2300-v707_vmw-350.7.8.65-151188.i386.rpm

    Diese Nummer zeigt fälschlicherweise an, dass die Treiberversion 7.8.65 lautet. Die tatsächliche Treiberversion ist aber 7.8.66.
  • esxtop-Festplattenstatistiken können mehrere Pfade einschließen (KB 1003115)
  • CD-ROM oder Diskettenlaufwerk des Clients kann getrennt werden (KB 1003118)
  • Authentifizierung von IBM Director Server-Konsole gegenüber dem Director-Agenten schlägt mit dem Fehler "Zielsystem ist zurzeit nicht verfügbar" fehl (KB 1003123)
  • Das Laden von Treibermodulen für die parallele Schnittstelle in der Servicekonsole führt zu Warnungen in den ESX Server-Startprotokollen (KB 1003091)
  • Bei installiertem IBM Director 5.20.1-Agent auf ESX Server 3.5 zeigt die Director-Konsole möglicherweise die Gerätetreiber nicht an (KB 1003120)
  • UserDuct_Open schlägt beim Crossdup mit VMK_WOULD_BLOCK oder mit "Waiters List Not Empty"-Warnungen fehl (KB 1004385)
  • VirtualCenter Server ermittelt keine Änderungen der Host-IP-Adresse, sofern nicht die SSL-Zertifikatprüfung aktiviert wurde (KB 1003066)
  • ESX Server reagiert bei hoher E/A-Arbeitslast durch den aacraid-Treiber zeitweise nicht mehr (KB 1003039)
  • CPU-Auslastung erreicht nach der Installation von Dell OpenManage Spitzenwerte (KB 1004508)
  • Plug-In für den Converter Enterprise-Client muss nach dem Upgrade installiert und aktiviert sein
    VirtualCenter Server 2.5 Update 2 bietet keine Unterstützung für ältere Versionen des Plug-Ins für den Converter Enterprise-Client. Sie müssen deshalb das Plug-In für den Converter Enterprise-Client nach der Aktualisierung von VirtualCenter Server 2.5 Update 2 installieren und aktivieren. Um das Plug-In für den Converter Enterprise-Client zu installieren und zu aktivieren, klicken Sie auf Plug-Ins verwalten im Menü Plug-Ins. Wählen Sie im Fenster Plug-In-Manager die Registerkarte Verfügbar und klicken Sie auf Herunterladen und installieren.
  • Auf ESX 3.5 werden möglicherweise harmlose Warnungen über ACPI IRQ-Ressourceneinstellungen ausgegeben.
    Beim Starten analysiert der ESX Server die ACPI-Tabellen im BIOS, um die aktuellen und möglichen IRQ-Ressourceneinstellungen für Interrupt-Link-Geräte auf der Plattform zu ermitteln. Auf bestimmten Servern ist die aktuelle Ressourceneinstellung (_CRS) keine der möglichen Ressourceneinstellungen (_PRS). Dies führt zu Warnungen wie den Folgenden:

    "WARNING: VMKAcpi: 291: Interrupt (5) from _CRS is not one of _PRS values"

    "WARNING: VMKAcpi: 399: IRQ from _CRS is bad or not in _PRS, will use from _PRS"

    Dieses Szenario ist harmlos. Dieses Problem wurde in der vorliegenden Version dahin gehend behoben, dass die Warnmeldungen nicht mehr ausgegeben werden. Diese Meldungen werden stattdessen nun protokolliert.
  • 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 gleichnamigen Link unter der Registerkarte "Konfiguration".
    Umgehung
    Klicken Sie zum Aktualisieren des Sensorstatus auf der Systemzustandseite 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 gleichnamigen Link unter der Registerkarte "Konfiguration".
    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 address of ESX Server host>/host/ipmi_sel abgerufen werden, möglicherweise nicht die neuesten Datensätze des IPMI-Systemereignisprotokolls.

Netzwerk

  • Aktualisiert: NetQueue ist standardmäßig im unm_nic-Treiber aktiviert, allerdings unterstützt VMware zurzeit NetQueue nicht

    Umgehung:
    1. Entladen Sie den Treiber mit dem folgenden Befehl:
      vmkload_mod -u unm_nic
    2. Deaktivieren Sie NetQueue mit dem folgenden Befehl:
      esxcfg-module -s multi_ctx=0 unm_nic
    3. Laden Sie den Treiber neu mit dem folgenden Befehl: vmkload_mod unm_nic
      Hinweis: An Stelle von esxcfg-module lädt der folgende Befehl den Treiber mit deaktivierter NetQueue und bleibt nicht erhalten:
      vmkload_mod unm_nic multi_ctx=0
    4. (Optional) Um zu überprüfen, ob NetQueue für den Treiber deaktiviert ist, verwenden Sie den folgenden Befehl:
      esxcfg_module -g unm_nic
      Die folgende Zeichenfolge sollte angezeigt werden: multi_ctx=0
  • NetXen P2-Karten unterstützen maximal 128 GB RAM auf einer Maschine
  • 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 die 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)
  • Virtuelle Maschine mit Microsoft Windows schlägt beim Empfangen von Jumbo Frames fehl
    Virtuelle Maschinen mit Microsoft Windows schlagen beim Empfangen von Jumbo Frames fehl und zeigen einen blauen Bildschirm an, wenn der ESX Server-Host im Debugmodus gestartet wurde.
  • 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.
  • Neu: 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 -1 zurü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-nics oder 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.
  • ESX Server 3.5 mit einer Broadcom bnx2x-Netzwerkkarte antwortet beim Starten im Debugmodus möglicherweise nicht mehr

    Wenn sich ESX Server 3.5 beim Laden des Broadcom bnx2x-Treibers im Debugmodus befindet, wird eine Meldung ähnlich der Folgenden angezeigt:

    VMware ESX Server [BETAbuild-144117]
    Spin count exceeded (portsetGlobalLock) - possible deadlock

    Umgehung:
    Diese Umgehung verringert zwar die Häufigkeit des Auftretens des Problems, beseitigt das Problem aber nicht vollständig.

    Diese Umgehung (das Ändern der Konfigurationsoption LinkStatePollTimeout) kann andere Funktionen, wie z. B. die NIC-Gruppierung, beeinträchtigen. Deshalb sollte diese Umgehung nur verwendet werden, wenn das System beim Starten im Debugmodus nicht mehr reagiert.

    1. Legen Sie den Konfigurationsparameter /Net/LinkStatePollTimeout auf einen Wert zwischen 30000 und 60000 fest.
      Der folgende Befehl legt diesen Wert beispielsweise auf 30000 fest:
         & esxcfg-advcfg -s 30000 /Net/LinkStatePollTimeout

      Der für diese Konfigurationsoption zu verwendende genaue Wert hängt von der Anzahl der bnx2x-Netzwerkkarten auf dem System ab. Wenn das System eine große Anzahl an bnx2x-Netzwerkkarten umfasst, wählen Sie einen höheren Wert.
    2. Stellen Sie sicher, dass der Wert dieses Parameters korrekt festgelegt wurde:
      Der folgende Befehl zeigt beispielsweise die aktuelle Einstellung dieses Parameters an:
      $ esxcfg-advcfg -g /Net/LinkStatePollTimeout

      Eine Meldung ähnlich der Folgenden wird angezeigt: Der Wert von "LinkStatePollTimeout" ist "30000"
    3. Starten Sie das System im Debugmodus.
    4. Stellen Sie nach dem Neustart den Standardwert "5000" der Konfigurationsoption LinkStatePollTimeout wieder her.
      Das Wiederherstellen des Standardwerts "5000" der Konfigurationsoption LinkStatePollTimeout ist zum Starten des Systems im normalen Modus notwendig.

  • Ethtool zeigt die Firmwareversion falsch an

    Ethtool zeigt die Firmwareversion der Netzwerkkarte möglicherweise falsch an, wenn die Versionsnummer mit einer zweistelligen Zahl endet. Wenn die Versionsnummer z. B. 4.4.14 (zwei Stellen) ist, zeigt ethtool die Firmwareversion als 4.4.> an.

Serverkonfiguration

  • 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.
  • Falsche Konfiguration der MTU auf vSwitch führt dazu, das Pakete verworfen werden (KB 1008676)

Speicher

Aktualisierung und Installation

ESX Server-Upgrade und -Installation

Andere Upgrade- und Installationsprobleme

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, oder C:\Programme(x86)\VMware\VMware Tools\VMControlPanel.cpl bzw. <VMware tools install path>\VMControlPanel.cpl.
  • Geklonte virtuelle Maschinen enthalten kein DNS-Suffix (KB 1004299)
  • Geklonte virtuelle Maschinen sehen die .vmdk-Datei der Quell-VM (KB 1004176)
  • Benutzer mit Berechtigung "Erstellen" kann keine virtuellen Maschinen erstellen(KB 1004417)
  • Benutzerdefiniertes VMware Tools-Skript wird für Ereignisse "Anhalten" oder "Herunterfahren" nicht ausgeführt (KB 1004390)
  • E/A kann auf virtuellen Maschinen während der Firmware-Aktualisierung 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

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 HA nicht empfohlen (bzw. wird im vollautomatischen Modus nicht von VMware HA durchgeführt), wenn der Host in den Wartungs- oder Standby-Modus wechselt, da der VMware HA-Failover-Level beim Wechseln in den entsprechenden Modus verletzt werden kann. Diese Einschränkung gilt unabhängig davon, ob die strenge HA-Zugangssteuerung aktiviert ist oder nicht.
  • Die Statusüberwachung von VMware HA wird in der Konsole nach einem Host-Failover nicht mehr neu gestartet
    Die VMware-Konsolenanzeige zeigt nach einem Hostausfall ein leeres Fenster an, wenn für einen HA-Cluster die Statusüberwachung aktiviert wurde. Die Konsole zeigt den Neustart der virtuellen Maschine nicht an.

    Umgehung
    Sie müssen eine neue Konsole öffnen, damit 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 zeigen die Registerkarten "Aufgaben" und "Ereignisse" möglicherweise die folgende Fehlermeldung und Empfehlung an:

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

    Ab VirtualCenter 2.5 Update 2 verfügt HA über eine erweiterte Netzwerkübereinstimmungsprüfung zum Erhöhen der Clusterzuverlässigkeit. Diese erweiterte Netzwerkübereinstimmungsprüfung sorgt für ordnungsgemäße clusterübergreifende Taktsignal-Netzwerkpfade. 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

Seitenanfang

Support