VMware ESXi™ 5.1 | 10. September 2012 | Build 799733

VMware vCenter Server™ 5.1 | 10. September 2012 | Build 799731

vCenter Server Appliance 5.1 | 10. September 2012 | Build 799730

Überprüfen Sie, ob Erweiterungen und Updates für diese Versionshinweise zur Verfügung stehen.

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

Neuigkeiten

Diese Version von VMware vSphere 5.1 umfasst ESXi 5.1 und vCenter Server 5.1. Weitere Informationen über die neuen und erweiterten Funktionen in dieser Version finden Sie unter Neuheiten bei VMware vSphere 5.1.

Internationalisierung

VMware vSphere 5.1 ist in den folgenden Sprachen verfügbar:

  • Englisch
  • Französisch
  • Deutsch
  • Japanisch
  • Koreanisch
  • Vereinfachtes Chinesisch

Kompatibilität und Installation

ESXi, vCenter Server und vSphere Web Client – Versionskompatibilität

Die VMware-Produkt-Interoperabilitätmatrix liefert Details zur Kompatibilität aktueller und vorheriger Versionen von VMware vSphere-Komponenten, einschließlich ESXi, VMware vCenter Server, vSphere Web 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.

Die ZIP-Datei mit vCenter Server und den Modulen enthält auch den vSphere Web Client und den vSphere-Client. Sie können mithilfe des VMware vCenter™-Installationsassistenten einen oder beide Clients installieren.

Hardwarekompatibilität für ESXi

Um herauszufinden, welche Prozessoren, Speichergeräte, SAN-Arrays und E/A-Geräte mit vSphere 5.1 kompatibel sind, lesen Sie die Informationen zu ESXi 5.1 im VMware-Kompatibilitätshandbuch.

Die Liste der unterstützten Prozessoren wurde für diese Version erweitert. Informationen dazu, welche Prozessoren mit dieser Version kompatibel sind, finden Sie im VMware-Kompatibilitätshandbuch.

Kompatibilität von Gastbetriebssystemen für ESXi

Verwenden Sie die ESXi 5.1-Informationen im VMware-Kompatibilitätshandbuch, um herauszufinden, welche Gastbetriebssysteme mit vSphere 5.1 kompatibel sind.

Ab vSphere 5.1 wurden Support-Level-Änderungen für ältere Gastbetriebssysteme eingeführt. Beschreibungen der unterschiedlichen Support-Levels finden Sie im Knowledgebase-Artikel 2015161. Das VMware-Kompatibilitätshandbuch bietet detaillierte Informationen über alle Betriebssystem- und VMware-Produktversionen.

Die folgenden Gastbetriebssystemversionen, die von ihren jeweiligen Anbietern nicht weiter unterstützt werden, laufen aus. Künftige Versionen von vSphere werden diese Gastbetriebssysteme nicht unterstützen, obwohl vSphere 5.1 sie noch unterstützt.

  • Windows NT
  • Alle 16-Bit-Versionen von Windows und DOS (Windows 98, Windows 95, Windows 3.1)
  • Debian 4.0 und 5.0
  • Red Hat Enterprise Linux 2.1
  • SUSE Linux Enterprise 8
  • SUSE Linux Enterprise 9 vor SP4
  • SUSE Linux Enterprise 10 vor SP3
  • SUSE Linux Enterprise 11 vor SP1
  • Ubuntu-Versionen 8.04, 8.10, 9.04, 9.10 und 10.10
  • Alle Versionen von Novell Netware
  • Alle Versionen von IBM OS/2

Kompatibilität von virtuellen Maschinen für ESXi

Virtuelle Maschinen, die mit ESX 3.x und höher (Hardwareversion 4) kompatibel sind, werden von ESXi 5.1 unterstützt. Virtuelle Maschinen, die mit ESX 2.x und höher (Hardwareversion 3) kompatibel sind, werden nicht mehr unterstützt. Wenn Sie solche virtuellen Maschinen unter ESXi 5.1 verwenden möchten, führen Sie ein Upgrade der VM-Kompatibilität durch. Weitere Informationen finden Sie in der vSphere-Upgrade-Dokumentation.

vSphere-Client-Verbindungen zu Umgebungen im verknüpften Modus mit vCenter Server 5.x

vCenter Server 5.1 kann sich nur zusammen mit anderen Instanzen von vCenter Server 5.1 im verknüpften Modus befinden.

Installationshinweise für diese Version

Weitere Informationen zum Installieren und Konfigurieren von ESXi und vCenter Server finden Sie im Installations- und Einrichtungshandbuch für vSphere.

Wenngleich die Installation unkompliziert ist, sind viele der nachfolgenden Konfigurationsschritte äußerst wichtig. Lesen Sie insbesondere die folgenden Abschnitte:

Migrieren von Drittanbieter-Lösungen

Sie können bei einem Host-Upgrade keine Lösungen von Drittanbietern, die auf einem ESX- oder ESXi-Host installiert sind, direkt migrieren. Architektonische Änderungen zwischen ESXi 5.0 und ESXi 5.1 führen zu einem Verlust von Drittanbieter-Komponenten und einer möglichen Systeminstabilität. Zur Ausführung solcher Migrationen können Sie mit Image Builder eine benutzerdefinierte ISO-Datei erstellen. Weitere Informationen zum Upgrade mit Drittanbieter-Anpassungen finden Sie in der vSphere Upgrade-Dokumentation. Weitere Informationen zur Verwendung von Image Builder zur Erstellung einer benutzerdefinierten ISO-Datei finden Sie im Installations- und Einrichtungshandbuch für vSphere.

Upgrades und Installationen nicht zulässig für nicht unterstützte CPUs

vSphere 5.1 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.1 durchgeführt. Falls Ihre Hosthardware nicht kompatibel ist, wird ein violetter Bildschirm mit einer Inkompatibilitätsmeldung angezeigt und Sie können vSphere 5.1 nicht installieren bzw. kein Upgrade auf vSphere 5.1 durchführen.

Upgrades für diese Version

Informationen zur Durchführung eines Upgrades von vCenter Server und ESXi-Hosts finden Sie im vSphere-Upgrade-Handbuch.

Testversionen von vSphere 5.1
Upgrades von den vSphere 5.1 Beta- und den vSphere 5.0 Release-Kandidat-Versionen auf vSphere 5.1 werden nicht unterstützt. Deinstallieren Sie ESXi 5.1 Beta bzw. den Release-Kandidaten und vCenter Server 5.1 Beta oder den Release-Kandidaten und führen Sie eine Neuinstallation von vCenter Server 5.1 und ESXi 5.1 durch. Sofern Sie Beta- oder Release-Kandidat-Versionen von vSphere 5.1 getestet haben, wird empfohlen, die Daten, die Sie aus den Konfigurationen auf vSphere 5.1 beibehalten möchten, neu zu erstellen.

vCenter Server-Upgrades

vSphere 5.1 unterstützt die folgenden Upgrade-Szenarien.

  • Sie können In-Place-Upgrades auf 64-Bit-Systemen von vCenter Server 4.x und vCenter Server 5.0 auf vCenter Server 5.1 durchführen.
    Sie können kein Upgrade einer Instanz von vCenter Server 4.x durchführen, der unter Windows XP Professional x64 Edition ausgeführt wird.

  • Kunden mit VirtualCenter 2.5 Update 6 und höher mit einem 32-Bit-Betriebssystem müssen aufgrund der Unterschiede von 32 und 64 Bit als ersten Schritt des Upgrade-Vorgangs ein Migrations-Upgrade auf vCenter Server 5.0 durchführen. Nach Durchführung dieses Migrations-Upgrades können Kunden ein In-Place-Upgrade von Version 5.0 auf Version 5.1 durchführen. Weitere Informationen dazu finden Sie in der Dokumentation vSphere-Upgrade der Version 5.0.

  • vCenter Server 5.1 kann auch ESX/ESXi 5.x-Hosts in demselben Cluster mit ESX/ESXi 4.x-Hosts verwalten. vCenter Server 5.1 kann ESX 2.x- und ESX 3.x-Hosts nicht verwalten.

ESX/ESXi-Upgrades

vSphere 5.1 bietet die folgenden Tools für Upgrades von ESX/ESXi-Hosts:

  • vSphere Update Manager. Sie können vSphere Update Manager zum Durchführen eines Upgrades oder eines Updates und zum Patchen von Clusterhosts und virtuellen Maschinen verwenden. Wenn Ihre Site vCenter Server verwendet, empfiehlt VMware die Verwendung von vSphere Update Manager. Lesen Sie zum Durchführen eines koordinierten Host-Upgrades oder eines koordinierten Upgrades von virtuellen Maschinen die Anleitung in der Dokumentation vSphere-Upgrade. Die vollständige Dokumentation für vSphere Update Manager finden Sie im Handbuch Installieren und Verwalten von VMware vSphere Update Manager.

  • Durchführen eines interaktiven Upgrades mithilfe eines ESXi-Installer-ISO-Images auf CD-ROM, DVD oder einem USB-Flash-Laufwerk. Sie können das ESXi 5.1-Installationsprogramm von einer CD-ROM, DVD oder einem USB-Flash-Laufwerk aus starten, um ein interaktives Upgrade durchzuführen. Diese Methode eignet sich für eine kleine Anzahl an Hosts.

  • Durchführen eines skriptbasierten Upgrades. Sie können ein Upgrade oder eine Migration von ESX/ESXi 4.x- und ESXi 5.0.x-Hosts auf ESXi 5.1 durchführen, indem Sie ein Update-Skript aufrufen, das für ein effizientes, unbeaufsichtigtes Upgrade sorgt. 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.

  • vSphere Auto Deploy. Wenn Ihr ESXi 5.0.x-Host mit vSphere Auto Deploy bereitgestellt wurde, können Sie Auto Deploy zum erneuten Bereitstellen des Hosts verwenden, indem Sie ihn mit einem neuen Image-Profil neu starten, das das ESXi-Upgrade enthält.

  • esxcli. Sie können mithilfe des esxcli-Befehlszeilendienstprogramms für ESXi ein Upgrade auf ESXi 5.0.x durchführen und Patches auf ESXi 5.0.x-Hosts anwenden, um ESXi 5.1 von einem Download-Depot auf vmware.com oder von einer heruntergeladenen ZIP-Datei eines von einem VMware-Partner vorbereiteten Depots aus zu installieren. Sie können esxclizum Durchführen eines Upgrades von ESX- oder ESXi-Hosts auf Version 5.x von ESX/ESXi-Versionen vor Version 5.0 verwenden.

Open Source-Komponenten für VMware vSphere 5.1

Informationen über Copyright und Lizenzen für die Open Source-Komponenten, die im Lieferumfang von vSphere 5.1 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.

Hinweise zu Produktunterstützung

  • vSphere-Client. In vSphere 5.1 werden alle neuen vSphere-Funktionen nur über den vSphere Web Client zur Verfügung gestellt. Der herkömmliche vSphere-Client wird weiterhin betrieben und den gleichen Funktionsumfang wie vSphere 5.0 unterstützen, jedoch keine der neuen Funktionen in vSphere 5.1 freilegen.

    vSphere 5.1 und die nachfolgenden Update- und Patch-Versionen sind die letzten Versionen, die den herkömmlichen vSphere-Client enthalten. Zukünftige Hauptversionen von VMware vSphere enthalten nur den vSphere Web Client.

    Bei vSphere 5.1 sind die Fehlerkorrekturen für den herkömmlichen vSphere-Client auf sicherheitsrelevante und kritische Probleme beschränkt. Bei kritischen Fehlern handelt es sich um Abweichungen von der angegebenen Produktfunktionalität, die zur Beschädigung und zum Verlust von Daten, zu Systemausfällen oder zu wesentlichen Ausfällen von Kundenanwendungen führen, bei denen es keine Umgehung gibt, die implementiert werden kann.

  • VMware Toolbox. vSphere 5.1 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.

  • VMI-Paravirtualisierung. vSphere 4.1 war die letzte Version, die die Paravirtualisierungsschnittstelle des VMI-Gastbetriebssystems unterstützt. Weitere Informationen zum Migrieren von VMI-fähigen virtuellen Maschinen, sodass sie auf künftigen Versionen von vSphere lauffähig sind, finden Sie im Knowledgebase-Artikel 1013842.

  • Anpassung von Windows-Gastbetriebssystemen. vSphere 5.1 ist die letzte Version, die die Anpassung von Windows 2000-Gastbetriebssystemen unterstützt. VMware wird weiterhin Anpassungen von neueren Versionen von Windows-Gastbetriebssystemen unterstützen.

  • VMCI-Sockets. Gastbetriebssystem-zu-Gastbetriebssystem-Kommunikationen (VM zu VM) sind in vSphere 5.1 auslaufend. Diese Funktionalität wird in der nächsten Hauptversion entfernt. VMware wird weiterhin die Host-zu-Gastbetriebssystem-Kommunikation unterstützen.

Bekannte Probleme

Die bekannten Probleme gliedern sich in folgende Gruppen.

