ESXi 4.1 Update 2 Installable | 27. Okt. 2011 | Build 502767
ESXi 4.1 Update 2 Embedded | 27. Okt. 2011 | Build 502767
VMware Tools | 27. Okt. 2011 | Build 493255

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

  • Unterstützung für neue Prozessoren — ESXi 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 ESXi 4.1 Update 2 unterstützt LSI 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 ESXi 4.1

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

Seitenanfang

Bevor Sie beginnen

ESXi, vCenter Server und vSphere Client – Versionskompatibilität

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

ESXi, vCenter Server und VDDK-Kompatibilität

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

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

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

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

MIB-Dateien (Management Information Base), die sich auf ESXi beziehen, werden nicht zusammen mit vCenter Server ausgeliefert. Nur MIB-Dateien, die sich auf vCenter Server beziehen, werden mit vCenter Server 4.0.x mitgeliefert. Alle MIB-Dateien können von der VMware Website unter http://downloads.vmware.com/de/d/ heruntergeladen werden.

Durchführen eines Upgrades der VMware Tools

VMware ESXi 4.1 Update 2 enthält die neueste Version von VMware Tools. VMware Tools besteht aus einer Reihe von Dienstprogrammen, welche die Leistung des Gastbetriebssystemens der virtuellen Maschine verbessern. Unter Behobene Probleme für VMware Tools finden Sie eine Liste der Probleme, die in dieser ESX-Version im Zusammenhang mit VMware Tools behoben wurden.

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

Upgrade oder Migration auf ESXi 4.1 Update 2

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

  • VMware vCenter Update Manager. Ein vSphere-Modul, das direkte Upgrades von ESXi 3.5 Update 5, ESXi 4.0.x und ESXi 4.1 auf ESXi 4.1 Update 1 unterstützt.
  • vihostupdate. Befehlszeilenprogramm, das direkte Upgrades von ESXi 4.0 und ESXi 4.1 Update 1 auf ESXi 4.1 Update 2 unterstützt. Dieses Dienstprogramm benötigt die vSphere-CLI. Weitere Informationen hierzu finden Sie im vSphere-Upgrade-Handbuch. Führen Sie zum Anwenden des VEM-Pakets die Umgehung mithilfe des Dienstprogramms vihostupdate aus. Somit ist es möglich, ESXi 4.1 Update 2 Embedded-Host zum Cisco Nexus 1000 AV 2 vDS hinzuzufügen.

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

Upgrade-Lieferumfang

Unterstützte Upgrade-Tools
Unterstützte Pfade für das Upgrade auf ESXi 4. 1 Update 2

ESXi 3.5 Update 5

ESXi 4.0
enthält:
ESXi 4.0 Update 1
ESXi 4.0 Update 2

ESXi 4.0 Update 3

ESXi 4.1

upgrade-from-ESXi3.5-to-4.1_update02.463540.zip
VMware vCenter Update Manager mit Host-Upgrade-Baseline

Ja

Nein

Nein

upgrade-from-esxi4.0-to-4.1-update02-463540.zip
  • VMware vCenter Update Manager mit Host-Upgrade-Baseline
  • vihostupdate

Nein

Ja

Nein

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

Anmerkungen:

In dieser Version enthaltene Patches

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

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

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

ESXi410-201110201-SG: Aktualisiert ESXi 4.1 Firmware
ESXi410-201110202-UG: Aktualisiert ESXi 4.1 Tools


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

ESXi410-201010401-SG aktualisiert Firmware
ESXi410-201010402-BG aktualisiert VMware Tools

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

Behobene Probleme

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

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

Sicherung

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

  • Wenn Sie während der Durchführung von Snapshot-Vorgängen gleichzeitig eine andere Aufgabe durchführen, wie z. B. das Durchsuchen eines Datenspeichers, wird die virtuelle Maschine möglicherweise abrupt ausgeschaltet. Fehlermeldungen ähnlich der folgenden werden in die Protokolldatei vmware.log geschrieben:
    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.

    Dieses Problem tritt auf, wenn ein anderer Prozess auf dieselbe Datei zugreift, die von der virtuellen Maschine für einen Vorgang benötigt wird.
    Dieses Problem wurde in der vorliegenden Version behoben.

