Versionshinweise zu VMware ESX Server 3i, Version 3.5 Update 3 Installable

Kontakt zum Vertrieb

VMware ESX Server 3i Version 3.5 Update 3 Installable | 6. November 2008 | Build 123629

Letzte Dokumentaktualisierung: 08. Dezember 2008

 

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


Diese Versionshinweise decken die folgenden Themen ab:

Hinweis: In vielen öffentlich verfügbaren Dokumenten wird auf VMware ESX Server 3.5 nun mit dem Namen VMware ESX 3.5 Bezug genommen und VMware ESX Server 3i Version 3.5 wird als VMware ESXi 3.5 bezeichnet. Diese Versionshinweise folgen der bisherigen Namenskonvention, damit eine mit den Produktoberflächen und der Dokumentation konsistente Namensgebung vorliegt. In künftigen Versionen werden die Produktnamen aktualisiert.

Neuigkeiten

Sie erhalten nachstehend Informationen zu einigen der wichtigsten Verbesserungen in der vorliegenden Version von VMware Infrastructure 3:

Hinweis: Nicht jede beliebige Kombination der VirtualCenter- und ESX Server-Versionen werden unterstützt. Nicht jede der vorgestellten Funktionen ist verfügbar, es sei denn, Sie verwenden VirtualCenter 2.5 Update 3 mit ESX Server 3i Version 3.5 Installable. Weitere Informationen zur Kompatibilität finden Sie in den Kompatibilitätstabellen für ESX Server, VirtualCenter und VMware Infrastructure-Client.

 

Neue Funktionen und unterstützte E/A-Geräte:

 

  • Erhöhung des vCPU-Grenzwerts pro Core — Der Grenzwert für VCPUs pro Core wurde von 8 (oder 11 für VDI-Arbeitslasten) auf 20 erhöht. Diese Änderung sorgt für eine Erhöhung des unterstützten Grenzwerts, schließt aber zusätzliche Leistungsoptimierungen nicht ein. Die Erhöhung des Grenzwerts bietet Benutzern mehr Flexibilität beim Konfigurieren von Systemen mit bestimmten Arbeitslasten und größtmöglichen Nutzen durch wesentlich schnellere Prozessoren. Die erreichbare Anzahl an VCPUs pro Core hängt von der Arbeitslast und den Spezifikationen der Hardware ab. Die meisten Bereitstellungen sollten mit dem vorherigen Bereich von 8 bis 11 vCPUs pro Core auskommen. Weitere Informationen finden Sie unter VI3 Performance Best Practices and Benchmarking Guidelines.
  • Unterstützung für HP BL495c — Diese Version bietet Unterstützung für HP Blade Server BL495c mit allen Virtual Connect- und E/A-Optionen, die eine 1 oder 10 Gbit-Verbindung zum Netzwerk (upstream) und eine 1 Gbit-Verbindung nur zu den Servern (downstream) ermöglichen.
  • Neu unterstützte NICs— Diese Version unterstützt die folgenden NIC-Controller:
    • Broadcom 5716 1 Gbit
    • Broadcom 57710 10 Gbit-Adapter
    • Broadcom 57711 10 Gbit-Adapter bei nur 1 Gbit Geschwindigkeit
    Hinweis: Die mit diesen Adaptern verfügbaren iSCSI/TOE-Hardware-Offloads werden von ESX Server 3.5 nicht unterstützt.
  • Neu unterstützte SATA Controller — Diese Version unterstützt die folgenden SATA-Controller
    • Broadcom HT1000 (wird nur im systemeigenen SATA-Modus mit SATA-Festplattenlaufwerken und SSD-Geräten unterstützt)
    • Intel ICH-7 (wird nur im IDE/ATA-Modus mit SATA CD oder DVD-Laufwerken unterstützt)
    Hinweis: Das Speichern von VMFS-Datenspeichern auf Laufwerken, die mit diesen Controllern verbunden sind, wird nicht unterstützt
  • Neu unterstützte Gastbetriebssysteme — Folgende zusätzliche Gastbetriebssysteme werden von ESX 3.5 Server Update 3 unterstützt:
    • Ubuntu 8.04.1
    • RHEL 4.7
  • Interne SAS Netzwerkspeicher-Controller — In dieser Version werden Intel Modular Server MFSYS25 SAS Storage Control Modules (SCMs) experimentell unterstützt. Informationen zu bekannten Problemen mit dieser Plattform und zu Umgehungen für die Probleme finden Sie unter Failover bei SAS-Link und Port mit dem Intel Modular Server bei Update 3 und späteren Versionen von ESX 3.5 und ESXi 3.5 (KB 1007394).
  • Interrupt Coalescing (IC) für Qlogic 4 Gbit FC HBAs — Seit dieser Version verringert die Funktion die CPU-Nutzung (und die CPU-Kosten pro E/A) und verbessert den Durchsatz der E/A-intensiven Arbeitslasten, indem ein einzelnes Interrupt für ein Burst von Fibre-Channel-Frames erzeugt wird, wenn diese in einem kurzen Zeitraum empfangen werden, anstatt die CPU jedes Mal zu unterbrechen, wenn ein Frame empfangen wird. Diese Funktion ist standardmäßig aktiviert.
  • CIM-Broker mit geringem Ressourcenverbrauch —  SFCB wurde auf Version 1.3.0 aktualisiert
  • IBM SAN Volume Controller — SVC wird nun mit einer Fixed-Multipathing-Richtlinie sowie mit einer MRU-Multipathing-Richtlinie unterstützt.

Seitenanfang

Vorgängerversionen von VMware Infrastructure 3

Funktionen und bekannte Probleme der Vorgängerversionen von VMware Infrastructure 3, zu denen ESX Server 3i, Version 3.5 und VirtualCenter 2.x-Versionen zählen, werden in den jeweiligen Versionshinweisen beschrieben. Zur Anzeige der Versionshinweise für Vorgängerversionen von VMware Infrastructure 3-Komponenten klicken Sie auf einen der folgenden Links:

Seitenanfang

Bevor Sie beginnen

Hinweis: Wenn Sie diese Version von einer anderen Quelle als dem physischen CD-Medium installieren, finden Sie im Knowledgebase-Artikel Dateinamen mit mehr als 64 Zeichen im ESX Server-ISO-Image können während der Extraktion des Inhalts abgeschnitten werden (KB 1005283) wichtige Informationen zu einem bekannten Installationsproblem.

Kompatibilität von ESX Server, VirtualCenter und VMware Infrastructure-Client

