ESX 4.0 Update 2 | 10. Juni 2010 | Build 261974 VMware Tools | 10. Juni 2010 | Build 261974 Letzte Dokumentaktualisierung: 24. Juni 2010 |
Diese Versionshinweise decken die folgenden Themen ab:
Neuigkeiten
Sie erhalten nachstehend Informationen zu einigen der wichtigsten Verbesserungen in der vorliegenden Version von VMware ESX:
- Aktivierung der Fehlertoleranz für Intel Xeon 56xx Series-Prozessoren – vSphere 4.0 Update 1 unterstützt Intel Xeon 56xx Series-Prozessoren ohne Fehlertoleranz. vSphere 4.0 Update 2 aktiviert die Fehlertoleranz für Intel Xeon 56xx Series-Prozessoren.
- Aktivierung der Fehlertoleranz für Intel i3/i5 Clarkdale-Series- und Intel Xeon 34xx Clarkdale-Series-Prozessoren – vSphere 4.0 Update 1 unterstützt Intel i3/i5 Clarkdale-Series- und Intel Xeon 34xx Clarkdale-Series-Prozessoren ohne Fehlertoleranz. vSphere 4.0 Update 2 aktiviert die Fehlertoleranz für Intel i3/i5 Clarkdale-Series- und Intel Xeon 34xx Clarkdale-Series-Prozessoren.
- Aktivierung der IOMMU-Funktion für AMD Opteron 61xx und 41xx Series-Prozessoren –vSphere 4.0 Update 1 unterstützt AMD Opteron 61xx und 41xx Series-Prozessoren ohne E/A-Arbeitsspeicherverwaltungseinheit (IOMMU). vSphere 4.0 Update 2 aktiviert die IOMMU-Funktion für AMD Opteron 61xx und 41xx Series-Prozessoren.
- Verbesserung der Dienstprogramme "esxtop" und "resxtop" – vSphere 4.0 Update 2 enthält eine Verbesserung der Leistungsüberwachungsdienstprogramme esxtopund resxtop. Die Dienstprogramme esxtop/ resxtopbieten nun eine größere Transparenz hinsichtlich der Leistung von NFS-Datenspeichern, indem für den NFS-Datenspeicher folgende Statistiken angezeigt werden: Reads/s, writes/s, MBreads/s, MBwrtn/s, cmds/s, GAVG/s(Latenz des Gastbetriebssystems).
- Zusätzliche Unterstützung für Gastbetriebssysteme – ESX/ESXi 4.0 Update 2 bietet nun Unterstützung für Ubuntu 10.04. Eine vollständige Liste der von dieser Version unterstützten Gastbetriebssysteme finden Sie im VMware-Kompatibilitätshandbuch .
Behobene Probleme –Diese Version enthält darüber hinaus verschiedene Fehlerkorrekturen, die im Abschnitt Behobene Probleme dokumentiert sind.
Seitenanfang
Vorherige Versionen von ESX 4.0
Die Funktionen und bekannten Probleme der vorherigen Versionen von ESX 4.0 werden in den Versionshinweisen für die jeweilige Version beschrieben. Wenn Sie Versionshinweise früherer Versionen von ESX 4.0 anzeigen möchten, klicken Sie auf einen der folgenden Links:
Seitenanfang
Bevor Sie beginnen
ESX, vCenter Server und vSphere-Client – Versionskompatibilität
Die VMware vSphere-Kompatibilitätstabellen liefern Details zur Kompatibilität aktueller und früherer Versionen von VMware vSphere-Komponenten, einschließlich ESX, vCenter Server, vSphere-Client und anderer VMware-Produkte.
Hardwarekompatibilität
- Erfahren Sie mehr über Hardwarekompatibilität
Die Listen zur Hardwarekompatibilität stehen in dem webbasierten Kompatibilitätshandbuch unter http://www.vmware.com/resources/compatibility zur Verfügung. 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 des Handbuchs können Sie z. B. sicherstellen, dass Server, E/A, Speicher und Gastbetriebssysteme kompatibel sind.
Registrieren Sie sich hier, um über Updates zum Kompatibilitätshandbuch benachrichtigt zu werden:
- Erfahren Sie mehr über die vSphere-Kompatibilität:
Kompatibilitätstabellen für VMware vSphere ( PDF)
Dokumentation
Die Dokumentation für VMware vSphere 4.0 Update 1 wurde aktualisiert und gilt für alle Update-Versionen von vSphere 4.0, einschließlich VMware vSphere 4.0 Update 2. Weitere Informationen hierzu finden Sie auf der Dokumentationsseite ESX 4.0 Update 1 und höher mit vCenter Server 4.0 Update 1 und höher.
Installation und Upgrade
Detaillierte und Schritt-für-Schritt-Anweisungen zu Installation und Konfiguration von ESX und vCenter Server finden Sie im Installationshandbuch – ESX und vCenter Server .
Nach Abschluss der Installation sind einige Konfigurationsschritte erforderlich. Insbesondere sind Lizenzierungs-, Netzwerk- und Sicherheitskonfigurationen erforderlich. Beachten Sie die folgenden Handbücher in der vSphere-Dokumentation für weitere Informationen zu diesen Konfigurationsaufgaben.
Künftige Versionen von VMware vSphere werden möglicherweise VMFS Version 2 (VMFS2) nicht unterstützen. Es wird empfohlen, auf VMFS Version 3 oder höher zu Upgrade bzw. zu migrieren. Weitere Informationen finden Sie im vSphere-Upgrade-Handbuch .
Die Installation von künftigen Versionen von VMware vCenter Server auf 32-Bit-Windows-Betriebssystemen wird möglicherweise nicht unterstützt. Sie sollten vCenter Server auf einem 64-Bit-Windows-Betriebssystem installieren. 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 speziell 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://www.vmware.com/download heruntergeladen werden.
Duchführen eines Upgrades der VMware Tools
VMware ESX 4.0 Update 2 setzt ein Upgrade von VMware Tools voraus. Die VMware Tools sind 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 den VMware Tools behoben wurden, finden Sie unter Behobene Probleme für VMware Tools.
Das VMware Tools-RPM-Installationsprogramm, das auf dem VMware Tools-ISO-Image für Linux-Gastbetriebssysteme zur Verfügung steht, ist veraltet. Es wird in einer künftigen ESX-Version entfernt. Es wird empfohlen, das tar.gz-Installationsprogramm zum Installieren der VMware Tools auf virtuellen Maschinen mit Linux-Gastbetriebssystemen zu verwenden.
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.0 Update 2
ESX 4.0 Update 2 bietet die folgenden Optionen für das Upgrade:
- vSphere Host Update Utility – Für eigenständige ESX 3.x-Hosts. Ein eigenständiger Host ist ein ESX/ESXi-Host, der nicht von vCenter Server verwaltet wird. Weitere Informationen zu Upgrades mit vSphere Host Update Utility finden Sie im vSphere-Upgrade-Handbuch .
- VMware vCenter Update Manager – Für von vCenter Server verwaltete ESX/ESXi-Hosts. Weitere Informationen finden Sie im Administratorhandbuch zu VMware vCenter Update Manager.
- esxupgrade.sh script – Für ESX 3.x-Hosts, die über keinen Netzwerkzugriff verfügen. Weitere Informationen finden Sie unter Durchführen eines Offline-Upgrades von ESX 3.x auf ESX 4.x (KB 1009440). Sofern der Host über Netzwerkzugriff verfügt, können Sie zum Durchführen des Upgrades das vSphere Host Update Utility oder den VMware vCenter Update Manager verwenden.
- Befehl "vihostupdate" der VMware vSphere-Befehlszeilenschnittstelle (vSphere CLI) – Das Befehlszeilenprogramm vihostupdateder vSphere CLI wendet Software-Updates auf ESX/ESXi 4.0-Hosts an und installiert und aktualisiert ESX/ESXi-Erweiterungen wie VMkernel-Module, Treiber und CIM-Anbieter. Weitere Informationen hierzu finden Sie im vSphere-Upgrade-Handbuch.
- esxupdate-Befehlszeilenprogramm– Nur für ESX. Es wendet Software-Updates auf ESX 4.0.X-Hosts an. Weitere Informationen hierzu finden Sie im Handbuch für die Patch-Verwaltung .
Mehrere Upgrade-Tools, die in vorherigen ESX-Versionen unterstützt wurden, werden in der aktuellen Version nicht mehr unterstützt. Zu diesen Tools gehören das grafische Upgrade von CD, das Upgrade im Textmodus von CD, das tarball-Upgrade unter Verwendung der Servicekonsole, das skriptbasierte Upgrade von CD oder dem PXE-Server unter Verwendung von esxupdateund das skriptbasierte Upgrade von CD oder dem PXE-Server unter Verwendung von Kickstart-Befehlen. vSphere Host Update Utility und VMware Update Manager sind die einzigen unterstützten Tools zur Durchführung von Upgrades von ESX 3.5.x auf ESX 4.0.
Unterstützte Upgrade-Pfade für das Host-Upgrade auf ESX 4.0 Update 2:
Upgrade-Typ |
ESX Server 3.5 enthält: Update 1 Update 2 Update 3 Update 4 Update 5 Update 5a |
ESX 4.0 |
ESX 4.0 Update 1 |
ISO-Image |
Ja |
Nein |
Nein |
Offline-Paket für ESX 4.0 Update 2 |
Nein |
Ja |
Ja |
Hinweise:
- Unterstützte Upgrade-Vorgehensweise unter Verwendung eines ISO-Images sind vSphere Host Update Utility 4.0 Update 2, vCenter Update Manager 4.0 Update 2 und esxupgrade.sh.Weitere Informationen finden Sie unter Durchführen eines Offline-Upgrades von ESX 3.x auf ESX 4.x (KB 1009440). Weitere Informationen hierzu finden Sie im vSphere-Upgrade-Handbuch .
- Unterstützte Upgrade-Vorgehensweise unter Verwendung des ESX 4.0 Update 2 Offline-Pakets sind der Befehl vihostupdateder vSphere-CLI und das Befehlszeilendienstprogramm esxupdate. Weitere Informationen hierzu finden Sie im vSphere-Upgrade-Handbuch und im Handbuch für die Patch-Verwaltung.
- Aktualisieren Sie beim Upgrade von ESX Server 3.0.x zunächst auf eine höhere Version von ESX Server 3.5.x und anschließend mithilfe eines ISO-Images auf ESX 4.0 Update 2. Weitere Informationen hierzu finden Sie in einem der 3.5.x Upgrade-Handbücher, wie z. B. in folgendem Upgrade-Handbuch: Update 2 und höher für ESX Server 3.5, ESX Server 3i Version 3.5, VirtualCenter 2.5.
- Sie können ESX 2.5.5 auf ESX 4.0 Update 2 Upgrade, indem Sie die virtuellen Maschinen verschieben. Weitere Informationen finden Sie im vSphere-Upgrade-Handbuch .
- Informationen zum Aktualisieren des ESX 4.0-Hosts auf ESX 4.0 Update 2 mithilfe von Online-Patches und vCenter Update Manager 4.0 Update 2 finden Sie im Abschnitt zu den Patches in diesen Versionshinweisen, im vSphere-Upgrade-Handbuch und im Administratorhandbuch zu VMware vCenter Update Manager .
Aktualisierte RPMs und Sicherheits-Fixes
Eine Liste der in ESX 4.0 Update 2 aktualisierten RPMs finden Sie unter Aktualisierte RPMs und Sicherheits-Fixes . Dieses Dokument gilt nicht für die ESXi-Produkte.
Seitenanfang
In dieser Version enthaltene Patches
Diese Version enthält alle Bulletins für die ESX Server-Software, die vor dem Veröffentlichungsdatum dieses Produkts zur Verfügung standen. Weitere Informationen zu den einzelnen Bulletins erhalten Sie auf der Seite zum Herunterladen von Patches von VMware oder indem Sie auf den Namen eines Bulletins klicken.
Patch-Version ESX400-Update02 enthält die folgenden einzelnen Bulletins:
ESX400-201006201-UG: Führt ein Update der VMware ESX 4.0-Kernkomponenten und der CIM-Komponenten durch
ESX400-201006202-UG: Führt ein Update der VMware ESX 4.0 mpt2sas-Gerätetreiber durch
ESX400-201006203-UG: Führt ein Update der VMware ESX 4.0 mptsas-, mptspi-Gerätetreiber durch
ESX400-201006204-UG: Führt ein Update der VMware ESX 4.0 fnic-Gerätetreiber durch
ESX400-201006205-UG: Führt ein Update der ESX 4.0 SCSI/iSCSI-Treiber durch
ESX400-201006206-UG: Führt ein Update der VMware ESX 4.0 ixgbe-Gerätetreiber durch
ESX400-201006207-UG: Führt ein Update der ESX 4.0 Intel igb-Treiber durch
ESX400-201006208-UG: Führt ein Update der ESX 4.0 USB-Speicherkomponente durch
ESX400-201006209-UG: Führt ein Update des ESX 4.0 qlogic SCSI-Treibers durch
ESX400-201006211-UG: Führt ein Update des VMware ESX 4.0 nx-nic-Gerätetreibers durch
ESX400-201006212-UG: Führt ein Update des VMware ESX 4.0 bnx2x-Gerätetreibers durch
ESX400-201006214-UG: Führt ein Update des VMware ESX 4.0 cciss-Gerätetreibers durch
ESX400-201006215-UG: Führt ein Update des Treibers für die VMware ESX 4.0 HP SAS-Controller durch
ESX400-201006217-UG: Führt ein Update der ESX 4.0 python-Komponente durch
ESX400-201006218-UG: Führt ein Update des VMware ESX 4.0 SCSI lpfc820-Gerätetreibers durch
ESX400-201006219-UG: Führt ein Update des VMware ESX 4.0 ATA libata-Gerätetreibers durch
ESX400-201006220-UG: Führt ein Update des ESX 4.0 Megaraid SAS-Gerätetreibers durch
ESX400-201006221-UG: Führt ein Update von tzdata durch
ESX400-201006222-UG: Führt ein Update von ESX 4.0 pam_passwdqc rpm durch
ESX400-201006224-UG: Führt ein Update von ESX 4.0 initscripts rpm durch
ESX400-201006225-UG: Führt ein Update der ESX 4.0 Web Access-Komponenten durch
ESX400-201006226-UG: Führt ein Update des VMware ESX 4.0 EHCI HCD-Gerätetreibers durch
ESX 4.0 Update 2 enthält zudem alle Fixes in den folgenden zuvor veröffentlichten Paketen:
Patch-Version ESX400-201005001
Patch-Version ESX400-201003001
Patch-Version ESX 400-201002001
Patch-Version ESX 400-200912001
Patch-Version ESX400-Update01a
Patch-Version ESX400-200909001
Patch-Version ESX400-200907001
Patch-Version ESX400-200906001
Weitere Informationen zu den Inhalten der Patches finden Sie in der Dokumentation, die auf der Download-Seite aufgeführt wird.
Seitenanfang
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.
CIM und API
-
Das Abonnement der wsman-Anzeige ist nach einem Systemneustart nicht mehr verfügbar
In vorherigen Versionen war Das Abonnement der wsman-Anzeige nach einem Systemneustart nicht mehr verfügbar. In der vorliegenden Version ist das Abonnement der wsman-Anzeige nach einem Systemneustart weiterhin dauerhaft verfügbar.
-
Die Base Server-Profildefinition entspricht nicht dem Standard
Um Konformität mit dem DMTF-Profilregistrierungsstandard DSP1033 zu gewährleisten, wurde die Rolle von Base Serverin der Klasse OMC_ReferencedBaseServerProfilevon "Antecedent" in "Dependent" geändert.
-
Es gibt Probleme mit LSI-Anbieter und vmw-Anbieter
Die beiden folgenden Probleme wurden beobachtet, die die storelib-Bibliothek betreffen:
- VMware_HHRCAlertIndication-Klassen werden nicht generiert, nachdem Sie ESX/ESXi-Hosts neu starten.
- Auf der storelib-Anzeige für die IR-Karte werden die Zeitstempeleinstellungen falsch angezeigt.
Um diese Probleme zu lösen, wurde die LSI-storelib-Bibliothek aktualisiert.
-
Fehlerstatusmeldung auf der Registerkarte "Systemstatus" des vSphere-Clients geändert
In dieser Version wurde bei der Beschreibung des Stromversorgungszustands auf der Registerkarte Systemstatus des vSphere-Clients die Meldung, dass ein Fehler erkannt wurde, durch die Fehlerstatusmeldung ersetzt.
-
Bei vorherigen ESX 4.0-Versionen war die sfcbd-Verfolgung (Small-Footprint CIM Broker Daemon) nicht aktiviert
Dieses Problem wurde in der vorliegenden Version behoben. Die sfcbd-Verfolgung ist in ESX 4.0 Update 2 standardmäßig aktiviert.
Gastbetriebssystem
-
Mehrere DNS-Suffixe werden nach der Image-Anpassung der Linux-Distributionen nicht ordnungsgemäß angewendet†
DNS-Suffixe werden automatisch angehängt, wenn eine Linux-Distribution versucht, einen DNS-Domänennamen aufzulösen. Wenn mehr als ein DNS-Suffix angepasst wird, wird nur das letzte DNS-Suffix angewendet. Je nach Linux-Distribution werden nicht alle angepassten DNS-Suffixe auf der Benutzeroberfläche der Linux-Distribution angezeigt.
-
Auf virtuellen FreeBSD-Maschinen kann mit dem Mausrad möglicherweise kein Bildlauf nach oben durchgeführt werden.
Auf der Konsole der virtuellen FreeBSD-Maschine konnte der Bildlauf nach oben nicht mit dem Mausrad durchgeführt werden.
Dieses Problem wurde in der vorliegenden Version behoben.
-
Virtuelle Maschinen, auf denen Windows Server 2003 (64 Bit) oder Windows XP-Gastbetriebssysteme (64 Bit) ausgeführt wird, melden möglicherweise eine falsche CPU-Taktfrequenz
Die von VMs mit Windows 2003- oder Windows XP-Gastbetriebssystemen (64 Bit) gemeldeten CPU-Taktfrequenzen sind möglicherweise falsch. In der virtuellen Maschine wurde QueryPerformanceCountermanchmal mit einer höheren Frequenz ausgeführt als von QueryPerformanceFrequencyangegeben.
Dieses Problem wurde in der vorliegenden Version behoben.
-
Wake-On-LAN funktioniert nicht mit der e1000 vNIC auf neueren Windows-Gastbetriebssystemen†
Für ESX/ESXi-Hosts steht die Wake-On-LAN-Funktion (zum Einschalten eines Hosts über das Netzwerk) auf bestimmten Windows-Gastbetriebssystemen für die e1000 vNIC nicht zur Verfügung. Insbesondere gilt dies für Windows Vista und höher und für 64-Bit-Versionen.
-
Die RHEL 5.3-Konsole der virtuellen Maschine zeigt möglicherweise einen schwarzen Bildschirm an, wenn sie aus dem Ruhezustandsmodus heraus fortgesetzt wird
Ein Problem mit dem SVGA-Treiber führt möglicherweise dazu, dass die RHEL 5.3-Konsole der virtuellen Maschine einen schwarzen Bildschirm anzeigt, wenn sie aus dem Ruhezustandsmodus heraus fortgesetzt wird.
Dieses Problem wurde in der vorliegenden Version behoben.
-
VMware Tools installiert keine Gast-SDK-DLLs im Verzeichnis system32 oder SysWOW64
Auf Windows-Gastbetriebssystemen installiert VMware Tools keine Gast-SDK-DLLs ( vmGuestLib.dllund vmGuestLibJava.dll) in den Systemverzeichnissen (system32 or SysWOW64). Dieses Problem wurde in der vorliegenden Version behoben.
-
Virtuelle Windows-Maschinen mit VMXNET3-Adaptern reagierten nach dem Standby-Modus möglicherweise nicht mehr.
Dieses Problem wurde möglicherweise durch den VMXNET3-Treiber verursacht.
Dieses Problem wurde in der vorliegenden Version behoben.
-
Die Konsole der virtuellen Maschine unter FreeBSD 7.2 zeigte wirre Zeichen an oder war nicht nutzbar, wenn VMware Tools nicht installiert war.
Die Konsole der virtuellen Maschine unter FreeBSD 7.2 zeigte wirre Zeichen an oder war nicht nutzbar, wenn VMware Tools nicht installiert war.
Dieses Problem wurde in der vorliegenden Version behoben.
-
Auf Linux-Gastbetriebssystemen werden Partitionsinformationen mit dem vierten erweiterten Dateisystem ext4 nicht angezeigt
Mit ext4 formatierte Partitionen werden möglicherweise nicht auf der Registerkarte Verkleinern des Dialogfelds "VMware Tools - Eigenschaften" angezeigt. Auf Linux-Systemen greifen Sie auf das Dialogfeld "VMware Tools - Eigenschaften" mit dem folgenden Befehl zu: /usr/bin/vmware-toolbox &. ext4 ist das Standard-Dateisystem für bestimmte Linux-Distributionen, beispielsweise Ubuntu 9.10.
Dieses Problem wurde in der vorliegenden Version behoben.
-
PAE-aktivierte SMP Windows 2000-VMs antworten nicht
PAE-aktivierte (PAE = Physical Address Extension, physische Adresserweiterung) Windows 2000-VMs mit mehreren Prozessoren reagieren bei einem Neustart möglicherweise nicht mehr oder schlagen fehl.
Dieses Problem wurde in der vorliegenden Version behoben.
-
Gastbetriebssysteme ohne APIC (Advanced Programmable Interrupt Controller) lösen manchmal eine Monitor Panic aus
Wenn bei einem Gastbetriebssystem ohne APIC in der Konfigurationsdatei der virtuellen Maschine APIC nicht deaktiviert wird, hängt sich die virtuelle Maschine manchmal bei der Reaktivierung aus dem S1-Ruhezustand auf.
Dieses Problem wurde in der vorliegenden Version behoben.
-
Ein Problem bei der Timer-Emulation führt dazu, dass Timer-Interrupts mit zu hoher Frequenz an das Gastbetriebssystem übergeben werden
Dieses Problem wurde nach einer VMotion-Migration beobachtet, wenn eine virtuelle Maschine über einen sehr langen Zeitraum (z. B. 100 Tage) hinweg aktiv war.
Dieses Problem wurde in der vorliegenden Version behoben.
-
Beim Neustart bestimmter Linux-Gastbetriebssysteme wird möglicherweise die virtuelle Maschine ausgeschaltet
Wenn eine virtuelle Maschine mit einem Linux-Gastbetriebssystem seit 30 Tagen oder länger läuft, wird bei einem Neustart des Gastbetriebssystems möglicherweise die virtuelle Maschine ausgeschaltet. In einem solchen Fall wird eine Fehlermeldung ähnlich der Folgenden in der Datei vmware.logprotokolliert:
Jun 10 09:57:40.347: vcpu-0| MONITOR PANIC: vcpu-0:VMM fault: regs=0x2f94, exc=0, eip=0x84c91
Dieses Problem wurde in der vorliegenden Version behoben.
Internationalisierung
-
Die Installation von VMware Tools schlägt manchmal bei virtuellen Maschinen unter Linux, Solaris oder FreeBSD fehl, die mit nicht unterstützten Zeichensätzen wie EUC_JP Japanese arbeiten
Wenn virtuelle Maschinen unter Linux, Solaris oder FreeBSD mit nicht unterstützten Zeichensätzen (z. B. EUC_JP Japanese) arbeiten, schlägt die Installation von VMware Tools unter den virtuellen Maschinen möglicherweise fehl.
Dieses Problem wurde in der vorliegenden Version behoben. Ab dieser Version kann VMware Tools unter Verwendung nativer Zeichensätze auf virtuellen Linux-, Solaris- und FreeBSD-Maschinen installiert und ausgeführt werden.
Sonstige Probleme
-
Das Gastbetriebssystem eines ESX/ESXi-Hosts oder einer virtuellen Maschine schlägt möglicherweise fehl, wenn Multi-Threaded-Anwendungen, die das VMCI Sockets SDK verwenden, ausgeführt werden †
Ein bekanntes Problem mit der VMCI Sockets-Bibliothek kann dazu führen, dass ein Host oder Gastbetriebssystem möglicherweise fehlschlägt, wenn Multi-Threaded-Anwendungen, die das VMCI Sockets SDK verwenden, ausgeführt werden.
-
Hilfemenüelemente erscheinen inaktiv oder das Klicken auf andere Hilfe-Links führt zu einem Fehler†
Hilfemenüelemente erscheinen inaktiv bei vSphere-Client-Installationen auf Maschinen mit Windows-Betriebssystemen, die nicht englisch, japanisch, deutsch oder chinesisch (vereinfacht) sind. Außerdem besteht das Problem, dass wenn Sie, um Hilfe zu erhalten, im vSphere-Client auf andere Links oder Schaltflächen klicken, folgende Fehlermeldung angezeigt wird: Fehlende Hilfedatei
-
Die Dienstprogramme "esxtop" und "resxtop" zeigen verschiedene Betriebszustandstatistiken logischer CPUs nicht an
Dieses Problem wurde in der vorliegenden Version behoben. Ein neuer Bildschirm "Betrieb" mit Statistiken zu logischen CPUs ist über das Dienstprogramm esxtop(unter ESX) und resxtop(unter ESX und ESXi) verfügbar. Zum Wechseln zum Bildschirm "Betrieb" drücken Sie yim Bildschirm esxtopbzw. resxtop.
-
Beibehaltung von Dateizugriffsberechtigungen beim Kopieren von Dateien zwischen POSIX-Betriebssystemen
Die Funktionen CopyFileFromHostToGuest()und CopyFileFromGuestToHost()der VIX C API behalten die Berechtigungsbits beim Kopieren von Dateien zwischen dem Host- und dem Gastbetriebssystem nicht bei. Die Berechtigungen der Zieldatei werden auf die Standardwerte des Besitzers gesetzt, wodurch in der Regel nur der Besitzer Lese- und Schreibzugriff hatte.
Wenn beispielsweise das Ausführungsbit auf dem Linux-Host für den Dateibesitzer gesetzt ist und die Datei mithilfe von CopyFileFromHostToGuest()auf ein Linux-Gastbetriebssystem kopiert wird, wird bei der Kopie auf dem Gastbetriebssystem das Ausführungsbit gelöscht.
In dieser Version wurde das Problem der Nichtbeibehaltung von Dateizugriffsberechtigungen beim Kopieren von Windows- oder Linux-Hosts auf Gastbetriebssysteme (und umgekehrt) behoben.
-
Mit Beginn der Sommerzeit (daylight saving time, DST) wird die Zeitanzeige auf bestimmten Systemen ungenau
Das in dieser Version angebotene aktualisierte tzdata-Paket (tzdata-2009u) adressiert die Umstellung auf die Sommerzeit für mehrere Länder und Regionen, wie z. B. für betroffene Teile der Antarktis, sowie von Argentinien, Bangladesch, Kuba, Ägypten, Fidschi, Marokko, Pakistan, Palästina, Russland, Syrien und Tunesien.
-
Fehlende Return-Anweisungen des World-Kopier-Dienstprogramms eines Benutzers können zur Beschädigung der Daten im Arbeitsspeicher oder dazu führen, dass der Server sich aufhängt
Fehlende Return-Anweisungen des World-Kopier-Dienstprogramms eines Benutzers können dazu führen, dass Daten doppelt in den Pufferspeicher der World eines Benutzers kopiert werden. Wenn nach dem erstmaligen Kopieren von Daten in den Pufferspeicher der World eines Benutzers Return-Anweisungen fehlen, wird eine zweite Kopie der Daten in einen nicht vorhandenen VMkernel-Puffer geschrieben. Dies kann zur Beschädigung von Daten im Arbeitsspeicher oder dazu führen, dass der Server sich aufhängt.
Dieses Problem wurde in der vorliegenden Version behoben.
Netzwerk
-
Virtuelle Maschinen werden möglicherweise aus einer Multicast-Gruppe ausgeschlossen, wenn sie das IGMPv1- oder IGMPv2-Protokoll in Verbindung mit gruppierten Uplink-Netzwerkkarten nutzen
Das Fehlen von Internet Group Management Protocol (IGMPv1 oder IGMPv2)-Mitgliedschaftsberichten kann dazu führen, dass virtuelle Maschinen aus der Multicast-Gruppe ausgeschlossen werden. Dieser Ausschluss von virtuellen Maschinen tritt auf, wenn die NIC-Gruppierungsrichtlinie auf Load Balancing Policy Source Port: Id or Source MAC Address gesetzt ist.
Dieses Problem wurde in der vorliegenden Version behoben.
-
Geschwindigkeits- und Duplex-Einstellungen für eine Netzwerkkarte werden möglicherweise nach dem Neustart des ESX/ESXi-Servers nicht beibehalten
Wenn die Geschwindigkeits- und Duplex-Einstellungen für eine Netzwerkkarte manuell vorgenommen werden und der ESX/ESXi-Host neu gestartet wird, gehen die eingestellten Werte möglicherweise verloren. Nach dem Neustart handelt der Netzwerkadapter ggf. seine Geschwindigkeits- und Duplex-Einstellungen möglicherweise automatisch aus.
Dieses Problem wurde in der vorliegenden Version behoben.
-
Netzwerk-Einrichtungsskript zur Konfiguration des Netzwerks ohne esxcfg-*-Befehle
Ab dieser Version ist ein Netzwerk-Einrichtungsskript in der vmware-esx-script-RPM verfügbar, das unter /usr/sbin/console-setupinstalliert ist. Mit diesem Skript lässt sich das ESX-Netzwerk interaktiv ohne Ausführung der esxcfg-*-Befehle konfigurieren. Mit diesem Skript können Sie die aktuellen Vswif-Konfigurationsdaten, die aktuellen Netzwerkadapter sowie die aktuellen vSwitch- und vDS-Informationen einsehen, Vswifs löschen und die Netzwerkschnittstelle der Servicekonsole konfigurieren.
-
Die Ringgröße der VMXNET3-Netzwerkschnittstellenkarte ist unter Windows-Gastbetriebssystemen nicht konfigurierbar
Dieses Problem wurde in der vorliegenden Version behoben. Konfigurationsparameter wie Rx Ring #1 Size, Rx Ring #2 Size, Tx Ring Size, Small Rx Buffersund Large Rx Bufferskönnen jetzt im Geräte-Manager (Dialogfeld in der Systemsteuerung) von Windows-Gastbetriebssystemen angepasst werden.
-
Es werden doppelte Multicast-Pakete generiert, wenn der vSwitch über mindestens zwei vmnics verfügt und der Promiscuous-Modus aktiviert ist
Dieses Problem kann bei einem vSwitch mit mehr als einem Uplink und aktiviertem Promiscuous-Modus auftreten. Einige der über die Uplinks, die zurzeit nicht vom Promiscuous-Port verwendet werden, eingehenden Pakete, werden nicht verworfen. Dieses Verhalten irritiert möglicherweise einige Anwendungen, z. B. die CARP-Protokollinstanz.
Dieses Problem wurde in der vorliegenden Version behoben. Ab dieser Version steht die Konfigurationsoption Net.ReversePathFwdCheckPromisczur Verfügung, mit der sich ausdrücklich alle Pakete für den Promiscuous-Port verwerfen lassen, die über aktuell nicht verwendete Uplinks eingehen.
Hinweis: Wenn Sie den Wert der Konfigurationsoption Net.ReversePathFwdCheckPromiscändern, während die ESX-Instanz ausgeführt wird, ist es erforderlich, den Promiscuous-Modus zu aktivieren oder zu reaktivieren, damit die Konfigurationsänderung wirksam wird.
-
Bei kürzlich von QLogic und NetXen veröffentlichten Firmware-Versionen werden einige Ports der Quad Port 1G-Netzwerkkarten nicht angezeigt
Dieses Problem tritt hauptsächlich bei unter dem Markennamen von HP vertriebenen NetXen-Karten auf, z. B. der NC375T. Mit dem Befehl esxcfg-nics -l(unterstützt unter ESX) und mit dem vSphere-Client können einige Ports von Quad Port 1G-Netzwerkkarten nicht angezeigt werden. Die entsprechenden NetXen-Geräte/-Ports werden von der Hardware erkannt und lassen sich mit dem Befehl lspci(unterstützt unter ESX) auflisten. Der Treiber kann jedoch einige der Ports nicht erstellen oder testen.
Dieses Problem wurde in der vorliegenden Version behoben. Der Fix befasst sich mit der Art und Weise, wie der Treiber Geräte erstellt.
-
Bei Windows-Gastbetriebssystemen vor Windows Vista wird möglicherweise die Verbindung unterbrochen, wenn diese Systeme in Verbindung mit der virtuellen Netzwerkkarte VMXNET3 verwendet werden
Die Network Driver Interface Specification (NDIS) ist Teil der Netzwerkarchitektur von Microsoft Windows-Betriebssystemen. Der NDIS-Transporttreiber kann auf unbestimmte Dauer die Pufferdaten vorhalten, die von VMXNET3-Treibern empfangen wurden, sodass der Pufferspeicher knapp wird.
Dieses Problem wurde in der vorliegenden Version behoben.
-
Die Verbindung zu mit einem verteilten vNetwork-Switch (vDS) verbundenen virtuellen Maschinen wird manchmal nach einem Failover getrennt
Die Portänderungen für virtuelle Maschinen in einem vDS werden alle fünf Minuten festgehalten. Da Portänderungen für virtuelle Maschinen nicht sofort festgehalten werden, verlieren virtuelle Maschinen möglicherweise die Netzwerkverbindung nach einem Failover-Ereignis, wenn Sie so konfiguriert wurden, dass sie weniger als fünf Minuten vor dem Failover eine Verbindung mit einem vDS herstellen.
Dieses Problem wurde in der vorliegenden Version behoben.
-
Ein verteilter vNetwork-Switch (vDS) meldet beim Hinzufügen eines neuen Ports einen Fehler, auch nachdem die Einstellung für die maximale Anzahl von Proxy-Ports erhöht wurde
Der vDS-Status und der Proxy-Switch werden in separaten Dateien gespeichert und unabhängig voneinander verarbeitet. Wenn der vDS erstellt wird, wird die gleiche maxPorts-Einstellung für beide verwendet. Wenn Sie jedoch die maxPorts-Einstellung ändern, wird nur die Proxy-Switch-Konfiguration aktualisiert. Da der vDS weiterhin den alten Wert für maxPortsverwendet, meldet er beim Hinzufügen eines neuen Ports einen Fehler, wenn die Gesamtzahl der Proxy-Ports den alten Wert für maxPortsübersteigt.
Dieses Problem wurde in der vorliegenden Version behoben.
Serverkonfiguration
Speicher
-
Beim Entfernen aller Snapshots von einer virtuellen Maschine mithilfe der Option "Alle löschen" kann eine große Menge an Festplattenspeicher belegt werden
Wenn Sie im Snapshot-Manager die Option Alle löschen verwenden, wird der Snapshot, der am weitesten von der Basisfestplatte entfernt ist, an den übergeordneten Snapshot übergeben, der infolgedessen wächst. Nach Abschluss der Übergabe wird dieser Snapshot entfernt. Der Vorgang beginnt erneut mit dem vor kurzem aktualisierten Snapshot, der seinem übergeordneten Snapshot zugeordnet wird. Dies wird solange fortgesetzt, bis alle Snapshots übergeben wurden.
Diese Methode ist möglicherweise relativ zeitaufwendig, weil die weit von der Basisfestplatte entfernten Snapshots möglicherweise mehrere Male kopiert werden müssen. Von größerer Bedeutung ist jedoch, dass auf diese Weise bei großen Snapshots viel Festplattenspeicher verbraucht wird. Dies ist besonders dann problematisch, wenn auf dem Datenspeicher nur eine begrenzte Menge von Speicherplatz vorhanden ist. Das Speicherplatzproblem ist störend, wenn Sie Snapshots explizit löschen, um Speicherplatz freizugeben.
Dieses Problem wurde in der vorliegenden Version behoben. Die Reihenfolge der Snapshot-Konsolidierung wurde dahingehend geändert, dass mit dem der Basisfestplatte am nächsten liegenden Snapshot und nicht mit dem am weitesten entfernten begonnen wird. Damit werden die Daten nicht wiederholt kopiert.
-
Virtuelle Maschinen, die einen PVSCSI-Adapter verwenden, antworten möglicherweise nicht mehr oder verhalten sich in der Anfangsphase eines Startvorgangs anders als erwartet
Auf Festplatten, die über PVSCSI-Controller angeschlossen sind, wird sowohl über BIOS als auch über den PVSCSI-Treiber zugegriffen. Wenn Sie eine virtuelle Maschine von einer PVSCSI-Platte aus starten, wird anfänglich das BIOS verwendet. Unter bestimmten Umständen erkennt der Startvorgang der virtuellen Maschine veraltete Daten, was zu Fehlverhalten im Gastbetriebssystem oder dazu führt, dass das Gastbetriebssystem nicht antwortet.
Dieses Problem wurde in der vorliegenden Version behoben.
-
Das Speicher-Array-Typ-Plug-In VMW_SATP_DEFAULT_AA steuerte unerwartet alle RSSM-Geräte (IBM RAID Shared Storage Module)
Da VMW_SATP_ALUA-Plug-Ins nicht in der Lage waren, RSSM-Geräte mit TPGS-Unterstützung (Target Port Group Support) zu steuern, übernahm das VMW_SATP_DEFAULT_AA-Plug-In die Steuerung.
Dieses Problem wurde in der vorliegenden Version behoben. Jetzt ermöglichen SATP-Regeln die Zuordnung von RSSM-Geräten mit TPGS-Funktionalität zu VMW_SATP_ALUA-Plug-Ins und die Zuordnung von RSSM-Geräten ohne TPGS-Funktionalität zu VMW_SATP_DEFAULT_AA-Plug-Ins.
-
Das Dienstprogramm "vmkiscsi-tool" zeigte keine Anmeldefehler an
Alle Attribute des Ziels, mit Ausnahme des Anmeldestatus, wurden vom Dienstprogramm vmkiscsi-toolgelesen und angezeigt. Die Fehlerbehebung ist möglicherweise ohne Informationen über den Anmeldestatus sehr komplex und umständlich.
Dieses Problem wurde in der vorliegenden Version behoben. vmkiscsi-toolzeigt jetzt auch Anmeldefehler an.
-
Der Emulex-Adapter konnte die Zielports des modularen HP-Speicher-Arrays nicht erneut erkennen, wenn ein Zielport auf dem Array zurückgesetzt wurde
Das modulare HP-Speicher-Array verfügt über eine Failover-Funktion, die dem aktiven Port ermöglicht, die Identität eines anderen Ports einschließlich dessen WWPN (World Wide Port Name) abzuleiten. Wenn dies geschieht, hat der Zielport dieselbe Ziel-ID (DID), aber einen anderen WWPN. Aufgrund dieses Unterschieds markierte der Treiber einen der beiden Zielports als NPR mit ausstehender Port-Anmeldung (PLOGI), während der andere Zielport mit der vom ersten Zielport abgeleiteten Identität normal fortgesetzt wurde.
Dieses Problem wurde in der vorliegenden Version behoben. Der Fix erkennt diese Bedingung und führt PLOGI erneut aus, sodass die Ziele erneut korrekt erkannt werden.
-
Virtuelle Maschine erkennt externe USB-Geräte nicht
Wenn ein USB-Gerät von einem USB-Anschluss eines ESX-Systems abgezogen und wieder an denselben Anschluss angeschlossen wird, erkennt eine virtuelle Maschine möglicherweise das USB-Gerät nicht.
Dieses Problem wurde in der vorliegenden Version behoben.
-
Wenn Datenzugriffsbefehle an ein Laufwerk ohne Medium gesendet werden, werden redundante Meldungen ausgegeben
Falls eine virtuelle Maschine auf ein CD-Laufwerk zugreift, dass keine CD enthält, wird die Datei vmware.logmit redundanten Einträgen ähnlich der Folgenden überfrachtet:
VIDE: ATAPI DMA 0x43 Failed: key 0x2, asc 0x3a, ascq 0x0
Dieses Problem wurde in der vorliegenden Version behoben.
-
Ein Fehler im Vorgang zur Freigabe eines Journal-Blocks verursacht ein Leck in einem Datei-Block, auf den der Dateisystemtreiber dann nicht mehr zugreifen kann
Für dieses Problem wird folgende Aussage protokolliert, die besagt, dass ein Vorgang zur Blockfreigabe fehlgeschlagen ist: WARNUNG: J3: 1644: Error freeing journal block (returned 0) for 4ac5183a-d1b537f3-2627-00237dce6676: Lock was not free
Dieses Problem wurde in der vorliegenden Version behoben. Lecks in Journal-Blöcken treten im Zusammenhang mit Vorgängen zur Blockfreigabe nicht mehr auf.
-
ESX behandelt Leselängen, die nicht auf 4 Byte ausgerichtet sind, nicht ordnungsgemäß
Wenn Leselängen nicht auf 4 Byte ausgerichtet sind, wird die RPC-Antwort vom ESX-Host mit Bytes aufgefüllt, um die Meldung auf 4 Byte auszurichten. Auf diese Weise wird der SG-Array fälschlicherweise mit Padding-Bytes gefüllt. Dies führt möglicherweise dazu, dass ESX nicht mehr antwortet, wenn der SG-Array keinen Platz für Padding-Bytes hat.
-
Hosts erkennen möglicherweise keine Ziel-LUNs über eine virtuelle Cisco M81KR-Netzwerkkarte, wenn das Ziel und die Hosts in der IVR-Zone eines Cisco MDS-Switch konfiguriert sind
Wenn eine virtuelle Cisco M81KR-Netzwerkkarte einem Host in einer IVR-Zone (Inter-VSAN Routing) mit dem Ziel auf einem Cisco MDS-Switch hinzugefügt wird, kommt es u. U. zu einer Zeitüberschreitung bei einem Anmeldeversuch auf dem Ziel, und der Host findet eventuell die LUNS auf dem Zielspeicher nicht.
Dieses Problem wurde in der vorliegenden Version behoben.
-
Unterstützung für die Speicher-Arrays SGI InfiniteStorage 4000, 4100 und 4600
Dieser Patch bietet Unterstützung für die folgenden Speicher-Arrays von SGI: SGI InfiniteStorage 4000, SGI InfiniteStorage 4100 und SGI InfiniteStorage 4600. Diese SGI-Controllers werden vom LSI Storage Array Type Plugin verwaltet, das zum VMware Native Multipath Plug-In (NMP) gehört.
-
Möglicherweise werden von Qlogic-Treibern für Fibre-Channel-HBAs (Hostbusadaptern) fälschlicherweise verworfene Frames gemeldet
Für Speicher-Arrays, die weniger Daten zurückgeben als erwartet (ein Underrun-Problem), wird vom Qlogic-Treiber an Stelle des Underrun-Problems mit dem ursprünglichen SCSI-Status fälschlicherweise gemeldet, dass Frames mit dem SCSI-Status Belegt verworfen wurden.
Dieses Problem wurde in der vorliegenden Version behoben. Der Qlogic-Treiber meldet ordnungsgemäß den SCSI-Status, jedoch nicht, dass die Frames verworfen wurden.
-
Für Geräte, die das Round Robin-PSP verwenden, wird der für die --iops-Option konfigurierte Wert nach dem Neustart des ESX-Hosts geändert
Wenn ein Gerät, das von der Round Robin-PSP gesteuert wird, für die Verwendung der Option --iopskonfiguriert wird, wird der für die Option --iopseingestellte Wert nicht beibehalten, wenn der ESX-Host neu gestartet wird.
Dieses Problem wurde in der vorliegenden Version behoben.
-
Ein Journal-Code-Problem führt zu "panic" (oder OOPS) in der Servicekonsole auf einem ESX-Host
Ein Journal kann inmitten eines Verkürzungs- oder Journal-Neustart-Vorgangs abgebrochen werden, was möglicherweise zu "panic" in der Servicekonsole führt.
Dieses Problem wurde in der vorliegenden Version behoben.
Unterstützte Hardware
-
Ereignismeldungen des StoreLib von IR-Karten haben einen fehlerhaften Zeitstempel†
In den Ereignismeldungen von StoreLib zeigt IndicationTimefür LSI 1078 und 1068E Integrated RAID (IR)-Controller fehlerhafte Zeitstempel an.
-
Wenn Sie mit dem vSphere-Client auf die Konsole einer virtuellen Maschine zugreifen, die eine NetXen NX3031-Netzwerkkarte (NIC) verwendet, fällt das System aus und es wird ein violetter Bildschirm angezeigt
Wenn sich die NetXen NX3031-Netzwerkkarte an einer relativ hohen Arbeitsspeicherposition (möglicherweise oberhalb 512 GB) befindet, stürzt das System ab, wenn es versucht, auf Adressen außerhalb des gültigen Bereichs zuzugreifen. Dieses Problem kann möglicherweise auftreten, wenn das System über einen physischen Arbeitsspeicher von 96 GB verfügt, aber die Arbeitsspeicher-Map-Konfiguration Adressen generiert, die außerhalb des 512-GB-Arbeitsspeicherbereichs liegen.
Eine Meldung ähnlich der Folgenden wird protokolliert, bevor das System nicht mehr reagiert:
<3>nommu_map_single: overflow a31407ad5a+54 of device mask 7fffffffff
Nachfolgend finden Sie ein Beispiel für eine Rückverfolgung dieses Problems:
0x4100c00e7338:[0x41801d1984bf]nommu_map_single+0x4e stack: 0x0
0x4100c00e7598:[0x41801d26f745]unm_nic_xmit_frame+0x4d8 stack: 0x4100c00e75c8
0x4100c00e7688:[0x41801d1a1609]process_tx_queue+0x874 stack: 0x41000b884600
Dieses Problem wurde in der vorliegenden Version behoben.
Upgrade und Installation
-
Die Installation von ESX auf einem System mit mehr als acht Netzwerkkarten (NICs) führt möglicherweise dazu, dass das System nicht mehr reagiert
Wenn Sie den Textmodus zum Installieren von ESX auf einem System mit mehr als acht NICs verwenden, reagiert das Installationsprogramm möglicherweise nicht mehr und eine Fehlermeldung ähnlich der Folgenden wird möglicherweise angezeigt:
Bei der ESX-Installation ist ein Fehler aufgetreten. Das 'NicSetup'-Objekt hat kein Attribut 'scrollDisplay'
Dieses Problem wurde in der vorliegenden Version behoben.
-
Änderungen an der Datei "/etc/syslog.conf" in ESX 4.0 werden nach einem Upgrade auf ESX 4.0 Update 1 möglicherweise überschrieben †
Dieses Problem tritt auf, wenn der vmkernel-Eintrag in der Datei syslog.confin ESX 4.0 nicht vorhanden ist. Wenn der vmkernel-Eintrag nicht vorhanden ist, werden Änderungen, die in der Datei syslog.confvorgenommen wurden, während des Upgrades überschrieben. Genauer gesagt ersetzt während des nächsten Updates oder Patches das Scriptlet lnxcfg postdie Datei syslog.confdurch eine neue Datei.
-
Beim Übernehmen des Bulletins ESX400-200911201-UG werden die symbolischen Links für die LSI-Bibliothek entfernt†
Während des Upgrade-Prozesses für das Bulletin ESX400-200911201-UG oder ESX400-Update01/ESX400-Update01a werden die folgenden symbolischen Links entfernt:
/lib/libstorelib.so.2
/lib/libstorelibir.so.2
/lib/libstorelibir-2.so.2
The vmware-esx-lsiRPM is responsible for this behavior. Wenn eine Anwendung vom vmware-esx-lsi-RPM abhängt, müssen Sie möglicherweise die symbolischen Links für diese Anwendung wiederherstellen, damit diese wieder verwendet werden können.
-
Auf QLogic HBAs wird die vom Treiber zwischengespeicherte Kopie von VPD während eines Flash-Updates beschädigt †
Die Ausführung eines Flash-Updates unter Verwendung der SANsurfer-SCLI oder -GUI führt dazu, dass die bereitgestellten QLogic-Adapterinformationen fehlerhaft sind. Neben den beschädigten Informationen wird möglicher-, aber nicht notwendigerweise bei Beendigung des Flash-Updates eine Fehlermeldung angezeigt, wie z. B. eine der Folgenden:
- GUI-Fehlermeldung: Flash kann nicht aktualisiert werden
- SCLI-Fehlermeldung: Flash-Update auf dem HBA fehlgeschlagen
Die VPD-Region des Flashs wird während des SANSurfer SCLI- oder GUI-Flash-Updates mit den aktualisierten Image-Versionen, Seriennummern und weiteren relevanten Adapterinformationen aufgefüllt. Nach einem Update zeigen die SANSurfer- oder SCLI-Dienstprogramme die VPD-Adapterinformationen falsch an. Zu den möglichen falsch angezeigten Daten gehören:
- Falsche BIOS/EFI/Fcode-Versionen oder Versionen mit dem Status "Nicht verfügbar".
- Falsche Anzahl an HBA-Adaptern. Beispielsweise wird ein 2-Port-HBA als zwei 1-Port-HBAs angezeigt.
-
Beim Upgrade auf ESX 4.0 Update 1 wird der Speicherplatz des Systems aufgebraucht, bevor das Upgrade abgeschlossen ist, wodurch das System in einen nicht behebbaren Zustand versetzt wird
Ein Problem in der Routine des RPM-Tools zum Berechnen des freien Festplattenspeichers führt zu einer Fehlberechnung des verfügbaren Speicherplatzes vor dem Upgrade. Wenn während eines Upgrades der gesamte Festplattenspeicher eines Systems aufgebraucht wird, wird der Upgrade-Prozess möglicherweise unterbrochen, wodurch das System in einen nicht behebbaren Zustand versetzt werden kann.
Dieses Problem wurde in der vorliegenden Version behoben.
vCenter Server, vSphere-Client und vSphere Web Access
-
Der vSphere-Client benötigt möglicherweise mehr Zeit als erwartet dafür, kürzlich installierte Erweiterungen in der Liste der installierten Erweiterungen anzuzeigen †
Nach der Installation der Erweiterungen vergehen 30 - 60 Sekunden, bevor neu installierte Erweiterungen in der Liste der installierten Erweiterungen erscheinen.
-
Der VMWare Paravirtual SCSI-Controller kann mit virtuellen Maschinen unter SUSE Linux Enterprise 11 SP1 verwendet werden
Ab vSphere 4.0 Update 2 können Sie virtuelle Suse Linux Enterprise 11-Maschinen (32 oder 64 Bit) mit dem VMware Paravirtual SCSI-Controller erstellen. Es muss jedoch als Gastbetriebssystem wenigstens SUSE Linux Enterprise 11 SP1 installiert sein, um den Treiber vmw_pvscsi hinzuzufügen.
Weitere Informationen über die Kombination aus Gastbetriebssystem und den unterstützten ESX-Versionen finden Sie im VMware-Kompatibilitätshandbuch.
-
Virtuelle 0S/2-Maschinen unterstützen nur einen virtuellen Prozessor
Wenn Sie ab vSphere 4.0 Update 2 virtuelle Maschinen mit dem OS/2-Gastbetriebssystem erstellen, können Sie höchstens einen virtuellen Prozessor wählen.
Verwaltung von virtuellen Maschinen
-
Legacy-Skripteinstellungen für vmware-toolbox werden auf einem Linux-Gastbetriebssystem nach einem Upgrade der VMware Tools auf die Standardeinstellungen zurückgesetzt †
Wenn Sie auf einer virtuellen Maschine mit ESX Server 3.0.x, auf der ein Linux-Gastbetriebssystem ausgeführt wird, VMware Tools aktualisieren, werden die vorhandenen Einstellungen auf der Skript-Registerkarte vmware-toolbox
auf die Standardwerte zurückgesetzt.
-
Nach dem Anhalten und Fortsetzen einer virtuellen Maschine können Versuche zum Deaktivieren des VMXNET3-Adapters fehlschlagen†
Wenn die Netzwerkverbindung zwischen dem Anhalten und Fortsetzen in einen nicht definierten Zustand wechselt, beispielsweise wenn der Name der Portgruppe geändert wird, kann das virtuelle Netzwerkgerät die neue Netzwerkverbindung mit dem Treiber nicht aktualisieren. Dieser Zustand verhindert, dass der VMXNET3-Adapter deaktiviert, deinstalliert oder aktualisiert werden kann.
-
Eine virtuelle Maschine reagiert beim Herunterfahren möglicherweise nicht mehr
Beim Herunterfahren oder möglicherweise bei anderen Gelegenheiten, wenn bestimmte Bedingungen eintreten, antwortet ein vmx-Prozess möglicherweise nicht mehr, was dazu führt, dass die entsprechende virtuelle Maschine nicht mehr reagiert.
Dieses Problem wurde in der vorliegenden Version behoben.
-
Eine virtuelle Maschine antwortet nicht oder wird nicht eingeschaltet, wenn ihre Netzwerkkarte mit einer Portgruppe verbunden ist, deren Name mehr als 50 Zeichen aufweist
Dieses Problem wurde in der vorliegenden Version behoben. Namen von Portgruppen können nicht mehr umbenannt werden, wenn die Länge des neuen Namens 50 Zeichen überschreitet . Bereits zugewiesene Namen von Portgruppen, die mehr als 50 Zeichen aufweisen, sind nicht für virtuelle Maschinen zugänglich.
VMotion und Storage VMotion
VMware High Availability und Fehlertoleranz
-
Wenn eine virtuelle Maschine, die auf einem NAS-Datenspeicher ausgeführt wird, so konfiguriert ist, dass sie als Reaktion auf die Hostisolierung heruntergefahren wird, wird sie als Folge eines Netzwerkisolationsereignisses möglicherweise auf zwei Hosts gleichzeitig ausgeführt †
Wenn eine virtuelle Maschine mit der Standardeinstellung konfiguriert ist, bei einer Hostisolierung herunterzufahren, kann die virtuelle Maschine möglicherweise während des Versuchs herunterzufahren nicht mehr antworten, wenn ein mehrfacher Netzwerkausfall auftritt, der eine Hostisolierung und den Verlust des Netzwerkzugriffs auf den Datenspeicher zur Folge hat. HA wird in diesem Fall versuchen, die virtuelle Maschine auszuschalten und sie auf einem anderen Host neu zu starten. Im vSphere-Client werden möglicherweise zwei Instanzen der virtuellen Maschine angezeigt. Es werden keine Daten beschädigt, weil HA und VMFS den Zugriff auf die Daten der virtuellen Maschine ordnungsgemäß steuern, aber die ursprüngliche virtuelle Maschine reagiert nicht mehr. Sie können dieses Problem bereinigen, indem Sie den Host direkt verbinden, der isoliert wurde, und die Frage abweisen.
VMware Tools
-
Virtuelle ThinPrint-Komponenten zum Drucken werden automatisch installiert, wenn Sie VMware Tools installieren
Wenn Sie ab dieser Version VMware Tools mithilfe der benutzerdefinierten Option installieren, können Sie die Auswahl von ThinPrint aufheben, sodass VMware Tools ohne die virtuellen Komponenten von ThinPrint installiert wird.
-
Ein Upgrade der VMware Tools führt dazu, dass die Funktionalität von Microsoft SQL Server nicht mehr verwendet werden kann
Einige Drittanbieter-Softwareprogramme, wie z. B. Microsoft SQL Server, bieten keine Unterstützung für die gemeinsame Nutzung der Datei atl71.dll. Darum erhöht die Software während der Installation nicht den .dll-Referenzzähler. Als Teil des Haupt-Upgrades der VMware Tools wird beim Deinstallieren von ATL71die gemeinsam genutzte Bibliothek atl71.dllentfernt, wenn ihr Referenzzähler für die gemeinsame Nutzung 0 erreicht. Als Folge davon kann die Funktionalität von Microsoft SQL Server nicht mehr verwendet werden .
Dieses Problem wurde in der vorliegenden Version behoben.
Seitenanfang
Bekannte Probleme
In diesem Abschnitt werden bekannte Probleme dieser Version unter den folgenden Themengebieten beschrieben:
Bekannte Probleme, die früher nicht dokumentiert wurden, werden mit einem Sternchen (*) markiert.
Sicherung
-
VMware Consolidated Backup (VCB) wird nicht mit Fehlertoleranz unterstützt
Ein auf einer FT-aktivierten virtuellen Maschine durchgeführtes VCB-Backup schaltet sowohl die primären als auch die sekundären virtuellen Maschinen aus und führt möglicherweise dazu, dass die virtuellen Maschinen unbrauchbar werden. Umgehung: Keine
CIM und API
-
Einige VRM-Sensoren der Stromversorgung werden nicht auf der Registerkarte "vCenter-Hardwarestatus" für die Server IBM x3850 und x3950 M2 angezeigt *
Auf der Registerkarte Hardwarestatus von vCenter Server werden die Sensoren nicht für alle Statuszustände des PS VRM-Sensors auf der Registerkarte Hardwarestatus für Server vom Typ IBM x3850 und x3950 M2 angezeigt. Die CIM-Instanzen werden nicht entsprechend jedem Systemzustand des VRM-Sensors der Stromversorgung auf Servern vom Typ IBM x3850 und x3950 M2 erstellt. Der Grund ist ein Defekt in der IBM BMC-Firmware 4.5. Aus diesem Grund werden die Sensoren nicht auf der Registerkarte Hardwarestatus von vCenter angezeigt.
-
In Small Footprint CIM Broker wird eine falsche Versionsnummer aufgeführt *
Die vom SLP-Service aufgeführte Versionsnummer von Small Footprint CIM Broker ist falsch. Diese Version enthält die SFCB-Version 1.3.3, aber in den SLP-Abfrageinformationen wird die Version als 1.3.0 aufgeführt. Das ist zwar eine falsche Versionsnummer, sie wirkt sich jedoch nicht auf die Verwendung des SLP-Dienstes aus. Zurzeit gibt es keine Umgehung für dieses Problem.
-
Das Abonnement der CIM-Anzeige ist nach einem ESX-Update nicht mehr verfügbar *
Das Abonnement der CIM-Anzeige geht verloren, wenn Sie zwischen ESX-Updates aktualisieren oder Patches anwenden. Die Informationen zum Empfänger der Anzeige werden durch das Upgrade überschrieben und gehen so verloren.
Umgehungen: Beide der folgenden Umgehungen haben sich als effektiv erwiesen. Wenden Sie die Methode an, die für Ihre Bereitstellung am besten geeignet ist.
- Führen Sie ein erneutes Abonnement der CIM-Anzeige durch
Möglicherweise ist es nicht möglich, diese Umgehung anzuwenden. In manchen Fällen ist ein erneutes Abonnement der CIM-Anzeige keine Option.
- Kopieren sie die entsprechenden Dateien aus dem Backup-Repository in das neue Repository, wie in den nachfolgenden Teilschritten beschrieben.
Bei dieser Umgehung werden die Abonnements der CIM XML-Anzeige wiederhergestellt.
- Verschieben Sie die folgenden Dateien aus dem Backup-Repository in das neue Repository:
cim_indicationfilter
cim_indicationfilter.idx
cim_indicationhandlercimxml
cim_indicationhandlercimxml.idx
cim_indicationsubscription
cim_indicationsubscription.idx
cim_listenerdestinationcimxml
cim_listenerdestinationcimxml.idx
.
Verschieben Sie beispielsweise die vorherigen Dateien aus dem Backup-Repository wie /var/lib/sfcb/registration/repository.previous/root/interopin das neue Repository wie
/var/lib/sfcb/registration/repository/root/interop
- Starten Sie den Prozess sfcbd-watchdogneu.
Gastbetriebssystem
-
Virtuelle Maschine unter Solaris 10 U4 reagiert nicht mehr während eines Upgrades der VMware Tools
Das Upgrade oder der Neustart der VMware Tools in einer virtuellen Maschine unter Solaris 10 U4 mit einem erweiterten vmxnet-Adapter kann möglicherweise dazu führen, dass das Gastbetriebssystem nicht mehr reagiert und die Installation nicht mehr fortgesetzt werden kann. Solaris 10 U5 und spätere Versionen sind von diesem Problem nicht betroffen.
Umgehung: Bevor Sie VMware Tools installieren oder Upgrade, sollten Sie vorübergehend die Konfiguration des erweiterten vmxnet-Adapters entfernen, indem Sie entweder dessen Autokonfigurationsdateien in /etc/
entfernen oder die virtuelle Hardware entfernen.
-
Geräte, die im laufenden Betrieb an den BusLogic-Adapter angeschlossen werden, sind im Linux-Gastbetriebssystem nicht sichtbar
Geräte, die an einen im laufenden Betrieb angeschlossenen BusLogic-Adapter angeschlossen werden, werden von einem Linux-Gastbetriebssystem nicht erkannt, wenn dieses zuvor über einen anderen BusLogic-Adapter verfügte. Außerdem schlägt möglicherweise das Entfernen des BusLogic-Adapters im laufenden Betrieb fehl. Dieses Problem tritt auf, weil der in Linux-Distributionen verfügbare BusLogic-Treiber keine Hot-Plug-APIs unterstützt. Dieses Problem betrifft nicht das Hinzufügen von Festplatten zum Adapter im laufenden Betrieb, sondern nur das Hinzufügen des Adapters selbst im laufenden Betrieb. Umgehung: Verwenden Sie zum Hinzufügen im laufenden Betrieb einen anderen Adapter, beispielsweise einen parallelen Adapter oder den SAS LSI Logic-Adapter. Wenn ein BusLogic-Adapter erforderlich ist, sollten Sie versuchen, den Adapter im laufenden Betrieb zu entfernen, nachdem Sie den BusLogic-Treiber im Gastbetriebssystem entladen haben. Sie können außerdem versuchen, den im laufenden Betrieb hinzugefügten Adapter zu steuern, indem Sie eine andere Instanz des BusLogic-Treibers laden. Sie können eine andere Instanz des BusLogic-Adapters laden, indem Sie den Befehl modprobe -o BusLogic1 BusLogic
ausführen (wobei Sie für jede Hinzufügeaktion im laufenden Betrieb BusLogic1 durch BusLogic2, BusLogic2 durch BusLogic3 usw. ersetzen).
-
Bei virtuellen Maschinen mit Windows NT-Gastbetriebssystemen ist die Bestätigung einer Warnmeldung erforderlich, die generiert wird, wenn die virtuelle Maschine ein automatisches Upgrade der VMware Tools versucht
Wenn Sie die Option festlegen, automatisch vor jedem Einschaltvorgang für Windows NT-Gastbetriebssysteme VMware Tools zu prüfen und zu Upgrade, erscheint die folgende Warnmeldung: Automatische Installation des VMXNet-Treibers fehlgeschlagen. Dieser Treiber muss manuell installiert werden
Umgehung: Das Upgrade wird so lange angehalten, bis die Warnung bestätigt wird. Melden Sie sich beim Windows NT-Gastbetriebssystem an und bestätigen Sie die Warnmeldung, um das Upgrade abzuschließen.
-
Beim Erstellen einer virtuellen Maschine von Ubuntu 7.10 Desktop wird möglicherweise ein schwarzer Bildschirm angezeigt
Wenn Sie die Installation für das Ubuntu 7.10 Desktop-Gastbetriebssystem auf einer virtuellen Maschine mit aktivierter Paravirtualisierung auf einem AMD-Host ausführen, bleibt der Bildschirm der virtuellen Maschine möglicherweise leer. Das korrekte Verhalten ist, dass das Installationsprogramm Ihnen die Anweisungen gibt, die CD aus dem Laufwerk zu entfernen und die Eingabetaste zu drücken.
Umgehung: Drücken Sie die Eingabetaste. Die Installation wird fortgesetzt und die virtuelle Maschine neu gestartet. Außerdem tritt dieser Fehler nicht auf, wenn Sie die Installation auf einer virtuellen Maschine mit zwei oder mehr virtuellen Prozessoren starten.
-
Ein automatisches Upgrade der VMware Tools schlägt für eine virtuelle Maschine unter Red Hat Enterprise Linux 5.x möglicherweise fehl
Ein automatisches Upgrade der VMware Tools schlägt schlägt möglicherweise für eine virtuelle Maschine unter Red Hat Enterprise Linux 5.x fehl, die mittels Cold-Migration von einem ESX 3.0.3-Host auf einen ESX/ESXi 4.0 Update 1-Host migriert wurde. Folgender Fehler tritt auf: Fehler beim Aktualisieren der VMware Tools.
Umgehung: Upgrade Sie VMware Tools auf dem ESX 4.0 Update 1-Host manuell.
-
Auf Windows 7-Gastbetriebssystemen wird der Videoausgang möglicherweise nicht korrekt angezeigt *
Windows Media Player auf einem Windows 7-Gastbetriebssystem zeigt möglicherweise Videodateien nicht korrekt an, wenn das Video skaliert ist.
Umgehung: Als Umgehung für dieses Problem können Sie eine der folgenden Aktionen ausführen:
- Spielen Sie das Video im Vollbildmodus ab (ALT + EINGABETASTE).
- Deaktivieren Sie Bei Größenänderung Video an Player anpassen.
-
Die virtuelle Maschine schlägt u. U. unter den Gastbetriebssystemen Windows 7 oder Windows Server 2008 R2 in ganz bestimmten Situationen fehl, wenn Windows Media Player verwendet wird
VMware unterstützt Windows Media Player auf beiden Versionen von Windows 7 (32 und 64 Bit) und Windows Server 2008 R2. In seltenen Fällen kann es jedoch zu einem Absturz der virtuellen Maschine kommen, wenn im Programmfenster von Windows Media Player ein Video wiedergegeben wird und das Fenster maximiert wird.
-
Timer-Interrupts werden mit hoher Frequenz an das VMI-fähige Gastbetriebssystem übertragen *
Ein Problem im VMI-Timer (Virtual Machine Interface) führt dazu, dass Timer-Interrupts mit hoher Frequenz an das Gastbetriebssystem übertragen werden. Dieses Problem tritt möglicherweise nach einer VMotion-Migration einer virtuellen Maschine auf, die für eine relativ lange Zeit, z. B. seit 100 Tagen, aktiv war.
Internationalisierung
Lizenzierung
Sonstige Probleme
-
Das Beenden oder der Neustart des vCenter Server-Dienstes über das Windows Services Control MMC-Plug-In kann zu einer Fehlermeldung führen
Unter bestimmten Bedingungen dauert das Starten des vCenter Server-Dienstes möglicherweise länger als gewöhnlich. Das Beenden und der Neustart des vCenter Server-Dienstes über das Windows Services Control MMC-Plug-In kann zur folgenden Fehlermeldung führen: Dienst konnte nicht in angemessener Zeit reagieren
.
Diese Meldung bedeutet, dass die für das Herunterfahren oder Starten von vCenter Server erforderliche Zeit den standardmäßig konfigurierten, systemweiten Zeitüberschreitungswert zum Beenden und Starten von Diensten überschritten hat.
Umgehung: Upgrade Sie nach ein paar Minuten den Bildschirm für die Dienstesteuerung. Es sollte nun angezeigt werden, dass der Dienst ordnungsgemäß gestoppt und neu gestartet wurde.
Netzwerk
-
VLAN-Tagging funktioniert nicht in SLES10-Gastbetriebssystemen, wenn Oplin-Netzwerkkarten im Passthrough-Modus (FPT) verwendet werden
Dieses Problem tritt auf, wenn ein Oplin 10GB-Adapter einer virtuellen Maschine zugewiesen wird, die das SUSE Enterprise Linux 10 (SLES10) 32-Bit- oder 64-Bit-Gastbetriebssystem als FPT-Gerät (fixed passthrough) ausführt, und das Gastbetriebssystem zur Durchführung von VLAN-Tagging konfiguriert ist. In einem solchen Fall verschlechtert sich der TCP-Verkehr und ein Aufruf von netperf
wird vorzeitig mit einer Fehlermeldung beendet. Der ICMP-Verkehr geht noch durch und Sie können noch pingen. Umgehung: Führen Sie tcpdump
aus, während der TCP-Verkehr noch aktiv ist. Durch das Ausführen von tcpdump
wird die Netzwerkkarte in den Promiscuous-Modus versetzt. Dies stellt sicher, dass der Verkehr ordnungsgemäß fließt. Dabei werden aber sehr viele CPU-Zyklen auf dem Gastbetriebssystem konsumiert.
-
Der ESX-Host wird getrennt, falls Sie die sekundäre Servicekonsole entfernen, wenn sich beide vSwitches in demselben Subnetz befinden
Der Host wird mit einer Fehlermeldung getrennt, wenn Sie die folgenden Schritte durchführen:
- Eine sekundäre Servicekonsole hinzufügen
- Das Gateway-Gerät der Servicekonsole ändern
- Das Gateway-Gerät auf die primäre Servicekonsole zurücksetzen
- Die sekundäre Servicekonsole entfernen
Umgehung: Keine
-
NetXen-Chipset bietet keine Hardwareunterstützung für VLANs
Die NetXen-Netzwerkkarte zeigt keine Hardwareunterstützung für VMNET_CAP_HW_TX_VLAN und VMNET_CAP_HW_RX_VLAN an. Dies liegt daran, dass der NetXen-Chipset keine Hardwareunterstützung für VLANs bietet. NetXen-VLAN-Unterstützung ist auf Softwarebasis verfügbar.
-
Bei der benutzerdefinierten Erstellung einer virtuellen Maschine können maximal vier Netzwerkkarten hinzugefügt werden
Während der Erstellung einer virtuellen Maschine mit der Option "Benutzerdefiniert" zeigt der vSphere-Client den Konfigurationsbildschirm "Netzwerk" an. Auf diesem Bildschirm werden Sie aufgefordert, die Anzahl an Netzwerkkarten anzugeben, die verbunden werden sollen. Im Dropdown-Menü können maximal vier Netzwerkkarten ausgewählt werden. Mit ESX/ESXi 4.0 Update 1 werden jedoch 10 Netzwerkkarten unterstützt.
Umgehung: Sie können weitere Netzwerkkarten hinzufügen, indem Sie den folgenden Vorgang ausführen.
-
- Navigieren Sie mithilfe des vSphere-Clients zu Home> Bestandsliste> VMs und Vorlagen.
- Klicken Sie bei ausgewählter Registerkarte "Erste Schritte" auf "VM-Einstellungen bearbeiten".
- Klicken Sie auf "Hinzufügen".
- Wählen Sie "Ethernet-Adapter" und klicken Sie auf "Weiter".
- Fahren Sie mit der Auswahl der geeigneten Einstellungen für Ihr Szenario fort.
-
Adressen können dem ESX-Servicekonsolenport nach einem Neustart nicht zugewiesen werden
Wenn bei einem Servicekonsolenport weder statische IPv4/IPv6-Adressen konfiguriert noch automatische Konfigurationsmethoden (DHCP, DHCP6 oder AUTOCONF) aktiviert sind, befindet sich der Port nach einem Neustart in einem ungültigen Zustand und Sie können dieser Schnittstelle keine Adressen zuweisen. Umgehung: Konfigurieren Sie eine statische IP-Adresse (IPv4 oder IPv6) oder richten Sie einen Servicekonsolenport für die Verwendung der automatischen Adressgenerierungsmethode (z. B. DHCP, DHCP6 oder AUTOCONF) vor dem Neustart ein. Sie können auch nach einem Neustart den Servicekonsolenport neu erstellen.
-
Die VmwVmNetNum des VM-INFO MIB wird als Ethernet0 angezeigt, wenn "snmpwalk" ausgeführt wird
Wenn "snmpwalk" für VM-INFO MIB auf einem ESX/ESXi-Host ausgeführt wird, wird die VmwVmNetNum des VM-INFO MIB als Ethernet0 statt Netzwerkadapter1 angezeigt, während die MOB-URL in der Beschreibung für VmwVmNetNum des VM-INFO als Netzwerkadapter1 angezeigt wird. Umgehung: Keine
-
Anwendungen, die VMCI-Sockets verwenden, schlagen nach der VM-Migration möglicherweise fehl
Wenn Sie Anwendungen haben, die VMCI-Sockets (Virtual Machine Communication Interface) verwenden, schlagen die Anwendungen nach einer VM-Migration möglicherweise fehl, wenn die von der Anwendung verwendeten VMCI-Kontextbezeichner bereits auf dem Zielhost verwendet werden. In diesem Fall funktionieren die auf dem ursprünglichen Host erstellten VMCI-Stream- oder Datagram-Sockets nicht mehr ordnungsgemäß. Zudem wird es unmöglich, neue Stream-Sockets zu erstellen. Umgehung: Laden Sie bei Windows-Gastbetriebssystemen den Gast-VMCI-Treiber neu, indem Sie das Gastbetriebssystem neu starten oder das Gerät über den Gerätemanager aktivieren. Beenden Sie bei Linux-Gastbetriebssystemen alle Anwendungen, die VMCI-Sockets verwenden, entfernen und laden Sie das vsock-Kernelmodul neu und starten Sie die Anwendungen erneut.
-
Das Anwenden von Portgruppen mit mehreren statisch zugewiesenen VMKNICs oder VSWIFs führt zu wiederholten Aufforderungen zur Angabe einer IP-Adresse
Das Anwenden einer vDS-Portgruppe mit mehreren statisch zugewiesenen VMKNICs oder VSWIFs führt dazu, dass der Benutzer wiederholt zur Angabe einer IP-Adresse aufgefordert wird. Über DHCP zugewiesene Schnittstellen sind davon nicht betroffen. Umgehung: Verwenden Sie nur eine statisch zugewiesene VMKNIC oder VSWIF pro Portgruppe. Wenn auf derselben vDS-Portgruppe mehrere statisch zugewiesene VMKNICs gewünscht werden, weisen Sie jede VMKNIC oder VSWIF einer eindeutigen Gruppe von Diensten (z. B. VMotion, Fehlertoleranz und anderen Diensten) zu.
-
Die Konsole für das Gastbetriebssystem fällt aus und Sie können über die Konsole nicht auf das Gastbetriebssystem zugreifen, wenn Sie für einen verteilten vNetwork-Switch oder einen vSwitch, der über die Servicekonsolen- oder die Verwaltungsnetzwerk-Portgruppe verfügt, den MTU-Wert auf weniger als 1500 festlegen
Wenn Sie für den verteilten vNetwork-Switch oder den vSwitch, der die Servicekonsolen-Portgruppe für ESX oder die Verwaltungsnetzwerk-Portgruppe für ESXi Embedded enthält, den MTU-Wert auf weniger als 1500 festlegen, fällt die Konsole für das Gastbetriebssystem aus und Sie können über die Konsole nicht auf das Gastbetriebssystem zugreifen. Die Servicekonsolen-Portgruppe für ESX und die Verwaltungsnetzwerk-Portgruppe für ESXi Embedded müssen mit einem vSwitch oder einem verteilten vNetwork-Switch verbunden sein, dessen MTU-Einstellung 1500 oder höher ist. Umgehung: Legen Sie die für den verteilten vNetwork-Switch oder den vSwitch, der die Servicekonsolen-Portgruppe für ESX oder die Verwaltungsnetzwerk-Portgruppe für ESXi Embedded enthält, den MTU-Wert nicht auf weniger als 1500 fest.
-
Das Abrufen von DNS- und Hostnamensinformationen vom DHCP-Server kann verzögert oder verhindert werden
-
Bei einem Upgrade von ESX 3.5-Hosts auf ESX 4.0 laden einige der Netzwerkgeräte den Treiber e1000e anstelle des Treibers e1000 *
Wenn Hosts vom Typ ESX 3.5 Update 4 oder ESX 3.5 Update 5 ein Upgrade auf ESX 4.0 oder höher herhalten, wird bei den folgenden Netzwerkgeräten der Treiber e1000e anstelle des Treibers e1000 geladen:
- Intel 82571EB Gigabit Ethernet Controller (einschließlich 105e, 105f, 1060, 10a4, 10a5, 10bc)
- Intel 82572EI Gigabit Ethernet Controller (einschließlich 107d, 107e, 107f, 10b9)
- Intel 82573V Gigabit Ethernet Controller (einschließlich 108b)
- Intel 82573E Gigabit Ethernet Controller (einschließlich 108c)
- Intel 80003ES2LAN Gigabit Ethernet Controller (einschließlich 1096, 1098, 10ba, 10bb)
- Intel 82573L Gigabit Ethernet Controller (einschließlich 109a)
-
Das Ändern der Netzwerkeinstellungen eines ESX/ESXi-Hosts verhindert, dass manche Software zur Überwachung des Hardwarestatus den Host automatisch erkennen kann
Nach dem Ändern der Netzwerkeinstellungen eines ESX/ESXi-Hosts sind die Drittanbieter-Management-Tools, die auf der CIM-Schnittstelle basieren (in der Regel die Hardwarestatus-Überwachungs-Tools), nicht in der Lage, anhand des Service Location Protocol-Dienstes (SLP) den Host automatisch zu erkennen.
Umgehung: Geben Sie den Hostnamen oder die IP-Adresse des Hosts manuell in das Drittanbieter-Management-Tool ein. Alternativ können Sie slpdund sfcbd-watchdogneu starten, indem Sie die entsprechende Methode verwenden:
Auf ESXi:
- Aktivieren Sie den Technical Support-Modus.
- Starten Sie slpdneu, indem Sie den Befehl /etc/init.d/slpd restartausführen.
- Starten Sie sfcbd-watchdogneu, indem Sie den Befehl /etc/init.d/sfcbd-watchdog restartausführen.
Starten Sie die Verwaltungsagenten im Direct Console User Interface (DCUI) neu. Dadurch werden zusätzlich zu den Agenten, die von diesem Defekt betroffen sind, weitere Agenten auf dem Host neu gestartet, was sich noch störender auswirken kann.
Auf ESX: Führen Sie in der ESX-Servicekonsole die folgenden Befehle aus:
/etc/init.d/slpd restart
/etc/init.d/sfcbd-watchdog restart
-
Virtuelle Maschinen verlieren die Netzwerkkonnektivität, wenn sie auf einen ESX-Host mit der Standardanzahl von Ports migriert werden
Standardmäßig wird die ESX-Servicekonsole mit einem virtuellen Switch mit nur 24 Ports installiert. Wenn virtuelle Maschinen auf einen Host migriert werden und die Anzahl der erforderlichen Ports die Standardanzahl übersteigt, verlieren manche virtuellen Maschinen möglicherweise die Netzwerkkonnektivität. Dies kann auftreten, wenn virtuelle Maschinen manuell migriert werden oder bei Notfallwiederherstellungsszenarien und Migrationen mit VMotion.
Umgehung: Nach dem Installieren ändern Sie vSwitch0, sodass er eine große Anzahl von Ports hat, indem Sie die Switch-Eigenschaften bearbeiten. ESX 4.0 und höher unterstützen bis zu 56 Ports auf einem virtuellen Switch.
Serverkonfiguration
-
Hostprofile erfassen und duplizieren keine Duplexinformationen von physischen Netzwerkkarten
Wenn Sie ein neues Hostprofil erstellen, werden die Duplexinformationen der physischen Netzwerkkarte nicht erfasst. Dies ist das beabsichtigte Verhalten. Wenn daher das Profil des Referenzhosts verwendet wird, um andere Hosts zu konfigurieren, wird die Duplexkonfiguration pro physischer Netzwerkkarte ausgehandelt. Somit können Sie Hosts mit einer Vielzahl von Funktionen der physischen Netzwerkkarte generisch behandeln. Umgehung: Ändern Sie das Hostprofil, nachdem es erstellt wurde, und wenden Sie die Parameter neu an, um einheitlich über alle Netzwerkkarten und Hosts hinweg, die unter Verwendung des Referenz-Hostprofils konfiguriert werden sollen, den Duplexwert der physischen Netzwerkkarte festzulegen.
Führen Sie zum Bearbeiten des Profils die folgenden Schritte aus.
- Klicken Sie auf der Startseite des vSphere-Clients auf Hostprofile.
- Wählen Sie das Hostprofil aus der Bestandsliste aus, klicken Sie auf die Registerkarte "Übersicht" und klicken Sie anschließend auf Profil bearbeiten.
- Wählen Sie Netzwerkkonfiguration > Konfiguration der physischen Netzwerkkarte > Bearbeiten.
- Wählen Sie im Dropdown-Menü "Feste Konfiguration der physischen Netzwerkkarte" aus und geben Sie die Geschwindigkeit und die Duplexinformationen ein.
Speicher
-
Wenn Sie die PSP_RR-Pfadauswahlrichtlinie mit Failover-Clustering verwenden, treten Probleme bei gemeinsam genutzten Festplatten auf und der Cluster funktioniert möglicherweise nicht
Das Failover-Clustering führt SCSI-3-Reservierungen auf gemeinsam genutzten Festplatten durch. Das Senden einer SCSI-3-Reservierung entlang eines Pfads erlaubt es dem Cluster, SCSI-3-Reservierungen nur auf diesem Pfad vorzunehmen. Wenn später PSP_RR auf einen anderen Pfad wechselt, kann das Failover-Clustering möglicherweise keine Reservierung vornehmen oder andere SCSI-3-Befehle verwenden, die von der Reservierung abhängen. Umgehung: Stellen Sie Geräte, die für gemeinsam genutzte Festplatten verwendet werden, nicht auf PSP_RR um. Verwenden Sie stattdessen je nach Standardwert für das Array die PSP_MRU- oder PSP_FIXED-Richtlinien.
-
Das Hinzufügen eines QLogic iSCSI-Adapters zu einem ESX/ESXi-System schlägt fehl, wenn ein vorhandenes Ziel mit demselben Namen, aber mit einer anderen IP-Adresse, vorhanden ist
Das Hinzufügen eines statischen Ziels für einen QLogic Hardware-iSCSI-Adapter schlägt fehl, wenn ein Ziel mit demselben iSCSI-Namen bereits vorhanden ist, auch dann, wenn sich die IP-Adressen unterscheiden. Sie können einen Qlogic iSCSI-Adapter auf einem ESX/ESXi-System nur mit einem eindeutigen iSCSI-Namen für ein Ziel installieren, jedoch nicht mit einer Kombination aus IP und iSCSI-Namen. Zudem unterstützen der Treiber und die Firmware nicht mehrere Sitzungen, die auf denselben Speicherendpunkt zugreifen.
Umgehung: Keine. Verwenden Sie nicht denselben iSCSI-Namen, wenn Sie Ziele hinzufügen.
-
Die ESX-Servicekonsole erkennt keine Änderungen an, die zur Laufzeit an der LUN-Größe vorgenommen werden
Wenn Änderungen an der Größe der LUN vorgenommen werden, die Ihrem ESX-Host zur Verfügung steht, wird die neue Größe vom VMkernel so erkannt, dass VMFS und virtuelle Maschinen die neue Größe verwenden können. Die Servicekonsole zeigt jedoch die alte Größe noch so lange an, bis Sie den Host neu gestartet haben. Dies liegt daran, dass die Servicekonsole die Gerätekapazität nur beim anfänglichen Gerätetest abruft. Umgehung: Starten Sie den ESX 3-Host neu. Falls Sie nicht neu starten möchten, führen Sie die folgenden Schritte aus:
- Stellen Sie sicher, dass die LUN nicht vom Host verwendet wird.
- Maskieren Sie die LUN vom Host aus.
- Prüfen Sie vom vSphere-Client aus den Speicheradapter erneut, den der Host zum Zugreifen auf die LUN verwendet.
- Heben Sie die Maskierung der LUN auf und sorgen Sie dafür, dass der Host auf sie zugreifen kann.
- Führen Sie eine erneute Prüfung des Speicheradapters durch.
Jetzt zeigt die Servicekonsole die richtige LUN-Größe an.
-
ESX wird manchmal von einem Clariion-iSCSI-Speichersystem nicht gestartet
Wenn Sie von iSCSI starten, startet Ihr ESX-Host möglicherweise nicht, wenn das Clariion-Speichersystem verwendet wird. Dies liegt daran, dass der QLogic Adapter SP versucht, von dem Standby-SP auf dem Clariion-Speicher zu starten, und den aktiven SP nicht korrekt erkennt. Umgehung: Stellen Sie sicher, dass die primären und die alternativem Start-LUNs im QLogic-BIOS auf unterschiedliche SPs auf dem Clariion-Speicher eingestellt sind. Falls dieses Problem weiterhin auftritt, ändern Sie die Reihenfolge der Start-LUNs.
-
In seltenen Fällen schlagen Vorgänge, die sich mit VMFS-Änderungen befassen, nach wiederholten SAN-Pfad-Failovern möglicherweise für alle ESX/ESXi-Hosts, die auf eine bestimmte LUN zugreifen, fehl.
In seltenen Fällen schlagen nach wiederholten Pfad-Failovern auf eine bestimmte SAN-LUN möglicherweise Versuche fehl, auf allen ESX/ESXi-Hosts, die auf diese LUN zugreifen, Vorgänge durchzuführen, wie z. B. das Erstellen eines VMFS-Datenspeichers, VMotion usw. Folgende Warnungen erscheinen in den Protokolldateien aller betroffenen Hosts:
-
I/O failed due to too many reservation conflicts.
-
Reservation error: SCSI reservation conflict
Falls Sie die Reservierungskonfliktmeldungen auf allen Hosts sehen, die auf die LUN zugreifen, bedeutet dies, dass das Problem durch die SCSI-Reservierungen für die LUN, die nicht vollständig aufgeräumt wurde, verursacht wird.
Umgehung: Führen Sie von einem beliebigen System im Cluster aus den folgenden Befehl zum Zurücksetzen der LUN aus, um die SCSI-Reservierung zu entfernen:
vmkfstools -L lunreset /vmfs/devices/disks/
-
NAS-Datenspeicher geben den verfügbaren Speicherplatz falsch wieder
Wenn Sie den verfügbaren Speicherplatz für einen ESX/ESXi-Host mithilfe des Befehls df
(ESXi) oder vdf
(ESX) in der Host-Servicekonsole anzeigen lassen, handelt es sich bei dem gemeldeten Speicherplatz für ESX/ESXi-NAS-Datenspeicher um freien Speicherplatz und nicht um verfügbaren Speicherplatz. Der Speicherplatz von NFS-Volumes, der in der Spalte "Frei" angegeben wird, wenn Sie Speicher > Datenspeicher auf der Registerkarte Konfiguration des vSphere-Clients wählen, zeigt auch den freien Speicherplatz an, nicht den verfügbaren Speicherplatz. In beiden Fällen kann sich der freie von dem verfügbaren Speicherplatz unterscheiden. ESX-Dateisysteme unterscheiden nicht zwischen freien und verfügbaren Blöcken, sondern melden immer freie Blöcke für beide Blocktypen (genau genommen die Felder "f_bfree" und "f_bavail" der struct "statfs"). Freie und verfügbare Blöcke können sich bei NFS-Volumen unterscheiden.
Umgehung: Sie können korrekte Informationen hinsichtlich des verfügbaren Speicherplatzes von NFS-Servern abrufen. Für ESX/ESXi gibt es keine Umgehung.
-
Harmlose Warnmeldungen zu Bereichskonflikten werden in den VMkernel-Protokollen für manche IBM-Server protokolliert
Wenn der SATA/IDE-Controller im PCI-Konfigurationsbereich im Legacy-PCI-Modus arbeitet, wird möglicherweise eine Fehlermeldung ähnlich der Folgenden zu den VMkernel-Protokollen hinzugefügt:
WARNUNG: vmklinux26: __request_region: Diese Meldung wurde einmal wiederholt: Region conflict @ 0x0 => 0x3
Umgehung: Solche Fehlermeldungen sind harmlos und können bedenkenlos ignoriert werden.
-
Das Gewähren von Berechtigungen zum Ändern eines Datenspeichers ermöglicht Benutzern, systemverwandte Dateien zu ändern
Durch das Gewähren aller Berechtigungen zum Ändern von Datenspeichern wird es Benutzern ermöglicht, die Systemdateien auf dem lokalen ESX-Datenspeicher zu ändern, einschließlich der Servicekonsolen-VMDK-Datei ( esxconsole.vmdk
). Diese Datei befindet sich im Ordner /esxconsole-
in einem Datenspeicher. Falls ein Benutzer den Ordner esxconsole
oder die VMDK-Datei umbenennt, kann der ESX-Host nicht neu starten. Umgehung: Sorgen Sie dafür, dass nur Administratoren Datenspeicher ändern dürfen. Stellen Sie sicher, dass sich diejenigen Benutzer, die berechtigt sind, Datenspeicher zu ändern, über die Probleme, die auftreten können, wenn der Ordner esxconsole
oder die Datei esxconsole.VMDK
umbenannt wird, im Klaren sind.
-
Wenn der Speicherprozessor eines HP MSA2012fc-Speicher-Arrays zurückgesetzt wird, werden fälschlicherweise kritische Warnungen ausgegeben *
Beim Zurücksetzen des Speicherprozessors des HP MSA2012fc-Speicher-Arrays sendet das ESX/ESXi NMP-Modul (Native Multipathing) Warnungen oder kritische Einträge an die VMkernel-Protokolle. Diese Warnmeldungen geben an, dass das physische Medium für das Gerät geändert wurde. Diese Meldungen treffen jedoch nicht für alle LUN-Typen zu. Sie sind nur kritisch für Daten-LUNs, gelten jedoch nicht für Verwaltungs-LUNs.
Umgehung: Das Problem kann nicht umgangen werden. In diesem Szenario können Sie beruhigt die protokollierten Warnungen ignorieren, sofern sie sich auf Verwaltungs-LUNs beziehen.
-
Eine virtuelle Maschine kann beim Zurücksetzen der SCSI-LUNs eine Endlosschleife verursachen, die das Herunterfahren der virtuellen Maschine verhindert *
Wenn SCSI-Treiber (entweder BusLogic oder LSI Logic) einer virtuellen Maschine die LUNs aus irgendwelchen Gründen zurücksetzen, kann dies eine Endlosschleife verursachen.
Versuche, die virtuelle Maschine abzuschießen, verlaufen nicht erfolgreich.
-
Das Gastbetriebssystem meldet E/A-Fehler in Bezug auf LSI-Controller*
Online-Upgrades der Controller-Firmware auf einem Array mit einem LSI-Controller können möglicherweise E/A-Ausfälle auf virtuellen Maschinen verursachen, die auf den Array zugreifen. Viele Arrays verwenden einen LSI-Controller. Bei der folgenden Liste handelt es sich beispielsweise um einige gängige Arrays, die LSI-Controller einsetzen:
- IBM DS48xx Serie
- IBM DS 3xxx Serie
- Dell MD3xxx Serie
- Sun STK Flexline Serie
Umgehung: Bevor Sie die Firmware auf einem Speichercontroller aktualisieren, leiten Sie von Hand alle LUNs auf den anderen Speichercontroller um und stellen Sie sicher, dass der ESX/ESXi-Host keine E/A an den Speichercontroller sendet.
-
Die Befehle der Servicekonsole liefern möglicherweise irreführende Informationen über die Cisco UCS Qlogic FCoE-Controller *
Auf Cisco Unified Computing-Systemen (UCS) mit einem Qlogic FCoE-Controller wird über die Befehle der Servicekonsole esxcfg-scsidevs -aund lspcimöglicherweise nicht der Controller als ein Qlogic FCoE-Controller, sondern als Fibre-Channel-Controller identifiziert.
Beispielsweise werden in der Ausgabe der folgenden Befehle der Servicekonsole die Cisco UCS Qlogic FCoE-Controller nicht ausdrücklich als FCoE-Controller identifiziert.
- Der Befehl lspcifür Cisco UCS Qlogic FCoE Controller:
04:00.0 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03)
04:00.1 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03)
- Der Befehl esxcfg-scsidevs -afür Cisco UCS Qlogic FCoE-Controller:
vmhba1 qla2xxx link-up fc.20010025b500000a:20000025b500001a (0:4:0.0) QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA
vmhba2 qla2xxx link-up fc.20010025b500000a:20000025b500000a (0:4:0.1) QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA
Unterstützte Hardware
-
Es werden keine CIM-Alarme empfangen, wenn das Stromkabel und das Netzteil neu an HP-Server angeschlossen werden
Es werden keine neuen SEL(IML)-Einträge für das erneute Anschließen des Stromkabels und des Netzteils auf HP-Servern erstellt, wenn eine unterbrochene Stromversorgung wiederhergestellt wird. Dies führt dazu, dass keine CIM-Alarme für diese Ereignisse generiert werden. Umgehung: Keine
-
ESX/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 dieser Hosts laufen möglicherweise beim Einschalten von virtuellen Maschinen oder bei Festplatten-E/A-Vorgängen langsam. Die 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 256 MB große Cache Upgrade-Modul der HP P-Serie.
-
Auf bestimmten Versionen des vSphere-Clients wird der Status des Akkus möglicherweise falsch als alarmierend angezeigt
Wenn sich der Akku im Lernmodus befindet, wird im vSphere-Client auf der Registerkarte "Hardwarestatus" eine Alarmmeldung angezeigt, die angibt, dass der Status des Akkus nicht in Ordnung ist. Allerdings ist der Ladezustand des Akkus in Ordnung.
Umgehung: Keine.
-
Die Meldung "Detected Tx Hang" wird in der VMkernel-Protokolldatei angezeigt
Einige Varianten der e1000-Netzwerkkarten blockieren aufgrund von Hardwarefehlern unter Volllast. ESX/ESXi erkennt das Problem und setzt die Karte automatisch zurück. Dieses Problem steht im Zusammenhang mit Tx-Paketen, TCP-Arbeitslasten und TCP Segmentation Offloading (TSO).
Umgehung: Sie können TSO deaktivieren, indem Sie in der Datei esx.confdie Option /adv/Net/UseHwTSOauf 0 setzen.
Upgrade und Installation
-
Der Datenbank-Upgrade-Assistent des vCenter Server-Systems schätzt während eines Upgrades von VirtualCenter 2.0.x auf vCenter Server 4.0 den erforderlichen Festplattenspeicher möglicherweise als zu hoch ein
Während eines Upgrades von VirtualCenter 2.0.x auf vCenter Server 4.0 kann der Datenbank-Upgrade-Assistent einen falschen Wert für den erforderlichen Festplattenspeicher anzeigen. In der Regel ist die angezeigte Schätzung höher als der tatsächlich erforderliche Speicherplatz. Umgehung: Keine
-
Die Installation des vSphere-Clients schlägt möglicherweise mit dem Fehler 1603fehl, wenn Sie nicht über eine aktive Internetverbindung verfügen
Sie können den vSphere-Client auf zwei Arten installieren: Vom vCenter Server-Medium aus oder indem Sie auf einen Link im ESX-, ESXi- oder vCenter Server-Begrüßungsbildschirm klicken. Das Installationsprogramm auf dem vCenter Server-Medium (.iso-Datei oder .zip-Datei) enthält zusätzlich zum vSphere-Client-Installationsprogramm ein vollständiges .NET-Installationsprogramm. Das Installationsprogramm, das über den Begrüßungsbildschirm aufgerufen wird, enthält ein vSphere-Client-Installationsprogramm, das die .NET-Installationsprogrammkomponenten aus dem Internet abruft. Wenn Sie über keine Internetverbindung verfügen, schlägt die zweite vSphere-Client-Installationsmethode mit dem Fehler 1603fehl, es sei denn, .NET 3.0 SP1 ist bereits auf Ihrem System installiert.
Umgehung: Richten Sie eine Internetverbindung ein, bevor Sie den Download versuchen, installieren Sie den vSphere-Client vom vCenter Server-Medium aus oder installieren Sie .NET 3.0 SP1, bevor Sie auf den Link auf dem Begrüßungsbildschirm klicken.
-
Einige Kickstart-Befehle für Skriptinstallationen von ESX 4.0 sind veraltet oder werden in dieser Version nicht unterstützt
Falls Ihr Installationsskript nicht mit ESX 4.0 funktioniert, enthält es möglicherweise veraltete oder nicht unterstützte Befehle. Die folgenden Kickstart-Befehle sind veraltet: autostep
clearpart --linux
clearpart --exceptvmfs
cmdline
device
deviceprobe
firewall --enabled
firewall --disabled
(ersetzt durch firewall --allowIncoming und firewall
--allowOutgoing
)
firstboot
harddrive
ignoredisk
interactive
lang
(Die Standardeinstellung wird verwendet.)
langsupport
(Die Standardeinstellung wird verwendet.)
lilo
lilocheck
logvol
mouse
part --onvmdk
raid
skipx
text
vmaccepteula
(heißt jetzt accepteula
)
vnc
volgroup
xconfig
xdisplay
%packages
(Die neue Methode zum Anpassen von Paketen besteht in der Verwendung von packages.xml)
%vmlicense_text
Die nachfolgenden Red Hat Enterprise Linux 3-Befehle werden nicht unterstützt:
autostep
cmdline
device
deviceprobe
firewall --blockIncoming
firewall --blockOutgoing
firstboot
harddrive
ignoredisk
interactive
lang
langsupport
lilo
lilocheck
logvol
mouse
raid
skipx
text
vnc
volgroup
xconfig
xdisplay
Workaround: Verwenden Sie nur die Kickstart-Befehle, die von VMware unterstützt werden. Eine detaillierte Liste der unterstützten Befehle finden Sie im Installationshandbuch – ESX und vCenter Server.
-
Wenn SQL Native Client bereits installiert ist, können Sie vCenter mit der mitgelieferten SQL Server 2005 Express-Datenbank nicht installieren
Wenn Sie vCenter mit der mitgelieferten SQL Server 2005 Express-Datenbank installieren und SQL Native Client bereits installiert ist, schlägt die Installation mit folgender Fehlermeldung fehl: Ein Installationspaket für das Produkt Microsoft SQL Native Client wurde nicht gefunden. Versuchen Sie, die Installation unter Verwendung einer gültigen Kopie des Installationspakets "sqlcli.msi" durchzuführen
.
Umgehung: Deinstallieren Sie SQL Native Client, sofern er nicht von einer anderen Anwendung verwendet wird. Installieren Sie anschließend vCenter mit der mitgelieferten SQL Server 2005 Express-Datenbank.
-
Nach Abbrechen der Deinstallation von vSphere-Client 4.0 kann das Produkt weder neu installiert noch deinstalliert werden
Wurde die Installation des vSphere-Clients abgebrochen, erscheint folgende Fehlermeldung, wenn erneut versucht wird, vSphere Client 4.0 zu installieren bzw. zu deinstallieren: Fehler beim Anwenden einer Transformation. Stellen Sie sicher, dass die angegebenen Transformationspfade gültig sind.
Umgehung: Verwenden Sie das Windows-Dienstprogramm in der Systemsteuerung, um vSphere Client 4.0 zu deinstallieren.
-
Der VMware Web Access-Kickstart-Skriptgenerator wird nicht unterstützt
Der VMware Web Access-Kickstart-Skriptgenerator steht in vSphere 4.0 für eine ESX-Skriptinstallation nicht zur Verfügung. Umgehung: Sie können das Kickstart-Skript verwenden, das automatisch nach einer interaktiven Installation generiert wird. Nach der ersten interaktiven Installation von ESX erstellt das Installationsprogramm ein /root/ks.cfg
-Skript im ESX-Dateisystem. Dieses Skript enthält die Einstellungen, die Sie während der interaktiven Installation vorgenommen haben. Eine vollständige Liste der unterstützten Befehle und ein Beispielskript finden Sie im Installationshandbuch – ESX und vCenter Server.
-
Wenn Sie zum Durchführen eines ESX-Host-Upgrades vSphere Host Update Utility verwenden, schlägt das Upgrade möglicherweise fehl
Wenn Sie zum Durchführen eines ESX-Upgrades vSphere Host Update Utility verwenden, schlägt das Upgrade möglicherweise mit folgendem Fehler fehl: Während des Upgrades ist ein Fehler aufgetreten. Die Verbindung zum Upgrade-Agenten wurde unterbrochen
.
Dies geschieht, wenn das Upgrade zu 26 % abgeschlossen ist. Der Prozess hält in der Servicekonsole bei VMware ESX Server Management-Dienste werden gestoppt
an.
Umgehung: Starten Sie den ESX-Host manuell neu, indem Sie auf die Schaltfläche "Zurücksetzen" klicken. Das ESX-Upgrade setzt sich fort und wird erfolgreich abgeschlossen, aber vSphere Host Update Utility zeigt den Fortschritt nicht an. Klicken Sie zum Anzeigen des aktuellen Hoststatus von vSphere Host Update Utility auf Erneut versuchen.
-
vCenter Server-Datenbank-Upgrade schlägt für Oracle 10gR2-Datenbanken mit bestimmten Benutzerberechtigungen fehl
Wenn Sie VirtualCenter Server 2.x auf vCenter Server Version 4.0 Upgrade und Sie über die Berechtigungen "connect", "create view", "create any sequence", "create any table" und "execute on dbms_lock" für die Datenbank (Oracle 10gR2) verfügen, schlägt das Upgrade fehl. Die Datei VCDatabaseUpgrade.log
zeigt folgenden Fehler: Fehler: Failed to execute SQL procedure. Got exception: ERROR [HY000] [Oracle][ODBC][Ora]ORA-01536: space quota exceeded for tablespace 'USERS'
Umgehung: Vergrößern Sie als Datenbankadministrator den Benutzer-Tablespace oder gewähren Sie dem Benutzer, der das Upgrade durchführt, die Berechtigung "unlimited tablespace".
-
Das Installieren von vCenter Server unter Windows Server 2008 schlägt bei Verwendung eines Benutzerkontos, bei dem es sich nicht um ein Systemkonto handelt, fehl
Wenn Sie während der Installation ein Benutzerkonto angeben, bei dem es sich nicht um ein Systemkonto handelt, schlägt die Installation von vCenter Server mit folgender Fehlermeldung fehl: Setup konnte das vCenter-Repository nicht erstellen
Umgehung: Schalten Sie auf dem System, auf dem vCenter Server installiert wird, unter Systemsteuerung > Benutzerkonten die Option "Benutzerkontensteuerung" aus, bevor Sie vCenter Server installieren. Geben Sie während der vCenter Server-Installation den Nicht-Systembenutzer an.
-
Keine Anmeldung bei VirtualCenter Server 2.5 möglich, nachdem der VI Client 2.0.x, 2.5 und vSphere Client 4.0 auf einem Windows Vista-System installiert wurden und der VI Client 2.0.x deinstalliert wurde
Nach dem Deinstallieren des VI Client 2.0.x auf einer Windows Vista-Maschine, auf der VI Client 2.0.x und 2.5 sowie vSphere Client 4.0 gleichzeitig vorhanden sind, ist keine Anmeldung bei vCenter Server 2.5 möglich. Die Anmeldung schlägt mit folgender Meldung fehl: Klasse nicht registriert (Ausnahme von HRESULT:0x80040154(REGDB_E_CLASSNOTREG))
Umgehung: Deaktivieren Sie die Benutzerkontensteuerung auf dem System, auf dem VI Client 2.0.x, 2.5 und vSphere Client 4.0 zusammen installiert sind, oder deinstallieren Sie den VI Client 2.5 und installieren Sie ihn neu.
-
Das ESX/ESXi-Installationsprogramm führt die lokalen SAS-Speichergeräte im Abschnitt "Remotespeicher" auf
Beim Anzeigen der Speicherorte, in denen ESX oder ESXi Installable installiert wird, führt das Installationsprogramm im Abschnitt "Remotespeicher" ein lokales SAS-Speichergerät auf. Dies liegt daran, dass ESX/ESXi nicht feststellen kann, ob das SAS-Speichergerät lokal oder remote ist. Es wird deshalb immer als remote angesehen. Umgehung: Keine
-
Wenn vSphere Host Update Utility die Netzwerkverbindung zum ESX-Host verliert, funktioniert das Host-Upgrade möglicherweise nicht
Wenn Sie zum Durchführen eines ESX/ESXi-Host-Upgrades das vSphere Host Update Utility verwenden und die Verbindung des Dienstprogramms mit dem Host unterbrochen wird, wird der Host möglicherweise nicht vollständig aktualisiert. Wenn dies geschieht, reagiert das Dienstprogramm möglicherweise nicht mehr oder die folgende Fehlermeldung wird ausgegeben: Fehler beim Ausführen der Kompatibilitätsprüfung auf dem Host.
Umgehung: Schließen Sie das Dienstprogramm, reparieren Sie die Netzwerkverbindung, starten Sie das Dienstprogramm neu und führen Sie das Upgrade erneut aus.
-
Die Ressourcenpooleinstellungen eines ESX-Hosts werden möglicherweise nach einem Upgrade von ESX Server 3.0.x oder ESX Server 3.5.x auf ESX 4.0 nicht beibehalten
Wenn der ESX-Host so konfiguriert ist, dass alle, die meisten oder fast alle verfügbaren Hostkapazitäten in den Ressourcenpooleinstellungen für die CPU- und Arbeitsspeicherreservierung zugeteilt werden, werden nach einem Upgrade von ESX Server 3.0.x oder ESX 3.5.x auf ESX 4.0 die Einstellungen möglicherweise nicht beibehalten. Nach einem Upgrade werden die Reservierungseinstellungen auf Null gesetzt. Dieses Problem betrifft nur eigenständige Hosts. DRS-Cluster sind davon nicht betroffen. Umgehung: Teilen Sie in den Ressourcenpooleinstellungen für die CPU- und Arbeitsspeicherreservierung nicht alle oder nahezu alle verfügbaren Hostkapazitäten zu. Falls Sie es doch tun, notieren Sie vor dem Upgrade die Informationen über die Ressourcenpooleinstellungen auf Hostebene und nach dem Upgrade ändern Sie die Informationen manuell.
-
Der Wert für die nächste Ausführung einiger geplanter Aufgaben wird nach einem Upgrade von VirtualCenter 2.0.2.x auf vCenter Server 4.0 nicht beibehalten
Wenn Sie VirtualCenter 2.0.2.x auf vCenter Server 4.0 Upgrade, wird für einige geplante Aufgaben der Wert für die Nächste Ausführung
möglicherweise nicht beibehalten und die Aufgaben werden möglicherweise unerwartet ausgeführt. Wenn z. B. eine Aufgabe so geplant ist, dass sie jeden Tag um 10 Uhr ausgeführt wird, wird sie nach dem Upgrade möglicherweise um 11.30 Uhr ausgeführt. Dieses Problem tritt auf, weil es Unterschiede zwischen den Methoden gibt, die VirtualCenter 2.0.2.x und vCenter Server 4.0 verwenden, um den Zeitpunkt der nächsten Ausführung zu berechnen. Dieses Verhalten ist nur unter den folgenden Bedingungen sichtbar:
- Sie haben geplante Aufgaben, deren Zeitpunkte für die nächste Ausführung Sie geändert haben, nachdem sie ursprünglich geplant wurden. Sie weisen jetzt einen anderen Zeitpunkt für die
Nächste Ausführung
auf.
- Der neu geplante Zeitpunkt für die
Nächste Ausführung
ist noch nicht eingetreten.
Umgehung: Führen Sie die folgenden Schritte aus:
- Warten Sie vor dem Upgrade, bis die Aufgaben zum Zeitpunkt ihrer
Nächsten Ausführung
ausgeführt werden.
- Nach dem Upgrade von vCenter 2.0.x auf vCenter Server 4.0 bearbeiten und speichern Sie die geplante Aufgabe. Dieser Vorgang berechnet den Zeitpunkt der
Nächsten Ausführung
auf den korrekten Wert neu.
-
Upgrades der Hardware der virtuellen Maschine von Version 4 auf Version 7 führen dazu, dass die Netzwerkeinstellungen von Solaris-Gastbetriebssystemen verloren gehen
Upgrades der Hardware der virtuellen Maschine von Version 4 auf Version 7 ändern die Adresse des PCI-Bus der virtuellen Netzwerkadapter in Gastbetriebssystemen. Solaris erkennt die Adapter nicht und ändert die Nummerierung der Netzwerkschnittstellen (Beispielsweise wird e1000g0 zu e1000g1). Diese Änderung an der Nummerierung tritt ein, weil Solaris-IP-Einstellungen Schnittstellenamen zugeordnet sind, sodass es so aussieht, als ob die Netzwerkeinstellungen verloren gegangen sind und das Gastbetriebssystem nicht über eine ordnungsgemäße Konnektivität verfügt. Umgehung: Verwenden Sie den Befehl prtconf -D
, um nach dem Upgrade der Hardware der virtuellen Maschine die neuen Schnittstellennamen zu ermitteln, und benennen Sie anschließend alle alten Konfigurationsdateien mit deren neuen Namen um. e1000g0 wird beispielsweise e1000g1, sodass jede /etc/*e1000g0
-Datei in das /etc/*e1000g1
-Äquivalent umbenannt wird.
-
Das vCenter Server-Installationsprogramm erkennt keine Service-Ports, wenn die Services nicht ausgeführt werden
Wenn Sie vCenter Server installieren und die Standardports übernehmen, kann das Installationsprogramm die Ports nicht validieren, wenn sie von nicht ausgeführten Services verwendet werden. Die Installation schlägt fehl und je nach verwendetem Port wird möglicherweise eine Fehlermeldung ausgegeben. Dieses Problem betrifft keine IIS-Dienste. IIS-Dienste werden immer korrekt validiert, ob die Services ausgeführt werden oder nicht.
Umgehung: Identifizieren Sie die Ports, die für nicht ausgeführte Services verwendet werden, bevor Sie mit der Installation beginnen, und vermeiden Sie sie.
-
Anwendbare Bulletins werden nicht aufgelistet, wenn die Hostmaschine mithilfe des Befehls "vihostupdate" geprüft wird
Das Prüfen der Hostmaschine mithilfe des Befehls "vihostupdate" für die anwendbaren Bulletins führt dazu, dass nach dem Download der Paket-ZIP-Datei für ESX 4.0 Update 1 nicht alle Bulletins aufgelistet werden, die im Paket enthalten sind.
Umgehung: Verwenden Sie das Dienstprogramm "esxupdate" zum Auflisten der verfügbaren Bulletins im ESX 4.0 Update 1-Paket. Weitere Informationen zum Dienstprogramm "esxupdate" finden Sie im Handbuch für die Patch-Verwaltung von ESX 4.
-
Mit esxupdate wird die neueste Version eines VIB heruntergeladen, wenn die abhängige Version nicht in der Bulletin-Liste verfügbar ist *
Wenn Sie einen Patch auf ESX mit dem Befehl "esxupdate" installieren, lädt der Befehl die neueste Version eines VIB anstelle der speziellen Version herunter, die von der ESX-Installation verwendet wird. Ein derartiges Update wird ausgeführt, wenn die Installation eine bestimmte Version des VIB erfordert, diese Version des VIB jedoch nicht auf der Bulletin-Liste verfügbar ist.
vCenter Server, vSphere-Client und vSphere Web Access
-
Alarme mit den Systemzustand betreffenden Auslösebedingungen werden nicht nach vSphere 4.0 migriert
Die Alarmauslösefunktionalität von vSphere 4.0 wurde erweitert. Sie enthält zusätzliche Alarmauslöser für den Systemzustand des Hosts. Dabei wurde der generische Auslöser "Host-Zustand" entfernt. Daher stehen Alarme, die diesen Auslöser enthalten, in vSphere 4.0 nicht mehr zur Verfügung. Umgehung: Verwenden Sie den vSphere-Client, um die Alarme erneut zu erstellen. Sie können die folgenden vorkonfigurierten VMware-Alarme verwenden, um den Systemzustand des Hosts zu überwachen:
- Batteriestatus des Hosts
- Lüftungsstatus der Hosthardware
- Betriebsstatus der Hosthardware
- Temperaturstatus der Hosthardware
- Status der Hauptplatine der Hosthardware
- Spannung der Hosthardware
- Arbeitsspeicherstatus des Hosts
- Prozessorstatus des Hosts
- Speicherstatus des Hosts
Falls sich der Status, den Sie überwachen möchten, nicht unter den vorkonfigurierten Alarmen befindet, können Sie einen benutzerdefinierten Alarm erstellen, der den Ereignisauslöser "Hardwarestatus geändert" verwendet. Für diesen Ereignisalarm müssen Sie die Auslösebedingungen manuell festlegen. Darüber hinaus müssen Sie manuell einstellen, welche Aktion durchgeführt werden soll, wenn der Alarm ausgelöst wird.
Hinweis: Für die vorkonfigurierten Alarme wurden bereits Standardauslösebedingungen festgelegt. Sie brauchen nur noch einzustellen, welche Aktion bei Alarmauslösung durchgeführt werden soll.
-
Der Web Access-Dienst startet nach beendeter ESX-Installation nicht
Wenn Sie Web Access verwenden, um eine Verbindung zu einem ESX-Host herzustellen, wird die folgende Meldung angezeigt: 503 Service Unavailable
Die Ursache liegt darin, dass der Web Access-Dienst nach Beenden der Installation von ESX nicht automatisch startet.
Umgehung: Führen Sie folgenden Befehl aus, um den Web Access-Dienst auf dem ESX-Host zu starten: service vmware-webAccess start
-
Guided Consolidation kann keine Systeme importieren, auf denen vCenter Converter ausgeführt wird
Bei den Importvorgängen von Guided Consolidation tritt ein Problem auf, wenn auf dem Quellsystem (d. h. auf dem importierten System) vCenter Converter ausgeführt wird. Guided Consolidation importiert das System und versucht, vCenter Converter von dem Quellsystem zu deinstallieren. Der Importvorgang gelingt, aber die folgende Fehlermeldung wird angezeigt, wenn Guided Consolidation versucht, vCenter Converter zu deinstallieren: VMware Converter Agent Install failed
.
Umgehung: Deinstallieren Sie vCenter Converter von den Quellsystemen, bevor Sie versuchen, sie unter Verwendung von Guided Consolidation zu importieren.
-
Webverknüpfungen zu virtuellen Maschinen mit ESX Server 3.5 funktionieren nach einem Upgrade auf ESX 4.0 nicht mehr
Webverknüpfungen, die für virtuelle Maschinen mit ESX Server 3.5 erstellt wurden, sind für die Benutzer nicht mehr zugänglich, wenn Sie ein Upgrade auf ESX 4.0 durchgeführt haben. vSphere Web Access 4.0 unterstützt die URLs für ESX 3.5 nicht. Der Benutzer kann nicht über die URLs, die für ESX Server 3.5 erstellt wurden, auf die virtuellen Maschinen zugreifen. Umgehung: Verwenden Sie vSphere Web Access 4.0, um Webverknüpfungen zu erstellen, die für ESX 4.0 gültig sind, und verteilen Sie diese an Ihre Benutzer. Weitere Informationen über das Erstellen von Webverknüpfungen finden Sie im Administratorhandbuch für vSphere Web Access .
-
Der vSphere-Client aktualisiert keine Sensoren, die physischen Ereignissen zugeordnet sind
Der vSphere-Client aktualisiert Sensorstatus nicht in jedem Fall. Manche Ereignisse können eine Aktualisierung auslösen, z. B. ein fehlerhaftes Netzteil oder die Entfernung einer redundanten Festplatte. Andere Ereignisse, wie das Öffnen des Gehäuses oder das Entfernen eines Lüfters, lösen möglicherweise keine Aktualisierung des Sensorstatus aus. Umgehung: Keine
-
Virtuelle Maschinen verschwinden aus dem Diagramm der virtuellen Switches in der Netzwerkansicht für die Hostkonfiguration
Virtuelle Maschinen werden in der Netzwerkansicht auf der Registerkarte "Konfiguration" des vSphere-Clients für einen Host im Diagramm der virtuellen Switches dargestellt. Wenn Sie einen anderen Host auswählen und dann zur Registerkarte "Konfiguration" des ersten Hosts zurückkehren, verschwinden die virtuellen Maschinen möglicherweise aus dem Diagramm der virtuellen Switches. Umgehung: Wählen Sie auf der Registerkarte "Konfiguration" eine andere Ansicht, z. B. Netzwerkadapter, Speicher oder Speicheradapter, und kehren Sie zur Registerkarte "Netzwerk" zurück.
-
Das Verwenden von Sonderzeichen in den Namen virtueller Maschinen während deren Erstellung ergibt einen Fehler, wenn sie über vSphere Web Access mit vCenter Server verbunden sind
Bei einer Verbindung zu vCenter Server mit vSphere Web Access löst die Verwendung von Sonderzeichen (z. B., "|\'{}[]-*^&@#!`~) im Namen der virtuellen Maschine währen der Erstellung den folgenden Fehler aus:
RuntimeFault: Ein allgemeiner Systemfehler ist aufgetreten.
Umgehung: Keine
-
vSphere Web Access zeigt die falsche Taktrate für die virtuelle Maschine an, nachdem die Anzahl der virtuellen Prozessoren erhöht wurde
In vSphere Web Access werden im Abschnitt "Leistung" der Registerkarte "Übersicht" falsche Informationen zur Taktrate einer ausgewählten virtuellen Maschine angezeigt, nachdem die Anzahl der CPUs für die virtuelle Maschine erhöht wurde. Wenn beispielsweise die Anzahl der CPUs für eine virtuelle Maschine von 1 CPU mit einer Geschwindigkeit von 1,559 Mhz auf 2 CPUs erhöht wird, müsste vSphere Web Access die Anzahl der CPUs und ihre Geschwindigkeit als 2 x 1,559 Mhz anzeigen. Die Taktrate wird jedoch fälschlicherweise mit 3,117 (1,559 x 2) angezeigt. Umgehung: Keine
-
Wenn Sie die Nummer des HTTPS-Ports in der SFCB-Konfigurationsdatei (
sfcb.cfg
) auf einen Port ändern, der nicht der Standardport ist, und den SFCB-Server (CIM) neu starten, erscheint der Systemstatus der Serverkomponenten des ESX/ESXi-Hosts nicht auf der Registerkarte "Hardwarestatus"
Dasselbe passiert, wenn Sie sich direkt an einem ESX/ESXi-Host anmelden und auf die Registerkarte Konfiguration klicken, um den Systemstatus anzuzeigen. Statusinformationen für die Serverkomponenten erscheinen nicht. Dieses Problem tritt auf, weil vCenter Server und der SFCB-Server über verschieden Ports kommunizieren.
Umgehung: Stellen Sie sicher, dass der SFCB-Server nur über den Standardport kommuniziert.
-
Starten oder Beenden des vctomcat-Webservice über die Windows-Eingabeaufforderung führt möglicherweise zu einer Fehlermeldung
Wenn Sie auf Microsoft Windows-Betriebssystemen die Befehle net start
und net stop
verwenden, um den vctomcat-Webservice zu starten bzw. zu beenden, wird möglicherweise die folgende Fehlermeldung angezeigt: Der Dienst reagiert auf die Kontrollfunktion nicht.
Weitere Informationen erhalten Sie, wenn Sie "NET HELPMSG 2186" eingeben.
Umgehung: Sie können diese Fehlermeldung ignorieren. Wenn Sie möchten, dass die Fehlermeldung nicht mehr erscheint, bearbeiten Sie die Registrierung und erhöhen Sie den Zeitüberschreitungswert für den Service Control Manager (SCM). Weitere Informationen finden Sie in folgendem Microsoft-KB-Artikel: http://support.microsoft.com/kb/922918.
-
Überblicksleistungsdiagramme werden nach einem Upgrade von vCenter Server 2.5 mit mitgelieferter SQL Express-Datenbank nicht angezeigt
Wenn Sie ein Upgrade von vCenter Server 2.5 auf vCenter Server 4.0 durchführen und dabei eine SQL Express-Datenbank involviert ist, werden die Überblicksleistungsdiagramme nicht angezeigt. Wenn Sie die Überblicksansicht auf der Registerkarte Leistung öffnen, wird folgender Fehler angezeigt: STATs Report service internal error
Dieser Fehler tritt auf, weil das vCenter Server-Upgrade-Tool die vorhandene Datenbank nicht neu konfigurieren kann. Sie müssen die Konfiguration manuell durchführen.
Umgehung:
- Wählen Sie Start > Programme > SQL Server Configuration Manager.
- Führen Sie im SQL Server Configuration Manager Folgendes aus:
- Wählen Sie Protocols for SQLEXP_VIM (Protokolle für SQLEXP_VIM).
- Wählen Sie TCP/IP.
- Wählen Sie unter "Enabled" True und unter "Listen All" Yes.
- Klicken Sie auf OK.
- Geben Sie in einem Befehlsfenster
Services.msc
ein, um den Dienst-Manager zu öffnen.
- Starten Sie in der Dienstliste die folgenden Dienste:
- SQL Server 2005 Services: SQL Server (SQLEXP_VIM)
- SQL Server 2005 Services: SQL-Browser (wenn der SQL-Browser-Dienst deaktiviert ist, markieren Sie ihn zum automatischen/manuellen Starten)
- VMware vCenter-Dienst
- VMware-Webservice
-
Der Befehl "vc-support" verwendet eine 64-Bit-DSN-Anwendung und kann keine Daten aus der vCenter Server-Datenbank abrufen
Wenn Sie den VMware-Befehl cscript vc-support.wsf
verwenden, um Daten aus der vCenter Server-Datenbank abzurufen, wird die Microsoft-Standardanwendung cscript.exe
verwendet. Diese Anwendung verwendet einen 64-Bit-DSN und keinen 32-Bit-DSN, wie es für die vCenter Server-Datenbank erforderlich wäre. Demzufolge treten Fehler auf und es können keine Daten abgerufen werden. Umgehung: Übergeben Sie an der Eingabeaufforderung des Systems die Datei vc-support.wsf
an die Anwendung cscript.exe
(mit dem 32-Bit DSN) und führen Sie diese aus:
%windir%\SysWOW64\cscript.exe vc-support.wsf
-
Das Menü "vSphere-Client-Rollen" zeigt für keine der vCenter Server-Systeme in einer Gruppe im verknüpften Modus Rollenzuweisungen an
Wenn Sie auf einem vCenter Server-System in einer Gruppe im verknüpften Modus eine Rolle erstellen, werden die vorgenommenen Änderungen an alle anderen vCenter Server-Systeme der Gruppe weitergegeben. Die Rolle wird jedoch nur auf Systemen angezeigt, die über die mit der Rolle zugewiesenen Berechtigungen verfügen. Wenn Sie eine Rolle entfernen, prüft der Vorgang den Status der Rolle nur auf dem aktuell ausgewählten vCenter Server-System. Er entfernt die Rolle jedoch aus allen vCenter Server-Systemen in der Gruppe im verknüpften Modus, ohne dass eine Warnung ausgegeben wird, die darauf hinweist, dass die Rolle möglicherweise auf anderen Servern verwendet wird. Umgehung: Bevor Sie eine Rolle aus dem vCenter Server-System löschen, stellen Sie sicher, dass die Rolle nicht über andere vCenter Server-Systeme hinweg verwendet wird. Wechseln Sie zum Feststellen, ob eine Rolle verwendet wird, zur Ansicht "Rollen" und benutzen Sie die Navigationsleiste, um jedes vCenter Server-System in der Gruppe auszuwählen. Die Verwendung dieser Rolle wird für das ausgewählte vCenter Server-System angezeigt.
Weitere Informationen über Best Practices für Benutzer und Gruppen sowie über das Festlegen von Rollen für vCenter Server-Gruppen im verknüpften Modus finden Sie im vSphere-Handbuch Grundlagen der Systemverwaltung .
-
Das Löschen von Snapshots und das Klonen von virtuellen Maschinen im laufenden Betrieb können bei hoher Arbeitslast der virtuellen Maschine lange dauern
Das Löschen von Snapshots und das Klonen von virtuellen Maschinen im laufenden Betrieb können lange dauern, wenn die virtuelle Maschine eine hohe E/A-Arbeitslast zu bewältigen hat. Wenn die virtuelle Maschine beispielsweise auf ihre lokalen Festplatten schreibt, ist die E/A-Arbeitslast sehr hoch. Umgehung: Vermeiden Sie diese Vorgänge, wenn die virtuelle Maschine auf ihre lokalen Festplatten schreibt oder andere schwere E/A-Arbeitslasten ausführt. Dies kann dazu beitragen, die Durchführungszeiten zu reduzieren.
-
Unter Windows Server 2008 ist nach der Installation das Beitreten zu einer Gruppe im verknüpften Modus nicht erfolgreich, wenn die Benutzerkontensteuerung (UAC) aktiviert ist
Wenn auf Windows Server 2008 mit einem 32- oder 64-Bit-Betriebssystem die Benutzerkontensteuerung (UAC) aktiviert ist und Sie versuchen, auf einem System, auf dem vCenter Server bereits ausgeführt wird, einer Gruppe im verknüpften Modus eine Maschine hinzuzufügen, ist die Verbindung nicht erfolgreich. Es wird jedoch keine Fehlermeldung angezeigt. In der Bestandsliste wird nur ein vCenter Server aufgeführt. Umgehung: Gehen Sie folgendermaßen vor.
Führen Sie folgende Schritte durch, um die UAC auszuschalten, bevor Sie die Maschine einer Gruppe im verknüpften Modus hinzufügen:
- Wählen Sie Start > Einstellungen > Systemsteuerung > Benutzerkonten aus, um das Dialogfeld "Benutzerkonto" zu öffnen.
- Klicken Sie auf Benutzerkontosteuerung ein- oder ausschalten.
- Deaktivieren Sie die Option Benutzerkontensteuerung verwenden, um zum Schutz des Computers beizutragen und klicken Sie auf OK.
- Starten Sie die Maschine neu, wenn Sie dazu aufgefordert werden.
Starten Sie die Konfiguration für den verknüpften Modus, wie nachfolgend beschrieben:
- Wählen Sie Start > Programme > VMware > vCenter Server-Konfiguration für den verknüpften Modus.
- Klicken Sie auf "Weiter".
- Wählen Sie Konfiguration für den verknüpften Modus ändern und klicken Sie auf Weiter.
- Klicken Sie auf vCenter Server-Instanz einer vorhandenen Gruppe für den verknüpften Modus oder einer anderen Instanz hinzufügenund klicken Sie auf Weiter.
- Geben Sie den Servernamen und die Informationen für den LDAP-Port an und klicken Sie auf Weiter.
- Klicken Sie auf Fortfahren, um die Installation abzuschließen.
- Klicken Sie auf Beenden, um den Verknüpfungsvorgang zu beenden.
Melden Sie sich bei einem der vCenter Server-Systeme an und vergewissern Sie sich, dass die Server verknüpft sind. Sind die vCenter Server verknüpft, schalten Sie die UAC folgendermaßen wieder ein:
- Wählen Sie Start > Einstellungen > Systemsteuerung > Benutzerkonten aus, um das Dialogfeld "Benutzerkonto" zu öffnen.
- Klicken Sie auf Benutzerkontosteuerung ein- oder ausschalten.
- Aktivieren Sie die Option Benutzerkontensteuerung verwenden, um zum Schutz des Computers beizutragen und klicken Sie auf OK.
- Starten Sie die Maschine neu, wenn Sie dazu aufgefordert werden.
-
Networking problems and errors might occur when analyzing machines with VMware Guided Consolidation
Wird eine große Zahl von Maschinen für Guided Consolidation analysiert, kann die Guided Consolidation-Komponente vCenter Collector Provider Service von dem Betriebssystem, auf dem die Guided Consolidation-Funktionalität installiert ist, für einen Virus oder einen Wurm gehalten werden. Dies tritt auf, wenn der Analysevorgang eine große Zahl von Maschinen findet, deren IP-Adressen ungültig sind oder bei denen Probleme bei der Namensauflösung auftreten. Dabei kommt es zu einem Engpass im Netzwerk und es werden entsprechende Fehlermeldungen angezeigt. Umgehung: Fügen Sie keine Maschinen zur Analyse hinzu, die nicht erreichbar sind. Wenn Sie Maschinen über den Namen hinzufügen, stellen Sie sicher, dass der NetBIOS-Name aufgelöst werden kann und dass der Rechner erreichbar ist. Wenn Sie Maschinen über die IP-Adresse hinzufügen, stellen Sie sicher, dass es sich um eine statische IP-Adresse handelt.
-
Keine Verbindung mit vSphere Web Access zu vCenter Server, wenn Sie den HTTP-Port vom vSphere-Client aus geändert haben
Wenn Sie über den vSphere-Client eine Verbindung mit dem vCenter Server hergestellt haben, können Sie den HTTP-Port von vCenter Server ändern ( Verwaltung > vCenter Server-Einstellungen > Webservice > Ports > HTTP). Dieser Port ermöglicht die Verbindung mit vCenter Server über vSphere Web Access. Wenn Sie den HTTP-Port ändern, ist vSphere Web Access möglicherweise für alle Benutzer nicht mehr erreichbar. Umgehung: Führen Sie die folgenden Schritte aus, um die Porteinstellungen in den Konfigurationsdateien von vSphere Web Access zu ändern, damit Verbindungen über den von Ihnen angegebenen Port möglich sind.
- Melden Sie sich bei der vCenter Server-Maschine an und öffnen Sie folgendes Verzeichnis:
C:\Programme\VMware\Infrastructure\tomcat\webapps\jslib-1.0.157180
\modules\com.vmware.webaccess.app_1.0.0
Wenn Sie vCenter Server in einem anderen Verzeichnis als C:\Programme\
installiert haben, wählen Sie den entsprechenden Pfad.
- Öffnen Sie die Datei
WebAccess.properties
und Upgrade Sie wie folgt den Wert login_url
mit der Portnummer, die Sie im vSphere-Client angegeben haben:
Aktueller Wert: http://localhost:80/sdk
Neuer Wert: http://localhost:[Neuer_Port]/sdk
- Klicken Sie mit der rechten Maustaste auf Arbeitsplatz und wählen Sie Verwalten.
- Wählen Sie unter Dienste und Anwendungen die Option Dienste, suchen Sie "VMware VirtualCenter Management Webservices" und starten Sie den Dienst neu.
HINWEIS: Ein Neustart des Dienstes wirkt sich auf die Verbindungen mit vCenter Server-Systemen im verknüpften Modus sowie auf vorhandene vSphere Web Access-Verbindungen aus.
- Löschen Sie den Cache Ihres Browsers.
- Verwenden Sie
http://localhost: /ui
, zum Herstellen einer Verbindung mit vCenter Server über vSphere Web Access.
-
Wenn Sie bei großen vCenter Server-Bestandslisten den vSphere-Client im verknüpften Modus öffnen und dabei die Bestandslisten aller vCenter Server-Systeme vollständig erweitert sind, reagiert der vSphere-Client möglicherweise für einige Minuten nicht
vSphere-Client-Bestandslisten sind dann vollständig erweitert, wenn Cluster und Datencenter erweitert sind. Wenn Sie den vSphere-Client schließen, nachdem die Bestandslisten erweitert wurden, wird die erwartete Bestandslistenansicht beim nächsten Öffnen des Clients geladen. Als Folge davon reagiert der vSphere-Client möglicherweise für einige Minuten nicht mehr, abhängig von der Anzahl der vCenter Server-Systeme und der Anzahl der Objekte in den Bestandslisten der jeweiligen vCenter Server-Systeme. Der vSphere-Client reagiert wird, nachdem alle Bestandslistenobjekte geladen wurden. Umgehung: Es wird empfohlen, bei einer Gruppe im verknüpften Modus nicht die Knoten aller vCenter Server-Systeme in der Bestandsliste zu erweitern. Reduzieren Sie die Knoten, bevor Sie den vSphere-Client schließen, um das Laden der erweiterten Knoten beim Start zu vermeiden.
-
Der Hardwarestatusdienst unterstützt keine Hosts vor ESX Server 3.5 Update 4
Hardwarestatusalarme werden für Hosts der Version ESX Server 3.5 Update 3 und früher nicht ausgelöst. Wenn Sie mit dem vSphere-Client die Registerkarte Hardwarestatus für einen Host anzeigen lassen, auf dem ESX Server 3.5 Update 3 oder früher ausgeführt wird, wird die Meldung angezeigt, dass für die Überwachung des Hardwaresystemstatus ESX Server 3.5 Update 4 oder höher oder ESXi erforderlich ist. Umgehung: Damit die Hardwarestatusüberwachung auf ESX Server 3.5 Update 3 oder früher unterstützt wird, installieren Sie Patch 11 für ESX Server 3.5 (ESX350-200901407-BG), der in ESX Server 3.5 Update 4 enthalten ist.
-
Im gemeinsam genutzten Speicher gespeicherte VM-Vorlagen stehen nicht mehr zur Verfügung, nachdem DPM (Distributed Power Management) einen Host in den Standby-Modus versetzt oder wenn ein Host in den Wartungsmodus versetzt wird
Der vSphere-Client weist VM-Vorlagen einem bestimmten Host zu. Wenn der Host, auf dem die VM-Vorlagen gespeichert sind, in den Wartungsmodus oder von DPM in den Standby-Modus versetzt wird, scheinen im vSphere-Client die Vorlagen deaktiviert zu sein. Dieses Verhalten tritt auch dann auf, wenn die Vorlagen im gemeinsam genutzten Speicher gespeichert werden. Umgehung: Deaktivieren Sie DPM auf dem Host, auf dem die VM-Vorlagen gespeichert sind. Befindet sich der Host im Wartungsmodus, verwenden Sie den Datenspeicherbrowser auf einem anderen Host, der sich nicht im Wartungs- oder Standby-Modus befindet und ebenfalls Zugriff auf den Datenspeicher hat, auf dem die Vorlagen gespeichert sind, um die VM-Vorlagen zu suchen. Sie können dann virtuelle Maschinen unter Verwendung dieser Vorlagen bereitstellen.
-
Bei der Neuinstallation der vSphere-CLI auf manchen Windows-Plattformen, z. B. Windows Vista Enterprise SP1 32 Bit, kann ein LibXML DLL-Modulladefehler auftreten
-
Fehlerhafte Links auf der ESX- und der ESXi-Begrüßungsseite
Die Download-Links im vSphere Remote Command Line-Abschnitt, im vSphere Web Services SDK-Abschnitt sowie die Links zum Herunterladen der vSphere 4-Dokumentation und von VMware vCenter auf der Begrüßungsseite von ESX und ESXi sind falsch zugeordnet.
Umgehung: Laden Sie die Produkte von der VMware-Website herunter.
-
Auf Nexus 1000v kann Distributed Power Management einen Host nicht in den Standby-Modus versetzen
Wenn ein Host weder Integrated Lights-Out (iLO) noch Intelligent Platform Management Interface (IPMI) für Distributed Power Management (DPM) unterstützt, kann dieser Host weiterhin DPM verwenden, vorausgesetzt, alle physischen Netzwerkkarten auf dem Host, die zu Nexus 1000V DVS hinzugefügt werden, verfügen über Wake-On-LAN-Unterstützung. Selbst wenn nur eine der physischen Netzwerkkarten keine Wake-On-LAN-Unterstützung bietet, kann der Host nicht von DPM in den Standby-Modus versetzt werden.
Umgehung: Keine.
Verwaltung von virtuellen Maschinen
-
Benutzerdefinierte Skripts, die in vmware-toolbox dem Ereignis "Anhalten" zugewiesen sind, werden nicht ausgeführt, wenn Sie die virtuelle Maschine vom vSphere-Client aus anhalten
Wenn Sie in der Registerkarte Skript von vmware-toolbox dem Ereignis "Anhalten" ein benutzerdefiniertes Skript zugewiesen und die virtuelle Maschine so konfiguriert haben, dass, wenn Sie Anhalte-Skripts starten, VMware Tools-Skripts ausgeführt werden, geschieht dies nicht, falls Sie die virtuelle Maschine vom vSphere-Client aus anhalten. Umgehung: Keine
-
Wenn bei einem automatischen Upgrade der VMware Tools das Gastbetriebssystem eingeschaltet wird, wird das Gastbetriebssystem automatisch neu gestartet, ohne dass eine Neustartbenachrichtigung ausgegeben wird
Wenn Sie angeben, dass auf einem Windows Vista- oder Windows 2008-Gastbetriebssystem die VMware Tools automatisch aktualisiert werden sollen, wenn das Betriebssystem eingeschaltet wird, werden VMware Tools aktualisiert und das Gastbetriebssystem automatisch neu gestartet, ohne dass eine Neustartbenachrichtigung ausgegeben wird. Umgehung: Keine
-
Ein Dialogfeld, in dem der Benutzer zur Eingabe von Sysprep-Dateiinformationen aufgefordert wird, erscheint möglicherweise beim Klonen und Anpassen von virtuellen Maschinen
Wenn Sie eine virtuelle Maschine klonen und anpassen, wird der Vorgang möglicherweise nicht abgeschlossen und ein Sysprep-Dialogfeld fordert Sie möglicherweise auf, zusätzliche Dateien anzugeben. Umgehung: Führen Sie die folgenden Schritte aus:
- Beachten Sie die Liste der fehlenden Dateien, die das Mini-Setup von Windows nicht finden kann.
- Kopieren Sie die benötigten Dateien (beispielsweise c_20127.nls) von der Quellmaschine in den Ordner mit den Sysprep-Installationsdateien, c:\sysprep\i386. Die von Sysprep angeforderten Dateien befinden sich normalerweise an folgendem Speicherort auf der virtuellen Quellmaschine:
C:\Windows\system32
.
- Führen Sie das Klonen mit Anpassung durch.
Hinweis:Das Sysprep-Verzeichnis wird entfernt, nachdem die virtuelle Maschine gestartet wurde und die Anpassung abgeschlossen ist.
-
Bei virtuellen Maschinen, die ein Windows NT-Gastbetriebssystem ausführen, muss nach einem Upgrade der virtuellen Hardware von Version 4 auf Version 7 der Netzwerkadaptertreiber neu installiert werden
Nach einem Upgrade der virtuellen Hardware auf einem Windows NT-Gastbetriebssystem kann die virtuelle Maschine keine IP-Adressen abrufen, da Windows NT die Plug-und-Play-Spezifikation nicht voll unterstützt. Umgehung: Installieren Sie nach einem Upgrade der virtuellen Hardware von Version 4 auf Version 7 auf einer virtuellen Maschine, auf der Windows NT ausgeführt wird, den Netzwerkadaptertreiber neu, indem Sie die folgenden Schritte durchführen.
- Klicken Sie mit der rechten Maustaste auf Netzwerkumgebung und wählen Sie Eigenschaften aus.
- Wählen Sie die Registerkarte Adapter aus.
- Entfernen Sie den vorhandenen Adapter.
- Fügen Sie einen neuen Adapter hinzu.
- Wählen Sie bei einem AMD PCNet-Treiber AMD PCNET Family Ethernet adapter aus und geben Sie als Pfad
C:\winnt\system32
an.
Klicken Sie bei einem vmxnet-Treiber auf Diskette und geben Sie als Pfad C:\Programme\VMware\VMware Tools\Drivers\vmxnet\
an.
- Starten Sie die virtuelle Maschine neu.
-
Eine IDE-Festplatte, die einer virtuellen Maschine mit der Hardwareversion 7 hinzugefügt wurde, wird als Festplatte 1 definiert, auch wenn bereits eine SCSI-Festplatte vorhanden ist
Wenn Sie einer virtuellen Maschine mit der Hardwareversion 7, die über eine als Festplatte 1 definierte SCSI-Festplatte verfügt, eine IDE-Festplatte hinzufügen, ändert die virtuelle Maschine die Plattennummerierung. Die IDE-Festplatte wird als Festplatte 1 definiert und die SCSI-Festplatte wird zu Festplatte 2. Umgehung: Keine. Verlassen Sie sich jedoch nicht ausschließlich auf die Plattennummer, wenn Sie sich entschließen, eine der Festplatten zu löschen. Überprüfen Sie stattdessen den Plattentyp, um sicherzustellen, dass Sie die richtige Platte löschen.
-
Das Wiederherstellen eines Snapshots funktioniert möglicherweise nicht, wenn Sie mittels Cold-Migration eine virtuelle Maschine mit einem Snapshot von einem ESX/ESXi 3.5-Host auf einen ESX/ESXi 4.0-Host verlagern
Sie können mittels Cold-Migration eine virtuelle Maschine mit Snapshots von einem ESX/ESXi 3.5-Host auf einen ESX/ESXi 4.0-Host verlagern. Dennoch funktioniert das Wiederherstellen eines Snapshots nach der Migration möglicherweise nicht. Umgehung: Keine
-
Der vCenter Server schlägt fehl, wenn die Delta-Festplattentiefe eines verknüpften Klons der virtuellen Maschine größer als die unterstützte Tiefe von 32 ist
Wenn die Delta-Festplattentiefe eines verknüpften Klons größer als die unterstützte Tiefe von 32 ist, schlägt der vCenter Server fehl. Folgende Fehlermeldung wird angezeigt: Win32-Ausnahme: Stapelüberlauf
Unter diesen Umständen kann der vCenter Server erst dann neu gestartet werden, wenn Sie die virtuelle Maschine von dem Host entfernt oder die vCenter Server-Datenbank bereinigt haben. Erwägen Sie, die virtuelle Maschine von dem Host zu entfernen statt die vCenter Server-Datenbank zu bereinigen, da dies sicherer ist.
Umgehung: Führen Sie die folgenden Schritte aus:
- Melden Sie sich beim vSphere-Client auf dem Host an.
- Zeigen Sie den Klon der virtuellen Maschine in der Bestandsliste an.
- Klicken Sie mit der rechten Maustaste auf die virtuelle Maschine und wählen Sie Von Festplatte löschen.
- Starten Sie den vCenter Server neu.
Hinweis: Wenn nach dem Neustart von vCenter Server die virtuelle Maschine in der Bestandsliste im vSphere-Client angezeigt wird und die Option Aus Bestandsliste entfernen im Kontextmenü der virtuellen Maschine deaktiviert ist, müssen Sie den Eintrag für die virtuelle Maschine manuell aus der vCenter-Datenbank entfernen.
-
Das Erstellen einer neuen SCSI-Festplatte in einer virtuellen Maschine kann dazu führen, dass eine ungenaue Fehlermeldung ausgegeben wird
Wenn Sie eine neue SCSI-Festplatte in einer virtuellen Maschine erstellen und den SCSI-Bus auf virtual setzen, wird folgende Fehlermeldung ausgegeben:
Stellen Sie sicher, dass die virtuelle Festplatte unter Verwendung der Option "Thick" erstellt wurde.
Allerdings ist Thickallein keine gültige Option. Die korrekte Option lautet eagerzeroedthick.
Umgehung: Erstellen Sie die SCSI-Festplatte mit dem Befehlszeilenbefehl vmkfstoolsund der Option eagerzeroedthick.
-
Die Optionen für den Installationsstartvorgang einer virtuellen Maschine werden nicht in das Open Virtualization Format (OVF) exportiert
Wenn Sie auf einer virtuellen Maschine, auf der die Option "Installationsstartvorgang" aktiviert ist, ein OVF-Paket erstellen, wird diese Option während des Exports ignoriert. Daher fehlt im OVF-Deskriptor das Element InstallSection
, das Informationen zum Installationsvorgang liefert. Wenn Sie ein OVF-Paket bereitstellen, wird das Element InstallSection
ordnungsgemäß analysiert. Umgehung: Nachdem die virtuelle Maschine nach OVF exportiert wurde, erstellen Sie die InstallSection
-Parameter manuell im OVF-Deskriptor. Ist eine Manifestdatei ( .mf
) vorhanden, müssen Sie sie im Anschluss an die Änderung des OVF-Deskriptors erneut generieren.
Beispiel: Legt fest, dass ein Installationsstart notwendig ist.
Die Aufnahme der InstallSection
-Parameter in den Deskriptor informiert den Bereitstellungsvorgang darüber, dass für den Abschluss der Bereitstellung ein Installationsstartvorgang erforderlich ist. Das Attribut ovf:initialBootStopDelay
legt die Startverzögerung fest.
Einzelheiten hierzu finden Sie in der OVF-Spezifikation.
-
Eine von einem Snapshot einer virtuellen Maschine mit einem LSI SAS-Controller geklonte virtuelle Maschine wird evtl. fälschlicherweise mit einem BusLogic-Controller konfiguriert
Wenn Sie einen Snapshot einer virtuellen Maschine mit einem LSI SAS-Controller erstellen und anschließend von dem Snapshot eine virtuelle Maschine klonen, wird für die von dem Snapshot geklonte virtuelle Maschine möglicherweise ein BusLogic- statt eines LSI SAS-Controllers in den VM-Eigenschaften konfiguriert. Umgehung: Überprüfen Sie in der Eigenschaft "Snapshot.config" den Controllertyp der virtuellen Maschine, die Sie anhand eines Snapshots einer virtuellen Maschine, die über einen LSI SAS-Controller verfügt, geklont haben. Konfigurieren Sie nach Bedarf den Controllertyp für die geklonte virtuelle Maschine.
-
Die virtuelle Maschine kann nicht gestartet werden, nachdem ein virtuelles CD-ROM-Laufwerk (iLO) ohne Medium als ein SCSI-Gerät hinzugefügt wurde*
Nachdem mit iLO (Integrated Lights-Out) ein virtuelles CD-ROM-Laufwerk ohne Medium der virtuellen Maschine als ein SCSI-Gerät hinzugefügt wurde, kann die virtuelle Maschine nicht gestartet werden, wenn Sie versuchen, von dem virtuellen CD-ROM-Laufwerk zu booten.
Es gibt drei Umgehungen für dieses Problem:
- Stellen Sie sicher, dass das virtuelle iLO-CD-ROM-Laufwerk immer ein Medium enthält, wenn es angeschlossen ist und von einer beliebigen virtuellen Maschine verwendet wird.
- Wenn das virtuelle CD-ROM-Laufwerk nicht zur Installation des Gastbetriebssystems auf der virtuellen Maschine verwendet wird, ändern Sie die Startreihenfolge im BIOS der virtuellen Maschine, sodass Festplatte, Diskettenlaufwerk und Netzwerkkarte vor dem CD-ROM-Laufwerk aufgeführt werden.
- Verwenden Sie kein virtuelles iLO-CD-ROM-Laufwerk. ESX kann sowohl lokale als auch Remote-CD-ROM-Laufwerke und ISO-Images mit den virtuellen Maschinen verbinden, ohne die Einschränkung durchzusetzen, dass nur ein CD-ROM-Laufwerk von iLO auf einem System angezeigt wird.
VMotion und Storage VMotion
-
Nach dem Neukonfigurieren und Verlagern der virtuellen Maschine kann das Wiederherstellen eines Snapshots fehlschlagen
Wenn Sie die Eigenschaften einer virtuellen Maschine neu konfigurieren und sie auf einen anderen Host verschieben, kann das Wiederherstellen eines zuvor erstellten Snapshots fehlschlagen. Umgehung: Vermeiden Sie es, virtuelle Maschinen auf einen Host zu verschieben, dessen Eigenschaften sich sehr von denen des ursprünglichen Hosts unterscheiden (z. B. verschiedene Versionen, verschiedene CPU-Typen usw.)
-
Bei der Verwendung von Storage VMotion für die Migration einer virtuellen Maschine mit vielen Festplatten kann es zu Zeitüberschreitungen kommen
Die Migration einer virtuellen Maschine mit vielen virtuellen Festplatten unter Verwendung von Storage VMotion kann möglicherweise nicht abgeschlossen werden. Der Storage VMotion-Vorgang benötigt während der abschließenden Kopierphase Zeit für das Öffnen, Schließen und Verarbeiten von Festplatten. Wegen dieses plattenbezogenen Overheads kann es bei Storage VMotion-Migrationen von virtuellen Maschinen mit vielen Festplatten zur Zeitüberschreitung kommen. Umgehung: Erhöhen Sie den Wert für die Storage VMotion-Einstellung fsr.maxSwitchoverSeconds
in der Konfigurationsdatei der virtuellen Maschine. Die Standardeinstellung beträgt 100 Sekunden. Oder vermeiden Sie es, während der Storage VMotion-Migration auf den betroffenen Datenspeichern viele Bereitstellungsvorgänge, Migrationen oder Einschalt- und Abschaltvorgänge durchzuführen.
-
Storage VMotion eines NFS-Volumes wird möglicherweise von dem NFS-Serverfestplattenformat überschrieben
Wenn Sie Storage VMotion zum Migrieren einer virtuellen Festplatte auf ein NFS-Volume oder für die Bereitstellung von virtuellen Maschinen, bei der NFS-Volumes einbezogen werden, verwenden, wird das Festplattenformat von dem NFS-Server bestimmt, auf dem sich das NFS-Volume befindet. Falls Sie eine Auswahl im Menü Festplattenformat getroffen haben, wird sie damit außer Kraft gesetzt. Umgehung: Keine
-
Wenn ESX/ESXi-Hosts ausfallen oder während Storage VMotion neu gestartet werden, kann der Vorgang fehlschlagen und die virtuellen Maschinen können verwaisen
Wenn Hosts ausfallen oder während Storage VMotion neu gestartet werden, kann der VMotion-Vorgang fehlschlagen. Die virtuellen Festplatten der virtuellen Zielmaschine können nach einem Neustart des Hosts in der Bestandsliste als verwaist erscheinen. In der Regel wird der Status der virtuellen Maschine beibehalten, bevor der Host heruntergefahren wird. Überprüfen Sie, falls die virtuelle Maschine nicht mit dem Status "verwaist" aufgeführt wird, ob die Ziel-VMDK-Dateien vorhanden sind.
Umgehung: Sie können die verwaiste virtuelle Zielmaschine manuell aus der VSphere-Bestandsliste löschen. Suchen Sie im Datenspeicher nach weiteren verwaisten Zielfestplatten und löschen Sie sie.
-
Auf einer lokalen Datenspeicher gespeicherte virtuelle Maschinen werden nicht vom Host migriert, wenn sich der Host im Wartungsmodus befindet
Auf einer lokalen Datenspeicher gespeicherte virtuelle Maschinen werden nicht vom Host migriert, wenn sich der Host im Wartungsmodus befindet. Umgehung: Verschieben Sie die virtuellen Maschinen auf lokalen Datenspeichern manuell auf einen anderen Host, falls sie weiterhin zur Verfügung stehen müssen, während sich der aktuell Host im Wartungsmodus befindet.
VMware High Availability und Fehlertoleranz
-
Failover auf sekundäre virtuelle VMware FT-Maschine führt zu Fehlermeldung auf dem Host-Client
Wenn VMware-Fehlertoleranz ein Failover auf eine sekundäre virtuelle Maschine durchführt und der für die sekundäre virtuelle Maschine ausgewählte Host erst kürzlich neu gestartet wurde, betrachtet der Host-Client diesen Versuch als Fehlschlag und zeigt folgende Fehlermeldung an: Anmeldung fehlgeschlagen wegen eines ungültigen Benutzernamens oder Kennworts
.
Diese Fehlermeldung wird angezeigt, weil der Host kürzlich neu gestartet wurde und es möglich ist, dass er noch keinen SSL-Fingerabdruck von vCenter Server empfangen hat. Nachdem der Fingerabdruck an den Host gesendet wurde, verläuft das Failover erfolgreich. Diese Bedingung tritt nur dann auf, wenn alle Hosts in einem FT-aktivierten Cluster ausgefallen sind, was dazu führt, dass der Host mit der sekundären virtuellen Maschine neu gestartet wird.
Umgehung: Keine. Das Failover verläuft nach einigen Versuchen erfolgreich.
-
Das Ändern der Systemzeit auf einem ESX/ESXi-Host führt zu einem VMware HA-Agent-Fehler
Wenn Sie die Systemzeit auf einem ESX/ESXi-Host ändern, wird nach kurzer Zeit der folgende HA-Agent-Fehler angezeigt: Der HA-Agent auf < Server> in < Cluster> im < Datencenter> hat einen Fehler
.
Dieser Fehler wird sowohl im Ereignisprotokoll als auch auf der Host-Registerkarte Übersicht im vSphere-Client angezeigt.
Umgehung: Korrigieren Sie die Systemzeit des Hosts und starten Sie "vpxa" mit dem Befehl service vmware-vpxa restart
neu.
-
Beim Konfigurieren von VMware High Availability (HA) auf einem stark belasteten System erscheint möglicherweise eine Fehlermeldung
Wenn Sie HA auf einem Host aktivieren, der aufgrund seiner Gast-VMs eine schwere Arbeitslast zu bewältigen hat, wird die HA-Konfiguration für den Host möglicherweise unterbrochen und eine Fehlermeldung ausgegeben:
HA-Agent auf dem Host fehlgeschlagen
Umgehung: Konfigurieren Sie HA für den Host neu, möglichst nachdem Sie die Last reduziert haben, indem Sie entweder virtuelle Maschinen ausschalten oder sie unter Verwendung von VMotion auf einen anderen Host im Cluster migrieren.
-
Die VMware-Fehlertoleranz unterstützt die IPv6-Adressierung nicht
Wenn den VMkernel-Netzwerkkarten für die Fehlertoleranzprotokollierung oder für vMotion IPv6-Adressen zugewiesen werden, schlägt das Aktivieren der Fehlertoleranz auf virtuellen Maschinen fehl.
Umgehung: Konfigurieren Sie die VMkernel-Netzwerkkarten anhand der IPv4-Adressen.
-
Das Hot-Plugging von Geräten wird nicht unterstützt, wenn die Fehlertoleranz auf virtuellen Maschinen deaktiviert ist
Die Hot-Plugging-Funktion wird auf virtuellen Maschinen nicht unterstützt, wenn die VMware-Fehlertoleranz auf diesen virtuellen Maschinen aktiviert oder deaktiviert ist. Sie müssen die Fehlertoleranz vorübergehend ausschalten, bevor Sie ein Hot-Plugging für ein Gerät durchführen können. Nach dem Hot-Plugging können Sie die Fehlertoleranz wieder einschalten. Nach dem Entfernen eines Geräts bei laufendem Betrieb sollten Sie die virtuelle Maschine allerdings neu starten, um die Fehlertoleranz einzuschalten.
VMware Tools
-
Wenn bestimmte Bedingungen zutreffen, kommt es vor, dass die Snapshots einer virtuellen Maschine nicht mehr reagieren *
Versuche, ein Snapshot einer virtuellen Maschine anzufertigen, führt möglicherweise dazu, dass der Status Vorgang läuftangezeigt wird, wenn alle folgenden Bedingungen zutreffen:
- Die Option Snapshot des Arbeitsspeichers der virtuellen Maschine erstellen wurde nicht ausgewählt.
- Die Option Gast-Dateisystem stilllegen wurde ausgewählt.
- Ein VSS (Volume Shadow Copy Service) von einem Drittanbieter wurde installiert.
In solchen Fällen wird der Status Vorgang läuftsolange angezeigt, bis für die Aufgabe eine Zeitüberschreitung eintritt. Darüber hinaus wird der Prozess fortgesetzt und verhindert somit, dass andere Snapshots erstellt werden.
Seitenanfang