ESX 4.1 Update 2 | 27. Okt. 2011 | Build 502767
VMware Tools | 27 Okt. 2011 | Build 493255

Letzte Dokumentaktualisierung: 27. Okt. 2011

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 neue Prozessoren — ESX 4.1 Update 2 unterstützt die AMD Opteron 6200-Serie (Interlagos) und die AMD Opteron 4200-Serie (Valencia).

    Hinweis: Für die Prozessoren der Familie AMD 15h behandelt ESX/ESXi 4.1 Update 2 jeden Kern innerhalb einer Recheneinheit als unabhängigen Kern, außer während der Anwendung von Lizenzen. Zum Zweck der Lizenzierung behandelt ESX/ESXi jede Recheneinheit als Kern. Obwohl beispielsweise ein Prozessor mit 8 Recheneinheiten das Prozessoräquivalent von 16 Kernen auf ESX/ESXi 4.1 Update 2 bereitstellen kann, verwendet er nur 8 Lizenzen.
  • Unterstützung für einen zusätzlichen Treiber — ESX 4.1 Update 2 unterstützt Dell PERC8 RAID-Treiber-Updates.

Behobene Probleme Diese Version enthält darüber hinaus verschiedene 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.1 bietet Unterstützung für ESX 4.1 Update 2 und vCenter Server 4.1 Update 2. 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 vSphere-Kompatibilitätstabellen ( PDF)

Installation und Upgrade

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

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

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

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

  • VMware vCenter Update Manager . vSphere-Modul, das direkte Upgrades von ESX 3.5 Update 5a, ESX 4.0.x und ESX 4.1 und ESX 4.1 Update 1 auf ESX 4.1 Update 2 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 und ESX 4.1 Update 1 auf ESX 4.1 Update 2 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 und ESX 4.1 Update 1 auf ESX 4.1 Update 2 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-Hosts 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 2:

Upgrade-Typ

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

ESX 3.5 Update 5a

ESX 4.0
enthält:
ESX 4.0 Update 1
ESX 4.0 Update 2
ESX 4.0 Update 3

ESX 4.1

ESX-4.1.0-update02-rc-463540.iso
  • VMware vCenter Update Manager mit ESX-Host-Upgrade-Baseline
  • esxupgrade.sh

Ja

Nein

Nein

upgrade-from-esx4.0-to-4.1-update02-463540.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-update02-463540.zip), wenn Sie das Dienstprogramm vihostupdateoder esxupdateverwenden, um das Upgrade durchzuführen.

Nein

Ja

Nein

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

Anmerkungen:

In dieser Version enthaltene Patches

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

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

ESX410-201110201-SG: Führt ein Update der ESX 4.1-Kernkomponenten und der CIM-Komponenten durch
ESX410-201110202-SG: Führt ein Update des ESX 4.1 Openldap-Clients durch
ESX410-201110203-UG: Führt ein Update des ESX 4.1 bnx2x-Gerätetreibers durch
ESX410-201110204-SG: Führt ein Update der ESX 4.1 Openssl-Komponente durch
ESX410-201110205-UG: Führt ein Update des ESX 4.1 bnx2-Gerätetreibers durch
ESX410-201110206-SG: Führt ein Update von ESX 4.1 libuser rpm durch
ESX410-201110207-SG: Führt ein Update von ESX 4.1 pam rpm durch
ESX410-201110208-UG: Führt ein Update von ESX 4.1 parted rpm durch
ESX410-201110209-UG: Führt ein Update der ESX 4.1 vaai-Komponente durch
ESX410-201110210-SG: Führt ein Update von ESX 4.1 qlogic-fchba-provider durch
ESX410-201110211-UG: Führt ein Update der ESX 4.1 sata-ahci-Treiber durch
ESX410-201110212-UG: Führt ein Update des ESX 4.1 scsi-aic79xx-Treibers durch
ESX410-201110213-UG: Führt ein Update des ESX 4.1 Megaraid SAS-Treibers durch
ESX410-201110214-SG: Führt ein Update von ESX 4.1 nss- und nspr-Bibliotheken durch
ESX410-201110215-UG: Führt ein Update des ESX 4.1 tg3-Netzwerktreibers durch
ESX410-201110216-UG: Führt ein Update des ESX 4.1 igb-Netzwerktreibers durch
ESX410-201110217-UG: Führt ein Update des ESX 4.1scsi-qla2xxx-Treibers durch
ESX410-201110218-UG: Führt ein Update der ESX 4.1 webCenter-Komponenten durch
ESX410-201110218-UG: Führt ein Update von ESX 4.1 tzdata rpm durch
ESX410-201110221-UG: Führt ein Update des ESX 4.1 esxupdate-Pakets durch
ESX410-201110222-UG: Führt ein Update der ESX 4.1 dhcp-cos-Komponente durch
ESX410-201110223-UG: Führt ein Update des ESX 4.1 nx-nic-Gerätetreibers durch
ESX410-201110224-SG: Führt ein Update des ESX 4.1 mptsas-Gerätetreibers durch

ESX 4.1 Update 2 enthält zudem alle Fixes in den folgenden bereits veröffentlichten Paketen:

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

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

Behobene Probleme

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

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

Sicherung

  • Die virtuelle Maschine schaltet sich beim Erstellen oder Löschen von Snapshots manchmal aus


  • vmx| [msg.disk.configureDiskError] Reason: Failed to lock the file
    vmx| Msg_Post: Error
    vmx| [msg.checkpoint.continuesync.fail] Error encountered while restarting virtual machine after taking snapshot. The virtual machine will be powered off.