Das Dokument Kompatibilitätstabellen für ESX Server, VirtualCenter und VMware Infrastructure-Client liefert Details zur Kompatibilität aktueller und früherer Versionen von VMware Infrastructure 3-Komponenten, einschließlich ESX Server, VirtualCenter und VI-Client.

Hardwarekompatibilität

Lesen Sie vor der Installation dieser Software die Kompatibilitätshandbücher zu ESX Server. Sie müssen sicherstellen, dass Server, E/A, Speicher, Gastbetriebssystem, Verwaltungsagent und Sicherungssoftware kompatibel sind. In diesen Handbüchern finden Sie ferner Informationen zu den für diese Version geltenden Mindestanforderungen und Skalierungseinschränkungen. Klicken Sie auf einen der folgenden Links, um das entsprechende Handbuch anzuzeigen:

Neu: Dokumentation

Die gesamte Dokumentation für ESX Server 3i Version 3.5 Update 2 Installable gilt auch für ESX Server 3i Version 3.5 Update 3 Installabe. Allerdings beziehen sich die Titelseiten nur auf ESX Server 3i Version 3.5 Update 2 Installable und VirtualCenter 2.5 Update 2. Eine vollständige Liste der Handbücher und zusätzlicher Dokumentation finden Sie in der VMware Infrastructure 3-Dokumentation.

Installation und Upgrade

Im Installationshandbuch finden Sie Schritt-für-Schritt-Anleitungen zur Installation und Konfiguration von ESX Server und VirtualCenter.

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

Upgrade oder Migration auf ESX Server 3i, Version 3.5 Update 3

Diese Version unterstützt die Migration virtueller Maschinen von ESX Server 2.x (und höheren Versionen einschließlich ESX Server 3.0.x) auf ESX Server 3i. Weitere Informationen zu Installations- und Aktualisierungsmethoden finden Sie im Upgrade-Handbuch.

ESX Server 3i Version 3.5 - lizenzfrei

Ab der Update 2-Version von ESX Server 3i Version 3.5 Installable und ESX Server 3i Version 3.5 Embedded können Sie Ihre Software kostenlos herunterladen und lizenzieren. Weitere Informationen zur Verwendung der kostenlosen Lizenz mit der Software finden Sie unter KB 1006481. Beachten Sie, dass die kostenlose Lizenz für vorherige Versionen von ESX Server 3i nicht unterstützt wird.

Seitenanfang

In dieser Version enthaltene Patches

Zusätzlich zu ISO-Images wird ESX Server 3i Version 3.5 Installable Update 3 als Patch verteilt, der auf vorhandene Installationen der ESX Server 3i Version 3.5 Installable-Software aufgespielt werden kann. Dieser Patch kann von der Download-Website für ESX Server 3i-Patches heruntergeladen werden oder unter Verwendung von VMware Update Manager aufgespielt werden. Wenn der Patch von der Website heruntergeladen wird, wird er unter der Bezeichnung ESXe350-200810401-O-UG verteilt. Das Patchpaket ESXe350-200810401-O-UG enthält die folgenden einzelnen Pakete, bei denen es sich um dieselben Pakete handelt, die in VMware Update Manager angezeigt werden:

  • ESXe350-200810401-I-UG: Firmware-Update für ESX Server 3i. Weitere Informationen finden Sie unter KB 1007056.
  • ESXe350-200810402-T-UG: VMware Tools-Update für ESX Server 3i - Weitere Informationen finden Sie unter KB 1007057.
  • ESXe350-200810403-C-UG: VI Client-Update für ESX Server 3i - Dieses Paket synchronisiert den VI-Client mit der neuesten Version von Update 3. Weitere Details hierzu finden Sie unter KB 1007058.

Diese Version enthält zudem alle Patches für die ESX Server-Software, die vor dem Veröffentlichungsdatum dieses Produkts zur Verfügung standen. Weitere Informationen zu den einzelnen Patches finden Sie auf der Download-Website für ESX Server 3i-Patches.

ESX Server 3i Version 3.5 Update 3 Installable enthält zudem alle Fixes in den folgenden bereits veröffentlichten Paketen:

  • ESXe350-200809401-O-SG
  • ESXe350-200808501-O-SG
  • ESXe350-200807812-O-BG
  • ESXe350-200808501-O-SG
  • ESXe350-200804401-O-BG
  • ESXe350-200802401-O-BG
  • ESXe350-200712401-O-BG

Mit ESX Server 3i, Version 3.5 Update 1 Installable veröffentlichtes Paket:

  • ESXe350-200803201-O-UG

Mit ESX Server 3i, Version 3.5 Update 2 Installable veröffentlichtes Paket:

  • ESXe350-200808201-O-UG

Weitere Informationen zu den Inhalten der Patches finden Sie in der Dokumentation, auf die auf der Download-Seite verwiesen wird.

Seitenanfang

Behobene Probleme

 

In dieser Version werden Probleme in den folgenden Bereichen behoben:

Sicherung

  • VirtualCenter zeigt falsche Informationen über VMware Tools an, nachdem der VCB-Befehl für einen Windows 2003-Gast ausgeführt wurde
    Bei Ausführung eines VMware Consolidated Backup (auf Dateiebene oder Komplettsicherung) auf virtuellen Maschinen unter 32-Bit- oder 64-Bit-Windows 2003 wird auf der Registerkarte "Übersicht" von VirtualCenter die Meldung angezeigt, dass VMware Tools nicht ausgeführt wird, obwohl VMware Tools weiterhin aktiv ist. Dieses Problem wurde in der vorliegenden Version behoben.

CIM und API

  • Neu: Die von do_gettimeofday()zurückgegebene Zeit ist nicht korrekt
    Die von do_gettimeofday()zurückgegebene Zeit ist die Anzahl der Sekunden seit dem Start. Der von do_gettimeofday()zurückgegebene Wert sollte die Anzahl der Sekunden seit 1970 sein. Dieses Problem wurde in der vorliegenden Version behoben.
  • Neu: Bei einigen Servern werden die Messungen des PECI-Temperatursensors falsch angezeigt. Falsche Werte werden für Prozessorsensoren im VI-Client und in der Eigenschaft "NominalReading" von CIM_Sensor-Instanzen für CPU PECI tic angezeigt. Dieses Problem wurde in der vorliegenden Version behoben.
  • VMware_Identity benötigt zu viel Zeit zum Zugriff auf große NIS-Datenbanken
    Der CIM_Identity-Provider wurde für diese Version deaktiviert, da das Aufzählen bei der VMware_Identity auf ESX-Systemen, die für den Zugriff auf große NIS-Datenbanken konfiguriert sind, zu lange dauert. Wenn Sie Instanzen von VMware_Identity, VMware_Account, CIM_Identityoder CIM_Accountanfordern, werden keine Instanzen zurückgegeben.
  • Die obligatorischen Eigenschaften MaxReadable, NominalReading, NormalMax, NormalMinund PollingIntervalin der Klasse CIM_NumericSensorzeigen falsche Werte
    Die Instanzen von CIM_NumericSensorverfügen über den folgenden Eigenschaftssatz: MaxReadable, NominalReading, NormalMax, NormalMin. Wenn der tatsächliche Sensor keine Werte dieser Eigenschaften unterstützt, werden die Werte in CIM-Antworten als 0 angezeigt. Dieses Problem wurde in der vorliegenden Version behoben.

