Tag Archives: Xen

HowTo: FreeBSD als HVM-DomU in Xen auf Debian Wheezy

3 Replies

Zu Hause und im Netz39 e.V. läuft je ein Server mit Debian Wheezy auf amd64 und als Virtualisierungssystem wird Xen benutzt. Linux-Gäste werden paravirtualisiert und das läuft schon seit Jahren fluffig. Für bestimmte Zwecke muss es aber auch mal ein anderes System sein und das ist im Hackerspace ein aktuelles FreeBSD 9.1 und zu Hause ein Debian GNU/kFreeBSD, also kein Debian GNU/Linux, sondern eben das Debian mit dem ganzen GNU Userland und einem FreeBSD-Kernel. In beiden Fällen ist auch die VM die 64-Bit-Variante und die Hardwarevirtualisierung der jeweiligen Prozessoren soll genutzt werden. Was fehlt: die initiale Config für die VM und da hab ich gesucht, recherchiert und probiert und präsentiere jetzt, was bei mir funktioniert hat. Zu Hause sieht’s so aus:

vcpus = 2
memory = 1024
name = 'kleopatra'
builder = 'hvm'
kernel = 'hvmloader'
disk =  [
                'phy:/dev/mapper/heaven-kleopatra,hda,w',
                'file:/home/alex/debian-7.1.0-kfreebsd-amd64-netinst.iso,hdc:cdrom,r',
        ]
boot = 'dc'
vif = [ 'mac=00:16:3E:XX:XX:XX,bridge=xenbr0' ]
vfb = [ 'type=vnc' ]
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

Und im Space:

vcpus       = 1
memory      = 512
name        = 'hydrogen'
builder     = 'hvm'
kernel      = 'hvmloader'
disk        = [
            'phy:/dev/mapper/vgmarx-wasserstoff,hda,w',
            'file:/media/images/FreeBSD-9.1-RELEASE-amd64-disc1.iso,hdc:cdrom,r',
          ]   
boot        = 'dc'
vif     = [ 'mac=00:16:3E:XX:XX:XX,bridge=xenbr0' ]
vfb     = [ 'type=vnc' ]
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

In beiden Fällen hatte ich zuvor Xen nach der Anleitung im Debian-Wiki aufgesetzt. Die XX in den Mac-Adressen sind durch zufällige Werte zwischen 00h und FFh zu ersetzen. Die Erzeugung von Zufallszahlen und die Umrechnung ins Hexadezimalsystem überlasse ich als Hausaufgabe.

Nach dem Start der DomU macht man einen SSH-Tunnel auf für den VNC-Port und verbindet sich mit seinem bevorzugten VNC-Client1 auf localhost:

ssh -L 5900:localhost:5900 yourxenhost

Nach der Installation in der Config die Bootreihenfolge anpassen bzw. das CD-Image rausnehmen, fertig.

  1. unter KDE benutze ich krdc, auch wenn ich den Namen grauslig finde [↩]

Xen: Debian Squeeze DomU in Debian Lenny Dom0

2 Replies

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. :-)