Versionshinweise zu ESX 4.1 Update 1

Kontakt zum Vertrieb
 

ESX 4.1 Update 1 | 10. Februar 2011 | Build 348481
VMware Tools | 10. Februar 2011 | Build 348481

Letzte Dokumentaktualisierung: 10. Februar 2011

Diese Versionshinweise decken die folgenden Themen ab:

Neuigkeiten

Sie erhalten nachstehend Informationen zu einigen der wichtigsten Verbesserungen in der vorliegenden Version von VMware ESX:

  • Zusätzliche Datenbankunterstützung für vCenter und VMware Update Manager . vCenter 4.1 Update 1 und VMware Update Manager 4.1 Update 1 unterstützen die Verwendung von Microsoft SQL Server 2008 R2- und Oracle 11g R2-Datenbanken.
  • Benutzeroberfläche für das Konfigurieren von VMware Update Manager . vSphere 4.1 Update 1 führt eine neue grafische Benutzeroberfläche für die nachträgliche Konfiguration von VMware Update Manager (VUM) und VMware Update Manager Download Service ein. Diese grafische Benutzeroberfläche kann beispielsweise für die folgenden Konfigurationsaufgaben verwendet werden: Zurücksetzen des Kennworts (verwendet von VMware Update Manager zum Authentifizieren seiner Datenbank), Ersetzen von SSL-Zertifikaten (von VMware Update Manager verwendet), Neuregistrieren der VMware Update Manager-Erweiterung mit vCenter, sowie Konfigurieren des Proxy-Servers und der Authentifizierungsdetails (von VMware Update Manager Download Service verwendet).
  • Verbesserte Skalierbarkeit . ESX 4.1 Update 1 unterstützt bis zu 160 logische Prozessoren.
  • Verbesserte Leistung für einige Datenbank- und Terminalservices-Workloads . Durchsatz und CPU-Nutzung sind in ESX 4.1 Update 1 wesentlich verbessert, Migrationen für bestimmte Datenbank- und Terminalservices-Workloads sind stark reduziert.
  • Unterstützung zusätzlicher Gastbetriebssysteme . ESX 4.1 Update 1 bietet Unterstützung für Ubuntu 10.10, Solaris 10 U9 und RHEL 6. Eine vollständige Liste der in dieser Version unterstützten Gastbetriebssysteme finden Sie im VMware-Kompatibilitätshandbuch.

Behobene Probleme –Diese Version enthält darüber hinaus einige Fehlerkorrekturen, die im Abschnitt Behobene Probleme dokumentiert sind.

Seitenanfang

Vorherige Versionen von ESX 4.1

Funktionen und bekannte Probleme vorheriger Versionen von ESX 4.1 werden in den Versionshinweisen beschrieben. Klicken Sie auf den folgenden Link, um die Versionshinweise für die vorherige Version anzuzeigen:

Seitenanfang

Bevor Sie beginnen

ESX, vCenter Server und vSphere-Client – Versionskompatibilität

Die VMware vSphere-Kompatibilitätstabellen liefern Details zur Kompatibilität aktueller und früherer Versionen von VMware vSphere-Komponenten, einschließlich ESX, vCenter Server, vSphere-Client und anderer VMware-Produkte.

ESX, vCenter Server und VDDK-Kompatibilität

Virtual Disk Development Kit (VDDK) 1.2 bietet Unterstützung für ESX 4.1 Update 1 und vCenter Server 4.1 Update 1. Weitere Informationen zu VDDK finden Sie unter http://www.vmware.com/support/developer/vddk/.

Hardwarekompatibilität

  • Erfahren Sie mehr über Hardwarekompatibilität

    Die Listen zur Hardwarekompatibilität stehen in dem webbasierten Kompatibilitätshandbuch unter http://www.vmware.com/resources/compatibility zur Verfügung. Das webbasierte Kompatibilitätshandbuch stellt eine zentrale Quelle für alle VMware-Kompatibilitätshandbücher dar und bietet die Möglichkeit zur Suche in den Handbüchern und zum Speichern der Suchergebnisse im PDF-Format. Anhand des Handbuchs können Sie z. B. sicherstellen, dass Server, E/A, Speicher und Gastbetriebssysteme kompatibel sind.

    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 vSphere-Kompatibilität:

    Kompatibilitätstabellen für VMware vSphere ( PDF)

Installation und Upgrade

Detaillierte und Schritt-für-Schritt-Anweisungen zur Installation und Konfiguration von ESX und vCenter Server finden Sie im Installationshandbuch – ESX und vCenter Server.

Nach der erfolgreichen Installation müssen Sie einige weitere Konfigurationsschritte, insbesondere für die Lizenzierung, für Netzwerke und für die Sicherheitskonfiguration, ausführen. Beachten Sie die folgenden Handbücher in der vSphere-Dokumentation für weitere Informationen zu diesen Konfigurationsaufgaben.

Versionen nach VMware vSphere werden möglicherweise VMFS Version 2 (VMFS2) nicht unterstützen. Es wird empfohlen, auf VMFS Version 3 oder höher zu aktualisieren bzw. zu migrieren. Weitere Informationen finden Sie im vSphere-Upgrade-Handbuch.

Die Installation von Versionen nach VMware vCenter Server auf 32-Bit-Windows-Betriebssystemen wird nicht unterstützt. Sie können vCenter Server 4.1 nur auf Windows 64-Bit-Plattformen installieren. Wenn VirtualCenter 2.x installiert ist, finden Sie im vSphere-Upgrade-Handbuch weitere Informationen über das Installieren von vCenter Server auf einem 64-Bit-Betriebssystem und das Beibehalten der VirtualCenter-Datenbank.

MIB-Dateien, die sich auf ESX beziehen, werden nicht zusammen mit vCenter Server mitgeliefert. Nur MIB-Dateien, die sich auf vCenter Server beziehen, sind im Lieferumfang von vCenter Server 4.0.x enthalten. Alle MIB-Dateien können von der VMware-Website unter http://www.vmware.com/download heruntergeladen werden.

Durchführen eines Upgrades der VMware Tools

VMware ESX 4.1 Update 1 setzt ein Upgrade von VMware Tools voraus. VMware Tools besteht aus einer Reihe von Dienstprogrammen, welche die Leistung des Gastbetriebssystemens der virtuellen Maschine verbessern. Eine Liste der Probleme, die in dieser ESX-Version im Zusammenhang mit VMware Tools behoben wurden, finden Sie unter Behobene Probleme für VMware Tools.

Informationen zum Ermitteln der installierten VMware Tools-Version finden Sie in der Knowledgebase unter Verifizieren einer Build-Version der VMware Tools (KB 1003947).

Upgrade oder Migration auf ESX 4.1 Update 1

ESX 4.1 Update 1 bietet die folgenden Optionen für das Upgrade:

  • VMware vCenter Update Manager . [Informationen erforderlich]
  • vihostupdate . Befehlszeilenprogramm, das direkte Upgrades von ESX 4.0 auf ESX 4.1 Update 1 unterstützt. Dieses Dienstprogramm benötigt die vSphere-CLI. Weitere Informationen finden Sie im vSphere-Upgrade-Handbuch.
  • esxupdate . Befehlszeilenprogramm für ESX 4.0 auf ESX 4.1 Update 1. Weitere Informationen dazu finden Sie im Handbuch für die Patch-Verwaltung von ESX 4.1.
  • esxupgrade.sh Skript . Für ESX 3.5 Hosts ohne Netzwerkzugriff. Weitere Informationen hierzu finden Sie im Knowledgebase-Artikel 1009440. Wenn der Host über Netzwerkzugriff verfügt, können Sie den vCenter Update Manager verwenden, um das Upgrade durchzuführen. Im Falle von ESX 3.0.x-Hosts müssen Sie zunächst auf ESX 4.0 oder auf eine ESX 4.0 Update-Version aktualisieren, indem Sie vSphere Host Update Utility 4.0 oder vCenter Update Manager 4.0 verwenden. Anschließend können Sie mithilfe von vCenter Update Manager 4.1 oder des esxupdate - bzw. des vihostupdate -Dienstprogramms auf ESX 4.1 Update 1 aktualisieren. Genauere Anweisungen hierzu finden Sie im vSphere Upgrade-Handbuch.

Mehrere Upgrade-Tools, die in vorherigen ESX-Versionen unterstützt wurden, werden in der aktuellen Version nicht mehr unterstützt. Diese Tools umfassen Upgrades mit grafischer Benutzeroberfläche von CD, Upgrades im Textmodus von CD, Tarball-Upgrades mithilfe der Servicekonsole, Upgrades im Skriptmodus von CD oder einem PXE-Server unter Verwendung von esxupdate und Upgrades im Skriptmodus von CD oder einem PXE-Server mithilfe von Kickstart-Befehlen. VMware Update Manager ist das einzige Tool, das zum Durchführen von Upgrades von ESX 3.5.x auf ESX 4.1 unterstützt wird.

Wenn Sie ein Upgrade von ESX 4.0 auf ESX 4.1 Update 1 mithilfe der Offline-Upgrade-ZIP-Datei durchführen, wird in der Ausgabe des Befehls esxupdate -a querydas ESX 4.1 Update 1-Rollup-Bulletin als ESX410-U01 anstatt als ESX410-Update01 angezeigt. [Um zu überprüfen, ob diese Informationen hier eingefügt werden müssen.]

In dieser Version sind Fixes für das Tool esxupdateenthalten, welche die Anwendung von Patches und die Durchführung von Upgrades beeinflussen können. Installieren Sie das ESX410-201101203-UG-Patch, bevor Sie ein Upgrade auf ESX 4.1 Update 1 durchführen.

Unterstützte Upgrade-Pfade für das Host-Upgrade auf ESX 4.1 Update 1:

Upgrade-Typ

Unterstützte Upgrade-Tools

ESX 3.5
Update 5a

ESX 4.0

enthält:
Update 1
Update 2

ESX 4.1  

ESX-4.1.0-update01-345122.iso (Offline)

 VUM - Host-Upgrade-Baseline

Ja

Nein

Nein

Offline-Paket für ESX 4.0 - 4.1 Update 1
  • VUM - Host-Upgrade-Baseline
  • esxupdate
  • vihostupdate
  • Installieren Sie das Pre-Upgrade-Bulletin, wenn Sie das vihostupdate- oder das esxupdate-Dienstprogramm verwenden möchten, um das neue Installationsprogramm auf dem ESX-Host herunterzuladen.

Nein

Ja

Nein
update-from-esx4.1-4.1_update01.zip (Offline)
  • VUM – Patch-Baseline
  • esxupdate
  • vihostupdate
 Nein Nein Ja