CIM und API

  • Die RefreshDatastore-API zeigt keinen Fehler an, wenn sie auf einem Offline-Datenspeicher aufgerufen wird


  • Der ESX-Host zeigt als Arbeitsspeichertyp "Unbekannt" an




  • Wenn ESXi 4.1 Update 1 Embedded installiert und das System neu gestartet wird, führt dies zu einem Benutzer-World-Core-Dump


  • CoreDump: 1480:Userworld sfcb-qlgc /var/core/sfcb-qlgc-zdump.003
    qlogic-fchba-provider-410.1.3.5-260247 (Version 1.3.5) in esx41u2
  • CIM-Server sendet ungültige Warnungen an IBM Systems Director
    Der CIM-Server-Prozess (sfcbd) auf dem ESX-Host sendet möglicherweise ungültige OMC_IpmiAlertIndication-Warnungen in Zusammenhang mit fehlenden CPUs an die IBM Systems Director-Software. Dieses Problem wurde auf IBM-Blade-Servern, wie z. B. IBM LS22 7901-AC1, beobachtet.

    Dieses Problem wurde in der vorliegenden Version behoben.

Gastbetriebssystem

  • vMotion schlägt periodisch mit einer Zeitüberschreitungsmeldung fehl
    vMotion schlägt periodisch mit einer Zeitüberschreitungsmeldung fehl und protokolliert die folgende Fehlermeldung in der hostd-Protokolldatei:
    Fehler -1: Der VM-Prozess konnte nicht gestartet werden. Der Peer-Prozess konnte nicht gestartet werden.
    Diese Meldung wird protokolliert, weil der Namensauflösungs-Aufruf durchgeführt wird, bevor die Signal-Handler installiert werden.

    Dieses Problem wurde in der vorliegenden Version behoben. Der Fix führt den Namensauflösungs-Aufruf nach der Installation der Signal-Handler durch.

  • Die Arbeitsspeicher-Hot-Plug-Funktion funktioniert auf SLES 11-32-Bit-Gastbetriebssystemen nicht
    Arbeitsspeicher-Hot-Plug ist auf SLES 11-32-Bit-Gastbetriebssystemen keine unterstützte Funktion. Die Option "Speicher/CPU-Hotplug" unter Einstellungen bearbeiten > Optionen ist in dieser Version deaktiviert.

Sonstige Probleme

  • Anmeldung beim ESX 4.1-Host mit nicht lokalen Anmeldedaten nicht möglich
    Dies ist auf Änderungen zurückzuführen, die in ESX 4.1 an der Datei /etc/security/access.confvorgenommen wurden. Der Eintrag -:ALL:ALLin der Datei access.confin ESX 4.1 führt zu einem Fehlschlagen von NIS bzw. allen nicht lokalen Benutzerauthentifizierungen.

    Dieses Problem wurde in der vorliegenden Version behoben, indem der neue Parameter plugins.vimsvc.shellAccessForAllUsersauf dem vSphere-Client hinzugefügt wurde. Sie können jetzt alle nicht lokalen Benutzerauthentifizierungen aktivieren, indem Sie plugins.vimsvc.shellAccessForAllUsersauf truesetzen und erneut eine Verbindung zu vCenter Server herstellen.
  • NUMA-Ungleichgewicht nach vMotion virtueller Maschinen (KB 2000740)
  • Fügt eine Arbeitsspeicherungleichgewichts-Warnung für ESX-Hosts hinzu, auf denen NUMA-Knoten aktiviert sind
    Die Leistung von ESX-Hosts, auf denen NUMA-Knoten aktiviert sind, kann beeinträchtigt werden, wenn der einem NUMA-Knoten zugewiesene Arbeitsspeicher mehr als 30 % größer ist als andere Knoten. Jetzt wird die folgende Warnung angezeigt, wenn ein ESX-Host ein Arbeitsspeicherungleichgewicht feststellt:

    Es wurde ein wesentliches Arbeitsspeicherungleichgewicht (DRAM) (über 30 Prozent) zwischen den NUMA-Knoten x(a MB) und y(b MB) festgestellt. Dies kann sich auf die Leistung auswirken.
  • Wenn Sie eine virtuelle Windows 2003 Service Pack 2 R2-Maschine mithilfe von vSphere 4.1 zurücksetzen, schlägt die virtuelle Maschine mit einem blauen Bildschirm fehl

  • Gast neu starten
  • Lange syslog-Meldungen werden auf ESXi-Hosts abgeschnitten
    Protokollmeldungen, die länger als etwa 2048 Byte sind, werden auf ESXi-Hosts möglicherweise nicht in /var/log/messagesgeschrieben.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der Datenspeicherbrowser kann auf NFS-Volumes keine symbolischen Links verwalten, wenn er von vCenter 4.1 oder vSphere 4.1 aus mit dem ESX-Host verbunden ist


  • ESX-Hosts schlagen mit einem violetten Diagnosebildschirm fehl, wenn Sie 'less /proc/scsi/*/*'über die Servicekonsole ausführen

  • `less /proc/scsi/*/*`/proc/scsi/
  • Die Meldungen in vpxalog-Dateien werden in mehrere Zeilen unterteilt

  • vpxa
  • Der vSphere-Client zeigt keine Warnmeldung an, wenn Syslog nicht konfiguriert ist



  • Warnung: Syslog nicht konfiguriert. Überprüfen Sie die Syslog-Optionen unter "Configuration.Software.Advanced Settings" im vSphere-Client.
  • Wenn ein Controller einen anderen Controller übernimmt, werden die Datenspeicher, die sich auf LUNs des übernommenen Controllers befinden, möglicherweise inaktiv


  • In ESXi 4.1 schlägt möglicherweise der hostd-Prozess häufig fehl
    Die gemeinsame Verwendung von Objekten durch den Aufgaben- und den Internationalisierungsfilter führt zu einem häufigen Fehlschlagen des hostd-Prozesses.

    Dieses Problem wurde in der vorliegenden Version behoben. Durch den Fix in ESX 4.1 Update 2 wird das Objekt geklont, anstatt es gemeinsam zu verwenden.
  • Das Ändern von Snapshots mithilfe des Befehls "vim-cmd" schlägt in bestimmten Snapshot-Baumstrukturen fehl
    Das Ändern von Snapshots mithilfe der Befehle vim-cmd vmsvc/snapshot.removeoder vim-cmd vmsvc/snapshot.revert
    schlägt bei der Anwendung auf bestimmte Snapshot-Baumstrukturen fehl.

    Dieses Problem wurde in der vorliegenden Version behoben. Jetzt wird für jeden Snapshot, der einer virtuellen Maschine zugewiesen wird, ein eindeutiger Bezeichner "snapshotId" erstellt. Sie können die snapshotId abrufen, indem Sie den Befehl vim-cmd vmsvc/snapshot.get <vmid>ausführen. Sie können die folgende neue Syntax verwenden, wenn Sie mit denselben Befehlen arbeiten:

    Snapshot wiederherstellen: vim-cmd vmsvc/snapshot.revert <vmid> <snapshotId> [suppressPowerOff/suppressPowerOn]
    Snapshot entfernen: vim-cmd vmsvc/snapshot.remove <vmid> <snapshotId>
  • Wenn Sie "Technischen Remote-Support-Modus (SSH)" oder "Lokalen technischen Support-Modus" aktivieren, wird eine Warnmeldung ähnlich der folgenden in vCenter Server angezeigt:

    Konfigurationsprobleme
    Der lokale technische Support-Modus wurde für den Host "localhost.localdomain" aktiviert.
    Der technische Remote-Support-Modus (SSH) wurde für den Host <server> aktiviert

    Dieses Problem wurde in der vorliegenden Version behoben. Sie können diese Warnung jetzt deaktivieren, indem Sie den Parameter "UserVars.SuppressShellWarning" in vCenter Server festlegen.
  • Eine virtuelle Maschine, die mit einem Fixed-Passthrough-Gerät konfiguriert ist, wird nicht eingeschaltet
    Eine virtuelle Maschine, die mit 14 oder mehr PCIe-Geräten konfiguriert ist, wird möglicherweise nicht eingeschaltet, wenn es sich bei einem der Geräte um ein Fixed-Passthrough-Gerät (FPT) handelt. Manchmal startet die virtuelle Maschine beim ersten Neustart, aber nicht bei nachfolgenden Neustarts. Eine Fehlermeldung ähnlich der folgenden wird in vmware.loggeschrieben:

    Mar 25 20:56:17.659: vcpu-0| Msg_Post: Error
    Mar 25 20:56:17.659: vcpu-0| [msg.pciPassthru.mmioOutsidePCIHole] PCIPassthru 005:00.0: Guest tried to map 32 device pages (with base address of 0x0) to a range occupied by main memory. This is outside of the PCI Hole. Add pciHole.start = "0" to the configuration file and then power on the VM.

    Dieses Problem wurde in der vorliegenden Version behoben.

