Versionshinweise zu ESXi 4.1 Update 1

Kontakt zum Vertrieb
 

ESXi 4.1 Update 1 Installable | 10. Februar 2011 | Build 348481
ESXi 4.1 Update 1 Embedded | 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 ESXi:

  • 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 für Konfigurationsaufgaben verwendet werden, wie z. B. das Zurücksetzen des Kennworts, das VMware Update Manager zum Authentifizieren seiner Datenbank verwendet, das Ersetzen von SSL-Zertifikaten, die von VMware Update Manager verwendet werden, das Neuregistrieren der VMware Update Manager-Erweiterung mit vCenter sowie das Konfigurieren des Proxy-Servers und der Authentifizierungsdetails, die von VMware Update Manager Download Service verwendet werden.
  • Verbesserte Skalierbarkeit . ESXi 4.1 Update 1 unterstützt bis zu 160 logische Prozessoren.
  • Verbesserte Leistung für einige Datenbank- und Terminalservices-Workloads . ESXi 4.1 Update 1 bietet wesentliche Verbesserungen hinsichtlich des Durchsatzes sowie eine verbesserte CPU- Nutzung und stark reduzierte Migrationen für bestimmte Datenbank- und Terminalservices-Workloads.
  • Unterstützung zusätzlicher Gastbetriebssysteme . ESXi 4.1 Update 1 bietet Unterstützung für Ubuntu 10.10, Solaris 10 U9 und RHEL 6. Eine vollständige Liste der Gastbetriebssysteme, die in dieser Version unterstützt werden, finden Sie im VMware-Kompatibilitätshandbuch.

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

Seitenanfang

Vorherige Versionen von ESXi 4.1

Die Funktionen und bekannten Probleme der vorherigen Version von ESXi 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

ESXi, 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 ESXi, 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 ESXi 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

Bei einigen seltenen Szenarien können Sie kein Upgrade von ESXi 4.1 auf ESXi 4.1 Update 1 RC durchführen.

Dieses Problem tritt nur dann auf, wenn Ihr ESXi-Host die folgende Konfiguration aufweist:

  • ESXi-Host enthält blockbasierte Gerätetreiber, wie z. B. den HP DL380 G7, der über einen Smart Array P410i-Controller und einen cciss-Treiber verfügt
  • ESXi 4.1-Host hat das ESXi 4.1-Patch in Boot-Bank auf Partition 5 (und nicht auf Partition 6) installiert
    Hinweis: ESXi-Host wurde von ESXi 3.5 auf ESXi 4.1 aktualisiert (gilt nur für ESXi Installable)

Dieses Problem tritt aufgrund einer falsch ausgerichteten EBR-Datenstruktur innerhalb der erweiterten Partition auf. Der Inhalt der Partitionstabelle im EBR oder der logischen Partition ist nicht beschädigt. Die Patch-Installation schlägt aufgrund einer in ESXi 4.1 VMkernel eingeführten Plausibilitätsprüfung fehl, die ein vorzeitiges Abbrechen des Installationsvorgangs auslöst.

Falls dieses Problem bei Ihnen auftritt, installieren Sie ESXi 4.1 Update 1 RC neu. Das GA-Build von ESXi 4.1 Update 1 wird den Fix zum Durchführen eines Upgrades von ESXi 4.1 auf ESXi 4.1 Update 1 enthalten.

Lesen Sie das ESXi Installable und vCenter Server-Handbuch zur Einrichtung für Schritt-für-Schritt-Anweisungen zur Installation und Konfiguration von ESXi Installable und vCenter Server oder das ESXi Embedded und vCenter Server-Handbuch zur Einrichtung für Schritt-für-Schritt-Anweisungen zur Einrichtung von ESXi Embedded und vCenter Server durch.

