Versionshinweise zu VMware ESXi 5.5 Update 3a

|

VMware ESXi™ 5.5 Update 3a | 6. Oktober 2015 | Build 3116895

Letzte Aktualisierung: 30. März 2016

Ü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:

  • Aktivierung der Protokollrotation Mithilfe der Protokollrotation für VMX-Dateien können Sie die Größe der Protokolldateien reduzieren, indem Sie die Größe jedes Protokolls und die Anzahl der aufzubewahrenden vorherigen Protokolle angeben.


  • Zertifizierung des PVSCSI-Adapters Der PVSCSI-Adapter ist für die Verwendung mit MSCS, Hauptclustern und Anwendungen wie SQL und Exchange zertifiziert. Dies ermöglicht Leistungssteigerungen beim Umstieg von LSI Logic SAS auf PVSCSI.


  • Unterstützung von Prozessoren der nächsten Generation Auch in dieser Version werden Prozessoren der nächsten Generation von Intel und AMD unterstützt. Weitere Informationen finden Sie im VMware-Kompatibilitätshandbuch.


  • ESXi-Authentifizierung für Active Directory ESXi wurde geändert und unterstützt nun nur die AES256-CTS/AES128-CTS/RC4-HMAC-Verschlüsselung für die Kerberos-Kommunikation zwischen ESXi und Active Directory.


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

Vorherige Versionen von ESXi 5.5

Die Funktionen und bekannten Probleme von ESXi 5.5 werden in den entsprechenden Versionshinweisen beschrieben. Versionshinweise für frühere Versionen von ESXi 5.5:

Internationalisierung

VMware vSphere 5.5 Update 3a gibt es in den folgenden Sprachen:

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

Kompatibilität und Installation

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

Die VMware-Produkt-Interoperabilitätsmatrix liefert Details zur Kompatibilität aktueller und vorheriger Versionen von VMware vSphere-Komponenten, einschließlich ESXi, VMware vCenter Server, vSphere Web Client und optionaler VMware-Produkte. Prüfen Sie die VMware-Produkt-Interoperabilitätsmatrix ebenfalls auf Informationen zu unterstützten Management- und Backup-Agenten, bevor Sie ESXi oder vCenter Server installieren.

vCenter Server ISO enthält den vSphere Client und den vSphere Web Client. Mithilfe des VMware vCenter™-Installationsassistenten können Sie einen oder beide Clients installieren.

ESXi, vCenter Server und VDDK-Kompatibilität

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

Kompatibilität von ESXi und Virtual SAN

Virtual SAN unterstützt keine Cluster, die mit ESXi-Hosts vor 5.5 Update 1 konfiguriert sind. Führen Sie für alle Hosts im Virtual SAN-Cluster ein Upgrade auf ESXi 5.5 Update 1 oder höher durch, bevor Sie Virtual SAN aktivieren. Auch vCenter Server sollte auf 5.5 Update 1 oder höher aktualisiert werden.

Hardwarekompatibilität für ESXi

Um eine Liste der Prozessoren, Speichergeräte, SAN-Arrays und E/A-Geräte anzuzeigen, die mit vSphere 5.5 Update 3 kompatibel sind, lesen Sie die Informationen zu ESXi 5.5 Update 3 im VMware-Kompatibilitätshandbuch.

Gerätekompatibilität für ESXi

Verwenden Sie die Informationen zu ESXi 5.5 Update 3 im VMware-Kompatibilitätshandbuch, um die Geräte zu ermitteln, die mit ESXi 5.5 Update 3a kompatibel sind.

Einige Geräte sind veraltet und werden nicht mehr von ESXi 5.5 und höher unterstützt. Während des Upgrade-Vorgangs wird der Gerätetreiber auf dem ESXi 5.5.x-Host installiert. Er funktioniert möglicherweise auch unter ESXi 5.5.x, aber das Gerät wird unter ESXi 5.5.x nicht unterstützt. Eine Aufstellung der veralteten Geräte, die nicht mehr von ESXi 5.5.x unterstützt werden, finden Sie im VMware-Knowledgebase-Artikel Veraltete Geräte und Warnungen während des Upgrade-Vorgangs von ESXi 5.5.

Kompatibilität von Gastbetriebssystemen für ESXi

Verwenden Sie die Informationen zu vSphere 5.5 Update 3 im VMware-Kompatibilitätshandbuch, um die Gastbetriebssysteme zu ermitteln, die mit ESXi 5.5 Update 3a kompatibel sind.

Kompatibilität von virtuellen Maschinen für ESXi

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

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

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

Installationshinweise für diese Version

Weitere Informationen zum Installieren und Konfigurieren von ESXi und vCenter Server finden Sie im Handbuch zur Installation und Einrichtung von vSphere .

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

Migrieren von Drittanbieterlö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.1 und ESXi 5.5 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 Ihres Hosts 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.5.x 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.5.x. Wenn Ihre Hosthardware nicht kompatibel ist, erscheint ein violetter Bildschirm mit einer entsprechenden Meldung. Sie können vSphere 5.5.x weder installieren noch ein Upgrade darauf durchführen.

Upgrades für diese Version

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

Unterstützte Upgrade-Pfade für das Upgrade auf ESXi 5.5 Update 3a:

Upgrade-Lieferumfang

Unterstützte Upgrade-Tools

Unterstützte Upgrade-Pfade auf ESXi 5.5 Update 3a

ESX/ESXi 4.0:
Enthält
ESX/ESXi 4.0 Update 1
ESX/ESXi 4.0 Update 2

ESX/ESXi 4.0 Update 3
ESX/ESXi 4.0 Update 4

ESX/ESXi 4.1:
Enthält
ESX/ESXi 4.1 Update 1
ESX/ESXi 4.1 Update 2

ESX/ESXi 4.1 Update 3

ESXi 5.0:
Enthält
ESXi 5.0 Update 1

ESXi 5.0 Update 2
ESXi 5.0 Update 3

ESXi 5.1
Enthält
ESXi 5.1 Update 1
ESXi 5.1 Update 2

ESXi 5.5:
Enthält
ESXi 5.5 Update 1
ESXi 5.5 Update 2

VMware-VMvisor-Installer-5.5.0.update03-3116895.x86_64.iso

 

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

Ja

Ja

Ja

Ja

Ja

ESXi550-201510001.zip
  • VMware vSphere Update Manager
  • ESXCLI
  • VMware vSphere-CLI

Nein

Nein

Ja*

Ja*

Ja

Verwendung von Patch-Definitionen, die vom VMware-Portal (online) heruntergeladen werden VMware vSphere Update Manager mit Patch-Baseline

Nein

Nein

Nein

Nein

Ja


*Hinweis: Ein Upgrade von ESXi 5.0.x oder ESXi 5.1.x auf ESXi 5.5 Update 3a mithilfe von - ESXi550-201510001.zip wird nur in ESXCLI unterstützt. Sie müssen den Befehl esxcli software profile update --depot=<depot_location> --profile=<profile_name> ausführen, um das Upgrade durchzuführen. Weitere Informationen finden Sie im Thema ESXi 5.5.x Upgrade-Optionen im vSphere-Upgrade-Handbuch.

Open Source-Komponenten für VMware vSphere 5.5 Update 3

Informationen über Copyright und Lizenzen für die Open Source-Softwarekomponenten, die im Lieferumfang von vSphere 5.5 Update 3 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 die Verfügbarkeit des Quellcodes bzw. dessen Modifizierung für die jeweils neueste vorliegende vSphere-Version erfordern.

Hinweise zur Produktunterstützung

  • vSphere Web Client. Linux-Plattformen werden von Adobe Flash nicht mehr unterstützt, weshalb der vSphere Web Client unter dem Linux-Betriebssystem nicht unterstützt wird. Drittanbieter-Browser, die die Unterstützung für Adobe Flash unter dem Linux-Desktop-Betriebssystem hinzufügen, sind möglicherweise weiterhin funktionsfähig.

    VMware vCenter Server Appliance. In vSphere 5.5 hält die VMware vCenter Server Appliance durch Erzwingen der DISA Security Technical Information Guidelines (STIG) strenge Compliance-Standards ein. Vor der Bereitstellung der VMware vCenter Server Appliance sollten Sie im VMware Hardened Virtual Appliance Operations Guide die Informationen zu den neuen Sicherheitsstandards für die Bereitstellung nachlesen, um den erfolgreichen Betrieb sicherzustellen.

  • vCenter Server-Datenbank. In vSphere 5.5 wird IBM DB2 nicht mehr als vCenter Server-Datenbank unterstützt.

  • VMware Tools. Ab vSphere 5.5 werden alle Informationen zum Installieren und Konfigurieren von VMware Tools in vSphere mit der restlichen vSphere-Dokumentation zusammengefasst. Informationen zur Verwendung von VMware Tools in vSphere finden Sie in der vSphere-Dokumentation. Installieren und Konfigurieren von VMware Tools ist für vSphere 5.5 und höher nicht relevant.

  • VMware Tools. Ab vSphere 5.5 gibt es in VMware Tools keine ThinPrint-Funktionen mehr.

  • vSphere Data Protection. vSphere Data Protection 5.1 ist aufgrund der geänderten Funktionsweise des vSphere Web Client nicht mit vSphere 5.5 kompatibel. Benutzer von vSphere Data Protection 5.1, die ein Upgrade auf vSphere 5.5 durchführen, müssen auch vSphere Data Protection aktualisieren, falls sie vSphere Data Protection weiterhin verwenden möchten.

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.

Die Patch-Version ESXi550-Update03 enthält die folgenden einzelnen Bulletins:

ESXi550-201510401-BG: Aktualisiert ESXi 5.5 esx-base vib

Die Patch-Version ESXi550-Update03 enthält die folgenden Image-Profile:

ESXi-5.5.0-20151004001-standard
ESXi-5.5.0-20151004001-no-tools

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

Behobene Probleme

In diesem Abschnitt werden in dieser Version gelöste Probleme beschrieben:

Sicherungsprobleme

  • Wiederherstellung einer virtuellen Maschine schlägt möglicherweise mit einer Fehlermeldung fehl
    Versuche, eine virtuelle Maschine auf einem ESXi-Host mit vSphere Data Protection wiederherzustellen, schlagen möglicherweise mit einer Fehlermeldung ähnlich der Folgenden fehl:

    Unerwartete Ausnahme bei Neukonfiguration gemeldet

    Dieses Problem wurde in der vorliegenden Version behoben.

CIM- und API-Probleme

  • Syslog-Protokollüberflutung, wenn das Systemereignisprotokoll voll ist und Indication-Abonnements vorhanden sind
    Wenn das Systemereignisprotokoll (System Event Log, SEL) voll ist und Indication-Abonnements vorhanden sind, führt dies zu einer Syslog-Protokollüberflutung. Die folgenden Einträge werden schnell protokolliert:

    sfcb-vmware_raw[xxxxxxxxxx]: Can't get Alert Indication Class. Standardeinstellungen verwenden
    sfcb-vmware_raw[xxxxxxxxxx]: Can't get Alert Indication Class. Standardeinstellungen verwenden
    sfcb-vmware_raw[xxxxxxxxxx]: Can't get Alert Indication Class. Standardeinstellungen verwenden

    Dieses Problem wurde in der vorliegenden Version behoben.
  • CIM-Indications schlagen möglicherweise beim Neustart der ESXi-Hosts mit Auto Deploy fehl
    Wenn die Ausführung des sfcbd-Diensts beendet wird, können die CIM-Indications im Hostprofil nicht korrekt angewendet werden.

    Dieses Problem wurde in dieser Version behoben, indem sichergestellt wurde, dass die CIM-Indications beim Anwenden des Hostprofils nicht auf den Status des sfcbd-Diensts zurückgreifen.
  • Als Status einiger Festplatten wird möglicherweise UNCONFIGURED GOOD anstelle von ONLINE angezeigt
    Auf einem ESXi 5.5-Host wird als Status einiger Festplatten möglicherweise UNCONFIGURED GOOD anstelle von ONLINE angezeigt. Dieses Problem tritt für einen LSI-Controller auf, der den LSI-CIM-Anbieter verwendet.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Laden des Kernel-Moduls über die CIM-Schnittstelle schlägt möglicherweise fehl
    Der Befehl LoadModule schlägt möglicherweise fehl, wenn das Kernel-Modul mit dem Client der CIM-Schnittstelle geladen wird. Eine Fehlermeldung ähnlich der folgenden wird angezeigt:

    Der Zugriff wurde durch die VMkernel-Zugriffssteuerungsrichtlinie verweigert.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Überwachung eines ESXi 5.5-Hosts mit Dell OpenManage schlägt möglicherweise aufgrund eines openwsmand-Fehlers fehl
    Die Überwachung eines ESXi 5.5-Hosts mit Dell OpenManage schlägt möglicherweise aufgrund eines openwsmand-Fehlers fehl. Eine Fehlermeldung ähnlich der Folgenden wird ggf. in die Protokolldatei syslog.log geschrieben:

    Failed to map segment from shared object: No space left on device

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Hardwarestatus-Abfrage auf vSphere Client schlägt möglicherweise mit einer Fehlermeldung fehl
    Versuche, den Hardwarestatus auf dem vSphere Client abzufragen, schlagen möglicherweise fehl. Eine Fehlermeldung ähnlich der folgenden wird in der Protokolldatei /var/log/syslog.log im ESXi-Host angezeigt:

    TIMEOUT DOING SHARED SOCKET RECV RESULT (1138472) Timeout (or other socket error) waiting for response from provider Header Id (16040) Request to provider 111 in process 4 failed. Error:Timeout (or other socket error) waiting for response from provider Dropped response operation details -- nameSpace: root/cimv2, className: OMC_RawIpmiSensor, Type: 0

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Überwachung eines ESXi 5.5-Hosts mit Dell OpenManage schlägt möglicherweise aufgrund eines openwsmand-Fehlers fehl
    Die Überwachung eines ESXi 5.5-Hosts mit Dell OpenManage schlägt möglicherweise aufgrund eines openwsmand-Fehlers fehl. Eine Fehlermeldung ähnlich der Folgenden wird ggf. in die Protokolldatei syslog.log geschrieben:

    Failed to map segment from shared object: No space left on device

    Dieses Problem wurde in der vorliegenden Version behoben.
  • sfcbd-Dienst reagiert möglicherweise nicht mehr und eine Fehlermeldung wird angezeigt
    Der Dienst sfcbd reagiert möglicherweise nicht mehr und die folgende Fehlermeldung wird möglicherweise in der syslog-Protokolldatei ausgegeben:

    spSendReq/spSendMsg failed to send on 7 (-1)
    Error getting provider context from provider manager: 11

    Dieses Problem tritt auf, wenn sich CIM-Server und -Anbieter wegen eines Semaphors in einem Deadlock befinden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Auf der Registerkarte „Hardwarestatus“ von vSphere Client werden falsche Alarme angezeigt
    Nach einem Upgrade der Integrated Lights Out (iLO)-Firmware auf HP DL980 G7 werden auf der Registerkarte „Hardwarestatus“ von vSphere Client falsche Alarme angezeigt. Es werden möglicherweise Fehlermeldungen ähnlich den folgenden in die Protokolldatei /var/log/syslog.log geschrieben:

    sfcb-vmware_raw[nnnnn]: IpmiIfruInfoAreaLength: Reading FRU for 0x0 at 0x8 FAILED cc=0xffffffff
    sfcb-vmware_raw[nnnnn]: IpmiIfcFruChassis: Reading FRU Chassis Info Area length for 0x0 FAILED
    sfcb-vmware_raw[nnnnn]: IpmiIfcFruBoard: Reading FRU Board Info details for 0x0 FAILED cc=0xffffffff
    sfcb-vmware_raw[nnnnn]: IpmiIfruInfoAreaLength: Reading FRU for 0x0 at 0x70 FAILED cc=0xffffffff
    sfcb-vmware_raw[nnnnn]: IpmiIfcFruProduct: Reading FRU product Info Area length for 0x0 FAILED
    sfcb-vmware_raw[nnnnn]: IpmiIfcSelReadEntry: data length mismatch req=19,resp=3
    sfcb-vmware_raw[nnnnn]: IpmiIfcSelReadEntry: EntryId mismatch req=0001,resp=0002
    sfcb-vmware_raw[nnnnn]: IpmiIfcSelReadEntry: EntryId mismatch req=0002,resp=0003
    sfcb-vmware_raw[nnnnn]: IpmiIfcSelReadEntry: EntryId mismatch req=0003,resp=0004
    sfcb-vmware_raw[nnnnn]: IpmiIfcSelReadEntry: EntryId mismatch req=0004,resp=0005
    sfcb-vmware_raw[nnnnn]: IpmiIfcSelReadEntry: EntryId mismatch req=0005,resp=0006
    sfcb-vmware_raw[nnnnn]: IpmiIfcSelReadEntry: EntryId mismatch req=0006,resp=0007

    Dieses Problem wurde in der vorliegenden Version behoben.
  • ESXi sendet Ereignisse doppelt an die Verwaltungssoftware
    ESXi sendet Ereignisse möglicherweise doppelt an die Verwaltungssoftware, wenn ein Intelligent Platform Management Interface (IPMI)-Sensorereignis auf dem ESXi-Host ausgelöst wird.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Hardwarestatus kann nach dem Entfernen des CIM Indication-Abonnements nicht überwacht werden
    Wenn der CIM-Client zwei Anforderungen von Einzeltermin löschen an dasselbe CIM Indication-Abonnement sendet, reagiert der sfcb-vmware_int-Dienst aufgrund eines Arbeitsspeicherkonflikts möglicherweise nicht mehr. Sie können den Hardwarestatus mit vCenter Server und ESXi möglicherweise nicht überwachen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Überwachung eines ESXi 5.5-Hosts mit Dell OpenManage schlägt möglicherweise aufgrund eines openwsmand-Fehlers fehl
    Die Überwachung eines ESXi 5.5-Hosts mit Dell OpenManage schlägt möglicherweise aufgrund eines openwsmand-Fehlers fehl. Möglicherweise wird folgende Fehlermeldung ausgegeben:

    Failed to map segment from shared object: No space left on device

    Dieses Problem wurde in der vorliegenden Version behoben.
  • CIM-Client zeigt möglicherweise einen Fehler aufgrund mehrerer Aufzählungen an
    Wenn Sie mehrere Aufzählungsabfragen über die Methode CBEnumInstances mit der Portklasse VMware Ethernet ausführen, tritt bei Servern, auf denen ESXi 5.5 läuft, möglicherweise eine Fehlermeldung ähnlich der folgenden auf:

    CIM error: enumInstances Class not found

    Dieses Problem tritt auf, wenn es der Verwaltungssoftware nicht gelingt, die von „VMware_EthernetPort()class“ bereitgestellten Daten abzurufen. Wenn dieses Problem auftritt, führt eine Abfrage mit MemStats möglicherweise zu der folgenden Fehlermeldung:

    MemStatsTraverseGroups: VSI_GetInstanceListAlloc failure: Not found.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Hardwarestatus kann auf ESXi-Host nicht überwacht werden
    Ein ESXi-Host gibt auf der Registerkarte „Hardwarestatus“ möglicherweise einen Fehler aus, da der Hardware-Überwachungsdienst (sfcbd) nicht reagiert. Ein Fehler ähnlich dem Folgenden wird in die Datei „syslog.log“ geschrieben:

    sfcb-hhrc[5149608]: spGetMsg receiving from 65 5149608-11 Resource temporarily unavailable
    sfcb-hhrc[5149608]: rcvMsg receiving from 65 5149608-11 Resource temporarily unavailable
    sfcb-hhrc[5149608]: Timeout or other socket error
    sfcb-LSIESG_SMIS13_HHR[6064161]: spGetMsg receiving from 51 6064161-11 Resource temporarily unavailable
    sfcb-LSIESG_SMIS13_HHR[6064161]: rcvMsg receiving from 51 6064161-11 Resource temporarily unavailable
    sfcb-LSIESG_SMIS13_HHR[6064161]: Timeout or other socket error
    sfcb-kmoduleprovider[6064189]: spGetMsg receiving from 57 6064189-11 Resource temporarily unavailable
    sfcb-kmoduleprovider[6064189]: rcvMsg receiving from 57 6064189-11 Resource temporarily unavailable
    sfcb-kmoduleprovider[6064189]: Timeout or other socket error

    Der folgende Syslog-Auszug auf Debugebene weist darauf hin, dass die ungültigen Daten „0x3c“ von IPMI gesendet wurden und „0x01“ erwartet wurde.

    sfcb-vmware_raw[35704]: IpmiIfcRhFruInv: fru.header.version: 0x3c

    Dieses Problem tritt auf, wenn der sfcb-vmware_raw-Anbieter beim Lesen der FRU-Inventardaten (Field Replaceable Unit) ungültige Daten vom IPMI-Tool (Intelligent Platform Management Interface) empfängt.

    Dieses Problem wurde in der vorliegenden Version behoben.