Netzwerk

  • Wenn Sie einen vNetwork Distributed Switch löschen, zeigt der ESX-Host eine Fehlermeldung an


  • Aufruf von "HostNetworkSystem.UpdateNetworkConfig" für Objekt "networkSystem-3739" auf vCenter Server "loganvc29.eng.vmware.com" ist fehlgeschlagen.
    Vorgang fehlgeschlagen, Diagnosebericht: DVS DvsPortset-0 hat 1 Schatten- oder Zombie-Port.
  • Das erste Paket, das die e1000 vNIC sendet, hat eine ungültige MAC-Adresse

  • 00:00:00:xx:xx:xx.
  • Der ESXi-Host, der mit dem vNetwork Distributed Switch (vDS) konfiguriert ist, trennt seine Verbindung zum vCenter Server und stellt die Verbindung auch nach mehreren Versuchen nicht wieder her

  • Grenzwert überschritten
  • Die Netzwerkkonnektivität schlägt möglicherweise fehl, wenn VLANs mit physischen Netzwerkkarten konfiguriert sind, die be2net- oder ixgbe-Treiber verwenden
    Wenn Sie auf einem vNetwork Distributed Switch ein einzelnes VLAN oder einen VLAN-ID-Bereich für dvUplink-Portgruppen konfigurieren, schlägt die Netzwerkkonnektivität möglicherweise für das einzelne VLAN oder für das VLAN fehl, dem die höchste VLAN-ID aus dem VLAN-ID-Bereich zugewiesen wurde, wenn Sie einen be2net- oder ixgbe-Treiber für eine physische Netzwerkkarte installiert haben.

    Dieses Problem wurde in der vorliegenden Version behoben.

