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

Letzte Dokumentaktualisierung: 27. Okt. 2011

Diese Versionshinweise decken die folgenden Themen ab:

Neuigkeiten

Sie erhalten nachstehend Informationen zu einigen der Verbesserungen in der vorliegenden Version von VMware ESX:

  • Unterstützung für neue Prozessoren — ESX 4.1 Update 2 unterstützt die AMD Opteron 6200-Serie (Interlagos) und die AMD Opteron 4200-Serie (Valencia).

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

Behobene Probleme Diese Version enthält darüber hinaus verschiedene Fehlerkorrekturen, die im Abschnitt Behobene Probleme dokumentiert sind.

Seitenanfang

Vorherige Versionen von ESX 4.1

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

Seitenanfang

Bevor Sie beginnen

ESX, vCenter Server und vSphere-Client – Versionskompatibilität

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

ESX, vCenter Server und VDDK-Kompatibilität

Virtual Disk Development Kit (VDDK) 1.2.1 bietet Unterstützung für ESX 4.1 Update 2 und vCenter Server 4.1 Update 2. Weitere Informationen zu VDDK finden Sie unter https://www.vmware.com/support/developer/vddk/.

Hardwarekompatibilität

  • Erfahren Sie mehr über Hardwarekompatibilität

    Sie finden die Hardwarekompatibilitätslisten im webbasierten Kompatibilitätshandbuch. Das webbasierte Kompatibilitätshandbuch stellt eine zentrale Quelle für alle VMware-Kompatibilitätshandbücher dar und bietet die Möglichkeit zur Suche in den Handbüchern und zum Speichern der Suchergebnisse im PDF-Format. Anhand dieses Handbuchs können Sie z. B. sicherstellen, dass Server, E/A, Speicher und Gastbetriebssysteme kompatibel sind.

    Registrieren Sie sich hier, um über Updates zum Kompatibilitätshandbuch benachrichtigt zu werden: Dies ist das RSS-Bild, das als Link auf einen RSS-Feed dient.

  • Erfahren Sie mehr über die vSphere-Kompatibilität:

    VMware vSphere-Kompatibilitätstabellen ( PDF)

Installation und Upgrade

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

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

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

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

Durchführen eines Upgrades der VMware Tools

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

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

Upgrade oder Migration auf ESX 4.1 Update 2

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

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

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

Upgrade-Typ

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

ESX 3.5 Update 5a

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

ESX 4.1

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

Ja

Nein

Nein

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

Nein

Ja

Nein

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

Anmerkungen:

In dieser Version enthaltene Patches

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

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

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

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

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

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

Behobene Probleme

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

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

Sicherung

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

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

  • Wenn Sie den Hardwarestatus
    (Home > Bestandsliste > Hosts und Cluster > Hardwarestatus > CPU/Arbeitsspeicher)
    eines ESXi-Hosts auf dem über vCenter 4.1 verbundenen HP DL980 G7-Server überprüfen, 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.

Gastbetriebssystem

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

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

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

Sonstige Probleme

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

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

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

  • 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.
  • ESX-Hosts schlagen mit einem violetten Diagnosebildschirm fehl, wenn Sie 'less /proc/scsi/*/*'über die Servicekonsole ausführen

  • Wenn Sie `less /proc/scsi/*/*` über die Konsole ausführen, werden einige SCSI-Treiber aus Linux portiert. Diese Treiber fügen unter /proc/scsi/Einträge hinzu und schreiben mehr Zeichen, als der Kernel angefordert hatte, was zu einer Beschädigung des Arbeitsspeichers führt. Dies verursacht ein Fehlschlagen des ESX-Hosts mit einem violetten Diagnosebildschirm.
    Dieses Problem wurde in der vorliegenden Version 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.
  • Der megaraid_sas-Treiber wurde von Version 4.0.14.1-18 auf Version 5.30 aktualisiert

  • Der megaraid_sas-Treiber wurde von Version 4.0.14.1-18 auf Version 5.30 aktualisiert. Das Upgrade fügt 11 neue PCI-IDs zum megaraid_sas-Treiber hinzu. Das Upgrade behebt die iMR-Chip- und gen2-Chip-Probleme.
    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.

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

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

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

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

Bekannte Probleme

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

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