CIM und API

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

  • Wenn Sie ein Speicherkabel von ESXi 4.0 trennen, navigieren Sie zu dem Datenspeicher, der auf diesem FC-SAN mithilfe von MOB (Managed Object Browser) erstellt wurde, und rufen Sie die RefreshDatastore-Methode auf der MoRef (Managed Object Reference) des veralteten Datenspeichers auf. Die RefreshDatastore-API zeigt keinen Fehler an.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESXi-Host zeigt als Arbeitsspeichertyp "Unbekannt" an

  • Wenn Sie den Hardwarestatus eines ESXi-Hosts auf dem über vCenter 4.1 verbundenen HP DL980 G7-Server überprüfen (Home > Bestandsliste > Hosts und Cluster > Hardwarestatus > CPU/Arbeitsspeicher), wird als Arbeitsspeichertyp Unbekannt angezeigt. Dies geschieht, weil das Common Interface Model (CIM) den DDR3-Arbeitsspeichertyp nicht unterstützt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Wenn ESXi 4.1 Update 1 Embedded installiert und das System neu gestartet wird, führt dies zu einem Benutzer-World-Core-Dump

  • Nach der Installation von ESXi 4.1 Update 1 und einem Neustart wird ein Benutzer-World-Core-Dump generiert und die folgende Fehlermeldung auf dem Alt-F11-Konsolenbildschirm angezeigt:

    CoreDump: 1480:Userworld sfcb-qlgc /var/core/sfcb-qlgc-zdump.003.
    Das mit ESXi 4.1 Update 2 ausgelieferte qlogic-fchba-provider-410.1.3.5-260247 (Version 1.3.5) in esx41u2behebt dieses Problem.
  • 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.
  • vCenter Server zeigt für alle installierten OEM VIBS nur ein Konfigurationselement vom Typ "ProviderEnabled" an
    Nach der Installation von OEM-Anbieter-VIBs zeigt vCenter Server für alle installierten OEM-Anbieter-VIBs nur das ProviderEnabled-Konfigurationselement /UserVars/CIMoemProviderEnabledan.

    Dieses Problem wurde in der vorliegenden Version behoben. Wenn Sie jetzt OEM-Anbieter-VIBs installieren, wird für jedes VIB ein Konfigurationselement /UserVars/CIMoem-<originalname>ProviderEnabled erstellt. Sie können jeden Anbieter einzeln aktivieren oder deaktivieren.

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.

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)
  • Wenn die Anzahl der CPU-Kerne pro Socket in einer physischen Maschine erhöht wird, braucht ESXi-Host mehr Zeit, um bestimmte Aufgaben zu erledigen.
    • Starten der Hostmaschine.
    • Hinzufügen eines Hosts zu einem HA-Cluster.
    • Erfassen von Diagnosedaten für vm-support.

  • Auf manchen Server-Plattformen kann die Anzahl der CPU-Kerne pro Prozessor-Socket, die für die Software sichtbar sind, über die BIOS-Konfigurationsoptionen eingestellt werden. Wenn diese Zahl erhöht wird, benötigen ESXi oder ESXi 4.1.x Embedded, die auf einem solchen Server ausgeführt werden, mehr Zeit für die Erfüllung folgender Aufgaben:
    Der zusätzliche Zeitaufwand für die oben genannten Aufgaben macht sich stärker bemerkbar, wenn die Anzahl der Kerne pro Prozessor-Socket auf 8 oder mehr erhöht wird. Dieses Problem wurde in dieser Version behoben. Weitere Informationen finden Sie unter KB 2006081.
  • 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

  • Wenn Sie im vSphere 4.1-Client die Option Gast neu starten für eine symmetrische Multiprocessing-VM mit Windows 2003 Service Pack 2 R2 auswählen, die auf einem Einzel-Prozessor-Kernel ausgeführt wird, schlägt die virtuelle Maschine fehl und zeigt einen blauen Bildschirm an.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • 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

  • Wenn der Datenspeicherbrowser über vCenter 4.1 oder vSphere 4.1 mit dem ESX-Host verbunden ist, zeigt er falsche Werte für symbolische Links und NFS-Volumes an.
    Der Pfad für symbolische Links wird jetzt nicht mehr kanonikalisiert. Dadurch wird das Problem behoben.
  • Die Meldungen in vpxalog-Dateien werden in mehrere Zeilen unterteilt

  • In ESXi 4.1 ist der Syslog-Server nicht in der Lage, die vpxa-Syslog-Meldungen automatisch zu verarbeiten, da die Meldungen in mehrere Zeilen unterteilt werden.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der vSphere-Client zeigt keine Warnmeldung an, wenn Syslog nicht konfiguriert ist

  • Wenn die Konfigurationsinformationen beim Laden der Datei "syslog.conf" nicht gefunden werden, wird in der Registerkarte "Übersicht" des vSphere-Clients keine Warnmeldung in Zusammenhang mit Konfigurationsproblemen angezeigt.
    Dieses Problem wurde in der vorliegenden Version behoben. Es wird jetzt die folgende Meldung in der Registerkarte "Übersicht" des vSphere-Clients angezeigt, 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

  • Die Datenspeicher, die sich auf LUNs des übernommenen Controllers befinden, werden möglicherweise inaktiv und bleiben so lange inaktiv, bis Sie manuell eine erneute Prüfung durchführen.
    Dieses Problem wurde in der vorliegenden Version behoben. Eine manuelle erneute Prüfung von Datenspeichern ist nicht erforderlich, wenn sich Controller ändern.
  • 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

  • Der Versuch, einen vNetwork Distributed Switch aus dem Konfigurationsabschnitt zu entfernen, führt zu der folgenden Fehlermeldung:
    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.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das erste Paket, das die e1000 vNIC sendet, hat eine ungültige MAC-Adresse

  • Die neuesten Gastbetriebssystem-Treiber schreiben Nullen in das RAL/RAH, bevor eine gültige MAC-Adresse festgelegt wird. Dies führt dazu, dass das erste Paket, das die e1000 vNIC sendet, die folgende MAC-Adresse hat: 00:00:00:xx:xx:xx.
    Dieses Problem wurde in der vorliegenden Version behoben. Die e1000 vNIC sendet jetzt erst nach dem Festlegen einer gültigen MAC-Adresse (RAL ist ungleich Null) ein Paket.
  • 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

  • Die globale Portset-Sperre ist für die Port-Aktivierung vorhanden, jedoch nicht für die Port-Deaktivierung. Wenn die Port-Deaktivierung vDS-Eigenschaften ändert, steht sie in Konflikt mit anderen Port-Zuständen, die vDS-Eigenschaften ändern. Als Ergebnis des Konflikts geht die Netzwerkverbindung verloren und die Verbindung des ESXi-Hosts zum vCenter Server wird getrennt. Außerdem wird die Fehlermeldung Grenzwert überschrittenim VMkernel-Protokoll angezeigt.
    Dieses Problem wurde in der vorliegenden Version behoben. Der Fix fügt eine globale Portset-Sperre für die Port-Deaktivierung hinzu.
  • 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

  • Wenn Sie eine Cold-Migration zwischen zwei ESX 4.1-Hosts durchführen, die sich auf zwei verschiedenen Clustern befinden, schlägt die Migration fehl.
    Dieses Problem kann durch Aktivieren von VCB auf der ESX-Firewall behoben werden.
  • 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

  • Der Syslog-Dienst startet nicht, wenn er so konfiguriert ist, dass er sich bei einem Remotehost anmeldet, der nicht über DNS aufgelöst werden kann, wenn der syslogd-Daemon gestartet wird. Dies bewirkt, dass sowohl Remote- als auch lokale Protokollierungsprozesse fehlschlagen.
    Dieses Problem wurde in der vorliegenden Version behoben. Falls der Remotehost jetzt nicht aufgelöst werden kann, bleibt dies ohne Auswirkung auf die lokale Protokollierung. Wenn der syslogd-Daemon startet, versucht er alle 10 Minuten erneut, den Host aufzulösen und eine Verbindung mit ihm herzustellen.
  • 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

  • Das Failover mit dem FalconStor-Hostbusadapter führt zu dem Zustand "Keine Pfade verfügbar", wenn einer der IPStor-Controller ausgeschaltet ist. Qlogic hat einen aktualisierten Treiber veröffentlicht, der das WWPN-Spoofing unterbindet. FalconStor-Arrays verwenden diese Methode zur Failover-Behandlung.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESX/ESXi-Host erkennt die iSCSI-Funktionen des NC382i-Adapters nach einem Upgrade nicht

  • Wenn Sie swiscsi nicht mithilfe eines Broadcom-abhängigen Adapters konfigurieren und ein Upgrade von ESX/ESXi 4.0 auf Version 4.1 durchführen, erkennen ESX/ESXi-Hosts die iSCSI-Funktionen des NC382i-Adapters nicht.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • Wenn Sie einen Fibre-Channel-Switch in einem ESX/ESXi-Host neu starten, wird der Verbindungsstatus des Switches nicht wiederhergestellt

  • Wenn Sie erzwingen, dass der Qlogic ISP2532 HBA im 4 GB-Modus arbeitet, und den Fibre-Channel-Switch neu starten, wird der Verbindungsstatus des Fibre-Channel-Switches nicht wiederhergestellt.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Zielinformationen für Fiber Channel-LUNs (Logical Unit Numbers) eines mit dem ESX-Host verbundenen 3par-Arrays wird in vSphere nicht angezeigt

  • Bei der Anzeige von Multipath-Informationen im mit dem ESX-Host oder vCenter Server verbundenen VMware Infrastructure Client werden möglicherweise die Zielinformationen für einige Pfade von funktionierenden LUNs nicht angezeigt.
    Ersetzen Sie die leeren Werte für Portnummern durch die neuen Pfadinformationen, um das Problem zu beheben.
  • In ESX/ESXi können virtuelle Maschinen die Raw-Gerätezuordnungsdateien nicht erkennen, die sich auf dem Dell MD36xxi-Speicher-Array befinden

  • Virtuelle Maschinen können die Raw-Gerätezuordnungsdateien nicht erkennen, die sich auf dem Dell MD36xxi-Speicher-Array befinden, wenn das Dell MD36xxi-Speicher-Array nicht zum Beanspruchungsregelsatz hinzugefügt wird.
    Dieses Problem wurde in der vorliegenden Version behoben. Der Fix fügt DELL MD36xxi-, MD3600f- und MD3620f-Speicher-Arrays zum Beanspruchungsregelsatz des Speicher-Array-Typ-Plug-ins (SATP) des nativen Multipathing-Plug-Ins (NMP) hinzu. Außerdem werden diese Speicher-Arrays durch VMW_SATP_LSI SATP behandelt. Weitere Informationen finden Sie unter 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

  • Während der Verarbeitung der gemeldeten Daten überprüft die LUN-Erkennungsfunktion nicht, ob die gemeldete Anzahl an LUNs die maximal unterstützte Anzahl an LUNs überschreitet. Dies führt dazu, dass bei ESX-Hosts mit einem integrierten QLogic-Fibre-Channel-Treiber möglicherweise ein "Exception 14"-Ausnahmefehler auftritt und sie mit einem violetten Diagnosebildschirm fehlschlagen.
    Dieses Problem wurde in der vorliegenden Version behoben. Die LUN-Erkennungsfunktion überprüft jetzt, ob die gemeldete Anzahl an LUNs die maximal unterstützte Anzahl an LUNs (256) überschreitet.
  • Die Einstellung "Aktive, nicht optimierte Pfade verwenden" (useANO) für Geräte wird nach Systemneustarts nicht beibehalten

  • Wenn Sie bei Geräten, die die Round-Robin-Pfadauswahlrichtlinie des nativen Multipathing-Plug-Ins (NMP) verwenden, den Wert der useANO-Einstellung auf TRUE setzen, wird dieser nach einem Systemneustart auf FALSE zurückgesetzt.
    Dieses Problem wurde in der vorliegenden Version behoben. Die useANO-Einstellung wird nach dem Systemneustart beibehalten.
  • ESXi 4.1 protokolliert kontinuierlich interne SATA-Fehlermeldungen auf einem Dell PowerEdge-System

  • Auf einem Dell PowerEdge R815- oder R715-System, das einen SATA SB600-, SB700- oder SB800-Controller verwendet, protokolliert ESXi 4.1 kontinuierlich interne SATA-Fehlermeldungen ähnlich der folgenden in der Datei "/var/log/messages".
    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)

    Wenn im SATA-CD-ROM-Laufwerk kein Datenträger bereit oder vorhanden ist, ruft ein interner Fehler den Interrupt-Handler auf, was zu einer übermäßigen Protokollierung führt.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • 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

  • Wenn bei einer LUN, die mehrere Verbindungen zum ESX-Host hat, eines der Kabel abgezogen wird, wird der Pfad, der den ESX-Host und den Speicher verbindet, inaktiv und verbleibt auch nach dem erneuten Anschließen des Kabels in diesem Zustand. Durch eine Aktualisierung oder ein erneutes Prüfen wird der Pfadstatus nicht aktualisiert. Nur ein Neustart aktiviert die Verbindung.
    Dieses Problem wurde in der vorliegenden Version behoben.

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

  • Wenn Sie ein MAI KEYLOK II-USB-Gerät auf CentOS 5.5-, RHEL 5.4-, Ubuntu 9.10- oder Ubuntu 10.04-Betriebssystemen an einen ESX-Host anhängen, können die im Gastbetriebssystem vorhandenen Linux-VMs nicht darauf zugreifen. Das Gerät ist im Gastbetriebssystem sichtbar, es kann jedoch von den Linux-VMs nicht verwendet werden.
    Dieses Problem wurde in der vorliegenden Version behoben.

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

  • Unmittelbar nach dem Upgrade von ESX 3.5 auf Version 4.1 steigt die CPU-Nutzung in der Netware 5.1 Service Pack 8-VM um mehr als 50 Prozent an.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • 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.

  • Warnmeldung während der Skriptinstallation von ESXi 4.1 U2, wenn in der Kickstart-Datei der Befehl "--fstype" angegeben ist
    In früheren Versionen von ESXi 4.1 konnte für Skriptinstallationen von ESXi optional der Befehl --fstypemit dem zugewiesenen Wert vmfs3verwendet werden. Mit dieser Version wurde der Befehl --fstypeaus der Skriptinstallation entfernt. Jetzt wird eine Warnmeldung ähnlich der folgenden angezeigt, wenn Sie den Befehl --fstypein der Kickstart-Datei für die Skriptinstallation angeben:
     
    Warnung:nfs:<host name>/ks.cfg:Zeile xxx: Das Argument "--fstype" für den Befehl "part" hat keinen Wert
     
    Jedoch wird die Installation erfolgreich durchgeführt.

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

  • Wenn Sie den ESX 3.5/4.0-Host über MOB (Managed Object Browser) durchsuchen (Inhalt > HA-Stammordner > HA-Datencenter > HA-Ordner-VM > Auf bestimmten VM-Wert klicken -> Übersicht -> Konfigurieren), statt ihn mit vCenter Server zu verbinden, werden der CPU-Reservierungswert [virtualMachineConfigSummary.cpuReservation]
    und der Arbeitsspeicherreservierungswert [virtualMachineConfigSummary.memoryReservation]für die virtuellen Maschinen als "nicht gesetzt" angezeigt.
    Dieses Problem wird durch das Abrufen der Reservierungsinformationen aus einer Konfigurationsdatei 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

  • Erstellen Sie in vCenter eine neue Windows 2000 Professional-VM. Klonen Sie die virtuelle Maschine mithilfe von vCenter und überprüfen Sie die vmx-Datei der neuen virtuellen Maschine. Als Gastbetriebssystem wird Windows 2000 angezeigt. Die geklonte virtuelle Maschine sollte Windows 2000 Professional als Gastbetriebssystem anzeigen.

    Dieses Problem wurde in der vorliegenden Version behoben. Der Fix tauscht die Einträge für die Betriebssysteme aus.
    .
  • In ESX/ESXi 4.0 zeigt die Leistungsstatistik-Eigenschaft "maxSample" in PerfQuerySpec einen falschen Wert an

  • Wenn Sie die Leistungsstatistik abfragen, gibt die Eigenschaft "maxSample" in PerfQuerySpec anstelle von einem Wert zwei Werte zurück. Dies geschieht auch, nachdem Sie für die "maxSample"-Eigenschaft festgelegt haben, dass sie einen einzigen Wert zurückgeben soll. Dieses Problem wurde in der vorliegenden Version behoben. Die "maxSample"-Eigenschaft zeigt jetzt den richtigen Wert an.
  • Der vSphere-Client zeigt einen falschen Wert für den bereitgestellten Speicherplatz für eine ausgeschaltete virtuelle Maschine an

  • Der ESX-Host berücksichtigt bei der Berechnung des bereitgestellten Speicherplatzes für eine ausgeschaltete virtuelle Maschine die Arbeitsspeicherreservierung nicht. Folglich zeigt der vSphere-Client möglicherweise eine Diskrepanz bei den Werten für den bereitgestellten Speicherplatz an, während die virtuelle Maschine ein- oder ausgeschaltet wird.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • 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

  • Wenn Sie auf mehreren virtuellen Maschinen, die auf zwei ESX-Hosts vorhanden sind, vMotion durchführen, wird der Arbeitsspeicher auf einem ESX-Host überbelegt und die Seitenzuteilung schlägt fehl. Dies führt zu einer Protokollüberflutung mit der folgenden Warnung:
    WARNUNG: vmklinux26: AllocPages: gfp_mask=0xd4, order=0x0, vmk_PktSlabAllocPage gab im VMkernel-Protokoll während vMotion 'Nicht genügend Arbeitsspeicher' zurück
    Dieses Problem wurde in der vorliegenden Version behoben.
  • 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

  • Ein vMotion-Vorgang schlägt möglicherweise mit Fehlermeldungen fehl, die auf gesperrte Auslagerungsdateien im Verzeichnis "workingdir" unter dem NAS-Datenspeicher hinweisen.
    Dieses Problem wurde in der vorliegenden Version behoben. Der Fix in ESX 4.1 Update 2 ruft FSS_OpenFilePath an Stelle von FSS_OpenFile auf und führt zu einer erfolgreichen Migration mit vMotion.

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

  • Wenn Sie auf einer Windows 2008 R2-VM eine dynamische Festplatte hinzufügen und einen stillgelegten Snapshot erstellen, zeigt die Festplattenverwaltung eine Meldung zu einer fehlgeschlagenen oder fehlenden Festplatte an. Dieses Problem tritt bei den folgenden Windows-Betriebssystemen auf.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der Windows HGFS Provider verursacht ein Deadlock, wenn eine Anwendung die WNetAddConnection2-API gleichzeitig von mehreren Threads aus aufruft

  • Die Windows HGFS Provider-Dll führt aufgrund der falschen Provider-Implementierung von Windows WNetAddConnection2- oder WNetCancelConnection-APIs in einer Multi-Threaded-Umgebung zu einem Deadlock für Anwendungen wie eEye Retina.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • 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 (Application Binary Interfaces) mit dem 2.4.21-63-Kernel nicht ordnungsgemäß. Dies führt dazu, dass einige Gerätetreiber, wie z. B. vmxnetund 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 "vmware-config-tools.pl" und "compile" aus. 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 Hardwareversion von ESX von 4 auf 7 durchführen, wird als Gerätestatus der Netzwerkkarte
    "Dieses Hardware-Gerät ist nicht mit dem Computer verbunden (Code 45)"angezeigt.
    Umgehung
    Deinstallieren Sie die Netzwerkkarte und installieren Sie sie erneut. Dadurch wird das Problem behoben.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Installation von VMware Tools auf einer RHEL 2.1-VM schlägt mit einer Fehlermeldung fehl

  • Wenn Sie versuchen, VMware Tools auf einer RHEL 2.1-VM zu installieren, die auf ESX 4.1 ausgeführt wird, indem Sie das Skript vmware-install.plausführen, schlägt der Installationsprozess mit der folgenden Fehlermeldung fehl:
    Neues initrd-Start-Image für den Kernel wird erstellt. Fehler beim Öffnen von /tmp/vmware-fonts2/system_fonts.conf, Ausführung abgebrochen.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • 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

  • Standardmäßig ist der CUPS-Dienst auf einer virtuellen Maschine deaktiviert. Wenn Sie jedoch den VMware Tools-Upgrade-Prozess auf einem SUSE Linux Enterprise Server 10 Service Pack 3 x86-Gastbetriebssystem starten, startet der CUPS-Dienst automatisch. Deaktivieren Sie den CUPS-Dienst in SUSE Linux Enterprise 10 und Red Hat Enterprise Linux 5 mithilfe der folgenden Befehle:
  • Unter SUSE Linux Enterprise 10
  • Führen Sie
    chkconfig --level 2345 cups off
    chkconfig --level 2345 cupsrenice off
    aus und deaktivieren Sie den CUPS-Dienst.
    Überprüfen Sie den Dienststatus mithilfe des Befehls
    service cups status
    chkconfig -l|grep -i cups

    . Stellen Sie sicher, dass der Dienst deaktiviert ist.
  • Unter Red Hat Enterprise Linux 5
  • Führen Sie
    chkconfig --level 2345 cups off
    system-config-servicesaus.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • 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.

  • Wenn ein Peer einer VMCI-Stream-Socket-Verbindung (z. B. ein Stream-Socket-Server, der in einer Server-VM ausgeführt wird) von einem Warteschlangenpaar getrennt wird, während der Verbindungsstatus Verbinden ist, kann der andere Peer (z. B. ein Stream-Socket-Client mit einer Verbindungsblockierung) möglicherweise keine Verbindung herstellen.
    Die Peer-Trennung kann erfolgen, wenn eines der folgenden Ereignisse eintritt:
    Dieses Problem wurde in der vorliegenden Version behoben. Der Fix in ESX 4.1 Update 2 behandelt die Peer-Trennung als ein Zurücksetzen und gibt die folgende Fehlermeldung an den anderen Peer weiter:
    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

  • Unter Windows kann erzwungen werden, dass VirtualAlloc den Arbeitsspeicher von oben nach unten zuteilt, indem der Registrierungsschlüssel "AllocationPreference" wie unter dem folgenden Link angegeben verwendet wird: http://www.microsoft.com/whdc/system/platform/server/PAE/PAEdrv.mspx.
    Auf solchen virtuellen Maschinen schlägt der VMware Tools-Dienst fehl.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der VMware Tools-Dienst (vmtoolsd) schlägt möglicherweise nach der Installation von VMware Tools auf einem Linux-Gastbetriebssystem mit einem langen Betriebssystemnamen fehl

  • Wenn ein Linux-Gastbetriebssystem einen vollständigen Betriebssystemnamen meldet, der länger als 100 Zeichen ist, schlägt der VMware Tools-Dienst möglicherweise fehl. Weitere Informationen finden Sie unter KB 1034633.
    Dieses Problem wurde in der vorliegenden Version behoben. Der Fix erhöht die maximal zulässige Länge des Betriebssystemnamens auf 255 Zeichen.
  • 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.

 

