Wir haben seit einiger Zeit das Problem, daß wir zwei virtuelle Maschinen auf unserem ESXi Host nicht mehr sichern können (wir erledigen die Sicherung ja mit VMExplorer, der einen Snapshot anfertigt), weil die beiden VMs mit der Meldung “Create Virtual Machine Snapshot” auf ewig in der Taskliste des ESXi stehen bleiben und dann auch keine weiteren Aktionen aus dem vSphere Client für diese beiden Maschinen mehr möglich sind.

Erster Schritt: Patchlevel anpassen, denn unser ESXi ist noch im Urzustand, wie er bei der Installation war. Zum Patchen muß der ESXi Host zunächst im Maintenance Modus sein, dazu müssen alle virtuellen Maschinen heruntergefahren werden:

Wenn alle Systeme heruntergefahren sind, dann kann man den ESXi Server in den Maintenance Modus schalten (das kann man zwar auch aus dem Host Update Utility, wenn das aber fehlschlägt, dann war das ganze Patchscannen umsonst, daher finde ich es sicherer, wenn der Host vorher im Maintenance Modus ist):

Wenn er im Maintenance Mode ist:

ruft man das “VMWare Host Update Utility v4.0″ auf, das wird bei der Installation der vSphere Konsole mit installiert. Man meldet sich an seinem Host an (bzw. trägt den ESXi Host ein, wenn das noch nicht geschehen ist) und klickt “Scan for Patches”

Wenn das erledigt ist, dann wird angezeigt, wieviele Patches gefunden wurden und ein Knopf “Patch Host” wird aktiv:

Das zeigt die Patches im einzelnen an und bringt einne Knopf “Install”:

Je nach Anzahl der Patches kann das eine Weile dauern, es sollte am Schluß die ersehnte Meldung “Patching has succeeded” angezeigt werden:

Nun den ESXi Server rebooten:

Wenn er sauber hochfährt (ohne Virtuelle Maschinen, denn er ist im Maintenance Modus), dann kann man den Maintenance Modus verlassen:

und nochmal Rebooten. Danach sollte ein erneuter Aufruf des Host Update Utility melden “Host is up to date”:

Fertig? Leider noch nicht, denn die VMWare Tools aus den Stationen sind noch alt und müssen aktualisiert werden. Das kann man für mehrere VMs auf einmal oder einzeln nacheinander aus dem Guest Menü machen:

Achtung: Das fährt die Stationen nochmal runter! Am Ende sollte der VMWare Tools Status überall OK sein:

Fertig!

Der Update auf Wordpress 2.9 ist ein guter Anlass, mal zu dokumentieren, wie der Update auf der Basis eines Jumpbox Servers funktioniert. In einem meiner ersten Artikel im Blog habe ich ja beschrieben, daß ich den Wordpress Server nicht von Grund auf aufgesetzt habe, sondern eine Jumpbox benutzt habe.

Jumpbox ist ein Anbieter, der fix und fertig installierte OpenSource Systeme als VMWare Images bereitstellt. Gegen eine jährliche Gebühr kann man jeweils entsprechend viele dieser Systeme produktiv betreiben (Toll ist übrigens auch die Möglichkeit, diese Systeme in der Amazon Cloud direkt hochzufahren, das beschreibe ich bei Gelegenheit auch mal).

Nun wurde die Jumpbox auf Wordpress 2.9 aktualisiert, also befassen wir uns mit dieser:

Zunächst wird das ZIP Archiv heruntergeladen, die WordPress Jumpbox hat 192 MB, dann wird das ZIP ausgepackt:

Je nachdem, welche VMWare Technik man einsetzt, kann man die Jumpbox sofort laden (in VMWare Workstation oder VMWare Server) oder, wie in meinem Falle, erst noch nach mit VMWare Converter nach ESX Server konvertieren:

In unserem Fall müssen wir allerdings den Hauptspeicher gleich auf 768 MB erhöhen:

Die so konvertierte Virtual Machine wird mit einem neuen Namen parallel zum bestehenden Wordpress Server auf dem ESX Server hochgefahren. Der alte Server hieß “blog.pohle.de”, der neue heißt nur “pohle.de” (die ersten Monate habe ich mein Blog unter Ausschluß der Öffentlichkeit und auch nur unter der eigenen Adresse “blog.pohle.de” betrieben, daher habe ich die Virtual Machine auch gleich so genannt. Da ich das Blog dann im August auf “pohle.de” umgeswitcht habe, ist jetzt eine gute Gelegenheit, auch die VM bei diesem Update gleich umzubenennen). Die Virtual Machine meldet sich und je nachdem, ob ein DHCP Server im Netzwerk ist oder nicht, muß man in der Konsole eine IP Adresse einstellen:

Der Rest wird über den Browser konfiguriert, die Konfiguration der Jumpbox erfolgt genau analog zur bestehenden:

Die restlichen Settings im JumpBox Konfigurationsmenü werden vom alten System 1:1 übernommen:

Dann wird von Wordpress Deutschland die eingedeutschte Version 2.9 geladen:

und das ZIP ausgepackt:

Diese Dateien werden mit WinSCP (SFTP habe ich auf der Jumpbox vorher über das Konfigurationsmenü eingeschaltet) auf die Jumpbox übertragen:

Dann noch in der wp-config.php die Sprache ‘de_DE’ eintragen:

und mal mit dem Admin anmelden (Passwort wie bei der Jumpbox eingegeben) – wir haben eine Deutsche Wordpress 2.9 Jumpbox:

Jetzt müssen die Inhalte aus dem alten Server transferiert werden, dazu bieten die Jumpboxen die Möglichkeit an, einfach ein Backup des alten Servers zu erstellen:

Während des Backups ist das Blog übrigens nicht betriebsfähig, es wird m Browser folgende Meldung angezeigt:

Diese Datei wird dann auf dem neuen Server zurückgesichert:

und schon sind alle Daten wieder da:

Jetzt ist ein guter Zeitpunkt, um die nicht mehr aktuellen Plugins zu aktualisieren:

Die Jumpbox für Wordpress unterstützt seit Mitte diesen Jahres die automatische Aktualisierung, allerdings muß hier der Host als “localhost” und der admin unbedingt in kleinbuchstaben eingegeben werden:

Dann nochmal gründlich testen, ob alles auch prima läuft und zuletzt wird die Zieladresse im Firewall auf den neuen Server geändert:

Kleine Aufräumarbeiten, wie

• Alten Server runterfahren, aus dem ESX Autostart rausnehmen
• Neuen Server in den ESX Autostart reintun
• Das Backup mit VMExplorer auf den neuen Server umkonfigurieren

und schon haben wir wieder einen pieksauberen, neuen Wordpress 2.9 Server.

Manche meiner Virtuellen Maschinen mit Windows hatten nach der Umstellung auf VMWare Workstation 7 und der Installation der aktuellen VMWare Tools Probleme, auf die Shared Folders des Hosts zuzugreifen.

Bei diesen Maschinen stelle ich fest, daß die Shared Folders unter dem Pfad

\\.host\Shared Folders\###

gemappt sind. Suche ich über die Netzwerkumgebung einen Folder, dann wird der Pfad als

\\vmware-host\Shared Folders\###

gelistet:

Nachdem ich nun alle festen Laufwerks Mappings auf den neuen Pfad geändert hatte durch trennen und neu zuordnen, funktioniert der Zugriff auf die Shared Folders wieder einwandfrei und mir scheint, auch deutlich schneller, als vorher.

Die neue Version “2″ von LogMeIn Hamachi erlaubt, ein VPN Netzwerk zu erstellen in dem ein Rechner als “Gateway” dient:

Wird dieser im Firmennetzwerk platziert, dann beziehen die Clients draußen in der Welt auf dem Hamachi Adapter eine Adresse vom DHCP Server im Firmennetzwerk und können sofort alle Rechner im Firmennetzwerk erreichen. Kein Umständliches Rumgetue mehr mit Routen auf den Rechnern draußen – es funktioniert schnell und einfach.

Betraibt man aber das zentrale Gateway auf einem ESXi 4.0 Server, stellt man fest, daß dieser Rechner sich sofort vom Netzwerk verabschiedet und auch nichts mehr PINGen kann, sobald man im LogMeIn Webinnterface diesen Rechner als Gateway definiert. Die Lösung liegt darin, daß der Rechner, der als Gateway dient, eine Netzwerk-Brücke anlegt und dazu auf dem Netzwerkadapter den Promiscous Mode einschaltet. Dieser ist aber auf dem ESXi 4.0 standardmäßig verboten.

Daher muß man den Netzwerkswitch, auf welchen der Hamachi Client gebunden ist, in den Promiscous Mode schalten:

Das kann durchaus im laufenden Betrieb geschehen, laufende Services werden -meistens- nicht beeinträchtigt.

