Seit mehr als 16 Jahren begleiten mich mehr oder weniger Server in meinen privaten 4 Wänden doch irgendwann hat alles ein Ende. Die Hoheit (meine Frau) hat sich durchgesetzt und mir meine “Spielwiese” bestehend aus 2 ESX Hosts mit 32 GB RAM und unzähligen VM’s ausgeredet.

Nach, wie ich heute beim herunterfahren des letzten Hosts feststellen konnte, 86 Tagen seit dem letzten Server Reboot aufgrund eines Updates werden diese Hosts nur mehr für kurze Momente aufgebaut, eingeschalten und für Testläufe verwendet. Ansonsten fristen Sie Ihr Dasein nur mehr als Staubfänger und Errinnerungen der guten alten Zeiten!

Ich danke euch! (für die vielen schlaflosen Nächten, weil eine HDD kaputt wurde, oder der CPU Lüfter nicht mehr rund lief und laut vor sich hinsurrt)

VMware hat einen Knowledge Base Artikel dazu veröffentlicht der genau diesen Effekt behandelt. Hier der Link zu VMware.

Beide Updates (KB 2482017 und 2467023) sind durch den letzten Microsoft Patch Day ausgerollt worden und betreffen beide Windows7 Versionen (32bit & 64bit) auf denen VMware View Client läuft.

• User die dieses Update auf Ihren Client installiert haben können entweder Ihre VMware View Client Installation auf Build 353760 updaten

• VMware empfiehlt auch für User die noch nicht die 2 Hotfixes installiert hat vor dem Update die neueste Build Version des VMware View Client zu installieren und dann erst die MS Hotfixes installieren sollen.

Nach dem Update auf den aktuellesten Client funktioniert die VMware View Umgebung wieder einwandfrei.

Folgendes Szenario hat sich am vergangenen Dienstag ergeben:

Mein virtueller Mailserver (Ubuntu 8.0.4 mit Zimbra 6.0.6) meldete I/O Read-Write Errors und stand nur mehr im Readmode. Ebenfalls ist mein vCenterServer gecrashed. Nach genauerer Untersuchung musste ich feststellen, daß eine Platte im VMFS3 Store bad blocks hatte und diese genau meine vmdk’s der betroffenen VM’s beinhalten.

Was tun? Jeder andere hätte wahrscheinlich aufgegeben und die VM’s neu installiert – ich wollte aber unbedingt die Daten retten und habe mich an die Arbeit gemacht mit HDD Recovery Tools (die alle nicht für VMFS3 partitionierte Festplatten gemacht sind) zumindest einen Teil der Daten zu retten. Und gleich vorweg – es war erfolgreich, denn sonst hättet Ihr unter www.vdi-guru.com keine Seite mehr erhalten. (Der Webserver ist ebenfalls eine der betroffenen VM’s gewesen)

Somit bin ich der erste (zumindest der erste der im großen weiten Internet darüber berichtet) Consultant der es geschafft hat eine defekte HDD mit VMFS3 Store wieder ohne Datenverlust zu retten!

Aber ich will kein Geld für dieses Know How! Ich teile hier mit euch die notwendigen Schritte und möchte allen anderen VM-Gurus die Suche nach einer Lösung des Problems ersparen und einen Lösungsweg zeigen.

Als erstes: Kläre ob die HDD überhaupt noch läuft. Also fährt sie noch an und kann man zumindest Teile auf der Platte lesen. Bei mir war es überhaupt kein Problem – zumindest solange man keinen “echten” Traffic auf der Platte hatte.

So sind zum Beispiel meine VM’s nach dem Restart des ESXi Hosts problemlos nach einem Datarecoveryprocess (fsck) wieder hochgekommen und haben Ihren Dienst angeboten. Also versuchte ich die VM-Directories einfach auf eine andere LUN zu kopieren. Das ging bis zu einer gewissen Datenmenge sogar gut. (einzelne Dateien sind problemlos kopiert worden) Nur ab einer gewissen Datenmenge stoppte der Kopierprozess mit Buffer I/O Error. Alle Versuche egal ob mit scp, vmkfstools waren erfolglos.

Nach genauerer Analyse der HDD stellte ich defekte Blöcke fest und somit war mir klar um noch eine Chance zu haben, die Daten zu retten, muss ich versuchen die Platte zu klonen. 500GB HDD’s habe ich zum Glück genügend und so schaufelte ich eine 500GB HDD frei und begann mit einem der besten Tools (Parted Magic) eine Live CD zu booten und meine beiden 500GB HDD’s zu prüfen. Tatsächlich! Die VMFS3 Platte hat defekte Blöcke.

Nach vielen Stunden Suche ob jemand eine VMFS3 formatierte Platte einmal retten konnte habe ich leider keinen einzigen Eintrag über eine erfolgreiche Aktion gefunden. Also musste ich mich trauen!

Das Tool meiner Wahl war “ddrescue” .

