Versionshinweise zu VMware ESXi 4.1 Update 3

Kontakt zum Vertrieb
 

ESXi 4.1 Update 3 Installable | 30. August 2012 | Build 800380
ESXi 4.1 Update 3 Embedded | 30. August 2012 | Build 800380
VMware Tools | 30. August 2012 | Build 784891

Letzte Dokumentaktualisierung: 13. September 2012

Diese Versionshinweise decken die folgenden Themen ab:

Neuigkeiten

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

  •   Unterstützung für zusätzliche Gastbetriebssysteme – In dieser Version wird die Unterstützung für viele Gastbetriebssysteme aktualisiert. 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 zahlreiche Fehlerkorrekturen, die im Abschnitt Behobene Probleme dokumentiert sind.

Seitenanfang

Vorherige Versionen von ESXi 4.1

Die Funktionen und bekannten Probleme der vorherigen Versionen von ESXi 4.1 werden in den Versionshinweisen für die jeweilige Version beschrieben. Wenn Sie Versionshinweise vorheriger Versionen von ESXi 4.1 anzeigen möchten, klicken Sie auf einen der folgenden Links:

Seitenanfang

Bevor Sie beginnen

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

Die VMware-Produkt-Interoperabilitätmatrix liefert Details zur Kompatibilität aktueller und vorheriger Versionen von VMware vSphere-Komponenten, einschließlich ESXi, VMware vCenter Server, vSphere-Client und wahlweise anderer VMware-Produkte.

ESXi, vCenter Server und VDDK-Kompatibilität

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

Hardwarekompatibilität

  • Erfahren Sie mehr über Hardwarekompatibilität

    Sie finden die Hardwarekompatibilitätslisten im webbasierten Kompatibilitätshandbuch. 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 dieses 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:

    VMware-Produkt-Interoperabilitätmatrix

Installation und Upgrade

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 Schritte zur Lizenzierungs-, Netzwerk- und Sicherheitskonfiguration erforderlich. In den folgenden Handbüchern der vSphere-Dokumentation erhalten Sie weitere Informationen zu diesen Konfigurationsaufgaben.

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://downloads.vmware.com/de/d/ heruntergeladen werden.

Durchführen eines Upgrades der VMware Tools

VMware ESXi 4.1 Update 3 enthält die neueste Version von VMware Tools. 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 3

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

  • VMware vCenter Update Manager. Ein vSphere-Modul, das direkte Upgrades von ESXi 3.5 Update 5, ESXi 4.0.x, ESXi 4.1, ESXi 4.1 Update 1 und ESXi 4.1 Update 2 auf ESXi 4.1 Update 3 unterstützt.
  • vihostupdate. Befehlszeilenprogramm, das direkte Upgrades von ESXi 4.0, ESXi 4.1 Update 1 und ESXi 4.1 Update 2 auf ESXi 4.1 Update 3 unterstützt. Dieses Dienstprogramm benötigt die vSphere-CLI. Weitere Informationen hierzu 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 3 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 3:

Upgrade-Lieferumfang
Unterstützte Upgrade-Tools
Unterstützte Upgrade-Pfade auf ESXi 4.1 Update 3

ESXi 3.5 Update 5

ESXi 4.0:
Umfasst
ESXi 4.0 Update 1
ESXi 4.0 Update 2
ESXi 4.0 Update 3
ESXi 4.0 Update 4

ESXi 4.1 :
Umfasst
ESXi 4.1 Update 1
ESXi 4.1 Update 2

upgrade-from-ESXi3.5-to-4.1_update03.800380.zip

 
VMware vCenter Update Manager mit Host-Upgrade-Baseline

Ja

Nein

Nein
upgrade-from-esxi4.0-to-4.1-update03-800380.zip
  • VMware vCenter Update Manager mit Host-Upgrade-Baseline
  • vihostupdate

Nein

Ja

Nein
update-from-esxi4.1-4.1_update03.zip
  • VMware vCenter Update Managermit Patch-Baseline
  • vihostupdate

Nein

Nein

Ja
ESXi 4.1 auf 4.1.x unter Verwendung der vom VMware-Portal (online) heruntergeladenen Patchdefinitionen VMware vCenter Update Manager mit Patch-Baseline

Nein

Nein

Ja

Anmerkungen:

Aktualisieren vom vSphere-Client

Nach dem Upgrade von vCenter Server oder dem ESX/ESXi-Host auf vSphere 4.1 Update 3 müssen Sie ein Upgrade des vSphere-Clients auf vSphere Client 4.1 Update 3 durchführen. Verwenden Sie den aktualisierten vSphere-Client zum Zugriff auf vSphere 4.1 Update 3.

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 3 (Embedded und Installable) als Patch verteilt, der auf vorhandene Installationen der ESXi 4.1-Software angewendet werden kann.

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

ESXi410-201208201-UG: Aktualisiert die ESXi 4.1 Firmware
ESXi410-201208202-UG: Aktualisiert ESXi 4.1 Tools

Patch-Version ESXi410-Update03 Security-only enthält die folgenden einzelnen Bulletins:

ESXi410-201208101-SG: Aktualisiert die ESXi 4.1 Security-only Firmware
ESXi410-201208102-SG: Aktualisiert ESXi 4.1 Tools

Behobene Probleme

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

CIM und API

  • Der gegenwärtige obere Grenzwert von 256 Dateideskriptoren für den Emulex-CIM-Anbieter reicht nicht aus
    Der Emulex-CIM-Anbieter überschreitet die SFCB-Zuteilung von 256 Dateideskriptoren, was zu einer Knappheit von Socket-Ressourcen auf ESXi-Hosts führt.

    Dieses Problem kann behoben werden, indem Sie den Socket-Grenzwert erhöhen und die vorab zugeteilten Socket-Paare optimieren.
  • Das Systemereignisprotokoll (System Event Log, SEL) für ESXi 4.1 Update 2 ist auf bestimmten Servern leer
    Beim Ausführen von ESXi 4.1 Update 2 auf bestimmten physischen Servern ist das Systemereignisprotokoll (SEL) auf dem vSphere-Client möglicherweise leer. Die IPMI-Protokolle des ESX-Hosts ( /var/log/ipmi/0/sel) sind möglicherweise ebenfalls leer.
    Möglicherweise wird eine Fehlermeldung ähnlich der folgenden in /var/log/messagesgeschrieben:
    Dec 8 10:36:09 esx-200 sfcb-vmware_raw[3965]: IpmiIfcSelReadAll: failed call to IpmiIfcSelReadEntry cc = 0xff

    Dieses Problem wurde in der vorliegenden Version behoben.

Gastbetriebssystem

  • Virtuelle SMP-Maschine fällt bei Ausführung von kexec mit "Monitor Panic" aus
    Wenn ein Linux-Kernel "abstürzt", dient die kexec-Funktion von Linux dazu, das Starten in einem speziellen kdump-Kernel zu ermöglichen und die Dump-Dateien zu dem Absturz zu sammeln. Während dieses Neustartvorgangs kann ein mit kexeckonfiguriertes SMP-Linux-Gastbetriebssystem möglicherweise einen Fehlschlag der virtuellen Maschine mit einer "Monitor Panic" verursachen. Fehlermeldungen ähnlich der folgenden werden möglicherweise protokolliert:

    vcpu-0| CPU reset: soft (mode 2)
    vcpu-0| MONITOR PANIC: vcpu-0:VMM fault 14: src=MONITOR rip=0xfffffffffc28c30d regs=0xfffffffffc008b50

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Gastbetriebssystem einer virtuellen Maschine meldet einen Kernel-Panikfehler, wenn Sie bei einigen ESXi-Versionen Solaris 10 mit der Standardarbeitsspeichergröße installieren
    Wenn Sie versuchen, Solaris 10 unter ESXi zu installieren, meldet das Gastbetriebssystem der virtuellen Maschine einen Kernel-Panikfehler. Die folgende Meldung wird angezeigt:
    panic[cpu0]/thread=fffffffffbc28340 ..page_unlock:...

    Dieses Problem wurde in der vorliegenden Version behoben, indem die Standardarbeitsspeichergröße auf 3 GB erhöht wurde.