Sicherung

  • VCB-Servicekonsolenbefehle generieren Fehlermeldungen in der ESX-Servicekonsole
    Wenn Sie VCB-Servicekonsolenbefehle in der Servicekonsole von ESX-Hosts ausführen, wird möglicherweise eine Fehlermeldung ähnlich der folgenden angezeigt:
    Closing Response processing in unexpected state:3 . Sie können diese Meldung ignorieren. Die Meldung hat keinen Einfluss auf die Ergebnisse der VCB-Servicekonsolenbefehle.

    Umgehung: Keine.

CIM und API

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

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

Gastbetriebssystem

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

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

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

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

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


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

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

Sonstiges

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

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

    Umgehung: Keine


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


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

    Umgehung: Sie können diese Warnmeldung ignorieren.

Netzwerk

  • Netzwerkverbindungsausfall und Systemfehler bei der Ausführung von Steuerungsvorgängen für physische Netzwerkkarten
    In manchen Fällen, wenn mehrere X-Frame II s2io-Netzwerkkarten denselben PCI-X-Bus verwenden, verursacht die Ausführung von Steuerungsvorgängen für die physische Netzwerkkarte, wie z. B. das Ändern der MTU, eine Trennung der Netzwerkverbindung und einen Systemabsturz.

    Umgehung: Vermeiden Sie, mehrere X-Frame II s2io-Netzwerkkarten in Steckplätze zu stecken, die sich denselben PCI-X-Bus teilen. Falls eine solche Konfiguration unumgänglich ist, vermeiden Sie es, Kontrollvorgänge an physischen Netzwerkkarten durchzuführen, während in den virtuellen Maschinen Netzwerk-E/A-Vorgänge stattfinden.
  • Beim Weiterleiten von Datenpaketen (Traffic-Forwarding) virtueller Maschinen mit aktivierter LRO treten möglicherweise TCP-Performance-Probleme auf
    Einige Linux-Module können LRO-generierte Pakete nicht handhaben. Infolgedessen kann es zu TCP-Performance-Problemen bei einer Datenverkehr weiterleitenden virtuellen Maschine kommen, wenn LRO an einem VMXNET2- bzw. VMXNET3-Gerät aktiviert und Linux als Gastbetriebssystem ausgeführt wird. Bei diesen Geräten ist LRO standardmäßig aktiviert.

    Umgehung: Konfigurieren Sie für Datenverkehr weiterleitende virtuelle Maschinen mit Linux-Gastbetriebssystemen den Modulladezeit-Parameter für die VMXNET2 - bzw. VMXNET3 -Linux-Treiber so, dass disable_lro=1 verwendet wird.
  • Es treten Arbeitsspeicherprobleme auf, wenn ein Host mehr als 1016 dvPorts an einem vDS verwendet
    Die maximal zulässige Anzahl an dvPorts pro Host am vDS ist zwar 4096, es kann aber zu Arbeitsspeicherproblemen kommen, sobald sich die Zahl der dvPorts für einen Host 1016 nähert. Ist dies der Fall, können keine virtuellen Maschinen bzw. virtuellen Adapter mehr zum vDS hinzugefügt werden.

    Umgehung: Konfigurieren Sie eine Maximalzahl von 1016 dvPorts pro Host an einem vDS.
  • Das Neukonfigurieren der VMXNET3-Netzwerkkarte führt möglicherweise dazu, dass die virtuelle Maschine fortgesetzt wird
    Das Neukonfigurieren einer VMXNET3-Netzwerkkarte bei aktiviertem Wake-on-LAN und während sich die virtuelle Maschine im Ruhezustand befindet, führt dazu, dass die virtuelle Maschine fortgesetzt wird.

    Umgehung: Versetzen Sie die virtuelle Maschine nach der Neukonfiguration einer VMXNET3 vNIC manuell in den Ruhezustand (beispielsweise nachdem Sie ein Hot-Add oder Hot-Remove ausgeführt haben).
  • Zuletzt erstellte VMkernel und Netzwerkadapter für Servicekonsole verschwinden nach dem Aus- und Wiedereinschalten
    Wenn ein ESX-Host innerhalb einer Stunde nach dem Erstellen eines neuen VMKernels bzw. eines Servicekonsolenadapters auf einem vDS aus- und wiedereingeschaltet wird, kann es sein, dass der neue Adapter verschwindet.

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