Nach der erfolgreichen Installation von ESXi Installable oder dem erfolgreichen Starten von ESXi Embedded sind einige weitere Konfigurationsschritte erforderlich. Insbesondere sind Lizenzierungs-, Netzwerk- und Sicherheitskonfigurationen erforderlich. In den folgenden Handbüchern der vSphere-Dokumentation erhalten Sie weitere Informationen zu diesen Konfigurationsaufgaben.

Künftige Versionen von 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.

Künftige Versionen von VMware vCenter Server können nicht mehr auf 32-Bit-Windows-Betriebssystemen installiert werden. vCenter Server 4.1 kann nur auf 64-Bit-Windows-Plattformen installiert werden. 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 (Management Information Base), die sich auf ESXi beziehen, werden nicht zusammen mit vCenter Server ausgeliefert. Nur MIB-Dateien, die sich auf vCenter Server beziehen, werden mit vCenter Server 4.0.X mitgeliefert. 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 ESXi 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. Unter Behobene Probleme für VMware Tools finden Sie eine Liste der Probleme, die in dieser ESX-Version im Zusammenhang mit VMware Tools behoben wurden.

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 ESXi 4.1 Update 1

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

  • VMware vCenter Update Manager. <Information awaited>
  • 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. Führen Sie zum Anwenden des VEM-Pakets die Umgehung mithilfe des Dienstprogramms vihostupdate aus. Somit ist es möglich, ESXi 4.1 Update 1 Embedded-Host zum Cisco Nexus 1000 AV 2 vDS hinzuzufügen. .

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

Upgrade-Typ

Unterstützte Upgrade-Tools

ESX 3.5
Update 5

ESX 4.0

enthält:
Update 1
Update 2

ESX 4.1  

upgrade-from-ESXi3.5-to-4.1_update01.345122.zip (Offline)

 VUM

Ja

Nein

Nein

upgrade-from-esxi4.0-to-4.1-update01-345122.zip
  • VUM - Host-Upgrade-Baseline
  • vihostupdate

Nein

Ja

Nein
update-from-esxi4.1-4.1_update01.zip (Offline)
  • VUM – Patch-Baseline
  • vihostupdate
 Nein Nein Ja
ESXi410-Update01 (Online) VUM – Patch-Baseline Nein Nein Ja

Anmerkungen:

In dieser Version enthaltene Patches

Diese Version enthält alle Bulletins für ESXi, 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.

Zusätzlich zum ZIP-Dateiformat wird ESXi 4.1 Update 01 (Embedded und Installable) als Patch verteilt, der auf vorhandene Installationen der ESXi 4.1-Software angewendet werden kann.

Patch-Version ESXi410-Update01 enthält die folgenden einzelnen Bulletins:

ESXi410-201101201-SG Updates ESXi 4.1 firmware
ESXi410-201101202-SG Updates ESXi 4.1 Tools

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 ESXi 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 vCenter Server > Registerkarte 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 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.
  • Die Funktion zum Hinzufügen von Komponenten im laufenden Betrieb schlägt möglicherweise fehl, wenn ESXi-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 ESXi-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 ESXi-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.

  • 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 standmäßigen VM-Einstellungen von 32- und 64-Bit-RHEL-Gastbetriebssystemen wurden aktualisiert
    Die empfohlenen Mindest-, Standard- und Maximalgrößen für Arbeitsspeicher in den standmäß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 ESXi 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 ESXi
    Warnmeldungen ähnlich der Folgenden erscheinen möglicherweise in     /var/log/messages , wenn ein ESXi-Host gestartet wird:
    WARNING: AcpiShared: 194 SSDTd+: Table length 11108 > 4096
    Diese Warnung wird generiert, wenn ein ESXi-Host eine ACPI-Tabelle vom BIOS liest, wenn 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.
  • 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.
  • 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.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 Tomcat 6.0.28 behoben wurden, unter den folgenden Namen: CVE-2010-2227 und CVE-2010-1157.

  • In den Netzwerkleistungsdiagrammen werden falsche Daten angezeigt
    In den Stapeldiagrammen, in denen die Netzwerkleistungen pro virtueller Maschine angezeigt werden, werden falsche Daten angezeigt. Auf das Diagramm kann von den Diagrammoptionen in den erweiterten Einstellungen der Registerkarte Leistung zugegriffen werden. Die Statistiken für die Netzwerkübertragung und den Empfang einer mit einem verteilten virtuellen Switch verbundenen virtuellen Maschine 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.

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

  • ESXi-Host-Maschinen mit mehr als 64 GB Arbeitsspeicher werden nicht gestartet, wenn "Trusted"-Start aktiviert ist
    ESXi 4.1-Host-Maschinen mit mehr als 64 GB Arbeitsspeicher werden nicht gestartet, wenn Trusted Platform Module (TPM) und Trusted Execution Technology (TXT) vorhanden und im BIOS aktiviert sind. Dieses Problem wurde in der vorliegenden Version behoben.

