Neues Familienmitglied: Unsere ESXi Whitebox

Nach so vielen Beiträgen über die Natur, Autos und das Leben im Allgemeinen wird es auch mal wieder Zeit für etwas Technisches: Meine neuste „Schöpfung“.
Im Rahmen meiner beruflichen Tätigkeit als Wanderheuschrecke Berater ist in letzter Zeit vermehrt erforderlich auch etwas komplexere IT-Landschaften für Testszenarien auf- und nachzubauen.

Dafür eignet sich Virtualisierung prinzipbedingt natürlich sehr .. doch leider geht meinem Notebook spätestens nach dem zweiten XenApp 6 Server ziemlich die Luft aus. Was liegt da näher als einen Baremetalhypervisor ala VMWare ESX(i) einzusetzen. Okay, fehlt nur noch die passende Hardware und etwas Zeit. Nachdem ich verschiedene Alternativen zum Kauf eines passenden Systems (es gibt günstige Markensysteme gebraucht ab ca 250€ die durchaus ESXi fähig sind; alternativ empfiehlt sich ein Lenovo T400..der ist dann auch portabel) eruiert hab, kamen Dani und ich gemeinsam zum folgenschweren Entschluss: Etwas Selbstgebautes soll her. Dafür gibt es gleich mehrere Gründe:

  1. Das Basteln macht Spaß
  2. Die Anpassbarkeit an die eigenen Wünsche ist quasi grenzenlos
  3. Bestehende Komponenten ließen sich wiederverwenden

Da mir „herkömmliche“ Rechner schon immer zu langweilig waren, sollte das System etwas ausgefallenes werden .. ein portables SmallFormFactor-System hatte ich im Sinn (hohe Portabilität, geringes Gewicht, Eyecatcher).

So war das Gehäuse tatsächlich die erste Komponente, die  durch einen größeren Zufall in unseren Besitz wechselte. Ein silberner Cube vom Typ Lian Li V350A sollte unser ESX System zukünftig beherbergen .. lecker. Selbiges gab es in Kombination mit einem Motherboard, welches hervorragend in unser Problemkind den HTPC passte. Selbiger bekam also ein neues Board und einen neuen Prozessor, während sein bisheriges Herz zumindest in Form der Hauptplatine (Gigabyte GA MA78GM-UD2H) die Basis für das Virtualisierungssystem bilden sollte.

Nach längeren Überlegungen entschied ich mich zum Kauf eines Phenom II 945 mit 4×3 GHz als „Gehirn“ des Systems sowie einer günstigen (und zweckmäßigen) 500 GB HDD. Acht Gigabyte Arbeitsspeicher sollen zukünftig auch mehreren Maschinen gleichzeitig genügen und die Netzanbindung erfolgt durch eine Intel Pro 1000 Server NIC (die OnBoard Karte des Gigabyte Mainboards ist inkompatibel zu ESX). Da das System auch entsprechend leise sein soll, beschaffte ich zudem einen Scythe Big Shuriken als CPU Lüfter, zwei Scythe Slipstream 800 RPM als Gehäuselüfter und einen 80mm Be quiet USC Lüfter zur Befächelung der Festplatte (zukünftig: Festplatten).

Teile des neuen Systems vor dem Zusammenbau

Die Montage des Sytems dauerte ca. 3h und hat wirklich Spaß gemacht. Wenn gleich das Lian Li Gehäuse umständlich geöffnet werden will (6 Schrauben pro Seitenwand plus Thumbscrews an der Rückseite), ist die Verarbeitung und der Aufbau vorbildlich. Dank ausziehbarem Mainboardschlitten ließen sich alle Komponenten gut und schnell verbauen und trotz größerer Bedenken passt der Big Shuriken hervorragend in das Case. Die meiste Zeit bedurfte übrigens der Umbau aller vormontierten Lüfter, welche in diesem Zusammenhang auch gleich entkoppelt wurden.

Herausnehmbare Lüfterkassette - jezt mit entkoppelten Scythe Slipstream Lüftern

Der interessierte Leser hat eventuell bemerkt, dass als Netzteil ein preisgünstiges 300W Modell von be Quiet (PurePower) ohne Kabelmanagement zum Einsatz kommt. Entgegen erster Befürchtungen kann ich hier positiv vermelden, dass sich die überflüssigen Kabel sehr gut in den (in unserem Fall) leeren 5,25″-Zoll Schächten verstauen lassen. Das Netzteil ist zudem angenehm leise, nervt in den ersten Minuten jedoch durch ein leises Pfeifen – zum Glück verschwindet dieses und man kann es vernachlässigen.