ESX410-Update01 (Online)

VUM – Patch-Baseline

Nein

Nein

Ja

Anmerkungen:

In dieser Version enthaltene Patches

Diese Version enthält alle Bulletins für ESX, die vor dem Veröffentlichungsdatum dieses Produkts zur Verfügung standen. Weitere Informationen zu den einzelnen Bulletins finden Sie auf der VMware-Seite Patches herunterladen.

Patch-Version ESX410-Update01 enthält die folgenden einzelnen Bulletins: [Informationen erwartet]

ESX410-201101201-SG aktualisiert ESX 4.1-Kern- und CIM-Komponenten
ESX410-201101202-UG aktualisiert ESX 4.1 VMware-webCenter-esx
ESX410-201101203-UG aktualisiert ESX 4.1 vmware-esx-esxupdate
ESX410-201101204-UG aktualisiert ESX 4.1 mptsas-Gerätetreiber
ESX410-201101206-UG aktualisiert ESX 4.1 bnx2xi-Gerätetreiber
ESX410-201101207-UG aktualisiert ESX 4.1 bnx2x-Gerätetreiber
ESX410-201101208-UG aktualisiert ESX 4.1 sata-Gerätetreiber
ESX410-201101211-UG aktualisiert ESX 4.1 VMware-esx-remove-rpms
ESX410-201101212-SG aktualisiert ESX 4.1 krb5, openldap, pam-krb5
ESX410-201101213-UG aktualisiert vmware-esx-drivers-net-enic
ESX410-201101214-UG aktualisiert vmware-esx-drivers-scsi-qla4xxx
ESX410-201101215-UG aktualisiert ESX 4.1 vmware-esx-net-nx-nic
ESX410-201101216-UG aktualisiert ESX 4.1 vmware-esx-vaai
ESX410-201101217-UG aktualisiert vmware-esx-drivers-net-e1000e
ESX410-201101218-UG aktualisiert net-cdc-ether, net-usbnet-Treiber
ESX410-201101219-UG aktualisiert vmware-esx-drivers-net-e1000
ESX410-201101220-UG aktualisiert net-igb, net-tg3, scsi-fnic
ESX410-201101221-UG aktualisiert ESX 4.1 HP SAS-Controller
ESX410-201101222-UG aktualisiert mptsas, mptspi-Gerätetreiber
ESX410-201101225-UG aktualisiert die vmware-esx-pam-config-Bibliothek
ESX410-201101226-SG aktualisiert glibc-Pakete

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

Behobene Probleme

In diesem Abschnitt werden die behobenen Probleme dieser Version unter den folgenden Themengebieten beschrieben:

Behobene Probleme, die früher als bekannte Probleme dokumentiert wurden, werden mit dem Symbol "†" markiert.

Sicherung

  • Es können keine Snapshots von stillgelegten virtuellen Windows 2008 R2-Maschinen erstellt werden, auf denen vCenter Server 4.1 ausgeführt wird
    Beim Erstellen eines Snapshots einer virtuellen Windows 2008 R2-Maschine, auf der vCenter Server 4.1 installiert ist, kann der Snapshot-Vorgang fehlschlagen. Dieses Problem tritt auf virtuellen Windows 2008 R2-Maschinen auf, wenn die ADAM-Datenbank installiert ist und das Snapshot-Volume als schreibgeschützt markiert ist. Sicherungsanwendungen, wie z. B. VMware Date Recovery, sichern die virtuelle Maschine nicht. Die folgende Fehlermeldung wird ausgegeben: Es konnte kein Snapshot für <vmname> erstellt werden, Fehler -3960 (virtuelle Maschine kann nicht stillgelegt werden).
    Dieses Problem wurde in der vorliegenden Version behoben.

CIM und API

  • vCenter Server gibt das Service-Tag des Blade-Chassis falsch wieder
    Auf Blade-Servern, auf denen ESX 4.1-Hosts laufen, gibt vCenter Server das Service-Tag des Blade-Chassis anstatt des Service-Tags des Blade-Servers wieder. Wenn ein Blade-Server von vCenter Server verwaltet wird, wird die Nummer des Service-Tags im Abschnitt "System" auf der Registerkarte vCenter Server > Konfiguration unter Prozessoren aufgelistet. Dieses Problem wurde sowohl auf Dell- als auch auf IBM-Blade-Servern festgestellt. Es tritt aufgrund eines falschen Werts für die Eigenschaft "SerialNumber" der festen CIM OMC_Chassis-Instanz auf. Dieses Problem wurde in der vorliegenden Version behoben.

Gastbetriebssystem

  • Das Windows-Gastbetriebssystem schlägt möglicherweise mit einem vmx_fb.dll-Fehler fehl
    Windows-Gastbetriebssysteme, die mit dem VMware Windows XP-Grafiktreibermodell (XPDM) installiert sind, schlagen möglicherweise mit einem     vmx_fb.dll -Fehler und einem blauen Bildschirm fehl. Dieses Problem wurde in der vorliegenden Version behoben.
  • Die von virtueller Hardware zurückgelieferten CPUID-Informationen unterscheiden sich von der CPUID der physischen Hardware
    Die Gastsoftware verwendet die CPUID-Informationen möglicherweise, um die Merkmale der zugrunde liegenden (virtuellen oder physischen) CPU-Hardware festzustellen. In einigen Fällen unterscheiden sich die von der virtuellen Hardware zurückgelieferten CPUID-Informationen von denen der physischen Hardware. Aufgrund dieser Unterschiede funktionieren bestimmte Komponenten der Gastsoftware möglicherweise nicht ordnungsgemäß. Der Fix in dieser Version sorgt dafür, dass bestimmte CPUID-Rückmeldungen mit den Informationen, die die physische Hardware zurückliefern würde, noch näher übereinstimmen.
  • Die Installation von Betriebssystem-spezifischen Paketen (OSPs) von VMware Tools auf SUSE Linux 9 führt zu einem Fehler bei der Bildschirmauflösung†
    Wenn Sie die VMware Tools OSP in SUSE Linux 9 installieren, konfiguriert das Betriebssystem die Datei /etc/X11/XF86Config des X Window-Systems und ersetzt den Vesa-Videotreiber durch den VMware-Videotreiber. Wenn Sie einen vom Vesa-Treiber abweichenden Videotreiber verwenden, ersetzt VMware Tools OSP diesen nicht. Versuche, die Bildschirmauflösung mithilfe der grafischen Benutzeroberfläche oder dem Linux-Befehl xrandr zu ändern, schlagen fehl. Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Funktion zum Hinzufügen von Komponenten im laufenden Betrieb schlägt möglicherweise fehl, wenn ESX-Hosts über wenig physischen Arbeitsspeicher verfügen
    Das Vergrößern des Arbeitsspeichers für virtuelle Maschinen mithilfe der Funktion zum Hinzufügen von Komponenten im laufenden Betrieb schlägt fehl, wenn der verfügbare physische Arbeitsspeicher auf ESX-Hosts weniger als die doppelte Menge des Overhead-Arbeitsspeichers der virtuellen Maschine beträgt.
    Klicken Sie zum Anzeigen des verfügbaren physischen Arbeitsspeichers im vSphere-Client auf ESX-Hosts > Ressourcenzuteilung -> Arbeitsspeicher > Verfügbare Kapazität.
    Klicken Sie zum Anzeigen des Overhead-Arbeitsspeichers der virtuellen Maschine auf Virtuelle Maschinen > Ressourcenzuteilung > Arbeitsspeicher > Overhead.         Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Signaturprüfung des RPM-Installationsprogramms für VMware Tools für RHEL3, RHEL4 und SLES9 schlägt beim Prüfen der Paketsignatur fehl
    Wenn Sie das RPM-Installationsprogramm verwenden, um VMware Tools für RHEL3, RHEL4 und SLES9 zu installieren, schlägt die Signaturprüfung mit der folgenden Fehlermeldung fehl     V3 RSA/MD5 Signatur: NOKEY, Schlüssel-ID 66fd4949 Warnmeldung. Das Problem tritt auf, da ältere RPM-Versionen keine RSA-Signaturen prüfen können, die von neueren RPM-Versionen erzeugt wurden. Laden Sie zum Verifizieren der Signatur die Schlüsseldatei VMWARE-PACKAGING-GPG-DSA-KEY.pub von http://www.vmware.com/download/packages.html herunter. Nach dem Importieren der Schlüsseldatei erscheint keine Warnmeldung.
  • Aktualisiert den WDDM-Treiber
    In dieser Version wird der WDDM-Treiber (Windows Display Driver Model) aktualisiert, um einige Probleme zu beheben, bei denen eine virtuelle Windows-Maschine fehlschlägt und ein blauer Bildschirm angezeigt wird.

  • Die Arbeitsspeichergrößen in den standardmäßigen VM-Einstellungen von 32- und 64-Bit-RHEL-Gastbetriebssystemen wurden aktualisiert
    Die empfohlenen Mindest-, Standard- und Maximalgrößen für Arbeitsspeicher in den standardmäßigen VM-Einstellungen von 32- und 64-Bit-RHEL-Gastbetriebssystemen wurden gemäß den aktuellen RHEL 6-Betriebssystemspezifikationen unter http://www.redhat.com/ aktualisiert.

  • Nach einem Upgrade auf ESX 4.1 kann es vorkommen, dass eine virtuelle Maschine nicht mehr von DOS-basierter Clientsoftware gestartet werden kann
    Wenn eine DOS-basierte Clientsoftware (z. B. Altiris Deployment Solution) PXE zum Starten eines DOS-Images verwendet, schlägt die PXE-Startsequenz beim Bootstrapping des Images vom Server möglicherweise fehl und der Bootloader meldet möglicherweise den folgenden Status: 0xc0000001Fehler. Dieses Problem wurde in der vorliegenden Version behoben.