Damit wird die komplette HDD gescannt, ein Logfile angelegt und anhand des Logfiles die Daten auf eine neue HDD kopiert. Danach wird versucht die defekten Blöcke zu splitten um den Datenverlust so gering wie möglich zu gestalten.

Dieser Kopierprozess dauert ziemlich lange – Geduld ist angebracht. Bei mir lief der erste Prozess ca. 12 Stunden und das waren keine sehr angenehme Stunden. Erst als der Kopierprozess abgeschlossen war und der nächste Schritt, daß “Trimming”  begonnen hat konnte ich mich dazu überreden schlafen zu gehen. Weitere Stunden später kam aber das erste “aufatmen” als der eigentliche Kopiervorgang erfolgreich abgeschlossen war und ddrescue sich mit den “defekten” Blöcken beschäftigte.

Dieser Schritt ist erbärmlich langsam. Versucht ddrescue ja beinahe unendlich lange einen einzigen Block auf der gesamten Platte zu verteilen um die “defekte Dateigröße” so klein wie möglich zu gestalten. Hier muss man geduldig sein und den Server arbeiten lassen. Bei mir ein Prozess von über 34 Stunden!!

Aber danach kann man sich endlich mit der erfreulicheren Tätigkeit beschäftigen. Das mounten der neuen Festplatte und das kopieren bzw. verschieben auf eine für den ESX Host lesbare LUN. Ich habe einfachheitshalber die lokale HDD des ESXi Hosts und den Midnight Comander dazu verwendet.

Nun sind die Daten auf einem VMFS3 Store und können von dem lokalen Store auf die shared storage wieder kopiert werden und danach wieder im vcenter Server eingebunden werden.

Ist das dann erledigt kann man sich auf die Schultern klopfen und einem ursprünglich katastrophalen Datenverlust abhaken und wieder mit positiver Einstellung sich den eigentlich spannenden Tätigkeiten widmen.

Für Fragen und Tips stehe ich gerne via email zur Verfügung

Die Kernthemen der Verbesserungen klingen fürs erste perfekt – wäre da nicht ein kleiner Haken. VMWare’s Servervirtualisierungstruppe dürfte mit der Desktopvirtualisierungstruppe nicht sehr eng zusammenarbeiten. So setzt die Managementlösung vCenter Server 4.1 ein 64bit Betriebssystem vorraus, der für VMWare View 4 notewendige View Composer in der aktuellen Version 2.0 unterstützt aber kein 64bit VCenter.

Was nun? Die Vorteile des neuesten Virtualisierungsprodukts nutzen, und View 4 in einem anderen vCenter Server betreiben, oder gar auf das neueste Release verzichten und weiterhin auf die schon mehrmals verschobene Veröffentllichung von View 4.5 warten?

Ich persönlich bin zutiefst über die “Verzögerungstaktik” enttäuscht, war ich doch immer ein Verfechter von VMWare’s Desktopvirtualisierungslösung, aber die derzeitige Unternehmenspolitik  lässt mich immer öfter nach “Alternativen” für meine Kunden umsehen.

Bleibt abzuwarten, wie der Markt reagiert – die ersten Kundenreaktionen waren negativ und so häufen sich bei mir die Anrufe, was man denn nun tun soll.

Ich werde meine Demo-Umgebung zur Zeit auf dem noch alten und komplett unterstützten Release vSphere 4.0 laufen lassen und rate dies zur Zeit auch meinen Kunden.

Die auf KVM beruhende Virtualiserungslösung kann virtuelle Maschinen sowohl unter Windows als auch unter Linux hosten sowie verwalten und zeichnet sich durch hohe Performance aus. Zusätzlich kann die Software Gast-Systeme mit bis zu 16 virtuellen CPUs und 256 Gigabyte Speicher pro virtueller Maschine unterstützen.  Zu den Neuerungen zählt auch die Fähigkeit, Images virtueller Maschinen im Open Virtualisation Format (OVF) zu im- und exportieren. Mit dem Tool V2V können virtuellen Maschinen unter VMware oder Xen für den Einsatz unter RHEV konvertiert werden.

So ist ein komfortabler Migrationsweg für alle frustrierten Virtualisierungskunden möglich und macht den Weg für eine zukunftsweisende Technologie bereit

Für mich viel interessanter war die Präsentation von RedHat’s Desktopvirtualisierungslösung.
Mit “Red Hat Enterprise Virtualization for Desktop 2.2″ können virtuelle Windows- und Linux-Desktops verwaltet werden. Die Remote-Rendering-Technik “Spice” sorgt dabei für Multimediafähigkeiten und eine dynamische Lastverteilung zwischen Server und Client. So stellt die Wiedergabe es HD-Videos auf einem Client kein Problem da. Erste Tests haben das in meiner Umgebung bestätigt und stellt für mich eine durchaus überlegenswerte Alternative zu VMWare’s View 4 und Citrix XenDesktop4 dar.

Interessant wird auch die Alternative zu Windows basierten Desktopsystemen die immer mehr von Kunden angefragt werden und die zur Zeit mit View und XenDesktop nicht ermöglicht werden können.