Seitenanfang

Bekannte Probleme

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

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

CIM und API

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

    esxcfg-advcfg-L /UserVars/CIMoemProviderEnabled

  • Konfigurationselemente vom Typ "OEM ProviderEnabled" werden bei einem Upgrade auf ESX 4.1 Update 2 standardmäßig aktiviert *
    Umgehung:
    1. Führen Sie den folgenden Befehl aus, um OEM-Anbieter zu deaktivieren:
      esxcfg-advcfg -s 0 /UserVars/CIMoem-<originalname>ProviderEnabled
    2. Starten Sie den Dienst sfcbdneu, indem Sie den folgenden Befehl ausführen:
        /etc/init.d/sfcbd-watchdog restart
  • SFCC-Bibliothek legt die SetBIOSAttribute-Methode in der generierten XML-Datei nicht fest
    Wenn die SFCC-Bibliothek (SFCC; Small Footprint CIM Client) versucht, die
    SetBIOSAttribute -Methode der CIM_BIOSService -Klasse über SFCC auszuführen, wird von SFCC eine XML-Datei mit der folgenden Fehlermeldung zurückgegeben: ERROR CODE="13" DESCRIPTION="The value supplied is incompatible with the type" . Dieses Problem tritt auf, wenn die alte SFCC-Bibliothek das Festlegen des Methodenparametertyps in der generierten XML-Datei nicht unterstützt. Aufgrund dieses Problems können Sie die SetBIOSAttribute-Methode nicht aufrufen. Die SFCC-Bibliothek in ESXi 4.1-Hosts legt den Methodenparametertyp in der generierten Socket-Stream-XML-Datei nicht fest.

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