Sonstige Probleme

  • Warnung in /var/log/vmkwarning beim Start von ESX
    Warnmeldungen ähnlich der Folgenden erscheinen möglicherweise in     /var/log/vmkwarning , wenn ein ESX-Host gestartet wird:
    WARNING: AcpiShared: 194 SSDTd+: Table length 11108 > 4096
    Diese Warnung wird generiert, wenn ein ESX-Host eine ACPI-Tabelle vom BIOS liest und die Tabellengröße 4096 Byte überschreitet. Diese Warnung ist harmlos und kann daher ignoriert werden. Mit diesem Fix wird die Warnung in einen Protokolleintrag umgewandelt.
  • Der Befehl "lokkit" verursacht möglicherweise den Ausfall von ESX-Hosts
    Führen Sie den Befehl     lokkit nicht aus. Falls Sie ihn ausführen, klicken Sie auf Abbrechen, um sicherzugehen, dass die Servicekonsole nicht beschädigt wird. Falls Sie den Befehl lokkit auf der Servicekonsole eines ESX-Hosts ausführen, wird ein Firewall-Konfigurationsfenster mit Sicherheitsstufen- oder Netzwerkoptionen und drei Schaltflächen eingeblendet: OK, Anpassen und Abbrechen. Wenn Sie auf OK klicken, ohne die Sicherheitsstufe oder die Netzwerkoptionen geändert zu haben, erscheint möglicherweise die Meldung setenforce: SELinux ist deaktiviert auf der Servicekonsole. Der ESX-Host fällt aus und wird nicht neu gestartet. Dieses Problem tritt auf, wenn in einem veralteten system-config-securitylevel-tui-Paket der Befehl lokkit vorhanden ist. Dieses Paket wurde auf allen ESX-Hosts installiert, die älter als ESX 4.1 Update 1 sind. Das Problem wurde in dieser Version behoben.
  • Update der Servicekonsole
    Die Version der Servicekonsole wurde auf 2.6.18-194.11.1 aktualisiert. Diese neue Kernelversion der Servicekonsole behebt auch das Problem mit dem Stackzeigerunterlauf im 64-Bit-Kompatibilitätsmodus (CVE-2010-3081). Dieses Problem wurde bereits in einem ESX 4.1-Patch vor Version ESX 4.1 Update 1 gepatcht.
    Im Projekt "Common Vulnerabilities and Exposures" (cve.mitre.org) erscheinen diese Probleme unter den folgenden Namen: CVE-2010-1084, CVE-2010-2066, CVE-2010-2070, CVE-2010-2226, CVE-2010-2248, CVE-2010-2521, CVE-2010-2524, CVE-2010-0008, CVE-2010-0415, CVE-2010-0437, CVE-2009-4308, CVE-2010-0003, CVE-2010-0007, CVE-2010-0307, CVE-2010-1086, CVE-2010-0410, CVE-2010-0730, CVE-2010-1085, CVE-2010-0291, CVE-2010-0622, CVE-2010-1087, CVE-2010-1173, CVE-2010-1437, CVE-2010-1088, CVE-2010-1187, CVE-2010-1436, CVE-2010-1641 und CVE-2010-3081.
  • In den Netzwerkleistungsdiagrammen werden falsche Daten angezeigt
    In den Stapeldiagrammen, in denen die Netzwerkleistungen pro virtueller Maschine angezeigt werden, werden falsche Daten angezeigt. Über Erweiterte Einstellungen in den Diagrammoptionen auf der Registerkarte Leistung können Sie auf das Diagramm zugreifen. Die Netzwerkübertragungs- und Netzwerkempfangsstatistiken einer virtuellen Maschine (verbunden mit einem verteilten virtuellen Switch) wurden in vorherigen Versionen umgetauscht und daher falsch angezeigt. Der Fix sorgt dafür, dass die richtigen Statistiken erfasst und an die Leistungsdiagramm-UI übertragen werden.
  • Update der Tomcat-Version
    Tomcat wurde auf Version 6.0.28 aktualisiert. Die neue Version behebt mehrere Sicherheitsprobleme vorheriger Versionen. Im Projekt "Common Vulnerabilities and Exposures" (CVE) (cve.mitre.org) erscheinen alle Sicherheitsprobleme, die in Apache Tomcat 6.0.24 behoben wurden, unter den folgenden Namen: CVE-2009-2693, CVE-2009-2901, CVE-2009-2902, CVE-2009-3548. Im Projekt "Common Vulnerabilities and Exposures" (CVE) (cve.mitre.org) erscheinen alle Sicherheitsprobleme, die in Apache Tomcat 6.0.28 behoben wurden, unter den folgenden Namen: CVE-2010-2227 und CVE-2010-1157.
  • cURL-RPM für Servicekonsole wurde aktualisiert
    Der cURL-RPM für die ESX-Servicekonsole wurde auf curl-7.15.5-9.4652.vmw aktualisiert, um ein Sicherheitsproblem zu beheben. Im Projekt "Common Vulnerabilities and Exposures" (CVE) (cve.mitre.org) wird dieses Problem unter dem Namen CVE-2010-0734 angegeben.
  • Async-Treiber zu den ESX 4.1 Update 1-Patches hinzugefügt
    Async-Treiber, die in den ESX 4.1 Update 1-Patches enthalten sind, wurden in ISO und Patches integriert.

    Servicekonsolenpakete wurden aktualisiert
    Die Servicekonsolen-Kernelpakete wurden in dieser Version aktualisiert, um ein Sicherheitsproblem zu beheben. Im Projekt "Common Vulnerabilities and Exposures" (CVE) (cve.mitre.org) wird dieses Problem unter dem Namen CVE-2010-3081 angegeben.

  • Updates der Servicekonsolen- und glibc-RPMs
    Die Servicekonsolen-glibc-, glibc-common- und nscd-RPMs wurden auf glibc-2.5-34.4909.vmw, glibc-common-2.5-34.4909.vmw bzw. nscd-2.5-34.4909.vmw aktualisiert, um mehrere Sicherheitsprobleme zu beheben. Im Projekt "Common Vulnerabilities and Exposures" (cve.mitre.org) werden diese Probleme unter den Namen CVE-2010-3847 und CVE-2010-3856 angegeben.

Netzwerk

  • Fehleranzeige in Servicekonsole, weil bnx2-Geräte auf 6 Ports beschränkt sind
    Eine Fehlermeldung ähnlich der Folgenden wird auf der Servicekonsole des ESX-Hosts angezeigt:     CPU10:4118 - intr vector: 290:out of interrupt vectors . Vor der Anwendung dieses Fixes enthielten die bnx2-Geräte im MSI-X-Modus und der Jumbo-Frame-Konfiguration nur 6 Ports. In dieser Version weist der bnx2-Treiber nur 1 RX-Warteschlange im MSI-X-Modus zu, unterstützt 16 Ports und schont Arbeitsspeicherressourcen. Das Problem wurde in der vorliegenden Version behoben.
  • ESX schlägt möglicherweise auf HP-Systemen mit einem Fehler des Typs "loading 32.networking-drivers" fehl
    ESX schlägt möglicherweise auf HP-Systemen, wie z. B. DL 980 G7 mit HP NC522SFP Dual Port 10GbE Gigabit-Serveradaptern, fehl und zeigt dabei eine ähnliche Meldung wie     loading 32.networking-drivers an. Dieses Problem tritt auf, wenn ESX den NetXen-Treiber startet, und zwar gewöhnlich während des Startens von ESX-Hosts oder der Installation von Netzwerktreibern. Dies hängt von einigen HP-Systemkonfigurationen ab. Nach Anwenden dieses Fixes können Sie die NetXen NIC für Gigabit Ethernet-Konnektivität mit ESX-Hosts verwenden.
  • e1000e v1.1.2-Treiber hinzugefügt
    In vorherigen Versionen war der Intel e1000e v1.1.2-Treiber nicht im Lieferumfang von ESX enthalten. Er musste separat heruntergeladen werden. Der e1000e v1.1.2-Treiber ist nunmehr im Lieferumfang von ESX enthalten.      
  • Neue Version von QLogic qla2xxx-Treiber hinzugefügt
    Eine neue Version des QLogic qla2xxx-Treibers (832.k1.27.1-1vmw) wurde in dieser Version zertifiziert und freigegeben.
  • Neue Version des Neterion vxge-Treibers (async) hinzugefügt
    Diese Version enthält die Version 2.0.28.21239 des Neterion vxge-Treibers (async).
  • ESX-Hosts schlagen möglicherweise fehl mit bnx2x
    Wenn Sie VMware ESX 4.1 mit Broadcom bnx2x (integrierte Treiberversion 1.54.1.v41.1-1vmw) verwenden, treten möglicherweise die folgenden Symptome auf:
    • Der ESX-Host trennt möglicherweise oft die Verbindung zum Netzwerk.
    • Der ESX-Host reagiert möglicherweise nicht mehr. Stattdessen erscheint ein violetter Diagnosebildschirm mit Meldungen ähnlich der Folgenden:
      [0x41802834f9c0]bnx2x_rx_int@esx:nover: 0x184f stack: 0x580067b28, 0x417f80067b97, 0x
      [0x418028361880]bnx2x_poll@esx:nover: 0x1cf stack: 0x417f80067c64, 0x4100bc410628, 0x
      [0x41802825013a]napi_poll@esx:nover: 0x10d stack: 0x417fe8686478, 0x41000eac2b90, 0x4        
    • Der ESX-Host reagiert möglicherweise nicht mehr. Stattdessen erscheint ein violetter Diagnosebildschirm mit Meldungen ähnlich der Folgenden:
      0:18:56:51.183 cu10:4106)0x417f80057838:[0x4180016e7793]PktContainerGetPkt@vmkernel:nover+0xde stack: 0x1
      0:18:56:51.184 pu10:4106)0x417f80057868:[0x4180016e78d2]Pkt_SlabAlloc@vmkernel:nover+0x81 stack: 0x417f800578d8
      0:18:56:51.184 cpu10:4106)0x417f80057888:[0x4180016e7acc]Pkt_AllocWithUseSizeNFlags@vmkernel:nover+0x17 stack: 0x417f800578b8
      0:18:56:51.185 cpu10:4106)0x417f800578b8:[0x41800175aa9d]vmk_PktAllocWithFlags@vmkernel:nover+0x6c stack: 0x1
      0:18:56:51.185 cpu10:4106)0x417f800578f8:[0x418001a63e45]vmklnx_dev_alloc_skb@esx:nover+0x9c stack: 0x4100aea1e988
      0:18:56:51.185 cpu10:4106)0x417f80057918:[0x418001a423da]__netdev_alloc_skb@esx:nover+0x1d stack: 0x417f800579a8
      0:18:56:51.186 cpu10:4106)0x417f80057b08:[0x418001b6c0cf]bnx2x_rx_int@esx:nover+0xf5e stack: 0x0
      0:18:56:51.186 cpu10:4106)0x417f80057b48:[0x418001b7e880]bnx2x_poll@esx:nover+0x1cf stack: 0x417f80057c64
      0:18:56:51.187 cpu10:4106)0x417f80057bc8:[0x418001a6513a]napi_poll@esx:nover+0x10d stack: 0x417fc1f0d078        
    • Der bnx2x-Treiber oder die bnx2x-Firmware sendet Panikmeldungen und schreibt eine Rückverfolgung mit Meldungen ähnlich der Folgenden in die Protokolldatei /var/log/vmkernel :
      vmkernel: 0:00:34:23.762 cpu8:4401)<3>[bnx2x_attn_int_deasserted3:3379(vmnic0)]MC assert!
      vmkernel: 0:00:34:23.762 cpu8:4401)<3>[bnx2x_attn_int_deasserted3:3384(vmnic0)]driver assert
      vmkernel: 0:00:34:23.762 cpu8:4401)<3>[bnx2x_panic_dump:634(vmnic0)]begin crash dump        

  • ESX-Hosts werden möglicherweise nicht gestartet oder sorgen dafür, dass auf einige Geräte nicht zugegriffen werden kann, wenn NetXen 1G NX3031-Geräte oder mehrere 10G NX2031-Geräte eingesetzt werden
    Bei der Verwendung eines NetXen 1G NX3031-Geräts oder mehrerer 10G NX2031-Geräte wird nach einem Upgrade von ESX 4.0 möglicherweise eine Fehlermeldung ähnlich der Folgenden auf der Servicekonsole von ESX 4.1-Hosts angezeigt:     Out of Interrupt vectors. Auf ESX-Hosts, wo NetXen 1G- und NX2031 10G-Geräte NetQueue nicht unterstützen, werden möglicherweise die MSI-X-Interrupt-Vectoren knapp. Dies kann dazu führen, dass ESX-Hosts nicht gestartet werden können oder auf andere Geräte (wie z. B. Speichergeräte) nicht zugegriffen werden kann. Dieses Problem wurde in der vorliegenden Version behoben.