Sonstige Probleme

  • Auf ESXi reicht der Zeitüberschreitungswert für die iSCSI-Initiator-Anmeldung, der für Software-iSCSI und abhängige iSCSI-Adapter zugeteilt wurde, nicht aus
    Wenn auf einem ESXi-Host mehrere Anmeldungen gleichzeitig versucht werden, schlägt der Anmeldevorgang aufgrund eines unzureichenden Zeitüberschreitungswerts für die Anmeldung fehl.

    Das Problem kann dadurch behoben werden, indem Sie es den Benutzern erlauben, den Zeitüberschreitungswert zu konfigurieren.
  • Auf visorfs-Dateisystemen erfassen ESXi-Hosts die vdf-Ausgabe für das Dienstprogramm "vm-support" nicht
    Die Option zum Erfassen der vdf-Ausgabe ist in ESXi nicht verfügbar. Ohne diese Option erfährt der Benutzer die Ramdisk-Speicherplatznutzung möglicherweise nicht.

    Die Aufnahme des Befehls vdf –hin das Dienstprogramm vm-supportbehebt das Problem.
  • ESXi-Host reagiert aufgrund einer Überflutung des USB-Protokolls für IBM-Geräte nicht mehr
    Ein ESXi-Host reagiert bei IBM-Nicht-Passthrough-Geräten, wie z. B. RSA2 oder RNDIS/CDC Ether, aufgrund einer dauerhaften Überflutung des USB-Protokolls mit Meldungen ähnlich der folgenden nicht mehr. Dieses Problem tritt auch dann auf, wenn keine virtuelle Maschine zur Verwendung der USB-Passthrough-Option konfiguriert ist.

    USB messages: usb X-Y: usbdev_release : USB passthrough device opened for write but not in use: 0, 1

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Entfernen der SCSI-Festplatte im laufenden Betrieb schlägt mit Fehler fehl
    Nach dem Hinzufügen einer SCSI-Festplatte im laufenden Betrieb schlägt das Entfernen dieser Festplatte im laufenden Betrieb möglicherweise mit dem Fehler Festplatte nicht vorhandenfehl. Fehlermeldungen ähnlich der folgenden werden in die vmx-Protokolldatei geschrieben:

    2010-06-22T19:40:26.214Z| vmx| scsi2:11: Cannot retrieve shares: A one-of constraint has been violated (-19)
    2010-06-22T19:40:26.214Z| vmx| scsi2:11: Cannot retrieve sched/limit/: A one-of constraint has been violated (-19)
    2010-06-22T19:40:26.214Z| vmx| scsi2:11: Cannot retrieve sched/bandwidthCap/: A one-of constraint has been violated (-19)
    2010-06-22T19:40:33.285Z| vmx| [msg.disk.hotremove.doesntexist] scsi2:11 is not present.
    2010-06-22T19:40:33.285Z| vmx| [msg.disk.hotremove.Failed] Failed to remove scsi2:11.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • ESXi-Host kann Active Directory nicht beitreten, wenn sich das Suffix der DNS-Domäne vom Active Directory-Domänennamen unterscheidet

    Dieses Problem wurde in der vorliegenden Version behoben.