Sicherheit

  • Behebt ein Ganzzahl-Überlauf-Problem im SFCB

    Diese Version behebt ein Ganzzahl-Überlauf-Problem im SFCB, das auftritt, wenn der Wert für "httpMaxContentLength" in /etc/sfcb/sfcb.cfgvom Standardwert in 0 geändert wird. Der Ganzzahl-Überlauf könnte es Remote-Angreifern ermöglichen, eine Dienstverweigerung (Beschädigung des Heap-Speichers) zu verursachen oder beliebigen Code über eine große Ganzzahl im Content-Length-HTTP-Header auszuführen.

    Im Projekt "Common Vulnerabilities and Exposures" (CVE) (cve.mitre.org) wurde diesem Problem die Bezeichnung CVE-2010-2054 zugewiesen.
  • Update auf pam RPM

    In dieser Version wurde pam RPM auf pam_0.99.6.2-3.27.5437.vmw aktualisiert, wodurch mehrere Sicherheitsprobleme mit PAM-Modulen behoben werden.

    Im Projekt "Common Vulnerabilities and Exposures" (cve.mitre.org) wurden diesen Problemen die Bezeichnungen CVE-2010-3316, CVE-2010-3435 und CVE-2010-3853 zugewiesen.
  • Die Cold-Migration schlägt zwischen ESX 4.1-Hosts fehl, die sich in zwei verschiedenen Clustern befinden


  • Update der openssl-Pakete
     
    Fehler-Zusammenfassung: In dieser Version wurden die openssl-Pakete von openssl098e auf openssl-0.9.8e.12.el5_5.7 aktualisiert, wodurch zwei Sicherheitsprobleme behoben werden. Im Projekt "Common Vulnerabilities and Exposures" (cve.mitre.org) wurden diesen Problemen die Bezeichnungen CVE-2008-7270 und CVE-2010-4180 zugewiesen.
  • Update der NSS- und NSPR-Bibliotheken
     
    In dieser Version wurde der Lizenztext in den Quelldateien der Network Security Services (NSS)- und Netscape Portable Runtime (NSPR)-Bibliotheken aktualisiert, um diese Pakete gemäß den Bedingungen der Lesser General Public License (LGPL) 2.1 anstelle der Mozilla Public License (MPL) zu verteilen. Außerdem wurden NSS und NSPR auf nspr-4.8.6-1 und nss-3.12.8-4 aktualisiert, wodurch mehrere Sicherheitsprobleme gelöst werden.

    Im Projekt "Common Vulnerabilities and Exposures" (cve.mitre.org) wurden diesen Problemen die Bezeichnungen CVE-2010-3170 und CVE-2010-3173 zugewiesen.
  • Update von libuser RPM
      
    In dieser Version wurde libuser RPM auf Version 0.54.7-2.1.el5_5.2 aktualisiert, um ein Sicherheitsproblem zu lösen. Im Projekt "Common Vulnerabilities and Exposures" (CVE) (cve.mitre.org) wurde diesem Problem die Bezeichnung CVE-2011-0002 zugewiesen.
  • Update von openldap- und openldap-client-RPMs
     
    In dieser Version wurden die openldap- und openldap-client-RPMs mit 2.3.43.12.el5_5.1 und 2.3.43-12.el5_6.7 aktualisiert, wodurch mehrere Sicherheitsprobleme hinsichtlich der OpenLDAP-Bibliotheken behoben werden.

    Im Projekt "Common Vulnerabilities and Exposures" (cve.mitre.org) wurden diesen Problemen die Bezeichnungen CVE-2010-0211, CVE-2010-0212 und CVE-2011-1024 zugewiesen.
  • Updates von userworld glibc

    Fehler-Zusammenfassung: In dieser Version wurde userworld glibc auf 2.5-58.el5_6.2 aktualisiert, um mehrere Sicherheitsprobleme zu beheben.
     
    Im Projekt "Common Vulnerabilities and Exposures" (cve.mitre.org) wurden diesen Problemen die Bezeichnungen CVE-2011-0536, CVE-2010-0296, CVE-2011-1071 und CVE-2011-1095 zugewiesen.
  • Update des mpt2sas-Treibers

    In dieser Version wurde der mpt2sas-Treiber aktualisiert, um mehrere Sicherheitsprobleme zu beheben, die eine Eskalation der lokalen Benutzerrechte zulassen.

    Im Projekt "Common Vulnerabilities and Exposures" (cve.mitre.org) wurden diesen Problemen die Bezeichnungen CVE-2011-1494 und CVE-2011-1495 zugewiesen.
  • Update der Intel e1000- und e1000e-Treiber

    Dies behebt ein Sicherheitsproblem bei den e1000- und e1000e-Linux-Treibern für Intel PRO/1000-Adapter, das es einem Remote-Angreifer ermöglicht, Paketfilter zu umgehen und manipulierte Pakete zu senden.

    Im Projekt "Common Vulnerabilities and Exposures" (CVE) (cve.mitre.org) wurde diesem Problem die Bezeichnung CVE-2009-4536 zugewiesen.

Serverkonfiguration

  • Syslog-Vorgänge schlagen möglicherweise fehl, wenn der Remotehost nicht erreichbar ist

  • syslogd
    syslogd
  • In ESXi werden Änderungen, die an der Datei /etc/pam.d/system-authzum Bearbeiten von Kennworteinstellungen vorgenommen wurden, nicht über Systemneustarts hinaus beibehalten.
    Die Datei /etc/pam.d/system-authkann nicht von Benutzern bearbeitet werden. Dies führt dazu, dass Änderungen, die an der Datei /etc/pam.d/system-autherfolgen, nicht über Systemneustarts hinaus bestehen bleiben. Sie können jetzt die Kennworteinstellungen bearbeiten, indem Sie Änderungen an der Datei /etc/pam.d/passwdvornehmen.

    Dieses Problem wurde in der vorliegenden Version behoben.