Gastbetriebssysteme

  • Das Laden oder die Versionserstellung mit dem vmxnet-Modul schlägt auf 64-Bit-Ubuntu-Gastbetriebssystemen fehl
    Wenn VMware Tools auf 64-Bit-Ubuntu-Gastbetriebssystemen installiert oder aktualisiert werden, erkennt das Installationsprogramm einen Fehler, der meldet, dass "vmxnet" nicht in den laufenden Kernel geladen werden konnte. Das Installationsprogramm von VMware Tools versucht, das Modul zu erstellen, und schlägt beim Laden des Moduls fehl. Das vmxnet-Modul wird nicht in das Modulverzeichnis kopiert. Dieses Problem wurde in der vorliegenden Version behoben.

VMware High Availability (HA)

  • Während HA-DRS-Clustervorgängen zeigt der VI-Client möglicherweise an, dass der Host nicht antwortet
    Bei HA-DRS-Clustervorgängen, wie z. B. beim Hinzufügen bzw. Entfernen eines Hosts aus einem DRS-Cluster oder beim Übernehmen von DRS-Empfehlungen, zeigt der VI-Client möglicherweise an, dass der Host nicht antwortet. Dies geschieht auch dann, wenn die IP-Adresse des Hosts erreichbar ist. Dieses Problem wurde in der vorliegenden Version behoben.
    Umgehung
    Trennen Sie den Host vom HA-DRS-Cluster und verbinden Sie ihn neu. Damit wird das System aktualisiert und der VI-Client wird die von Ihnen vorgenommenen Konfigurationsänderungen anzeigen. Sollte der VI-Client den Status des Hosts erneut als "Antwortet nicht" anzeigen, trennen Sie den Host vom HA-DRS-Cluster, entfernen Sie ihn und fügen Sie ihn wieder zu demselben Cluster hinzu.

Migration mit VMotion

  • Neu: SNMP-Trap während VMotion generiert
    Während VMotion werden auf dem ESX Server-Quell-Host SNMP-Trap-Meldungen über das Ausschalten und auf dem ESX Server-Ziel-Host SNMP-Trap-Meldungen über das Einschalten generiert. Dieses Problem wurde in der vorliegenden Version behoben. Die Traps werden nicht während VMotion auf Hosts generiert, auf denen dieses Update installiert ist.

Netzwerk

  • Neu: Die Netzwerkverbindung kann verloren gehen, wenn die Netzwerk-Gruppierungsrichtlinie auf der Port-ID basiert.
    Die Verbindung zum Netzwerk kann verloren gehen, wenn die Netzwerkgruppierung verwendet wird und die Gruppierungsrichtlinie auf der Port-ID basiert. Folgende Fehlermeldung wird in diesem Fall in VMkernel protokolliert:
    Aug 6 23:27:07 [hostname] vmkernel: 0:02:33:07.052 cpu0:1024)Net: L2Sec_EnforcePortCompliance:229: 0x3000005: peer not allowed
    promiscuous, revoking setting
    Die Netzwerkverbindung funktioniert unterbrechungsfrei, wenn Sie den Promiscuous-Modus des virtuellen Switches aktivieren und folgenden Befehl ausführen: tcpdump -i portgroup. Wenn Sie tcpdumpallerdings wieder stoppen, geht die Verbindung zum Netzwerk verloren. Dieses Problem wurde in der vorliegenden Version behoben.
  • Netzwerkadapter verlieren die Verbindung während einer Skriptinstallation
    Bei einer Skriptinstallation führen die folgenden beiden Befehle nicht zu einem verbundenen Paar aktiver Netzwerkadapter auf dem virtuellen Switch VS_VM1. Stattdessen wird vmnic3 zum aktiven Adapter und vmnic4 zum Standby-Adapter.
    esxcfg-vswitch -L vmnic3 VS_VM1
    esxcfg-vswitch -L vmnic4 VS_VM1
    Der Befehl esxcfg-vswitch -Lfunktioniert nun wie erwartet und mit demselben Funktionsumfang wie in 3.0.x.
  • Die ESX Server-Hosts reagieren bei einem Broadcast Storm im Netzwerk nicht mehr
    Wenn ein Broadcast Storm im Netzwerk auftritt, reagieren die ESX Server-Hosts möglicherweise aufgrund eines Problems mit dem tg3-Netzwerktreiber nicht mehr. Während dieses Zeitraums verfügen Servicekonsolen oder virtuelle Maschinen, die den tg3-NIC verwenden, über keine Verbindung zum Netzwerk mehr. Durch einen Neustart des Computers oder durch das Ent- und Neuladen des Treibers kann die Verbindung wiedergeherstellt werden. Dies behebt aber nicht das Problem.
    ESX Server-Hosts mit dem tg3-Port können keine Pakete senden und empfangen, wenn Sie einem Broadcast Storm ausgesetzt waren. Folgende Fehlermeldungen werden in diesem Fall in VMkernel protokolliert:

    1. WARNING: Net: 1082: Rx storm on 1 queue 3501>3500, run 321>320
    2. VMNIX: WARNING: NetCos: 1086: virtual HW appears wedged (bug number 90831), resetting

    Dieses Problem wurde in der vorliegenden Version behoben. Dieser Fix stellt sicher, dass die NIC innerhalb von 35 Sekunden zurückgesetzt wird, wenn der tg3-Treiber nicht mehr antwortet.
  • Bei aktiviertem Beaconing und wenn eine NIC die Verbindung zu einer Gruppe mit zwei NICs trennt, zeigt die NIC-Gruppierung keine beschreibende Fehlermeldung an
    Wenn Sie die NIC-Gruppierung für das Beaconing konfigurieren und die Verbindung einer NIC zu einer Gruppe mit zwei NICs trennen, wird eine Meldung ähnlich der Folgenden angezeigt:
    Removing from config file only.
    Die vmnic wird dennoch aus der Portgruppe entfernt.

    Ab dieser Version wird eine passende Meldung ähnlich der Folgenden angezeigt:
    Need uplink: for beaconing. (Minimum 2 required).
    Die vmnic verbleibt zudem in der Portgruppe.
  • Netzwerktreiber mit hoher Leistung für NetWare-Gäste
    In dieser Version wurde die Leistung für NetWare-Gäste erhöht, indem Kompatibilitätsprobleme zwischen dem E1000.LAN-Treiber und der virtuellen E1000 NIC-Emulation behoben wurden.
  • e1000-Treiber schlagen mit folgendem Fehler fehl: " P2MCache: GetPhysMemRange failed" Fehler
    Intel Pro/1000 Gigabit Ethernet-Gerätetreiber (e1000) reservieren MTU-Byte für rx-Puffer für einige Gäste, melden dem Gerät aber eine rx-Puffergröße von 2048 Byte. Wenn sich diese Puffer am Rande des physischen Arbeitsspeicherbereichs für den Gast befinden, kann dies zu Problemen mit dem virtuellen e1000-Gerät führen, wobei folgende Meldungen in die VMkernel-Protokolle geschrieben werden:
    WARNING: Alloc: ppn=0xc0000 out of range: 0x0-0xc0000 (count=3)
    WARNING: P2MCache: GetPhysMemRange failed: PPN 0xc0000 canBlock 0 status Bad parameter.
    Dieses Problem wurde in der vorliegenden Version behoben.
  • Das Windows-Gastbetriebssystem hängt bei einem Neustart oder Herunterfahren
    In einem ungewöhnlichen Fall und unter hoher Netzwerkbelastung gehen dem Windows-vmxnet-Treiber für einige Pakete "send-completions" verloren. Der Windows-Gast wartet auf diese Vervollständigungsbestätigungen, wodurch das System bei einem Neustart oder Herunterfahren hängt. Dieses Problem wurde in der vorliegenden Version behoben.