Wie dort zu lesen ist, und wie ich in der Community ebenfalls immer öfter erfahre sieht man bei Suse eine Änderung in der Bereitschaft Xen weiterhin zu unterstützen.

Bleibt noch abzuwarten, ob und wann Suse sich komplett von der Xen Unterstützung löst und genauso wie RedHat KVM priorisiert.

Immer mehr Pressemeldungen gelangen nach Europa die eine Verschiebung vom Announcement von VMWare’s View 4.5 betrifft.

Ein spitzenmäßig geschriebener Artikel ist wie meisstens auf Brian Madden’s Blog zu lesen.

Ich bin schon sehr gespannt was denn nun endlich offiziell von VMWare kommt, da einige meiner Kunden dringend auf dieses Release (Windows 7  Support und mehr) warten. Ich bin in die nähere Entwicklung von View 4.5 nicht eingebunden, da mich zur Zeit andere Kundenprojekte beschäftigen.

Sobald wir aber nähere Infos dazu erhalten haben, werden wir wieder berichten!

Nun hat man meinen Wunsch, eine Videoreportage darüber zu machen erhört und Brian Madden und Gabe Knuth haben im Rahmen derer Geek Week ein sehr eindrucksvolles Video zum Thema Performance in 3 verschiedenen Szenarien gedreht.

Unter diesem Link kommt Ihr direkt zur Videoreportage und könnt euch ein eigenes Bild über die Performance machen.

Viel Spaß beim Video gucken.

Zuerst aber noch eine Warnung!!!

Installiert keine XenServer 5.5 U2 auf aktuellen HP Blades mit der Firmware höher als 4.8.0!!! So unglaublich es klingt, aber Citrix hat sein neuestes Virtualisierungsprodukt
Xen Server 5.5 U2 nicht mit aktuellen Betriebssystemtreibern ausgeliefert und diese haben Probleme mit der aktuellen Firmware von HP’s BladeCentern.
Im speziellen geht es um die Firmware für die Boradcom 10GB NICS.

Es gibt bei der Installation auf diesen Blades keine speziellen Fehlermeldungen, aber der Netzwerktraffic funktioniert dann nicht mehr und die NICs werden als “not connected” bezeichnet.

Offizielles Statement von Citrix: Please downgrade the firmware on your Broadcom 10GB NICS to 4.8.0.

Ich bin mit dieser Aussage natürlich nicht zufrieden gewesen und habe einen nicht besonders schönen, aber funktionierenden Workaround gefunden, empfehle aber jedem auf die nächste Version von Citrix’s Xen Server zu warten,
da zu erwarten ist, daß Citrix hier endlich aktuelle Treiber mitpackt.

Nun aber zu den positiven Dingen. Citrix Xen App 6.0 und Citrix Provisioning Server – mein aktuelles Traumpaar!

Auch die mir zur Zeit vorliegende TechPreview begeistert! Bis auf ein paar kleinere Stolperfallen läuft diese Version bereits in meiner Pilotumgebung einwandfrei. Auch das streamen von XenApp 6.0 TP VHD’s funktioniert und so kann man
innerhalb von kürzester Zeit eine neue parallel betriebene XenApp6 Farm hochziehen und betreiben.
Die Performance des Citrix Provisioning Server’s in der Version 5.2 begeistert mich! Ohne Probleme meistert dieser die Bereitstellung von 10 XenApp Servern in meiner Umgebung und bietet so 514 Usern einen gesharten Desktop im Look & Feel von Windows 7.
Paralell haben wir in diesem Projekt auch XenDesktop4 mit ebenfalls Windows7 Clients am laufen und der genialste Geniestreich meines Kundens war einen User die Frage zu stellen auf was für einem System der User gerade ist und dieser antwortete, na klar auf einem Win7 Desktop.
Dem war natürlich nicht so – er befand sich auf einem Terminal Desktop und hatte die selbe Arbeitsumgebung wie auf dem Win7 Desktop.

Also Leute, ich kann euch nur empfehlen schaut euch das Thema genauer an! Am 24.3. soll XenApp6 final gehen und spätestens dann solltet Ihr alle eure Kunden schön langsam auf den Geschmack von echter 64bit Terminalserverarchitektur bringen.

Ich werde bei Zeiten etwas ausführlicher berichten und auch ein paar Screenshots liefern.

Bis dahin – viel Spaß beim testen!

Wie Amilcar Alfaro, Senior Product Manager bei Microsoft in einem Interview verlautbaren ließ, wird Microsoft in seinem Lizenzmodell für “Virtual Enterprise Centralized Desktops” (VECD) im Laufe des Jahres 2010 einige Restriktionen aufheben. Dies wird endlich den Weg für viele Desktopvirtualisierungsprojekte ebnen und die von mir immer wieder angesprochene Hürde aufheben.

Das Interview findet ihr hier

Ich freue mich, wenn diese Änderungen endlich umgesetzt werden, hier sofort berichten zu können.