Speicher

  • Das Failover des FalconStor-Hostbusadapters (HBA) ruft den Zustand "Keine Pfade verfügbar" (All Paths Down, APD) hervor, wenn QLogic QME2472-Hostbusadapter mit ESX 4.0 verwendet werden


  • Der ESX/ESXi-Host erkennt die iSCSI-Funktionen des NC382i-Adapters nach einem Upgrade nicht


  • Wenn Sie einen Fibre-Channel-Switch in einem ESX/ESXi-Host neu starten, wird der Verbindungsstatus des Switches nicht wiederhergestellt


  • Die Zielinformationen für Fiber Channel-LUNs (Logical Unit Numbers) eines mit dem ESX-Host verbundenen 3par-Arrays wird in vSphere nicht angezeigt


  • In ESX/ESXi können virtuelle Maschinen die Raw-Gerätezuordnungsdateien nicht erkennen, die sich auf dem Dell MD36xxi-Speicher-Array befinden


  • KB 1037925
  • Snapshots von aktualisierten VMFS-Volumes können nicht auf ESX 4.x-Hosts gemountet werden
    Snapshots von VMFS3-Volumes, die von VMFS2 aktualisiert wurden und deren Blockgröße über 1 MB liegt, können möglicherweise nicht auf ESX 4.x-Hosts gemountet werden. Der Befehl zum Auflisten der erkannten VMFS-Snapshot-Volumes esxcfg-volume -lschlägt fehl und zeigt die folgende Fehlermeldung an:

    ~ # esxcfg-volume -l
    Fehler: Kein Dateisystem auf dem Gerät

    Dieses Problem wurde in der vorliegenden Version behoben. Jetzt können Sie Snapshots von VMFS3-Volumes, die von VMFS2 aktualisiert wurden, mounten und neu signieren.
  • ESX-Hosts mit einem integrierten QLogic-Fibre-Channel-Treiber schlagen beim Prüfen auf LUNs mit einem violetten Diagnosebildschirm fehl


  • Die Einstellung "Aktive, nicht optimierte Pfade verwenden" (useANO) für Geräte wird nach Systemneustarts nicht beibehalten


  • ESXi 4.1 protokolliert kontinuierlich interne SATA-Fehlermeldungen auf einem Dell PowerEdge-System


  • cpu2:4802)<6>ata1:soft resetting port
    cpu1:4802)<6>ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
    cpu0:4802)<6>ata1.00: configured for UDMA/100
    cpu0:4802)<6>ata1: EH complete
    cpu0:4802)<3>ata1.00: exception Emask 0x40 SAct 0x0 SErr 0x800 action 0x2
    cpu0:4802)<3>ata1.00: (irq_stat 0x40000001)
    cpu0:4802)<3>ata1.00: tag 0 cmd 0xa0 Emask 0x40 stat 0x51 err 0x24 (internal error)

  • Ein ESX-Host, der mit einem Bandlaufwerk verbunden ist, auf das mithilfe des aic79xx-Treibers zugegriffen wird, schlägt fehl
    Ein ESX-Host, der mit einem Bandlaufwerk verbunden ist, auf das mithilfe des aic79xx-Treibers zugegriffen wird, schlägt möglicherweise mit einem violetten Bildschirm fehl und zeigt eine Fehlermeldung ähnlich der folgenden an, wenn der Treiber versucht, auf einen frei gewordenen Arbeitsspeicherbereich zuzugreifen:

    Loop 1 frame=0x4100c059f950 ip=0x418030a936d9 cr2=0x0 cr3=0x400b9000

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der Pfadstatus von LUNs (Logical Unit Numbers), die mit einem ESX/ESXi-Host verbunden sind, wird auch nach dem erneuten Verbinden der LUNs mit dem ESX/ESXi-Host nicht aktualisiert


Unterstützte Hardware

  • Ein MAI KEYLOK II-USB-Gerät, das an einen ESX-Host angehängt ist, ist auf Linux-VMs nicht verfügbar


Upgrade und Installation

  • Während einer Neuinstallation von ESX 4.1 Update 1 oder früheren Versionen kann die Blockgröße oder die Größe des VMFS-Volumes nicht geändert werden
    Wenn Sie ESX/ ESXi 4.1 Update 1 oder frühere Versionen mit erweitertem Setup installieren, steht Ihnen keine Option zum Ändern der Partitionsgröße und der VMFS-Blockgröße zur Verfügung. Standardmäßig wird das VMFS-Volume für die gesamte Partition erstellt.
    ESX/ESXi ermöglicht Ihnen jetzt, die vmfs-Blockgröße während der GUI-, Text- und Kickstart-Installation anzugeben, wodurch das Problem behoben wird.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Wenn Sie ein Upgrade von ESX 3.5 auf Version 4.1 durchführen, steigt die CPU-Nutzung in der NetWare 5.1 Service Pack 8-VM


  • Der megaraid_sas-Treiber wurde von Version 4.0.14.1-18 auf Version 5.30 aktualisiert


  • Die ESX 4.1-Installation schlägt auf einem Hitachi BS320 AC51A3-Blade-Server mit dem LSI SAS Mezzanine-Controller (LSI 1064E) fehl
    Das Problem tritt aufgrund einer FireWire-Serial-Bus-Prüfung auf, die als experimentelle Funktion in ESX 4.1 hinzugefügt wurde. Unter https://www.vmware.com/support/policies/experimental.html finden Sie Informationen zur offiziellen Haltung von VMware gegenüber experimentellen Funktionen in unseren Produkten.

    Dieses Problem wurde in der vorliegenden Version durch die Deaktivierung von FireWire behoben. FireWire wird in ESX 4.1 und höher nicht offiziell unterstützt.