Sicherheit

  • Ausweitung von VMware-Rechten auf 32-Bit- und 64-Bit-Gastbetriebssystemen
    Ein Fehler in der CPU-Hardwareemulation von VMware führt dazu, dass die virtuelle CPU das Trap-Flag nicht korrekt handhabt. Unter Ausnutzung dieses Fehlers können die Rechte auf Gastbetriebssystemen erweitert werden. Ein Angreifer benötigt dazu ein Benutzerkonto auf dem Gastbetriebssystem und muss über die Berechtigung verfügen, Anwendungen auszuführen.
    Der Standard "Common Vulnerabilities and Exposures" (CVE) (cve.mitre.org) hat diesem Problem die Bezeichnung CVE-2008-4915 zugewiesen.
  • Verwundbarkeit bei rekursivem Durchlaufen durch Verzeichnisse
    VirtualCenter bietet Administratoren fein abgestimmte Berechtigungen. Eine Verwundbarkeit bei rekursivem Durchlaufen durch Verzeichnisse, kann Administratoren eventuell ermöglichen, diese Berechtigungen zu erweitern. Um diesen Fehler auszunutzen, benötigt ein Administrator die Berechtigung "Datastore.FileManagement".
    Der Standard "Common Vulnerabilities and Exposures" (CVE) (cve.mitre.org) hat diesem Problem die Bezeichnung CVE-2008-4281 zugewiesen.

Serverkonfiguration

  • Datenverlust bei seriellen Schnittstellen
    In dieser Version ist das Problem behoben, dass es beim Senden von Faxen mit einer virtuellen Maschine unter Verwendung der seriellen Schnittstelle auf dem ESX Server-Host zu Datenverlusten, beispielsweise fehlenden Zeilen und unklaren Informationen, kommen kann.
    Dieser Fix wird aktiviert, indem nach der Patch-Installation in die vmx-Datei serial <n>.hardwareFlowControl = “TRUE”eingefügt wird.
  • Die Startoption force36BitMTRRMask wird nicht mehr benötigt
    Aufgrund von BIOS MTRR-Problemen auf bestimmten Plattformen konnten ESX Server-Hosts zuvor nur dann gestartet werden, wenn die VMkernel-Startoption force36BitMTRRMask auf "false" gesetzt wurde. Dieses Update bietet die volle Unterstützung für bis zu 64 GB an Arbeitsspeicher ohne die Erfordernis, eine Startoption anzugeben.
    Als Folge dieser Änderung wird die VMkernel-Startoption force36BitMTRRMask nicht mehr unterstützt. Wenn die Option aktiviert wird, ist das Ergebnis "no operation" (NOP) und der Start wird fortgesetzt.

Speicher

  • Unterstützung für erweiterte Konfigurationsoptionen für die iSCSI-Software zum Steuern des Multipath-Failover
    Dieser Fix ermöglicht der iSCSI-Software, das Multipath-Failover mit LUN-Zurücksetzung oder Zielzurücksetzung anhand der erweiterten Konfigurationsoptionen Disk.UseLunResetund Disk.UseDeviceResetzu steuern.
  • Im VI-Client dauert das Hinzufügen der Software iSCSI-Zieladresse auf der Registerkarte "Dynamische Erkennung" sehr lange
    Die lange Verzögerung ergibt sich daraus, dass bei jedem Hinzufügen einer Discovery-Adresse eine Zielerkennung ausgelöst wird. Nach dem Hinzufügen der Discovery-Adresse müssen Sie erneut einen Prüfvorgang durchführen, damit VMkernel die neuen Ziele anhand der hinzugefügten Discovery-Adresse finden kann. Dies löst erneut eine Zielerkennung aus. Die Zielerkennung nach dem Hinzufügen der Discovery-Adresse ist überflüssig und führt lediglich zu unnötigen Verzögerungen.
    Durch diese Änderung wird nach dem Hinzufügen einer Discovery-Adresse keine Zielerkennung durchgeführt, wodurch die Zeit für die Ausführung des Vorgangs verringert wird.
  • Fehler: "Aktualisierung der Festplattenpartitionsinformationen fehlgeschlagen"
    Die Festplattenpartitionsinformationen sind nicht aktuell, was zu mehreren Problemen führt. So wird der Bestand nicht aktualisiert und es werden keine Datenspeicher erstellt, erweitert, vergrößert oder entfernt. Möglicherweise wird die folgende Fehlermeldung angezeigt: Fehler bei Konfiguration des Hosts: Aktualisieren der Festplattenpartitionsinformationen ist fehlgeschlagen.Dieses Problem wurde in der vorliegenden Version behoben.

