1. Startseite
  2. Support
  3. Support-Ressourcen
  4. VMware-Dokumentation
  5. Ausgewählte VMware-Dokumentationssätze
  6. vSphere 4.1 Update 3
0800 100 6711
0695 170 9016

Versionshinweise zu ESX 4.1 Update 3

ESX 4.1 Update 3 | 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 ESX:

  • 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 ESX 4.1

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

Seitenanfang

Bevor Sie beginnen

ESX, 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 ESX, VMware vCenter Server, vSphere-Client und wahlweise anderer VMware-Produkte.

ESX, vCenter Server und VDDK-Kompatibilität

Virtual Disk Development Kit (VDDK) 1.2.2 bietet Unterstützung für ESX 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

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

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

Wenn VirtualCenter 2.x installiert ist, finden Sie im vSphere-Upgrade-Handbuch weitere Informationen über das Installieren von vCenter Server auf einem 64-Bit-Betriebssystem und das Beibehalten der VirtualCenter-Datenbank.

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

Durchführen eines Upgrades der VMware Tools

VMware ESX 4.1 Update 3 enthält die neueste Version von VMware Tools. VMware Tools ist eine Reihe von Dienstprogrammen, welche die Leistung des Gastbetriebssystems der virtuellen Maschine verbessern. Eine Liste der Probleme, die in dieser ESX-Version im Zusammenhang mit VMware Tools behoben wurden, finden Sie unter Behobene Probleme für VMware Tools.

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

Upgrade oder Migration auf ESX 4.1 Update 3

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

  • VMware vCenter Update Manager . vSphere-Modul, das direkte Upgrades von ESX 3.5 Update 5a und höher, ESX 4.0.x, ESX 4.1, ESX 4.1 Update 1 und ESX 4.1 Update 2 auf ESX 4.1 Update 3 unterstützt. Weitere Informationen hierzu finden Sie im Administratorhandbuch für VMware vCenter Update Manager.
  • vihostupdate . Befehlszeilenprogramm, das direkte Upgrades von ESX 4.0.x, ESX 4.1, ESX 4.1 Update 1 und ESX 4.1 Update 2 auf ESX 4.1 Update 3 unterstützt. Dieses Dienstprogramm benötigt die vSphere-CLI. Weitere Informationen hierzu finden Sie im vSphere-Upgrade-Handbuch.
  • esxupdate . Befehlszeilenprogramm, das direkte Upgrades von ESX 4.0.x, ESX 4.1, ESX 4.1 Update 1 und ESX 4.1 Update 2 auf ESX 4.1 Update 3 unterstützt. Weitere Informationen hierzu finden Sie im Handbuch für die Patch-Verwaltung von ESX 4.1.
  • esxupgrade.sh Skript . Skript, das Upgrades von ESX 3.5 Update 5a und höher unterstützt. Weitere Informationen hierzu finden Sie im Knowledgebase-Artikel 1009440 und im vSphere-Upgrade-Handbuch.

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

Upgrade-Typ

Unterstützte Upgrade-Tools
Unterstützte Upgrade-Pfade auf ESX 4. 1 Update 3

ESX 3.5 Update 5a

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

ESX 4.1 :
Umfasst
ESX 4.1 Update 1
ESX 4.1 Update 2

ESX-4.1.0-update3-800380.iso
  • VMware vCenter Update Manager mit ESX-Host-Upgrade-Baseline
  • esxupgrade.sh

Ja

Nein

Nein
upgrade-from-esx4.0-to-4.1-update03-800380.zip
  • VMware vCenter Update Manager mit Host-Upgrade-Baseline
  • esxupdate
  • vihostupdate
    Hinweis: Installieren Sie zuerst das Pre-Upgrade-Paket ( pre-upgrade-from-esx4.0-to-4.1-update03-800380.zip), wenn Sie das Dienstprogramm vihostupdateoder esxupdateverwenden, um das Upgrade durchzuführen.

Nein

Ja

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

Nein

Nein

Ja
ESX 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:

Aktualisierte RPMs und Sicherheits-Fixes

