VMware ESXi 5.1 Update1 | 25. April 2013 | Build 1065491

Letzte Aktualisierung: 25. April 2013

Ü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

Die vorliegende Version von VMware ESXi weist folgende Verbesserungen auf:

  • Unterstützung für weitere Gastbetriebssysteme In dieser Version wurde die Unterstützung für viele Gastbetriebssysteme aktualisiert.
    Eine vollständige Liste der von dieser Version unterstützten Gastbetriebssysteme finden Sie im VMware-Kompatibilitätshandbuch.

  • Behobene Probleme Diese Version enthält zahlreiche Fehlerkorrekturen, die im Abschnitt Behobene Probleme dokumentiert sind.

Vorherige Versionen von ESXi 5.1

Die Funktionen und bekannten Probleme von ESXi 5.1 werden in den entsprechenden Versionshinweisen beschrieben. Versionshinweise früherer Versionen von ESXi 5.1 finden Sie in den Versionshinweisen für VMware vSphere 5.1.

Internationalisierung

VMware vSphere 5.1 Update 1 gibt es in den folgenden Sprachen:

  • 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.

ESXi, vCenter Server und VDDK-Kompatibilität

Virtual Disk Development Kit (VDDK) 5.1.1 bietet Unterstützung für die Versionen ESXi 5.1 Update 1 und vCenter Server 5.1 Update 1. Weitere Informationen zu VDDK finden Sie unter http://www.vmware.com/support/developer/vddk/.

Hardwarekompatibilität für ESXi

Um herauszufinden, welche Prozessoren, Speichergeräte, SAN-Arrays und E/A-Geräte mit vSphere 5.1 Update 1 kompatibel sind, lesen Sie die Informationen zu ESXi 5.1 Update 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 Informationen zu ESXi 5.1 Update 1 im VMware-Kompatibilitätshandbuch, um die Gastbetriebssysteme zu ermitteln, die mit ESXi 5.1 Update 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 Update 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 Update 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 Update 1 verwenden möchten, führen Sie ein Upgrade der VM-Kompatibilität durch. Weitere Informationen finden Sie in der vSphere-Upgrade-Dokumentation.

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 Update 1 unterstützt nur CPUs mit LAHF- und SAHF-Befehlssätzen. Bei einer Installation oder einem Upgrade prüft das Installationsprogramm die Kompatibilität der Host-CPU mit vSphere 5.1 Update 1. Wenn Ihre Hosthardware nicht kompatibel ist, erscheint ein violetter Bildschirm mit einer entsprechenden Meldung und Sie können weder vSphere 5.1 Update 1 installieren noch ein Update darauf 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.

ESXi 5.1 Update 1 stellt die folgenden Tools für das Upgrade von ESX/ESXi-Hosts zur Verfügung:

  • 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 Update 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-, ESXi 5.0.x und ESXi 5.1-Hosts auf ESXi 5.1 Update 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.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 ESXi 5.1.x-Hosts aktualisieren und Patches darauf anwenden. Dies kann entweder von einem Download-Depot auf vmware.com oder von einer heruntergeladenen ZIP-Datei eines von einem VMware-Partner vorbereiteten Depots aus erfolgen. Sie können esxcli zum Durchführen eines Upgrades von ESX- oder ESXi-Hosts auf Version 5.1.x von ESX/ESXi-Versionen vor Version 5.1 verwenden.

Unterstützte Upgrade-Pfade für das Upgrade auf ESXi 5.1 Update 1:

Upgrade-Lieferumfang

Unterstützte Upgrade-Tools

Unterstützte Upgrade-Pfade auf ESXi 5.1 Update 1

ESX 4.0:
Umfasst
ESX 4.0 Update 1
ESX4.0 Update 2

ESX4.0 Update 3
ESX 4.0 Update 4

ESXi 4.0:
Umfasst
ESXi 4.0 Update 1
ESXi 4.0 Update 2

ESXi 4.0 Update 3
ESXi 4.0 Update 4

ESX 4.1:
Dazu gehören
ESX 4.1 Update 1
ESX 4.1 Update 2

ESX 4.1 Update 3

 

ESXi 4.1 :
Dazu gehören
ESXi 4.1 Update 1

ESXi 4.1 Update 2
ESXi 4.1 Update 3

ESXi 5.0:
Umfasst
ESXi 5.0 Update 1

ESXi 5.0 Update 2

ESXi 5.1

VMware-VMvisor-Installer-5.1.0.update01-xxxxxx.x86_64.iso

 

  • VMware vCenter Update Manager
  • CD-Upgrade
  • Skriptbasiertes Upgrade

Ja

Ja

Ja

Ja

Ja

Ja

update-from-esxi5.1-5.1_update01.zip
  • VMware vCenter Update Manager
  • ESXCLI
  • VMware vSphere-CLI

Nein

Nein

Nein

Nein

Nein

Ja

Verwendung von Patch-Definitionen, die vom VMware-Portal (online) heruntergeladen werden

VMware vCenter Update Manager mit Patch-Baseline

Nein

Nein

Nein

Nein

Nein

Ja

 

Open Source-Komponenten für VMware vSphere 5.1 Update 1

Informationen über Copyright und Lizenzen für die Open Source-Softwarekomponenten, die im Lieferumfang von vSphere 5.1 Update 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 (virtuelle Maschine zu virtuelle Maschine) 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.

In dieser Version enthaltene Patches

Diese Version enthält alle Bulletins für ESXi, die vor dem Veröffentlichungsdatum dieses Produkts zur Verfügung standen. Weitere Informationen zu den einzelnen Bulletins finden Sie auf der VMware-Seite Patches herunterladen.

Patch-Version ESXi510-Update01 enthält die folgenden einzelnen Bulletins:

ESXi510-201304201-UG: Aktualisiert ESXi 5.1 esx-base vib
ESXi510-201304202-UG: Aktualisiert ESXi 5.1 tools-light vib
ESXi510-201304203-UG: Aktualisiert ESXi 5.1 net-ixgbe vib
ESXi510-201304204-UG: Aktualisiert ESXi 5.1 ipmi-ipmi-si-drv vib
ESXi510-201304205-UG: Aktualisiert ESXi 5.1 net-tg3 vib
ESXi510-201304206-UG: Aktualisiert ESXi 5.1 misc-drivers vibs
ESXi510-201304207-UG: Aktualisiert ESXi 5.1 net-e1000e vib
ESXi510-201304208-UG: Aktualisiert ESXi 5.1 net-igb vib
ESXi510-201304209-UG: Aktualisiert ESXi 5.1 scsi-megaraid-sas vib
ESXi510-201304210-UG: Aktualisiert ESXi 5.1 net-bnx2 vib


Patch-Version ESXi510-Update01 Security-only enthält die folgenden einzelnen Bulletins:

ESXi510-201304101-SG: Aktualisiert ESXi 5.1 esx-base vib
ESXi510-201304102-SG: Aktualisiert ESXi 5.1 tools-light vib
ESXi510-201304103-SG - Aktualisiert ESXi 5.1 net-bnx2x vib
ESXi510-201304104-SG - Aktualisiert ESXi 5.1 esx-xserver vib


Patch-Version ESXi510-Update01 enthält die folgenden Image-Profile:

ESXi-5.1.0-20130402001-standard
ESXi-5.1.0-20130402001-no-tools

Patch-Version ESXi510-Update01 Security-only enthält die folgenden Image-Profile:

ESXi-5.1.0-20130401001s-standard
ESXi-5.1.0-20130401001s-no-tools


Weitere Informationen zur Klassifizierung von Patches und Updates finden Sie unter KB 2014447.

Behobene Probleme

In diesem Abschnitt werden die behobenen Probleme dieser Version unter den folgenden Themengebieten beschrieben:

CIM und API

  • Die von ESXi 5.1-Hosts gemeldete SMBIOS-UUID unterscheidet sich möglicherweise von der tatsächlichen SMBIOS-UUID
    Wenn das ESXi 5.1-System ein SMBIOS der Version 2.6 oder höher aufweist, kann sich die vom ESXi 5.1-Host gemeldete SMBIOS-UUID von der tatsächlichen SMBIOS-UUID unterscheiden. Die Byte-Reihenfolge der ersten drei Felder der UUID ist nicht korrekt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • ESXi 5.x-Host scheint in vCenter Server getrennt zu sein und protokolliert die Meldung "Ramdisk (root) ist voll" in der Datei vpxa.log
    Wenn das Simple Network Management-Protokoll (SNMP) die Anzahl der SNMP-Trap-Dateien ( .trp) im Ordner /var/spool/snmpvon ESXi nicht bewältigen kann, scheint der Host in vCenter Server möglicherweise getrennt zu sein. Sie können u. U. keine Aufgaben auf dem Host durchführen.
    Die Datei vpxa.logenthält mehrere Einträge der folgenden Art:
    WARNING: VisorFSObj: 1954: Die Datei
    /var/run/vmware/f4a0dbedb2e0fd30b80f90123fbe40f8.lck kann für den Prozess "vpxa" nicht erstellt werden, da die inode-Tabelle von dessen Ramdisk (root) voll ist.
    WARNING: VisorFSObj: 1954: Die Datei
    /var/run/vmware/watchdog-vpxa.PID kann für den Prozess "sh" nicht erstellt werden, da die inode-Tabelle von dessen Ramdisk (root) voll ist.


    Dieses Problem wurde in der vorliegenden Version behoben.
  • vCenter Server oder vSphere-Client kann den HHRC (Host Hardware RAID Controller)-Status nicht überwachen
    Wenn Sie einen HHRC-CIM-Anbieter, z. B. einen LSI-CIM-Anbieter, installiert haben, schlägt der Prozess "sfcb-hhrc" fehl, wenn ein Fehler im Wrapped-HHRC-CIM-Anbieter auftritt.

    Das Problem wird in der vorliegenden Version dadurch behoben, dass die Fehlerbehandlungsfunktion und die Robustheit des HHRCWrapperProvider verbessert wurden.

