Versionshinweise zu ESXi 4.1 Update 2

Kontakt zum Vertrieb
 

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


    • 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 ESXi-Host zeigt als Arbeitsspeichertyp "Unbekannt" an

    • Unbekannt

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


    • Fehler -1: Der VM-Prozess konnte nicht gestartet werden. Der Peer-Prozess konnte nicht gestartet werden.

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.


  • 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


  • 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


  • 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

    • [virtualMachineConfigSummary.cpuReservation]
    [virtualMachineConfigSummary.memoryReservation]

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

 

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