Gastbetriebssystem

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

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

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

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

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


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

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

Sonstige Probleme

  • Ausführen von "resxtop" oder "esxtop" über einen längeren Zeitraum hat möglicherweise Arbeitsspeicherprobleme zur Folge
    Die Arbeitsspeichernutzung durch
    resxtop oder esxtop nimmt möglicherweise mit der Zeit zu, abhängig davon, was auf dem überwachten ESXi-Host geschieht. Dies bedeutet, dass sich resxtop oder esxtop bei Verwendung einer Standardverzögerung von 5 Sekunden zwischen zwei Anzeigen möglicherweise nach etwa 14 Stunden selbst abschaltet.

    Umgehung: Obwohl Sie die Option -nverwenden können, um die Gesamtzahl an Wiederholungen zu ändern, sollten Sie in Betracht ziehen, resxtopnur dann auszuführen, wenn Sie die Daten benötigen. Falls Sie resxtop- oder esxtop-Statistiken über einen längeren Zeitraum hinweg erfassen müssen, beenden Sie resxtopoder esxtopin regelmäßigen Abständen und starten Sie es neu, statt eine resxtop- oder esxtop-Instanz über Wochen oder Monate auszuführen.
  • Gruppen-ID-Länge in vSphere-Client ist kürzer als Gruppen-ID-Länge in vCLI
    Wenn Sie eine Gruppen-ID mithilfe des vSphere-Clients angeben, sind nur neun Zeichen erlaubt. Dagegen können Sie bis zu zehn Zeichen angeben, wenn Sie die Gruppen-ID mithilfe von
    vicfg-user vCLI angeben.

    Umgehung: Keine


  • Eine Warnmeldung wird angezeigt, wenn Sie den Befehl "esxcfg-pciid" ausführen
    Wenn Sie versuchen, den Befehl esxcfg-pciidauszuführen, um die Ethernet-Controller und -Adapter aufzulisten, wird möglicherweise eine Warnmeldung ähnlich der folgenden angezeigt:
    Vendor short name AMD Inc does not match existing vendor name Advanced Micro Devices [AMD]
    kernel driver mapping for device id1022:7401 in /etc/vmware/pciid/pata_amd.xml conflicts with definition for unknown
    kernel driver mapping for device id 1022:7409 in /etc/vmware/pciid/pata_amd.xml conflicts with definition for unknown
    kernel driver mapping for device id 1022:7411 in /etc/vmware/pciid/pata_amd.xml conflicts with definition for unknown
    kernel driver mapping for device id 1022:7441 in /etc/vmware/pciid/pata_amd.xml conflicts with definition for unknown


    Dieses Problem tritt auf, wenn sowohl die Plattformgeräte-Deskriptordateien als auch die treiberspezifischen Deskriptordateien Beschreibungen für dasselbe Gerät enthalten.

    Umgehung: Sie können diese Warnmeldung ignorieren.
  • Hinzufügen eines ESXi 4.1 Update 1 Embedded-Hosts zu Cisco Nexus 1000V Release 4.0(4)SV1(3a) schlägt fehl
    Möglicherweise können Sie über vCenter Server keinen ESXi 4.1 Update 1 Embedded-Host zu Cisco Nexus 1000V Release 4.0(4)SV1(3a) hinzufügen.

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

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

