Versionshinweise zu VMware ESX Server 3i, Version 3.5 Update 4 Installable

Kontakt zum Vertrieb
 

VMware ESX Server 3i Version 3.5 Update 4 Installable | 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 öffentlichen Dokumenten wird VMware ESX Server 3.5 nun VMware ESX 3.5 genannt, während VMware ESX Server 3i Version 3.5 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:

Experimentelle Unterstützung für PXE-Startvorgänge – ESX Server 3i Version 3.5 Update 4 Installable unterstützt PXE-Startvorgänge experimentell. Weitere Informationen finden Sie unter Installieren von VMware ESX Server 3i Version 3.5 Update 4 unter Verwendung von PXE-Booting (KB 1008971).

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
    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.
    • 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
    • IBM System-Management-Prozessor (iBMC)
    • SUN StorageTek 2530 SAS Array
    • Sun Storage 6580 Array
    • Sun Storage 6780 Array

    • Hinweise:

    Netzwerkkarten:

    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:

    Speicher-Arrays:

Seitenanfang

Vorgängerversionen von VMware Infrastructure 3

Funktionen und bekannte Probleme der Vorgängerversionen von VMware Infrastructure 3, zu denen ESX Server 3i, Version 3.5 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/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.

Registrieren Sie sich hier, um über Updates zum Kompatibilitätshandbuch 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 3i Version 3.5 Update 3 Installable gilt auch für ESX Server 3i Version 3.5 Update 4 Installable. 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 3i, Version 3.5 Update 4

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

Duchführen eines Upgrades der VMware Tools

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

ESX Server 3i Version 3.5 - lizenzfrei

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

Seitenanfang

In dieser Version enthaltene Patches

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

  • ESXe350-200903201-I-UG: Firmware-Update für ESXi 3.5 U4
  • ESXe350-200903202-T-UG: VMware Tools-Update für ESXi 3.5 U4
  • ESXe350-200903203-C-UG: VI-Client-Update für ESXi 3.5 U4 - Dieses Paket synchronisiert den VI-Client mit der neuesten Version von Update 4.

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

ESX Server 3i Version 3.5 Update 4 Installable enthält zudem alle Fixes in den folgenden bereits veröffentlichten Paketen:

  • ESXe350-200903411-O-BG
  • ESXe350-200901401-O-SG
  • ESXe350-200811401-O-SG
  • ESXe350-200810401-O-UG
  • ESXe350-200809401-O-SG
  • ESXe350-200808501-O-SG
  • ESXe350-200807812-O-BG
  • ESXe350-200808501-O-SG
  • ESXe350-200804401-O-BG
  • ESXe350-200802401-O-BG
  • ESXe350-200712401-O-BG

Mit ESX Server 3i, Version 3.5 Update 1 Installable veröffentlichtes Paket:

  • ESXe350-200803201-O-UG

Mit ESX Server 3i, Version 3.5 Update 2 Installable veröffentlichtes Paket:

  • ESXe350-200808201-O-UG

Mit ESX Server 3i, Version 3.5 Update 3 Embedded veröffentlichtes Paket:

  • ESXe350-200810401-O-UG

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

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 -ades 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 vcbRestorezum 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 vcbResAllmit der Option -awird ab dieser Version nicht mehr unterstützt.