Eine Liste der in ESX 4.1 Update 3 aktualisierten RPMs finden Sie im Dokument Aktualisierte RPMs und Sicherheits-Fixes . Dieses Dokument gilt nicht für die ESXi-Produkte.

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 ESX, die vor dem Veröffentlichungsdatum dieses Produkts zur Verfügung standen. Weitere Informationen zu den einzelnen Bulletins finden Sie auf der VMware-Seite Patches herunterladen.

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

ESX410-201208201-UG: Führt ein Update der ESX 4.1-Kernkomponenten und der CIM-Komponenten durch
ESX410-201208202-UG: Führt ein Update des ESX 4.1 Megaraid SAS-Treibers durch
ESX410-201208203-UG: Führt ein Update des ESX 4.1 scsi-hpsa-Treibers durch
ESX410-201208204-UG: Führt ein Update des ESX 4.1 e1000e-Treibers durch
ESX410-201208205-UG: Führt ein Update des ESX 4.1 usbcore-Treibers durch
ESX410-201208206-UG: Führt ein Update des ESX 4.1 usb-storage-Treibers durch
ESX410-201208207-UG: Führt ein Update des ESX 4.1 e2fsprogs-Pakets durch

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

ESX410-201208101-SG: Führt ein Update der ESX 4.1-Kernkomponenten und der CIM-Komponenten durch
ESX410-201208102-SG: Führt ein Update des ESX 4.1 libxml2-python-Pakets durch
ESX410-201208103-SG: Führt ein Update der ESX 4.1 OpenSSL-Komponente durch
ESX410-201208104-SG: Führt ein Update des ESX 4.1 glibc-nscd-Pakets durch
ESX410-201208105-SG: Führt ein Update der ESX 4.1 popt- und rpm-python-Bibliotheken durch
ESX410-201208106-SG: Führt ein Update des ESX 4.1 gnutls-Pakets durch
ESX410-201208107-SG: Führt ein Update des ESX 4.1 perl-Pakets durch

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 ESX-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 ESX 4.1 Update 2 ist auf bestimmten Servern leer
    Beim Ausführen von ESX 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 ESX-Versionen Solaris 10 mit der Standardarbeitsspeichergröße installieren
    Wenn Sie versuchen, Solaris 10 unter ESX 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

  • ESX schlägt fehl, wenn SCSI-Befehle keine Werte an die Servicekonsole zurückliefern
    Wenn abgeschlossene SCSI-Befehle keine Rückgabewerte an die Servicekonsole senden, schlägt ESX fehl und die Servicekonsole zeigt die folgende Fehlermeldung an:
    COS Panic: Lost heartbeat @ esxsc_panic+0x43/0x4f error message

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Auf ESX reicht der für Software-iSCSI- und abhängige iSCSI-Adapter zugeteilte Zeitüberschreitungswert für die iSCSI-Initiator-Anmeldung nicht aus
    Wenn bei einem ESX-Host versucht wird, gleichzeitig mehrere Anmeldungen durchzuführen, schlägt der Anmeldevorgang aufgrund eines zu geringen Zeitüberschreitungswerts für die Anmeldung fehl.

    Das Problem kann dadurch behoben werden, indem Sie es den Benutzern erlauben, den Zeitüberschreitungswert zu konfigurieren.
  • Bei visorfs-Dateisystemen erfasst der ESX-Host die vdf-Ausgabe für das Dienstprogramm "vm-support" nicht
    Die Option zum Erfassen der vdf-Ausgabe steht in ESX nicht zur Verfügung. 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.
  • ESX-Host reagiert aufgrund einer Überflutung des USB-Protokolls für IBM-Geräte nicht mehr
    Ein ESX-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.
  • ESX-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 ESX-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.
  • ESX-Host fällt nach einem fehlgeschlagenen vMotion-Vorgang mit einem violetten Bildschirm aus
    Ein ESX-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 vor dem Kopieren zugeordnet werden.
  • Wenn Sie die Vereinigungsfunktion (Coalescing) auf ESX deaktivieren, fällt der Host mit einem violetten Bildschirm aus
    Wenn bei ESX vmxnet3als vNIC in einigen virtuellen Maschinen verwendet wird und Sie die Paketvereinigung deaktivieren, schlägt der ESX-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 ESX-Host leer dargestellt
    Die Netzwerkkonfiguration eines ESX-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 ESX-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 ESX-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

  • Update des glibc-RPM der ESX-Servicekonsole behebt mehrere Sicherheitsprobleme
    Der glibc-RPM der ESX-Servicekonsole wurde auf Version glibc-2.5-81.el5_8.1 aktualisiert, um mehrere Sicherheitsprobleme zu beheben.
    Im Projekt "Common Vulnerabilities and Exposures" (cve.mitre.org) wurden diesen Problemen die Bezeichnungen CVE-2009-5029, CVE-2009-5064, CVE-2010-0830, CVE-2011-1089, CVE-2011-4609 und CVE-2012-0864 zugewiesen.
  • Update auf Apache Tomcat 6.0.35 behebt mehrere Sicherheitsprobleme
    Apache Tomcat wurde auf Version 6.0.35 aktualisiert, um mehrere Sicherheitsprobleme zu beheben.
    Im Projekt "Common Vulnerabilities and Exposures" (cve.mitre.org) wurden diesen Problemen die Bezeichnungen CVE-2011-3190, CVE-2011-3375, CVE-2011-4858 und CVE-2012-0022 zugewiesen.
  • Update von Perl RPM der ESX-Servicekonsole behebt mehrere Sicherheitsprobleme
    Perl RPM der ESX-Servicekonsole wurde auf perl-5.8.8.32.1.8999.vmw aktualisiert, um mehrere Sicherheitsprobleme zu beheben.
    Von dem Projekt "Common Vulnerabilities and Exposures" (cve.mitre.org) wurde diesen Problemen die Namen CVE-2010-2761, CVE-2010-4410 und CVE-2011-3597 zugewiesen.
  • Update der RPMs popt, rpm, rpm-libs und rpm-python der ESX-Servicekonsole behebt mehrere Sicherheitsprobleme
    Die RPMs popt, rpm, rpm-libs und rpm-python der ESX-Servicekonsole wurden auf die folgenden Versionen aktualisiert, um mehrere Sicherheitsprobleme zu beheben:
    • popt-1.10.2.3-28.el5_8
    • rpm-4.4.2.3-28.el5_8
    • rpm-libs-4.4.2.3-28.el5_8
    • rpm-python-4.4.2.3-28.el5_8
    Im Projekt "Common Vulnerabilities and Exposures" (cve.mitre.org) wurden diesen Problemen die Bezeichnungen CVE-2012-0060, CVE-2012-0061und CVE-2012-0815 zugewiesen.
  • Update von GnuTLS RPM der ESX-Servicekonsole behebt mehrere Sicherheitsprobleme
    GnuTLS RPM der ESX-Servicekonsole wurde auf Version 1.4.1-7.el5_8.2 aktualisiert, um mehrere Sicherheitsprobleme zu beheben.
    Im Projekt "Common Vulnerabilities and Exposures" (cve.mitre.org) wurden diesen Problemen die Bezeichnungen CVE-2011-4128, CVE-2012-1569 und CVE-2012-1573 zugewiesen.
  • Update des OpenSSL-RPMs der Servicekonsole behebt ein Sicherheitsproblem
    Das OpenSSL-RPM der Servicekonsole wurde auf Version 0.9.8e-22.el5_8.3 aktualisiert, um ein Sicherheitsproblem zu beheben.
    Im Projekt "Common Vulnerabilities and Exposures" (CVE) (cve.mitre.org) wurde diesem Problem die Bezeichnung CVE-2012-2110 zugewiesen.
  • 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.
  • Ein Update auf libmxl2 RPMs der ESX-Servicekonsole behebt ein Sicherheitsproblem
    Die libmxl2 RPMs der ESX-Servicekonsole werden auf libxml2-2.6.26-2.1.15.el5_8.2 und libxml2-python-2.6.26-2.1.15.el5_8.2 aktualisiert, um ein Sicherheitsproblem zu beheben.
    Im Projekt "Common Vulnerabilities and Exposures" (CVE) (cve.mitre.org) wurde diesem Problem die Bezeichnung CVE-2012-0841 zugewiesen.

