Installiert man in der aktuellen VMWare Workstation 7.1 ein neues virtuelles System, dann erhält das die VMWare Tools 8.4.2 Nach einer anschließenden Migration auf einen ESXi 4.0 Host arbeitet dann in der Konsole die Maus nicht mehr flüssig. Sie hängt immer etwas hinterher, was ein schnelles Arbeiten in der Konsole nicht zuläßt.

Der Grund dafür ist: Die VMWare Tools sind zu neu, der ESX arbeitet flüssig nur mit einen eigenen VMWare Tools 4.0 zusammen. Man kiann die aber nicht einfach vom ESXi Host aus aktualisieren, weil der natürlich behauptet, daß das nicht nötig wäre, denn die installierten Tools sind zu neu. Daher scheitert auch ein “Upgrade VMWare Tools” bei der Migration.

Also manuell: VMWare Tools über die Systemsteuerung deinstallieren, VM neu starten und dann aus dem ESXi die VMWare Tools wieder installieren. Siehe da: Die Maus läuft wieder, wie gewohnt.

Seit ich am das Foto unseres frisch aufgeräumten Rechnerraumes online gestellt habe, erreichen mich ständig Anfragen zu den Geräten, die man da sieht. Das überrascht und freut mich sehr. Also – hier die Erklärungen. Ich habe jeweils in das Foto Nummern eingefügt und erkläre diese Nummern dann im Text direkt darunter.

Linker Teil des Regals, oben:

1. Darmstadt – Unser Fernsehaufnamerechner. Er ist mit einer Hauppauge WinTV PVR-350 Karte ausgerüstet, die an unserem Kabelanschluß hängt und Fernsehsendungen aufnimmt. Über diesen Rechner habe ich schon mal hier geschrieben.
2. Ein Videorecorder von Sony. Er ist via Scart Kabel an die Hauppauge Karte im Rechner Darmstadt daneben angeschlossen und erlaubt uns, Videokassetten zu digitalisieren. Vorzug dabei ist – er macht das nicht nur mit VHS Kassetten, sondern auch mit den Video 8 Tapes aus Thomas allererster Videokamera.
3. Das Spiralkabel das von der Decke hängt ist ein Relikt an die Anfangszeiten unseres Rechnerraumes. Es kommt vom Deckenauslaß, führt also Strom, wenn im Rechnerraum das Licht eingeschaltet wird. Das Spiralkabel führt hinten im Rack auf Kaltgerätesteckdosen und dort waren früher die 10 Monitore angeschlossen, die in diesem Regal eingebaut waren. Licht an = Monitore an – der Theorie folgend, daß man Monitore nur braucht, wenn man im Raum ist. Die Monitore gibt es nicht mehr, das Kabel schon, aber es hängt nur noch der Flatscreen und der Lautsprecher dran, so daß der Einschalteffekt nicht mehr so atemberaubend ist.
4. Ein Lautsprecher. Der hängt an der Soundkarte von Darmstadt, damit man kontrollieren kann, ob der Rechner Sound aufzeichnet. Die Stromversorgung dieses Lautsprechers erfolgt über den Lichtschalter (siehe 3), so daß nur Sound im Raum ist, wenn auch einer da ist.
5. Ein Temperatursensor, der an der MessPC Ethernet Box hängt und die Temperatur oben überwacht. Diese wird von unserem Nagios abgefragt.
6. Ein Feuchtigkeitssensor, Rest siehe 5
7. Uranus – mein erster Tablet PC. Ein Fujitsu Siemens Stylistic aus dem Jahr 2002. Ich habe ihn etwa 2 Jahre als meinen “immer dabei” Rechner mitgeführt. Als ich ihn dann durch ein Acer Table ablöste (seither habe ich keine Slates mehr, sondern nur Convertible Tablets, die die Tastatur fest eingebaut haben) führte ich ihn einer viel nützlicheren Verwendung zu: Er besitzt ein “Outdoor Display”, man kann die Anzeige also ohne Beleuchtung auch im grellsten Sonnenlicht erkennen – ideal, um als Cockpitcomputer im Flugzeug zur Anzeige der Anflugkarten zu dienen. Er hat einen kleinen Bluetooth Stecker, mit dem ist er mit einem portablen Bluetooth GPS verbunden und zeigt mir dann auf den Anflugkarten sogar die aktuelle Position an. Wer schon mit mir geflogen ist, weiß, daß ich ihn, außer bei unseren Rundflügen, immer auf den Knien habe.
8. Die Tastatur dieses Tablet PC ist mit Infrarot verbunden. Das ist übrigens blödsinnig – hier im Rechnerraum, wo der Tablet auf einem Ständer steht, geht das ja noch ganz gut. Was aber, wenn man in einem Zug oder einem Flugzeug mit der Tastatur arbeiten möchte? Genau, das funktioniert nicht, weil man nicht weiß, wie man da alles aufstellen soll. Daher bleibt bei meinem Uranus die Tastatur und der Ständer schön im Rechnerraum und nur der Tablet PC kommt mit.
9. Ein externes CD Laufwerk für den Tablet, hauptsächlich, um die Jeppesen Software für die Anflugkarten zu pflegen, da kommen Aktualisierungen nicht immer nur per Internet, sondern auch manchmal auf CD.
10. Wir verwenden in den meisten Geräten keine Batterien, sondern Akkus. Irgendwo müssen die aufgeladen werden und so stehen hier meine Ansmann Ladegeräte für Mignon und Micro Akkus und die Ladegeräte für die Sony Videokameras und die Canon EOS 350 Kameras.
11. Über die beiden Funkgeräte müßte man ja fast einen eigenen Artikel schreiben – die dienen Thomas und mir dazu, daß wir uns, wenn ich Rundflüge mache oder wir an verschiedenen Flugplätzen dieser Welt unterwegs sind, miteinander verständigen können. Wir haben lange danach gesucht und von der Bundesnetzagentur über die Deutsche Flugsicherung viele Anfragen gestartet – diese Motorola Geräten sind die einzigen, die an den meisten Orten auf der Welt betrieben werden können. Hier werden sie aufgeladen und warten auf ihren nächsten Einsatz.
12. Mein alter Sony Vaio VGN A117 – den hatte ich schon mal beschrieben, das ist meine “Leise Konsole” für den Einsatz im Garten oder vor dem Haus – ein Laptop mit einer SSD und einem superhellen Display. Hier parkt er und wird aufgeladen.