Verwaltung von virtuellen Maschinen

  • Wenn Sie in ESX 3.5/4.0 den ESX-Host über MOB (Managed Object Browser) durchsuchen, werden die CPU- und Arbeitsspeicherreservierungswerte als "nicht gesetzt" angezeigt

  • [virtualMachineConfigSummary.cpuReservation]
    [virtualMachineConfigSummary.memoryReservation]

  • Nach dem Upgrade von ESX 4.0 auf ESX 4.0 Update 1 funktioniert auf einer seriellen PCI-Karte mit mehreren Ports nur ein Port
    Wenn Sie einen ESX-Host von ESX 4.0 auf ESX 4.0 Update 1 aktualisieren, funktioniert nur ein Port der seriellen Karte, obwohl vor dem Upgrade alle Ports auf der seriellen Karte ordnungsgemäß funktionierten. Wenn Sie die virtuelle Maschine einschalten, wird auf der Konsole möglicherweise die folgende Fehlermeldung angezeigt:
    "serial0: Die Datei "/dev/ttyS1" ist offenbar kein serieller Port: Eingabe/Ausgabe-Fehler. Das virtuelle Gerät serial0 wird nicht verbunden gestartet."

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Anpassung eines im laufenden Betrieb erstellten Klons einer virtuellen Maschine, auf dem das Gastbetriebssystem Windows 2008 R2 ausgeführt wird, schlägt fehl und der Klon startet kontinuierlich neu Die Anpassung des im laufenden Betrieb erstellten Klons eines Windows 2008 R2-Gastbetriebssystems schlägt mit der Fehlermeldung "Automatische Prüfung nicht gefunden"fehl und die virtuelle Maschine startet fortwährend neu.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • In vCenter zeigt eine geklonte Windows 2000 Professional-VM in der vmx-Datei Windows 2000 anstelle von Windows 2000 Professional als Gastbetriebssystem an




  • In ESX/ESXi 4.0 zeigt die Leistungsstatistik-Eigenschaft "maxSample" in PerfQuerySpec einen falschen Wert an

  • PerfQuerySpec
  • Der vSphere-Client zeigt einen falschen Wert für den bereitgestellten Speicherplatz für eine ausgeschaltete virtuelle Maschine an


  • Das Entfernen eines Snapshots führt zu einem Fehlschlagen des VMware-hostd-Management-Agents
    Wenn Sie den Snapshot einer virtuellen Maschine entfernen, schlägt der VMware-hostd-Management-Agent möglicherweise fehl und zeigt eine Rückverfolgung ähnlich der folgenden an:

    [2010-02-23 09:26:36.463 F6525B90 error 'App']
    Ausnahme: Assert Failed: "_config != __null && _view != __null" @ bora/vim/hostd/vmsvc/vmSnapshot.cpp:1494

    Dies liegt daran, dass die Datei <vm_name>-aux.xml, die sich im selben Verzeichnis wie die Konfigurationsdatei der virtuellen Maschine befindet, leer ist. Wenn eine virtuelle Maschine erstellt oder registriert wird, wird der Inhalt der Datei <vm_name>-aux.xmleingelesen und das _view-Objekt gefüllt. Wenn die XML-Datei leer ist, wird das _view-Objekt nicht gefüllt. Dies führt zu einem Fehler beim Konsolidieren des Snapshots.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESX-Host reagiert nicht mehr, wenn SNMP-Abfragen mithilfe einer MIB-Datei gesendet werden
    Ein ESX-Host reagiert möglicherweise nicht mehr, wenn Sie den eingebetteten SNMP-Agenten auf dem Host aktivieren und SNMP-Abfragen mithilfe der MIB-Datei VMWARE-VMINFO-MIB.miban virtuelle Maschinen senden, die gerade migriert, geklont, erstellt oder gelöscht werden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Eine virtuelle Maschine, die mit Snapshots ausgeführt wird, reagiert möglicherweise nicht mehr, wenn der Wert "Grenzwert – IOPs" für die virtuelle Festplatte geändert wird
    Wenn Sie auf einer virtuellen Maschine, die mit einem oder mehreren Snapshots ausgeführt wird oder einen Snapshot erstellt, den Wert "Grenzwert – IOPs" für eine virtuelle Festplatte von Unbegrenzt in einen anderen Wert ändern, reagiert die virtuelle Maschine möglicherweise alle paar Sekunden nicht mehr.

    Dieses Problem wurde in der vorliegenden Version behoben.

vMotion und Storage vMotion

  • Wenn Sie vMotion auf mehreren virtuellen Maschinen durchführen, zeigt der ESX-Host Warnmeldungen vom Typ Nicht genügend Arbeitsspeicheran


  • WARNUNG: vmklinux26: AllocPages: gfp_mask=0xd4, order=0x0, vmk_PktSlabAllocPage gab im VMkernel-Protokoll während vMotion 'Nicht genügend Arbeitsspeicher' zurück
  • Wenn Sie versuchen, High Availability (HA) und Distributed Resource Scheduler (DRS) in den Wartungsmodus zu versetzen oder einen vMotion-Vorgang durchzuführen, schlägt vMotion mit der Fehlermeldung Nicht genügend Arbeitsspeicherfehl
    Wenn Sie gleichzeitige vMotions durchführen oder einen 4.1-Host in den Wartungsmodus versetzen, der Teil eines DRS-aktivierten Clusters ist, der vCenter 4.1 oder vSphere 4.1 verwendet, schlägt das Entfernen virtueller Maschinen mit den folgenden Fehlermeldungen fehl:

    Migration zu Host <> mit Fehler 'Nicht genügend Arbeitsspeicher' (195887124) fehlgeschlagen. vMotion-Migration [184468762:1286284186972455] Schreibfunktion fehlgeschlagen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • vMotion schlägt aufgrund von gesperrter Auslagerungsdatei fehl