Serverkonfiguration

  • Wenn auf dem ESX-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 ESX-Host ausführen, auf dem die Startoption für die gemeinsame Nutzung von Seiten deaktiviert ist, schlägt der ESX-Host möglicherweise mit einem violetten Bildschirm fehl.
    Durch Deaktivieren der gemeinsamen Nutzung von Seiten wird die Leistung des ESX-Hosts stark beeinträchtigt. 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 ESX-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 ESX-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 ESX-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 ESX-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 ESX-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 ESX 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 [hostname] vmkernel: 107:01:39:59.667 cpu12:21263)VSCSIFs: 329: handle 9267(vscsi0:0):Invalid Opcode (0xd1)
    Nov 22 11:55:06 [hostname] 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 ESX 4.1Update2-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 ESX-Host meldet möglicherweise ein beschädigtes VMFS-Volume, wenn Sie auf einem ESX-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 ESX-Host meldet evtl. fälschlicherweise, dass das VMFS beschädigt ist. Der ESX-Host protokolliert Fehlermeldungen ähnlich der folgenden in der Datei /var/log/vmkernel:

    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.
  • Ein ESX-Host fällt möglicherweise aufgrund eines Problems im VMFS-Modul mit einem violetten Diagnosebildschirm aus.
    Ein ESX-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.
  • ESX-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.
  • ESX-Host fällt möglicherweise beim Neusignieren eines VMFS-Volumes mit einem violetten Bildschirm aus
    Ein ESX-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.
  • ESX-Host fällt bei einem Recompose-Vorgang auf VMware View mit einem violetten Bildschirm und der Fehlermeldung "Out of memory for timers" aus
    Ein ESX-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.
  • Daten werden beim Emulex LPe12000-Treiber beschädigt, wenn eine 4G DMA-Grenzadresse bewältigt
    Wenn beim ESX-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 ESX-Hosts kann auf einem IBM BladeCenter HX5 UEFI-Server nicht geändert werden
    Wenn Sie versuchen, die Betriebsrichtlinie eines ESX-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.