Netzwerk

  • Die Netzwerkgrenzwerte für eine virtuelle Maschine funktionieren nicht ordnungsgemäß, wenn der Grenzwert größer als 2048 MBit/s ist
    Wenn Sie Network I/O Control (NetIOC) auf dem ESXi-Host konfigurieren und das Hostlimit für den Datenverkehr der virtuellen Maschine auf einen Wert über 2048 MBit/s setzen, wird die Bandbreitenbegrenzung nicht erzwungen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • ESXi-Host fällt nach einem fehlgeschlagenen vMotion-Vorgang mit einem violetten Bildschirm aus
    Ein ESXi-Host fällt möglicherweise nach einem fehlgeschlagenen vMotion-Vorgang mit einem violetten Bildschirm aus, der einen Ausnahme 14-Fehler anzeigt.

    @BlueScreen: #PF Exception 14 in world 4362:vemdpa IP 0x418006cf1edc addr 0x588
    3:06:49:28.968 cpu8:4362)Code start: 0x418006c00000 VMK uptime: 3:06:49:28.968
    3:06:49:28.969 cpu8:4362)0x417f80857ac8:[0x418006cf1edc]Port_BlockNotify@vmkernel:nover+0xf stack: 0x4100afa10000
    3:06:49:28.969 cpu8:4362)0x417f80857af8:[0x418006d5c81d]vmk_PortLinkStatusSet@vmkernel:nover+0x58 stack: 0x417fc88e3ad8
    3:06:49:28.970 cpu8:4362)0x417f80857b18:[0x41800723a310]svs_set_vnic_link_state@esx:nover+0x27 stack: 0x4100afb3f530
    3:06:49:28.971 cpu8:4362)0x417f80857b48:[0x418007306a9f]sf_platform_set_link_state@esx:nover+0x96 stack: 0x417f80857b88
    3:06:49:28.971 cpu8:4362)0x417f80857b88:[0x41800725a31e]sf_set_port_admin_state@esx:nover+0x149 stack: 0x41800000002c
    3:06:49:28.972 cpu8:4362)0x417f80857cb8:[0x4180072bb5f0]sf_handle_dpa_call@esx:nover+0x657 stack: 0x417f80857cf8

    Dieses Problem wurde in Umgebungen beobachtet, in denen der Cisco Nexus 1000v-Switch verwendet wird.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • IP-Adressbereich wird für VLANs nicht angezeigt
    Bei Ausführung des Befehls esxcfg-infozeigen die Netzwerkhinweise für eine physische Netzwerkkarte einige VLAN IP-Adressbereiche nicht an. Der IP-Adressbereich wird auch in der Benutzeroberfläche von vCenter Server nicht angezeigt. Eine Fehlermeldung ähnlich der folgenden wird in die Datei vmkernel.loggeschrieben:
    Dec 17 03:38:31 vmmon2 vmkernel: 8:19:26:44.179 cpu6:4102)NetDiscover: 732: Too many vlans for srcPort 0x2000002; won't track vlan 273

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Der PCI-Gerätetreiber e1000e unterstützt die Funktion für alternative MAC-Adressen auf Intel 82571EB Serializer-Deserializer nicht
    Das PCI-Gerät Intel 82571EB Serializer-Deserializer mit der Geräte-ID 1060 unterstützt die Funktion für alternative MAC-Adressen, aber der Gerätetreiber e1000e des gleichen Geräts unterstützt die Funktion nicht.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • IBM-Server schlägt beim Versuch, Slow-Path-Pakete zu injizieren, mit einem violetten Bildschirm fehl
    Wenn die in Zusammenhang mit Slow-Path-Paketen stehenden Metadaten kopiert werden, ohne dass überprüft wurde, ob genügend Daten zugeordnet wurden, werden die Metadaten aus dem zugeordneten Bereich des Frames verschoben und eine Seitenfehler tritt auf. Das Problem wird behoben, indem die erforderlichen Daten für die Aufnahme der Metadaten zugeordnet werden, bevor sie kopiert werden.
  • Wenn Sie die Vereinigungsfunktion (Coalescing) auf ESXi deaktivieren, fällt der Host mit einem violetten Bildschirm aus
    Wenn bei ESXi vmxnet3als vNIC in einigen virtuellen Maschinen verwendet wird und Sie die Paketvereinigung deaktivieren, schlägt der ESXi-Host mit einem violetten Bildschirm fehl, wenn die virtuelle Maschine gestartet wird.

    Das Problem kann behoben werden, indem Sie das Überprüfen der Vereinigung und die Assertion-Logik korrigieren.
  • Wenn sich die auslastungsbasierte Gruppierung ändert, sendet der vNIC-Portzuordnungs-VMkernel keine RARP-Pakete (Reverse Address Resolution Protocol)
    Wenn "Routing anhand der pNIC-Auslastung" die Gruppierungsrichtlinie der dvs-Portgruppe ist und die vNIC-zu-pNIC-Zuordnung geändert wird, wenn einige pNICs voll ausgelastet sind, sendet der VMkernel keine RARP-Pakete, um den physischen Switch über diese Änderung zu informieren. Dies hat zur Folge, dass bei virtuellen Maschinen die Netzwerkkonnektivität unterbrochen wird.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • vSwitch-Konfiguration wird auf ESXi-Host leer dargestellt
    Die Netzwerkkonfiguration eines ESXi-Hosts wird möglicherweise im vSphere-Client leer angezeigt. Das Ausführen des Befehls esxcfg-vswitch -lin der Konsole für den lokalen Support-Modus schlägt mit folgendem Fehler fehl:

    Failed to read advanced option subtree UserVars: Error interacting with configuration file
    /etc/vmware/esx.conf: Unlock of ConfigFileLocker failed : Error interacting with configuration file /etc/vmware/esx.conf: I am being asked to delete a .LOCK file that I'm not sure is mine. This is a bad thing and I am going to fail. Lock should be released by (0)

    Fehlermeldungen ähnlich der folgenden werden in die Datei hostd.loggeschrieben:

    [2011-04-28 14:22:09.519 49B40B90 verbose 'App'] Looking up object with name = "firewallSystem" failed.
    [2011-04-28 14:22:09.610 49B40B90 verbose 'NetConfigProvider'] FetchFn: List of pnics opted out
    [2011-04-28 14:22:09.618 49B40B90 info 'HostsvcPlugin'] Failed to read advanced option subtree UserVars: Error interacting with configuration file /etc/vmware/esx.conf: Unlock of ConfigFileLocker failed : Error interacting with configuration file /etc/vmware/esx.conf: I am being asked to delete a .LOCK file that I'm not sure is mine. This is a bad thing and I am going to fail. Lock should be released by (0)

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Netzwerkkonnektivität zu einer für IPv6 konfigurierten virtuellen Maschine schlägt möglicherweise nach dem Installieren von VMware Tools fehl
    Die Netzwerkkonnektivität zu Gastbetriebssystemen mit den Kernel-Versionen 2.6.34 und höher, die für die Verwendung mit IPv6 konfiguriert sind, funktioniert möglicherweise nicht, nachdem Sie VMware Tools installiert haben.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der vSphere-Client zeigt möglicherweise auf einigen Gastbetriebssystemen keine IPv6-Adressen an
    Auf einigen Gastbetriebssystemen werden IPv6-Adressen möglicherweise im vSphere-Client und mit dem Befehl vmware-vim-cmdnicht angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Beim Ausführen des Befehls "esxcli network connection list" auf einem ESXi-Host wird eine Fehlermeldung generiert
    Das Ausführen des Befehls esxcli network connection listführt möglicherweise zu einer Fehlermeldung ähnlich der folgenden, wenn der ESXi-Host IP-Rohverbindungen ausführt, z. B. den vSphere HA (FDM)-Agenten und ICMP-Ping:

    terminate called after throwing an instance of 'VmkCtl::Lib::SysinfoException' what(): Sysinfo error on operation returned status : Ungültiger Parameter. Please see the VMkernel log for detailed error information Aborted

    Dieses Problem wurde in der vorliegenden Version behoben.

Sicherheit

  • Beim Update auf den ThinPrint-Agenten wird ein DLL-Aufruf entfernt
    Dieses Update entfernt als Maßnahme zur Verbesserung der Sicherheit das Aufrufen einer nicht vorhandenen ThinPrint DLL.
    VMware möchte Moshe Zioni von Comsec Consulting für die Meldung dieses Problems danken.

Serverkonfiguration

  • Wenn auf dem ESXi-Host die gemeinsame Nutzung von Seiten deaktiviert ist, schlägt der Host mit einem violetten Bildschirm fehl
    Wenn Sie einen vMotion-Vorgang für einen ESXi-Host ausführen, auf dem die Startoption für die gemeinsame Nutzung von Seiten deaktiviert ist, schlägt der ESXi-Host möglicherweise mit einem violetten Bildschirm fehl.
    Das Deaktivieren der gemeinsamen Nutzung von Seiten beeinträchtigt die Leistung des ESXi-Hosts stark. Da die gemeinsame Nutzung von Seiten nie deaktiviert werden sollte, wurde in dieser Version die Option zum Konfigurieren der gemeinsamen Nutzung von Seiten entfernt.
  • Der ESXi-Host protokolliert einen falschen C1E-Zustand
    In vmkernel.logund in der Ausgabe des Befehls "dmesg" wird möglicherweise die Meldung C1E vom BIOS aktiviertangezeigt. Die Meldung wird möglicherweise auch dann angezeigt, wenn C1E vom BIOS deaktiviert wurde, und wird möglicherweise dann nicht angezeigt, wenn C1E vom BIOS aktiviert wurde.

