Datenfront

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

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

Seit dem 21. Juli verdichten sich die Gerüchte um ein großes Treiberproblem innerhalb der Standardtreiber für VMware ESX 4.0.0.
Dabei handelt es sich wohl um ein Problem mit lokal eingebauten und eingebundenen Bus Adaptern zur Massenspeicheranbindung, näher um LSI und Adaptec basierte Controller für SAS, (Parallel-) SCSI und S-ATA Festplatten. Werden diese in einem Host verwendet, so kann es unter Umständen dazu kommen, dass im Falle einer Abschaltung des Servers der Cache der Adapter nicht ordnungsgemäß auf die angeschlossenen Festplatten geschrieben wird. Das führt wiederum unweigerlich zu korrupten Daten, wenn die Batterie der RAID Controller leer läuft und im Fall von lokal angeschlossenen VMFS Laufwerken auf einem Host wahrscheinlich zu Datenverlust!
Da beim ESX 4.0 Server die SC als VMDK Datei auf dem lokalen VMFS Laufwerk vorgehalten wird, sollte der Patch unverzüglich auf alle ESX 4.0.0 Systeme gleich welcher Patch- / Buildstand ausgebracht werden. Der ESXi Server ist davon zur Zeit nicht betroffen.


Der Fehler wurde von VMware bereits veröffentlicht:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1012794


Gestern habe ich dazu eine sehr wichtige E-Mail über meine DELL Kanäle erhalten.
DELL geht davon aus, dass in den nächsten Tagen (03.08.) ein ausserplanmäßiges Update bereitgestellt wird, das den Fehler im Treiber behebt.
Die Tests laufen wohl schon, dauern allerdings bis zu 2 x 48h, da der RAID Controller/Cache nur alle 48h eine vollständige Entladung der Batterie erfährt.

Man sollte jetzt nicht panisch reagieren und ein Downgrade auf die Version ESX 3.5.0U4 durchführen, sondern dafür sorgen, dass die Server am (Strom-)Netz bleiben und nicht längerfristig vom Strom getrennt werden. Dazu sollte man die DPM Funktion in vSphere 4.0 temporär auf manuell setzen oder komplett abschalten.

Heute Nacht hat VMware einen Fehler in der Hauptspeicherverwaltung für virtualisierte / emulierte Treiber veröffentlicht, der auf den ersten Blick nur nicht gepatchte Systeme der aktuellen Versionen von ESX(i) betreffen.


Bei secunia wurde der Fehler als weniger kritisch eingestuft. Ich unterstütze diese Ansicht in Teilen. Für virtualisierte Serverumgebungen ergibt sich ein deutlich geringeres Gefährdungspotential, als für virtualisierte Arbeitsplatzumgebungen unter VMware View alias VDI.

http://secunia.com/advisories/32965/

http://lists.vmware.com/pipermail/security-announce/2008/000046.html

Update der VMware Tools notwendig!
Liest man sich die entsprechenden Knowledgebase Artikel durch, fällt direkt auf, dass die VMware Tools geupdatet werden und das neue Paket in alle Gäste ausgerollt werden muss, damit die Systemintegrität wieder hergestellt werden kann.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007501

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007504

Administratoren der Umgebungen sollten zeitnah das Update testen und verproben und gegebenfalls ausrollen.

Yesterday was one of those days I will not forget very soon. so what happened exactly, I don't know, but a lot of glass is being broken on that VMware "Dooms-Day".
But they worked hard to fix it up:

1. Make sure You don't turn back time in your environment!!!
   Some customers reported, although having NO time sync within the VMs running towards the hosts, time is being set back! One of my customers ran in this nightmare .
   I don't know what really happened exactly and I'm still wondering about this and this is still under investigation with the DELL Pro Support EMEA team.
   
   
2. Be patient and install the fixes as needed. But please test these patches carefully, because it seems that the complete kernel of VMware is being superseeded by these patches!
   Nobody knows (outside VMware) what was the real issue of this bug and from what point of kernel-build they fixed and recompiled the kernel sources. I'm looking forward to getting any information about this special issue from my sources at VMware.
   I'm testing this patch today in the morning and will give a fast feedback on my first impressions.
   
   Fix for ESX 3.5 Update 2 can be found here.
   The description of the patch is here.
   
   Fix for ESXi 3.5 Update 2 can be found here.
   The description of the patch is here.
   
   
3. Follow the guidelines from VMware to installing these very critical patches!
   Instructions can be found here.
   
   

As several news services report, there is a timebomb within the licencing System of VMware Infrastructure.
VMware has not found the source for the bug and claims for using an earlier time period within VMware ESX(i) Hosts and VC Server as well.

Be very careful in doing so, because of the logging of the VC database can be corrupt, or lose data because of rewriting the "real" old data with the new ones.
I'm trying to figure out how far you can go back (or may be into the future!)

The link to the knowledge base article is here

To workaround do as followed:

1. stop ntpd service on each ESX host with version mentioned above (ESX 3.5.0.103908). service ntpd stop
2. check that the service isn't running anymore. service ntpd status
3. set a date in the past maybe something like june 12th 2008, same time!

Then please go to your updatemanager to prevent systemes to install ESX 3.5.0 Update 2!

1. Open VI Client and install and enable the update manager client.
2. Navigate to the update manager (click the button!).
3. Change the default baseline for non critical host updates and exclude the esx 3.5.0 Update 2 patch.
4. the baseline should now show the annex "modified" in brackets behind the baseline type.

That's it for the very first time, so stay tuned on any broadcasting service for updates

From yesterday in the morning until now the Update 2 sources on the VMware website are still disabled!