Speicher

  • Das Erstellen von großen VMDK-Dateien auf NFS schlägt möglicherweise fehl
    Wenn Sie eine große virtuelle Festplatte (.vmdk-Datei) auf einem NFS-Speicher erstellen, z. B. eine Festplatte mit einer Größe von mehr als 1 TB, schlägt der Erstellungsvorgang möglicherweise mit einem Fehler fehl:     Ein allgemeiner Systemfehler ist aufgetreten: Festplatte konnte nicht erstellt werden: Fehler bei der Erstellung der Festplatte . Dieses Problem tritt auf, wenn der NFS-Client nicht lange genug wartet, bis das NFS-Speicher-Array die virtuelle Festplatte initialisiert hat, nachdem eine Zeitüberschreitung des RPC-Parameters für den NFS-Client eingetreten ist. Der Standardwert für die Zeitüberschreitung beträgt 10 Sekunden.
    Dieser Fix stellt die Konfigurationsoption zum Optimieren des RPC-Zeitüberschreitungsparameters mithilfe des Befehls     esxcfg-advcfg -s <Timeout> /NFS/SetAttrRPCTimeout zur Verfügung.
  • Nicht unterstützte SCSI-Warnmeldungen in VMkernel protokolliert
    Nicht unterstützte SCSI-Warnmeldungen ähnlich der Folgenden werden in     /var/log/vmkernel geschrieben.
    Apr 29 04:10:55 localhost vmkernel: 0:00:01:08.161 cpu0:4096)WARNING: ScsiHost: 797: SCSI command failed on handle 1072: Nicht unterstützt . Die Meldungen können ignoriert werden. Diese harmlosen Meldungen erscheinen, weil gewisse SCSI-Befehle im Speicher-Array nicht unterstützt werden. In dieser Version werden die Warnmeldungen in /var/log/vmkwarning unterdrückt, um Supportanrufe zu reduzieren.
  • Meldungen werden in VMkernel-Protokolldateien protokolliert, wenn Speicher-Arrays vom vSphere-Client aus neu geprüft werden
    ESX-Hosts generieren möglicherweise Meldungen ähnlich der Folgenden in den VMkernel-Protokolldateien für LUNs, die ESX-Hosts nicht zugeordnet sind: 0:22:30:03.046 cpu8:4315)ScsiScan: 106: Pfad 'vmhba0:C0:T0:L0': Periphere Bezeichner 0x1 wird nicht unterstützt . Solche Meldungen werden protokolliert, wenn ESX-Hosts gestartet werden, wenn Sie vom vSphere-Client aus einen Vorgang zum erneuten Prüfen der Speicher-Arrays initiieren oder alle 5 Minuten nach dem Start eines ESX-Hosts. Ab dieser Version werden die Meldungen nicht mehr protokolliert.
  • Fehlermeldungen werden beim Prüfen auf LUNs im iSCSI-Speicher-Array protokolliert
    ESX-Hosts schlagen möglicherweise mit der Meldung     NOT_REACHED bora/modules/vmkernel/tcpip2/freebsd/sys/support/vmk_iscsi.c:648" auf einem violetten Bildschirm fehl, wenn Sie von der Servicekonsole aus mithilfe des Befehls esxcfg-swiscsi oder über den vSphere-Client ( Bestandsliste > Konfiguration > Speicheradapter > iSCSI-Softwareadapter) auf LUNs im iSCSI-Speicher-Array prüfen. Dieses Problem tritt möglicherweise auf, wenn der Parameter tcp.window.size in /etc/vmware/vmkiscsid/iscsid.conf manuell geändert wird. Dieser Fix behebt das Problem und protokolliert außerdem Warnmeldungen in /var/log/vmkiscsid.log für ESX, wenn der Wert des Parameters tcp.window.size in einen Wert geändert wird, der geringer als der Standardwert ist.
  • ESX-Hosts schlagen möglicherweise bei der Verwendung von LSI SAS HBAs fehl, die mit SATA-Festplatten verbunden sind
    Daten können bei ESX-Hosts verlorengehen, die LSI SAS HBAs verwenden, die mit SATA-Festplatten verbunden sind. Dieses Problem tritt auf, wenn die maximale E/A-Größe im mptsas-Treiber auf mehr als 64 KB festgelegt ist und LSI SAS HBAs mit SATA-Festplatten verbunden sind. Dieses Problem wurde in der vorliegenden Version behoben.
  • VMW_PSP_RR ist als standardmäßige Pfadauswahlrichtlinie für NetApp-Speicher-Arrays festgelegt, die SATP_ALUA unterstützen
    Die VMW_PSP_RR-Richtlinie ist als standardmäßige Pfadauswahlrichtlinie (PSP) für NetApp-Speicher-Arrays festgelegt, die SATP_ALUA unterstützen. Sie können diese Richtlinie über vCenter Server oder die Befehlszeilenschnittstelle (CLI) festlegen.
    So legen Sie diese Richtlinie über vCenter Server fest:
    1. Klicken Sie auf die Registerkarte Konfiguration.
    2. Wählen Sie im linken Bereich unter Hardwareadapter die Option Speicheradapter.
    3. Wählen Sie im rechten Bereich den vmhba aus, der mit den NetApp-LUNs verbunden ist.
    4. Wählen Sie die LUN aus, deren Pfadrichtlinie Sie ändern möchten, klicken Sie mit der rechten Maustaste und wählen Sie Pfade verwalten.
    5. Legen Sie im Dialogfeld, das eingeblendet wird, unter Richtlinie die Option Pfadauswahl auf Round Robin fest.

      Führen Sie zum Festlegen dieser Richtlinie über die CLI die folgenden Befehle auf der Servicekonsole aus:
      # esxcli nmp satp addrule --satp="VMW_SATP_ALUA" --psp="VMW_PSP_RR" --claim-option="tpgs_on" --vendor="NETAPP" --description="NetApp arrays with ALUA support"
      # esxcli corestorage claimrule load
      # esxcli corestorage claimrule run

      Das Problem wurde in dieser Version behoben.
  • VMW_PSP_RR ist als standardmäßige Pfadauswahlrichtlinie (PSP) für IBM 2810XIV-Speicher-Arrays festgelegt
    Die VMW_PSP_RR-Richtlinie ist als standardmäßige Pfadauswahlrichtlinie (PSP) für IBM 2810XIV-Speicher-Arrays festgelegt. Sie können diese Richtlinie über vCenter Server oder die Befehlszeilenschnittstelle (CLI) festlegen.
    So legen Sie diese Richtlinie über vCenter Server fest:
    1. Klicken Sie auf die Registerkarte Konfiguration.
    2. Wählen Sie im linken Bereich unter Hardwareadapter die Option Speicheradapter.
    3. Wählen Sie im rechten Bereich den vmhba aus, der mit den IBM-LUNs verbunden ist.
    4. Wählen Sie die LUN aus, deren Pfadrichtlinie Sie ändern möchten, klicken Sie mit der rechten Maustaste und wählen Sie Pfade verwalten.
    5. Legen Sie im Dialogfeld, das eingeblendet wird, unter Richtlinie die Option Pfadauswahl auf Round Robin fest.
      Führen Sie zum Festlegen dieser Richtlinie über die CLI die folgenden Befehle auf der Servicekonsole aus:
      # esxcli nmp satp addrule --satp="VMW_SATP_ALUA" --psp="VMW_PSP_RR" --claim-option="tpgs_on" --vendor="IBM" --model="2810XIV" --description="IBM 2810XIV-Arrays mit ALUA-Unterstützung"
      # esxcli nmp satp addrule --satp="VMW_SATP_DEFAULT_AA" --psp="VMW_PSP_RR" --claim-option="tpgs_off" --vendor="IBM" --model="2810XIV" --description="IBM 2810XIV arrays without ALUA support" # esxcli corestorage claimrule load
      # esxcli corestorage claimrule run

      Das Problem wurde in der vorliegenden Version behoben.
  • Die Zielinformationen einiger LUNs fehlen in der vCenter Server-UI
    Die Zielinformationen von LUNs werden manchmal in der vCenter Server-UI nicht angezeigt.    Führen Sie zum Anzeigen dieser Informationen auf der Registerkarte Konfiguration die folgenden Schritte aus:
    1. Klicken Sie auf unter "Hardware" auf Speicheradapter.
    2. Klicken Sie auf iSCSI-Hostbusadapter im Bereich Speicheradapter.
    3. Klicken Sie auf Pfade im Bereich Ansicht.
      In Versionen vor ESX 4.1 Update 1 wurden die Zielinformationen einiger iSCSI-LUNs nicht angezeigt. Dieses Problem wurde in der vorliegenden Version behoben.

  • Die Datei "txtsetup.oem" auf der Diskette verweist auf den falschen Speicherort des PVSCSI-Treibers
    Die Installation des Microsoft Windows Server 2003-Gastbetriebssystems auf ESX 4.1-Hosts mit VMware Paravirtual SCSI-Treiber (PVSCSI) als Startlaufwerk schlägt mit dem folgenden Fehler fehl:
    Legen Sie den Datenträger mit der Bezeichnung:
    VMware PVSCSI Controller Disk
    in das Laufwerk     A: ein
    Die Datei     txtsetup.o em auf einer Diskette verweist auf den falschen Speicherort des PVSCSI-Treibers. In der vorliegenden Version wird der Speicherort korrekt angegeben.
  • Die Funktion zum erneuten Prüfen von Standardspeicher wurde abgeändert, um außer Betrieb genommene Speichergeräte zu handhaben
    Die Funktion zum erneuten Prüfen von Speicher wurde abgeändert, um außer Betrieb genommene Speichergeräte zu handhaben, was zu dem Status "Keine Pfade verfügbar" ("all paths down", APD) führt. Weitere Informationen hierzu finden Sie im KB-Artikel 1015084 unter http://kb.vmware.com/kb/1015084. Die in diesem KB-Artikel angegebene Umgehung für dieses Problem sieht vor, die erweiterte Konfigurationsoption /VMFS3/FailVolumeOpenIfAPD auf 1 festzulegen, bevor das erneute Prüfen gestartet wird, und sie anschließend auf 0 zurückzusetzen, wenn der Vorgang abgeschlossen ist. Dieses Problem wurde in der vorliegenden Version behoben. Sie müssen diese Umgehung (Festlegen und Zurücksetzen dieser erweiterten Konfigurationsoption) beim Starten des Vorgangs zum erneuten Prüfen nicht anwenden. Virtuelle Maschinen auf Nicht-APD-Volumes schlagen während des Vorgangs zum erneuten Prüfen auch dann nicht mehr fehl, wenn sich einige LUNs im Status "Keine Pfade verfügbar" befinden.
  • Neue Version des 3ware SCSI-Treibers (async) hinzugefügt
    In dieser Version des Produkts ist die Version 2.26.08.036vm40-1OEM des 3ware SCSI-Treibers (async) enthalten.