Rechter Teil des Regals, oben:

1. Monalisa – auf diesem Rechner läuft die Serversoftware für unsere Pinnacle ShowCenter 200, die im Haus verteilt sind. So können wir alle digitalisierten Filme überall im Haus ansehen. Wir sind übrigens vollständig noch im “Nicht HD Zeitalter” und scheuen die Umrüstung.
2. Die externen Festplatten sind an Monalisa angeschlossen und uns Filesystem eingebunden. So kommt der Rechner zusammen mit den internen Platten auf etwa 3 TB Speicherplatz. Da wir, wie erwähnt, nicht HD fahren, ist noch einiges frei. Monalisa hat übrigens, ob der Datenmengen, eine eigene Sicherungsplatte und wird einmal im Monat gesichert.
3. Leonardo – das ist unser NAS Server, der via iSCSI die Datenpartitionen unseres Fileserver bereitstellt und mittels SMB/CIFS einige Shares hostet (z.B. für Musik und Photos). Er hat 4 interne Platten mit je 750 GB, die über ein Software RAID 5 zusammengefaßt sind, das ergibt etwa 2 TB nutzbaren Platz. Der Server läuft mit FreeNAS und wenn ich nicht gelegentlich aus lauter Gewohnheit ein Update installieren würde, könnte ich fast vergessen, daß er da ist – so stabil und völlig störungsfrei läuft er. Das Software RAID hat übrigens schon einen Festplattenausfall erfolgreich überlebt und sich nach dem Austausch der Platte einwandfrei rekonstruiert. Das Betriebssystem booted übrigens von dem USB Stick der vorne raussteht (siehe Pfeil), so daß die 4 eingebauten Platten vollständig zur Verfügung stehen.
4. Ein Ladesystem für Handies und iPhones und Blackberries.
5. Backupfestplatten. Ich mag die Western Digital MyBook Festplatten sehr gerne, weil die chic aussehen, aufrecht stehen (nimmt wenig Platz weg) und sich auch in ein Bücherregal stellen lassen.
6. Die Dockingstation von meinem Dell Latitude XT (ein convertible, ich bin seit 2002 dem Thema Tablet PC treu geblieben). Sie steht eigentlich nur hier, weil ich keinen anderen Platz dafür habe – ich mag Docking Stations nicht sehr gerne.

