Tag Archives: Virtualisierung

Xen: Debian Squeeze DomU in Debian Lenny Dom0

Aus der Reihe »Sonntag nachmittag für Frustrationstolerante« heute Folge 137 aus der Reihe »Virtualisierte Maschinen und freie Betriebssysteme«. Folgende Ausgangssituation: Server mit installiertem Debian Lenny als Xen Host (Dom0), es laufen diverse virtuelle Maschinen (DomU), unter anderem welche mit Debian Etch, eisfair-1, eisfair-2 und eben auch eine mit Debian Squeeze, dem aktuellen Testing-Zweig der Debian-Distribution. Bis auf die DomU mit eisfair-1 liefen alle virtuellen Maschinen bis dato mit dem Kernel 2.6.26-2-xen-686, der auch auf dem Host zum Einsatz kommt.

Vor einigen Tagen nun gab es in Debian Squeeze ein Update von udev 149 auf 150. Das Paket verweigerte dann aber die Installation mit dem Hinweis, dass der verwendete Kernel zu alt sei. Das war durchaus nervig, weil dadurch auch die Updates anderer Pakete nicht mehr eingespielt wurden, also hieß es: Kernel-Update.

Einfach mal schnell Kernel-Update gestaltete sich dann leider nicht so einfach. Debian hat Xen quasi aus der Distribution rausgeworfen bzw. bietet keine dedizierten Xen-Kernel mehr an. Gut, das ließ sich noch relativ problemlos lösen. Die Wahl fiel auf linux-image-2.6.30-bpo.2-686-bigmem von backports.org, denn dort heißt es:

This kernel also runs on a Xen hypervisor. It supports only unpriviledged (domU) operation.

Also fix den Kernel in der Dom0 installiert. DomU runtergefahren, Config angepasst, Kernelmodule ins Dateisystem der DomU kopiert, DomU gestartet und dann – nichts. Beim Hochfahren blieb die virtuelle Maschine einfach hängen, und zwar schon so früh im Bootprozess, dass ich keine Ahnung hatte, woran das lag.

Der nächste Schritt bestand dann darin eine weitere VM zum Testen aufzusetzen und die Suchmaschine der Wahl zu befragen. Ich weiß nicht, wo ich überall gelesen habe und was ich alles probiert habe. Am Ende funktionierte der Kernel, es waren nur Anpassungen an der Xen-Config notwendig, daher erstmal hier die Config und dann noch ein paar Kommentare dazu:

kernel  = '/boot/vmlinuz-2.6.30-bpo.2-686-bigmem'
ramdisk = '/boot/initrd.img-2.6.30-bpo.2-686-bigmem'
memory  = '128'
root    = '/dev/xvda1 ro'
disk    = [ 'phy:heaven/falbala_root,xvda1,w',
            'phy:heaven/falbala_swap,xvda2,w' ]
name    = 'falbala'
vif  = [ 'mac=00:16:3e:7d:4b:a2, bridge=eth0' ]
extra = 'xencons=hvc0 console=hvc0'
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

Wie man sieht, sind die Block-Devices, die in die VM gereicht werden, LVM Logical Volumes. Hier musste ich die Durchgereichten von /dev/sda* auf /dev/xvda* wechseln. Das hat definitiv mit dem verwendeten Kernel zu tun, der die Blockdevices nur noch dort ähm findet, oder so. Ich denke das war die entscheidende Änderung. In der mit »extra« beginnenden Zeile, habe ich die Angaben für die Xen-Konsole noch angepasst, irgendwo hatte ich gelesen, dass das jetzt hvc0 und nicht mehr xvc0 heißen muss. Die entsprechenden Änderungen an /etc/fstab und /etc/inittab innerhalb der virtuellen Maschine mussten natürlich auch noch vorgenommen werden, aber danach lief die DomU wieder und auch das Update von udev ließ sich problemlos einspielen. :-)

ext3-Dateisystem verkleinern mit Knoppix

Hatte ich schon erwähnt, dass ich im September umgezogen bin? Bin ich, nur in anderes Viertel, aber mit jemandem zusammen in eine neue WG, der wie ich ebenfalls einen kleinen Server zu Haus stehen hatte. Da die Hardware heutzutage leistungsfähig genug ist und Xen zuverlässig läuft, sind wir dabei Schritt für Schritt die Dienste von den beiden ehemaligen Servern auf eine Maschine mit ein paar virtuellen Xen-Hosts zu packen. Da ich ungern an Produktivsystemen neue Dinge ausprobiere, teste ich solche Sachen auf einem anderen Rechner. Gestern hatte ich dank dieser Anleitung auf besagtem Testrechner unter Debian Etch in kurzer Zeit einen laufenden Xen-Wirt eingerichtet. Die 40GB-Platte war dort ungefähr zu gleichen Teilen in /home und / geteilt – klassische Partitionen. Da ich Xen gern mit LVM testen wollte und die Partitionen kaum belegt waren, entschied ich mich für eine Neuaufteilung: 8 GB für das root-Filesystem und der Rest für LVM. Auf dem Testsystem sind außer Testinstallationen keine wichtigen Daten, also die erste Gelegenheit für mich, mal resize2fs auszuprobieren…

Beim Verkleinern einer Partition soll man erst mit resize2fs das Dateisystem (ich benutze eigentlich immer ext3) verkleinern und dann mit fdisk die Partition selbst noch verkleinern. Das Manual sagt, dass die Partition natürlich nicht kleiner gemacht werden soll als das Dateisystem – logisch. Zunächst jedoch will resize2fs nochmal e2fsck aufgerufen haben:

e2fsck -f /dev/hdb3
resize2fs -p /dev/hdb3 8G

Dann habe ich fdisk /dev/hdb aufgerufen, hdb3 gelöscht und neu angelegt. Der vorgeschlagene Beginn der Partition war der gleiche wie zuvor, habe ich extra kontrolliert und dann die Partition mit +8300M neu angelegt. Reboot und siehe da: reicht wohl nicht, es kommt die Beschwerde, dass das Dateisystem 2 097 152 Blöcke hat, die Partition aber nur 2 026 458. Also nochmal Knoppix booten und Partition neu anlegen. Interessant ist dann zunächst die Ausgabe von fdisk -l

Platte /dev/hdb: 40.0 GByte, 40020664320 Byte
16 Köpfe, 63 Sektoren/Spuren, 77545 Zylinder
Einheiten = Zylinder von 1008 × 512 = 516096 Bytes

    Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/hdb1   *           1         203      102280+  83  Linux
/dev/hdb2             204        2284     1048824   82  Linux Swap / Solaris
/dev/hdb3            2285       18367     8105832   83  Linux
/dev/hdb4           43895       77545    16960104    5  Erweiterte
/dev/hdb5           43895       77545    16960072+  83  Linux

fdisk zeigt hier auch Blöcke an, aber die Anzahl ist verschieden zu der, die zuvor e2fsck beim Boot des Systems zeigte – genau genommen exakt viermal so groß. Aber irgendwie stimmt das auch ungefähr mit den 8300 Megabyte von vorhin überein, in Kilobyte versteht sich. Ich habe dann also diesmal beim Neuanlegen der Partition +8388608K angegeben, das vierfache von dem Wert, den das System vorher beim Booten für die Größe des Dateisystem genannt hatte. Der kam wie gesagt ursprünglich von den 8G beim resize2fs. fdisk machte dann ein paar Blöcke mehr draus, als ich Kilobyte eingegeben hatte, umso besser. Da der Kernel noch nichts von der Änderung der Partitionstabelle durch fdisk wusste, lohnte ein e2fsck unter Knoppix nicht und ich hab gleich neu gestartet.

Das Debian etch beschwerte sich dann nicht mehr über ein Filesystem, das größer war als die Partition, ließ aber dennoch einen Check drüber laufen. Der weitere Systemstart verlief problemlos. Das LVM richte ich dann später ein…

happy

Interessant finde ich jedoch noch die Frage, was ich hätte eingeben müssen, um von vornherein die passenden Größen für resize2fs und fdisk parat zu haben, einfach auch 8G bei fdisk wäre nämlich deutlich zu wenig gewesen. Ziel: möglichst wenig Platz auf der Partition verschenken. Wer da Ideen hat, den bitte ich um Kommentare!

Spielverderber Pentium M

cpu-z Ich bin vor ein paar Wochen umgezogen. Mein neuer Mitbewohner hat ebenso wie ich einen Heimserver mit in die neue Wohnung getragen. Damit wir Strom sparen, soll aus den zweien ein neuer werden, auf dem dann mit Xen mehrere virtualisierte Systeme laufen. Im Zuge dessen schaue ich mir gerade verschiedene Plattformen an. Zur Auswahl stehen da unter anderem eisXen, von dem zur Zeit intern die beta 6 getestet wird. Außerdem in der engeren Wahl der c’t-Debian-Server, der ebenfalls Xen als Basis nutzt. Vielleicht wird es auch eine selbstgestrickte Lösung mit Debian oder Gentoo, mal sehen.

Vorher wollte ich allerdings die eine oder andere Sache testen. Da wir nicht unendlich viele Festplatten zur Verfügung haben, dachte ich mir, dass man das auch mit VMware probieren kann – dachte ich. Da hab ich nun 2 GB Arbeitsspeicher in meinem Notebook und einen fortschrittlichen Prozessor und dann hat Intel im Dothan-Kern die PAE weggelassen. Das macht das Ausführen eines Xen-Kernels auf dieser Maschine (auch in VMware) unmöglich. Blöde Spielverderber! :-(

Virtualisierung: Protected Mode 2.0?

Mit der Einführung des Protected Mode auf den i386-Prozessoren und der Ermöglichung des hardwaregestützten Multitasking-Betriebs wurden Rechnernutzung und Betriebssysteme auf dem PC-Sektor revolutioniert.

Lange Zeit gab es keine Neuentwicklungen – wenn man von speziellen Befehlssätzen wie SSE, MMX und multiskalaren Architekturen absieht (die den Prozessor zwar schneller und leistungsfähiger machen, aber keine konzeptuellen Neuerungen bringen).

Mittlerweile wird Virtualisierung immer mehr zum Thema und auf Prozessorebene mit der Paravirtualisierung zunehmend unterstützt.

Einige Fragen, die mir gerade in den Sinn kamen:

  • Ist die Virtualisierung der Nachfolger des Protected Mode?
  • Wird sie ebenso viel Auswirkungen auf unsere Systeme haben?
  • Und wie werden spätere Nutzungsszenarien aussehen?
  • Findet man neue Konzepte für die Struktur eines Desktop-Betriebssystems?
  • Oder bleiben wir dabei, mehrere Systeme auf einer Maschine zu integrieren und belassen Virtualisierung in einem “Nischendasein” für Serverarchitekturen?