Netzwerk

  • Fehler aufgrund einer Beschränkung auf 6 Ports für bnx2-Geräte in Servicekonsole angezeigt
    Eine Fehlermeldung ähnlich der Folgenden wird auf der Servicekonsole des ESXi-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 eine RX-Warteschlange im MSI-X-Modus zu, unterstützt 16 Ports und schont Arbeitsspeicherressourcen. Das Problem wurde in der vorliegenden Version behoben.
  • ESXi schlägt möglicherweise auf HP-Systemen mit einem Fehler des Typs "loading 32.networking-drivers" fehl
    ESXi 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 ESXi den NetXen-Treiber startet, und zwar gewöhnlich während des Startens von ESXi-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 ESXi-Hosts verwenden.
  • e1000e v1.1.2-Treiber hinzugefügt
    In vorherigen Versionen war der Intel e1000e v1.1.2-Treiber nicht im Lieferumfang von ESXi enthalten. Er musste separat heruntergeladen werden. Der e1000e v1.1.2-Treiber ist nunmehr im Lieferumfang von ESXi 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).
  • ESXi-Hosts schlagen möglicherweise fehl mit bnx2x
    Wenn Sie ESXi 4.1 mit Broadcom bnx2x (integrierte Treiberversion 1.54.1.v41.1-1vmw) verwenden, treten möglicherweise die folgenden Symptome auf:
    • Der ESXi-Host trennt möglicherweise oft die Verbindung zum Netzwerk.
    • Der ESXi-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 ESXi-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.  