19″ Schrank, oben:

1. Hier kommen die Kabel aus den Büros an. Wir haben seinerzeit übrigens CAT 7 Kabel verlegen lassen (das war 1998 noch ziemlich futuristisch) und sind somit noch für einige Zeit gerüstet. Derzeit ist das schnellste, was wir fahren, sowieso nur Gigabit Ethernet, also reicht auch das CAT 6 Patchpanel (ein CAT 7 Panel gab es 1998 noch nicht).
2. Unser Gigabit Backbone Switch – der hat gerade keine Kabel drin, weil er bei unserem Umbau den Geist aufgegeben hat (bei Abschaltungen im Rechenzentrum geht immer was kaputt). Ersatz ist unterwegs, kam aber nicht mehr rechtzeitig fürs Foto.
3. Der Netgear Fast Ethernet Switch, der hat zwei Gigabit Ports, einen benutze ich für einen Server, einen zum Uplink zum Gigabit Switch.
4. Unser Internet Router. Das ist das AVM VoIP Gateway 5188, das sollte mal eine Fritz!Box für Unternehmen werden mit 4 internen und 4 externen ISDN Bussen. Hatte als erstes einen eingebauten VPN Server. Leider wurde das Produkt eingestellt, was ich jammerschade finde.
5. Ein GBit Switch aus meinem Unterwegs-Netzwerk. Ist solange als Ersatz eingebaut, bis der “große” Gigabit Switch da ist.
6. Eine Bianca Brick XM. Etwa Baujahr 1999. Ein modularer Router, in den Man Netzwerkkarten und ISDN Karten einbauen kann. Über die ISDN Karten wurden dann Netzwerkverbindungen hergestellt, oder die ISDN Karten wurden mit einer Netzwerk CAPI geteilt. Dieser hier hat sogar ISDN Karten mit Modemfunktion, die können als Faxmodem dienen. In ihren goldenen Zeiten war diese Bianca ein Einwahlserver für Außendienstmitarbeiter, die sich vom Laptop aus übers Handy ins Netzwerk einwählten. Direkt. Ohne Internet dazwischen.
7. Eine Bianca Brick XS. Die ist Baujahr 1997. Die kleine Schwester von der XM, dieses Modell hat ein 10 MBit Ethernet Interface und eine ISDN Karte. Das war unser erster Internet Router, der unser Netzwerk mit 64 KBit ans Internet angebunden hat, damals noch bei SpaceNet in München. Heute darf sie als Netzwerk CAPI dienen und unseren Konfigurationszugang in die Telefonanlage bereitstellen.
8. Ein Auvisio Mediaserver, der steht hier nicht produktiv, sondern ist nur ein Ersatzgerät. Man baut eine Platte ein, lädt Musik und Filme drauf und kann die dann an einem angeschlossenen Fernseher ansehen.
9. Das Gateway für unsere Netzwerkgäste. Trennt das WLAN für unsere Gäste im Büro und Besprechungsraum von unserem Netzwerk und erlaubt unseren Gästen den Zugriff aufs Internet (mit einem Ticketsystem).
10. Das Musiphone mit 6 Kanälen, hängt analog an der Telefonanlage und sorgt mit einem Kanal für Wartemusik und mit den anderen 5 Kanälen für Ansagen. Wenn Sie meine persönliche Durchwahl anrufen und eine Ansage kommt, daß Sie nun mit mir verbunden werden, dann sind Sie in diesem Gerät gerade auf Kanal 4 unterwegs.

19″ Schrank, unten:

1. Sissy – Das ist die Ansage vor Abfrage für verschiedene unserer Hotlines.
2. Sieht geheimnisvoll aus, nicht? Ist aber ein simpler CD Case. Thomas hebt dort seine CDs mit den Wartemusiken und den für uns gesprochenen Ansagen auf, damit er die immer griffbereit hat, wenn er eine Ansage ändern oder neu einspielen muß.
3. Info – Wenn Sie das Glück haben, während unseres Urlaubs anzurufen (was zugegeben, leider selten vorkommt) dann landen Sie hier und bekommen mitgeteilt, daß die Pohle & Schultes AG im Urlaub ist. Wir sollten den Info viel öfter aktivieren, denke ich mir gerade.
4. Mozart – Wenn Sie unsere Hauptnummer wählen, werden sie direkt, bevor sich jemand meldet, von feiner Musik begrüßt. Das macht unser Mozart. Die Stimme ist übrigens von Frau Klaas (falls Sie ihr mal Grüß Gott sagen möchten während Sie warten).
5. 3 Musiphone Ansagegeräte – die waren mal die wichtigsten (zumindest für Kunden, die ein Problem hatten), denn sie bildeten viele Jahre unsere Expressschaltung. Deshalb dürfen sie auch weiter auf ihrem Platz bleiben.
6. Unser Prunkstück – eine Original Deutsche Post Wartemusik. Modell “Hanau”. Das ist übrigens die Wartemusik unserer privaten Telefonanlage. Das Baujahr ist nicht bekannt, wir schätzen aber so um 1980 rum.
7. Die Schlüssel für unseren 19″ Schrank. Am besten im Schrank aufgehoben. Nein, wir schließen ihn nicht ab.

19″ Schrank, oben – von hinten:

1. Eine 4-fach schaltbare Steckdosenleiste von Infratec. Die schaltet hier unser Internet Gateway (wofür es ein Script auf unserem Nagios gibt – er stellt fest, daß das Internet nicht verfügbar ist und löst einen Reset des Gateway aus durch aus- und einschalten der Stromversorgung) und an den anderen drei Steckdosen unsere Netzwerk Switches und die beiden Biancas.
2. Hier sieht man die beiden Biancas mal von hinten mit ihren Anschlüssen.
3. Unser 19″ Schrank verfügt, wie unser gesamter Rechnerraum über 2 unabhängige Stromkreise.

Einer unserer Server von hinten, hier der Medienserver “Monalisa”:

1. Die Kabel zu den externen Festplatten, Strom und USB 2.0
2. Das Kabel zum Bildschirmumschalter. Der wird weiter unten im Detail gezeigt.
3. Eine der Infratec PM211 Steckdosenleisten. Die haben jeweils einen Netzwerkanschluß und 2 unabhänig voneinander schaltbare Kontakte mit je 2 Steckdosen. An diesem Server ist das so gelöst, daß die USB Festplatten gesondert geschaltet werden können, da der Rechner nicht startet, wenn externer USB Platten angeschlossen sind.
4. Der linke Server ist Leonardo, unser NAS System.

Unser IP-Konsolensystem (wir haben noch ein anderes, ohne Fernzugriff):

1. Unsere 4 “lebenswichtigen” Server hängen an diesem einfachen 4-fach KVM-Umschalter. Zugegeben, die Kabel sind etwas sperrig, aber es sind nur 4 Stück und der Switch ist auch nicht mehr ganz taufrisch. Er kann natürlich per Softkey umgeschaltet werden, denn es hängt ja keine lokale Konsole dran, es könnte also gar keiner lokal umschalten.
2. Unser AVOCENT SwitchView IP1020 der das Signal vom Konsolenumschalter auf dem Netzwerk per IP bereitstellt. Er braucht keine lokale Software zum Zugriff, sondern liefert ein Java Applet aus, mit dem dann die Konsolen gesteuert werden können. Das ist eine einfache und günstige Lösung für IP Zugriff, wenn man nur wenige Server hat und ist bei vielen unserer kleineren Kunden im Einsatz. Kann 1024*768, für Serverkonsolen genügt das.

Unser zweites Konsolensystem im Testlabor:

1. Das ist unser zweites Konsolensystem, auch ein einfaches Gerät. Das ist allerdings schon etwas moderner, und die Kabel sind schon dünner. Schafft übrigens 1680*1050 auf einen LCD problemlos und ohne Unschärfe!
2. Hier hängt kein IP System dran, sondern ein physikalischer Monitor auf dem Tisch.
3. Der Netzwerk Switch vom Testlabor, das natürlich per Firewall vom restlichen Netzwerk getrennt ist.
4. Die Rechner vom Testlabor.

Linker Teil des Regals, unten:

1. Hier sieht man die 4 Rechner unseres Testlabors von vorne. Die erfüllen unterschiedliche und wechselnde Aufgaben, weshalb sich eine detaillierte Beschreibung nicht anbietet – sie wäre schon nach wenigen Tagen inaktuell.
2. Der Rechner Sahara ist produktiv, denn er ist für die Datensicherung unseres ESXi Systems zuständig (mit VMExplorer) und dient als Konsole im Rechnerraum.
3. Unser Konferenztelefon Polycom SoundStation 2W, das wird hier natürlich nicht verwendet, sondern steht nur zum Laden des Akkus hier. Es ist ja ein schnurloses System, das wir im gesamten Bürobereich verwenden. Im Garten funktioniert es leider nicht. Die Reichweite des Senders würde passen, aber wir haben soviele Vögel hier wohnen, daß jedes Telefonat klingt, als würde ich aus einer Vogelvoliere telefonieren.
4. Der Laptop von Thomas, der steht auch nicht zum Arbeiten hier, sondern wird hier nur aufgeladen. Da er ihn meistens irgendwo im Haus oder im Garten benutzt, ist es unpraktisch, ihn in seinem Büro im zweiten Stock aufzuladen.
5. Unser Canon i965 Fotodrucker. Wird hauptsächlich benutzt, um Fotos auszudrucken und das kann er sehr gut und sehr farbecht. Thomas nimmt ihn auch manchmal her, um Druckvorlagen für Kataloge auf Fotopapier zu drucken, das ist farbechter, als Testdrucke auf dem Farblaser.
6. Die Festplatte der Datensicherung, natürlich nur eine davon, die werden im wöchentlichen Wechsel zwischen unserem Tresor, dem Bankschließfach und diesem Regal reihum getauscht. Ja, ich sichere zwar täglich, aber die Platte tauschen wir nur einmal pro Woche aus. Das ist für unsere Sicherungsanforderungen der beste Kompromiß.
7. Der Monitor im Rechnerraum. Kann über den Bildschirmumschalter auf alle Rechner des Testlabors, ist aber meistens auf Sahara geschaltet.

Nochmal eine Ansicht in der Totalen:

1. Wickie, das ist unser VMWare ESXi Server.

Zum Schluß noch ein Schwenk nach links, an die Wand mit den Telefonanlagen:

1. Hier kommen alle Leitungen der Telekom an und weil es soviele sind, haben wir für die NTBAs einen kleinen Kasten bekommen.
2. Notfalltelefon. Das hängt auf einer analogen Amtsleitung und funktioniert auch, wenn sonst garnichts mehr funktioniert. Die Nummer steht übrigens im Telefonbuch und wird regelmäßig von den Gewinnspielautomaten angerufen. Wir heben nur selten ab.
3. Der Splitter für DSL. Wir haben inzwischen auch einen 16 Mbit Downstream, 1 MBit Upstream DSL Anschluß der Telekom mit fixer IP Adresse. Der ersetzt die 2 MBit Leitung prächtig.
4. Ein Relikt an alte Zeiten, der Anschlußkasten unserer 2 MBit Leitung. Symmetrisch. War wahnsinnig teuer seinerzeit diese Leitung. Glücklicherweise durch DSL inzwischen obsolet. Wir lassen den Kasten einfach hängen, als Erinnerung.
5. Die Batterie für die Telefonanlagen APC Back UPS CS 650. Ermöglicht, daß wir bei Stromausfall noch telefonieren können und dient als Blitzschutz.
6. Unsere dienstälteste Telefonanlage, eine Telenorma I2. Die ist heute noch im Einsatz und funktioniert prächtig.
7. Wir lieben vor allem die wunderschönen Systemtelefone dieser Anlage, hier eines davon.
8. Diese Telefonanlage, eine Bosch I3 stieß zu uns, als wir nach Dorfen umzogen, das ist jetzt auch schon 12 Jahre her und die I3 ist nicht mehr im Angebot.
9. Der Verteilerkasten unserer Telefonanlage.
10. Hier hängt nichts mehr, denn das war der Platz der Klimaanlage. Im Zuge der Virtualisierung unserer Rechnerfarm wurde die Wärmelast so niedrig, daß wir die Klimaanlage nicht mehr brauchen. Spart Lärm, Strom und Unmengen CO2. Ein Buzz-Word habe ich auch noch dafür: GreenIT.
11. Wenn Sie uns eine Nachricht auf einem Anrufbeantworter hinterlassen, ist die Chance groß, daß Ihre Worte hier auf der Festplatte landen. Memo heißt er.
12. Hier lagern wir das Foto-Papier für den Foto-Drucker.