Speicher

  • iSCSI kann nicht über Netzwerkkarte mit langem logischen Gerätenamen konfiguriert werden
    Bei Ausführung des Befehls
    esxcli swiscsi nic add -n von einer vSphere-Befehlszeilenschnittstelle (vCLI) aus wird iSCSI über keine VMkernel-Netzwerkkarte konfiguriert, deren logischer Gerätename 8 Zeichen überschreitet. Netzwerkkartentreiber von Drittanbietern, die vmnic- und vmknic-Namen mit mehr als 8 Zeichen verwenden, funktionieren nicht mit der iSCSI-Port-Bindungs-Funktion in ESXi-Hosts und geben möglicherweise Ausnahmefehlermeldungen in der Remotebefehlszeilenschnittstelle aus. Befehle wie z. B. esxcli swiscsi nic list, esxcli swiscsi nic add, esxcli swiscsi vmnic list , die von der vCLI-Schnittstelle aus gestartet werden, schlagen fehl, weil sie von Drittanbietertreibern erstellte lange vmnic-Namen nicht handhaben können.

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


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

    Umgehung: Ändern Sie zum Beheben dieses Problems und zum Beschleunigen des Startvorgangs den Zeitüberschreitungswert für synchrone Befehle während des Startvorgangs auf 10 Sekunden, indem Sie den Parameter Scsi.CRTimeoutDuringBootauf 10000 festlegen.

    So Ändern Sie den Parameter vom vSphere-Client aus:
    1. Wählen Sie im Bestandslistenbereich des vSphere-Client den Host, klicken Sie auf die Registerkarte Konfiguration und anschließend unter "Software" auf Erweiterte Einstellungen.
    2. Wählen Sie SCSI.
    3. Ändern Sie den Parameter Scsi.CRTimeoutDuringBootauf 10000.