Serverkonfiguration

  • Systemuhr zeigt die falsche Uhrzeit an
    In seltenen Fällen zeigt die Systemuhr auf ESXi-Hosts die falsche Uhrzeit an. 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 ESXi-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 ESXi-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 ESXi-Hosts. Ab dieser Version werden die Meldungen nicht mehr protokolliert.
  • Fehlermeldungen werden beim Prüfen auf LUNs im iSCSI-Speicher-Array protokolliert
    ESXi-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 ESXi, wenn der Wert des Parameters tcp.window.size in einen Wert geändert wird, der geringer als der Standardwert ist.
  • ESXi-Hosts schlagen möglicherweise bei der Verwendung von LSI SAS HBAs fehl, die mit SATA-Festplatten verbunden sind
    Daten können bei ESXi-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 ESXi 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 ESXi-Hosts nicht an
    Das Energieverbrauchsdiagramm, auf das vom vSphere-Client für ESX 4.1-Hosts zugegriffen wird, erscheint auf manchen ESXi-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.

  • Verbesserungen an Tboot sowie am Melden und Behandeln von SINIT-Fehlern
    Falls Tboot einen ESXi-Host nicht im sicheren Modus starten kann, wird eine Fehlermeldung ähnlich der Folgenden angezeigt:
    Intel TXT-Boot ist bei einem vorherigen Versuch fehlgeschlagen. TXT.ERRORCODE:<error code>. <description>
    Dieses Problem wurde in der vorliegenden Version behoben.

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 ESXi-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 ESXi-Hosts vermeiden können.

  • Wenn Sie einen ESXi-Host nach einem erfolgreichen Upgrade auf Version 4.1 neu starten, wird eine Fehlermeldung angezeigt †
    Wenn Sie den ESXi-Host nach einem erfolgreichen Upgrade, das vom Dienstprogramm "vihostupdate" ausgeführt wurde, neu starten, wird möglicherweise die folgende Fehlermeldung angezeigt: Das neue Upgrade-Image ist offenbar beschädigt, das Upgrade schlägt möglicherweise fehl. Dies tritt nur bei einem Upgrade von der ESXi-Version 4.0 oder 4.0 Update 1 auf die Version ESX 4.1 auf. Dies gilt nicht für Upgrades von ESX 4.0 Update 2.

  • Die DNS-Server-Einstellungen gehen nach dem zweiten ESXi-Neustart verloren†
    Nachdem ESXi unter Verwendung der Skriptinstallationsmethode installiert wurde, gehen die DNS-Server-Einstellungen verloren, wenn ESXi zum zweiten Mal neu gestartet wird. Die Einstellungen sind nach dem ersten Neustart nach der Installation vorhanden, gehen aber nach dem zweiten Neustart verloren. Dieses Problem wurde in der vorliegenden Version behoben.

  • ESXi 4.1 kann von einem USB-Laufwerk unter Verwendung der Skriptinstallationsmethode nicht installiert werden
    Wenn Sie versuchen, ESXi 4.1 mithilfe des auf einem USB-Laufwerk gespeicherten Skripts zu installieren, oder wenn sich das Installationsmedium auf einem USB-Laufwerk befindet, wird der ESXi 4.1-Installationsvorgang angehalten und die folgende Meldung angezeigt:
    Total number of sectors not a multiple of sectors per track!
    Add mtools_skip_check=1 to your .mtoolsrc file to skip this test.
    Das Problem wurde in der vorliegenden Version behoben.

Verwaltung von virtuellen Maschinen

  • Virtuelle Maschinen werden in manchen Fällen auch dann nicht gestartet, wenn Auslagerungsspeicherplatz auf ESXi 4.1-Hosts vorhanden ist
    Das Starten einer virtuellen Maschine, die auf einem ESXi 4.1-Host ausgeführt wird, schlägt mit der Fehlermeldung     Insufficient COS swap to power on in /var/log/vmware/hostd.log fehl, 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 ESXi 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 Zustand 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 Zustand fortgesetzt oder auf einen ESXi 4.1-Host migriert wird, reagiert die virtuelle Maschine möglicherweise nicht und die Microsoft Windows Ereignisprotokolle 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 ESXi 3.5-Hosts erstellt wurden, können nicht wiederhergestellt werden
    Snapshots von ESXi-Hosts können nach einem Upgrade von ESXi 3.5 Update 4 auf ESXi 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 ESXi 3.5-Hosts anhalten und diese anschließend auf ESXi 4.x-Hosts fortsetzen. Die Fehlermeldung erscheint nicht in der vorliegenden Version. Sie können Snapshots wiederherstellen, die auf ESXi 3.5-Hosts erstellt wurden, und dann die virtuellen Maschinen auf ESXi 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 ESXi-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.
  • ESXi-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 ESXi 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.      

Seitenanfang