Gastbetriebssystem

  • Wenn Sie eine virtuelle Maschine unter Verwendung von Hardware Version 9 erstellen, steht die 64-Bit-Option für Mac OS X 10.8 nicht zur Verfügung
    Wenn Sie in vSphere 5.1 eine virtuelle Maschine unter Verwendung von Hardware Version 9 erstellen, erscheint die 64-Bit-Option für das Betriebssystem Mac OS X 10.8 nicht in der Dropdown-Liste der Gastbetriebssysteme.

    Dieses Problem wurde in der vorliegenden Version behoben, sofern Sie den NGC-Client zum Herstellen einer Verbindung mit vSphere 5.1 Update 1 verwenden.
  • Der Zeitstempelzähler (TSC) ist für virtuelle Solaris 10-Maschinen nicht korrekt kalibriert
    Dieses Problem wurde in der vorliegenden Version behoben.
    Um die TSC-Kalibrierung innerhalb der Toleranz des NTP-Protokolls zu korrigieren, wurde eine Unterstützung für die Gast-Timer-Kalibrierung für Solaris 10-Gastbetriebssysteme hinzugefügt.
  • Auf einem ESXi 5.1-Host reagieren virtuelle Maschinen mit beanspruchten vCPUs möglicherweise nicht
    Virtuelle Maschinen auf einem ESXi 5.1-Host, die unter VM-Hardwareversion 7 ausgeführt werden, reagieren möglicherweise nicht, wenn ihre vCPUs beschäftigt sind. Dieses Problem betrifft virtuelle Maschinen, bei denen das Gastbetriebssystem den logischen APIC-Zielmodus verwendet. Virtuelle Maschinen, bei denen das Gastbetriebssystem den physischen Zielmodus verwendet, sind davon nicht betroffen.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Die Funktion CreateTemporaryFile InGuest() führt möglicherweise zu einer Ausnahme des Typs GuestPermissionDeniedFault
    Wenn Sie eine eingeschaltete virtuelle Maschine neu konfigurieren, um einen SCSI-Controller aufzunehmen, und versuchen, eine temporäre Datei auf dem Gastbetriebssystem zu erstellen, schlägt der Vorgang möglicherweise mit einer Ausnahme vom Typ GuestPermissionDeniedFaultfehl.

    Dieses Problem wurde in der vorliegenden Version behoben.

Sonstige Probleme

  • Bei Verwendung des Befehls "invoke-vmscript" tritt ein Fehler auf
    Wenn Sie PowerCLI-Befehlsskripts mit dem cmdlet invoke-vmscriptauf einer virtuellen Maschine ausführen, schlägt die Skriptausführung mit der folgenden Fehlermeldung fehl:

    Der Agent des Gastbetriebssystems konnte nicht kontaktiert werden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESXi-Host schlägt mit einem violetten Diagnosebildschirm fehl, wenn Sie versuchen, eine Tastatur oder eine Maus mit einem USB-Anschluss zu verbinden oder eine solche Verbindung zu trennen
    Wenn Sie versuchen, eine Tastatur oder eine Maus mit einem USB-Anschluss zu verbinden oder eine solche Verbindung trennen, schlägt der ESXi-Host mit folgender Fehlermeldung fehl:
    PCPU## locked up. Failed to ack TLB invalidate.

    Weitere Informationen finden Sie unter KB 2000091.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das erstmalige Beitreten eines ESXi-Hosts zu einer Domäne mithilfe des vSphere Authentication Proxy-Diensts (CAM-Dienst) schlägt aufgrund einer Verzögerung der DC-Replizierung möglicherweise fehl
    Der automatisierte Vorgang zum erstmaligen Hinzufügen eines ESXi-Hosts mithilfe des vSphere Authentication Proxy-Diensts (CAM-Dienst) schlägt möglicherweise mit einer Fehlermeldung der folgenden Art fehl:

    Anmeldung aufgrund eines falschen Benutzernamens oder Kennworts nicht möglich

    Dieses Problem tritt auf, wenn der Authentication Proxy-Dienst das Konto auf einem Domänencontroller erstellt und der ESXi-Host mit einem anderen Domänencontroller kommuniziert, was zu einer Verzögerung bei der Domänencontroller-Replizierung führt. Daher schlägt die Verbindung des ESXi-Hosts mit dem Domänencontroller (DC) mit dem neu erstellten Konto fehl.
    Das Problem tritt nicht auf, wenn der ESXi-Host direkt zur Active Directory-Domäne hinzugefügt wird, also ohne den Authentication Proxy-Dienst zu verwenden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Komponentenbasierte Protokollierung und erweiterte Konfigurationen wurden zur hostd-Protokollierungsebene hinzugefügt
    In älteren Versionen war es schwierig, während eines Problems geeignete Protokolle abzurufen. Um dieses Problem zu vermeiden, wird in der vorliegenden Version die komponentenbasierte Protokollierung eingeführt. Dabei werden die Protokollierer in verschiedene Gruppen unterteilt und ihnen unterschiedliche Präfixe zugeordnet. Zudem können Sie mithilfe der neuen erweiterten Konfiguration die Protokollierungsebene des hostd-Protokolls ohne Neustart ändern.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Virtuelle Maschinen mit Windows 2003 R2 64-Bit als Gastbetriebssystem auf einem ESXi-Host mit vShield Endpoint schlagen möglicherweise mit einem blauen Diagnosebildschirm fehl
    Ein fehlerhafter API-Aufruf im vShield Endpoint-Treiber vsepflt.sysführt möglicherweise bei virtuellen Maschinen mit Windows 2003 R2 64-Bit als Gastbetriebssystem zur Anzeige eines blauen Diagnosebildschirms.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • VMware Ondisk Metadata Analyser (VOMA) schlägt mit einem Segmentierungsfehler fehl
  • VMware Ondisk Metadata Analyser (VOMA) schlägt aufgrund des VMFSCK-Moduls mit einem Segmentierungsfehler fehl.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der vSphere-Netzwerk-Core-Dump erfasst keine vollständigen Daten
    Der vSphere-Netzwerk-Core-Dump erfasst keine vollständigen Daten, wenn der Festplatten-Dump aufgrund ungenügender Dump-Steckplatzgröße einige Daten nicht erfassen kann.

    Dieses Problem wurde in der vorliegenden Version behoben. Fehler aufgrund der Steckplatzgröße des Festplatten-Dumps haben keine Auswirkung auf den Netzwerk-Core-Dump mehr.

  • ESXi-Hosts schlagen möglicherweise fehl, wenn der hostd-worker-Thread 100 % der CPU-Ressourcen verbraucht
    Unter einer ausreichend hohen Arbeitslast des ESXi-Hosts kann es vorkommen, dass der hostd-worker-Thread dauernd 100 % der CPU verbraucht, wenn die VM-Screenshot-Datei für vCloud Director UI abgerufen wird. Dieses Problem kann dazu führen, dass der ESXi-Host ausfällt.

    Dieses Problem wurde in der vorliegenden Version behoben.