Installationsprobleme
  • Bei der statusorientierten Auto Deploy-Installation kann das Argument "firstdisk" von "esx" auf Systemen nicht verwendet werden, die ESX/ESXi bereits auf USB installiert haben
    Sie konfigurieren das Hostprofil für einen Host, den Sie für die statusorientierte Installation mit Auto Deploy einrichten möchten. Als Teil der Konfiguration wählen Sie USB als Festplatte und geben "esx" als erstes Argument ein. Auf dem Host ist derzeit ESX/ESXi auf USB installiert. Anstelle der Installation von ESXi auf USB installiert Auto Deploy ESXi auf der lokalen Festplatte.

    Umgehung: Keine.

  • Die Auto Deploy PowerCLI-cmdlets "Copy-DeployRule" und "Set-DeployRule" benötigen ein Objekt als Eingabe
    Wenn Sie das cmdlet Copy-DeployRuleoder Set-DeployRuleausführen und ihm den Namen eines Image-Profils oder ein Hostprofils übergeben, tritt ein Fehler auf.

    Umgehung: Übergeben Sie ihm das Image-Profil- bzw. Hostprofilobjekt.

  • Das Anwenden eines Hostprofils, das für die Verwendung von Auto Deploy mit statusfreiem Caching eingerichtet ist, schlägt fehl, wenn ESX auf der ausgewählten Festplatte installiert ist
    Sie verwenden Hostprofile, um Auto Deploy mit aktiviertem statusfreiem Caching einzurichten. Sie wählen im Hostprofil eine Festplatte aus, auf der eine Version von ESX (nicht ESXi) installiert ist. Wenn Sie das Hostprofil anwenden, wird eine Fehlermeldung mit dem folgenden Text angezeigt.
    2 Bootbanks erwartet, 0 gefunden

    Umgehung: Entfernen Sie die ESX-Software von der Festplatte oder wählen Sie eine andere Festplatte für die Verwendung des statusfreien Cachings aus.

  • vSphere Auto Deploy funktioniert nicht mehr, wenn die IP-Adresse der Maschine, die den Auto Deploy-Server hostet, geändert wurde
    Sie installieren Auto Deploy auf einer anderen Maschine als vCenter Server und ändern die IP-Adresse der Maschine, die den Auto Deploy-Server hostet. Nach der Änderung funktionieren die Auto Deploy-Befehle nicht mehr.

    Umgehung: Starten Sie den Auto Deploy-Server-Dienst neu.
    net start vmware-autodeploy-waiter
    Falls nach einem Neustart des Diensts das Problem nicht behoben wurde, müssen Sie möglicherweise den Auto Deploy-Server neu registrieren. Führen Sie den folgenden Befehl unter Angabe aller Optionen aus.
    autodeploy-register.exe -R -a vCenter-IP -p vCenter-Port -u user_name -w password -s setup-file-path

  • Die vDS-Konfiguration schlägt für mit Auto Deploy gestartete ESXi-Systeme fehl
    In einem Cluster können nur zwei Hosts eine virtuelle Maschine ausführen, die für Fault Tolerance (FT) aktiviert ist. Einer der Hosts wird mit Auto Deploy neu gestartet. Die vDS-Konfiguration schlägt fehl und der Host verbleibt im Wartungsmodus, nachdem er erneut mit dem vCenter Server-System verbunden wurde.
    Dies geschieht, wenn nur das ESXi-System, das neu gestartet wird, die sekundäre virtuelle Maschine hosten kann. Der Fault Tolerance-Vorgang fügt die sekundäre virtuelle Maschine zur Bestandsliste des ESXi-Hosts hinzu, die gestartet wird, und die vDS-Migration schlägt mit einem Fehler des Typs Die Ressource ist in Gebrauchfehl.
    Das Problem wurde in den folgenden Situationen beobachtet:

    • Während der Durchführung eines Upgrades von ESXi-Hosts, die sich in einem Cluster befinden.
    • Wenn viele Hosts in einem Cluster gleichzeitig neu gestartet werden, sodass nur ein oder zwei Hosts vollständig gestartet sind.
    • In einem kleinen Cluster (zwei oder drei Hosts).

    Umgehung: Falls das Problem während der Durchführung eines Upgrades auftritt, deaktivieren Sie vorübergehend Fault Tolerance auf den virtuellen Maschinen. Die virtuellen Maschinen können auf den Host migriert werden, für den bereits ein Upgrade durchgeführt wurde. Nach Abschluss des Upgrade-Vorgangs aktivieren Sie Fault Tolerance erneut.
    Falls das Problem auftritt, wenn in einem kleinen Cluster mehrere Hosts neu gestartet werden, warten Sie, bis mehrere Hosts gestartet wurden, und starten Sie den betroffenen Host neu. Zudem können Sie Fault Tolerance für die virtuelle Maschine deaktivieren, deren sekundäre virtuelle Maschine dem betroffenen Host zugewiesen ist.

  • Auf HP DL980 G7 werden ESXi-Hosts nicht mit Auto Deploy gestartet, wenn Onboard-Netzwerkkarten verwendet werden
    Sie können ein HP DL980 G7-System mit Auto Deploy nicht starten, wenn das System die Onboard-Netzwerkkarten (LOM Netxen) für den Start per PXE verwendet.

    Umgehung: Installieren Sie auf dem Host eine von HP genehmigte Add-On-Netzwerkkarte, z. B. HP NC3 60T, und verwenden Sie diese Netzwerkkarte für den Start per PXE.

  • Das Installieren von vCenter Server und verwandten Komponenten schlägt fehl, wenn der Benutzername des angemeldeten Benutzers Nicht-ASCII-Zeichen enthält
    Wenn der Benutzername des aktuell angemeldeten Benutzers Nicht-ASCII-Zeichen enthält, schlägt das Installieren von vCenter Server, vCenter Inventory Server, vCenter Single Sign On oder vSphere Web Client mit der folgenden Fehlermeldung fehl: Der Benutzername enthält Zeichen, die nicht im ASCII-Zeichensatz enthalten sind. Geben Sie zur Anmeldung einen Benutzernamen an, der ausschließlich ASCII-Zeichen enthält.

    Umgehung: Melden Sie sich mit einem Benutzernamen an, der keine Nicht-ASCII-Zeichen enthält, und wiederholen Sie den Installationsvorgang.

  • Das Installieren von Auto Deploy schlägt fehl, wenn der Installationspfad Nicht-ASCII-Zeichen enthält
    Falls Sie einen Ordner auswählen, dessen Name Nicht-ASCII-Zeichen enthält, wenn Sie das Installationsprogramm von Auto Deploy ausführen, tritt der folgende Fehler auf
    : Fehler 29106. Unbekannter Fehler.

    Umgehung: Wählen Sie einen Ordner aus, dessen Pfadangabe nur ASCII-Zeichen enthält.

  • Ein Live-Update mit esxcli schlägt mit einem VibDownloadError fehl
    Ein Benutzer führt zwei Updates hintereinander folgendermaßen durch.

    1. Ein Live-Update mit dem esxcli-Softwareprofil-Update oder dem VIB-Update-Befehl esxcli.
    2. Ein Update, das einen Neustart erfordert.

    Die zweite Transaktion schlägt fehl. Eine häufige Ursache liegt in der Verifizierung der Signatur, die nur dann überprüft werden kann, nachdem das VIB heruntergeladen wurde.

    Umgehung: Der Fehler kann in zwei Schritten behoben werden.

    1. Starten Sie den ESXi-Host neu, um dessen Zustand zu bereinigen.
    2. Wiederholen Sie die Live-Installation.

  • ESXi-Skriptinstallation kann die Kickstart-Datei (ks) auf dem CD-ROM-Laufwerk nicht finden, wenn keine Netzwerkkarten mit der Maschine verbunden sind
    Wenn sich die Kickstart-Datei auf einem CD-ROM-Laufwerk eines Systems befindet, mit dem keine Netzwerkkarten verbunden sind, wird die folgende Fehlermeldung vom Installationsprogramm angezeigt: Kickstart-Datei auf CD-ROM mit Pfad < path_to_ks_file>wurde nicht gefunden.

    Umgehung: Verbinden Sie die Netzwerkkarten neu, um die Netzwerkverbindung herzustellen, und wiederholen Sie die Installation.

  • Der Webservice "VMware VirtualCenter Management" wird nicht gestartet, wenn vCenter Server an einem Speicherort installiert wurde, dessen Name die Sonderzeichen !, @ oder # enthält
    Wenn der Installationspfad von vCenter Server die Sonderzeichen !, @ oder # enthält, wird vCenter Server zwar ordnungsgemäß installiert, aber der Webservice "VMware VirtualCenter Management" wird nicht gestartet und das Anmelden beim vCenter Server schlägt mit dem Fehler Keine ausreichenden Berechtigungenfehl. Beispiel: Beim folgenden Installationspfad würde der Fehler auftreten: C:\VMware!@SingleSign@On!#$Installer.

    Umgehung: Installieren Sie vCenter Server am Standardspeicherort oder an einem benutzerdefinierten Speicherort ohne Sonderzeichen.

  • Skriptinstallation schlägt auf der SWFCoE-LUN fehl
    Wenn das ESXi-Installationsprogramm die Installation unter Verwendung der Kickstart-Datei (ks) durchführt, sind zu dem Zeitpunkt, an dem die Installation gestartet wird, noch nicht alle FCoE-LUNs geprüft und ausgefüllt worden. Dies führt dazu, dass die Skriptinstallation auf einer LUN fehlschlägt. Das Problem tritt auf, wenn das HTTPS-, HTTP- oder FTP-Protokoll für den Zugriff auf die Kickstart-Datei verwendet wird.

    Umgehung: Fügen Sie im Abschnitt %preder Kickstart-Datei eine sleep-Anweisung von zwei Minuten ein:
    %pre --interpreter=busybox
    sleep 120

  • Das Installieren des vCenter Single Sign On-Servers schlägt auf Systemen fehl, auf denen IBM DB2 9.7 Fix Pack 1 oder früher ausgeführt wird
    Komponenten von Single Sign On (SSO) benötigen DB2 9.7 Fix Pack 2 oder höher. Wenn Sie versuchen, SSO auf einem System zu installieren, auf dem Vorgängerversionen von DB2 9.7 ausgeführt werden, schlägt die Installation fehl.

    Umgehung: Führen Sie ein Update der DB2 9.7-Instanz auf Fix Pack 2 oder höher durch.

  • Beim Durchführen eines Upgrades von vCenter Server ohne gleichzeitiges Upgrade des Auto Deploy-Servers können Probleme auftreten
    Wenn Sie ein Upgrade von vCenter Server durchführen, ersetzt vCenter Server den vSphere 5.0-HA-Agenten (vmware-fdm) auf jedem ESXi-Host durch einen neuen Agenten. Das Ersetzen wird bei jedem Neustart eines ESXi-Hosts vorgenommen. Wenn vCenter Server nicht zur Verfügung steht, können die ESXi-Hosts keinem Cluster beitreten.

    Umgehung: Führen Sie, falls möglich, ein Upgrade des Auto Deploy-Servers durch.
    Wenn ein Upgrade vom Auto Deploy-Server nicht möglich ist, können Sie Image Builder PowerCLI-cmdlets verwenden, die in vSphere PowerCLI enthalten sind, um ein ESXi 5.0-Image-Profil zu erstellen, das die neue vmware-fdm-VIB umfasst. Sie können Ihre Hosts mit diesem Imageprofil versehen.

    1. Fügen Sie das ESXi 5.0-Software-Depot und das Software-Depot hinzu, das das neue vmware-fdm-VIB enthält.
      Add-EsxSoftwareDepot C:\ Path\VMware-Esxi-5.0.0- buildnumber-depot.zip Add-EsxSoftwareDepot http:// vcenter server/vSphere-HA-depot
    2. Klonen Sie das vorhandene Image-Profil und fügen Sie das vmware-fdm-VIB hinzu.
      New-EsxImageProfile -CloneProfile "ESXi-5.0.0- buildnumber-standard" -name " Imagename" Add-EsxSoftwarePackage -ImageProfile " ImageName" -SoftwarePackage vmware-fdm
    3. Erstellen Sie eine neue Regel, die Ihren Hosts das neue Image-Profil zuweist, und fügen Sie die Regel dem Regelsatz hinzu.
      New-DeployRule -Name " Rule Name" -Item " Image Name" -Pattern " my host pattern" Add-DeployRule -DeployRule " Rule Name"
    4. Führen Sie einen Vorgang zum Testen und Reparieren von Übereinstimmungen für die Hosts durch.
      Test-DeployRuleSetCompliance Host_list

  • Wenn das statusfreie Caching aktiviert ist und der Auto Deploy-Server nicht zur Verfügung steht, startet der Host möglicherweise nicht automatisch mithilfe des gespeicherten Images
    In manchen Fällen startet ein Host, der für das statusfreie Caching mit Auto Deploy eingerichtet ist, nicht automatisch von der Festplatte, auf der sich das gespeicherte Image befindet, wenn der Auto Deploy-Server nicht zur Verfügung steht. Die kann auch dann passieren, wenn das gewünschte Startgerät in der logischen Startreihenfolge als Nächstes steht. Was sich tatsächlich ereignet, hängt von den BIOS-Einstellungen des Serveranbieters ab.

    Umgehung: Wählen Sie die Festplatte mit dem zwischengespeicherten Image als Startgerät manuell aus.

  • Die Installation schlägt fehl, wenn Sie vCenter Single Sign On mit einer lokalen Datenbank auf einer türkischen Version von Windows 2008 R2 64-Bit installieren
    Möglicherweise tritt ein Fehler auf (Fehler 20003 oder 20010), wenn Sie vCenter Single Sign On in einer türkischen Windows-Umgebung installieren und sich die Datenbank auf dem lokalen System befindet. Dieser Fehler tritt auf, wenn Microsoft SQL Server bestimmte Buchstaben groß schreibt, was zur Folge hat, dass die Datenbank nicht kompatibel mit vCenter Single Sign On ist.

    Umgehung:

    1. Installieren Sie die Datenbank auf einem separaten System, auf dem eine englische Version von Windows 2008 Server ausgeführt wird.
    2. Führen Sie das vCenter Single Sign On-Installationsprogramm auf dem System aus, auf dem die türkische Version von Windows 2008 Server ausgeführt wird.
    3. Stellen Sie remote eine Verbindung zur Datenbank her.

  • Installation von vCenter Single Sign On im Hochverfügbarkeits- oder Wiederherstellungsmodus schlägt fehl, wenn sich das Master-Kennwort vom Administratorkennwort unterscheidet
    Das folgende Verhalten wird beobachtet, wenn Sie vCenter Single Sign On im Hochverfügbarkeitsmodus installieren:

    • Wenn Sie das richtige vCenter Single Sign On-Administratorkennwort angeben, verläuft die Validierung anscheinend erfolgreich, aber die Installation schlägt mit einer Fehlermeldung fehl, die besagt, dass das vCenter Single Sign On-Master-Kennwort falsch ist.
    • Wenn Sie das richtige vCenter Single Sign On-Master-Kennwort angeben, schlägt die Validierung fehl, weil das Installationsprogramm das vCenter Single Sign On-Administratorkennwort erwartet.

    Das folgende Verhalten wird beobachtet, wenn Sie vCenter Single Sign On im Wiederherstellungsmodus installieren:

    • Wenn Sie das richtige vCenter Single Sign On-Administratorkennwort angeben, schlägt die Installation mit einer Fehlermeldung fehl, die besagt, dass das vCenter Single Sign On-Master-Kennwort falsch ist.
    • Wenn Sie vCenter Single Sign On auf einer Domänenmaschine installieren und Sie das richtige vCenter Single Sign On-Master-Kennwort angeben, schlägt die Installation mit einer Fehlermeldung fehl, die besagt, dass das SSPI Service-Konto nicht konfiguriert werden kann, weil das Installationsprogramm das vCenter Single Sign On-Administratorkennwort erwartet.
    • Wenn Sie Single Sign On auf einer Arbeitsgruppenmaschine installieren, schlägt die Installation mit einer Fehlermeldung fehl, die besagt, dass die Konfiguration des Lookup Service fehlgeschlagen ist. Die Protokolldatei enthält eine Fehlermeldung, die besagt, dass das vCenter Single Sign On-Administratorkennwort falsch ist.

    Umgehung: Vergewissern Sie sich, dass das gleiche Kennwort als vCenter Single Sign On-Master-Kennwort und als vCenter Single Sign On-Administratorkennwort verwendet wird. Sie können die Kennwörter unter Verwendung der folgenden Befehle überprüfen. Der standardmäßige SSO-Server-Ordner <ssoserver folder> ist in der Regel "C:\Programme\VMware\Infrastructure\SSOServer".

    • vCenter Single Sign On-Master-Kennwort:
      <ssoserver folder>\utils>rsautil.cmd manage-secrets -a list

    • vCenter Single Sign On-Administratorkennwort:
      <ssoserver folder>\utils>rsautil.cmd manage-identity-sources -a list -u admin

    Sie können die Kennwörter unter Verwendung der folgenden Befehle festlegen:

    • vCenter Single Sign On-Master-Kennwort:
      <ssoserver folder>\utils\rsautil.cmd manage-secrets -a change -m <master password> -N <new Master Password>

    • vCenter Single Sign On-Administratorkennwort:
      <ssoserver folder>\utils\rsautil.cmd reset-admin-password -m <master password> -u <admin> -p <pass>

    Standardmäßig läuft das vCenter Single Sign On-Administratorkennwort in 365 Tagen ab. Wenn Sie dieses Kennwort zurücksetzen, setzen Sie auch das vCenter Single Sign On-Master-Kennwort zurück, um sicherzustellen, dass beide Kennwörter identisch bleiben.

  • Die Installation schlägt fehl, wenn Sie versuchen, vCenter Single Sign On in einer IPv6-Umgebung zu installieren
    Wenn Sie den Befehl netsh interface ipv4 installmit anschließendem Neustart in einer reinen IPv6-Umgebung unter Windows 2003, 2008 oder 2008 R2 verwenden, schlägt die Installation von vCenter Single Sign On fehl. Die folgende Fehlermeldung wird angezeigt: Fehler 29114. Es kann keine Verbindung zur Datenbank hergestellt werden.Zudem erscheint diese Fehlermeldung möglicherweise in der Datei install.log: Error: Failed to access configuration database: Network error IOException: Address family not supported by protocol family: create.

    Umgehung: Verwenden Sie den FQDN oder den Hostnamen des vCenter Server-Systems. Die Best Practice besteht darin, anstatt der IP-Adresse, die sich ändern kann, wenn sie von DHCP zugewiesen wurde, den FQDN zu verwenden, der in allen Fällen funktioniert. Darüber hinaus müssen Sie unter Verwendung des folgenden Befehls die IPv4-Schnittstelle neu installieren: netsh interface ipv4 install.
    Alternativ können Sie unter Windows 2003, 2008 oder 2008 R2 zum Dialogfeld "Adaptereinstellungen ändern" navigieren und die Aktivierung des folgenden Kontrollkästchens aufheben: Internet Protocol Version 4 (TCP/IPv4).

  • Die Installation der vCenter Single Sign On-Datenbank schlägt fehl, wenn ein doppeltes Anführungszeichen in Ihrem Kennwort vorkommt
    Wenn in Ihrem Single Sign On-Kennwort ein doppeltes Anführungszeichen (") vorkommt, schlägt die Installation der Single Sign On-Datenbank fehl. Eine Fehlermeldung wird angezeigt, wenn Sie Single Sign On SQL Express installieren.

    Umgehung: Verwenden Sie kein Single Sign On-Kennwort mit einem doppelten Anführungszeichen.

  • Das Installieren von vCenter Single Sign On schlägt fehl, wenn der Hostname des Systems nicht unterstützte Zeichen enthält
    Eine Fehlermeldung wird angezeigt und die Installation von Single Sign On schlägt fehl, wenn der Hostname des Single Sign On-Systems Nicht-ASCII-Zeichen oder Zeichen im hohen ASCII-Bereich enthält.

    Umgehung: Verwenden Sie nur ASCII-Zeichen für die Hostnamen von Systemen, auf denen Single Sign On installiert ist.

  • Die Installation von vCenter Single Sign On schlägt fehl, wenn der Name des Single Sign On-Ordners nicht unterstützte Zeichen enthält
    Eine Fehlermeldung wird angezeigt und die Installation von Single Sign On schlägt fehl, wenn der Name des Single Sign On-Build-Ordners Nicht-ASCII-Zeichen oder Zeichen im hohen ASCII-Bereich enthält.

    Umgehung: Verwenden Sie nur ASCII-Zeichen für Quellordner, die Single Sign On-Installationsdateien enthalten.

  • Das Herstellen einer Verbindung zur MSSQL-Datenbank schlägt während der Installation von vCenter Single Sign On fehl
    Die Fehlermeldung Die Datenbankverbindung ist fehlgeschlagenwird angezeigt, wenn Sie vCenter Single Sign On installieren und Sie manuell erstellte MSSQL-Datenbankbenutzer verwenden. Für eine MSSQL-Datenbank müssen Sie Datenbankbenutzer mit SQL Server-Authentifizierung verwenden. Benutzer mit Windows-Authentifizierung werden nicht unterstützt.

    Umgehung: Vergewissern Sie sich, dass die manuell erstellten Datenbankbenutzer die SQL Server-Authentifizierung verwenden.

  • Ein Fehler des Typs "Unzureichende Rechte" tritt auf, wenn Sie manuell erstellte DB2-Datenbankbenutzer verwenden
    Wenn Sie vCenter Single Sign On installieren und das Installationsprogramm Sie zur Angabe von Single Sign On-Datenbankinformationen für vorhandene Datenbanken auffordert, können Sie das Kontrollkästchen Manuell erstellte DB-Benutzer verwenden aktivieren. Wenn Sie eine DB2-Datenbank verwenden und über manuell erstellte Benutzer mit dem Skript rsaIMSLiteDB2SetupUsers.sqlverfügen, erhalten Sie möglicherweise eine Fehlermeldung, die besagt, dass die Datenbankbenutzer nicht über die erforderlichen Berechtigungen verfügen.

    Umgehung: Das Skript rsaIMSLiteDB2SetupUsers.sql, das sich im Verzeichnis <installation directory>\Single Sign On\DBScripts\SSOServer\schema\db2befindet, enthält zwei der erforderlichen Berechtigungen nicht. Wenn Sie das Skript zum manuellen Erstellen von Benutzern verwenden, fügen Sie ihm die folgenden Anweisungen für die fehlenden Berechtigungen hinzu:
    GRANT DBADM ON DATABASE TO USER RSA_DBA;
    GRANT CREATETAB ON DATABASE TO USER RSA_USER;

Upgrade-Probleme

Bekannte Probleme, die sowohl Installationen und Upgrades betreffen, werden unter Installationsprobleme aufgeführt.
  • Bei der Durchführung eines Upgrades von vSphere Authentication Proxy von Version 5.0 auf Version 5.1 wird die Warnung "Ungültiger Benutzername oder ungültiges Kennwort" angezeigt
    Wenn Sie ein Upgrade von vSphere Authentication Proxy von Version 5.0 auf Version 5.1 auf Systemen durchführen, auf denen vCenter Server Heartbeat installiert ist, zeigt das Installationsprogramm möglicherweise die Warnung Fehler 29453 Anmeldung fehlgeschlagen wegen eines ungültigen Benutzernamens oder Kennwortsan. Sie können die Warnung ignorieren und mit der Installation fortfahren.

Lizenzierungsprobleme
  • ESXi 5.1 kann unter Verwendung des benannten Administratorkontos nicht zu vCenter Server hinzugefügt werden
    Wenn Sie versuchen, unter Verwendung eines benannten Administratorkontos einen ESXi 5.1-Host zu vCenter Server hinzuzufügen, tritt möglicherweise einen Fehler beim Herunterladen der Lizenz auf: Herunterladen der Lizenzdatei von <IP-Adresse> nach vCenter Server fehlgeschlagen aufgrund von Ausnahme: vim.fault.HostConnectFault.

    Umgehung: Verwenden Sie das Root-Konto zum Hinzufügen eines ESXi 5.1-Hosts zu vCenter Server.

Netzwerkprobleme
  • Das System antwortet während einer TFTP/HTTP-Übertragung nicht mehr, wenn ESXi 5.1 oder 5.0 U1 mit Auto Deploy bereitgestellt wird
    Bei der Bereitstellung von ESXi 5.1 oder 5.0 U1 mit Auto Deploy auf Emulex 10GbE NC553i FlexFabric 2-Ports unter Verwendung der neuesten Open-Source gPXE antwortet das System während einer TFTP/HTTP-Übertragung nicht mehr.

    Emulex 10GbE PCI-E-Controller sind im Speicher abgebildete Controller. Der auf dem Controller laufende PXE/UNDI-Stack muss während der PXE TFTP/HTTP-Übertragung vom Real Mode in den Big Real Mode umschalten, um die gerätespezifischen Register zu programmieren, die sich über 1 MB befinden, damit Pakete über das Netzwerk gesendet und empfangen werden können. Während dieses Vorgangs werden CPU-Interrupts unbeabsichtigt aktiviert. Dies bewirkt, dass das System nicht mehr reagiert, wenn andere Geräte-Interrupts während der CPU-Modusumschaltung generiert werden.

    Umgehung: Führen Sie ein Upgrade der Firmware der Netzwerkkarte auf Build 4.1.450.7 oder höher durch.

  • Änderungen der Anzahl von Ports auf einem virtuellen Standard-Switch werden erst wirksam, wenn der Host neu gestartet wird
    Wenn Sie die Anzahl der Ports auf einem virtuellen Standard-Switch ändern, werden die Änderungen erst wirksam, wenn Sie den Host neu starten. Dies unterscheidet sich vom Verhalten bei einem verteilten virtuellen Switch, bei dem Änderungen der Anzahl von Ports sofort wirksam werden.

    Wenn Sie die Anzahl der Ports auf einem virtuellen Standard-Switch ändern, achten Sie darauf, dass die Gesamtanzahl der Ports auf dem Host, Standard-Switches und verteilte Switches zusammengenommen, nicht höher als 4096 ist.

    Umgehung: Keine.

  • Die präfix- und bereichsbasierte Zuteilung von MAC-Adressen wird nur von vCenter Server 5.1 und ESXi 5.1 unterstützt
    Die präfix- und bereichsbasierte Zuteilung von MAC-Adressen wird nur von vCenter Server 5.1 und ESXi 5.1 unterstützt. Wenn Sie Hosts vor 5.1 zu vCenter Server 5.1 hinzufügen und eine andere als die präfix- oder bereichsbasierte Zuteilung von VMware OUI-MAC-Adressen verwenden, können virtuelle Maschinen, denen MAC-Adressen zugewiesen sind, bei denen es sich nicht um VMware OUI-Adressen mit Präfix handelt, ihre Hosts vor Version 5.1 nicht einschalten.
    Die präfix- und bereichsbasierten Zuteilungsschemen von MAC-Adressen werden auf Hosts vor Version 5.1 nicht unterstützt, weil Hosts vor Version 5.1 explizit validieren, ob eine zugeteilte MAC-Adresse den Präfix VMware OUI 00:50:56 verwendet. Wenn die MAC-Adresse nicht den Präfix 00:50:56 aufweist, kann der Host vor 5.1 der virtuellen Maschine nicht eingeschaltet werden.

    Umgehung:

    1. Fügen Sie keine Hosts vor Version 5.1 zu vCenter Server 5.1 hinzu.

    2. Wenn die virtuelle Maschine neu erstellt wurde und auf Hosts vor Version 5.1 platziert wird, bearbeiten Sie die Einstellungen der virtuellen Maschine. Wenn die MAC-Adresse der neuen virtuellen Maschine nicht das Präfix 00:50:56 aufweist, ändern Sie ihre MAC-Adresse in den Typ "manuell" und geben Sie eine andere gültige MAC-Adresse mit dem Präfix 00:50:56 an. Nachdem Sie die Änderungen vorgenommen haben, kann es in vCenter Server MAC-Adressen mit und ohne VMware-OUI-Präfixe geben.

  • Der administrative Zustand einer physischen Netzwerkkarte wird nicht ordnungsgemäß als "ausgefallen"gemeldet
    Das administrative Festlegen des Zustands einer physischen Netzwerkkarte auf "ausgefallen" entspricht nicht der IEEE-Norm. Wenn über den Befehl für virtuelle Switches eine physische Netzwerkkarte auf "ausgefallen" festgelegt wurde, treten zwei bekannte Probleme auf:

    • ESXi erfährt eine Zunahme des Datenverkehrsaufkommens, die es nicht bewältigen kann. Dies führt zu einer Verschwendung von Netzwerkressourcen am physischen Switch von ESXi sowie in den ESXi-Ressourcen selbst.

    • Die Netzwerkkarte verhält sich in unerwarteter Weise. Operatoren erwarten, dass die Netzwerkkarte ausgeschaltet ist, aber sie wird als aktiv angezeigt.

    Es wird empfohlen, den ESXCLI-Befehl -n vmnicN mit den folgenden Vorbehalten zu verwenden:
    • Dieser Befehl schaltet nur den Treiber aus. Die Netzwerkkarte wird nicht ausgeschaltet. Wenn der physische ESXi-Netzwerkadapter in der Verwaltungsschnittstelle des physischen Switches des ESXi-Systems angezeigt wird, scheint das Standard-Switch-Uplink noch aktiv zu sein.

    • Der administrative Zustand einer Netzwerkkarte ist in ESXCLI oder der UI nicht sichtbar. Denken Sie daran, beim Debuggen den Zustand zu überprüfen, indem Sie die Datei "/etc/vmware/esx.conf" untersuchen.

    • Der SNMP-Agent meldet den administrativen Zustand. Er meldet ihn jedoch nicht richtig, wenn der Zustand der Netzwerkkarte auf "ausgefallen" festgelegt wurde, als der Betriebszustand ohnehin "ausgefallen" lautete. Er meldet den administrativen Zustand ordnungsgemäß, wenn der Zustand der Netzwerkkarte auf "ausgefallen" festgelegt wurde, als der Betriebszustand "aktiv" war.

    Umgehung: Ändern Sie den administrativen Zustand auf dem physischen Switch des ESXi-Systems in "ausgefallen", anstatt den Befehl des virtuellen Switches zu verwenden.

  • vMotion und Storage vMotion für virtuelle Maschinen auf Monoflat-Festplatten mit einem Snapshot funktionieren nicht
    Monoflat ist ein Festplattenformat, das von VMware nicht mehr unterstützt wird. Monoflat-Festplatten können eingeschaltet werden, wenn sie an virtuelle Maschinen angehängt sind, aber VMware empfiehlt die Migration der angehängten virtuellen Maschinen nicht. Die Migration schlägt fehl, wenn ein Snapshot vorhanden ist.

    Umgehung: Ändern Sie das Festplattenformat, bevor Sie versuchen, eine Migration durchzuführen. VMware unterstützt die VMFS-Festplattenformate "eagerzeroedthick", "zeroedthick", "thin disk" und "2gbsparse".

  • Änderungen bei der Unterstützung von Linux-Treibern
    Gerätetreiber für virtuelle vmxnet2- oder vmxnet- (flexible) Netzwerkkarten stehen für virtuelle Maschinen nicht zur Verfügung, auf denen Linux-Kernelversion 3.3 und höher ausgeführt wird.

    Umgehung: Verwenden Sie eine virtuelle vmxnet3- oder e1000-Netzwerkkarte für virtuelle Maschinen, auf denen Linux-Kernelversion 3.3 und höher ausgeführt wird.

  • Die Zuteilung der Bandbreite für Network I/O Control von vSphere 5.0 wird nicht gerecht über mehrere Uplinks verteilt
    Wenn bei der Verwendung von Network I/O Control in vSphere 5.0 ein Grenzwert für die Netzwerkbandbreite eines Ressourcenpools festgelegt wurde, wird die Einhaltung dieses Grenzwerts über eine Gruppe von Uplinks auf Hostebene erzwungen. Dieser Bandbreitengrenzwert wird durch einen Token-Verteilungsalgorithmus implementiert, der nicht für die gerechte Verteilung der Bandbreite über mehrere Uplinks hinweg konzipiert wurde.

    Umgehung: Die Grenzwerte für Network I/O Control von vSphere 5.1 wurden auf eine pro Uplink-Basis beschränkt.

  • Die Einstellung maxProxySwitchPorts wird nach dem Neustart eines statusfreien Hosts nicht beibehalten
    Die maximale Anzahl an Ports für einen Host wird auf 512 zurückgesetzt, nachdem der Host neu gestartet und ein Hostprofil übernommen wurde. Wenn Sie auf einem bestimmten statusfreien Host auf einem Distributed Switch maxProxySwitchPorts festlegen, wird die Einstellung möglicherweise nicht beibehalten, wenn der Host neu gestartet wird. Dies gilt nur für statusfreie Hosts, die Teil eines Distributed Switch sind und bei denen die Einstellung maxProxySwitchPorts geändert wurde.

    Umgehung: Ändern Sie die maxProxySwitchPorts-Einstellungen für die Hosts nach dem Neustart manuell.

  • Die Einstellung "Länge des gespiegelten Pakets" könnte dazu führen, dass eine Remotespiegelungsquell-Sitzung nicht funktioniert
    Wenn Sie eine Remotespiegelungsquell-Sitzung mit festgelegter Option "Länge des gespiegelten Pakets"konfigurieren, empfängt das Ziel einige gespiegelte Pakete nicht. Wenn Sie die Option jedoch deaktivieren, werden die Pakete wieder empfangen.
    Wenn die Option "Länge des gespiegelten Pakets" festgelegt ist, werden Pakete gekürzt, die länger als die angegebene Länge sind, und Pakete werden verworfen. Ein Code auf niedriger Ebene sorgt nicht für das Fragmentieren und Neuberechnen der Prüfsumme der verworfenen Pakete. Es gibt zwei Ursachen für das Verwerfen von Paketen:

    • Die "Länge des gespiegelten Pakets" ist größer als die MTU (Maximum Transmission Unit)
      Wenn in Ihrer Umgebung TSO aktiviert ist, können die ursprünglichen Pakete sehr groß sein. Auch wenn sie aufgrund der angegebenen "Länge des gespiegelten Pakets" abgeschnitten wurden, sind sie immer noch größer als die MTU und werden daher von der physischen Netzwerkkarte verworfen.

    • Dazwischenliegende Switches führen die L3-Prüfung durch
      Einige abgeschnittene Pakete können die falsche Paketlänge und Prüfsumme aufweisen. Einige erweiterte physische Switches prüfen die L3-Informationen und verwerfen ungültige Pakete. Das Ziel empfängt die Pakete nicht.

    Umgehung:

    • Wenn TSO (TCP Segmentation Offload) aktiviert ist, deaktivieren Sie die Option "Länge des gespiegelten Pakets".

    • Sie können die L3-Prüfung auf einigen Switches, z. B. dem Ciscos 4500 Series-Switch, aktivieren oder deaktivieren. Wenn diese Switches verwendet werden, deaktivieren Sie die L3-Prüfung. Im Falle von Switches, die nicht konfiguriert werden können, deaktivieren Sie die Option "Länge des gespiegelten Pakets".

  • Das Aktivieren von mehr als 16 VMkernel-Netzwerkadaptern sorgt dafür, dass vSphere vMotion fehlschlägt
    vSphere 5.x 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-Migrationen zu oder von diesem Host fehlschlagen. Eine Fehlermeldung in den VMkernel-Protokollen auf ESXi 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.

    Umgehung: Deaktivieren Sie vMotion VMkernel-Netzwerkadapter, bis insgesamt nur 16 davon für vMotion aktiviert sind.

  • Der vSphere-Netzwerk-Core-Dump funktioniert nicht, wenn in einer VLAN-Umgebung ein nx_nic-Treiber verwendet wird
    Wenn auf einem Host, der Teil eines VLANs ist, Netzwerk-Core-Dump konfiguriert wird, schlägt der Netzwerk-Core-Dump fehl, wenn die Netzwerkkarte einen QLogic Intelligent Ethernet Adapters-Treiber (nx_nic) verwendet. Empfangene Netzwerk-Core-Dump-Pakete werden nicht mit dem richtigen VLAN-Tag gekennzeichnet, wenn der Uplink-Adapter nx_nic verwendet.

    Umgehung: Verwenden Sie einen anderen Uplink-Adapter mit einem anderen Treiber, wenn Sie den Netzwerk-Core-Dump in einem VLAN konfigurieren.

  • Bei eingekapselten Remotespiegelungssitzungen muss die Ziel-IP-Adresse eine gültige Unicast-IP-Adresse sein
    Bei einer eingekapselten Remotespiegelungssitzung sorgt ein vSphere Distributed Switch dafür, dass der ursprüngliche Datenverkehr auf die angegebene Ziel-IP-Adresse umgeleitet wird. Wenn Sie eine Multicast- oder Broadcast-IP-Adresse als Ziel für die Sitzung ausgewählt haben, wird der ursprüngliche Datenverkehr auf mehrere Ziele gespiegelt. Dadurch kann viel physische Netzwerkbandbreite verbraucht werden. Wenn Sie eine ungültige IP-Adresse angegeben haben, z. B. eine reservierte IP-Adresse, wird der ursprüngliche Datenverkehr nicht gespiegelt.

    Umgehung: Konfigurieren Sie gültige Unicast-IP-Adressen als das Ziel der eingekapselten Remotespiegelungssitzung.

  • Die Suche nach verteilten virtuellen Portgruppen mithilfe eines privaten VLAN in einer Umgebung mit mehreren vCenter Servern liefert möglicherweise falsche Ergebnisse
    Wenn Sie mehrere vCenter Server mit einer Instanz von vSphere Web Client verwalten, liefert die Suche nach verteilten virtuellen Portgruppen mit bestimmten privaten VLAN-Einstellungen möglicherweise nicht nur diese bestimmten Portgruppen, sondern auch Portgruppen, die nicht zu den Suchergebnissen gehören sollten.

    Umgehung: Führen Sie die Suche erneut durch.

  • Beim Benennen eines Netzwerkprotokollprofils mit Surrogatpaaren tritt ein Fehler auf
    Das Erstellen eines Netzwerkprotokollprofils mit Surrogatpaaren schlägt fehl und eine Fehlermeldung hinsichtlich der Behandlung von UTF-8 im vSphere Web Client wird angezeigt.

    Umgehung: Vermeiden Sie, Surrogatpaare für Netzwerkprotokollprofile zu verwenden.

  • Wenn die Kickstart-Datei einer Skriptinstallation eine Netzwerkkarte aufruft, die bereits verwendet wird, schlägt die Installation fehl
    Wenn Sie eine Kickstart-Datei verwenden, um nach der Installation ein Verwaltungsnetzwerk einzurichten, und Sie von der Kickstart-Datei aus eine Netzwerkkarte aufrufen, die bereits verwendet wird, wird die folgende Fehlermeldung angezeigt: Sysinfo-Fehler bei Vorgang, gemeldeter Status: Belegt. Detaillierte Fehlerinformationen finden Sie im VMkernel-Protokoll.

    Der Fehler tritt auf, wenn Sie eine Skriptinstallation auf einem System mit zwei Netzwerkkarten initiieren: eine Netzwerkkarte, die für SWFCoE/SWiSCSI konfiguriert ist, und eine für das Netzwerk konfigurierte Netzwerkkarte. Wenn Sie die Netzwerkkarte für das Netzwerk verwenden, um die Skriptinstallation zu initiieren, indem Sie bei den Startoptionen entweder netdevice=<nic> oder BOOTIF=<MAC der NIC> angeben, verwendet die Kickstart-Datei die andere Netzwerkkarte ( netdevice=<nic configured for SWFCoE / SWiSCSI>) in der Netzwerkzeile, um das Verwaltungsnetzwerk zu konfigurieren.

    Die Installation (Partitionierung der Festplatten) ist erfolgreich, aber, wenn das Installationsprogramm versucht, die in der Kickstart-Datei angegebenen Netzwerkparameter für das Konfigurieren des Verwaltungsnetzwerks für den Host zu verwenden, schlägt es fehl, da die Netzwerkkarte von SWFCoE/SWiSCSI verwendet wurde.

    Umgehung: Verwenden Sie in der Kickstart-Datei eine verfügbare Netzwerkkarte, um nach der Installation ein Verwaltungsnetzwerk einzurichten.

  • vCenter Server kann keiner Gruppe im verknüpften Modus beitreten
    vCenter Server kann keiner Gruppe im verknüpften Modus beitreten, wenn Sie während der Durchführung eines Upgrades von vCenter Server den HTTPS-Port von vCenter Server geändert haben.

    Umgehung:

    1. Öffnen Sie den vSphere-Client.
    2. Navigieren Sie zu Verwaltung > vCenter Server-Einstellungen > Erweiterte Einstellungen.
    3. Wählen Sie den Schlüssel namens VirtualCenter.VimApiURL aus.
    4. Ändern Sie im Wertefeld die Portnummer in der URL in die Nummer, die Sie während der Durchführung des Upgrades von vCenter Server erhalten haben.
    5. Starten Sie den Dienst VMware VirtualCenter Server neu.
    6. Starten Sie "Konfiguration für den verknüpften Modus ändern", indem Sie auf Startmenü > VMware > vCenter Server-Konfiguration für den verknüpften Modus klicken. Diese Option verlinkt einen vCenter Server mit einer Gruppe im verknüpften Modus.

  • Virtuelle Maschinen, auf denen ESX läuft und die auch vmxnet3 als pNIC verwenden, können abstürzen
    Virtuelle Maschinen, auf denen ESX als Gast läuft und die auch vmxnet3 als pNIC verwenden, können abstürzen, weil sich die Unterstützung für vmxnet3 noch in der Versuchsphase befindet. Die Standard-Netzwerkkarte für eine virtuelle Maschine mit ESX ist e1000, daher tritt dieses Problem nur auf, wenn Sie den Standard außer Kraft setzen und vmxnet3 wählen.

    Umgehung: Verwenden Sie e1000 oder e1000e als pNIC für die virtuelle Maschine mit ESX.

  • Eine Fehlermeldung wird angezeigt, wenn eine große Anzahl von dvPorts benutzt wird
    Wenn Sie eine virtuelle Maschine mit dvPort auf einem Host hochfahren, auf dem bereits eine große Anzahl von dvPorts genutzt wird, erscheint die Fehlermeldung Nicht genügend Arbeitsspeicher vorhandenoder Keine Ressourcen mehr frei. Dies kann auch auftreten, wenn Sie die Switches auf einem Host mit einem esxcli-Befehl auflisten.

    Umgehung: Erhöhen Sie den Wert für dvsLargeHeap.

    1. Ändern Sie die erweiterte Konfigurationsoption des Hosts:
      • esxcli-Befehl: esxcfg-advcfg -s /Net/DVSLargeHeapMaxSize 100
      • Virtual Center: Navigieren Sie zu Hostkonfiguration -> Software -> Erweiterte Einstellungen -> Ändern Sie unter "Netz" den Wert für DVSLargeHeapMaxSize von 80 auf 100.
      • vSphere 5.1 Web Client: Navigieren Sie zu Host verwalten -> Einstellungen -> Erweiterte Systemeinstellungen -> Filter. Ändern Sie den Wert für DVSLargeHeapMaxSize von 80 auf 100.
    2. Erfassen Sie ein Hostprofil aus dem Host. Weisen Sie das Profil dem Host zu und aktualisieren Sie die Antwortdatei.
    3. Starten Sie den Host neu, um zu bestätigen, dass der Wert angewendet wurde.

    Hinweis: Der maximale Wert für /Net/DVSLargeHeapMaxSize ist 128.

    Kontaktieren Sie den VMware Support, wenn bei einer größeren Bereitstellung nach der Änderung von /Net/DVSLargeHeapMaxSize auf 128 Probleme auftreten und die Protokolle eine der folgenden Fehlermeldungen enthalten:

    Unable to Add Port; Status(bad0006)= Limit exceeded (Port kann nicht hinzugefügt werden; Status (bad0006) = Grenzwert überschritten)

    Failed to get DVS state from vmkernel Status (bad0014)= Out of memory (DVS-Status konnte vom vmkernel-Status nicht bezogen werden (bad0014) = Kein Arbeitsspeicher mehr)

  • Standard-Switch-Topologie im vSphere Web Client zeigt die Failover-Richtlinie sowohl für die Switch-Ebene als auch für die Portgruppenebene
    Das Portstatussymbol und die Bezeichnung "Standby" oder "Nicht benutzt" gelten für die Failover-Richtlinie auf Switch-Ebene. Wenn eine Portgruppe ausgewählt ist, gilt die orange Linie für die Failover-Richtlinie auf Portgruppenebene.

    Umgehung: Keine. Die orange markierten physischen Netzwerkadapter werden für den Portgruppenverkehr verwendet, auch wenn Sie in der Topologie die Bezeichnung "Standby" oder "Nicht benutzt" haben.

  • ESXi schlägt mit Emulex BladeEngine-3 10G NICs (be2net-Treiber) fehl
    ESXi kann bei Systemen fehlschlagen, die Emulex BladeEngine-3 10G-Netzwerkkarten haben, wenn ein vCDNI-gestützter Netzwerkpool mit VMware vCloud Director konfiguriert wurde. Sie müssen einen aktualisierten Gerätetreiber von Emulex installieren, wenn Sie mit diesem Gerät einen Netzwerkpool einrichten.

    Umgehung: Keine.

Speicherprobleme
  • Virtuelle Maschine hat eine Datenspeicherlatenz beobachtet
    Möglicherweise gibt es falsche Werte für die von virtuellen Maschinen beobachtete Datenspeicherlatenz, wenn SDRS oder SIOC auf einem Datenspeicher ausgeführt wird, der mit einer Kombination aus ESXi 5.0- und ESXi 5.1-Hosts verbunden ist. ESXi 5.1 erfasst einen neue Statistik namens "Virtuelle Maschine hat eine Datenspeicherlatenz beobachtet", die von ESXi 5.0 nicht erfasst wird. Wegen dieses Unterschieds ist es nicht möglich, den Durchschnitt der Statistikwerte zwischen einer Mischung aus ESXi 5.0- und ESXi 5.1-Hosts zu berechnen. Dies kann auch zu einem weniger aggressiven SDRS-E/A-Lastausgleichsverhalten führen, wenn bei einem Datenspeicher-Cluster Datenspeicher mit einer Kombination aus ESXi 5.0- und ESXi 5.1-Hosts gemountet sind, statt wenn ein Datenspeicher-Cluster nur über ESXi 5.1-Hosts verfügt.

    Umgehung: Führen Sie ein Upgrade von allen Hosts auf ESXi 5.1 durch.

  • Aktivieren von historischen Leistungsdiagrammen für Datenspeicher und Datenspeicher-Cluster in einer Speicher-DRS-Umgebung
    Wenn Sie in einer vSphere 5.1-Umgebung die Erfassungsebene für die Statistik auf den Standardwert 1 setzen, werden nur Echtzeit-Leistungsdiagramme für Speicher-DRS-Datenindikatoren in Verbindung mit Datenspeicher- und Datenspeicher-Cluster-Messwerten angezeigt. Wenn Sie ein anderes Zeitintervall auswählen, wird im Diagramm Keine Daten verfügbarangezeigt. Dies wird dadurch verursacht, dass viele Datenspeicher- und Datenspeicher-Cluster-Messwerte standardmäßig auf Statistik-Erfassungsebene 3 verlegt wurden, um die Leistung zu verbessern.

    Umgehung: Um historische Leistungsdiagramme für Datenspeicher- und Datenspeicher-Cluster-Messwerte zu ermöglichen, verlegen Sie die Speicher-DRS-Zähler auf die Statistik-Erfassungsebene 1. Weitere Hinweise finden Sie hier: Knowledgebase-Artikel 2009532. Achten Sie darauf, dass Änderungen der Zählerwerte eine wesentliche Zunahme der Datenerfassung und -speicherung bei gleichzeitiger Verringerung der Leistung bewirken können. Weitere Informationen finden Sie unter Ändern der Erfassungsebenen der Leistungsindikatoren im Programmierhandbuch zu vSphere Web Services und in der vSphere API-Referenzdokumentation.

  • Das Erstellen eines VMFS5-Datenspeichers schlägt möglicherweise fehl, wenn Sie ein EMC Symmetrix VMAX/VMAXe-Speicher-Array einsetzen
    Wenn Ihr ESXi-Host mit einem VMAX/VMAXe-Array verbunden ist, können Sie möglicherweise keinen VMFS5-Datenspeicher auf einer LUN erstellen, die von dem Array präsentiert wird. Wenn dies der Fall ist, wird die folgende Fehlermeldung angezeigt: Während der Hostkonfiguration ist ein Fehler aufgetreten.. Der Fehler ist darauf zurückzuführen, dass die ATS (VAAI)-Portion des Symmetrix Enginuity Microcodes (VMAX 5875.x) einen neuen Datenspeicher auf einer vorher unbeschriebenen LUN verhindert.

    Umgehung:

    1. Deaktivieren Sie das hardwarebeschleunigte Sperren auf dem ESXi-Host.
    2. Erstellen Sie einen VMFS5-Datenspeicher.
    3. Reaktivieren Sie das hardwarebeschleunigte Sperren auf dem Host.

    Verwenden Sie die folgenden Aufgaben, um den Parameter für das hardwarebeschleunigte Sperren zu deaktivieren und anschließend zu reaktivieren.

    Im vSphere Web Client

    1. Navigieren Sie zum Host im Navigator von vSphere Web Client.
    2. Klicken Sie auf die Registerkarte Verwalten und anschließend auf Einstellungen.
    3. Klicken Sie unter "System" auf Erweiterte Systemeinstellungen.
    4. Wählen Sie "VMFS3.HardwareAcceleratedLocking" aus und klicken Sie auf das Symbol "Bearbeiten".
    5. Ändern Sie den Wert des Parameters "VMFS3.HardwareAcceleratedLocking":
      • 0 - deaktiviert
      • 1 - aktiviert

    Im vSphere-Client

    1. Wählen Sie im Bestandslistenbereich des vSphere-Clients den Host aus.
    2. Klicken Sie auf die Registerkarte Konfiguration und anschließend unter Software auf Erweiterte Einstellungen.
    3. Ändern Sie den Wert des Parameters "VMFS3.HardwareAcceleratedLocking":
      • 0 - deaktiviert
      • 1 - aktiviert

  • Versuche, eine GPT-Partition auf einer leeren Festplatte zu erstellen, schlagen möglicherweise bei der Verwendung von Storagesystem::updateDiskPartitions()
    fehl Sie können das API Storagesystem::computeDiskPartitionInfoverwenden, um die Festplattenspezifikation abzurufen, und anschließend die Festplattenspezifikation zum Beschriften der Festplatte und zum Erstellen einer Partition mit Storagesystem::updateDiskPartitions()verwenden. Wenn jedoch die Festplatte anfänglich leer und das Format der Zielfestplatte GPT ist, schlägt das Erstellen der Partition möglicherweise fehl.

    Umgehung: Verwenden Sie stattdessen DatastoreSystem::createVmfsDatastorezum Beschriften und Partitionieren einer leeren Festplatte sowie zum Erstellen eines VMFS5-Datenspeichers.

  • Storage vMotion schlägt möglicherweise fehl mit einer Fehlermeldung
    Wenn die Speicherkonfiguration überladen und belastet ist, kann es viel länger dauern, bis eine Datei auf einem VMFS-Datenspeicher geöffnet wird. Diese Verzögerung kann dazu führen, dass Storage vMotion einer virtuellen Maschine mit folgender Fehlermeldung fehlschlägt: Der Pfad einer übergeordneten Festplatte ist für einen Snapshot der Festplatte /Pfad/zu/Festplatte/XXX.vmdk erforderlich.

    Umgehung: Führen Sie das folgende Power CLI-Skript aus, um die Festplatteninformationen der virtuellen Maschine neu zu laden und Storage vMotion erneut durchzuführen.

    1. Ersetzen Sie Folgendes durch die entsprechenden Werte:
      Connect-VIServer ...
      $hostName = ...
      $vmName = ...
    2. Rufen Sie das öffentliche API ServiceInstance-Objekt ab.
      $serviceInstance = Get-View ServiceInstance
    3. Laden Sie das InternalVimService51-Assembly.
      [System.Reflection.Assembly]::LoadWithPartialName( InternalVimService51)
    4. Konfigurieren Sie die Interne API VimService-Instanz.
      $internalVimService = new-Object InternalVimApi_51.InternalvimService
      $internalVimService.Timeout = $serviceInstance.Client.VimService.Timeout;
      $internalVimService.Url = $serviceInstance.Client.VimService.Url;
      $internalVimService.CookieContainer = $serviceInstance.Client.VimService.CookieContainer;
      $svcRef = new-object InternalVimApi_51.ManagedObjectReference
      $svcRef.type = ServiceInstance;
      $svcRef.Value = ServiceInstance;
      $internalServiceContent = $internalVimService.RetrieveServiceContent($svcRef);
    5. Rufen Sie das VMHost-Objekt ab.
      $vmhost = Get-VMHost $hostName | Get-View
      $hostRef = new-object InternalVimApi_51.ManagedObjectReference
      $hostRef.type = $vmhost.MoRef.Type
      $hostRef.Value = $vmhost.MoRef.Value
    6. Rufen Sie den internen Konfigurationsmanager ab.
      $configManager = $internalVimService.RetrieveInternalConfigManager($hostRef)
    7. Rufen Sie das VM-Objekt ab.
      $vm = Get-VM $vmName | Get-View
      $vmRef = new-object InternalVimApi_51.ManagedObjectReference
      $vmRef.type = $vm.MoRef.Type
      $vmRef.Value = $vm.MoRef.Value
    8. Laden Sie die Festplatten der VM neu.
      $internalVimService.ReloadDisks_Task($configManager.llProvisioningManager, $vmRef, @( currentConfig, snapshotConfig))

    Um das Fehlschlagen von Storage vMotion zu verhindern, wenn das Speicher-Array belastet und langsam ist, bearbeiten Sie die folgende Option in der Datei /etc/vmware/config, um die Anzahl der Wiederholungen für das Öffnen der Festplatte zu erhöhen:
    diskLibMiscOptions.openRetries = hoher Wert, z. B. 99

  • Versuche, eine Diagnosepartition auf einer GPT-Festplatte zu erstellen, schlagen möglicherweise fehl
    Wenn eine GPT-Festplatte keine Partitionen hat oder die Endportion der Platte leer ist, können Sie möglicherweise keine Diagnosepartition auf der Festplatte erstellen.

    Umgehung: Vermeiden Sie die Verwendung von GPT-formatierten Festplatten für Diagnosepartitionen. Wenn Sie für die Diagnosepartition, eine vorhandene leere GPT-Festplatte verwenden müssen, konvertieren Sie die Festplatte in das MBR-Format.

    1. Erstellen Sie einen VMFS3-Datenspeicher auf der Festplatte.
    2. Entfernt den Datenspeicher.

    Das Festplattenformat ändert sich von GPT in MBR.

  • ESXi kann nicht von einer FCoE-LUN starten, die größer als 2 TB ist und bei der der Zugriff über eine Intel FCoE-Netzwerkkarte erfolgt
    Wenn Sie ESXi auf einer FCoE-Start-LUN installieren, die größer als 2 TB ist und bei der der Zugriff über eine Intel FCoE-Netzwerkkarte erfolgt, gelingt die Installation möglicherweise. Wenn Sie jedoch versuchen, Ihren ESXi-Host zu starten, schlägt der Startvorgang fehl. Zum BIOS-Zeitpunkt sehen Sie die Fehlermeldungen: FEHLER: Keine passende Geometrie für diese Festplattenkapazität!und FEHLER: Verbindungsaufbau mit keiner konfigurierten Festplatte möglich!.

    Umgehung: Installieren Sie ESXi auf keiner FCoE-LUN, die größer als 2 TB ist, wenn es mit der für den FCoE-Start konfigurierten Intel FCoE-Netzwerkkarte verbunden ist. Installieren Sie ESXi auf einer FCoE-LUN, die kleiner als 2 TB ist.

Serverkonfigurationsprobleme
  • Das Übernehmen von Hostprofilen schlägt möglicherweise fehl, wenn auf VMFS-Ordner über die Konsole zugegriffen wird
    Wenn ein Benutzer über die Konsole auf den VMFS-Datenspeicherordner zugreift, während gleichzeitig ein Hostprofil vom Host übernommen wird, schlägt der Standardisierungs- oder Übernahmevorgang möglicherweise fehl. Dieser Fehler tritt auf, wenn auf dem Hostprofil das statusfreie Caching aktiviert ist oder eine Auto Deploy-Installation durchgeführt wurde.

    Umgehung: Greifen Sie beim Standardisieren des Hostprofils nicht über die Konsole auf den VMFS-Datenspeicher zu.

  • Führende Weißraumzeichen im Anmelde-Banner verursachen einen Fehler bei der Übereinstimmung von Hostprofilen
    Wenn Sie ein Hostprofil bearbeiten und beim Ändern des Texts des Anmelde-Banners (Meldung des Tages) führende Weißraumzeichen hinzufügen, tritt beim Übernehmen des Profils ein Übereinstimmungsfehler auf. Der Übereinstimmungsfehler Der Anmelde-Banner wurde geändertwird angezeigt.

    Umgehung: Bearbeiten Sie das Hostprofil und entfernen Sie die führenden Weißraumzeichen aus dem Text des Anmelde-Banners.

  • Ein vom ESXi 5.0-Host extrahiertes Hostprofil kann vom ESX 5.1-Host nicht übernommen werden, wenn Active Directory aktiviert ist
    Das Anwenden eines Hostprofils mit aktiviertem Active Directory, das ursprünglich von einem ESXi 5.0-Host auf einen ESX 5.1-Host extrahiert wurde, schlägt fehl. Beim Festlegen der maximalen Arbeitsspeichergröße für den Likewise-Systemressourcenpool tritt möglicherweise ein Fehler auf. Wenn Active Directory aktiviert ist, verbrauchen die Dienste im Likewise-Systemressourcenpool mehr als den Standardgrenzwert für die maximale Arbeitsspeichergröße für ESXi 5.0, die in einem ESXi 5.0-Hostprofil erfasst wurde. Folglich schlägt das Anwenden eines ESXi 5.0-Hostprofils bei Versuchen fehl, den Grenzwert für die maximale Arbeitsspeichergröße auf ESXi 5.0-Niveau festzulegen.

    Umgehung: Führen Sie einen der folgenden Schritte durch:

    • Bearbeiten Sie das Hostprofil manuell, um den Grenzwert für die maximale Arbeitsspeichergröße für die Likewise-Gruppe zu erhöhen.
      1. Navigieren Sie vom Hostprofileditor zum Ordner Ressourcenpool und sehen Sie sich host/vim/vmvisor/plugins/likewise an.
      2. Ändern Sie die Einstellung Maximale Arbeitsspeichergröße (MB) von 20 (dem ESXi 5.0-Standardwert) auf 25 (den ESXi 5.1-Standardwert).
    • Deaktivieren Sie das Unterprofil für die Likewise-Gruppe. Führen Sie einen der folgenden Schritte aus:
      • Bearbeiten Sie im vSphere Web Client das Hostprofil und heben Sie die Aktivierung des Kontrollkästchens für den Ordner Ressourcenpool auf. Diese Aktion deaktiviert die Ressourcenpoolverwaltung. Sie können dies gezielt für das Element host/vim/vmvisor/plugins/likewise im Ressourcenpool-Ordner deaktivieren.
      • Klicken Sie mit der rechten Maustaste im vSphere-Client auf das Hostprofil und wählen Sie im Menü Profilkonfiguration aktivieren/deaktivieren...

  • Das Host-Gateway wird gelöscht und Übereinstimmungsfehler treten auf, wenn ein ESXi 5.0.x-Hostprofil neu auf einen statusorientierten ESXi 5.1-Host angewendet wird
    Wenn ein ESXi 5.0.x-Hostprofil auf einen neu installierten ESXi 5.1-Host angewendet wird, lautet der Profil-Übereinstimmungsstatus "Nicht übereinstimmend". Nachdem dasselbe Profil erneut angewendet wurde, wird die Gateway-IP des Hosts gelöscht und der Übereinstimmungsstatus wird weiterhin als "Nicht übereinstimmend" angezeigt. Die Statusmeldung lautet Die IP-Routenkonfiguration stimmt nicht mit der Spezifikation überein.

    Umgehung: Führen Sie eine der folgenden Umgehungen durch:

    • Melden Sie sich über die direkte Konsole (DCUI) beim Host an und fügen Sie das Standard-Gateway unter Verwendung des folgenden esxcli-Befehls manuell hinzu:
      esxcli network ip route ipv4 add --gateway xx.xx.xx.xx --network yy.yy.yy.yy
    • Extrahieren Sie ein neues Hostprofil vom ESX 5.1-Host, nachdem Sie das ESX 5.0-Hostprofil einmal angewendet haben. Migrieren Sie den ESX 5.1-Host auf das neue ESX 5.1-basierte Hostprofil.

  • Nach der Aktivierung von statusfreiem Caching auf einer USB-Festplatte treten möglicherweise Übereinstimmungsfehler auf
    Wenn auf einem Hostprofil das statusfreie Caching für USB-Festplatten aktiviert ist, treten nach der Standardisierung möglicherweise Übereinstimmungsfehler auf. Nach dem Neustart des Hosts zum Anwenden der standardisierten Änderungen ist das statusfreie Caching erfolgreich, aber Übereinstimmungsfehler treten weiterhin auf.

    Umgehung: Das Problem kann nicht umgangen werden.

  • Auf Hosts mit vielen Datenspeichern tritt beim Anwenden eines Hostprofils mit aktiviertem statusfreiem Caching eine Zeitüberschreitung ein
    Auf einem Host mit vielen Datenspeichern tritt beim Anwenden eines Hostprofils mit aktiviertem statusfreiem Caching eine Zeitüberschreitung ein.

    Umgehung: Verwenden Sie den vSphere-Client, um den Zeitüberschreitungswert zu erhöhen:

    1. Wählen Sie Administrator > vCenter Server-Einstellungen.
    2. Wählen Sie Zeitüberschreitungseinstellungen.
    3. Ändern Sie die Werte für normale Vorgänge und lange Vorgänge bis 3600 Sekunden.

  • Übereinstimmungsfehler bei Netzwerkrichtlinien treten weiterhin für Hostprofile auf, die von ESXi 4.1- oder ESXi 4.0-Hosts erstellt und auf ESXi 5.1-Hosts angewendet wurden
    Nach dem Anwenden eines von einem ESXi 4.1- oder ESXi 4.0-Host erstellten Hostprofils auf einen ESXi 5.1-Host treten möglicherweise weiterhin die folgenden Fehler bei der Übereinstimmung von Hostprofilen auf:

    Bei Portgruppe [PORT GROUP NAME] stimmt die Netzwerkrichtlinieneigenschaft spec.policy.nicTeaming.failureCriteria nicht überein
    Bei Portgruppe [PORT GROUP NAME] stimmt die Netzwerkrichtlinieneigenschaft spec.policy.nicTeaming.reversePolicy nicht überein

    Die oben aufgeführten Netzwerkeinstellungen werden auf ESXi 5.1-Hosts nicht unterstützt und werden nicht mehr konfiguriert, wenn ein Hostprofil mit diesen Einstellungen angewendet wird.

    Umgehung: Zwei mögliche Lösungen stehen zur Verfügung:

    • Nachdem Sie das ursprünglich von einem ESXi 4.1-Host erstellte Hostprofil auf einen ESXi 5.1-Host angewendet haben, erstellen Sie ein neues Hostprofil vom ESXi 5.1-Host und hängen Sie es an diesem ESXi 5.1-Host sowie an andere betroffene ESXi 5.1-Hosts an.
    • Ändern Sie die NIC-Gruppierungsrichtlinie im Hostprofil in Benutzer muss die Richtlinienoption explizit auswählen anstatt Angegebene NIC-Gruppierungsrichtlinie übernehmen.

  • Hostprofil kann nicht vom Host extrahiert werden, wenn auf vmknics IPv4 deaktiviert ist
    Wenn Sie alle IPv4-Adressen von allen vmknics entfernen, können Sie kein Hostprofil von diesem Host extrahieren. Diese Aktion betrifft vor allem Hosts, die mit Auto Deploy bereitgestellt wurden, da in dieser Umgebung die Hostkonfiguration nur über Hostprofile gespeichert werden kann.

    Umgehung: Weisen Sie einer IPv4-Adresse mindestens eine vmknic zu.

  • Die Übernahme eines Hostprofils schlägt beim Anwenden eines von einem ESXi 4.1-Host extrahierten Hostprofils auf einen ESXi 5.1-Host fehl
    Wenn Sie einen Host mit ESXi 4.1 einrichten, ein Hostprofil von diesem Host (mit vCenter Server) extrahieren und versuchen, ein Profil an einem ESXi 5.1-Host anzuhängen, schlägt der Vorgang fehl, wenn Sie versuchen, das Profil anzuwenden. Möglicherweise wird die folgende Fehlermeldung angezeigt: NTP-Dienst ist deaktiviert.

    Der NTPD-Dienst wird möglicherweise auch dann ausgeführt (eingeschaltet), ohne dass in /etc/ntp.confein NTP-Server für ESXi 4.1 angegeben ist. ESXi 5.1 benötigt einen expliziten NTP-Server, damit der Dienst ausgeführt werden kann.

    Umgehung: Schalten Sie den NTP-Dienst ein, indem Sie zu /etc/ntp.confeinen gültigen NTP-Server hinzufügen, und starten Sie den NTP-Daemon auf dem 5.1-Host neu. Vergewissern Sie sich, dass nach dem Neustart der Dienst weiterhin ausgeführt wird. Dies Aktion gewährleistet, dass der NTP-Dienst für den Host und das Profil, das auf ihn angewendet wird, synchronisiert wurde.

  • Das Hostprofil weist den Status "Nicht übereinstimmend" auf, nachdem das Profil erfolgreich übernommen wurde
    Dieses Problem tritt auf, wenn ein Hostprofil von einem ESXi 5.0-Host extrahiert und von einem ESXi 5.1-Host übernommen wurde, der ein lokales SAS-Gerät enthält. Selbst dann, wenn die Standardisierung des Hostprofils erfolgreich ist, wird die Übereinstimmung des Hostprofils als "Nicht übereinstimmend" angezeigt.

    Möglicherweise erhalten Sie Fehlermeldungen ähnlich der folgenden:

    • Der Spezifikationsstatus fehlt für den Host: Die Pfadauswahlrichtlinie des Geräts naa.500000e014ab4f70 muss auf VMW_PSP_FIXED festgelegt werden
    • Der Spezifikationsstatus fehlt für den Host: Geräteparameter naa.500000e014ab4f70 müssen auf State = "on" Queue Full Sample Size = "0" Queue Full Threshold = "0" festgelegt werden

    Das ESXi 5.1-Hostprofilspeicher-Plug-In filtert das lokale SAS-Gerät für die PSA- und NMP-Gerätekonfiguration heraus, während ESXi 5.0 solche Gerätekonfigurationen enthält. Dies führt dazu, dass ein Gerät fehlt, wenn das ältere Hostprofil von einem neueren Host übernommen wird.

    Umgehung: Bearbeiten Sie das Hostprofil manuell und entfernen Sie die PSA- und NMP-Gerätekonfigurationseinträge für alle lokalen SAS-Geräte. Sie können ermitteln, ob ein Gerät ein lokales SAS-Gerät ist, indem Sie den folgenden esxcli-Befehl eingeben:
    esxcli storage core device list

    Wenn die folgende Zeile zurückgegeben wird, handelt es sich bei dem Gerät um ein lokales SAS-Gerät:
    Ist lokales SAS-Gerät

  • Fehler bei der Übereinstimmung von Hostprofilen treten auf, wenn ESXi-Hosts aus der vCenter Server-Bestandsliste entfernt werden
    Beim Überprüfen der Übereinstimmung von Hostprofilen muss vCenter Server manchmal einen ESXi-Host nach mit Hostprofilen verwandten Daten abfragen. Der Zielhost für die Überprüfung der Übereinstimmung von Hostprofilen ist nicht unbedingt der ESXi-Host, den vCenter Server für diese Hostprofil-Datenabfragen verwendet. Eine Wettlaufsituation findet statt, wenn ein Kunde einen ESXi-Host aus der vCenter Server-Bestandsliste entfernt und gleichzeitig eine Überprüfung der Übereinstimmung von Hostprofilen durchführt. Während dieser Zeit tritt bei einer Abfrage auf Hostprofildaten ein Fehler mit folgender Meldung auf: Der Host ist nicht verfügbar zum Prüfen auf Übereinstimmung.

    Umgehung: Überprüfen Sie nach dem Entfernen des Hosts aus der vCenter Server-Bestandsliste die Übereinstimmung von Hostprofilen erneut. vCenter Server versucht, einen anderen Host zum Abfragen der Hostprofildaten zu verwenden.

  • Standardmäßige Systemdienste starten immer auf ESXi-Hosts, die mit Auto Deploy bereitgestellt wurden
    Im Falle von ESXi-Hosts, die mit Auto Deploy bereitgestellt wurden, wird die Startrichtlinie für Dienste im Abschnitt "Dienstkonfiguration" des entsprechenden Hostprofils nicht ganz eingehalten. Insbesondere wenn einer der Dienste, die auf ESXi standardmäßig eingeschaltet sind, einen Wert für die Startrichtlinie von offaufweist, startet dieser Dienst nach wie vor zur Startzeit auf dem mit Auto Deploy bereitgestellten ESXi-Host.

    Umgehung: Stoppen Sie den Dienst manuell, nachdem Sie den ESXi-Host gestartet haben.

  • Fehler bei der Übereinstimmung von Hostprofilen für Firewall-Regelsätze treten möglicherweise nach dem Standardisieren eines ESXi 5.1-Hosts mit einem ESXi 5.0-Hostprofil auf
    Beim Prüfen der Übereinstimmung anhand eines von einem ESXi 5.0-Host erstellten Hostprofils treten möglicherweise Übereinstimmungsfehler auf, die im Zusammenhang mit CIMHttpsService und CIMHttpService stehen.

    In einigen Fällen besteht möglicherweise eine Nichtübereinstimmung in einem Hostprofil zwischen dem aktivierten Zustand der Firewall-Regelsätze für die CIM/WBEM-Dienste (CIMHttpService und CIMHttpsService) und der Richtlinie zum Starten von Diensten für den CIM/WBEM-Dienst (sfcb-watchdog). Wenn der Dienst startet, werden die Firewallports automatisch geöffnet. Dies führt zu einem Übereinstimmungsfehler für die Firewall-Regelsätze des CIM-Diensts.

    Umgehung: Führen Sie eine der folgenden Umgehungen durch.

    • Sorgen Sie für die Konsistenz des Hostprofils, indem Sie die Firewall-Regelsatzunterprofile für den CIMHttpService und den CIMHttpsService im Hostprofil bearbeiten, sodass der aktivierte Parameter Trueist.
    • Navigieren Sie zur Sicherheitsprofilkonfiguration des ESXi-Hosts, von dem das Hostprofil erstellt wurde (oder des neuen Referenzhosts, falls er seit der Erstellung geändert wurde), und aktualisieren Sie die Firewallinformationen manuell. Führen Sie anschließend den Vorgang Hostprofil vom Referenzhost aktualisieren durch.

    Wenn Sie den vSphere Web Client verwenden, können Sie alternativ den Vorgang "Einstellungen vom Host kopieren" durchführen, um das Hostprofil zu aktualisieren.

  • Nach einem snmpd-Neustart erfolgt das Abrufen von Informationen von VMWARE-VMINFO-MIB nicht ordnungsgemäß
    Einige Informationen von VMWARE-VMINFO-MIB fehlen möglicherweise während SNMPWalk, nachdem Sie den snmpd-Daemon mithilfe von /etc/init.d/snmpd restartvon der ESXi Shell neu gestartet haben.

    Umgehung: Verwenden Sie /etc/init.d/snmpd restartnicht. Sie müssen zum Starten und Beenden des SNMP-Daemons den Befehl esxcli system snmp set --enableverwenden. Falls Sie /etc/init.d/snmpd restartverwendet haben, um snmpd von der ESXi Shell aus neu zu starten, starten Sie Hostd neu, entweder von der DCUI aus oder mithilfe von /etc/init.d/hostd restartvon der ESXi Shell aus.

    • Probleme bei vCenter Server und dem vSphere-Client
      • Die vCenter Server Appliance Web-Benutzeroberfläche funktioniert nicht in Firefox 14
        In Firefox 14 oder höher erscheinen die Registerkarten "Verwaltung", "Dienste" und "Speicher" nicht in der vCenter Server Appliance Web-Benutzeroberfläche. Die Seite "Admin" erscheint, ist aber leer. Damit wird die Konfiguration der Active Directory-Mitgliedschaft und anderer Einstellungen verhindert.

        Umgehung: Verwenden Sie einen anderen unterstützten Browser oder die Firefox Extended Support Release, die auf Firefox 10 basiert und hier heruntergeladen werden kann: http://www.mozilla.org/en-US/firefox/organizations/all.html.

      • Nicht installierte Plug-Ins erscheinen in der vSphere Web Client Plug-In-Verwaltungsschnittstelle
        Wenn Sie ein aktuell geladenes vSphere Web Client-Plug-In deinstallieren, zeigt die Plug-In-Verwaltungsschnittstelle das Plug-In weiterhin, bis der Webserver neu gestartet wird. Die Plug-In-Funktionalität selbst ist im vSphere Web Client nicht mehr verfügbar.

        Umgehung: Starten Sie den Webserver neu.

      • Die VM-Konsole des vSphere Web Client reagiert nicht auf Mauseingaben
        Im Falle von virtuellen Maschinen, auf denen einige Linux-Distributionen ausgeführt werden, reagiert die Konsole möglicherweise anfänglich nicht auf Mauseingaben, wenn Sie die Konsole vom vSphere Web Client aus starten.

        Umgehung: Klicken Sie auf Vollbildmodus, um in den Vollbildmodus zu wechseln.

      • Ein Webbrowser-Kontextmenü wird angezeigt, wenn Sie mit der rechten Maustaste auf ein Objekt in der vSphere Web Client-Bestandsliste klicken.
        Beim Verwenden von Windows 8 mit Internet Explorer 10 wird das Browser-Kontextmenü über dem Kontextmenü des Objekts angezeigt, wenn Sie zu einem Objekt in der vSphere Web Client-Bestandsliste navigieren und mit der rechten Maustaste klicken. .

        Umgehung: Klicken Sie in der Anwendung mit der rechten Maustaste an einer anderen Stelle, damit das Kontextmenü des Objekts angezeigt wird.

      • Ordner kann nicht gelöscht werden
        Wenn Sie die Berechtigung Folder.Delete folder nur auf Ordnerebene definiert haben, wird beim Versuch, diesen Ordner zu entfernen, eine Fehlermeldung generiert, die besagt, dass Sie nicht über die erforderlichen Berechtigungen verfügen.

        Umgehung: Keine.

      • Fehler des Typs Failed to read requestin vpxd.log
        Fehlermeldungen ähnlich der folgenden werden möglicherweise in der Datei vpxd.log protokolliert:
        2012-05-15T08:41:03.120Z [7F7DCB7C6700 error 'QsAdapter.HTTPService'] Failed to read request; stream: UNIX(/var/run/vmware/vpxd-qsadapter-pipe), error: N7Vmacore16TimeoutExceptionE(Operation timed out)
        2012-05-15T08:41:03.120Z [7F7DCB889700 error 'SoapAdapter.HTTPService'] Failed to read request; stream: TCP(), error: N7Vmacore16TimeoutExceptionE(Operation timed out)
        2012-05-15T08:41:33.124Z [7F7DCB5BE700 error 'SSL SoapAdapter.HTTPService'] Failed to read request; stream: SSL(no stream), error: N7Vmacore16TimeoutExceptionE(Operation timed out)
        2012-05-15T08:41:48.125Z [7F7DCB57D700 error 'SSL SoapAdapter.HTTPService'] Failed to read request; stream: SSL(no stream), error: N7Vmacore16TimeoutExceptionE(Operation timed out)
        2012-05-15T08:41:48.125Z [7F7DCAD75700 error 'SSL SoapAdapter.HTTPService'] Failed to read request; stream: SSL(no stream), error: N7Vmacore16TimeoutExceptionE(Operation timed out)
        2012-05-15T08:41:58.127Z [7F7DCBC58700 error 'SoapAdapter.HTTPService'] Failed to read request; stream: TCP(), error: N7Vmacore16TimeoutExceptionE(Operation timed out)

        Bei diesen Protokolleinträgen handelt es sich nicht um echte Fehler, vielmehr weisen sie nur auf einen Versuch hin, eine Verbindung zu einem externen Dienst herzustellen, der nicht ausgeführt wird.

        Umgehung: Keine.

      • Tag-Namen dürfen keine Surrogatpaarzeichen enthalten
        Wenn Sie versuchen, ein Tag mit einem Namen zu erstellen, der Surrogatpaarzeichen enthält, schlägt das Erstellen des Tags fehl.

        Umgehung: Verwenden Sie keine Surrogatpaarzeichen in Tag-Namen.

      • Änderungen am Hostnamen des vCenter Server-Systems werden nicht im vSphere Web Client oder in der Bestandsliste von vSphere Web Client widergespiegelt
        Wenn Sie den Hostnamen eines vCenter Server-Systems oder einer vCenter Server Appliance ändern, zeigt die lokale Maschine den neuen Hostnamen an, aber der alte Name wird im vSphere Web Client und in der vSphere-Client-Bestandsliste angezeigt.

        Umgehung: Verwenden Sie den vSphere-Client oder vSphere Web Client, um den Anzeigenamen des vCenter Server-Systems zu ändern.

        Führen Sie im vSphere Web Client Folgendes durch:

        1. Navigieren Sie zur vCenter Server-Instanz und wählen Sie die Registerkarte Verwalten.
        2. Klicken Sie unter Einstellungen auf Allgemein.
        3. Wählen Sie im Dialogfeld "vCenter Server-Einstellungen bearbeiten" Laufzeiteinstellungen aus.
        4. Geben Sie im Feld Name von vCenter Server den Namen für das vCenter Server-System ein.
        5. Klicken Sie auf OK.

        Führen Sie im vSphere-Client Folgendes durch:

        1. Wählen Sie Verwaltung > vCenter Server-Einstellungen.
        2. Falls das vCenter Server-System Teil einer Gruppe im verknüpften Modus ist, wählen Sie den Server, den Sie konfigurieren möchten, in der Dropdown-Liste Aktueller vCenter Server aus.

          Hinweis: Die vCenter Server Appliance unterstützt den verknüpften Modus nicht.

        3. Wählen Sie im Navigationsfenster die Option Laufzeiteinstellungen.
        4. Geben Sie im Feld Name von vCenter Server den Namen für das vCenter Server-System ein.
        5. Klicken Sie auf OK.

      • vSphere Web Client antwortet nicht, wenn mehrere Vorgänge ausgeführt werden
        Wenn Sie Vorgänge ausführen, die mehrere virtuelle Maschinen betreffen, z. B. das Ein- und Ausschalten von mehreren virtuellen Maschinen, antwortet der vSphere Web Client möglicherweise erst dann, wenn die Aufgaben abgeschlossen sind. Dies ist auf eine Einschränkung in Flash über die Anzahl der Aufgaben, die parallel ausgeführt werden dürfen, zurückzuführen. Der vSphere Web Client antwortet, wenn alle Aufgaben zum Server gesendet werden.

        Umgehung: Keine.

      • Das Sichern der Inventory Service-Datenbank schlägt fehl
        Das Sichern der Inventory Service-Datenbank, während Inventory Service ausgeführt wird, schlägt aufgrund eines Fehlers des Typs bad_certificatefehl.

        Umgehung: Fahren Sie den Inventory Service herunter, bevor Sie eine Datensicherung durchführen.

        Führen Sie auf einem Windows-System Folgendes durch:

        1. Halten Sie den Inventory Service an:
          1. Wählen Sie unter "Verwaltung" in der Windows-Systemsteuerung Dienste aus.
          2. Klicken Sie mit der rechten Maustaste auf "VMware vCenter Inventory Service" und wählen Sie Beenden aus.
        2. Öffnen Sie die Eingabeaufforderung und wechseln Sie in das Verzeichnis vCenter Server-Installationsverzeichnis\Infrastructure\Inventory Service\scripts.

          vCenter Server-Installationsverzeichnis ist das Verzeichnis, in dem Sie vCenter Server installiert haben. Dies ist standardmäßig C:\VMware\.

        3. Führen Sie an der Eingabeaufforderung den folgenden Befehl aus, um die Inventory Service-Datenbank zu sichern: backup.bat -file backup_file_name.

        Führen Sie auf einer vCenter Server Appliance Folgendes durch:

        1. Öffnen Sie eine Konsole und führen Sie den Befehl service vmware-inventory service stopaus, um den Inventory Service anzuhalten.
        2. Ändern Sie das Verzeichnis in /usr/lib/vmware-vpx/inventoryservice/scripts/.
        3. Führen Sie den folgenden Befehl aus, um die Inventory Service-Datenbank zu sichern: ./backup.sh -file backup_file_name.

      • Ein ESXi-Host kann unter Verwendung der Link-lokalen IPv6-Adresse nicht zur vCenter Server Appliance hinzugefügt werden
        Wenn Sie versuchen, unter Verwendung der Link-lokalen IPv6-Adresse des Formats fe80::* einen ESXi-Host zur vCenter Server Appliance hinzuzufügen, wird die folgende Fehlermeldung angezeigt: Kommunikation mit angegebenem Host nicht möglich.

        Umgehung: Verwenden Sie eine gültige IPv6-Adresse für den Host, bei der es sich nicht um eine Link-lokale Adresse handelt.

      • Das Aktivieren von DRS für einen Cluster erzeugt eine fehlerhafte Warnung über die Aktivierung von DPM
        Wenn Sie vom Bereich "Vorgang läuft" aus eine Aufgabe des Typs "Clusterdienste bearbeiten" fortsetzen und DRS aktivieren, sehen Sie möglicherweise eine Meldung, die fälschlicherweise besagt, dass DPM aktiviert wird. Dies geschieht, nachdem Sie sich vom vSphere Web Client abgemeldet und wieder angemeldet haben, während die Aufgabe "Clusterdienste bearbeiten" im Bereich "Vorgang läuft" gespeichert wurde.

        Umgehung: Es ist keine Umgehung erforderlich. DPM wird nicht aktiviert.

      • Suchvorgänge schlagen fehl und die Plug-Ins "Hardwarestatus" und "Systemzustand" werden im vSphere-Client deaktiviert
        Der vSphere-Client stellt keine Verbindung zum Inventory Service her, wenn er unter Windows 2003 oder Windows XP installiert wird. Dies hat die folgenden Auswirkungen:

        • Wenn Sie versuchen, die vSphere-Client-Bestandsliste zu durchsuchen, sehen Sie die Fehlermeldung Anmeldung beim Abfragedienst fehlgeschlagen. Ein Kommunikationsfehler ist beim Senden von Daten zum Server aufgetreten. (Die zugrunde liegende Verbindung wurde getrennt: Beim Senden ist ein unerwarteter Fehler aufgetreten.)
        • Die Plug-Ins "Hardwarestatus" und "Systemzustand" sind deaktiviert und können im vSphere-Client nicht angezeigt werden.

        Umgehung: Es gibt keine Umgehung für Windows XP 32-Bit. Wenden Sie für Windows 2003 und Windows XP 64-Bit den entsprechenden Hotfix wie folgt an.

        Plattform: x64
        Sprache: Englisch
        Pfad: ( http://hotfixv4.microsoft.com/Windows%20Server%202003/sp3/Fix192447/3790/free/351403_ENU_x64_zip.exe)

        Plattform: ia64
        Sprache: Englisch
        Pfad: ( http://hotfixv4.microsoft.com/Windows%20Server%202003/sp3/Fix192447/3790/free/351397_ENU_ia64_zip.exe)

        Plattform: i386
        Sprache: Englisch
        Pfad: ( http://hotfixv4.microsoft.com/Windows%20Server%202003/sp3/Fix192447/3790/free/351385_ENU_i386_zip.exe)

      • Die vCenter Server- und vCenter Single Sign On-Dienste starten nicht
        Wenn Sie den Hostnamen oder die Portzuweisung des Single Sign On-Datenbankservers ändern, schlägt Single Sign On fehl. Als Folge davon startet der vCenter Server nicht. Dieses Problem kann auch auftreten, wenn Sie SQL Server Express Edition verwenden, die zusammen mit Single Sign On und vCenter Server installiert wird. Falls SQL Server Express Edition für die Verwendung von dynamischen Ports konfiguriert ist, kann sich die Portzuweisung ändern, wenn Sie das System neu starten. Dies geschieht, wenn der Port von einem anderen Dienst belegt ist.

        Umgehung: Wenn Sie den Hostnamen oder den Port des Single Sign On-Datenbankservers ändern, müssen Sie Single Sign On mit dem neuen Hostnamen bzw. Port neu konfigurieren.

        1. Halten Sie den vCenter Single Sign On-Server an.
        2. Geben Sie den folgenden Befehl ein:
          <ssoserver folder>\utils> ssocli configure-riat -a configure-db --database-host <new database server> --database-port <new database port> -m <master password>
        3. Bearbeiten Sie die folgende Textdatei, um die Portnummer durch den neuen Wert zu ersetzen. Dies erfolgt in der Zeile, die wie folgt beginnt: db.url=:
          <ssoserver folder>\webapps\lookupservice\WEB-INF\classes\config.properties
        4. Starten Sie den vCenter Single Sign On-Server.

      • Durch das Anhängen einer Oracle-Datenbank an die vCenter Server Appliance wird eine Fehlermeldung hinsichtlich eines nicht kompatiblen Schemas angezeigt
        Wenn Sie versuchen, die vCenter Server Appliance mit einer externen Oracle-Datenbank zu konfigurieren, die zuvor mit einer vCenter Server 5.0-Appliance verwendet wurde, erhalten Sie die folgende Fehlermeldung: Fehler: Inkompatible DB-Schemaversion.

        Umgehung: Sie können den Assistenten für die Einrichtung der vCenter Server Appliance verwenden, um die Datenbank zurückzusetzen. Wenn Sie dies tun, werden alle Datensätze in der Datenbank gelöscht. Um die Datensätze in der Datenbank beizubehalten, führen Sie den im vSphere-Upgrade-Handbuch beschriebenen Upgrade-Vorgang durch, um ein Upgrade der vCenter Server Appliance und der Datenbank von vCenter Server 5.0 auf vCenter Server 5.1 durchzuführen.

        So setzen Sie die Datenbank zurück:

        1. Melden Sie sich bei der Web-Benutzeroberfläche der vCenter Server Appliance an und starten Sie den Assistenten für die Einrichtung.
        2. Geben Sie die Datenbankinformationen ein.

          Der Assistent zeigt die folgende Meldung an: Die Datenbank wurde mit einer inkompatiblen Schemaversion initialisiert.

        3. Wählen Sie DB-Inhalt zurücksetzen.

      • Fehlermeldungen im Zusammenhang mit Python-Skripts werden angezeigt, wenn eine ungültige Konfigurationsdatei in den Konfigurationsassistenten der vCenter Server Appliance hochgeladen wird
        Wenn Sie bei der anfänglichen Konfiguration im Assistenten der vCenter Server Appliance Konfigurationsdatei hochladen und dann eine ungültige Datei auswählen, werden in der Web-Benutzeroberfläche Fehlermeldungen im Zusammenhang mit Python-Skripts angezeigt.

        Umgehung: Keine.

      • Anmelde- oder Navigationsfehler nach Durchführung eines Upgrades einer vCenter Server Appliance mit einer statischen IP-Adresse
        Nach Durchführung eines Upgrades einer vCenter Server Appliance mit einer statischen IP-Adresse treten möglicherweise die folgenden Fehler auf:

        • Wenn Sie versuchen, sich bei der Web-Benutzeroberfläche der vCenter Server Appliance anzumelden, wird möglicherweise die folgende Fehlermeldung angezeigt: Es konnte keine Verbindung zum Server hergestellt werden. Bitte versuchen Sie es erneut.
        • Wenn Sie in der Web-Benutzeroberfläche der vCenter Server Appliance versuchen, zu einer neuen Seite zu navigieren, wird möglicherweise die folgende Fehlermeldung angezeigt: Nicht gefunden.

        Umgehung: Löschen Sie den Browser-Cache und melden Sie sich erneut bei der Web-Benutzeroberfläche der vCenter Server Appliance an.

      • Active Directory wird nicht als Identitätsquelle erkannt, wenn die vCenter Server Appliance mit einer Active Directory-Domäne verbunden ist, bevor vCenter Single Sign On gestartet wird
        Dies kann geschehen, wenn die vCenter Server Appliance als Teil ihrer Erstkonfiguration über den Konfigurationsassistenten der Web-Benutzeroberfläche mit einer Active Directory-Domäne verbunden wird. Nach Abschluss der Konfiguration funktionieren die entsprechenden vCenter Server- und vCenter Single Sign On-Dienste möglicherweise, aber Active Directory wird nicht als Identitätsquelle erkannt.

        Umgehung: Führen Sie einen der folgenden Schritte aus:

        • Starten Sie die vCenter Server-Appliance neu.
        • Starten Sie Single Sign On und anschließend den vSphere Web Client-Dienst neu.

      • vCenter Server Appliance-Einstellungen, die bei der Erstkonfiguration fehlgeschlagen sind, können nicht neu konfiguriert werden
        Bei der ersten Anmeldung bei der vCenter Server Appliance werden Sie vom Erstkonfigurationsassistenten aufgefordert, die Lizenzvereinbarung zu akzeptieren und die Datenbankoptionen, vCenter Single Sign On und Active Directory zu konfigurieren. Falls einer dieser Schritte fehlschlägt, führt der Konfigurationsassistent die verbleibenden Schritte durch und startet den vCenter Server-Dienst.

        Falls Sie versuchen, eine Einstellung neu zu konfigurieren, die der Assistent nicht konfigurieren konnte, wird die folgende Meldung angezeigt: Fehler: VPXD muss beendet sein, um diesen Vorgang durchzuführen.

        Umgehung: Führen Sie Folgendes durch:

        1. Melden Sie sich bei der Konsole der vCenter Server Appliance an und führen Sie den folgenden Befehl aus: /etc/init.d/vmware-vpxd stop
        2. Melden Sie sich bei der Web-Benutzeroberfläche der vCenter Server Appliance an und konfigurieren Sie die entsprechenden Einstellungen neu.
        3. Verwenden Sie die Web-Benutzeroberfläche, um den vCenter Server-Dienst neu zu starten.

      • Das in den Ergebnissen der erweiterten Suche aufgeführte verwandte Element ist möglicherweise nicht das in den Suchkriterien angegebene Element
        Wenn Sie im vSphere Web Client eine erweiterte Suche durchführen und eine Beziehung zwischen Objekten angeben, sind die Suchergebnisse richtig, aber das in den Ergebnissen aufgeführte verwandte Element ist möglicherweise nicht das in den Suchkriterien angegebene Element.

        Wenn Sie beispielsweise eine Suche nach allen Ordnern durchführen, deren Hostname "example" enthält, wird die richtige Liste der Ordner in den Suchergebnissen angezeigt. Der Host, der in der Spalte der verwandten Objekte aufgeführt ist, ist jedoch möglicherweise nicht der Host, dessen Namen "example" enthält, sondern ein anderer Host in dem Ordner.

        Umgehung: Keine.

      • Manche chinesischen und japanischen Zeichen werden nicht ordnungsgemäß im vSphere Web Client angezeigt
        Wenn Sie von einem Linux-System mit der Standardsprache Chinesisch oder Japanisch aus auf den vSphere Web Client zugreifen, werden einige Zeichen im vSphere Web Client als rechteckige Kästchen und nicht als chinesische oder japanische Zeichen dargestellt.

        Umgehung: Installieren Sie Linux mit der Standardsprache Englisch und ändern Sie nach Abschluss der Installation die Standardsprache in Chinesisch bzw. Japanisch.

      • Der Erstkonfigurationsassistent für die vCenter Server Appliance unterstützt die Konfiguration von statischen IP-Adressen nicht
        Wenn Sie sich zum ersten Mal nach der Bereitstellung bei der Web-Benutzeroberfläche der vCenter Server Appliance anmelden, wird der Konfigurationsassistent gestartet und fordert Sie auf, die Lizenzvereinbarung zu akzeptieren und die Datenbankoptionen, vCenter Single Sign On und Active Directory zu konfigurieren. Der Assistent bietet keine Netzwerkkonfigurationsoptionen. Die vCenter Server Appliance ist standardmäßig für die Verwendung von DHCP konfiguriert.

        Umgehung: Wenn Sie die Erstkonfiguration mithilfe des Assistenten abgeschlossen haben, muss das SSL-Zertifikat der Appliance geändert werden, um die Konfiguration in eine statische Netzwerkkonfiguration zu ändern:

        1. Klicken Sie auf der Seite "Admin" der Web-Benutzeroberfläche der vCenter Server Appliance auf die Schaltfläche Zertifikatseinstellungen umschalten, um die Option Neugenerierung des Zertifikats aktiviert auf Ja festzulegen.
        2. Konfigurieren Sie die statische IP-Adresse für die vCenter Server Appliance.

        Wenn Sie die Erstkonfiguration mithilfe des Assistenten noch nicht abgeschlossen haben, führen Sie die folgenden Schritte aus:

        1. Melden Sie sich bei der vCenter Server Appliance-Webschnittstelle an.
        2. Akzeptieren Sie die Lizenzvereinbarung und klicken Sie anschließend auf Abbrechen.
        3. Konfigurieren Sie das Netzwerk.

          Wenn Sie den Hostnamen oder die IP-Adresse ändern, wird die Verbindung zur Web-Benutzeroberfläche getrennt. Melden Sie sich erneut unter Angabe des neuen Hostnamens oder der neuen IP-Adresse an.

        4. Klicken Sie auf der Seite "vCenter Server" auf die Registerkarte "Übersicht".
        5. Klicken Sie auf die Schaltfläche Starten neben dem Assistenten für die Einrichtung. Schließen Sie die Einrichtung mithilfe des Assistenten ab, um die Erstkonfiguration der Appliance abzuschließen.

        Wenn Sie vCenter Server zum Bereitstellen der vCenter Server Appliance als ein OVF verwenden, können Sie während der Bereitstellung eine statische IP-Adresse konfigurieren. Diers betrifft allerdings nur Umgebungen, bei denen eine vCenter Server-Instanz bereitgestellt ist.

      • Der Hostname kann in der Web-Benutzeroberfläche der vCenter Server Appliance nicht geändert werden
        Wenn Sie versuchen, in der Web-Benutzeroberfläche der vCenter Server Appliance den Hostnamen zu ändern, schlägt dies möglicherweise fehl. Dieses Problem tritt auf, wenn eine Appliance für die Verwendung einer statischen IP-Adresse und eines Hostnamens konfiguriert ist. Wenn Sie auf der Registerkarte "Netzwerk" sowohl den Hostnamen als auch die IP-Adresse ändern und diese Einstellungen speichern, wird nur die IP-Adresse geändert. Der Hostname bleibt unverändert.

        Umgehung: Wenn Sie sowohl den Hostnamen als auch die IP-Adresse ändern müssen, nehmen Sie die Änderungen in zwei getrennten Vorgängen vor.

      • Beim Ändern der MTU für unabhängige Hardware-iSCSI im vSphere-Client müssen Sie zuerst Jumbo-Frames aktivieren
        Wenn Sie den vSphere-Client zum Ändern des MTU-Parameters im Dialogfeld "Erweiterte Einstellungen" verwenden, müssen Sie zuerst das Kontrollkästchen "Jumbo-Frame" aktivieren. Anderenfalls wird die MTU-Änderung nicht an den unabhängigen Hardwareadapter weitergeleitet. Das Kontrollkästchen "Jumbo-Frame" ist im vSphere Web Client nicht vorhanden, also ändern Sie den Wert im Eingabefeld "MTU".

        Umgehung:
        Im vSphere-Client:

        1. Wählen Sie einen Host aus dem Bestandslistenbereich aus.
        2. Klicken Sie auf die Registerkarte Konfiguration und anschließend unter Hardware auf Speicheradapter.
        3. Wählen Sie einen unabhängigen Hardwareadapter aus der Liste der Speicheradapter aus.
        4. Klicken Sie auf Eigenschaften und anschließend auf Erweitert.
        5. Aktivieren Sie Jumbo-Frames, indem Sie das Kontrollkästchen "Jumbo-Frame" aktivieren.
        6. Bearbeiten Sie den Wert im Eingabefeld "MTU" und klicken Sie auf "OK".
        7. Hinweis: Wenn Sie Jumbo-Frames aktivieren, aber einen Wert für die MTU-Größe eingeben, der 1500 Byte nicht überschreitet, wird das Aktivieren der Jumbo-Frames ignoriert.

        Im vSphere Web Client:
        1. Navigieren Sie zum Host im Objektnavigator von vSphere Web Client.
        2. Klicken Sie auf die Registerkarte Verwalten und anschließend auf Speicher.
        3. Klicken Sie auf Speicheradapter, und wählen Sie in der Liste der Adapter den unabhängigen Hardware-iSCSI-Adapter aus.
        4. Klicken Sie unter "Adapterdetails" auf die Registerkarte Erweiterte Optionen, und klicken Sie auf Bearbeiten.
        5. Ändern Sie den Wert des MTU-Parameters.

      • Nach dem Ersetzen der SSL-Zertifikate ist keine Anmeldung beim vCenter Server möglich
        Nachdem Sie die SSL-Zertifikate für vCenter Server ersetzt haben, können Sie sich möglicherweise nicht beim Server anmelden. Dies liegt daran, dass vCenter Server nicht neu gestartet wird, wenn Sie SSL-Zertifikate ersetzen. Sie müssen den Server neu starten, um das Zertifikat für Single Sign On zu aktualisieren.

        Umgehung: Starten Sie vCenter Server neu, nachdem Sie SSL-Zertifikate ersetzt haben.

      • Eine Java-E/A-Ausnahme wird in der Protokolldatei protokolliert, wenn Sie auf der vCenter Server Appliance vCenter Single Sign On starten
        Wenn Sie auf der vCenter Server Appliance vCenter Single Sign On starten, wird möglicherweise in /var/log/vmware/sso/catalina.outeine Java-E/A-Ausnahme protokolliert.

        Beispiel:

        java.io.IOException: ClientAbortException: java.net.SocketException: Broken pipe
        at com.sun.xml.ws.server.SDDocumentImpl.writeTo(SDDocumentImpl.java:278)
        at com.sun.xml.ws.transport.http.HttpAdapter.publishWSDL(HttpAdapter.java:539)

        Wenn Sie den Single Sign On-Server auf der vCenter Server Appliance anhalten, wird außerdem eine Meldung über Arbeitsspeicherverlust in /var/log/vmware/sso/catalina.outprotokolliert.

        Beispiel:

        SEVERE: The web application [/ims] appears to have started a thread named [Thread-4] but has failed to stop it. This is very likely to create a memory leak.

        Umgehung: Keine.

      • vCenter Server startet möglicherweise nicht oder Sie können sich beim vSphere Web Client nicht anmelden, nachdem Sie das Single Sign On-Serversystem neu gestartet haben
        Wenn Sie die Maschine neu starten, auf der vCenter Single Sign On installiert ist, treten möglicherweise Änderungen am System auf. Beispiele: Updates werden für das Betriebssystem durchgeführt, der Name der Maschine wird geändert oder die Maschine wird zu einer Active Directory-Domäne hinzugefügt oder aus einer Active Directory-Domäne entfernt. Diese Änderungen führen möglicherweise dazu, dass der Single Sign On-Server nicht antwortet, obwohl Single Sign On ausgeführt wird. Folglich startet vCenter Server nicht. Dies kann auch passieren, wenn Sie die Parameter einer virtuellen Maschine, auf der Single Sign On installiert ist, ändern oder klonen (z. B. die Arbeitsspeichermenge, die Anzahl der CPUs, die MAC-Adresse usw.).

        Umgehung: Führen Sie die folgenden Schritte aus.

        1. Suchen Sie auf dem System, auf dem Single Sign On installiert ist, das Single Sign On-Installationsverzeichnis und führen Sie den folgenden Befehl vom Ordner utilsaus:
          rsautil manage-secrets -a recover -m masterPassword
        2. Starten Sie den Single Sign On-Dienst neu.
        3. Starten Sie den vCenter Server-Dienst.
        1. Die Active Directory-Domäne des vCenter Server-Systems wird nicht in der Single Sign On-Serverliste der Identitätsquellen aufgeführt
          Wenn unter Windows vCenter Server auf einer Maschine installiert ist, die einer Active Directory-Domäne angehört, werden die Domänenbenutzer im vSphere-Client oder vSphere Web Client nicht angezeigt. Unter Linux wird die Fehlermeldung Domänenbenutzer kann nicht abgerufen werdenangezeigt.

          Umgehung: Konfigurieren Sie eine "Reverse Forward"-Lookup-Zone, einen entsprechenden Zeigerdatensatz und synchronisieren Sie die Systemuhr.

        2. Die vCenter Server Appliance unterstützt die Active Directory-Konfiguration mit IPv6 nicht
          Wenn Sie versuchen, Active Directory auf der vCenter Server Appliance mit IPv6 zu konfigurieren, schlägt die Konfiguration fehl.

          Umgehung: Konfigurieren Sie Active Directory auf der vCenter Server Appliance mit IPv4.

        3. Speicherprofile, die zuvor auf der vCenter Server Appliance erstellt wurden, sind nach einer Sicherung und Wiederherstellung der Inventory Service-Datenbank nicht sichtbar
          Nachdem Sie die Inventory Service-Datenbank gesichert und wiederhergestellt haben, sind Speicherprofile, die zuvor auf der vCenter Server Appliance erstellt wurden, nicht sichtbar.

          Umgehung:

          1. Melden Sie sich bei der Webkonsole der vCenter Server Appliance unter https:// IP-Adresse-der-Appliance:5480 an.
          2. Starten Sie den vmware-SPS-Dienst neu.

          Wenn der Dienst neu gestartet wurde, sind die Speicherprofile wieder sichtbar.

        4. Die vCenter Server Appliance unterstützt keine IPv6-Adressen in der Proxy-Einstellung
          Wenn Sie versuchen, auf der Seite Netzwerk der vCenter Server Appliance-Webkonsole eine IPv6-Adresse für die Proxy-Einstellung einzugeben, schlägt die Konfiguration fehl.

          Umgehung: Verwenden Sie eine IPv4-Adresse für die Proxy-Einstellung der vCenter Server Appliance.

        5. Nach bestimmten Vorgängen dauert es mehrere Minuten, bis die Anmeldeseite des vSphere Web Client geöffnet wird
          Wenn Sie die vSphere Web Client-URL in einem Browser öffnen, können Sie in der Regel erwarten, dass die Anmeldeseite sofort geöffnet wird. Wenn Sie jedoch die Installation erst abgeschlossen haben, den vSphere Web Client-Dienst neu starten oder die vCenter Server Appliance konfigurieren, wird die Anmeldeseite nicht sofort geöffnet. Möglicherweise sehen Sie einige Minuten lang eine leere Seite gefolgt von einer HTTP 404-Seite.

          Umgehung: Warten Sie einige Minuten und versuchen Sie dann, die Seite erneut zu aktualisieren. Wenn Sie nach 2 bis 4 Minuten die Seite aktualisieren, wird die Anmeldeseite ordnungsgemäß geöffnet.

        6. Unter Linux wird auf einigen vSphere Web Client-Seiten die Schriftart nicht ordnungsgemäß dargestellt
          Die Linux- und UNIX-Shell- (*nix/*nux) Web-Hosting-Dienste wenden die Adobe Flex Spark-Skins bei einigen vSphere Web Client-Seiten nicht ordnungsgemäß an. Beispiel: Fettschriftarten in Titeln werden nicht fett dargestellt.

          Umgehung: Installieren Sie die Microsoft True Type Core-Schriftarten (msttcorefonts) für Ihr Betriebssystem. Geben Sie beispielsweise für Ubuntu-Systeme an der Eingabeaufforderung sudo apt-get install msttcorefontsein.

        7. Anmeldung beim vSphere Web Client mit Windows-Sitzungsanmeldedaten nicht möglich
          Der vSphere Web Client unterstützt das Anmelden mit Windows-Sitzungsanmeldedaten nicht, wenn Sie bei Windows als ein lokaler Betriebssystembenutzer angemeldet sind. Sie müssen ein Active Directory-Benutzer einer Domäne sein, die als Identitätsquelle in vCenter Single Sign On vorhanden ist, wenn Sie sich beim vSphere Web Client mit Windows-Sitzungsanmeldedaten anmelden.

          Hinweis: Das Anmelden mit Windows-Sitzungsanmeldedaten wird nicht für vCenter Server 5.0-Systeme unterstützt.

          Umgehung: Um Windows-Sitzungsanmeldedaten für das Anmelden beim vSphere Web Client von einem Browser auf einem Windows-System aus zu verwenden, müssen Sie sich beim Windows-System als ein Active Directory-Benutzer einer Domäne anmelden, die als Identitätsquelle in vCenter Single Sign On vorhanden ist.

        8. Wenn Sie im vSphere Web Client auf "Protokoll-Browser" klicken, wird eine Fehlermeldung des Typs "Nicht autorisierter Zugriff" angezeigt.
          Wenn Sie im vSphere Web Client auf den Link "Protokoll-Browser" klicken, wird eine Fehlermeldung angezeigt: Exception: https://<system-address>:12443/vmwb/logbrowser: Nicht autorisierter Zugriff.Dieser Fehler tritt auf, nachdem Sie das Standard-SSL-Zertifikat des vCenter Single Sign On-Servers ersetzt haben, entweder direkt oder indem Sie das Zertifikat in der vCenter Server Appliance neu generiert haben.

          Umgehung:

          1. Melden Sie sich beim vSphere Web Client als Single Sign On-Administrator an.
          2. Navigieren Sie zu Verwaltung > Anmeldung und Erkennung > Konfiguration und klicken Sie auf die Registerkarte STS-Zertifikat.
          3. Klicken Sie auf Bearbeiten.
          4. Wählen Sie den Single Sign On SSL-Keystore aus.
            • Wenn Single Sign On auf einem Windows-System ausgeführt wird, wählen Sie die folgende Datei aus:
              C:\Programme\VMware\Infrastructure\SSOServer\security\server-identity.jks(Standardpfad)
            • Wenn Single Sign On unter Linux (vCenter Server Appliance) ausgeführt wird, wählen Sie die folgende Datei aus:
              /usr/lib/vmware-sso/security/server.jks(Standardpfad)
          5. Öffnen Sie die Single Sign On-Server-XML-Datei mit einem Texteditor oder einem Browser.
            • Unter Windows:
              C:\Programme\VMware\Infrastructure\SSOServer\conf\server.xml(Standardpfad)
            • Unter Linux:
              /usr/lib/vmware-sso/conf/server.xml(Standardpfad)
          6. Suchen Sie auf dem Connector-Element nach keystorePass="...". Die Zeichenfolge in Anführungszeichen ist Ihr Kennwort.
          7. Geben Sie das Kennwort beim vSphere Web Client ein, wenn Sie dazu aufgefordert werden.
          8. Wählen Sie nur die angezeigte Kette aus.
          9. Klicken Sie auf OK und geben Sie das Kennwort erneut ein.
          10. Starten Sie die folgenden Dienste neu: vSphere Web Client, vCenter Server, vCenter Inventory Service und den VMware Protokoll-Browser. Es ist kein Neustart von Single Sign On erforderlich.

        9. Die Authentifizierung schlägt fehl, wenn vCenter Single Sign On-Systembenutzer (System-Domain) versuchen, sich beim vSphere Web Client anzumelden
          Die Standard-Kennwortrichtlinie für vCenter Single Sign On-Systembenutzer gibt an, dass Kennwörter nach 365 Tagen ablaufen. vCenter Single Sign On erzeugt jedoch keine Warnung kurz vor Ablauf des Kennworts eines Benutzers.

          Umgehung: vCenter Single Sign On-Administratorbenutzer können abgelaufene Kennwörter für System-Domain-Benutzer ändern. Bitten Sie einen Administrator, Ihr Kennwort zurückzusetzen. Wenn Sie ein Single Sign On-Administratorbenutzer sind, verwenden Sie das Befehlszeilen-Tool ssopass, um das Kennwort zurückzusetzen.

          Unter Windows:

          1. Öffnen Sie ein Terminal-Fenster und navigieren Sie zum Verzeichnis C:\Programme\VMware\Infrastructure\SSOServer\ssolscli
          2. Führen Sie den folgenden Befehl aus.
            ssopass <username>
          3. Geben Sie das aktuelle Passwort für den Benutzer ein, auch wenn es abgelaufen ist.
          4. Geben Sie das neue Passwort ein und bestätigen Sie es durch nochmalige Eingabe.

          Unter Linux (vCenter Server Appliance):

          1. Öffnen Sie ein Terminalfenster und navigieren Sie zu "/usr/lib/vmware-sso/bin".
          2. Führen Sie den folgenden Befehl aus.
            ./ssopass <username>
          3. Geben Sie das aktuelle Passwort für den Benutzer ein, auch wenn es abgelaufen ist.
          4. Geben Sie das neue Passwort ein und bestätigen Sie es durch nochmalige Eingabe.

        10. Windows-Sitzungsauthentifizierung kann im vSphere Web Client nicht verwendet werden, wenn vCenter Single Sign On für High Availability konfiguriert ist
          Die Verwendung von Windows-Sitzungsauthentifizierung erfordert die Durchführung mehrerer, aufeinanderfolgender Aufrufe von Single Sign On und alle Aufrufe müssen an denselben Server gerichtet sein. Da der Security Token Service-Client (STS) keine Cookies akzeptiert, die vom STS gesendet werden, gibt es keine Garantie, dass die Aufrufe in einer High-Availability-Konfiguration an denselben Server gehen.

          Umgehung: Keine

        11. vCenter Server benötigt ungewöhnlich lange zum Starten und auf dem vSphere Client tritt eventuell Zeitablauf ein
          Wenn Objekten in der vCenter Server-Bestandsliste eine große Anzahl von Berechtigungen zugewiesen ist, startet der vCenter Server-Dienst nicht so schnell wie erwartet wird, da vCenter Server überprüft, ob die Benutzer und Gruppen in der Bestandslistenquelle existieren. Bei der Verbindung mit dem vSphere Client kann Zeitablauf eintreten, wenn Sie sich mit Windows-Sitzungsanmeldedaten anmelden. Die folgenden Meldungen erscheinen in den vCenter Server-Protokollen, während der Dienst startet:
          [SSO] [SsoAdminFacadeImpl] [Find Group]
          [UserDirectorySso] GetUserInfo (DOMAIN\ *USER OR GROUP*, true) res: DOMAIN\ *USER OR GROUP*
          [UserDirectorySso] NormalizeUserName (DOMAIN\ *USER OR GROUP*, false) re: DOMAIN\ *USER OR GROUP*

          Umgehung: Halten Sie die Anzahl der Berechtigungen, die Sie Objekten zuweisen, möglichst gering oder verwenden Sie die Vererbung von einem Objekt auf einer höheren Ebene, um die Anzahl von einzelnen Berechtigungszuweisungen zu verringern.

        VM-Verwaltungsprobleme
        • Das Kompatibilitätsupgrade der virtuellen Maschine von ESX 3.x und höher (VM-Version 4) konfiguriert fälschlicherweise den Flexible-Adapter einer virtuellen Maschine unter Windows auf den Standardtreiber des Windows-Systems
          Wenn Sie ein Windows-Gastbetriebssystem mit einem Flexible-Netzwerkadapter haben, der für den VMware Accelerated AMD PCnet-Adaptertreiber konfiguriert ist, und ein Upgrade der Kompatibilität der virtuellen Maschine von ESX 3.x und höher (VM-Version 4) auf eine spätere Kompatibilitätseinstellung durchführen, beispielsweise ESXi 4.x und später (VM-Version 7), konfiguriert Windows den Flexible-Adapter auf den Standardtreiber Windows AMD PCNET Family PCI Ethernet Adapter.
          Diese Fehlkonfiguration tritt auf, weil die VMware Tools-Treiber keine Signatur haben und Windows den Windows-Standardtreiber mit Signatur auswählt. Die Netzwerkeinstellungen des Flexible-Adapters, die vor dem Kompatibilitätsupgrade vorhanden waren, gehen verloren. Die Netzwerkgeschwindigkeit der Netzwerkkarte ändert sich von 1 GBit/s auf 10 MBit/s.

          Umgehung: Konfigurieren Sie die Flexible-Netzwerkadapter so, dass sie den VMXNET-Treiber des Windows-Gastbetriebssystems verwenden, wenn Sie ein Upgrade der Kompatibilität der virtuellen Maschine vornehmen. Wenn Ihr Gastbetriebssystem mit ESXi5.1 VMware Tools aktualisiert ist, wird der VMXNET-Treiber an folgendem Standort installiert: C:\Programme\Common Files\VMware\Drivers\vmxnet\.

        • Wenn Sie VMware Tools auf einer virtuellen Maschine installieren und einen Neustart durchführen, wird das Netzwerk unbrauchbar
          Auf virtuellen Maschinen mit dem CentOS 6.3-Betriebssystem oder dem Oracle Linux 6.3-Betriebssystem wird das Netzwerk unbrauchbar, wenn VMware Tools ordnungsgemäß installiert und die virtuelle Maschine neu gestartet wurde. Wenn Sie versuchen, die IP-Adresse von einem DHCP-Server manuell abzurufen oder eine statische IP-Adresse über die Befehlszeile festzulegen, wird die Fehlermeldung Es konnte kein Arbeitsspeicher zugeteilt werdenangezeigt.
          Das Problem ist, dass der Flexible-Netzwerkadapter, der standardmäßig verwendet wird, keine gute Wahl für diese Betriebssysteme ist.

          Umgehung: Ändern Sie den Netzwerkadapter von Flexible in E1000 oder VMXNET 3 wie folgt:

          1. Führen Sie den Befehl vmware-uninstall-tools.plaus, um VMware Tools zu deinstallieren.
          2. Schalten Sie die virtuelle Maschine aus.
          3. Klicken Sie im vSphere Web Client mit der rechten Maustaste auf die virtuelle Maschine und wählen Sie Einstellungen bearbeiten.
          4. Klicken Sie auf "Virtuelle Hardware" und entfernen Sie den aktuellen Netzwerkadapter, indem Sie auf das Symbol "Entfernen" klicken.
          5. Fügen Sie einen neuen Netzwerkadapter hinzu und wählen Sie den Adaptertyp E1000 oder VMXNET 3 aus.
          6. Schalten Sie die virtuelle Maschine ein.
          7. VMware Tools neu installieren
          8. .

        • Klon- oder Migrationsvorgänge, bei denen virtuelle Nicht-VMFS-Festplatten auf ESXi beteiligt sind, schlagen mit einem Fehler fehl
          Egal, ob Sie den Befehl "vmkfstools" oder den Client verwenden, um einen Klon-, Kopier- oder Migrationsvorgang auf den virtuellen Festplatten der gehosteten Formate durchzuführen, der Vorgang schlägt mit folgender Fehlermeldung fehl: Das System kann die angegebene Datei nicht finden.

          Umgehung: Um einen Klon-, Kopier- oder Migrationsvorgang auf den virtuellen Festplatten der gehosteten Formate durchzuführen, müssen Sie das VMkernel-multiextent-Modul in ESXi laden.

          1. Melden Sie sich bei der ESXi Shell an und laden Sie das multiextent-Modul.
            # vmkload_mod multiextent
          2. Überprüfen Sie, ob Ihre VM-Festplatten vom Typ "gehostet" sind. Gehostete Festplatten enden mit der Erweiterung -s00x.vmdk.
          3. Konvertieren Sie alle virtuellen Festplatten im gehosteten Format in eines der VMFS-Formate.
            1. Klonen Sie die gehostete Quellfestplatte "test1.vmdk nach test2.vmdk".
              # vmkfstools -i test1.vmdk test2.vmdk -d zeroedthick|eagerzereodthick|thin
            2. Löschen Sie nach dem erfolgreichen Klonvorgang die gehostete Festplatte "test1.vmdk".
              # vmkfstools -U test1.vmdk
            3. Benennen Sie die geklonte VMFS-Festplatte "test2.vmdk" in "test1.vmdk" um.
              # vmkfstools -E test2.vmdk test1.vmdk
          4. Entladen Sie das multiextent-Modul.
            #vmkload_mod -u multiextent

        • Das Anpassen einer virtuellen Windows-Maschine schlägt während des Klon- oder Bereitstellungsvorgangs fehl
          In vCenter Server schlägt die Gastanpassung einer virtuellen Windows 2008-, Windows 2008 R2- oder Windows 7-Maschine mit einem Fehler fehl: Interner Fehler beim Laden oder Suchen einer Antwortdatei für die unbeaufsichtigte InstallationDiese Problem tritt auf, weil die Anpassungsspezifikation eines der Zeichen &, >, <, ", oder ' in einem der folgenden Felder enthält: "Computername", "Registrierter Besitzername" bzw. "Registrierter Organisationsname".

          Umgehung: Verwenden Sie keine Sonderzeichen in diesen Feldern.

        • Der vSphere Client und der vSphere Web Client ermöglichen das Erstellen einer virtuellen Festplatte mit 2 TB - 1 MB Größe, wobei die maximal unterstützte Größe 2 TB - 512 Byte ist
          Wenn Sie mit dem vSphere Client und dem vSphere Web Client eine virtuelle Festplatte erstellen, können Sie eine virtuellen Festplatte mit maximal 2 TB - 1 MB einrichten. Die maximale unterstützte Größe einer virtuellen Festplatte ist aber 2 TB - 512 Byte.

          Umgehung: Verwenden Sie den Befehl vmkfstools, um die virtuelle Festplatte mit einer Größe von 2 TB - 512 Byte zu erstellen:
          vmkfstools -c --createvirtualdisk disk_size

        • Einer virtuellen Maschine ist keine IP-Adresse zugewiesen und sie erscheint nicht betriebsbereit
          Dieses Problem wird durch eine LUN-Rückstellungsanforderung bewirkt, die von einem Gastbetriebssystem ausgeht. Dieses Problem gilt speziell für das IBM XIV Fibre Channel-Array, wenn die Software FCoE in ESXi-Hosts konfiguriert ist. Virtuelle Maschinen, die in der LUN untergebracht sind, weisen folgende Probleme auf:

          • Den virtuellen Maschinen ist keine IP-Adresse zugewiesen.
          • Die virtuellen Maschinen können nicht ein- und ausgeschaltet werden.
          • In der Konsole wird kein Mauszeiger angezeigt. Daher kann die virtuelle Maschine im Gastbetriebssystem weder gesteuert noch bedient werden.

          Umgehung: Setzen Sie aus dem ESXi-Host die LUN zurück, auf der die virtuellen Maschinen untergebracht sind, die das Problem aufweisen.

          1. Führen Sie den folgenden Befehl aus, um die LUN-Informationen zu erhalten:
            # vmkfstools -P /vmfs/volumes/ DATASTORE_NAME
          2. Suchen Sie nach der folgenden Zeile in der Ausgabe, um die UID der LUN zu erhalten:
            Partitions spanned (on lvm): eui.001738004XXXXXX:1
            eui.001738004XXXXXXist die Geräte-UID.
          3. Führen Sie den folgenden Befehl aus, um die LUN zurückzusetzen:
            # vmkfstools -L lunreset /vmfs/devices/disks/eui.001738004XXXXXX
          4. Wenn eine nicht reagierende virtuelle Maschine in einem Datenspeicher liegt, dem mehrere LUNs zugewiesen sind, beispielsweise hinzugefügte Erweiterungen, führen Sie die LUN-Rückstellung für alle Datenspeichererweiterungen durch.

        VMware HA- und Fault Tolerance-Probleme
        • Fehlertolerante virtuelle Maschinen stürzen ab, wenn sie für das Erfassen von Statistikinformationen auf einem vCenter Server-Beta-Build eingerichtet sind
          Die vmx*3-Funktion ermöglicht es Benutzern, "stats vmx" zum Erfassen von Leistungsstatistiken für das Debuggen von Supportproblemen auszuführen. Wenn Fault Tolerance auf einem vCenter Server-Beta-Build aktiviert ist, ist "stats vmx" nicht kompatibel.

          Umgehung: Vergewissern Sie sich beim Aktivieren von Fault Tolerance, dass die virtuelle Maschine nicht für das Erfassen von Statistikinformationen auf einem vCenter Server-Beta-Build eingerichtet ist.

        • Virtuelle Maschinen in einem vSphere HA-Cluster mit Fault Tolerance werden möglicherweise nicht mehr geschützt, wenn ein APD-Fehler (All Paths Down, "keine Pfade verfügbar") auf allen Knoten auftritt
          Wenn in einem vSphere HA-Cluster ein APD-Zustand auf dem primären und sekundären Knoten für den eine virtuelle Maschine hostenden Datenspeicher auftritt, wird die virtuelle Maschine möglicherweise nicht geschützt. Dies ist darauf zurückzuführen, dass die sekundäre virtuelle Maschine nicht als neue primäre virtuelle Maschine gestartet werden kann, was wiederum auf ein Zeitablaufsproblem beim Melden von APD-Zuständen zurückzuführen ist. Dies kann dazu führen, dass die virtuelle Maschine unbekannt wird. Dieses Problem scheint nicht in einem Cluster mit einer kleineren Anzahl von fehlertoleranten virtuellen Maschinen aufzutreten.

          Umgehung:

          1. Heben Sie von vCenter Server aus die Registrierung der virtuellen Maschine auf und registrieren Sie sie erneut unter Verwendung desselben Namens wie zuvor. Die virtuelle Maschine wird auf dem alten primären Knoten wieder aktiv.
          2. Konfigurieren Sie den vSphere HA-Cluster und Fault Tolerance so, wie sie vorher konfiguriert waren.

        Probleme bei unterstützter Hardware
        • Der PCI-Status Unbekannt Unbekanntwird in vCenter Server auf dem Apple Mac Pro-Server angezeigt
          Auf der Registerkarte "Hardwarestatus" in vSphere 5.1 wird für einige PCI-Geräte auf dem Apple Mac Pro Unbekannt Unbekanntangezeigt. Dies ist auf fehlende Hardwarebeschreibungen für diese PCI-Geräte auf dem Apple Mac Pro zurückzuführen. Der Anzeigefehler auf der Registerkarte "Hardwarestatus" hindert diese PCI-Geräte nicht daran, ordnungsgemäß zu funktionieren.

          Umgehung: Keine.

        • Der PCI-Status Unbekannt Unbekanntwird in vCenter Server auf dem AMD PileDriver angezeigt
          Auf der Registerkarte "Hardwarestatus" in vSphere 5.1 wird für einige PCI-Geräte auf dem AMD PileDriver Unbekannt Unbekanntangezeigt. Dies ist auf fehlende Hardwarebeschreibungen für diese PCI-Geräte auf dem AMD PileDriver zurückzuführen. Der Anzeigefehler auf der Registerkarte "Hardwarestatus" hindert diese PCI-Geräte nicht daran, ordnungsgemäß zu funktionieren.

          Umgehung: Keine.

        • DPM wird auf dem Apple Mac Pro-Server nicht unterstützt
          Die Distributed Power Management-Funktion (DPM) von vSphere 5.1 wird auf dem Apple Mac Pro nicht unterstützt. Fügen Sie den Apple Mac Pro nicht zu einem Cluster hinzu, bei dem DPM aktiviert ist. Wenn der Host in den Zustand "Standby" wechselt, kann er den Standby-Zustand nicht beenden, wenn der Befehl zum Einschalten ausgegeben wird, und zeigt die Fehlermeldung Zeitüberschreitung beim Vorgangan. Der Apple Mac Pro wird nicht wieder aktiviert, wenn der Softwarebefehl zum Ausschalten, der von vSphere zum Versetzen eines Hosts in den Standby-Zustand verwendet wird, ausgegeben wird.

          Umgehung: Wenn der Apple Mac Pro-Host in den Zustand "Standby" wechselt, müssen Sie den Host wieder einschalten, indem Sie den Schalter zum Einschalten betätigen.

        • IPMI wird auf dem Apple Mac Pro-Server nicht unterstützt
          Auf der Registerkarte "Hardwarestatus" in vSphere 5.1 werden die richtigen Daten nicht angezeigt oder Daten für einige der Hardwarekomponenten auf dem Apple Mac Pro fehlen. Dies liegt daran, dass IPMI nicht für den Apple Mac Pro unterstützt wird.

          Umgehung: Keine.

        Sonstige Probleme
        • Nach einer Netzwerk- oder Speicherunterbrechung werden syslog über TCP, syslog über SSL und die Speicherprotokollierung nicht automatisch neu gestartet.
          Nach einer Netzwerk- oder Speicherunterbrechung wird in bestimmten Konfigurationen der syslog-Dienst nicht automatisch neu gestartet. Zu diesen Konfigurationen gehören syslog über TCP, syslog über SSL und der Interrupt "Speicherprotokollierung".

          Umgehung: Starten Sie syslog explizit neu, indem Sie den folgenden Befehl ausführen:
          esxcli system syslog reloadSie können auch syslog über UDP konfigurieren, was automatisch neu gestartet wird.

        • Windows Server 2012-Failover-Clustering wird nicht unterstützt
          Wenn Sie versuchen, einen Cluster für das Failover-Clustering in Windows Server 2012 zu erstellen, und angeben, dass Sie Validierungstests durchführen möchten, werden die Validierungstests mit Warnungen durchgeführt und danach werden die Validierungstests erneut durchgeführt. Der Assistent unter dem Gastbetriebssystem Windows Server 2012 setzt das Erstellen von Clustern nicht weiter fort.

          Umgehung: Keine.

        • Im vSphere Web Client-Protokollbrowser werden einige Protokolltypen nicht angezeigt
          Bei Windows-Installationen von vCenter Server und dem vSphere Web Client werden im Protokollbrowser die folgenden Protokolltypen nicht angezeigt:

          • Installieren
          • Lookup-Server
          • SSO-service-cfg

          Dieses Problem tritt in vLogBrowser in VMware Workbench nicht auf.

          Umgehung: Generieren Sie ein Protokollpaket und laden Sie es herunter. Verwenden Sie einen Texteditor zum Anzeigen der Protokolldateien.