VMware Tools

  • Die Installation von VMware Tools auf einer virtuellen Maschine mit dem Betriebssystem Windows NT 4.0 führt zu einer Fehlermeldung
    Versuche, VMware Tools auf einer virtuellen Maschine mit dem Betriebssystem Windows NT 4.0 zu installieren, sind erfolgreich. Der vSphere-Client zeigt als Tools-Status jedoch Folgendes an: VMware Tools: Veraltet.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das VMware Tools-Upgrade schlägt fehl, wenn einige Ordner unter /tmpin manchen Linux-Gastbetriebssystemen gelöscht werden
    Wenn Sie ein Upgrade von VMware Tools von ESX 3.5 auf ESX 4.0 durchführen, schlägt das Upgrade möglicherweise fehl, da einige Linux-Distributionen alte Dateien und Ordner unter /tmpperiodisch löschen. Das VMware Tools-Upgrade benötigt dieses Verzeichnis unter /tmpfür automatische Upgrades.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • Eine virtuelle Windows-Maschine verliert nach dem Upgrade von VMware Tools die Netzwerkkonnektivität
    Wenn Sie VMware Tools, bei dem das Host Guest File System (HGFS) installiert ist, von ESX 3.5 auf ESX 4.x aktualisieren, wird der HGFS-Treiber möglicherweise nicht ordnungsgemäß deinstalliert. Folglich zeigt die Netzwerk-Registerkarte "Anbieterreihenfolge" der virtuellen Windows-Maschine unter Netzwerkverbindungen > Erweitert > Erweiterte Einstellungen falsche Informationen an und die Netzwerkverbindung der virtuellen Maschine wird möglicherweise unterbrochen.

    Dieses Problem wurde in der vorliegenden Version behoben. Jetzt werden während des Upgrades die frühere Version des HGFS-Treibers und alle damit zusammenhängenden Registrierungseinträge ordnungsgemäß deinstalliert.
  • Wenn Sie einen stillgelegten Snapshot einer Windows 2008 R2-VM erstellen, schlägt die zusätzliche Festplatte in der virtuellen Maschine fehl
    • Windows 2003
    • Windows Vista
    • Windows 2008
    • Windows 7


  • Der Windows HGFS Provider verursacht ein Deadlock, wenn eine Anwendung die WNetAddConnection2-API gleichzeitig von mehreren Threads aus aufruft

  • WNetAddConnection2WNetCancelConnection
  • Die Verwendung der VMXNET-Netzwerkschnittstellenkarte ist nach der Installation von VMware Tools in RHEL3 mit dem neuesten Kernel auf ESX 4.1 U1 nicht möglich

  • vmxnetvsocket
    Umgehung
  • Windows-Gastbetriebssysteme zeigen nach einem Upgrade der virtuellen Hardware einen falschen Netzwerkkarten-Gerätestatus an


  • "Dieses Hardware-Gerät ist nicht mit dem Computer verbunden (Code 45)"
    Umgehung

  • Die Installation von VMware Tools auf einer RHEL 2.1-VM schlägt mit einer Fehlermeldung fehl

  • vmware-install.pl
    Neues initrd-Start-Image für den Kernel wird erstellt. Fehler beim Öffnen von /tmp/vmware-fonts2/system_fonts.conf, Ausführung abgebrochen.
  • Nach der Installation von VMware Tools werden beim Neustart virtueller Linux-Maschinen überflüssige Fehler angezeigt
    Nachdem Sie VMware Tools für Linux installiert und das Gastbetriebssystem gestartet haben, meldet der Geräte-Manager für den Linux-Kernel (udev) möglicherweise überflüssige Fehler ähnlich der folgenden:

    May 4 16:06:11 rmavm401 udevd[23137]: add_to_rules: unknown key 'SUBSYSTEMS'
    May 4 16:06:11 rmavm401 udevd[23137]: add_to_rules: unknown key 'ATTRS{vendor}'
    May 4 16:06:11 rmavm401 udevd[23137]: add_to_rules: unknown key 'ATTRS{model}'
    May 4 16:06:11 rmavm401 udevd[23137]: add_to_rules: unknown key 'SUBSYSTEMS'
    May 4 16:06:11 rmavm401 udevd[23137]: add_to_rules: unknown key 'ATTRS{vendor}'
    May 4 16:06:11 rmavm401 udevd[23137]: add_to_rules: unknown key 'AT

    This issue is resolved in this release. Jetzt erkennt das VMware Tools-Installationsprogramm für Linux das Gerät und schreibt nur systemspezifische Regeln.
  • Einträge in der Konfigurationsdatei werden während der Installation von VMware Tools auf virtuellen Linux-Maschinen überschrieben
    Wenn Sie auf virtuellen Linux-Maschinen VMware Tools installieren oder aktualisieren, überschreibt das VMware Tools-Installationsprogramm möglicherweise Einträge in der Konfigurationsdatei (z. B.die Datei /etc/updated.conf für Redhat und Ubuntu und /etc/sysconfig/locate für SuSE), die von den Entwicklungstools von Drittanbietern vorgenommen wurden. Dies könnte Auswirkungen auf Cron-Aufträgen haben, die updatedb auf diesen virtuellen Maschinen ausführen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der deaktivierte CUPS-Dienst (Common UNIX Printing System) startet automatisch, wenn VMware Tools auf einer SUSE Linux Enterprise Server 10 Service Pack 3, x86-VM installiert oder aktualisiert wird


  • Unter SUSE Linux Enterprise 10

  • chkconfig --level 2345 cups off
    chkconfig --level 2345 cupsrenice off


    service cups status
    chkconfig -l|grep -i cups

  • Unter Red Hat Enterprise Linux 5

  • chkconfig --level 2345 cups off
    system-config-services
  • Das VMCI-Socket (Virtual Machine Communication Interface) auf einem Linux-Gastbetriebssystem reagiert nicht mehr, wenn ein Warteschlangenpaar getrennt wird.
    • Die virtuelle Maschine ist nicht verfügbar.
    • Es wird ein busmem-Invalidierungsfehler aus dem Gastbetriebssystem gemeldet.

  • Verbinden


    Verbindung von Peer zurückgesetzt
  • Die Kernel-Module von VMware Tools werden beim Wechsel zwischen Kernels nicht geladen
    Wenn Sie VMware Tools installieren und zwischen den Kernels wechseln, werden die Module "vsock" und "vmmemctl" beim Startvorgang nicht geladen. Die folgende Fehlermeldung wird angezeigt, wenn Sie einen dmesg-Befehl ausführen oder manuell versuchen, die Module für den falschen Kernel zu laden:

    vmmemctl: Unstimmigkeit hinsichtlich der Version von Symbol module_layout
    vsock: Unstimmigkeit hinsichtlich der Version von Symbol module_layout

    Dieses Problem wurde in der vorliegenden Version behoben. Der Fix in ESX 4.1 Update 2 erstellt die VMware Tools-Module während des Wechsels zwischen den Kernels neu.
  • Der VMware Tools-Dienst (vmtoolsd) schlägt auf 64-Bit-Windows-VMs fehl, wenn mithilfe eines Registrierungsschlüssels eine Zuteilungsreihenfolge des virtuellen Arbeitsspeichers von oben nach unten erzwungen wird



  • Der VMware Tools-Dienst (vmtoolsd) schlägt möglicherweise nach der Installation von VMware Tools auf einem Linux-Gastbetriebssystem mit einem langen Betriebssystemnamen fehl


  • Die X11-Konfiguration wird nach der Installation von VMware Tools geändert

    Nach der Installation von VMware Tools auf einer SLES-VM (SuSe Linux Enterprise Server) wird die X11-Konfiguration geändert. Dadurch wird die Gebietsschema-Einstellung der Tastatur in Albanisch geändert, die Maus- und Monitorkonfiguration ist leer und VNC schlägt fehl.

    Dieses Problem wurde in der vorliegenden Version behoben.

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, wird möglicherweise eine Fehlermeldung ähnlich der folgenden angezeigt:
    Closing Response processing in unexpected state:3 . Sie können diese Meldung ignorieren. Die Meldung hat keinen Einfluss auf die Ergebnisse der VCB-Servicekonsolenbefehle.

    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

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

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

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

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

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


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

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