Speicher

  • Speicherprotokollmeldungen für PSA-Komponenten müssen erweitert werden
    Der Mechanismus des ESXi-Hosts zum Protokollieren von Fehlern protokolliert nicht alle Speicherfehlermeldungen, was die Fehlerbehebung von Speicherproblemen erschwert.

    Das Erweitern der Protokollmeldungen für die PSA-Komponenten behebt dieses Problem.
  • Wiederherstellen eines Snapshots schlägt fehl, wenn virtuelle Maschinen eine gemeinsam genutzte VMDK-Datei referenzieren
    Wenn in einer Umgebung mit zwei eingeschalteten virtuellen Maschinen auf demselben ESXi-Host diese Maschinen eine gemeinsam genutzte VMDK-Datei referenzieren, schlägt das Wiederherstellen eines Snapshots auf jeder der beiden virtuellen Maschinen fehl und der vSphere-Client zeigt möglicherweise einen Dateisperre-Fehler an. Dieses Problem tritt bei den beiden Datenspeichertypen VMFS und NFS auf.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Beschädigtes VMFS-Volume führt zu aufgebrauchtem VMFS-Heap-Arbeitsspeicher
    Wenn der ESXi-Host feststellt, dass ein VMFS-Volume beschädigt ist, kann dies beim VMFS-Treiber zu Speicherverlusten und somit zum Aufbrauchen des VMFS-Heap-Speichers führen. Alle VMFS-Vorgänge werden gestoppt, was zu verwaisten virtuellen Maschinen und fehlenden Datenspeichern führen kann. vMotion-Vorgänge funktionieren möglicherweise nicht und wenn Sie neue virtuelle Maschinen starten, werden Fehlermeldungen bezüglich fehlender Dateien und nicht ausreichenden Speichers ausgegeben. Dieses Problem betrifft alle ESXi-Hosts, die die beschädigte LUN verwenden und virtuelle Maschinen auf dieser LUN ausführen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • VirtualCenter-Agentendienst schlägt bei einer Cold-Migration fehl
    Der VirtualCenter-Agentendienst ( vpxa) schlägt möglicherweise während einer Cold-Migration einer virtuellen Maschine fehl. Fehlermeldungen ähnlich der folgenden werden in die Protokolldatei vpxd.loggeschrieben:

    [2011-11-02 12:06:34.557 03296 info 'App' opID=CFA0C344-00000198] [VpxLRO] -- BEGIN task-342826 -- vm-2851 -- vim.VirtualMachine.relocate -- 8D19CD22-FD15-44B9-9384-1DB4C1A7F7A2(ED8C34F5-CE61-4260-A8C1-D9CA5C2A1C4B)
    [2011-11-02 12:20:05.509 03296 error 'App' opID=CFA0C344-00000198] [VpxdVmprovUtil] Unexpected exception received during NfcCopy
    [2011-11-02 12:20:05.535 03296 error 'App' opID=CFA0C344-00000198] [migrate] (SINITAM02) Unexpected exception (vmodl.fault.HostCommunication) while relocating VM. Aborting.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Zeitüberschreitungsproblem bei VMW_SATP_LSI-Plug-In führt zu Pfad-Thrashing
    Unter bestimmten Umständen reagieren Logical Units (LU) auf Speicher-Controllern, die vom VMW_SATP_LSI-Plug-In beansprucht werden, möglicherweise nicht innerhalb des für das Plug-In festgelegten Zeitüberschreitungswerts von 5 Sekunden auf vom Plug-In ausgegebene Befehle zur Pfadauswertung. Wenn zwei oder mehr vSphere-Hosts gemeinsam auf diese betroffenen LUs zugreifen, kann dies zu Pfad-Thrashing führen (Weitere Informationen hierzu finden Sie unter Grundlegendes zu Pfad-Thrashing).

    In der vorliegenden Version wurde der Zeitüberschreitungswert des VMW_SATP_LSI-Plug-Ins auf 10 Sekunden erhöht. Bevor Sie dieses Update installieren, wenden Sie sich an Ihren Speicheranbieter, um den entsprechenden E/A-Zeitüberschreitungswert für das Gastbetriebssystem festzulegen.
  • Ein Datenspeicher größer als 2 TB - 512 Byte kann nicht auf ESXi 4.x mit dem vSphere-Client erstellt werden
    In vorherigen Versionen war es möglich, unter Verwendung der vSphere-Befehlszeilenschnittstelle einen Datenspeicher größer als 2 TB - 512 Byte zu erstellen. Diese Konfiguration wird jedoch nicht unterstützt.

    Der Versuch, unter Verwendung der vSphere-Befehlszeilenschnittstelle einen Datenspeicher größer als 2 TB - 512 Byte zu erstellen, schlägt jetzt kontrolliert fehl.
  • Während des Taktsignal-Zurückgewinnungsvorgangs werden Warnmeldungen protokolliert
    VMFS veranlasst möglicherweise E/A-Vorgänge auf ein Volume, wenn ein VMFS-Taktsignal-Zurückgewinnungsvorgang ausgeführt oder eine virtuelle Zurücksetzung auf einem zugrunde liegenden Gerät durchgeführt wird. Als Folge davon werden Warnmeldungen ähnlich der folgenden protokolliert:

    WARNING: ScsiDeviceIO: 2360: Failing WRITE command (requiredDataLen=512 bytes) to write-quiesced partition naa.9999999999

    Zudem wird eine Warnmeldung an der ESX-Konsole ausgegeben.

    Diese Warnungen und Alarme sind harmlos und können ignoriert werden.

    In dieser Version wurden Warnmeldungen entfernt und Warnungen wurden in Protokollmeldungen geändert.
  • Das Installieren bestimmter Versionen von VMware Tools führt zu einer Protokollüberflutung
    Wenn Sie bestimmte Versionen von VMware Tools installieren, z. B. Version 8.3.7, wird die Protokolldatei vmkernel.logmöglicherweise mit Meldungen ähnlich der folgenden überflutet:

    Nov 22 11:55:06 vm_name-c vmkernel: 107:01:39:59.667 cpu12:21263)VSCSIFs: 329: handle 9267(vscsi0:0):Invalid Opcode (0xd1)
    Nov 22 11:55:06 vm_name-c vmkernel: 107:01:39:59.687 cpu5:9487)VSCSIFs: 329: handle 9261(vscsi0:0):Invalid Opcode (0xd1)

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Standard-SATP-Plug-In für LSI-Arrays wurde geändert und bietet jetzt ALUA-Unterstützung
    Auf ESXi 4.1 Update2-Hosts war VMW_SATP_LSI das Standard-Speicher-Array-Typ-Plug-In (SATP) für LSI-Arrays. Asymmetric Logical Unit Access (ALUA) wurde von diesem Plug-In nicht unterstützt. In dieser Version wurde das SATP-Plug-In für LSI-Arrays mit ALUA-Unterstützung in VMW_SATP_ALUA geändert. TPGS/ALUA-Arrays werden jetzt automatisch vom Standard-SATP-Plug-In VMW_SATP_ALUA beansprucht. Die folgenden Speicher-Arrays werden von VMW_SATP_ALUA beansprucht:
    Beschreibung des Anbietermodells
    • LSI INF-01-00
    • IBM ^1814* DS4000
    • IBM ^1818* DS5100/DS5300
    • IBM ^1746* IBM DS3512/DS3524
    • DELL MD32xx Dell MD3200
    • DELL MD32xxi Dell MD3200i
    • DELL MD36xxi Dell MD3600i
    • DELL MD36xxf Dell MD3600f
    • SUN LCSM100_F
    • SUN LCSM100_I
    • SUN LCSM100_S
    • SUN STK6580_6780 Sun StorageTek 6580/6780
    • SUN SUN_6180 Sun Storage 6180
    • SGI IS500 SGI InfiniteStorage 4000/4100
    • SGI IS600 SGI InfiniteStorage 4600
  • Der ESXi-Host meldet möglicherweise ein beschädigtes VMFS-Volume, wenn Sie auf einem ESXi-Host Dateien aus Verzeichnissen löschen, die über mehr als 468 Dateien verfügen
    Der Versuch, eine Datei aus einem Verzeichnis, das mehr als 468 Dateien enthält, bzw. das Verzeichnis selbst zu löschen, schlägt möglicherweise fehl und der ESXi-Host meldet evtl. fälschlicherweise, dass das VMFS beschädigt ist. Der ESXi-Host protokolliert Fehlermeldungen ähnlich der folgenden in /var/log/ messages:

    cpu10:18599)WARNING: Fil3: 10970: newLength 155260 but zla 2
    cpu10:18599)Fil3: 7054: Corrupt file length 155260, on FD <70, 93>, not truncating

    Dieses Problem wurde in der vorliegenden Version behoben.
  • ESXi-Host reagiert nicht mehr, wenn das VMW_SATP_LSI-Modul über keinen Heap-Arbeitsspeicher mehr verfügt
    Dieses Problem tritt auf Servern auf, die Zugriff auf vom VMW_SATP_LSI-Modul beanspruchte LUNs haben. Ein im VMW_SATP_LSI-Modul auftretender Arbeitsspeicherverlust führt dazu, dass das Modul über keinen Arbeitsspeicher mehr verfügt. Fehlermeldungen ähnlich der folgenden werden in die Datei vmkernel.loggeschrieben:

    Feb 22 14:18:22 [host name] vmkernel: 2:03:59:01.391 cpu5:4192)WARNING: Heap: 2218: Heap VMW_SATP_LSI already at its maximumSize. Cannot expand.
    Feb 22 14:18:22 [host name] vmkernel: 2:03:59:01.391 cpu5:4192)WARNING: Heap: 2481: Heap_Align(VMW_SATP_LSI, 316/316 bytes, 8 align) failed. caller: 0x41800a9e91e5
    Feb 22 14:18:22 [host name] vmkernel: 2:03:59:01.391 cpu5:4192)WARNING: VMW_SATP_LSI: satp_lsi_IsInDualActiveMode: Out of memory.

    Der Arbeitsspeicherverlust im VMW_SATP_LSI-Modul wurde in dieser Version behoben.
  • ESXi-Host fällt möglicherweise beim Neusignieren eines VMFS-Volumes mit einem violetten Bildschirm aus
    Ein ESXi-Host fällt möglicherweise beim Neusignieren eines VMFS-Volumes mit einem violetten Bildschirm aus, der Fehlermeldungen ähnlich der folgenden anzeigt.

    #DE Exception 0 in world 20519269:helper22-6 @ 0x418024b26a33
    117:05:20:07.444 cpu11:20519269)Code start: 0x418024400000 VMK uptime: 117:05:20:07.444
    117:05:20:07.444 cpu11:20519269)0x417f84b2f290:[0x418024b26a33]Res3_ExtendResources@esx:nover+0x56 stack: 0x4100ab400040
    117:05:20:07.445 cpu11:20519269)0x417f84b2f2e0:[0x418024af9a58]Vol3_Extend@esx:nover+0x9f stack: 0x0
    117:05:20:07.445 cpu11:20519269)0x417f84b2f4f0:[0x418024afd3f6]Vol3_Open@esx:nover+0xdc9 stack: 0x417f84b2f668
    117:05:20:07.446 cpu11:20519269)0x417f84b2f6a0:[0x4180246225d1]FSS_Probe@vmkernel:nover+0x3ec stack: 0x417f84b2f6f0
    117:05:20:07.446 cpu11:20519269)0x417f84b2f6f0:[0x41802463d0e6]FDS_AnnounceDevice@vmkernel:nover+0x1dd stack: 0x3133306161336634

    Dieses Problem wurde in der vorliegenden Version behoben.
  • ESXi-Host fällt bei einem Recompose-Vorgang auf VMware View mit einem violetten Bildschirm und der Fehlermeldung "Out of memory for timers" aus
    Ein ESXi-Host fällt möglicherweise mit einem violetten Bildschirm aus, auf dem Fehlermeldungen ähnlich der folgenden und ein Stack-Trace angezeigt werden, wenn Sie auf VMware View einen Recompose-Vorgang durchführen:

    @BlueScreen: Out of memory for timers
    0:20:06:44.618 cpu38:4134)Code start: 0x418033600000 VMK uptime: 0:20:06:44.618
    0:20:06:44.619 cpu38:4134)0x417f80136cf8:[0x418033658726]Panic@vmkernel:nover+0xa9 stack: 0x417f80136d78
    0:20:06:44.619 cpu38:4134)0x417f80136d28:[0x41803367958e]TimerAlloc@vmkernel:nover+0x10d stack: 0x9522bf175903
    0:20:06:44.619 cpu38:4134)0x417f80136d78:[0x418033679fbb]Timer_AddTC@vmkernel:nover+0x8a stack: 0x4100b8317660
    0:20:06:44.620 cpu38:4134)0x417f80136e08:[0x41803384d964]SCSIAsyncDeviceCommandCommon@vmkernel:nover+0x2f7 stack: 0x41037db8c
    0:20:06:44.620 cpu38:4134)0x417f80136e58:[0x41803383fbed]FDS_CommonAsyncIO@vmkernel:nover+0x48 stack: 0x410092dea0e8

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Ein ESXi-Host fällt möglicherweise aufgrund eines Problems im VMFS-Modul mit einem violetten Diagnosebildschirm aus.
    Ein ESXi-Host fällt möglicherweise aufgrund eines Problems im VMFS-Modul mit einem violetten Diagnosebildschirm aus, auf dem Fehlermeldungen ähnlich der folgenden angezeigt werden.

    @BlueScreen: #PF Exception 14 in world 8008405:vmm0:v013313 IP 0x418001562b6d addr 0x28
    34:15:27:55.853 cpu9:8008405)Code start: 0x418000e00000 VMK uptime: 34:15:27:55.853
    34:15:27:55.853 cpu9:8008405)0x417f816af398:[0x418001562b6d]PB3_Read@esx:nover+0xf0 stack: 0x41000e1c9b60
    34:15:27:55.854 cpu9:8008405)0x417f816af468:[0x4180015485df]Fil3ExtendHelper@esx:nover+0x172 stack: 0x0
    34:15:27:55.854 cpu9:8008405)0x417f816af538:[0x41800154ded4]Fil3_SetFileLength@esx:nover+0x383 stack: 0xa00000001
    34:15:27:55.854 cpu9:8008405)0x417f816af5a8:[0x41800154e0ea]Fil3_SetFileLengthWithRetry@esx:nover+0x6d stack: 0x417f816af5e8
    34:15:27:55.854 cpu9:8008405)0x417f816af638:[0x41800154e38b]Fil3_SetAttributes@esx:nover+0x246 stack: 0x41027fabeac0
    34:15:27:55.854 cpu9:8008405)0x417f816af678:[0x41800101de7e]FSS_SetFileAttributes@vmkernel:nover+0x3d stack: 0x1000b000
    34:15:27:55.855 cpu9:8008405)0x417f816af6f8:[0x418001434418]COWUnsafePreallocateDisk@esx:nover+0x4f stack: 0x4100a81b4668
    34:15:27:55.855 cpu9:8008405)0x417f816af728:[0x418001434829]COWIncrementFreeSector@esx:nover+0x68 stack: 0x3
    34:15:27:55.855 cpu9:8008405)0x417f816af7b8:[0x418001436b1a]COWWriteGetLBNAndMDB@esx:nover+0x471 stack: 0xab5db53a0
    34:15:27:55.855 cpu9:8008405)0x417f816af908:[0x41800143761f]COWAsyncFileIO@esx:nover+0x8aa stack: 0x41027ff88180
    34:15:27:55.855 cpu9:8008405)0x417f816af9a8:[0x41800103d875]FDS_AsyncIO@vmkernel:nover+0x154 stack: 0x41027fb585c0
    34:15:27:55.856 cpu9:8008405)0x417f816afa08:[0x4180010376cc]DevFSFileIO@vmkernel:nover+0x13f stack: 0x4100077c3fc8

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Beim Handhaben einer 4G DMA-Grenzadresse werden beim Emulex LPe12000-Treiber Daten beschädigt
    Wenn beim ESXi-Host der Emulex LPe12000-Treiber den dma_boundary-Wert in der Hostvorlage nicht festlegen kann, wird der dma_boundary-Wert auf null (0) festgelegt. Dies hat zur Folge, dass die SG-Listenadressen die für den Treiber definierte Adressgrenze überschreiten, wobei Daten beschädigt werden.

    Dieses Problem wurde in der vorliegenden Version behoben.