Sonstige Probleme

  • Das Klonen einer VM-Vorlage, für die CBT aktiviert ist, von ESXi-Hosts schlägt möglicherweise fehl
    Der Versuch, VM-Vorlagen mit aktivierter Funktion für die Nachverfolgung geänderter Blöcke (Changed Block Tracking, CBT) gleichzeitig von zwei verschiedenen ESXi 5.5-Hosts zu klonen, schlägt möglicherweise fehl. Eine Fehlermeldung ähnlich der folgenden wird angezeigt:

    VM_template.vmdk' konnte nicht geöffnet werden: Die Datei der Änderungsverfolgung konnte nicht geöffnet/erstellt werden (2108).

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Anmeldung bei ESXi-Host mit Active Directory-Anmeldedaten ist nicht möglich
    Anmeldeversuche bei einem ESXi-Host schlagen möglicherweise fehl, nachdem der Host erfolgreich einer Active Directory beigetreten ist. Dieses Problem tritt auf, wenn ein Benutzer aus einer Domäne versucht, einer anderen vertrauenswürdigen Domäne beizutreten, die nicht am ESXi-Client-Standort vorhanden ist. Eine Fehlermeldung ähnlich der Folgenden wird in die Protokolldatei sys.log/netlogon.log geschrieben:

    netlogond[17229]: [LWNetDnsQueryWithBuffer() /build/mts/release/bora-1028347/likewise/esxi-esxi/src/linux/netlogon/utils/lwnet-dns.c:1185] DNS lookup for '_ldap._tcp.<domain details>' failed with errno 0, h_errno = 1

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Update der cURL-Bibliothek
    cURL kann „localhost“ nicht auflösen, wenn IPv6 deaktiviert ist. Eine Fehlermeldung ähnlich der folgenden wird angezeigt:

    Fehler: enumInstances-Initialisierung ist fehlgeschlagen

    Dieses Problem wurde in der vorliegenden Version behoben.

Netzwerkprobleme

  • ESXi-Hosts, deren virtuelle Maschinen einen e1000- oder e1000e-vNIC-Treiber aufweisen, schlagen möglicherweise mit einem lilafarbenen Bildschirm fehl
    ESXi-Hosts, deren virtuelle Maschinen einen e1000- oder e1000e-vNIC-Treiber aufweisen, schlagen möglicherweise mit einem lilafarbenen Bildschirm fehl, wenn Sie den TCP-Segmentierungs-Offload (TCP Segmentation Offload, TSO) aktivieren. Ggf. werden Fehlermeldungen ähnlich der Folgenden in die Protokolldateien geschrieben:

    cpu7:nnnnnn)Code start: 0xnnnnnnnnnnnn VMK uptime: 9:21:12:17.991
    cpu7:nnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]E1000TxTSOSend@vmkernel#nover+0x65b stack: 0xnnnnnnnnnn
    cpu7:nnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]E1000PollTxRing@vmkernel#nover+0x18ab stack: 0xnnnnnnnnnnnn
    cpu7:nnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]E1000DevAsyncTx@vmkernel#nover+0xa2 stack: 0xnnnnnnnnnnnn
    cpu7:nnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]NetWorldletPerVMCB@vmkernel#nover+0xae stack: 0xnnnnnnnnnnnn
    cpu7:nnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]WorldletProcessQueue@vmkernel#nover+0x488 stack: 0xnnnnnnnnnnnn
    cpu7:nnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]WorldletBHHandler@vmkernel#nover+0x60 stack: 0xnnnnnnnnnnnnnnn
    cpu7:nnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]BH_Check@vmkernel#nover+0x185 stack: 0xnnnnnnnnnnnn

    Dieses Problem wurde in der vorliegenden Version behoben.
  • ESXi reagiert auf unnötige Internet Control Message Protocol (ICMP)-Anforderungstypen
    Der ESXi-Host reagiert möglicherweise auf unnötige Internet Control Message Protocol (ICMP)-Anforderungstypen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • ESXi-hostd schlägt möglicherweise beim Ausführen von erneuten Prüfungen für Speichergeräte fehl
    Wenn Sie erneute Prüfungen für Speichergeräte ausführen, schlägt hostd möglicherweise fehl, da mehrere Threads versuchen, dasselbe Objekt zu ändern. Ggf. werden in der Protokolldatei vmkwarning.log Fehlermeldungen ähnlich der Folgenden angezeigt:

    cpu43:nnnnnnn)ALERT: hostd detected to be non-responsive
    cpu20:nnnnnnn)ALERT: hostd detected to be non-responsive

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Protokollüberflutung beim Hinzufügen des ESXi-Hosts in vCenter Server
    Wenn Sie einen ESXi-Host in vCenter Server hinzufügen und eine VMkernel-Schnittstelle für vMotion erstellen, wird die folgende Meldung in kurzen Abständen (Protokollüberflutung) in der Datei hostd.log angezeigt:

    Failed to find vds Id for portset vSwitch0

    Dieses Problem wurde in der vorliegenden Version behoben.
  • 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-Bereitstellungsdienste 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.
  • Probleme beim Aktivieren der Konfiguration von Rx Ring#2 zum Beheben von unzureichendem Arbeitsspeicher und Paketausfällen auf der Empfängerseite
    Eine virtuelle Linux-Maschine, bei der die LRO-Funktionalität (Large Receive Offload) auf einem VMXNET3-Gerät aktiviert ist, kann von Paketausfällen auf der Empfängerseite betroffen sein, wenn Rx Ring #2 über nicht genügend Arbeitsspeicher verfügt, da die Größe von Rx Ring#2 ursprünglich nicht konfiguriert werden kann.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Bei Verwendung von DvFilter mit einem von NetQueue unterstützten Uplink wird möglicherweise ein lilafarbener Diagnosebildschirm angezeigt
    Für einen ESXi-Server wird möglicherweise eine lilafarbener Diagnosebildschirm angezeigt, wenn DvFilter mit einem von NetQueue unterstützten Uplink und einer vSwitch- oder vSphere Distributed Switch (VDS)-Verbindung verwendet wird. Der ESXi-Host meldet möglicherweise eine Rückverfolgung ähnlich der Folgenden:

    pcpu:22 world:4118 name:"idle22" (IS)
    pcpu:23 world:2592367 name:"vmm1:S10274-AAG" (V)
    @BlueScreen: Spin count exceeded (^P) - possible deadlock
    Code start: 0xnnnnnnnnnnnn VMK uptime: 57:09:18:15.770
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]Panic@vmkernel#nover+0xnn stack: 0xnnnnnnnnnnnn
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]SP_WaitLock@vmkernel#nover+0xnnn stack: 0xnnnnnnnnnnnn
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]NetSchedFIFOInput@vmkernel#nover+0xnnn stack: 0x0
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]NetSchedInput@vmkernel#nover+0xnnn stack: 0xnnnnnnnnnnnn
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]IOChain_Resume@vmkernel#nover+0xnnn stack: 0xnnnnnnnnnnnn
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]PortOutput@vmkernel#nover+0xnn stack: 0xnn

    Dieses Problem wurde in der vorliegenden Version behoben.
  • ESXi-Host schlägt bei deaktivierter NetFlow-Funktion mit einem lilafarbenen Diagnosebildschirm fehl
    Ein ESXi-Host schlägt möglicherweise mit einem lilafarbenen „PF exception 14“-Diagnosebildschirm fehl, wenn die NetFlow-Funktion von vSphere Distributed Switch deaktiviert wird. Diese Situation ist auf ein Timer-Synchronisierungsproblem zurückzuführen.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Änderung des Netzwerk-Schedulers in SFQ bei hoher E/A-Last führt möglicherweise zu einer nicht behebbaren Übertragung
    Bei hoher E/A-Last setzt der SFQ-Netzwerk-Scheduler beim Wechsel der Netzwerk-Scheduler möglicherweise die physische Netzwerkkarte zurück. Dies kann zu einer nicht behebbaren Übertragung führen, bei der keine Pakete an den Treiber übertragen werden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • vmkping-Befehl schlägt bei Jumbo-Frames möglicherweise fehl
    Der vmkping-Befehl schlägt bei Jumbo-Frames möglicherweise fehl, nachdem eine von vielen Vmknic-MTUs im selben Switch geändert wurde. Eine Fehlermeldung ähnlich der folgenden wird angezeigt:

    sendto() fehlgeschlagen (Meldung zu lang)

    Dieses Problem wurde in der vorliegenden Version behoben.
  • ESXi-Firewall lehnt möglicherweise die Dienste ab, die Port 0-65535 als Dienst-Port verwenden
    Der Konzentrator für den virtuellen seriellen Port (Virtual Serial Port Concentrator, vSPC) bzw. der NFS-Clientdienst funktioniert auf der ESXi-Plattform möglicherweise nicht. Dies passiert, wenn eine andere Regelsatzreihenfolge vorliegt, die als Ergebnis der Aktivierung der Sequenz Port 0-65535 erlaubt. Dadurch werden die Pakete für vSPC oder den NFS-Client unerwartet verworfen, selbst wenn die zulässige IP im entsprechenden Regelsatz angegeben ist.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • IPv6-Router-Ankündigungen funktionieren nicht wie erwartet bei der 802.1q-Kennzeichnung mit VMXNET3-Adaptern
    IPv6-Router-Ankündigungen (RA) funktionieren nicht wie erwartet bei der 802.1q-Kennzeichnung mit VMXNET3-Adaptern in einer virtuellen Maschine mit Linux, da die für die VLAN-Schnittstelle bestimmte IPv6 RA-Adresse an die Basisschnittstelle übermittelt wird.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Netzwerkkonnektivität des ESXi-Hosts wird möglicherweise unterbrochen
    Möglicherweise wird die Netzwerkkonnektivität eines ESXi-Hosts unterbrochen und es treten Stabilitätsprobleme auf, wenn mehrere Fehlermeldungen ähnlich der Folgenden protokolliert werden:

    WARNING: Heartbeat: 785: PCPU 63 hatte 7 Sekunden lang kein Taktsignal; *kann* gesperrt sein.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Netzwerkkonnektivität wird beim Anwenden des Hostprofils während der Ausführung von Auto Deploy unterbrochen
    Beim Anwenden des Hostprofils während der Ausführung von Auto Deploy wird möglicherweise die Netzwerkkonnektivität unterbrochen, da die VTEP-Netzwerkkarte (VXLAN Tunnel Endpoint) als Verwaltungs-vmknic gekennzeichnet wird.

    Dieses Problem wurde in der vorliegenden Version behoben.

Sicherheitsprobleme

  • Update der libxml2-Bibliothek
    Die userworld-libxml2-Bibliothek von ESXi wurde auf Version 2.9.2 aktualisiert.
  • Update auf ESXi-Userworld-OpenSSL-Bibliothek
    Die ESXi-Userworld-OpenSSL-Bibliothek wurde auf Version 1.0.1m aktualisiert.
  • Update der libPNG-Bibliothek
    Die libPNG-Bibliothek wurde auf libpng-1.6.16 aktualisiert.

Serverkonfigurationsprobleme

  • SOL (Serial over LAN)-Konsolenumleitung funktioniert möglicherweise nicht ordnungsgemäß
    Eine PCIe-Karte für die Umleitung des seriellen Ports funktioniert möglicherweise nicht ordnungsgemäß, wenn sie mit einem ISA (Industry Standard Architecture)-IRQ (Interrupt Request) (0-15 Dezimalstellen) auf einem APIC (Advanced Programmable Interrupt Controller) verbunden ist, da die Interrupts nicht von der CPU empfangen werden können. Damit diese und andere mit ISA-IRQs verbundene PCI-Geräte funktionieren, erlaubt VMkernel nun Level-Triggered-Interrupts auf ISA-IRQs.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Esxtop zeigt möglicherweise fälschlicherweise eine CPU-Nutzung von 100 % an
    PCPU UTIL/CORE UTIL im Dienstprogramm „esxtop“ zeigt fälschlicherweise eine CPU-Nutzung von 100 % an, wenn für PcpuMigrateIdlePcpus der Wert „0“ festgelegt ist.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Bei der Abfrage von Fibre-Channel-HBAs (Hostbusadaptern) wird der Status „Unbekannt(1)“ gemeldet
    Nach dem Upgrade des ESXi-Hosts von ESXi 5.1 auf 5.5 und dem Import des neuesten MIB-Moduls gibt die Drittanbieter-Überwachungssoftware bei der Abfrage von Fibre-Channel-HBAs (Hostbusadaptern) den Status „Unbekannt(1)“ zurück.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Host-Gateway wird gelöscht und Übereinstimmungsfehler treten möglicherweise auf, wenn ein vorhandenes ESXi-Hostprofil neu auf einen statusorientierten ESXi-Host angewendet wird
    Wenn ein bestehendes ESXi-Hostprofil auf einen neu installierten ESXi 5.5-Host angewendet wird, lautet der Profil-Übereinstimmungsstatus möglicherweise „Nicht übereinstimmend“. Dies passiert, wenn das Hostprofil von Hosts mit konfigurierter VXLAN-Schnittstelle erstellt wird. Der Übereinstimmungstest auf Hosts mit dem zuvor erstellten Hostprofil schlägt dann möglicherweise fehl. Eine Fehlermeldung ähnlich der folgenden wird angezeigt:

    Die IP-Routenkonfiguration stimmt nicht mit der Spezifikation überein

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Lilafarbener Diagnosebildschirm mit Seitenfehlerausnahme wird in einer geschachtelten ESXi-Umgebung angezeigt
    In einer geschachtelten ESXi-Umgebung führt die Implementierung von CpuSchedAfterSwitch() zu einer Racebedingung beim Scheduler-Code und ein lilafarbener Diagnosebildschirm mit Seitenfehlerausnahme wird angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • iSCSI-Initiatorname zulässig beim Aktivieren von Software-iSCSI mithilfe von esxcli
    Nun können Sie einen iSCSI-Initiatornamen für den Befehl esxcli iscsi software set angeben.
  • Für eine virtuelle Maschine wird möglicherweise keine Warnmeldung angezeigt, wenn die CPU nicht vollständig reserviert ist
    Wenn Sie eine virtuelle Maschine erstellen, für sched.cpu.latencySensitivity den Wert „Hoch“ festlegen und die virtuelle Maschine einschalten, wird die exklusive Affinität für die vCPUs möglicherweise nicht aktiviert, falls die VM keine vollständige CPU-Reservierung aufweist.

    In früheren Versionen hat die VM keine Warnmeldung angezeigt, wenn die CPU nicht vollständig reserviert war. Weitere Informationen finden Sie im Knowledgebase-Artikel 2087525.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • SNMPD wird nach einem Upgrade des ESXi-Hosts möglicherweise automatisch gestartet
    SNMPD wird nach einem Upgrade des ESXi-Hosts auf Version 5.5 Update 2 möglicherweise automatisch gestartet.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Hostprofile werden durch eine einfache Änderung der SNMP-Option „syscontact“ oder „syslocation“ inkompatibel
    Hostprofile werden inkompatibel, wenn eine einfache Änderung an der SNMP-Option „syscontact“ oder „syslocation“ vorgenommen wird. Dieses Problem tritt auf, wenn das SNMP-Hostprofil-Plug-In nur einen einzigen Wert auf alle an das Hostprofil angehängte Hosts anwendet. Es wird u. U. eine Fehlermeldung ähnlich der folgenden angezeigt:

    Konfiguration des SNMP-Agenten unterscheidet sich

    Dieses Problem wurde in der vorliegenden Version durch die Aktivierung von Werteinstellungen pro Host für bestimmte Parameter wie „syslocation“, „syscontact“, „v3targets“, „v3users“ und „engineid“ behoben.
  • Beim Versuch, einen FIFO zu erstellen und Daten darauf zu schreiben, wird möglicherweise ein violetter Diagnosebildschirm angezeigt
    Wenn Sie eine FIFO erstellen und versuchen, Daten in das /tmp/dpafifo-Verzeichnis zu schreiben, wird unter bestimmten Bedingungen ein violetter Diagnosebildschirm angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Versuche, Windows 8 und Windows 2012 Server auf virtuellen Maschinen des ESXi-Hosts neu zu starten, schlagen möglicherweise fehl
    Nach einem Neustart reagieren virtuelle Maschinen mit Windows 8 und Windows 2012 Server möglicherweise nicht mehr, wenn beim Start der Microsoft Windows-Splash-Screen angezeigt wird. Weitere Informationen finden Sie im Knowledgebase-Artikel 2092807.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Einstellen des CPU-Limits einer Uniprozessor-VM führt zu einem Abfall der ESXi-Nutzung
    Wenn Sie das CPU-Limit einer Uniprozessor-VM festlegen, kann die gesamte ESXi-Nutzung aufgrund eines Fehlers im ESXi-Scheduler abfallen. Dies ist darauf zurückzuführen, dass der ESXi-Scheduler davon ausgeht, dass die VMs mit dem CPU-Limit ausgeführt werden (wenn sie nicht ausgeführt werden) und Schätzungen über die CPU-Auslastung vornimmt. Dies führt zu einer falschen Entscheidung beim Lastausgleich.

    Details finden Sie im Knowledgebase-Artikel 2096897.

    Dieses Problem wurde in der vorliegenden Version behoben.