Netzwerk

  • Lang laufende vMotion-Vorgänge führen möglicherweise zu einer Unicast-Überflutung
    Wenn bei Verwendung der Multiple-NIC vMotion-Funktion mit vSphere 5 vMotion-Vorgänge über einen langen Zeitraum ausgeführt werden, tritt bei allen Schnittstellen des physischen Switches eine Unicast-Überflutung auf. Wenn die vMotion-Funktion länger benötigt als die Verwendungsdauer der MAC-Adressentabelle, empfängt der Quell- und Zielhost große Mengen an Netzwerkverkehr.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Ein ESXi-Host zeigt nach erfolgreicher Anwendung eines Hostprofils auf den Host möglicherweise einen Übereinstimmungsfehler an
    Wenn Sie ein Hostprofil erfolgreich auf einen ESXi-Host anwenden, kann es passieren, dass der Host eine Nichtkonformität feststellt und eine Fehlermeldung ähnlich der folgenden anzeigt:
    IPv4-Routen stimmen nicht überein

    Dieses Problem tritt auf, wenn zwei oder mehr VMkernel-Portgruppen dasselbe Subnetz verwenden.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Virtuelle Maschinen mit dem VMXNET 3 vNIC-Netzwerkadapter generieren möglicherweise Fehlermeldungen in der hostd-Protokolldatei
    Virtuelle Maschinen mit dem VMXNET 3 vNIC-Netzwerkadapter generieren in der hostd-Protokolldatei möglicherweise Fehlermeldungen der folgenden Art:

    2012-06-12T07:09:03.351Z [5E342B90 error 'NetworkProvider'] Unknown port type [0]: convert to UNKNOWN.
    2012-06-12T07:09:03.351Z [5E342B90 error 'NetworkProvider'] Unknown port type [0]: convert to UNKNOWN.
    2012-06-12T07:09:03.351Z [5E342B90 error 'NetworkProvider'] Unknown port type [0]: convert to UNKNOWN.


    Dieses Problem tritt auf, wenn der Porttyp nicht festgelegt ist. Sie können diese Meldung ignorieren. Dieses Verhalten ist normal.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Während arpresolve reagiert der ESXi-Host nicht mehr und zeigt einen violetten Diagnosebildschirm an
    Während arpresolve reagiert der ESXi-Host möglicherweise nicht mehr und zeigt einen violetten Diagnosebildschirm mit den folgenden Meldungen an:

    2012-08-30T14:35:11.247Z cpu50:8242)@BlueScreen: #PF Exception 14 in world 8242:idle50 IP 0x4180280056ad addr 0x1
    2012-08-30T14:35:11.248Z cpu50:8242)Code start: 0x418027800000 VMK uptime: 7:14:19:29.193
    2012-08-30T14:35:11.249Z cpu50:8242)0x412240c87868:[0x4180280056ad]arpresolve@ # +0xd4 stack: 0x412240c878a8
    2012-08-30T14:35:11.249Z cpu50:8242)0x412240c878e8:[0x418027ff69ba]ether_output@ # +0x8d stack: 0x412240c87938
    2012-08-30T14:35:11.250Z cpu50:8242)0x412240c87a28:[0x4180280065ad]arpintr@ # +0xa9c stack: 0x41003eacd000
    2012-08-30T14:35:11.251Z cpu50:8242)0x412240c87a68:[0x418027ff6f76]ether_demux@ # +0x1a1 stack: 0x41003eacd000
    2012-08-30T14:35:11.252Z cpu50:8242)0x412240c87a98:[0x418027ff72c4]ether_input@ # +0x283 stack: 0x412240c87b50
    2012-08-30T14:35:11.253Z cpu50:8242)0x412240c87b18:[0x418027fd338f]TcpipRx@ # +0x1de stack: 0x2
    2012-08-30T14:35:11.254Z cpu50:8242)0x412240c87b98:[0x418027fd2d9b]TcpipDispatch@ # +0x1c6 stack: 0x410008ce6000
    2012-08-30T14:35:11.255Z cpu50:8242)0x412240c87c48:[0x4180278ed76e]WorldletProcessQueue@vmkernel#nover+0x3c5 stack: 0x0
    2012-08-30T14:35:11.255Z cpu50:8242)0x412240c87c88:[0x4180278edc79]WorldletBHHandler@vmkernel#nover+0x60 stack: 0x2
    2012-08-30T14:35:11.256Z cpu50:8242)0x412240c87ce8:[0x41802781847c]BHCallHandlers@vmkernel#nover+0xbb stack: 0x100410000000000
    2012-08-30T14:35:11.257Z cpu50:8242)0x412240c87d28:[0x41802781896b]BH_Check@vmkernel#nover+0xde stack: 0x4a8a29522e753
    2012-08-30T14:35:11.258Z cpu50:8242)0x412240c87e58:[0x4180279efb41]CpuSchedIdleLoopInt@vmkernel#nover+0x84 stack: 0x412240c87e98
    2012-08-30T14:35:11.259Z cpu50:8242)0x412240c87e68:[0x4180279f75f6]CpuSched_IdleLoop@vmkernel#nover+0x15 stack: 0x62
    2012-08-30T14:35:11.260Z cpu50:8242)0x412240c87e98:[0x41802784631e]Init_SlaveIdle@vmkernel#nover+0x13d stack: 0x0
    2012-08-30T14:35:11.261Z cpu50:8242)0x412240c87fe8:[0x418027b06479]SMPSlaveIdle@vmkernel#nover+0x310 stack: 0x0
    2012-08-30T14:35:11.272Z cpu50:8242)base fs=0x0 gs=0x41804c800000 Kgs=0x0

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Virtuelle Solaris 11-Maschinen mit dem VMXNET3-Netzwerkadapter schreiben möglicherweise alle 30 Sekunden Meldungen in den Ordner /var/adm/messages
    Virtuelle Solaris 11-Maschinen mit dem VMXNET3-Netzwerkadapter schreiben möglicherweise Meldungen in den Ordner /var/adm/messages. Unter Umständen wird eine Fehlermeldung wie die folgende in das Systemprotokoll eingetragen:
    vmxnet3s: [ID 654879 kern.notice] vmxnet3s:1: getcapab(0x200000) -> no
    Dieses Problem tritt alle 30 Sekunden neu auf.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • Aufgrund eines Fehlers beim Reinigen des Transit-Rings reagiert ein ESXi-Host möglicherweise nicht mehr und zeigt einen violetten Diagnosebildschirm an
    Ein ESXi-Host reagiert möglicherweise nicht mehr und zeigt einen violetten Diagnosebildschirm mit Meldungen ähnlich der folgenden an:

    @BlueScreen: #PF Exception 14 in world 4891:vmm0:HQINTSQ IP 0x41800655ea98 addr 0xcc
    41:11:55:21.277 cpu15:4891)Code start: 0x418006000000 VMK uptime: 41:11:55:21.277
    41:11:55:21.278 cpu15:4891)0x417f818df948:[0x41800655ea98]e1000_clean_tx_irq@esx:nover+0x9f stack: 0x4100b5610080
    41:11:55:21.278 cpu15:4891)0x417f818df998:[0x418006560b9a]e1000_poll@esx:nover+0x18d stack: 0x417f818dfab4
    41:11:55:21.279 cpu15:4891)0x417f818dfa18:[0x41800645013a]napi_poll@esx:nover+0x10d stack: 0x417fc68857b8
    41:11:55:21.280 cpu15:4891)0x417f818dfae8:[0x4180060d699b]WorldletBHHandler@vmkernel:nover+0x442 stack: 0x417fc67bf7e0
    41:11:55:21.280 cpu15:4891)0x417f818dfb48:[0x4180060062d6]BHCallHandlers@vmkernel:nover+0xc5 stack: 0x100410006c38000
    41:11:55:21.281 cpu15:4891)0x417f818dfb88:[0x4180060065d0]BH_Check@vmkernel:nover+0xcf stack: 0x417f818dfc18
    41:11:55:21.281 cpu15:4891)0x417f818dfc98:[0x4180061cc7c5]CpuSchedIdleLoopInt@vmkernel:nover+0x6c stack: 0x410004822dc0
    41:11:55:21.282 cpu15:4891)0x417f818dfe68:[0x4180061d180e]CpuSchedDispatch@vmkernel:nover+0x16e1 stack: 0x0
    41:11:55:21.282 cpu15:4891)0x417f818dfed8:[0x4180061d225a]CpuSchedWait@vmkernel:nover+0x20d stack: 0x410006108b98
    41:11:55:21.283 cpu15:4891)0x417f818dff28:[0x4180061d247a]CpuSched_VcpuHalt@vmkernel:nover+0x159 stack: 0x4100a24416ac
    41:11:55:21.284 cpu15:4891)0x417f818dff98:[0x4180060b181f]VMMVMKCall_Call@vmkernel:nover+0x2ba stack: 0x417f818dfff0
    41:11:55:21.284 cpu15:4891)0x417f818dffe8:[0x418006098d19]VMKVMMEnterVMKernel@vmkernel:nover+0x10c stack: 0x0
    41:11:55:21.285 cpu15:4891)0xfffffffffc058698:[0xfffffffffc21d008]__vmk_versionInfo_str@esx:nover+0xf59cc9f7 stack: 0x0
    41:11:55:21.297 cpu15:4891)FSbase:0x0 GSbase:0x418043c00000 kernelGSbase:0x0

    Dieser Fehler triff auf, wenn während der Reinigung des Transit-Rings die CPU für die Durchführung anderer Aufgaben vorgesehen ist. Falls in der Zwischenzeit eine andere CPU den Ring reinigt, wird die erste CPU den Ring fälschlicherweise reinigen und so die Referenz einer null-SKB aufheben.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Netzwerkkonnektivität auf virtuellen IPv6-Maschinen funktioniert nicht mit VMXNET3
    Wenn auf einer VMXNET3-Schnittstelle mehr als 32 IPv6-Adressen konfiguriert sind, werden die Unicast- und Multicast-Verbindungen zu einigen dieser Adressen unterbrochen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Update des tg3-Treibers auf Version 3.123b.v50.1
    Der mit ESXi 5.1 Update 1 mitgelieferte tg3-Inbox-Treiber hat die Version 3.123b.v50.1.
  • Hostprofil kann möglicherweise keinen MTU-Wert auf den vSwitches des Zielhosts anwenden
    Wenn Sie ein Hostprofil anwenden, das nur den MTU-Wert für einen Standard-vSwitch ändert, wird die neue MTU-Konfiguration nicht auf den vSwitches des neuen Zielhosts angewendet.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • Eine virtuelle Maschine könnte nach einer vMotion-Migration in einer vNetwork Distributed Switch-Umgebung die Netzwerkkonnektivität mit der externen Umgebung verlieren
    Eine virtuelle Maschine verliert nach einer vMotion-Migration in einer Umgebung mit verteilten vNetwork Switches möglicherweise die Netzwerkkonnektivität mit der externen Umgebung.
    Dieses Problem kann auftreten, wenn gleichzeitig alle folgenden Bedingungen erfüllt sind:
    • Die VM-Netzwerkportgruppe ist auf dem vNetwork Distributed Switch konfiguriert.
    • Die virtuelle Maschine ist mit VMXNET2 (erweitert)- oder Flexible(VMXNET)-Netzwerkkarte konfiguriert.
    • Die Sicherheitseinstellung für die VM-Netzwerkportgruppe ist auf MAC-Adressenänderungen ablehnen festgelegt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • ESX/ESXi-Host mit Broadcom bnx2x Async-Treiber Version 1.61.15.v50.1 schlägt möglicherweise mit einem violetten Diagnosebildschirm fehl
    ESX/ESXi-Hosts mit Broadcom bnx2x Async-Treiber Version 1.61.15.v50.1 schlagen möglicherweise mit einem violetten Diagnosebildschirm fehl, wenn der bnx2x Async-Treiber die maximale Segmentgröße (MSS) für den TCP-Segmentierungs-Offload (TSO) in VMkernel auf null festlegt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Physische Netzwerkkarten, die auf "Automatisch aushandeln" festgelegt sind, können unter Verwendung von Hostprofilen nicht auf "Fest" festgelegt werden, wenn Hostprofil und Netzwerkkarte dieselben Geschwindigkeits- und Duplex-Einstellungen aufweisen
    Bei der Anwendung eines Hostprofils werden die Geschwindigkeits- und Duplex-Einstellungen einer physischen Netzwerkkarte überprüft. Wenn die Geschwindigkeits- und Duplex-Einstellungen einer physischen Netzwerkkarte eines ESXi-Hosts mit den Werten im Hostprofil übereinstimmen, zeigt der ESXi-Host selbst dann Konformität an, wenn die physische Netzwerkkarte auf "Automatisch aushandeln" und das Hostprofil auf "Fest" festgelegt ist. Zudem können auf "Automatisch aushandeln" festgelegte physische Netzwerkkarten unter Verwendung von Hostprofilen nicht auf "Fest" geändert werden, wenn die Geschwindigkeits- und Duplex-Einstellungen des ESXi-Hosts und des Hostprofils identisch sind.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Ein ESXi 5.1-Host mit aktivierter Signalprüfung schlägt möglicherweise beim Neustart fehl und zeigt einen violetten Diagnosebildschirm an
    Wenn Sie einen ESXi 5.1-Host mit aktivierter Signalprüfung neu starten, schlägt der Host möglicherweise mit einem violetten Diagnosebildschirm fehl und zeigt Fehlermeldungen ähnlich der folgenden an:
    2012-09-12T13:32:10.964Z cpu6:4578)@BlueScreen: #PF Exception 14 in world 4578:helper34-0 IP 0x41803c0dbf43 addr 0x200 2012-09-12T13:32:10.964Z cpu6:4578)Code start: 0x41803ba00000 VMK uptime: 0:00:10:57.178 2012-09-12T13:32:10.965Z cpu6:4578)0x41220789ba70:[0x41803c0dbf43]NCPGetUplinkBeaconState@ # +0x1e stack: 0x410003000000 2012-09-12T13:32:10.966Z cpu6:4578)0x41220789bf40:[0x41803c0dcc5d]NCPHealthChkTicketCB@ # +0x258 stack: 0x0 2012-09-12T13:32:10.967Z cpu6:4578)0x41220789bf60:[0x41803c0a991d]NHCTicketEventCB@com.vmware.net.healthchk#1.0.0.0+0x3c stack: 0x0 2012-09-12T13:32:10.968Z cpu6:4578)0x41220789bff0:[0x41803ba483df]helpFunc@vmkernel#nover+0x52e stack: 0x0

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Intel I350 Gigabit Netzwerkadapter generiert falsche MAC-Adresse für einen ESXi-Host
    Auf einem ESXi-Host werden dem eingebetteten Intel I350 Gigabit Netzwerkadapter falsche oder doppelte MAC-Adressen zugewiesen. Dies führt zu hohen Paketverlusten.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • iSCSI-LUNs gehen nach Beendigung des APD-Status nicht wieder online
    Nach Beendigung des Zustands "Keine Pfade verfügbar" (APD-Status) gehen iSCSI-LUNs erst nach einem Neustart des Hosts wieder online. Dieses Problem tritt bei für iSCI konfigurierten Broadcom iSCSI-Adaptern mit aktiviertem Offloading auf.
     
    Dieses Problem wurde in der vorliegenden Version behoben.