Unterstützte Hardware

  • Betriebsrichtlinie eines ESXi-Hosts kann auf einem IBM BladeCenter HX5 UEFI-Server nicht geändert werden
    Wenn Sie versuchen, die Betriebsrichtlinie eines ESXi-Hosts zu ändern, der auf einem IBM BladeCenter HX5 UEFI-Server ausgeführt wird, zeigen die Energieverwaltungseinstellungen auf dem vSphere-Client die folgende Meldung an:

    Technologie: Nicht verfügbar
    Aktive Richtlinie: Nicht unterstützt.

    Dieses Problem wurde in der vorliegenden Version behoben.

vCenter Server, vSphere-Client und vSphere Web Access

  • Die hostd- und vpxa-Dienste schlagen fehl und der ESXi-Host wird von vCenter Server getrennt
    Ein sfcb-vmware_base TIMEOUT-Fehler führt möglicherweise dazu, dass die hostd- und vpxa-Dienste fehlschlagen und der ESXi-Host immer wieder von vCenter Server getrennt wird. Fehlermeldungen ähnlich der folgenden werden in /var/log/messagesgeschrieben:

    Jan 30 12:25:17 sfcb-vmware_base[2840729]: TIMEOUT DOING SHARED SOCKET RECV RESULT (2840729)
    Jan 30 12:25:17 sfcb-vmware_base[2840729]: Timeout (or other socket error) waiting for response from provider
    Jan 30 12:25:17 sfcb-vmware_base[2840729]: Request Header Id (1670) != Response Header reqId (0) in request to provider 685 in process 3. Drop response.
    Jan 30 12:25:17 vmkernel: 7:19:02:45.418 cpu32:2836462)User: 2432: wantCoreDump : hostd-worker -enabled : 1

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der vSphere-Client zeigt falsche Daten für eine virtuelle Maschine an
    In den Überblicksleistungsdiagrammen des vSphere-Clients werden für eine virtuelle Maschine möglicherweise Daten selbst für den Zeitraum angezeigt, in dem die virtuelle Maschine ausgeschaltet war.

    Dieses Problem wurde in der vorliegenden Version behoben.

