VMware ESX Server 3.5 Update 5 | 3. Dezember 2009 | Build 207095
Letzte Dokumentaktualisierung: 03 Dez. 2009
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 den bisherigen Bezeichnungen, um mit den Produktoberflächen und Dokumentationen übereinzustimmen. In künftigen Versionen werden die Produktnamen aktualisiert.
Anmerkungen:
Sie erhalten nachstehend Informationen zu einigen der wichtigsten Verbesserungen in der vorliegenden Version von VMwareESX Server:
Aktivierung der Intel Xeon 3400-Prozessorserie – Die Intel Xeon 3400-Prozessorserie wird jetzt unterstützt. Erweiterte VMotion-Funktionen werden auch unterstützt. Weitere Informationen über vorherige Prozessorfamilien, die von Enhanced VMotion unterstützt werden, finden Sie unter Unterstützte Prozessoren für Enhanced VMotion Compatibility (EVC) (KB 1003212).
Treiber-Update für den Broadcom bnx2-Netzwerk-Controller – Der Treiber für bnx2-Controller wurde auf Version 1.6.9 aktualisiert. Dieser Treiber unterstützt das bootcode-Upgrade auf bnx2-Chipsets und erfordert ein Upgrade der bmapilnx- und lnxfwnx2-Tools von Broadcom. Dieser Treiber bietet auch Unterstützung für den Netzwerk-Controller - Sideband-Schnittstelle (NC-SI) für SOL (Serial Over LAN) anwendbar auf Broadcom NetXtreme 5709- und 5716-Chipsets.
Treiber-Update für LSI SCSI- und SAS-Controller – Der Treiber für LSI SCSI- und SAS-Controller wurde auf Version 2.06.74 aktualisiert. Diese Version des Treibers wird benötigt, um die Unterstützung für gemeinsam genutzte SAS-Umgebungen zu verbessern.
Neu unterstützte Gastbetriebssysteme – Die Unterstützung für folgende Gastbetriebssysteme wurde speziell für diese Version hinzugefügt:
Vollständigere Informationen über von dieser Version unterstützte Gastbetriebssysteme finden Sie im "VMware-Kompatibilitätshandbuch": www.vmware.com/resources/compatibility/search.php.
Neu unterstützte Management-Agenten – Aktuelle Informationen zu unterstützten Management-Agenten finden Sie unter Vom VMware ESX Server unterstützte Hardware-Lifecycle-Management-Agenten.
Neu unterstützte Netzwerkkarten – In dieser Version von ESX Server wird der HP NC375T (NetXen) PCI Express Quad Port Gigabit Server-Adapter unterstützt.
Neu unterstützte SATA-Controller – In dieser Version von ESX Server wird der Intel Ibex Peak SATA AHCI-Controller unterstützt.
Hinweis: |
|
Funktionen und bekannte Probleme der Vorgängerversionen von VMware Infrastructure 3, zu denen ESX Server 3.x- 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:
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 des VI-Clients.
Die Listen zur Hardwarekompatibilität stehen nun in einem webbasierten Kompatibilitätshandbuch unter www.vmware.com/guides zur Verfügung. Dieses neue Format bietet eine zentrale Quelle für alle VMware-Kompatibilitätshandbücher. Die vorherigen PDF-Versionen werden nicht mehr aktualisiert. Das webbasierte Kompatibilitätshandbuch ermöglicht das Durchsuchen der Handbücher und das Speichern der Suchergebnisse im PDF-Format.
Um über Updates des Kompatibilitätshandbuchs benachrichtigt zu werden, können Sie sich registrieren unter
VMware Infrastructure-Kompatibilitätstabellen ( PDF)
Die gesamte Dokumentation für ESX Server 3.5 Update 4 gilt auch für ESX Server 3.5 Update 5. Eine vollständige Liste der Handbücher und zusätzlicher Dokumentation finden Sie in der VMware Infrastructure 3-Dokumentation.
Im Installationshandbuch finden Sie Schritt-für-Schritt-Anleitungen zur Installation und Konfiguration des ESX Servers und von VirtualCenter.
Wenngleich die Installation unkompliziert ist, sind viele der nachfolgenden Konfigurationsschritte äußerst wichtig. Lesen Sie insbesondere die folgenden Abschnitte:
Diese Version von ESX Server 3.5 Update 5 ermöglicht ausschließlich Upgrades von zuvor unterstützten Versionen. Das Installationsprogramm von ESX Server 3.5 Update 5 fordert Sie nur dann auf, ein Upgrade auszuführen, wenn eine zuvor unterstützte Version von ESX Server gefunden wurde. Informationen zu den Installationsanforderungen finden Sie im Installationshandbuch.
Für ein Upgrade Ihres ESX Server-Hosts auf ESX Server 3.5 Update 5, folgen Sie einen der folgenden unterstützten Upgrade-Pfaden:
Upgrade-Typ |
ESX Server 3.0.1 |
ESX Server 3.0.2 |
ESX Server 3.0.3 |
ESX Server 3.5 |
ESX Server 3.5 Update 1 |
ESX Server 3.5 Update 2 |
ESX Server 3.5 Update 3 |
ESX Server 3.5 Update 4 |
Upgrade-ZIP |
Nein |
Nein |
Nein |
Ja |
Ja |
Ja |
Ja |
Ja |
ISO-Image |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Hinweis: |
|
Weitere Informationen zu den Installations- und Upgrade-Methoden finden Sie im Upgrade-Handbuch.
Eine Liste der in ESX Server 3.5 Update 5 aktualisierten RPMs finden Sie unter Aktualisierte RPMs und Sicherheits-Fixes. Dieses Dokument gilt nicht für die ESX Server 3i-Produkte.
Es wird empfohlen, VMware Tools für diese Version des ESX Server zu aktualisieren. Die VMware Tools-Version sollte 7.4.8 sein. Der Windows-SVGA-Treiber wurde auf Version 11.4.3.3 aktualisiert.
Diese Version enthält 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 3.5-Patches.
ESX Server 3.5 Update 5 enthält alle Fixes in ESX Server 3.5 Update 4 sowie die folgenden Patches, die nach ESX Server 3.5 Update 4 veröffentlicht wurden:
Zudem behebt ESX Server 3.5 Update 5 neue Probleme (weitere Informationen finden Sie im Abschnitt Behobene Probleme) und diese Probleme werden auch in den folgenden Paketen der einzelnen Patches behoben:
In dieser Version werden Probleme in den folgenden Bereichen behoben:
Der Befehl vcbSnapAllschlägt möglicherweise mit einem Fehler fehl, wenn das backup_destinationals scpfestgelegt ist. Dieses Problem wurde in ESX Server 3.5 Update 5 behoben.
In früheren Versionen von ESX Server weist die Eigenschaft NumberOfBlocksfür die OMC_Memory-Instanz bei mancher Dell MLK-Hardware einen Wert von 0 auf.
Das Protokoll ist mit storelib Physical Device Device ID-Meldungen gefüllt
In manchen Fällen protokollieren Anbieter, die LSI Logic-Treiber (megaraid2, megaraid_sas, mptscsi) verwenden, wiederholt Meldungen wie z. B. storelib Physical Device Device IDund füllen die Protokolldatei /var/log/messagesauf. Diese Meldungen sind Teil des Debug-Codes. In dieser Version werden diese Debug-Code-Meldungen nicht an dieser Stelle protokolliert.
Eine Debug-Meldung wird alle zwei Minuten im Systemprotokoll protokolliert
Die folgende Debug-Meldung wird alle zwei Minuten in der Datei /var/log/messagesprotokolliert:
trying to open /sbin/modprobe edd 2>&1
LSI-Anbieter protokollieren wiederholt die Meldung failed to get TopLevelSystemim Systemprotokoll von ESX Server-Hosts, die über keine LSI-Controller verfügen. In dieser Version wird die Meldung nicht protokolliert, wenn keine LSI-Controller vorhanden sind.
vSphere-Client zeigt den Status des Hostarbeitsspeichers als "Unbekannt" auf Servern an, auf denen ESX Server 3.5 Update 4 ausgeführt wird
Auf Servern, auf denen ESX Server 3.5 Update 4 ausgeführt wird, zeigen die DIMM-Module (Dual In-Line Memory Module) den Arbeitsspeicherstatus als "Unbekannt" an, wohingegen die DIMMs auf anderen Systemen den potenziell falschen Status als "OK" angeben.
Systemstatus und speicherverwandte Informationen auf dem VI-Client werden nach einem Upgrade auf ESX Server 3.5 Update 4 geändert
Nach einem Upgrade auf ESX Server 3.5 Update 4 werden der Systemstatus und speicherverwandte Informationen auf dem VI-Client geändert. Wenn Sie zudem mithilfe des CIM-Clients eine EI-Operation auf einige der Klassen durchführen, z. B. auf VMWARE_StorageExtent, erhalten Sie eine Fehlermeldung ähnlich der Folgenden:
/var/pegasus/bin/cimcli CIMException: Cmd= enumerateInstances Object= VMWARE_StorageExtent
ProviderLoadFailure: (/var/pegasus/lib/libvmwprovider.so) Provider is not a CMPI style provider. Cannot find VMware_StorageExtent_Create<mi-type>MI symbol.
Erhöhter E/A-Zeitüberschreitungswert für Linux-Gastbetriebssysteme mit einer Kernelversion von 2.6.13 oder höher
Ab ESX 3.5 Update 5 installiert VMware Tools eine udev-Regeldatei auf Linux-Betriebssystemen mit einer Kernelversion von 2.6.13 oder höher. Diese Regeldatei ändert den Standardzeitüberschreitungswert von virtuellen VMware-Festplatten auf 180 Sekunden. Dies erhöht die Überlebenschancen des Gastbetriebssystems während eines Failover-Szenarios.
Der Arbeitsspeicher-Scrubber-Dienst in Solaris ruft den Arbeitsspeicher-Balloon auf
Der Arbeitsspeicher-Scrubber-Dienst in Solaris ruft den Arbeitsspeicher-Balloon auf, indem er auf die Arbeitsspeicherseiten zugreift, die von dem Balloon-Treiber reserviert sind. In dieser Version ist der Arbeitsspeicher-Scrubber-Dienst deaktiviert, wenn der Balloon-Treiber geladen ist, um so die Pop-Rate des Arbeitsspeicher-Balloons zu reduzieren.
Der Balloon-Treiber auf virtuellen Solaris-Maschinen wird häufig zurückgesetzt
Manche virtuelle Solaris-Maschinen setzen den Balloon-Treiber häufig zurück. In dieser Version wurden zwei neue Parameter eingeführt, anhand derer Sie das Ballooning deaktivieren können. Diese Parameter sind:
Diese Parameter können in der .vmx-Datei konfiguriert werden. Wenn der Parameter sched.mem.balloon.resetlimitden Wert 0 erreicht, wird das Ballooning deaktiviert. Wurde auf einer virtuellen Maschine das Ballooning deaktiviert, kann es nur durch einen Neustart der virtuellen Maschine wieder aktiviert werden.
Anwendungen, die die Datei "msvcp71.dll" benötigen, werden nicht geöffnet, wenn die VSS-Komponente deinstalliert wird
Wenn Sie VMware Tools oder die VSS-Komponenten von VMware Tools deinstallieren, werden Anwendungen, die die Datei msvcp71.dllbenötigen, nicht geöffnet, wenn die virtuelle Maschine neu gestartet wird. Dieses Problem wurde in der vorliegenden Version behoben.
Die Registerkarte Virtuelle Maschinen in VirtualCenter zeigt virtuelle Windows 2008 Server-Maschinen als virtuelle Windows Vista-Maschinen an.
Die Arbeitsspeicherauslastung des Gastbetriebssystems wird überschätzt und verursacht somit ausgelöste Arbeitsspeicheralarme in VirtualCenter Server
Die Arbeitsspeicherauslastung von Gastbetriebssystemen wird möglicherweise auf Intel-Systemen überschätzt, welche die EPT-Technologie unterstützen, oder auf AMD-Systemen, welche die RVI-Technologie unterstützen. Dies könnte dazu führen, dass die Arbeitsspeicheralarme des VirtualCenter Server auch dann ausgelöst werden, wenn das Gastbetriebssystem nicht aktiv auf große Arbeitsspeichermengen zugreift.
Beim Installieren der VMware Tools wird auf virtuellen Windows XP Embedded-Maschinen nach der Datei "i8042prt.sys" gefragt
Beim Installieren der VMware Tools wird auf virtuellen Windows XP Embedded-Maschinen nach der Datei i8042prt.sysgefragt. Sie müssen diese Datei manuell aus dem Verzeichnis C:\Windows\system32\driversauswählen und auf OK.
klicken Hinweis: Es wird in diesem Fall davon ausgegangen, dass sich der Ordner \Windows\system32\driversauf Laufwerk C:befindet.
Virtuelle Windows-Maschinen schlagen mit einem blauen Bildschirm fehl, wenn auf sie über RDP-Sitzungen zugegriffen werden.
Manche virtuelle Windows-Maschinen schlagen möglicherweise mit einem Fehler auf dem blauen Bildschirm fehl, wenn auf sie über eine RDP-Sitzung (Remote Desktop Protocol) zugegriffen wird.
Java-Anwendungen, die in virtuellen SMP-Maschinen (Symmetric Multi-Processing) mit aktiviertem VMI ausgeführt werden, schlagen möglicherweise fehl.
Das automatische Upgrade von VMware Tools auf einer virtuellen Windows-Maschine erfordert den manuellen Benutzerzugriff.
Bei einem automatischen Upgrade von VMware Tools auf einer virtuellen Windows-Maschine über den VI-Client zeigt das Installationsprogramm möglicherweise ein Dialogfeld mit einer Eingabeaufforderung an. Sie müssen sich zum Anschließen des Upgrade-Prozesses bei der virtuellen Maschine anmelden und auf das Dialogfeld reagieren. Das Problem wurde in dieser Version behoben, sodass das automatische Upgrade ohne manuellen Benutzerzugriff abgeschlossen wird.
Bei virtuellen Maschinen, die das Virtual Machine Interface (VMI) verwenden, dauert der Startvorgang möglicherweise sehr lange.
Eine virtuelle Maschine, die das Virtual Machine Interface (VMI) verwendet, antwortet möglicherweise nicht mehr. Dieses Problem wurde in der ESX Server 3.5 Update 5-Version behoben.
Bei virtuellen SMP-Maschinen, die die RVI-Funktion (Rapid Virtualization Indexing) von AMD verwenden, wird möglicherweise ein schwarzer Bildschirm für bis zu 30 Sekunden nach dem Einschalten angezeigt.
VMware Tools überschreibt den SVGA-Treiber, ohne die Version des vorhandenen SVGA-Treibers zu prüfen.
Das Reparieren oder Ändern von VMware Tools schlägt mit einem schwerwiegenden Fehler fehl
Wenn Sie VMware Tools auf einer virtuellen Maschine über die Menüfolge Systemsteuerung > Software reparieren oder ändern, schlägt das Installationsprogramm fehl und führt ein Rollback mit dem Fehler Schwerwiegender Fehler während der Installationdurch. In dieser Version wurde die Option zum Reparieren über die Menüfolge Systemsteuerung > Software entfernt. Stattdessen müssen Sie setup.exedirekt von dem Originalmedium ausführen, das für eine Neuinstallation verwendet wurde.
ESX aktiviert bei VMware HA-Datenverkehr, VMotion-, Klon- oder Patch-Vorgängen automatisch die Firewall
Bei Ausführung bestimmter Vorgänge auf dem ESX-Host, wie z. B. VMotion, Klonen, HA-Konfiguration oder Patchen, wird die Firewall des Betriebssystems der ESX-Konsole möglicherweise auf eine zuvor gespeicherte Konfiguration zurückgesetzt. Diese Zurücksetzung tritt auf, wenn Sie die Firewall-Konfiguration mit einem anderen Tool als dem unterstützten Befehl esxcfg-firewallgeändert haben.
Deaktivieren Sie die Firewall nicht, indem Sie chkconfig firewall offausführen oder indem Sie das Firewall-Startskript blockieren. Deaktivieren Sie die Firewall, indem Sie dem Datenverkehr keine Einschränkungen auferlegen. Führen Sie dazu den Befehl esxcfg-firewall --allowIncoming --allowOutgoingaus.
Ändern Sie die aktive Firewall-Konfiguration nicht, indem Sie den iptables-Befehl oder andere Linux-Befehle zur Firewall-Verwaltung ausführen. Verwalten Sie die Firewall-Konfiguration des Konsolenbetriebssystems ausschließlich mit dem Befehl esxcfg-firewall, mit vSphere oder dem VI-Client.
So verwalten Sie mit dem vSphere-Client die Firewall-Konfiguration des Konsolenbetriebssystems:
Wenn Sie eine neue Firewall-Dienstdefinition hinzufügen möchten, erstellen Sie eine zusätzliche XML-Datei im Verzeichnis /etc/vmware/firewall. Sie können den neuen Dienst anschließend mit dem Befehl esxcfg-firewall -e <Name_des_neuen_Diensts>verwenden.
Wenn Sie einen von ESX angebotenen Dienst erweitern möchten, kopieren Sie dessen XML-Definition von der Originaldatei in das Verzeichnis /etc/vmware/firewall(verwenden Sie services.xmloder eine der anderen Dateien). Geben Sie dem neuen Dienst einen eindeutigen Namen, der sich vom Namen der Originaldatei (die unter dem alten Namen weiterhin zur Verfügung steht) unterscheiden muss. Deaktivieren Sie anschließend den alten und aktivieren Sie den neuen Dienst. Beispiel: esxcfg-firewall -d ftpClient -e myFtpClient.
Ändern Sie nicht die ursprünglich von ESX bereitgestellten Firewall-XML-Dateien. Diese Dateien werden möglicherweise später einmal durch einen Patch oder ein Upgrade ersetzt, wobei Ihre Änderungen verloren gehen.
Virtuelle Maschine wird ausgeschaltet, wenn VMotion fehlschlägt
Wenn aufgrund einer hohen arbeitsspeicherintensiven VM-Last oder eines ähnlichen Problems VMotion fehlschlägt, wird die virtuelle Maschine möglicherweise ausgeschaltet. Dieses Problem wurde in der vorliegenden Version behoben, damit virtuelle Maschinen auf dem Quellhost weiterhin funktionieren können, falls VMotion fehlschlägt.
ESX Server-Host fällt möglicherweise beim Herunterfahren oder Neustart mit einem violetten Bildschirm aus, wenn die Dämonen pegasusund wsmannicht gestoppt werden. Dieses Problem wurde in der vorliegenden Version behoben.
ESX Server startet nicht und zeigt auf manchen ASUS-Systemen einen violetten Bildschirm an
Gemäß ACPI-Spezifikation müssen Datenformate, die von den Methoden _PRSund _CRSzurückgegeben werden, für alle Interrupt-Link-Geräte übereinstimmen, von denen sie implementiert werden. Falls das BIOS fälschlicherweise unterschiedliche Formate implementiert, startet der ESX Server möglicherweise nicht und zeigt einen violetten Bildschirm an. Der Fix erkennt Inkonsistenzen in Datenformaten, ignoriert die fehlerhafte Informationen und lässt das System starten.
Dateiberechtigungsprobleme beim Lesen von Auslagerungsdateien unter NFS
Die Dateiberechtigungsprobleme wurden in dieser Version behoben.
Arbeitsspeicher wird von im Leerlauf befindlichen virtuellen Maschinen zurückgewonnen, obwohl freier Arbeitsspeicher zur Verfügung steht
In einer Konfiguration, die mehrere virtuellen Maschinen mit sehr viel Arbeitsspeicher enthält, wird Arbeitsspeicher von im Leerlauf befindlichen virtuellen Maschinen zurückgewonnen, obwohl freier Arbeitsspeicher zur Verfügung steht. Dieses Problem wurde in der vorliegenden Version behoben.
Konfigurationsdaten gehen bei einem Neustart verloren
Wenn die /-Partition der ESX Server-Servicekonsole voll ist, gehen bei einer Änderung der Konfigurationsdatei esx.confdurch einen Befehl alle Konfigurationsdaten verloren. Wenn beispielsweise das Dateisystem voll ist, führen alle Versuche, die vSwitch-Konfiguration zu ändern, dazu, dass alle Konfigurationsdaten verloren gehen. Infolgedessen fällt nach einem Neustart das Netzwerk aus. In dieser Version von ESX Server wurde das Problem behoben, sodass in einem solchen Fall keine Daten verloren gehen. Darüber hinaus wird eine Fehlermeldung angezeigt, die besagt, dass das Dateisystem voll ist.
ESX Server erkennt keine CDP-Informationen auf Intel MT- oder PT-Netzwerkkarten nach einer nativen VLAN-Änderung (KB 1006379)
ESX-Host fällt aus, wenn seine verfügbaren TCP/IP-Sockets ausgeschöpft sind und ein NFS-Client ein gemountetes Verzeichnis hat.
TSO-Frames sind auf allen tg3-Netzwerkkarten deaktiviert
Es gibt bei tg3-Netzwerkkarten schon lange Probleme mit TSO-Frames (TCP Segmentation Offload) und deren Implementierung bietet keine wesentliche Leistungssteigerung. Ab dieser Version sind auf allen tg3-Netzwerkkarten TSO-Frames deaktiviert.
ESX Server antwortet möglicherweise nicht, wenn die bnx2-Netzwerkkarte von NetWatchDog zurückgesetzt wird
Wenn die bnx2-Netzwerkkarte von NetWatchDogzurückgesetzt wird, schlägt die bnx2-Initialisierung fehl. Diese Version von ESX Server enthält einen Fix, der das Zurücksetzen der Netzwerkkarte stoppt, wenn die Initialisierung nach fünf Versuchen von NetWatchDogfehlschlägt, und zeigt eine Meldung ähnlich der Folgenden an:
Jul 15 10:17:09 prme-stg270 VMkernel: 0:00:12:51.090 cpu12:1127)<5>bnx2: giving up resetting vmnic1 initialization failed 4 times
Übermäßige serielle Protokollierung in großen PCPU-Systemen kann zu einem Ausfall von ESX Server-Hosts mit Meldungen auf einem violetten Bildschirm führen
Im Falle einer übermäßigen seriellen Protokollierung in großen PCPU-Systemen kann es zu Ausfällen von ESX Server-Hosts und Meldungen auf einem violetten Bildschirm kommen. Diese Version von ESX Server ändert das Verhalten der seriellen Protokollierung von ESX Server-Hosts. Die serielle Protokollierung ist standardmäßig aktiviert. Die Option logSynchronouswurde in VirtualCenter Server entfernt. Diese Option finden Sie unter VirtualCenter > Konfiguration > Erweiterte Einstellungen > VMkernel > Starten > logSynchronous. Sie können die serielle Protokollierung jetzt aktivieren bzw. deaktivieren wie folgt:
esxcfg-advcfg –s <value> /Misc/LogToSerial
Systeme mit einer Intel igb-Karte generieren eine große Anzahl von Interrupts pro Sekunde
In dieser Version wurde dieses Problem behoben. Mit diesem Fix werden Systeme mit Intel igb-Karten standardmäßig im dynamisch konservativen Modus ausgeführt und diese weisen eine niedrigere Rate von Interrupts pro Sekunde auf. Außerdem ist die TCP-Durchsatzleistung optimal.
Der Befehl esxcfg-firewallgibt einen Panikfehler aus, wenn beim Öffnen mehrerer Ports falsche Eingabe angegeben wird. Dieses Problem wurde in der vorliegenden Version behoben.
Neue Befehlsoptionen wurden eingeführt, um den Wert von maxActive-Uplinks festzulegen und abzurufen
Mit dieser Version von ESX Server gibt es neue Optionen für den Befehl esxcfg-vswitch. Diese Optionen sind -Xund -xund ermöglichen das Setzen bzw. Abrufen des Werts für maxActive.
Ein ESX Server, der auf einem Dell 6650-Server mit BCM5700-Netzwerkkarten installiert ist, antwortet möglicherweise nicht und zeigt einen violetten Bildschirm an.
NetQueue ist standardmäßig deaktiviert in unm_nic
In ESX Server 3.5 Update 5 ist NetQueue im NetXen-Treiber standardmäßig deaktiviert. VMware unterstützt NetQueue auf dem NetXen-Treiber zurzeit nicht.
Behebt ein Pufferbeschädigungsproblem, das in hostd auftritt, wenn gleichzeitig mehrere Clients eine Verbindung mit einem ESX Server-Host herstellen.
Linux-Gastbetriebssysteme verlieren die Netzwerkkonnektivität nach einem VMware Tools-Upgrade
Wenn VMware Tools auf einem Linux-Gastbetriebssystem aktualisiert wird, verliert das Gastbetriebssystem die Netzwerkkonnektivität. Nach dem Upgrade stoppt das Gastbetriebssystem den Netzwerkdienst und startet den Dienst nicht automatisch neu. Dieses Problem tritt auch bei einem automatischen Upgrade von VMware Tools auf Linux-Gastbetriebssystemen auf.
Diese Version von ESX Server unterstützt den Befehl esxcfg-nic -afür BCM5715S-Netzwerkkarten in ESX Server 3.5
Der Firewall-Dienst wird gestoppt, wenn das System in den Einzelbenutzermodus versetzt wird
Wenn das System im Einzelbenutzermodus ausgeführt wird, werden alle netzwerkverwandten Dienste, darunter auch die Firewall-Dienste, gestoppt. Der Firewall-Dienst und alle anderen netzwerkverwandten Dienste werden automatisch neu gestartet, wenn das System wieder in den Mehrbenutzermodus versetzt wird.
ESX Server fällt mit Exception 14in world vsi_traverseaus, wenn der Befehl vm-supportausgeführt wird.
Gastbetriebssysteme können auf das SCSI CD-Laufwerk zugreifen (KB 1008673)
Unzureichender Arbeitsspeicher für COS verursacht einen Systemausfall mit einem violetten Bildschirm
In ESX Server 3.5 Update 5 wurde der für das Console OS (COS) reservierte Arbeitsspeicher erhöht, was die Möglichkeit eines Serverausfalls wegen unzureichendem Arbeitsspeicher reduziert. Diese erhöhte Arbeitsspeicherreservierung steht nur dann zur Verfügung, wenn Sie eine Neuinstallation von ESX Server 3.5 Update 5 durchführen. Wenn Sie auf ESX Server 3.5 Update 5 von einer vorherigen Version von ESX Server aktualisieren, werden die Arbeitsspeichereinstellungen aus der vorherigen Version beibehalten. In diesem Fall, ist es empfehlenswert, je nach Ihren COS-Arbeitsspeicheranforderungen die Menge des reservierten Arbeitsspeichers zu erhöhen und die Auslagerungsdatei zu vergrößern. Sie können die Menge des reservierten Arbeitsspeichers erhöhen und die Auslagerungsdatei vergrößern, indem Sie die Anweisungen unter Reservierten physischen Arbeitsspeicher für COS und die Auslagerungsdatei erhöhen, um ESX Serverausfälle zu verhindern (KB 1013243) befolgen.
Diese Version von ESX Server enthält einen Fix, der einen Mechanismus bereitstellt, der die Leistung der ESX Server-Hosts erhöht, die wegen des IRQ-Sharings möglicherweise beeinträchtigt wurde. Weitere Informationen hierzu finden Sie unter Die Leistung von ESX Server 3.5 ist möglicherweise wegen des IRQ-Sharings beeinträchtigt (KB 1003710).
Ab dieser Version können Benutzer die NTP-Eigenschaften in der UTC-Zeitzone mithilfe des VI-Clients nach dem Installieren von ESX Server festlegen.
Die aktualisierte RDM-Größe wird auf der virtuellen Maschine nicht angezeigt
In früheren Versionen von ESX Server wurde die aktualisierte RDM-Größe nur dann auf virtuellen Maschinen angezeigt, nachdem der ESX Server neu gestartet wurde. Ab dieser Version wird die aktualisierte RDM-Größe in den virtuellen Maschinen angezeigt, indem eine erneute Prüfung der LUN durchgeführt wird. Der ESX Server muss nicht neu gestartet werden.
Mehrere erneute Prüfungen von VMFS-Volumes auf den ESX Server-Maschinen führen zu einem violetten Bildschirm
Wenn mehrere erneute Prüfungen von VMFS-Volumes auf den ESX Server-Maschienen mit mehreren installierten IBM Director-Agenten durchgeführt werden, könnte dies zu einem violetten Bildschirm führen.
In dieser Version wird ein Problem behoben, bei dem während eines Snapshot-Vorgangs virtuelle Maschinen möglicherweise ausgeschaltet werden, wenn auf dem Speicher, wo sich die virtuellen Maschinen befinden, ein Pfad-Failover auftritt.
Ein Failover tritt möglicherweise bei Microsoft-Clustern in CIB-Konfiguration aufgrund der VMFS-Aktivität auf
In einer CIB-Konfiguration (Cluster-in-a-box) tritt aufgrund von Reservierungskonflikten, die aus VMFS-Vorgängen entstehen, die von einem anderen Host durchgeführt werden, der dasselbe Volume gemeinsam nutzt, möglicherweise ein Failover auf. Wenn der Konflikt auftritt, werden im Windows-Ereignisprotokoll SCSI-Fehler protokolliert.
Eine Beschädigung des VMFS-Taktsignals tritt in den VMFS-Volumes auf und führt zu VM-Ausfällen
Wenn in vorherigen Versionen eine Beschädigung des VMFS-Taktsignals in den VMFS-Volumes aufgetreten ist, konnten die virtuellen Maschinen möglicherweise nicht eingeschaltet werden. Die erwarteten Meldungen, die auf eine Beschädigung des VMFS-Taktsignals für das VMFS-Volume hindeuten, wurden jedoch nicht in den VMkernel-Protokolldateien protokolliert. In ESX 3.5 Update 5 werden Protokollmeldungen ähnlich den Folgenden in den VMkernel-Protokolldateien protokolliert:
Mar 24 17:06:25 blr-2nd-1-dhcp274 vmkernel: 0:01:34:08.655 cpu4:1039)WARNING: FS3: ReadHostPulse:1017: FS 49c2390a-1976a3cb-1449-001aa0ae5b61 may be damaged.
Mar 24 17:06:25 blr-2nd-1-dhcp274 vmkernel: 0:01:34:08.666 cpu4:1039)WARNING: FS3: ReadHostPulse:1028: Corrupt heartbeat detected at offset 0x3b9e00: [state 0 offset 0 gen 0 owner 00000000-00000000-0000-000000000000 journalAddr 0
Wenden Sie sich an den VMware-Support, wenn Sie diese Protokollmeldungen klären möchten.
Wenn ein Benutzer die Zuordnung von einigen LUNs aus EMC Invista- oder EMC DGC-Speicher-Arrays aufhebt und die LUNs auf ESX-Hosts erneut prüft, wird die folgende Warnmeldung angezeigt: D:0x0/H:0x0 0x0 0x0 0x0. Diese Warnmeldung wurde in ESX 3.5 Update 5 behoben.
Die vport-Anzahl ist inkonsistent, wenn mehrere mehrfach-NPIV-konfigurierten virtuellen Maschinen gleichzeitig gestartet werden
Dieses Problem tritt auf, weil die virtuellen Ports nicht für alle virtuellen Maschinen erstellt werden. In dieser Version von ESX Server wird die Inkonsistenz in der Anzahl der auf dem proc-Knoten erstellten virtuellen Ports behoben.
Eine Wettlaufsituation in der DentryCache-Initialisierung führt dazu, dass das System mit einem violetten Bildschirm ausfällt.
Zeitüberschreitung bei VMotion auf ESX Server-Hosts, die über eine große Anzahl von inaktiven VMFS-Volumes verfügen
VMotion schlägt möglicherweise fehl auf ESX Server-Hosts, die viele inaktiven VMFS-Volumes haben. Zudem könnte es lange dauern, bis die virtuellen Maschinen auf solchen Hosts eingeschaltet werden.
Der aktive Pfad kann nicht als OFF markiert werden, wenn ein aktiver E/A-Vorgang auf dem Zielspeicher-Array durchgeführt wird
In früheren Versionen von ESX Server können Sie jederzeit die aktiven Speicherpfade als OFF markieren, indem Sie den Befehl esxcfg-mpathvon der Servicekonsole des ESX Server-Hosts, dem VI-Client oder dem VirtualCenter Server ausführen. Ab ESX 3. 5 Update 5 kann der aktive Pfad nicht als OFF markiert werden, wenn ein aktiver E/A-Vorgang auf dem Zielspeicher-Array durchgeführt wird oder wenn es eine aktive Reservierung auf dem Speicherpfad gibt. Die nicht aktiven Pfade dürfen jedoch jederzeit als OFF markiert werden.
Die Möglichkeit, den ESX Server mithilfe eines für TCP-Unterstützung konfigurierten NFS-Servers zu installieren (KB 1015512)
Beim Upgrade von ESX 3.5 auf ESX 3.5 Update 2 schlägt der Upgrade-Vorgang mit dem Fehler More than one vmkernel foundfehl. Dieses Problem tritt möglicherweise beim Upgrade von ESX 3.5 auf eine ESX 3.5-Update-Version vor ESX 3.5 Update 5 auf.
Der esxupdate-Befehl behält die benutzerdefinierten Einstellungen in "/etc/yum.conf" nicht bei
Benutzerdefinierte Änderungen an der Datei /etc/yum.confwerden überschrieben, wenn ein Patch oder eine Update-Version installiert wurde, und die Änderungen gehen verloren. Dieses Problem wurde in der vorliegenden Version behoben.
Das Konfigurieren einer Portgruppe zur Verwendung der Richtlinien "Anhand des IP-Hashs routen" und "Signalprüfung" verursacht doppelte Pakete
Vor dieser Version führte das Konfigurieren einer Portgruppe zur Verwendung der Richtlinie "Anhand des IP-Hashs routen" für den Lastenausgleich sowie der Richtlinie "Signalprüfung" für die Netzwerk-Failover-Ermittlung zu doppelten Paketen. Ab dieser Version lässt der VI-Client eine solche Konfiguration nicht zu und zeigt die folgende Fehlermeldung an:
Das gleichzeitige Einstellen der Netzwerk-Failover-Ermittlung auf "Signalprüfung" und des Lastenausgleichs auf "Anhand des IP-Hashs routen" ist keine gültige Konfiguration. Ändern Sie Ihre Einstellungen.
Es gibt allerdings einige Ausnahmefälle, in denen eine Portgruppe eine Richtlinieneinstellung erben kann, und deshalb die Richtlinien "Anhand des IP-Hashs routen" und "Signalprüfung" gleichzeitig für die Portgruppe aktiviert sind.
Beim Download einer großen Datei mit dem Datenspeicherbrowser oder beim Exportieren einer virtuellen Appliance nach OVF tritt ein E/A-Fehler auf
In früheren Versionen wurde beim Download oder Upload einer großen Datei unter Verwendung des Datenspeicherbrowsers möglicherweise ein E/A-Fehler angezeigt. Dieses Problem tritt auch auf, wenn eine virtuelle Appliance nach OVF exportiert wird.
VI Client zeigt eine große Anzahl an Protokollmeldungen an, die den Text "DiagnosticMgr.Browse" in den hostd-Protokollen enthalten
Wenn Sie mit dem VI-Client eine direkte Verbidung zu einem ESX Server-Host herstellen und unter Verwaltung > Systemprotokolle auf Alle anzeigen klicken, wird in den hostd-Protokollen möglicherweise eine große Anzahl an Protokollmeldungen mit dem Text DiagnosticMgr.Browseangezeigt. Dieses Problem tritt aufgrund eines Fehlers in der Berechnung des Protokollendes durch den VI-Client auf. Dieses Problem wurde in dieser Version behoben.
In einem bestimmten Fall, wenn virtuelle Maschinen auf dem ESX Server-Host für autostart/autostop konfiguriert sind, antwortet der Host beim Herunterfahren möglicherweise nicht mehr. Das für das automatische Starten und Stoppen von virtuellen Maschinen zuständige Skript wurde in dieser Version von ESX Server geändert, um dieses Problem zu beheben.
In dieser Version von ESX Server wurde ein Problem behoben, wobei unmittelbar nach dem Verschieben von virtuellen Maschinen zwischen ESX Server-Hosts mithilfe von VMotion die Leistung der virtuellen Maschinen für kurze Zeit nachlässt.
Dieses Problem könnte unter dem folgenden Szenario auftreten:
In diesem Abschnitt werden bekannte Probleme dieser Version von ESX Server beschrieben. Diese Probleme sind in die folgenden Bereiche aufgegliedert:
Auf einem NEC Express 5800 140Ba-10-Server beansprucht der cimprovagt- oder der cimserver-Vorgang bis zu 99 % von CPU 0 auf dem COS. Dadurch können die verbleibenden Anwendungen, darunter auch snmpd, nicht ausgeführt werden.
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 Redundanzsensor 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, der über zwei physische Stromversorgungen verfügt, 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 2 oder höher kann eine CallMethod-Abfrage auf einer CIM_RecordLog-Instanz manchmal fehlschlagen. Sie können jedoch das Systemereignisprotokoll über eine Remote-Managementkonsole oder -schnittstelle löschen.
Manche CIM-Klassen funktionieren nicht ordnungsgemäß auf IBM Multinode-Systemen
Bei den folgenden Klassen gibt der Vorgang EnumerateInstances()eine Instanz weniger als der Vorgang EnumerateInstanceNames()zurück:
Bei den folgenden Klassen schlägt der Vorgang GetInstance()bei einigen Instanzen fehl. Jedoch ist die Operation EnumerateInstances()erfolgreich:
Die Operationen EnumerateInstances()und EnumerateInstanceNames()geben für die folgenden Klassen keine Ergebnisse zurück:
Ä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.
Firewall auf ESX Server 3.5 führt zu Konflikten mit CIM Indication-Unterstützung
Ausgehende HTTP-Verbindungen werden von der Firewall auf ESX Server 3.5 geblockt. Dies führt dazu, dass Indication-Ereignisse nicht den Indication-Verbraucher erreichen.
Umgehung: Öffnen Sie in der Servicekonsole einen ausgehenden Port für Verbindungen zum Indication-Verbraucher mit dem folgenden Befehl:
esxcfg-firewall -o <port-number>,tcp,out,http
So schließen Sie einen Port für HTTP in der Firewall:
esxcfg-firewall -c <port-number>,tcp,out,http
Solaris Update Manager startet nicht und zeigt im xterm-Fenster schriftartbezogene Fehler an. (KB 1013079)
VMware Tools installiert den SVGA-Treiber nicht automatisch im Windows XP Embedded Studio (KB 1015250)
Der XPDM-SVGA-Treiber von VMware Tools ist unter Windows 7 (32- und 64-Bit) und Windows 2008 R2 instabil. Daher wird dieser Treiber nicht auf virtuellen Maschinen installiert, die diese Gastbetriebssystemversionen ausführen. Wenn Sie auf diesen Betriebssystemen auf die aktuelle Version von VMware Tools aktualisieren, wird auch der SVGA-Treiber entfernt, sofern er vorhanden ist.
Die Energiesparoption in der Liste der Optionen für das Herunterfahren in Windows 7 ist nicht verfügbar
In einer virtuellen Windows 7-Maschine steht die Energiesparoption in der Liste der Optionen für das Herunterfahren nicht zur Verfügung, weil der XPDM-SVGA-Treiber in diesen Gastbetriebssystemversionen von VMware Tools nicht installiert wird. Der Standard-Vesa-Treiber ist enthalten, aber dieser unterstützt die Energiesparfunktion nicht.
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.
Nach der Installation von VMware Tools auf SUSE Linux Enterprise Server 10 mit SP3 kann VMware Tools möglicherweise den schnellen vmxnet-Netzwerkdienst nicht starten.
Umgehung:Führen Sie die folgenden Aufgaben aus:
Beantworten Sie während der Installation von VMware Tools die folgende Frage mit NEIN:
Vor der ersten Ausführung der VMware Tools müssen Sie diese mit dem folgenden Befehl konfigurieren: "/usr/bin/vmware-config-tools.pl". Soll dieses Programm jetzt den Befehl für Sie ausführen?
Führen Sie nach der Installation der VMware Tools den folgenden Befehl aus:
vmware-config-tools.pl --compile
Sämtliche Felder im VI-Client und in Web Access bieten 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
Anzeigeeinschränkungen für Nicht-ASCII-Zeichen
Einschränkungen in Bezug auf die gesteuerte Konsolidierung
Übersetzungsprobleme
Für diese Version sind folgende Übersetzungsprobleme bekannt:
Weitere Internationalisierungsprobleme
Es wurden folgende zusätzliche Probleme festgestellt:
Einige Dell-BIOS-Systeme weisen möglicherweise doppelte Interrupt-Routing-Einträge in der ACPI-Tabelle auf (KB 1013804)
Systemstatus unvollständig nach der Installation von HP Insight Manager (KB 1015607)
Die IBM Director Server 6.1.1.1-Web-Schnittstelle mit dem installierten IBM Director 6.1.2-Plattformagenten zeigt die MAC-Adresse des vmnic als den Namen der LAN-Verbindung an. Verwenden Sie zum Abrufen des Namens der LAN-Verbindung die Eigenschaft ElementName.
Die Netzwerkkonnektivität geht auf manchen Intel-Netzwerkkarten nach einem Neustart des ESX Servers verloren (KB 1015620)
Wenn ESX Server mit einer Kickstart-Datei installiert wird, werden nach dem Neustart die Firewall-Regeln zurückgesetzt
Wenn Sie ESX Server mit einer Kickstart-Datei installieren, in der Authentifizierungsserver, wie z. B. NIS und Active Directory, angegeben sind, werden die Firewall-Regeln für diese Server nicht gespeichert. Nach einem Neustart werden die Firewall-Regeln auf die Standardregeln zurückgesetzt. Eine Umgehung finden Sie unter KB 1001154.
ESX Server unterstützt nicht mehr als eine vmknic auf demselben Subnetz. (KB 1013077)
Link- und Unlink-Vorgänge auf dem vSwitch aktualisieren die Gruppierungsrichtlinie des vSwitches dort, wo sich die Portgruppe befindet, nicht ordnungsgemäß
Wenn eine Portgruppe zusammen mit einer NIC-Gruppierungsrichtlinie angegeben wird (anstatt die Richtlinie von dem vSwitch zu übernehmen), wird ein Link- oder Unlink-Vorgang auf dem vSwitch (durch Ausführung des Befehls esxcfg-vswitch -L/-U <vmnicX> <vSwitchY>) die Gruppierungsrichtlinie des vSwitches, wo sich die Portgruppe befindet, nicht ordnungsgemäß aktualisieren. Der Status ("Aktiv" oder "Standby") der Uplinks wird im VI-Client möglicherweise nicht korrekt angezeigt. Die Anzahl der aktiven Links entspricht der in der Einstellung des ursprünglichen Gruppierungsrichtlinie der Portgruppe angegebenen Anzahl.
Der ypbind-Dienst (NIS) startet nicht nach dem Startvorgang des Servers
Der ypbind-Dienst startet nicht nach dem Starten des ESX Server, obwohl ypbindstandardmäßig aktiviert ist. Dies kann passieren, wenn entweder der portmap- oder der ypbind-Dienst nicht ordnungsgemäß konfiguriert ist, um zur Startzeit zu starten. Fehlerbehebungstipps und Lösungen finden Sie unter KB 1015289.
ESX-Maschinen, die passive MSCS-Knoten hosten, melden Reservierungskonflikte bei Speichervorgängen (KB 1009287)
PS/2-Tastatur funktioniert nicht mehr mit ESX Server nach dem Upgrade auf ESX Server 3.5 Update 5 (KB 1011852)
Das Ein- oder Ausschalten einer virtuellen Maschine mithilfe von Web Access führt dazu, dass mehrere redundante Fehlermeldungen in hostd.log protokolliert werden
Wenn Sie eine virtuelle Maschine mithilfe von Web Access ein- oder ausschalten, werden alle 2 bis 3 Sekunden Fehlermeldungen ähnlich der Folgenden in die Datei hostd.logim Verzeichnis /var/log/vmware/geschrieben:
Throw vmodl.fault.ManagedObjectNotFound
Wenn Sie eine deutsche, japanische oder chinesische (vereinfachtes Chinesisch) Sprachunterstützung für den Einsatz von Virtual Infrastructure Web Access oder dem VI-Client mit Ihrem ESX Server-Host wünschen, muss sich das Sprachpaket auf dem Host befinden und das Standardgebietsschema muss auf Ihre gewünschte Sprache gesetzt sein. Ab ESX Server 3.5 Update 3 werden die Sprachpaketdateien auf allen Hosts installiert und müssen nicht auf den Host kopiert werden, bevor das Gebietsschema geändert wird.
So legen Sie das Standardgebietsschema auf dem Host fest.
Ersetzen Sie für Deutsch die Zeilen durch die folgenden Zeilen:
<locale>
<DefaultLocale>de_DE</DefaultLocale>
</locale>
Ersetzen Sie für Japanisch die Zeilen durch die folgenden Zeilen:
<locale>
<DefaultLocale>ja_JP</DefaultLocale>
</locale>
Ersetzen Sie für Chinesisch die Zeilen durch die folgenden Zeilen:
<locale>
<DefaultLocale>zh_CN</DefaultLocale>
</locale>
service mgmt-vmware restart
service vmware-VMware Web Access restart