Unterstützte Hardware

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

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


    Umgehung: Aktualisieren Sie das BIOS auf 2010.05.21 oder eine spätere Version.
  • ESXi-Installationen auf HP-Systemen benötigen den HP-NMI-Treiber
    ESXi 4.1-Instanzen auf HP-Systemen benötigen den HP-NMI-Treiber, um die ordnungsgemäße Verarbeitung von Non-maskable Interrupts (NMIs) sicherzustellen. Der NMI-Treiber stellt sicher, dass NMIs korrekt erkannt und protokolliert werden. Ohne den Treiber werden NMIs, die Hardwarefehler signalisieren, auf HP-Systemen, die ESXi 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".
  • ESXi auf der HP G6-Plattform mit P410i oder P410 Smart Array-Controller läuft während des Einschaltens der virtuellen Maschinen oder bei Festplatten-E/A-Vorgängen langsam
    Einige Hosts laufen möglicherweise beim Einschalten von virtuellen Maschinen oder bei Festplatten-E/A-Vorgängen langsam. Das Hauptsymptom ist eine herabgestufte E/A-Leistung, wodurch viele Fehlermeldungen ähnlich der folgenden in /var/log/messagesprotokolliert werden:

    Mar 25 17:39:25 vmkernel: 0:00:08:47.438 cpu1:4097)scsi_cmd_alloc returned NULL
    Mar 25 17:39:25 vmkernel: 0:00:08:47.438 cpu1:4097)scsi_cmd_alloc returned NULL
    Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)NMP: nmp_CompleteCommandForPath: Command 0x28 (0x410005060600) to NMP device
    "naa.600508b1001030304643453441300100" failed on physical path "vmhba0:C0:T0:L1" H:0x1 D:0x0 P:0x0 Possible sense data: 0x
    Mar 25 17:39:26 0 0x0 0x0.
    Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)WARNING: NMP: nmp_DeviceRetryCommand: Device
    "naa.600508b1001030304643453441300100": awaiting fast path state update for failoverwith I/O blocked. No prior reservation
    exists on the device.
    Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)NMP: nmp_CompleteCommandForPath: Command 0x28 (0x410005060700) to NMP device
    "naa.600508b1001030304643453441300100" failed on physical path "vmhba0:C0:T0:L1" H:0x1 D:0x0 P:0x0 Possible sense data: 0x
    Mar 25 17:39:26 0 0x0 0x0


    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

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

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

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

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

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

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

  • Die Installation des vSphere-Clients schlägt möglicherweise mit einem Fehler fehl
    Wenn Sie den vSphere-Client installieren, kann es sein, dass das Installationsprogramm versucht, eine veraltete Laufzeitumgebung für Microsoft Visual J# zu aktualisieren. Das Upgrade schlägt fehl und auch die Installation des vSphere-Clients schlägt mit folgendem Fehler fehl: Das Installationsprogramm von Microsoft Visual J# 2.0 Second Edition gibt den Fehlercode 4113 zurück.

    Umgehung: Deinstallieren Sie alle früheren Versionen von Microsoft Visual J# und installieren Sie anschließend den vSphere-Client. Das Installationsprogramm enthält ein aktualisiertes Microsoft Visual J#-Paket.
  • Der gleichzeitige Zugriff auf zwei ESXi-Installationen auf USB-Flash-Laufwerken führt zu Panikmeldungen
    Wenn Sie ein System starten, das Zugriff auf mehrere Installationen von ESXi mit der gleichen Build-Nummer auf zwei unterschiedlichen USB-Flash-Laufwerken hat, werden Panikmeldungen angezeigt.

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

