ESXi 4.0 Update 3 | 5. Mai 2011 | Build 398348 Letzte Dokumentaktualisierung: 19. Mai 2011 |
Diese Versionshinweise decken die folgenden Themen ab:
Neuigkeiten
Die nachstehende Liste beschreibt einige der Verbesserungen in der vorliegenden Version von VMware ESXi:
- Erweiterte APD-Behandlung mit automatischem Failover bei erneuten LUN-Prüfungen.
- Einbeziehung eines zusätzlichen Treibers: Enthält den 3ware SCSI 2.26.08.036vm40-Treiber. Für vorherige Versionen muss dieser Treiber separat heruntergeladen werden.
- Aktualisiert VMware Tools WDDM-, XPDM- und PVSCSI-Treiber.
Behobene Probleme: Diese Version enthält darüber hinaus verschiedene Fehlerkorrekturen, die im Abschnitt Behobene Probleme dokumentiert sind.
Seitenanfang
Vorherige Versionen von ESXi 4.0
Die Funktionen und bekannten Probleme der vorherigen Versionen von ESXi 4.0 werden in den Versionshinweisen für die jeweilige Version beschrieben. Wenn Sie Versionshinweise vorheriger Versionen von ESXi 4.0 anzeigen möchten, klicken Sie auf einen der folgenden Links:
Seitenanfang
Bevor Sie beginnen
ESXi, 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 ESXi, 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:
VMware vSphere-Kompatibilitätstabellen ( 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 3 . Weitere Informationen finden Sie auf der entsprechenden ESXi-Dokumentationsseite:
Installation und Upgrade
Im ESXi Installable und vCenter Server Handbuch zur Einrichtung finden Sie Schritt-für-Schritt-Anleitungen zur Installation und Konfiguration von ESXi Installable und vCenter Server. Genaue Anleitungen zur Einrichtung von ESXi Embedded und vCenter Server finden Sie im Handbuch zur Einrichtung für ESXi Embedded und vCenter Server .
Nach der erfolgreichen Installation von ESXi Installable oder dem erfolgreichen Starten von ESXi Embedded sind einige weitere 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. Sie sollten auf VMFS Version 3 oder höher aktualisieren bzw. 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. Es wird empfohlen, vCenter Server auf einem 64-Bit-Windows-Betriebssystem zu 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 (Management Information Base), die sich auf ESXi beziehen, werden nicht zusammen mit vCenter Server ausgeliefert. 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/de/download heruntergeladen werden.
Durchführen eines Upgrades der VMware Tools
VMware ESXi 4.0 Update 3 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 Version von ESXi im Zusammenhang mit VMware Tools behoben wurden, finden Sie unter Behobene Probleme für VMware Tools.
Das VMware Tools-RPM-Installationsprogramm, das im VMware Tools-ISO-Image für Linux-Gastbetriebssysteme zur Verfügung steht, ist veraltet. Es wird in einer künftigen ESXi-Version entfernt. Verwenden Sie das tar.gz-Installationsprogramm zum Installieren der VMware Tools auf virtuellen Maschinen mit Linux-Gastbetriebssystemen.
Informationen zum Ermitteln der installierten VMware Tools-Version finden Sie in der Knowledgebase unter Verifizieren einer Build-Version der VMware Tools (KB 1003947).
Upgrade oder Migration auf ESXi 4.0 Update 3
ESXi 4.0 Update 3 bietet die folgenden Optionen für das Upgrade:
- VMware vCenter Update Manager– Sie können ein Upgrade von ESXi 3.5 Update 5 und ESXi 4.0.x mithilfe von vCenter Update Manager 4.0 Update 3 durchführen. Weitere Informationen hierzu finden Sie im Administratorhandbuch zu VMware vCenter Update Manager .
- vSphere Host Update Utility– Sie können ein Upgrade von ESXi 3.5 Update 5 und ESXi 4.0.x mithilfe von vSphere Host Update Utility 4.0 Update 3 durchführen. Weitere Informationen hierzu finden Sie im vSphere-Upgrade-Handbuch .
- Befehl "vihostupdate" der VMware vSphere-Befehlszeilenschnittstelle (vSphere-CLI)– Sie können ein Upgrade von ESXi 4.0.x mithilfe des Befehls vihostupdatedurchführen. Informationen hierzu finden Sie im vSphere-Upgrade-Handbuch und im Handbuch für die Patch-Verwaltung.
Unterstützte Upgrade-Pfade für das Host-Upgrade auf ESXi 4.0 Update 3:
Upgrade-Lieferumfang |
Unterstützte Upgrade-Tools |
Unterstützte Upgrade-Pfade auf ESXi 4.0 Update 3 |
ESXi 3.5 Update 5 |
ESXi 4.0 einschließlich ESXi 4.0 Update 1 und ESXi 4.0 Update 2 |
upgrade-from-esxi3.5-4.0_update03-398348.zip |
- VMware vCenter Update Manager mit ESX-Host-Upgrade-Baseline
- vSphere Host Update Utility
|
Ja |
Nein
|
update-from-esxi4.0-4.0_update03.zip |
vihostupdate |
Nein |
Ja
|
Patch-Definitionen, die vom VMware-Portal (online) heruntergeladen werden |
- VMware vCenter Update Manager mit Host-Patch-Baseline
- vSphere Host Update Utility
|
Nein
|
Ja
|
Hinweis: Direkte Upgrades von älteren Versionen als ESXi 3.5 Update 5 werden nicht unterstützt. Sie sollten zunächst ein Upgrade auf eine neuere unterstützte Version durchführen und anschließend ein Upgrade auf ESXi 4.0 Update 3 durchführen.
Seitenanfang
In dieser Version enthaltene Patches
Diese Version enthält alle Bulletins für die ESXi Server-Software, die vor dem Veröffentlichungsdatum dieses Produkts zur Verfügung standen. Weitere Informationen finden Sie auf der Seite Patches herunterladen.
Patch-Version
ESXi400-Update03 enthält die folgenden einzelnen Bulletins:
ESXi400-201105201-UG: Aktualisiert die Firmware
ESXi400-201105202-UG: Aktualisiert Tools
ESXi400-201105203-UG: Aktualisiert den VI-Client
Weitere Informationen zu den Inhalten der Patches finden Sie in der Dokumentation, auf die auf der Download-Seite verwiesen 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.
Sicherung
CIM und API
-
vCenter Server gibt fälschlicherweise das Service-Tag des Blade-Chassis wieder
Auf Blade-Servern, auf denen ESXi läuft, gibt vCenter Server das Service-Tag des Blade-Chassis anstatt des Service-Tags des Blades wieder. Auf einem von vCenter Server verwalteten Dell- oder IBM-Blade-Server wird die Nummer des Service-Tags unter Prozessoren > im Abschnitt "System" von vCenter Server auf der Registerkarte Konfiguration aufgeführt . Dieses Problem tritt wegen eines falschen Werts für die Eigenschaft SerialNumberder Instanz Fixed CIM OMC_Chassisauf.
Dieses Problem wurde in der vorliegenden Version behoben.
Gastbetriebssystem
-
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, die für eine relativ lange Zeit, z. B. seit 100 Tagen, aktiv war.
Dieses Problem wurde in der vorliegenden Version behoben.
-
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.
Dieses Problem wurde in der vorliegenden Version behoben.
-
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.
Dieses Problem wurde in der vorliegenden Version behoben.
-
Mausbewegungen in RDP-Sitzungen auf virtuellen Windows-Maschinen werden von Mausbewegungen der MKS-Konsole betroffen
Wenn ein Administrator mithilfe des vSphere-Clients eine Konsole auf einer virtuellen Windows-Maschine öffnet, auf der mehrere Benutzer über Terminalsitzungen angemeldet sind, werden deren Mausbewegungen möglicherweise mit denen des Administrators synchronisiert.
Dieses Problem wurde in der vorliegenden Version behoben.
-
vmrun-Befehle werden auf Ubuntu 10.04-Gastbetriebssystemen nicht ausgeführt
Der Befehl listProcessesInGuest vmrunwird auf Ubuntu 10.04-Gastbetriebssystemen möglicherweise nicht ausgeführt. Das Gastbetriebssystem zeigt eine Fehlermeldung ähnlich der Folgenden an:
Fehler: Ungültiger Benutzername oder ungültiges Kennwort für das Gastbetriebssystem
Dieses Problem wurde in der vorliegenden Version behoben.
-
Das Windows-Gastbetriebssystem schlägt möglicherweise mit einem vmx_fb.dll-Fehler fehl
Windows-Gastbetriebssysteme, die mit dem VMware Windows XP-Grafiktreibermodell (XPDM) installiert sind, schlagen möglicherweise mit einem vmx_fb.dll-Fehler und einem blauen Bildschirm fehl.
Das Problem wurde in der vorliegenden Version behoben.
-
Die Standardeinstellungen für die Arbeitsspeichergröße in den virtuellen RHEL- und Ubuntu 32-Bit- und 64-Bit-Maschinen wurden aktualisiert
Die Mindest- und Standard-Arbeitsspeichergrößen für die RHEL- und Ubuntu 32-Bit und 64-Bit-Gastbetriebssysteme wurden wie folgt aktualisiert:
Bei RHEL 6 (32-Bit) wurde die Mindestmenge des Arbeitsspeichers von 1 GB auf 512 MB, die Standardmenge des empfohlenen Arbeitsspeichers von 2 GB auf 1 GB, die Menge des maximal empfohlenen Arbeitsspeichers von 64 GB auf 16 GB und die Festplattengröße von 8 GB auf 16 GB aktualisiert.
Bei RHEL 6 (64-Bit) wurde die Standardmenge des empfohlenen Arbeitsspeichers von 2 GB auf 1 GB und die Festplattengröße von 8 GB auf 16 GB aktualisiert.
Für Ubuntu (32-Bit und 64-Bit) wurde die empfohlene Mindestmenge an Arbeitsspeicher von 64 MB auf 256 MB aktualisiert.
Sonstige Probleme
-
Aufgrund eines Mangels an Sockets verliert der ESXi-Host zeitweise die Verbindung mit vCenter Server
Dieses Problem wurde in der Version ESXi 4.0 Update 3 behoben. ESXi400-201104401-SG enthält bereits den Fix für dieses Problem. Dieser Patch wurde vor ESXi 4.0 Update 3 veröffentlicht. Weitere Informationen finden Sie im Knowledgebase-Artikel KB 1037259.
-
In den Netzwerkleistungsdiagrammen werden falsche Daten angezeigt
In den Stapeldiagrammen, in denen die Netzwerkleistungen pro virtueller Maschine angezeigt werden, werden falsche Daten angezeigt. Über Diagrammoptionen in Diagrammoptionen auf der Registerkarte Leistung können Sie auf das Diagramm zugreifen. Die Statistiken für die Netzwerkübertragung und den Empfang einer mit einem Distributed Virtual Switch (DVS) verbundenen virtuellen Maschine werden in vorherigen Versionen umgetauscht und daher falsch angezeigt.
Dieses Problem wurde in der vorliegenden Version behoben.
-
vSphere-Client zeigt den falschen bereitgestellten Speicherplatz für eine ausgeschaltete virtuelle Maschine an
Bei der Berechnung des bereitgestellten Speicherplatzes einer ausgeschalteten virtuellen Maschine berücksichtigt der ESXi-Host die Arbeitsspeicherreservierung nicht. Folglich zeigt der vSphere-Client möglicherweise eine Diskrepanz in den Werten für den bereitgestellten Speicherplatz an, während die virtuelle Maschine ein- oder ausgeschaltet wird.
Dieses Problem wurde in der vorliegenden Version behoben.
-
ESXi-Host schlägt möglicherweise fehl, wenn USB-Geräte an EHCI-Controller angeschlossen sind
Wenn Sie USB-Geräte (einschließlich Baseboard Management Controller [BMC], wie z. B. iLO- oder DRAC-basierter USB-Geräte) an EHCI-Controller anschließen, könnte ein Speicherfehler manchmal zu einem Ausfall eines ESXi-Hosts führen. Dabei wird ein violetter Bildschirm und Fehlermeldungen ähnlich der Folgenden angezeigt:
2010-12-11T10:11:30.683Z cpu1:2606)@BlueScreen: PANIC bora/vmkernel/main/dlmalloc.c:4803 - Usage error in dlmalloc
2010-12-11T10:11:30.684Z cpu1:2606)Code start: 0x418031000000 VMK uptime: 0:03:35:09.476
2010-12-11T10:11:30.685Z cpu1:2606)0x412208b87b10:[0x418031069302]Panic@vmkernel#nover+0xa9 stack: 0x410014b12e80
2010-12-11T10:11:30.687Z cpu1:2606)0x412208b87b30:[0x4180310285eb]DLM_free@vmkernel#nover+0x602 stack: 0x1
2010-12-11T10:11:30.688Z cpu1:2606)0x412208b87b70:[0x418031038ef1]Heap_Free@vmkernel#nover+0x164 stack: 0x3e8
Dieses Problem wurde in der vorliegenden Version behoben.
-
Aufgrund eines durch eine TTY-Wettlaufsituation verursachten Zustands fällt der ESXi-Host aus und zeigt einen violetten Bildschirm an
Ein ESXi-Host schlägt möglicherweise mit einem violetten Bildschirm fehl, auf dem eine Fehlermeldung ähnlich der Folgenden angezeigt wird, wenn mehrere Threads, die versuchen, denselben TTY zu verwenden, eine Wettlaufsituation verursachen:
ASSERT bora/vmkernel/user/userTeletype.c:969 cr2=0xff9fcfec cr3=0xa114f000 cr4=0x128
Dieses Problem wurde in der vorliegenden Version behoben.
-
Lange Syslog-Meldungen werden auf ESXi-Hosts nicht protokolliert
Protokollmeldungen, die länger als 2048 Byte sind, werden auf ESXi-Hosts nicht in /var/log/messagesgeschrieben.
Dieses Problem wurde in der vorliegenden Version behoben.
-
Die Protokollüberflutung wird im VMkernel-Protokoll vermerkt: usbdev_ioctl: REAPURBDELAY (KB 1029451)
-
Die Durchführung eines Downgrades oder Upgrades mithilfe des Dell Update Package-Dienstprogramms schlägt auf ESXi 4.0-Hosts möglicherweise fehl
Dieses Problem wurde in der vorliegenden Version behoben.
Netzwerk
- Traffic-Shaping-Werte werden nach einem Neustart des ESXi-Hosts zurückgesetzt
Wenn Sie den Traffic-Shaping-Wert auf einem vDS oder vSwitch auf einen Wert größer als 4 GB konfigurieren, wird der Wert auf unter 4 GB zurückgesetzt, wenn Sie den ESXi-Host starten. Dieses Problem führt dazu, dass der Traffic-Shaper den Datenverkehr mit viel niedrigeren Werten gestaltet, was eine sehr geringe Netzwerkbandbreite mit sich bringt. Wenn Sie beispielsweise den Traffic-Shaping-Wert auf eine maximale Bandbreite von 6 GBit/s festlegen, ändert sich der Wert auf etwa 1,9 GBit/s, wenn Sie den ESXi-Host neu starten.
Dieses Problem wurde in der vorliegenden Version behoben.
-
ESXi-Host schlägt beim Zurücksetzen der bnx2-Netzwerkkarte fehl
Aufgrund der Firmwaresynchronisierung schlägt das Zurücksetzen einer bnx2-Netzwerkkarte möglicherweise fehl, was dazu führt, dass der ESXi-Host mit einem violetten Bildschirm ausfällt. Nachfolgend finden Sie ein Beispiel für eine Rückverfolgung dieses Problems:
0x4100c178f7f8:[0x41802686d9f4]bnx2_poll+0x167 stack: 0x4100c178f838
0x4100c178f878:[0x4180267a3ec6]napi_poll+0xed stack: 0x4100c178f898
0x4100c178f938:[0x41802642abaf]WorldletBHHandler+0x426 stack: 0x417fe726c680
0x4100c178f9a8:[0x4180264218f7]BHCallHandlersInt+0x106 stack: 0x4100c178f9f8
0x4100c178f9f8:[0x418026421dc1]BH_Check+0x144 stack: 0x4100c178fae0
0x4100c178fa28:[0x41802642e524]IDT_HandleInterrupt+0x12b stack: 0x418040000000
0x4100c178fa48:[0x41802642e9f2]IDT_IntrHandler+0x91 stack: 0x0
0x4100c178fb28:[0x4180264a9b16]gate_entry+0x25 stack: 0x1
Dieses Problem wurde in der vorliegenden Version behoben. Der Fix versetzt die Netzwerkkarte in den Status "Link deaktiviert", wenn eine Zeitüberschreitung bei der Firmwaresynchronisierung eintritt, und verhindert so, dass der ESXi-Host ausfällt. Die folgende Meldung wird in die VMkernel-Protokolldatei geschrieben:
bnx2: Zurücksetzen... NIC-Initialisierung fehlgeschlagen: vmnicX.
-
e1000e 1.1.2-NAPI-Treiber aufgenommen
In vorherigen Versionen wurde der Intel e1000e 1.1.2-NAPI-Treiber nicht in den Lieferumfang von ESXi aufgenommen. Er musste separat heruntergeladen werden Der e1000e 1.1.2-NAPI-Treiber ist im Lieferumfang dieser Version von ESXi enthalten.
-
ESXi-Hosts schlagen möglicherweise mit bnx2x fehl
Wenn Sie ESXi mit dem Broadcom bnx2x-Treiber verwenden, treten möglicherweise die folgenden Symptome auf:
- Die Netzwerkverbindung des ESXi-Hosts wird möglicherweise öfters unterbrochen.
- Der ESXi-Host reagiert möglicherweise nicht mehr. Stattdessen erscheint ein violetter Diagnosebildschirm mit Meldungen ähnlich der Folgenden:
[0x41802834f9c0]bnx2x_rx_int@esx:nover: 0x184f stack: 0x580067b28, 0x417f80067b97, 0x
[0x418028361880]bnx2x_poll@esx:nover: 0x1cf stack: 0x417f80067c64, 0x4100bc410628, 0x
[0x41802825013a]napi_poll@esx:nover: 0x10d stack: 0x417fe8686478, 0x41000eac2b90, 0x4
- Der ESXi-Host reagiert möglicherweise nicht mehr. Stattdessen erscheint ein violetter Diagnosebildschirm mit Meldungen ähnlich der Folgenden:
0:18:56:51.183 cu10:4106)0x417f80057838:[0x4180016e7793]PktContainerGetPkt@vmkernel:nover+0xde stack: 0x1
0:18:56:51.184 pu10:4106)0x417f80057868:[0x4180016e78d2]Pkt_SlabAlloc@vmkernel:nover+0x81 stack: 0x417f800578d8
0:18:56:51.184 cpu10:4106)0x417f80057888:[0x4180016e7acc]Pkt_AllocWithUseSizeNFlags@vmkernel:nover+0x17 stack: 0x417f800578b8
0:18:56:51.185 cpu10:4106)0x417f800578b8:[0x41800175aa9d]vmk_PktAllocWithFlags@vmkernel:nover+0x6c stack: 0x1
0:18:56:51.185 cpu10:4106)0x417f800578f8:[0x418001a63e45]vmklnx_dev_alloc_skb@esx:nover+0x9c stack: 0x4100aea1e988
0:18:56:51.185 cpu10:4106)0x417f80057918:[0x418001a423da]__netdev_alloc_skb@esx:nover+0x1d stack: 0x417f800579a8
0:18:56:51.186 cpu10:4106)0x417f80057b08:[0x418001b6c0cf]bnx2x_rx_int@esx:nover+0xf5e stack: 0x0
0:18:56:51.186 cpu10:4106)0x417f80057b48:[0x418001b7e880]bnx2x_poll@esx:nover+0x1cf stack: 0x417f80057c64
0:18:56:51.187 cpu10:4106)0x417f80057bc8:[0x418001a6513a]napi_poll@esx:nover+0x10d stack: 0x417fc1f0d078
- Der bnx2x-Treiber oder die bnx2x-Firmware sendet Panikmeldungen und schreibt eine Rückverfolgung mit Meldungen ähnlich der Folgenden in die Protokolldatei /var/log/message:
vmkernel: 0:00:34:23.762 cpu8:4401)<3>[bnx2x_attn_int_deasserted3:3379(vmnic0)]MC assert!
vmkernel: 0:00:34:23.762 cpu8:4401)<3>[bnx2x_attn_int_deasserted3:3384(vmnic0)]driver assert
vmkernel: 0:00:34:23.762 cpu8:4401)<3>[bnx2x_panic_dump:634(vmnic0)]begin crash dump
Das Problem wurde in der vorliegenden Version behoben.
- ESXi-Host fällt mit einem violetten Diagnosebildschirm mit einer Meldung des Typs spin count exceeded aus
Ein Netzwerkproblem kann dazu führen, dass ein ESXi-Host mit einem violetten Diagnosebildschirm und einer Fehlermeldung ähnlich der Folgenden ausfällt:
Spin count exceeded (rentry) -possible deadlock with PCPU6
Dieses Problem tritt auf, wenn das System gleichzeitig Daten sendet und die Routing-Tabelle aktualisiert.
Dieses Problem wurde in der vorliegenden Version behoben.
- Die NIC-Gruppierungsrichtlinie funktioniert nicht ordnungsgemäß auf älteren vSwitches
Wenn Sie die Portgruppenrichtlinien der NIC-Gruppierung für einen Parameter konfigurieren, wie z. B. für Lastausgleich, Netzwerk-Failover-Erkennung, Switches-Benachrichtigung oder Failback, und Sie den ESXi-Host anschließend neu starten, sendet der ESXi-Host Daten möglicherweise nur über eine physische Netzwerkkarte.
Dieses Problem wurde in der vorliegenden Version behoben.
- CDP (Cisco Discovery Protocol)-Netzwerkspeicherortinformationen fehlen auf ESXi-Hosts
Der vSphere-Client und das ESX-Kommandozeilenprogramm zeigen CDP-Netzwerkspeicherortinformationen möglicherweise nicht an.
Dieses Problem wurde in der vorliegenden Version behoben.
-
ESXi-Hosts werden möglicherweise nicht gestartet oder sorgen dafür, dass auf einige Geräte nicht zugegriffen werden kann, wenn NetXen 1G NX3031-Geräte oder mehrere 10G NX2031-Geräte eingesetzt werden
Wenn Sie neue NetXen-Netzwerkkarten auf einem ESXi 4.0-Host installieren oder ein Upgrade von ESXi 3.5 auf ESXi 4.0 durchführen, sehen Sie möglicherweise eine Fehlermeldung ähnlich der Folgenden auf der Servicekonsole des ESXi 4.0-Hosts: Out of Interrupt vectors. Auf ESXi-Hosts, wo NetXen 1G- und NX2031 10G-Geräte NetQueue nicht unterstützen, werden möglicherweise die MSI-X-Interrupt-Vektoren knapp. Aufgrund dieses Problems werden ESXi-Hosts möglicherweise nicht gestartet oder es kann auf andere Geräte (z. B. Speichergeräte) nicht zugegriffen werden.
Das Problem wurde in der vorliegenden Version behoben.
Serverkonfiguration
-
Der ESXi-Host generiert keine Warnmeldung, wenn Syslog nicht konfiguriert ist
Wenn Sie die Syslog-Einstellungen auf einem ESXi-Host nicht konfigurieren, generiert der Host weder einen Alarm noch Konfigurationsfehlermeldungen.
Dieses Problem wurde in der vorliegenden Version behoben. Jetzt wird eine Warnmeldung ähnlich der Folgenden auf der Registerkarte Übersicht des ESXi-Hosts angezeigt, wenn Sie Syslog nicht konfigurieren:
Konfigurationsprobleme
Problem auf [Hostname] erkannt in: Warnung: Syslog nicht konfiguriert. Überprüfen Sie die Syslog-Optionen unter "Configuration.Software.AdvancedSettings" im vSphere-Client
-
Syslog-Vorgänge schlagen möglicherweise fehl, wenn der Remotehost nicht erreichbar ist
Der Syslog-Dienst startet nicht, wenn er so konfiguriert ist, dass er sich bei einem Remotehost anmeldet, der nicht über DNS aufgelöst werden kann, wenn der syslogd-Daemon gestartet wird. Dies bewirkt, dass sowohl Remote- als auch lokale Protokollierungsprozesse fehlschlagen.
Dieses Problem wurde in der vorliegenden Version behoben. Falls der Remotehost jetzt nicht aufgelöst werden kann, bleibt dies ohne Auswirkung auf die lokale Protokollierung. Wenn der syslogd-Daemon startet, versucht er alle 10 Minuten erneut, den Host aufzulösen und eine Verbindung mit ihm herzustellen.
Speicher
- Das Verbinden einer Bandbibliothek über eine Adaptec-Karte mit dem aic79xx-Treiber führt möglicherweise zu einem Ausfall von ESXi†
Wenn Ihr ESXi Server an eine Bandbibliothek über einen Adaptec-HBA (z. B.: AHA-39320A) angeschlossen ist, der den aic79xx-Treiber verwendet, könnte der Server ausfallen, wenn der Treiber versucht, auf einen frei gewordenen Speicherbereich zuzugreifen. Bei einem solchen Zustand wird eine Fehlermeldung ähnlich der Folgenden ausgegeben: Loop 1 frame=0x4100c059f950 ip=0x418030a936d9 cr2=0x0 cr3=0x400b9000.
Dieses Problem wurde in der vorliegenden Version behoben.
- 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.
Dieses Problem wurde in der vorliegenden Version behoben.
- ESXi-Host schlägt möglicherweise mit einem violetten Diagnosebildschirm während des Mountens eines virtuellen CD-ROM-Laufwerks vom Server-RSA (Remote Supervisor Adapter) fehl
Dieses Problem wurde in der vorliegenden Version behoben.
-
FalconStor IPStor-Failover verursacht einen APD-Zustand (All Paths Down) in ESXi 4.x bei der Verwendung von Qlogic FC-HBAs
Beim Durchführen eines IPStor-Failovers werden Meldungen ähnlich der Folgenden in /var/log/vmkernelprotokolliert:
vmkernel: 1:10:57:57.524 cpu4:4219)<3>rport-4:0-0: blocked FC remote port time out: saving binding
vmkernel: 1:10:57:57.712 cpu2:4206)<3>rport-3:0-1: blocked FC remote port time out: saving binding
Qlogic hat einen im Lieferumfang dieser Produktversion enthaltenen aktualisierten Treiber freigegeben, der sich mit WWPN-Spoofing, der bevorzugten Methode der FalconStor-Arrays für die Behandlung von Failovers, befasst.
-
ESXi-Host schlägt mit einem violetten Diagnosebildschirm fehl, wenn während der Initialisierung von Dentrycache mehrere Prozesse auf dieselbe Ressource zugreifen
Dieses Problem wurde in der vorliegenden Version behoben.
-
ESXi-Host protokolliert Meldungen in der VMkernel-Protokolldatei, wenn Speicher-Arrays vom vSphere-Client aus neu geprüft werden
ESXi-Hosts protokollieren möglicherweise Meldungen ähnlich der Folgenden in der VMkernel-Protokolldatei für LUNs, die ESXi-Hosts nicht zugeordnet sind: 0:22:30:03.046 cpu8:4315)ScsiScan: 106: Pfad 'vmhba0:C0:T0:L0': Periphere Bezeichner 0x1 wird nicht unterstützt. Dieses Problem tritt auf, wenn ESXi-Hosts gestartet werden, wenn Sie vom vSphere-Client aus einen Vorgang zum erneuten Prüfen der Speicher-Arrays initiieren oder alle 5 Minuten nach dem Start eines ESXi-Hosts.
Dieses Problem wurde in der vorliegenden Version behoben.
-
Das Erstellen von großen .vmdk-Dateien auf NFS schlägt möglicherweise fehl
Wenn auf einem NFS-Speicher versucht wird, eine große virtuelle Festplatte ( .vmdk-Datei) zu erstellen (z. B. mehr als 1 TB), schlägt der Vorgang möglicherweise mit der folgenden Fehlermeldung fehl: Ein allgemeiner Systemfehler ist aufgetreten: Festplatte konnte nicht erstellt werden: Fehler bei der Erstellung der Festplatte. Dieses Problem tritt auf, wenn der NFS-Client nicht lange genug wartet, bis das NFS-Speicher-Array die virtuelle Festplatte initialisiert hat, nachdem eine Zeitüberschreitung des RPC-Parameters für den NFS-Client eingetreten ist. Der Standardwert für die Zeitüberschreitung beträgt 10 Sekunden.
Dieser Fix stellt eine Konfigurationsoption zur Verfügung. Nach Anwenden dieses Fixes können Sie mithilfe des Befehls esxcfg-advcfg -s <Timeout> /NFS/SetAttrRPCTimeoutden Parameter für die RPC-Zeitüberschreitung ändern.
-
ESXi-Host schlägt während LVM-Vorgängen fehl
Wenn Sie Vorgänge durchführen, die den Logical Volume Manager (LVM) verwenden, wie z. B. Schreibvorgänge oder das Neusignieren, Erweitern oder Vergrößern eines Volumes, schlägt der ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm fehl. Möglicherweise werden Fehlermeldungen ähnlich der Folgenden in die Protokolle geschrieben:
63:05:21:52.692 cpu1:4135)OC: 941: Could not get object from FS driver: Permission denied
63:05:21:52.692 cpu1:4135)WARNING: Fil3: 1930: Failed to reserve volume f530 28 1 4be17337 9c7dae2 23004d45 22b547d 0 0 0 0 0 0 0
63:05:21:52.692 cpu1:4135)FSS: 666: Failed to get object f530 28 2 4be17337 9c7dae2 23004d45 22b547d 4 1 0 0 0 0 0 :Permission denied
63:05:21:52.706 cpu1:4135)WARNING: LVM: 2305: [naa.60060e80054402000000440200000908:1] Disk block size mismatch (actual 512 bytes, stored 0 bytes)
Dieses Problem wurde in der vorliegenden Version behoben.
-
Manche virtuelle Maschinen antworten nicht mehr beim erneuten Prüfen des Speichers, wenn sich eine LUN auf dem Host im Status "Keine Pfade verfügbar" befindet
Beim erneuten Prüfen des Speichers antworten manche virtuelle Maschinen nicht mehr, wenn sich eine LUN auf dem Host im Status "Keine Pfade verfügbar" ("all paths down", APD) befindet. Weitere Informationen finden Sie unter KB 1016626. Um bei der Verwendung einer früheren Version des ESXi-Hosts das im KB-Artikel beschriebene Problem zu umgehen, müssen Sie die erweiterte Konfigurationsoption /VMFS3/FailVolumeOpenIfAPDmanuell auf 1 festlegen, bevor Sie eine erneute Prüfung durchführen, und sie nach Abschluss der Prüfung wieder auf 0 zurücksetzen.
Dieses Problem wurde in der vorliegenden Version behoben. Jetzt müssen Sie diese Umgehung (Festlegen und Zurücksetzen dieser erweiterten Konfigurationsoption) beim Starten des Vorgangs zum erneuten Prüfen nicht mehr anwenden. Virtuelle Maschinen auf Nicht-APD-Volumes schlagen während des Vorgangs zum erneuten Prüfen auch dann nicht mehr fehl, wenn sich einige LUNs im Status "Keine Pfade verfügbar" befinden.
-
ESXi-Host fällt mit einem violetten Diagnosebildschirm mit einer Meldung des Typs "Spin count exceeded " aus
Ein mit einem NFS-Datenspeicher verbundener ESXi-Host fällt möglicherweise mit einem violetten Diagnosebildschirm und einer Fehlermeldung ähnlich der Folgenden aus:
0x4100c00875f8:[0x41801d228ac8]ProcessReply+0x223 stack: 0x4100c008761c
0x4100c0087648:[0x41801d18163c]vmk_receive_rpc_callback+0x327 stack: 0x4100c0087678
0x4100c0087678:[0x41801d228141]RPCReceiveCallback+0x60 stack: 0x4100a00ac940
0x4100c00876b8:[0x41801d174b93]sowakeup+0x10e stack: 0x4100a004b510
0x4100c00877d8:[0x41801d167be6]tcp_input+0x24b1 stack: 0x1
0x4100c00878d8:[0x41801d16097d]ip_input+0xb24 stack: 0x4100a05b9e00
0x4100c0087918:[0x41801d14bd56]ether_demux+0x25d stack: 0x4100a05b9e00
0x4100c0087948:[0x41801d14c0e7]ether_input+0x2a6 stack: 0x2336
0x4100c0087978:[0x41801d17df3d]recv_callback+0xe8 stack: 0x4100c0087a58
0x4100c0087a08:[0x41801d141abc]TcpipRxDataCB+0x2d7 stack: 0x41000f03ae80
0x4100c0087a28:[0x41801d13fcc1]TcpipRxDispatch+0x20 stack: 0x4100c0087a58
Dieses Problem könnte sich durch eine vom NFS-Server erhaltene ungültige Antwort auf einen Lesevorgang ergeben, den Sie auf dem NFS-Datenspeicher durchführen.
Dieses Problem wurde in der vorliegenden Version behoben.
-
ESXi-Host fällt aus, wenn VMFS-Snapshot-Volumes mehreren Hosts in einem vCenter Server-Cluster ausgesetzt sind
Ein ESXi-Host fällt möglicherweise mit einem violetten Diagnosebildschirm aus, auf dem eine Fehlermeldung ähnlich der Folgenden angezeigt wird, wenn VMFS-Snapshot-Volumes mehreren Hosts in einem vCenter Server-Cluster ausgesetzt sind.
WARNING: LVM: 8703: arrIdx (1024) out of bounds
Dieses Problem wurde in der vorliegenden Version behoben.
-
ESXi-Host fällt aufgrund eines Problems mit dem megaraid_sas-Treiber aus
Wenn aufgrund eines Gerätefehlers ein E/A-Ausfall im megaraid_sas-Treiber auftritt, wird der Sense-Puffer nicht ordnungsgemäß gefüllt. Dies führt zu einem Ausfall des ESXi-Hosts.
-
ESXi-Host fällt beim Ausführen bestimmter VM-Vorgänge während des Speicher-LUN-Pfad-Failovers aus
Wenn Sie während des Speicher-LUN-Pfad-Failovers einen VM-Vorgang durchführen, der Delta-Festplatten-Metadaten aktualisiert, z. B. das Erstellen oder Löschen von Snapshots, fällt der ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm aus.
Dieses Problem wurde in der vorliegenden Version behoben.
-
Fehlermeldungen werden beim Prüfen auf LUNs im iSCSI-Speicher-Array protokolliert
ESXi-Hosts fallen möglicherweise mit der Meldung NOT_REACHED bora/modules/vmkernel/tcpip2/freebsd/sys/support/vmk_iscsi.c:648auf einem violetten Bildschirm aus, wenn Sie mithilfe des Befehls esxcfg-swiscsioder über den vSphere-Client ( Bestandsliste > Konfiguration > Speicheradapter > iSCSI-Softwareadapter) auf LUNs im iSCSI-Speicher-Array prüfen. Dieses Problem tritt möglicherweise auf, wenn Sie den Parameter tcp.window.sizein /etc/vmware/vmkiscsid/iscsid.confmanuell ändern.
Dieser Fix behebt das Problem und protokolliert außerdem Warnmeldungen in /var/log/vmkiscsid.logfür ESXi, wenn der Wert des Parameters tcp.window.sizein einen Wert geändert wird, der geringer als der Standardwert ist.
-
ESXi-Host mit Software-iSCSI-Initiator schlägt fehl und zeigt iscsi_vmk-Meldungen an
ESXi-Hosts, die Software-iSCSI-Initiatoren verwenden, schlagen möglicherweise mit einem violetten Diagnosebildschirm fehl, auf dem iscsi_vmk-Meldungen ähnlich der Folgenden angezeigt werden:
#PF Exception(14) in world 4254:iscsi_trans_ ip 0x41800965fddb addr 0x8
Code starts at 0x418009000000
0x4100c04f7e50:[0x41800965fddb]iscsivmk_ConnShutdown+0x486 stack: 0x410000000000
0x4100c04f7eb0:[0x418009665e93]iscsivmk_StopConnection+0x286 stack: 0x4100c04f7ef0
0x4100c04f7ef0:[0x418009663e4c]iscsivmk_TransportStopConn+0x12b stack: 0x4100c04f7f6c
0x4100c04f7fa0:[0x418009481654]iscsitrans_VmklinkTxWorld+0x36f stack: 0x1d
0x4100c04f7ff0:[0x41800909870b]vmkWorldFunc+0x52 stack: 0x0
0x4100c04f7ff8:[0x0]Unknown stack: 0x0
Dieses Problem tritt bekanntermaßen auf, wenn E/A-Verzögerungen Zeitüberschreitungen bei E/A-Anfragen verursachen, was letztendlich zum Abbruch führt.
Dieses Problem wurde in der vorliegenden Version behoben.
-
Snapshots von aktualisierten VMFS-Volumes können nicht auf ESXi 4.x-Hosts gemountet werden
Snapshots von VMFS3-Volumes, die von VMFS2 aktualisiert wurden und eine Blockgröße größer als 1 MB aufweisen, können möglicherweise nicht auf ESXi 4.x-Hosts gemountet werden. Der Befehl zum Auflisten der erkannten VMFS-Snapshot-Volumes esxcfg-volume -lschlägt fehl und zeigt die folgende Fehlermeldung an:
~ # esxcfg-volume -l
Fehler: Kein Dateisystem auf dem Gerät
Dieses Problem wurde in der vorliegenden Version behoben. Jetzt können Sie Snapshots von VMFS3-Volumes, die von VMFS2 aktualisiert wurden, mounten und neu signieren.
-
ESXi-Host fällt mit der Fehlermeldung "Ungültiges Objekt gefunden" aus
Ein ESXi-Host fällt möglicherweise mit einem violetten Diagnosebildschirm aus, auf dem Fehlermeldungen ähnlich der Folgenden angezeigt werden:
[7m21:04:02:05.579 cpu10:4119)WARNING: Fil3: 10730: Found invalid object on 4a818bab-b4240ea4-5b2f-00237de12408 expected
21:04:02:05.579 cpu10:4119)FSS: 662: Failed to get object f530 28 2 4a818bab b4240ea4 23005b2f 824e17d 4 1 0 0 0 0 0 :Not found
21:04:02:05.579 cpu0:4096)VMNIX: VMKFS: 2521: status = -2
Dieses Problem tritt auf, wenn eine Adresse im Dateideskriptor des VMFS-Volumes beschädigt ist.
Dieses Problem wurde in der vorliegenden Version behoben.
-
Vorgänge zum erneuten Prüfen von schreibgeschützten VMFS-Volumes dauern sehr lange oder es tritt eine Zeitüberschreitung ein
Vorgänge zum erneuten Prüfen oder zum Hinzufügen von Speicher, die Sie vom vSphere-Client aus durchführen, können aufgrund einer Zeitüberschreitung sehr lange dauern oder fehlschlagen und Meldungen ähnlich der Folgenden werden in die Datei /var/log/vmkernel:
geschrieben:
Jul 15 07:09:30 [vmkernel_name]: 29:18:55:59.297 <cpu id>ScsiDeviceToken: 293: Sync IO 0x2a to device "naa.60060480000190101672533030334542" failed: I/O error H:0x0 D:0x2 P:0x0 Valid sense data: 0x7 0x27 0x0.
Jul 15 07:09:30 [vmkernel name]: 29:18:55:59.298 cpu29:4356)NMP: nmp_CompleteCommandForPath: Command 0x2a (0x4100b20eb140) to NMP device "naa.60060480000190101672533030334542" failed on physical path "vmhba1:C0:T0:L100" H:0x0 D:0x2 P:0x0 Valid sense data: 0x7 0x27 0x0.
Jul 15 07:09:30 [vmkernel_name]: 29:18:55:59.298 cpu29:4356)ScsiDeviceIO: 747: Command 0x2a to device "naa.60060480000190101672533030334542" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x7 0x27 0x0.
VMFS versucht weiterhin, das Volume zu mounten, auch wenn die LUN schreibgeschützt ist.
Dieses Problem wurde in der vorliegenden Version behoben. Ab dieser Version versucht VMFS nicht, das Volume zu mounten, wenn es schreibgeschützt ist.
-
Die Zielinformationen einiger LUNs fehlen in der vCenter Server UI
Die Zielinformationen von LUNs werden manchmal in der vCenter Server-UI nicht angezeigt. In Versionen vor ESXi 4.0 Update 3 zeigen einige iSCSI-LUNs die Zielinformationen nicht an. Führen Sie die folgenden Schritte aus, um auf der Registerkarte Konfigurationdiese Informationen anzuzeigen:
- Klicken Sie unter "Hardware" auf Speicheradapter.
- Klicken Sie im Bereich "Speicheradapter" auf iSCSI-Hostbusadapter.
- Klicken Sie im Bereich "Details" auf Pfade.
-
ESXi-Hosts, die QLogic HBAs verwenden, reagieren aufgrund eines leeren Heap-Speichers nicht
Aufgrund eines leeren Heap-Speichers reagieren ESXi 4.x-Hosts, die QLogic HBAs verwenden, möglicherweise nicht. Die Hosts sind in vCenter Server getrennt und sind über SSH oder den vSphere-Client zugänglich. Fehlermeldungen ähnlich der Folgenden werden in die VMkernel-Protokolldatei geschrieben:
vmkernel: 17:12:38:35.647 cpu14:6799)WARNING: Heap: 1435: Heap qla2xxx already at its maximumSize. Cannot expand.
vmkernel: 17:12:38:35.647 cpu14:6799)WARNING: Heap: 1645: Heap_Align(qla2xxx, 96/96 bytes, 64 align) failed. caller: 0x418011ea149b
Dieses Problem wurde in der vorliegenden Version behoben.
-
VMFS protokolliert irreführende Fehlermeldungen
VMFS-Volumes protokollieren möglicherweise irreführende Fehlermeldungen ähnlich der Folgenden in der VMkernel-Protokolldatei, die auf eine beschädigte Festplatte anstatt auf ein harmloses, nicht initialisiertes Protokollpuffer hindeuten:
Aug 4 21:45:43 [Hostname] vmkernel: 114:02:53:33.345 cpu9:21627)FS3: 3833: FS3DiskLock for [type bb9c7cd0 offset 13516784692132593920 v 13514140778984636416, hb offset 16640
Aug 4 21:45:43 [host name] vmkernel: gen 0, mode 16640, owner 00000006-4cd3bbfe-fece-e61f133cdd37 mtime 35821792] failed at 60866560 on volume [Volume-Name]
Dieses Problem wurde in der vorliegenden Version behoben.
-
Das Anschließen bestimmter USB-Speichergeräte kann dazu führen, dass ein ESXi-Host ausfällt
Das Anschließen bestimmter USB-Speichergeräte kann dazu führen, dass ein ESXi-Host ausfällt. Dabei wird ein violetter Bildschirm und eine Fehlermeldung ähnlich der Folgenden angezeigt:
@BlueScreen: #UD Exception(6) in world 1037009:usb-storage @ 0x41803a844eb6 Code starts at 0x41803a400000 0x4100c168fe90:[0x41803a844eb6]usb_stor_invoke_transport+0x73d stack: 0x10 0x4100c168feb0:[0x41803a842158]usb_stor_transparent_scsi_command+0x1b stack: 0x7d41af17b64564
0x4100c168ff30:[0x41803a8467b9]usb_stor_control_thread+0x7c4 stack: 0x4100b0fdbaa0
0x4100c168ff60:[0x41803a7c51f2]kthread+0x79 stack: 0x41000000000e
0x4100c168ffa0:[0x41803a7c2b62]LinuxStartFunc+0x51 stack: 0xe
0x4100c168fff0:[0x41803a49870b]vmkWorldFunc+0x52 stack: 0x0
ESXi erkennt diese Protokollverletzungen jetzt und behandelt sie entsprechend.
-
Der ESXi-Host antwortet nicht mehr, wenn eines der gespiegelten Installationslaufwerke vom Server entfernt wird
Ein ESXi-Host antwortet möglicherweise nicht mehr, wenn Sie eines der gespiegelten Installationslaufwerke von dem Server entfernen, der mit einem LSI SAS-Controller verbunden ist. Der ESXi-Host zeigt Meldungen ähnlich der Folgenden an:
[329125.915302] sd 0:0:0:0: still retrying 0 after 360 s
[329175.056594] sd 0:0:0:0: still retrying 0 after 360 s
[329226.201904] sd 0:0:0:0: still retrying 0 after 360 s
[329276.339208] sd 0:0:0:0: still retrying 0 after 360 s
[329326.478513] sd 0:0:0:0: still retrying 0 after 360 s
Dieses Problem wurde in der vorliegenden Version behoben.
-
ESXi-Host schlägt mit einem violetten Bildschirm fehl und zeigt einen ENOMEM-Zustandsfehler des Typs "Unhandled Async_Token" an
Aufgrund eines Arbeitsspeicherzuteilungsfehlers auf einem System, das beim Zuteilen von Async_Tokenfür die E/A-Behandlung Arbeitsspeichereinschränkungen unterliegt, fällt der ESXi-Host aus.
In der vorliegenden Version wird das Auftreten dieses Problems stark verringert.
Upgrade und Installation
- Auf ESXi 3.5-Hosts erstellte Snapshots können nicht wiederhergestellt werden
ESXi-Hosts können nicht zu einem vorherigen Snapshot zurückkehren, nachdem Sie ein Upgrade von ESXi 3.5 Update 4 auf ESXi 4.0 Update 3 durchgeführt haben. Die folgende Meldung wird möglicherweise in vCenter Server angezeigt, falls Sie versuchen, einen solchen Vorgang durchzuführen: Die Funktionen des oder der Prozessoren in dieser Maschine unterscheiden sich von denjenigen der Maschine, auf der der Prüfpunkt gespeichert wurde. Versuchen Sie, den Snapshot auf einer Maschine zu verwenden, deren Prozessoren über die gleichen Funktionen verfügen. Dieses Problem tritt möglicherweise auf, wenn Sie virtuelle Maschinen auf ESXi 3.0-Hosts erstellen, vMotion ausführen, virtuelle Maschinen auf ESXi 3.5-Hosts anhalten und diese anschließend auf ESXi 4.x-Hosts fortsetzen.
Die Fehlermeldung erscheint nicht in der vorliegenden Version. Sie können Snapshots wiederherstellen, die auf ESXi 3.5-Hosts erstellt wurden, und dann die virtuellen Maschinen auf ESXi 4.x-Hosts fortsetzen.
-
In dieser Version ist eine aktualisierte Version des PVSCSI-Treibers enthalten, damit Sie das Windows XP-Gastbetriebssystem installieren können
Verwaltung virtueller Maschinen
- Geräte, die im laufenden Betrieb nicht vom vSphere-Client getrennt werden können, können auf einer virtuellen Maschine entfernt werden, auf der Fault Tolerance aktiviert ist
Wenn Fault Tolerance aktiv ist, sollten Sie nicht in der Lage sein, Geräte, wie z. B. Netzwerkkarten und SCSI-Controller, im laufenden Betrieb vom vSphere-Client zu entfernen, wenn die virtuelle Maschine ausgeführt wird. Allerdings erscheinen diese als Wechselmedien in der Windows-Taskleiste der virtuellen Maschine und Sie können sie von innerhalb des Gastbetriebssystems entfernen.
Dieses Problem wurde in der vorliegenden Version behoben. Jetzt können Sie über die Taskleiste der virtuellen Maschine keine Geräte entfernen, wenn Fault Tolerance aktiviert ist.
-
Snapshot-Delta-Dateien werden nicht gelöscht, wenn Snapshots in einem benutzerdefinierten Verzeichnis erstellt werden
Alle Snapshots werden in einem Standard-VM-Verzeichnis erstellt. Wenn Sie jedoch ein benutzerdefiniertes Verzeichnis für Snapshots angeben, verbleiben die Snapshot-Delta-Dateien möglicherweise in diesem Verzeichnis, wenn Sie Snapshots löschen. Diese redundanten Dateien beanspruchen Speicherplatz und müssen daher manuell gelöscht werden.
Dieses Problem wurde in der vorliegenden Version behoben.
- Das Anhalten von VMware Tools, während ein Snapshot einer stillgelegten virtuellen Maschine erstellt wird, führt zu einem Ausfall von hostd
Dieses Problem wurde in der vorliegenden Version behoben. Jetzt schlägt der stillgelegte Snapshot-Vorgang allmählich fehl, wenn VMware Tools angehalten wird.
-
Virtuelle Maschinen werden in manchen Fällen auch dann nicht gestartet, wenn Auslagerungsspeicherplatz auf ESXi-Hosts vorhanden ist
Das Einschalten einer virtuellen Maschine, die auf einem ESXi 4.0-Host ausgeführt wird, schlägt mit der Fehlermeldung Insufficient COS swap to power onin /var/log/vmware/hostd.logfehl, obwohl die Maschine über freien Speicherplatz verfügt. Nach der Installation dieses Updates können Sie virtuelle Maschinen einschalten.
-
Der ESXi-Host reagiert beim Durchführen eines RevertSnapshot- oder RevertToCurrentSnapshot-Vorgangs möglicherweise nicht mehr
Beim Durchführen eines RevertSnapshot- oder RevertToCurrentSnapshot-Vorgangs von vCenter Server aus, reagiert ein ESXi-Host möglicherweise nicht mehr. Eine Fehlermeldung ähnlich der Folgenden wird in hostd.logprotokolliert:
Apr 22 08:46:26 Hostd: [2010-04-22 08:46:26.381 'App' 49156 error] Caught signal 11
Dieses Problem wurde in der vorliegenden Version behoben.
-
Virtuelle Maschine schlägt während vMotion fehl
Wenn bei dem NFS-Volume, das eine virtuelle Maschine hostet, Fehler auftreten, könnte die NVRAM-Datei der virtuellen Maschine beschädigt werden und von der Standardgröße 8 KB auf eine Größe von mehreren Gigabyte anwachsen. Wenn Sie zurzeit einen vMotion- oder Suspend-Vorgang durchführen, schlägt die virtuelle Maschine mit einer Fehlermeldung ähnlich der Folgenden fehl:
nicht behebbarer Fehler bei der Arbeitsspeicherreservierung bei bora/lib/snapshot/snapshotUtil.c:856
Dieses Problem wurde in der vorliegenden Version behoben.
- VM-Befehle schlagen fehl, wenn sie über hostd aufgerufen werden, unmittelbar nachdem eine virtuelle Maschine ausgeschaltet wurde
Ein VM- Befehl, wie z. B. PowerOn, den Sie über hostd aufrufen, unmittelbar nachdem eine virtuelle Maschine ausgeschaltet wurde, schlägt möglicherweise mit einer Fehlermeldung ähnlich der Folgenden fehl:
Ein angegebener Parameter war nicht korrekt
Eine Fehlermeldung ähnlich der Folgenden wird möglicherweise in die vCenter-Protokolldatei geschrieben:
[2009-11-16 15:06:09.266 01756 error 'App'] [vm.powerOn] Received unexpected exception
Dieses Problem wurde in der vorliegenden Version behoben.
- Leistungseinbußen werden bei mit CPU-Limits konfigurierten virtuellen Maschinen verzeichnet, die auf ESXi-Hosts 4.x ausgeführt werden (KB 1030955)
- Virtuelle Maschine werden beim Erstellen oder Löschen von Snapshots manchmal ausgeschaltet
Wenn Sie beim Durchführen von Snapshot-Vorgängen gleichzeitig eine andere Aufgabe durchführen, wie z. B. das Durchsuchen eines Datenspeichers, wird die virtuelle Maschine möglicherweise abrupt ausgeschaltet. Fehlermeldungen ähnlich der Folgenden werden in die Protokolldatei vmware.loggeschrieben:
vmx| [msg.disk.configureDiskError] Reason: Failed to lock the file
vmx| Msg_Post: Error
vmx| [msg.checkpoint.continuesync.fail] Fehler beim Neustart der virtuellen Maschine nach dem Erstellen eines Snapshots. Die virtuelle Maschine wird ausgeschaltet.
Dieses Problem tritt auf, wenn ein anderer Prozess auf dieselbe Datei zugreift, die von der virtuellen Maschine für einen Vorgang benötigt wird.
Dieses Problem wurde in der vorliegenden Version behoben.
-
Das Festschreiben eines Snapshots von der Befehlszeile aus schlägt mit einer Rückverfolgung fehl
Beim Ausführen des Befehls vmware-cmd <vmx> removesnapshotssehen Sie möglicherweise eine Rückverfolgung ähnlich der Folgenden:
Traceback (most recent call last):
File "/usr/bin/vmware-cmd", line 88, in ?
main()
File "/usr/bin/vmware-cmd", line 63, in main
operationName, result = CommandProcessor.Process(host, args)
File "/usr/lib/vmware/vmware-cmd/CommandProcessor.py", line 11, in Process
result = operation.DoIt(*processedArgs)
File "/usr/lib/vmware/vmware-cmd/operations/SnapshotOps.py", line 122, in DoIt
Der Befehl vmware-cmd <vmx> removesnapshotsschlägt fehl, weil die Datei <vm_name>-aux.xml, die sich in demselben Verzeichnis wie die Konfigurationsdatei der virtuellen Maschine befindet, leer ist. Wenn eine virtuelle Maschine auf einem Host erstellt oder registriert wird, wird der Inhalt der Datei <vm_name>-aux.xmleingelesen und das _view-Objekt gefüllt. Wenn die XML-Datei leer ist, wird das _view-Objekt nicht gefüllt. Dies führt zu einem Fehler beim Konsolidieren des Snapshots.
Dieses Problem wurde in der vorliegenden Version behoben.
- Das Hinzufügen von Arbeitsspeicher im laufenden Betrieb schlägt fehl, wenn der zugewiesene VM-Arbeitsspeicher mit der Größe seiner Speicherreservierung übereinstimmt
Eine Fehlermeldung ähnlich der Folgenden erscheint im vSphere-Client:
Hinzufügen von Arbeitsspeicher im laufenden Betrieb fehlgeschlagen. Ziel-VM konnte nicht fortgesetzt werden: Ungültiger Parameter. Hotplug-Vorgang fehlgeschlagen
Meldungen ähnlich der Folgenden werden in die Protokolldatei /var/log/vmkernelgeschrieben:
WARNING: FSR: 2804: 1270734344 D: Received invalid swap bitmap lengths: source 0, destination 32768! Failing migration.
WARNUNG: FSR: 3425: 1270734344 D: Der Auslagerungsstatus konnte von der virtuellen Quellmaschine nicht übertragen werden: Bad parameter
WARNING: FSR: 4006: 1270734344 D: Die Auslagerungsdatei konnte von der virtuellen Quellmaschine auf die virtuelle Zielmaschine nicht übertragen werden.
Dieses Problem tritt auf, wenn während des Hot-Add-Vorgangs Fast Suspend Resume (FSR) fehlschlägt.
Dieses Problem wurde in der vorliegenden Version behoben.
vMotion und Storage vMotion
VMware Tools
- Perfmon führt keine VM-Leistungsindikatoren nach der Installation von VMware Tools auf
Nach der Installation von VMware Tools erscheinen VM-Speicher und VM-Prozessor in der Liste der Leistungsindikatoren im Windows-Systemmonitor (Perfmon) möglicherweise nicht, wenn ein anderer Prozess auf die Datei zugreift, die von der virtuellen Maschine für einen Vorgang benötigt wird. Das Aktualisieren oder Reparieren von VMware Tools behebt dieses Problem nicht.
Nachdem Sie diese Update-Version installieren, können Sie ein Upgrade oder Reparatur von VMware Tools durchführen, um das Problem zu beheben.
-
Das Erstellen von stillgelegten Snapshots schlägt möglicherweise auf nicht-englischen Versionen von Microsoft Windows-Gastbetriebssystemen fehl
Dieses Problem tritt auf, wenn ein bekannter Windows-Ordnerpfad Nicht-ASCII-Zeichen enthält (zum Beispiel der Anwendungsdatenordner in tschechischen Windows-Gastbetriebssystemen). Das Vorhandensein von Nicht-ASCII-Zeichen führt dazu, dass der Snapshot-Vorgang fehlschlägt.
Dieses Problem wurde in der vorliegenden Version behoben.
-
VMware-Systemsteuerungs-UI-Schaltfläche in der Windows-Systemsteuerung zum Durchführen des Upgrades für VMware Tools ist deaktiviert
Die VMware-Systemsteuerungs-UI-Schaltfläche in der Windows-Systemsteuerung zum Durchführen des Upgrades für VMware Tools von einem Windows-Gastbetriebssystem aus ist für Nicht-Administratoren deaktiviert. Zudem werden die Optionen "Verkleinern" und "Skripts" in der VMware Tools-Systemsteuerung für Nicht-Administratoren deaktiviert. Dieser Fix besteht lediglich aus einer UI-Änderung und blockiert keine Upgrades von benutzerdefinierten Anwendungen. Um Upgrades von VMware Tools für alle Benutzer zu blockieren, legen Sie in der VMX-Datei den Parameter isolation.tools.autoinstall.disable="TRUE"fest.
- Einträge in der Konfigurationsdatei werden während der Installation von VMware Tools auf virtuellen Linux-Maschinen überschrieben
Wenn Sie auf virtuellen Linux-Maschinen VMware Tools installieren oder aktualisieren, überschreibt das VMware Tools-Installationsprogramm möglicherweise Einträge in der Konfigurationsdatei (z. B. in der Datei /etc/updatedb.conffür Redhat und Ubuntu und in /etc/sysconfig/locatefür SuSE), die von den Entwicklungstools von Drittanbietern vorgenommen wurden. Dies könnte Auswirkungen auf Cron-Aufträgen haben, die updatedbauf diesen virtuellen Maschinen ausführen.
Dieses Problem wurde in der vorliegenden Version behoben.
- Snapshots stillgelegter virtueller Maschinen schlagen möglicherweise auf einigen nicht-englischen Versionen der Windows-Gastbetriebssysteme
Snapshots stillgelegter virtueller Maschinen schlagen möglicherweise auf einigen nicht-englischen Versionen der Windows-Gastbetriebssysteme fehl, beispielsweise auf französischen Gastbetriebssystemversionen von Windows 2008 R2 und Windows 7. Dieses Problem tritt auf, weil der VMware Snapshot Provider-Service auf einigen nicht-englischen Versionen der Microsoft Windows-Gastbetriebssysteme nicht ordnungsgemäß als Windows-Dienst oder COM+-Anwendung registriert wird. Dieses Problem führt dazu, dass der Snapshot-Vorgang fehlschlägt und daher kein Snapshot erstellt wird.
Dieses Problem wurde in der vorliegenden Version behoben.
- Nach der Installation von VMware Tools werden beim Neustart virtueller Linux-Maschinen überflüssige Fehler angezeigt
Nachdem Sie VMware Tools für Linux installiert und das Gastbetriebssystem gestartet haben, meldet der Geräte-Manager für den Linux-Kernel (udev) möglicherweise überflüssige Fehler ähnlich der Folgenden:
May 4 16:06:11 rmavm401 udevd[23137]: add_to_rules: unknown key 'SUBSYSTEMS'
May 4 16:06:11 rmavm401 udevd[23137]: add_to_rules: unknown key 'ATTRS{vendor}'
May 4 16:06:11 rmavm401 udevd[23137]: add_to_rules: unknown key 'ATTRS{model}'
May 4 16:06:11 rmavm401 udevd[23137]: add_to_rules: unknown key 'SUBSYSTEMS'
May 4 16:06:11 rmavm401 udevd[23137]: add_to_rules: unknown key 'ATTRS{vendor}'
May 4 16:06:11 rmavm401 udevd[23137]: add_to_rules: unknown key 'AT
This issue is resolved in this release. Jetzt erkennt das VMware Tools-Installationsprogramm für Linux das Gerät und schreibt nur systemspezifische Regeln.
-
Nach einem Upgrade von VMware Tools schlägt die Netzwerkkonnektivität auf einer virtuellen Windows-Maschine fehl, wenn der HGFS-Treiber nicht ordnungsgemäß deinstalliert wurde
Wenn Sie ein Upgrade von VMware Tools mit installiertem HGFS von ESX 3.5 auf ESX 4.0 durchführen, ist es möglich, dass der HGFS-Treiber nicht ordnungsgemäß deinstalliert wird. Folglich zeigt die Netzwerk-Registerkarte Anbieterreihenfolge der virtuellen Windows-Maschine unter Netzwerkverbindungen > Erweitert > Erweiterte Einstellungen falsche Informationen an und die Netzwerkverbindung der virtuellen Maschine wird möglicherweise unterbrochen.
Dieses Problem wurde in der vorliegenden Version behoben. Jetzt werden während des Upgrades die frühere Version des HGFS-Treibers und alle damit zusammenhängenden Registrierungseinträge ordnungsgemäß deinstalliert.
- Aktualisierung des PVSCSI-Treibers
In dieser Version wird für die Gastbetriebssysteme Windows XP (32- und 64-Bit), Windows Server 2003 (32- und 64-Bit), Windows Vista (32- und 64-Bit), Windows Server 2008 RTM (32- und 64-Bit), Windows 7 (32- und 64-Bit) und Windows Server 2008 R2 (64-Bit) der PVSCSI-Treiber auf Version 1.0.7.0 aktualisiert.
-
Bei gewissen Gastbetriebssystemen tritt ein nicht behobener Fehler des Typs "symbol __stack" auf, wenn Sie VMware Tools installieren
Beim Installieren von VMware Tools auf bestimmten Gastbetriebssystemen, wie z. B. RHEL 3, sehen Sie möglicherweise eine Fehlermeldung ähnlich der Folgenden:
Symbol __stack_chk_fail from module /usr/X11R6/lib/modules/drivers/vmware_drv.o is unresolved!
Dieses Problem wurde in der vorliegenden Version behoben.
-
Automatisches Upgrade von VMware Tools funktioniert nicht, wenn die Hardwarebeschleunigung auf einer virtuellen Windows-Maschine auf "Keine" festgelegt ist
Wenn die Hardwarebeschleunigung auf einer virtuellen Windows-Maschine auf Keine festgelegt ist (auch dann, wenn Sie sie mithilfe der Option Tools vor jedem Einschaltvorgang prüfen und aktualisieren konfigurieren), wird das Upgrade von VMware Tools nicht sofort nach dem Neustart der virtuellen Maschine durchgeführt. Das Upgrade von VMware Tools wird nur dann durchgeführt, wenn Sie auf das Hardwarebeschleunigungs-Dialogfeld reagieren, das von der virtuellen Maschine nach der Anmeldung angezeigt wird.
Dieses Problem wurde in der vorliegenden Version behoben.
Seitenanfang
Bekannte Probleme
In diesem Abschnitt werden bekannte Probleme dieser Version unter den folgenden Themengebieten beschrieben:
Behobene Probleme, die früher nicht dokumentiert wurden, werden mit einem Sternchen (*) markiert.
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 auf der Registerkarte Hardwarestatus für Server vom Typ IBM x3850 und x3950 M2 nicht für alle Statuszustände des PS VRM-Sensors 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. Diese falsche Versionsnummer wirkt sich jedoch nicht auf die Nutzung des SLP-Dienstes aus. Für dieses Problem gibt es zurzeit keine Umgehung.
-
Das CIM-Indication-Abonnement ist nach einem ESXi-Update nicht mehr verfügbar
Das CIM-Indication-Abonnement geht verloren, wenn Sie zwischen ESXi-Updates aktualisieren oder Patches aufspielen. Die Informationen zum Empfänger der Indication 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 eine erneute Subskription der CIM-Indications durch
Möglicherweise ist es nicht möglich, diese Umgehung anzuwenden. In manchen Fällen ist ein erneutes Abonnement der CIM-Indications nicht möglich.
- Kopieren sie die entsprechenden Dateien aus dem Backup-Repository in das neue Repository, wie in den nachfolgenden Teilschritten beschrieben.
Bei dieser Umgehung werden die CIM XML-Indication-Abonnements 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 aktualisieren, sollten Sie vorübergehend den erweiterten vmxnet-Adapter neu konfigurieren, 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 ESXi 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 ESXi 4.0 Update 1-Host manuell.
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: Aktualisieren 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.
-
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.
-
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
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 mehrere Sitzungen, die auf denselben Endpunkt zugreifen.
Umgehung: Keine. Verwenden Sie nicht denselben iSCSI-Namen, wenn Sie Ziele hinzufügen.
-
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:
WARNING: vmklinux26: __request_region: Diese Meldung wurde einmal wiederholt: Region conflict @ 0x0 => 0x3
Umgehung: Solche Fehlermeldungen sind harmlos und können bedenkenlos ignoriert werden.
-
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 das 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 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
-
Das Starten von VMware ESX schlägt möglicherweise auf Dell 2900-Servern fehl
Wenn auf einem Server des Typs Dell 2900 ein älteres BIOS als 2.1.1 installiert ist, reagiert der VMkernel von ESX während des Starts möglicherweise nicht mehr. Dies ist auf einen Fehler im Dell BIOS zurückzuführen, der in der BIOS-Version 2.1.1 behoben ist. Umgehung: Aktualisieren Sie das BIOS auf die Version 2.1.1 oder später.
- VMware ESXi Embedded starten nicht auf Servern des Typs HP DL385 G2, wenn das BIOS USB 1.1-Controller verwendet
Systeme mit VMware ESXi Embedded erkennen auf Servern des Typs HP DL385 G2 die USB 1.1-Controller nicht. Daher schlägt der Start des ESXi-Systems fehl. Dieses Problem tritt auf Servern des Typs HP DL385 G2 immer auf, wenn das BIOS so eingestellt ist, dass der USB 1.1-Controller verwendet wird. Umgehung: Aktivieren Sie während der Startphase eines Systems mit ESXi Embedded den USB 2.0-Controller in den BIOS-Einstellungen. In manchen Installationen wird dieser Controller als V1.1+V2.0 angezeigt.
-
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.
-
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
-
vSphere Host Update Utility zeigt während eines Upgrades von ESXi 3.5.x auf ESXi 4.0.x eine falsche Fehlermeldung an *
Wenn Sie mit dem vSphere Host Update Utility ein Upgrade von ESXi 3.5.x auf ESXi 4.0.x durchführen, zeigt das Dienstprogramm möglicherweise eine Fehlermeldung ähnlich der Folgenden an:
Versuch, in geschütztem Arbeitsspeicher zu lesen oder darin zu schreiben. Dies ist oft ein Hinweise darauf, dass anderer Arbeitsspeicher beschädigt ist
Umgehung: Keine. Sie können diese Fehlermeldung ignorieren.
-
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 nicht über eine 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.
-
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.
-
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: Fehler beim Erstellen des vCenter-Repositorys
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.
-
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, bis die Aufgaben zum Zeitpunkt ihrer
Nächsten Ausführung
ausgeführt werden, bevor Sie aktualisieren.
- 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-Services 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.
- Upgrades schlagen fehl, wenn zwei Versionen von ESXi auf derselben Maschine vorhanden sind
Auf derselben Maschine werden zwei Versionen von ESXi nicht unterstützt. Sie müssen eine der Versionen entfernen. Die folgenden Umgehungen gelten für die möglichen Kombinationen zweier ESXi-Versionen auf derselben Maschine.
Umgehungen:
- ESXi Embedded und ESXi Installable befinden sich auf derselben Maschine und wenn Sie ESXi Installable entfernen und nur ESXi Embedded verwenden möchten, führen Sie die folgenden Schritte aus.
- Stellen Sie sicher, dass Sie die Maschine von dem ESX Embedded-USB-Flash-Gerät aus starten.
- Kopieren Sie die virtuelle Maschinen von dem ESXi Installable-VMFS-Datenspeicher in den ESXi Embedded-VMFS-Datenspeicher.
Dies ist Best Practice, um Datenverlust zu vermeiden.
- Entfernen Sie alle Partitionen mit Ausnahme der VMFS-Partition von der Festplatte, auf der ESXi Installable installiert ist.
- Starten Sie die Maschine neu und konfigurieren Sie die Starteinstellung für das Starten vom USB-Flash-Gerät.
- ESXi Embedded und ESXi Installable befinden sich auf derselben Maschine und wenn Sie ESXi Embedded entfernen und nur ESXi Installable verwenden möchten, führen Sie die folgenden Schritte aus.
- Starten Sie das System von ESXi Installable aus.
- Starten Sie die Maschine neu und konfigurieren Sie die Starteinstellung, sodass sie nicht vom USB-Laufwerk, sondern von der Festplatte gestartet wird, auf der Sie ESXi installiert haben.
- Sofern Sie das ESXi Embedded-USB-Gerät entfernen können, entfernen Sie es. Wenn das USB-Gerät ein internes Gerät ist, löschen oder überschreiben Sie die USB-Partitionen.
- Wenn sich zwei Versionen von ESXi Embedded oder zwei Versionen von ESXi Installable auf derselben Maschine befinden, entfernen Sie eine der beiden Installationen.
-
Die Patch-Installation mit "vihostupdate" schlägt auf ESXi-Hosts bei Dateigrößen über 256 MB fehl
Die Patch-Installation auf einem ESXi 4.0-Host schlägt fehl, wenn Sie die Installation anhand des Befehls "vihostupdate" auf einem Server durchführen, für den kein Scratch-Verzeichnis konfiguriert ist, und die Größe der heruntergeladenen Datei mehr als 256 MB beträgt. Die Installation schlägt in der Regel auf einer Hostmaschine fehl, die über keine zugewiesene LUN bzw. keine ESXi 4.0-Installation auf Fibre-Channel- oder SAS-Festplatte verfügt.
Sie sollten die Einstellungen für das Scratch-Verzeichnis auf dem ESXi Server überprüfen und sicherstellen, dass das Scratch-Verzeichnis konfiguriert ist. Wenn der ESXi Server anfänglich startet, versucht das System, das Scratch-Verzeichnis automatisch zu konfigurieren. Wenn für das Scratch-Verzeichnis kein Speicher zur Verfügung steht, ist das Scratch-Verzeichnis nicht konfiguriert und verweist auf ein temporäres Verzeichnis.
Umgehung
Um die Größenbegrenzung für eine einzelne Datei zu umgehen, sollten Sie unter Verwendung des vSphere-Clients ein Scratch-Verzeichnis auf einem VMFS-Volume konfigurieren.
So konfigurieren Sie das Scratch-Verzeichnis:
- Stellen Sie über den vSphere-Client eine Verbindung zum Host her.
- Wählen Sie den Host in der Bestandsliste aus.
- Klicken Sie auf die Registerkarte Konfiguration.
- Wählen Sie in der Liste mit den Softwareeinstellungen Erweiterte Einstellungen aus.
- Suchen Sie nach "ScratchConfig" in der Parameterliste und setzen Sie den Wert für "ScratchConfig.ConfiguredScratchLocation" auf ein Verzeichnis auf einem VMFS-Volume, das mit dem Host verbunden ist.
- Klicken Sie auf OK.
- Starten Sie die Hostmaschine neu, damit die Änderungen am Host wirksam werden.
-
Der Befehl "vihostupdate" kann auf ESXi 4.0-Hosts fehlschlagen, für die das Scratch-Verzeichnis nicht konfiguriert ist
Je nach Konfiguration des Scratch-Verzeichnisses können Paketgrößen, wie z. B. die Größe des ESXi 4.0 Update 1-Pakets, möglicherweise zu groß für einen ESXi 4.0-Host sein. Wenn Sie in solchen Fällen eine Installation mithilfe von vihostupdate durchführen, schlägt die Installation fehl, wenn das Scratch-Verzeichnis nicht für die Verwendung von Speicher konfiguriert ist, der von der Festplatte unterstützt wird.
Umgehung: Sie können mithilfe des VMware vSphere-Clients oder von VMware Update Manager die Konfiguration des Scratch-Verzeichnisses ändern. Die folgende Schritte veranschaulichen die Verwendung des Clients.
- Überprüfen Sie die Konfiguration des Scratch-Verzeichnisses.
Nachfolgend wird der Navigationspfad des vSphere-Clients dargestellt:
Konfiguration> Erweiterte Einstellungen> ScratchConfig
Folgendes gilt für einen ESXi-Host:
- Wenn das Scratch-Verzeichnis auf /tmp/scratch festgelegt wird, ist die Größe des Pakets eingeschränkt. Sie können beispielsweise ein Patchpaket von 163 MB anwenden, ein Update-Paket, wie z. B. ein ESXi 4.0-Update-Paket von 281 MB, jedoch nicht.
- Wenn das Scratch-Verzeichnis auf den Pfad des VMFS-Volumes festgelegt wurde, können Sie Pakete bis zu der Größe eines ESXi 4.0-Pakets von 281 MB anwenden.
- Verwenden Sie den vSphere-Client, um das Scratch-Verzeichnis entsprechend zu ändern.
Nachfolgend wird der Navigationspfad des vSphere-Clients dargestellt: Konfiguration> Erweitert Einstellungen> ScratchConfig.
- Starten Sie den ESXi-Host neu, damit die geänderten Einstellungen wirksam werden.
- Rufen Sie den Befehl vihostupdate.pl auf, um das Paket zu installieren.
Sie können beispielsweise einen Befehl ähnlich dem Folgenden aufrufen (ersetzen Sie die Platzhalter gemäß Ihren Erfordernissen):
vihostupdate.pl --server --username root --password --bundle http:// .zip --install
-
Wenn ESXi 3.5 auf ESXi 4.0 Update 3 aktualisiert wird, zeigt der Befehl "esxupdate query" die installierten Bulletins nicht an
Bulletins werden im Rahmen des Upgrades von ESXi 3.5 auf ESXi 4.0 Update 3 installiert. Nach dem Upgrade zeigt der Befehl esxupdate query jedoch keine Bulletins an.
Umgehung: Dieses Problem hat keine Auswirkung auf die Kernfunktionalität des Hosts. Das Problem kann nicht umgangen werden.
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öserbedingungen festgelegt. Sie brauchen nur noch einzustellen, welche Aktion bei Alarmauslösung durchgeführt werden soll.
-
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, von dem Quellsystem vCenter Converter zu deinstallieren. Der Importvorgang gelingt, aber die folgende Fehlermeldung wird angezeigt, wenn Guided Consolidation versucht, vCenter Converter zu deinstallieren: VMware Converter-Agent-Installation ist fehlgeschlagen
.
Umgehung: Deinstallieren Sie vCenter Converter von den Quellsystemen, bevor Sie versuchen, sie unter Verwendung von Guided Consolidation zu importieren.
-
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 "Netzwerk" 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.
-
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.
-
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 alle 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.
-
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 einer virtuellen Maschine vom Typ "Verknüpfter Klon" größer ist als die unterstützte Tiefe von 32
Wenn die Delta-Festplattentiefe eines verknüpften Klons größer ist als die unterstützte Tiefe von 32, 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 Thickkeine 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 regenerieren.
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
definiert die Startverzögerung.
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 der virtuellen CD-ROM 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 Fault Tolerance
-
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
-
Die IP-Virtualisierung von Windows Server 2008 R2 (64-Bit) funktioniert auf vSphere 4.0 Update 1 möglicherweise nicht *
Die IP-Virtualisierung, die es Ihnen ermöglicht, RDP-Sitzungen eindeutige IP-Adressen zuzuteilen, funktioniert möglicherweise nicht auf einem Windows 2008 R2 Terminal Server, der unter vSphere 4.0 Update 1 ausgeführt wird. Die IP-Virtualisierung funktioniert jedoch, wenn Sie einen physischen Windows 2008 R2 Terminal Server konfigurieren oder eine virtuelle Windows 2008 R2-Maschine unter XenServer 5.5 Update 2 Dell OEM Edition ausführen. Dieses Problem tritt möglicherweise auf, wenn Sie VMware Tools nach der Installation der Remotedesktopdienste installieren.
Umgehung: Wählen Sie die Option für eine benutzerdefinierte Installation von VMware Tools und entfernen Sie VMCI aus der Liste der Treiber, die installiert werden sollen.
-
Unter bestimmten Bedingungen reagieren Snapshots einer virtuellen Maschine nicht
Versuche, einen Snapshot einer virtuellen Maschine zu erstellen, führen möglicherweise dazu, dass der Status Vorgang läuftangezeigt wird, wenn alle der 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