Probleme bei unterstützter Hardware

  • Stromverbrauchs- und Leistungskapazitätswerte fehlen im esxtop-Befehl
    Auf Lenovo-Systemen fehlen die Stromverbrauchs- und Leistungskapazitätswerte im esxtop-Befehl.

    Dieses Problem wurde in der vorliegenden Version behoben.

Speicherprobleme

  • Bei einem High Availability-Failover oder einem Hostabsturz verbleiben die .vswp-Dateien der eingeschalteten VMs auf dem betreffenden Host möglicherweise im Speicher
    Bei einem High Availability-Failover oder einem Hostabsturz verbleiben die .vswp-Dateien der eingeschalteten virtuellen Maschinen auf dem betreffenden Host möglicherweise im Speicher. Wenn viele derartige Failover oder Abstürze auftreten, könnte die Speicherkapazität hierdurch möglicherweise erschöpft werden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • In der VMkernel-Protokolldatei wird beim erneuten Prüfen eines VMFS-Datenspeichers mit mehreren Erweiterungen möglicherweise eine falsche Meldung über eine PE-Änderung angezeigt
    Wenn Sie einen VMFS-Datenspeicher mit mehreren Erweiterungen erneut prüfen, wird möglicherweise die folgende Protokollmeldung in das VMkernel-Protokoll geschrieben, selbst wenn keine Probleme bei der Speicherkonnektivität vorliegen:

    Number of PEs for volume changed from 3 to 1. A VMFS volume rescan may be needed to use this volume.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Bei vorübergehenden Fehlern schlägt möglicherweise die E/A für ein Gerät wiederholt fehl und es erfolgt kein Failover zu einem alternativen funktionierenden Pfad
    Bei vorübergehenden Fehlern wie etwa BUS BUSY, QFULL, HOST ABORTS, HOST RETRY usw. führen Sie möglicherweise wiederholt Befehle für den aktuellen Pfad aus und es erfolgt selbst nach einem angemessenen Zeitraum kein Failover zu einem anderen Pfad.

    Dieses Problem wurde in der vorliegenden Version behoben. Wenn bei derartigen vorübergehenden Fehlern der Pfad nach ein paar Wiederholungsversuchen ausgelastet ist, wird der Pfadstatus nun in DEAD geändert. Demzufolge wird ein Failover ausgelöst und ein alternativer funktionierender Pfad zum Gerät wird zum Senden von E/A-Vorgängen verwendet.
  • Bei einem High Availability-Failover oder einem Hostabsturz verbleiben die .vswp-Dateien der eingeschalteten VMs auf dem betreffenden Host möglicherweise im Speicher
    Bei einem High Availability-Failover oder einem Hostabsturz verbleiben die .vswp-Dateien der eingeschalteten virtuellen Maschinen auf dem betreffenden Host möglicherweise im Speicher. Wenn viele derartige Failover oder Abstürze auftreten, könnte die Speicherkapazität hierdurch möglicherweise erschöpft werden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Blockzuordnungsversuche für einen Offlinespeicher führen möglicherweise zum Absturz des hostd-Diensts
    Der hostd-Dienst schlägt möglicherweise auf einem ESXi 5.x-Host fehl, wenn versucht wird, die acquireLeaseExt-API für eine Snapshot-Festplatte auszuführen, die offline geschaltet wird. Diese Snapshot-Festplatte befindet sich möglicherweise auf einer Erweiterung, die offline geschaltet wurde. Der API-Aufrufer kann eine Drittanbieter-Sicherungslösung sein. Eine Fehlermeldung ähnlich der Folgenden wird in der Datei vmkernel.log angezeigt:

    cpu4:4739)LVM: 11729: Some trailing extents missing (498, 696).

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESXi 5.5-Host reagiert beim Erfassen des vm-support-Protokollpakets möglicherweise nicht mehr und es wird ein lilafarbener Diagnosebildschirm angezeigt
    Wenn für Inbox- oder Drittanbietertreiber die SCSI-transportspezifischen Schnittstellen nicht definiert sind, reagiert der ESXi-Host möglicherweise nicht mehr und es wird ein lilafarbener Diagnosebildschirm angezeigt. Dieses Problem tritt beim Erfassen von vm-support-Protokollpaketen oder beim Ausführen von I/O Device Management (IODM)-Befehlszeilenschnittstellen (Command-Line Interfaces, CLIs) auf, wie zum Beispiel:

    • esxcli storage san sas list

    • esxcli storage san sas stats get


    Dieses Problem wurde in der vorliegenden Version behoben.
  • Versuche, VMFS-Volumes über 16 TB hinaus zu erweitern, sind in bestimmten Szenarien möglicherweise nicht erfolgreich
    Ein ESXi-Host schlägt möglicherweise fehl, wenn Sie versuchen, einen VMFS5-Datenspeicher über 16 TB hinaus zu erweitern. Fehlermeldungen ähnlich der Folgenden werden in die Datei vmkernel.log geschrieben:

    cpu38:34276)LVM: 2907: [naa.600000e00d280000002800c000010000:1] Device expanded (actual size 61160331231 blocks, stored size 30580164575 blocks)
    cpu38:34276)LVM: 2907: [naa.600000e00d280000002800c000010000:1] Device expanded (actual size 61160331231 blocks, stored size 30580164575 blocks)
    cpu47:34276)LVM: 11172: LVM device naa.600000e00d280000002800c000010000:1 successfully expanded (new size: 31314089590272)
    cpu47:34276)Vol3: 661: Unable to register file system ds02 for APD timeout notifications: Already exists
    cpu47:34276)LVM: 7877: Using all available space (15657303277568).
    cpu7:34276)LVM: 7785: Error adding space (0) on device naa.600000e00d280000002800c000010000:1 to volume 52f05483-52ea4568-ce0e-901b0e0cd0f0: No space left on device
    cpu7:34276)LVM: 5424: PE grafting failed for dev naa.600000e00d280000002800c000010000:1 (opened: t), vol 52f05483-52ea4568-ce0e-901b0e0cd0f0: Limit exceeded
    cpu7:34276)LVM: 7133: Device scan failed for <naa.600000e00d280000002800c000010000:1>: Limit exceeded
    cpu7:34276)LVM: 7805: LVMProbeDevice failed for device naa.600000e00d280000002800c000010000:1: Limit exceeded
    cpu32:38063)<3>ata1.00: bad CDB len=16, scsi_op=0x9e, max=12
    cpu30:38063)LVM: 5424: PE grafting failed for dev naa.600000e00d280000002800c000010000:1 (opened: t), vol 52f05483-52ea4568-ce0e-901b0e0cd0f0: Limit exceeded
    cpu30:38063)LVM: 7133: Device scan failed for <naa.600000e00d280000002800c000010000:1>: Limit exceeded

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESXi-Host schlägt möglicherweise mit einem lilafarbenen Diagnosebildschirm fehl, wenn einer VM-Festplatte mehrere vSCSI-Filter zugeordnet sind
    Ein ESXi 5.5-Host schlägt möglicherweise mit einem lilafarbenen Diagnosebildschirm ähnlich dem Folgenden fehl, wenn einer VM-Festplatte mehrere vSCSI-Filter zugeordnet sind.

    cpu24:103492 opID=nnnnnnnn)@BlueScreen: #PF Exception 14 in world 103492:hostd-worker IP 0xnnnnnnnnnnnn addr 0x30
    PTEs:0xnnnnnnnnnn;0xnnnnnnnnnn;0x0;
    cpu24:103492 opID=nnnnnnnn)Code start: 0xnnnnnnnnnnnn VMK uptime: 21:06:32:38.296
    cpu24:103492 opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSCSIFilter_GetFilterPrivateData@vmkernel#nover+0x1 stack: 0x4136c7d
    cpu24:103492 opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSCSIFilter_IssueInternalCommand@vmkernel#nover+0xc3 stack: 0x410961
    cpu24:103492 opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]CBRC_FileSyncRead@<None>#<None>+0xb1 stack: 0x0
    cpu24:103492 opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]CBRC_DigestRecompute@<None>#<None>+0x291 stack: 0x1391
    cpu24:103492 opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]CBRC_FilterDigestRecompute@<None>#<None>+0x36 stack: 0x20
    cpu24:103492 opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSI_SetInfo@vmkernel#nover+0x322 stack: 0x411424b18120
    cpu24:103492 opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]UWVMKSyscallUnpackVSI_Set@<None>#<None>+0xef stack: 0x41245111df10
    cpu24:103492 opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]User_UWVMKSyscallHandler@<None>#<None>+0x243 stack: 0x41245111df20
    cpu24:103492 opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]User_UWVMKSyscallHandler@vmkernel#nover+0x1d stack: 0x275c3918
    cpu24:103492 opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]gate_entry@vmkernel#nover+0x64 stack: 0x0

    Dieses Problem wurde in der vorliegenden Version behoben.
  • ESXi-Host reagiert bei Speicherfluktuationen auf anderen als ATS VMFS-Datenspeichern nicht mehr und wird von vCenter Server getrennt
    Ein ESXi-Host reagiert möglicherweise nicht mehr und auf die virtuellen Maschinen kann nicht mehr zugegriffen werden. Darüber hinaus wird der ESXi-Host möglicherweise aufgrund eines Deadlocks bei Speicherfluktuationen auf anderen als ATS VMFS-Datenspeichern vom vCenter Server getrennt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der ESXi-Host wird mit einer falschen IQN auf einer Ziel-Management-Software registriert
    Unisphere Storage Management registriert die angegebene IQN des Initiators, wenn Software-iSCSI zum ersten Mal aktiviert wird. Während eines statusfreien Starts wird der registrierte IQN nicht entsprechend dem im Hostprofil definierten Namen geändert. Sie müssen die Initiatoren manuell aus dem Array entfernen und sie anschließend unter dem neuen IQN hinzufügen.

    Dieses Problem wurde durch Hinzufügen einiger neuer Parameter zum Aktivierungsbefehl für Software-iSCSI gelöst, so dass Unisphere den Initiator unter dem im Hostprofil definierten Namen registriert. Mit der folgenden Befehlszeile wird der IQN während der Aktivierung von Software-iSCSI festgelegt:

    esxcli iscsi software set --enabled=true --name iqn.xyz
  • vSphere Replication-Synchronisierung schlägt möglicherweise wegen einer Änderung beim Namen des Quelldatenspeichers fehl
    Wenn Sie einen Datenspeicher umbenennen, auf dem Replizierungsquell-VMs ausgeführt werden, schlagen Replizierungssynchronisierungen dieser virtuellen Maschinen fehl und es wird eine Fehlermeldung ähnlich der Folgenden angezeigt:

    VRM-Server - Laufzeitfehler. Suchen Sie in der Dokumentation nach Informationen zur Fehlerbehebung.
    Die detaillierte Ausnahme ist: 'Ungültiges Datenspeicherformat '<Datenspeichername>'

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Versuche, den NFS-Datenspeicher zu unmounten, schlagen möglicherweise fehl
    Versuche, den NFS-Datenspeicher zu unmounten, schlagen möglicherweise fehl, da die E/A-Vorgänge von NFS aufgrund von Konnektivitätsproblemen während NFS LOCK LOST-Fehlern ggf. nicht mehr reagieren. Es wird eine Fehlermeldung ähnlich der folgenden angezeigt:

    cpu23:xxxxx opID=xxxxxabf)WARNING: NFS: 1985: datastore1 verfügt über geöffnete Dateien, Unmounten nicht möglich

    Dieses Problem wurde in der vorliegenden Version behoben.

Upgrade- und Installationsprobleme

  • Beim Starten des ESXi 5.5-Hosts mit statusfreiem Caching von vSphere Auto Deploy wird eine Fehlermeldung auf dem Startbildschirm angezeigt
    Eine Fehlermeldung ähnlich der Folgenden mit Rückverfolgungen wird auf dem Startbildschirm angezeigt, wenn der ESXi 5.5-Host mit statusfreiem Caching von Auto Deploy gestartet wird. Dieser Fehler wird durch eine unerwartet kurze Meldung im network.py-Syslog-Skript, die weniger als vier Zeichen enthält, verursacht.

    IndexError: Zeichenfolgenindex liegt außerhalb des zulässigen Bereichs

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Installations- oder Upgrade-Versuche für VMware Tools auf einer virtuellen Maschine mit Solaris 10 Update 3 schlagen möglicherweise fehl
    Installations- oder Upgrade-Versuche für VMware Tools auf einer virtuellen Maschine mit Solaris 10 Update 3 schlagen möglicherweise mit folgender Fehlermeldung fehl:

    Detected X version 6.9
    Could not read /usr/lib/vmware-tools/configurator/XOrg/7.0/vmwlegacy_drv.so Execution aborted.

    Dieses Problem tritt auf, wenn das vmware-config-tools.pl-Skript die Datei vmwlegacy_drv.so kopiert, die nicht in Xorg 6.9 verwendet werden sollte.
  • Tastaturlayoutoption für DCUI und Hostprofil-Benutzeroberfläche wird möglicherweise fälschlicherweise als „Tschechoslowakisch“ angezeigt
    Die Tastaturlayoutoption für die Benutzerschnittstelle der direkten Konsole (Direct Console User Interface, DCUI) und die Hostprofil-Benutzeroberfläche wird möglicherweise fälschlicherweise als „Tschechoslowakisch“ angezeigt. Diese Option wird während der ESXi-Installation sowie in der DCUI nach der Installation angezeigt.

    Dieses Problem wurde in der vorliegenden Version durch Umbenennen der Tastaturlayoutoption in „Tschechisch“ behoben.
  • Option zum Beibehalten der Datei „tools.conf“ ist standardmäßig verfügbar
    Beim Upgrade von VMware Tools in einem 64-Bit-Windows-Gastbetriebssystem wird die Datei tools.conf automatisch entfernt. Die Datei tools.conf wird ab ESXi 5.5 Update 3 standardmäßig beibehalten.
  • Gastbetriebssystem schlägt möglicherweise beim Neustart nach der Installation, dem Upgrade oder der Deinstallation von VMware Tools fehl
    Wenn Sie eine virtuelle Maschine unmittelbar nach der Installation, dem Upgrade oder der Deinstallation von VMware Tools in einer Linux-Umgebung (RHEL oder Cent OS 6) ausschalten, schlägt das Gastbetriebssystem beim nächsten Neustart aufgrund einer beschädigten RAMDISK-Imagedatei möglicherweise fehl. Das Gastbetriebssystem meldet einen Fehler ähnlich dem Folgenden:

    RAMDISK: incomplete write (31522 != 32768)
    write error
    Kernel panic - not syncing : VFS: Unable to mount root fs on unknown-block(0,0)


    In dieser Version wurden die Probleme mit dem kompletten Erstellungsvorgang für die initramfs-Datei während der Installation, des Upgrades oder der Deinstallation von VMware Tools behoben.

    Ein Gastbetriebssystem mit beschädigter RAMDISK-Imagedatei kann gerettet werden, um den Startvorgang abzuschließen. Weitere Informationen finden Sie im Knowledgebase-Artikel 2086520.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Anwenden eines Hostprofils bei aktiviertem statusfreiem Caching auf dem statusfreien ESXi-Host dauert möglicherweise sehr lange
    Das Anwenden eines Hostprofils auf einem statusfreien ESXi-Host mit einer großen Anzahl von Speicher-LUNs dauert möglicherweise sehr lange, wenn Sie das statusfreie Caching mit esx als Argument für die erste Festplatte aktivieren. Dies passiert, wenn Sie ein Hostprofil manuell oder während des Neustarts des Hosts anwenden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • VIB-Bereitstellungsvorgang führt möglicherweise nach dem Neustart eines ESXi-Hosts zum Verlust der VIB-Installation oder Konfigurationsänderung
    Wenn VIBs im System installiert sind, erstellt „esxupdate“ ein neues Image in /altbootbank und ändert den zu aktualisierenden Boot-Status für /altbootbank boot.cfg. Wenn ein installierbares Live-VIB installiert ist, wird die Konfigurationsänderung in /altbootbank gespeichert. Der Bereitstellungsvorgang löscht den Inhalt von /altbootbank, außer Sie führen im Anschluss an den Bereitstellungsvorgang einen Standardisierungsvorgang aus. Die VIB-Installation geht möglicherweise verloren, wenn Sie den Host im Anschluss an einen Bereitstellungsvorgang neu starten.

    Dieses Problem wurde in der vorliegenden Version behoben.

