blog.hait.de

Vor kurzem habe ich mir einen neuen Rootserver bei Hetzner bestellt. Auf diesen Server wollte ich Xen installieren um kritische Systeme (Mail, Web) von weniger wichtigen Webanwendungen zu trennen. Im konkreten Fall geht es z.B. darum, dass www.guldan.info das z.B. phpBB2 nutzt in einer eigenen Virtuellen Maschine läuft und somit eventuelle Sicherheitslücken nicht das gesamte System kompromitieren. Hier nun ein kleiner Erfahrunsgbericht.

Der neue Server bei Hetzner ist ein DS7000 mit einem Athlon X2. Auf Nachfrage war es möglich ein System mit AM2 Sockel zu bekommen, dieses unterstützt dann auch Pacifica/SVM. Damit ist eine Installation von unmodifizierten Gästen möglich, sogar Windows wäre dann kein Problem.

Linux 64 Bit die Erste

Als Distribution habe ich Gentoo ausgesucht, das habe ich schon ein paar mal installiert, konnte mich bei einem Desktop PC aber nicht dazu durchringen das System installiert zu lassen. Wenn man mal schnell ein Paket installieren will, dann ist der Rechner immer erstmal ein paar Minuten (wenn nicht sogar Stunden) mit kompilieren beschäftigt – irgendwie unbefriedigend. Auf einem Server sieht das schon anders aus, wenn man erst einmal alles am laufen hat, spielt man irgendwann ja nur noch Updates ein. Und die können im Hintergrund ruhig ein paar Stunden kompilieren.

Für die Gastsystem bzw. Virtuellen Maschine lässt sich ja auch noch ein anderes System installieren z.B. Debian oder Ubuntu. Somit gehen dort Paket-Nachinstallationen schneller von der Hand.

Bei der Installation des Gentoo Grundsystems habe ich mich an diese beiden Anleitungen gehalten:

• Gentoo with Raid and LVM – aus dieser Doku habe ich mir die Installation des Software Raids abgeschaut.
• Gentoo Linux AMD 64 Handbook – aus dieser Doku die restliche Installation

Das einrichten des Grundsystemes klappte ziemlich gut. Danach ging es also an das Einrichten von XEN. Auch dazu gibt es eine passende HowTo, diesesmal im Gentoo-Wiki:

• Howto Xen and Gentoo

Leider steht nirgendwo, dass es keine gute Idee ist, ein “reines” 64 Bit System zu kompilieren wenn man auch XEN installieren will. Zumindestens die xen-tools brauchen 32 Bit Libraries. Da sich meine ursprüngliche Wahl ein “nonmultilib” Profil zu benutzen nicht mehr Rückgängig machen lies, durfte ich wieder alles entfernen und von vorne beginnen.

Linux 64 Bit die Zweite

Alles wie beim ersten Mal, nur dieses Mal das Gentoo Profil nicht angefasst.

Das installieren von Xen und das Kompilieren der dom0/domU Kernel funktionierte, beim Neustarten hatte ich am Anfang Probleme mit eth0. Im Wiki steht, man soll in /etc/conf.d/rc das automatische Starten von eth0 durch die folgende Zeile deaktivieren.

  RC_PLUG_SERVICES="!net.*"

Auf meinem Gentoo reichte das aber leider nicht aus, zusätzlich musste noch ein paar Zeilen darunter,

RC_NET_STRICT_CHECKING="no"

in

RC_NET_STRICT_CHECKING="lo"

geändert werden. Danach klappte auch das Netzwerk und ich konnte in den XEN Kernel booten.

Leider klappt das Starten einer neuen domU Instanz absolut nicht. Nach dem Starten einer domU bekam ich keinerlei Fehlermeldungen, trotzdem blieb die Konsole leer. Egal welche Images oder Einstellungen ich benutzte – immer das selbe Ergebnis. Die Konsole blieb leer, XEN war der Meinung die domU läuft (xm list zeigte sie jedenfalls an) und nichts passierte. Ohne wirkliche Fehlermeldung war es schwer das Problem zu lokalisieren und auch bei Google oder den Xen Mailinglisten habe ich nichts gefunden. Falls irgendjemand eine Erklärung für mein Problem hat, immer her damit.

Linux 32 Bit

Also noch einmal von Anfang, dieses mal installierte ich aber ersteinmal kein AMD64 System sondern ein normales 32Bit Gentoo, eventuell lag es ja am 64 Bit. Im Prinzip alles wie oben nur das 32 Bit Handbook von Gentoo. Das installieren des Basissystems klappte wieder ohne größere Probleme. Beim installieren von Grub bin ich dann allerdings wieder auf ein neues Problem gestossen. Man kann die Grub innerhalb eines laufenden Systems Testen in dem man grub startet und dann die gleichen Befehle eingibt wie man sie auch in die menu.lst einträgt.