CIM und API

  • Die obligatorischen Eigenschaften MaxReadable, NominalReading, NormalMax, NormalMinund PollingIntervalin der Klasse CIM_NumericSensorzeigen 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.
  • Auf HP 380 G5-Maschinen, auf denen ESX Server 3.5 Update 3 ausgeführt wird, wird als Antwort auf CIM_IPProtocolEndpoint-Abfragen die IP-Adresse der IPMI-Karte nicht zurückgegeben.

    Dieses Problem wurde in der vorliegenden Version behoben. CIM_IPProtocolEndpointverhält sich wie erwartet.
  • 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.
  • Unvorhersehbares Verhalten bei Verwendung des sfcbd-Skripts
    Auf ESX Server 3i Version 3.5 Update 4 wird der CIM-Broker-Daemon (SFCB) mit geringem Speicherbedarf über zwei Skripts gesteuert /etc/init.d/sfcbdund /etc/init.d/sfcbd-watchdog. Allerdings kann die Verwendung des Skripts /etc/init.d/sfcbdzum Starten, Beenden oder Neustarten zu unerwartetem Verhalten führen. Das korrekte Skript zum Starten, Beenden und Neustarten ist sfcbd-watchdog.

    Dieses Problem wurde in der vorliegenden Version behoben. Die Ausführung von Befehlen, die das sfcbd-Skript mit der start-, stop- oder restart-Option verwenden, wird nun sofort verhindert und eine Fehlermeldung wird ausgegeben, die erläutert, dass diese Vorgänge nicht zulässig sind.
  • 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

  • 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 restartin 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.
  • Auf ESX Server 3i Version 3.5 Update 4, auf dem Dell Open Manage-Management-Agenten ausgeführt werden, kann eine Spitze bei der CPU-Nutzung auftreten
    Eine Spitze in der CPU-Nutzung wurde festgestellt, wenn Dell Open Manage-Management-Agenten mit LSI MPT SCSI-Treibern oder MegaRAID SAS-Treibern interagiert. Dieses Problem wurde in der vorliegenden Version insofern behoben, dass die Spitzen bei der CPU-Nutzung in den aktualisierten Versionen der LSI MPT SCSI- und MegaRAID SAS-Treibern eliminiert wurden.
  • 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

  • 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.
  • Vor ESX Server 3i Version 3.5 Update 4 wurde die Verbindung zu allen USB-Geräten unterbrochen.
    Dieses Problem gilt nicht für ESX Server. Dieses Problem gilt für Versionen von ESX Server 3i Version 3.5 vor Update 4. Bestimmte Chipsätze (wie z. B. die Broadcom-Chipsätze) verwenden USB-Hostcontroller mit hoher Geschwindigkeit, deren Verbindungen zu allen USB-Geräten (einschließlich USB-Speichergeräten, wie z. B. USB-Flash-Laufwerke und USB CD-ROM-Laufwerke) unterbrochen wird. Ein Problem mit den "asynchronen Park-Modus-Bits" verursacht dieses Verbindungsproblem.

    Dieses Problem wurde in der vorliegenden Version insofern behoben, dass ESX Server 3i Version 3.5 Update 4 eine Fehlerkorrektur enthält, die die "asynchronen Park-Modus-Bits" der betroffenen Chipsätze selektiv deaktiviert und dadurch jede Verbindungsunterbrechung zwischen USB-Hostcontrollern mit hoher Geschwindigkeit und USB-Geräten verhindert.
  • 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:

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 GetInstancefü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.
  • 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.
  • 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_AssociatedSensorgeben 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 NumberOfBlocksfü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 Datei vmx_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.sidin 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 -xaus, um die World-ID dieser virtuellen Maschine zu ermitteln.
    2. Führen Sie den Befehl vmkload_app -k 9 widaus, 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

  • esxtop-Festplattenstatistiken können mehrere Pfade einschließen (KB 1003115)
  • CD-ROM oder Diskettenlaufwerk des Clients kann getrennt werden (KB 1003118)
  • Das Laden von Treibermodulen für die parallele Schnittstelle in der Servicekonsole führt zu Warnungen in den ESX Server-Startprotokollen (KB 1003091)
  • 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)
  • 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_selabgerufen werden, möglicherweise nicht die neuesten Datensätze des IPMI-Systemereignisprotokolls.
  • Gelegentlich gelingt ESX Server 3i Version 3.5 der Neustart des Servers nicht, wenn ein Neustart angefordert wurde (KB 1009394)