Virtual SAN-Probleme

  • Die Prüfung des Virtual SAN-Clusters schlägt möglicherweise aufgrund einer unerwarteten Netzwerkpartitionierung im Cluster fehl
    Die Prüfung des Virtual SAN-Clusters schlägt möglicherweise aufgrund einer unerwarteten Netzwerkpartitionierung fehl, wobei die IGMP v3-Abfrage nicht gemeldet wird, falls sich das System im V2-Modus befindet.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Virtual SAN auf Festplatten mit hoher Latenz bewirkt möglicherweise, dass die E/A-Backlogs und der Cluster nicht mehr reagieren
    Virtual SAN verarbeitet Festplatten mit extrem hoher Latenz, die kurz vor der Beendigung stehen, nicht ordnungsgemäß. Eine solche Festplatte, die kurz vor der Beendigung steht, verursacht möglicherweise E/A-Backlogs und die Virtual SAN-Clusterknoten reagieren im vCenter Server möglicherweise nicht mehr.

    Dieses Problem wurde in der vorliegenden Version durch die neue Funktion DDH (Dying Disk Handling) behoben, die ein Framework für die Latenzüberwachung im Kernel, einen Daemon zur Erkennung von Zeiträumen mit hoher Latenz sowie einen Mechanismus zum Unmounten einzelner Festplatten und Festplattengruppen bereitstellt.
  • Verbesserung der Virtual SAN-Neusynchronisierung
    Möglicherweise tritt eine Situation auf, in der sich die Neusynchronisierung der Virtual SAN-Komponenten verlangsamt oder zum Stillstand kommt. In dieser Version wird die komponentenbasierte Überlastung eingeführt, die der Verbesserung von Neusynchronisierungen und der Stabilität von Virtual SAN-Clustern dient.

Probleme bei vCenter Server und beim vSphere Web Client

  • Die Registerkarte „Übersicht“ zeigt für den bereitgestellten Speicherplatz von virtuellen Maschinen und NFS- oder NAS-Datenspeichern auf VAAI-aktivierten Hosts möglicherweise falsche Werte an
    Wenn eine virtuelle Festplatte im Format „Thick-Provision Lazy-Zeroed“ auf einem VAAI-unterstützten NAS eines VAAI-aktivierten ESXi-Hosts erstellt wird, wird der bereitgestellte Speicherplatz für die zugehörige virtuelle Maschine und den entsprechenden Datenspeicher möglicherweise falsch angezeigt.

    Dieses Problem wurde in der vorliegenden Version behoben.

VM-Verwaltungsprobleme

  • Versuche, ein USB-Gerät über den vSphere Client oder vSphere Web Client hinzuzufügen, schlagen möglicherweise fehl
    Versuche, USB-Geräte über den vSphere Client oder vSphere Web Client hinzuzufügen, schlagen möglicherweise fehl, wenn der Intel USB 3.0-Treiber verwendet wird.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Erstellen eines Stilllegungs-Snapshots einer virtuellen Maschine führt möglicherweise dazu, dass der MOB-Wert des currentSnapshot-Felds nicht festgelegt ist
    Nachdem Sie einen Stilllegungs-Snapshot erstellt und den Managed Object Browser (MOB) der virtuellen Maschine durchsucht haben, wird der MOB-Wert des currentSnapshot-Felds als nicht festgelegt angezeigt. Um das currentSnapshot-Feld anzuzeigen, navigieren Sie zu „Inhalt -> Root-Ordner -> Datencenter -> vmFolder -> vmname -> Snapshot -> currentSnaphot.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Mehrere opID-Tagging-Protokollmeldungen werden in kurzer Zeit in das VMkernel-Protokoll geschrieben
    Beim Helper World opID-Tagging werden viele Protokollmeldungen generiert, die in kurzer Zeit in das VMkernel-Protokoll geschrieben werden und das Protokoll auffüllen. Im VMkernel-Protokoll werden Einträge ähnlich dem Folgenden protokolliert:

    cpu16:nnnnn)World: nnnnn: VC opID hostd-60f4 maps to vmkernel opID nnnnnnnn cpu16:nnnnn)World: nnnnn: VC opID HB-host-nnn@nnn-nnnnnnn-nn maps to vmkernel opID nnnnnnnn cpu8:nnnnn)World: nnnnn: VC opID SWI-nnnnnnnn maps to vmkernel opID nnnnnnnn cpu14:nnnnn)World: nnnnn: VC opID hostd-nnnn maps to vmkernel opID nnnnnnnn cpu22:nnnnn)World: nnnnn: VC opID hostd-nnnn maps to vmkernel opID nnnnnnnn cpu14:nnnnn)World: nnnnn: VC opID hostd-nnnn maps to vmkernel opID nnnnnnnn cpu14:nnnnn)World: nnnnn: VC opID hostd-nnnn maps to vmkernel opID nnnnnnnn cpu4:nnnnn)World: nnnnn: VC opID hostd-nnnn maps to vmkernel opID nnnnnnnn

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Unterstützung für USB 3.0
    In dieser Version wurde die Unterstützung für USB 3.0 hinzugefügt, derzeit jedoch ausschließlich für Apple Mac Pro.

High Availability- und Fault Tolerance-Probleme

Probleme bei vMotion und Storage vMotion

  • Schnelles Anhalten und Fortsetzen oder Storage vMotion kann nicht für vorab zugeordnete virtuelle Maschinen ausgeführt werden
    Wenn Sie das schnelle Anhalten und Fortsetzen (Fast Suspend and Resume, FSR) oder Storage vMotion für vorab zugeordnete virtuelle Maschinen ausführen, schlägt der Vorgang möglicherweise fehl, da die Reservierungsvalidierung während des Reservierungstransfers von der Quell-VM zur Ziel-VM fehlschlägt.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Storage vMotion schlägt auf einer virtuellen Maschine fehl
    Die Ausführung von Storage vMotion auf einer virtuellen Maschine schlägt möglicherweise fehl, wenn Sie die lokale Hostauslagerung konfiguriert und den Wert der Datei checkpoint.cptConfigName in der VMX-Datei festgelegt haben. Es wird u. U. eine Fehlermeldung ähnlich der folgenden angezeigt:

    xxxx-xx-xxT00:xx:xx.808Z| vmx| I120: VMXVmdbVmVmxMigrateGetParam: type: 2 srcIp=<127.0.0.1> dstIp=<127.0.0.1> mid=xxxxxxxxxxxxx uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx priority=none checksumMemory=no maxDowntime=0 encrypted=0 resumeDuringPageIn=no latencyAware=no diskOpFile=
    <snip>
    xxxx-xx-xxT00:xx:xx.812Z| vmx| I120: VMXVmdb_SetMigrationHostLogState: hostlog state transits to failure for migrate 'to' mid xxxxxxxxxxxxxxxx


    Dieses Problem wurde in der vorliegenden Version behoben.
  • Changed Block Tracking (CBT) wird während einer Cold-Migration für virtuelle RDM-Festplatten zurückgesetzt
    Die Cold-Migration zwischen verschiedenen Datenspeichern unterstützt keinen CBT-Reset für virtuelle RDM-Festplatten.

    Dieses Problem wurde in der vorliegenden Version behoben.

Probleme bei VMware Tools

  • Versuche, ein Upgrade von VMware Tools auf einer Windows 2000-VM auszuführen, können fehlschlagen
    Upgrade-Versuche für VMware Tools auf einer virtuellen Maschine unter Windows 2000 schlagen möglicherweise mit einer Fehlermeldung ähnlich der Folgenden fehl, die in die Datei vmmsi.log geschrieben wird:

    Invoking remote custom action. DLL: C:\WINNT\Installer\MSI12.tmp, Entrypoint: VMRun
    VM_CacheMod. Return value 3.
    PROPERTY CHANGE: Deleting RESUME property. Its current value is '1'.
    INSTALL. Return value 3.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Einige Treiber funktionieren möglicherweise nicht wie erwartet auf einer virtuellen Maschine unter Solaris 11
    Auf einem ESXi 5.5-Host stammen einige der unter dem Gastbetriebssystem Solaris 11 installierten Treiber möglicherweise von Solaris 10. Daher funktionieren sie unter Umständen nicht wie erwartet.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Beim Versuch, für VMware Tools einen neuen Kernel zu konfigurieren, wird möglicherweise die Liste mit den Treibern im Eintrag „add_drivers“ abgeschnitten
    Wenn Sie versuchen, für VMware Tools einen neuen Kernel mithilfe des /usr/bin/vmware-config-tools.pl -k <kernel version>-Skripts zu konfigurieren, nachdem der Kernel mit Dracut aktualisiert wurde, wird möglicherweise die Liste mit den Treibern im Eintrag add_drivers der Datei /etc/dracut.conf.d/vmware-tools.conf abgeschnitten. Dieses Problem tritt auf, wenn VMware Tools im Kernel hochgestreamt werden.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Telnet kann nach Installation von VMware Tools unter den Betriebssystemen Windows 8 oder Windows Server 2012 nicht geöffnet werden
    Nach dem Installieren von VMware Tools unter den Gastbetriebssystemen Windows 8 oder Windows Server 2012 schlagen Versuche, telnet mit dem Befehl start telnet://xx.xx.xx.xx aufzurufen, mit der folgenden Fehlermeldung fehl:

    Make sure the virtual machine's configuration allows the guest to open host applications

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die Ereignisanzeige des Gastbetriebssystems zeigt Warnmeldungen, nachdem Sie VMware Tools installiert haben
    Nachdem Sie VMware Tools installiert haben, zeigen einige Plug-Ins möglicherweise eine Warnmeldung in der Windows-Ereignisanzeige, wenn Sie versuchen, einen RDP auf eine virtuelle Maschine unter Windows durchzuführen. Die Warnmeldung gibt an, dass keine Remoteprozeduraufrufe (Remote Procedure Calls, RPCs) an den Host gesendet werden können.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Der VMware Tools-Dienst schlägt während des Herunterfahrens auf einer virtuellen Linux-Maschine möglicherweise fehl
    Auf einer virtuellen Linux-Maschine schlägt der VMware Tools-Dienst vmtoolsd möglicherweise fehl, wenn Sie das Gastbetriebssystem herunterfahren.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Automatisches Upgrade von VMware Tools schlägt beim erstmaligen Einschalten der virtuellen Maschine möglicherweise fehl
    Wenn eine virtuelle Maschine mit Gastanpassung bereitgestellt oder geklont wird und die Aktualisierungsrichtlinie von VMware Tools so festgelegt ist, dass sie ein automatisches Upgrade von VMware Tools beim nächsten Einschalten der virtuellen Maschine zulässt, schlägt das automatische Upgrade von VMware Tools möglicherweise fehl, wenn die virtuelle Maschine erstmalig eingeschaltet wird.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Stilllegungsvorgänge können dazu führen, dass eine virtuelle Maschine abstürzt
    Versuche, einen stillgelegten Snapshot auf einer virtuellen Maschine mit Microsoft Windows 2008 oder später auszuführen, schlagen möglicherweise fehl und die VM löst möglicherweise einen Notfallalarm mit einem blauen Bildschirm und einer Fehlermeldung ähnlich der folgenden aus:

    A problem has been detected and Windows has been shut down to prevent damage to your computer. If this is the first time you've seen this Stop error screen restart your computer. If this screen appears again, follow these steps:

    Disable or uninstall any anti-virus, disk defragmentation or backup utilities. Check your hard drive configuration, and check for any updated drivers. Run CHKDSK /F to check for hard drive corruption, and then restart your computer.


    Weitere Informationen finden Sie im Knowledgebase-Artikel 2115997.

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Die virtuelle Maschine antwortet nach einem Snapshot-Vorgang auf einer Linux-VM möglicherweise nicht
    Wenn Sie versuchen, einen Stilllegungs-Snapshot einer virtuellen Linux-Maschine zu erstellen, schlägt die VM nach dem Snapshot-Vorgang möglicherweise fehl und erfordert einen Neustart. Fehlermeldungen ähnlich der folgenden werden in die Protokolldatei vmware.log geschrieben:

    TZ| vmx| I120: SnapshotVMXTakeSnapshotComplete: done with snapshot 'smvi_UUID': 0
    TZ| vmx| I120: SnapshotVMXTakeSnapshotComplete: Snapshot 0 failed: Failed to quiesce the virtual machine (40).
    TZ| vmx| I120: GuestRpcSendTimedOut: message to toolbox timed out.
    TZ| vmx| I120: Vix: [18631 guestCommands.c:1926]: Error VIX_E_TOOLS_NOT_RUNNING in
    MAutomationTranslateGuestRpcError(): VMware Tools are not running in the guest


    Weitere Details finden Sie im Knowledgebase-Artikel 2116120

    Dieses Problem wurde in der vorliegenden Version behoben.
  • Neues Problem Versuche, eine Snapshot-Konsolidierung durchzuführen, schlagen möglicherweise mit folgender Fehlermeldung fehl: Unerwartetes Signal: 11
    Das Konsolidieren oder Löschen eines Snapshots führt möglicherweise dazu, dass die auf VMware ESXi 5.5 Update 3-Hosts ausgeführten virtuellen Maschinen mit folgender Fehlermeldung fehlschlagen: Unerwartetes Signal: 11. Es wird in der Protokolldatei vmware.log eine Protokollmeldung ähnlich der Folgenden angezeigt:

    [YYYY-MM-DD] <time>Z| vcpu-0| I120: SNAPSHOT: SnapshotDiskTreeFind: Detected node change from 'scsiX:X' to ''.

    Weitere Details finden Sie im Knowledgebase-Artikel 2133118.

    Dieses Problem wurde in der vorliegenden Version behoben.

Bekannte Probleme

Die bekannten in ESXi 5.5 vorhandenen Probleme werden wie folgt gruppiert:

Neue bekannte Probleme, die in dieser Version dokumentiert werden, werden als Neues Problem hervorgehoben.