vMotion und Storage vMotion

  • vMotion ist nach einem Neustart des ESXi 4.1-Hosts deaktiviert
    Wenn Sie vMotion auf einem ESXi-Host aktivieren und den ESXi-Host neu starten, ist vMotion nach demNeustart nicht mehr aktiviert.


    Umgehung: Um das Problem zu beheben, installieren Sie die neueste von Ihrem Systemanbieter bereitgestellte Version des ESXi-Images erneut.

  • Hot-Plug-Vorgänge schlagen nach dem Verlagern der Auslagerungsdatei fehl
    Hot-Plug-Vorgänge schlagen bei eingeschalteten virtuellen Maschinen in einem DRS-Cluster bzw. auf einem eigenständigen Host mit der Fehlermeldung Ziel konnte nicht fortgesetzt werden; VM wurde nicht gefundenfehl, nachdem der Speicherort der Auslagerungsdatei geändert wurde.

    Umgehung: Führen Sie eine der folgenden Aufgaben aus:
    • Starten Sie die betroffenen virtuellen Maschinen neu, um den neuen Speicherort der Auslagerungsdatei für diese Maschinen zu registrieren, und führen Sie anschließend die Hot-Plug-Vorgänge aus.
    • Migrieren Sie die betroffenen virtuellen Maschinen mithilfe von vMotion.
    • Halten Sie die betroffenen virtuellen Maschinen an.

VMware Tools

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

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

  • 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