Upgrade und Installation

  • Das Installieren von ESX im grafischen Modus führt auf bestimmten Dell PowerEdge 12G-Servern zu einer falsch ausgerichteten Anzeige
    Wenn Sie ESX auf 12G-Servern im grafischen Modus installieren, ist die Ausrichtung des Installationsbildschirms nicht korrekt. Dieses Problem wurde auf allen 12G-Servern beobachtet. Durch die Verwendung des vesa-Treibers für das Installationsprogramm wird dieses Problem behoben.

    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 ESX-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 ESX-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 ESX-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 ESX-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 ESX 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 ESX 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 ESX-Host ausgeführt wird, schlägt möglicherweise fehl
    Auf einem ESX-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 ESX 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 ESX 4.1 Update 1
    Auf virtuellen Maschinen, die auf ESX 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 ESX 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 ESX 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
    • Wenn Sie ein Upgrade von VMware Tools von einer früheren auf eine spätere Version durchführen, schlägt die IP-Virtualisierung fehl. Dies geschieht, weil der ESX-Host nicht prüft, ob die neue Version des VMCI-Treibers vorhanden ist, und die vsock-DLL-Dateien nicht installieren kann.

Seitenanfang

Bekannte Probleme

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

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

Sicherung

  • VCB-Servicekonsolenbefehle generieren Fehlermeldungen in der ESX-Servicekonsole
    Wenn Sie VCB-Servicekonsolenbefehle in der Servicekonsole von ESX-Hosts ausführen, werden möglicherweise Fehlermeldungen ähnlich den folgenden angezeigt:

    Closing Response processing in unexpected state:3
    canceling invocation: server=TCP:localhost:443, moref=vim.SessionManager:ha-sessionmgr, method=logout

    Closing Response processing in unexpected state:3
    [.... error 'App'] SSLStreamImpl::BIORead (58287920) failed: Thread pool shutdown in progress
    [.... error 'App'] SSLStreamImpl::DoClientHandshake (58287920) SSL_connect failed with BIO Erro

    Sie können diese Meldungen ignorieren. Die Meldungen haben keinen Einfluss auf die Ergebnisse der VCB-Servicekonsolenbefehle.

    Umgehung: Keine.

CIM und API

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

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

Gastbetriebssystem

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