Upgrade- und Installationsprobleme

  • Aktualisiert Durch die Aktualisierung von VMware vCenter Server 5.5 auf 5.5 U2 oder höher wird die maximale JVM-Arbeitsspeicher-Heap-Größe reduziert
    Versuche, VMware vCenter Server 5.5 auf 5.5 U2 oder höher zu aktualisieren, verringert die maximale Heap-Größe des JVM-Arbeitsspeichers. Grund ist ein Patch für die Datei wrapper.conf, mit dem die Datei für den VMware Inventory-Dienst, den profilgesteuerten Speicherdienst von VMware und VMware VirtualCenter Web Management mit Standardwerten überschrieben wird. Weitere Details finden Sie im Knowledgebase-Artikel 2114669.

    Problemumgehung: Um dieses Problem zu beheben, ändern Sie die maximale JVM-Arbeitsspeicher-Heap-Größe anhand der Größe der vCenter Server-Bestandsliste.

  • Neues Problem Die Benutzerprozesse des VMware Tools-Diensts werden nach der Installation des neuesten VMware Tools-Pakets möglicherweise nicht unter dem Linux-Betriebssystem ausgeführt
    Unter dem Linux-Betriebssystem treten möglicherweise Upgrade- oder Installationsprobleme mit VMware Tools auf oder die Benutzerprozesse des VMware Tools-Diensts (vmtoolsd) werden möglicherweise nach der Installation des neuesten VMware Tools-Pakets nicht ausgeführt. Dieses Problem tritt auf, wenn Sie eine ältere glibc-Version als Version 2.5 verwenden, wie beispielsweise SLES10sp4.

    Problemumgehung: Führen Sie ein Upgrade von Linux-glibc auf Version 2.5 oder höher durch.

  • Versuche, alle Image-Profile bei der Ausführung des Get-EsxImageProfile-Befehls in vSphere PowerCLI abzurufen, schlagen möglicherweise fehl
    Wenn Sie den Get-EsxImageProfile-Befehl mit vSphere PowerCLI ausführen, um alle Image-Profile abzurufen, wird ein Fehler ähnlich dem Folgenden angezeigt:

    PowerCLI C:\Windows\system32> Get-EsxImageProfile
    Get-EsxImageProfile : Der Parameter 'name' darf keine leere Zeichenfolge sein.
    Parametername: name
    At line:1 char:20
    + Get-EsxImageProfile <<<<
    + CategoryInfo : NotSpecified: (:) [Get-EsxImageProfile], ArgumentException
    + FullyQualifiedErrorId : System.ArgumentException,VMware.ImageBuilder.Commands.GetProfiles


    Problemumgehung: Führen Sie den Befehl Get-EsxImageProfile -name "ESXi-5.x*" aus, der die Option -name enthält und alle während der PowerCLI-Sitzung erstellten Image-Profile anzeigt.

    Beispiel: Beim Ausführen des Befehls Get-EsxImageProfile -name "ESXi-5.5.*" werden alle 5.5-Image-Profile ähnlich dem folgenden angezeigt:

    PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> Get-EsxmageProfile -name "ESXi-5.5.*"

    Name Vendor Last Modified Acceptance Level
    ---- ------ ------------- ----------------
    ESXi-5.5.0-20140701001s-no-... VMware, Inc. 8/23/2014 6:... PartnerSupported
    ESXi-5.5.0-20140302001-no-t... VMware, Inc. 8/23/2014 6:... PartnerSupported
    ESXi-5.5.0-20140604001-no-t... VMware, Inc. 8/23/2014 6:... PartnerSupported
    ESXi-5.5.0-20140401020s-sta... VMware, Inc. 8/23/2014 6:... PartnerSupported
    ESXi-5.5.0-20131201001s-sta... VMware, Inc. 8/23/2014 6:... PartnerSupported
  • Die einfache Installation schlägt unter Windows Server 2012 fehl
    Die einfache Installation schlägt unter Windows Server 2012 fehl, wenn das Betriebssystem eine per DHCP zugewiesene IP-Adresse verwendet.

    Problemumgehung: Konfigurieren Sie Windows 2012 Server so, dass eine statische IP-Adresse verwendet wird.

  • Wenn die Beibehaltung von VMFS in Kombination mit Auto Deploy für statusfreies Caching oder statusorientierte Installationen verwendet wird, wird keine Core-Dump-Partition erstellt
    Wenn Sie Auto Deploy für statusfreies Caching oder statusorientierte Installationen auf einer leeren Festplatte verwenden, wird eine MSDOS-Partitionstabelle erstellt. Eine Core-Dump-Partition wird jedoch nicht erstellt.

    Problemumgehung: Wenn Sie die Option für statusfreies Caching oder statusorientierte Installationen in Hostprofilen aktivieren, wählen Sie VMFS überschreiben aus, selbst wenn Sie die Installation auf einer leeren Festplatte durchführen. Dadurch wird eine Core-Dump-Partition mit 2,5 GB erstellt.

  • Während der Skriptinstallation wird ESXi auf einer SSD-Festplatte installiert, obwohl die Option "--ignoressd" für den Befehl "installorupgrade" verwendet wird
    In ESXi 5.5 wird die Option --ignoressd nicht für den Befehl installorupgrade unterstützt. Falls Sie die Option --ignoressd mit dem Befehl installorupgrade verwenden, zeigt das Installationsprogramm eine Warnmeldung an, dass es sich um eine ungültige Kombination handelt. Das Installationsprogramm installiert ESXi jedoch weiterhin auf der SSD, anstatt die Installation abzubrechen und eine Fehlermeldung anzuzeigen.

    Problemumgehung: Verwenden Sie den Befehl install anstelle des Befehls installorupgrade, um die Option --ignoressd in einer Skriptinstallation von ESXi zu verwenden.

  • Durch die Verzögerung beim Löschen des Auto Deploy-Cache wird möglicherweise ein gelöschtes Hostprofil angewendet
    Nachdem ein Hostprofil gelöscht wurde, wird es nach einer Weile aus dem Auto Deploy-Cache gelöscht. Solange das Hostprofil im Cache vorhanden ist, wendet Auto Deploy dieses Hostprofil an. Alle Regeln, die das Profil anwenden, schlagen erst dann fehl, wenn das Profil aus dem Cache gelöscht wird.

    Problemumgehung: Mithilfe des PowerCLI-Cmdlets Get-DeployRuleSet können Sie ermitteln, ob es Regeln gibt, die gelöschte Hostprofile verwenden. Das Cmdlet zeigt in der itemlist der Regel die Zeichenfolge deleted. Anschließend können Sie das Cmdlet Remove-DeployRule ausführen, um diese Regel zu entfernen.

  • 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

    Problemumgehung: Wählen Sie eine andere Festplatte für die Verwendung des statusfreien Cachings aus oder entfernen Sie die ESX-Software von der Festplatte. Wenn Sie die ESX-Software entfernen, ist sie nicht mehr verfügbar.

  • Die Installation oder der Start von ESXi 5.5.0 schlägt auf Servern von Oracle America (Sun)-Herstellern fehl
    Wenn Sie auf Servern von Oracle America (Sun)-Herstellern eine Neuinstallation von ESXi 5.5.0 durchführen oder eine vorhandene ESXi 5.5.0-Installation starten, zeigt die Serverkonsole während des Installationsvorgangs oder beim Starten des vorhandenen ESXi 5.5.0-Builds einen leeren Bildschirm an. Dies ist darauf zurückzuführen, dass für Server von Oracle America (SUN)-Herstellern das Flag HEADLESS in der Tabelle ACPI FADT gesetzt wurde, obwohl es sich dabei nicht um monitorlos laufende Plattformen handelt.

    Problemumgehung: Übergeben Sie beim Installieren oder Starten von ESXi 5.5.0 die Startoption ignoreHeadless="TRUE".

  • Bei Verwendung der ESXCLI-Befehle für das Upgrade eines ESXi-Hosts mit weniger als 4 GB physischem RAM ist das Upgrade zwar erfolgreich, aber beim Neustart schlagen einige ESXi-Vorgänge fehl
    ESXi 5.5 benötigt mindestens 4 GB an physischem RAM. Das ESXCLI-Befehlszeilentool prüft vor dem Upgrade nicht, ob die erforderlichen 4 GB Arbeitsspeicher vorhanden sind. Mit ESXCLI führen Sie zwar das Upgrade eines Hosts mit zu wenig Arbeitsspeicher erfolgreich durch, aber wenn Sie den aktualisierten ESXi 5.5-Host mit weniger als 4 GB Arbeitsspeicher starten, schlagen einige Vorgänge möglicherweise fehl.

    Problemumgehung: Keine. Stellen Sie sicher, dass auf dem ESXi-Host mindestens 4 GB an physischem RAM vorhanden sind, bevor Sie mit dem Upgrade auf Version 5.5 fortfahren.

  • Nach der Durchführung eines Upgrades von vCenter Server Appliance 5.0.x auf 5.5 schlägt der Start vCenter Server fehl, wenn eine externe vCenter Single Sign-On-Instanz verwendet wird
    Wenn der Benutzer eine externe vCenter Single Sign-On-Instanz verwenden will, während er das Upgrade der vCenter Server Appliance von 5.0.x auf 5.5 durchführt, schlägt der Start des vCenter Server nach dem Upgrade fehl. In der Appliance-Verwaltungsschnittstelle ist die vCenter Single Sign-On-Instanz als nicht konfiguriert aufgelistet.

    Problemumgehung: Führen Sie die folgenden Schritte aus:

    1. Öffnen Sie die vCenter Server Appliance-Verwaltungsschnittstelle in einem Webbrowser (https://Appliance-Adresse:5480).
    2. Klicken Sie auf der Seite "vCenter Server/Übersicht" auf die Schaltfläche Server anhalten.
    3. Füllen Sie auf der vCenter Server/SSO-Seite das Formular mit den entsprechenden Einstellungen aus und klicken Sie auf Einstellungen speichern.
    4. Kehren Sie zur Übersichtsseite zurück und klicken Sie auf Server starten.

  • Beim Upgrade eines ESXi-Hosts der Version 4.x oder 5.0.x auf Version 5.1 oder 5.5 mithilfe von ESXCLI gehen die Einstellungen für vMotion und die Fault Tolerance-Protokollierung (FT Logging) aller VMkernel-Portgruppen nach dem Upgrade verloren
    Wenn Sie den Befehl esxcli software profile update <Optionen> für das Upgrade eines ESXi-Hosts der Version 4.x oder 5.0.x auf Version 5.1 oder 5.5 verwenden, ist zwar das Upgrade erfolgreich, aber die Einstellungen für vMotion und die Fault Tolerance-Protokollierung aller VMkernel-Portgruppen gehen verloren. Deshalb wird für vMotion und die Fault Tolerance-Protokollierung die Standardeinstellung (Deaktiviert) wiederhergestellt.

    Problemumgehung: Führen Sie ein interaktives oder skriptbasiertes Upgrade durch, oder verwenden Sie vSphere Update Manager für das Upgrade der Hosts. Wenn Sie den Befehl esxcli verwenden, müssen Sie die Einstellungen für vMotion und die Fault Tolerance-Protokollierung nach dem Upgrade manuell auf die betroffene VMkernel-Portgruppe anwenden.

  • Beim Upgrade von vSphere 5.0.x oder früher auf Version 5.5 werden die manuell festgelegten Werte für die Zuteilung von Systemressourcen auf den Standardwert zurückgesetzt
    In vSphere 5.0.x und früher müssen Einstellungen in der Benutzeroberfläche für die Zuteilung von Systemressourcen als vorübergehende Umgehung des Problems geändert werden. Diese Einstellungen können nicht auf den Standardwert zurückgesetzt werden, ohne ESXi neu zu installieren. In vSphere 5.1 und höher wird das Systemverhalten geändert, sodass die Beibehaltung von benutzerdefinierten Einstellungen für die Zuteilung von Systemressourcen Werte ergeben könnte, deren Verwendung nicht sicher ist. Beim Upgrade werden all diese Werte zurückgesetzt.

    Problemumgehung: Keine.

  • IPv6-Einstellungen der virtuellen Netzwerkschnittstellenkarte vmk0 werden nach dem Upgrade von ESX 4.x auf ESXi 5.5 nicht beibehalten
    Wenn für einen ESX 4.x-Host mit aktivierter IPv6-Adresse ein Upgrade auf ESXi 5.5 mithilfe der Option --forcemigrate durchgeführt wird, wird die IPv6-Adresse der virtuellen Netzwerkschnittstellenkarte (NIC) vmk0 nach dem Upgrade nicht beibehalten.

    Problemumgehung: Keine.

Netzwerkprobleme

  • Verwendung von PCNet32-Netzwerkadapter mit opakem NSX-Netzwerk nicht möglich
    Wenn der flexible PCNet32-Netzwerkadapter mit der opaken NSX-Netzwerksicherung konfiguriert ist, bricht die Verbindung zum Adapter beim Einschalten der VM ab.
  • Problemumgehung: Keine

  • Beim Upgrade auf ESXi 5.5 wird die IGMP-Konfiguration des TCP/IP-Stacks für die Verwaltung von Multicast-Gruppen möglicherweise geändert
    Die Standard-IGMP-Version der Verwaltungsschnittstellen wird für ESXi 5.5-Hosts für die Verwaltung von Multicast-Gruppen von IGMP V2 in IGMP V3 geändert. Dies führt dazu, dass die Verwaltungsschnittstelle beim Upgrade auf ESXi 5.5 möglicherweise von IGMP V3 auf IGMP V2 zurückgesetzt wird, wenn sie eine IGMP-Abfrage einer früheren Version erhält, und Fehlermeldungen über nicht übereinstimmende IGMP-Versionen angezeigt werden.

    Problemumgehung: Bearbeiten Sie die IGMP-Standardversion, indem Sie das IGMP-Intervall für den erneuten Beitritt unter Verwendung der Option Erweiterte Konfiguration für TCP/IP ändern.
  • Statische Routen, die vmknic-Schnittstellen und dynamischen IP-Adressen zugeordnet sind, werden nach einem Neustart möglicherweise nicht angezeigt
    Nach einem Neustart des Hosts werden statische Routen, die der VMkernel-Netzwerkschnittstelle (vmknic) und dynamischen IP-Adressen zugeordnet sind, möglicherweise nicht angezeigt.
    Dieses Problem entsteht durch eine Racebedingung zwischen dem DHCP-Client und dem Befehl zum Wiederherstellen von Routen. Der DHCP-Client kann das Abrufen einer IP-Adresse für vmknics möglicherweise nicht abschließen, wenn der Host während des Neustarts versucht, benutzerdefinierte Routen wiederherzustellen. Deshalb wird das Gateway möglicherweise nicht eingerichtet, und die Routen werden nicht wiederhergestellt.

    Problemumgehung: Führen Sie den Befehl esxcfg-route –r aus, um die Routen manuell wiederherzustellen.
  • Ein ESXi-Host reagiert nicht mehr, nachdem er über seine IPv6-Adresse zu vCenter Server hinzugefügt wurde
    Wenn Sie einen ESXi-Host über seine verbindungslokale IPv6-Adresse im Format fe80::/64 zu vCenter Server hinzugefügt haben, wird der Hostname nach kurzer Zeit abgeblendet und reagiert nicht mehr auf vCenter Server.

    Problemumgehung: Verwenden Sie eine gültige IPv6-Adresse, bei der es sich nicht um eine verbindungslokale Adresse handelt.

  • Es wird keine Fehlermeldung angezeigt, obwohl Sie in vSphere Web Client mehr virtuelle Funktionen konfigurieren können, als von der physischen Netzwerkkarte unterstützt werden
    In den SR-IOV-Einstellungen eines physischen Adapters können Sie mehr virtuelle Funktionen konfigurieren, als vom Adapter unterstützt werden. Beispielsweise können Sie 100 virtuelle Funktionen für eine Netzwerkkarte konfigurieren, die nur 23 virtuelle Funktionen unterstützt, und es wird dennoch keine Fehlermeldung angezeigt. Sie werden in einer Meldung aufgefordert, den Host neu zu starten, damit die SR-IOV-Einstellungen angewendet werden. Nach dem Neustart des Hosts ist für die Netzwerkschnittstellenkarte die vom Adapter unterstützte Anzahl von virtuellen Funktionen konfiguriert. In diesem Beispiel sind dies 23 virtuelle Funktionen. Die Meldung, in der Sie zum Neustart des Hosts aufgefordert werden, wird weiterhin angezeigt, obwohl dies nicht der Fall sein sollte.

    Problemumgehung: Keine

  • Auf einem SR-IOV-fähigen ESXi-Host können virtuellen Funktionen zugeordnete virtuelle Maschinen möglicherweise nicht gestartet werden
    Wenn SR-IOV auf einem ESXi 5.1-Host oder höher mit Intel ixgbe-Netzwerkkarten aktiviert ist und in der Umgebung verschiedene virtuelle Funktionen aktiviert sind, werden einige virtuelle Maschinen möglicherweise nicht gestartet.
    Die Datei vmware.log enthält Meldungen, die so oder ähnlich lauten:
    2013-02-28T07:06:31.863Z| vcpu-1| I120: Msg_Post: Error
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.log.error.unrecoverable] VMware ESX unrecoverable error: (vcpu-1)
    2013-02-28T07:06:31.863Z| vcpu-1| I120+ PCIPassthruChangeIntrSettings: 0a:17.3 failed to register interrupt (error code 195887110)
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.haveLog] A log file is available in "/vmfs/volumes/5122262e-ab950f8e-cd4f-b8ac6f917d68/VMLibRoot/VMLib-RHEL6.2-64-HW7-default-3-2-1361954882/vmwar
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.requestSupport.withoutLog] You can request support.
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.requestSupport.vmSupport.vmx86]
    2013-02-28T07:06:31.863Z| vcpu-1| I120+ To collect data to submit to VMware technical support, run "vm-support".
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.response] We will respond on the basis of your support entitlement.

    Problemumgehung: Verringern Sie die Anzahl der virtuellen Funktionen, die der betroffenen virtuellen Maschine zugeordnet sind, bevor Sie die VM starten.

  • Auf einem physischen Emulex BladeEngine 3-Netzwerkadapter kann ein durch eine virtuelle Funktion unterstützter VM-Netzwerkadapter einen VMkernel-Adapter nicht erreichen, der die physische Funktion als Uplink verwendet
    Datenverkehr wird nicht zwischen einer virtuellen Funktion und der zugehörigen physischen Funktion übertragen. Beispielsweise kann auf einem durch die physische Funktion unterstützten Switch eine virtuelle Maschine, die eine virtuelle Funktion auf demselben Port verwendet, einen VMkernel-Adapter auf demselben Switch nicht kontaktieren. Dies ist ein bekanntes Problem bei den physischen Emulex BladeEngine 3-Adaptern. Weitere Informationen erhalten Sie von Emulex.

    Problemumgehung: Deaktivieren Sie den systemeigenen Treiber für Emulex BladeEngine 3-Geräte auf dem Host. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 2044993.

  • ESXi Dump Collector kann die ESXi-Kerndatei nicht an den Remoteserver senden
    ESXi Dump Collector kann die ESXi-Kerndatei nicht senden, falls für den VMkernel-Adapter, der den Datenverkehr des Dump Collector verarbeitet, eine verteilte Portgruppe konfiguriert ist, für die eine Linkzusammenfassungsgruppe (LAG) als aktiver Uplink festgelegt ist. Auf dem physischen Switch ist ein LACP-Portkanal konfiguriert.

    Problemumgehung: Führen Sie eine der folgenden Problemumgehungen durch:

    • Verwenden Sie einen vSphere Standard-Switch zum Konfigurieren des VMkernel-Adapters, der den Datenverkehr für den ESXi Dump Collector mit dem Remoteserver verarbeitet.
    • Verwenden Sie eigenständige Uplinks für den Datenverkehr der verteilten Portgruppe, in welcher der VMkernel-Adapter konfiguriert ist.
  • Wenn Sie mithilfe von vSphere Client die Anzahl der Ports eines vSphere Standard Switch oder vSphere Distributed Switch auf einem Host ändern, wird die Änderung selbst nach einem Neustart nicht wirksam
    Wenn Sie mithilfe von vSphere Client die Anzahl der Ports eines vSphere Standard Switch oder vSphere Distributed Switch auf einem ESXi 5.5-Host ändern, wird die Portanzahl selbst nach einem Neustart nicht geändert.

    Beim Neustart eines Hosts mit ESXi 5.5 werden die Ports der virtuellen Switches dynamisch hoch- oder herunterskaliert. Die Anzahl der Ports orientiert sich an der Anzahl der virtuellen Maschinen, die auf dem Host ausgeführt werden können. Auf Hosts dieser Art müssen Sie die Anzahl der Switch-Ports nicht selbst konfigurieren.

    Problemumgehung: Keine in vSphere Client.