Sicherheit

  • Aktualisierung des libxslt-Pakets behebt mehrere Sicherheitsprobleme
    Das libxslt-Userworld-Paket von ESXi wurde aktualisiert, um mehrere Sicherheitsprobleme zu beheben. Von dem Projekt "Common Vulnerabilities and Exposures" (cve.mitre.org) wurden diesen Problemen die Namen CVE-2011-1202, CVE-2011-3970, CVE-2012-2825, CVE-2012-2870 und CVE-2012-2871 zugewiesen.
  • Update der libxml2-Bibliothek behebt mehrere Sicherheitsprobleme
    Die ESXi-userworld-libxml2-Bibliothek wurde aktualisiert, um mehrere Sicherheitsprobleme zu beheben. Im Projekt "Common Vulnerabilities and Exposures" (cve.mitre.org) wurden diesen Problemen die Bezeichnungen CVE-2011-3102, CVE-2012-2807 und CVE-2012-5134 zugewiesen.

Serverkonfiguration

  • Der ESXi-Host reagiert nicht mehr und ein violetter Diagnosebildschirm wird angezeigt
    Aufgrund einer nicht ordnungsgemäßen Sperrfreigabe des IPMI-Treibers reagiert der ESXi-Host nicht mehr und ein violetter Diagnosebildschirm wird angezeigt. Auf dem Bildschirm wird eine Fehlermeldung der folgenden Art zusammen mit ipmi_request_settime- und i_ipmi_request-Rückverfolgungsdaten angezeigt:

    Failed to ack TLB invalidate

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESXi-Host antwortet möglicherweise nicht mehr, wenn er zwei ausgelöste Interrupts gleichzeitig bedient
    Wenn Level-Triggered-Interrupts für dasselbe Gerät oder denselben Treiber in zwei unterschiedlichen CPUs eines ESXi-Hosts auftreten und gleichzeitig ausgeführt werden, antwortet der ESXi-Host nicht mehr und zeigt einen violetten Diagnosebildschirm mit einer Meldung ähnlich einer der folgenden an:
    • mpt2sas_base_get_smid_scsiio
    • Failed at vmkdrivers/src_9/vmklinux_9/vmware/linux_scsi.c:2221 -- NOT REACHED

    Dieses Problem wurde in der vorliegenden Version dadurch behoben, dass der Interrupt-Behandlungsmechanismus für Level-Triggered-Interrupts verbessert wurde.

  • vCenter Server und ESXi-Host zeigen die Kartennamen der Dell H310-Serie nicht ordnungsgemäß an
    Die PCI-IDs der Dell H310-Serie wurden nicht zum megaraid_sas-Treiber hinzugefügt. Daraufhin zeigen vCenter Server und ESXi-Host die Kartennamen der Dell H310-Serie nicht ordnungsgemäß an.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Versuche, ein Hostprofil anzuwenden, schlagen möglicherweise mit einer Fehlermeldung fehl, die angibt, dass das CIM Indication-Abonnement nicht gelöscht werden kann
    CIM Indication-Abonnements werden im Repository gespeichert und eine Kopie befindet sich im Arbeitsspeicher. Wenn Sie versuchen, ein Hostprofil zu übernehmen, wenn das Repository und der Arbeitsspeicher nicht synchron sind, schlägt der Löschvorgang möglicherweise fehl. Eine Fehlermeldung ähnlich der folgenden wird in die Protokolldatei var/log/syslog.loggeschrieben:
    Fehler beim Löschen des Indication-Abonnements. Das angeforderte Objekt wurde nicht gefunden

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Eine virtuelle 32-Bit-Red Hat Enterprise Linux 4.8-Maschine weist möglicherweise unter ESXi 5.x eine höhere durchschnittliche Last als unter ESX 4.0 auf
  • Eine virtuelle Maschine, auf der ein 32-Bit-Red Hat Enterprise Linux 4.8-Gastbetriebssystem mit einer Arbeitslast ausgeführt wird, die sich dadurch auszeichnet, dass die Maschine meistens im Leerlauf betrieben wird, der zeitweise durch gleichzeitiges Aufwecken von mehreren Aufgaben unterbrochen wird, weist möglicherweise unter ESXi 5.x eine höhere durchschnittliche Last als unter ESX 4.0 auf.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • Auf der Registerkarte "Hardwarestatus" wird möglicherweise der Hoststatus nicht mehr angezeigt
    Auf einem ESXi 5.1-Host schlägt der Small-Footprint-CIM-Broker-Daemon ( sfcbd) häufig fehl und zeigt CIM-Fehler an. Daraufhin wird möglicherweise auf der Registerkarte Hardwarestatus der Hoststatus nicht mehr angezeigt und in der Datei syslog.log ist möglicherweise eine Fehlermeldung ähnlich der folgenden zu finden:
    Zeitüberschreitung (oder anderer Socketfehler) beim Senden der Anforderung an den Anbieter.

    Dieses Problem wurde in der vorliegenden Version behoben.