Sonstiges

  • 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

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

Speicher

  • iSCSI kann nicht über Netzwerkkarte mit langem logischen Gerätenamen konfiguriert werden
    Bei Ausführung des Befehls
    esxcli swiscsi nic add -n von einer 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 der folgenden auf:

    Nov 3 23:10:19 vmkernel: 0:00:00:44.917 cpu2:4347)Vob: ImplContextAddList:1222: Vob add (@&!*@*@(vob.scsi.scsipath.add)Add path: %s) failed: VOB-Kontextüberlauf
    Das System protokolliert mitunter ähnliche Meldungen beim erneuten Prüfen des Speichers. Die Meldungen stellen das erwartete Verhalten dar und sind kein Hinweis auf einen Fehler. Sie 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.

Serverkonfiguration

  • Das Durchführen eines Upgrades auf ESX 4.1 Update 1 schlägt fehl, wenn auf dem Host LDAP konfiguriert ist und der LDAP-Server nicht erreichbar ist
    Das Durchführen eines Upgrades von ESX 4.x auf ESX 4.1 Update 1 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.

    Unterstützte Hardware

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

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


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

      Umgehung: Laden Sie den NMI-Treiber herunter und installieren Sie ihn. Der Treiber steht als Offline-Paket auf der HP-Website zur Verfügung. Siehe zudem KB 1021609 unter http://kb.vmware.com/kb/1021609.
    • Virtuelle Maschinen werden möglicherweise schreibgeschützt, wenn sie auf einem iSCSI-Datenspeicher mit EqualLogic-Speicher laufen
      Virtuelle Maschinen werden möglicherweise auf schreibgeschützt gesetzt, wenn Sie ein EqualLogic-Array mit einer 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


      Umgehung: Installieren Sie das HP 256MB P-series Cache-Upgrade-Modul von http://h30094.www3.hp.com/product.asp?mfg_partno=462968-B21&pagemode=ca&jumpid=in_r3924/kc.

    Upgrade und Installation

    • 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 Update 1 Fehlermeldungen angezeigt
      Wenn Sie ein Upgrade von ESX 4.0 oder ESX 4.1 auf ESX 4.1 Update 1 durchführen, werden auf der ESX-Servicekonsole möglicherweise Fehlermeldungen ähnlich der 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 Update 1-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 Update 1 durchgeführt wird
      Wenn Sie ein Upgrade des ESX-Hosts von ESX 4.0 Update 2 auf ESX 4.1 Update 1 mithilfe des Hilfsprogramms 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 Update 1 mitgelieferten und asynchronen Treiber-Bulletins anzuzeigen.

    • Das Upgrade auf ESX 4.1 Update 1 schlägt fehl, wenn auf dem Host eine vorherige Version von IBM Management Agent 6.2 konfiguriert ist
      Wenn Sie ein Upgrade eines Hosts von ESX 4.x auf ESX 4.1 Update 1 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 auf ESX 4.1 Update 1.

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

    vMotion und Storage vMotion

    • 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

    • PR 632995: Die Verwendung der VMXNET-Netzwerkschnittstellenkarte ist nach der Installation von VMware Tools in RHEL3 mit dem neuesten 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.

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


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

    Seitenanfang