Serverkonfigurationsprobleme

  • Neues Problem Die Hardware der Netzwerkkarte antwortet möglicherweise nicht mehr und zeigt eine Fehlermeldung an
    Gelegentlich kann es vorkommen, dass die Hardware der Netzwerkkarte unter bestimmten Umständen nicht mehr antwortet und in den Treiberprotokollen die folgende Fehlermeldung angezeigt wird:

    Nicht mehr reagierende Hardware-Einheit erkannt

    Das Problem wurde bei einigen neuen e1000e-Geräten wie 82579, i217, i218 und i219 beobachtet.

    Problemumgehung: Die Hardware der Netzwerkkarte wird nach dem Auftreten des Problems zurückgesetzt.

  • Problem bei der Menünavigation, wenn der Zugriff auf die Benutzerschnittstelle der direkten Konsole (DCUI) über eine serielle Konsole erfolgt
    Wenn der Zugriff auf die Benutzerschnittstelle der direkten Konsole über eine serielle Konsole erfolgt, funktionieren die Aufwärts- und Abwärtspfeile bei der Navigation zum Menü nicht, und der Benutzer wird zwangsweise vom DCUI-Konfigurationsbildschirm abgemeldet.

    Problemumgehung: Stoppen Sie den DCUI-Prozess. Der DCUI-Prozess wird automatisch neu gestartet.

  • Nach einem Upgrade von ESXi-Hosts auf 5.5 Update 2 und anschließenden Änderungen der Hostkonfiguration werden Hostprofile möglicherweise fälschlicherweise als übereinstimmend angezeigt
    Wenn ein ESXi-Host, der mit einem Hostprofil übereinstimmt, auf ESXi 5.5 Update 2 aktualisiert wird und wenn anschließend einige Änderungen an der Hostkonfiguration vorgenommen werden, wird das Profil bei einer erneuten Überprüfung der Übereinstimmung zwischen Host und Hostprofil fälschlicherweise als übereinstimmend gemeldet.

    Problemumgehung:
    • Navigieren Sie im vSphere Client zu dem Hostprofil, bei dem das Problem auftritt, und führen Sie Profil aus Referenzhost aktualisieren aus.
    • Navigieren Sie im vSphere Web Client zu dem Hostprofil, bei dem das Problem auftritt, klicken Sie auf Einstellungen vom Host kopieren, wählen Sie den Host aus, von dem Sie die Konfigurationseinstellungen kopieren möchten, und klicken Sie dann auf OK.
  • Beim vSphere Distributed Switch schlägt die Standardisierung des Hostprofils fehl
    Bei der Anwendung eines Hostprofils mit einem vSphere Distributed Switch können Standardisierungsfehler auftreten, wenn sich eine virtuelle Maschine mit Fault Tolerance auf einem Host, der den Distributed Switch im betreffenden Hostprofil verwendet, im ausgeschalteten Zustand befindet.

    Problemumgehung: Verschieben Sie die ausgeschalteten virtuellen Maschinen auf einen anderen Host, damit das Hostprofil angewendet werden kann.

  • Für das Hostprofil werden Übereinstimmungsfehler zu den Firewalleinstellungen angezeigt, wenn Sie ein ESX 4.0- oder ESX 4.1-Profil auf einen ESXi 5.5.x-Host anwenden
    Wenn Sie ein Hostprofil von einem ESX 4.0- oder ESX 4.1-Host extrahieren und versuchen, es auf einen ESXi 5.5.x-Host anzuwenden, wird das Profil erfolgreich standardisiert. Bei der Übereinstimmungsprüfung werden Fehler zu Firewalleinstellungen gemeldet, wie beispielsweise:

    Regelsatz LDAP nicht gefunden
    Regelsatz LDAPS nicht gefunden
    Regelsatz TSM nicht gefunden
    Regelsatz VCB nicht gefunden
    Regelsatz activeDirectorKerberos nicht gefunden

    Problemumgehung: Es ist keine Umgehung erforderlich. Dies wird erwartet, weil die Firewalleinstellungen für einen ESX 4.0- oder ESX 4.1-Host von denen für einen ESXi 5.5.x-Host abweichen.

  • Änderungen der BIOS-Geräteeinstellungen für einen ESXi-Host führen möglicherweise zu ungültigen Gerätenamen
    Änderungen der BIOS-Geräteeinstellungen für einen ESXi-Host führen möglicherweise zu ungültigen Gerätenamen, wenn die Änderung eine Verschiebung der <segment:bus:device:function>-Werte verursacht, die den Geräten zugeordnet sind. Beispielsweise verschiebt die Aktivierung einer vorher deaktivierten, integrierten Netzwerkkarte möglicherweise die <segment:bus:device:function>-Werte, die anderen PCI-Geräten zugeordnet sind. Dies führt dazu, dass ESXi die diesen Netzwerkkarten zugewiesenen Namen ändert. Anders als bei vorherigen Versionen von ESXi versucht ESXi 5.5 Gerätenamen durch <segment:bus:device:function>-Änderungen zu erhalten, falls das Host-BIOS spezifische Gerätestandortinformationen bereitstellt. Wegen eines Bugs in dieser Funktion werden manchmal ungültige Namen wie "vmhba1" und "vmnic32" generiert.

    Problemumgehung: Ein einmaliger oder zweimaliger Neustart des ESXi-Hosts entfernt möglicherweise die ungültigen Gerätenamen und stellt die ursprünglichen Namen wieder her. Führen Sie keinen ESXi-Host aus, der ungültige Gerätenamen besitzt.

Speicherprobleme

  • ESXi-Hosts mit HBA-Treibern reagieren möglicherweise nicht mehr, wenn die VMFS-Taktsignale für die Datenspeicher ablaufen
    ESXi-Hosts mit HBA-Treibern reagieren möglicherweise nicht mehr, wenn VMFS-Taktsignale für die Datenspeicher mit Fehlermeldungen ähnlich den Folgenden ablaufen:

    mem>2014-05-12T13:34:00.639Z cpu8:1416436)VMW_SATP_ALUA: satp_alua_issueCommandOnPath:651: Path "vmhba2:C0:T1:L10" (UP) command 0xa3 failed with status Timeout. H:0x5 D:0x0 P:0x0 Possible sense data: 0x5 0x20 0x0.2014-05-12T13:34:05.637Z cpu0:33038)VMW_SATP_ALUA: satp_alua_issueCommandOnPath:651: Path "vmhba2:C0:T1:L4" (UP) command 0xa3 failed with status Timeout. H:0x5 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0.

    Dieses Problem tritt bei dem HBA-Treiber auf, wenn eine hohe Festplatten-E/A im Datenspeicher mit dem ESXi-Host verbunden und Multipathing nicht auf der HBA-Ebene, sondern auf der Zielebene aktiviert ist.

    Problemumgehung: Ersetzen Sie den HBA-Treiber durch den neuesten Async-HBA-Treiber.
  • Versuche, Storage vMotion für virtuelle Maschinen mit RDM-Festplatten im Live-Modus durchzuführen, schlagen möglicherweise fehl
    Storage vMotion-Vorgänge für virtuelle Maschinen mit RDM-Festplatten schlagen möglicherweise fehl, und virtuelle Maschinen werden möglicherweise als ausgeschaltet angezeigt. Versuche, die virtuelle Maschine einzuschalten, schlagen mit dem folgenden Fehler fehl:

    Datei konnte nicht gesperrt werden

    Problemumgehung: Keine.
  • Umbenannte Tags werden im Assistenten „VM-Speicherrichtlinie bearbeiten“ als fehlend angezeigt
    Eine Speicherrichtlinie für virtuelle Maschinen kann Regeln basierend auf Datenspeicher-Tags enthalten. Wenn Sie ein Tag umbenennen, wird es von der VM-Speicherrichtlinie, die auf dieses Tag verweist, nicht automatisch aktualisiert und als fehlend angezeigt.

    Problemumgehung: Entfernen Sie das als fehlend gekennzeichnete Tag aus der VM-Speicherrichtlinie und fügen Sie das umbenannte Tag hinzu. Wenden Sie die Speicherrichtlinie auf alle veralteten Elemente an.

  • Virtuelle Maschinen können nicht eingeschaltet werden, wenn für deren Flash-Lesecache eine Blockgröße von 16 KB, 256 KB, 512 KB oder 1024 KB festgelegt ist
    Virtuelle Maschinen, für die der Flash-Lesecache und eine Blockgröße von 16 KB, 256 KB, 512 KB oder 1024 KB konfiguriert sind, können nicht eingeschaltet werden. Der Flash-Lesecache unterstützt eine Cachegröße von mindestens 4 MB und höchstens 200 GB sowie eine Blockgröße von mindestens 4 KB und höchstens 1 MB. Beim Einschalten der virtuellen Maschine schlägt der Vorgang mit folgenden Fehlermeldungen fehl:

    Beim ESX-Host ist ein Fehler beim Einschalten der virtuellen Maschine aufgetreten.

    Das Starten der virtuellen Maschine ist fehlgeschlagen.

    Einschalten des Moduls 'DiskEarly' fehlgeschlagen.

    Die Festplatte 'scsi0:0' konnte nicht konfiguriert werden.

    Mit einer nicht konfigurierten Festplatte kann die virtuelle Maschine nicht eingeschaltet werden. vFlash-Cache kann nicht angehängt werden: msg.vflashcache.error.VFC_FAILURE

    Problemumgehung: Konfigurieren Sie die Größe und die Blockgröße des Flash-Lesecache für die virtuelle Maschine.

    1. Klicken Sie mit der rechten Maustaste auf die virtuelle Maschine und wählen Sie Einstellungen bearbeiten.
    2. Erweitern Sie auf der Registerkarte Virtuelle Hardware die Option Festplatte, um die Festplattenoptionen anzuzeigen.
    3. Klicken Sie neben dem Feld vFlash-Lesecache auf Erweitert.
    4. Erhöhen Sie den Wert für die zu reservierende Cachegröße, oder reduzieren Sie die Blockgröße.
    5. Klicken Sie auf OK, um Ihre Änderungen zu speichern.
  • Benutzerdefinierte Erweiterungen einer gespeicherten Ressourcenpoolstruktur-Datei können in vSphere Web Client nicht geladen werden
    Auf der Hostübersichtsseite wird eine DRS-Fehlermeldung angezeigt.

    Beim Deaktivieren von DRS in vSphere Web Client werden Sie aufgefordert, die Ressourcenpoolstruktur zu speichern, damit sie in Zukunft erneut geladen werden kann. Die Standarderweiterung dieser Datei lautet .snapshot, aber Sie können auch eine andere Erweiterung für diese Datei auswählen. Wenn die Datei eine benutzerdefinierte Erweiterung aufweist, wird sie beim Laden als deaktiviert angezeigt. Dieses Verhalten tritt nur bei OS X auf.

    Problemumgehung: Ändern Sie die Erweiterung in .snapshot, damit die Datei in vSphere Web Client unter OS X geladen werden kann.

  • Auf der Übersichtsseite des Hosts wird eine DRS-Fehlermeldung ausgegeben
    Auf der Übersichtsseite des Hosts wird folgende DRS-Fehlermeldung anzeigt:

    DRS-Ressourceneinstellungen können nicht auf dem Host angewendet werden. Der Vorgang ist im aktuellen Zustand nicht zulässig. Dies kann die Effektivität von DRS erheblich beeinträchtigen.

    Bei manchen Konfigurationen kann aufgrund einer Racebedingung eine Fehlermeldung im Protokoll erstellt werden, die nicht sinnvoll ist und die ignoriert werden kann. Diese Fehlermeldung kann darauf zurückzuführen sein, dass die Registrierung einer virtuellen Maschine zum selben Zeitpunkt aufgehoben wird, zu dem DRS-Ressourceneinstellungen angewendet werden.

    Problemumgehung: Sie können diese Fehlermeldung ignorieren.

  • Die Konfiguration des vFlash-Lesecache für VMDKs mit mehr als 16 TB führt zu einer Fehlermeldung
    Der vFlash-Lesecache unterstützt keine virtuellen Maschinen mit mehr als 16 TB. Konfigurationsversuche derartiger Festplatten schlagen fehl.

    Problemumgehung: Keine

  • Virtuelle Maschinen werden beim Neukonfigurieren der Cachegröße möglicherweise ausgeschaltet
    Wenn Sie den vFlash-Lesecache auf einer virtuellen Maschine falsch konfigurieren, beispielsweise durch Zuweisung eines ungültigen Werts, wird die virtuelle Maschine möglicherweise ausgeschaltet.

    Problemumgehung: Halten Sie sich an die Empfehlungen für die Cachegröße in der Dokumentation zu vSphere Storage.

  • Die Neukonfiguration einer virtuellen Maschine mit aktiviertem vFlash Read Cache kann mit der Fehlermeldung Zeitüberschreitung beim Vorgang fehlschlagen
    Neukonfigurationsvorgänge benötigen sehr viel E/A-Bandbreite. Falls das System stark ausgelastet ist, kann bei derartigen Vorgängen vor dem Abschluss eine Zeitüberschreitung auftreten. Dieses Verhalten kann auch auftreten, wenn auf dem Host LUNs vorhanden sind, die einen APD-Zustand (All Paths Down, keine Pfade verfügbar) aufweisen.

    Problemumgehung: Korrigieren Sie alle APD-Zustände des Hosts und wiederholen Sie den Vorgang mit einer geringeren E/A-Last auf LUN und Host.

  • DRS führt für virtuelle Maschinen mit vFlash-Lesecache aus Gründen des Lastausgleichs keinen vMotion-Vorgang aus
    DRS führt für virtuelle Maschinen mit vFlash-Lesecache aus Gründen des Lastausgleichs keinen vMotion-Vorgang aus.

    Problemumgehung: DRS empfiehlt die Ausführung von vMotion für diese virtuellen Maschinen nur in folgenden obligatorischen Fällen:

    • Zum Evakuieren eines Hosts, für den der Benutzer den Wartungs- oder Standby-Modus angefordert hat
    • Zum Beheben von DRS-Regelverstößen.
    • Die Ressourcennutzung des Hosts weist den Status "Rot" auf.
    • Mindestens ein Host ist überlastet, und der Bedarf der virtuellen Maschine wird nicht erfüllt.
      Hinweis: Sie können optional festlegen, dass DRS diesen Grund ignoriert.
  • Hosts werden in den Standby-Modus versetzt, wenn bei virtuellen Maschinen der aktive Arbeitsspeicher niedrig, aber der belegte Arbeitsspeicher hoch ist
    In ESXi 5.5 gibt es eine Änderung beim Standardverhalten von DPM, um diese Funktion weniger aggressiv zu gestalten. Dadurch kann die Leistungsbeeinträchtigung für virtuelle Maschinen verhindert werden, wenn der aktive Arbeitsspeicher niedrig, aber der belegte Arbeitsspeicher hoch ist. Die Formel für DPM lautet X%*IdleConsumedMemory + active memory. Die Variable X% kann angepasst werden und ist standardmäßig auf 25 % festgelegt.

    Problemumgehung: Sie können auf das aggressive Verhalten von DPM aus früheren Versionen von ESXi zurückgreifen, indem Sie in den erweiterten Optionen PercentIdleMBInMemDemand=0 einstellen.

  • Von DRS initiierte vMotion-Vorgänge schlagen möglicherweise fehl
    In Fällen, in denen DRS für virtuelle Maschinen mit einer vFlash-Lesecache-Reservierung einen vMotion-Vorgang empfiehlt, kann vMotion fehlschlagen, da auf dem Zielhost nicht genügend Arbeitsspeicher (RAM) zum Verwalten der Flash-Lesecache-Reservierung der virtuellen Maschinen vorhanden ist.

    Problemumgehung: Halten Sie sich an die Konfigurationsempfehlungen für den Flash-Lesecache in der Dokumentation zu vSphere Storage.
    Falls vMotion fehlschlägt, führen Sie die folgenden Schritte aus:

    1. Konfigurieren Sie die Blockgröße der virtuellen Maschinen auf dem Zielhost und die eingehenden virtuellen Maschinen neu, um die allgemeine Zielnutzung des VMkernel-Arbeitsspeichers auf dem Zielhost zu reduzieren.
    2. Verschieben Sie die virtuelle Maschine mithilfe von vMotion manuell auf den Zielhost, um sicherzustellen, dass dieses Problem nicht mehr auftritt.
  • Probleme, die während der vFlash-Konfiguration von einzelnen SSD-Geräten auftreten, werden nicht angezeigt
    Die Konfiguration von vFlash-Ressourcen ist eine Aufgabe, die anhand einer Liste von SSD-Geräten ausgeführt wird. Nach Abschluss der Aufgabe für alle Objekte meldet vSphere Web Client die erfolgreiche Durchführung, möglicherweise ohne über eventuelle Probleme bei der Konfiguration einzelner SSD-Geräte zu informieren.

    Problemumgehung: Führen Sie eine der folgenden Aufgaben aus:

    • Doppelklicken Sie im Fenster "Kürzlich bearbeitete Aufgaben" auf die abgeschlossene Aufgabe.
      Etwaige Konfigurationsfehler werden im Abschnitt "Verknüpfte Ereignisse" des Dialogfelds "Aufgabendetails" angezeigt.
    • Sie können auch folgende Schritte ausführen:
      1. Wählen Sie den Host in der Bestandsliste aus.
      2. Klicken Sie auf die Registerkarte Überwachen, und klicken Sie auf Ereignisse.
  • Es können keine SMART-Informationen für Micron PCIe SSDs auf dem ESXi-Host abgerufen werden
    Ihre Versuche, den Befehl esxcli storage core device smart get -d zu verwenden, um Statistiken für das Micron PCIe SSD-Gerät anzuzeigen, schlagen fehl. Die folgende Fehlermeldung wird angezeigt:
    Fehler beim Abrufen von Smart-Parametern: Das Gerät kann nicht geöffnet werden

    Problemumgehung: Keine. In dieser Version werden Micron PCIe-SSDs von diesem Befehl esxcli storage core device smart nicht unterstützt.

  • ESXi wendet den Grenzwert für die Bandbreite, der für eine virtuelle SCSI-Festplatte in der Konfigurationsdatei einer virtuellen Maschine konfiguriert ist, nicht an
    Die Grenzwerte für die Bandbreite und den Durchsatz einer virtuellen SCSI-Festplatte werden mithilfe eines Parametersatzes in der Konfigurationsdatei der virtuellen Maschine (.vmx) konfiguriert. Beispielsweise könnte die Konfigurationsdatei die folgenden Grenzwerte für die virtuelle Festplatte scsi0:0 enthalten:
    sched.scsi0:0.throughputCap = "80IOPS"
    sched.scsi0:0.bandwidthCap = "10MBps"
    sched.scsi0:0.shares = "normal"

    ESXi wendet den Grenzwert sched.scsi0:0.bandwidthCap nicht auf die virtuelle Festplatte scsi0:0 an.

    Problemumgehung: Setzen Sie auf eine frühere Version des Festplatten-E/A-Schedulers zurück, indem Sie den vSphere Web Client oder den Befehl "esxcli system settings advanced set" verwenden.

    • Bearbeiten Sie im vSphere Web Client in der Liste "Erweiterte Systemeinstellungen" für den Host den Parameter Disk.SchedulerWithReservation.
      1. Navigieren Sie zum Host.
      2. Klicken Sie auf der Registerkarte Verwalten auf Einstellungen und wählen Sie Erweiterte Systemeinstellungen.
      3. Suchen Sie den Parameter Disk.SchedulerWithReservation, beispielsweise mithilfe der Textfelder Filter oder Suchen.
      4. Klicken Sie auf Bearbeiten, und legen Sie den Parameter auf "0" fest.
      5. Klicken Sie auf OK.
    • Führen Sie in der ESXi Shell für den Host den folgenden Konsolenbefehl aus:
      esxcli system settings advanced set -o /Disk/SchedulerWithReservation -i=0
  • Bei einer Migration können virtuelle Maschinen mit konfiguriertem Flash-Lesecache nicht aus dem Host entfernt werden, wenn im Cache ein Fehler vorliegt
    Bei virtuellen Maschinen mit konfiguriertem Flash-Lesecache können Migrationsfehler auftreten, wenn der Cache fehlerhaft oder nicht verwendbar ist. Dieser Fehler verhindert die Migration dieser virtuellen Maschinen.

    Problemumgehung:

    1. Konfigurieren Sie die betroffenen virtuellen Maschinen neu und deaktivieren Sie den Cache.
    2. Führen Sie die Migration aus.
    3. Aktivieren Sie den Cache erst nach Abschluss der Migration.

    Sie können die virtuelle Maschine auch erst ab- und dann wieder einschalten, um den Fehler im Cache zu beheben.

  • Sie können das VFFS-Volume nach dem Upgrade eines Hosts von ESXi 5.5 Beta nicht löschen
    Sie können das VFFS-Volume nicht löschen, nachdem für einen Host ein Upgrade von ESXi 5.5 Beta durchgeführt wurde.

    Problemumgehung: Dies tritt nur auf, wenn Sie ein Upgrade von ESXi 5.5 Beta auf ESXi 5.5 durchführen. Installieren Sie ESXi 5.5 anstelle eines Upgrades, um dieses Problem zu vermeiden. Beim Upgrade von ESXi 5.5 Beta löschen Sie das VFFS-Volume vor dem Upgrade.

  • Die erwarteten Verbesserungen der Latenzzeit treten nicht ein, wenn der vFlash-Lesecache auf virtuellen Maschinen mit älteren Windows- und Linux-Gastbetriebssystemen aktiviert ist
    Der vFlash-Lesecache bietet optimale Leistung, wenn die Cache-Größe mit jener des Ziel-Working-Sets übereinstimmt und die Dateisysteme des Gastbetriebssystems mindestens an einer 4-KB-Grenze ausgerichtet sind. Der Flash-Lesecache filtert falsch ausgerichtete Blöcke aus, um die Zwischenspeicherung von Teilblöcken im Cache zu vermeiden. Dieses Verhalten ist typisch, wenn der vFlash-Lesecache für VMDKs von virtuellen Maschinen mit Windows XP sowie Linux-Distributionen vor 2.6. konfiguriert ist. In diesen Fällen tritt eine niedrige Cachezugriffsrate mit einer niedrigen Cache-Belegung auf, die eine Verschwendung der Cachereservierung für diese VMDKs bedeutet. Dieses Verhalten trifft nicht auf virtuelle Maschinen zu, auf denen Windows 7, Windows 2008 oder Linux ab Distribution 2.6 ausgeführt wird. Diese Betriebssysteme richten ihre Dateisysteme an einer 4-KB-Grenze aus, um eine optimale Leistung zu erzielen.

    Problemumgehung: Um die Cachezugriffsrate und die optimale Verwendung der Cachereservierung für jede VMDK zu verbessern, stellen Sie sicher, dass das auf der VMDK installierte Gastbetriebssystem mindestens an einer 4-KB-Grenze ausgerichtet ist.

