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: 
- 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 des Kernels der ESX-Servicekonsole behebt mehrere Sicherheitsprobleme
Der Kernel der ESX-Servicekonsole wurde aktualisiert, um mehrere Sicherheitsprobleme zu beheben.
Im Projekt "Common Vulnerabilities and Exposures" (cve.mitre.org) wurden diesen Problemen die Bezeichnungen CVE-2011-1833, CVE-2011-2484, CVE-2011-2496, CVE-2011-3188, CVE-2011-3209, CVE-2011-3363, CVE-2011-4110, CVE-2011-1020, CVE-2011-4132, CVE-2011-4324, CVE-2011-4325, CVE-2012-0207, CVE-2011-2699 und CVE-2012-1583 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
vsock
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.
- Deaktivieren Sie LDAP, indem Sie vor dem Upgrade den Befehl esxcfg-auth --disableldapvon der Servicekonsole aus aufrufen.
- 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:
- Wählen Sie im Bestandslistenbereich des vSphere-Client den Host, klicken Sie auf die Registerkarte Konfiguration und anschließend unter "Software" auf Erweiterte Einstellungen.
- Wählen Sie SCSI.
- Ä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
-
- 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