Unterstützte Hardware

  • Das Energieverbrauchsdiagramm zeigt die Informationen einiger ESX-Hosts nicht an
    Das Energieverbrauchsdiagramm, auf das vom vSphere-Client für ESX-Host 4.1 zugegriffen wird, erscheint auf manchen ESX-Hosts von bestimmten Anbietern nicht. Im Diagramm wird ein Energieverbrauch von 0 Watt angezeigt. Um auf das Energieverbrauchsdiagramm vom vSphere-Client aus zuzugreifen, klicken Sie auf Host, klicken Sie dann auf die Registerkarte Leistung und wählen Sie anschließend Betrieb aus dem Dropdown-Menü aus. Das Energieverbrauchsdiagramm wurde in der vorliegenden Version aktualisiert, sodass nunmehr zusätzliche Hosts von Bull, Dell, HP, Mitsubishi, NEC und Toshiba unterstützt werden.

  • Zusätzliche Unterstützung für Dell iDRAC-Geräte
    In der vorliegenden Version wird das iDRAC Dell-Gerät mit der ID 413C:a102 unterstützt.

Upgrade und Installation

  • Abhängigkeitsauflösung von "esxupdate" ist nicht vereinbar mit der Bulletin-Richtlinie
    Die Abhängigkeitsauflösung des Dienstprogramms     esxupdate stimmt mit der Richtlinie für die Bulletinerstellung nicht überein. Beim Installieren von ESX-Hosts erscheinen weder Fehler- noch Warnmeldungen. Benutzer können nach der Installation die Informationen zum installierten VIB überprüfen, indem Sie in der Servicekonsole den Befehl esxupdate --vib-view query ausführen. Die Bulletin-Verteilungsrichtlinie sollte verwendet werden, damit die niedrigste erforderliche Version des VIBs verwendet wird, sodass Sie die von Ihnen installierten Fixes kontrollieren und unbekannte oder unerwartete Updates für ESX-Hosts vermeiden können.

Verwaltung von virtuellen Maschinen

  • Virtuelle Maschinen werden in manchen Fällen auch dann nicht gestartet, wenn Auslagerungsspeicherplatz auf ESX 4.1-Hosts vorhanden ist
    Das Starten einer virtuellen Maschine, die auf einem ESX 4.1-Host ausgeführt wird, schlägt mit der Fehlermeldung     Insufficient COS swap to power on fehl in /var/log/vmware/hostd.log , obwohl die Servicekonsole über 800 MB freien Speicherplatz verfügt und das Auslagern aktiviert ist. Zudem werden mehr als 20 MB freier Speicherplatz angezeigt, wenn der Befehl free -m in der Servicekonsole ausgeführt wird. Dieser Fix sorgt dafür, dass virtuelle Maschinen eingeschaltet werden können, wenn der Auslagerungsspeicherplatz auf ESX 4.1-Hosts vorhanden ist.
  • Nachdem eine virtuelle Maschine migriert wurde, werden USB-Geräte auf dem Zielhost fälschlicherweise als der virtuellen Maschine zugewiesen angezeigt
    Nachdem Sie eine virtuelle Maschine auf einen Zielhost migriert haben, der USB-Geräte enthält, und anschließend weitere USB-Geräte der migrierten virtuellen Maschine auf dem Zielhost hinzugefügt haben, erscheinen die USB-Geräte auf dem Zielhost möglicherweise als der virtuellen Maschine zugewiesen, obwohl sie ihr nicht zugewiesen sind.

    Das Fortsetzen einer virtuellen 64-Bit-Windows-Maschine aus dem angehaltenen Status führt möglicherweise dazu, dass die virtuelle Maschine ausfällt
    Wenn eine virtuelle 64-Bit-Windows-Maschine, die Softwaretechniken für die Virtualisierung des Befehlssatzes oder Binary Translation (BT) verwendet, aus dem angehaltenen Status fortgesetzt oder auf einen ESX 4.1-Host migriert wird, regiert die virtuelle Maschine möglicherweise nicht und die Microsoft Windows Event-Protokolle zeigen möglicherweise Fehlermeldungen ähnlich der Folgenden an:
    .NET Runtime
    .NET Runtime version * Fatal Execution Engine Error *
    Application Error:
    Faulting application name: oobe.exe *
    Faulting module name: mscorwks.dll *
    Exception code: 0xc00000005
    Das Problem wurde in der vorliegenden Version behoben.

vMotion und Storage vMotion

  • Snapshots, die auf ESX 3.5-Hosts erstellt wurden, können nicht wiederhergestellt werden
    Snapshots von ESX-Hosts können nach einem Upgrade von ESX 3.5 Update 4 auf ESX 4.1 Update 1 nicht wiederhergestellt werden. Die folgende Meldung wird möglicherweise in vCenter Server angezeigt:     Die Funktionen des oder der Prozessoren in dieser Maschine unterscheiden sich von denjenigen der Maschine, auf der der Prüfpunkt gespeichert wurde. Versuchen Sie, den Snapshot auf einer Maschine zu verwenden, deren Prozessoren über die gleichen Funktionen verfügen . Dieses Problem tritt möglicherweise auf, wenn Sie virtuelle Maschinen auf ESX 3.0-Hosts erstellen, vMotion ausführen, virtuelle Maschinen auf ESX 3.5-Hosts anhalten und diese anschließend auf ESX 4.x-Hosts fortsetzen. Die Fehlermeldung erscheint nicht in der vorliegenden Version. Sie können Snapshots wiederherstellen, die auf ESX 3.5-Hosts erstellt wurden, und dann die virtuellen Maschinen auf ESX 4.x-Hosts fortsetzen.
  • Die Auslagerungsdatei einer virtuellen Maschine vergrößert sich nach Abschluss von Storage vMotion
    Wenn eine virtuelle Maschine, die mit Arbeitsspeicherreservierung ausgeführt wird, mithilfe von Storage vMotion auf einen anderen Datenspeicher verschoben wird, weist die virtuelle Maschine nach Abschluss von Storage vMotion eine Auslagerungsdatei auf, deren Größe gleich der des konfigurierten Arbeitsspeichers ist. Meldungen ähnlich der Folgenden werden möglicherweise in den     vmware.log -Dateien der virtuellen Maschine protokolliert
    May 25 16:42:38.756: vmx| FSR: Decreasing CPU reservation by 750 MHz, due to atomic CPU reservation transfer of that amount. New reservation is 0 MHz.FSR: Decreasing memory reservation by 20480 MB, due to atomic memory reservation transfer of that amount. New reservation is 0 pages. CreateVM: Swap: generating normal swap file name.
    Wenn ESX-Hosts Storage vMotion ausführen, vergrößert sich die Auslagerungsdatei der virtuellen Maschinen auf "memsize". Nach Anwendung dieses Fixes bleibt die Größe der Auslagerungsdatei nach Ausführung von Storage vMotion unverändert.
  • ESX-Hosts schlagen möglicherweise fehl, wenn die Storage vMotion-Aufgabe beim Verlagern einer eingeschalteten virtuellen Maschine abgebrochen wird
    Das Abbrechen der Storage vMotion-Aufgabe beim Verlagern einer eingeschalteten virtuellen Maschine, die mehrere Festplatten auf demselben Datenspeicher enthält, auf einen anderen Datenspeicher auf demselben Host führt möglicherweise dazu, dass die ESX 4.1-Hosts mit dem folgenden Fehler ausfallen:     Exception: NOT_IMPLEMENTED bora/lib/pollDefault/pollDefault.c:2059 . Dieses Problem wurde in der vorliegenden Version behoben.