Virtual SAN

  • Neues Problem Nicht gemountete Virtual SAN-Festplatten und Festplattengruppen werden im vSphere Client im Feld „Betriebsstatus“ als gemountet angezeigt
    Nachdem die Virtual SAN-Festplatten oder -Festplattengruppen mit dem CLI-Befehl esxcli vsan storage diskgroup unmount oder automatisch vom Virtual SAN Device Monitor-Dienst in den nicht gemounteten Zustand versetzt wurden, wird auf der Benutzeroberfläche der vSphere Client UI fälschlicherweise im Feld Betriebsstatus Gemountet angezeigt, wenn die Festplatten ständig hohe Latenzen aufweisen.

    Problemumgehung: Überprüfen Sie das Feld Integrität, das anstatt des Feldes Betriebsstatus einen auf ein Problem hinweisenden Wert anzeigt.
  • Ein ESXi-Host mit mehreren VSAN-Festplattengruppen zeigt die Magnetfestplattenstatistik bei Ausführung des vsan.disks_stats-Befehls möglicherweise nicht an
    Ein ESXi-Host mit mehreren VSAN-Festplattengruppen zeigt die Magnetfestplattenstatistik bei Ausführung des RVC (Ruby vSphere Console)-Befehls vsan.disks_stats möglicherweise nicht an. Der Host zeigt nur die SSD (Solid-State Drive)-Informationen an.

    Problemumgehung: Keine
  • VM-Verzeichnisse enthalten doppelte Auslagerungsdateien (.vswp)
    Dieses Problem tritt möglicherweise auf, wenn die virtuellen Maschinen, die im Virtual SAN ausgeführt werden, nicht ordnungsgemäß heruntergefahren werden und wenn Sie eine Neuinstallation von ESXi und vCenter Server ausführen, ohne die Daten von den Virtual SAN-Festplatten zu löschen. Dies führt dazu, dass alte Auslagerungsdateien (.vswp) sich in den Verzeichnissen für die virtuellen Maschinen befinden, die nicht ordnungsgemäß heruntergefahren wurden.

    Problemumgehung: Keine

  • Versuche, einer Virtual SAN-Festplattengruppe mehr als sieben Magnetfestplatten hinzuzufügen, schlagen möglicherweise mit einer falschen Fehlermeldung fehl
    Virtual SAN-Festplattengruppen unterstützen maximal eine SSD-Festplatte und sieben HDD-Magnetfestplatten. Versuche, eine weitere Magnetfestplatte hinzuzufügen, schlagen möglicherweise mit einer falschen Fehlermeldung ähnlich der folgenden fehl:

    Die Anzahl der Festplatten ist nicht ausreichend.

    Problemumgehung: Keine
  • Erneute Prüfung schlägt beim Hinzufügen einer Virtual SAN-Festplatte fehl
    Wenn Sie eine Virtual SAN-Festplatte hinzufügen, schlägt die erneute Prüfung wegen eines Testfehlers in Bezug auf einen non-Virtual SAN-Datenträger fehl.

    Problemumgehung: Sie können den Fehler ignorieren, da alle Festplatten richtig registriert werden.
  • Ein Festplattenlaufwerk (HDD), das nach dem zugehörigen Solid-State-Laufwerk (SSD) entfernt wird, wird möglicherweise weiterhin als Speicherfestplatte aufgelistet, die von Virtual SAN beansprucht wird
    Wenn zuerst ein SSD- und dann das zugehörige HDD-Laufwerk von einem Virtual SAN-Datenspeicher entfernt wird und Sie den Befehl esxcli vsan storage list ausführen, wird das bereits entfernte HDD-Laufwerk immer noch als von Virtual SAN beanspruchte Speicherfestplatte aufgelistet. Wenn das HDD-Laufwerk anschließend in einen anderen Host eingelegt wird, wird es möglicherweise als Komponente von zwei verschiedenen Hosts angezeigt.

    Problemumgehung: Wenn SSD und HDD beispielsweise aus dem ESXi-Host x entfernt und in den ESXi-Host y eingelegt werden, führen Sie die folgenden Schritte aus, um zu verhindern, dass das HDD-Laufwerk als Komponente von ESXi-Host x und ESXi-Host y angezeigt wird:
    1. Legen Sie die SSD- und HDD-Laufwerke, die aus dem ESXi-Host x entfernt wurden, in den ESXi-Host y ein.
    2. Nehmen Sie das SSD-Laufwerk auf dem ESXi-Host x außer Betrieb.
    3. Führen Sie den Befehl esxcfg-rescan -A aus.
       Die HDD- und SSD-Laufwerke werden nun nicht mehr auf dem ESXi-Host x aufgelistet.
  • Der Abschnitt Arbeiten mit Virtual SAN der vSphere Storage-Dokumentation gibt an, dass die maximale Anzahl der HDD-Festplatten pro Festplattengruppe 6 beträgt. Die maximal zulässige Anzahl von HDD-Festplatten beträgt jedoch 7.
  • Nach einem Fehlschlag in einem Virtual SAN-Cluster meldet vSphere HA möglicherweise mehrere zum Teil irreführende Ereignisse, bevor eine virtuelle Maschine neu gestartet wird
    Der vSphere HA-Master-Agent versucht mehrfach, eine auf Virtual SAN ausgeführte virtuelle Maschine neu zu starten, nachdem sie anscheinend ausgefallen war. Wenn die virtuelle Maschine nicht sofort neu gestartet werden kann, überwacht der Master-Agent den Clusterzustand und unternimmt einen weiteren Versuch, sofern die Bedingungen darauf hindeuten, dass ein Neustart erfolgreich sein könnte. Für virtuelle Maschinen, die auf Virtual SAN ausgeführt werden, verfügt der vSphere HA-Master-Agent über eine spezielle Anwendungslogik, die erkennt, wenn sich die Zugriffsfähigkeit auf Objekte einer virtuellen Maschine möglicherweise geändert hat, und versucht, sie neu zu starten, wenn eine Änderung der Zugriffsfähigkeit wahrscheinlich ist. Der Master-Agent unternimmt einen erneuten Versuch nach jeder möglichen Änderung der Zugriffsfähigkeit sowie in den Fällen, bei denen die virtuelle Maschine nicht erfolgreich eingeschaltet werden konnte und auf die nächste mögliche Änderung der Zugriffsfähigkeit gewartet werden muss.

    Nach jedem gescheiterten Versuch meldet vSphere HA ein Ereignis, das angibt, dass das Failover fehlgeschlagen ist. Nach fünf Fehlschlägen meldet vSphere HA, dass keine weiteren Versuche zum Neustarten der virtuellen Maschine unternommen werden, da die maximale Anzahl der Failover-Versuche erreicht wurde. Selbst nachdem gemeldet wurde, dass der vSphere HA-Master-Agent keine weiteren Versuche unternimmt, wird bei der nächsten möglichen Änderung der Zugriffsfähigkeit dennoch ein weiterer Versuch unternommen.

    Problemumgehung: Keine.

  • Durch das Ausschalten eines Virtual SAN-Hosts wird die Ansicht der Speicheranbieter im vSphere Web Client länger als erwartet aktualisiert
    Wenn Sie einen Virtual SAN-Host ausschalten, wird die Ansicht der Speicheranbieter möglicherweise ohne Inhalt angezeigt. Die Schaltfläche "Aktualisieren" dreht sich weiter, obwohl keine Informationen angezeigt werden.

    Problemumgehung: Warten Sie mindestens 15 Minuten, bis die Ansicht der Speicheranbieter wieder ausgefüllt wird. Die Ansicht wird auch dann aktualisiert, wenn Sie den Host einschalten.

  • Virtual SAN meldet eine fehlgeschlagene Aufgabe als abgeschlossen
    Möglicherweise meldet Virtual SAN bestimmte Aufgaben als abgeschlossen, obwohl sie intern fehlgeschlagen sind.

    Nachfolgend finden Sie Bedingungen und entsprechende Gründe für Fehler:

    • Bedingung: Benutzer versuchen, eine neue Festplattengruppe zu erstellen oder eine neue Festplatte zu einer bereits vorhandenen Festplattengruppe hinzuzufügen, nachdem die Virtual SAN-Lizenz bereits abgelaufen ist.
      Fehlerstapel: Ein allgemeiner Systemfehler ist aufgetreten: Festplatte kann nicht hinzugefügt werden Virtual SAN ist nicht auf diesem Host lizenziert.
    • Bedingung: Benutzer versuchen, eine Festplattengruppe mit einer Anzahl von Platten zu erstellen, die höher als die maximal unterstützte Anzahl ist. Oder sie versuchen, neue Festplatten zu einer bereits vorhandenen Festplattengruppe hinzuzufügen, sodass die Gesamtzahl der Festplatten die unterstützte maximale Anzahl der Festplatten pro Festplattengruppe überschreitet.
      Fehlerstapel: Ein allgemeiner Systemfehler ist aufgetreten: Zu viele Festplatten.
    • Bedingung: Benutzer versuchen, eine Festplatte zur Festplattengruppe mit Fehlern hinzuzufügen.
      Fehlerstapel: Ein allgemeiner Systemfehler ist aufgetreten: Es konnte keine Partitionstabelle erstellt werden.

    Problemumgehung: Nachdem der Grund für einen Fehler identifiziert wurde, beheben Sie diesen und führen Sie die Aufgabe erneut aus.

  • Virtual SAN-Datenspeicher können keine lokalen Host- und Systemauslagerungsdateien speichern
    In der Regel können Sie die System- oder die lokale Hostauslagerungsdatei auf einem Datenspeicher ablegen. Der Virtual SAN-Datenspeicher unterstützt jedoch keine System- oder lokalen Hostauslagerungsdateien. Folglich steht die UI-Option, die es Ihnen ermöglicht, den Virtual SAN-Datenspeicher als Speicherort für die System- bzw. die lokale Hostauslagerungsdatei auszuwählen, nicht zur Verfügung.

    Problemumgehung: Verwenden Sie in einer Virtual SAN-Umgebung andere unterstützte Optionen zum Speichern der lokalen Host- und Systemauslagerungsdateien.

  • Eine Virtual SAN-VM in einem vSphere HA-Cluster wird als vSphere HA-geschützt gemeldet, obwohl sie ausgeschaltet wurde
    Dies kann passieren, wenn Sie eine virtuelle Maschine ausschalten, deren Home-Objekt sich in einem Virtual SAN-Datenspeicher befindet und der Zugriff auf das Objekt nicht möglich ist. Dieses Problem tritt auf, wenn die Wahl eines HA-Master-Agenten erfolgt, nachdem der Zugriff auf das Objekt nicht mehr möglich ist.

    Problemumgehung:

    1. Vergewissern Sie sich, dass auf das Home-Objekt wieder zugegriffen werden kann, indem Sie die Übereinstimmung des Objekts mit der angegebenen Speicherrichtlinie überprüfen.
    2. Schalten Sie die virtuelle Maschine ein und dann wieder aus.

    Der Status ändert sich in "Nicht geschützt".

  • Das VM-Objekt behält den Status "Veraltet" auch dann bei, wenn die Aktion "Neu anwenden" ausgelöst und erfolgreich abgeschlossen wurde
    Wenn Sie aufgrund der neuen Speicheranforderungen das vorhandene Profil einer virtuellen Maschine bearbeiten, erhalten die zugeordneten VM-Objekte (Home oder Festplatte) möglicherweise den Status "Veraltet". Dies passiert, wenn die aktuelle Umgebung keine Neukonfiguration der VM-Objekte unterstützt. Durch Verwendung der Aktion Neu anwenden wird der Status nicht geändert.

    Problemumgehung: Fügen Sie zusätzliche Ressourcen, Hosts oder Festplatten zum Virtual SAN-Cluster hinzu und führen Sie die Aktion Neu anwenden erneut aus.

  • Die automatisch Beanspruchung von Festplatten funktioniert bei Virtual SAN nicht wie erwartet, wenn Sie Virtual SAN nach Aktivieren dieser Funktion lizenzieren
    Wenn Sie Virtual SAN im automatischen Modus aktivieren und anschließend eine Lizenz zuweisen, beansprucht Virtual SAN keine Festplatten.

    Problemumgehung: Ändern Sie den Modus in Manuell und anschließend zurück in Automatisch. Virtual SAN beansprucht dann die Festplatten ordnungsgemäß.

  • vSphere High Availability (HA) kann eine virtuelle Maschine nicht neu starten, wenn das Virtual SAN-Netzwerk partitioniert ist
    Dies tritt auf, wenn Virtual SAN für die Internode-Kommunikation VMkernel-Adapter verwendet, die sich in demselben Subnetz wie andere VMkernel-Adapter eines Clusters befinden. Eine solche Konfiguration kann zu einem Netzwerkausfall führen und die Internode-Kommunikation von Virtual SAN unterbrechen, wohingegen die Internode-Kommunikation von vSphere HA davon nicht berührt wird.

    In dieser Situation erkennt der HA-Master-Agent möglicherweise den Ausfall einer virtuellen Maschine, kann diese aber nicht neu starten. Dieses Problem kann beispielsweise auftreten, wenn der Host, auf dem der Master-Agent ausgeführt wird, keinen Zugriff auf die Objekte der virtuellen Maschine besitzt.

    Problemumgehung: Stellen Sie sicher, dass die von Virtual SAN verwendeten VMkernel-Adapter kein Subnetz gemeinsam mit den VMkernel-Adaptern nutzen, die zu anderen Zwecken verwendet werden.

  • VM-Verzeichnisse enthalten doppelte Auslagerungsdateien (.vswp)   
    Dieses Problem tritt möglicherweise auf, wenn die virtuellen Maschinen, die im Virtual SAN ausgeführt werden, nicht ordnungsgemäß heruntergefahren werden und wenn Sie eine Neuinstallation von ESXi und vCenter Server ausführen, ohne die Daten von den Virtual SAN-Festplatten zu löschen. Dies führt dazu, dass alte Auslagerungsdateien (.vswp) sich in den Verzeichnissen für die virtuellen Maschinen befinden, die nicht ordnungsgemäß heruntergefahren wurden.

    Problemumgehung: Keine

  • Virtuelle Maschinen sind möglicherweise aufgrund hoher Netzwerklatenz nicht mehr verfügbar
    Wenn in einem Virtual SAN-Cluster die Netzwerklatenz hoch ist, ist in vCenter Server möglicherweise kein Zugriff mehr auf einige virtuelle Maschinen möglich und Sie können die virtuellen Maschinen nicht einschalten oder auf sie zugreifen.

    Problemumgehung: Führen Sie den RVC-Befehl vsan.check_state -e -r aus.
  • Bei VM-Vorgängen tritt möglicherweise aufgrund von hoher Netzwerklatenz eine Zeitüberschreitung ein
    Wenn Speichercontroller mit geringen Warteschlangentiefen verwendet werden, kann eine hohe Netzwerklatenz eine Zeitüberschreitung von Vorgängen virtueller Maschinen verursachen.

    Problemumgehung: Wiederholen Sie die Vorgänge, wenn die Netzwerkauslastung geringer ist.
  • Virtuelle Maschinen werden möglicherweise in eine verkürzte Version ihres VMX-Dateipfads umbenannt
    Wenn vorübergehend kein Zugriff auf die VMX-Datei einer virtuellen Maschine möglich ist, wird die virtuelle Maschine in eine verkürzte Version des VMX-Dateipfads umbenannt. Beispiel für die Umbenennung einer virtuellen Maschine: /vmfs/volumes/vsan:52f1686bdcb477cd-8e97188e35b99d2e/236d5552-ad93. Durch das Abschneiden des Dateipfads wird möglicherweise die Hälfte der UUID des Stammverzeichnisses der virtuellen Maschine gelöscht, sodass es schwierig ist, die umbenannte virtuelle Maschine anhand ihres Namens der ursprünglichen virtuellen Maschine zuzuordnen.

    Problemumgehung: Führen Sie den RVC-Befehl vsan.fix_renamed_vms aus.