Aktualisierung und Installation

  • Installation des ESX Servers mit der Kickstartdatei im interaktiven Modus schlägt fehl
    Wenn ESX Server mit der Kickstartdatei im interaktiven Modus installiert wird, reagiert das anaconda-Installationsprogramm möglicherweise nicht mehr. Dieses Problem wurde in der vorliegenden Version behoben.
  • Liste der Netzwerkgeräte wird nun während der ESX Server-Installation korrekt angezeigt
    In dieser Version ist das Problem behoben, dass im Dropdown-Menü auf dem Bildschirm mit der Netzwerkkonfiguration bei einer ISO-Neuinstallation für ESX Server 3.5 nicht unterstützte Netzwerkgeräte aufgelistet werden und unterstützte Netzwerkgeräte manchmal nicht angezeigt werden. Netzwerkgeräte, für die in der Installationsprogrammumgebung kein entsprechendes Treibermodul geladen wurde, werden in der Liste nicht angezeigt.

Verwaltung von virtuellen Maschinen

  • Neu: Daten, die an den Tastatur-Port gesendet werden, können ein Herunterfahren der virtuellen Maschine verursachen
    Wenn ungewöhnliche Datengrößen an den Tastatur-E/A-Port gesendet werden, kann dies dazu führen, dass die virtuelle Maschine heruntergefahren wird. Dieses Problem kann dann verursacht werden, wenn das Gastbetriebssystem privilegierte Zugriffsrechte auf den Tastatur-Port hat. Es betrifft weder den ESX Server-Host noch andere virtuelle Maschinen. Dieses Problem wurde in der vorliegenden Version behoben.

Seitenanfang

Bekannte Probleme

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

Sicherung

  • Consolidate Helper-Snapshots werden möglicherweise nicht automatisch entfernt
    In ESX Server 3.5 Update 2 werden Consolidate Helper-Snapshots iterativ erstellt, um den Zeitraum, in dem eine virtuelle Maschine während der Snapshot-Erstellung inaktiv ist, zu minimieren. Consolidate Helper-Snapshots werden jetzt deshalb als Consolidate Helper- xxx und nicht nur als Consolidate Helper bezeichnet. Bei der Verwendung von VMware Consolidated Backup 1.1 mit ESX Server 3.5 Update 2 oder höher kann der vorübergehende Snapshot ignoriert werden, wenn vcbMounter während eines Vorgangs zum Löschen eines Snapshots einen Fehler erkennt. Durch den Befehl vbCleanup.batwird der Snapshot Consolidate Helper- xxx nicht gelöscht. Der Snapshot muss mithilfe des VI-Clients manuell gelöscht werden. Dieser Fehler tritt bei VMware Consolidated Backup 1.5 nicht auf.

CIM und API

  • Einige CIM-Klassen funktionieren nicht ordnungsgemäß auf IBM Multinode-Systemen
    Die folgenden Anomalien werden angezeigt. Die Operation EnumerateInstancegibt in den folgenden Klassen eine Instanz weniger als die Operation EnumerateInstanceNameszurück:
    • CIM_AssociatedSensor
    • CIM_MemberOfCollection
    Bei den folgenden Klassen schlägt die Operation GetInstancefür einige Instanzen fehl. Jedoch ist die Operation EnumerateInstanceserfolgreich:
    • CIM_HostedService
    • CIM_Sensor
    • CIM_SystemDevice
    • CIM_Slot
    • CIM_ElementConformsToProfile
    Die Operationen EnumerateInstancesund EnumerateInstanceNamesgeben keine Ergebnisse zurück:
    • CIM_OwningCollectionElement
    • CIM_RedundancySet
  • Die Operation RequestStateChange(RestoreDefaultThresholds) gibt einen Fehler aus
    Die Operation "RequestStateChange(RestoreDefaultThresholds)" auf ESX Server 3.5 führt bei einigen Sensoren zu einer Fehlermeldung:
    CIM_ERR_FAILED: index out of bounds

    Trotz der Fehlermeldung stellt CIMOM die Schwellenwerte wieder her.
  • VI-Client zeigt auf HP-Servern einen falschen Namen für den Redundanzsensor zur Stromversorgung an
    Bei einer Verbindung einer ESX Server-Installation mit einem HP Serversystem über den VI-Client zeigt der VI-Client den Namen des Redundanzsensors für die Stromversorgung auf dem Server fälschlicherweise als physische Stromquelle an. Beispielsweise zeigt der VI-Client bei einem HP Server mit einem Redundanzsensor mit zwei physischen Stromversorgungen den Redundanzsensor als Stromversorgungen für die Stromversorgung 3 an.
  • Ausführen einer CallMethod-Abfrage auf einer CIM_RecordLog-Instanz schlägt möglicherweise fehl
    In ESX Server 3.5 Update 3 kann eine CallMethod-Abfrage (CM) auf einer CIM_RecordLog-Instanz fehlschlagen. Sie können jedoch das Systemereignisprotokoll über eine Remote-Managementkonsole oder -schnittstelle löschen.
  • Änderungen des Sensorschwellenwerts werden nicht sofort übernommen
    Wenn Sie mithilfe von CIM den Sensorschwellenwert ändern, gibt die Sensoraufzählung möglicherweise nicht sofort die neuen Eigenschaftswerte zurück. Die Änderungen werden ungefähr eine Minute später übernommen.
  • Bei mancher Dell MLK-Hardware weist die Eigenschaft "NumberOfBlocks" für die OMC_Memory-Instanz einen Wert von 0 auf. Dieses Problem wird zurzeit untersucht.
  • Auf HP 380 G5-Rechnern, auf denen ESX Server 3.5 Update 3 ausgeführt wird, wird als Antwort auf CIM_IPProtocolEndpoint-Abfragen die IP-Adresse der IPMI-Karte nicht zurückgegeben.
  • In ESX Server Version 3.5 wird die nachfolgende Fehlermeldung ausgegeben, wenn für numerische Stromversorgungssensoren die Operation Reset() aufgerufen wird:
    CIM_ERR_FAILED: index out of bounds
    Verwenden Sie stattdessen die Operation RequestStateChange(Reset), um dieses Problem zu umgehen.
  • InvokeMethod(RequestStateChange) für Sensor und SEL schlägt fehl, wenn Sie das WS-Man-Protokoll verwenden.
  • Aufrufe von ModifyInstance() zum Ändern des Sensorschwellenwerts schlagen fehl, wenn Sie das WS-Man-Protokoll verwenden.
  • Indication-Ereignisse auf ESX Server 3.5 Update 3 funktionieren nicht bei Verwendung des WS-Man-Protokolls.
  • Auf den IBM IBM x3850 M2- und x3950 M2-Servern verfügen einige OMC_DiscreteSensor-Instanzen über falsche Geräte-IDs (-1 erscheint als letztes Segment der Geräte-ID).
  • Die InvokeMethod(RequestPowerStateChange) schlägt fehl, wenn Sie das WS-Man-Protokoll verwenden.
  • Die Server IBM x3850 M2 und x3950 M2 verfügen nicht über eine Gehäuseeingriffanzeige.