Verwaltung von virtuellen Maschinen

  • VMX-Datei wird möglicherweise während des Erstellens eines Stilllegungs-Snapshots beschädigt
    Wenn Sie einen Stilllegungs-Snapshot einer virtuellen Maschine mit dem VSS-Dienst, dem SYNC-Treiber von VMware Tools oder einem Sicherungsagenten erstellen, schreibt hostd in die .vmx-Datei. Als Folge davon wird die .vmx-Datei geleert.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Virtuelle Maschine fällt mit "Monitor Panic" aus, wenn das Paging deaktiviert wird
    Fehlermeldungen ähnlich der folgenden werden in vmware.loggeschrieben:

    Aug 16 14:17:39.158: vcpu-0| MONITOR PANIC: vcpu-1:VMM64 fault 14: src=MONITOR rip=0xfffffffffc262277 regs=0xfffffffffc008c50

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Neustart der virtuellen Windows 2003-Maschine auf ESXi-Host mit NetBurst-basierter CPU nimmt viel Zeit in Anspruch
    Der Neustart einer virtuellen Windows 2003 Server-Maschine mit gemeinsam genutzten Arbeitsspeicherseiten dauert etwa 5 bis 10 Minuten, wenn auf dem ESXi-Host eine NetBurst-basierte CPU installiert ist. Allerdings können Sie dieselbe virtuelle Maschine ohne Verzögerung herunterfahren und einschalten.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Manchmal schlägt die Neukonfigurationsaufgabe einer virtuellen Maschine aufgrund eines Deadlocks fehl
    In einigen Szenarien schlägt die Neukonfigurationsaufgabe einer virtuellen Maschine aufgrund eines Deadlocks fehl. Der Deadlock tritt beim Ausführen von Neukonfigurations- und Datenspeicheränderungsvorgängen auf.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Löschen einer virtuellen Maschine führt zum Entfernen nicht verknüpfter virtueller Festplatten
    Wenn Sie einen Snapshot einer virtuellen Maschine erstellen und die virtuelle Maschine später löschen, werden unabhängige bzw. nicht unabhängige virtuelle Festplatten, die zuvor von der virtuellen Maschine getrennt wurden, möglicherweise ebenfalls gelöscht.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • PCI-Konfigurationsspeicherwerte für VMDirectIO zwischen ESXi und der virtuellen Maschine sind inkonsistent
    Wenn Sie den VMDirectIO-Pfad für einen Netzwerkschnittstellenadapter im Passthrough-Modus festlegen und ihn einer virtuellen Maschine zuweisen, wird der Zustand des "Interrupt Disable"-Bits (INTx) des Gerätesteuerungsregisters als für die virtuelle Maschine aktiviert und für ESXi deaktiviert angezeigt. Dies ist nicht richtig, da in beiden Fällen der INTx-Wert aktiviert sein soll.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • BPDU-Frames (Bridge Protocol Data Unit), die von der überbrückten Netzwerkkarte übertragen werden, deaktivieren den physischen Uplink
    Wenn Sie BPDU-Guard auf dem Port des physischen Switches aktivieren, sorgen BPDU-Frames, die von der überbrückten virtuellen Netzwerkkarte übertragen werden, dafür, dass der physische Uplink deaktiviert wird und folglich ausfällt.
    Machen Sie den Host ausfindig, der die BPDU-Pakete überträgt, und legen Sie auf diesem Host esxcfg-advcfg -s 1 /Net/BlockGuestBPDUfest. Dies sorgt dafür, dass BPDU-Pakete für diese virtuelle Netzwerkkarte ausgefiltert und blockiert werden. Schalten Sie die virtuellen Maschinen mit den überbrückten virtuellen Netzwerkkarten erst ein, nachdem dieser Filter eingeschaltet wurde, damit der Filter wirksam wird.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die extraConfig-Einstellungen für eine virtuelle Maschine können über das API nicht entfernt werden
    Dieses Problem wurde in der vorliegenden Version behoben.

VMware HA und Fault Tolerance

  • Sekundäre virtuelle FT-Maschine, die auf einem ESXi-Host ausgeführt wird, schlägt möglicherweise fehl
    Auf einem ESXi-Host schlägt eine mit einem VMXNET 3-Adapter installierte sekundäre virtuelle Fault Tolerance-Maschine möglicherweise fehl. Fehlermeldungen ähnlich den folgenden werden in die Protokolldatei vmware.loggeschrieben:

    Dec 15 16:11:25.691: vmx| GuestRpcSendTimedOut: message to toolbox timed out.
    Dec 15 16:11:25.691: vmx| Vix: [115530 guestCommands.c:2468]: Error VIX_E_TOOLS_NOT_RUNNING in VMAutomationTranslateGuestRpcError(): VMware Tools are not running in the guest
    Dec 15 16:11:30.287: vcpu-0| StateLogger::Commiting suicide: Statelogger divergence
    Dec 15 16:11:31.295: vmx| VTHREAD watched thread 4 "vcpu-0" died

    Dieses Problem tritt nicht auf einer virtuellen Maschine auf, die mit dem E1000-Adapter installiert wurde.

    Dieses Problem wurde in der vorliegenden Version behoben.

vMotion und Storage vMotion

  • Wenn Sie eine Live-Migration von virtuellen Windows 2008-Maschinen von ESX 4.0 auf ESX 4.1 vornehmen und anschließend Storage vMotion durchführen, schlagen Stilllegungs-Snapshots fehl
    Ein Storage vMotion-Vorgang auf ESXi 4.1 legt für eine virtuelle Windows 2008-Maschine standardmäßig disk.enableUUIDauf "true" fest und aktiviert so die Anwendungsstilllegung. Der nachfolgende Stilllegungs-Snapshot-Vorgang schlägt so lange fehl, bis die virtuelle Maschine aus- und wieder eingeschaltet wird.

    Dieses Problem wurde in der vorliegenden Version behoben.