Nach dem ersten Hochfahren zeigte sich sofort: Das System ist so leise wie erhofft und funktionierte sogar auf Anhieb. Einzig den Stecker der Power-LED musste ich mehrmals wandern lassen, bis selbige mich fröhlich blau anstrahlen wollte.

Das Endresultat: Mein neuer ESXi Cube

Die anschließende ESXi 4.1 Installation ging übrigens schnell (7 Minuten) und ohne größere Schwierigkeiten von der Hand. Das erste Testsystem (ein virtualisiertes Windows Server 2008 R2) war in insgesamt 13 Minuten installiert und bekräftig daher zumindest bisher meine Hoffnungen in die Performance des Würfelchens.

Über die weiteren Erfahrungen mit dem System und die Dinge, die ich damit anstellen möchte, werde ich hier sicherlich zu gegebener Zeit berichten.

Homeserver, ESX-System und Drucker in trauter Dreisamkeit

Debian Lenny und Broadcom NetXtreme [UPDATE]

Zur Abwechslung (hatten wir ja schon eine Ewigkeit nicht mehr) auch mal wieder etwas Technisches an dieser Stelle.

Ein Kollege bat mich vor einigen Stunden ihm mal eben einer unserer Systeme mit einem Linux neuaufzusetzen. Seine Wahl fiel auf Debian, meine hätte genau so ausgehen.

Also gesagt, getan und schnell das NetInst Minimal Image von den offiziellen Quellen heruntergeladen. Einige Minuten später startete auch schon die Installation und der Gefallen unter Kollegen erschien so gut wie erledigt. Tja, leider nur genau so lange, wie Debian mit der folgenden Meldung das Mittagessen unterbrechen wollte:

"Nein, die Netzwerkkarte mag ich nicht"

Wie man sieht, verweigert Debian in der Version 5 nicht quelloffene Firmwares (wie sie die Broadcom Netzwerkkarte des HP ProLiant DL380G5 benötigt), das Ganze ist hier recht anschaulich nachlesbar und geht auf den Debian Social Contract zurück.

Das Netz eröffnete hier diverse Lösungen vom Verzicht auf die Netzwerkkarte (eher wenig praktisch, wenn man remote arbeiten will), über das Anpassen der Medien bis hin zu dem, was der Installer auch vorschlägt: Liefer die Pakete doch einfach nach. Gesagt getan..ich besorgte das File (.deb), kopierte es auf den USB-Stick und schon mit dem dritten Gerät seiner Art funktionierte das ganze dann. Irgendwie scheinen USB-Sticks und ich heute nicht wirklich auf einer Wellenlänge zu sein.

Nach geglückter Installation startete das System dann durch .. mitten in den nackigen GRUB Bootloader. Nein, nein .. nicht das grafische Menü sondern die minimalistische Kommandozeile. Selbige ließ sich absolut nicht dazu überreden einen Kernel von der primären Platte zu laden. Wie sich später herausstellte, erscheint es sinnvoll den USB-Stick mit der Firmware nach getaner Arbeit und VOR dem Installpart von Grub wieder zu entfernen.

Update: Bei einer neuerlichen Installation hat sich herausgestellt, dass der Installer es auch übel nimmt, wenn der Stick im Rahmen der Partitionierung angesteckt ist. Ich habe ihn – um Seiteneffekte zu vermeiden – zwar entfernt und den Partitionierungsassistenten nochmals laufen lassen, dieser hing dann jedoch im Zustand „Detecting partitions…“ fest.

Auf ein letztes noch: Leider passierte mir während der Installation ein kleiner Fauxpas mit der Subnetzmaske. Kein Problem..ein paar Schritte zurückgegangen, korrigiert und alles lief wie gewünscht. Leider musste ich nach dem Reboot in das neue System signifikante Konnektivitätsprobleme feststellen. Wie ich herausfand, hatte der Debian Installer (eigenartigerweise) die falsche Subnetzmaske in die entsprechenden Konfigfiles eingetragen .. naja, wenigstens wird’s so nicht langweilig 🙂

Aus alt mach neu: Update von Debian Etch auf Lenny

Ausgangssituation:

  • Aktuelles Debian Etch
  • Aktueller VMWare Server 2.0

Ziel:

  • Debian Lenny
  • Lauffähiger VMWare Server 2.0