VMware Tools

  • Ein Fehler wird angezeigt, wenn VMware Tools bei angehaltener Druckwarteschlange installiert wird
    Wenn Sie VMware Tools auf einer virtuellen Maschine installieren, auf der die Druckwarteschlange angehalten wurde ( Verwaltung> Dienste> Druckwarteschlange), und auf VMware Tools installieren> Standard oder Benutzerdefiniertmit ausgewählter Thin Print-Funktion ( Benutzerdefiniertes Setup > VMware Gerätetreiber > Thin Print) klicken, wird beim Deinstallieren von VMware Tools der folgende Fehler angezeigt:     - Runtime Error! Program: C:\Program Files\VMware\VMware Tools\TPVCGateway.exe. This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information . Click OK to remove the error message and uninstall VMware Tools. Die Fehlermeldung erscheint nicht in der vorliegenden Version.
  • VMware-Systemsteuerungs-UI-Schaltfläche in der Windows-Systemsteuerung zum Durchführen des Upgrades für VMware Tools ist deaktiviert
    Die VMware-Systemsteuerungs-UI-Schaltfläche in der Windows-Systemsteuerung zum Durchführen des Upgrades für VMware Tools von einem Windows-Gastbetriebssystem aus ist für Nicht-Administrator-Benutzer deaktiviert. Zudem werden die Optionen Verkleinern und Skripts in der VMware Tools-Systemsteuerung für Nicht-Administrator-Benutzer deaktiviert. Dieser Fix besteht lediglich aus einer UI-Änderung und blockiert keine Upgrades von benutzerdefinierten Anwendungen. Um Upgrades von VMware Tools für alle Benutzer zu blockieren, legen Sie den Parameter     isolation.tools.autoinstall.disable="TRUE " in der VMX-Datei fest.
  • Die Installation von "vmware-open-vm-tools-xorg-utilities" schlägt möglicherweise fehl
    Wenn Sie "vmware-open-vm-tools-xorg-utilities" auf Gastbetriebssystemen installieren und wenn die Verzeichnisse     /usr und / auf verschiedenen Geräten gemountet sind, wird eine Fehlermeldung ähnlich der Folgenden angezeigt:
    failed: ln: creating hard link
    `/usr/lib/vmware-tools/libconf/etc/fonts/fonts.conf' =>
    `/etc/fonts/fonts.conf': Invalid cross-device link error     .
    Wenn Sie beispielsweise zypper (SLES-Paketmanager) ausführen, um "vmware-open-vm-tools-utilities" zu installieren, wird möglicherweise die oben erwähnte Fehlermeldung auf dem Bildschirm angezeigt. Wenn "vmware-open-vm-tools-xorg-utilities" versucht, Hard-Links auf     /etc/fonts/fonts.conf zu erstellen, tritt möglicherweise ein Problem beim geräteübergreifenden Link auf, wenn die Verzeichnisse /usr und / auf verschiedenen Geräten gemountet sind. Nach der Anwendung dieses Fixes können Sie "vmware-open-vm-tools-xorg-utilities" installieren.
  • Das Erstellen von Snapshots stillgelegter virtueller Maschinen schlägt möglicherweise auf nicht englischen Versionen von Microsoft Windows-Gastbetriebssystemen fehl
    Dieses Problem tritt auf, wenn ein bekannter Windows-Ordnerpfad Nicht-ASCII-Zeichen enthält, zum Beispiel der Anwendungsdatenordner in tschechischen Windows-Gastbetriebssystemen. Dieses Problem führt dazu, dass der Snapshot-Vorgang fehlschlägt. Dieses Problem wurde in der vorliegenden Version behoben.      

  • Snapshots stillgelegter virtueller Maschinen schlagen möglicherweise auf einigen nicht-englischen Versionen der Windows-Gastbetriebssysteme fehl
    Snapshots stillgelegter virtueller Maschinen schlagen möglicherweise auf einigen nicht-englischen Versionen der Windows-Gastbetriebssysteme fehl, beispielsweise auf französischen Gastbetriebssystemversionen von Windows 2008 R2 und Windows 7. Dieses Problem tritt auf, weil der VMware Snapshot Provider-Service auf einigen nicht englischen Versionen der Microsft Windows-Gastbetriebssysteme nicht ordnungsgemäß als Windows-Dienst oder COM+-Anwendung registriert wird. Dieses Problem führt dazu, dass der komplette Snapshot-Vorgang fehlschlägt und kein Snapshot erstellt wird. Dieses Problem wurde in der vorliegenden Version behoben.

Seitenanfang

Bekannte Probleme

In diesem Abschnitt werden bekannte Probleme dieser Version in den folgenden Themengebieten beschrieben:

Behobene Probleme, die früher nicht dokumentiert wurden, werden mit einem Sternchen (*) markiert.

Sicherung

  • VCB-Servicekonsolenbefehle generieren möglicherweise Fehlermeldungen in der ESX-Servicekonsole
    Wenn Sie VCB-Servicekonsolenbefehle in der Servicekonsole von ESX-Hosts ausführen, wird möglicherweise eine Fehlermeldung ähnlich der Folgenden angezeigt:     Closing Response processing in unexpected state:3 . Sie können diese Meldung ignorieren. Die Meldung hat keinen Einfluss auf die Ergebnisse der VCB-Servicekonsolenbefehle.

    Für dieses Problem gibt es zurzeit keine Umgehung.

CIM und API

  • SFCC-Bibliothek legt die SetBIOSAttribute-Methode in der generierten XML-Datei nicht fest
    Wenn die SFCC-Bibliothek (SFCC; Small Footprint CIM Client) versucht, die     SetBIOSAttribute -Methode der CIM_BIOSService -Klasse über SFCC auszuführen, wird von SFCC eine XML-Datei mit der folgenden Fehlermeldung zurückgegeben: ERROR CODE="13" DESCRIPTION="The value supplied is incompatible with the type" . Dieses Problem tritt auf, wenn die alte SFCC-Bibliothek das Festlegen des Methodenparametertyps in der generierten XML-Datei nicht unterstützt. Aufgrund dieses Problems können Sie die SetBIOSAttribute-Methode nicht aufrufen. Die SFCC-Bibliothek in ESX 4.1-Hosts legt den Methodenparametertyp in der generierten Socket-Stream-XML-Datei nicht fest.

    Hier einige Vorschläge für Umgehungen:
    • IBM aktualisiert die CIMOM-Version
    • IBM patcht die CIMOM-Version mit diesem Fix
    • IBM verwendet eine eigene Version der SFCC-Bibliothek

Gastbetriebssystem

  • Das Gastbetriebssystem reagiert nach dem Vergrößern des Arbeitsspeichers im laufenden Betrieb auf mehr als 3 GB möglicherweise nicht mehr *
    Das Redhat 5.4-64-Gastbetriebssystem reagiert möglicherweise nicht mehr, wenn es mit einem angeschlossenen IDE-Gerät gestartet wird und der Arbeitsspeicher im laufenden Betrieb von weniger als 3 GB auf mehr als 3 GB vergrößert wird.

    Umgehung: Verwenden Sie nicht die Funktion "Hot-Add" zum Ändern der Speichergröße der virtuellen Maschine von kleiner gleich 3072 MB auf über 3072 MB. Schalten Sie die virtuelle Maschine aus, um diese Neukonfiguration durchzuführen. Wenn das Gastbetriebssystem bereits nicht mehr antwortet, starten Sie die virtuelle Maschine neu. Das Problem tritt nur auf, wenn die 3-GB-Marke beim laufenden Betriebssystem überschritten wird.
  • Installationsfehler auf dem Windows NT-Gastbetriebssystem bei einer virtuellen Maschine mit Hardwareversion 7 *
    Wenn Sie Windows NT 3.51 in einer virtuellen Maschine mit der Hardwareversion 7 installieren, reagiert der Installationsvorgang nicht mehr. Das geschieht unmittelbar nach dem Erscheinen des blauen Startbildschirm, der bei Windows NT Version 3.51 angezeigt wird. Dies ist ein bekanntes Problem beim Windows NT 3.51 Kernel. Virtuelle Maschinen mit Hardwareversion 7 verfügen über mehr als 34 PCI-Busse und der Windows NT-Kernel unterstützt Hosts mit einer Obergrenze von 8 PCI-Bussen.

    Umgehung: Wenn es sich um eine Neuinstallation handelt, löschen Sie die vorhandene virtuelle Maschine und erstellen Sie eine neue. Bei der Erstellung der virtuellen Maschine wählen Sie Hardwareversion 4. Sie müssen den Assistenten für neue virtuelle Maschinen zum Auswählen eines benutzerdefinierten Pfads verwenden, um die Hardwareversion ändern zu können. Wenn Sie die virtuelle Maschine mit Hardwareversion 4 erstellt und auf Hardwareversion 7 aktualisiert haben, verwenden Sie VMware vCenter Converter zum Herabstufen der virtuellen Maschine auf Hardwareversion 4.
  • Das Installieren der VMware Tools OSP-Pakete auf SLES 11-Gastbetriebssystemen führt zur Fehlermeldung "Pakete nicht unterstützt" *
    Wenn Sie VMware Tools OSP-Pakete in einem SUSE Linux Enterprise Server 11-Gastbetriebssystem installieren, wird eine Fehlermeldung ähnlich der Folgenden angezeigt:     Die folgenden Pakete werden von ihrem Anbieter nicht unterstützt .

    Umgehung: Ignorieren Sie die Meldung. Die OSP-Pakete enthalten keine Kennzeichnung, die sie als vom Anbieter unterstützt markiert. Die Pakete werden dennoch unterstützt.
  • Das Kompilieren von VMware Kernel-Modulen wird nur für den laufenden Kernel unterstützt *
    VMware unterstützt derzeit nur das Kompilieren von Kernel-Modulen für den gerade laufenden Kernel.

    Umgehung: Starten Sie den Kernel, bevor Sie Module dafür kompilieren.

Sonstige Probleme

  • Das Ausführen von "resxtop" oder "esxtop" über einen längeren Zeitraum führt möglicherweise zu Arbeitsspeicherproblemen *
    Die Arbeitsspeichernutzung durch     resxtop oder esxtop erhöht sich möglicherweise mit der Zeit, je nachdem, was auf dem überwachten ESX-Host passiert. Dies bedeutet, dass sich resxtop oder esxtop bei Verwendung einer Standardverzögerung von 5 Sekunden zwischen zwei Anzeigen möglicherweise nach etwa 14 Stunden selbst abschaltet.

    Umgehung: Obwohl Sie die Option -nverwenden können, um die Gesamtzahl an Wiederholungen zu ändern, sollten Sie in Betracht ziehen, "resxtop" nur dann auszuführen, wenn Sie die Daten benötigen. Falls Sie resxtop- oder esxtop-Statistiken über einen längeren Zeitraum hinweg erfassen müssen, beenden Sie resxtopoder esxtopin regelmäßigen Abständen und starten Sie es neu, statt eine resxtop- oder esxtop-Instanz über Wochen oder Monate auszuführen.
  • Gruppen-ID-Länge in vSphere-Client ist kürzer als Gruppen-ID-Länge in vCLI *
    Wenn Sie eine Gruppen-ID mithilfe des vSphere-Clients angeben, sind nur neun Zeichen erlaubt. Dagegen können Sie bis zu zehn Zeichen angeben, wenn Sie die Gruppen-ID mithilfe von     vicfg-user vCLI angeben.

    Umgehung: Keine

  • Eine Warnmeldung wird angezeigt, wenn Sie den Befehl "esxcfg-pciid" ausführen
    Wenn Sie versuchen, den Befehl "esxcfg-pciid" in der Servicekonsole auszuführen, um die Ethernet-Controller und -Adapter aufzulisten, wird möglicherweise eine Warnmeldung ähnlich der Folgenden angezeigt:
    Vendor short name AMD Inc does not match existing vendor name Advanced Micro Devices [AMD]
    kernel driver mapping for device id1022:7401 in /etc/vmware/pciid/pata_amd.xml conflicts with definition for unknown
    kernel driver mapping for device id 1022:7409 in /etc/vmware/pciid/pata_amd.xml conflicts with definition for unknown
    kernel driver mapping for device id 1022:7411 in /etc/vmware/pciid/pata_amd.xml conflicts with definition for unknown
    kernel driver mapping for device id 1022:7441 in /etc/vmware/pciid/pata_amd.xml conflicts with definition for unknown

    Dieses Problem tritt auf, wenn sowohl die Plattformgeräte-Deskriptordateien als auch die treiberspezifischen Deskriptordateien Beschreibungen für dasselbe Gerät enthalten.

    Umgehung: Sie können diese Warnmeldung ignorieren.