Die neue Version der VMware Workstation , Version 7 ist erschienen und begeistert mich. Daher hier ein Bericht meiner ersten Eindrücke auf meinem Rechner.

Ob das Zufall ist, daß die Version 7 von nun auch genau die erste ist, die Windows 7 unterstützt? Das ist natürlich die größte Neuerung auf den ersten Blick – Untersützung von Windows 7 in 32-bit und 64-bit Editions, inklusive der Aero Oberfläche dank des neuen WDDM Grafiktreibers, kann Windows 7 (und natürlich auch Vista) nun auch in einer VM alle Reize der neuen Oberfläche ausspielen:

Das gilt allerdings auch für Windows XP, denn ein neuer SVGAII Grafiktreiber ermöglicht es Windows XP, nun auch anspruchsvolle Grafikanwendungen, in der VM laufen zu lassen:

Neu ist, daß man jeder virtuellen Maschine konfigurieren kann, wieviele Prozessoren und auch, wieviele Cores pro Prozessor sie erhalten soll. Natürlich kann man nicht mehr Cores konfigurieren, als der Host hat

Der Netzwerkeditor ist viel übersichtlicher geworden, auf meinem Laptop mit den verschiedenen Netzwerkkarten für meine Kundennetze ist das eine schöne Verbesserung:

Tipp: Wenn man Netzwerkkarten fürs manuelle Bridging eintragen möchte, dann muß man zunächst das “Auto Bridging” auf dem Adapter 0 rausnehmen, sonst kann man keinen anderen Adapter auf Bridging umstellen.

Noch ein rasantes Feature, auf das ich schon lange gewartet habe: “Pause”. Man kann eine Virtuelle Maschine, in der gerade Programme laufen, die den Prozessor belasten (gutes Beispiel ist der Virenscanner) in die Pause schicken und wieder loslassen, wenn man gerade nicht am PC sitzt:

dann wird die Maschine angehalten und abgedunkelt. Der Prozessor wird frei, der Speicher allerdings nicht. Dafür geht der Prozess dramatisch schneller, als Suspend (und auch sicherer). Wenn man dann wieder möchte, läßt man die Maschine wieder los:

Man kann nun einen Virtuellen Drucker hinzufügen,

und über diesem aus der Virtuellen Maschine heraus direkt auf einem beliebigen Drucker des Hostrechners ausdrucken:

Das wird übrigens mit ThinPrint gemacht, die kennen wir aus der Terminalserverumgebung gut:

Es können nun zeitgesteuert automatische Snapshots des Systems angelegt werden, wobei das Feature sich auch noch darum kümmert, die Snapshots entsprechend lange aufzuheben:

Der Hammer zum Schluß: Die Zwischenablage kann jetzt Grafik! Bisher war es nur möglich, mit der gemeinsamen Zwischenablage zwischen Host und Guest reinen Text zu übertragen, seit Version 7 geht nun auch Grafik, das ist für mich, der ständig mit Screenshots rumhantiert, der Kaufgrund für die neue Version!

Weitere Features der neuen Version 7:

• Es sollen jetzt bis zu 32 GB Speicher für die Guests möglich sein – das konnte ich mangels Masse nicht ausprobieren.
• Die gleiche Lizenznummer kann nun für die Windows oder die Linux Version der VMWare Workstation verwendet werden, man kann also umsteigen, ohne sich eine neue Lizenz kaufen zu müssen (in der Vergangenheit war die Lizenznummer nur für eine der beiden Versionen gültig).
• Man soll jetzt ESX 4.0 als Client laufen lassen können, offiziell supported. Inoffiziell ging das vorher auch schon. Praktisch, um neue Konfigurationen oder die HA Features vom ESX auszutesten oder zu demonstrieren.

VMWare Workstation zum 30-Tage ausprobieren gibt es hier, einen 10% Rabatt auf die VMWare Workstation Lizenz gibt’s hier.

Vor kurzem habe ich ja den VM Explorer für das Backup von Virtuellen Maschinen auf ESXi Hosts empfohlen, nun bin ich einmal mehr entzückt, denn es geht noch besser. Mit der neuen Version 1.6.008, die heute erschienen ist, wird die Sicherung von VMs um den Faktor 2-4 beschleunigt. Ich habe die Betaversion schon einige Wochen im Einsatz und die Änderungen sind dramatisch:

• Backup zweier VMs vorher 150 Minuten, jetzt 55 Minuten
• Weitere zwei VMs vorher 48 Minuten, jetzt 21 Minuten