Bekannte Probleme

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

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

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 ESXi 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

  • 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 ESXi-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-pciidin 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.
  • Hinzufügen eines ESXi 4.1 Update 1 Embedded-Hosts zu Cisco Nexus 1000V Release 4.0(4)SV1(3a) schlägt fehl
    Möglicherweise können Sie über vCenter Server keinen ESXi 4.1 Update 1 Embedded-Host zu Cisco Nexus 1000V Release 4.0(4)SV1(3a) hinzufügen.

    Umgehung
    Verwenden Sie zum Hinzufügen eines ESXi 4.1 Update 1 Embedded-Hosts zu Cisco Nexus 1000V Release 4.0(4)SV1(3a) das Dienstprogramm vihostupdate, um das VEM-Paket auf ESXi-Hosts anzuwenden.
    Führen Sie die folgenden Schritte aus, um einen ESXi 4.1 Update 1 Embedded-Host hinzuzufügen:
    1. Richten Sie Cisco Nexus 1000V Release 4.0(4)SV1(3a) ein.
    2. Richten Sie vCenter Server mit dem installierten VUM-Plug-In ein.
    3. Stellen Sie eine Verbindung zwischen Cisco Nexus 1000V Release 4.0(4)SV1(3a) und vCenter Server her.
    4. Erstellen Sie einen Datencenter und fügen Sie den ESXi 4.1 Update 1 Embedded-Host zu vCenter Server hinzu.
    5. Fügen Sie ESXi 4.1 Update 1 Compatible AV.2 VEM Bits zu einem ESXi-Host hinzu, indem Sie den folgenden Befehl von der vSphere-CLI aus ausführen:
      vihostupdate.pl --server <Server IP> -i -b <VEM offline metadata path>
      Auf der Servicekonsole erscheinen die folgenden Eingabeaufforderungen:
      Benutzername eingeben:
      Kennwort eingeben:
      Bitte warten Sie, während der Patch installiert wird...
    6. Navigieren Sie nach dem Update der Patches zur Ansicht Netzwerk in vCenter Server und fügen Sie den Host in Cisco Nexus 1000V Release 4.0(4)SV1(3a) hinzu.
    7. Stellen Sie sicher, dass ESXi 4.1 Update 1-Host zu Cisco Nexus 1000V Release 4.0(4)SV1(3a) hinzugefügt wurde.

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

Speicher

  • Große Anzahl speicherrelevanter Meldungen in der VMkernel-Protokolldatei *
    Wenn ESXi 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 verlangsamtem Starten von ESXi-Hosts führen*
    Es kann zu bedeutenden 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 ESXi 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 ESXi-Hosts finden Sie im KB-Artikel 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.
  • ESXi-Installationen auf HP-Systemen benötigen den HP-NMI-Treiber *
    ESXi 4.1-Instanzen auf HP-Systemen benötigen den HP-NMI-Treiber, um die ordnungsgemäße Verarbeitung von Non-maskable Interrupts (NMIs) sicherzustellen. Der NMI-Treiber stellt sicher, dass NMIs korrekt erkannt und protokolliert werden. Ohne diesen Treiber werden NMIs, die Hardware-Fehler signalisieren, auf HP-Systemen mit ESXi 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".
  • 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.
  • ESXi 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.

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 ESXi 4.0.x auf ESXi 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-ESXi4.0-to-4.1.0-0.0.260247-release.zip und upgrade-from-esxi4.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 ESXi 4.0.x-Hosts, bei dem dieser Fehler aufgetreten ist, das Upgrade-Paket manuell, indem Sie das Befehlszeilenprogramm "esxupdate" ausführen.

  • Der gleichzeitige Zugriff auf zwei ESXi-Installationen auf USB-Flash-Laufwerken führt zu Panikmeldungen
    Wenn Sie ein System starten, das Zugriff auf mehrere Installationen von ESXi mit der gleichen Build-Nummer auf zwei unterschiedlichen USB-Flash-Laufwerken hat, werden Panikmeldungen angezeigt.

    Umgehung: Trennen Sie eines der USB-Flash-Laufwerke und starten Sie das System neu.

vMotion und Storage vMotion

  • vMotion ist nach einem Neustart des ESXi 4.1-Hosts deaktiviert
    Wenn Sie vMotion auf einem ESXi-Host aktivieren und den ESXi-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 ESXi-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