Netzwerk

  • iSCSI kann nicht über Netzwerkkarte mit langem logischen Gerätenamen konfiguriert werden
    Bei Ausführung des Befehls     esxcli swiscsi nic add -n von einer Remotebefehlszeilenschnittstelle oder einer Servicekonsole aus wird iSCSI nicht über eine VMkernel-Netzwerkkarte konfiguriert, deren logischer Gerätename 8 Zeichen überschreitet. Netzwerkkartentreiber von Drittanbietern, die vmnic- und vmknic-Namen mit mehr als 8 Zeichen verwenden, funktionieren nicht mit der iSCSI-Port-Bindungs-Funktion in ESX-Hosts und geben möglicherweise Ausnahmefehlermeldungen in der Remotebefehlszeilenschnittstelle aus. Befehle wie z. B. esxcli swiscsi nic list, esxcli swiscsi nic add, esxcli swiscsi vmnic list , die von der Servicekonsole aus gestartet werden, schlagen fehl, weil sie von Drittanbietertreibern erstellte lange vmnic-Namen nicht handhaben können.

    Umgehung: Der Netzwerkkartentreiber des Drittanbieters muss die vmnic-Namen auf höchstens 8 Byte begrenzen, um mit den Anforderungen für iSCSI-Port-Bindungen kompatibel zu sein.
    Hinweis: Falls der Treiber nicht für iSCSI-Port-Bindungen verwendet wird, kann sein Name bis zu 32 Byte lang sein. Dies gilt auch für iSCSI ohne Port-Bindungs-Funktion.
  • Netzwerkverbindungsausfall und Systemfehler bei der Ausführung von Steuerungsvorgängen für physische Netzwerkkarten *
    In manchen Fällen, wenn mehrere X-Frame II s2io-Netzwerkkarten denselben PCI-X-Bus verwenden, verursacht die Ausführung von Steuerungsvorgängen für die physische Netzwerkkarte, wie z. B. das Ändern der MTU, eine Trennung der Netzwerkverbindung und einen Systemabsturz.

    Umgehung: Vermeiden Sie, mehrere X-Frame II s2io NICs in Steckplätze zu stecken, die sich denselben Pci-x-Bus teilen. Falls eine solche Konfiguration unumgänglich ist, vermeiden Sie es Kontrollvorgänge an physischen Netzwerkkarten durchzuführen, während in den virtuellen Maschinen Netzwerk-E/A-Vorgänge stattfinden.
  • Beim Weiterleiten von Datenpaketen (Traffic-Forwarding) virtueller Maschinen mit aktivierter LRO treten möglicherweise TCP-Performance-Probleme auf *
    Einige Linux-Module können LRO-generierte Pakete nicht handhaben. Infolgedessen kann es zu TCP-Performance-Problemen bei einer Datenverkehr weiterleitenden virtuellen Maschine kommen, wenn LRO an einem VMXNET2- bzw. VMXNET3-Gerät aktiviert und Linux als Gastbetriebssystem ausgeführt wird. Bei diesen Geräten ist LRO standardmäßig aktiviert.

    Umgehung: Konfigurieren Sie für Datenverkehr weiterleitende virtuelle Maschinen mit Linux-Gastbetriebssystemen den Modulladezeit-Parameter für die VMXNET2 - bzw. VMXNET3 -Linux-Treiber so, dass disable_lro=1 verwendet wird.
  • Es treten Arbeitsspeicherprobleme auf, wenn ein Host mehr als 1016 dvPorts an einem vDS verwendet *
    Die maximal zulässige Anzahl an dvPorts pro Host am vDS ist zwar 4096, es kann aber zu Arbeitsspeicherproblemen kommen, sobald die Zahl der dvPorts für einen Host sich 1600 nähert. Ist dies der Fall, können keine virtuellen Maschinen bzw. virtuellen Adapter mehr zum vDS hinzugefügt werden.

    Umgehung: Konfigurieren Sie eine Maximalzahl von 1016 dvPorts pro Host an einem vDS.
  • Ausführen von "vicfg-snmp -r or vicfg-snmp -D" auf ESX-Systemen schlägt fehl *
    Wenn Sie auf einem ESX-System versuchen, die aktuellen SNMP-Einstellungen durch Ausführen des Befehls     vicfg-snmp -r zurückzusetzen oder den SNMP-Agenten mit dem Befehl vicfg-snmp -D zu deaktivieren, schlägt der Befehl fehl. Der Fehler tritt auf, weil der Befehl versucht, den blockierten und nicht mehr reagierenden Befehl esxcfg-firewall auszuführen. Bei nicht reagierendem Befehl esxcfg-firewall führt der Befehl vicfg-snmp -r oder vicfg-snmp -D zu einer Zeitüberschreitung und signalisiert einen Fehler. Das Problem tritt auf ESXi-Systemen nicht auf.

    Umgehung: Durch das Starten des ESX-Systems wird die Sperrdatei gelöscht und der zuvor ausgeführte Befehl     vicfg-snmp , der die Sperre verursachte, angewendet. Allerdings tritt nach wie vor ein Fehler auf, wenn Sie versuchen, den Befehl vicfg-snmp -r oder vicfg-snmp -D auszuführen.
  • Das Neukonfigurieren der VMXNET3-Netzwerkkarte führt möglicherweise dazu, dass die virtuelle Maschine fortgesetzt wird *
    Das Neukonfigurieren einer VMXNET3-Netzwerkkarte bei aktiviertem Wake-on-LAN und während sich die virtuelle Maschine im Ruhezustand befindet, führt dazu, dass die virtuelle Maschine fortgesetzt wird.

    Umgehung: Versetzen Sie die virtuelle Maschine nach der Neukonfiguration einer VMXNET3 vNIC manuell in den Ruhezustand (beispielsweise nachdem Sie ein Hot-Add oder Hot-Remove ausgeführt haben).
  • Zuletzt erstellte VMkernel und Netzwerkadapter für Servicekonsole verschwinden nach dem Aus- und Wiedereinschalten *
    Wenn ein ESX-Host innerhalb einer Stunde nach dem Erstellen eines neuen VMKernels bzw. eines Servicekonsolenadapters auf einem vDS aus- und wiedereingeschaltet wird, kann es sein, dass der neue Adapter verschwindet.

    Umgehung: Wenn Sie einen ESX-Host innerhalb einer Stunde nach dem Erstellen eines VMkernels oder Servicekonsolenadapters aus- und wiedereinschalten müssen, führen Sie vor dem Neustart des Hosts     esxcfg-boot –r im CLI des Hosts aus.

Speicher

  • Große Anzahl speicherrelevanter Meldungen in der VMkernel-Protokolldatei *
    Wenn ESX auf einem Host mit mehreren physischen Pfaden zu Speichergeräten startet, zeichnet die VMkernel-Protokolldatei eine große Anzahl von speicherrelevanten Meldungen ähnlich der Folgenden auf:
    Nov 3 23:10:19 vmkernel: 0:00:00:44.917 cpu2:4347)Vob: ImplContextAddList:1222: Vob add (@&!*@*@(vob.scsi.scsipath.add)Add path: %s) failed: VOB-Kontextüberlauf
    Das System protokolliert mitunter ähnliche Meldungen beim erneuten Prüfen des Speichers. Die Meldungen stellen das erwartete Verhalten dar und sind kein Hinweis auf einen Fehler. Sie sind unbedenklich und können ignoriert werden.

    Umgehung: Wenn Sie die Meldungen nicht sehen möchten, schalten Sie die Protokollierung aus.
  • Dauerhafte Reservierungskonflikte auf gemeinsam genutzten LUNs können zum verlangsamten Starten von ESX-Hosts führen*
    Es kann zu erheblichen Verzögerungen beim Starten der Hosts kommen, die LUNs auf einem SAN gemeinsam nutzen. Das kann seine Ursache in Konflikten zwischen den LUN SCSI-Reservierungen haben.

    Umgehung: Um das Problem zu lösen und den Startvorgang zu beschleunigen, ändern Sie den Wert für die Zeitüberschreitung für synchrone Befehle während des Startvorgangs auf 10 Sekunden. Setzen Sie dazu den Parameter Scsi.CRTimeoutDuringBootauf 10000.

    So Ändern Sie den Parameter vom vSphere-Client aus:
    1. Wählen Sie im Bestandslistenfenster des vSphere-Clients den Host, klicken Sie auf die Registerkarte Konfiguration und anschließend unter "Software" auf Erweiterte Einstellungen.
    2. Wählen Sie SCSI.
    3. Ändern Sie den Parameter Scsi.CRTimeoutDuringBootauf 10000.