Speicher

  • Der ESXi-Host schlägt möglicherweise mit einem violetten Diagnosebildschirm fehl, wenn während der Zuteilung die Richtung der SCSI-Befehlsdaten nicht initialisiert ist
    Wenn das Modul eines Drittanbieters eine benutzerdefinierte SCSI-Befehlsstruktur erstellt, ohne die VMKernel-APIs zu verwenden, und diese SCSI-Befehlsstruktur aufruft, schlägt der ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm fehl.
    Dieses Problem tritt auf, wenn der SCSI-Befehl eine DMA-Übertragung erfordert und die Datenrichtung in der SCSI-Befehlsstruktur nicht initialisiert ist.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • ScsiDeviceIO-bezogene Fehlermeldung wird während der Geräteerkennung möglicherweise protokolliert
    Wenn während der Geräteerkennung ein optionaler SCSI-Befehl mit einer bestimmten Bedingung fehlschlägt, werden möglicherweise die fehlgeschlagenen SCSI-Befehle vom ESXi 5.1-Host protokolliert. Möglicherweise wird eine Fehlermeldung ähnlich der folgenden in die Datei vmkernel.loggeschrieben:
    2011-10-03T15:16:21.785Z cpu3:2051)ScsiDeviceIO: 2316: Cmd(0x412400754280) 0x12, CmdSN 0x60b to dev "naa.600508e000000000f795beaae1d28903" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x24 0x0.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Versuche zum Aktivieren der Flusssteuerung auf dem Intel 82599EB Gigabit Ethernet Controller schlagen fehl
    Wenn Sie versuchen, die Flusssteuerung auf dem Intel 82599EB Gigabit Ethernet Controller zu aktivieren, legt der ixgbe-Treiber fälschlicherweise den Flusssteuerungsmodus auf die prioritätsbasierte Flusssteuerung fest, in der die Flusssteuerung immer deaktiviert ist. Als Folge davon wird die Fehlermeldung Pausenparameter des Geräts können nicht festgelegt werden: Ungültiges Argumentangezeigt, wenn Sie versuchen, die Flusssteuerung zu aktivieren.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Versuche, eine Diagnosepartition auf einer leeren Festplatte oder GPT-partitionierten Festplatte zu erstellen, schlagen möglicherweise fehl
    Versuche, mithilfe des vSphere-Clients eine Diagnosepartition zu erstellen, schlagen möglicherweise fehl, wenn Sie versuchen, die Diagnosepartition auf einer leeren Festplatte (einer Festplatte ohne Partitionstabelle) oder auf einer GPT-partitionierten Festplatte mit freiem Speicherplatz am Ende zu erstellen.
    Wenn Sie versuchen, eine Diagnosepartition auf einer leeren Festplatte zu erstellen, wird eine Fehlermeldung der folgenden Art angezeigt:
    Das Partitionsformat "Unbekannt" wird nicht unterstützt
    Eine Fehlermeldung ähnlich der folgenden wird angezeigt, wenn Sie versuchen, eine Diagnosepartition auf einer GPT-partitionierten Festplatte mit freiem Speicherplatz am Ende zu erstellen:
    Während der Hostkonfiguration ist ein Fehler aufgetreten.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Löschen von Dateien im VMFS-Verzeichnis nicht möglich, nachdem eine oder mehrere Dateien in dieses verschoben wurden
    Nachdem eine oder mehrere Dateien in das Verzeichnis verschoben wurden, schlägt ein Versuch, das Verzeichnis oder Dateien des Verzeichnisses zu löschen, möglicherweise fehl. In solch einem Fall enthält die Datei vmkernel.logEinträge ähnlich dem folgenden:
    2012-06-25T21:03:29.940Z cpu4:373534)WARNING: Fil3: 13291: newLength 85120 but zla 2
    2012-06-25T21:03:29.940Z cpu4:373534)Fil3: 7752: Corrupt file length 85120, on FD <281, 106>, not truncating


    Dieses Problem wurde in der vorliegenden Version behoben.

  • Ein ESXi-Host zeigt möglicherweise einen violetten Diagnosebildschirm an, wenn Sie ioctl IOCTLCMD_VMFS_QUERY_RAW_DISK von disklib aus ausführen
    Der ESXi-Host reagiert nicht mehr und zeigt einen violetten Diagnosebildschirm an, wenn eine Pseudo-LUN der Klasse SCSI_CLASS_RAID(0xc)mit der gleichen naa.id, die von einer physischen Raw-Gerätezuordnung (pRDM) in einer virtuellen Maschine verwendet wird, als die neue LUN präsentiert und eine erneute Prüfung durchgeführt wird.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die virtuelle Maschine, die READ10/WRITE10-Warnmeldungen ausgibt, kann nicht identifiziert werden
    Im Falle von READ10/WRITE10-Warnungen ist es schwierig, die virtuelle Maschine zu ermitteln, die diese Befehle ausgibt, da in den Protokolldateien nur die VSCSCI-Handle-ID festgehalten wird. Die World-ID, die Teil der VMkernel-Protokolleinträge ist, entspricht nicht immer der virtuellen Maschine, die den Befehl ausgegeben hat.

    Das Problem wird in der vorliegenden Version dadurch behoben, dass die READ10/WRITE10-Warnungen so erweitert wurden, dass sie auch den Namen der virtuellen Maschine enthalten.
  • Wenn Sie einen VMFS3-Datenspeicher mit einem nicht standardmäßigen Startsektor oder auf einer LUN mit sehr kleinen Partitionen erstellen, schlagen QueryVmfsDatastoreExpandOptions und QueryVmfsDatastoreExtendOptions möglicherweise fehl
    Der ESXi-Host (hostd) behandelt die DatastoreSystem-verwalteten Objektmethodenaufrufe von QueryVmfsDatastoreExpandOptionsund QueryVmfsDatastoreExtendOptionsnicht ordnungsgemäß. Dieses Problem tritt bei den folgenden Datenspeichern auf:
    • VMFS3-Datenspeicher, die mit einem Startsektor größer als 1 MB und kleiner als der durch (Anzahl der Köpfe * Anzahl der Sektoren * Sektorgröße) bestimmte Wert erstellt wurden.
    • VMFS3-Datenspeicher, die auf einer LUN mit einer Partition erstellt wurden, deren Größe kleiner als der durch (Anzahl der Köpfe * Anzahl der Sektoren * Sektorgröße) bestimmte Wert ist.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • ESXi-Host schlägt aufgrund eines Synchronisierungsproblems zwischen ausstehenden COW-Async-E/A-Vorgängen und Schließung der Sparse-Redo-Protokolldatei möglicherweise fehl
    ESXi-Host schlägt möglicherweise mit einem violetten Diagnosebildschirm fehl und meldet einen PF-Ausnahmefehler mit einer Rückverfolgung ähnlich der folgenden:

    @BlueScreen: #PF Exception 14 in world 137633099:vmm0:TSTSPSR IP 0x41801e20b01f addr 0x0
    cpu4:137633099)Code start: 0x41801dc00000 VMK uptime: 464:10:04:03.850
    cpu4:137633099)0x417f86a5f6b8:[0x41801e20b01f]COWCopyWriteDone@esx:nover+0x122 stack: 0x41027f520dc0
    cpu4:137633099)0x417f86a5f6e8:[0x41801dc0838a]AsyncPopCallbackFrameInt@vmkernel:nover+0x81 stack: 0x0
    cpu4:137633099)0x417f86a5f968:[0x41801e20b2c2]COWAsyncDataDone@esx:nover+0x125 stack: 0x41027f5aebd8
    cpu4:137633099)0x417f86a5f998:[0x41801dc0838a]AsyncPopCallbackFrameInt@vmkernel:nover+0x81 stack: 0x41027f556ec0
    cpu4:137633099)0x417f86a5f9c8:[0x41801dc085e9]AsyncCompleteOneIO@vmkernel:nover+0xac stack: 0x41027fd9c540
    cpu4:137633099)0x417f86a5f9f8:[0x41801dc0838a]AsyncPopCallbackFrameInt@vmkernel:nover+0x81 stack: 0x41027f5ae440
    cpu4:137633099)0x417f86a5fa18:[0x41801de240b9]FS_IOAccessDone@vmkernel:nover+0x80 stack: 0x41027f556858
    cpu4:137633099)0x417f86a5fa48:[0x41801dc0838a]AsyncPopCallbackFrameInt@vmkernel:nover+0x81 stack: 0x41027f59a2c0
    cpu4:137633099)0x417f86a5fa78:[0x41801dc085e9]AsyncCompleteOneIO@vmkernel:nover+0xac stack: 0x41027f480040
    cpu4:137633099)0x417f86a5faa8:[0x41801dc0838a]AsyncPopCallbackFrameInt@vmkernel:nover+0x81 stack: 0x417f86a5fad8
    cpu4:137633099)0x417f86a5fad8:[0x41801de3fd1d]FDSAsyncTokenIODone@vmkernel:nover+0xdc stack: 0x0
    cpu4:137633099)0x417f86a5fbd8:[0x41801de4faa9]SCSICompleteDeviceCommand@vmkernel:nover+0xdf0 stack: 0x41027f480040

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der Zugriff auf beschädigte Metadaten eines VMFS3-Volumes führt möglicherweise zum Ausfall des ESXi-Hosts
    Wenn die Dateimetadaten eines VMFS3-Volumes beschädigt sind, schlägt der ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm fehl, wenn versucht wird, auf eine solche Datei zuzugreifen. Eine Beschädigung der VMFS-Dateien ist äußerst selten, kann aber durch externe Speicherprobleme verursacht werden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Durch Hinzufügen eines neuen ESXi-Hosts zu einem High Availability-Cluster und das anschließende Neukonfigurieren des Clusters kann ein anderer Host im Cluster mit einem violetten Diagnosebildschirm fehlschlagen
    Wenn ein neuer ESXi-Host zu einem HA-Cluster hinzugefügt und der HA-Cluster anschließend neu konfiguriert wird, kann jeder andere Host im HA-Cluster mit einem violetten Diagnosebildschirm und einer Fehlermeldung ähnlich der folgenden fehlschlagen:

    0x4122264c7ce8:[0x41802a07e023]NFSLock_GetLease@<None>#<None>+0x2e stack: 0x410023ce8570.

    Durch den Neustart des fehlgeschlagenen ESXi-Hosts schlägt der Host möglicherweise ähnlich fehl.
    Dieses Problem tritt dann auf, wenn alle folgenden Szenarios in der HA-Umgebung zutreffen:
    • Der Wert der NFS-Option "LockRenewMaxFailureNumber", welche die Anzahl der fehlgeschlagenen Sperraktualisierungen festlegt, die eintreten müssen, bevor die Sperre als veraltet markiert wird, wird von 1 in 0 geändert.
    • Der Wert der NFS-Option "LockUpdateTimeout", die festlegt, wie lange es dauert, bis die Anforderung auf Aktualisierung der Sperre abgebrochen wird, wird von 1 in 0 geändert.
    • Ein Host versucht, die Sperre auf dem NFS-Volume zu beziehen.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Der ESXi-Host schlägt möglicherweise aufgrund von Wettlaufsituationen in VMkernel, die zu Null-Pointer-Ausnahmen führen, mit einem violetten Diagnosebildschirm fehl
    Null-Pointer-Ausnahmen führen aufgrund von Wettlaufsituationen in VMkernel zum Ausfall des ESXi-Hosts mit einem violetten Diagnosebildschirm.
    Diese Wettlaufsituationen können beim Ausführen gewisser Dateisystemfunktionen auf dem Gerätedateisystem (DevFS) im ESXi-Host auftreten.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Ein Upgrade von ESX/ESXi 4.x oder niedriger auf ESXi 5.0 oder höher schlägt möglicherweise fehl, wenn die Standardeinstellung der Konfigurationsoption "MaxHeapSizeMB" für VMFS geändert wurde
    Ein ESX-Host reagiert möglicherweise nicht mehr nach einem Upgrade von ESX 4.x oder niedriger auf ESX 5.0 oder höher. Die folgende Fehlermeldung wird angezeigt:

    hostCtlException: Modul "/usr/lib/vmware/vmkmod/vmfs3" kann nicht geladen werden: Fehler

    Dieses Problem tritt möglicherweise auf, wenn die Konfigurationsoption MaxHeapSizeMBfür VMFS manuell vom Benutzer auf einem ESX-Host vor dem Upgrade festgelegt wurde.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Wenn der Stilllegungs-Snapshot-Vorgang fehlschlägt, werden die Redo-Protokolle nicht konsolidiert
    Beim Versuch, einen Stilllegungs-Snapshot einer virtuellen Maschine zu erstellen, werden die Redo-Protokolle, die als Teil des Snapshots erstellt wurden, nicht konsolidiert, wenn der Snapshot-Vorgang zum Ende hin fehlschlägt. Die Redo-Protokolle belegen möglicherweise beträchtlichen Datenspeicher.

    Dieses Problem wurde in der vorliegenden Version behoben. Wenn der Stilllegungs-Snapshot-Vorgang fehlschlägt, werden die Redo-Protokolldateien konsolidiert.

  • Auf virtuellen Maschinen, die sich auf NFS-Datenspeichern befinden, ist der Zugriff im ESXi 5.1-Host nicht möglich, nachdem vSphere Storage Appliance (VSA) 5.1 den Wartungsmodus verlassen hat
    Der hostd-Agent meldet vCenter und dem ESXi-Host einen falschen Status von virtuellen Maschinen, sobald Sie den NFS-Speicher trennen, wenn er den Wert Misc.APDTimeoutüberschreitet. Dieses Problem tritt bei ausgeschalteten virtuellen Maschinen auf.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Die Verfolgungsfunktionalität für geänderte Blöcke liefert als Ergebnis möglicherweise eine gesamte Thin-bereitgestellte Festplatte
    Bei sehr großen Thin-bereitgestellten virtuellen Festplatten kann es passieren, dass jeder Aufruf von QueryChangedDiskAreasdie gesamte Festplatte zurückgibt, statt nur die genutzten Bereiche, wenn die Anzahl der erforderlichen IOCTLs das hartcodierte Limit für IOCTLs überschreitet. Dies führt zu extrem großen Volumina von Sicherungsdaten. Das beschriebene Verhalten lässt sich insbesondere bei den Linux-Dateisystemen ext2 und ext3 beobachten.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • ESXi-Hosts schlagen möglicherweise mit einem violetten Diagnosebildschirm im ata-Treiber fehl
    Eine Wettlaufsituation im ata-Treiber kann zu einem Fehlschlagen des Treibers und der Anzeige eines violetten Diagnosebildschirms mit einem Stack-Trace der folgenden Art führen:
    BUG: failure at vmkdrivers/src_9/drivers/ata/libata-core.c:5833/ata_hsm_move()! (inside vmklinux)
    Panic_vPanic@vmkernel#nover+0x13 stack: 0x3000000010, 0x412209a87e00
    vmk_PanicWithModuleID@vmkernel#nover+0x9d stack: 0x412209a87e20,0x4
    ata_hsm_move@com.vmware.libata#9.2.0.0+0xa0 stack: 0x0, 0x410017c03e
    ata_pio_task@com.vmware.libata#9.2.0.0+0xa5 stack: 0x0, 0x0, 0x53fec
    vmklnx_workqueue_callout@com.vmware.driverAPI#9.2+0x11a stack: 0x0,
    helpFunc@vmkernel#nover+0x568 stack: 0x0, 0x0, 0x0, 0x0, 0x0


    Dieses Problem wurde in der vorliegenden Version behoben.