VMware Tools

  • VMware Snapshot Provider Service (vmvss) wird beim Deinstallieren von VMware Tools auf Windows 2008 R2-Gastbetriebssystemen nicht entfernt

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Bestimmte virtuelle SLES-Maschinen werden nach einem Upgrade der VMware Tools nicht neu gestartet
    Nach einem Upgrade der VMware Tools schlagen auf bestimmten virtuellen SLES-Maschinen, wie z. B. SLES 10 SP4 und SLES 11 SP2, Versuche, die virtuelle Maschine neu zu starten, möglicherweise mit der Fehlermeldung Warten auf sda2....... keine Antwortfehl. Dieses Problem tritt auf, weil während des Deinstallationsvorgangs von VMware Tools die INITRD_MODULES-Optionen in /etc/sysconfig/kernelgelöscht werden.

    Dieses Problem wurde in der vorliegenden Version behoben. Das Problem tritt möglicherweise allerdings weiterhin auf, wenn Sie ein Upgrade von einer früheren Version von VMware Tools auf die in dieser Version verfügbare Version von VMware Tools durchführen. Weitere Informationen hierzu finden Sie im Technical Information Document (TID) 7005233 auf der Novell-Website.
  • Zeitüberschreitung beim Upgrade der VMware Tools bei ESXi 4.1 Update 1
    Auf virtuellen Maschinen, die auf ESXi 4.1 Update 1 ausgeführt werden, führen Versuche, ein Upgrade der VMware Tools durchzuführen, möglicherweise zu einer Zeitüberschreitung. Fehlermeldungen ähnlich den folgenden werden in die Protokolldatei vmware.loggeschrieben:

    Nov 30 15:36:34.839: vcpu-0| TOOLS INSTALL finished copying upgrader binary into guest. Starting Upgrader in guest.
    Nov 30 15:36:34.840: vcpu-0| TOOLS INSTALL Sending "upgrader.create 1"
    Nov 30 15:36:34.902: vcpu-0| TOOLS INSTALL Received guest file root from upgrader during unexpected state...ignoring.
    Nov 30 15:36:34.904: vcpu-0| GuestRpc: Channel 6, unable to send the reset rpc.
    Nov 30 15:36:34.905: vcpu-0| GuestRpc: Channel 6 reinitialized.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • VMware Tools-Dienst schlägt während des Startens der virtuellen Windows 2008 R2-Maschine fehl
    Der VMware Tools-Dienst ( vmtoolsd.exe) schlägt während des Startvorgangs des Windows 2008 R2-Gastbetriebssystems fehl. Allerdings können Sie diesen Dienst nach Abschluss des Betriebssystem-Startvorgangs manuell starten.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Während einer Batch-Erfassung auf einem Server mit 128 CPUs schlägt Esxtop fehl
    Wenn Sie versuchen, auf einem Server mit 128 logischen CPUs eine Batch-Erfassung durchzuführen, schlägt esxtop fehl. Die Ursache hierfür liegt in der eingeschränkten Puffergröße des Headers. Durch das Erhöhen der Puffergröße des Headers wird dieses Problem behoben.
  • Bei der Deinstallation bzw. beim Upgrade von VMware Tools werden benutzerdefinierte Einträge in der Datei "modprobe.conf" entfernt
    Änderungen, die Sie an der Datei /etc/modprobe.confvornehmen, werden möglicherweise überschreiben, wenn Sie VMware Tools deinstallieren oder aktualisieren.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die IP-Virtualisierung von Windows Server 2008 R2 (64-Bit) funktioniert auf ESXi 4.0 Update 1 möglicherweise nicht
    Die IP-Virtualisierung, die es Ihnen ermöglicht, RDP-Sitzungen eindeutige IP-Adressen zuzuteilen, funktioniert möglicherweise nicht auf Windows Server 2008 R2 (64-Bit), der unter ESXi 4.0 Update 1 ausgeführt wird. Dies ist darauf zurückzuführen, dass die vsock-DLLs von separaten 32- und 64-Bit-Programmdateien registriert wurden. Dies führt dazu, dass die Katalog-IDs der 32-Bit- und den 64-Bit-Winsock-Kataloge für vSock LSP nicht synchron sind.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Beim Durchführen eines Upgrades von VMware Tools wird der für die IP-Virtualisierung des Remotedesktops erforderliche VMCI-Treiber nicht ersetzt
    • vsock

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

  • Das Konfigurationselement "/UserVars/CIMoemProviderEnabled" wird bei einem Upgrade auf ESXi 4.1 Update 3 nicht gelöscht
    Umgehung: Löschen Sie /UserVars/CIMoemPrividerEnabledunter Verwendung des folgenden Befehls:

    esxcfg-advcfg-L /UserVars/CIMoemProviderEnabled

  • Konfigurationselemente vom Typ "OEM ProviderEnabled" werden bei einem Upgrade auf ESXi 4.1 Update 3 standardmäßig aktiviert
    Umgehung:
    1. Führen Sie den folgenden Befehl aus, um OEM-Anbieter zu deaktivieren:
      esxcfg-advcfg -s 0 /UserVars/CIMoem-<originalname>ProviderEnabled
    2. Starten Sie den Dienst sfcbdneu, indem Sie den folgenden Befehl ausführen:
        /etc/init.d/sfcbd-watchdog restart
  • 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

  • Bei der Installation des RHEL 6.1-Gastbetriebssystems wird das Installationsfenster nicht ordnungsgemäß angezeigt (KB 2003588).

  • 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 oder 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 dann 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, dass die Pakete nicht unterstützt werden
    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.

  • Keine Netzwerkverbindung nach dem Bereitstellen und Einschalten einer virtuellen Maschine
    Wenn Sie eine virtuelle Maschine bereitstellen, die mithilfe des Anpassungsassistenten auf einem ESXi-Host erstellt wurde, und die virtuelle Maschine einschalten, geht möglicherweise die Netzwerkverbindung der virtuellen Maschine verloren.

    Umgehung:    Wählen Sie nach dem Bereitstellen einer jeden virtuellen Maschine auf dem ESXi-Host im Fenster "Eigenschaften virtueller Maschine" die Option Beim Einschalten verbinden aus, bevor Sie die virtuelle Maschine einschalten.

Sonstige Probleme

  • Ein ESX/ESXi 4.1 U2-Host mit installiertem vShield Endpoint 1.0 fällt mit einem violetten Diagnosebildschirm aus, auf dem VFileFilterReconnectWork angezeigt wird (KB 2009452).

  • Ausführen von "resxtop" oder "esxtop" über einen längeren Zeitraum hat möglicherweise Arbeitsspeicherprobleme zur Folge
    Die Arbeitsspeichernutzung durch     resxtop oder esxtop nimmt möglicherweise mit der Zeit zu, abhängig davon, was auf dem überwachten ESXi-Host geschieht. 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, resxtopnur 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-pciidauszufü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.x 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.x Embedded-Host zu Cisco Nexus 1000V Release 4.0(4)SV1(3a) hinzufügen.

    Umgehung
    Verwenden Sie zum Hinzufügen eines ESXi 4.1.x 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.x 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 ein Datencenter und fügen Sie den ESXi 4.1.x Embedded-Host zu vCenter Server hinzu.
    5. Fügen Sie ESXi 4.1.x-kompatible 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>
      In der Befehlszeile (vCLI) 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 der ESXi 4.1.x-Host zu Cisco Nexus 1000V Release 4.0(4)SV1(3a) hinzugefügt wurde.

