Neuer Patch von VMware: ESX(i) 4.0.0U1a

Friday, 11 December 2009 18:07:42 (W. Europe Standard Time, UTC+01:00)


Nachdem es doch einige Probleme mit dem neusten Updatepaket von VMware gibt, hat der Softwarehersteller eine zweite Auflage des Update1 Paketes für ESX(i) 4.0.0 herausgebracht. Der Patch ist vornehmlich an alle Kunden gedacht, die zum Einen Hardwareagenten in der Service Console oder modifizierte ESX(i) Varianten einsetzten und zum Zweiten die Updatepakete per Updatemanager installieren.
Neben dem ersetzenden Update1 Paket kommt direkt noch ein weiterer Patch für das GLIBC Paket mit, das auch außer der Reihe publiziert worden ist.
Kunden die bereits Update1 auf den ESX(i) ausgebracht haben erhalten lediglich ein Update der GLIC Bibliothek und eine Änderung in der Paketverwaltung von RedHat (RPMD).
Das Updatepaket kann jetzt, wie gewohnt über den UpdatemNager auf die Hosts ausgebracht werden.

Alle Knowledgebase Artikel zum Patch:

KB1016070

Due to a possible dead lock on rpmdb, upgrading ESX 4.0 to 4.0 Update 1 can fail or time out and leave the host in an unusable state

http://kb.vmware.com/kb/1016070

KB1016262

vCenter agent service does not install or upgrade on ESXi 4.0 hosts

http://kb.vmware.com/kb/1016262

KB1014842

VMware ESX 4.0, Patch ESX400-Update01a

http://kb.vmware.com/kb/1014842

KB1014797

VMware ESX 4.0, Patch ESX400-200912101-UG: Updates Service Console glibc

http://kb.vmware.com/kb/1014797


PSOD nach Update auf VMware ESX 4.0.0 Update1

Wednesday, 25 November 2009 12:54:20 (W. Europe Standard Time, UTC+01:00)
Gestern erhielt ich eine E-Mail von Kollegen aus den Staaten, dass es derzeit zu Problemen mit dem Einspielen des Update1 Paketes über den VMware Update Manager für den ESX Server kommen kann.
Die Probleme können genau dann entstehen, wenn auf der Service Console eines ESX 4.0 Systems Drittanbieter Agenten installiert worden sind und diese im Status "laufend" sich befinden.
Inwiefern auch ein Upgrade der Version ESX 3.x auf ESX 4.0.0U1 betroffen ist oder die manuelle Installation in der SC selber oder über das "Host Update Utility" des vSphere 4.0 Clients betroffen ist, kann ich und konnten meine Kollegen weder bestätigen noch ausschließen. Generell empfehle ich mit dem Update auf Version ESX 4.0.0 U1 und auf ESXi 4.0.0 U1 zu warten.
Als Workaround bietet der Hersteller Vmware untwer dem folgenden KB Artikel eine Lösung für das Problem an:

http://kb.vmware.com/kb/1016070

Will man also ein System aktualisieren, auf dem zum Beispiel eine Hardwareüberwachung wie DELL OMSA oder HP Insight Manager installiert worden ist, so sollten diese Dienste vor dem Start der Aktualisierung in der SC deaktiviert werden. Nach der Installation und dem Neustart des Hosts können die Agenten wieder gestartet werden.
Hat ein Kunde bereits die Installation ausgelöst, so ist umgehend ein Support Call bei VMware zu eröffnen, da es ansonsten zu Datenverlust kommen kann. Betroffen davon sind insbesondere Systeme mit lokal angeschlossenem Storage. iSCSI und FC Laufwerke sollen allerdings nicht dieses Fehlerbild aufweisen. Wir bleiben dran...

Erste Updates für vSphere 4.0

Friday, 17 July 2009 22:10:15 (W. Europe Daylight Time, UTC+02:00)
Nachdem die RTM / GA Version von VMware vSphere 4.0 seit dem 22. Mai verfügbar ist wurden die ersten Updates für den ESX(i) Server 4.0.0 veröffentlicht. Das Updatepaket beinhaltet dabei einige wichtige Sicherheitsupdates für Linux Module innerhalb der aktuellen SC mit dem modifizierten RHEL 5.1 für x86-64.