Gastbetriebssysteme

  • Die grafische Installation von Solaris 10 Update 4, 64-Bit schlägt bei der standardmäßigen RAM-Größe von 512 MB für die virtuelle Maschine fehl
    Nach der Installation von ESX Server 3.5 Update 3 Installable oder ESX Server 3.5 Update 3 Embedded, schlägt die grafische Installation von Solaris 10 Update 4, 64-Bit bei der standardmäßigen RAM-Größe von 512 MB für die virtuelle Maschine fehl.
    Umgehung: Verwenden Sie das Solaris 10 Update 4-Installationsprogramm im Textmodus oder legen Sie die RAM-Größe in der virtuellen Maschine auf mindestens 580 MB fest.
  • Die Linux-Gastbetriebssysteme verlieren ihre Verbindung zum Netzwerk nach einer automatischen Tool-Aktualisierung
    Wenn die Version der VMware Tools in einem Linux-Gastbetriebssystem veraltet ist und eine automatische Tool-Aktualisierung durchgeführt wird, geht für das Gastbetriebssystem die Verbindung zum Netzwerk verloren. Bei einer automatischen Tool-Aktualisierung stoppt das Gastbetriebssystem den Netzwerkdienst und startet den Dienst nicht automatisch neu, wenn das Upgrade beendet wurde.
    Umgehung:Starten Sie den Netzwerkdienst im Gastbetriebssystem manuell neu oder starten Sie das Gastbetriebssystem nach einer automatischen Tool-Aktualisierung neu.
  • Für x64-basierte Versionen von Windows Vista- und Windows Server 2008-Gastbetriebssystemen ist ein Microsoft-Hotfix erforderlich
    Bei x64-basierten Versionen von Windows Vista- und Windows Server 2008-Gastbetriebssystemen ohne Microsoft-Hotfix (http://support.microsoft.com/kb/950772) kann die Situation eintreten, dass das Gastbetriebssystem nicht mehr reagiert und den folgenden Fehler zurückgibt:
    MONITOR PANIC: vcpu-3:ASSERT vmcore/vmm/cpu/segment.c:430
  • Windows-Gastbetriebssysteme werden möglicherweise aus dem Standby- oder Ruhezustandsstatus heraus nicht mehr fortgesetzt
    Virtuelle Maschinen mit auf Windows Server 2008 und Windows Server 2003 basierten Gastbetriebssystemen im Standby- oder Ruhezustandsstatus reagieren gegebenenfalls nicht mehr, wenn sie aus dem Standby- oder Ruhezustandsstatus heraus fortgesetzt werden sollen.
    Vgl. KB 946331 auf der Microsoft Support-Website.
  • Deinstallationsprogramm der VMware Tools in Ubuntu-Gast führt nicht zum Entfernen des vmxnet-Moduls (KB 1004351)
  • Administrator kann sich nicht an geklonter virtueller Windows Vista-Maschine anmelden (KB 1004301)
  • VMware Tools-Upgrade auf Linux-Gästen erfordert manuellen Neustart des Netzwerkdienstes (KB 1004322)
  • VMware Tools-Upgrade für Windows-Gast kann nicht fortgesetzt werden (KB 1004317)
  • Ubuntu 7.10, 64-Bit SMP reagiert bei Ausführung, Installation oder Start auf einem Intel-Host möglicherweise nicht mehr (KB 1004384)

VMware High Availability (HA)

  • HA-Netzwerkübereinstimmungsprüfung
    Während der HA-Konfiguration in VirtualCenter 2.5 Update 2 zeigen die Registerkarten "Aufgaben" und "Ereignisse" möglicherweise die folgende Fehlermeldung und Empfehlung an:

    Der HA-Agent auf <esxhostname> im Cluster <clustername> in <datacenter> weist einen Fehler auf - Nicht kompatibles HA-Netzwerk:
    Verwenden Sie die erweiterten Cluster-Einstellungen "das.allowNetwork" zum Steuern der Netzwerknutzung.

    Ab VirtualCenter 2.5 Update 2 verfügt HA über eine erweiterte Netzwerkübereinstimmungsprüfung zum Erhöhen der Clusterzuverlässigkeit. Diese erweiterte Netzwerkübereinstimmungsprüfung sorgt für ordnungsgemäße clusterübergreifende Taktsignal-Netzwerkpfade. Weitere Informationen finden Sie unter KB 1006606.
  • Die Migration von virtuellen Maschinen wird nicht empfohlen, wenn der ESX Server-Host in den Wartungs- oder Standby-Modus wechselt
    Die Migration von virtuellen Maschinen wird von VMware HA nicht empfohlen (bzw. wird im vollautomatischen Modus nicht von VMware HA durchgeführt), wenn der Host in den Wartungs- oder Standby-Modus wechselt, da der VMware HA-Failover-Level beim Wechseln in den entsprechenden Modus verletzt werden kann. Diese Einschränkung gilt unabhängig davon, ob die strenge HA-Zugangssteuerung aktiviert ist oder nicht.
  • Die Statusüberwachung von VMware HA wird in der Konsole nach einem Host-Failover nicht mehr neu gestartet
    Die VMware-Konsolenanzeige zeigt nach einem Hostausfall ein leeres Fenster an, wenn für einen HA-Cluster die Statusüberwachung aktiviert wurde. Die Konsole zeigt den Neustart der virtuellen Maschine nicht an.

    Umgehung
    Sie müssen eine neue Konsole öffnen, damit Sie den Neustart der virtuelle Maschinen nach dem Failover sehen können.

Internationalisierung

Sämtliche Felder im VI-Client und in VMware Web Access bieten ab sofort Unterstützung für die Eingabe von Nicht-ASCII-Zeichen, mit Ausnahme der folgenden Einschränkungen:

Einschränkungen in Bezug auf die Eingabe von Nicht-ASCII-Zeichen

  • Die Angabe eines Nicht-ASCII-Werts als Eingabe wird nicht von der Remote-Befehlszeilenschnittstelle (RCLI) unterstützt.
  • Der Name des Computers, auf dem VMware Infrastructure 3 oder eine der zugehörigen Komponenten installiert wird, darf keine Nicht-ASCII-Zeichen enthalten.
  • Der Name des Computers oder der virtuellen Maschine, auf dem/der der VirtualCenter Server installiert ist, darf keine Nicht-ASCII-Zeichen im Computernamen aufweisen. Anderenfalls schlägt die Installation von VirtualCenter Server fehl.
  • Verwenden Sie für alle Komponenten den im Installationsprogramm standardmäßig vorgegebenen Installationspfad. Nehmen Sie keine Änderung am Installationspfad vor, wenn der Pfad nach der Änderung Nicht-ASCII-Zeichen und erweiterte ASCII-Zeichen enthält.
  • Datenspeichernamen, Namen virtueller Netzwerke und Image-Dateinamen (CD, DVD und Diskettenlaufwerk) dürfen ausschließlich ASCII-Zeichen umfassen.
  • Die Meldung des Tages darf nur ASCII-Zeichen enthalten.
  • Bei der Anmeldung am VirtualCenter Server sind nur Benutzernamen mit ASCII-Zeichen erlaubt (Anmeldename unter Windows).
  • Die Image-Anpassung kann fehlschlagen, wenn Nicht-ASCII-Zeichen verwendet werden.
  • Benutzerdefinierte Attributnamen und -werte dürfen nur aus ASCII-Zeichen bestehen.
  • Zur Einhaltung der allgemeinen Internet- und Protokollstandards dürfen die folgenden Elemente keine Nicht-ASCII-Zeichen enthalten: Hostnamen, Arbeitsgruppennamen, Domänennamen, URLs, E-Mail-Adressen, SMTP-Servernamen und SNMP-Community-Namen.
  • Gastbetriebssystemanpassungen unter Verwendung der ASCII-Codierung werden unterstützt, die Anpassung mit UTF-8-codierten systemeigenen Zeichen aus dem Japanischen, Chinesischen oder Deutschen werden jedoch nur eingeschränkt unterstützt. Für Anpassungen mit Besitzer-, Organisations-, Benutzernamen und Kennwörtern, die Nicht-ASCII-Zeichen enthalten, müssen VirtualCenter und die Sysprep-Tools mit dem gleichen Gebietsschema verwaltet werden wie das Gastbetriebssystem. Dies schließt die Verwendung von UTF-8-codierten Antwortdateien ein.

Anzeigeeinschränkungen für Nicht-ASCII-Zeichen

  • Werden bei der Verwaltung eines VirtualCenter Servers mit dem VI-Client unterschiedliche Windows-Sprachversionen verwendet, kann es aufgrund der Unterschiede in Bezug auf die sprachspezifische Unterstützung in Windows zu einer fehlerhaften Darstellung einiger Zeichen kommen.
  • Wenn eine Fehlermeldung Protokollspeicherorte oder Benutzernamen mit Nicht-ASCII-Zeichen enthält, wird die Fehlermeldung in der lokalisierten Umgebung nicht richtig angezeigt.
  • Bei Verwendung des Import-Assistenten von VMware Converter stimmt das Datums- und Uhrzeitformat gelegentlich nicht mit dem aktuellen Gebietsschema überein.
  • Unicode-Zeichen werden in der Spalte "Status" und in den Aufgabendetails der Aufgabenansicht im japanischen Gebietsschema als Fragezeichen (???) angezeigt.
  • Der Abschnitt "Befehle" auf der Registerkarte Übersicht wird nicht ordnungsgemäß angezeigt.

Einschränkungen in Bezug auf die gesteuerte Konsolidierung

Die Registerkarte "Gesteuerte Konsolidierung" ist nur im Gebietsschema en_US verfügbar.

Übersetzungsprobleme

Für diese Version sind folgende Übersetzungsprobleme bekannt:

  • Der Upgrade-Assistent ist nicht übersetzt.
  • Einige Fehlermeldungen, die vom ESX Server-Host stammen, sind nicht übersetzt.
  • Einige der lokalisierten Oberflächenlayouts sind noch nicht fertiggestellt.

Andere Internationalisierungsprobleme

Es wurden folgende zusätzliche Probleme festgestellt:

  • Die in der Aktion "Skript ausführen" für einen Alarm verwendeten Werte werden nach einem Neustart des VirtualCenter Servers möglicherweise nicht ordnungsgemäß angezeigt, wenn die Host-Betriebssystemsprachen von VMware Infrastructure-Client und VirtualCenter Server/Datenbank nicht übereinstimmen.
  • In der chinesischen (vereinfacht) Version von VI Web Access wird der falsche Text auf der Schaltfläche "Abbrechen" angezeigt.
  • Der VI-Client setzt möglicherweise die Spracheinstellung außer Kraft
    Der VI-Client setzt möglicherweise die Spracheinstellung außer Kraft und zeigt Meldungen in anderen Sprachen als in der Hauptsprache an. Der VI-Client kann Meldungen anzeigen, die vom Server (VirtualCenter Server und ESX Server) dynamisch in der auf dem Server festgelegten Hauptsprache erstellt werden. Dieses Problem tritt nicht auf, wenn alle Programme in der Sprache des eingestellten Gebietsschemas des Betriebssystems ausgeführt werden.
  • Assistent für eine Neuinstallation zeigt im deutschsprachigen VI-Client den falschen Text an
    Der Assistent für eine Neuinstallation zeigt im deutschsprachigen VI-Client den falschen Text an.
    Der Assistent für eine Neuinstallation zeigt den folgenden Text an:
    Der Installations-Assistent ermöglicht Ihnen, VMware Infrastructure Client 2.5 zu reparieren oder zu entfernen., anstatt: Der Installations-Assistent ermöglicht Ihnen, VMware Infrastructure Client 2.5 zu entfernen.
  • Links mit von Maschinen erzeugten Namen von virtuellen Maschinen funktionieren nicht

    Wenn Sie unter Verwendung von VMware Web Access den Datenspeicher durchsuchen, indem Sie auf einen Link mit von Maschinen erzeugten Namen von virtuellen Maschinen (der Name beginnt im Allgemeinen mit einem Plus-Zeichen und endet mit einem Schrägstrich, z. B. +5paw55qE5qih5p2,/) klicken, gibt der Webbrowser eine leere Seite oder eine Seite mit dem Hinweis darauf aus, dass die Seite nicht gefunden wurde. Sie können jedoch auf solche virtuellen Maschinen mithilfe des VI-Clients zugreifen.

Migration mit VMotion

Sonstige Probleme

Netzwerk

  • Neu: Erweitertes netperf-Testen schlägt für IPv6 fehl
    Eine hohe Arbeitsbelastung über 12 Stunden hinweg unter Verwendung von "netperf" auf virtuellen Maschinen mit Internet Protocol Version 6 (IPv6) kann dazu führen, dass Sockets heruntergefahren werden. Folgende Sockets sind davon betroffen: TCP_STREAM, UDP_STREAM, TCP_RR und UDP_RR. Möglicherweise werden Fehlermeldungen ähnlich der Folgenden auf der Konsole der virtuellen Maschine angezeigt:

    send_tcp_rr: data recv error: Connection timed out
    netperf: cannot shutdown tcp stream socket: Transport endpoint is not connected
    Dies ist ein bekanntes Problem.
  • Virtuelle Maschine mit Microsoft Windows schlägt beim Empfangen von Jumbo Frames fehl
    Virtuelle Maschine mit Microsoft Windows schlägt beim Empfangen von Jumbo Frames fehl und zeigt einen blauen Bildschirm an, wenn der ESX-Host im Debugmodus gestartet wurde.
  • Treiber für NetXen-Netzwerkkarte unterstützt bis zu 31 GB an physischem RAM auf ESX Server-Hosts (KB 1003046)
  • Doppelte Pakete werden erstellt, wenn Signalprüfung mit VLAN-Typ 4095 verwendet wird
    Während eines Netzwerkvorgangs einer virtuellen Maschine, bei dem die VLAN-ID auf 4095 gesetzt wird und der dazugehörige vSwitch mit einer Signalprüfung konfiguriert ist, werden doppelte Pakete erstellt.
    Umgehung: Bei der Verwendung einer VLAN-ID von 4095, legen Sie für "Netzwerk-Failover-Ermittlung" die Option "Nur Verbindungsstatus" statt "Signalprüfung" fest. ( KB 1004373)

Serverkonfiguration

Speicher

Aktualisierung und Installation

 

Installation und Aktualisierung von VirtualCenter

ESX Server-Upgrade und -Installation

Andere Upgrade- und Installationsprobleme

Verwaltung von virtuellen Maschinen

  • Neu: Das VMware Tools-Symbol wird in der Systemsteuerung von 64-Bit-Gastbetriebssystemen von Windows Vista und Windows 2008 nicht angezeigt
    Für VMware Tools auf Windows Vista- und Windows 2008-Gastbetriebssystemen ist nur die 32-Bit-Systemsteuerung verfügbar. Deshalb wird das Symbol für VMware Tools nicht in der Systemsteuerung von 64-Bit-Betriebssystemen angezeigt.

    Umgehung: Verwenden Sie das Applet der Systemsteuerung der 32-Bit-Version, das in der Taskleiste von VMware zur Verfügung steht, oder C:\Programme(x86)\VMware\VMware Tools\VMControlPanel.cplbzw. <VMware tools install path>\VMControlPanel.cpl.
  • Benutzer mit Berechtigung "Erstellen" kann keine virtuellen Maschinen erstellen(KB 1004417)
  • Geklonte virtuelle Maschinen enthalten kein DNS-Suffix (KB 1004299)
  • Bereitstellung virtueller Maschinen anhand einer Vorlage schlägt mit einem Hinweis auf fehlende Berechtigungen fehl (KB 1004295)
  • Geklonte virtuelle Maschinen sehen die .vmdk-Datei der Quell-VM (KB 1004176)
  • Benutzerdefiniertes VMware Tools-Skript wird für Ereignisse "Angehalten" oder "Herunterfahren" nicht ausgeführt (KB 1004390)
  • Virtuelle Maschinen werden nach einem Failover möglicherweise nicht eingeschaltet, wenn der Host isoliert ist
    Virtuelle Maschinen werden nach einem Failover möglicherweise nicht eingeschaltet, wenn der Host isoliert ist und die Hostisolierungsreaktion auf "Herunterfahren des Gastes", der Standardkonfiguartion für einen Cluster, eingestellt ist. Dies tritt möglicherweise bei Clustern mit weniger als fünf Knoten und auf virtuellen Maschinen auf, die mehr Zeit zum Herunterfahren des Gastes benötigen.
    Umgehung
    Setzen Sie bei Clustern mit weniger als fünf Knoten die Isolierungsreaktion auf entweder "VM eingeschaltet lassen" oder "Ausschalten".
    Zum Festlegen der Isolierungsreaktion für eine virtuelle Maschine wählen Sie den Cluster aus, klicken Sie auf den Link "Einstellungen bearbeiten" und wählen Sie unter "VMware HA" Optionen für virtuelle Maschinen. Wählen Sie im Popup-Menü "Isolierungsreaktion" für die bestimmte virtuelle Maschine entweder VM eingeschaltet lassen oder Ausschalten.
  • E/A kann auf virtuellen Maschinen während der Firmware-Aktualisierung verzögert werden
    Wenn virtuelle Maschinen auf einer gemeinsam genutzten LUN mit hoher E/A-Arbeitslast ausgeführt werden und wenn die Firmware mit dem Speicherverwaltungsdienstprogramm aktualisiert wird oder wenn der Speichercontroller neu gestartet wird, kann E/A auf jeder virtuellen Maschine verzögert werden.
    In der Datei "vmkernel.log" können den folgenden ähnliche Fehlermeldungen angezeigt werden:
    1:01:05:07.275 cpu2:1039)WARNING: FS3: 4785: Reservation error: Not supported
    SCSI: 4506: Cannot find a path to device vmhba1:0:125 in a good state. Trying path vmhba1:0:125.
    1:01:05:10.262 cpu3:1039)ALERT: SCSI: 4506: Cannot find a path to device vmhba1:0:125 in a good state. Trying path vmhba1:0:125.
    1:01:05:40.748 cpu1:1083)<6>mptbase: ioc0: LogInfo(0x30030108): Originator={IOP}, Code={Invalid Page}, SubCode(0x0108)
    1:01:05:40.930 cpu0:1024)Log: 472: Setting loglevel (via VSI) for module 'SCSI' to 5

Probleme bei VirtualCenter, VI-Client und Web Access

Seitenanfang