Also z.B:

root (hd0,0)kernel /boot/xen.gz

Und dabei kam dann die neue Fehlermeldung:

Error 28: Selected item cannot fit into memory

Und auch diesemal scheine ich mir wieder einen schönen Spezialfall rausgesucht zu haben. Bei Google findet man zwar ein paar Sachen zu dem Fehler, warum er bei mir aber mit der Xen.gz auftritt wurde nirgendswo beschrieben. Der Fehler ging einfach nicht weg un das System wollte auch nicht booten. Ohne direkt vor der Maschine zu sitzen war die Sache also schwer zu diagnostiezieren.

Linux 64 Bit die Dritte

Da ich nun langsam die Schnauze voll hatte, installierte ich noch einmal alles neu. Dieses mal wieder AMD64 ohne irgendwelche Änderungen an den USE Flags oder sonstige Spielreien. Nach der Installation des Grundsystems -> Der selbe Fehler im Grub. Da das aber vorher schon einmal funktioniert hatte, probierte ich das System zu booten. Und das klappte natürlich. D.h. Xen Kernel Image per Kommandozeile im Grub testen geht nicht, ansonsten erhält man den Fehler “Error 28: Selected item cannot fit into memory” beim Booten klappt dann alles. Warum das 32 Bit System nicht booten wollte weiss ich jetzt allerdings immer noch nicht, aber an dem Grub Fehler hat es vermutlich nicht gelegen. Probieren kann ich es ja nun nicht mehr.

Leider brachte auch der dritte 64Bit Versuch keine Besserung, wieder blieb die Console leer. Schon beim zweiten Versuch hatte ich irgendwie vermutet, dass die Virtuelle Maschine zwar bootet – ich nur davon nichts mitbekomme, darum hatte ich in die gemounteten Images geschaut und geprüft ob sich etwas in den Logdateien finden lässt. Dort war aber nichts, beim 18. Lesen der Doku viel mir aber auf, dass hinter der Angabe der RootPartition ein “ro” steht. Das ro also gelöscht, die DomU neugestartet, beendet und gemountet. Siehe da, die Logdateien haben sich geändert was bedeutete das die VM gebootet hat.

Da fragt man sich, warum die Doku die RootPartionen Read Only mountet. Also liefen die VMs, schon beim zweiten 64 Bit Versuch. Blieb das Problem mit der Console. Als erstes vermutetet ich, dass die Ausgaben irgendwie nicht in der SSH Session landen. In den XEN Mailingliste finden sich auch ein paar Emails die auf so ein Problem hindeuten, allerdings wurde wieder einmal keine echte Lösung anboten. Nach ein paar weiteren Stunden Google fand ich dann heraus, dass XEN beim booten der VM den Kernel anweist eine Seriell Konsole aufzumachen. “xm console <id>” macht dann nichts andere, als sich zu dieser Console zu verbinden. Da viel mir wieder ein, dass ich irgendwo beim XEN Kernel konfigurieren in der XEN-Kategorie etwas mit Serieller Konsole gelesen hatte.

  [ ] Disable serial port drivers

In der Hilfe steht dann zu diesem Flag:

Disable serial port drivers, allowing the Xen console driver to provide a serial console at ttyS0.

Da es zu meinem Problem zu passen schien, aktivierte ich dieses Flag in beiden Kernel (dom0/domU) und kompilierte diese neu. Nach einem Reboot startete ich eine neue VM und erhielt zum erstenmal die Ausgabe der bootenden VM. Geschafft.
In den XEN Mailinglisten lies sich zu diesem Problem wieder nichts finden und auch generell bei Google bin ich auf keine Lösung gestossen. Auf jeden Fall habe ich in der Gentoo/Xen Howto eine Note hinzugefügt. So ein Wiki ist schon was feines.

In den nächsten Tagen geht es dann noch an das einrichten von LVM2 und das aufsetzen der neuen Virtuellen Maschinen. Mal schauen ob die Probleme jetzt aufhören. Im nachhinein ärgere ich mich nur, dass ich nicht schon beim ersten Versuch auf die Idee mit der seriellen Console gekommen bin. Ärgerlich ist auch, dass das Flag nach dem emergen der Sourcen aktiviert war. Ich habe es nur abgeschaltet weil es in der Howto so vorgegeben war.

Ich berichte dann sicherlich noch einmal sobald alles steht.