Netzwerk

  • Aktualisiert: NetQueue ist aktiviert, wird für den unm_nic-Treiber jedoch nicht unterstützt
    Da NetQueue für den unm_nic-Treiber nicht unterstützt wird, ist die Aktivierung des Treibers nicht angebracht. Die folgende Umgehung deaktiviert NetQueue für den unm_nic-Treiber.
    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-modulelä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)
  • Die Informationen zur Netzwerkkonfiguration auf der direkten Konsole sind möglicherweise inkonsistent
    Wenn Sie auf ESX Server 3i-Hosts F2 > Netzwerkadapter wählen, um die Informationen zur Netzwerkkonfiguration anzuzeigen, zeigt die Benutzerschnittstelle für eine Netzwerkkarte manchmal die MAC-Adresse und manchmal andere identifizierende Informationen an.
  • 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 -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.
  • 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

  • Anzeige falscher Gerätepfade für LUNs in Speicherübersicht (KB 1003064)
  • Manuell von einem ESX Server 2.x-Host auf einen ESX Server 3.x-Host migrierte VMs können anschließend möglicherweise nicht eingeschaltet werden (KB 1003069)
  • Ausführung von "esxcfg-mpath -l" kann zur Anzeige einer falschen Anzahl an LUN-Pfaden führen (KB 1003141)
  • ESX Server-Start von SAN auf einem Emulex LP1150- oder LPe1150-HBA nicht möglich (KB 1003067)
  • Vorhandensein eines entfernbaren Speichergeräts kann Converter an der erfolgreichen Konvertierung einer physischen Maschine in eine ESX Server-VM hindern (KB 1003042)
  • Bestimmte Sonderzeichen verursachen Fehler in der CHAP-Konfiguration für den Software-iSCSI-Initiator (KB 1003095)
  • Über QLogic-Adapter an einen McData FC-Switch angeschlossene Geräte werden nach einem Neustart gelegentlich nicht angezeigt (KB 1003040)
  • Einige Fibre-Channel-HBAs werden bei Aktivierung von BIOS-Start nicht initialisiert (KB 1003192)
  • ESX Server erkennt zweiten Hostbusadapter SAS LSI3444E in IBM x3650, Typ 7979 nicht (KB 1004486)
  • Nur ein vmhba für jeden SAS-Controller (Serial Attached SCSI) (KB 1004374)
  • ESX Server-Host kann Zugriff auf iSCSI-Ziele von Arrays der Serie EMC CX3 verlieren (KB 1004318)
  • Core-Dumps gehen verloren, wenn mehrere ESX-Hosts eine Dump-Partition teilen
    Wenn mehrere ESX-Hosts, die dieselbe Dump-Partition verwenden, ausfallen und gleichzeitig Core-Dumps speichern, können die Core-Dumps verloren gehen.
  • LSI-Aufgaben und nicht verknüpfte Speicherpools werden bei Starts nicht beibehalten
    Das von LSI implementierte dauerhafte Schema erstellt auf dem Hostbetriebssystem für jede Aufgabe und jeden nicht konkreten Speicherpool (ein Speicherpool, der nicht mit einem Speichervolumen verknüpft ist) eine neue Datei. Diese Dateien werden bei Starts nicht beibehalten. Aus diesem Grund sind nicht konkrete Speicherpools nicht mehr verfügbar, nachdem das Hostbetriebssystem neu gestartet wurde. Darüber hinaus werden alle ausgeführten Aufgaben vor dem Neustart nicht angezeigt.
    Unterstützung für 10GbE IP-Speicher (iSCSI und NFS) mit den Update-Versionen dient der Konnektivität. Die Gesamtleistung kann schwanken.
  • Das Anlegen einer großen Datei in einem übergreifenden VMFS-Datenspeicher schlägt möglicherweise fehl, wenn die erste Datenspeichererweiterung kleiner als 1 GB ist
    Wenn Sie versuchen, eine große virtuelle Festplattendatei in einem übergreifenden VMFS-Datenspeicher zu erstellen, schlägt dies möglicherweise fehl. Dieses Problem tritt üblicherweise auf, wenn die erste Datenspeichererweiterung zu klein ist, d. h. weniger als 1GB. Sie wird durch einen Mangel an Zeigerblocks verursacht.
    Umgehung: Falls möglich, erstellen Sie den Datenspeicher neu, indem Sie zunächst die größere Partition verwenden und anschließend die kleineren Erweiterungen hinzufügen.
  • SAS-Festplatten-Arrays (SAS, Serial Attached SCSI) können nicht als Raw-Device-Mapping-Festplatten unter Verwendung des VI-Clients hinzugefügt werden
    Wenn Sie den VI-Client zum Erstellen virtueller Maschinen auf Raw-Device-Mapping-Festplatten verwenden oder eine Festplatte zu einer virtuellen Maschine hinzufügen, wird die Option Raw-Device-Mapping im Assistenten für neue virtuelle Maschinen und im Assistenten zum Hinzufügen von Hardware deaktiviert.
    Umgehung:So fügen Sie SAS-Festplatten-Arrays als Raw-Device-Mapping-Festplatten hinzu:
    1. Führen Sie in der ESX Server-Servicekonsole folgenden Befehl mit der angegebenen Syntax aus:
    # vmkfstools -r <raw_device_path> -a <bus_type> <RDM_file_name>
    2. Fügen Sie mit dem Assistenten zum Hinzufügen von Hardware die neu erstellte virtuelle Festplatte als vorhandene Festplatte zur virtuellen Maschine hinzu.
  • Virtuelle Maschine kann nicht auf das physische CD-ROM-Laufwerk mit Intel I/O Controller Hub 9 (ICH9) oder Intel I/O Controller Hub 10 (ICH10) zugreifen
    Dieses Problem ist bislang auf ESX Server 3i Version 3.5 Update 4 Embedded und ESX Server 3i Version 3.5 Update 4 Installable aufgetreten. Sie können vom Gastbetriebssystem aus nicht auf das physische CD-ROM-Laufwerk des Hosts zugreifen. Dieses Problem tritt auf, wenn sich beim Starten des ESX Server-Hosts keine CD im CD-ROM-Laufwerk befand. Damit von einem Gastbetriebssystem aus auf das CD-ROM-Laufwerk zugegriffen werden kann, muss sich eine CD im Laufwerk befinden, wenn der ESX Server-Host gestartet wird.

    Umgehung: Prüfen Sie den Speicheradapter nach dem Einlegen der CD erneut, indem Sie die folgenden Schritte implementieren:
    1. Melden Sie sich über den VI-Client beim ESX Server-Host an.
    2. Klicken Sie auf die Registerkarte Konfiguration.
    3. Navigieren Sie zu Speicheradapter.
    4. Klicken Sie in der oberen rechten Ecke auf Erneut prüfen....
  • Die Kapazität einer zu einem Datenspeicher hinzugefügten LUN ist möglicherweise nicht sichtbar, wenn der VI-Client mit einem ESX Server-Host verbunden wird
    Sie können im Fenster "Speicher" der Registerkarte "Konfiguration" des VI-Clients die Eigenschaften eines Datenspeichers ändern. Wenn der VI-Client mit einem ESX Server-Host verbunden wird, wird im Fenster "Eigenschaften" die Kapazität für die hinzugefügte LUN möglicherweise nicht angezeigt, wenn Sie durch Klicken von Erweiterung hinzufügen im Fenster "Eigenschaften" des Datenspeichers LUNs zu einem Datenspeicher hinzufügen.
    Umgehung: Schließen Sie das Eigenschaftenfenster, klicken Sie auf den Link Speicher auf der Registerkarte Konfiguration und öffnen Sie das Eigenschaftenfenster 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 Host, der ESX 3.5 Update 4 ausführt, die Meldung "hda: Interrupt verloren" am Bildschirm an. Diese Fehlermeldung wird möglicherweise auch in /var/log/messagesgeschrieben. Dieses Problem führt zu keinem Datenverlust und kann ignoriert werden.

Aktualisierung und Installation

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

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

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

    Der ESX Server 3i Version 3.5-Host zeigt beim Starten von einer Wiederherstellungs-CD Sonderzeichen in der Fortschritts-Kontrollanzeige des Bootloaders an. Diese Zeichen sind ungefährlich und können ignoriert werden.
  • Neu: Der Befehl "esxupdate -l info" zeigt das Build-Datum des Pakets als Datum der Veröffentlichung an (KB 1009459)

ESX Server-Upgrade und -Installation

  • Das ESX Server-Installationsprogramm akzeptiert ungültige Subnetzmaske und fährt mit der Installation fort
    Wenn Sie beim Installieren von ESX Server mit dem textbasierten Modus eine ungültige Subnetzmaske eingeben, fährt das Installationsprogramm mit der Installation fort, ohne dass eine Fehlermeldung zurückgegeben wird. Im grafischen Modus der Installation zeigt das Installationsprogramm nur dann eine Fehlermeldung an, wenn der numerische Wert der eingegebenen Subnetzmaske 255 Zeichen überschreitet.
  • Ein Upgrade auf ESX Server 3, Version 3.5 kann bei fast voller Root-Partition zu einer unvollständigen Systemkonfiguration führen (KB 1003311)

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