vCenter Server und vSphere Web Client

  • ESXi-Host kann Active Directory-Domäne nicht hinzugefügt werden
    Beim Versuch, Berechtigungen zuzuweisen, wird der Active Directory-Domänenname möglicherweise nicht in der Dropdown-Liste "Domäne" unter der Option "Benutzer und Gruppen auswählen" angezeigt. Außerdem wird unter der Option "Authentifizierungsdiensteinstellungen" möglicherweise kein vertrauenswürdiger Domänen-Controller angezeigt, selbst wenn Active Directory über vertrauenswürdige Domänen verfügt.

    Problemumgehung:
    1. Starten Sie die netlogond-, lwiod- und lsassd-Daemons neu.
    2. Melden Sie sich über den vSphere Client beim ESXi-Host an.
    3. Klicken Sie auf der Registerkarte Konfiguration auf Authentifizierungsdiensteinstellungen.
    4. Aktualisieren Sie den Bildschirm, um die vertrauenswürdigen Domänen anzuzeigen.

VM-Verwaltungsprobleme

  • Cold-Migration und Storage vMotion können für eine virtuelle Maschine nicht ausgeführt werden, wenn der VMDK-Dateiname mit „core“ beginnt
    Das Ausführen von Cold-Migration und Storage vMotion für eine virtuelle Maschine schlägt mit einer Fehlermeldung ähnlich der Folgenden fehl, wenn der VMDK-Dateiname mit „core“ beginnt:

    Ein allgemeiner Systemfehler ist aufgetreten: Fehler beim Benennen oder Umbenennen einer VM-Datei.

    Möglicherweise werden in der Protokolldatei vpxd.log Fehlermeldungen ähnlich der folgenden angezeigt:

    mem> 2014-01-01T11:08:33.150-08:00 [13512 info 'commonvpxLro' opID=8BA11741-0000095D-86-97] [VpxLRO] -- FINISH task-internal-2471 -- -- VmprovWorkflow --
    mem> 2014-01-01T11:08:33.150-08:00 [13512 info 'Default' opID=8BA11741-0000095D-86-97] [VpxLRO] -- ERROR task-internal-2471 -- -- VmprovWorkflow: vmodl.fault.SystemError:
    mem> --> Result:
    mem> --> (vmodl.fault.SystemError){
    mem> --> dynamicType = ,
    mem> --> faultCause = (vmodl.MethodFault) null,
    mem> --> reason = "Error naming or renaming a VM file.",
    mem> --> msg = "",
    mem> --> }

    Dieses Problem tritt auf, wenn der ESXi-Host VMDK-Dateien mit einem Dateinamen, der mit "core" beginnt, fälschlicherweise als Core-Datei und nicht als den erwarteten Festplattentyp klassifiziert.

    Problemumgehung: Stellen Sie sicher, dass der VMDK-Dateiname der virtuellen Maschine nicht mit "core" beginnt. Verwenden Sie außerdem zum Umbenennen der VMDK-Datei das Dienstprogramm vmkfstools, um sicherzustellen, dass der Dateiname nicht mit dem Wort "core" beginnt.
  • Bei virtuellen Maschinen mit Windows 7 Enterprise 64-Bit-Gastbetriebssystemen in französischer Sprache treten bei Klonvorgängen Probleme auf
    Falls Sie eine geklonte virtuelle Maschine unter einer französischen Version von Windows 7 Enterprise 64-Bit verwenden, wird die virtuelle Maschine vom Netzwerk getrennt und die Anpassungsspezifikation wird nicht angewendet. Dieses Problem tritt auf, wenn die virtuelle Maschine auf einem ESXi 5.1-Host ausgeführt wird, auf ESXi 5.5 geklont wird und die VMware Tools-Version auf die neueste für den ESXi 5.5-Host verfügbare Version aktualisiert wird.

    Problemumgehung: Führen Sie ein Upgrade der Kompatibilität der virtuellen Maschine auf ESXi 5.5 und höher durch, bevor Sie ein Upgrade auf die neueste verfügbare Version von VMware Tools vornehmen.

  • Das Vergrößern einer virtuellen Festplatte für eine ausgeführte virtuelle Maschine schlägt fehl
    Wenn Sie die virtuelle Festplatte vergrößern, während die virtuelle Maschine ausgeführt wird, wird möglicherweise folgende Fehlermeldung angezeigt:

    Der Vorgang wird bei diesem Gerätetyp nicht unterstützt.

    Dieser Fehler kann auftreten, wenn Sie die Festplatte auf über 2 TB vergrößern. Die Erweiterung im laufenden Betrieb unterstützt die Vergrößerung der Festplatte auf maximal 2 TB. Die Erweiterung im laufenden Betrieb wird von virtuellen SATA-Festplatten unabhängig von der Größe nicht unterstützt.

    Problemumgehung: Schalten Sie die virtuelle Maschine aus, um die virtuelle Festplatte auf mindestens 2 TB zu vergrößern.

VMware HA- und Fault Tolerance-Probleme
  • Neues Problem Fault Tolerance (FT) wird für die Plattformen Intel Skylake-DT/S, Broadwell-EP, Broadwell-DT und Broadwell-DE nicht unterstützt
    Für die Plattformen Intel Skylake-DT/S, Broadwell-EP, Broadwell-DT und Broadwell-DE wird Fault Tolerance nicht unterstützt. Versuche, eine virtuelle Maschine einzuschalten, schlagen fehl, nachdem Sie Fault Tolerance für einen einzelnen Prozessor aktiviert haben.

    Problemumgehung: Keine

  • Bei der Auswahl eines ESX/ESXi 4.0-/4.1-Hosts in einem vSphere HA-Cluster für das Failover einer virtuellen Maschine wird die virtuelle Maschine möglicherweise nicht wie erwartet neu gestartet.
    Wenn vSphere HA eine virtuelle Maschine auf einem anderen ESX/ESXi 4.0-/4.1-Host als dem ursprünglichen Host neu startet, wird eine Abfrage ausgestellt, die nicht beantwortet wird. Die virtuelle Maschine wird auf dem neuen Host erst eingeschaltet, nachdem Sie die Abfrage manuell im vSphere Client beantwortet haben.

    Problemumgehung: Beantworten Sie die Abfrage im vSphere Client. Sie können eine Zeitüberschreitung (standardmäßig 15 Minuten) abwarten, nach der vSphere HA versucht, die virtuelle Maschine auf einem anderen Host neu zu starten. Wenn der Host ESX/ESXi Version 5.0 oder höher ausführt, wird die virtuelle Maschine neu gestartet.

  • Wenn ein vMotion-Vorgang ohne gemeinsam genutzten Speicher in einem vSphere HA-Cluster fehlschlägt, kann es sein, dass die virtuelle Zielmaschine auf einem unerwarteten Host registriert wird.
    Eine vMotion-Migration ohne gemeinsam genutzten Speicher kann fehlschlagen, weil die virtuelle Zielmaschine keine Handshakenachricht erhält, mit der die Übertragung der Kontrolle zwischen den beiden virtuellen Maschinen koordiniert wird. Das vMotion-Protokoll schaltet die virtuellen Quell- und Zielmaschinen aus. Wenn sich die Quell- und Zielhosts im selben Cluster befinden und vSphere HA aktiviert wurde, kann es vorkommen, dass die virtuelle Zielmaschine von vSphere HA auf einem anderen Host als dem Host, der als Ziel für die vMotion-Migration ausgewählt wurde, registriert wird.

    Problemumgehung: Wenn Sie die virtuelle Zielmaschine beibehalten und auf einem bestimmten Host registrieren möchten, verlagern Sie die virtuelle Zielmaschine auf den Zielhost. Es empfiehlt sich, diese Verlagerung vor dem Einschalten der virtuellen Maschine vorzunehmen.

Probleme bei unterstützter Hardware
  • Sensorwerte für Lüfter, Stromversorgung, Spannung und aktuelle Sensoren werden in der Gruppe "Andere" der Registerkarte "vCenter Server-Hardwarestatus" angezeigt
    Einige Sensorwerte werden in der Gruppe "Andere" anstatt der entsprechenden kategorisierten Gruppe aufgelistet.

    Problemumgehung: Keine.

  • Fehler bei IOMMU (I/O Memory Management Unit) können entstehen, wenn der Debugging-Mapper von DMA (Direct Memory Access) aktiviert ist
    Der Debugging-Mapper platziert Geräte in IOMMU-Domänen, um Arbeitsspeicherzugriffe von Geräten auf Adressen zu erfassen, die nicht explizit zugeordnet sind. Auf einigen Systemen von HP mit alter Firmware können Fehler bei IOMMU entstehen.

    Problemumgehung: Laden Sie Upgrades der Firmware von der HP-Website herunter und installieren Sie sie.

    • Führen Sie ein Upgrade der Firmware des HP iLO2-Controllers durch.
      Die im August 2011 veröffentlichte Version 2.07 löst das Problem.
    • Führen Sie ein Upgrade der Firmware des HP Smart Array durch.
      Die im Januar 2012 veröffentlichte Version 5.14 löst das Problem für das HP Smart Array P410.

Probleme bei VMware Tools

  • VMware Tools kann auf Linux-Gastbetriebssystemen anhand der Ausführung des Befehls „vmware-install.pl -d“ nicht installiert werden, wenn VMware Tools zuvor nicht installiert wurde
    Wenn VMware Tools nicht auf Ihrem Linux-Gastbetriebssystem installiert ist, schlagen Versuche, eine Erstinstallation von VMware Tools anhand der Ausführung des Befehls vmware-install.pl -d durchzuführen, möglicherweise fehl.
    Dieses Problem tritt bei den folgenden Gastbetriebssystemen auf:
    • RHEL 7 und höher
    • CentOS 7 und höher
    • Oracle Linux 7 und höher
    • Fedora 19 und höher
    • SLES 12 und höher
    • SLED 12 und höher
    • openSUSE 12.2 und höher
    • Ubuntu 14.04 und höher
    • Debian 7 und höher

    Problemumgehung: Zur Zeit gibt es keine Lösung, damit der -default (-d)-Switch funktioniert. Sie können VMware Tools jedoch ohne den - default-Switch installieren.
    Wählen Sie Ja aus, wenn Sie vom Installationsprogramm mit der Option Möchten Sie dennoch mit diesem älteren Installationsprogramm fortfahren? dazu aufgefordert werden.

    Hinweis: In dieser Version wird ein neuer --force-install’(-f)-Switch zur Installation von VMware Tools eingeführt.
  • Datei ist nach Upgrade von VMware Tools nicht mehr vorhanden
    Die Datei deployPkg.dll in C:\Programme\Vmware\Vmware Tools\ wird nach dem Upgrade von VMware Tools nicht gefunden. Dieser Fall tritt bei einem Upgrade von Version 5.1 Update 2 auf Version 5.5 Update 1 oder höher und von Version 5.5 auf Version 5.5 Update 1 oder höher auf.

    Problemumgehung: Keine
  • Bei der Installation oder Deinstallation von VMware Tools mithilfe der betriebssystemspezifischen Pakete (OSPs) wird der Benutzer zwangsweise abgemeldet
    Bei der Installation oder Deinstallation von VMware Tools-Paketen auf virtuellen Maschinen mit RHEL (Red Hat Linux Enterprise) und CentOS, die mit den betriebssystemspezifischen Paketen installiert wurden, wird der aktuelle Benutzer zwangsweise abgemeldet. Dieses Problem tritt bei virtuellen Maschinen mit RHEL 6.5 64-Bit, RHEL 6.5 32-Bit, CentOS 6.5 64-Bit und CentOS 6.5 32-Bit auf.

    Problemumgehung:
    • Verwenden Sie Secure Shell (SSH) zur Installation oder Deinstallation von VMware Tools.
      oder
    • Der Benutzer muss sich erneut anmelden, um die VMware Tools-Pakete zu installieren oder zu deinstallieren.

Sonstige Probleme

  • SRM-Vorgang zur Testwiederherstellung schlägt möglicherweise mit einem Fehler fehl
    Versuche, die SRM (Site Recovery Manager)-Testwiederherstellung durchzuführen, schlagen möglicherweise mit einer Fehlermeldung ähnlich der Folgenden fehl:
    'Fehler - Ein allgemeiner Systemfehler ist aufgetreten: VM nicht gefunden'.
    Wenn mehrere Vorgänge zur Testwiederherstellung gleichzeitig ausgeführt werden, nimmt die Wahrscheinlichkeit der Anzeige von Fehlermeldungen zu.

    Problemumgehung: Keine. Dies ist jedoch kein dauerhaftes Problem und es tritt möglicherweise nicht auf, wenn Sie den Vorgang zur SRM-Testwiederherstellung erneut ausführen.
>