Unterstützte Hardware

  • Die Leistung eines OpenIPMI-Treibers mit einer Schnittstelle im Tastatur-Controllerstil im Interrupt-getriebenen Modus ist niedrig
    Der OpenIPMI-Treiber mit einer Schnittstelle im Tastatur-Controllerstil (KCS) funktioniert langsamer im Interrupt-getriebenen Modus. Installieren Sie den Patch http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=b88e769368a88cf28e53db158b84eda096144bce des quelloffenen IPMI-Treibers, um die Transaktionszeitverzögerung beim Betreiben des Treibers in einem Interrupt-Modus zu reduzieren.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESXi-Host schlägt möglicherweise mit einem violetten Diagnosebildschirm fehl, wenn der Befehl "vmware-vimdump" von der DCUI aus ausgeführt wird
    Wenn Sie den Befehl vmware-vimdumpvon der DCUI (Direct Console User Interface, Benutzerschnittstelle der Direktkonsole) aus ausführen, schlägt der ESXi-Host möglicherweise mit einem violetten Diagnosebildschirm fehl. Dies kann auch zu fehlenden Taktsignalen führen. Dieses Problem tritt nicht auf, wenn zur Ausführung des Befehls eine Verbindung über eine SSH-Konsole verwendet wird.

    Dieses Problem wurde in der vorliegenden Version behoben.

Upgrade und Installation

  • An virtuelle Solaris-Maschinen angehängte RDMs werden möglicherweise überschrieben, wenn ESXi-Hosts mit Update Manager aktualisiert werden
    Beim Upgrade auf ESXi 5.x mit Update Manager führt ein Fehler beim Ermitteln des Typs der Festplattenpartition dazu, dass die an virtuelle Solaris-Maschinen angehängten RDMs überschrieben werden. Dies kann möglicherweise zu einem Datenverlust bei den RDMs führen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Eine Neuinstallation von ESXi 5.1 entfernt nicht die Datenspeicherbezeichnung des lokalen VMFS einer früheren Installation
    Eine Neuinstallation von ESXi 5.1 auf einem bestehenden lokalen VMFS-Datenträger behält die Datenspeicherbezeichnung bei, selbst wenn der Benutzer die Option zum Überschreiben des Datenspeichers wählt, um den VMFS-Datenträger zu überschreiben.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die skriptbasierte ESXi 5.x-Installation warnt fälschlicherweise davor, dass USB- oder SD-Medien VMFS nicht unterstützen, obwohl in der Kickstart-Datei der Parameter --novmfsondisk verwendet wird
    Wenn Sie die skriptbasierte Installation zum Installieren von ESXi 5.1 auf einem Datenträger verwenden, der als USB- oder SD-Medium erkannt wird, zeigt das Installationsprogramm möglicherweise die folgende Warnmeldung an:

    Die im Installationsprogramm angegebene Festplatte (<Festplatten-ID>) unterstützt VMFS nicht.

    Diese Meldung wird selbst dann angezeigt, wenn Sie den Parameter --novmfsondiskfür den Befehl "install" in der Kickstart-Datei angegeben haben.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Bei Verwendung von AutoDeploy tritt beim iPXE-Vorgang möglicherweise eine Zeitüberschreitung ein
    Wenn Sie AutoDeploy zum Starten von ESXi 5.1-Hosts verwenden, tritt beim iPXE-Vorgang möglicherweise eine Zeitüberschreitung ein, während versucht wird, eine IP-Adresse von DHCP-Servern abzurufen, und der AutoDeploy-Startvorgang wird abrupt beendet.

    Dieses Problem wird in der vorliegenden Version behoben, indem das Limit für die gesamte Zeitüberschreitung auf 60 Sekunden angehoben wird.
  • Versuche, ein Upgrade des ESXi-Hosts in einem HA-Cluster mithilfe von vCenter Update Manager durchzuführen, können fehlschlagen
    Das Durchführen eines Upgrades des ESXi-Hosts in einem HA-Cluster mit vCenter Update Manager (VUM) schlägt möglicherweise mit einer Fehlermeldung ähnlich der folgenden fehl:
    Der Host gibt den esxupdate-Fehlercode 7 zurück
    Dieses Problem tritt auf, wenn mehrere Bereitstellungsvorgänge mit unterschiedlichen Baselines in Update Manager durchgeführt werden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Versuche, ein Upgrade von ESX 4.1 mit Erweiterungen zum lokalen Dateispeicher auf ESXi 5.1 durchzuführen, schlagen fehl
    Upgrades von ESX 4.1 mit Erweiterungen zum lokalen Datenspeicher auf ESXi 5.1 werden nicht unterstützt. Jedoch ermöglicht der aktuelle Upgrade-Vorgang dieses Upgrade-Verhalten und überträgt die Erweiterungen auf den lokalen Datenspeicher, ohne eine Fehler- oder Warnmeldung auszugeben.

    Dieses Problem wurde in der vorliegenden Version behoben, indem eine Prüfung zum Vorprüfungs-Skript hinzugefügt wurde, um eine solche Situation zu erkennen und ggf. eine Meldung anzuzeigen, die den Benutzer auffordert, das Upgrade zu beenden oder zu migrieren.
  • Microsoft Windows Deployment Services (WDS) starten virtuelle Maschinen per PXE-Startvorgang möglicherweise nicht, wenn diese den VMXNET3-Netzwerkadapter verwenden
    Versuche, virtuelle Maschinen, die den VMXNET3-Netzwerkadapter verwenden, per PXE-Startvorgang mithilfe der Microsoft Windows Deployment Services (WDS) zu starten, schlagen möglicherweise mit Fehlermeldungen ähnlich der folgenden fehl:

    Windows konnte nicht gestartet werden. Dies kann auf eine kürzlich durchgeführte Hardware- oder Softwareänderung zurückzuführen sein. So beheben Sie das Problem:
    1. Legen Sie die Windows-CD/DVD ein und starten Sie den Computer neu.
    2. Wählen Sie die Spracheinstellungen aus, und klicken Sie dann auf "Weiter".
    3. Klicken Sie auf "Computer reparieren".
    Wenn Sie den Datenträger nicht besitzen, wenden Sie sich an den Systemadministrator oder den Computerhersteller.

    Status: 0xc0000001

    Info: Fehler bei Startauswahl. Zugriff auf ein erforderliches Gerät nicht möglich
    .

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Eine skriptbasierte ESXi-Installation oder ein Upgrade von einem verbundenen USB-Laufwerk schlägt möglicherweise fehl, wenn der Dateisystemtyp auf einem der USB-Laufwerke weder fat16 noch fat32 ist
    Wenn mehrere USB-Flash-Laufwerke mit einem ESXi-Host verbunden sind, schlägt eine skriptbasierte ESXi-Installation oder ein Upgrade mit der Startoption ks=usbmöglicherweise mit einem Ausnahmefehler fehl, wenn der Dateisystemtyp auf einem der USB-Laufwerke mit MS-DOS-Partitionierung weder fat16noch fat32ist.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Nach einem ESX-Upgrade behält der ESX-Host die ältere Version der Datei /etc/vmware/service/service.xml bei
    Wenn Sie die Datei etc/vmware/service/service.xml, bei der ein "Sticky-Bit" gesetzt ist, ändern und anschließend ein ESX/ESXi-Upgrade von Version 4.0 auf 5.1 durchführen, verursacht die alte service.xml-Datei Kompatibilitätsprobleme. Dies geschieht, weil die alte service.xml-Datei selbst nach dem Upgrade vom ESX-Host beibehalten wird.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die skriptbasierte Installation von ESXi 5.1 mit IPv6-Details schlägt fehl
    Wenn Sie eine skriptbasierte Installation von ESXi 5.1 mit den im ks.cfgenthaltenen IPv6-Details durchführen, schlägt die Installation beim Validieren der IPv6-Details fehl.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der Wert von Syslog.global.logDir und der Wert von Syslog.global.logHost werden nach dem Upgrade eines ESXi-Hosts nicht aufbewahrt
    Wenn Sie ein Upgrade eines ESXi-Hosts von Version 4.x auf Version 5.x durchführen, werden der Wert von Syslog.global.logDirund der Wert von Syslog.global.logHostmöglicherweise nicht aufbewahrt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die VIBs-Tests von Drittanbietern sollten während der Durchführung eines Upgrades von ESXi 5.0-Hosts auf Version 5.1 nicht ausgeführt werden
    Wenn Sie ein Upgrade von ESXi 5.0 auf ESXi 5.1 mit Drittanbieter-VIBs von Power Path durchführen, sollten das ESXi-Installationsprogramm und vSphere Update Manager die Warnmeldungen der Drittanbieter-VIBs nicht anzeigen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • resxtop schlägt bei einem Upgrade von vSphere 5.0 auf vSphere 5.1 fehl
    In vSphere 5.1 sind SSL-Zertifizierungsprüfungen aktiviert. Dies könnte dazu führen, dass resxtop beim Herstellen einer Verbindung zu Hosts fehlschlägt. Eine Ausnahmemeldung ähnlich der folgenden wird angezeigt:
    HTTPS_CA_FILE oder HTTPS_CA_DIR nicht festgelegt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Versuche, ein Upgrade von ESX/ESXi 4.0 Update 4 auf ESXi Server 5.1 durchzuführen, können zur Anzeige einer Fehlermeldung führen, wenn das Kennwort für das vpxuser-Konto nicht unter Verwendung von MD5-Verschlüsselung festgelegt wurde
    Wenn Sie ein Upgrade von ESX/ESXi 4.0 Update 4 auf ESXi Server 5.1 unter Verwendung von VMware Update Manager (VUM) durchführen, wird möglicherweise eine Fehlermeldung der folgenden Art angezeigt:

    Das Kennwort für den Benutzer vpxuser wurde nicht unter Verwendung der MD5-Verschlüsselung festgelegt. Nur die ersten 8 Zeichen werden berücksichtigt. Bitte setzen Sie nach dem Neustart das Kennwort zurück.

    Dieses Problem tritt auf, wenn das Kennwort für das vpxuser-Konto nicht unter Verwendung der MD5-Verschlüsselung festgelegt wurde.

    Dieses Problem wurde in der vorliegenden Version behoben.