Ich habe natürlich auch den Restore gestestet und eine der Maschinen, die ich gesichert habe, zurückgespeichert, unter neuem Namen registriert, in ein anderes Netzwerk gehängt und hochgefahren. Läuft einwandfrei.

Das einzige, was ein wenig unbequem ist, ist daß man auf dem ESXi nun SSH einschalten muß, und nach dieser Änderung leider den ESXi neu starten muß. In der Hilfe des VM Explorer ist genau beschrieben, wie das geht:

Das läßt sich aber sicher nicht umgehen und in Zukunft weiß ich es von vorneherein, wenn ich einen ESXi einrichte, daß ich sofort SSH einschalte, denn der Geschwindigkeitsunterschied beim Sichern ist das wert.

Für das Backup unserer VMs auf dem ESXi Host habe ich ein Produkt gefunden, daß perfekt für ein einfaches und gutes Backup geeignet ist: VM Explorer vom Schweizer Hersteller Trilead. VMExplorer verbindet sich, einmal auf einer Windows Station installiert, mit dem oder den ESX Servern und bietet für jeden Server die Möglichkeit, ein Backup durchzuführen. Dabei wird dann von der VM ein Snapshot erstellt und dieser Snapshot auf den Backup Speicherplatz übertragen, dieser ist in unserem Fall eine 2 TB Festplatte, die an der Windows Station angeschlossen ist.

In der Free Edition war’s das auch schon, man braucht dann die Pro Edition, damit man einen Backup Scheduler aktivieren kann. In diesem legt man dann die Backups nach eigenem Gusto und gewünschter Häufigkeit an. In unserem Falle wird die externe 2 TB USB Festplatte jeden Freitag ausgetauscht und so sind die Backup Jobs darauf ausgerichtet, den Exchange, den SQL Server und die Kundensysteme täglich zu sichern und die restlichen VMs im Laufe der Woche jeweils einmal:

Einmal am Tag schickt VM Explorer dann ein E-Mail mit der Nachricht, ob alle Backups gut verlaufen sind:

Die Sicherungen selbst werden standardmäßig in Verzeichnissen abgelegt, die mit dem Namen der VM und Datum und Uhrzeit der Sicherung gekennzeichnet sind. Hier sind die normalen Dateien der VM abgelegt, diese können dann mit VMExplorer auf den ESXi Host zurückgesichert werden, auch unter anderem Namen, so daß die laufende Instanz nicht beeinträchtigt wird.

Es ist auch möglich, aus dem Sicherungsverzeichnis heraus eine VM mit vCenter Converter ins VMWare Workstation Format zu konvertieren – für Notfälle beim Totalausfall des ESXi sicher eine mögliche Option.

Insgesamt macht das Produkt einen runden Eindruck und ist die Lizenzkosten von 490 EUR absolut wert, wenn man regelmäßige Backups anfertigen möchte. Für Einmalbackups oder gelegentliche Backups von Hand genügt die Free Edition, die es glücklicherweise auch gibt.

Ich habe natürlich auch einige Restore Tests gemacht und dabei festgestellt, daß ich die Option “Compress Disk Files” im Tab “Connection” keinesfalls aktivieren darf, da sonst mein ESXi bei der Rücksicherung abbricht. Die Option ist allerdings standardmäßig beim Einrichten eines Backups auch nicht aktiviert.

Als ich meine VMWare Systeme von VMWare Server 1.0.9 auf den neuen ESXi 4.0 migrierte, erhielt ich bei einigen Systemen beim Upgrade der VMWare Tools die Fehlermeldung “Fehler bei der Anwendung von Transformen”:

Die einfachste Lösung ist, wenn man die VMWare Tools deinstalliert, dann die virtuelle Maschine rebooted und danach die VMWare Tools wieder installiert. In allen Fällen kam bei mir die Fehlermeldung nicht mehr.

Ich hatte vor, meinen Asterisk Server, der auf einer physikalischen Maschine installiert ist, auf den ESXi Server zu migireren. Der alte Asterisk ist Version 1.4 und ich müßte, das unterliegende Linux aktualisieren, die Treiber von der ISDN Karte (die ich nicht mehr brauche) rauskratzen und den Asterisk auch auf die neueste Version bringen.

Zuviel Arbeit. Statt dessen habe ich lieber die Konfigurationsdateien vom Asterisk gesichert und mir eine Installations CD als ISO Image vom Projekt AsteriskNOW geladen. Neue Virtual Machine erstellt, ISO Image als Boot Datei geladen und AsteriskNOW installiert. Beim erstellen der Virtual Machine muß man nur darauf achten, daß man als Netzwerkkarte die “E1000″ wählt, sonst findet das Linux in AsteriskNOW keine Netzwerkverbindung:

ich habe eine 16GB Disk angelegt, die ist wahrschinelich noch viel zu groß. Beim Setup das Default Harddisk Layout akzeptiert, die Timezone ausgewählt (“Berlin”) und das root Passwort gesetzt.

Nach der Installation ruft man die Adresse, die der Server vom DHCP erhalten hat, auf und man findet sich im komfortablen FreePBX Browser Interface wieder, in dem man recht bequem die Teilnehmer, SIP und IAX2 Kanäle einrichten kann. Sogar das Flash Operator Panel, das alle aktiven Verbindungen anzeigt, ist schon vorinstalliert. Perfekt, gute Arbeit vom AsteriskNOW Team!

Das Zurückspielen meiner Einstellungen war recht einfach, ich habe allerdings mir die Mühe gemacht, meine Konfigurationsdateien durchzufuzeln, was nicht mehr gebraucht wird, wegzuwerfen und die Konfiguration im FreePBX nachzubauen. Nach weniger als 3 Stunden waren wir wieder online.

Wenn man eine Virtual Machine von einer CD/DVD booten muß oder anderswie ein ISO Image in einer VM mounten muß, dann muß man beim ESXi 4.0 nicht mehr umständlich mit WinSCP eine Verbindung aufmachen und dann den ISO Kopieren, denn es gibt nun den Link “Browse Datastore”, dieser erscheint z.B. wenn man mit der rechten Maustaste im vSphere Client auf einen Datastore klickt. “Browse Datastore” fördert einen kleinen Filemanager zu Tage, der es erlaubt, Dateien bequem hinauf- und auch herunterzuladen:

Danach kann man bequem die ISO Datei mounten.

Übrigens: Mit dem Browse Datastore kann man auch alle Dateien auf den Datastores vom ESXi hin- und her verschieben.

VMWare hat gerade den ESXi 4.0 veröffentlicht. Die neueste Version des ESX Server als installable ISO Image zum kostenlosen Download. Gegen bloße Registrierung kann man das ISO Image kostenfrei laden, brennt es auf eine CD, legt diese in seinen 64-bit Server ein (der muß allerdings auf der Hardware-Kompatibilitätsliste stehen), booted von dieser CD und etwa 10 Minuten später läuft der ESXi Server und ist bereit zur Aufnahme von virtuellen Maschinen.

Ich habe mir für den ESXi 4.0 einen neuen Server bei DELL beschafft, der wurde zeitgleich mit der Veröffentlichung geliefert, es ist ein DELL T605 mit 16 GB RAM und 2*250 GB und 2*1,5 TB SATA Festplatten in jeweils einem RAID 1 Verbund. Für DELL Server gibt es eine spezielle Version des ESXi Image mit DELL Treibern und Management Agents vorinstalliert, da wir dann in der ESXi auch gleich angezeigt, ob es der Hardware gut geht.

Der ESXi Server wird mit dem ebenfalls kostenlos herunterladbaren vSphere Client verwaltet und physikalische und virtuelle Maschinen werden mit dem ebenfalls kostenlos herunterladbaren VMWare vCenter Converter auf den ESXi migriert.

Bei einem Hardwarepreis von etwa 2.000 EUR ist das eine Low-Budget Lösung für viele kleine Unternehmen, die von der Virtualisierung profitieren wollen. Auf jeden Fall ist der ESXi gegenüber der Installation von VMWare Server auf Windows oder Linux vorzuziehen, die Performance und die Verwaltbarkeit ist dramatisch besser.

Natürlich muß man auf die Verfügbarkeitsfeatures von VMWare erstmal verzichten, kann die aber jederzeit kostenpflichtig nachrüsten, genauso, wie man Supportverträge mit VMWare erwerben kann.

Der hier vorgestellte Ansatz ist zunächst mal gefacht für kleine Unternehmen, die mittelfristig mit einem VMWare Server auskommen und keine extremen Ansprüche an die Verfügbarkeit des Systems stellen. Natürlich muß man sich in diesem Zusammenhang konzeptionelle Gedanken über Backup, Recovery und Verfügbarkeit machen, aber die Hürde für den Einstieg in die wirklich performante Virtualisierung ist mit ESXi 4.0 deutlich niedriger angesetzt worden.