Unterstützte Hardware

  • Starten von ESX schlägt möglicherweise fehl, wenn die allowInterleavedNUMANodes-Startoption FALSE ist
    Auf einem IBM eX5-Host mit einer MAX 5-Erweiterung kann ESX nicht gestartet werden und zeigt in der Servicekonsole eine     SysAbort -Meldung an. Dieses Problem tritt möglicherweise auf, wenn die allowInterleavedNUMANodes -Startoption nicht auf TRUE gesetzt ist. Der Standardwert für diese Option ist FALSE.

    Umgehung: Setzen Sie die     allowInterleavedNUMANodes -Startoption auf TRUE. Weitere Informationen über das Konfigurieren der oben erwähnten Startoption für ESX-Hosts finden Sie in KB 1021454 unter http://kb.vmware.com/kb/1021454.
  • PCI-Geräte-Zuordnungsfehler bei HP ProLiant DL370 G6 *
    Wenn Sie E/A-Vorgänge auf dem HP ProLiant DL370 G6 durchführen, wird möglicherweise ein violetter Bildschirm oder es werden Warnungen zu "Lint1 Interrupt" bzw. NMI in der Konsole angezeigt. Der HP ProLiant DL370 G6 Server verfügt über zwei Intel I/O Hubs (IOH) und hat einen BIOS-Defekt in den Strukturdefinitionen des ACPI Direct Memory Access Remapping (DMAR). Dies führt bei einigen PCI-Geräten dazu, dass sie unter der falschen DMA-Remapping-Einheit beschrieben werden. Jeder DMA-Zugriff durch solche falsch beschriebenen PCI-Geräte löst einen IOMMU-Fehler aus und das Gerät empfängt einen E/A-Fehler. Je nach Gerät führt dieser E/A-Fehler möglicherweise zu einem Lint1-Interrupt oder zu einer NMI-Warnmeldung in der Konsole oder das System friert mit einem violetten Bildschirm ein.

    Umgehung: Aktualisieren Sie das BIOS auf 2010.05.21 oder eine spätere Version.
  • ESX-Installationen auf HP-Systemen benötigen den HP NMI-Treiber *
    ESX 4.1 Instanzen auf HP-Systems benötigen den HP NMI-Treiber, um ein einwandfreies Handling von "non-maskable" Interrupts (NMIs) zu gewährleisten. Der NMI-Treiber stellt sicher, dass NMIs korrekt erkannt und protokolliert werden. Ohne den Treiber werden NMIs, die Hardwarefehler signalisieren, auf HP-Systemen mit ESX ignoriert.
    Vorsicht: Wenn dieser Treiber bei der Installation nicht installiert wird, führt dies möglicherweise unbemerkt zur Datenbeschädigung.

    Umgehung: Laden Sie den NMI-Treiber herunter und installieren Sie ihn. Der Treiber steht als Offline-Paket auf der HP-Website zur Verfügung. Siehe zudem KB 1021609 unter http://kb.vmware.com/kb/1021609.
  • Virtuelle Maschinen werden möglicherweise schreibgeschützt, wenn sie auf einem iSCSI-Datenspeicher mit EqualLogic-Speicher laufen *
    Virtuelle Maschinen werden möglicherweise auf schreibgeschützt gesetzt, wenn Sie ein EqualLogic-Array mit einer älteren Firmware-Version verwenden. Die Firmware verliert gelegentlich E/A aus der Array-Warteschlange, was die virtuellen Maschinen veranlasst, auf schreibgeschützt zu wechseln, nachdem die E/A als fehlgeschlagen gekennzeichnet wurde.

    Umgehung: Aktualisieren Sie die EqualLogic Array Firmware auf Version 4.1.4 oder höher.
  • Nach dem Aktualisieren des Speicher-Arrays wechselt der Status der Hardwarebeschleunigung im vSphere-Client nach kurzer Verzögerung auf "unterstützt" *
    Beim Aktualisieren der Firmware eines Speicher-Arrays auf eine Version, die die VAAI-Funktionalität unterstützt, registriert vSphere 4.1 die Änderung nicht sofort. Der vSphere-Client zeigt vorübergehend "Unbekannt" als Status für die Hardwarebeschleunigung an.

    Umgehung: Diese Verzögerung ist unbedenklich. Der Status der Hardwarebeschleunigung ändert sich nach kurzer Zeit auf "Unterstützt".
  • ESX auf der HP G6-Plattform mit P410i oder P410 Smart Array-Controller läuft während des Einschaltens der virtuellen Maschinen oder bei Festplatten-E/A-Vorgängen langsam *
    Einige dieser Hosts laufen möglicherweise beim Einschalten von virtuellen Maschinen oder bei Festplatten-E/A-Vorgängen langsam. Das Hauptsymptom ist eine herabgestufte E/A-Leistung, wodurch viele Fehlermeldungen ähnlich der Folgenden in     /var/log/messages protokolliert werden:
    Mar 25 17:39:25 vmkernel: 0:00:08:47.438 cpu1:4097)scsi_cmd_alloc returned NULL
    Mar 25 17:39:25 vmkernel: 0:00:08:47.438 cpu1:4097)scsi_cmd_alloc returned NULL
    Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)NMP: nmp_CompleteCommandForPath: Command 0x28 (0x410005060600) to NMP device
    "naa.600508b1001030304643453441300100" failed on physical path "vmhba0:C0:T0:L1" H:0x1 D:0x0 P:0x0 Possible sense data: 0x
    Mar 25 17:39:26 0 0x0 0x0.
    Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)WARNING: NMP: nmp_DeviceRetryCommand: Device
    "naa.600508b1001030304643453441300100": awaiting fast path state update for failoverwith I/O blocked. No prior reservation
    exists on the device.
    Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)NMP: nmp_CompleteCommandForPath: Command 0x28 (0x410005060700) to NMP device
    "naa.600508b1001030304643453441300100" failed on physical path "vmhba0:C0:T0:L1" H:0x1 D:0x0 P:0x0 Possible sense data: 0x
    Mar 25 17:39:26 0 0x0 0x0

    Umgehung: Installieren Sie das HP 256MB P-series Cache-Upgrade-Modul von http://h30094.www3.hp.com/product.asp?mfg_partno=462968-B21&pagemode=ca&jumpid=in_r3924/kc.
  • Auf bestimmten Versionen des vSphere-Clients wird der Status des Akkus möglicherweise falsch als alarmierend angezeigt *
    Wenn sich der Akku im Lernmodus befindet, wird im vSphere-Client auf der Registerkarte Hardwarestatus eine Alarmmeldung angezeigt, die angibt, dass der Status des Akkus nicht in Ordnung ist. Allerdings ist der Ladezustand des Akkus in Ordnung.

    Umgehung: Keine.

Upgrade und Installation

  • Die Installation von vCenter Server 4.1 unter Verwendung einer vorhandenen IBM DB2-Datenbank schlägt manchmal fehl mit einer DB2 Fehlermeldung *
    Wenn Sie vCenter Server 4.1 unter Verwendung einer vorhandenen vCenter Server DB2-Datenbank installieren, erhalten Sie mitunter eine Fehlermeldung ähnlich der Folgenden:
    Es ist ein Datenbankfehler aufgetreten: "ODBC-Fehler: (5UA01) - [IBM][CLI Driver][DB2/NT64] SQL20453N Die Aufgabe "RULE_TOPN1_DB2USER1" kann nicht entfernt werden, da er gerade ausgeführt wird. SQLSTATE=5UA01" wird bei der Ausführung der SQL-Anweisung "CALL CREATE_TOPN_JOB1_PROC() " zurückgegeben
    Diese Meldung wird angezeigt, wenn bei DB2 ein bekanntes IBM-Problem auftritt. Sie bedeutet, dass eine DB2-Aufgabe ausgeführt wird und das vCenter Server-Installationsprogramm die vCenter-Datenbank nicht initialisieren kann.

    Umgehung: Um den Konflikt zu lösen und vCenter Server zu installieren, gehen Sie wie folgt vor:

    1. Wenn vCenter Server ausgeführt wird, fahren Sie ihn kontrolliert herunter.
    2. Verwenden Sie "Systemsteuerung - Verwaltung - Dienste", um den DB2-Service anzuhalten und neu zu starten.
    3. Starten Sie den Installationsvorgang erneut und stellen Sie sicher, dass Sie die Option zum Überschreiben der bestehenden Datenbank auswählen.

  • Die Installation des vSphere-Clients schlägt möglicherweise mit einem Fehler fehl *
    Wenn Sie den vSphere-Client installieren, kann es sein, dass das Installationsprogramm versucht, eine veraltete Laufzeitumgebung für Microsoft Visual J# zu aktualisieren. Das Upgrade ist nicht erfolgreich und die Installation des vSphere-Clients schlägt fehl mit der Meldung Das Installationsprogramm von Microsoft Visual J# 2.0 Second Edition hat den Fehler '4113' zurückgegeben.

    Umgehung: Deinstallieren Sie alle vorherigen Versionen von Microsoft Visual J# und installieren Sie anschließend den vSphere-Client. Die Installation enthält ein aktualisiertes Microsoft Visual J#-Paket.

    Die Standardisierung von Hosts, die von ESX 4.0.x auf ESX 4.1 aktualisiert werden, schlägt möglicherweise fehl *
    Die Standardisierung des Host-Upgrades schlägt möglicherweise fehl, da vor dem Neustart des Systems initrd nicht neu generiert werden kann. Dieses Problem tritt auf, nachdem Sie die beiden Host-Upgrade-Pakete (upgrade-from-ESX4.0-to-4.1.0-0.0.260247-release.zip und upgrade-from-esx4.0-to-4.1-update01.zip) in das Update Manager-Repository importiert haben. Ein bekanntes Problem in der Upgrade-Prüflogik von Update Manager verursacht dieses Problem.

    Umgehung: Installieren Sie Update Manager neu, um ihn wiederherzustellen. Installieren Sie zum Wiederherstellen des ESX 4.0.x-Hosts, bei dem dieser Fehler aufgetreten ist, das Upgrade-Paket manuell, indem Sie das Befehlszeilenprogramm     esxupdate ausführen.

vMotion und Storage vMotion

  • vMotion ist nach einem Neustart des ESX 4.1-Hosts deaktiviert
    Wenn Sie vMotion auf einem ESX-Host aktivieren und den ESX-Host neu starten, ist vMotion nach dem Neustart nicht mehr aktiviert.

    Umgehung: Um das Problem zu beheben, installieren Sie die neueste von Ihrem Systemanbieter bereitgestellte Version des ESX-Images erneut.

  • Hot-Plug-Vorgänge schlagen nach dem Verlagern der Auslagerungsdatei fehl *
    Hot-Plug-Vorgänge schlagen bei eingeschalteten virtuellen Maschinen in einem DRS-Cluster bzw. auf einem eigenständigen Host mit der Fehlermeldung Ziel konnte nicht fortgesetzt werden; VM wurde nicht gefundenfehl, nachdem der Speicherort der Auslagerungsdatei geändert wurde.

    Umgehung: Führen Sie eine der folgenden Aufgaben aus:
    • Starten Sie die betroffenen virtuellen Maschinen neu, um den neuen Speicherort der Auslagerungsdatei für diese Maschinen zu registrieren, und führen Sie anschließend die Hot-Plug-Vorgänge aus.
    • Migrieren Sie die betroffenen virtuellen Maschinen mithilfe von vMotion.
    • Halten Sie die betroffenen virtuellen Maschinen an.

Seitenanfang