vCenter Server, vSphere-Client und vSphere Web Client

  • VMRC und der vSphere-Client reagieren möglicherweise nicht, wenn sie mit einer ausgefallenen virtuellen Maschine verbunden sind
    Auf einem ESXi 5.1-Host reagieren VMRC (VMware Remote Console) und der vSphere-Client möglicherweise nicht mehr, wenn sie mit einer ausgefallenen virtuellen Maschine oder einer virtuellen Maschine, bei der VMware Tools fehlgeschlagen ist, verbunden sind.

    Dieses Problem wurde in der vorliegenden Version behoben.

Verwaltung von virtuellen Maschinen

  • Bereitstellung von virtuellen Maschinen mithilfe von Vorlagendateien nicht möglich
    Möglicherweise sind Sie nicht in der Lage, virtuelle Maschinen unter Verwendung der Vorlagendateien bereitzustellen. Dieses Problem tritt auf, wenn ein Datenspeicher, der die Vorlagendateien vorhält, neu signiert wird und die .vmtx-Dateien nicht aktualisiert werden.

    Dieses Problem wird in der vorliegenden Version behoben, indem die .vmtx-Dateien der Vorlage mit dem zuletzt neu signierten Datenspeicherpfad aktualisiert werden.

  • Der Einschaltvorgang einer virtuellen Maschine schlägt möglicherweise mit Warnmeldungen fehl, die besagen, dass für den VMFS-Heap nicht genügend Arbeitsspeicher vorhanden ist
    Wenn eine virtuelle Maschine über mehr als 18 virtuelle Festplatten verfügt und jede von ihnen eine Kapazität von mehr als 256 GB aufweist, kann der ESXi-Host möglicherweise eine solche virtuelle Maschine nicht einschalten. Eine Warnmeldung ähnlich der folgenden wird u. U. in der Datei VMkernel.log protokolliert:
    WARNING: Heap: 2525: Heap vmfs3 already at its maximum size. Cannot expand. WARNING: Heap: 2900: Heap_Align(vmfs3, 2099200/2099200 bytes, 8 align) failed. caller: 0x4180368c0b90

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Stilllegungs-Snapshot kann nicht erstellt werden, nachdem eine unabhängige Festplatte einer virtuellen Maschine gelöscht wurde
    Wenn eine unabhängige Festplatte einer virtuellen Maschine gelöscht wurde, schlagen Versuche, einen Stilllegungs-Snapshot einer virtuellen Maschine zu erstellen, fehl, da die Daten bzgl. des Festplattenmodus für einen bestimmten SCSI-Knoten möglicherweise veraltet sind.
    Es wird möglicherweise eine Fehlermeldung ähnlich der folgenden angezeigt:
    Status: Beim Stilllegen der virtuellen Maschine ist ein Fehler aufgetreten. Weitere Informationen finden Sie im Ereignisprotokoll der virtuellen Maschine.

    Die Protokolldateien enthalten möglicherweise Einträge ähnlich den folgenden:
    HotAdd: Adding scsi-hardDisk with mode 'independent-persistent' to scsi0:1

    ToolsBackup: changing quiesce state: STARTED -> DONE SnapshotVMXTakeSnapshotComplete done with snapshot 'back': 0
    SnapshotVMXTakeSnapshotComplete: Snapshot 0 failed: Das Stilllegen der virtuellen Maschine ist fehlgeschlagen. (40).

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Uhrzeitsynchronisierung mit dem ESXi-Server kann zu einem unerwarteten Neustart des Gastbetriebssystems führen, wenn ein ESXi-Host als NTP-Server konfiguriert ist
    Wenn ein ESXi-Host als NTP-Server konfiguriert ist, wird während der Uhrzeitsynchronisierung mit dem ESXi-Host das Gastbetriebssystem möglicherweise unerwartet neu gestartet. Dieses Problem tritt auf, wenn die Empfindlichkeitsstufe für die Überwachung virtueller Maschinen auf einem High Availability-Cluster auf Hoch und die Option das.iostatsIntervalauf Falsch eingestellt ist.

    Dieses Problem kann durch Festlegung der Option das.iostatsIntervalauf Wahr behoben werden.
  • Der ESXi-Host schlägt möglicherweise bei der Durchführung gewisser VM-Vorgänge fehl
    Wenn Sie gewisse VM-Vorgänge durchführen, kann ein Problem bezüglich der Metadatenbeschädigung von LUNs manchmal zur Folge haben, dass ein ESXi-Host mit einem violetten Diagnosebildschirm fehlschlägt. Dabei werden Fehlermeldungen ähnlich den folgenden angezeigt:
    @BlueScreen: #DE Exception 0 in world 4277:helper23-15 @ 0x41801edccb6e 3:21:13:31.624 cpu7:4277)Code start: 0x41801e600000 VMK uptime: 3:21:13:31.624 3:21:13:31.625 cpu7:4277)0x417f805afed0:[0x41801edccb6e]Fil3_DirIoctl@esx:nover+0x389 stack: 0x410007741f60 3:21:13:31.625 cpu7:4277)0x417f805aff10:[0x41801e820f99]FSS_Ioctl@vmkernel:nover+0x5c stack: 0x2001cf530 3:21:13:31.625 cpu7:4277)0x417f805aff90:[0x41801e6dcf03]HostFileIoctlFn@vmkernel:nover+0xe2 stack: 0x417f805afff0 3:21:13:31.625 cpu7:4277)0x417f805afff0:[0x41801e629a5a]helpFunc@vmkernel:nover+0x501 stack: 0x0 3:21:13:31.626 cpu7:4277)0x417f805afff8:[0x0] stack: 0x0

    Dieses Problem wurde in der vorliegenden Version behoben. Bei einer Metadatenbeschädigung von LUNs wird jetzt eine entsprechende Fehlermeldung angezeigt.

vMotion und Storage vMotion

  • Wenn Sie eine Live-Migration virtueller Windows Server 2008-Maschinen von ESX/ESXi 4.0 auf ESXi 5.1 vornehmen und anschließend Storage vMotion durchführen, schlagen die Stilllegungs-Snapshots fehl
    Ein Storage vMotion-Vorgang auf ESXi 5.1 legt für eine virtuelle Windows Server 2008-Maschine standardmäßig disk.enableUUIDauf "true" fest und aktiviert so die Anwendungsstilllegung. Der nachfolgende Stilllegungs-Snapshot-Vorgang schlägt so lange fehl, bis die virtuelle Maschine aus- und wieder eingeschaltet wird.

    Dieses Problem wurde in der vorliegenden Version behoben.

