vSphere 5.0 - Versionshinweise | VMware Schweiz\nStartseitSupportSupport-RessourcenVMware-DokumentationVMware vSphere-DokumentationvSphere 5.0 - Versionshinweise\nvSphere 5.0 - Versionshinweise\nVMware ESXi™ 5.0 | 24. August 2011 | Build 469512\nVMware vCenter Server™ 5.0 | 24. August 2011 | Build 456005\nvCenter Server Appliance 5.0 | 24. August 2011 | Build 472350\nDiese Version von vSphere 5.0 umfasst ESXi 5.0 und vCenter Server 5.0. Weitere Informationen über die neuen und erweiterten Funktionen in dieser Version finden Sie unter Neuheiten bei VMware vSphere 5.0.\nVMware vSphere 5.0 ist in den folgenden Sprachen verfügbar:\nIn vSphere 5.0 können Sie VMware vSphere Client™ so konfigurieren, dass alle Texte der Benutzerschnittstelle auf Englisch erscheinen, auch für den Fall, dass für die Maschine, auf der er läuft, eine andere Sprache eingerichtet ist. Diese Konfiguration kann durch Angabe eines Befehlszeilenparameters für die Dauer einer einzelnen Sitzung erfolgen. Diese Konfiguration gilt für die Texte der Benutzerschnittstelle. Sie gilt nicht für andere Einstellungen des Gebietsschemas, z. B. für Datum und Uhrzeit oder für das Formatieren von numerischen Angaben.\nDie VMware-Produkt-Interoperabilitätmatrix liefert Details zur Kompatibilität aktueller und vorheriger Versionen von VMware vSphere-Komponenten, einschließlich ESXi, VMware vCenter Server, vSphere-Client und wahlweise anderer VMware-Produkte. Überprüfen Sie außerdem diese Site auf Informationen zu unterstützten Verwaltungs- und Sicherungsagenten, bevor Sie ESXi oder vCenter Server installieren.\nUm herauszufinden, welche Prozessoren, Speichergeräte, SAN-Arrays und E/A-Geräte mit vSphere 5.0 kompatibel sind, lesen Sie die Informationen zu ESXi 5.0 im VMware-Kompatibilitätshandbuch.\nUpgrades und Installationen für unterstützte CPUsvSphere 5.0 unterstützt nur CPUs mit LAHF- und SAHF-Befehlssätzen. Während einer Installation oder eines Upgrades wird eine Prüfung auf die Kompatibilität der Host-CPU mit vSphere 5.0 durchgeführt. Weitere Informationen zur CPU-Unterstützung finden Sie im VMware-Kompatibilitätshandbuch.\nVerwenden Sie die ESXi 5.0-Informationen im VMware-Kompatibilitätshandbuch, um die Gastbetriebssysteme zu ermitteln, die mit vSphere 5.0 kompatibel sind.\nVirtuelle Maschinen mit virtueller Hardware der Versionen 4.0 und höher werden von ESXi 5.0 unterstützt. Die Hardwareversion 3 wird nicht mehr unterstützt. Wenn Sie virtuelle Maschinen der Hardwareversion 3 unter ESXi 5.0 verwenden möchten, müssen Sie ein Upgrade der virtuellen Hardware durchführen. Weitere Informationen finden Sie in der vSphere-Upgrade-Dokumentation.\nvSphere-Client-Verbindungen zu Umgebungen im verknüpften Modus\nvCenter Server 5.0 kann sich nur zusammen mit anderen Instanzen von vCenter Server 5.0 im verknüpften Modus befinden. Gruppen im verknüpften Modus, die sowohl vCenter Server 5.0 als auch frühere Versionen von vCenter Server enthalten, werden nicht unterstützt.\nKompatibilität von vSphere 5.0 und VMware View\nInformationen zu vSphere-Konfigurationen, die mit VMware View unterstützt werden, finden Sie in der VMware-Produkt-Interoperabilitätmatrix .\nNach der erfolgreichen Installation müssen Sie einige Lizenzierungs-, Netzwerk- und Sicherheitskonfigurationsaufgaben durchführen. Beachten Sie die folgenden Handbücher in der vSphere-Dokumentation für weitere Informationen zu diesen Konfigurationsaufgaben.\nDie Dokumentation zu vCenter Server und Hostverwaltung zwecks Lizenzierung\nDie Dokumentation zu vSphere-Netzwerk zwecks Netzwerke\nDie Dokumentation zu vSphere-Sicherheit zwecks Sicherheit und Informationen zu Firewallports\nvCenter Server 5.0 unterstützt nur die Installation auf 64-Bit-Plattformen von Windows. Wenn das System ein 64-Bit-System ist, können Sie ein Upgrade von vCenter Server 4.1 auf vCenter Server 5.0 durchführen. Wenn VMware VirtualCenter Server 2.5 oder vCenter Server 4.0 auf einem 32-Bit-System installiert ist, finden Sie weitere Informationen über das Installieren von vCenter Server auf einem 64-Bit-Betriebssystem und das Beibehalten der VirtualCenter-Datenbank im vSphere-Upgrade-Handbuch.\nvCenter Server 5.0 enthält zum vCenter Server gehörende MIB-Dateien (MIB, Management Information Base). Sie können MIB-Dateien, die sich auf ESXi beziehen, von der VMware-Website unter http://www.vmware.com/download/vsphere/drivers_tools.html herunterladen.\nESX/ESXi-Hosts enthalten möglicherweise Drittanbieter-Software, z. B. Cisco Nexus 1000V VEMs oder EMC PowerPath-Module. Die ESXi 5.0-Architektur hat sich seit ESX/ESXi 4.x geändert, sodass angepasste Software-Pakete von Drittanbietern (VIBS) nicht migriert werden können, wenn Sie ein Upgrade von ESX/ESXi 4.x auf ESXi 5.0 durchführen. Wenn Sie ein Upgrade eines 4.x-Hosts mit angepassten VIBS, die sich nicht im Upgrade-ISO-Image befinden, durchführen, können Sie zwar mit dem Upgrade fortfahren, jedoch erscheint eine Fehlermeldung, in der die fehlenden VIBS aufgelistet werden. Für ein erfolgreiches Upgrade bzw. eine erfolgreiche Migration solcher Hosts müssen Sie Image Builder zum Erstellen eines benutzerdefinierten ESXi-ISO-Images mit den fehlenden VIBs verwenden. Wenn Sie ein Upgrade ohne die Drittanbieter-Software durchführen möchten, verwenden Sie die Option ForceMigrateoder wählen Sie die Option zum Entfernen von Drittanbieter-Softwaremodulen während des Standardisierungvorgangs im vSphere Update Manager. Weitere Informationen zur Erstellung einer benutzerdefinierten ISO-Datei mithilfe von Image Builder finden Sie im Installations- und Einrichtungshandbuch für vSphere. Informationen zur Durchführung von Upgrades mit Anpassungen von Drittanbietern finden Sie in den Handbüchern vSphere-Upgrade und Installieren und Verwalten von VMware vSphere Update Manager. Informationen zur Durchführung von Upgrades mit vSphere Update Manager finden Sie in den Handbüchern vSphere-Upgrade und Installieren und Verwalten von VMware vSphere Update Manager. Upgrades für diese Version\nInformationen zur Durchführung eines Upgrades von vCenter Server und ESXi-Hosts finden Sie im Handbuch vSphere-Upgrade.\nvSphere 5.0 unterstützt die folgenden Upgrade-Szenarien.\nSie können In-Place-Upgrades auf 64-Bit-Systemen von vCenter Server 4.x auf vCenter Server 5.0 durchführen.\nSie können kein Upgrade einer Instanz von vCenter Server 4.0.x durchführen, der unter Windows XP Professional x64 Edition ausgeführt wird.\nSie können ein Upgrade von VirtualCenter 2.5 Update 6 und höher und vCenter Server 4.x auf vCenter Server 5.0 durchführen, indem Sie vCenter Server 5.0 auf einem neuen 64-Bit-Betriebssystem installieren und die vorhandene Datenbank migrieren.\nDiese Upgrade-Methode ermöglicht das Upgrade von einem 32-Bit-System auf ein 64-Bit-System.\nvCenter Server 5.0 kann ESXi 5.0-Hosts in demselben Cluster mit ESX/ESXi 4.x- und ESX/ESXi 3.5-Hosts verwalten. Er kann auch ESX/ESXi 3.5-Hosts in demselben Cluster mit ESX/ESXi 4.x-Hosts verwalten. vCenter Server 5.0 kann ESX 2.x- und ESX 3.0.x-Hosts nicht verwalten.\nvSphere 5.0 stellt die folgenden Tools für die Aktualisierung von ESX/ESXi-Hosts zur Verfügung:\nvSphere Update Manager. Wenn auf Ihrer Site vCenter Server eingesetzt wird, verwenden Sie vSphere Update Manager zum Durchführen eines koordinierten Host-Upgrades oder eines koordinierten Upgrades von virtuellen Maschinen. Weitere Informationen finden Sie im Handbuch vSphere-Upgrade. Eine umfassende Dokumentation zu vSphere Update Manager finden Sie im Handbuch Installieren und Verwalten von VMware vSphere Update Manager.\nDurchführung eines interaktiven Upgrades mithilfe eines ESXi-Installations-ISO-Image auf CD-ROM oder DVD. Sie können das ESXi 5.0-Installationsprogramm von einem CD-ROM- oder DVD-Laufwerk aus starten, um ein interaktives Upgrade durchzuführen. Diese Methode eignet sich für das Durchführen eines Upgrades für eine kleine Anzahl von Hosts.\nDurchführen eines skriptbasierten Upgrades. Sie können ein Upgrade oder eine Migration von ESXi/ESX 4.x-Hosts auf ESXi 5.0 durchführen, indem Sie ein Update-Skript ausführen, was eine effiziente, unbeaufsichtigte Durchführung ermöglicht. Skriptbasierte Upgrades bieten zudem eine effiziente Möglichkeit zum Bereitstellen mehrerer Hosts. Sie können ein Skript zum Durchführen eines Upgrades von ESXi von einem CD-ROM- oder DVD-Laufwerk aus verwenden oder das Installationsprogramm per PXE-Startvorgang starten.\nTestversionen von vSphere 5.0\nUpgrades von vSphere 5.0 Beta und den vSphere 5.0 Release Candidate-Versionen auf vSphere 5.0 werden nicht unterstützt. Deinstallieren Sie ESXi 5.0 Beta bzw. den Release-Kandidaten und vCenter Server 5.0 Beta oder den Release-Kandidaten und führen Sie eine Neuinstallation von vCenter Server 5.0 und ESXi 5.0 durch. Sofern Sie Beta- oder Release-Kandidat-Versionen von vSphere 5.0 getestet haben, wird empfohlen, die Daten, die Sie aus den Konfigurationen auf vSphere 5.0 beibehalten möchten, neu zu erstellen.\nVMware vSphere bietet einen Satz von SDKs für vSphere-Server- und Gastbetriebssystemumgebungen.\nvSphere Management SDK. Eine Sammlung von Software Development Kits für die vSphere Management-Programmierumgebung. Das vSphere Management SDK enthält die folgenden vSphere-SDKs:\nvSphere Web Services SDK.Enthält Unterstützung für neue Funktionen in ESXi 5.0 und den vCenter Server 5.0-Serversystemen. Sie können dieses SDK auch mit vorherigen Versionen von ESX/ESXi und vCenter Server verwenden. Weitere Informationen finden Sie in der Dokumentation zu VMware vSphere Web Services SDK.\nvSphere vCenter Storage Monitoring Service (SMS) SDK. SMS 2.0 wird von vCenter Server 5.0 unterstützt. Weitere Informationen finden Sie in der Dokumentation zu vCenter SMS SDK.\nvSphere ESX Agent Manager (EAM) SDK. EAM 1.0 wird von ESXi 5.0 unterstützt. Weitere Informationen finden Sie in der Dokumentation zu vSphere ESX Agent Manager.\nvSphere Guest SDK. Das VMware vSphere Guest SDK 4.0 wird von ESXi 5.0 unterstützt. Weitere Informationen finden Sie in der Dokumentation zu VMware vSphere Guest SDK.\nVMware vSphere SDK für Perl. Das SDK für Perl 5.0 wird von vSphere 5.0 unterstützt. Weitere Informationen finden Sie in der Dokumentation zu vSphere SDK für Perl.\nInformationen über Copyright und Lizenzen für die Open Source-Komponenten, die im Lieferumfang von vSphere 5.0 enthalten sind, finden Sie unter http://www.vmware.com/download/vsphere/open_source.html auf der Registerkarte Open Source. Sie können auch die Quelldateien für jede GPL-, LGPL- oder vergleichbare Lizenz herunterladen, die es erfordert, den Quellcode oder Änderungen des Quellcodes für die neueste allgemein verfügbare Version von vSphere zur Verfügung zu stellen.\nVMware vSphere 5.0 ist die letzte Version für die folgenden Management-Funktionen und Plattformen. VMware bietet weiterhin technischen Support für diese Funktionen und Plattformen bis zum Ende der Supportdauer an.\nVMware Toolbox. vSphere 5.0 ist die letzte Version, die Unterstützung für die grafische Benutzeroberfläche von VMware Tools, VMware Toolbox, bietet. VMware wird die Befehlszeilenschnittstelle (CLI) der Toolbox weiterhin aktualisieren und unterstützen, damit alle VMware Tools-Funktionen ausgeführt werden können.\nVMCI-Sockets. vSphere 5.0 ist die letzte Hauptversion, die die Verwendung von VMCI-Sockets für die Kommunikation zwischen virtuellen Maschinen unterstützt. Die Verwendung von VMCI-Sockets für die Kommunikation zwischen ESXi und virtuellen Maschinen wird weiterhin unterstützt.\nVorgefertigte Module für nicht unterstützte Linux-Gastbetriebssysteme. vSphere 5.0 ist die letzte Version, bei der vorgefertigte Module (PBMs) für nicht unterstützte Linux-Gastbetriebssysteme im Lieferumfang enthalten sind. Wenn Sie ein nicht unterstütztes Linux-Gastbetriebssystem verwenden möchten, müssen Sie während der Installation von VMware Tools die Linux-Kernel-Module aus dem Quellcode kompilieren.\nBandlaufwerke. VMware unterstützt keine Bandlaufwerke, die an ESX/ESXi-Hosts angeschlossen sind. Weitere Informationen dazu finden Sie im Knowledgebase-Artikel 1016407.\nvSphere 5.0 und dessen nachfolgende Update- und Patch-Versionen sind die letzten vSphere-Versionen, die VMware ESX/ESXi 3.5 und VMware Virtual Center 2.5 unterstützen. Zukünftige Versionen von vSphere (dazu gehören VMware ESXi, VMware vCenter Server, VMware vSphere Client und VMware vCenter-Erweiterungen und -Plug-Ins, wie z. B. vCenter Update Manager) können nicht mehr mit VMware ESX/ESXi 3.5 und VMware Virtual Center 2.5 betrieben werden. VMware ESX/ESXi 3.5 und VMware Virtual Center 2.5 werden weiterhin bis zu den ursprünglich veröffentlichten Daten zur Beendigung der Unterstützung unterstützt.\nDie folgenden bekannten Probleme wurden beim Testen der Software erkannt. Sie helfen Ihnen, das Verhalten, auf das Sie in dieser Version treffen, besser zu verstehen. Diese Liste der Probleme gilt nur für diese Version von vSphere 5.0. Einige bekannte Probleme von vorherigen Versionen betreffen möglicherweise auch diese Version. Wenn ein Problem auftritt, das nicht in der Liste der bekannten Probleme aufgeführt ist, prüfen Sie die Liste der bekannten Probleme früherer Versionen, suchen Sie in der VMware-Knowledgebase oder teilen Sie uns das Problem durch Ihr Feedback mit.\nLesen Sie durch alle bekannten Probleme, um die Probleme zu finden, die Sie zutreffen. Die Probleme gliedern sich wie folgt:\nRegelinformationen fehlen, wenn das Image Builder-cmdlet zum Anzeigen eines geänderten Image-Profils in PowerShell 1.0 ausgeführt wird\nInstallieren Sie vSphere PowerCLI auf Microsoft PowerShell 1.0. Fügen Sie anschließend ein OEM-Softwarepaket zu einem Image-Profil hinzu. Beim Auflisten des Image-Profils fehlen die Informationen zur Rules-Eigenschaft.\nUmgehung: Sie können auf die Regelinformationen zugreifen, indem Sie die Rules-Eigenschaft des Image-Profilobjekts anzeigen.\nKeine Fehlermeldung, wenn Sie vSphere Authentication Proxy, vSphere ESXi Dump Collector und vSphere Syslog Collector-Support-Tools für vCenter Server auf vorherigen Versionen von vCenter Server installieren\nvCenter Server-Tools (VMware ESXi Dump Collector, VMware Syslog Collector, vSphere Auto Deploy und vSphere Authentication Proxy) sind auf dem Installationsmedium von vSphere 5.0 enthalten. Wenn Sie versuchen, ein oder mehrere Tools auf einem System zu installieren, auf dem eine vorherige Version von vCenter Server installiert ist, schlägt die Installation ohne Anzeige einer Fehlermeldung fehl.\nDie vSphere Authentication Proxy-, vSphere ESXi Dump Collector- und vSphere Syslog Collector-Support-Tools für vCenter Server unterstützen IPv6 nicht\nDie Hostmaschinen für Authentication Proxy, ESXi Dump Collector und Syslog Collector müssen eine gültige IPv4-Adresse aufweisen. Sie können diese Support-Tools auf Maschinen in Netzwerkumgebungen installieren, in denen entweder nur IPv4 oder IPv4 und IPv6 eingesetzt werden. Sie können die Tools nicht auf Maschinen in reinen IPv6-Umgebungen installieren. Die Authentication Proxy-, ESXi Dump Collector- und Syslog Collector-Dienste werden zwecks Kommunikation mit vCenter Server an eine IPv4-Adresse gebunden. IPv6 wird nicht unterstützt. vCenter Server kann sich auf einer Hostmaschine in einer Netzwerkumgebung befinden, in denen nur IPv4, IPv4 und IPv6 oder nur IPv6 eingesetzt werden. Allerdings muss die Maschine, die eine Verbindung zu vCenter Server über den vSphere-Client herstellt, über eine IPv4-Adresse verfügen, damit die Authentication Proxy-, ESXi Dump Collector- und Syslog Collector-Dienste funktionieren können.\nvCenter Inventory Service unterstützt das standardmäßige Binden an IPv6-Schnittstellen nicht\nWenn Sie vCenter Server installieren, unterstützt vCenter Inventory Service standardmäßig nur IPv4.\nUmgehung: Führen Sie die folgenden Schritte durch, um die IPv6-Unterstützung für vCenter Inventory Service zu aktivieren.\nHalten Sie den vCenter Inventory Service an. Wählen Sie unter "Verwaltung" in der Systemsteuerung Dienste aus.\nKlicken Sie mit der rechten Maustaste auf vCenter Inventory Service und wählen Sie Anhalten.\nÄndern Sie den Wert für dataservice.nio.enabledin false.\nStarten Sie den vCenter Inventory Service neu.\nEine skriptbasierte ESXi-Installation oder ein Upgrade von CD oder DVD schlägt fehl, es sei denn, Großbuchstaben werden beim Übergeben des Namen der Skriptdatei an den Startbefehl verwendet.\nWenn Sie eine skriptbasierte Installation oder ein Upgrade von einem ESXi 5.0-Installer-ISO-Image aus, das auf CD oder DVD gebrannt wurde, zusammen mit dem Installations- bzw. Upgrade-Skript (Kickstart-Datei) durchführen, wird der Name der Kickstart-Datei nur dann erkannt, wenn dieser in Großbuchstaben angegeben wird, auch wenn der Name der Datei nur aus Kleinbuchstaben besteht. Wenn z. B. der Name der Kickstart-Datei ks.cfglautet und Sie den Startbefehl ks=cdrom:/ks.cfgzum Angeben des Speicherorts der Kickstart-Datei verwenden, schlägt die Installation fehl mit einer Fehlermeldung ähnlich der Folgenden:\nHandledError: Fehler (weitere Informationen finden Sie in der Protokolldatei): Kickstart-Datei auf CD-ROM mit Pfad -- /ks.cfg wurde nicht gefunden.\nUmgehung: Verwenden Sie Großbuchstaben im Startbefehl, um den Namen der Kickstart-Datei anzugeben, z. B.: ks=cdrom:/KS.CFG\nIrreführende Fehlermeldung, wenn Sie versuchen, unter Angabe eines\nrelativen Pfads VIBs zu installieren\nWenn Sie mithilfe des Befehls esxcli software vib versuchen, ein Depot, ein VIB oder ein Profil zu installieren und Sie einen relativen Pfad angeben, schlägt der Vorgang mit folgender Fehlermeldung fehl: Datei oder Verzeichnis nicht vorhanden: '/var/log/vmware/a.vib'\nUmgehung: Geben Sie den absoluten Pfad an, wenn Sie die Installation durchzuführen.\nDer vSphere-Client kann nicht in einem Ordner installiert werden, dessen Name Sonderzeichen enthält\nWenn Sie den vSphere-Client in einem Ordner oder Verzeichnis installieren, dessen Name ein Semikolon (;), eine linke eckige Klammer ([), eine rechte eckige Klammer (]), ein Gleichheitszeichen (=), ein Pluszeichen (+), ein Komma (,) oder ein Rautezeichen (#) enthält, erscheint die folgende Fehlermeldung:\nDer Installationspfad enthält ein ';'-Zeichen. Wählen Sie ein Installationsverzeichnis ohne dieses Zeichen aus.\nAuch wenn der Ordnername kein Semikolon (;) enthält, können Sie den vSphere-Client im angegebenen Ordner nicht installieren. Wenn Sie außerdem den vSphere-Client in einem benutzerdefinierten Ordner installieren, dessen Name ein Rautezeichen enthält (\n#), kann der Client keine Verbindung zu vCenter Server herstellen.\nUmgehung: Installieren Sie den vSphere-Client nicht in einem benutzerdefinierten Ordner, dessen Name ein Semikolon (;), eine linke eckige Klammer ([), eine rechte eckige Klammer (]), ein Gleichheitszeichen (=), ein Pluszeichen (+), ein Komma (,) oder ein Rautezeichen (#) enthält\nUnter Windows 2008 ist nach der Installation das Beitreten zu einer Gruppe im verknüpften Modus nicht erfolgreich, wenn die Benutzerkontensteuerung (UAC) aktiviert ist\nWenn die Benutzerkontensteuerung (UAC) auf einem Windows 2008 x64-Bit-Betriebssystem 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, scheint es, als sei die Verknüpfung erfolgreich, aber in Wirklichkeit schlägt sie fehl. In der Bestandsliste wird nur ein vCenter Server aufgeführt.\nUmgehung: Schalten Sie die Benutzerkontensteuerung (UAC) aus, bevor nach der Installation das Beitreten zu einer Gruppe im verknüpften Modus vorgenommen wird, and schalten Sie sie anschließend wieder ein.\nBenutzerkontensteuerung (UAC) ausschalten.\nWählen Sie im Startmenü von Windows Systemsteuerung > Benutzerkonten.\nStarten Sie die Konfiguration für den verknüpften Modus. Wählen Sie Start > Programme > VMware > vCenter Server-Konfiguration für den verknüpften Modus.\nWählen Sie vCenter Server-Instanz einer vorhandenen Gruppe für den verknüpften Modus oder einer anderen Instanz hinzufügen und klicken Sie auf Weiter.\nSind die vCenter Server-Systeme verknüpft, schalten Sie die UAC ein. Wählen Sie im Startmenü von Windows Systemsteuerung > Benutzerkonten.\nWenn nach dem Installieren von vSphere Web Client der Benutzer auf "Beenden" im Installationsassistenten klickt, wird ein Browser gestartet und eine leere Seite angezeigt.\nNach der Installation des vSphere-Clients wird ein Browser gestartet und eine leere Seite angezeigt, wenn Sie im Installationsassistenten auf "Beenden" klicken. Die Seite bleibt leer und der Browser stellt keine Verbindung zur vSphere Administration Application her.\nUmgehung: Beenden Sie den Browser und starten Sie die vSphere Administration Application-Seite vom Startmenü aus.\nUpgrade-Probleme Ein Live-Update mit ESXCLI schlägt mit einer VibDownloadError-Fehlermeldung fehl\nWenn Sie die folgenden Aufgaben sequentiell durchführen, schlägt die Transaktion "Neustart erforderlich" fehl und eine VibDownloadError-Fehlermeldung erscheint.\nEin Live-Update unter Verwendung des Befehls esxcli software profile updateoder esxcli vib update.\nVor dem Neustart wird eine Transaktion ausgeführt, die nicht erfolgreich abgeschlossen wird. Eine mögliche häufige Ursache liegt in der Verifizierung der Signatur, die nur dann überprüft werden kann, nachdem das VIB heruntergeladen wurde.\nVersuchen Sie, ohne den Host neu zu starten, eine weitere Transaktion auszuführen, die einen Neustart erfordert. Die Transaktion schlägt mit einer VibDownloadError-Fehlermeldung fehl.\nESX 4.0 Update 2-Hosts stürzen möglicherweise nach einem Upgrade auf vCenter Server Version 5.0 ab\nBeim Absturz erscheint die folgende Meldung auf dem violetten Bildschirm: NOT_IMPLEMENTED bora/vmkernel/filesystems/visorfs/visorfsObj.c:3391.\nUmgehung: Bevor Sie ein Upgrade auf vCenter Server 5.0 durchführen, führen Sie ein Upgrade aller ESX 4.0 Update 2-Hosts, die von vCenter Server verwaltet werden, auf ESX 4.0 Update 3 durch.\nUpgrade von vCenter Server schlägt mit folgender Fehlermeldung fehl: Der Systemadministrator hat Richtlinien festgelegt, die diese Installation verhindern\nDieses Problem kann auftreten, wenn der Computer über nicht genügend zusammenhängenden Arbeitsspeicher für Windows Server 2003 oder Windows XP verfügt, um überprüfen zu können, ob das .msi- oder das .msp-Paket ordnungsgemäß signiert ist.\nWählen Sie im Windows-Startmenü Ausführen, geben Sie control admintools ein und klicken Sie auf OK.\nDoppelklicken Sie auf Local Security Policy.\nWählen Sie Software Restriction Policies.\nWenn keine Software-Einschränkungen aufgeführt sind, klicken Sie mit der rechten Maustaste auf Software Restriction Policies und wählen Sie Create New Policy.\nDoppelklicken Sie unter Object Type auf Enforcement.\nWählen Sie All users except local administrators und klicken Sie auf OK.\nStarten Sie den Computer neu und führen Sie das vCenter Server-Upgrade erneut durch.\nDie Datenmigration schlägt fehl, wenn der Pfad der vCenter Server-Installationsmedien Nicht-ASCII-Zeichen enthält\nTritt dieses Problem auf, erscheint eine Fehlermeldung ähnlich der Folgenden: 'ascii' codec can't decode byte 0xd0 in position 30: ordinal not in range(128). Das Installationsprogramm wird dann während der Datenmigration unerwartet beendet.\nUmgehung: Stellen Sie sicher, dass der Pfad der vCenter Server-Installationsmedien keine Nicht-ASCII-Zeichen enthält.\nWährend eines skriptbasierten Upgrades von ESX/ESXi 4.x auf ESXi 5.0 ändern sich die Namen der MPX- und VML-Festplattengeräte, was möglicherweise dazu führt, dass das Upgrade fehlschlägt\nNach einem Neustart des Hosts werden die MPX- und VML-Festplattengerätenamen möglicherweise nicht beibehalten. Wenn sich während eines skriptbasierten Upgrades nach einem Neustart die Namen ändern, wird das Upgrade möglicherweise unterbrochen.\nUmgehung: Verwenden Sie nach Möglichkeit NAA-IDs (Network Address Authority Identifiers) für Festplattengeräte. Führen Sie bei Maschinen, die über keine Festplatten mit NAA-IDs verfügen, z. B. Hewlett Packard-Maschinen mit CCISS-Controllern, das Upgrade von einer CD oder DVD aus, auf der sich das ESXi-Installer-ISO-Image befindet. Alternativ können Sie bei einem skriptbasierten Upgrade die zu aktualisierende ESX- oder ESXi-Instanz angeben, indem Sie den Befehl upgradeunter Angabe des Parameters --firstdisk=verwenden. Weitere Informationen zu Installations- und Upgrade-Skriptbefehlen finden Sie im Installations- und Einrichtungshandbuch für vSphere sowie in der Dokumentation zu vSphere-Upgrade.\nDie ESX-Konsole und der esxi_install.log-Bericht können während eines Upgrades keine DHCP-Adresse beziehen, wenn das ESX-System manuell zugewiesene IP-Adressen in einem Subnetz ohne den DHCP-Dienst verwendet\nDiese Situation tritt auf, wenn ein ESX-System mit manuell zugewiesenen IP-Adressen in einem Subnetz ohne DHCP-Server ausgeführt wird oder wenn die Kapazität des DHCP-Servers ausgeschöpft ist. In jedem Fall wird das System, wenn das ESX-System aktualisiert wird, bis zu eine Minute angehalten, wenn es versucht, eine IPv4-Adresse von einem DHCP-Server zu beziehen.\nUmgehung: Keine. Nachdem das System bis zu eine Minute angehalten wird, wird das Upgrade erfolgreich durchgeführt. Sie werden möglicherweise aufgefordert, die Eingabetaste zu drücken, um fortzufahren. Sie können entweder die Eingabetaste drücken oder die Eingabeaufforderung einfach ignorieren. In beiden Fällen fährt das System mit der Durchführung des Upgrades nach der Pause fort.\nUpgrade von ESX 4.x auf ESXi 5.0 wird in fehlgeschlagenem Zustand mit der Meldung Datei möglicherweise beschädigtgestoppt\nWenn Sie ein Upgrade von einem ESX 4.x-System auf ESXi 5.0 ausführen und sich unter /etc/sysconfig/networkirrelevante oder nicht erkannte Zeilen befinden, kann das Upgrade-Installationsprogramm diese Zeilen nicht analysieren und wird mit diesem Fehler gestoppt.\nUmgehung: Stellen Sie vor dem Upgrade sicher, dass sich in den ESX-Konfigurationsdateien unter /etc/sysconfig/networkkeine irrelevanten bzw. nicht erkannten Zeilen befinden. Achten Sie insbesondere auf die Zeile encoding=UTF-8, die auch ohne Zutun des Benutzers zu einer Datei hinzugefügt werden kann.\nDie automatische Zuweisung eines vSphere-Lizenzschlüssels zu bestimmten ESX/ESXi-Hosts in einem Host-Container schlägt möglicherweise fehl und die Hosts bleiben im Testmodus vCenter Server 5.0 unterstützt die automatische Zuweisung von Lizenzschlüsseln zu ESX/ESXi-Hosts. Sie können einem Host-Container in vCenter Server, wie z. B. einem Datencenter oder einem Cluster, einen Lizenzschlüssel zuordnen. vCenter Server weist dann allen nicht lizenzierten Hosts, die Sie diesem Host-Container hinzuzufügen, den Lizenzschlüssel zu. Sie können einem Host-Container nur einen Lizenzschlüssel zuordnen. Wenn die Lizenz, die Sie einem Host-Container zuordnen, eine andere Version als die Hosts aufweist, die Sie diesem Host-Container hinzufügen, wird den Hosts die Lizenz nicht zugewiesen. Wenn Sie beispielsweise einem Cluster eine vSphere 5.x-Lizenz zuordnen und dem Cluster ESX/ESXi 4.x-Hosts hinzufügen, wird den ESX/ESXi 4.x-Hosts die Lizenz nicht zugewiesen, sodass sie im Testmodus verbleiben.\nUmgehung: Stellen Sie sicher, dass alle Hosts, die Sie dem Host-Container hinzufügen, die gleiche Version wie die Lizenz aufweisen, die Sie demselben Container zuordnen. Wenn ein Host aus demselben Container eine Lizenz einer anderen Version benötigt, ordnen Sie dem Host die Lizenz direkt zu. Sie ordnen beispielsweise einem Cluster eine vSphere 5.x-Lizenz zu. Sie fügen dem Cluster ESXi 5.x-Hosts hinzu, denen die vSphere 5.x -Lizenz zugewiesen wird. Sie fügen demselben Cluster ESX/ESXi 4.x-Hosts hinzu und ordnen den Hosts eine vSphere 4.x-Lizenz zu. Sie verbinden die ESX/ESXi 4.x-Hosts zu vCenter Server neu und ihnen wird die vSphere 4.x-Lizenz zugewiesen.\nSicherheitsprobleme Die Sitzungen der Datenspeicher-Weboberfläche werden nicht sofort beendet, wenn Sie das Browserfenster schließen\nWenn Sie einen Webbrowser nach dem Zugriff auf die Datenspeicher-Weboberfläche schließen, wird die Sitzung auf der Serverseite nicht sofort beendet. VMware möchte Jason Jones von Inner Security für die Meldung dieses Problems danken.\nUmgehung: Bevor Sie das Browserfenster schließen, müssen Sie auf der Datenspeicher-Weboberfläche auf Abmelden klicken, um die Sitzung zu beenden.\nStellen Sie sicher, dass der Zugriff auf die vCenter Server Appliance sicher ist\nWenn die vCenter Server Appliance zum Verwenden eines Verzeichnisdiensts, wie z. B. Active Directory oder NIS (Network Information Service) konfiguriert ist, verfügen alle Benutzer über Anmelderechte bei der lokalen Shell. Auf die lokale Shell kann nur mit der Remotekonsole im vCenter-Client zugegriffen werden. Sie müssen die Zugriffsrechte auf die vCenter Server Appliance unter Verwendung von vCenter Server bzw. der hostd-Rechte auf die entsprechenden Administratoren beschränken.\nUmgehung: Sorgen Sie dafür, dass nur Administratoren VM-Vorgänge auf der vCenter Server Appliance ausführen können. Dies beinhaltet den Zugriff auf die Konsole der virtuellen Maschine und die Möglichkeit, eine virtuelle Maschine ein- bzw. auszuschalten.\nFolgendes gilt für das vCenter Server-System, das die vCenter Server Appliance verwaltet: Weisen Sie Benutzern ohne Administratorrechte keine Rechte für virtuelle Maschinen auf der vCenter Server Appliance zu.\nFolgendes gilt für den hostd-Prozess von ESXi-Systemen, die die vCenter Server Appliance hosten: Weisen Sie Benutzern ohne Administratorrechte keine Rechte für virtuelle Maschinen auf der vCenter Server Appliance zu.\nWenn die Zugriffsrechte auf diese Art eingerichtet sind, hat kein Benutzer ohne Administratorrechte über den vSphere-Client Zugriff auf die vCenter Server Appliance. Netzwerkprobleme In den Assistenten "Host dem vSphere Distributed Switch hinzufügen" und "Hosts verwalten" werden keine Details zur Servicekonsole angezeigt\nWenn Sie einen 4.x-ESX-Host zu einem Distributed Switch hinzufügen, werden die Details der Netzwerkadapter der Servicekonsole im Abschnitt "Details zum virtuellen Adapter" auf der Seite "Netzwerkkonnektivität" des Assistenten "Host hinzufügen" nicht angezeigt. Normalerweise sollten hier MAC-Adresse, IP-Adresse und Subnetzmaske angezeigt werden.\nUmgehung: Wenn Sie die Details zu einem Netzwerkadapter der Servicekonsole anzeigen möchten, beenden Sie den Assistenten "Hosts hinzufügen" bzw. "Hosts verwalten" und navigieren Sie dann im vSphere-Client zu "Host > Konfiguration > Netzwerk".\nWenn der Netzwerkadapter der Servicekonsole auf einem Standard-Switch bereitgestellt wird:\nSuchen Sie den Switch.\nKlicken Sie auf "Eigenschaften...".\nWählen Sie den Netzwerkadapter der Servicekonsole aus.\nNotieren Sie sich den Namen des Adapters, der im VSS-Diagramm angezeigt wird.\nWenn der Netzwerkadapter der Servicekonsole auf einem Distributed Switch bereitgestellt wird:\nNavigieren Sie zur Registerkarte "vSphere Distributed Switch".\nSuchen Sie den Distributed Switch und wählen Sie "Virtuelle Adapter verwalten...".\nSuchen Sie den Netzwerkadapter der Servicekonsole und wählen Sie ihn aus.\nDer ESXi Dump Collector-Server wird unbemerkt beendet\nWenn der Port des ESXi Dump Collector-Servers mit einem ungültigen Wert konfiguriert wurde, wird er ohne Fehlermeldung unbemerkt beendet. Da dies der Port ist, über den der ESXi Dump Collector-Server Core-Dumps von ESXi-Hosts empfängt, verhindern diese unbemerkten Beendigungen, dass diese von ESXi-Hosts stammenden Core-Dumps erfasst werden. Da ESXi Dump Collector keine Fehlermeldungen an vCenter Server sendet, ist der vSphere-Administrator nicht über dieses Problem informiert. Falls es nicht behoben wird, werden die Unterstützungsmöglichkeiten bei Ausfällen auf einem ESXi-Host beeinträchtigt.\nUmgehung: Wählen Sie beim Konfigurieren des ESXi Dump Collector-Servers nur einen Port aus dem empfohlenen Portbereich aus, um dieses Problem zu vermeiden. Die Verwendung des Standardports wird empfohlen.\nDie Verwendung einer 10G QLogic-Netzwerkkarte, Version QLE3142, mit einem nx_nic-Treiber führt dazu, dass Server während eines gPXE-Startvorgangs nicht funktionieren\nWenn eine 10G QLogic-Netzwerkkarte, Version QLE3142, mit einem nx_nic-Treiber für einen gPXE-Startvorgang in die ESXi Stateless-Startkonfiguration verwendet wird, funktioniert der ESXi-Server nicht mehr und kann nicht gestartet werden.\nUmgehung: Verwenden Sie für den gPXE-Startvorgang andere Netzwerkkarten.\nvSphere 5.0 hat eine Obergrenze von 16 VMkernel-Netzwerkadaptern, die für vMotion pro Host aktiviert sind. Wenn Sie für einen angegebenen Hosts mehr als 16 VMkernel-Netzwerkadapter für vMotion aktivieren, könnte das Durchführen von vMotion zu oder von diesem Host fehlschlagen. Die Fehlermeldung lautet refusing request to initialize 17 stream ip entries, wobei die Zahl die Anzahl der VMkernel-Netzwerkadapter angibt, die Sie für vMotion aktiviert haben.\nUmgehung: Deaktivieren Sie vMotion VMkernel-Netzwerkadapter, bis höchstens 16 davon für vMotion aktiviert sind.\nUnter ESXi 5.0 überschreibt die Netzwerk-E/A-Steuerung 802.1p-Tags in ausgehenden Paketen\nIn ESXi 5.0 überbrückt die Netzwerk-E/A-Steuerung die Lücke zwischen dem QoS (Quality of Service) des virtuellen Netzwerks und dem QoS des physischen Netzwerks, sodass Sie ein 802.1p-Tag auf pro Ressourcenpool-Basis angeben können.\nEin Nebeneffekt dieser Funktionalität ist, dass jeder Ressourcenpool mit einem Standard-802.1p-Tag (0) versehen wird, auch wenn der Tag nicht explizit festgelegt wurde. CoS-Bit-Tagging innerhalb einer virtuellen Maschine wird beim Verlassen des ESXi-Hosts überschrieben, wenn die Netzwerk-E/A-Steuerung aktiviert ist.\nUmgehung: Keine. Wahlweise können Sie die Netzwerk-E/A-Steuerung nicht verwenden.\nVMkernel-Netzwerkadapterkonfigurationen, die nur IPv6 verwenden, werden im Hostprofil nicht unterstützt\nWenn Sie den vSphere-Client zum Festlegen von IP-Konfigurationen für ein Hostprofil verwenden, können Sie nur IPv4-, nur IPv6- oder eine Kombination aus IPv4- und IPv6-Einstellungen für VMkernel-Netzwerkadapter festlegen. Allerdings werden Einstellungen, die nur IPv6 vorsehen, in Hostprofilen nicht unterstützt. Wenn Sie VMkernel-Netzwerkadapter mit Einstellungen konfigurieren, die nur IPv6 vorsehen, werden Sie aufgefordert, IPv4-Konfigurationen in der Hostprofil-Antwort-Datei anzugeben.\nVerwenden Sie nur IPv6-Einstellungen, wenn Sie Ihre VMkernel-Netzwerkadapter über den vSphere-Client konfigurieren, und verwenden Sie kein Hostprofil.\nNehmen Sie sowohl IPv6- als auch IPv4-Konfigurationen für VMkernel-Netzwerkadapter auf, wenn Sie ein Hostprofil erstellen und anwenden, und deaktivieren Sie anschließend die IPv4-Konfigurationen für die VMkernel-Netzwerkadapter, nachdem Sie das Profil angewendet haben.\nBei einigen Cisco-Switches gehen Pakete mit gesetztem Prioritäts-Bit verloren\nDie VMware vSphere Netzwerk-E/A-Steuerung ermöglicht Ihnen, den ausgehenden Datenverkehr mit 802.1p-Tags zu versehen. Bei einigen Cisco-Switches (4948 und 6509) gehen die Pakete verloren, wenn die mit Tags versehenen Pakete über das native VLAN (VLAN 0) übertragen werden.\nErhebliche Verzögerung des ESXi-Startvorgangs bei der VLAN-Konfiguration und dem Laden von Treibern\nBei ESXi-Hosts mit BE2- oder BE3-Schnittstellen kommt es zu einer erheblichen Verzögerung beim Laden der Treiber und der VLAN-Konfiguration. Die Verzögerungsdauer steigt mit der Anzahl der BE2- und BE3-Schnittstellen auf dem Host. Die Verzögerung kann mehrere Minuten dauern.\nDas Hinzufügen eines Netzwerkressourcenpools zu einem vSphere Distributed Switch schlägt mit der Fehlermeldung\nDer Vorgang für einen vSphere Distributed Switch kann für ein oder mehrere Hostmitglieder nicht abgeschlossen werden fehl\nDiese Fehlermeldung besagt, dass ein oder mehrere Hosts auf dem Distributed Switch bereits der maximalen Anzahl von Netzwerkressourcenpools zugeordnet wurde. Die für einen Host maximal zulässige Anzahl von Netzwerkressourcenpools beträgt 56.\nDas Hinzufügen eines Netzwerkressourcenpools zu einem vSphere Distributed Switch schlägt mit der Fehlermeldung vim.fault.LimitExceeded fehl\nDiese Fehlermeldung besagt, dass der Distributed Switch bereits über die maximale Anzahl von Netzwerkressourcenpools verfügt. Die für einen vSphere Distributed Switch maximal zulässige Anzahl von Netzwerkressourcenpools beträgt 56.\nLLDP zeigt keine Systemnamen für extreme Switches an\nStandardmäßig werden die Systemnamen von extremen Switches nicht veröffentlicht. Sofern nicht ausdrücklich festgelegt ist, dass der Systemname eines extremen Switches veröffentlicht wird, kann LLDP diese Informationen nicht anzeigen.\nUmgehung: Führen Sie den Befehl configure lldp ports <Port-ID> advertise system-name aus, um den Systemnamen des extremen Switches zu veröffentlichen.\nDas Abschneiden von gespiegelten Paketen sorgt dafür, dass ESXi fehlschlägt\nWenn die Länge eines gespiegelten Pakets die für die Portspiegelungssitzung festgelegte Länge für gespiegelte Pakete überschreitet ist, schlägt ESXi fehl. Andere Vorgänge, die Pakete abschneiden, sorgen möglicherweise auch dafür, dass ESXi fehlschlägt.\nUmgehung: Legen Sie für eine Portspiegelungssitzung keine Länge für gespiegelte Pakete fest.\nFault Tolerance ist nicht kompatibel mit vSphere DirectPath I/O mit vSphere vMotion\nWenn auf einer virtuellen Maschine Fault Tolerance aktiviert ist, ist DirectPath I/O mit vMotion für alle virtuellen Adapter auf der virtuellen Maschine deaktiviert.\nUmgehung: Deaktivieren Sie Fault Tolerance und starten Sie die virtuelle Maschine neu, bevor Sie DirectPath I/O mit vMotion aktivieren.\nvCenter Server Virtual Appliance unterstützt IPv6 nicht\nObwohl die Webkonsole der virtuellen vCenter Server-Appliance eine Option zum Konfigurieren von IPv6 bereitstellt, unterstützt die virtuelle vCenter Server-Appliance das Konfigurieren von IPv6 nicht.\nUmgehung: Legen Sie die IPv6-Konfiguration auf der Webkonsole der virtuellen vCenter Server-Appliance nicht fest und ändern Sie diese auch nicht.\nvSphere DirectPath I/O mit vSphere vMotion wird von VMCI-basierten Anwendungen deaktiviert\nWenn Sie eine VMCI-basierte Anwendung auf einem Cisco UCS-System verwenden, wird auf allen VM-Netzwerkadaptern DirectPath inaktiv.\nUmgehung: Beenden Sie alle VMCI-basierten Anwendungen und starten Sie die virtuelle Maschine neu, um vSphere DirectPath I/O wiederherzustellen.\nVerwenden der mitgelieferten Emulex BE2/BE2-Netzwerkkarten (be2net-Treiber)\nBei Verwendung von vSphere 5.0 mit Emulex BE2/BE3-Netzwerkkarten (be2net-Treiber) in einer HP FlexFabric/Flex-10- oder IBM Virtual Fabric Adapter-Umgebung (VFA-Imgebung) funktioniert die Verbindung auf Windows-VMs oder dem Server möglicherweise nicht ordnungsgemäß, wenn VLANs konfiguriert sind.\nUmgehung: Verwenden Sie den mit vSphere 5.0 mitgelieferten Treiber nicht. Besorgen Sie sich vor dem Upgrade auf vSphere 5.0 einen aktualisierten Treiber von Emulex, HP oder IBM, der auf HP FlexFabric/Flex-10- bzw. IBM VFA-Systemen zu verwenden ist.\nDer E/A-Latenz-Schwellenwert scheint 15 ms zu betragen, nachdem Sie die E/A-Metriken für einen Datenspeicher-Cluster deaktivieren\nNachdem Sie die E/A-Metriken für einen Datenspeicher-Cluster deaktivieren, wird weiterhin auf der Seite "Übersicht" für den Datenspeicher-Cluster ein E/A-Latenz-Schwellenwert von 15 ms (Standardwert) angezeigt.\nUmgehung: Keine. Wählen Sie zum Anzeigen des richtigen Werts Datenspeicher-Cluster > Speicher.\nEin Link für den Wechsel in den SDRS-Wartungsmodus erscheint auf der Seite "Übersicht" eines eigenständigen Datenspeichers\nNur Datenspeicher, die Teil eines Datenspeicher-Clusters sind, können erfolgreich in den Speicher-DRS-Wartungsmodus versetzt werden. Allerdings erscheint ein Link für den Wechsel in den SDRS-Wartungsmodus auf der Seite "Übersicht" eines Datenspeichers, der sich nicht in einem Datenspeicher-Cluster befindet. Wenn Sie auf In den SDRS-Wartungsmodus wechseln für einen eigenständigen Datenspeicher klicken, versucht der Datenspeicher, in den Wartungsmodus zu wechseln, und es scheint, als stehe die Aufgabe unendlich aus.\nUmgehung: Brechen Sie im Bereich "Kürzlich bearbeitete Aufgaben" des vSphere-Clients die Aufgabe "In den SDRS-Wartungsmodus wechseln" ab.\nDer Zustand "Keine Pfade verfügbar" (APD) während Storage vMotion kann zu einem Kommunikationsfehler zwischen vCenter Server und dem ESXi-Host führen\nWenn der Zustand "Keine Pfade verfügbar" (APD) eintritt, wenn Sie virtuelle Maschinen mithilfe von Storage vMotion migrieren, trennt vCenter Server den in Storage vMotion beteiligten Host von der vCenter Server-Bestandsliste. Dieser Zustand bleibt so lange bestehen, bis der Storage vMotion-Vorgang im Hintergrund abgeschlossen ist. Diese Aktion kann je nach Dauer des Storage vMotion-Vorgangs einige Minuten oder Stunden dauern. Während dieser Zeit kann vCenter Server keinen weiteren Vorgang für diesen bestimmten Host durchführen.\nUmgehung: Keine. Nach Abschluss des Storage vMotion-Vorgangs verbindet vCenter Server den Host wieder mit der Bestandsliste. Keine der laufenden virtuellen Maschinen auf nicht-APD-Datenspeichern sind von diesem Fehler betroffen.\nDem Datenspeicher hinzugefügte symbolische Links führen möglicherweise dazu, dass Datenspeicherinhalte im Datenspeicherbrowser falsch angezeigt werden\nWenn Sie symbolische Links auf der obersten Ebene eines Datenspeichers hinzufügen, entweder extern in einem NFS-Server oder durch Anmelden beim Host, werden möglicherweise falsche Datenspeicherinformationen, wie z. B. dessen Dateien und Ordner, angezeigt, wenn Sie den Datenspeicher durchsuchen. Dieses Problem ist möglicherweise auf symbolische Links zurückzuführen, die auf die falschen Dateien und Ordner verweisen.\nUmgehung: Entfernen Sie die symbolischen Links. Verwenden Sie keine symbolischen Links in Datenspeichern.\nVersuche, eine Erweiterung zu einem ATS-fähigen VMFS-Datenspeicher hinzuzufügen, schlagen fehl\nSie können einen ATS-fähigen Datenspeicher nur über ein ATS-fähiges Gerät erweitern. Wenn Sie das Gerät, das ATS nicht unterstützt, auswählen, um den ATS-fähigen Datenspeicher zu erweitern, schlägt der Vorgang fehl. Der vSphere-Client zeigt die Meldung Während der Hostkonfiguration ist ein Fehler aufgetretenangezeigt. Möglicherweise erscheint in der Protokolldatei auch die folgende Fehlermeldung: Vorgang fehlgeschlagen, dem Dateisystem konnte keine Erweiterung hinzugefügt werden.\nUmgehung: Stellen Sie, bevor Sie einem ATS-Datenspeicher eine Erweiterung hinzufügen, sicher, dass das Erweiterungsgerät ATS unterstützt, indem Sie den folgenden Befehl ausführen:\nesxcli storage core device vaai status get -d=Geräte-ID\nIn der Ausgabe müssen die folgenden Informationen angezeigt werden:\nBeim Ausgleichen der E/A-Last verhält sich Speicher-DRS möglicherweise nicht wie erwartet\nWenn Sie IOMeter-Software zum Generieren einer E/A-Last, um Speicher-DRS zu testen, füllt IOMeter die Dateien standardmäßig nur mit Nullbytes. Diese Daten enthalten keine zufälligen Muster aus Einsen und Nullen, die in Echtzeitdaten vorhanden sind und von Speicher-DRS benötigt werden, um die E/A-Merkmale und die Leistung des Datenspeichers festzustellen.\nUmgehung: Verwenden Sie zum Testen der Lastausgleichsfunktionalität von Speicher-DRS reale Daten, um mindestens 20 Prozent des Speicherplatzes des Datenspeichers zu füllen. Wenn Sie IOMeter-Software zum Generieren einer E/A-Last verwenden, wählen Sie eine Version aus, die zufällige Muster aus Einsen und Nullen in Ihre Dateien schreibt.\nDie Namen der Festplatten einer neuen virtuellen Maschine erscheinen nicht in den Empfehlungen von Speicher-DRS für die anfängliche Platzierung\nBeim Erstellen, Klonen oder Bereitstellen (von Vorlage) einer virtuellen Maschine auf einem Speicher-DRS-fähigen Datenspeicher-Cluster werden die Namen der Festplatten der neuen virtuellen Maschine weder in den Platzierungsempfehlungen noch im Fehlerdialogfeld aufgeführt. Im Dialogfeld wird Neue VM-Festplatte auf <Name des Datenspeichers> platzierenangezeigt.\nUmgehung: Keine. Beim Erstellen von virtuellen Maschinen werden die Namen der Festplatten erst dann zugewiesen, wenn die Festplatten platziert werden. Wenn die Festplatten der virtuellen Maschine unterschiedlich groß sind und auf verschiedenen Datenspeichern platziert werden, können Sie anhand der Speicherplatznutzungstatistik abschätzen, welche Festplatte auf welchem Datenspeicher platziert wird.\nSpeicher-DRS scheint deaktiviert zu sein, wenn Sie den Assistenten für geplante Aufgaben verwenden, um eine virtuelle Maschine zu erstellen oder zu klonen\nWenn Sie eine geplante Aufgabe erstellen, um eine virtuelle Maschine zu erstellen oder zu klonen, und einen Datenspeicher-Cluster als Speicherziel für die Dateien der virtuellen Maschine auswählen, ist das Kontrollkästchen "Speicher-DRS für diese virtuelle Maschine deaktivieren" immer aktiviert. Für die virtuelle Maschine können Sie das Kontrollkästchen "Speicher-DRS für diese virtuelle Maschine deaktivieren" im Assistenten für geplante Aufgaben nicht deaktivieren.\nUmgehung: Keine. Das Kontrollkästchen "Speicher-DRS für diese virtuelle Maschine deaktivieren" im Assistenten für geplante Aufgaben ist immer aktiviert. Nach der Ausführung der geplanten Aufgabe und dem Erstellen der virtuellen Maschine ist die Automatisierungsebene der virtuellen Maschine jedoch mit der Standard-Automatisierungsebene des Datenspeichers Clusters identisch.\nvSphere-Client zeigt einen Fehler an, wenn Sie versuchen, ein Unmounten eines NFS-Datenspeichers durchzuführen, bei dem Storage I/O Control aktiviert ist\nWenn Sie für einen NFS-Datenspeicher Storage I/O Control aktivieren, können Sie kein Unmounten dieses Datenspeichers durchführen. Die folgende Fehlermeldung erscheint: Die Ressource ist in Gebrauch.\nUmgehung: Deaktivieren Sie Storage I/O Control, bevor Sie versuchen, ein Unmounten des Datenspeichers durchzuführen.\nESXi kann nicht zwischen virtuellen Thick-Provision Lazy-Zeroed- und Thick-Provision Eager-Zeroed-Festplatten auf NFS-Datenspeichern mit Unterstützung für die Hardwarebeschleunigung unterscheiden\nWenn Sie NFS-Datenspeicher verwenden, die die Hardwarebeschleunigung unterstützen, ermöglicht Ihnen der vSphere-Client das Erstellen von virtuellen Festplatten im Format "Thick-Provision Lazy-Zeroed" (zeroedthick) oder "Thick-Provision Eager-Zeroed" (eagerzeroedthick). Wenn Sie jedoch im Dialogfeld "Eigenschaften der virtuellen Maschine" den Festplattentyp überprüfen, wird unabhängig von dem Format, das Sie beim Erstellen der Festplatte ausgewählt haben, stets "Thick-Provision Eager-Zeroed" als Festplattenformat im Abschnitt "Festplattenbereitstellung" angezeigt. ESXi unterscheidet nicht zwischen virtuellen Lazy-Zeroed und Eager-Zeroed-Festplatten auf NFS-Datenspeichern.\nNach der Migration wird der Modus einer IDE-RDM-Festplatte in physischer Kompatibilität nicht in "Unabhängig, dauerhaft" geändert\nDer Modus der IDE-RDM-Festplatte in physischer Kompatibilität ändert sich nicht in "Unabhängig, dauerhaft", nachdem Sie die virtuelle Maschine mit der Festplatte vom ESX/ESXi 4.x-Host auf ESXi 5.0 migriert haben.\nUmgehung: Verwenden Sie nach der Migration den vSphere-Client, um den Modus der Festplatte in "Unabhängig, dauerhaft" zu ändern.\nVersuche, einer vorhandenen virtuellen Maschine eine RDM mit virtueller Kompatibilität mit einer untergeordneten Festplatte hinzuzufügen, schlagen fehl\nWenn Sie versuchen, einer vorhandenen virtuellen Maschine eine RDM mit virtueller Kompatibilität, die über eine untergeordnete Festplatte verfügt, hinzuzufügen, schlägt der Vorgang fehl. Im vSphere-Client wird die folgende Fehlermeldung angezeigt: Neukonfiguration fehlgeschlagen: vim.fault.DeviceUnsupportedForVmPlatform.\nUmgehung: Entfernen Sie eine untergeordnete Festplatte, um die RDM mit virtueller Kompatibilität hinzufügen zu können.\nVersuche, bei aktiviertem Software-FCoE Speicherzuordnungen anzuzeigen, schlagen mit einer Fehlermeldung fehl\nDieses Problem betrifft nur diejenigen ESXi-Hosts, die ohne eine vorherige Software-FCoE-Konfiguration zu vCenter Server hinzugefügt wurden. Nachdem Sie Software-FCoE-Adapter auf diesen Hosts aktiviert haben, schlagen Versuche, Speicherzuordnungen im vSphere-Client anzuzeigen, fehl. Die folgende Fehlermeldung erscheint: Es ist ein interner Fehler aufgetreten: Antwort konnte nicht serialisiert werden.\nUmgehung: Konfigurieren Sie zuerst Software-FCoE auf dem ESXi-Host und fügen Sie anschließend den Host zu vCenter Server hinzu.\nEin NFS-Datenspeicher mit ausreichend Speicherplatz zeigt Fehlermeldungen an, die besagen, dass der Speicherplatz nicht ausreicht\nDieses Problem tritt nur dann auf, wenn Sie Remote Procedure Calls (RPC) verwenden, Clients gemeinsam nutzen und mehrere NFS-Volumes von derselben NFS-Server-IP-Adresse mounten. Wenn bei dieser Konfiguration der Speicherplatz eines der NFS-Volumes ausgeschöpft wird, könnten andere NFS-Volumes, die denselben RPC-Client gemeinsam nutzen, auch melden, dass der Speicherplatz nicht ausreicht.\nUmgehung: Deaktivieren Sie die gemeinsame Nutzung des RPC-Clients auf Ihrem Host, indem Sie diese Aufgabe durchführen:\nWählen Sie im Bestandslistenfenster des vSphere-Clients den Host aus.\nKlicken Sie im linken Bereich auf NFS und scrollen Sie nach unten bis "NFS.MaxConnPerIP" (rechts).\nÄndern Sie den Standardwert in 128.\nVersuche, die Registrierung mehrerer Speicheranbieter gleichzeitig aufzuheben, schlagen möglicherweise mit einem Fehler fehl\nWenn Sie versuchen, gleichzeitig die Registrierung mehrerer Speicheranbieter von vCenter Server aufzuheben, schlagen diese Versuche möglicherweise fehl. Die folgende Fehlermeldung wird angezeigt, obwohl die fehlgeschlagenen Anbieter in vCenter Server vorhanden sind: ManagedObjectNotFound. Die Datei "sms.log" zeigt möglicherweise die folgende Ausnahme an: ProviderUnregistrationFault.\nUmgehung: Heben Sie die Registrierung der Anbieter nach und nach einzeln manuell auf.\nNach einem Neustart erkennt ein statusfreier Host keine iSCSI-Datenspeicher\nWenn ein statusfreier Host zu einem Cisco Nexus 1000V Series-Switch hinzugefügt und mit einem MTU-Wert von 9000 konfiguriert wird, kann der Host nach erfolgtem Neustart keine iSCSI-Datenspeicher erkennen, obwohl er die zugehörigen Geräte erkennen kann.\nUmgehung: Um die Datenspeicher sichtbar zu machen, klicken Sie auf dem Bildschirm Konfiguration > Speicher des vSphere-Clients auf Aktualisieren.\nServerkonfigurationsprobleme Eine Änderung der SATP-PSP-Regel für Hostprofile, die auf einen ESXi-Host angewendet wird, wird nach einem Neustart nicht auf dem Host widergespiegelt\nNach einer SATP-PSP-Regel (SAN-Arraytyp-Plug-In-Pfadauswahlrichtlinie), dem Anwenden der Änderung und dem Neustart eines mit Auto Deploy bereitgestellten Hosts, wird diese neue Änderung nicht in der SATP-PSP für jedes dieser Geräte widergespiegelt. Im Falle von ESXi-Hosts, die nicht mit Auto Deploy bereitgestellt wurden, wird die SATP-PSP-Änderung ordnungsgemäß auf dem Host aktualisiert. Allerdings scheitert eine Überprüfung der Richtlinieneinhaltung des ESXi-Hosts mit dem Hostprofil.\nUmgehung: Löschen Sie nach dem Anwenden des Hostprofils auf dem ESXi-Host das Hostprofil und extrahieren Sie ein neues Hostprofil aus dem ESXi-Host. Hängen Sie dieses anschließend an den Host, bevor Sie den Host neu starten. Verwenden Sie dazu die Funktion "Profil aus Referenzhost aktualisieren" in der Hostprofil-Benutzeroberfläche. Diese Aufgabe löscht das Hostprofil und extrahiert ein neues Profil vom Host unter Beibehaltung der vorhandenen Anhänge.\nVerwenden Sie den esxcli-Befehl zum Bearbeiten der SATP-PSP auf dem Host selbst, bevor Sie das Hostprofil extrahieren. Verwenden Sie den Hostprofileditor zum Bearbeiten der SATP-PSP nicht.\nDas Anwenden eines Hostprofils mit einer Dienststartrichtlinie "aus" sorgt nicht dafür, dass der Dienst deaktiviert wird\nZum Erstellen eines Hostprofils wird als Referenzhost ein ESXi-Host verwendet, bei dem in der Konfiguration einige Dienste deaktiviert sind. Dieses Hostprofil wird dann auf einen Host angewendet, bei dem diese Dienste aktiviert sind. Beim Anwenden des Hostprofils werden die Dienste auf dem ESXi-Zielhost nicht deaktiviert. Diese Situation tritt in der Regel bei Benutzern ein, die die ESXShell- oder SSH-Dienste auf den ESXi-Zielhosts über das Sicherheitsprofil im vSphere-Client oder die Fehlerbehebungsoptionen in der DCUI aktiviert haben.\nUmgehung: Der Neustartvorgang deaktiviert die Dienste. Sie können im vSphere-Client die Dienste auch manuell beenden, indem Sie den Host konfigurieren. Führen Sie diesen Vorgang für jeden Dienst durch.\nKlicken Sie im Abschnitt "Software" auf Sicherheitsprofil.\nKlicken Sie auf Eigenschaften und wählen Sie den Dienst aus.\nKlicken Sie auf Anhalten und anschließend auf OK.\nDer Antwortdateistatus des Hostprofils wird beim Austauschen des angehängten Profils des Hosts nicht aktualisiert\nBeim Anhängen eines Hostprofils an einen Host, der vorher an ein anderes Hostprofil angehängt war, wird der Antwortdateistatus nicht aktualisiert. Wenn der Status der Antwortdatei "Abgeschlossen" lautet, wird er in der Hostprofilansicht immer noch als "Abgeschlossen" aufgeführt, nachdem ein anderes Hostprofil an den Host angehängt wurde. Allerdings wurde der tatsächliche Status möglicherweise in "Nicht abgeschlossen" geändert.\nUmgehung: Aktualisieren Sie den Status der Antwortdatei manuell, wenn Sie ein Hostprofil angehängt haben.\nWählen Sie in der Bestandslistenansicht "Hostprofile" des vSphere-Clients das neu angehängte Profil aus.\nKlicken Sie auf die Registerkarte Hosts und Cluster.\nKlicken Sie mit der rechten Maustaste in der Liste "Elementname" auf den Host and wählen Sie Antwortdatei prüfen.\nDer Antwortdateistatus für das Hostprofil wird aktualisiert.\nMögliche Zeitüberschreitung beim manuellen Anwenden eines Hostprofils mit einer großen Konfiguration\nBeim Anwenden eines Hostprofils mit einer großen Konfiguration, wie z. B. einer großen Anzahl von vSwitches und Portgruppen, tritt möglicherweise eine Zeitüberschreitung ein, wenn der Zielhost entweder nicht oder nur teilweise konfiguriert ist. In solchen Fällen erscheint im vSphere-Client die Fehlermeldung Die Hostkonfiguration kann nicht übernommen werden, obwohl der zugrunde liegende Prozess auf ESXi, der die Konfiguration anwendet, möglicherweise weiterhin ausgeführt wird.\nZudem enthalten syslog.log oder andere Protokolldateien möglicherweise Fehlermeldungen wie die Folgende:\nFehler beim Interagieren mit Konfigurationsdatei /etc/vmware/esx.conf: Zeitüberschreitung beim Warten auf die Freigabe der Sperre /etc/vmware/esx.conf.LOCK. Ein anderer Prozess hat diese Datei für mehr als 20 Sekunden gesperrt. Der Prozess, der die Sperre zurzeit besitzt, ist hostd-worker(5055). Dies ist wahrscheinlich ein temporärer Zustand. Versuchen Sie es später erneut.\nDieser Fehler wird durch ein Systemkonflikt verursacht, wenn mehrere Vorgänge versuchen, Informationen zur Systemkonfiguration abzurufen, während das Hostprofil die Konfiguration anwendet. Aufgrund dieser Fehler und anderer zeitüberschreitungsbezogenen Fehler wird die Konfiguration, die im Hostprofil erfasst wurde, möglicherweise auch nicht nach Abschluss des Anwendungsvorgangs des Hostprofils angewendet. Überprüfen Sie den Host auf Übereinstimmung, um die Teile der Konfiguration, die nicht angewendet wurden, zu ermitteln, und führen Sie einen Anwendungsvorgang durch, um diese aufgetretenen Probleme bei der Übereinstimmung zu beheben.\nESXi-Hosts, die nicht mit Auto Deploy bereitgestellt wurden\nErhöhen Sie den Zeitüberschreitungswert für den Anwendungsvorgang, indem Sie den folgenden Eintrag zur Datei /etc/vmware/hostd/cmdMo.xml hinzufügen:\nWobei xxxx der Zeitüberschreitungswert in Sekunden ist. Der Zeitüberschreitungswert für den Anwendungsvorgang beträgt standardmäßig 10 Minuten. Sie können mit diesem Eintrag auch einen längeren Zeitüberschreitungswert festlegen. Beispielsweise erhöht ein Wert von 3600 den Zeitüberschreitungswert auf 1 Stunde. Der zu verwendende Wert kann je nach der Konfiguration des Hostprofils variieren. Nach Festlegung eines ausreichend hohen Werts erscheint der Zeitüberschreitungsfehler für den Anwendungsvorgang nicht mehr und die Aufgabe ist bis zu ihrem Abschluss im vSphere-Client sichtbar.\nStarten Sie hostd neu.\nHosts, die mit Auto Deploy bereitgestellt wurden\nStarten Sie den mit Auto Deploy bereitgestellten ESXi-Host neu.\nStellen Sie bei ESXi-Hosts, die mit Auto Deploy bereitgestellt wurden, sicher, dass die Antwortdatei vollständig ist, indem Sie auf dem ESXi-Host den Vorgang "Antwortdatei aktualisieren" ausführen und anschließend den Host neu starten.\nDie Konfiguration im Hostprofil und der Antwortdatei wird während der Systeminitialisierung angewendet. Bei großen Konfigurationen kann der Neustart länger dauern. Dennoch ist es erheblich schneller als das manuelle Anwenden des Hostprofils über den vSphere-Client.\nDie Überprüfung der Richtlinieneinhaltung eines Hostprofils für einen Referenzhost mit einem neu erstellten Profil schlägt fehl\nEine Überprüfung der Richtlinieneinhaltung für ein neu konfiguriertes Hostprofil, z. B. mit iSCSI konfiguriert, schlägt möglicherweise fehl, wenn vor der Überprüfung die Antwortdatei nicht aktualisiert wurde.\nUmgehung: Aktualisieren Sie die Antwortdatei für das Profil, bevor Sie eine Überprüfung der Richtlinieneinhaltung durchführen.\nEin Hostprofil kann nicht angewendet werden, wenn das syslog-Protokollverzeichnis auf einen Datenspeicher ohne Pfad festgelegt wurde\nWenn das syslog-Verzeichnis mit dem esxcli-Befehl oder mit dem vSphere-Client auf einen Datenspeicher ohne zusätzlichen Pfad festgelegt wird, kann ein aus diesem System extrahiertes Hostprofil nicht auf andere Hosts angewendet werden.Im nachfolgenden Beispiel wird das System auf eine Weise konfiguriert, die diesen Zustand hervorruft:\nDas Festlegen von "Syslog.global.logDir" auf "datastore1" im Dialogfeld "Erweiterte Einstellungen" der Registerkarte "Konfiguration" des Hosts führt ebenfalls zu diesem Problem.\nUmgehung: Führen Sie eine der folgenden Aktionen durch:\nÄndern Sie im Dialogfeld "Erweiterte Einstellungen" den Wert von "Syslog.global.logDir" von "DATASTORE_NAME" auf "DATASTORE_NAME /", bevor Sie das Hostprofil extrahieren.\nBearbeiten Sie das Hostprofil, damit die Option "Syslog.global.logDir" für die erweiterte Konfiguration an Stelle von "DATASTORE_NAME" den Wert "DATASTORE_NAME /" hat.\nDurch das Anwenden eines Hostprofils werden möglicherweise vSwitches und Portgruppen neu erstellt\nDie vSwitches und Portgruppen eines Hosts werden möglicherweise neu erstellt, wenn ein Hostprofil angewendet wird. Dies kann selbst dann vorkommen, wenn der Host dem Hostprofil entspricht.\nDieses Problem tritt auf, wenn für die Optionen der Portgruppenprofil-Richtlinie die Standardwerte verwendet werden. Diese Einstellung führt zu einem Problem, bei dem der Vergleich zwischen dem Profil und der Hostkonfiguration fälschlicherweise fehlschlägt, wenn das Profil angewendet wird. Zu diesem Zeitpunkt verläuft die Überprüfung der Richtlinieneinhaltung erfolgreich. Der Fehler beim Vergleich führt dazu, dass durch die Aktion zum Anwenden des Profils die vSwitches und Portgruppen neu erstellt werden. Dies betrifft alle Unterprofile im Portgruppenprofil.\nUmgehung: Ändern Sie die Profileinstellungen, damit sie den gewünschten Einstellungen entsprechen, anstatt die Standardeinstellungen zu verwenden.\nDer in VMware eingebettete SNMP-Agent meldet ein falsches Datum für die Softwareinstallation über hrSWInstalledTablevon HOST-RESOURCES-MIB\nWenn Sie anhand des in VMware eingebetteten SNMP-Agenten nach installierter Software (hrSWInstalledTable RFC 2790) suchen, ist das Installationsdatum für vom Benutzer installierte Software falsch, weil hrSWInstalledTablevon HOST-RESOURCES-MIBein falsches hrSWInstalledDatemeldet.\nUmgehung: Um das korrekte Installationsdatum abzurufen, verwenden Sie den esxcli-Befehl esxcli software vib list.\nDie im Lieferumfang der vCenter Server Appliance eingebettete Datenbank unterstützt eine Bestandsliste mit maximal 5 Hosts und 50 virtuellen Maschinen\nDie eingebettete Datenbank ist nicht zum Verwalten einer Bestandsliste konfiguriert, die mehr als 5 Hosts und 50 virtuelle Maschinen enthält. Das Überschreiten dieser Einschränkungen kann viele Probleme verursachen, z. B., dass vCenter Server nicht mehr antwortet, wenn Sie die eingebettete Datenbank mit der vCenter Server Appliance verwenden.\nDie Seitenleiste "Alarme" von vSphere Web Client gibt nicht die richtige Anzahl der Alarme im System an\nWenn im System mehr als 100 Alarme vorhanden sind, werden in der Seitenleiste "Alarme" von vSphere Web Client nur 100 Alarme angegeben.\nÜberblicksleistungsdiagramme für Datenspeicher-Cluster oder Datenspeicher erscheinen in großen Umgebungen nicht\nIn einigen großen Umgebungen werden Überblicksleistungsdiagramme für Datenspeicher-Cluster oder Datenspeicher möglicherweise nicht angezeigt, weil für vSphere Management WebServices (Tomcat) nicht genügend freier Arbeitsspeicher zur Verfügung steht.\nUmgehung: Erhöhen Sie die Menge des verfügbaren Arbeitsspeichers für Tomcat.\nBei der Verwendung von vSphere Web Client werden Sie wiederholt aufgefordert, die Menge des für Adobe Flash zur Verfügung stehenden lokalen Speichers zu erhöhen\nvSphere Web Client verwendet lokalen Speicher auf dem System, das für den Zugriff auf den Client für das Speichern von Protokolldateien verwendet wird. Die Speicherlimits für die Protokolldateien werden von den Adobe Flash Player-Einstellungen vorgegeben. Wenn die Protokolldateien größer werden, erscheint ein Dialogfeld, in dem der Benutzer aufgefordert wird, den Grenzwert zu erhöhen. Sie werden immer wieder aufgefordert, den Grenzwert zu erhöhen, bis das Speicherlimit Unbegrenzt erreicht hat.\nUmgehung: So legen Sie die Speicherlimits für den Adobe Flash Player fest:\nÖffnen Sie den Bereich "Globale Speichereinstellungen", indem Sie in Ihrem Web-Browser die folgende URL öffnen: http://www.macromedia.com/support/documentation/de/flashplayer/help/settings_manager03.html\nBewegen Sie den Schieberegler auf Unbegrenzt.\nÖffnen Sie den Bereich "Website-Speichereinstellungen", indem Sie in Ihrem Web-Browser die folgende URL öffnen: http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager07.html\nWählen Sie die URL für vSphere Web Client unter "Besuchte Websites" aus.\nIn vSphere Web Client können mehrere Spalten für die Sortierung nicht ausgewählt werden\nIn Tabellen in vSphere Web Client können Sie die primäre Spalte für die Sortierung auswählen, indem Sie auf die Spaltenkopfzeile klicken. Wenn Sie auf eine zweite Spaltenkopfzeile klicken, wird diese Spalte zur primären statt zur sekundären Sortierspalte.\nUmgehung: Führen Sie die folgende Prozedur durch, wenn Sie nach mehreren Spalten in vSphere Web Client-Tabellen sortieren möchten:\nKlicken Sie auf eine Spaltenkopfzeile, um eine Spalte als primäre Sortierspalte festzulegen.\nWählen Sie die sekundären und nachfolgenden Spalten für die Sortierung aus, indem Sie bei gedrückter Strg-Taste auf die jeweilige Spalte klicken.\nInternet Explorer 7 kann vSphere Web Client-Seiten nicht laden\nWenn in den Internet Explorer 7-Sicherheitseinstellungen about:internetund https://localhostnicht als vertrauenswürdige Sites aufgeführt werden, kann der Webbrowser keine vSphere Web Client-Seiten öffnen.\nUmgehung: Fügen Sie about:internetund https://localhostals vertrauenswürdige Sites hinzu:\nWählen Sie in Internet Explorer 7 Extras > Internetoptionen.\nWählen Sie Vertrauenswürdige Sites.\nGeben Sie im Textfeld Diese Website zur Zone hinzufügen die Site about:internet\nein und klicken Sie auf Hinzufügen.\nGeben Sie im Textfeld Diese Website zur Zone hinzufügen die Site https://localhost\nSchließen Sie Internet Explorer und starten Sie ihn neu.\nDas Öffnen der vSphere Administration Application über eine Verknüpfung verursacht den Fehler: 'https://localhost:9443/admin-app' wurde nicht gefunden\nWenn Firefox der Standard-Webbrowser ist und nicht ausgeführt wird, verursacht das Starten von vSphere Administration Application über eine Verknüpfung möglicherweise den Fehler: 'https://localhost:9443/admin-app' wurde nicht gefunden. Stellen Sie sicher, dass Sie den Namen korrekt eingegeben haben, und versuchen Sie es erneut.\nUmgehung: Dies ist ein bekanntes Problem mit Firefox auf manchen Windows-Systemen. Weitere Informationen hierzu finden Sie unter http://kb.mozillazine.org/Windows_error_opening_Internet_shortcut_or_local_HTML_file_-_Firefox.\nvSphere Web Client lädt die vCenter Server-Bestandsliste nicht, wenn der Hostname von vCenter Server nicht aufgelöst werden kann\nWenn vSphere Web Client den Hostnamen von vCenter Server nicht auflösen kann und vCenter Server über eine IP-Adresse mit dem vSphere-Client registriert ist, kann vSphere Web Client die Bestandslistenstruktur nicht laden.\nUmgehung: Stellen Sie sicher, dass der Hostname von vCenter Server aufgelöst werden kann, indem Sie einen der folgenden Schritte durchführen:\nFügen Sie das vCenter Server-System zu Ihrem Namensserver hinzu.\nFügen Sie das vCenter Server-System zur Datei C:\_Windows\_System32\_drivers\_etc\_hostsauf dem System hinzu, auf dem vSphere Web Client ausgeführt wird.\nDer Befehl "snmpwalk" generiert eine Fehlermeldung, wenn Sie ihn ohne die Option "-t" ausführen\nWenn der Befehl snmpwalkohne die Optionen -tund -rzum Abfragen von SNMP-Daten ausgeführt wird, zeigt der eingebettete VMware-SNMP-Agent die Daten unvollständig an und generiert die Fehlermeldung Keine Antwort vom Host.\nUmgehung: Wenn Sie den Befehl snmpwalkausführen, verwenden Sie die Option -t, um das Zeitüberschreitungsintervall anzugeben, und die Option -r, um die Anzahl an Wiederholungen anzugeben. Beispiel: snmpwalk -m all -c public -v1 Hostname -r 2 -t 10 Name der Variablen.\nFlash-Plug-In stürzt beim An- oder Abmelden bei vSphere Web Client unter Linux ab\nWenn Sie sich unter Linux bei vSphere Web Client anmelden oder dort abmelden, stürzt das Flash-Plug-In möglicherweise ab.\nUmgehung: Laden Sie die Seite neu, um das Flash-Plug-In neu zu starten.\nAuf das Verwaltungstool von vSphere Web Client kann nicht unter Verwendung einer lokalen IPv6-Adresse zugegriffen werden\nWenn Sie versuchen, auf das Verwaltungstool von vSphere Web Client unter Verwendung einer lokalen IPv6-Adresse zuzugreifen, zeigt der Webbrowser die folgende Fehlermeldung an: Auf das vSphere Web Client-Verwaltungstool kann von einem Remotehost aus nicht zugegriffen werden.\nUmgehung: Verwenden Sie "localhost" anstelle der IPv6-Adresse, um auf das Verwaltungstool zuzugreifen. Verwenden Sie z. B. https://localhost:9443/admin-appanstelle einer Adresse wie https://[fc00:10:20:123:355c:1744:1b82:6716]:9443/admin-app.\nInternet Explorer 7 kann auf keine vSphere-Client-Webseiten zugreifen, wenn der Client auf einem System installiert ist, das ausschließlich IPv6 verwendet\nWenn vSphere Web Client auf einem System installiert ist, das ausschließlich IPv6 verwendet, können Sie Internet Explorer 7 nicht für den Zugriff auf vSphere Web Client verwenden.\nUmgehung: Verwenden Sie Firefox oder Internet Explorer 8 für den Zugriff auf vSphere Web Client.\nInternet Explorer kann möglicherweise das Client-Integrations-Plug-In nicht herunterladen\nWenn Sie Internet Explorer zum Herunterladen des Client-Integrations-Plug-Ins verwenden, erscheint möglicherweise die folgende Fehlermeldung: Internet Explorer kann vmware-vmcr-win32-x86.exe von localhost nicht herunterladen.Dies kann passieren, wenn bestimmte Sicherheitseinstellungen in Internet Explorer das Herunterladen des Client-Integrations-Plug-Ins verhindern.\nUmgehung: Verwenden Sie eine alternative Methode zum Herunterladen des Client-Integrations-Plug-Ins.\nVerwenden Sie Firefox, um eine Verbindung zu vSphere Web Client herzustellen und das Client-Integrations-Plug-In herunterzuladen.\nVerwenden Sie Internet Explorer, um eine direkte Verbindung zur Client-Integrations-Plug-In-Datei unter Verwendung des nicht sicheren Ports http://\nPortnummer/vsphere-client/vmrc/vmware-vmrc-win32-x86.exe herzustellen. Beispiel: http://localhost:9090/vsphere-client/vmrc/vmware-vmrc-win32-x86.exe.\nvSphere Web Client lädt und aktualisiert keine Daten\nManchmal kann vSphere Web Client keine Daten laden und aktualisieren. Das Drehfeld-Steuerelement in der oberen rechten Ecke des Anwendungsfensters dreht sich weiter und die angeforderten Informationen werden nicht angezeigt.\nUmgehung: Führen Sie eine oder mehrere der folgenden Verfahren durch:\nKlicken Sie auf die Aktualisierungsschaltfläche des Browsers.\nWählen Sie ein anderes Objekt aus der Bestandslistenstruktur aus und klicken Sie auf die Aktualisierungsschaltfläche des Browsers.\nÜberprüfen Sie den Systemzustand von vCenter Server und dessen Diensten. Starten Sie alle Dienste neu, die angehalten wurden.\nBeim Sichern von Daten des Bestandslistendiensts in der vCenter Server-Appliance tritt ein Fehler auf\nWenn Sie das Skript /usr/lib/vmware-vpx/inventoryservice/scripts/backup.shausführen, um die Daten des Bestandslistendiensts in der vCenter Server-Appliance zu sichern, schlägt es möglicherweise fehl mit der folgenden Fehlermeldung: Java HotSpot(TM) 64-Bit-Server-VM - Warnung: Versuch der Zuteilung von Stack-Guard-Seiten fehlgeschlagen.Dieser Fehler tritt auf, wenn wenig freier Arbeitsspeicher für die vCenter Server-Appliance zur Verfügung steht und JVM nicht genügend Arbeitsspeicher zum Starten des Prozesses zuteilen kann.\nUmgehung: Erhöhen Sie den System-RAM für die vCenter Server-Appliance.\nEin Neustart von vpxd in der vCenter Server-Appliance schlägt mit einem Datenbankfehler fehl\nEin Neustart von vpxdauf einer vCenter Server-Appliance mit einer eingebetteten Datenbank schlägt möglicherweise fehl. Eine Fehlermeldung ähnlich der Folgenden erscheint in der Datei vpxd.log:\nDieser Fehler tritt auf, wenn die Systemuhr auf der vCenter Server-Appliance auf einen Zeitpunkt zurückgesetzt wurde, der früher als der Zeitpunkt ist, zu dem die Datenbank erstellt wurde. Folglich weisen von der vCenter Server-Appliance erstellte Datenbankobjekte einen Zeitstempel auf, der eine Zeit in der Zukunft angibt. Dies führt dazu, dass Abfragen auf Datenbankobjekte fehlschlagen.\nDieser Fehler tritt möglicherweise während der Active Directory-Konfiguration auf, wenn die Uhr auf dem Active Directory-Domänencontroller auf einen früheren Zeitpunkt als die Uhr auf der vCenter Server-Appliance gesetzt wurde, da während der Konfiguration die Uhr der vCenter Server-Appliance mit der Uhr auf dem Active Directory-Domänencontroller synchronisiert wird.\nUmgehung: Setzen Sie nach dem Konfigurieren der eingebetteten Datenbank die Systemuhr auf der vCenter Server-Appliance nicht auf einen früheren Zeitpunkt. Stellen Sie beim Konfigurieren von Active Directory sicher, dass die Uhr auf dem Active Directory-Domänencontroller nicht auf einen Zeitpunkt gesetzt ist, der früher als der der Uhr auf der vCenter Server-Appliance ist.\nDer vCLI-Befehl zum Löschen der eingebetteten Konfiguration des SNMP-Agenten setzt die Quelle der Indications zurück und löscht Trapfilter\nDer vCLI-Befehl vicfg-snmp -rzum Löschen der eingebetteten Konfiguration des SNMP-Agenten setzt die Quelle von Ereignissen oder Traps auf den Standardwert indicationszurück und löscht alle Trapfilter.\nDas Aktivieren des eingebetteten SNMP-Agenten schlägt fehl mit der Fehlermeldung "Adresse wird bereits verwendet"\nWenn Sie einen Port außer udp/161 für den eingebetteten SNMP-Agenten konfigurieren, währen der Agent nicht aktiviert ist, überprüft der Agent nicht, ob der Port verwendet wird. Dies könnte zu einem Portkonflikt führen, wenn Sie den Agenten aktivieren, und die Fehlermeldung Adresse wird bereits verwendetgenerieren.\nUmgehung: Aktivieren Sie den eingebetteten SNMP-Agenten, bevor Sie den Port konfigurieren.\nAuf die Anmeldeseite von vSphere Web Client kann nicht von der vCenter Server-Begrüßungsseite aus zugegriffen werden\nWenn Sie die URL "localhost" verwenden, um auf die vCenter Server-Begrüßungsseite zuzugreifen, wird ein Fehler generiert, wenn Sie auf "Bei vSphere Web Client anmelden" klicken.\nUmgehung: Verwenden Sie die IP-Adresse oder den Hostnamen des vCenter Server-Systems, um auf die Begrüßungsseite zuzugreifen.\nIm Dialogfeld "Benutzer und Gruppen auswählen" des vSphere-Clients sind Benutzer- und Gruppennamen abgeschnitten\nWenn Sie einem Bestandslistenobjekt im vSphere-Client eine Berechtigung hinzufügen, werden die Namen von Benutzern und Gruppen im Dialogfeld "Benutzer und Gruppen auswählen" möglicherweise abgeschnitten. Beispiel: Administrator wird möglicherweise als tor angezeigt. Benutzer und Gruppen können nur ausgewählt werden, wenn Sie den vollständigen, richtigen Namen eingeben.\nDieses Problem tritt auf, wenn der Workstation-Dienst in Windows angehalten wurde.\nUmgehung: Starten Sie den Workstation-Dienst auf der vCenter Server-Maschine neu.\nWählen Sie Start > Programme > Verwaltung > Dienste.\nKlicken Sie mit der rechten Maustaste auf Workstation und wählen Sie Starten.\nDie exportierte Liste der virtuellen Maschinen ist möglicherweise unvollständig\nWenn Sie ein Datencenter, einen Cluster, einen Host oder ein anderes Objekt in der vSphere-Client-Bestandsliste auswählen und eine Liste deren virtuellen Maschinen exportieren, enthält die Liste möglicherweise nicht alle virtuellen Maschinen. Dies geschieht, weil die Informationen in der Liste nicht immer für Objekte, die nicht sichtbar sind, gefüllt werden.\nUmgehung: Scrollen Sie vor dem Exportieren durch die Liste, um sicherzugehen, dass alle virtuellen Maschinen angezeigt werden.\nStörende Fehlermeldungen erscheinen in den vSphere Web Client-Protokolldateien\nAufgrund der Versionen von Tomcat und dm Server erscheinen einige störende Fehlermeldungen in den vSphere Web Client-Protokolldateien. Darunter sind einige INFO-Meldungen sowie die Meldung SEVERE: No global context defined for server.Sie können diese Meldungen ignorieren.\nIn der Online-Hilfe zu vSphere Web Client wird Firefox 3.5 fälschlicherweise als unterstützter Browser aufgeführt\nIn der Online-Hilfe zu vSphere Web Client wird Firefox 3.5 fälschlicherweise als unterstützter Browser für vSphere Web Client und das Client-Integrations-Plug-In aufgeführt .\nUmgehung: Weitere Informationen zu den unterstützten Webbrowsern finden Sie im Installations- und Einrichtungshandbuch für vSphere.\nBeim Versuch, VM-Speicherprofile anzuzeigen, wird im vSphere-Client eine Fehlermeldung angezeigt\nWenn Sie den vSphere-Client zu vCenter Server verbinden und versuchen, das Speicherprofil einer virtuellen Maschine anzuzeigen, erscheint möglicherweise die Fehlermeldung VC kann keine Verbindung zum profilgesteuerten Speicherdienst unter http:///sps/sdk herstellen.\nEin Portkonflikt tritt auf, wenn der Speicherprofildienst und ein weiterer Dienst für die Verwendung von Port 31000 konfiguriert sind. vSphere Web Client und vCenter Orchestrator können diesen Konflikt verursachen.\nUmgehung: Starten Sie den vSphere Web Client-Dienst und den vCenter Orchestrator-Konfigurationsdienst neu. Die Dienste wählen den nächsten verfügbaren Port aus, wenn sie neu gestartet werden. Wenn nur einer der Dienste auf der Maschine vorhanden ist oder ausgeführt wird, müssen Sie nur diesen Dienst neu starten.\nVM-Verwaltungsprobleme Treiberverfügbarkeit für xHCI-Controller für USB 3.0-Geräte\nVirtuelle Hardwareversion 8 bietet Unterstützung für den xHCI-Controller und USB 3.0-Geräte. Allerdings steht für viele Betriebssysteme kein xHCI-Treiber zur Verfügung. Ohne einen im Gastbetriebssystem installierten Treiber können Sie keine USB 3.0-Geräte verwenden. Zurzeit sind keine Treiber für das Windows-Betriebssystem verfügbar. Wenden Sie sich an den Anbieter des Betriebssystems, um zu erfahren, wann ein Treiber zur Verfügung stehen wird. Wenn Sie virtuelle Maschinen mit Windows-Gastbetriebssystemen erstellen oder aktualisieren, können Sie den vorhandenen EHCI+UHCI-Controller, der USB 1.1- und 2.0-Geräte für die USB-Konfiguration von einem ESXi-Host oder einem Clientcomputer auf eine virtuelle Maschine unterstützt, weiterhin verwenden. Wenn Ihre virtuelle Windows-Maschine über xHCI- und EHCI+UHCI-USB-Controller verfügt, werden neu hinzugefügte USB 1.1- und USB 2.0-Geräte mit xHCI verbunden und nicht vom Gastbetriebssystem erkannt.\nUmgehung: Entfernen Sie den xHCI-Controller aus der Konfiguration der virtuellen Maschine, um USB-Geräte mit EHCI+UHCI zu verbinden.\nLinux-Kernels früher als 2.6.27 melden keine Nicht-2er-Potenzen für Kerne pro Socket\nAb ESXi 5.0 ermöglicht die Unterstützung von virtuellen CPUs mit mehreren Kernen Nicht-2er-Potenzen für Kerne pro Socket. Linux-Kernels vor 2.6.27 melden nur 2er-Potenz-Werte für Kerne pro Socket korrekt. Beispielsweise melden einige Linux-Gastbetriebssysteme möglicherweise keine Informationen zu physischen IDs, wenn Sie numvcpus = 6und cpuid.coresPerSocket = 3in der .vmx-Datei festlegen. Linux-Kernels 2.6.28 und höher melden die CPU- und Kerntopologie ordnungsgemäß.\nWenn Sie virtuellen Maschinen mit Linux 64-Bit- oder Windows 7 32-Bit-Gastbetriebssystemen Arbeitsspeicher im laufenden Betrieb hinzufügen, können Sie den vorhanden virtuellen Speicher auf mehr als 3 GB erhöhen\nBeim Hinzufügen von Arbeitsspeicher im laufenden Betrieb zu virtuellen Maschinen mit Linux 64-Bit- oder Windows 7 32-Bit Gastbetriebssystemen gelten die folgenden Voraussetzungen.\nWenn die eingeschaltete virtuelle Maschine über weniger als 3 GB Arbeitsspeicher verfügt, können Sie nicht mehr als 3 GB Arbeitsspeicher im laufenden Betrieb hinzufügen.\nWenn die virtuelle Maschine über 1 GB Arbeitsspeicher verfügt, können Sie 2 GB hinzufügen.\nWenn die virtuelle Maschine über 2 GB Arbeitsspeicher verfügt, können Sie 1 GB hinzufügen.\nWenn die virtuelle Maschine über 3444 MB Arbeitsspeicher verfügt, können Sie 128 MB hinzufügen.\nWenn die eingeschaltete virtuelle Maschine über genau 3 GB Arbeitsspeicher verfügt, können Sie keinen Arbeitsspeicher im laufenden Betrieb hinzufügen.\nWenn die eingeschaltete virtuelle Maschine über mehr als 3 GB Arbeitsspeicher verfügt, können Sie den Arbeitsspeicher der virtuellen Maschinen auf bis zu 16 Mal der anfänglichen, eingeschalteten Größe oder bis zu dem Hardwarelimit erhöhen, je nachdem, was kleiner ist. Die Hardwareversionsgrenze ist 255 GB für Hardwareversion 7 und 1011 GB für Hardwareversion 8.\nLinux 64-Bit- und Windows 7 32-Bit-Gastbetriebssysteme hängen, wenn deren Arbeitsspeicher von 3 GB oder weniger auf mehr als 3 GB erhöht wird, während die virtuelle Maschine eingeschaltet ist. Diese vSphere-Einschränkung stellt sicher, dass Sie diesen Fehler im Gastbetriebssystem nicht auslösen.\nFehler beim Hinuzfügen von CPUs im laufenden Betrieb auf virtuellen Maschinen der Hardwareversion 7\nDas Hinzufügen virtueller CPUs im laufenden Betrieb wird mit der virtuellen Mehrkern-CPU-Funktion für virtuelle Maschinen der Hardwareversion 8 unterstützt.\nWenn Sie bei virtuellen Maschinen der Hardwareversion 7 mit mehr als einem Kern pro Socket im Dialogfeld "Eigenschaften der virtuellen Maschine" das Hinuzfügen von CPUs im laufenden Betrieb aktivieren und versuchen, CPUs im laufenden Betrieb hinzuzufügen, schlägt der Vorgang fehl und die Fehlermeldung Das CPU-Hotplug wird für diese virtuelle Maschine nicht unterstützterscheint.\nUmgehung: Wenn Sie bei virtuellen Maschinen mit der Hardwareversion 7 die Funktion für das Hinzufügen von CPUs im laufenden Betrieb verwenden möchten, schalten Sie die virtuelle Maschine aus und legen Sie die Anzahl der Kerne pro Socket auf 1 fest.\nDie besten Ergebnisse erzielen Sie, wenn Sie virtuelle Maschinen der Hardwareversion 8 verwenden.\nDas Hinzufügen von Arbeitsspeicher im laufenden Betrieb zu einem Windows 2003 32-Bit-System, das den LSISAS-Treiber vom 20. November 2007 verwendet, kann dazu führen, dass die virtuelle Maschine nicht mehr antwortet\nDer LSISAS-Treiber vom 20. November 2007 kann den Arbeitsspeicher über 3 GB nicht ordnungsgemäß adressieren, wenn diese Art von Arbeitsspeicher beim Systemstart nicht vorhanden ist. Wenn Sie Arbeitsspeicher im laufenden Betrieb zu einem System hinzufügen, das vor dem Vorgang über weniger als 3 GB Arbeitsspeicher, aber nach dem Vorgang über mehr als 3 GB Arbeitsspeicher verfügt, wird der Zustand von Windows beschädigt und Windows reagiert bald nicht mehr.\nUmgehung: Verwenden Sie den neuesten LSISAS-Treiber, der auf der LSI-Website zur Verfügung steht. Verwenden Sie nicht den virtuellen LSISAS1068-Adapter für virtuelle Windows 2003-Maschinen.\nFalsche IPv6-Adresse erscheint auf der Registerkarte "Übersicht" auf MacOS X Server 10.6.5 und höheren Gastbetriebssystemen\nWenn Sie auf Alle anzeigen auf der Registerkarte Übersicht des vSphere-Clients klicken, enthält die Liste der IPv6-Adressen eine falsche Adresse für die lokale Verbindungsadresse. Sie sehen die falsche Adresse, wenn Sie ifconfigausführen und die Ausgabe des Befehls mit der Liste der Adresse im vSphere-Client vergleichen. Diese falsche Information erscheint auch dann, wenn Sie den Befehl vim-cmdausführen, um die GuestInfo-Daten abzurufen.\nDas gleichzeitige Erstellen einer großen Anzahl an virtuellen Maschinen sorgt dafür, dass Dateivorgänge fehlschlagen\nWenn Sie gleichzeitig eine große Anzahl an virtuellen Maschinen erstellen, die sich innerhalb desselben Verzeichnisses befinden, wird das Speichersystem überfordert und infolgedessen schlagen einige Dateivorgänge fehl. Eine vim.fault.CannotAccessFile-Fehlermeldung erscheint und der Vorgang zum Erstellen der virtuellen Maschine schlägt fehl.\nUmgehung: Erstellen Sie zusätzliche virtuelle Maschinen in kleineren Bündeln, z. B. 64, oder versuchen Sie, virtuelle Maschinen in unterschiedlichen Datenspeichern oder Innerhalb von unterschiedlichen Verzeichnissen desselben Datenspeichers zu erstellen.\nUSB-Geräte, die von einem ESXi-Host an eine virtuelle Maschine übergeben werden, werden während einer Migration mit vMotion möglicherweise getrennt\nWenn ein USB-Gerät von einem ESXi-Host an eine virtuelle Maschine übergeben wird und das Gerät so konfiguriert ist, dass es während der Migration mit vMotion verbunden bleibt, wird das Gerät während des vMotion-Vorgangs möglicherweise getrennt. Die Geräte können auch getrennt werden, wenn DRS eine Migration auslöst. Wenn die Geräte getrennt werden, kehren sie zum Host zurück und sind nicht mehr mit der virtuellen Maschine verbunden. Dieses Problem tritt häufiger auf, wenn Sie virtuelle Maschinen mit mehreren verbundenen USB-Geräten migrieren. Es kann jedoch auch auftreten, wenn nur ein Gerät oder eine kleine Anzahl von Geräten verbunden sind.\nUmgehung: Führen Sie eine Migration der virtuellen Maschine zurück auf den ESXi-Host durch, an dem die USB-Geräte physisch angeschlossen sind, und verbinden Sie die Geräte mit der virtuellen Maschine neu.\nEine virtuelle Maschine mit einem unzugänglichen SCSI-Passthrough-Gerät kann nicht eingeschaltet werden\nWenn ein mit einer virtuellen Maschine verbundenes SCSI-Passthrough-Gerät über eine Geräteunterstützung verfügt, die vom Host der virtuellen Maschine unzugänglich ist, kann die virtuelle Maschine nicht eingeschaltet werden. Es erscheint zudem die folgenden Fehlermeldung: Beim ESX-Host ist ein unerwarteter Fehler beim Einschalten der virtuellen Maschine aufgetreten..\nUmgehung: Führen Sie eines der folgenden Verfahren durch:\nWenn der Host der virtuellen Maschine über ein physisches SCSI-Gerät verfügt, ändern Sie die Geräteunterstützung des SCSI-Passthrough-Geräts des Hosts und schalten Sie die virtuelle Maschine ein.\nVerfügt der Host nicht über ein physisches SCSI-Gerät , entfernen Sie das SCSI-Passthrough-Gerät von der virtuellen Maschine und schalten Sie sie ein.\nDas Taskleistensymbol von VMware Tools zeigt den Status möglicherweise als "Veraltet" an\nWenn eine virtuelle Maschine VMware Tools verwendet, die mit vSphere 4.x installiert wurde, zeigt das Symbol in der Taskleiste des Gastbetriebssystems den Status möglicherweise als "Veraltet" an. Im vSphere 5.0-Client und vSphere Web Client wird auf der Registerkarte Übersicht für die virtuelle Maschine der Status als Veraltet (OK. Diese Version wird auf dem vorhandenen Host unterstützt, Sie müssen jedoch ein Upgrade durchführen, falls die neuen Funktionen nicht ordnungsgemäß ausgeführt werden können)angezeigt. VMware Tools, die mit vSphere 4.x installiert wurde, wird unterstützt. Ein Upgrade für die Verwendung mit vSphere 5.0 ist nicht zwingend erforderlich.\nUmgehungen: Verwenden Sie in vSphere 5.0 die Registerkarte Übersicht für die virtuelle Maschine im vSphere-Client oder in vSphere Web Client, um den Status von VMware Tools zu ermitteln. Wenn der Status "Veraltet" lautet und Sie kein Upgrade durchführen möchten, können Sie die folgenden Einstellungen zum Deaktivieren der Upgrade-Eingabeaufforderungen und des Warnsymbols im Gastbetriebssystem verwenden:\nWenn die virtuelle Maschine so eingestellt ist, dass ein automatisches Upgrade von VMware Tools durchgeführt wird, Sie aber möchten, dass die virtuelle Maschine auf der niedrigsten unterstützten Version verbleibt, setzen Sie die folgende Eigenschaft als erweiterten Konfigurationsparameter: Setzen Sie tools.supportedOld.autoupgradeauf FALSE. Diese Einstellung deaktiviert auch das Ausrufezeichensymbol des Gastbetriebssystems, das angibt, dass VMware Tools nicht unterstützt wird.\nWenn VMware Tools veraltet ist und Sie das Ausrufezeichensymbol deaktivieren möchten, das auf dem VMware Tools-Symbol in der Taskleiste erscheint, setzen Sie die folgende Eigenschaft als einen erweiterten Konfigurationsparameter: Setzen Sie tools.supportedOld.warnauf FALSE.\nKeine dieser Einstellungen beeinflusst das Verhalten von VMware Tools, wenn auf der Registerkarte "Übersicht" der Status als "Nicht unterstützt" oder "Fehler" angezeigt wird. In diesen Situationen erscheint das Ausrufezeichensymbol und ein Upgrade von VMware Tools wird auch dann automatisch durchgeführt (sofern diesbezüglich konfiguriert), wenn die erweiterten Konfigurationseinstellungen auf FALSEfestgelegt sind. Sie können erweiterte Konfigurationsparameter entweder durch Bearbeiten der .vmx-Konfigurationsdatei der virtuellen Maschine oder durch die Verwendung des vSphere-Clients oder von vSphere Web Client zum Bearbeiten der Einstellungen der VM festlegen. Wählen Sie auf der Registerkarte Optionen die Option Erweitert > Allgemein aus und klicken Sie auf Konfigurationsparameter.\nDas Prüfen und Aktualisieren der Tools beim Aus- und erneutem Einschalten funktioniert nicht in ESXi 5.0\nIn ESX/ESXi 4.1 stand die Option "Tools beim Aus- und erneutem Einschalten prüfen und aktualisieren" zum Durchführen eines Upgrades von VMware Tools zur Verfügung, wenn die virtuelle Maschine heruntergefahren war. Diese Funktion funktioniert nicht in ESXi 5. Ignorieren Sie alle dokumentierten Verfahren bezüglich dieser Funktion.\nUmgehung: Installieren Sie VMware Tools manuell.\nBei Mac OS X-Gastbetriebssystemen mit hoher CPU- und Arbeitsspeichernutzung tritt möglicherweise beim Anhalten oder Fortsetzen einer virtuellen Maschine oder während Migrationsvorgängen eine Kernelpanik auf\nNach Vorgängen zum Anhalten oder Fortsetzen einer virtuellen Maschine oder während Migrationsvorgängen auf einem Host mit einer schweren CPU- und Arbeitsspeicherlast tritt möglicherweise eine Zeitüberschreitung bei der TLB-Invalidierungsanforderung ein. In solchen Fällen antwortet das Mac OS X-Gastbetriebssystem nicht mehr und eine Variante einer der folgenden Meldungen wird in die Datei "vmware.log" geschrieben:\nUmgehung: Reduzieren Sie die CPU- und Arbeitsspeicherlast auf dem Host oder reduzieren Sie die Anzahl virtueller CPUs auf 1.\nVorgänge zum Klonen oder Verschieben einer virtuellen Maschine von ESXi 5.0 auf ESX/ESXi 4.1 schlagen fehl, wenn die Replizierung aktiviert ist\nWenn Sie den Befehl hbr enablereplicationverwenden, um die Replizierung einer virtuellen Maschine zu aktivieren, die sich auf einem ESXi 5.0-Host befindet, und die virtuelle Maschine auf einen ESX/ESXi 4.1- oder früheren Host klonen, schlägt die Validierung mit einer Fehlermeldung ähnlich der Folgenden fehl: Vorgang wird nicht unterstützt. Das Klonen von virtuellen ESXi 5.0-Maschinen auf ESX/ESXi 4.1-Hosts wird nicht unterstützt.\nUmgehung: Wählen Sie eine der folgenden Umgehungen aus:\nKlonen Sie die virtuelle Maschine auf einen ESXi 5.0-Host\nKlonen oder verschieben Sie eine neue virtuelle Maschine auf einem ESX/ESXi 4.1-Host.\nDie Inkompatibilität von vCenter Server 5.0 und ESX/ESXi-Hosts sorgt dafür, dass Migrationsvorgänge für virtuelle Maschinen mit Delta-Festplatten fehlschlagen\nWenn vCenter Server 5.0 einen Host vor ESX/ESXi 4.0 Update 3 verwaltet, können Sie keine virtuellen Maschinen mit Snapshots oder Delta-Festplatten auf diesen Host migrieren. Beim Versuch, eine solche Migration durchzuführen, erscheint die folgende Systemfehlermeldung: Aufgrund einer Versionsinkompatibilität zwischen vCenter Server und ESX wird das Migrieren von virtuellen Maschinen mit Snapshots oder Delta-Festplatten nicht unterstützt . Führen Sie zum Fortfahren dieses Vorgangs ein Upgrade von Ihren ESX-Hosts auf ESX 4.0 Update 3 oder höher durch.\nFür ESX/ESXi 4.1 gilt dieselbe Einschränkung und eine ähnliche Fehlermeldung erscheint. ESX/ESXi 4.1 unterstützt das Migrieren von virtuellen Maschinen mit Delta-Festplatten nicht, wenn vCenter Server 5.0 den Host verwaltet.\nUmgehung: Führen Sie ein Upgrade des ESX/ESXi-Hosts auf ESX/ESXi 4.0 Update 3 oder höher durch oder führen Sie ein Upgrade auf ESX 4.1 Update 1 oder höher durch.\nSpeicherfehlkonfigurationen können das Verbinden von USB-Geräten mit virtuellen Maschinen verhindern\nUSB-Geräte, die von einem ESXi-Host mit einer virtuellen Maschine verbunden werden, stehen zum Hinzufügen zur virtuellen Maschine möglicherweise nicht zur Verfügung, wenn Speicherfehlkonfigurationen vorliegen. Fehlkonfigurationen auf dem Host können zu langen Prüfvorgängen beim Start führen. Dies wiederum führt dazu, dass es scheint, als ob USB-Geräte, die mit dem Host verbunden sind, für das Passthrough an die virtuelle Maschine nicht zur Verfügung stehen. Wenn beispielsweise eine SendTargets-Adresse (bzw. Dynamische Erkennung) auf dem System nicht vorhanden ist oder nicht antwortet, tritt eine Erkennungszeitüberschreitung auf. Zudem kann eine iSCSI-Fehlkonfiguration aufgrund von TCP-Zeitüberschreitungen Verzögerungen zwischen einer und zwei Minuten verursachen.\nUmgehung: Beheben Sie die Fehlkonfiguration und verwenden Sie anschließend den Befehl service mgmt-vmware restart, um hostdneu zu starten.\nBenutzerdefinierte VMware Tools-Skripts können nicht über die VMware-Toolbox-Benutzeroberfläche in einem Linux-Gastbetriebssystem festgelegt werden, wenn die benutzerdefinierten Skripts Nicht-ASCII-Zeichen in ihren Pfaden enthalten\nIn Linux-Gastbetriebssystemen werden im Fenster "VMware Tools - Eigenschaften" Nicht-ASCII-Zeichen als kleine Quadrate mit einem Xdargestellt, wenn das Systemgebietsschema zh_CN.gb18030, ja_JP.eucjpoder ko_KR.euckrist. In diesen Fällen können Sie keine benutzerdefinierten VMware Tools-Skripts festlegen.\nÄndern Sie den Namen des Verzeichnisses, in dem sich die benutzerdefinierten VMware Tools-Skripts befinden, sodass sie nur ASCII-Zeichen enthalten.\nLegen Sie die benutzerdefinierten VMware Tools-Skripts fest, indem Sie in einer Shell den Befehl vmware-toolbox-cmd scripteingeben.\nNicht-ASCII-DNS-Suffixe werden nach dem Anpassen von Windows XP und Windows 2003 nicht ordnungsgemäß gesetzt\nWenn Sie den Assistenten zur Anpassung von Spezifikationen verwenden, um Windows XP oder Windows 2003 anzupassen, und auf der Registerkarte DNS der Netzwerkeigenschaften ein Nicht-ASCII-DNS-Suffix eingeben, wird die Anpassung als erfolgreich gemeldet, aber das Nicht-ASCII-DNS-Suffix wird nicht ordnungsgemäß gesetzt.\nUmgehung: Setzen Sie unter Windows XP und Windows 2003 das DNS-Suffix manuell.\nEine virtuelle Windows 7-SMP-Maschine mit einem geringen Arbeitsspeichergrenzwert antwortet nicht mehr und zeigt eine Fehlermeldung auf einem blauen Bildschirm an\nWenn eine virtuelle SMP-Maschine mit einem Windows 7-Gastbetriebssystem über einen Arbeitsspeichergrenzwert verfügt, der 50 Prozent weniger als die RAM-Größe der virtuellen Maschine ist, und auf einem ESXi-Host mit überbelegtem Arbeitsspeicher und überbelegter CPU ausgeführt wird, antwortet die virtuelle Maschine möglicherweise nicht mehr. Wenn diese Bedingungen vorhanden sind und Sie eine Migration mit vMotion durchführen oder einen Fortsetzungsvorgang anhalten, erscheint ein blauer Bildschirm mit der folgenden bzw. einer ähnlichen STOP-Fehlermeldung: *** STOP: 0x0000007E\nUmgehung: Deaktivieren Sie die Arbeitsspeichergrenzwerte für die virtuelle Maschine oder legen Sie einen höheren Arbeitsspeichergrenzwert fest.\nIn VMware eingebetteter SNMP-Agent meldet für Prozessoren im hrDeviceStatus-Objekt des HOST-RESOURCES-MIB-Moduls einen falschen Status\nBeim Übermitteln der Systemdetails zeigt der in VMware eingebettete SNMP-Agent für Prozessoren einen falschen Status an. Der SNMP-Agent meldet den Prozessorstatus Unbekanntfür das hrDeviceStatus-Objekt in HOST-RESOURCES-MIB. Die ESX/net-snmp-Implementierung von HOST-RESOURCES-MIB gibt das hrDeviceStatus-Objekt nicht zurück, was dem Übermitteln des Status Unbekanntentspricht.\nUmgehung: Verwenden Sie entweder CIM-APIs oder SMBIOS-Daten zum Überprüfen des Prozessorstatus.\nDer Snapshot-Festplattenpfad in der .vmsd-Snapshot-Datenbankdatei und der übergeordnete Pfad in der Delta-Festplattendeskriptordatei werden nach der Migration nicht aktualisiert\nWenn snapshot.redoNotWithParentauf TRUEfestgelegt ist und Sie die Einstellung snapshotDirectorybeispielsweise von Datenbank A in Datenbank B ändern, erhalten Sie möglicherweise die Fehlermeldung Es wurde eine ungültige Snapshot-Konfiguration erkannt. Dieses Problem tritt auf, wenn beide der folgenden Bedingungen erfüllt sind:\nSie stellen einen vorherigen Snapshot in der Snapshot-Struktur wieder her und erstellen neue Snapshots von diesem Snapshot-Punkt aus. Dies führt zu einer nicht linearen Hierarchie in der Snapshot-Struktur.\nDie Festplatten-Links in einer Festplattenkette umfassen mehrere Datenspeicher und enthalten sowohl den Quell- als auch den Zieldatenspeicher. Diese Situation tritt auf, wenn Sie die snapshotDirectory-Einstellungen mehrmals ändern, sodass sie auf verschiedene Datenspeicher verweisen, und Sie zwischen den snapshotDirectory-Änderungen Snapshots der virtuellen Maschine erstellen. Beispiel: Sie erstellen Snapshots einer virtuellen Maschine, wobei snapshotDirectoryauf Datenspeicher A festgelegt ist, stellen einen vorherigen Snapshot wieder her, ändern anschließend die snapshotDirectory-Einstellung auf Datenspeicher B und erstellen zusätzliche Snapshots. Dann migrieren Sie die virtuelle Festplatte von Datenspeicher B nach Datenspeicher A.\nEs ist Best Practice, die Standardeinstellung beizubehalten, mit der der übergeordnete und die untergeordneten Snapshots zusammen in dem Snapshot-Verzeichnis gespeichert werden. Sie sollten es vermeiden, die snapshotDirectory-Einstellungen zu ändern oder zwischen Datenspeicheränderungen Snapshots zu erstellen. Wenn Sie snapshot.redoNotWithParentauf TRUEfestlegen, führen Sie eine vollständige Speichermigration auf einen Datenspeicher durch, der zurzeit nicht von der virtuellen Maschine verwendet wird.\nUmgehung: Aktualisieren Sie die Festplattenpfadreferenzen in der Snapshot-Datenbankdatei und der Festplattendeskriptordatei manuell auf den korrekten Datenspeicherpfad.\nEine Cold-Migration einer virtuellen Maschine mit einer virtuellen IDE-Festplatte von einem ESXi 5.0-Host auf einen ESX/ESXi 4.x-Host schlägt mit folgender Fehlermeldung fehl: Der Vorgang wird für dieses Objekt nicht unterstützt\nWenn Sie vCenter Server 5.0 zum Durchführen einer Cold-Migration einer virtuellen Maschine, die eine oder mehrere virtuelle IDE-Festplatten hat, von einem ESXi 5.0-Host auf einen Host, auf dem ESX/ESXi 4.x ausgeführt wird, verwenden, schlägt die Migration mit der folgenden Fehlermeldung fehl: Der Vorgang wird für dieses Objekt nicht unterstützt.\nWählen Sie auf dem ESXi 5.0-Host die virtuelle Maschine aus.\nWenn sich die virtuelle Maschine auf einem nur für Hosts vorgesehenen Datenspeicher auf dem ESXi 5.0-Host befindet, verschieben Sie die .vmx- und .vmdk-Dateien auf eine gemeinsam genutzte LUN, auf die der ESXi 5.0- und der ESX/ESXi 4.x-Host zugreifen können.\nFühren Sie eine Cold-Migration der virtuellen Maschine auf den ESX/ESXi 4.x-Host mithilfe der Option Host ändern im Assistenten "Migrieren von virtuellen Maschinen" durch.\nBeim Übergang auf die Sommerzeit wird die Zeitachse auf den Leistungsdiagrammen nicht auf die neue Uhrzeit aktualisiert.\nBeispiel: Die lokalen Uhren in Gebieten, in denen die Uhren umgestellt werden, wurden am Sonntag, dem 27. März 2011 um 3 Uhr um eine Stunde vorgestellt. Die Markierungen auf der Zeitachse von Leistungsdiagrammen hätten ..., 2:00, 2:20, 2:40, 4:00, 4:20, ...lauten sollen, d. h. ohne Markierungen für die Stunde, die um 3 Uhr beginnt. In Wirklichkeit werden jedoch die Markierungen ..., 2:00, 2:20, 2:40, 3:00, 3:20, 3:40, 4:00, 4:20, ...angezeigt.\nNach einem Storage vMotion-Vorgang, bei dem der Benutzer eine Datenträgerformatänderung angibt, behalten Festplatten virtueller Maschinen ihr ursprüngliches Format bei\nWenn Sie während eines Storage vMotion-Vorgangs einer eingeschalteten virtuellen Maschine auf einem Host, auf dem ESX/ESXi 4.1 oder früher ausgeführt wird, versuchen, das Festplattenformat in "Thick-Provision Eager-Zeroed" zu ändern, erfolgt keine Konvertierung. Der Storage vMotion-Vorgang wird zwar erfolgreich durchgeführt, aber die Festplatten behalten das ursprüngliche Format bei. Dies ist auf eine Einschränkung von ESX/ESXi 4.1 und früher zurückzuführen. Wenn der gleiche Vorgang auf einer virtuellen Maschine auf einem ESXi 5.0-Host durchgeführt wird, erfolgt die Konvertierung ordnungsgemäß.\nEine virtuelle Maschine lässt sich nach einer Migration von ESXi 5.0 auf ESX/ESXi 3.5 nicht einschalten, wenn unter ESXi 5.0 Festplatten im laufenden Betrieb hinzugefügt werden.\nWenn ein Festplattengerät im laufenden Betrieb zu einer virtuellen Maschine mit Hardwareversion 4 auf einem ESXi 5.0-Host hinzugefügt wird, kann die virtuelle Maschine nach einer Migration auf einen ESX/ESXi 3.5-Host nicht eingeschaltet werden. Im Protokoll des ESX/ESXi 3.5-Hosts erscheint ein Eintrag ähnlich dem Folgenden: [msg.scsi.esx.filters] scsi0:1 Gerätefilter werden nicht unterstützt.Der Fehler tritt auf, weil der ESXi 5.0-Host fälschlicherweise eine leere SCSI-Filtereinstellung zur Konfiguration der virtuellen Maschine hinzufügt.\nUmgehung: Entfernen Sie alle Festplattenfiltereinträge aus der .vmx-Konfigurationsdatei der virtuellen Maschine, indem Sie die folgenden Aktionen durchführen:\nHeben Sie die Registrierung der virtuellen Maschine auf.\nÖffnen Sie die Konfigurationsdatei der virtuellen Maschine in einem Texteditor.\nEntfernen Sie alle Zeilen, die scsiX:Y.filtersenthalten.\nSpeichern Sie die Konfigurationsdatei der virtuellen Maschine.\nRegistrieren Sie die virtuelle Maschine.\nDas vCenter Server-Unterstützungspaket-Tool findet keine Protokolldaten, die in einem benutzerdefinierten Speicherort gespeichert sind\nDas vCenter Server-Unterstützungspaket-Tool findet keine Protokolldateien, die in einem benutzerdefinierten, nicht standardmäßigen Speicherort gespeichert sind. Das vCenter Server-Unterstützungspaket-Tool unterscheidet sich vom Erfassungs-Tool des vSphere-Clients.\nUmgehung: Verbinden Sie einen vSphere-Client mit vCenter Server und verwenden Sie die Funktion "Exportieren von Systemprotokollen", um die Protokolldaten abzurufen. Wählen Sie im vSphere-Client Verwaltung > Exportieren von Systemprotokollen.\nFalls Sie keine Verbindung zwischen einem vSphere-Client und vCenter Server herstellen können, müssen Sie die Dateien manuell in das Protokollpaket kopieren.\nIn vCenter Server 5.0 werden einige erweiterte Konfigurationsoptionen für vSphere HA nicht mehr unterstützt. Die folgenden Optionen werden nicht mehr unterstützt.\nFalls Sie versuchen, eine der nicht unterstützten Optionen festzulegen, meldet vCenter Server 5.0, dass die Option ungültig ist. Wenn Sie darüber hinaus ein Upgrade auf vCenter Server 5.0 von einer vorherigen Version durchführen, bei der eine oder mehrere dieser Optionen definiert sind, werden sie gelöscht und haben keine Auswirkung mehr.\nNach dem Ausschalten einer fehlertoleranten primären virtuellen Maschine schlägt das Entfernen des Hosts der sekundären virtuellen Maschine von einem vDS fehl. Wenn Sie eine fehlertolerante virtuelle Maschine ausschalten, sind die von deren sekundären virtuellen Maschine verwendeten Schatten-dvPorts im VMkernel noch vorhanden. Dies verhindert, dass der Host, auf dem die sekundäre virtuelle Maschine ausgeführt wird, aus dem vDS entfernt wird.\nUmgehung: Starten Sie den Host neu, um ihn vom vDS zu entfernen. Die Schatten-Ports werden nach dem Neustart entfernt.\nBei einem Hostausfall kann vSphere HA eine virtuelle Maschine nicht neu starten, die mit vMotion migriert wurde. Während des Migrierens einer virtuellen Maschine von einem Host auf einen anderen fällt der ursprüngliche Host möglicherweise aus, reagiert nicht mehr oder verliert den Zugriff auf den Datenspeicher, der die Konfigurationsdatei der virtuellen Maschine enthält. Wenn solch ein Ausfall auftritt und vMotion danach ebenfalls fehlschlägt, startet vSphere HA möglicherweise die virtuelle Maschine nicht neu und schützt sie möglicherweise nicht mehr.\nUmgehung: Wenn die virtuelle Maschine ausfällt und vSphere HA sie nicht wieder einschaltet, schalten Sie die virtuelle Maschine manuell ein. vSphere HA schützt dann die virtuelle Maschine wieder.\nWenn Sie RHEL 6 neu starten oder per PXE-Startvorgang starten, erscheint ein leerer Bildschirm\nWenn Sie versuchen, den Red Hat-Bootloader zu verwenden, um RHEL 6 in einer virtuellen EFI-Maschine per PXE-Startvorgang zu starten, wird der Bildschirm leer, nachdem das Betriebssystem ausgewählt wird. Dieses Problem tritt auch dann auf, wenn Sie in einer normalen Installation von RHEL 6 die Direktive splashscreenaus der Datei "grub.conf" entfernen und die virtuelle Maschine neu starten.\nUmgehung: Stellen Sie sicher, dass die Direktive splashscreenvorhanden ist und auf eine Datei verweist, auf die der Bootloader Zugriff hat.\nMehrere vNICs werden bei einem Neustart von Mac OS X 10.6.x willkürlich getrennt\nWenn Sie Mac OS X 10.6 neu starten, wird ein falscher Gastbetriebssystem-Verbindungsstatus für n >=3 e1000 vNICs angezeigt.\nBei n(e1000)=3 lautet der Gastbetriebssystem-Verbindungsstatus: 2 (verbunden), 1 (getrennt).\nBei n(e1000)=5 lautet der Gastbetriebssystem-Verbindungsstatus: 3 (verbunden), 2 (getrennt) usw.\nUmgehung: Verwenden Sie das Dienstprogramm "ifconfig", um die Adapter manuell zu aktivieren und zu deaktivieren. Die manuelle Aktivierung und Deaktivierung wird nach dem nächsten Neustartvorgang nicht beibehalten.\nIBM x3550 M2 Force Legacy Video on Boot muss deaktiviert werden\nIBM x3550 M2 hat eine Firmware-Option namens "Force Legacy Video on Boot", die INT10h-Videounterstützung beim Starten von der Unified Extensible Firmware Interface (UEFI) ermöglicht. Diese Option ist nicht kompatibel mit ESXi 5.0 und muss deaktiviert sein.\nUmgehung: Drücken Sie beim Starten von IBM x3550 M2 von UEFI F1, um in das Firmware-Setup zu gelangen, wählen Sie System Settings > Legacy Support > Force Legacy Video on Boot und klicken Sie auf Disable.\nBenutzer mit Benutzernamen, die Nicht-ASCII-Zeichen enthalten, können sich nicht über vSphere Web Client beim vCenter Server anmelden\nvSphere Web Client nimmt keine Benutzernamen an, die Nicht-ASCII-Zeichen enthalten. Benutzer mit Namen, die Nicht-ASCII-Zeichen enthalten, können vSphere Web Client zum Herstellen einer Verbindung mit vCenter Server nicht verwenden.\nUmgehung: Verwenden Sie den vSphere-Client zum Herstellen einer Verbindung mit vCenter Server.\nProbleme in Zusammenhang mit der lokalisierten Suche und mit lokalisierten Suchbereichen in der Hilfe zu vSphere Web Client\nZu den bekannten Problemen im Zusammenhang mit der lokalisierten Suche in der Hilfe zu vSphere Web Client gehören:\nSuchen unter Verwendung erweiterter Zeichen anderer Sprachen als Englisch führen zu keinen Ergebnissen.\nWenn die Namen von Suchbereichen Nicht-ASCII-Zeichen enthalten, werden diese Zeichen nicht korrekt dargestellt.\nUmgehung: Bearbeiten Sie die Datei "tomcat-server.xml", um UTF-8 als Zeichensatz für URIs anzugeben:\nÖffnen Sie die Datei Installationsverzeichnis_von_vSphere_Web_Client\_springsource-dm-server-2.0.4\_config\_tomcat-server.xmlmithilfe eines Texteditors.\nBearbeiten Sie den folgenden Abschnitt der Datei, um den Parameter URIEncoding="UTF-8"am Ende folgender Zeile hinzuzufügen: connectionTimeout="20000":\n9090 ist der Standardwert für den Connector-Port. Falls Sie diesen Wert während der Installation geändert haben, sehen Sie eine andere Portnummer. Ändern Sie die Portnummer nicht.\nNach der Änderung sieht der Abschnitt wie folgt aus:\nBearbeiten Sie den folgenden Abschnitt der Datei, um den Parameter URIEncoding="UTF-8"am Ende folgender Zeile hinzuzufügen: keystoreFile="config/keystore":\n9443 ist der Standardwert für den Connector-Port. Falls Sie diesen Wert während der Installation geändert haben, sehen Sie eine andere Portnummer. Ändern Sie die Portnummer nicht.\nMigrationsprobleme VMware HA- und Fault Tolerance-Probleme Gastbetriebssystemprobleme\nProbleme bei unterstützter Hardware Internationalisierungsprobleme Die Informationen auf der Registerkarte "Virtuelle Maschinen" werden möglicherweise nicht aktualisiert\nManchmal werden die Informationen auf der Registerkarte Virtuelle Maschinen des Sphere-Clients nicht sofort aktualisiert. Wenn Sie beispielsweise eine große Anzahl an virtuellen Maschinen klonen oder registrieren, werden einige virtuelle Maschinen möglicherweise nicht auf der Registerkarte Virtuelle Maschinen angezeigt, obwohl sie in der Bestandslistenstruktur vorhanden sind. Wenn Sie eine große Anzahl an virtuellen Maschinen ein- oder ausschalten, werden die neuen Betriebszustände möglicherweise nicht auf der Registerkarte Virtuelle Maschinen angezeigt, obwohl sie in der Bestandslistenstruktur ordnungsgemäß angezeigt werden.\nUmgehung: Drücken Sie F5, um die Informationen auf dieser Registerkarte zu aktualisieren.\nDie Webkonsole der VMware vCenter Server-Appliance bietet Optionen für das Konfigurieren von IPv6, obwohl IPv6 nicht unterstützt wird\nObwohl die VMware vCenter Server-Appliance IPv6 nicht unterstützt, steht auf der Registerkarte Netzwerk der Webkonsole der VMware vCenter Server-Appliance eine Konfigurationsoption für IPv6 und eine IPv6-Adresse wird standardmäßig der Appliance zugewiesen, wenn sich ein DHCPv6-Server im Netzwerk befindet.\nUmgehung: Geben Sie eine ungültige statische IPv6-Adresse für die VMware vCenter Server-Appliance ein, um zu verhindern, dass die Appliance eine IPv6-Adresse über DHCP bezieht.\nUnter Windows Server 2008 wird vSphere Web Client nicht in Internet Explorer 9 geladen\nWenn Sie unter Windows Server 2008 versuchen, vSphere Web Client in Internet Explorer 9 zu laden, sehen Sie nur einen blauen Hintergrund im Fenster des Webbrowsers und es passiert nichts.\nUmgehung: Verwenden Sie unter Windows Server 2008 Internet Explorer 7 bzw. 8 oder Mozilla Firefox 3.6 oder höher, um auf vSphere Web Client zuzugreifen.\nDer Zustand von vSphere Web Client wird zwischen Sitzungen nicht beibehalten\nDer Zustand von vSphere Web Client wird normalerweise zwischen Sitzungen beibehalten, sodass, wenn Sie sich erneut bei vSphere Web Client anmelden, dieselben Objekte und Registerkarten ausgewählt sind, die ausgewählt waren, als Sie sich von der vorherigen Sitzung abgemeldet haben. Wenn jedoch Ihre Webbrowser-Voreinstellungen so festgelegt sind, dass der Browser den Verlauf nicht speichert, oder die Website-Speichereinstellungen des Flash Players keinen Arbeitsspeicher für besuchte Sites zuteilen, speichert der Flash Player keine Daten von vSphere Web Client und der Zustand wird von Sitzung zu Sitzung nicht beibehalten.\nUmgehung: Führen Sie das folgende Verfahren durch:\nNavigieren Sie zu http://www.macromedia.com/support/documentation/de/flashplayer/help/settings_manager07.html und stellen Sie sicher, dass die Menge des Arbeitsspeichers auf einen Wert anders als Keinen festgelegt ist.\nWenn Sie den Firefox-Browser verwenden, legen Sie die Einstellungen für den Browserverlauf fest: Wählen Sie Extras > Einstellungen.\nWählen Sie eine Option außer Niemals anlegen.\nvSphere Web Client produziert in Abständen den Fehler 2406: Die geladene Datei verfügt über keine gültige Signatur\nBei Verwendung von Mozilla Firefox 3.6.x auf SUSE Linux Enterprise Server 11 oder Red Hat Enterprise Linux 5 tritt in Abständen die folgende Fehlermeldung auf: Fehler 2406: Die geladene Datei verfügt über keine gültige Signatur.\nStarten Sie den Webbrowser neu und stellen Sie eine neue Verbindung zu vSphere Web Client her.\nvCenter Server stürzt beim Exportieren von Systemprotokollen ab\nWenn Sie Systemprotokolle von vCenter Server exportieren, verwendet vCenter Server den in der Windows-Umgebungsvariablen TEMPangegebenen Ordner. Standardmäßig wird diese Variable auf C:\_Windows\_Tempfestgelegt.\nWenn vCenter Server zum Speichern einer großen Menge an Protokolldaten konfiguriert ist oder wenn Sie eine große Anzahl an Hosts auswählen, von denen Protokolle heruntergeladen werden sollen, kann es passieren, dass das in der TEMP-Variablen angegebene Laufwerk über keinen Speicherplatz mehr verfügt. Falls es sich bei diesem Laufwerk um dasselbe Laufwerk handelt, auf dem vCenter Server installiert ist, stürzt der VMware VirtualCenter Server-Dienst möglicherweise ab.\nUmgehung: Stellen Sie sicher, dass das in der Windows-Umgebungsvariablen TEMPangegebene Laufwerk über genügend freien Speicherplatz für exportierte Protokolle verfügt. Ziehen Sie in Betracht, ein anderes Laufwerk als C:in der TEMP-Variablen zu verwenden, um eine Unterbrechung der Systemdienste zu verhindern.\nBei der Suche im vSphere-Client oder in vSphere Web Client werden veraltete Ergebnisse angezeigt oder es kommt zu einer Zeitüberschreitung\nWenn Sie die Bestandsliste im vSphere-Client oder in vSphere Web Client durchsuchen, werden möglicherweise veraltete Informationen angezeigt. Bei der Verwendung von vSphere Web Client kann es außerdem zu einer Zeitüberschreitung kommen.\nDie folgende Fehlermeldung deutet auf einen unerwarteten Laufzeitfehler in der Protokolldatei ds.logdes Bestandslistendiensts hin:\nUmgehung: Starten Sie den Bestandslistendienst neu. Führen Sie für ein vCenter Server-System unter Windows die folgenden Schritte durch:\nStarten Sie Windows Service Manager: Wählen Sie Start > Ausführen.\nGeben Sie services.msc\nKlicken Sie mit der rechten Maustaste auf den vCenter Inventory Service und wählen Sie Neustart.\nFühren Sie für die vCenter Server-Appliance die folgenden Schritte durch: Melden Sie sich bei der VMware vCenter Server Appliance Web-Konsole an.\nWählen Sie auf der Registerkarte vCenter Server die Option Status aus.\nKlicken Sie auf vCenter beenden.\nKlicken Sie auf vCenter starten.\nSonstige Probleme Der Speicherort der Protokolldateien hat sich von /var/login /var/run/loggeändert\nDie ESXi 5.0-Protokolldateien befinden sich im Verzeichnis /var/run/log. Um abwärtskompatibel zu sein, enthält die Protokolldatei Links von dem vorherigen Speicherort, /var/log, auf die neuesten Protokolldateien im aktuellen Speicherort, /var/run/log. Die Protokolldatei enthält keine Links auf rotierte Protokolldateien.\nNach der Deinstallation von VMware Tools mithilfe des TAR-Installationsprogramms können Sie auf virtuellen Linux-Maschinen keine OSPs installieren\nNach der Deinstallation von VMware Tools, die mithilfe des TAR-Installationsprogramms auf einer virtuellen Linux-Maschine installiert wurden, verbleiben Dateien auf dem System. In dieser Situation können Sie keine OSPs installieren.\nUmgehung: Führen Sie den folgenden Befehl aus: rm -rf /usr/lib/vmware-tools /etc/vmware-tools\nWenn in den LAN-Einstellungen von Internet Explorer ein Proxy-Server aktiviert ist, kann PowerCLI manchmal kein Online-Depot hinzufügen\nEin Online-Depot kann in PowerCLI mithilfe des cmdlets Add-ESXSoftwareDepothinzugefügt werden. Unter bestimmten Bedingungen, bei denen der Proxy-Server für die verwendete Maschine aktiviert ist, kann PowerCLI das Online-Depot in der Sitzung nicht hinzufügen.\nDieser Fehler kann nur dann auftreten, wenn alle folgenden Bedingungen erfüllt sind.\nDie Site des Kunden benötigt einen HTTP-Proxy-Server für den Zugriff auf das Web.\nDer Kunde hostet ein Depot im internen Netzwerk.\nDer Proxy-Server des Kunden kann keine Verbindung zum Depot im internen Netzwerk herstellen.\nUmgehung: Deaktivieren Sie den Proxy-Server in den LAN-Einstellungen von Internet Explorer. Fügen Sie das Online-Depot in PowerCLI hinzu.