Sonstiges

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

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

    Umgehung: Obwohl Sie die Option -nverwenden können, um die Gesamtzahl an Wiederholungen zu ändern, sollten Sie in Betracht ziehen, 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 resxtop oder esxtop in 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.

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).
  • Zuletzt erstellte VMkernel und Netzwerkadapter für Servicekonsole verschwinden nach dem Aus- und Wiedereinschalten
    Wenn ein ESX-Host innerhalb einer Stunde nach dem Erstellen eines neuen VMKernels bzw. eines Servicekonsolenadapters auf einem vDS aus- und wiedereingeschaltet wird, kann es sein, dass der neue Adapter verschwindet.

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

Serverkonfiguration

  • Das Durchführen eines Upgrades auf ESX 4.1.x schlägt fehl, wenn auf dem Host LDAP konfiguriert und der LDAP-Server nicht erreichbar ist
    Das Durchführen eines Upgrades von ESX 4.x auf ESX 4.1.x schlägt fehl, wenn Sie auf dem ESX-Host LDAP konfiguriert haben und der LDAP-Server nicht erreichbar ist.

    Umgehung: Um dieses Problem zu umgehen, führen Sie eine der folgenden Aufgaben durch:

    • Legen Sie die folgenden Parameter in der Datei /etc/ldap.conffest.
      • Legen Sie zum Zulassen, dass eine Zeitüberschreitung bei Verbindungen zum LDAP-Server auftreten darf, den Parameter bind_policyauf softfest.
      • Legen Sie zum Festlegen der Dauer bis zum Eintreten einer Zeitüberschreitung der LDAP-Verbindung den Parameter bind_timelimitauf 30(Sekunden) fest.
      • Legen Sie zum Festlegen der Dauer bis zum Eintreten einer Zeitüberschreitung pro LDAP-Abfrage den Parameter timelimitauf 30(Sekunden) fest.

         

    • Deaktivieren Sie LDAP und aktivieren Sie es nach Abschluss des Upgrades erneut.
      1. Deaktivieren Sie LDAP, indem Sie vor dem Upgrade den Befehl esxcfg-auth --disableldapvon der Servicekonsole aus aufrufen.
      2. Aktivieren Sie LDAP, indem Sie nach dem Upgrade von der Servicekonsole aus den Befehl esxcfg-auth --enableldap --enableldapauth --ldapserver=xx.xx.xx.xx --ldapbasedn=xx.xx.xxaufrufen.