Netzwerk

  • Bestimmte Versionen des VMXNET 3-Treibers können das Gerät nicht initialisieren, wenn die Anzahl an vCPUs kein Vielfaches von zwei ist (KB 2003484).
  • 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-Netzwerkkarten 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 sich die Zahl der dvPorts für einen Host 1016 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

  • iSCSI kann nicht über Netzwerkkarte mit langem logischen Gerätenamen konfiguriert werden
    Bei Ausführung des Befehls     esxcli swiscsi nic add -n von einer vSphere-Befehlszeilenschnittstelle (vCLI) aus wird iSCSI über keine 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 vCLI-Schnittstelle 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.

  • Große Anzahl speicherrelevanter Meldungen in der Protokolldatei "/var/log/messages"
    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 den 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 können die Meldungen ignorieren.

    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 ESXi-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: Ändern Sie zum Beheben dieses Problems und zum Beschleunigen des Startvorgangs den Zeitüberschreitungswert für synchrone Befehle während des Startvorgangs auf 10 Sekunden, indem Sie den Parameter Scsi.CRTimeoutDuringBootauf 10000 festlegen.

    So Ändern Sie den Parameter vom vSphere-Client aus:
    1. Wählen Sie im Bestandslistenbereich des vSphere-Client 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 ESXi nicht gestartet werden und zeigt 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 zum Konfigurieren der Startoption für ESXi-Hosts finden Sie unter KB 1021454.
  • PCI-Geräte-Zuordnungsfehler bei HP ProLiant DL370 G6
    Wenn Sie E/A-Vorgänge auf dem HP ProLiant DL370 G6-Server durchführen, wird möglicherweise ein violetter Bildschirm oder es werden Warnungen zu "Lint1 Interrupt" bzw. NMI 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, zu einer NMI-Alarmmeldung 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 (G7 und früher) 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 in IML protokolliert werden. Ohne den Treiber werden NMIs, die Hardwarefehler signalisieren, auf HP-Systemen, die ESXi ausführen, ignoriert.
    Vorsicht: Ein Fehler bei der Installation dieses Treibers führt möglicherweise dazu, dass NMI-Ereignisse vom Betriebssystem ignoriert werden. Das Ignorieren von NMI-Ereignissen kann zu einer Instabilität des Systems führen.

    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 auch KB 1026431.
  • 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 späteren Firmware-Version verwenden. Die Firmware verliert möglicherweise gelegentlich E/A aus der Array-Warteschlange, was die virtuellen Maschinen veranlasst, auf Nur-Lesen 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 Upgrade 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".
  • 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 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 den folgenden in /var/log/messagesprotokolliert 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

    Dieses Problem wird durch das Fehlen eines akkubetriebenen Cache-Moduls im Host verursacht.
    Ohne das akkubetriebene Cache-Modul arbeitet der Controller im Zero-Memory-Raid-Modus, was die Anzahl der gleichzeitig vom Controller verarbeitbaren Befehle stark einschränkt.

    Umgehung: Installieren Sie das 256 MB große Cache Upgrade-Modul der HP P-Serie von der HP-Website.

Upgrade und Installation

  • Mehrfachpfad-Upgrade von ESXi 3.5 über ESXi 4.0.x auf ESXi 4.1 Update 3 mithilfe von VMware vCenter Update Manager schlägt fehl
    Nachdem Sie unter Verwendung von VMware vCenter Update Manager ein Upgrade von ESXi 3.5 auf ESXi 4.0.x durchgeführt haben, schlägt der Versuch, ein Upgrade der ESXi-Installation auf ESXi 4.1 Update 3 durchzuführen, mit einer Fehlermeldung ähnlich der folgenden fehl:

    VMware vCenter Update Manager hat einen unbekannten Fehler. Auf der Registerkarte "Aufgaben und Ereignisse" und in den Protokolldateien finden Sie weitere Details.

    Das Upgrade schlägt für folgende Upgrade-Pfade fehl:

    • ESXi 3.5 über ESXi 4.0 Update 1 auf ESXi 4.1 Update 3
    • ESXi 3.5 über ESXi 4.0 Update 2 auf ESXi 4.1 Update 3
    • ESXi 3.5 über ESXi 4.0 Update 3 auf ESXi 4.1 Update 3
    • ESXi 3.5 über ESXi 4.0 Update 4 auf ESXi 4.1 Update 3
    • ESXi 3.5 über ESXi 4.0 auf ESXi 4.1 Update 3

    Umgehung: Starten Sie den Host nach dem Upgrade auf ESXi 4.0.x neu, und führen Sie anschließend ein Upgrade auf ESXi 4.1 Update 3 durch.

  • Host-Upgrade auf ESX/ESXi 4.1 Update 1 schlägt fehl, wenn Sie das Upgrade mithilfe von Update Manager 4.1 durchführen (KB 1035436)

  • 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 schlägt fehl und auch die Installation des vSphere-Clients schlägt mit folgendem Fehler fehl: Das Installationsprogramm von Microsoft Visual J# 2.0 Second Edition gibt den Fehlercode 4113 zurück.

    Umgehung: Deinstallieren Sie alle früheren Versionen von Microsoft Visual J# und installieren Sie anschließend den vSphere-Client. Das Installationsprogramm enthält ein aktualisiertes Microsoft Visual J#-Paket.
  • 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 demNeustart 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.

VMware Tools

  • Die Verwendung der VMXNET-Netzwerkschnittstellenkarte ist nach der Installation von VMware Tools in RHEL3 mit dem neuesten Errata-Kernel auf ESXi 4.1 U1 nicht möglich
    Einige Treiber in VMware Tools, die mit RHEL 3.9-Modulen vorgefertigt wurden, funktionieren aufgrund einer ABI-Inkompatibilität mit dem 2.4.21-63-Kernel nicht ordnungsgemäß. Dies führt dazu, dass einige Gerätetreiber, wie z. B. vmxnet und vsocket, bei der Installation von VMware Tools auf REHL 3.9 nicht geladen werden.

    Umgehung: Führen Sie den Startvorgang in den 2.4.21-63-Kernel aus. Installieren Sie das Kernel-Quellpaket und das gcc-Paket für den 2.4.21-63-Kernel. Führen Sie den Befehl vmware-config-tools.pl, --compileaus. Dadurch werden die Module für diesen Kernel kompiliert. Die resultierenden Module sollten mit dem laufenden Kernel funktionieren.

  • Windows-Gastbetriebssysteme zeigen nach einem Upgrade der virtuellen Hardware einen falschen Netzwerkkarten-Gerätestatus an
    Wenn Sie auf Windows-Gastbetriebssystemen ein Upgrade des ESXi-Hosts von ESXi 3.5 auf ESXi 4.1 zusammen mit einem Upgrade der ESXi-Hardwareversion von 4 auf 7 durchführen, wird als Gerätestatus der Netzwerkkarte
    Dieses Hardwaregerät ist nicht mit dem Computer verbunden (Code 45)angezeigt.

    Umgehung: Deinstallieren Sie die Netzwerkkarte und installieren Sie sie anschließend erneut. Deinstallieren Sie außerdem die Netzwerkkarten, die im Geräte-Manager als ghostedangezeigt werden, wenn Sie die unter folgender Adresse beschriebenen Schritte ausführen: http://support.microsoft.com/kb/315539.

  • VMware Tools führt kein automatisches Upgrade durch, wenn eine virtuelle Microsoft Windows 2000-Maschine neu gestartet wird
    Wenn Sie VMware Tools zum Durchführen eines automatischen Upgrades beim Aus- und Wiedereinschalten konfigurieren, indem Sie die Option Tools vor jedem Einschaltvorgang prüfen und aktualisieren im Bereich Erweitert des Fensters "Eigenschaften virtueller Maschine" auswählen, wird auf Microsoft Windows 2000-Gastbetriebssystemen kein automatisches Upgrade durchgeführt.

    Umgehung:         Führen Sie im Microsoft Windows 2000-Gastbetriebssystem ein manuelles Upgrade der VMware Tools durch.

 

 

Seitenanfang