Migration des Betriebssystems:

  1. Abändern der /etc/apt/sources.list.
    Dazu entfernen alle alten Einträge und Verwendung der Folgenden:

    deb http://ftp.debian.org/debian/ lenny main
    deb-src http://ftp.debian.org/debian/ lenny main
    
    deb http://security.debian.org/ lenny/updates main contrib
    deb-src http://security.debian.org/ lenny/updates main contrib
    
  2. „Apt-get update“ ausführen
  3. apt-get dist-upgrade“ ausführen und viel Geduld mitbringen (ca 150MB neue Pakete)
    Dabei erfolgt auf Rückfrage ein Neustart verschiedener Dienste wie u.a. SSH, was die laufende Session jedoch nicht beeinträchtigt.
  4. Reboot!
  5. LenTest:~# uname -a
    Linux LenTest 2.6.26-1-686 #1 SMP Thu Oct 9 15:18:09 UTC 2008 i686 GNU/Linux
    

    –> jap, wir sind angekommen

Migration des VMWare Servers

Spontane Erkenntnis: VMWare Server mag uns nicht mehr:

LenTest:~# vmware
@@PRODUCT_NAME@@ is installed, but it has not been (correctly) configured
for the running kernel. To (re-)configure it, invoke the
following command: /usr/bin/vmware-config.pl.

Bedingt durch den aktualisierten Kernel müssen Teile des VMWare Servers neu übersetzt werden.

Vorkehrungen vor der Rekonfiguration des VMWare Servers:

  1. Die aktuellen Kernel Headers installieren:
    uname -a
    apt-get install linux-headers-2.6.26-1-686 (die durch uname -a bestimmte Version des Kernels ist hier zu verwenden)
  2. Symbolischen Link auf GCC ändern: (nachzulesen hier)
    mv /usr/bin/gcc-4.1 /usr/bin/gcc-4.1.bak
    ln -s /usr/bin/gcc /usr/bin/gcc-4.1

Nun kann vmware-config.pl erneut ausgeführt werden.

Dabei ist zu beachten, dass die folgende Warnmeldung mit yes bestätigt werden muss:

Your kernel was built with "gcc" version "4.1.3", while you are trying to use
"/usr/bin/gcc" version "4.3.2". This configuration is not recommended and
VMware Server may crash if you'll continue. Please try to use exactly same
compiler as one used for building your kernel. Do you want to go with compiler
"/usr/bin/gcc" version "4.3.2" anyway? [no]

Abschließend sollte das ganze dann so enden:

The configuration of VMware Server 2.0.0 build-122956 for Linux for this
running kernel completed successfully.

Telnet Scripting unter Linux (AXIGEN)

Auf meinem Server kommt ein etwas unbekannter Mailserver zum Einsatz: AXIGEN.

Selbiger funktioniert sehr gut, ist äußerst einfach zu warten und der Service ist spitze. Einzige Beschränkung wenn man nichts zahlen möchte: 5 Benutzerkonten und eine Domain. Mir reicht das und daher bin ich äußerst glücklich.

Leider konfrontierte mich das AXIGEN System kürzlich mit einem Problem. Ich nutze das RPOP Modul des Servers um Mails von zwei verschiedenen T-Online Konten einsammeln zu lassen. Im Rahmen des nächtliche Backups muss dazu der Axigen Service gestoppt und nach Abschluss der Sicherung neugestartet werden.

Unglücklicherweise funktioniert in ca 2/3 Fällen das RPOP Modul nach der Sicherung nur noch für eines der beiden Konten. Wird das Modul über das Managementinterface neu gestartet, arbeitet alles sofort wieder reibungslos.

Nun denn, der Support ist informiert und eine Lösung sicher in Aussicht. Trotzdem wollte ich den Prozess des RPOP Service Neustartens automatisieren. Glücklicherweise ist dies im Rahmen des Telnet Interfaces des AXIGEN Servers recht einfach möglich:

#!/bin/sh
#Script zum Restarten des RPOP Services
host=127.0.0.1
port=7000
( echo open ${host} ${port}
sleep 1
echo user admin
sleep 1
echo ##Passwort des Admins hier##
sleep 1
echo config server
sleep 1
echo config rpop
sleep 1
echo stop service
sleep 3
echo start service
sleep 5
echo commit
sleep 1
echo commit
sleep 1
echo save config
sleep 2
echo exit ) | telnet

Für die Sicherheitsfanatiker: Der Telnetservice lauscht nur auf dem Interface 127.0.0.1 – also keine Bedenken an dieser Stelle 😉