Speicher

  • ESX-Host fällt mit einem violetten Bildschirm aus, wenn eine LUN in 10-Sekunden-Intervallen zu bestimmten Gastbetriebssystemen hinzugefügt wird *
    Der violette Diagnosebildschirm zeigt Fehlermeldungen ähnlich der folgenden an:

    20:16:16:49.575 cpu0:4120)Code start: 0x41801d800000 VMK uptime: 20:16:16:49.575
    20:16:16:49.576 cpu0:4120)0x417f800c7c18:[0x41801ddb5cf4]fnic_fcpio_cmpl_handler@esx:nover+0x8ef stack: 0x1dc0
    20:16:16:49.577 cpu0:4120)0x417f800c7c68:[0x41801ddb4aa0]fnic_wq_copy_cmpl_handler@esx:nover+0xaf stack: 0x417f800c7d18
    20:16:16:49.577 cpu0:4120)0x417f800c7c88:[0x41801ddb97dd]fnic_isr_msix_wq_copy@esx:nover+0x18 stack: 0x22
    20:16:16:49.578 cpu0:4120)0x417f800c7cc8:[0x41801dc7fd64]Linux_IRQHandler@esx:nover+0x43 stack: 0x83
    20:16:16:49.578 cpu0:4120)0x417f800c7d58:[0x41801d8323e1]IDTDoInterrupt@vmkernel:nover+0x348 stack: 0x4100b1a77ed0
    20:16:16:49.579 cpu0:4120)0x417f800c7d98:[0x41801d8326ba]IDT_HandleInterrupt@vmkernel:nover+0x85 stack: 0x12927df33a3a96
    20:16:16:49.580 cpu0:4120)0x417f800c7db8:[0x41801d83300d]IDT_IntrHandler@vmkernel:nover+0xc4 stack: 0x417f800c7ec0

    Dieses Problem tritt in Umgebungen auf, in denen die Cisco UCS M81KR Virtual Interface Card (VIC) verwendet wird.

    Umgehung: Verwenden Sie den async-Treiber. Die korrekte Version können Sie bei Cisco erfragen.

  • 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 ü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 ESX-Hosts und geben möglicherweise Ausnahmefehlermeldungen in der Remotebefehlszeilenschnittstelle aus. Befehle wie z. B. esxcli swiscsi nic list, esxcli swiscsi nic add, esxcli swiscsi vmnic list , die von der Servicekonsole aus gestartet werden, schlagen fehl, weil sie von Drittanbietertreibern erstellte lange vmnic-Namen nicht handhaben können.

    Umgehung: Der Netzwerkkartentreiber des Drittanbieters muss die vmnic-Namen auf höchstens 8 Byte begrenzen, um mit den Anforderungen für iSCSI-Port-Bindungen kompatibel zu sein.
    Hinweis: Falls der Treiber nicht für iSCSI-Port-Bindungen verwendet wird, kann sein Name bis zu 32 Byte lang sein. Dies gilt auch für iSCSI ohne Port-Bindungs-Funktion.

  • Große Anzahl speicherrelevanter Meldungen in der VMkernel-Protokolldatei
    Wenn ESX auf einem Host mit mehreren physischen Pfaden zu Speichergeräten startet, zeichnet die VMkernel-Protokolldatei eine große Anzahl von speicherrelevanten Meldungen ähnlich 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 ESX-Hosts führen
    Es kann zu erheblichen Verzögerungen beim Starten der Hosts kommen, die LUNs auf einem SAN gemeinsam nutzen. Das kann seine Ursache in Konflikten zwischen den LUN SCSI-Reservierungen haben.

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

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

    Umgehung: Aktualisieren Sie das BIOS auf 2010.05.21 oder eine spätere Version.
  • ESX-Installationen auf HP-Systemen benötigen den HP-NMI-Treiber
    ESX 4.1-Instanzen auf HP-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 ESX 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".
  • ESX auf der HP G6-Plattform mit P410i oder P410 Smart Array-Controller läuft während des Einschaltens der virtuellen Maschinen oder bei Festplatten-E/A-Vorgängen langsam
    Einige 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

    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

  • Das Upgrade auf ESX 4.1 Update 2 schlägt fehl, wenn Sie das Pre-Upgrade-Bulletin pre-upgrade-from-ESX4.0-to-4.1.0-1.4.348481-release.zipanwenden
    Wenn Sie das Pre-Upgrade-Bulletin pre-upgrade-from-ESX4.0-to-4.1.0-1.4.348481-release.zipauf einen Host mit Patches oder Update-Versionen anwenden, die später als September 2010 veröffentlicht wurden, was ESX400-201009001 und ESX 4.0 Update 3 einschließt, schlägt das Upgrade auf ESX 4.1 Update 2 fehl und die folgende Fehlermeldung wird angezeigt:

    Encountered error RunCommandError:
    This is an unexpected error. Please report it as a bug.
    Error Message - Command '['/usr/bin/vim-cmd', 'hostsvc/runtimeinfo']'
    terminated due to signal 6

    Dieses Problem tritt nicht auf, wenn Sie das Pre-Upgrade-Bulletin pre-upgrade-from-esx4.0-to-4.1-502767.zipanwenden.

    Umgehung: Führen Sie zuerst das esxupdate-Bulletin pre-upgrade-from-esx4.0-to-4.1-502767.zipaus, bevor Sie das Upgrade-Paket installieren.

    Hinweis: Verwenden Sie dieses Bulletin nur für Upgrades mit dem esxupdate-Dienstprogramm. Wenn Sie Upgrades mit VMware Update Manager durchführen, wird das Bulletin nicht benötigt.

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

  • Auf der ESX-Servicekonsole werden beim Durchführen eines Upgrades von ESX 4.0 oder ESX 4.1 auf ESX 4.1.x Fehlermeldungen angezeigt
    Wenn Sie ein Upgrade von ESX 4.0 oder ESX 4.1 auf ESX 4.1.x durchführen, werden auf der ESX-Servicekonsole möglicherweise Fehlermeldungen ähnlich den folgenden angezeigt:
    Auf dem ESX 4.0-Host: Error during version check: The system call API checksum doesn’t match"
    Auf dem ESX 4.1-Host: Vmkctl & VMkernel Mismatch,Signature mismatch between Vmkctl & Vmkernel

    Sie können die Meldungen ignorieren.

    Umgehung:Starten Sie den ESX 4.1.x-Host neu.

  • Die Ausgabe des Befehls "esxupdate - a" zeigt keine mitgelieferten Treiber an, wenn ein Upgrade des ESX-Hosts von ESX 4.0 Update 2 auf ESX 4.1.x durchgeführt wird
    Wenn Sie ein Upgrade des ESX-Hosts von ESX 4.0 Update 2 auf ESX 4.1.x mithilfe des Dienstprogramms esxupdatedurchführen, zeigt die Ausgabe des Befehls esxupdate -akeine mitgelieferten Treiber an.

    Umgehung
    Führen Sie den Informationsbefehl esxupdate -b <ESX410-Update01>aus, um Informationen über alle für ESX 4.1.x mitgelieferten und asynchronen Treiber-Bulletins anzuzeigen.

  • Das Upgrade auf ESX 4.1.x schlägt fehl, wenn auf dem Host eine vorherige Version von IBM Management Agent 6.2 konfiguriert ist
    Wenn Sie auf dem Host ein Upgrade von ESX 4.x auf ESX 4.1.x durchführen, schlägt das Upgrade fehl und Fehlermeldungen werden in ESX und VUM angezeigt:

    • In ESX protokolliert der Host die folgende Meldung in der Datei esxupdate.log: DependencyError: VIB rpm_vmware-esx-vmware-release-4_4.1.0-0.0.260247@i386 breaks host API vmware-esx-vmware-release-4 <= 4.0.9.
    • In VUM wird die folgende Meldung auf der Registerkarte Aufgaben & Ereignisse angezeigt: Standardisierung fehlgeschlagen: SingleHostRemediate: esxupdate-Fehler, Version: 1.30, "Vorgang: 14: Beim Auflösen der Abhängigkeiten ist ein Fehler aufgetreten.

    Dieses Problem tritt auf, wenn auf dem ESX 4.x-Host eine vorherige Version von IBM Management Agent 6.2 ausgeführt wird.

    Umgehung: Installieren Sie IBM Management Agent 6.2 auf dem ESX 4.x-Host und aktualisieren Sie ihn anschließend auf ESX 4.1.x.

  • Beim Prüfen des ESX-Hosts anhand des ESX410-Update01- oder ESX410-201101226-SG-Bulletins wird eine Meldung des Typs "Nicht kompatibler Status" angezeigt
    Wenn Sie VUM zum Prüfen eines ESX-Hosts verwenden, der das ESX410-Update01- oder ESX410-201101226-SG-Bulletin enthält, zeigt das Ergebnis der Prüfung möglicherweise an, dass der Status nicht kompatibel ist.

    Umgehung:
  •  
    • Ignorieren Sie die Meldung des Typs "Nicht kompatibler Status" und fahren Sie mit dem Standardisierungsvorgang fort.
    • Entfernen Sie die Meldung des Typs "Nicht kompatibler Status", indem Sie das ESX410-201101203-UG-Bulletin installieren, und führen Sie die Prüfung durch.

vMotion und Storage vMotion

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

vSphere-Befehlszeilenschnittstelle

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

    Umgehung: Durch das Starten des ESX-Systems wird die Sperrdatei gelöscht und der zuvor ausgeführte Befehl     vicfg-snmp , der die Sperre verursachte, angewendet. Allerdings tritt nach wie vor ein Fehler auf, wenn Sie versuchen, den Befehl vicfg-snmp -r oder vicfg-snmp -D auszuführen.

VMware Tools

  • Die Verwendung der VMXNET-Netzwerkschnittstellenkarte ist nach der Installation von VMware Tools in RHEL3 mit dem neuesten Errata-Kernel auf ESX 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 ESX-Hosts von ESX 3.5 auf ESX 4.1 zusammen mit einem Upgrade der ESX-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.

Seitenanfang