VMware Tools

  • VMware Tools schlägt möglicherweise beim Erstellen eines Snapshots einer stillgelegten virtuellen Maschine fehl
    Wenn sich nicht ausführbare Dateien im Ordner backupScripts.dbefinden, schlägt VMware Tools möglicherweise beim Erstellen eines Snapshots einer stillgelegten virtuellen Maschine fehl.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Nach der Installation von VMware Tools ändert sich der Name des Gastbetriebssystems von Microsoft Windows Server 2012 (64-Bit) in Microsoft Windows 8 (64-Bit)
    Wenn Sie virtuelle Microsoft Windows Server 2012 (64-Bit)-Maschinen erstellen und anschließend VMware Tools installieren, ändert sich der Name des Gastbetriebssystems von Microsoft Windows Server 2012 (64-Bit) in Microsoft Windows 8 (64-Bit).

    Dieses Problem wurde in der vorliegenden Version behoben.
  • VMware Tools-OSP-Pakete haben identische Distributions-IDs in ihren Dateinamen
    VMware Tools-OSP-Pakete haben keine eindeutigen Dateinamen für die Gastbetriebssysteme SLES11 (SUSE Linux Enterprise Server 11), RHEL5 (Red Hat Enterprise Linux 5) und RHEL6 (Red Hat Enterprise Linux 6). Infolgedessen ist es schwierig, VMware Tools-OSP-Pakete unter Verwendung des Red Hat Satellite-Servers bereitzustellen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • VMware Tools installiert eine vorherige Version der Microsoft Visual C++-Laufzeitbibliothek
    VMware Tools installiert Version 9.0.30729.4148der Microsoft Visual C++-Laufzeitbibliothek, obwohl Version 9.0.30729.6161vorhanden ist.

    Dieses Problem wurde in der vorliegenden Version behoben. VMware Tools installiert jetzt die neueste Version der Microsoft Visual C++-Laufzeitbibliothek. Wenn im System eine neuere Version der Microsoft Visual C++-Laufzeitbibliothek verfügbar ist, installiert VMware Tools die Microsoft Visual C++-Laufzeitbibliothek nicht.
  • Bei Verwendung von VMware Tools kommt es möglicherweise zu Arbeitsspeicherverlusten im Linux-Gastbetriebssystem
    Wenn für die Netzwerkschnittstelle im Linux-Gastbetriebssystem mehrere VLANs konfiguriert sind, kann die Verwendung von VMware Tools zu Arbeitsspeicherverlusten führen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Nach der Installation von VMware Tools ändern sich möglicherweise die Dateizugriffsberechtigungen für "/etc/fstab"
    Wenn VMware Tools auf einer virtuellen Maschine, z. B. einer SUSE Linux Enterprise Server 11 SP1-Maschine, installiert wird, ändert sich das Dateiberechtigungsattribut für /etc/fstabvon 644 in 600.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • VMware Tools auf einer virtuellen Linux-Maschine schlägt möglicherweise intermittierend fehl
    VMware Tools enthält eine gemeinsam genutzte Bibliotheksdatei mit dem Namen libdnet. Falls bestimmte andere Programme wie z. B. Dell OpenManage installiert sind, wird im Dateisystem eine andere gemeinsam genutzte Bibliothek mit demselben Namen erstellt. Wenn VMware Tools geladen wird, lädt es die Bibliothek libdnet.so.1der Dell OpenManage-Software anstatt libdnet.sovon VMware Tools. In der Folge werden auf der Registerkarte Übersicht des vSphere-Clients die Informationen zum Gastbetriebssystem möglicherweise nicht angezeigt, und die Informationen zur Netzwerkkarte werden möglicherweise ebenfalls nicht angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Auf einem ESX/ESXi-Host mit einer älteren Version als 5.1 wird eine Warnmeldung angezeigt, wenn nur ein Upgrade von VMware Tools auf Version 5.1 durchgeführt wird
    Wenn Sie auf einem ESX/ESXi-Host mit einer älteren Version als 5.1 und mit einer virtuellen Maschine, auf der ein Windows-Gastbetriebssystem ausgeführt wird, lediglich ein Upgrade von VMware Tools auf Version 5.1 durchführen, wird möglicherweise in der Windows-Ereignisanzeige eine Warnmeldung ähnlich der folgenden angezeigt:
    [ warning] [vmusr:vmusr] vmware::tools::UnityPBRPCServer::Start: Failed to register with the host!

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Nach Installation von View Agent wird beim Neustart eine Fehlermeldung angezeigt
    Nach Installation von View Agent zeigt VMware Tools die folgende Fehlermeldung an, wenn Sie einen Neustart durchführen:

    VMware Tools nicht behebbarer Fehler: (vthread-3)

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Versuche, VMware Tools zu installieren, schlagen in Verbindung mit de rLinux-Kernel-Version 3.7 möglicherweise fehl
    VMware Tools-Treiber sind nicht kompiliert, da unter Linux-Kernel-Version 3.7 die VMware Tools-Installationsskripts den neuen Kernel-Header-Pfad nicht identifizieren können. Dies könnte dazu führen, dass die Installation von VMware Tools fehlschlägt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Anpassung des Gastbetriebssystems schlägt möglicherweise fehl, wenn es von einigen nicht englischen Versionen der Windows-Gastbetriebssystemvorlagen bereitgestellt wird
    Die Anpassung des Gastbetriebssystems schlägt möglicherweise fehl, wenn es von einigen nicht englischen Versionen der Windows-Gastbetriebssystemvorlagen bereitgestellt wird, z. B. der französischen Version des Microsoft Windows 7-, der russischen Version des Microsoft Windows 7- und der französischen Version des Microsoft Windows Server 2008 R2-Gastbetriebssystems. Dieses Problem tritt auf, wenn der VMware Tools-Dienst vmtoolsd.exefehlschlägt.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Namen und Beschreibungen der Leistungsindikatoren für den VM-Prozessor oder VM-Arbeitsspeicher können auf Gastbetriebssystemen wie Windows Vista oder höher nicht angezeigt werden
    Wenn Sie als Benutzer mit Administratorberechtigungen ein Remoteleistungsprotokoll auf Gastbetriebssystemen wie Windows Vista oder höher konfigurieren, werden die Namen und Beschreibungen der Leistungsindikatoren für den VM-Prozessor und den VM-Arbeitsspeicher möglicherweise nicht in der Konsole des Windows-Systemmonitors ( perfmon) angezeigt.
    Dies geschieht, wenn das Windows-Gastbetriebssystem mit einem anderen Gebietsschema als en_usoder deinstalliert wird. Dieses Problem tritt in Verbindung mit VMware Tools Version 8.3.1.2 auf.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Vorgefertigte Module (Pre-built modules, PBMs) sind für die 32- und 64-Bit-Version des Ubuntu 12.10-Betriebssystems auf ESXi 5.1-Hosts nicht verfügbar
    Möglicherweise können die PBMs für das Ubuntu 12.10-Betriebssystem (sowohl 32- als auch 64-Bit-Version) auf ESXi 5.1-Hosts nicht gefunden werden.

    Dieses Problem wurde in der vorliegenden Version behoben.

  • Virtuelle Maschinen mit vShield Endpoint Thin Agent haben möglicherweise Leistungsprobleme beim Kopieren von Netzwerkdateien zu oder von einer CIFS-Freigabe
    Möglicherweise treten Leistungsprobleme mit virtuellen Maschinen auf, während Netzwerkdateien zu oder von einer CIFS (Common Internet File System)-Freigabe kopiert werden.
    Dieses Problem zeigt sich bei der Verwendung von virtuellen Maschinen, auf denen vShield Endpoint Thin Agent, eine im VMware Tools-Paket enthaltene Software, ausgeführt wird.

    Dieses Problem wurde in der vorliegenden Version behoben.

  •   Ein Windows-Gastbetriebssystem, das auf einem ESXi 5.1-Host mit vShield Endpoint und VMware Tools ausgeführt wird, zeigt möglicherweise Zugriffsverletzungsfehler an
    In einer Umgebung mit einer mit VMware Tools gebundelten vShield Endpoint-Komponente zeigt ein Windows-Gastbetriebssystem auf einem ESXi 5.1-Host möglicherweise Zugriffsverletzungsfehler während des Zugriffs auf Netzwerkdateien. Eine Fehlermeldung ähnlich der folgenden wird möglicherweise angezeigt, wenn Sie versuchen, eine Netzwerkdatei zu öffnen:

    Fehler beim Öffnen des Dokuments. Diese Datei ist bereits geöffnet oder wird von einer anderen Anwendung verwendet.


    Dieses Problem wurde in der vorliegenden Version behoben.

Bekannte Probleme

Behobene Probleme, die früher nicht dokumentiert wurden, werden mit einem Sternchen (*) markiert. Die bekannten Probleme gliedern sich in folgende Gruppen.

Upgrade- und Installationsprobleme

  • Bestandslistenobjekte sind nach dem Upgrade einer mit der Postgres-Datenbank konfigurierten vCenter Server Appliance möglicherweise nicht sichtbar*
    Wenn eine mit der Postgres-Datenbank konfigurierte vCenter Server Appliance von 5.0 Update 2 auf 5.1 Update 1 aktualisiert wird, sind Bestandslistenobjekte wie zum Beispiel Datencenter, vDS usw., die vor dem Upgrade vorhanden waren, möglicherweise nicht mehr sichtbar. Dieses Problem tritt auf, wenn Sie unter Verwendung von vSphere Web Client eine Verbindung zur vCenter Server Appliance herstellen.

    Umgehung: Starten Sie nach dem Upgrade der vCenter Server Appliance den Inventory Service neu.

  • 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

  • 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.

  • 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.

  • 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

  • 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.

  • Bei einem Upgrade eines ESXi 5.0-Hosts auf ESXi 5.1 mit ESXCLI, vMotion und Fault Tolerance (FT) gehen die Protokollierungseinstellungen verloren
    Auf einem ESXi 5.0-Host aktivieren Sie vMotion und Fault Tolerance für eine Portgruppe. Sie führen den Befehl esxcli software profile update aus, um ein Upgrade des Hosts durchzuführen. Im Rahmen eines erfolgreichen Upgrades werden die vMotion-Einstellungen und die Protokollierungseinstellungen für Fault Tolerance auf die Standardeinstellungen zurückgesetzt, d. h., sie werden deaktiviert.

    Umgehung: Verwenden Sie vSphere Upgrade Manager, um ein Upgrade der Hosts durchzuführen, oder setzen Sie manuell vMotion und Fault Tolerance auf deren Einstellungen vor dem Upgrade zurück.

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.

  • 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.

  • Ä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 die Linux-Kernelversion 3.3 und höher ausgeführt wird.

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

  • 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 "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 Switch der Serie 4500, 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.

      • 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.

      • 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)

      • 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

      • Bei der Migration virtueller Maschinen mit RDM-LUNs von einem VMFS-Datenspeicher nach einem NFS-Datenspeicher werden die RDM-LUNs von den VMs getrennt
        Wenn Sie mit dem vSphere Web Client virtuelle Maschinen mit RDM-LUNs von einem VMFS-Datenspeicher nach einem NFS-Datenspeicher migrieren, wird der Migrationsvorgang ohne Fehler- oder Warnmeldung abgeschlossen und die RMD-LUNs werden nach der Migration von der virtuellen Maschine getrennt. Allerdings wird bei der Migration eine VMDK-Datei derselben Größe wie die RDM-LUN auf dem NSF-Datenspeicher erstellt, um die RDM-LUN zu ersetzen.
        Bei Verwendung des vSphere-Clients wird eine entsprechende Fehlermeldung im Kompatibilitätsabschnitt des Migrations-Assistenten angezeigt.

        Umgehung: Keine
      • 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.

      • 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" in 3600 Sekunden.

        1. 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.

        2. 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.

        3. 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

        4. 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.

        5. 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
        • Durch das Aktivieren oder Deaktivieren des View Storage Accelerator werden möglicherweise die Verbindungen von ESXi-Hosts mit vCenter Server unterbrochen
          Wenn VMware View mit vSphere 5.1 bereitgestellt wurde und ein View-Administrator View Storage Accelerator in einem Desktop-Pool aktiviert oder deaktiviert, werden möglicherweise die Verbindungen von ESXi 5.1-Hosts mit vCenter Server 5.1 unterbrochen.

          Die Funktion View Storage Accelerator wird auch "Content Based Read Caching" genannt. In der View Administrator-Konsole von View 5.1 wird diese Funktion als Host-Caching bezeichnet.

          Umgehung: Aktivieren oder deaktivieren Sie View Storage Accelerator nicht in mit vSphere 5.1 bereitgestellten View-Umgebungen.

        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.

        • Klon- oder Migrationsvorgänge unter Verwendung virtueller Nicht-VMFS-Festplatten auf ESXi schlagen mit einer Fehlermeldung fehl
          Unabhängig davon, ob Sie den vmkfstools-Befehl oder den Client verwenden, um einen Klon-, Kopier- oder Migrationsvorgang auf den virtuellen Laufwerken von gehosteten Formaten durchzuführen, schlägt der Vorgang mit der folgenden 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

        • 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.

        Migrationsprobleme
        • Versuche, Storage vMotion zum Migrieren von mehreren virtuellen Linked-Clone-Maschinen zu verwenden, schlagen fehl
          Dieser Fehler betrifft in der Regel virtuelle Linked-Clone-Maschinen. Dieser Fehler tritt auf, wenn die Größe von Delta-Festplatten 1 MB beträgt und die CBRC-Funktion (Content Based Read Cache) in ESXi-Hosts aktiviert wurde. Die folgende Fehlermeldung wird angezeigt: Die Quelle hat erkannt, dass das Ziel nicht fortgesetzt werden konnte.

          Umgehung: Verwenden Sie eine der folgenden Methoden, um Storage vMotion-Ausfälle zu vermeiden:

          • Verwenden Sie 4 KB als die Größe von Delta-Festplatten.

          • Anstatt Storage vMotion zu verwenden, migrieren Sie ausgeschaltete virtuelle Maschinen auf einen neuen Datenspeicher.

        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.

        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 starten syslog über TCP, syslog über SSL und die Speicherprotokollierung nicht automatisch neu
          Nach einer Netzwerk- oder Speicherunterbrechung startet der syslog-Dienst in bestimmten Konfigurationen nicht automatisch neu. 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.