ESXi 4.0 Update 1 Installable | 19. November 2009 | Build 208167 ESXi 4.0 Update 1 Embedded | 19. November 2009 | Build 208167 Letzte Dokumentaktualisierung: 10 Dez. 2009 |
Diese Versionshinweise decken die folgenden Themen ab:
Neuigkeiten
Sie erhalten nachstehend Informationen zu einigen der wichtigsten Verbesserungen in der vorliegenden Version von VMware ESXi:
Unterstützung für VMware View 4.0 – In dieser Version wird VMware View 4.0 unterstützt, eine Lösung, die speziell für das Bereitstellen von Desktops als verwalteten Dienst vom Protokoll zur Plattform entwickelt wurde.
Windows 7- und Windows 2008 R2-Unterstützung –Diese Version unterstützt 32- und 64-Bit-Versionen von Windows 7 sowie Windows 2008 R2 (64-Bit) als Gastbetriebssystemplattformen. Zudem wird der vSphere-Client jetzt unterstützt und kann auf einer Windows 7-Plattform installiert werden. Eine vollständige Liste der von dieser Version unterstützten Gastbetriebssysteme finden Sie im VMware-Kompatibilitätshandbuch .
Erweiterte Clustering-Unterstützung für Microsoft Windows – Microsoft Cluster Server (MSCS) für Windows 2000 und 2003 und das Failover-Clustering für Windows Server 2008 wird jetzt auf einem VMware High Availability- (HA) und Dynamic Resource Scheduler-Cluster (DRS) in einer eingeschränkten Konfiguration unterstützt. Die HA- und DRS-Funktionalität kann für individuelle virtuelle MSCS-Maschinen effektiv deaktivert werden, ohne dass HA und DRS auf dem ganzen ESX/ESXi-Host deaktiviert werden müssen .Im Handbuch Einrichten für das Failover-Clustering und Microsoft Cluster Service finden Sie zusätzliche Konfigurationsrichtlinien.
Erweiterte Unterstützung für VMware Paravirtualized SCSI – Windows 2003- und 2008-Gastbetriebssysteme unterstützen nun an einen PVSCSI-Adapter (Paravirtualized SCSI) angeschlossene Startlaufwerke. Es stehen auch Diskettenimages mit dem bei der Windows-Installation benötigten Treiber zur Verfügung. Drücken Sie während der Installation auf F6, um zusätzliche Treiber zu installieren. Disketten-Images befinden sich im Ordner /vmimages/floppies/.
Verbesserte Leistung des verteilten vNetwork-Switches – Mehrere Leistungs- und Nutzungsprobleme wurden behoben. Dadurch wurde Folgendes erreicht:
- Verbesserte Leistung bei Änderungen an der Konfiguration einer Instanz eines verteilten vNetwork-Switches (vDS), wenn der ESX/ESXi-Host stark ausgelastet ist.
- Verbesserte Leistung beim Hinzufügen oder Entfernen des ESX/ESXi-Hosts zu/von einer vDS-Instanz
Erhöhung des vCPU-Grenzwerts pro Core – Der Grenzwert für vCPUs pro Core wurde von 20 auf 25 erhöht. Diese Änderung sorgt nur für eine Erhöhung des unterstützten Grenzwerts. Sie schließt keine zusätzlichen Leistungsoptimierungen ein. Die Erhöhung des Grenzwerts bietet Benutzern mehr Flexibilität beim Konfigurieren von Systemen mit bestimmten Arbeitslasten und größtmöglichen Nutzen durch wesentlich schnellere Prozessoren. Die erreichbare Anzahl an VCPUs pro Core hängt von der Arbeitslast und den Spezifikationen der Hardware ab. Weitere Informationen finden Sie im Handbuch zu den Performance Best Practices für VMware vSphere 4.0 .
Aktivierung der Intel Xeon 3400-Prozessorserie – Die Xeon 3400-Prozessorserie wird jetzt unterstützt. Eine vollständige Liste der unterstützten Drittanbieter-Hardware und -Geräte finden Sie im VMware-Kompatibilitätshandbuch .
Behobene Probleme –Diese Version enthält darüber hinaus verschiedene Fehlerkorrekturen, die im Abschnitt "Behobene Probleme" dokumentiert sind.
Seitenanfang
Vorherige Versionen von VMware vSphere 4
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 früherer Versionen von ESXi 4.0 anzeigen möchten, klicken Sie auf einen der folgenden Links:
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 wahlweise anderer VMware-Produkte. Überprüfen Sie außerdem die "Kompatibilitätstabellen für vSphere 4.0" auf Informationen zu unterstützten Verwaltungs- und Sicherungsagenten, bevor Sie ESXi oder vCenter Server installieren.
Hardwarekompatibilität
Dokumentation
Die Dokumentation wurde für VMware vSphere 4.0 Update 1 aktualisiert.
Installation und Upgrade
Im Handbuch zur Einrichtung für ESXi Installable und vCenter Server Update 1 finden Sie Schritt-für-Schritt-Anleitungen zur Installation und Konfiguration von ESXi Installable und vCenter Server. Schritt-für-Schritt-Anleitungen zur Einrichtung von ESXi Embedded und vCenter Server finden Sie im Handbuch zur Einrichtung für ESXi Embedded und vCenter Server Update1 .
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. Es wird empfohlen, auf VMFS Version 3 oder höher zu Upgrade bzw. zu migrieren. Weitere Informationen finden Sie im vSphere-Upgrade-Handbuch Update 1 .
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 Update 1 weitere Informationen über das Installieren von vCenter Server auf einem 64-Bit-Betriebssystem unter Beibehaltung der VirtualCenter-Datenbank.
Das VMware Tools-RPM-Installationsprogramm, das zuvor auf dem VMware Tools-ISO-Image für Linux-Gastbetriebssysteme zur Verfügung stand, steht in ESXi nicht zur Verfügung. Es wird empfohlen, das tar.gz-Installationsprogramm zum Installieren der VMware Tools auf virtuellen Maschinen mit Linux-Gastbetriebssystemen zu verwenden.
MIB-Dateien (Management Information Base), die sich auf ESXi beziehen, werden nicht zusammen mit vCenter Server ausgeliefert. Nur MIB-Dateien, die sich auf vCenter Server beziehen, werden mit vCenter Server 4.0 mitgeliefert. Alle MIB-Dateien können von der VMware-Website unter www.vmware.com/de/download heruntergeladen werden.
Upgrade oder Migration auf ESXi 4.0 Update 1
vSphere 4.0 Update 1 stellt folgende Anwendungen bereit, die Sie zum Upgrade von ESXi 4.0 Update01 verwenden können:
- vSphere Host Update Utility– Für eigenständige Hosts. Ein eigenständiger Host ist ein ESX/ESXi-Host, der nicht von vCenter Server verwaltet wird. Weitere Informationen hierzu finden Sie im vSphere-Upgrade-Handbuch Update 1 .
- VMware vCenter Update Manager– Für von vCenter Server verwaltete ESX/ESXi-Hosts. Weitere Informationen finden Sie im Administratorhandbuch zu VMware vCenter Update Manager Update 1 .
- Befehlszeilendienstprogramm "vihostupdate"- Das Befehlszeilenprogramm "vihostupdate" wendet Software-Updates auf ESX/ESXi-Hosts an und installiert und aktualisiert ESX/ESXi-Erweiterungen wie VMkernel-Module, Treiber und CIM-Anbieter. Weitere Informationen hierzu finden Sie im vSphere-Upgrade-Handbuch Update 1 .
Unterstützte Upgrade-Pfade für das Host-Upgrade auf ESXi 4.0 Update 1
Upgrade-Typ |
ESXi Server 3.5 |
ESXi Server 3.5 Enthält: Update 1 Update 2 Update 3 Update 4 Update 5 |
ESXi 4.0 |
Upgrade mit Upgrade-ZIP für ESXi 4.0 Update 1 |
Ja |
Ja |
Nein |
Upgrade mit Offline-Paket für ESXi 4.0 Update 1 |
Nein |
Nein |
Ja |
Hinweise:
- Unterstützte Vorgehensweisen für das Upgrade unter Verwendung von Upgrade-ZIP sind vSphere Host Update Utility und vCenter Update Manager. Weitere Informationen hierzu finden Sie im vSphere-Upgrade-Handbuch Update 1 und im Administratorhandbuch zu VMware vCenter Update Manager Update 1 .
- Die unterstützte Vorgehensweise für die Verwendung des Offline-Pakets für ESXi 4.0 Update 1 ist das Befehlszeilendienstprogramm vihostupdate. Weitere Informationen hierzu finden Sie im vSphere-Upgrade-Handbuch Update 1 .
- Informationen zum Upgrade des ESXi 4.0-Hosts auf ESXi 4.0 Update 1 unter Verwendung der Online-Patches und vCenter Update Manager 4.0 Update 1 finden Sie im Patches-Abschnitt dieser Versionshinweise und im Administratorhandbuch zu vCenter Update Manager 4.0 U1 .
- Informationen zum Upgrade des ESXi 4.0-Hosts auf ESXi 4.0 Update 1 unter Verwendung der Online-Patches und vSphere Host Update Utility finden Sie im Patches-Abschnitt dieser Versionshinweise und im vSphere-Upgrade-Handbuch Update 1 .
Duchführen eines Upgrades der VMware Tools
Diese Version von VMware ESXi setzt ein Upgrade von VMware Tools voraus.
In dieser Version enthaltene Patches
Zusätzlich zu ISO-Images wird ESXi 4.0 Update 1(Embedded und Installable) als Patch verteilt, der auf vorhandene Installationen der ESXi 4.0-Software angewendet werden kann.
Das Patchpaket kann von der VMware-Webseite für Download-Patches heruntergeladen oder unter Verwendung von VMware Update Manager angewendet werden. Das Patchpaket enthält dieselben Bulletins wie die einzelnen Bulletins in VMware Update Manager. Dies ist das Patchpaket:
Patch-Version ESXi400-Update01 enthält die folgenden einzelnen Bulletins:
Diese Version enthält zudem alle Patches für die ESXi Server-Software, die vor dem Veröffentlichungsdatum dieses Produkts zur Verfügung standen. Weitere Informationen zu den einzelnen Patches finden Sie auf der VMware-Webseite für Download-Patches.
ESXi 4.0 Update 1 enthält zudem alle Fixes in den folgenden zuvor veröffentlichten Paketen:
Weitere Informationen zu den Inhalten der Patches finden Sie in der Dokumentation, die auf der Download-Seite aufgeführt wird.
Seitenanfang
Behobene Probleme
In dieser Version werden Probleme in den folgenden Themengebieten behoben:
† Behobene Probleme, die früher als bekannte Probleme dokumentiert wurden.
CIM und API
- Der ESXi-Sperrmodus funktioniert nicht korrekt
Der CIMOM auf einem ESXi-Host weist folgende Probleme auf, wenn sich der Host im Sperrmodus befindet:
- Die Methode PowerManagementService.Reboot()meldet fälschlicherweise einen erfolgreichen Abschluss, wenn sich der Host im Sperrmodus befindet.
- Die Methode RecordLog.ClearLog()verläuft erfolgreich, sollte aber zurückgewiesen werden.
- Im Sperrmodus führt CIMOM Systemaufrufe in einer Schleife aus. Damit kann die CPU-Nutzung auf 100 % steigen.
- Die wiederholten Systemaufrufe führen dazu, dass Authentifizierungsfehlermeldungen in die Systemprotokolle geschrieben werden.
Diese Probleme wurden behoben. Der CIMOM weist nun im Sperrmodus die folgenden extrinsischen Methodenaufrufe zurück:
- Anforderungen, die mit dem Benutzernamen 'root' authentifiziert werden, werden im Sperrmodus immer zurückgewiesen.
- Die Methode PowerManagementService.Reboot()schlägt im Sperrmodus immer fehl, weil der PowerManagementService-Provider bei Ausführung immer anhand des Hosts authentifiziert wird. Im Sperrmodus akzeptiert der Host keine Authentifizierungsanforderungen.
Der CIMOM akzeptiert im Sperrmodus die folgenden extrinsischen Methodenaufrufe:
- Andere extrinsische Methodenaufrufe als PowerManagementService.Reboot(), die mit einem anderen Benutzernamen als 'root' authentifiziert werden, wenn der Benutzername über vSphere-Administrationsrechte auf dem Host verfügt. Diese Methodenaufrufe werden weiterhin vom Authentifizierungscache authentifiziert.
- Extrinsische Methoden, die anhand eines Tickets, das über eine AcquireCIMServicesTicket()-Anforderung an die vSphere Web Services API erhalten wurde, authentifiziert werden. Das Ticket kann nur ausgestellt werden, wenn der Host von vCenter verwaltet und bevor der Host in den Sperrmodus versetzt wird. Die Ticketauthentifizierung gilt für die RecordLog.ClearLog()-Methode. Allerdings stellt die PowerManagementService.Reboot()-Methode eine Ausnahme dar.
Gastbetriebssystem
- Virtuelle Maschinen schlagen manchmal mit einem blauen Bildschirm fehl, wenn die Hardwarebeschleunigung vollaktiviert ist
Virtuelle Maschinen schlagen manchmal mit einem blauen Bildschirm fehl, wenn Sie bei vollaktivierter Hardwarebeschleunigung in Windows-Gastbetriebssystemen bestimmte Anwendungen ausführen.
Es handelt sich dabei um ein Problem mit dem SVGA-Treiber, das in dieser Version behoben wurde.
- Behebt ein Problem, wobei VMware Tools über "GuestInfo" falsche Festplatteninformationen für Linux-Gastbetriebssysteme, die LVM-Partitionen (Logical Volume Manager) (Logical Volume Manager) verwenden, meldet.
- Neu:Überschätzte Arbeitsspeicherauslastung von Gastbetriebssystemen verursacht fälschlich ausgelöste Alarme in vCenter Server
Die Arbeitsspeicherauslastung von Gastbetriebssystemen wird möglicherweise auf Intel-Systemen überschätzt, welche die EPT-Technologie unterstützen, oder auf AMD-Systemen, welche die RVI-Technologie unterstützen. Dies könnte dazu führen, dass die Arbeitsspeicheralarme des vCenter Servers auch dann ausgelöst werden, wenn das Gastbetriebssystem nicht aktiv auf große Speichermengen zugreift. Dieses Problem wurde in der vorliegenden Version behoben.
- Schriftartanzeigeproblem in virtuellen Maschinen bei der Anzeige auf Breitbildschirmen
Wenn eine virtuelle Maschine für Breitbildauflösung konfiguriert ist, erscheinen verzerrte Schriftarten in Microsoft Office-Anwendungen. Dieses Problem tritt auf, wenn die Auflösung auf 2560 x 1024 eingestellt ist.
Das Problem wurde in der vorliegenden Version behoben.
- Neu:Systembefehle schlagen fehl bei Verwendung der Gast-SDK-Bibliothek auf einem vMA 4.0-System
Wenn Sie versuchen, die Gast-SDK-Bibliothek auf einem vSphere Management Assistant (vMA) 4.0-System zu verwenden, schlagen die Systembefehle fehl und der folgende Fehler wird möglicherweise angezeigt: Lesen der Dateidaten nicht möglich: Fehler 21
Dieses Problem tritt auf, weil die Gast-SDK-Bibliotheken nicht auf Systemen gefunden werden, die Verzeichnisse enthalten, auf die der Befehl ldconfigzugreifen kann.
Dieses Problem wurde in der vorliegenden Version behoben.
- Wenn Sie VMware Tools oder die VSS-Komponenten in VMware Tools auf Version 4.0 Upgrade, werden Anwendungen, die die Datei "msvcp71.dll" benötigen, nicht gestartet, wenn eine virtuelle Maschine neu gestartet wird
Dieses Problem wurde in dieser Version behoben.
- Behebt ein Problem, wobei unter dem OS/2-Gastbetriebssystem eine e1000-vNIC-Emulation nicht ordnungsgemäß funktioniert
Dieser Fix enthält zur Behebung dieses Problems eine aktualisierte e1000-vNIC-Emulation.
Sonstige Probleme
- Neu:Nach dem Starten des ESX/ESXi-Hosts wird eine Warnmeldung in "/var/log" protokolliert
Nach dem Einschalten oder Neustart des ESX/ESXi-Hosts wird die folgende Warnmeldung in die Datei "/var/log/messages" eingetragen:
Peer table full for sfcbd.
Sie können diese Meldung ignorieren. Sie rührt nicht von Problemen mit ESX/ESXi her.
Dieses Problem wurde in der vorliegenden Version behoben.
- Einer Serie von vmklinux-Heapzuteilungswarnungen folgt ein ESX/ESXi-Systemausfall
Dieses Problem wird durch eine fehlerhalte Antwort auf eine legitime Mehrfachvergabe von Arbeitsspeicher verursacht. Nach häufiger Auslagerung oder Verwendung von VMotion tritt möglicherweise eine vmklinux-Beschränkung auf. Das Problem wird vor allem durch einen Mangel an Arbeitsspeicher unterhalb der Adresse 4 GB ausgelöst. In einer solchen Situation warnt eine Serie von Protokollmeldungen davor, dass die Zuteilung des Arbeitsspeichers für den vmklinux-Heap fehlgeschlagen ist. ESX/ESXi steht dann nicht mehr zur Verfügung; Ausnahme 14 wird in einer "Helper World" protokolliert. Nachfolgend ein Beispiel der protokollierten Meldungen:
[1:01:35:02.450 cpu7:4480)WARNING: Heap: 1471: Could not allocate 2093688 bytes for dynamic heap vmklinux. Request returned Out of memory
[1:01:35:02.450 cpu7:4480)WARNING: Heap: 1645: Heap_Align(vmklinux, 1024/1024 bytes, 8 align) failed. caller: 0x4180303746b7
[1:01:35:02.450 cpu7:4480)WARNING: Heap: 1471: Could not allocate 2093688 bytes for dynamic heap vmklinux. Request returned Out of memory
[1:01:35:02.450 cpu7:4480)WARNING: Heap: 1645: Heap_Align(vmklinux, 1024/1024 bytes, 8 align) failed. caller: 0x4180303746b7
[VMware ESX [Releasebuild-164009 X86_64]
#PF Exception(14) in world 4480:helper18-7 ip 0x41803037480c addr 0x0
Obwohl dieses Problem theoretisch auch bei ESXi auftreten kann, wurde es bisher nur bei ESX-Installationen beobachtet. Aufgrund der Verwendung von niedrigem Arbeitsspeicher durch die Servicekonsole ist ESX anfälliger.
Dieses Problem wurde in der vorliegenden Version behoben.
Netzwerk
- Wenn sich Intel MT- und PT-Dualport-Netzwerkkarten im Promiscuous-Modus befinden, ist der VLAN-Filter eingeschaltet
Dies führt dazu, dass CDP-Pakete (Cisco Discovery Protocol) verloren gehen. Dieser Fix bietet Prüfungen für CDP-Pakete mit VLAN-Tags, Plausibilitätskontrollen für eingehende Pakete und Protokollierungsausgabe für Analysefehler.
- Behebt ein Problem mit dem NetXen nx_nic-Netzwerktreiber auf NX2031-Karten, wobei ESX möglicherweise nicht mehr reagiert, nachdem auf Systemen mit mehr als 32 GB Arbeitsspeicher die Warteschlange angehalten wurde
- Behebt ein Problem, wobei ESX möglicherweise den CDP-Daemon im Betriebssystem der Konsole deaktiviert
- Aktualisiert die Beschreibung des Broadcom NetXtreme BCM5722-Netzwerkadapters in vCenter für manche Dell-Server
Die Beschreibung in vCenter für Broadcom NetXtreme BCM5722-Netzwerkadapter auf manchen Dell-Servern, die einige unnötige Wörter enthalten hat, wurde entfernt und auf NetXtreme BCM5722 Gigabit Ethernet aktualisiert. Die Beschreibung für Dell PowerEdge T105-, R300- und T300-Server wurde aktualisiert.
- Behebt ein Problem, wobei ESX mit dem nx_nic-Treiber möglicherweise fehlschlägt, nachdem ein Ethernet-Header als IP-Header entschlüsselt wurde
Dieser Fix legt die Variable LRO enabledauf 0 fest, da in ESX 4.0 Update 1 LRO (Large Receive Offload) nicht unterstützt wird.
Sicherheit
- Behebt ein Problem, wobei der NTPD-Daemon möglicherweise einen stapelbasierenden Pufferüberlauf aufweist, wenn er für die Verwendung des autokey-Sicherheitsmodells konfiguriert ist
Das Projekt "Common Vulnerabilities and Exposures" (cve.mitre.org) hat diesem Problem die Bezeichnung CVE-2009-1252 zugewiesen.
- Ein stackbasierter Pufferüberlauf in "ISC dhclient" ermöglicht Remote-DHCP-Servern möglicherweise das Ausführen von beliebigem Code unter Verwendung einer manuell gefertigten Subnetzmaskenoption
Das Projekt "Common Vulnerabilities and Exposures" (cve.mitre.org) hat diesem Problem die Bezeichnung CVE-2009-0692 zugewiesen.
Serverkonfiguration
- Eine TPM-verwandte Warnmeldung wird auf ESX/ESXi 4.0 ausgegeben, obwohl TPM auf dem System nicht zur Verfügung steht (KB 1011452)
- Der ESXi 4.0-Server antwortet manchmal nicht mehr, wenn der Hostarbeitsspeicher mehrfach zugeteilt ist
Der ESXi 4.0-Server antwortet manchmal nicht mehr, wenn der Hostarbeitsspeicher bei einer Nutzung von mehr als 200% überlastet und der Server als "Long Uptime Server" konfiguriert ist. Alle virtuellen Maschinen schlagen fehl, wenn der Server auf keine Aktionen mehr reagiert. Dieses Problem wurde in der vorliegenden Version behoben.
- Behebt ein Problem, wobei sich an manchen Maschinen die von CIM OMC_SMASHFirmwareIdentity gemeldete BIOS-Version von dmidecode unterscheidet
- Behebt ein Problem, wobei die DRAC den Namen des Betriebssystems über IPMI ermittelt und sowohl für ESX als auch für ESXi "VMware ESX Server" anzeigt
Dieser Fix ersetzt den fest einprogrammierten Namen durch VMware_HypervisorSoftwareIdentity.ElementName.
- Behebt ein Problem, wobei die für VMware_HypervisorSoftwareIdentity abgerufene Versionsinformation zur Erstellungszeit fest einprogrammiert ist
Falls CIM-Komponenten individuell gepatcht sind, stimmen die Build-Werte für diesen Anbieter möglicherweise mit der Build-Nummer oder Versionsinformation in anderen Komponenten oder Anwendungen nicht überein. Nach Anwendung dieses Fixes wird die Versionsinformation mithilfe eines gemeinsam genutzten Mechanismus abgerufen, der auch von anderen Komponenten im System verwendet wird.
- Neu:ESXi DCUI schlägt fehl, wenn der Test des Verwaltungsnetzwerks unterbrochen und dann neu gestartet wird
ESXi Direct Console User Interface (DCUI) schlägt fehl, wenn Sie den Test des Verwaltungsnetzwerks mit der ESC-Taste unterbrechen und dann den Test erneut starten. Dieses Problem wurde in der vorliegenden Version behoben.
Speicher
- Behebt ein Problem, wobei der Dell MegaRAID SAS1078R-Controller nicht als "PERC 6" identifiziert wird, weil die PCI-ID-Subsysteminformationen nicht ordnungsgemäß behandelt werden
- ESX Server antwortet möglicherweise nicht, wenn ein NFS-Volume offline genommen wird
Wenn ein gemountetes NFS-Volume in einem ESX Server-Cluster offline genommen wird, könnte dies dazu führen, dass der Heap vergrößert wird und der ESX Server nicht mehr antwortet.
- Neu:Anwendungen schlagen möglicherweise fehl und zeigen bei einem LUN-Reset einen E/A-Fehler an
Bei einem LUN- oder SCSI-Bus-Reset auf einem RHEL 5-Gastbetriebssystem schlagen möglicherweise die Anwendungen in der virtuellen Maschine aufgrund eines E/A-Fehlers fehl. Dieses Problem tritt nur dann auf, wenn Sie den PVSCSI-Adapter und den ESX iSCSI-Initiator verwenden. Dieses Problem wurde in der vorliegenden Version behoben.
- Der Proxydateipfadzugriff auf einem gemeinsam genutzten SMB/CIFS-Speicher schlägt fehl
Das Starten einer virtuellen Maschine von einem CD-ROM aus schlägt fehl, wenn sich die ISO-Datei auf einer mithilfe des SMB/CIFS-Protokolls gemounteten Freigabe befindet. Dieses Problem tritt auf, weil der Proxydateipfadzugriff verweigert wird, wenn das SMB/CIFS-Protokoll verwendet wird. Dieses Problem wurde in der vorliegenden Version behoben.
- Dieser Fix erhöht den Arbeitsspeicherheap für den HPSA-Treiber, damit er mehr als zwei Controller bedienen kann
- Neu:SCSI-Abbruchfehler beim Testen mehrerer virtueller Maschinen
Da der HP Smart Array-Treiber den SCSI-Abbruch nicht unterstützt, wird stattdessen ein Geräte-Reset ausgegeben. Die unmittelbare Ausführung des Resets kann die gleichzeitige E/A unterbrechen sowie zu mehr E/A-Ausfällen und SCSI-Abbruchfehlern führen.
Dieses Problem wurde in der vorliegenden Version dahin gehend behoben, dass das Zurücksetzen nach einer kurzen Verzögerung ausgeführt wird.
Unterstützte Hardware
- vCenter gibt einen Fehler aus, wenn die Konfigurationsoption "Power.CpuPolicy" in "Dynamisch" geändert wird
Wenn die Option Power.CpuPolicyvon "Statisch" in "Dynamisch" geändert wird, gibt vCenter die folgende Fehlermeldung aus:
Der eingegebene Wert ist ungültig. Geben Sie einen anderen Wert ein.
Dieser Fehler tritt auf, weil ESX/ESXi 4.0 auch dann versucht, die CPU-Energieverwaltungsrichtlinie des Systems in "Dynamisch" zu ändern, wenn das BIOS Prozessorleistungszustände (P-Zustände) nicht ordnungsgemäß unterstützt.
Dieses Problem wurde in der vorliegenden Version behoben.
Upgrade und Installation
- Das Upgrade von ESX Server 3i 3.5 auf ESXi 4.0 schlägt in bestimmten Fällen fehlDieses Problem tritt nur bei Installationen auf Serial Attached SCSI-Festplatten (SAS-Festplatten) oder Fibre-Channel-Festplatten (FC-Festplatten) auf. Wenn Sie in solchen Fällen versuchen, einen auf einer SAS- oder FC-Festplatte installierten ESX Server 3i 3.5 zu Upgrade, tritt während des Upgrades folgender Fehler auf:
Nicht unterstütztes Startlaufwerk. Das Layout des Startgeräts auf dem Host unterstützt keine Aktualisierung
Beachten Sie, dass dieses nur eines von mehreren Problemen ist, die den oben genannten Fehler verursachen können.
Dieses Problem wurde in der vorliegenden Version behoben. Beachten Sie allerdings, dass ein In-Place-Upgrade von ESXi Installable auf einer Boot-LUN, die ebenfalls eine VMFS-Partition enthält, nicht möglich ist.
- Neu:Das Verwenden des Host Update Utility auf ESXi Installable schlägt mit folgendem Fehler fehl: Fehler: Nicht unterstützte Boot-Festplatte
Dieser Fehler kann auftretren, wenn für den Host eine große Menge an lokalem Speicher vorhanden ist. In solch einem Szenario schlägt ein Skript zur Vorabprüfung fehl, weil das Skript keine großen Ganzzahlen unterstützt. Allerdings ist eine solche Unterstützung erforderlich, wenn die Speichergröße einen bestimmten Punkt erreicht. Deshalb schlägt das Skript zur Vorabprüfung aufgrund einer Einschränkung des Skripts fehl und nicht aufgrund eines Fehlers bei der Upgrade-Unterstützung.
Der vollständige Fehler für dieses Problem lautet wie folgt:
FEHLER: Nicht unterstützte Boot-Festplatte
Das Layout des Startgeräts auf dem Host unterstützt keine Upgrades
Dieses Problem wurde in der vorliegenden Version behoben.
- Behebt ein Problem, wobei beim Installieren von VMware Tools die vorhandenen virtuellen Druckertreiber "TPOG" und "TPOGPS" überschrieben werden, wenn der .print-Server von ThinPrint installiert wird
Mit diesem Fix wird nach einem von .printerstellten Registrierungseintrag gesucht. Sofern dieser Registrierungseintrag erkannt wird, werden die mit VMware Tools mitgelieferten virtuellen Druckertreiber nicht installiert.
vCenter Server und vSphere-Client
- vSphere Client zeigt den richtigen Bezeichner für das FreeBSD-Betriebssystem nicht an
Der richtige Bezeichner für das FreeBSD-Betriebssystem wird auf der Registerkarte "Übersicht" im vSphere-Client nicht angezeigt. Dieses Problem wurde in der vorliegenden Version behoben.
Verwaltung von virtuellen Maschinen
- Neu:Das SLES 10-Gastbetriebssystem wird in vCenter fälschlicherweise als SLES 8/9 angegeben, wenn VMware Tools ausgeführt wird
Wenn ESX 4.0 von vCenter 4.0 verwaltet wird und VMware Tools ausgeführt wird, zeigt die Registerkarte "Übersicht" des vSphere-Clients das Suse Linux Enterprise 10-Gastbetriebssystem (32-Bit) als Suse Linux Enterprise 8/9 (32-Bit) und Suse Linux Enterprise 10 (64-Bit) als Suse Linux Enterprise 8/9 (64-Bit) an.
- Behebt ein Problem, wobei ESX möglicherweise fehlschlägt, wenn während einer Synchronisierung die Warteschlange mit einer übermäßig großen Anzahl von RPC-Meldungen gefüllt wird und somit für VMX kein Arbeitsspeicher mehr zur Verfügung steht
Mit diesem Fix wird die Anzahl der RPC-Meldungen, die sich während einer Synchronisierung in der Warteschlange befinden dürfen, auf 1 beschränkt.
- Neu:Die Daten der Netzwerkleistung werden nicht angezeigt, wenn der VMXNET3-Adapter verwendet wird
Das Fenster Netzwerk auf der Registerkarte Leistung einer virtuellen Maschine wird nicht angezeigt, wenn ein Gast einen Adapter der VMXNET Generation 3 verwendet. Wenn eine virtuelle Maschine über einen Mix aus virtuellen Adaptern verfügt, wird das Fenster Netzwerk für Adapter eines anderen Typs als VMXNET3 weiterhin angezeigt.
Dieses Problem wurde in der vorliegenden Version behoben.
- Behebt ein Problem, wobei der Status eines Taktsignals einer virtuellen Maschine nicht korrekt angezeigt wird
VMotion und Storage VMotion
- Der Fix für einen bereits erkannten VMotion-Fehler kann die Migration von virtuellen Maschinen, deren Video-RAM mehr als 30 MB beträgt, auf einen Host ohne den Fix verhindern
ESX/ESXi 4.0 Update 1 behebt den VMotion-Fehler, wie in KB 1011971 beschrieben. Wenn VMotion für die Migration einer virtuellen Maschine, deren Video-RAM mehr als 30 MB beträgt, auf einen ESX/ESXi 4.0 Update 1-Host verwendet wird, ist es jedoch möglich, dass Sie keine Migration zurück auf einen Host durchführen können, auf dem dieser Fix nicht implementiert wurde.
- Neu:Anwendungen wie z. B. MPlayer und MEncoder, die in einer virtuellen Maschine ausgeführt werden, schlagen mit einem Fehler des Typs "Unzulässige Instruktion" fehl
Eine Vielzahl von Anwendungen führen Supplemental Streaming SIMD Extension 3-Instruktionen (SSSE3-Instruktionen) aus, wie z. B. MPlayer und MEncoder.
Diese Anwendungen schlagen bei Ausführung in einer virtuellen Maschine nach einer VMotion-Migration oder dem Anhalten und Fortsetzen der virtuellen Maschine mit einem Fehler des Typs "Unzulässige Instruktion" fehl. In seltenen Fällen tritt dieser Fehler bei einer normalen Ausführung auf.
Dieses Problem wurde in der vorliegenden Version behoben.
- Neu:Bei Verwendung der VMotion-Funktion kommt es zu einem Fehlschlagen der Migration gefolgt von einem Systemausfall des Zielhosts
Wenn die Migration einer virtuellen Maschine mit VMotion aufgrund eines seltenen Fehlers bei der Fortsetzung fehlschlägt, behält die virtuelle Quellmaschine möglicherweise einen veralteten Auslagerungsstatus bei. Nachfolgende Migrationsversuche der virtuellen Quellmaschine können zu einem Systemausfall des Zielhosts führen.
Dieses Problem wurde in der vorliegenden Version behoben.
VMware High Availability und Fehlertoleranz
- Das Aktivieren von HA schlägt fehl, wenn der ESX/ESXi-Host keine DNS-Konnektivität hat
Wenn beim Aktivieren oder Konfigurieren von VMware HA der ESX/ESXi-Host keine DNS-Konnektivität hat und sich in der Datei /etc/hostskein Eintrag für den Kurznamen des Hosts befindet, kann das Aktivieren oder Konfigurieren von HA fehlschlagen. Dieses Problem wurde in der vorliegenden Version behoben.
- Beim Aktivieren der Fehlertoleranz wird die sekundäre virtuelle Maschine für ein paar Sekunden gestartet, bevor sie dann ausfällt, was dazu führt, dass die primäre virtuelle Maschine in den Status "Sekundäre VM erforderlich" versetzt wird
Wenn primäre und sekundäre virtuelle Maschinen für Fehlertoleranz auf Hosts mit gemischten Steppings von Intel Xeon 5400- oder 5200 Series-Prozessoren (CPUID Family 6, Model 23, Steppings 6 und 10) ausgeführt werden, wird die sekundäre virtuelle Maschine für ein paar Sekunden gestartet, bevor sie dann ausfällt. Dies führt dazu, dass die primäre virtuelle Maschine in den Status "Sekundäre VM erforderlich" versetzt 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:
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
Gastbetriebssystem
- Virtuelle Maschine unter Solaris 10 U4 reagiert nicht mehr während eines Upgrades der VMware Tools
Das Upgrade oder der Neustart der VMware Tools in einer virtuellen Maschine unter Solaris 10 U4 mit einem erweiterten vmxnet-Adapter kann möglicherweise dazu führen, dass das Gastbetriebssystem nicht mehr reagiert und die Installation nicht mehr fortgesetzt werden kann. Solaris 10 U5 und spätere Versionen sind von diesem Problem nicht betroffen.
Umgehung: Bevor Sie VMware Tools installieren oder Upgrade, sollten Sie vorübergehend die Konfiguration des erweiterten vmxnet-Adapters entfernen, indem Sie entweder dessen Autokonfigurationsdateien in /etc/
entfernen oder die virtuelle Hardware entfernen.
- Auf ESXi findet die Installation der VMware Tools keine PBMs für bestimmte Linux-Gastbetriebssysteme
Das Standard-Installationsprogramm für VMware Tools enthält "Prebuilt Modules" (PBMs) nur für bestimmte, unterstützte Linux-Gastbetriebssysteme.
Umgehung: Auf der VMware-Website können Sie ein alternatives ISO-Image mit Linux-Tools herunterladen. Es enthält VMware Tools sowohl für unterstützte als auch für verschiedene ältere und nicht unterstützte Linux-Gastbetriebssysteme. Alternativ können Sie mithilfe des Skripts install-vmware.pl
, das zusammen mit VMware Tools ausgeliefert wird, Kernel-Module für die nicht unterstützten Linux-Versionen kompilieren.
- 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.
- Mehrere DNS-Suffixe werden nach der Image-Anpassung der Linux-Distribution nicht ordnungsgemäß angewendet
DNS-Suffixe werden automatisch angehängt, wenn eine Linux-Distribution versucht, einen DNS-Domänennamen aufzulösen. Wenn mehr als ein DNS-Suffix angepasst wird, wird nur das letzte DNS-Suffix angewendet. Je nach Linux-Distribution werden nicht alle angepassten DNS-Suffixe auf der Benutzeroberfläche der Linux-Distribution angezeigt. Umgehung: Keine
- 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.
- Neu:Ein automatisches Upgrade der VMware Tools schlägt möglicherweise für eine virtuelle Maschine unter Red Hat Enterprise Linux 5.x fehl, die mittels Cold-Migration von ESX 3.0.3 nach ESX/ESXi 4.0 Update 1 migriert wurde
Ein automatisches Upgrade der VMware Tools schlägt möglicherweise fehl mit der Meldung Fehler beim Upgrade der VMware Tools, wenn die virtuelle Maschine unter Red Hat Enterprise Linux 5.x läuft und mittels Cold-Migration von einem ESX 3.0.3-Host nach einem ESX/ESXi 4.0 Update 1-Host migriert wurde.
Umgehung: Upgrade Sie VMware Tools auf dem ESX 4.0 Update 1-Host manuell.
- Neu:Wake-On-LAN funktioniert nicht mit der e1000 vNIC auf neueren Windows-Gastbetriebssystemen
Für ESX/ESXi-Hosts steht die Wake-On-LAN-Funktion (zum Einschalten eines Hosts über das Netzwerk) auf bestimmten Windows-Gastbetriebssystemen für die e1000 vNIC nicht zur Verfügung. Insbesondere gilt dies für Windows-Versionen von Vista aufwärts und für 64-Bit-Version.
Umgehung: Verwenden Sie einen vNIC-Typ, der Wake-On-LAN unterstützt, wie z. B. VMXNET3
- Bei Windows Vista- und Windows 7-Gastbetriebssystemen wird die Videoausgabe möglicherweise nicht korrekt angezeigt
Windows Media Player kann in einem Windows Vista- oder Windows 7-Gastbetriebssystem fälschlicherweise Video-Dateien anzeigen, wenn das Video skaliert wird.
Umgehung: Als Umgehung für dieses Problem können Sie eine der folgenden Aktionen ausführen:
- Spielen Sie das Video im Vollbildmodus ab (ALT + EINGABETASTE).
- Deaktivieren Sie Bei Größenänderung Video an Player anpassen.
- Das Windows 7-Betriebssystem mit Media Player 11 wird nicht unterstützt
Das Microsoft Windows 7-Gastbetriebssystem, das Windows Media Player 11 enthält, wird auf einer virtuellen Maschine nicht unterstützt. Wenn Sie versuchen, auf einer virtuellen Maschine, auf der das Microsoft Windows 7 Betriebssystem ausgeführt wird, den Media Player auszuführen und das entsprechende Fenster zu maximieren, schlägt die virtuelle Maschine möglicherweise fehl.
Internationalisierung
Lizenzierung
- Virtuelle Maschine mit Mehrweg-Unterstützung für Virtual SMP startet möglicherweise nicht und meldet sofort nach einem Lizenz-Upgrade des Hosts einen Lizenzfehler
Unmittelbar nach dem Upgrade der Lizenz für einen Host schaltet vCenter Server die virtuelle Maschine nicht ein. Wenn Sie beispielsweise von einer Edition, die 4 vCPU unterstützt, auf eine Edition Upgrade, die 8vCPU unterstützt, meldet vCenter Server einen Lizenzfehler, z. B.: Maschine hat 8 virtuelle CPUs, aber der Host unterstützt nur 4....
Umgehung: Warten Sie mindestens eine Minute, bevor Sie virtuelle Maschinen einschalten, damit das Lizenz-Upgrade wirksam wird. Wechseln Sie zum manuellen Initiieren der Lizenzänderung nach Home > Lizenzierung und klicken Sie auf Upgrade.
Sonstige Probleme
- Neu:Die Diagnosepartition wird erst bei einem Systemausfall initialisiert
Standardmäßig ist die Diagnosepartition (oder Dump-Partition) nicht initialisiert. Wenn Sie versuchen, die Informationen in der Diagnosepartition zu erfassen, beispielsweise durch Ausführung des Befehls vm-support, wird eine harmlose Fehlermeldung ausgegeben, die angibt, dass die Diagnosepartition nicht initialisiert wurde.
Umgehung: Keine. Dieses Problem hat keine Auswirkung auf die Verarbeitung des Befehls vm-support. Sie können diese Fehlermeldung bedenkenlos ignorieren.
- Das Beenden oder der Neustart des vCenter Server-Dienstes über das Windows Services Control MMC-Plug-In kann zu einer Fehlermeldung führen
Unter bestimmten Bedingungen dauert das Starten des vCenter Server-Dienstes möglicherweise länger als gewöhnlich. Das Beenden und der Neustart des vCenter Server-Dienstes über das Windows Services Control MMC-Plug-In kann zur folgenden Fehlermeldung führen: Dienst konnte nicht in angemessener Zeit reagieren
.
Diese Meldung bedeutet, dass die für das Herunterfahren oder Starten von vCenter Server erforderliche Zeit den standardmäßig konfigurierten, systemweiten Zeitüberschreitungswert zum Beenden und Starten von Diensten überschritten hat.
Umgehung: Upgrade Sie nach ein paar Minuten den Bildschirm für die Dienstesteuerung. Es sollte nun angezeigt werden, dass der Dienst ordnungsgemäß gestoppt und neu gestartet wurde.
- Hilfemenüelemente erscheinen inaktiv oder das Klicken auf andere Hilfe-Links führt zu einem Fehler
Hilfemenüelemente erscheinen inaktiv bei vSphere-Client-Installationen auf Maschinen mit Windows-Betriebssystemen, die nicht englisch, japanisch, deutsch oder chinesisch (vereinfacht) sind. Außerdem besteht das Problem, dass wenn Sie, um Hilfe zu erhalten, im vSphere-Client auf andere Links oder Schaltflächen klicken, folgende Fehlermeldung angezeigt wird: Fehlende Hilfedatei
Umgehung: Kopieren Sie den Inhalt des Online-Hilfe-Ordners des vSphere-Clients von
C:\Programme\VMware\Infrastructure\Virtual Infrastructure Client\Help\de\VIC40
nach
C:\Programme\VMware\Infrastructure\Virtual Infrastructure Client\Help\de
.
Stellen Sie sicher, dass nur der Inhalt des Online-Hilfe-Unterverzeichnisses des vSphere-Clients ( VIC40
) auf diese Ebene kopiert wird.
Sie können die Online-Hilfe für andere Produktkomponenten unter C:\Programme\VMware\Infrastructure\Virtual Infrastructure Client\Help\de
anzeigen, indem Sie auf die Datei index.html
im Unterverzeichnis für das jeweilige Hilfesystem doppelklicken. Wenn Sie beispielsweise das Hilfesystem für die DRS-Fehlerbehebung anzeigen möchten, doppelklicken Sie auf die Datei index.html
im Unterverzeichnis DSR40
. Welche Unterverzeichnisse für Online-Hilfe-Systeme anderer vSphere-Module an diesem Speicherort vorhanden sind, hängt davon ab, welche vSphere-Produkte Sie installiert haben.
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.
- Das Ändern einer VMkernel-Netzwerkkarte mithilfe von DHCPv6 von einer statischen DNS-Attribution in DHCP DNS aktualisiert die DNS-Namenserver nicht
Wenn Sie die Servicekonsole, die vSphere-CLI oder den vSphere-Client zum Ändern einer IPv6-VMkernel-Netzwerkkarte, die DHCPv6 verwendet, von einer statischen DNS-Attribution in DHCP DNS ändern, werden die DNS-Namenserver bis zur nächsten Verlängerung der DHCPv6-Lease nicht aktualisiert.
Umgehung: Deaktivieren und aktivieren Sie anschließend die VMkernel-Netzwerkkarte wieder manuell, um die neuen DNS-Namenserver abzurufen. Sie können dies bewerkstelligen, indem Sie die Option Restart Management Network in der Benutzerschnittstelle der direkten Konsole, der auf Tastatureingabe beschränkten Benutzerschnittstelle für ESXi, wählen. Wenn Sie nichts unternehmen, wird der DNS-Nameserver abgerufen, wenn die DHCPv6-Lease verlängert wird.
- 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.
- DPM kann keinen Host in den Standby-Modus versetzen, wenn die VMkernel VMotion-Netzwerkkarte Teil eines vDS und der Host für die Verwendung von Wake-On-LAN für das Remoteeinschalten konfiguriert ist
Wenn die VMkernel VMotion-Netzwerkkarte eines Hosts Teil eines vDS ist, ist die Netzwerkkarte nicht für die Unterstützung von Wake-On-LAN konfiguriert. Der Host wird demnach als nicht fähig betrachtet, einen Remoteeinschaltvorgang durchzuführen und DPM kann ihn nicht automatisch in den Standby-Modus versetzen, es sei denn, er ist für die Verwendung von IPMI oder iLO für den Remote-Einschaltvorgang konfiguriert. DPM wählt andere Hosts aus, die nach Möglichkeit in den Standby-Modus versetzt werden. Falls Sie versuchen, den Host manuell in den Standby-Modus zu versetzen, wird der Versuch fehlschlagen und das Dialogfeld Wechsel in den Standby-Modus gestoppt erscheint. Umgehung: Verwenden Sie statt Wake-On-LAN IPMI oder iLO, um Hosts einzuschalten, die eines dieser Protokolle unterstützen, indem Sie auf jedem Host die IPMI- oder iLO-Anmeldedaten konfigurieren. Wenn Sie Wake-On-LAN zum Einschalten von Hosts verwenden müssen, konfigurieren Sie die VMkernel VMotion-Schnittstelle auf einem vNetwork-Standard-Switch (vSwitch) anstatt auf einem vDS.
- 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
- Neu: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 nicht 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/<Gerätename>
- NAS-Datenspeicher geben den verfügbaren Speicherplatz falsch wieder
Wenn Sie den verfügbaren Speicherplatz für einen ESX/ESXi-Host mithilfe des Befehls df
(ESXi) oder vdf
(ESX) in der Host-Servicekonsole anzeigen lassen, handelt es sich bei dem gemeldeten Speicherplatz für ESX/ESXi-NAS-Datenspeicher um freien Speicherplatz und nicht um verfügbaren Speicherplatz. Der Speicherplatz von NFS-Volumes, der in der Spalte "Frei" angegeben wird, wenn Sie Speicher > Datenspeicher auf der Registerkarte Konfiguration des vSphere-Clients wählen, zeigt auch den freien Speicherplatz an, nicht den verfügbaren Speicherplatz. In beiden Fällen kann sich der freie von dem verfügbaren Speicherplatz unterscheiden. ESX-Dateisysteme unterscheiden nicht zwischen freien und verfügbaren Blöcken, sondern melden immer freie Blöcke für beide Blocktypen (genau genommen die Felder "f_bfree" und "f_bavail" der struct "statfs"). Freie und verfügbare Blöcke können sich bei NFS-Volumen unterscheiden.
Umgehung: Sie können korrekte Informationen hinsichtlich des verfügbaren Speicherplatzes von NFS-Servern abrufen. Für ESX/ESXi gibt es keine Umgehung.
- Harmlose Warnmeldungen zu Bereichskonflikten werden in den VMkernel-Protokollen für manche IBM-Server protokolliert
Wenn der SATA/IDE-Controller im PCI-Konfigurationsbereich im Legacy-PCI-Modus arbeitet, wird möglicherweise eine Fehlermeldung ähnlich der Folgenden zu den VMkernel-Protokollen hinzugefügt:
WARNUNG: vmklinux26: __request_region: Diese Meldung wurde einmal wiederholt: Region conflict @ 0x0 => 0x3
Umgehung: Solche Fehlermeldungen sind harmlos und können bedenkenlos ignoriert werden.
Unterstützte Hardware
- Es werden keine CIM-Alarme empfangen, wenn das Stromkabel und das Netzteil neu an HP-Server angeschlossen werden
Es werden keine neuen SEL(IML)-Einträge für das erneute Anschließen des Stromkabels und des Netzteils auf HP-Servern erstellt, wenn eine unterbrochene Stromversorgung wiederhergestellt wird. Dies führt dazu, dass keine CIM-Alarme für diese Ereignisse generiert werden. Umgehung: Keine
- ESX/ESXi auf der HP G6-Plattform mit P410i oder P410 Smart Array-Controller läuft während des Einschaltens der virtuellen Maschinen oder bei Festplatten-E/A-Vorgängen langsam
Einige dieser Hosts laufen möglicherweise beim Einschalten von virtuellen Maschinen oder bei Festplatten-E/A-Vorgängen langsam. Die Hauptsymptom ist eine herabgestufte E/A-Leistung, wodurch viele Fehlermeldungen ähnlich der Folgenden in /var/log/messages
protokolliert werden. Mar 25 17:39:25 vmkernel: 0:00:08:47.438 cpu1:4097)scsi_cmd_alloc returned NULL!
Mar 25 17:39:25 vmkernel: 0:00:08:47.438 cpu1:4097)scsi_cmd_alloc returned NULL!
Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)NMP: nmp_CompleteCommandForPath: Command 0x28 (0x410005060600) to NMP device
"naa.600508b1001030304643453441300100" failed on physical path "vmhba0:C0:T0:L1" H:0x1 D:0x0 P:0x0 Possible sense data: 0x
Mar 25 17:39:26 0 0x0 0x0.
Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)WARNUNG: 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.
- Einige Dell-BIOS-Systeme weisen möglicherweise doppelte Interrupt-Routing-Einträge in der ACPI-Tabelle auf (KB 1013804)
- Auf bestimmten Versionen des vSphere-Clients wird der Status des Akkus möglicherweise falsch als alarmierend angezeigt
Wenn sich der Akku im Lernmodus befindet, wird im vSphere-Client auf der Registerkarte "Hardwarestatus" eine Alarmmeldung angezeigt, die angibt, dass der Status des Akkus nicht in Ordnung ist. Allerdings ist der Ladezustand des Akkus in Ordnung.
Umgehung: Keine.
- Die Meldung "Detected Tx Hang" wird in der VMkernel-Protokolldatei angezeigt
Einige Varianten der e1000-Netzwerkkarten blockieren aufgrund von Hardwarefehlern unter Volllast. ESX/ESXi erkennt das Problem und setzt die Karte automatisch zurück. Dieses Problem steht im Zusammenhang mit Tx-Paketen, TCP-Arbeitslasten und TCP Segmentation Offloading (TSO).
Umgehung: Sie können TSO deaktivieren, indem Sie in der Datei esx.confdie Option /adv/Net/UseHwTSOauf 0 setzen.
- Ereignismeldungen von StoreLib von IR-Karten haben einen fehlerhaften Zeitstempel
"IndicationTime" in den Ereignismeldungen von StoreLib zeigt einen fehlerhaften Zeitstempel für LSI 1078 und 1068E Integrated RAID (IR)-Controller an.
Upgrade und Installation
- Die Installation des vSphere-Clients schlägt möglicherweise mit dem Fehler 1603fehl, wenn Sie nicht über eine aktive Internetverbindung verfügen
Sie können den vSphere-Client auf zwei Arten installieren: Vom vCenter Server-Medium aus oder indem Sie auf einen Link im ESX-, ESXi- oder vCenter Server-Begrüßungsbildschirm klicken. Das Installationsprogramm auf dem vCenter Server-Medium (.iso-Datei oder .zip-Datei) enthält zusätzlich zum vSphere-Client-Installationsprogramm ein vollständiges .NET-Installationsprogramm. Das Installationsprogramm, das über den Begrüßungsbildschirm aufgerufen wird, enthält ein vSphere-Client-Installationsprogramm, das die .NET-Installationsprogrammkomponenten aus dem Internet abruft. Wenn Sie über keine Internetverbindung verfügen, schlägt die zweite vSphere-Client-Installationsmethode mit dem Fehler 1603fehl, es sei denn, .NET 3.0 SP1 ist bereits auf Ihrem System installiert.
Umgehung: Richten Sie eine Internetverbindung ein, bevor Sie den Download versuchen, installieren Sie den vSphere-Client vom vCenter Server-Medium aus oder installieren Sie .NET 3.0 SP1, bevor Sie auf den Link auf dem Begrüßungsbildschirm klicken.
- 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
- 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: Setup konnte das vCenter-Repository nicht erstellen
Umgehung: Schalten Sie auf dem System, auf dem vCenter Server installiert wird, unter Systemsteuerung > Benutzerkonten die Option "Benutzerkontensteuerung" aus, bevor Sie vCenter Server installieren. Geben Sie während der vCenter Server-Installation den Nicht-Systembenutzer an.
- Keine Anmeldung bei VirtualCenter Server 2.5 möglich, nachdem der VI Client 2.0.x, 2.5 und vSphere Client 4.0 auf einem Windows Vista-System installiert wurden und der VI Client 2.0.x deinstalliert wurde
Nach dem Deinstallieren des VI Client 2.0.x auf einer Windows Vista-Maschine, auf der VI Client 2.0.x und 2.5 sowie vSphere Client 4.0 gleichzeitig vorhanden sind, ist keine Anmeldung bei vCenter Server 2.5 möglich. Die Anmeldung schlägt mit folgender Meldung fehl: Klasse nicht registriert (Ausnahme von HRESULT:0x80040154(REGDB_E_CLASSNOTREG))
Umgehung: Deaktivieren Sie die Benutzerkontensteuerung auf dem System, auf dem VI Client 2.0.x, 2.5 und vSphere Client 4.0 zusammen installiert sind, oder deinstallieren Sie den VI Client 2.5 und installieren Sie ihn neu.
- Das ESX/ESXi-Installationsprogramm führt die lokalen SAS-Speichergeräte im Abschnitt "Remotespeicher" auf
Beim Anzeigen der Speicherorte, in denen ESX oder ESXi Installable installiert wird, führt das Installationsprogramm im Abschnitt "Remotespeicher" ein lokales SAS-Speichergerät auf. Dies liegt daran, dass ESX/ESXi nicht feststellen kann, ob das SAS-Speichergerät lokal oder remote ist. Es wird deshalb immer als remote angesehen. Umgehung: Keine
- Wenn vSphere Host Update Utility die Netzwerkverbindung zum ESX-Host verliert, funktioniert das Host-Upgrade möglicherweise nicht
Wenn Sie zum Durchführen eines ESX/ESXi-Host-Upgrades das vSphere Host Update Utility verwenden und die Verbindung des Dienstprogramms mit dem Host unterbrochen wird, wird der Host möglicherweise nicht vollständig aktualisiert. Wenn dies geschieht, reagiert das Dienstprogramm möglicherweise nicht mehr oder die folgende Fehlermeldung wird ausgegeben: Fehler beim Ausführen der Kompatibilitätsprüfung auf dem Host.
Umgehung: Schließen Sie das Dienstprogramm, reparieren Sie die Netzwerkverbindung, starten Sie das Dienstprogramm neu und führen Sie das Upgrade erneut aus.
- Wenn auf demselben System vSphere Client 4.0 und VI Client 2.5 installiert werden, wird abhängig von der Reihenfolge, in der Sie die Anwendungen deinstallieren, die Desktopverknüpfung nicht aktualisiert
Wenn Sie die vSphere Client 4.0-Anwendung auf einem System installieren, auf dem sich eine Instanz der VI Client 2.5-Anwendung befindet, erscheinen nur die vSphere Client 4.0-Desktopverknüpfungen auf dem Desktop. Über diese Verknüpfung können Sie beide Anwendungen starten. Wenn Sie die vSphere Client 4.0-Anwendung deinstallieren, die VI Client 2.5-Anwendung jedoch nicht deinstallieren, verbleibt die vSphere Client 4.0-Desktopverknüpfung auf dem System. Sie können die Verknüpfung nach wie vor benutzen, um sich beim VI Client 2.5 anzumelden, aber wenn Sie versuchen, sich beim vSphere Client 4.0 anzumelden, werden Sie aufgefordert, die Anwendung herunterzuladen.
Umgehung: Führen Sie einen der folgenden Schritte aus:
- Wenn Sie nur die vSphere Client 4.0-Anwendung deinstallieren, benennen Sie die Desktopverknüpfung um oder installieren Sie die VI Client 2.5-Anwendung neu, sodass der Link den installierten Client korrekt widerspiegelt.
- Sofern Sie beide Anwendungen deinstallieren, entfernen Sie alle nicht funktionierenden Verknüpfungen.
- Der Wert für die nächste Ausführung einiger geplanter Aufgaben wird nach einem Upgrade von VirtualCenter 2.0.2.x auf vCenter Server 4.0 nicht beibehalten
Wenn Sie VirtualCenter 2.0.2.x auf vCenter Server 4.0 Upgrade, wird für einige geplante Aufgaben der Wert für die Nächste Ausführung
möglicherweise nicht beibehalten und die Aufgaben werden möglicherweise unerwartet ausgeführt. Wenn z. B. eine Aufgabe so geplant ist, dass sie jeden Tag um 10 Uhr ausgeführt wird, wird sie nach dem Upgrade möglicherweise um 11.30 Uhr ausgeführt. Dieses Problem tritt auf, weil es Unterschiede zwischen den Methoden gibt, die VirtualCenter 2.0.2.x und vCenter Server 4.0 verwenden, um den Zeitpunkt der nächsten Ausführung zu berechnen. Dieses Verhalten ist nur unter den folgenden Bedingungen sichtbar:
- Sie haben geplante Aufgaben, deren Zeitpunkte für die nächste Ausführung Sie geändert haben, nachdem sie ursprünglich geplant wurden. Sie weisen jetzt einen anderen Zeitpunkt für die
Nächste Ausführung
auf.
- Der neu geplante Zeitpunkt für die
Nächste Ausführung
ist noch nicht eingetreten.
Umgehung: Führen Sie die folgenden Schritte aus:
- Warten Sie vor dem Upgrade, bis die Aufgaben zum Zeitpunkt ihrer
Nächsten Ausführung
ausgeführt werden.
- Nach dem Upgrade von vCenter 2.0.x auf vCenter Server 4.0 bearbeiten und speichern Sie die geplante Aufgabe. Dieser Vorgang berechnet den Zeitpunkt der
Nächsten Ausführung
auf den korrekten Wert neu.
- Während eines Upgrades werden Standardalarme, die erst in vCenter Server 4.0 eingeführt wurden, nicht zum System hinzugefügt
Während eines Upgrades auf vCenter Server 4.0 werden die Standardalarme, die erst in vCenter Server 4.0 eingeführt wurden, nicht zum System hinzugefügt. Nachfolgende Standardalarme fehlen: HostConnectionStateAlarm
VmFaultToleranceLatencyStatusAlarm
HostEsxCosSwapAlarm
VmDiskLatencyAlarm
DatastoreDiskUsageAlarm
LicenseNonComplianceAlarm
VmTimedoutStartingSecondaryAlarm
VmNoCompatibleHostForSecondaryAlarm
HostErrorAlarm
VmErrorAlarm
HostConnectivityAlarm
NetworkConnectivityAlarm
StorageConnectivityAlarm
MigrationErrorAlarm
ExitStandbyErrorAlarm
VmHighAvailabilityError
HighAvailabilityError
LicenseError
HealthStatusChangedAlarm
VmFaultToleranceStateChangedAlarm
Umgehung: Weitere Informationen über ein Skript, das die neuen Standardalarme zum System hinzufügt, finden Sie im VMware Knowledgebase-Artikel 1010399.
- Upgrades der Hardware der virtuellen Maschine von Version 4 auf Version 7 führen dazu, dass die Netzwerkeinstellungen von Solaris-Gastbetriebssystemen verloren gehen
Upgrades der Hardware der virtuellen Maschine von Version 4 auf Version 7 ändern die Adresse des PCI-Bus der virtuellen Netzwerkadapter in Gastbetriebssystemen. Solaris erkennt die Adapter nicht und ändert die Nummerierung der Netzwerkschnittstellen (Beispielsweise wird e1000g0 zu e1000g1). Diese Änderung an der Nummerierung tritt ein, weil Solaris-IP-Einstellungen Schnittstellenamen zugeordnet sind, sodass es so aussieht, als ob die Netzwerkeinstellungen verloren gegangen sind und das Gastbetriebssystem nicht über eine ordnungsgemäße Konnektivität verfügt. Umgehung: Verwenden Sie den Befehl prtconf -D
, um nach dem Upgrade der Hardware der virtuellen Maschine die neuen Schnittstellennamen zu ermitteln, und benennen Sie anschließend alle alten Konfigurationsdateien mit deren neuen Namen um. e1000g0 wird beispielsweise e1000g1, sodass jede /etc/*e1000g0
-Datei in das /etc/*e1000g1
-Äquivalent umbenannt wird.
- Das vCenter Server-Installationsprogramm erkennt keine Service-Ports, wenn die Services nicht ausgeführt werden
Wenn Sie vCenter Server installieren und die Standardports übernehmen, kann das Installationsprogramm die Ports nicht validieren, wenn sie von nicht ausgeführten Services verwendet werden. Die Installation schlägt fehl und je nach verwendetem Port wird möglicherweise eine Fehlermeldung ausgegeben. Dieses Problem betrifft keine IIS-Dienste. IIS-Dienste werden immer korrekt validiert, ob die Services ausgeführt werden oder nicht.
Umgehung: Identifizieren Sie die Ports, die für nicht ausgeführte Services verwendet werden, bevor Sie mit der Installation beginnen, und vermeiden Sie sie.
- Aktualisiert: 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.
- 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 vihostupdatedurchfü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/scratchfestgelegt 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 ( /<vmfs-volume-path>), 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.plauf, 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 <ServerIPAdressePlatzhalter> --username root --password <KennwortPlatzhalter> --bundle <URLPlatzhalter>.zip --install
- 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.
- Wenn ESXi 3.5 auf ESXi 4.0 Update 1 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 1 installiert. Nach dem Upgrade zeigt der Befehl esxupdate queryjedoch keine Bulletins an.
Umgehung: Dieses Problem hat keine Auswirkung auf die Kernfunktionalität des Hosts. Das Problem kann nicht umgangen werden.
- Der WS-Management-Dienst wird nicht automatisch auf einem Host gestartet, der von ESXi 3.5.x auf ESXi 4.0 Update 1 aktualisiert wurde
Dieses Upgrade kann dazu führen, dass der WS-Management-Dienst (wsman) nicht automatisch gestartet wird, was durch die Ausführung des folgenden wsman-Statusbefehls überprüft werden kann:
/etc/init.d/wsman status
Umgehung:
- Starten Sie den wsman-Dienst im Tech Support-Modus.
Weitere Informationen zur Verwendung des Tech Support-Modus finden Sie unter KB 1003677. Sie können den Dienst wie folgt starten: /etc/init.d/wsman start
- Überprüfen Sie den Status des wsman-Dienstes, um sicherzustellen, dass er ausgeführt wird.
Beispiel: /etc/init.d/wsman status
- Benennen Sie in der Datei /etc/chkconfig.dbden Eintrag für den WS-Management-Dienst von wsmandin wsmanum, damit die Änderung beim Neustart erhalten bleibt.
Nachfolgend finden Sie ein Beispiel für den vollständigen Pfad der Datei: /etc/init.d/wsman
vCenter Server und vSphere-Client
- Guided Consolidation kann keine Systeme importieren, auf denen vCenter Converter ausgeführt wird
Bei den Importvorgängen von Guided Consolidation tritt ein Problem auf, wenn auf dem Quellsystem (d. h. auf dem importierten System) vCenter Converter ausgeführt wird. Guided Consolidation importiert das System und versucht, vCenter Converter von dem Quellsystem zu deinstallieren. Der Importvorgang gelingt, aber die folgende Fehlermeldung wird angezeigt, wenn Guided Consolidation versucht, vCenter Converter zu deinstallieren: VMware Converter-Agent-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
- Wenn Sie im vSphere-Client auf der Registerkarte "Erste Schritte" für bestimmte Objekte (Cluster, Host, virtuelle Maschine) auf die Schaltfläche "Registerkarte schließen [x]" klicken, geschieht nichts
Wenn Sie im vSphere-Client auf der Registerkarte Erste Schritte für bestimmte Objekte (Cluster, Host, virtuelle Maschine) auf die Schaltfläche Registerkarte schließen [x] klicken, geschieht nichts. Dieses Problem tritt nur dann auf, wenn der vSphere Client auf einer Maschine läuft, in deren Betriebssystem Javascript deaktiviert ist. Umgehung: Keine
- Die Leistungsdiagramme werden nicht im Überblick angezeigt, wenn der vCenter Server eine Oracle-Datenbank verwendet
Leistungsdiagramme werden über die Ansicht "Überblick" auf der Registerkarte Leistung angezeigt. Falls Ihr vCenter Server eine Oracle-Datenbank verwendet, erscheinen die Diagramme nicht, wenn Sie diese Ansicht öffnen. Stattdessen wird folgende Fehlermeldung angezeigt: Interner Fehler bei STATs-Berichtsdienst:
Initialisierung der STATs-Berichtsanwendung konnte nicht erfolgreich abgeschlossen werden.
Dieser Fehler tritt auf, weil aufgrund von Lizenzbeschränkungen VMware eine Platzhalterdatei anstatt der ojdbc5.jar
-Datei von Oracle mit den Überblicksleistungsdiagrammen ausführt.
Umgehung: Führen Sie die folgende Aufgabe zum Überschreiben der Platzhalterdatei ojdbc5.jar
von Oracle mit der tatsächlichen Datei durch.
- Laden Sie die Datei
ojdbc5.jar
von der Website "Oracle Technology Network" herunter.
- Tauschen Sie die VMware-Platzhalterdatei durch die heruntergeladene
ojdbc5.jar
-Datei aus. Standardmäßig befindet sich diese Datei im Verzeichnis C:\Programme\VMware\Infrastructure\tomcat\lib
.
- Starten Sie den vCenter Server-Webservice neu.
- Alarme mit den Systemzustand betreffenden Auslösebedingungen werden nicht nach vSphere 4.0 migriert
Die Alarmauslösefunktionalität von vSphere 4.0 wurde erweitert. Sie enthält zusätzliche Alarmauslöser für den Systemzustand des Hosts. Dabei wurde der generische Auslöser "Host-Zustand" entfernt. Daher stehen Alarme, die diesen Auslöser enthalten, in vSphere 4.0 nicht mehr zur Verfügung. Umgehung: Verwenden Sie den vSphere-Client, um die Alarme erneut zu erstellen. Sie können die folgenden vorkonfigurierten VMware-Alarme verwenden, um den Systemzustand des Hosts zu überwachen:
- Batteriestatus des Hosts
- Lüftungsstatus der Hosthardware
- Betriebsstatus der Hosthardware
- Temperaturstatus der Hosthardware
- Status der Hauptplatine der Hosthardware
- Spannung der Hosthardware
- Arbeitsspeicherstatus des Hosts
- Prozessorstatus des Hosts
- Speicherstatus des Hosts
Falls sich der Status, den Sie überwachen möchten, nicht unter den vorkonfigurierten Alarmen befindet, können Sie einen benutzerdefinierten Alarm erstellen, der den Ereignisauslöser "Hardwarestatus geändert" verwendet. Für diesen Ereignisalarm müssen Sie die Auslösebedingungen manuell festlegen. Darüber hinaus müssen Sie manuell einstellen, welche Aktion durchgeführt werden soll, wenn der Alarm ausgelöst wird.
Hinweis: Für die vorkonfigurierten Alarme wurden bereits Standardauslösebedingungen festgelegt. Sie brauchen nur noch einzustellen, welche Aktion bei Alarmauslösung durchgeführt werden soll.
- Virtuelle Maschinen verschwinden aus dem Diagramm der virtuellen Switches in der Netzwerkansicht für die Hostkonfiguration
Virtuelle Maschinen werden in der Netzwerkansicht auf der Registerkarte "Konfiguration" des vSphere-Clients für einen Host im Diagramm der virtuellen Switches dargestellt. Wenn Sie einen anderen Host auswählen und dann zur Registerkarte "Konfiguration" des ersten Hosts zurückkehren, verschwinden die virtuellen Maschinen möglicherweise aus dem Diagramm der virtuellen Switches. Umgehung: Wählen Sie auf der Registerkarte "Konfiguration" eine andere Ansicht, z. B. Netzwerkadapter, Speicher oder Speicheradapter, und kehren Sie zur Registerkarte "Netzwerk" zurück.
- 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: 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: Interner Fehler bei STATs-Berichtsdienst
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
- 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: Geben Sie in eine Eingabeaufforderung des Systems Folgendes ein, um den Befehl vc-support.wsf
mit der 32-Bit-DSN-Anwendung cscript.exe
auszuführen:
%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 "Benutzerkonten" 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 ändernund 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 "Benutzerkonten" 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.
- Der vCenter Server-Ressourcen-Manager aktualisiert den Hostbaum in einem Cluster nicht, bei dem weder DRS noch HA aktiviert ist
Wenn Sie VMotion zum Einschalten oder Migrieren einer virtuellen Maschine auf Clustern verwenden, bei denen weder HA noch DRS aktiviert ist, schlägt der Vorgang möglicherweise fehl mit folgender Fehlermeldung:
-
Der Host verfügt für die Reservierung nicht über ausreichende Arbeitsspeicherressourcen.
-
Der Host verfügt für die Reservierung nicht über ausreichende CPU-Ressourcen.
Dieses Problem tritt auch dann auf, wenn es scheint, als habe der Host genügend Kapazitäten frei, und nur dann, wenn sich beide Hosts in demselben Cluster befinden.
Wenn VMotion verwendet wird, um eine virtuelle Maschine auf einen Host zu migrieren oder sie unter dem neuen Host einzuschalten, schätzt vCenter Server ab, ob der Host über genügend nicht reservierten Ressourcen verfügt, um den Anforderungen der virtuellen Maschine gerecht zu werden. Die internen Datenstrukturen, die für diese Einschätzung verwendet werden, werden jedoch nicht aktualisiert, wenn Sie VMotion in einem Cluster zum Migrieren einer virtuelle Maschine von einem Quell- auf einen Zielhost verwenden, nachdem Sie die virtuelle Maschine auf dem Quellhost eingeschaltet haben. Alle künftigen Zugangssteuerungsberechnungen für den Quellhost berücksichtigen die Reservierung dieser virtuellen Maschine, obwohl er nicht mehr auf dem Host ausgeführt wird. Dieses Verhalten führt möglicherweise dazu, dass Einschalt- und VMotion-Vorgänge, die den Quellhost als Ziel haben, fehlschlagen.
Hinweis: Diese Fehler werden in der Protokolldatei wie folgt gemeldet:
-
vim.fault.InsufficientHostCpuCapacityFault
-
vim.fault.InsufficientHostMemoryCpuCapacityFault
Umgehung: Konfigurieren Sie die Reservierung der virtuellen Maschine neu oder schalten Sie die Maschine ein bzw. aus. Diese Aktionen zwingen vCenter Server dazu, seine interne Datenstrukturen zu Upgrade.
- 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 den Konfigurationsassistenten für den verknüpften Modus ausführen, nachdem Sie in einer reinen IPv6-Umgebung ein vCenter Server-System mit einer Gruppe verknüpft haben, gibt es keine Option, um das vCenter Server-System aus dem verknüpften Modus zu isolieren
Wenn vCenter Server in einer reinen IPv6-Umgebung (Windows 2008 x32 oder Windows 2008 x64) verknüpft ist und Sie den Konfigurationsassistenten für den verknüpften Modus aufrufen, ist die Option vCenter Server-Instanz einer vorhandenen Gruppe für den verknüpften Modus oder einer anderen Instanz hinzufügen aktiviert. Es gibt keine Option, um das vCenter Server-System aus dem verknüpften Modus zu isolieren. Umgehung: Konfigurieren Sie das vCenter Server-System im gemischten Modus (IPv4 und IPv6) und rufen Sie den Konfigurationsassistenten für den verknüpften Modus auf: Start > VMware > Konfiguration für den verknüpften Modus. Die Option Beitreten ist deaktiviert und die Option Diese vCenter Server-Instanz von der Gruppe für den verknüpften Modus isolieren ist aktiviert.
Hinweis: Wenn Sie ein vCenter Server-System im gemischten Modus konfigurieren, muss der Domänencontroller auch im gemischten Modus arbeiten. Falls Sie den gemischten Modus nicht in Ihrer IPv6-Umgebung verwenden möchten, müssen Sie vCenter Server deinstallieren, um das System aus dem verknüpften Modus zu isolieren.
- Wenn Sie bei großen vCenter Server-Bestandslisten den vSphere-Client im verknüpften Modus öffnen und dabei die Bestandslisten aller vCenter Server-Systeme vollständig erweitert sind, reagiert der vSphere-Client möglicherweise für einige Minuten nicht
vSphere-Client-Bestandslisten sind dann vollständig erweitert, wenn Cluster und Datencenter erweitert sind. Wenn Sie den vSphere-Client schließen, nachdem die Bestandslisten erweitert wurden, wird die erwartete Bestandslistenansicht beim nächsten Öffnen des Clients geladen. Als Folge davon reagiert der vSphere-Client möglicherweise für einige Minuten nicht mehr, abhängig von der Anzahl der vCenter Server-Systeme und der Anzahl der Objekte in den Bestandslisten der jeweiligen vCenter Server-Systeme. Der vSphere-Client reagiert wird, nachdem alle Bestandslistenobjekte geladen wurden. Umgehung: Es wird empfohlen, bei einer Gruppe im verknüpften Modus nicht die Knoten aller vCenter Server-Systeme in der Bestandsliste zu erweitern. Reduzieren Sie die Knoten, bevor Sie den vSphere-Client schließen, um das Laden der erweiterten Knoten beim Start zu vermeiden.
- vCenter Server schlägt möglicherweise fehl, wenn die Berechtigungen für das vpxuser-Konto geändert werden
Wenn Sie einen vSphere-Client direkt mit einem ESX/ESXi-Host verbinden und die Registerkarte Berechtigungen auswählen, ist es möglich, die Berechtigungen für das vpxuser-Konto zu ändern. Es wäre beispielsweise sinnvoll, die Berechtigungen zu ändern, sodass vpxuser nicht über Administratorrechte für alle Hostbestandslistenobjekte verfügt. vCenter Server schlägt jedoch nach einer solchen Änderung möglicherweise fehl. Umgehung: Legen Sie das vpxuser-Konto auf dem Host so fest, dass es über Administratorrechte ab dem Root-Ordner abwärts verfügt. Sie können dies tun, indem Sie einen vSphere-Client mit dem Host verbinden und anschließend die Registerkarte Berechtigungen auswählen.
- 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
- Neu: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, unterstützen Wake-On-LAN. 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.
- Neu:Das Erstellen einer neuen SCSI-Festplatte in einer virtuellen Maschine kann dazu führen, dass eine ungenaue Fehlermeldung ausgegeben wird
Wenn Sie eine neue SCSI-Festplatte in einer virtuellen Maschine erstellen und den SCSI-Bus auf virtual setzen, wird folgende Fehlermeldung ausgegeben:
Stellen Sie sicher, dass die virtuelle Festplatte unter Verwendung der Option "Thick" erstellt wurde.
Allerdings ist Thickallein keine gültige Option. Die korrekte Option lautet eagerzeroedthick.
Umgehung: Erstellen Sie die SCSI-Festplatte mit dem Befehlszeilenbefehl vmkfstoolsund der Option eagerzeroedthick.
- Die Optionen für den Installationsstartvorgang einer virtuellen Maschine werden nicht nach OVF exportiert
Wenn Sie auf einer virtuellen Maschine, auf der die Option "Installationsstartvorgang" aktiviert ist, ein OVF-Paket erstellen, wird diese Option während des Exports ignoriert. Daher fehlt im OVF-Deskriptor das Element InstallSection
, das Informationen zum Installationsvorgang liefert. Wenn Sie ein OVF-Paket bereitstellen, wird das Element InstallSection
ordnungsgemäß analysiert. Umgehung: Nachdem die virtuelle Maschine nach OVF exportiert wurde, erstellen Sie die InstallSection
-Parameter manuell im OVF-Deskriptor. Ist eine Manifestdatei ( .mf
) vorhanden, müssen Sie sie im Anschluss an die Änderung des OVF-Deskriptors erneut generieren.
Beispiel: <InstallSection ovf:initialBootStopDelay="300"> <Info>Legt fest, dass ein Installationsstartvorgang notwendig ist.</Info> </InstallSection>
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
die Startverzögerung fest.
Einzelheiten hierzu finden Sie in der OVF-Spezifikation.
- Eine von einem Snapshot einer virtuellen Maschine mit einem LSI SAS-Controller geklonte virtuelle Maschine wird evtl. fälschlicherweise mit einem BusLogic-Controller konfiguriert
Wenn Sie einen Snapshot einer virtuellen Maschine mit einem LSI SAS-Controller erstellen und anschließend von dem Snapshot eine virtuelle Maschine klonen, wird für die von dem Snapshot geklonte virtuelle Maschine möglicherweise ein BusLogic- statt eines LSI SAS-Controllers in den VM-Eigenschaften konfiguriert. Umgehung: Überprüfen Sie in der Eigenschaft "Snapshot.config" den Controllertyp der virtuellen Maschine, die Sie anhand eines Snapshots einer virtuellen Maschine, die über einen LSI SAS-Controller verfügt, geklont haben. Konfigurieren Sie nach Bedarf den Controllertyp für die geklonte virtuelle Maschine.
- Neu:Nach dem Anhalten und Fortsetzen einer virtuellen Maschine kann das Deaktivieren des VMXNET3-Adapters fehlschlagen
Wenn die Netzwerkverbindung zwischen dem Anhalten und Fortsetzen in einen nicht definierten Zustand wechselt, beispielsweise wenn der Name der Portgruppe geändert wird, kann das virtuelle Netzwerkgerät die neue Netzwerkverbindung mit dem Treiber nicht Upgrade. Dieser Zustand verhindert, dass der VMXNET3-Adapter deaktiviert, deinstalliert oder aktualisiert werden kann.
Umgehung: Verbinden Sie den Adapter neu mit einer gültigen Portgruppe.
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.
- Das Konvertieren einer virtuellen Festplatte von "Thick" nach "Thin" unter Verwendung von Storage VMotion schlägt fehl
Beim Migrieren von virtuellen Maschinen, die mit dem VMFS-Maximalgrenzwert für Dateisysteme konfiguriert sind, wird folgende Fehlermeldung ausgegeben: Datei[vol] <VM-Pfad> ist größer als die vom Datenspeicher <Zieldatenspeicher>
unterstützte maximale Größe.
Umgehung: Keine. Konfigurieren Sie eine VM-Festplatte nicht auf ihr maximales Volume-Limit, wenn Sie vorhaben, die virtuelle Maschine zu migrieren.
- Auf einer lokalen Datenspeicher gespeicherte virtuelle Maschinen werden nicht vom Host migriert, wenn sich der Host im Wartungsmodus befindet
Auf einer lokalen Datenspeicher gespeicherte virtuelle Maschinen werden nicht vom Host migriert, wenn sich der Host im Wartungsmodus befindet. Umgehung: Verschieben Sie die virtuellen Maschinen auf lokalen Datenspeichern manuell auf einen anderen Host, falls sie weiterhin zur Verfügung stehen müssen, während sich der aktuell Host im Wartungsmodus befindet.
VMware High Availability und Fehlertoleranz
- Failover auf sekundäre virtuelle VMware FT-Maschine führt zu Fehlermeldung auf dem Host-Client
Wenn VMware-Fehlertoleranz ein Failover auf eine sekundäre virtuelle Maschine durchführt und der für die sekundäre virtuelle Maschine ausgewählte Host erst kürzlich neu gestartet wurde, betrachtet der Host-Client diesen Versuch als Fehlschlag und zeigt folgende Fehlermeldung an: Anmeldung fehlgeschlagen wegen eines ungültigen Benutzernamens oder Kennworts
.
Diese Fehlermeldung wird angezeigt, weil der Host kürzlich neu gestartet wurde und es möglich ist, dass er noch keinen SSL-Fingerabdruck von vCenter Server empfangen hat. Nachdem der Fingerabdruck an den Host gesendet wurde, verläuft das Failover erfolgreich. Diese Bedingung tritt nur dann auf, wenn alle Hosts in einem FT-aktivierten Cluster ausgefallen sind, was dazu führt, dass der Host mit der sekundären virtuellen Maschine neu gestartet wird.
Umgehung: Keine. Das Failover verläuft nach einigen Versuchen erfolgreich.
- Das Ändern der Systemzeit auf einem ESX/ESXi-Host führt zu einem VMware HA-Agent-Fehler
Wenn Sie die Systemzeit auf einem ESX/ESXi-Host ändern, wird nach kurzer Zeit der folgende HA-Agent-Fehler angezeigt: Der HA-Agent auf < Server> in < Cluster> im < Datencenter> hat einen Fehler
.
Dieser Fehler wird sowohl im Ereignisprotokoll als auch auf der Host-Registerkarte Übersicht im vSphere-Client angezeigt.
Umgehung: Korrigieren Sie die Systemzeit des Hosts und starten Sie "vpxa" mit dem Befehl service vmware-vpxa restart
neu.
- Das Upgrade von einem ESX/ESXi 3.x-Host auf einen ESX/ESXi 4.0-Host verläuft erfolgreich, aber die VMware HA-Neukonfiguration schlägt möglicherweise fehl
Wenn Sie mit vCenter Update Manager 4.0 ein Upgrade des ESX/ESXi 3.x-Hosts auf ESX/ESXi 4.0 durchführen und der Host Teil eines HA- oder DRS-Clusters ist, verläuft das Upgrade erfolgreich und der Host wird wieder mit vCenter Server verbunden, aber die HA-Neukonfiguration schlägt möglicherweise fehl. Die folgende Fehlermeldung wird auf der Host-Registerkarte Übersicht angezeigt: Der HA-Agent weist einen Fehler auf: cmd addnode fehlgeschlagen für primären Knoten: Interner AAM-Fehler - Agent konnte nicht gestartet werden. : Unbekannter HA-Fehler
.
Umgehung: Konfigurieren Sie HA manuell neu, indem Sie mit der rechten Maustaste auf den Host klicken und Für VMware HA neu konfigurieren wählen.
- 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 wird. 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.
Seitenanfang
Versionshinweise zu VMware ESXi 4.0 Update 1
ESXi 4.0 Update 1 Installable | 19. November 2009 | Build 208167 ESXi 4.0 Update 1 Embedded | 19. November 2009 | Build 208167 Letzte Dokumentaktualisierung: 10 Dez. 2009 |
Diese Versionshinweise decken die folgenden Themen ab:
Neuigkeiten
Sie erhalten nachstehend Informationen zu einigen der wichtigsten Verbesserungen in der vorliegenden Version von VMware ESXi:
Unterstützung für VMware View 4.0 – In dieser Version wird VMware View 4.0 unterstützt, eine Lösung, die speziell für das Bereitstellen von Desktops als verwalteten Dienst vom Protokoll zur Plattform entwickelt wurde.
Windows 7- und Windows 2008 R2-Unterstützung –Diese Version unterstützt 32- und 64-Bit-Versionen von Windows 7 sowie Windows 2008 R2 (64-Bit) als Gastbetriebssystemplattformen. Zudem wird der vSphere-Client jetzt unterstützt und kann auf einer Windows 7-Plattform installiert werden. Eine vollständige Liste der von dieser Version unterstützten Gastbetriebssysteme finden Sie im VMware-Kompatibilitätshandbuch .
Erweiterte Clustering-Unterstützung für Microsoft Windows – Microsoft Cluster Server (MSCS) für Windows 2000 und 2003 und das Failover-Clustering für Windows Server 2008 wird jetzt auf einem VMware High Availability- (HA) und Dynamic Resource Scheduler-Cluster (DRS) in einer eingeschränkten Konfiguration unterstützt. Die HA- und DRS-Funktionalität kann für individuelle virtuelle MSCS-Maschinen effektiv deaktivert werden, ohne dass HA und DRS auf dem ganzen ESX/ESXi-Host deaktiviert werden müssen .Im Handbuch Einrichten für das Failover-Clustering und Microsoft Cluster Service finden Sie zusätzliche Konfigurationsrichtlinien.
Erweiterte Unterstützung für VMware Paravirtualized SCSI – Windows 2003- und 2008-Gastbetriebssysteme unterstützen nun an einen PVSCSI-Adapter (Paravirtualized SCSI) angeschlossene Startlaufwerke. Es stehen auch Diskettenimages mit dem bei der Windows-Installation benötigten Treiber zur Verfügung. Drücken Sie während der Installation auf F6, um zusätzliche Treiber zu installieren. Disketten-Images befinden sich im Ordner /vmimages/floppies/.
Verbesserte Leistung des verteilten vNetwork-Switches – Mehrere Leistungs- und Nutzungsprobleme wurden behoben. Dadurch wurde Folgendes erreicht:
- Verbesserte Leistung bei Änderungen an der Konfiguration einer Instanz eines verteilten vNetwork-Switches (vDS), wenn der ESX/ESXi-Host stark ausgelastet ist.
- Verbesserte Leistung beim Hinzufügen oder Entfernen des ESX/ESXi-Hosts zu/von einer vDS-Instanz
Erhöhung des vCPU-Grenzwerts pro Core – Der Grenzwert für vCPUs pro Core wurde von 20 auf 25 erhöht. Diese Änderung sorgt nur für eine Erhöhung des unterstützten Grenzwerts. Sie schließt keine zusätzlichen Leistungsoptimierungen ein. Die Erhöhung des Grenzwerts bietet Benutzern mehr Flexibilität beim Konfigurieren von Systemen mit bestimmten Arbeitslasten und größtmöglichen Nutzen durch wesentlich schnellere Prozessoren. Die erreichbare Anzahl an VCPUs pro Core hängt von der Arbeitslast und den Spezifikationen der Hardware ab. Weitere Informationen finden Sie im Handbuch zu den Performance Best Practices für VMware vSphere 4.0 .
Aktivierung der Intel Xeon 3400-Prozessorserie – Die Xeon 3400-Prozessorserie wird jetzt unterstützt. Eine vollständige Liste der unterstützten Drittanbieter-Hardware und -Geräte finden Sie im VMware-Kompatibilitätshandbuch .
Behobene Probleme –Diese Version enthält darüber hinaus verschiedene Fehlerkorrekturen, die im Abschnitt "Behobene Probleme" dokumentiert sind.
Seitenanfang
Vorherige Versionen von VMware vSphere 4
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 früherer Versionen von ESXi 4.0 anzeigen möchten, klicken Sie auf einen der folgenden Links:
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 wahlweise anderer VMware-Produkte. Überprüfen Sie außerdem die "Kompatibilitätstabellen für vSphere 4.0" auf Informationen zu unterstützten Verwaltungs- und Sicherungsagenten, bevor Sie ESXi oder vCenter Server installieren.
Hardwarekompatibilität
Dokumentation
Die Dokumentation wurde für VMware vSphere 4.0 Update 1 aktualisiert.
Installation und Upgrade
Im Handbuch zur Einrichtung für ESXi Installable und vCenter Server Update 1 finden Sie Schritt-für-Schritt-Anleitungen zur Installation und Konfiguration von ESXi Installable und vCenter Server. Schritt-für-Schritt-Anleitungen zur Einrichtung von ESXi Embedded und vCenter Server finden Sie im Handbuch zur Einrichtung für ESXi Embedded und vCenter Server Update1 .
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. Es wird empfohlen, auf VMFS Version 3 oder höher zu Upgrade bzw. zu migrieren. Weitere Informationen finden Sie im vSphere-Upgrade-Handbuch Update 1 .
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 Update 1 weitere Informationen über das Installieren von vCenter Server auf einem 64-Bit-Betriebssystem unter Beibehaltung der VirtualCenter-Datenbank.
Das VMware Tools-RPM-Installationsprogramm, das zuvor auf dem VMware Tools-ISO-Image für Linux-Gastbetriebssysteme zur Verfügung stand, steht in ESXi nicht zur Verfügung. Es wird empfohlen, das tar.gz-Installationsprogramm zum Installieren der VMware Tools auf virtuellen Maschinen mit Linux-Gastbetriebssystemen zu verwenden.
MIB-Dateien (Management Information Base), die sich auf ESXi beziehen, werden nicht zusammen mit vCenter Server ausgeliefert. Nur MIB-Dateien, die sich auf vCenter Server beziehen, werden mit vCenter Server 4.0 mitgeliefert. Alle MIB-Dateien können von der VMware-Website unter www.vmware.com/de/download heruntergeladen werden.
Upgrade oder Migration auf ESXi 4.0 Update 1
vSphere 4.0 Update 1 stellt folgende Anwendungen bereit, die Sie zum Upgrade von ESXi 4.0 Update01 verwenden können:
- vSphere Host Update Utility– Für eigenständige Hosts. Ein eigenständiger Host ist ein ESX/ESXi-Host, der nicht von vCenter Server verwaltet wird. Weitere Informationen hierzu finden Sie im vSphere-Upgrade-Handbuch Update 1 .
- VMware vCenter Update Manager– Für von vCenter Server verwaltete ESX/ESXi-Hosts. Weitere Informationen finden Sie im Administratorhandbuch zu VMware vCenter Update Manager Update 1 .
- Befehlszeilendienstprogramm "vihostupdate"- Das Befehlszeilenprogramm "vihostupdate" wendet Software-Updates auf ESX/ESXi-Hosts an und installiert und aktualisiert ESX/ESXi-Erweiterungen wie VMkernel-Module, Treiber und CIM-Anbieter. Weitere Informationen hierzu finden Sie im vSphere-Upgrade-Handbuch Update 1 .
Unterstützte Upgrade-Pfade für das Host-Upgrade auf ESXi 4.0 Update 1
Upgrade-Typ |
ESXi Server 3.5 |
ESXi Server 3.5 Enthält: Update 1 Update 2 Update 3 Update 4 Update 5 |
ESXi 4.0 |
Upgrade mit Upgrade-ZIP für ESXi 4.0 Update 1 |
Ja |
Ja |
Nein |
Upgrade mit Offline-Paket für ESXi 4.0 Update 1 |
Nein |
Nein |
Ja |
Hinweise:
- Unterstützte Vorgehensweisen für das Upgrade unter Verwendung von Upgrade-ZIP sind vSphere Host Update Utility und vCenter Update Manager. Weitere Informationen hierzu finden Sie im vSphere-Upgrade-Handbuch Update 1 und im Administratorhandbuch zu VMware vCenter Update Manager Update 1 .
- Die unterstützte Vorgehensweise für die Verwendung des Offline-Pakets für ESXi 4.0 Update 1 ist das Befehlszeilendienstprogramm vihostupdate. Weitere Informationen hierzu finden Sie im vSphere-Upgrade-Handbuch Update 1 .
- Informationen zum Upgrade des ESXi 4.0-Hosts auf ESXi 4.0 Update 1 unter Verwendung der Online-Patches und vCenter Update Manager 4.0 Update 1 finden Sie im Patches-Abschnitt dieser Versionshinweise und im Administratorhandbuch zu vCenter Update Manager 4.0 U1 .
- Informationen zum Upgrade des ESXi 4.0-Hosts auf ESXi 4.0 Update 1 unter Verwendung der Online-Patches und vSphere Host Update Utility finden Sie im Patches-Abschnitt dieser Versionshinweise und im vSphere-Upgrade-Handbuch Update 1 .
Duchführen eines Upgrades der VMware Tools
Diese Version von VMware ESXi setzt ein Upgrade von VMware Tools voraus.
In dieser Version enthaltene Patches
Zusätzlich zu ISO-Images wird ESXi 4.0 Update 1(Embedded und Installable) als Patch verteilt, der auf vorhandene Installationen der ESXi 4.0-Software angewendet werden kann.
Das Patchpaket kann von der VMware-Webseite für Download-Patches heruntergeladen oder unter Verwendung von VMware Update Manager angewendet werden. Das Patchpaket enthält dieselben Bulletins wie die einzelnen Bulletins in VMware Update Manager. Dies ist das Patchpaket:
Patch-Version ESXi400-Update01 enthält die folgenden einzelnen Bulletins:
Diese Version enthält zudem alle Patches für die ESXi Server-Software, die vor dem Veröffentlichungsdatum dieses Produkts zur Verfügung standen. Weitere Informationen zu den einzelnen Patches finden Sie auf der VMware-Webseite für Download-Patches.
ESXi 4.0 Update 1 enthält zudem alle Fixes in den folgenden zuvor veröffentlichten Paketen:
Weitere Informationen zu den Inhalten der Patches finden Sie in der Dokumentation, die auf der Download-Seite aufgeführt wird.
Seitenanfang
Behobene Probleme
In dieser Version werden Probleme in den folgenden Themengebieten behoben:
† Behobene Probleme, die früher als bekannte Probleme dokumentiert wurden.
CIM und API
- Der ESXi-Sperrmodus funktioniert nicht korrekt
Der CIMOM auf einem ESXi-Host weist folgende Probleme auf, wenn sich der Host im Sperrmodus befindet:
- Die Methode PowerManagementService.Reboot()meldet fälschlicherweise einen erfolgreichen Abschluss, wenn sich der Host im Sperrmodus befindet.
- Die Methode RecordLog.ClearLog()verläuft erfolgreich, sollte aber zurückgewiesen werden.
- Im Sperrmodus führt CIMOM Systemaufrufe in einer Schleife aus. Damit kann die CPU-Nutzung auf 100 % steigen.
- Die wiederholten Systemaufrufe führen dazu, dass Authentifizierungsfehlermeldungen in die Systemprotokolle geschrieben werden.
Diese Probleme wurden behoben. Der CIMOM weist nun im Sperrmodus die folgenden extrinsischen Methodenaufrufe zurück:
- Anforderungen, die mit dem Benutzernamen 'root' authentifiziert werden, werden im Sperrmodus immer zurückgewiesen.
- Die Methode PowerManagementService.Reboot()schlägt im Sperrmodus immer fehl, weil der PowerManagementService-Provider bei Ausführung immer anhand des Hosts authentifiziert wird. Im Sperrmodus akzeptiert der Host keine Authentifizierungsanforderungen.
Der CIMOM akzeptiert im Sperrmodus die folgenden extrinsischen Methodenaufrufe:
- Andere extrinsische Methodenaufrufe als PowerManagementService.Reboot(), die mit einem anderen Benutzernamen als 'root' authentifiziert werden, wenn der Benutzername über vSphere-Administrationsrechte auf dem Host verfügt. Diese Methodenaufrufe werden weiterhin vom Authentifizierungscache authentifiziert.
- Extrinsische Methoden, die anhand eines Tickets, das über eine AcquireCIMServicesTicket()-Anforderung an die vSphere Web Services API erhalten wurde, authentifiziert werden. Das Ticket kann nur ausgestellt werden, wenn der Host von vCenter verwaltet und bevor der Host in den Sperrmodus versetzt wird. Die Ticketauthentifizierung gilt für die RecordLog.ClearLog()-Methode. Allerdings stellt die PowerManagementService.Reboot()-Methode eine Ausnahme dar.
Gastbetriebssystem
- Virtuelle Maschinen schlagen manchmal mit einem blauen Bildschirm fehl, wenn die Hardwarebeschleunigung vollaktiviert ist
Virtuelle Maschinen schlagen manchmal mit einem blauen Bildschirm fehl, wenn Sie bei vollaktivierter Hardwarebeschleunigung in Windows-Gastbetriebssystemen bestimmte Anwendungen ausführen.
Es handelt sich dabei um ein Problem mit dem SVGA-Treiber, das in dieser Version behoben wurde.
- Behebt ein Problem, wobei VMware Tools über "GuestInfo" falsche Festplatteninformationen für Linux-Gastbetriebssysteme, die LVM-Partitionen (Logical Volume Manager) (Logical Volume Manager) verwenden, meldet.
- Neu:Überschätzte Arbeitsspeicherauslastung von Gastbetriebssystemen verursacht fälschlich ausgelöste Alarme in vCenter Server
Die Arbeitsspeicherauslastung von Gastbetriebssystemen wird möglicherweise auf Intel-Systemen überschätzt, welche die EPT-Technologie unterstützen, oder auf AMD-Systemen, welche die RVI-Technologie unterstützen. Dies könnte dazu führen, dass die Arbeitsspeicheralarme des vCenter Servers auch dann ausgelöst werden, wenn das Gastbetriebssystem nicht aktiv auf große Speichermengen zugreift. Dieses Problem wurde in der vorliegenden Version behoben.
- Schriftartanzeigeproblem in virtuellen Maschinen bei der Anzeige auf Breitbildschirmen
Wenn eine virtuelle Maschine für Breitbildauflösung konfiguriert ist, erscheinen verzerrte Schriftarten in Microsoft Office-Anwendungen. Dieses Problem tritt auf, wenn die Auflösung auf 2560 x 1024 eingestellt ist.
Das Problem wurde in der vorliegenden Version behoben.
- Neu:Systembefehle schlagen fehl bei Verwendung der Gast-SDK-Bibliothek auf einem vMA 4.0-System
Wenn Sie versuchen, die Gast-SDK-Bibliothek auf einem vSphere Management Assistant (vMA) 4.0-System zu verwenden, schlagen die Systembefehle fehl und der folgende Fehler wird möglicherweise angezeigt: Lesen der Dateidaten nicht möglich: Fehler 21
Dieses Problem tritt auf, weil die Gast-SDK-Bibliotheken nicht auf Systemen gefunden werden, die Verzeichnisse enthalten, auf die der Befehl ldconfigzugreifen kann.
Dieses Problem wurde in der vorliegenden Version behoben.
- Wenn Sie VMware Tools oder die VSS-Komponenten in VMware Tools auf Version 4.0 Upgrade, werden Anwendungen, die die Datei "msvcp71.dll" benötigen, nicht gestartet, wenn eine virtuelle Maschine neu gestartet wird
Dieses Problem wurde in dieser Version behoben.
- Behebt ein Problem, wobei unter dem OS/2-Gastbetriebssystem eine e1000-vNIC-Emulation nicht ordnungsgemäß funktioniert
Dieser Fix enthält zur Behebung dieses Problems eine aktualisierte e1000-vNIC-Emulation.
Sonstige Probleme
- Neu:Nach dem Starten des ESX/ESXi-Hosts wird eine Warnmeldung in "/var/log" protokolliert
Nach dem Einschalten oder Neustart des ESX/ESXi-Hosts wird die folgende Warnmeldung in die Datei "/var/log/messages" eingetragen:
Peer table full for sfcbd.
Sie können diese Meldung ignorieren. Sie rührt nicht von Problemen mit ESX/ESXi her.
Dieses Problem wurde in der vorliegenden Version behoben.
- Einer Serie von vmklinux-Heapzuteilungswarnungen folgt ein ESX/ESXi-Systemausfall
Dieses Problem wird durch eine fehlerhalte Antwort auf eine legitime Mehrfachvergabe von Arbeitsspeicher verursacht. Nach häufiger Auslagerung oder Verwendung von VMotion tritt möglicherweise eine vmklinux-Beschränkung auf. Das Problem wird vor allem durch einen Mangel an Arbeitsspeicher unterhalb der Adresse 4 GB ausgelöst. In einer solchen Situation warnt eine Serie von Protokollmeldungen davor, dass die Zuteilung des Arbeitsspeichers für den vmklinux-Heap fehlgeschlagen ist. ESX/ESXi steht dann nicht mehr zur Verfügung; Ausnahme 14 wird in einer "Helper World" protokolliert. Nachfolgend ein Beispiel der protokollierten Meldungen:
[1:01:35:02.450 cpu7:4480)WARNING: Heap: 1471: Could not allocate 2093688 bytes for dynamic heap vmklinux. Request returned Out of memory
[1:01:35:02.450 cpu7:4480)WARNING: Heap: 1645: Heap_Align(vmklinux, 1024/1024 bytes, 8 align) failed. caller: 0x4180303746b7
[1:01:35:02.450 cpu7:4480)WARNING: Heap: 1471: Could not allocate 2093688 bytes for dynamic heap vmklinux. Request returned Out of memory
[1:01:35:02.450 cpu7:4480)WARNING: Heap: 1645: Heap_Align(vmklinux, 1024/1024 bytes, 8 align) failed. caller: 0x4180303746b7
[VMware ESX [Releasebuild-164009 X86_64]
#PF Exception(14) in world 4480:helper18-7 ip 0x41803037480c addr 0x0
Obwohl dieses Problem theoretisch auch bei ESXi auftreten kann, wurde es bisher nur bei ESX-Installationen beobachtet. Aufgrund der Verwendung von niedrigem Arbeitsspeicher durch die Servicekonsole ist ESX anfälliger.
Dieses Problem wurde in der vorliegenden Version behoben.
Netzwerk
- Wenn sich Intel MT- und PT-Dualport-Netzwerkkarten im Promiscuous-Modus befinden, ist der VLAN-Filter eingeschaltet
Dies führt dazu, dass CDP-Pakete (Cisco Discovery Protocol) verloren gehen. Dieser Fix bietet Prüfungen für CDP-Pakete mit VLAN-Tags, Plausibilitätskontrollen für eingehende Pakete und Protokollierungsausgabe für Analysefehler.
- Behebt ein Problem mit dem NetXen nx_nic-Netzwerktreiber auf NX2031-Karten, wobei ESX möglicherweise nicht mehr reagiert, nachdem auf Systemen mit mehr als 32 GB Arbeitsspeicher die Warteschlange angehalten wurde
- Behebt ein Problem, wobei ESX möglicherweise den CDP-Daemon im Betriebssystem der Konsole deaktiviert
- Aktualisiert die Beschreibung des Broadcom NetXtreme BCM5722-Netzwerkadapters in vCenter für manche Dell-Server
Die Beschreibung in vCenter für Broadcom NetXtreme BCM5722-Netzwerkadapter auf manchen Dell-Servern, die einige unnötige Wörter enthalten hat, wurde entfernt und auf NetXtreme BCM5722 Gigabit Ethernet aktualisiert. Die Beschreibung für Dell PowerEdge T105-, R300- und T300-Server wurde aktualisiert.
- Behebt ein Problem, wobei ESX mit dem nx_nic-Treiber möglicherweise fehlschlägt, nachdem ein Ethernet-Header als IP-Header entschlüsselt wurde
Dieser Fix legt die Variable LRO enabledauf 0 fest, da in ESX 4.0 Update 1 LRO (Large Receive Offload) nicht unterstützt wird.
Sicherheit
- Behebt ein Problem, wobei der NTPD-Daemon möglicherweise einen stapelbasierenden Pufferüberlauf aufweist, wenn er für die Verwendung des autokey-Sicherheitsmodells konfiguriert ist
Das Projekt "Common Vulnerabilities and Exposures" (cve.mitre.org) hat diesem Problem die Bezeichnung CVE-2009-1252 zugewiesen.
- Ein stackbasierter Pufferüberlauf in "ISC dhclient" ermöglicht Remote-DHCP-Servern möglicherweise das Ausführen von beliebigem Code unter Verwendung einer manuell gefertigten Subnetzmaskenoption
Das Projekt "Common Vulnerabilities and Exposures" (cve.mitre.org) hat diesem Problem die Bezeichnung CVE-2009-0692 zugewiesen.
Serverkonfiguration
- Eine TPM-verwandte Warnmeldung wird auf ESX/ESXi 4.0 ausgegeben, obwohl TPM auf dem System nicht zur Verfügung steht (KB 1011452)
- Der ESXi 4.0-Server antwortet manchmal nicht mehr, wenn der Hostarbeitsspeicher mehrfach zugeteilt ist
Der ESXi 4.0-Server antwortet manchmal nicht mehr, wenn der Hostarbeitsspeicher bei einer Nutzung von mehr als 200% überlastet und der Server als "Long Uptime Server" konfiguriert ist. Alle virtuellen Maschinen schlagen fehl, wenn der Server auf keine Aktionen mehr reagiert. Dieses Problem wurde in der vorliegenden Version behoben.
- Behebt ein Problem, wobei sich an manchen Maschinen die von CIM OMC_SMASHFirmwareIdentity gemeldete BIOS-Version von dmidecode unterscheidet
- Behebt ein Problem, wobei die DRAC den Namen des Betriebssystems über IPMI ermittelt und sowohl für ESX als auch für ESXi "VMware ESX Server" anzeigt
Dieser Fix ersetzt den fest einprogrammierten Namen durch VMware_HypervisorSoftwareIdentity.ElementName.
- Behebt ein Problem, wobei die für VMware_HypervisorSoftwareIdentity abgerufene Versionsinformation zur Erstellungszeit fest einprogrammiert ist
Falls CIM-Komponenten individuell gepatcht sind, stimmen die Build-Werte für diesen Anbieter möglicherweise mit der Build-Nummer oder Versionsinformation in anderen Komponenten oder Anwendungen nicht überein. Nach Anwendung dieses Fixes wird die Versionsinformation mithilfe eines gemeinsam genutzten Mechanismus abgerufen, der auch von anderen Komponenten im System verwendet wird.
- Neu:ESXi DCUI schlägt fehl, wenn der Test des Verwaltungsnetzwerks unterbrochen und dann neu gestartet wird
ESXi Direct Console User Interface (DCUI) schlägt fehl, wenn Sie den Test des Verwaltungsnetzwerks mit der ESC-Taste unterbrechen und dann den Test erneut starten. Dieses Problem wurde in der vorliegenden Version behoben.
Speicher
- Behebt ein Problem, wobei der Dell MegaRAID SAS1078R-Controller nicht als "PERC 6" identifiziert wird, weil die PCI-ID-Subsysteminformationen nicht ordnungsgemäß behandelt werden
- ESX Server antwortet möglicherweise nicht, wenn ein NFS-Volume offline genommen wird
Wenn ein gemountetes NFS-Volume in einem ESX Server-Cluster offline genommen wird, könnte dies dazu führen, dass der Heap vergrößert wird und der ESX Server nicht mehr antwortet.
- Neu:Anwendungen schlagen möglicherweise fehl und zeigen bei einem LUN-Reset einen E/A-Fehler an
Bei einem LUN- oder SCSI-Bus-Reset auf einem RHEL 5-Gastbetriebssystem schlagen möglicherweise die Anwendungen in der virtuellen Maschine aufgrund eines E/A-Fehlers fehl. Dieses Problem tritt nur dann auf, wenn Sie den PVSCSI-Adapter und den ESX iSCSI-Initiator verwenden. Dieses Problem wurde in der vorliegenden Version behoben.
- Der Proxydateipfadzugriff auf einem gemeinsam genutzten SMB/CIFS-Speicher schlägt fehl
Das Starten einer virtuellen Maschine von einem CD-ROM aus schlägt fehl, wenn sich die ISO-Datei auf einer mithilfe des SMB/CIFS-Protokolls gemounteten Freigabe befindet. Dieses Problem tritt auf, weil der Proxydateipfadzugriff verweigert wird, wenn das SMB/CIFS-Protokoll verwendet wird. Dieses Problem wurde in der vorliegenden Version behoben.
- Dieser Fix erhöht den Arbeitsspeicherheap für den HPSA-Treiber, damit er mehr als zwei Controller bedienen kann
- Neu:SCSI-Abbruchfehler beim Testen mehrerer virtueller Maschinen
Da der HP Smart Array-Treiber den SCSI-Abbruch nicht unterstützt, wird stattdessen ein Geräte-Reset ausgegeben. Die unmittelbare Ausführung des Resets kann die gleichzeitige E/A unterbrechen sowie zu mehr E/A-Ausfällen und SCSI-Abbruchfehlern führen.
Dieses Problem wurde in der vorliegenden Version dahin gehend behoben, dass das Zurücksetzen nach einer kurzen Verzögerung ausgeführt wird.
Unterstützte Hardware
- vCenter gibt einen Fehler aus, wenn die Konfigurationsoption "Power.CpuPolicy" in "Dynamisch" geändert wird
Wenn die Option Power.CpuPolicyvon "Statisch" in "Dynamisch" geändert wird, gibt vCenter die folgende Fehlermeldung aus:
Der eingegebene Wert ist ungültig. Geben Sie einen anderen Wert ein.
Dieser Fehler tritt auf, weil ESX/ESXi 4.0 auch dann versucht, die CPU-Energieverwaltungsrichtlinie des Systems in "Dynamisch" zu ändern, wenn das BIOS Prozessorleistungszustände (P-Zustände) nicht ordnungsgemäß unterstützt.
Dieses Problem wurde in der vorliegenden Version behoben.
Upgrade und Installation
- Das Upgrade von ESX Server 3i 3.5 auf ESXi 4.0 schlägt in bestimmten Fällen fehlDieses Problem tritt nur bei Installationen auf Serial Attached SCSI-Festplatten (SAS-Festplatten) oder Fibre-Channel-Festplatten (FC-Festplatten) auf. Wenn Sie in solchen Fällen versuchen, einen auf einer SAS- oder FC-Festplatte installierten ESX Server 3i 3.5 zu Upgrade, tritt während des Upgrades folgender Fehler auf:
Nicht unterstütztes Startlaufwerk. Das Layout des Startgeräts auf dem Host unterstützt keine Aktualisierung
Beachten Sie, dass dieses nur eines von mehreren Problemen ist, die den oben genannten Fehler verursachen können.
Dieses Problem wurde in der vorliegenden Version behoben. Beachten Sie allerdings, dass ein In-Place-Upgrade von ESXi Installable auf einer Boot-LUN, die ebenfalls eine VMFS-Partition enthält, nicht möglich ist.
- Neu:Das Verwenden des Host Update Utility auf ESXi Installable schlägt mit folgendem Fehler fehl: Fehler: Nicht unterstützte Boot-Festplatte
Dieser Fehler kann auftretren, wenn für den Host eine große Menge an lokalem Speicher vorhanden ist. In solch einem Szenario schlägt ein Skript zur Vorabprüfung fehl, weil das Skript keine großen Ganzzahlen unterstützt. Allerdings ist eine solche Unterstützung erforderlich, wenn die Speichergröße einen bestimmten Punkt erreicht. Deshalb schlägt das Skript zur Vorabprüfung aufgrund einer Einschränkung des Skripts fehl und nicht aufgrund eines Fehlers bei der Upgrade-Unterstützung.
Der vollständige Fehler für dieses Problem lautet wie folgt:
FEHLER: Nicht unterstützte Boot-Festplatte
Das Layout des Startgeräts auf dem Host unterstützt keine Upgrades
Dieses Problem wurde in der vorliegenden Version behoben.
- Behebt ein Problem, wobei beim Installieren von VMware Tools die vorhandenen virtuellen Druckertreiber "TPOG" und "TPOGPS" überschrieben werden, wenn der .print-Server von ThinPrint installiert wird
Mit diesem Fix wird nach einem von .printerstellten Registrierungseintrag gesucht. Sofern dieser Registrierungseintrag erkannt wird, werden die mit VMware Tools mitgelieferten virtuellen Druckertreiber nicht installiert.
vCenter Server und vSphere-Client
- vSphere Client zeigt den richtigen Bezeichner für das FreeBSD-Betriebssystem nicht an
Der richtige Bezeichner für das FreeBSD-Betriebssystem wird auf der Registerkarte "Übersicht" im vSphere-Client nicht angezeigt. Dieses Problem wurde in der vorliegenden Version behoben.
Verwaltung von virtuellen Maschinen
- Neu:Das SLES 10-Gastbetriebssystem wird in vCenter fälschlicherweise als SLES 8/9 angegeben, wenn VMware Tools ausgeführt wird
Wenn ESX 4.0 von vCenter 4.0 verwaltet wird und VMware Tools ausgeführt wird, zeigt die Registerkarte "Übersicht" des vSphere-Clients das Suse Linux Enterprise 10-Gastbetriebssystem (32-Bit) als Suse Linux Enterprise 8/9 (32-Bit) und Suse Linux Enterprise 10 (64-Bit) als Suse Linux Enterprise 8/9 (64-Bit) an.
- Behebt ein Problem, wobei ESX möglicherweise fehlschlägt, wenn während einer Synchronisierung die Warteschlange mit einer übermäßig großen Anzahl von RPC-Meldungen gefüllt wird und somit für VMX kein Arbeitsspeicher mehr zur Verfügung steht
Mit diesem Fix wird die Anzahl der RPC-Meldungen, die sich während einer Synchronisierung in der Warteschlange befinden dürfen, auf 1 beschränkt.
- Neu:Die Daten der Netzwerkleistung werden nicht angezeigt, wenn der VMXNET3-Adapter verwendet wird
Das Fenster Netzwerk auf der Registerkarte Leistung einer virtuellen Maschine wird nicht angezeigt, wenn ein Gast einen Adapter der VMXNET Generation 3 verwendet. Wenn eine virtuelle Maschine über einen Mix aus virtuellen Adaptern verfügt, wird das Fenster Netzwerk für Adapter eines anderen Typs als VMXNET3 weiterhin angezeigt.
Dieses Problem wurde in der vorliegenden Version behoben.
- Behebt ein Problem, wobei der Status eines Taktsignals einer virtuellen Maschine nicht korrekt angezeigt wird
VMotion und Storage VMotion
- Der Fix für einen bereits erkannten VMotion-Fehler kann die Migration von virtuellen Maschinen, deren Video-RAM mehr als 30 MB beträgt, auf einen Host ohne den Fix verhindern
ESX/ESXi 4.0 Update 1 behebt den VMotion-Fehler, wie in KB 1011971 beschrieben. Wenn VMotion für die Migration einer virtuellen Maschine, deren Video-RAM mehr als 30 MB beträgt, auf einen ESX/ESXi 4.0 Update 1-Host verwendet wird, ist es jedoch möglich, dass Sie keine Migration zurück auf einen Host durchführen können, auf dem dieser Fix nicht implementiert wurde.
- Neu:Anwendungen wie z. B. MPlayer und MEncoder, die in einer virtuellen Maschine ausgeführt werden, schlagen mit einem Fehler des Typs "Unzulässige Instruktion" fehl
Eine Vielzahl von Anwendungen führen Supplemental Streaming SIMD Extension 3-Instruktionen (SSSE3-Instruktionen) aus, wie z. B. MPlayer und MEncoder.
Diese Anwendungen schlagen bei Ausführung in einer virtuellen Maschine nach einer VMotion-Migration oder dem Anhalten und Fortsetzen der virtuellen Maschine mit einem Fehler des Typs "Unzulässige Instruktion" fehl. In seltenen Fällen tritt dieser Fehler bei einer normalen Ausführung auf.
Dieses Problem wurde in der vorliegenden Version behoben.
- Neu:Bei Verwendung der VMotion-Funktion kommt es zu einem Fehlschlagen der Migration gefolgt von einem Systemausfall des Zielhosts
Wenn die Migration einer virtuellen Maschine mit VMotion aufgrund eines seltenen Fehlers bei der Fortsetzung fehlschlägt, behält die virtuelle Quellmaschine möglicherweise einen veralteten Auslagerungsstatus bei. Nachfolgende Migrationsversuche der virtuellen Quellmaschine können zu einem Systemausfall des Zielhosts führen.
Dieses Problem wurde in der vorliegenden Version behoben.
VMware High Availability und Fehlertoleranz
- Das Aktivieren von HA schlägt fehl, wenn der ESX/ESXi-Host keine DNS-Konnektivität hat
Wenn beim Aktivieren oder Konfigurieren von VMware HA der ESX/ESXi-Host keine DNS-Konnektivität hat und sich in der Datei /etc/hostskein Eintrag für den Kurznamen des Hosts befindet, kann das Aktivieren oder Konfigurieren von HA fehlschlagen. Dieses Problem wurde in der vorliegenden Version behoben.
- Beim Aktivieren der Fehlertoleranz wird die sekundäre virtuelle Maschine für ein paar Sekunden gestartet, bevor sie dann ausfällt, was dazu führt, dass die primäre virtuelle Maschine in den Status "Sekundäre VM erforderlich" versetzt wird
Wenn primäre und sekundäre virtuelle Maschinen für Fehlertoleranz auf Hosts mit gemischten Steppings von Intel Xeon 5400- oder 5200 Series-Prozessoren (CPUID Family 6, Model 23, Steppings 6 und 10) ausgeführt werden, wird die sekundäre virtuelle Maschine für ein paar Sekunden gestartet, bevor sie dann ausfällt. Dies führt dazu, dass die primäre virtuelle Maschine in den Status "Sekundäre VM erforderlich" versetzt 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:
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
Gastbetriebssystem
- Virtuelle Maschine unter Solaris 10 U4 reagiert nicht mehr während eines Upgrades der VMware Tools
Das Upgrade oder der Neustart der VMware Tools in einer virtuellen Maschine unter Solaris 10 U4 mit einem erweiterten vmxnet-Adapter kann möglicherweise dazu führen, dass das Gastbetriebssystem nicht mehr reagiert und die Installation nicht mehr fortgesetzt werden kann. Solaris 10 U5 und spätere Versionen sind von diesem Problem nicht betroffen.
Umgehung: Bevor Sie VMware Tools installieren oder Upgrade, sollten Sie vorübergehend die Konfiguration des erweiterten vmxnet-Adapters entfernen, indem Sie entweder dessen Autokonfigurationsdateien in /etc/
entfernen oder die virtuelle Hardware entfernen.
- Auf ESXi findet die Installation der VMware Tools keine PBMs für bestimmte Linux-Gastbetriebssysteme
Das Standard-Installationsprogramm für VMware Tools enthält "Prebuilt Modules" (PBMs) nur für bestimmte, unterstützte Linux-Gastbetriebssysteme.
Umgehung: Auf der VMware-Website können Sie ein alternatives ISO-Image mit Linux-Tools herunterladen. Es enthält VMware Tools sowohl für unterstützte als auch für verschiedene ältere und nicht unterstützte Linux-Gastbetriebssysteme. Alternativ können Sie mithilfe des Skripts install-vmware.pl
, das zusammen mit VMware Tools ausgeliefert wird, Kernel-Module für die nicht unterstützten Linux-Versionen kompilieren.
- 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.
- Mehrere DNS-Suffixe werden nach der Image-Anpassung der Linux-Distribution nicht ordnungsgemäß angewendet
DNS-Suffixe werden automatisch angehängt, wenn eine Linux-Distribution versucht, einen DNS-Domänennamen aufzulösen. Wenn mehr als ein DNS-Suffix angepasst wird, wird nur das letzte DNS-Suffix angewendet. Je nach Linux-Distribution werden nicht alle angepassten DNS-Suffixe auf der Benutzeroberfläche der Linux-Distribution angezeigt. Umgehung: Keine
- 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.
- Neu:Ein automatisches Upgrade der VMware Tools schlägt möglicherweise für eine virtuelle Maschine unter Red Hat Enterprise Linux 5.x fehl, die mittels Cold-Migration von ESX 3.0.3 nach ESX/ESXi 4.0 Update 1 migriert wurde
Ein automatisches Upgrade der VMware Tools schlägt möglicherweise fehl mit der Meldung Fehler beim Upgrade der VMware Tools, wenn die virtuelle Maschine unter Red Hat Enterprise Linux 5.x läuft und mittels Cold-Migration von einem ESX 3.0.3-Host nach einem ESX/ESXi 4.0 Update 1-Host migriert wurde.
Umgehung: Upgrade Sie VMware Tools auf dem ESX 4.0 Update 1-Host manuell.
- Neu:Wake-On-LAN funktioniert nicht mit der e1000 vNIC auf neueren Windows-Gastbetriebssystemen
Für ESX/ESXi-Hosts steht die Wake-On-LAN-Funktion (zum Einschalten eines Hosts über das Netzwerk) auf bestimmten Windows-Gastbetriebssystemen für die e1000 vNIC nicht zur Verfügung. Insbesondere gilt dies für Windows-Versionen von Vista aufwärts und für 64-Bit-Version.
Umgehung: Verwenden Sie einen vNIC-Typ, der Wake-On-LAN unterstützt, wie z. B. VMXNET3
- Bei Windows Vista- und Windows 7-Gastbetriebssystemen wird die Videoausgabe möglicherweise nicht korrekt angezeigt
Windows Media Player kann in einem Windows Vista- oder Windows 7-Gastbetriebssystem fälschlicherweise Video-Dateien anzeigen, wenn das Video skaliert wird.
Umgehung: Als Umgehung für dieses Problem können Sie eine der folgenden Aktionen ausführen:
- Spielen Sie das Video im Vollbildmodus ab (ALT + EINGABETASTE).
- Deaktivieren Sie Bei Größenänderung Video an Player anpassen.
- Das Windows 7-Betriebssystem mit Media Player 11 wird nicht unterstützt
Das Microsoft Windows 7-Gastbetriebssystem, das Windows Media Player 11 enthält, wird auf einer virtuellen Maschine nicht unterstützt. Wenn Sie versuchen, auf einer virtuellen Maschine, auf der das Microsoft Windows 7 Betriebssystem ausgeführt wird, den Media Player auszuführen und das entsprechende Fenster zu maximieren, schlägt die virtuelle Maschine möglicherweise fehl.
Internationalisierung
Lizenzierung
- Virtuelle Maschine mit Mehrweg-Unterstützung für Virtual SMP startet möglicherweise nicht und meldet sofort nach einem Lizenz-Upgrade des Hosts einen Lizenzfehler
Unmittelbar nach dem Upgrade der Lizenz für einen Host schaltet vCenter Server die virtuelle Maschine nicht ein. Wenn Sie beispielsweise von einer Edition, die 4 vCPU unterstützt, auf eine Edition Upgrade, die 8vCPU unterstützt, meldet vCenter Server einen Lizenzfehler, z. B.: Maschine hat 8 virtuelle CPUs, aber der Host unterstützt nur 4....
Umgehung: Warten Sie mindestens eine Minute, bevor Sie virtuelle Maschinen einschalten, damit das Lizenz-Upgrade wirksam wird. Wechseln Sie zum manuellen Initiieren der Lizenzänderung nach Home > Lizenzierung und klicken Sie auf Upgrade.
Sonstige Probleme
- Neu:Die Diagnosepartition wird erst bei einem Systemausfall initialisiert
Standardmäßig ist die Diagnosepartition (oder Dump-Partition) nicht initialisiert. Wenn Sie versuchen, die Informationen in der Diagnosepartition zu erfassen, beispielsweise durch Ausführung des Befehls vm-support, wird eine harmlose Fehlermeldung ausgegeben, die angibt, dass die Diagnosepartition nicht initialisiert wurde.
Umgehung: Keine. Dieses Problem hat keine Auswirkung auf die Verarbeitung des Befehls vm-support. Sie können diese Fehlermeldung bedenkenlos ignorieren.
- Das Beenden oder der Neustart des vCenter Server-Dienstes über das Windows Services Control MMC-Plug-In kann zu einer Fehlermeldung führen
Unter bestimmten Bedingungen dauert das Starten des vCenter Server-Dienstes möglicherweise länger als gewöhnlich. Das Beenden und der Neustart des vCenter Server-Dienstes über das Windows Services Control MMC-Plug-In kann zur folgenden Fehlermeldung führen: Dienst konnte nicht in angemessener Zeit reagieren
.
Diese Meldung bedeutet, dass die für das Herunterfahren oder Starten von vCenter Server erforderliche Zeit den standardmäßig konfigurierten, systemweiten Zeitüberschreitungswert zum Beenden und Starten von Diensten überschritten hat.
Umgehung: Upgrade Sie nach ein paar Minuten den Bildschirm für die Dienstesteuerung. Es sollte nun angezeigt werden, dass der Dienst ordnungsgemäß gestoppt und neu gestartet wurde.
- Hilfemenüelemente erscheinen inaktiv oder das Klicken auf andere Hilfe-Links führt zu einem Fehler
Hilfemenüelemente erscheinen inaktiv bei vSphere-Client-Installationen auf Maschinen mit Windows-Betriebssystemen, die nicht englisch, japanisch, deutsch oder chinesisch (vereinfacht) sind. Außerdem besteht das Problem, dass wenn Sie, um Hilfe zu erhalten, im vSphere-Client auf andere Links oder Schaltflächen klicken, folgende Fehlermeldung angezeigt wird: Fehlende Hilfedatei
Umgehung: Kopieren Sie den Inhalt des Online-Hilfe-Ordners des vSphere-Clients von
C:\Programme\VMware\Infrastructure\Virtual Infrastructure Client\Help\de\VIC40
nach
C:\Programme\VMware\Infrastructure\Virtual Infrastructure Client\Help\de
.
Stellen Sie sicher, dass nur der Inhalt des Online-Hilfe-Unterverzeichnisses des vSphere-Clients ( VIC40
) auf diese Ebene kopiert wird.
Sie können die Online-Hilfe für andere Produktkomponenten unter C:\Programme\VMware\Infrastructure\Virtual Infrastructure Client\Help\de
anzeigen, indem Sie auf die Datei index.html
im Unterverzeichnis für das jeweilige Hilfesystem doppelklicken. Wenn Sie beispielsweise das Hilfesystem für die DRS-Fehlerbehebung anzeigen möchten, doppelklicken Sie auf die Datei index.html
im Unterverzeichnis DSR40
. Welche Unterverzeichnisse für Online-Hilfe-Systeme anderer vSphere-Module an diesem Speicherort vorhanden sind, hängt davon ab, welche vSphere-Produkte Sie installiert haben.
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.
- Das Ändern einer VMkernel-Netzwerkkarte mithilfe von DHCPv6 von einer statischen DNS-Attribution in DHCP DNS aktualisiert die DNS-Namenserver nicht
Wenn Sie die Servicekonsole, die vSphere-CLI oder den vSphere-Client zum Ändern einer IPv6-VMkernel-Netzwerkkarte, die DHCPv6 verwendet, von einer statischen DNS-Attribution in DHCP DNS ändern, werden die DNS-Namenserver bis zur nächsten Verlängerung der DHCPv6-Lease nicht aktualisiert.
Umgehung: Deaktivieren und aktivieren Sie anschließend die VMkernel-Netzwerkkarte wieder manuell, um die neuen DNS-Namenserver abzurufen. Sie können dies bewerkstelligen, indem Sie die Option Restart Management Network in der Benutzerschnittstelle der direkten Konsole, der auf Tastatureingabe beschränkten Benutzerschnittstelle für ESXi, wählen. Wenn Sie nichts unternehmen, wird der DNS-Nameserver abgerufen, wenn die DHCPv6-Lease verlängert wird.
- 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.
- DPM kann keinen Host in den Standby-Modus versetzen, wenn die VMkernel VMotion-Netzwerkkarte Teil eines vDS und der Host für die Verwendung von Wake-On-LAN für das Remoteeinschalten konfiguriert ist
Wenn die VMkernel VMotion-Netzwerkkarte eines Hosts Teil eines vDS ist, ist die Netzwerkkarte nicht für die Unterstützung von Wake-On-LAN konfiguriert. Der Host wird demnach als nicht fähig betrachtet, einen Remoteeinschaltvorgang durchzuführen und DPM kann ihn nicht automatisch in den Standby-Modus versetzen, es sei denn, er ist für die Verwendung von IPMI oder iLO für den Remote-Einschaltvorgang konfiguriert. DPM wählt andere Hosts aus, die nach Möglichkeit in den Standby-Modus versetzt werden. Falls Sie versuchen, den Host manuell in den Standby-Modus zu versetzen, wird der Versuch fehlschlagen und das Dialogfeld Wechsel in den Standby-Modus gestoppt erscheint. Umgehung: Verwenden Sie statt Wake-On-LAN IPMI oder iLO, um Hosts einzuschalten, die eines dieser Protokolle unterstützen, indem Sie auf jedem Host die IPMI- oder iLO-Anmeldedaten konfigurieren. Wenn Sie Wake-On-LAN zum Einschalten von Hosts verwenden müssen, konfigurieren Sie die VMkernel VMotion-Schnittstelle auf einem vNetwork-Standard-Switch (vSwitch) anstatt auf einem vDS.
- 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
- Neu: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 nicht 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/<Gerätename>
- NAS-Datenspeicher geben den verfügbaren Speicherplatz falsch wieder
Wenn Sie den verfügbaren Speicherplatz für einen ESX/ESXi-Host mithilfe des Befehls df
(ESXi) oder vdf
(ESX) in der Host-Servicekonsole anzeigen lassen, handelt es sich bei dem gemeldeten Speicherplatz für ESX/ESXi-NAS-Datenspeicher um freien Speicherplatz und nicht um verfügbaren Speicherplatz. Der Speicherplatz von NFS-Volumes, der in der Spalte "Frei" angegeben wird, wenn Sie Speicher > Datenspeicher auf der Registerkarte Konfiguration des vSphere-Clients wählen, zeigt auch den freien Speicherplatz an, nicht den verfügbaren Speicherplatz. In beiden Fällen kann sich der freie von dem verfügbaren Speicherplatz unterscheiden. ESX-Dateisysteme unterscheiden nicht zwischen freien und verfügbaren Blöcken, sondern melden immer freie Blöcke für beide Blocktypen (genau genommen die Felder "f_bfree" und "f_bavail" der struct "statfs"). Freie und verfügbare Blöcke können sich bei NFS-Volumen unterscheiden.
Umgehung: Sie können korrekte Informationen hinsichtlich des verfügbaren Speicherplatzes von NFS-Servern abrufen. Für ESX/ESXi gibt es keine Umgehung.
- Harmlose Warnmeldungen zu Bereichskonflikten werden in den VMkernel-Protokollen für manche IBM-Server protokolliert
Wenn der SATA/IDE-Controller im PCI-Konfigurationsbereich im Legacy-PCI-Modus arbeitet, wird möglicherweise eine Fehlermeldung ähnlich der Folgenden zu den VMkernel-Protokollen hinzugefügt:
WARNUNG: vmklinux26: __request_region: Diese Meldung wurde einmal wiederholt: Region conflict @ 0x0 => 0x3
Umgehung: Solche Fehlermeldungen sind harmlos und können bedenkenlos ignoriert werden.
Unterstützte Hardware
- Es werden keine CIM-Alarme empfangen, wenn das Stromkabel und das Netzteil neu an HP-Server angeschlossen werden
Es werden keine neuen SEL(IML)-Einträge für das erneute Anschließen des Stromkabels und des Netzteils auf HP-Servern erstellt, wenn eine unterbrochene Stromversorgung wiederhergestellt wird. Dies führt dazu, dass keine CIM-Alarme für diese Ereignisse generiert werden. Umgehung: Keine
- ESX/ESXi auf der HP G6-Plattform mit P410i oder P410 Smart Array-Controller läuft während des Einschaltens der virtuellen Maschinen oder bei Festplatten-E/A-Vorgängen langsam
Einige dieser Hosts laufen möglicherweise beim Einschalten von virtuellen Maschinen oder bei Festplatten-E/A-Vorgängen langsam. Die Hauptsymptom ist eine herabgestufte E/A-Leistung, wodurch viele Fehlermeldungen ähnlich der Folgenden in /var/log/messages
protokolliert werden. Mar 25 17:39:25 vmkernel: 0:00:08:47.438 cpu1:4097)scsi_cmd_alloc returned NULL!
Mar 25 17:39:25 vmkernel: 0:00:08:47.438 cpu1:4097)scsi_cmd_alloc returned NULL!
Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)NMP: nmp_CompleteCommandForPath: Command 0x28 (0x410005060600) to NMP device
"naa.600508b1001030304643453441300100" failed on physical path "vmhba0:C0:T0:L1" H:0x1 D:0x0 P:0x0 Possible sense data: 0x
Mar 25 17:39:26 0 0x0 0x0.
Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)WARNUNG: 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.
- Einige Dell-BIOS-Systeme weisen möglicherweise doppelte Interrupt-Routing-Einträge in der ACPI-Tabelle auf (KB 1013804)
- Auf bestimmten Versionen des vSphere-Clients wird der Status des Akkus möglicherweise falsch als alarmierend angezeigt
Wenn sich der Akku im Lernmodus befindet, wird im vSphere-Client auf der Registerkarte "Hardwarestatus" eine Alarmmeldung angezeigt, die angibt, dass der Status des Akkus nicht in Ordnung ist. Allerdings ist der Ladezustand des Akkus in Ordnung.
Umgehung: Keine.
- Die Meldung "Detected Tx Hang" wird in der VMkernel-Protokolldatei angezeigt
Einige Varianten der e1000-Netzwerkkarten blockieren aufgrund von Hardwarefehlern unter Volllast. ESX/ESXi erkennt das Problem und setzt die Karte automatisch zurück. Dieses Problem steht im Zusammenhang mit Tx-Paketen, TCP-Arbeitslasten und TCP Segmentation Offloading (TSO).
Umgehung: Sie können TSO deaktivieren, indem Sie in der Datei esx.confdie Option /adv/Net/UseHwTSOauf 0 setzen.
- Ereignismeldungen von StoreLib von IR-Karten haben einen fehlerhaften Zeitstempel
"IndicationTime" in den Ereignismeldungen von StoreLib zeigt einen fehlerhaften Zeitstempel für LSI 1078 und 1068E Integrated RAID (IR)-Controller an.
Upgrade und Installation
- Die Installation des vSphere-Clients schlägt möglicherweise mit dem Fehler 1603fehl, wenn Sie nicht über eine aktive Internetverbindung verfügen
Sie können den vSphere-Client auf zwei Arten installieren: Vom vCenter Server-Medium aus oder indem Sie auf einen Link im ESX-, ESXi- oder vCenter Server-Begrüßungsbildschirm klicken. Das Installationsprogramm auf dem vCenter Server-Medium (.iso-Datei oder .zip-Datei) enthält zusätzlich zum vSphere-Client-Installationsprogramm ein vollständiges .NET-Installationsprogramm. Das Installationsprogramm, das über den Begrüßungsbildschirm aufgerufen wird, enthält ein vSphere-Client-Installationsprogramm, das die .NET-Installationsprogrammkomponenten aus dem Internet abruft. Wenn Sie über keine Internetverbindung verfügen, schlägt die zweite vSphere-Client-Installationsmethode mit dem Fehler 1603fehl, es sei denn, .NET 3.0 SP1 ist bereits auf Ihrem System installiert.
Umgehung: Richten Sie eine Internetverbindung ein, bevor Sie den Download versuchen, installieren Sie den vSphere-Client vom vCenter Server-Medium aus oder installieren Sie .NET 3.0 SP1, bevor Sie auf den Link auf dem Begrüßungsbildschirm klicken.
- 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
- 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: Setup konnte das vCenter-Repository nicht erstellen
Umgehung: Schalten Sie auf dem System, auf dem vCenter Server installiert wird, unter Systemsteuerung > Benutzerkonten die Option "Benutzerkontensteuerung" aus, bevor Sie vCenter Server installieren. Geben Sie während der vCenter Server-Installation den Nicht-Systembenutzer an.
- Keine Anmeldung bei VirtualCenter Server 2.5 möglich, nachdem der VI Client 2.0.x, 2.5 und vSphere Client 4.0 auf einem Windows Vista-System installiert wurden und der VI Client 2.0.x deinstalliert wurde
Nach dem Deinstallieren des VI Client 2.0.x auf einer Windows Vista-Maschine, auf der VI Client 2.0.x und 2.5 sowie vSphere Client 4.0 gleichzeitig vorhanden sind, ist keine Anmeldung bei vCenter Server 2.5 möglich. Die Anmeldung schlägt mit folgender Meldung fehl: Klasse nicht registriert (Ausnahme von HRESULT:0x80040154(REGDB_E_CLASSNOTREG))
Umgehung: Deaktivieren Sie die Benutzerkontensteuerung auf dem System, auf dem VI Client 2.0.x, 2.5 und vSphere Client 4.0 zusammen installiert sind, oder deinstallieren Sie den VI Client 2.5 und installieren Sie ihn neu.
- Das ESX/ESXi-Installationsprogramm führt die lokalen SAS-Speichergeräte im Abschnitt "Remotespeicher" auf
Beim Anzeigen der Speicherorte, in denen ESX oder ESXi Installable installiert wird, führt das Installationsprogramm im Abschnitt "Remotespeicher" ein lokales SAS-Speichergerät auf. Dies liegt daran, dass ESX/ESXi nicht feststellen kann, ob das SAS-Speichergerät lokal oder remote ist. Es wird deshalb immer als remote angesehen. Umgehung: Keine
- Wenn vSphere Host Update Utility die Netzwerkverbindung zum ESX-Host verliert, funktioniert das Host-Upgrade möglicherweise nicht
Wenn Sie zum Durchführen eines ESX/ESXi-Host-Upgrades das vSphere Host Update Utility verwenden und die Verbindung des Dienstprogramms mit dem Host unterbrochen wird, wird der Host möglicherweise nicht vollständig aktualisiert. Wenn dies geschieht, reagiert das Dienstprogramm möglicherweise nicht mehr oder die folgende Fehlermeldung wird ausgegeben: Fehler beim Ausführen der Kompatibilitätsprüfung auf dem Host.
Umgehung: Schließen Sie das Dienstprogramm, reparieren Sie die Netzwerkverbindung, starten Sie das Dienstprogramm neu und führen Sie das Upgrade erneut aus.
- Wenn auf demselben System vSphere Client 4.0 und VI Client 2.5 installiert werden, wird abhängig von der Reihenfolge, in der Sie die Anwendungen deinstallieren, die Desktopverknüpfung nicht aktualisiert
Wenn Sie die vSphere Client 4.0-Anwendung auf einem System installieren, auf dem sich eine Instanz der VI Client 2.5-Anwendung befindet, erscheinen nur die vSphere Client 4.0-Desktopverknüpfungen auf dem Desktop. Über diese Verknüpfung können Sie beide Anwendungen starten. Wenn Sie die vSphere Client 4.0-Anwendung deinstallieren, die VI Client 2.5-Anwendung jedoch nicht deinstallieren, verbleibt die vSphere Client 4.0-Desktopverknüpfung auf dem System. Sie können die Verknüpfung nach wie vor benutzen, um sich beim VI Client 2.5 anzumelden, aber wenn Sie versuchen, sich beim vSphere Client 4.0 anzumelden, werden Sie aufgefordert, die Anwendung herunterzuladen.
Umgehung: Führen Sie einen der folgenden Schritte aus:
- Wenn Sie nur die vSphere Client 4.0-Anwendung deinstallieren, benennen Sie die Desktopverknüpfung um oder installieren Sie die VI Client 2.5-Anwendung neu, sodass der Link den installierten Client korrekt widerspiegelt.
- Sofern Sie beide Anwendungen deinstallieren, entfernen Sie alle nicht funktionierenden Verknüpfungen.
- Der Wert für die nächste Ausführung einiger geplanter Aufgaben wird nach einem Upgrade von VirtualCenter 2.0.2.x auf vCenter Server 4.0 nicht beibehalten
Wenn Sie VirtualCenter 2.0.2.x auf vCenter Server 4.0 Upgrade, wird für einige geplante Aufgaben der Wert für die Nächste Ausführung
möglicherweise nicht beibehalten und die Aufgaben werden möglicherweise unerwartet ausgeführt. Wenn z. B. eine Aufgabe so geplant ist, dass sie jeden Tag um 10 Uhr ausgeführt wird, wird sie nach dem Upgrade möglicherweise um 11.30 Uhr ausgeführt. Dieses Problem tritt auf, weil es Unterschiede zwischen den Methoden gibt, die VirtualCenter 2.0.2.x und vCenter Server 4.0 verwenden, um den Zeitpunkt der nächsten Ausführung zu berechnen. Dieses Verhalten ist nur unter den folgenden Bedingungen sichtbar:
- Sie haben geplante Aufgaben, deren Zeitpunkte für die nächste Ausführung Sie geändert haben, nachdem sie ursprünglich geplant wurden. Sie weisen jetzt einen anderen Zeitpunkt für die
Nächste Ausführung
auf.
- Der neu geplante Zeitpunkt für die
Nächste Ausführung
ist noch nicht eingetreten.
Umgehung: Führen Sie die folgenden Schritte aus:
- Warten Sie vor dem Upgrade, bis die Aufgaben zum Zeitpunkt ihrer
Nächsten Ausführung
ausgeführt werden.
- Nach dem Upgrade von vCenter 2.0.x auf vCenter Server 4.0 bearbeiten und speichern Sie die geplante Aufgabe. Dieser Vorgang berechnet den Zeitpunkt der
Nächsten Ausführung
auf den korrekten Wert neu.
- Während eines Upgrades werden Standardalarme, die erst in vCenter Server 4.0 eingeführt wurden, nicht zum System hinzugefügt
Während eines Upgrades auf vCenter Server 4.0 werden die Standardalarme, die erst in vCenter Server 4.0 eingeführt wurden, nicht zum System hinzugefügt. Nachfolgende Standardalarme fehlen: HostConnectionStateAlarm
VmFaultToleranceLatencyStatusAlarm
HostEsxCosSwapAlarm
VmDiskLatencyAlarm
DatastoreDiskUsageAlarm
LicenseNonComplianceAlarm
VmTimedoutStartingSecondaryAlarm
VmNoCompatibleHostForSecondaryAlarm
HostErrorAlarm
VmErrorAlarm
HostConnectivityAlarm
NetworkConnectivityAlarm
StorageConnectivityAlarm
MigrationErrorAlarm
ExitStandbyErrorAlarm
VmHighAvailabilityError
HighAvailabilityError
LicenseError
HealthStatusChangedAlarm
VmFaultToleranceStateChangedAlarm
Umgehung: Weitere Informationen über ein Skript, das die neuen Standardalarme zum System hinzufügt, finden Sie im VMware Knowledgebase-Artikel 1010399.
- Upgrades der Hardware der virtuellen Maschine von Version 4 auf Version 7 führen dazu, dass die Netzwerkeinstellungen von Solaris-Gastbetriebssystemen verloren gehen
Upgrades der Hardware der virtuellen Maschine von Version 4 auf Version 7 ändern die Adresse des PCI-Bus der virtuellen Netzwerkadapter in Gastbetriebssystemen. Solaris erkennt die Adapter nicht und ändert die Nummerierung der Netzwerkschnittstellen (Beispielsweise wird e1000g0 zu e1000g1). Diese Änderung an der Nummerierung tritt ein, weil Solaris-IP-Einstellungen Schnittstellenamen zugeordnet sind, sodass es so aussieht, als ob die Netzwerkeinstellungen verloren gegangen sind und das Gastbetriebssystem nicht über eine ordnungsgemäße Konnektivität verfügt. Umgehung: Verwenden Sie den Befehl prtconf -D
, um nach dem Upgrade der Hardware der virtuellen Maschine die neuen Schnittstellennamen zu ermitteln, und benennen Sie anschließend alle alten Konfigurationsdateien mit deren neuen Namen um. e1000g0 wird beispielsweise e1000g1, sodass jede /etc/*e1000g0
-Datei in das /etc/*e1000g1
-Äquivalent umbenannt wird.
- Das vCenter Server-Installationsprogramm erkennt keine Service-Ports, wenn die Services nicht ausgeführt werden
Wenn Sie vCenter Server installieren und die Standardports übernehmen, kann das Installationsprogramm die Ports nicht validieren, wenn sie von nicht ausgeführten Services verwendet werden. Die Installation schlägt fehl und je nach verwendetem Port wird möglicherweise eine Fehlermeldung ausgegeben. Dieses Problem betrifft keine IIS-Dienste. IIS-Dienste werden immer korrekt validiert, ob die Services ausgeführt werden oder nicht.
Umgehung: Identifizieren Sie die Ports, die für nicht ausgeführte Services verwendet werden, bevor Sie mit der Installation beginnen, und vermeiden Sie sie.
- Aktualisiert: 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.
- 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 vihostupdatedurchfü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/scratchfestgelegt 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 ( /<vmfs-volume-path>), 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.plauf, 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 <ServerIPAdressePlatzhalter> --username root --password <KennwortPlatzhalter> --bundle <URLPlatzhalter>.zip --install
- 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.
- Wenn ESXi 3.5 auf ESXi 4.0 Update 1 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 1 installiert. Nach dem Upgrade zeigt der Befehl esxupdate queryjedoch keine Bulletins an.
Umgehung: Dieses Problem hat keine Auswirkung auf die Kernfunktionalität des Hosts. Das Problem kann nicht umgangen werden.
- Der WS-Management-Dienst wird nicht automatisch auf einem Host gestartet, der von ESXi 3.5.x auf ESXi 4.0 Update 1 aktualisiert wurde
Dieses Upgrade kann dazu führen, dass der WS-Management-Dienst (wsman) nicht automatisch gestartet wird, was durch die Ausführung des folgenden wsman-Statusbefehls überprüft werden kann:
/etc/init.d/wsman status
Umgehung:
- Starten Sie den wsman-Dienst im Tech Support-Modus.
Weitere Informationen zur Verwendung des Tech Support-Modus finden Sie unter KB 1003677. Sie können den Dienst wie folgt starten: /etc/init.d/wsman start
- Überprüfen Sie den Status des wsman-Dienstes, um sicherzustellen, dass er ausgeführt wird.
Beispiel: /etc/init.d/wsman status
- Benennen Sie in der Datei /etc/chkconfig.dbden Eintrag für den WS-Management-Dienst von wsmandin wsmanum, damit die Änderung beim Neustart erhalten bleibt.
Nachfolgend finden Sie ein Beispiel für den vollständigen Pfad der Datei: /etc/init.d/wsman
vCenter Server und vSphere-Client
- Guided Consolidation kann keine Systeme importieren, auf denen vCenter Converter ausgeführt wird
Bei den Importvorgängen von Guided Consolidation tritt ein Problem auf, wenn auf dem Quellsystem (d. h. auf dem importierten System) vCenter Converter ausgeführt wird. Guided Consolidation importiert das System und versucht, vCenter Converter von dem Quellsystem zu deinstallieren. Der Importvorgang gelingt, aber die folgende Fehlermeldung wird angezeigt, wenn Guided Consolidation versucht, vCenter Converter zu deinstallieren: VMware Converter-Agent-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
- Wenn Sie im vSphere-Client auf der Registerkarte "Erste Schritte" für bestimmte Objekte (Cluster, Host, virtuelle Maschine) auf die Schaltfläche "Registerkarte schließen [x]" klicken, geschieht nichts
Wenn Sie im vSphere-Client auf der Registerkarte Erste Schritte für bestimmte Objekte (Cluster, Host, virtuelle Maschine) auf die Schaltfläche Registerkarte schließen [x] klicken, geschieht nichts. Dieses Problem tritt nur dann auf, wenn der vSphere Client auf einer Maschine läuft, in deren Betriebssystem Javascript deaktiviert ist. Umgehung: Keine
- Die Leistungsdiagramme werden nicht im Überblick angezeigt, wenn der vCenter Server eine Oracle-Datenbank verwendet
Leistungsdiagramme werden über die Ansicht "Überblick" auf der Registerkarte Leistung angezeigt. Falls Ihr vCenter Server eine Oracle-Datenbank verwendet, erscheinen die Diagramme nicht, wenn Sie diese Ansicht öffnen. Stattdessen wird folgende Fehlermeldung angezeigt: Interner Fehler bei STATs-Berichtsdienst:
Initialisierung der STATs-Berichtsanwendung konnte nicht erfolgreich abgeschlossen werden.
Dieser Fehler tritt auf, weil aufgrund von Lizenzbeschränkungen VMware eine Platzhalterdatei anstatt der ojdbc5.jar
-Datei von Oracle mit den Überblicksleistungsdiagrammen ausführt.
Umgehung: Führen Sie die folgende Aufgabe zum Überschreiben der Platzhalterdatei ojdbc5.jar
von Oracle mit der tatsächlichen Datei durch.
- Laden Sie die Datei
ojdbc5.jar
von der Website "Oracle Technology Network" herunter.
- Tauschen Sie die VMware-Platzhalterdatei durch die heruntergeladene
ojdbc5.jar
-Datei aus. Standardmäßig befindet sich diese Datei im Verzeichnis C:\Programme\VMware\Infrastructure\tomcat\lib
.
- Starten Sie den vCenter Server-Webservice neu.
- Alarme mit den Systemzustand betreffenden Auslösebedingungen werden nicht nach vSphere 4.0 migriert
Die Alarmauslösefunktionalität von vSphere 4.0 wurde erweitert. Sie enthält zusätzliche Alarmauslöser für den Systemzustand des Hosts. Dabei wurde der generische Auslöser "Host-Zustand" entfernt. Daher stehen Alarme, die diesen Auslöser enthalten, in vSphere 4.0 nicht mehr zur Verfügung. Umgehung: Verwenden Sie den vSphere-Client, um die Alarme erneut zu erstellen. Sie können die folgenden vorkonfigurierten VMware-Alarme verwenden, um den Systemzustand des Hosts zu überwachen:
- Batteriestatus des Hosts
- Lüftungsstatus der Hosthardware
- Betriebsstatus der Hosthardware
- Temperaturstatus der Hosthardware
- Status der Hauptplatine der Hosthardware
- Spannung der Hosthardware
- Arbeitsspeicherstatus des Hosts
- Prozessorstatus des Hosts
- Speicherstatus des Hosts
Falls sich der Status, den Sie überwachen möchten, nicht unter den vorkonfigurierten Alarmen befindet, können Sie einen benutzerdefinierten Alarm erstellen, der den Ereignisauslöser "Hardwarestatus geändert" verwendet. Für diesen Ereignisalarm müssen Sie die Auslösebedingungen manuell festlegen. Darüber hinaus müssen Sie manuell einstellen, welche Aktion durchgeführt werden soll, wenn der Alarm ausgelöst wird.
Hinweis: Für die vorkonfigurierten Alarme wurden bereits Standardauslösebedingungen festgelegt. Sie brauchen nur noch einzustellen, welche Aktion bei Alarmauslösung durchgeführt werden soll.
- Virtuelle Maschinen verschwinden aus dem Diagramm der virtuellen Switches in der Netzwerkansicht für die Hostkonfiguration
Virtuelle Maschinen werden in der Netzwerkansicht auf der Registerkarte "Konfiguration" des vSphere-Clients für einen Host im Diagramm der virtuellen Switches dargestellt. Wenn Sie einen anderen Host auswählen und dann zur Registerkarte "Konfiguration" des ersten Hosts zurückkehren, verschwinden die virtuellen Maschinen möglicherweise aus dem Diagramm der virtuellen Switches. Umgehung: Wählen Sie auf der Registerkarte "Konfiguration" eine andere Ansicht, z. B. Netzwerkadapter, Speicher oder Speicheradapter, und kehren Sie zur Registerkarte "Netzwerk" zurück.
- 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: 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: Interner Fehler bei STATs-Berichtsdienst
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
- 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: Geben Sie in eine Eingabeaufforderung des Systems Folgendes ein, um den Befehl vc-support.wsf
mit der 32-Bit-DSN-Anwendung cscript.exe
auszuführen:
%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 "Benutzerkonten" 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 ändernund 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 "Benutzerkonten" 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.
- Der vCenter Server-Ressourcen-Manager aktualisiert den Hostbaum in einem Cluster nicht, bei dem weder DRS noch HA aktiviert ist
Wenn Sie VMotion zum Einschalten oder Migrieren einer virtuellen Maschine auf Clustern verwenden, bei denen weder HA noch DRS aktiviert ist, schlägt der Vorgang möglicherweise fehl mit folgender Fehlermeldung:
-
Der Host verfügt für die Reservierung nicht über ausreichende Arbeitsspeicherressourcen.
-
Der Host verfügt für die Reservierung nicht über ausreichende CPU-Ressourcen.
Dieses Problem tritt auch dann auf, wenn es scheint, als habe der Host genügend Kapazitäten frei, und nur dann, wenn sich beide Hosts in demselben Cluster befinden.
Wenn VMotion verwendet wird, um eine virtuelle Maschine auf einen Host zu migrieren oder sie unter dem neuen Host einzuschalten, schätzt vCenter Server ab, ob der Host über genügend nicht reservierten Ressourcen verfügt, um den Anforderungen der virtuellen Maschine gerecht zu werden. Die internen Datenstrukturen, die für diese Einschätzung verwendet werden, werden jedoch nicht aktualisiert, wenn Sie VMotion in einem Cluster zum Migrieren einer virtuelle Maschine von einem Quell- auf einen Zielhost verwenden, nachdem Sie die virtuelle Maschine auf dem Quellhost eingeschaltet haben. Alle künftigen Zugangssteuerungsberechnungen für den Quellhost berücksichtigen die Reservierung dieser virtuellen Maschine, obwohl er nicht mehr auf dem Host ausgeführt wird. Dieses Verhalten führt möglicherweise dazu, dass Einschalt- und VMotion-Vorgänge, die den Quellhost als Ziel haben, fehlschlagen.
Hinweis: Diese Fehler werden in der Protokolldatei wie folgt gemeldet:
-
vim.fault.InsufficientHostCpuCapacityFault
-
vim.fault.InsufficientHostMemoryCpuCapacityFault
Umgehung: Konfigurieren Sie die Reservierung der virtuellen Maschine neu oder schalten Sie die Maschine ein bzw. aus. Diese Aktionen zwingen vCenter Server dazu, seine interne Datenstrukturen zu Upgrade.
- 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 den Konfigurationsassistenten für den verknüpften Modus ausführen, nachdem Sie in einer reinen IPv6-Umgebung ein vCenter Server-System mit einer Gruppe verknüpft haben, gibt es keine Option, um das vCenter Server-System aus dem verknüpften Modus zu isolieren
Wenn vCenter Server in einer reinen IPv6-Umgebung (Windows 2008 x32 oder Windows 2008 x64) verknüpft ist und Sie den Konfigurationsassistenten für den verknüpften Modus aufrufen, ist die Option vCenter Server-Instanz einer vorhandenen Gruppe für den verknüpften Modus oder einer anderen Instanz hinzufügen aktiviert. Es gibt keine Option, um das vCenter Server-System aus dem verknüpften Modus zu isolieren. Umgehung: Konfigurieren Sie das vCenter Server-System im gemischten Modus (IPv4 und IPv6) und rufen Sie den Konfigurationsassistenten für den verknüpften Modus auf: Start > VMware > Konfiguration für den verknüpften Modus. Die Option Beitreten ist deaktiviert und die Option Diese vCenter Server-Instanz von der Gruppe für den verknüpften Modus isolieren ist aktiviert.
Hinweis: Wenn Sie ein vCenter Server-System im gemischten Modus konfigurieren, muss der Domänencontroller auch im gemischten Modus arbeiten. Falls Sie den gemischten Modus nicht in Ihrer IPv6-Umgebung verwenden möchten, müssen Sie vCenter Server deinstallieren, um das System aus dem verknüpften Modus zu isolieren.
- Wenn Sie bei großen vCenter Server-Bestandslisten den vSphere-Client im verknüpften Modus öffnen und dabei die Bestandslisten aller vCenter Server-Systeme vollständig erweitert sind, reagiert der vSphere-Client möglicherweise für einige Minuten nicht
vSphere-Client-Bestandslisten sind dann vollständig erweitert, wenn Cluster und Datencenter erweitert sind. Wenn Sie den vSphere-Client schließen, nachdem die Bestandslisten erweitert wurden, wird die erwartete Bestandslistenansicht beim nächsten Öffnen des Clients geladen. Als Folge davon reagiert der vSphere-Client möglicherweise für einige Minuten nicht mehr, abhängig von der Anzahl der vCenter Server-Systeme und der Anzahl der Objekte in den Bestandslisten der jeweiligen vCenter Server-Systeme. Der vSphere-Client reagiert wird, nachdem alle Bestandslistenobjekte geladen wurden. Umgehung: Es wird empfohlen, bei einer Gruppe im verknüpften Modus nicht die Knoten aller vCenter Server-Systeme in der Bestandsliste zu erweitern. Reduzieren Sie die Knoten, bevor Sie den vSphere-Client schließen, um das Laden der erweiterten Knoten beim Start zu vermeiden.
- vCenter Server schlägt möglicherweise fehl, wenn die Berechtigungen für das vpxuser-Konto geändert werden
Wenn Sie einen vSphere-Client direkt mit einem ESX/ESXi-Host verbinden und die Registerkarte Berechtigungen auswählen, ist es möglich, die Berechtigungen für das vpxuser-Konto zu ändern. Es wäre beispielsweise sinnvoll, die Berechtigungen zu ändern, sodass vpxuser nicht über Administratorrechte für alle Hostbestandslistenobjekte verfügt. vCenter Server schlägt jedoch nach einer solchen Änderung möglicherweise fehl. Umgehung: Legen Sie das vpxuser-Konto auf dem Host so fest, dass es über Administratorrechte ab dem Root-Ordner abwärts verfügt. Sie können dies tun, indem Sie einen vSphere-Client mit dem Host verbinden und anschließend die Registerkarte Berechtigungen auswählen.
- 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
- Neu: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, unterstützen Wake-On-LAN. 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.
- Neu:Das Erstellen einer neuen SCSI-Festplatte in einer virtuellen Maschine kann dazu führen, dass eine ungenaue Fehlermeldung ausgegeben wird
Wenn Sie eine neue SCSI-Festplatte in einer virtuellen Maschine erstellen und den SCSI-Bus auf virtual setzen, wird folgende Fehlermeldung ausgegeben:
Stellen Sie sicher, dass die virtuelle Festplatte unter Verwendung der Option "Thick" erstellt wurde.
Allerdings ist Thickallein keine gültige Option. Die korrekte Option lautet eagerzeroedthick.
Umgehung: Erstellen Sie die SCSI-Festplatte mit dem Befehlszeilenbefehl vmkfstoolsund der Option eagerzeroedthick.
- Die Optionen für den Installationsstartvorgang einer virtuellen Maschine werden nicht nach OVF exportiert
Wenn Sie auf einer virtuellen Maschine, auf der die Option "Installationsstartvorgang" aktiviert ist, ein OVF-Paket erstellen, wird diese Option während des Exports ignoriert. Daher fehlt im OVF-Deskriptor das Element InstallSection
, das Informationen zum Installationsvorgang liefert. Wenn Sie ein OVF-Paket bereitstellen, wird das Element InstallSection
ordnungsgemäß analysiert. Umgehung: Nachdem die virtuelle Maschine nach OVF exportiert wurde, erstellen Sie die InstallSection
-Parameter manuell im OVF-Deskriptor. Ist eine Manifestdatei ( .mf
) vorhanden, müssen Sie sie im Anschluss an die Änderung des OVF-Deskriptors erneut generieren.
Beispiel: <InstallSection ovf:initialBootStopDelay="300"> <Info>Legt fest, dass ein Installationsstartvorgang notwendig ist.</Info> </InstallSection>
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
die Startverzögerung fest.
Einzelheiten hierzu finden Sie in der OVF-Spezifikation.
- Eine von einem Snapshot einer virtuellen Maschine mit einem LSI SAS-Controller geklonte virtuelle Maschine wird evtl. fälschlicherweise mit einem BusLogic-Controller konfiguriert
Wenn Sie einen Snapshot einer virtuellen Maschine mit einem LSI SAS-Controller erstellen und anschließend von dem Snapshot eine virtuelle Maschine klonen, wird für die von dem Snapshot geklonte virtuelle Maschine möglicherweise ein BusLogic- statt eines LSI SAS-Controllers in den VM-Eigenschaften konfiguriert. Umgehung: Überprüfen Sie in der Eigenschaft "Snapshot.config" den Controllertyp der virtuellen Maschine, die Sie anhand eines Snapshots einer virtuellen Maschine, die über einen LSI SAS-Controller verfügt, geklont haben. Konfigurieren Sie nach Bedarf den Controllertyp für die geklonte virtuelle Maschine.
- Neu:Nach dem Anhalten und Fortsetzen einer virtuellen Maschine kann das Deaktivieren des VMXNET3-Adapters fehlschlagen
Wenn die Netzwerkverbindung zwischen dem Anhalten und Fortsetzen in einen nicht definierten Zustand wechselt, beispielsweise wenn der Name der Portgruppe geändert wird, kann das virtuelle Netzwerkgerät die neue Netzwerkverbindung mit dem Treiber nicht Upgrade. Dieser Zustand verhindert, dass der VMXNET3-Adapter deaktiviert, deinstalliert oder aktualisiert werden kann.
Umgehung: Verbinden Sie den Adapter neu mit einer gültigen Portgruppe.
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.
- Das Konvertieren einer virtuellen Festplatte von "Thick" nach "Thin" unter Verwendung von Storage VMotion schlägt fehl
Beim Migrieren von virtuellen Maschinen, die mit dem VMFS-Maximalgrenzwert für Dateisysteme konfiguriert sind, wird folgende Fehlermeldung ausgegeben: Datei[vol] <VM-Pfad> ist größer als die vom Datenspeicher <Zieldatenspeicher>
unterstützte maximale Größe.
Umgehung: Keine. Konfigurieren Sie eine VM-Festplatte nicht auf ihr maximales Volume-Limit, wenn Sie vorhaben, die virtuelle Maschine zu migrieren.
- Auf einer lokalen Datenspeicher gespeicherte virtuelle Maschinen werden nicht vom Host migriert, wenn sich der Host im Wartungsmodus befindet
Auf einer lokalen Datenspeicher gespeicherte virtuelle Maschinen werden nicht vom Host migriert, wenn sich der Host im Wartungsmodus befindet. Umgehung: Verschieben Sie die virtuellen Maschinen auf lokalen Datenspeichern manuell auf einen anderen Host, falls sie weiterhin zur Verfügung stehen müssen, während sich der aktuell Host im Wartungsmodus befindet.
VMware High Availability und Fehlertoleranz
- Failover auf sekundäre virtuelle VMware FT-Maschine führt zu Fehlermeldung auf dem Host-Client
Wenn VMware-Fehlertoleranz ein Failover auf eine sekundäre virtuelle Maschine durchführt und der für die sekundäre virtuelle Maschine ausgewählte Host erst kürzlich neu gestartet wurde, betrachtet der Host-Client diesen Versuch als Fehlschlag und zeigt folgende Fehlermeldung an: Anmeldung fehlgeschlagen wegen eines ungültigen Benutzernamens oder Kennworts
.
Diese Fehlermeldung wird angezeigt, weil der Host kürzlich neu gestartet wurde und es möglich ist, dass er noch keinen SSL-Fingerabdruck von vCenter Server empfangen hat. Nachdem der Fingerabdruck an den Host gesendet wurde, verläuft das Failover erfolgreich. Diese Bedingung tritt nur dann auf, wenn alle Hosts in einem FT-aktivierten Cluster ausgefallen sind, was dazu führt, dass der Host mit der sekundären virtuellen Maschine neu gestartet wird.
Umgehung: Keine. Das Failover verläuft nach einigen Versuchen erfolgreich.
- Das Ändern der Systemzeit auf einem ESX/ESXi-Host führt zu einem VMware HA-Agent-Fehler
Wenn Sie die Systemzeit auf einem ESX/ESXi-Host ändern, wird nach kurzer Zeit der folgende HA-Agent-Fehler angezeigt: Der HA-Agent auf < Server> in < Cluster> im < Datencenter> hat einen Fehler
.
Dieser Fehler wird sowohl im Ereignisprotokoll als auch auf der Host-Registerkarte Übersicht im vSphere-Client angezeigt.
Umgehung: Korrigieren Sie die Systemzeit des Hosts und starten Sie "vpxa" mit dem Befehl service vmware-vpxa restart
neu.
- Das Upgrade von einem ESX/ESXi 3.x-Host auf einen ESX/ESXi 4.0-Host verläuft erfolgreich, aber die VMware HA-Neukonfiguration schlägt möglicherweise fehl
Wenn Sie mit vCenter Update Manager 4.0 ein Upgrade des ESX/ESXi 3.x-Hosts auf ESX/ESXi 4.0 durchführen und der Host Teil eines HA- oder DRS-Clusters ist, verläuft das Upgrade erfolgreich und der Host wird wieder mit vCenter Server verbunden, aber die HA-Neukonfiguration schlägt möglicherweise fehl. Die folgende Fehlermeldung wird auf der Host-Registerkarte Übersicht angezeigt: Der HA-Agent weist einen Fehler auf: cmd addnode fehlgeschlagen für primären Knoten: Interner AAM-Fehler - Agent konnte nicht gestartet werden. : Unbekannter HA-Fehler
.
Umgehung: Konfigurieren Sie HA manuell neu, indem Sie mit der rechten Maustaste auf den Host klicken und Für VMware HA neu konfigurieren wählen.
- 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 wird. 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.
Seitenanfang