Speicher

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

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


  • Große Anzahl speicherrelevanter Meldungen in der VMkernel-Protokolldatei
    Wenn ESX auf einem Host mit mehreren physischen Pfaden zu Speichergeräten startet, zeichnet die VMkernel-Protokolldatei eine große Anzahl von speicherrelevanten Meldungen ähnlich der folgenden auf:

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

    Umgehung: Wenn Sie die Meldungen nicht sehen möchten, schalten Sie die Protokollierung aus.
  • Dauerhafte Reservierungskonflikte auf gemeinsam genutzten LUNs können zum verlangsamten Starten von ESX-Hosts führen
    Es kann zu erheblichen Verzögerungen beim Starten der Hosts kommen, die LUNs auf einem SAN gemeinsam nutzen. Das kann seine Ursache in Konflikten zwischen den LUN SCSI-Reservierungen haben.

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

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

Serverkonfiguration

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

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

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

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

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

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


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

          Umgehung: Laden Sie den NMI-Treiber herunter und installieren Sie ihn. Der Treiber steht als Offline-Paket auf der HP-Website zur Verfügung. Siehe zudem KB 1021609 unter http://kb.vmware.com/kb/1021609.
        • Virtuelle Maschinen werden möglicherweise schreibgeschützt, wenn sie auf einem iSCSI-Datenspeicher mit EqualLogic-Speicher laufen
          Virtuelle Maschinen werden möglicherweise auf schreibgeschützt gesetzt, wenn Sie ein EqualLogic-Array mit einer späteren Firmware-Version verwenden. Die Firmware verliert möglicherweise gelegentlich E/A aus der Array-Warteschlange, was die virtuellen Maschinen veranlasst, auf Nur-Lesen zu wechseln, nachdem die E/A als fehlgeschlagen gekennzeichnet wurde.


          Umgehung: Aktualisieren Sie die EqualLogic Array Firmware auf Version 4.1.4 oder höher.
        • Nach dem Upgrade des Speicher-Arrays wechselt der Status der Hardwarebeschleunigung im vSphere-Client nach kurzer Verzögerung auf "Unterstützt"
          Beim Aktualisieren der Firmware eines Speicher-Arrays auf eine Version, die die VAAI-Funktionalität unterstützt, registriert vSphere 4.1 die Änderung nicht sofort. Der vSphere-Client zeigt vorübergehend "Unbekannt" als Status für die Hardwarebeschleunigung an.


          Umgehung: Diese Verzögerung ist unbedenklich. Der Status der Hardwarebeschleunigung ändert sich nach kurzer Zeit auf "Unterstützt".
        • ESX auf der HP G6-Plattform mit P410i oder P410 Smart Array-Controller läuft während des Einschaltens der virtuellen Maschinen oder bei Festplatten-E/A-Vorgängen langsam
          Einige Hosts laufen möglicherweise beim Einschalten von virtuellen Maschinen oder bei Festplatten-E/A-Vorgängen langsam. Das Hauptsymptom ist eine herabgestufte E/A-Leistung, wodurch viele Fehlermeldungen ähnlich der folgenden in
          /var/log/messages protokolliert werden:
          Mar 25 17:39:25 vmkernel: 0:00:08:47.438 cpu1:4097)scsi_cmd_alloc returned NULL
          Mar 25 17:39:25 vmkernel: 0:00:08:47.438 cpu1:4097)scsi_cmd_alloc returned NULL
          Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)NMP: nmp_CompleteCommandForPath: Command 0x28 (0x410005060600) to NMP device
          "naa.600508b1001030304643453441300100" failed on physical path "vmhba0:C0:T0:L1" H:0x1 D:0x0 P:0x0 Possible sense data: 0x
          Mar 25 17:39:26 0 0x0 0x0.
          Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)WARNING: NMP: nmp_DeviceRetryCommand: Device
          "naa.600508b1001030304643453441300100": awaiting fast path state update for failoverwith I/O blocked. No prior reservation
          exists on the device.
          Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)NMP: nmp_CompleteCommandForPath: Command 0x28 (0x410005060700) to NMP device
          "naa.600508b1001030304643453441300100" failed on physical path "vmhba0:C0:T0:L1" H:0x1 D:0x0 P:0x0 Possible sense data: 0x
          Mar 25 17:39:26 0 0x0 0x0


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

        Upgrade und Installation

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

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

          Umgehung: Deinstallieren Sie alle früheren Versionen von Microsoft Visual J# und installieren Sie anschließend den vSphere-Client. Das Installationsprogramm enthält ein aktualisiertes Microsoft Visual J#-Paket.

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

          Sie können die Meldungen ignorieren.

          Umgehung:Starten Sie den ESX 4.1 Update 1-Host neu.

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

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

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

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

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

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

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

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

        vMotion und Storage vMotion

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

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

        vMotion und Storage vMotion

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

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

        VMware Tools

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

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

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


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

        Seitenanfang