Das Updatepaket von VMware für die einzelnen Varianten von VMware ESX 4.0.0 wurde mit Größen zwischen 163,4MB und 377,9MB nicht gerade klein.
Parallel dazu wurden die ISO Dateien auf der Downloadseite angepasst und tragen nun den folgenden Build-Stand:
VMware ESXi installable VMware-VMvisor-Installer-4.0.0-171294.x86_64.iso
VMware ESX "Classic"    esx-DVD-4.0.0-171294.iso

Ich bin gespannt wann das vCenter geupdatet wird, da es zur Zeit zwei kleinere Probleme gibt:
  1. Reboot der vCenter VM an einem dvSwitch schlägt fehl, genau wie das Clonen / Deploy an eine dvSwitch Portgruppe
  2. Memory-Leak in der Tomcat Server Engine
Es bleibt also spannend!

VMware Virtual Center 2.5.0 Update 3 ist da!

Saturday, 04 October 2008 07:46:08 (W. Europe Daylight Time, UTC+02:00)
Das jüngste Update Paket für das VirtualCenter beseitigt unter anderem Probleme mit dem Wartungsmodus & dem UpdateManager!



Wie immer im Verborgenen erblickte das neueste Kind von VMware das Licht der Welt. Das Update 3 ist da!
Da es in der bisherigen Version erhebliche Probleme mit der Berechnung der HA Kapazitäten in Verbindung mit dem UpdateManager und der benötigten vMotion Technologie gab, hat VMware diesen Schritt vorgezogen. Aber erstmal alles Schritt für Schritt:

Problem:
Insbesondere in kleineren Umgebungen mit zwei oder drei ESX Servern kann man einen produktiven ESX Server nicht mehr so einfach in den Wartungsmodus versetzen, insbesondere dann, wenn auch noch VMware HA auf Clusterebene eingestellt worden ist. Der Server startet mit dem Wartungsmodus und bleibt bei genau 2% stehen, bricht mit Fehler ab.
Betrachtet man af der Zusammenfassungseite die Clusterkonfiguration stellt man fest, dass die konfigurierte Failover Quote für HA auf ein Host eingestellt ist und die verfügbare Clusterkapazität den Ausfall von "NULL" Hosts erlaubt?!
Der kluge Administrator baut vor und hat extra für das kleine Cluster eingestellt, dass auch dann im HA Fall VMs neu gestartet werden, wenn die Kapazitätsgarantien für die VMs auf "erlaubt" gestellt.
Zusätzlich wurden die das.VmMemoryMinMB und das.VmCpuMinMHz gesetzt und trotzdem nix Wartungsmodus!?

Workaround:
Temporär die Clusterfunktion HA ausschalten. Die Konfiguration des Clusters geht dabei NICHT verloren (liegt in der VCDB) und im Anschluss an die Updateeinspielung wieder einschalten. Dabei wierden zunächst die Konfiguration und Pakete vom ESX Server deinstalliert und entfernt und im Anschluss wieder neu installiert.

Lösung:
Das Update 3 für VMware VirtualCenter behebt dieses Problem, auch in kleinen Clustern mit zwei bis drei Hosts klappt das einstellen des Wartungsmodus jetzt wieder problemlos und man kann auch über den UpdateManager wieder Patches einspielen.

demnächst mehr zum Thema VI 3.5 Update 3 hier!

VMware UpdateManager lädt keine Updates herunter

Monday, 15 September 2008 22:33:00 (W. Europe Daylight Time, UTC+02:00)
Der VMware UpdateManager (VUM) ist eine der Neuerungen in VI 3.5. Neben der Herausforderung der Installation und Konfigration des VUM kommt es immer wieder im Kundenumfeld zu Problemen mit dem Internetzugang für den VUM. Viele Firmen verwenden einen Proxyserver mit Authentifizierung für den Zugang zum Internet. Erschwerend für den VUM kann hinzukommen, dass der Kunde eine Proxykaskade einsetzt um einen mehrfach abgesicherten Zugang zum Internet zu bieten und / oder Zusätzlich Inhaltsfilter einsetzt, die das Herunterladen von EXE Dateien oder TAR Archiven unterbindet. Diese Konfigurationen lassen sich noch handhaben aber dazu mehr in einem separaten Blogeintrag später.