Beim Setup von MSI Paketen auf einem Windows 2003 Server kann es zur Meldung

The System Administrator has set policies to prevent this installation.

kommen.

Dumm nur, wenn man selbst der Administrator ist und sich keiner Schuld bewußt ist, also auch gar keine Softwareeinschränkungen gesetzt hat.

Bei der gezeigten Fehlermeldung hilft es meistens, wenn man eine Softwareeinschränkung definiert. Das geht über das Menü

Start – Control Panel – Administrative Tools – Local Security Policies

Dort klickt man mit der rechten Maustaste auf “Software Restriction Policies” und erstellt welche:

Im “Enforcement” stellt man die dann auf “All users except local Administrators”

und schon geht’s!

Man kann die Konsolen von virtuellen Maschinen, die auf einem ESX oder ESXi Server laufen, auch direkt aufrufen, ohne jedesmal den VMWare vSphere Client öffnen zu müssen. Das bietet sich an, wenn man mit einzelnen Konsolen häufig arbeitet und nicht jedesmal den gesamten VMWare ESX Server verwalten möchte (die hier beschriebene Vorgehendweise ist für vSphere unter Windows, ich bin sicher, es funktioniert unter Linux ähnlich).

Auf dem Windows Rechner muß der VMWare vSphere Client installiert sein, dann ist im Verzeichnis

C:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\4.0

das Programm “vmware-vmrc.exe” vorhanden. Mit diesem legt man sich einen Shortcut mit der folgenden Commandline an:

“C:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\4.0\vmware-vmrc.exe” -h HOSTNAME -u USERNAME -p PASSWORD “[Datastore 2 RAID 1] Blackberry/Blackberry.vmx”

Die Parameter HOSTNAME, USERNAME und PASSWORT ermittelt man recht einfach, es sind die gleichen, die man beim Start des vSphere Client eingibt:

Die fügt man so, wie man sie eingibt, in den Shortcut ein, also ohne irgendwelche Anführungszeichen.

Die Virtuelle Maschine zu übergeben, ist etwas trickreicher. Dazu startet man am besten den vSphere Client und geht in die Eigenschaften der gewünschten VM findet man die Angabe des “Virtual Maschine Configuration File”:

Den kopiert man sich komplett heraus und setzt ihn zwischen zwei Anführungszeichen in den Aufruf:

“C:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\4.0\vmware-vmrc.exe” -h HOSTNAME -u USERNAME -p PASSWORD “[Datastore 2 RAID 1] Blackberry/Blackberry.vmx“

Diese Komandozeile kann man dann entweder aus einem Batch oder einem Icon auf dem Desktop heraus aufrufen. Die Konsole hat dann auch einen chicen blauen Rand, statt dem gewohnten grünen vom vSphere Client:

Diese Vorgehensweise ist nicht nur einfacher zu handhaben, es spart auch Zeit, denn der Start der einzelnen Remote Console aus dem Shortcut geht dramatisch schneller, als den vSphere Client zu laden, die richtige VM auszusuchen und deren Remote Console zu laden.

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.