Einige weitere Modifikationen wie Bootsplash mit fbsplash, die demnächst in einem kommerziellen Derivat sichtbar sein werden, sind noch nicht aktiv. Hier geht’s lang zum Blogpost:

http://blog.lesslinux.org/fresh-development-build-isohybrid-conversion-and-boot-on-xen/

Installation von Debootstrap

Zuerst muss debootstrap vorhanden sein, am einfachsten natürlich mit apt-get install debootstrap. Unter Ubuntu kann mit debootstrap auch die Folgeversion installiert werden. Debian-User können das Ubuntu-Debootstrap direkt von http://archive.ubuntu.com/ubuntu/pool/main/d/debootstrap/ herunterladen und mit dpkg -i installieren. Nutzer von RPM-Distributionen sollten ein Konvertierungstool installieren oder Debootstrap direkt aus dem .tar.gz installieren.

Vorbereitung eines Images

Für Xen DomUs haben Sie die Möglichkeit, physikalische Festplatten oder deren Partitionen zu nutzen oder Festplattenimages zu verwenden. Bei den Images wiederum gibt es zwei Möglichkeiten: Tap-Disks, die wachsen können und beispielsweise VMware VMDK-Format unterstützen oder “Plain-Images”, die als Loopback-Device gemountet werden können. Ich empfehle bei Testkonfigurationen grundsätzlich und bei Produktivsystemen für die Systempartitionen Images von Partitionen. Die Gründe:

• Im Gegensatz zu partitionierten Festplattenimages kann ein Partitionsimage ohne Verrenkungen vergrößert werden
• Ein Mounten ist simpel mit mount -o loop ... möglich, es muss kein Offset errechnet und angegeben werden
• Im Gegensatz zu VMDK-Images benötigt der Mount auf einer Xen-losen Maschine keine zusätzlichen Werkzeuge

Images erstelle ich als Sparse-Images, das geht schnell und spart Plattenplatz, hat aber bei Maschinen mit vielen Xen-Instanzen deutlich spürbare Einbußen durch doppelte Fragmentierung zur Folge. Zunächst entsteht ein Image für die Systempartition. Da ich gerne auch Kernel in der Xen-Instanz baue, hier 8GB groß, das Swap-Image bekommt ein Gigabyte:

dd if=/dev/zero bs=$((1024**2)) count=1 seek=8191 of=xvda1.img
dd if=/dev/zero bs=$((1024**2)) count=1 seek=1023 of=swap.img

Als nächstes entsteht eine Swap-Signatur und ein Dateisystem auf dem Image xvda1.img. Das Dateisystem mounte ich gleich auf einen noch zu erstellenden Mountpoint /tmp/minibuntu:

mkswap -f swap.img
freeloop=` losetup -f `
losetup $freeloop xvda1.img
echo "loopdevice is $freeloop"
mkfs.ext3 $freeloop
mkdir /tmp/minibuntu
mount $freeloop /tmp/minibuntu

Installation des Basissystems

Die Installation des Basissystems geht innerhalb weniger Minuten mit dem Befehl debootstrap. Auf einem 64-Bit Hostsystem haben Sie die Wahl, 32- oder 64-Bit-Gäste zu installieren. Bei Gästen, die keine allzu große Prozessgröße erwarten lassen, sind 32-Bit-Gäste oft einen Tick flotter und kompakter:

debootstrap --arch i386 lucid /tmp/minibuntu http://archive.ubuntu.com/ubuntu

oder

debootstrap --arch amd64 lucid /tmp/minibuntu http://archive.ubuntu.com/ubuntu

Das so installierte Ubuntu würde sich mit dem Hostkernel schon booten, darüber hinaus jedoch kaum nutzen lassen. Setzen wir einige Einstellungen:

vim /tmp/minibuntu/etc/default/locale

# BEGIN /etc/default/locale
LANG="POSIX"
# oder
# LANG="de_DE.UTF-8"
# END /etc/default/locale

vim /tmp/minibuntu/etc/network/interfaces

# BEGIN /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
# END /etc/network/interfaces

echo '127.0.0.1 localhost' > /tmp/minibuntu/etc/hosts
echo 'lucid-domU.test' > /tmp/minibuntu/etc/hostname

Auch eine vollständige /etc/apt/sources.list wird benötigt:

vim /tmp/minibuntu/etc/apt/sources.list

# BEGIN /etc/apt/sources.list
deb http://de.archive.ubuntu.com/ubuntu/ lucid main restricted
deb-src http://de.archive.ubuntu.com/ubuntu/ lucid main restricted
deb http://de.archive.ubuntu.com/ubuntu/ lucid-updates main restricted
deb-src http://de.archive.ubuntu.com/ubuntu/ lucid-updates main restricted
deb http://de.archive.ubuntu.com/ubuntu/ lucid universe
deb-src http://de.archive.ubuntu.com/ubuntu/ lucid universe
deb http://de.archive.ubuntu.com/ubuntu/ lucid-updates universe
deb-src http://de.archive.ubuntu.com/ubuntu/ lucid-updates universe
deb http://de.archive.ubuntu.com/ubuntu/ lucid multiverse
deb-src http://de.archive.ubuntu.com/ubuntu/ lucid multiverse
deb http://de.archive.ubuntu.com/ubuntu/ lucid-updates multiverse
deb-src http://de.archive.ubuntu.com/ubuntu/ lucid-updates multiverse
deb http://security.ubuntu.com/ubuntu lucid-security main restricted
deb-src http://security.ubuntu.com/ubuntu lucid-security main restricted
deb http://security.ubuntu.com/ubuntu lucid-security universe
deb-src http://security.ubuntu.com/ubuntu lucid-security universe
deb http://security.ubuntu.com/ubuntu lucid-security multiverse
deb-src http://security.ubuntu.com/ubuntu lucid-security multiverse
# END /etc/apt/sources.list

Ohne /etc/fstab geht wenig im domU-System, die Platten heissen nicht mehr wie bei den alten dom0- und domU-Kerneln /dev/sda, sondern /dev/xvda:

vim /tmp/minibuntu/etc/fstab

# BEGIN /etc/fstab
proc /proc proc defaults 0 0
/dev/xvda1 / ext3 defaults 0 1
/dev/xvda2 none swap sw 0 0
# END /etc/fstab

Eine Konsole für Xen. Xen nutzt /dev/hvc0 als Systemkonsole, diese muss noch mit einem getty versehen werden. Das erledigen Sie durch Kopieren der Definition von tty1 und entsprechende Anpassungen:

cp /tmp/minibuntu/etc/init/{tty1,hvc0}.conf
sed -i 's/tty1/hvc0/g' /tmp/minibuntu/etc/init/hvc0.conf

Chroot, Passwort und Kernel

Zum Abschluss der Installation und der Nachinstallation von Software müssen Sie per chroot in das frisch installierte Ubuntu wechseln. Zunächst benötigen Sie dafür einige spezielle Dateisysteme:

mount -t proc none /tmp/minibuntu/proc
mount -t devpts none /tmp/minibuntu/dev/pts 

Wenn Host und Gast die gleiche Architektur nutzen, klappt der Chroot klassisch:

LANG=C chroot /tmp/minibuntu /bin/bash

Ist der Host dagegen 64 bittig und der Gast 32 bittig, ist setarch zu verwenden:

LANG=C setarch i386 chroot /tmp/minibuntu /bin/bash

Zunächst aktivieren wir Shadow-Passwörter und setzen ein Root-Passwort:

shadowconfig on
passwd

Auf 32-Bit-Gästen muss zwingend ein PAE-Kernel installiert werden. Nur dieser enthält Unterstützung für pvops. Kernel ohne PAE laufen nur auf dem “nackten Metall”. Bei 64 Bit sollten alle Kernel pvops unterstützen:

apt-get install linux-image-generic-pae

Da ein Bootloader bei unserer Konfiguration keinen Sinn macht, sind entsprechende Nachfragen mit [No] zu beantworten.

Aufbau des Initramfs

Im Gegensatz zu gängigen Dateisystemtreibern enthält Ubuntus Kernel die Frontend-Treiber für Blockdevices und das Netz nur als Module. Diese sind entsprechend zu Initramfs-Konfiguration hinzuzufügen:

vim.tiny /etc/initramfs-tools/initramfs.conf

MODULES=list

Diese Liste ist entsprechend anzupassen:

vim.tiny /etc/initramfs-tools/modules

# BEGIN /etc/initramfs-tools/modules
xen-kbdfront
xen-netfront
xen-blkfront
# END /etc/initramfs-tools/modules

Und anschließend wird das Initramfs neu aufgebaut:

mkinitramfs -o /boot/initrd.img-2.6.32-24-generic-pae 2.6.32-24-generic-pae

Verlassen Sie nun den Chroot wieder und unmounten Sie die beiden speziellen Dateisysteme.

exit
umount /tmp/minibuntu/proc
umount /tmp/minibuntu/dev/pts

Kopieren der Kernel, Aufbau der domU-Konfiguration

Kopieren Sie nun Kernel und Initramfs von /tmp/minibuntu/boot in das Verzeichnis, welches Festplattenimages und später die Konfiguration enthält. Erstellen Sie dann eine Datei ubuntu.cfg mit folgendem Inhalt (selbstverständlich ist der Pfad zum Installationsverzeichnis anzupassen und Kernel sowie Initramfs umzubenennen oder zu verlinken):

kernel = "/usr/local/xendomains/lucid_test/vmlinuz"
ramdisk = "/usr/local/xendomains/lucid_test/initrd.gz"
memory = 512
name = "lucid-test"
vif = [ 'mac=00:16:00:00:42:23' ]
disk = [ 'file:/usr/local/xendomains/lucid_test/xvda1.img,xvda1,w',
         'file:/usr/local/xendomains/lucid_test/swap.img,xvda2,w' ]
root = '/dev/xvda1 ro'
extra = 'console=hvc0'

Jetzt nicht vergessen, das Loopback-Device zu unmounten und freizugeben:

umount /tmp/minibuntu
umount $freeloop
losetup -d $freeloop

Dann kann auch die neue domU gestartet werden:

xm create -c ubuntu.cfg

Melden Sie sich in der Konsole der domU an und installieren Sie die Xen-Version der C-Bibliothek, sowie OpenSSH nach:

apt-get install ssh libc6-xen

Beim nächsten Mal kann dann die Domain ohne -c gestartet und per SSH zugegriffen werden. Soll die virtuelle Festplatte vergrößert werden, kann dies nach dem Herunterfahren mit dd erfolgen:

dd if=/dev/zero bs=$((1024**2)) count=1 seek=16383 of=xvda1.img
freeloop=` losetup -f`
losetup $freeloop xvda1.img
fsck.ext3 -f $freeloop
resize2fs $freeloop
losetup -d $freeloop

That’s it! Soll die domU automatisch mit dem Xend des Hostes starten, die .cfg in /etc/xen/auto verlinken und darauf achten, dass das Startscript /etc/init.d/xendomains beim Systemstart unmittelbar nach xend gestartet wird. Die so erstellte Domain ist prinzipiell portabel, man sollte sich allerdings keine allzugroßen Hoffnungen auf einen Boot unter alten Xen-Versionen (vor 3.4) machen. Sind noch alte dom0s vorhanden, schafft möglicherweise Ubuntus ec2-Kernel für Amazons Elastic Computing Cloud Abhilfe.

Ich habe einmal testweise ein Setup auf einer AMD64-Maschine erstellt, auf 32-Bit-Systemen sind lediglich einige Kleinigkeiten anders: Der Kernel muss PAE-Support haben und es muss zwingend ein Prozessortyp ausgewählt werden, der über Virtualisierungserweiterungen verfügt. Da heutzutage kaum Rechner als Xen-Host zum Einsatz kommen dürften, die nicht 64-Bit-tauglich sind, sollte sich die Frage nach pvops-Dom0s auf 32-Bit-Hardware kaum stellen.

Die Vorbereitung

Fürs Bauen des Kernels müssen zuerst einige Debian-Pakete nachinstalliert werden. Meine Testmaschine war ein recht blankes Netinstall, so dass diese Liste hoffentlich vollständig ist:

apt-get install build-essential libncurses5-dev python-twisted \
        git-core zlib1g-dev gettext libX11-dev uuid-dev libssl-dev\
        bin86 bcc flex bison python-dev bridge-utils

Neuere Xen-Versionen benötigen Intels ACPI-Compiler. Den habe ich noch nicht in den Ubuntu-Paketlisten gefunden, stattdessen habe ich ihn aus den Quellen gebaut und mittels install installiert. Da nur ein einziges Binary benötigt wird, ist es leicht möglich, das temporäre Build-Verzeichnis in den Pfad aufzunehmen und so das System nicht zu verschmutzen. Bitte prüft vor der ACPICA-Installation, ob unter http://www.acpica.org/downloads/ neuere Versionen bereitstehen:

cd /usr/src
wget http://acpica.org/download/acpica-unix-20100806.tar.gz
tar xvzf acpica-unix-20100806.tar.gz
cd acpica-unix-20100806/compiler
make
install -m 0755 iasl /usr/bin

Bau und Boot des pvops-Kernels

Wie eingangs erwähnt, ist Support für pvops-Dom0 noch nicht Teil des offiziellen Kernels. Es muss daher Jeremys 2.6.32er mit pvops-Patches ausgecheckt werden. Falls jemand abkürzen möchte, kann er hier die von mir verwendeten Sourcen herunterladen, diese beinhalten bereits eine .config.

cd /usr/src
git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux-2.6-xen
cd linux-2.6-xen
git reset --hard
git checkout -b xen/stable-2.6.32.x origin/xen/stable-2.6.32.x

Beim Selbstbau dürfte es meist ganz gut passen, die Kernelconfig des Ubuntu als Basis zu verwenden und mit make oldconfig die Xen-spezifischen Punkte zu ergänzen. Wer dabei die richtigen Treiber statisch einbindet, braucht auch an der Initramfs-Konfiguration nichts zu modifizieren:

cd /usr/src
cd linux-2.6-xen
cp /boot/config-` uname -r ` .config
make oldconfig

Zum Vergleich hier meine Xen-spezifischen Optionen:

CONFIG_XEN=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=32
CONFIG_XEN_SAVE_RESTORE=y
CONFIG_SWIOTLB_XEN=y
CONFIG_MICROCODE_XEN=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
CONFIG_XEN_DOM0_PCI=y
CONFIG_XEN_PCI_PASSTHROUGH=y
CONFIG_PCI_XEN=y
CONFIG_XEN_PCIDEV_FRONTEND=y
CONFIG_XEN_BLKDEV_FRONTEND=m
CONFIG_NETXEN_NIC=m
CONFIG_XEN_NETDEV_FRONTEND=m
CONFIG_XEN_KBDDEV_FRONTEND=m
CONFIG_HVC_XEN=y
CONFIG_XEN_FBDEV_FRONTEND=m
CONFIG_XEN_BALLOON=y
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XEN_DEV_EVTCHN=m
CONFIG_XEN_BACKEND=y
CONFIG_XEN_NETDEV_BACKEND=y
CONFIG_XEN_BLKDEV_BACKEND=y
CONFIG_XEN_BLKDEV_TAP=y
CONFIG_XEN_BLKBACK_PAGEMAP=y
CONFIG_XEN_PCIDEV_BACKEND=y
CONFIG_XEN_PCIDEV_BACKEND_VPCI=y
CONFIG_XENFS=m
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_MCE=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_GNTDEV=m
CONFIG_XEN_S3=y
CONFIG_ACPI_PROCESSOR_XEN=y
CONFIG_XEN_PLATFORM_PCI=m

Wer möchte, kann meine Konfiguration komplett oder als unified diff (gegen Ubuntus 2.6.32-24 Kernel) herunterladen und diese verwenden. Das Bauen geht dann wie gewohnt, ich strippe die Kernelmodule und erstelle gleich eine GRUB-Konfiguration:

make
make install
make modules_install
find /lib/modules/2.6.32.18-xen0-pvops/ -name '*.ko' -exec strip --strip-unneeded {} \;
mkinitramfs -o /boot/initrd.img-2.6.32.18-xen0-pvops 2.6.32.18-xen0-pvops
update-grub

Der erste Neustart

Rebooten Sie nun den Rechner und wählen Sie den neuen pvops-Kernel als Startkernel aus. Die Maschine sollte problemlos hochfahren, tut sie das nicht, stehen die Chancen schlecht, dass dieser Kernel auch auf Xen sauber startet.

Installation von Xen und den Xen-Tools

Als dieses Tutorial erstellt wurde, war mit Xen 4.0.1 gerade die erste Maintenance-Release der 4.0er-Reihe erhältlich. Falls Sie noch 3.4.x oder 4.0.0 verwenden (und damit zufrieden sind): Aktualisieren Sie auf jeden Fall auf 4.0.1, weil hier einige Bugs im Zusammenspiel von Xen und dom0-pvops-Kerneln beseitigt wurden:

cd /usr/src
wget http://bits.xensource.com/oss-xen/release/4.0.1/xen-4.0.1.tar.gz
tar xvzf xen-4.0.1.tar.gz
cd xen-4.0.1
make xen
make install-xen
make tools
make install-tools PYTHON_PREFIX_ARG=

Es folgt die Erstellung einer Bootloder-Konfiguration, bitte die UUID entsprechend anpassen:

vim.tiny /etc/grub.d/50_xen

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry "Ubuntu 10.04 - Xen 4.0.1 - 2.6.32.18 pvops" {
        insmod ext2
        set root=(hd0,1)
        search --no-floppy --fs-uuid --set dc50c3d6-787a-45d7-951b-20836d10443c
        multiboot /boot/xen-4.0.1.gz dummy=dummy
        module /boot/vmlinuz-2.6.32.18-xen0-pvops root=UUID=dc50c3d6-787a-45d7-951b-20836d10443c ro dummy=dummy
        module /boot/initrd.img-2.6.32.18-xen0-pvops
}

chmod a+x /etc/grub.d/50_xen
vim.tiny /etc/default/grub

GRUB_DEFAULT="Ubuntu 10.04 - Xen 4.0.1 - 2.6.32.18 pvops"
GRUB_HIDDEN_TIMEOUT=30
GRUB_HIDDEN_TIMEOUT_QUIET=false

Anschließend nicht vergessen, die Grub-Konfiguration noch einmal neu aufzubauen:

update-grub

Ein Dateisystem für Xen: Einige Scripte benäötigen das alte /proc/xen. Dieses wird durch einen Eintrag in der /etc/fstab beim nächsten Neustart gemountet:

xenfs /proc/xen xenfs defaults

Dann benötigen wir noch zwei Module und deren Devices – die Module sollten in die /etc/modules eingetragen werden:

modprobe -v xen-evtchn
modprobe -v xen-gntdev

mkdir /dev/xen
mknod -m 0660 /dev/xen/gntdev c 10 57
mknod -m 0660 /dev/xen/evtchn c 10 58

Das war es: Beim nächsten Neustart startet der eben gebootete pvops-Kernel nicht auf nacktem Metall, sondern auf dem Hypervisor. Mit pvops-Kernel sollte es auch möglich sein, die beschleunigten Grafiktreiber von AMD und nVidia zu nutzen, ausprobiert habe ich dies nicht, weil bei mir Xen nur auf dem Server eingesetzt wird.

Auf die Konfiguration von pvops-DomUs gehe ich in den nächsten Tagen ein: Für diese halten aktuelle Distributionen oft passende Kernel bereit, ich werde jedoch auch zeigen, wie man mit einem frischen Vanilla-Kernel 2.6.35.x ein wenig mehr herausholt.

Vielen Dank an…

• …das offizielle Xen-Blog, an dessen Anleitung ich mich grob orientiert habe
• …die Mitarbeiter des Xen-Wikis, die viele wertvolle Informationen zu pvops zusammengetragen haben

Update, 31. August 2010

• bridge-utils zur Paketliste hinzugefügt
• Ergänzung zu /proc/xen
• Ergänzung zu fehlenden Devices und Modulen

• Wie stark suckt Flash? Es gibt eine Beta der 10.1 für Linux, Hardwarebeschleunigung inbegriffen, News bei LinuxForDevices.com.

  Ich konnte mich nie wirklich mit Flash unter Linux, BSD oder MacOS X anfreunden und werde es wahrscheinlich nie wirklich können. Auf meinem 64 Bit Desktop läuft Flash im Plugin-Wrapper und schmiert zweimal am Tag ab. Ich bin damit die meiste Zeit ohne Flash unterwegs und vermisse es nicht wirklich. Nur wenn ich gerade Flash für ein kleines Video brauche, ist es nicht da. Ich hoffe, dass HTML5-Video bald soweit verbreitet ist, dass man auch für die Freizeit kein Flash-Plugin mehr braucht.

• Endlich kostenlose Navigation auf dem Nokia E71 Nokia reagiert auf protestierende Nutzer: News bei engadget.com.

  Dass Nokia seine kostenlose Navigation beim Start nur für eine Hand voll Geräte anbot, fand ich ärgerlich. Sollte ich ein ein Jahr altes E71 wegwerfen und ein mir ein E72 kaufen, um in den Genuß der Navigationslösung zu kommen? Der Protest der letzten Monate hat gewirkt: Nokia bietet die kostenlose Ovi Maps Version 3.0.3 nun auch für E66 und E71.

• Mein YaCY-Host läuft wieder! Ich mache wieder bei der freien Suchmaschine mit und helfe, mich und andere von Google abzunabeln.

  Auf dem Büroserver läuft nun eine Xen-Instanz mit 1,25GB RAM und 30GB Platte. 25GB Plattenplatz und 1GB RAM darf sich Yacy nehmen, dafür habe ich die CPU-Zyklen etwas beschränkt und stelle nur einen Prozessorkern bereit. Cool: Wenn man die Proxy-Indexierungstiefe auf 1 setzt und hin und wieder doch zu Google greifen muss, indexiert Yacy die auf den gelesenen Google-Ergebnisseiten verlinkten Seiten.

  Nachtrag: Hier gibt es einen älteren Artikel von mir zu Einrichtung und Funktionsweise von YaCY.

• Xen 4.0 erschienen: Neue Version des Hypervisors, News bei Golem.

  Wenn ich die Nachricht richtig deute, läuft Kernel 2.6.31 dann mit pv_ops auf Xen (der Kernel erkennt, ob er auf Xen oder direkt auf der Hardware läuft), wenn ein Prozessor mit Intels oder AMDs Virtualisierungserweiterungen gefunden wird. Damit ist der Einsatz neuer Xen-Versionen auf vielen Maschinen die älter als zwei Jahre sind, in weite Ferne gerückt. Immerhin: Da pv_ops ein fester Bestandteil des Kernels ist/wird, hat das manuelle Patchen des dom0-Kernels bald ein Ende. Ich hoffe, dass Xen damit eine Zukunft im SMB-Bereich und nicht nur im Rechenzentrum hat, denn KVM hat mit PCI Passthrough u.ä. in letzter Zeit mächtig aufgeholt.

• Einsteiger-Smartphones von Nokia C3, C6 und E5, News bei Golem, News bei Engadget und News bei Infosync.

  Immer noch kein Symbian^3, stattdessen das neu gelabelte Symbian^1 (TOFKAS605TH = The OS Formerly Known As Series 60 5th Edition), nett und meine Erfahrungen mit E71 und 5230 zeigen, dass Nokia durchaus brauchbare Geräte mit langen Standby-Zeiten und schneller Navigation bauen kann, auch die Preise sind moderat und die Tastatur des E5 hoffentlich so gut wie beim E71, aaaaaber von einem Gerät wie dem C6 hätte ich langsam das neue Touchscreen-Symbian erwartet.

Beim Neuaufsetzen eines Servers ist es besser, gleich eine PointToPoint-Lösung mit 255.255.255.255-Maske aufzusetzen. Damit können bei einer 29-Bit-Maske (255.255.255.248) acht statt fünf IP-Adressen genutzt werden — satte 60% mehr (bei vier, fünf, oder sechs Bit Masken fällt der Gewinn natürlich kleiner aus). Die Änderungen gegenüber dem Setup von gestern sind, dass dummy0 in der /etc/network/interfaces der dom0 entfällt. In der /etc/xen/xend-config.sxp wird das extern erreichbare Interface eingetragen (in der Regel eth0):

(network-script 'network-route netdev=eth0')
(vif-script     'vif-route netdev=eth0')

Die Netzwerkkonfiguration der domU bekommt nun die primäre IP-Adresse der dom0 als Gateway eingetragen, dazu das Schlüsselwort pointopoint (nur ein ‘t’!) und die “dichte” Netzmaske:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 172.16.16.114
        netmask 255.255.255.255
        gateway 192.168.1.2
        pointopoint 192.168.1.2
        post-up ethtool -K eth0 tx off

Vielen Dank an…

• Umstellung Debian Etch mit XEN 3 auf routed …die fleissigen Dokumentatoren im Hetzner-Wiki
• …den Admin bei 1&1, dessen Default-Setup mit pointopoint auf der primären IP mich dazu anregte, hier nochmal nachzuforschen

Ziel waren zwei Server: Ein 64-Bit-System fürs Büro und ein 32-Bit-System für einen alten (AMD Athlon XP 2000, 512MB, 80GB) Hetzner Rootie (Presse-Testsystem). Beide Systeme wurden zunächst mit einem Ubuntu Minimalsystem ausgestattet. Bei Hetzner geschah dies aus dem Notfall-System per debootstrap (fertige OS-Images werden nur einmal am Tag aufgespielt, was stört, wenn man nach einer abgeschossenen Installation neu aufsetzen möchte) und der Server zuhause wurde per Debian-Installer per PXE-Netboot eingerichtet. Die zwei Möglichkeiten, einen Hetzner-Server mit Ubuntu oder Debian auszustatten — debootstrap und den Debian-Installer im SSH-Modus — erkläre ich bei Gelegenheit im Detail.

Benötigte Pakete

Mit dem folgenden Befehl sollten alle Abhängigkeiten aufgelöst werden, die zum Bau von Xen und dem Betrieb einer Dom0 benötigt werden:

apt-get install rsync screen build-essential bin86 bcc libssl-dev \
      gettext libncurses-dev python python-dev pciutils-dev libx11-dev \
      pkg-config python-twisted bridge-utils gawk

Unter 32 Bit-Systemen sollte man aus Performance-Gründen noch die angepasste C-Bibliothek installieren:

apt-get install libc6-xen

Kernel kompilieren

Ubuntu selbst bietet einen Kernel für Amazons EC2, der sollte einigermaßen gut auf aktuellen Xen-Versionen laufen. Getestet habe ich es nicht. Stattdessen habe ich selbst drei Kernel kompiliert: Einen für AMD64 mit vollem Dom0-Support und vielen Treibern, einen mit stark abgespeckten Treibern (für 64Bit-DomUs) und einen i686-Kernel mit vollem Dom0-Support und der Möglichkeit, auf älteren Xen-Versionen gestartet zu werden. Die für Xen benötigten Frontend- sowie Backend-Treiber habe ich statisch integriert, was den Vorteil hat, dass an der Konfiguration des Initramfs nichts geändert werden muss. Alle Konfigurationen bieten Verbesserungspotential, beispielsweise beim Abspecken um nicht benötigte Treiber. Hier sei allerdings darauf verwiesen, dass das Entfernen vermeintlich nicht benötigter Funktionen Unresolved Symbols und damit Kompilationsabbrüche zur Folge haben kann.

Als Kernel kommt hier Gentoos 2.6.31.12 — konkret das Patchset xen-patches-2.6.31-12.tar.bz2 — zum Einsatz. Die verwendeten Patches stammen größtenteils von openSUSEs Xen-Kernel, wurden aber von SuSE-Spezifika befreit. Das macht das Bauen und die Installation einfacher. Gepflegt werden die Patches als eigenes Projekt bei Google Code.

Meine Konfigurationsdateien:

• config-2.6.31.12-mfs002-xen0-compat-i586
• config-2.6.31.12-mfs001-xen0-amd64
• config-2.6.31.12-mfs006-xenU-minimal-amd64

Und nun zum Bauen des Kernels, hier für AMD64:

mkdir xen-patches-2.6.31-12
cd xen-patches-2.6.31-12
tar xvjf ../xen-patches-2.6.31-12.tar.bz2
cd ../linux-2.6.31
for i in ../xen-patches-2.6.31-12/*.patch1 ; do patch -p1 < $i ; done
wget -O .config http://cdprojekte.mattiasschlenker.de/Public/Xen-Kernel/config-2.6.31.12-mfs001-xen0-amd64
make oldconfig
make
make install
make modules_install

Der Kernel braucht noch ein passendes Initramfs, dieses entsteht mit:

mkinitramfs -o /boot/initrd.img-2.6.31.12-mfs001-xen0-amd64 2.6.31.12-mfs001-xen0-amd64

Falls Sie Xen Frontend- oder Backend-Treiber in Module ausgelagert haben, müssen Sie ggf. die Modulliste des Initramfs anpassen!

Xen Hypervisor installieren

Ohne Xen nützt der schönste Kernel nichts, also bauen und installieren wir Xen 3.4.2 aus dem offiziellen Tarball von www.xen.org:

tar xvzf xen-3.4.2.tar.gz
cd xen-3.4.2
make xen
make install-xen

Bootloader konfigurieren

Der einfachste Weg ist die Erstellung eines simplen Scriptes /etc/grub.d/50_xen, welches hart kodiert Kernelnamen, Xen-Version und Pfade (Root-Device ist hier /dev/sda4) enthält. Zweimal root=... ist kein Tippfehler, sondern als Workaround für einen kleinen Bug in den Scripten des Initramfs gedacht:

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.

menuentry "Ubuntu 9.10 - Xen 3.4.2 + Linux 2.6.31" {
        insmod ext2
        set root=(hd0,4)
        multiboot /boot/xen-3.4.2.gz
        module /boot/vmlinuz-2.6.31.12-mfs001-xen0-amd64 root=/dev/sda4 ro root=/dev/sda4
        module /boot/initrd.img-2.6.31.12-mfs001-xen0-amd64
}

Das Script muss nun noch ausführbar gesetzt werden, sonst wird der neue Eintrag nicht in die GRUB-Konfiguration übernommen!

chmod a+x /etc/grub.d/50_xen

In der Datei /etc/default/grub sollten Sie den Standard-Booteintrag auf den neuen Kernel setzen:

GRUB_DEFAULT="Ubuntu 9.10 - Xen 3.4.2 + Linux 2.6.31"

Danach rufen Sie update-grub auf um die Bootloader-Konfiguration neu aufzubauen. Rebooten Sie jetzt den Rechner mit Xen und dem neuen Kernel.

Installation der Xen-Tools

Die Xen-Tools habe ich in einem frisch entpackten Xen-Tarball kompiliert. Die bei der Installation angegebene Variable ist wichtig, damit die Python-Module in den bei Ubuntu üblichen Pfaden landen. Gibt man diese Variable nicht an, ist es ggf. erforderlich eine Umgebunsvariable PYTHONPATH zu setzen und diese ggf. in das Script /etc/init.d/xend einzubauen:

rm -rf xen-3.4.2
tar xvzf xen-3.4.2.tar.gz
cd xen-3.4.2
make tools
make install-tools PYTHON_PREFIX_ARG=

Wenn alles geklappt hat, lässt sich der Xend starten. Läuft dieser, können die Bootmeldungen des Hypervisors ausgelesen werden.

/etc/init.d/xend start
xm dmesg

Xend in den Runleveln verlinken

Ich habe Xend vor dem SSH-Server verlinkt, den Start der domU-Instanzen danach. Grund waren Probleme mit dem SSH-Server: Upstart (oder der Xend?) versucht diesen neu zu starten, wenn neue Interfaces auftauchen. Das gelingt nicht immer, so dass ich während meiner Tests häufiger ohne SSH da stand. Auf einem Root-Server ist so etwas natürlich ganz bescheiden.

update-rc.d xend start 14 2 3 4 5 . stop 80 0 1 6 .
update-rc.d xendomains start 21 2 3 4 5 . stop 79 0 1 6 .

Vorbereitung für Routing-Setup

Achtung: Siehe auch den Nachtrag vom 19. März für ein besseres Setup!

Provider wie Hetzner oder Strato routen einem Server zugewiesene Subnetze auf dessen primäre IP-Adresse. Deshalb muss bei diesen Servern das Xen-Netzwerk von bridged auf routed umgestellt werden. Achtung: Einige Provider klemmen Server gnadenlos ab, wenn hinter einem Port des Routers bislang unbekannte MAC-Adressen auftauchen. Wer den Xend bei so einem Provider startet, ohne vorher auf routed umgestellt zu haben, fliegt aus der SSH-Verbindung raus und darf mit dem Support telefonieren!

Zuerst wird die Datei /etc/modules um eine Zeile

dummy

für den Dummy-Netzwerk-Adapter erweitert.

Es folgt die statische Konfiguration der primären IP-Adresse auf eth0 und der ersten nutzbaren IP-Adresse auf dummy. In diesem Fall haben wir das Subnetz 172.16.16.112/ 255.255.255.248 (acht Adressen von .112 bis .119) zugewiesen bekommen, .112 ist hier die Adresse des Netzes, .113 wird auf dummy0 gelegt, .114 bis .118 (fünf von acht Adressen) sind für die domUs nutzbar und .119 ist die Broadcast-Adresse:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 192.168.1.2
        netmask 255.255.255.0
        gateway 192.168.1.1

auto dummy0
iface dummy0 inet static
        address 172.16.16.113
        netmask 255.255.255.248

In der Konfigurationsdatei /etc/xen/xend-config.sxp des Xend muss die Einstellung von bridged auf routed umgestellt werden. Das zu routende Device muss explizit angegeben werden:

# (network-script network-bridge)
# (vif-script     vif-bridge)
(network-script 'network-route netdev=dummy0')
(vif-script     'vif-route netdev=dummy0')

An dieser Stelle ist ein Neustart des Xend, besser ein Reboot erforderlich. Anschließend können die domUs konfiguriert werden. Die Routing-Informationen werden hierfür in der Client-Config eingetragen:

kernel = "/boot/vmlinuz-2.6.31.12-mfs006-xenU-minimal-amd64"
ramdisk = "/boot/initrd.img-2.6.31.12-mfs006-xenU-minimal-amd64"
memory = 256
name = "ubuntu-amd64-minimal"
vif = [ 'ip=172.16.16.114' , 'mac=00:16:00:00:00:27' ]
disk = [ 'file:/usr/local/xendomains/test01_64/sda1.img,sda1,w' ]
root = "/dev/sda1 ro"
extras = "console=hvc0 xencons=tty"

Daneben ist es erforderlich, die IP-Konfiguration in der /etc/network/interfaces der domU einzutragen -- DHCP möchte ich an dieser Stelle nicht erklären, das würde den Rahmen sprengen.

Vielen Dank an...

• Installing Xen on Ubuntu 9.10 -- Brandon's Blog ...für die Idee mit dem Gentoo-Kernel und die GRUB-Konfiguration
• An introduction to custom Xen networking -- Debian Administration ...für die Hinweise zum Routed-Setup

Anmerkungen:

• Nie erst Ubuntus Xen-Tools 3.3 installieren und dann diese Anleitung durchführen. Das resultierende Versionsmischmasch wird garantiert kein funktionierendes Netzwerk zur Folge haben!

• Details zur domU-Konfiguration bei Hetzner folgen

• Details zur Ubuntu-/Debian-Installation aus Hetzners Rettungssystem folgen

Denkste…

Auf dem Büroserver lief ein Vanilla-Xen mit selbstgebautem Kernel. So sollte es auch bleiben. Für ein Update des Ubuntu 7.10 mit Xen 3.2 bestand zunächst keine Veranlassung, ich besorgte mir also frische openSUSE-11.0-Kernel-Quellen — die sind relativ aktuell (2.6.25) und enthalten die Xen-Patches mit all den von mir benötigten Features. Dummerweise brach der Build mit einem Compile-Fehler ab — möchte openSUSEs Kernel etwa einen bestimmten Compiler? Da die Dom0 letztlich nicht besonders viele Dienste beherrbergt und eigentlich dazu dient, Geräte an die DomUs durchzuschleifen, entschied ich mich für das Aufsetzen einer frischen Dom0. Als Distribution sollte openSUSE 11.0 zum Einsatz kommen, schließlich ist Novell neben RedHat der Distributor mit dem stärksten Xen-Engagement und sollte daher eine komplette und gut abgestimmte Dom0 liefern. Leser, die über planet.ubuntuusers.de auf diesen Eintrag kamen, mögen mir verzeihen.

Und dann nach Netzwerkprobleme

Als Installationsmedium verwenden wir gerne einen PXE-/TFTP-Bootserver. Da genügt es, den Rechner ans Netz zu stöpseln, das BIOS korrekt einzustellen und dann ein paar Sekunden auf das Bootmenü zu warten. Der neue Rechner lud auch brav Kernel und Initrd, fand aber danach keinen Link mehr. Gnarrrr…

eth0: RTL8168c/8111c at 0xee112000, 00:21:de:ad:be:ef, XID 3c4000c0 IRQ 18

Das Problem ist besonders bei Realtek-Karten bekannt und tritt immer wieder einmal auf: Anscheinend bleiben Reste des PXE-Codes im Speicher der Karte, worauf diese vom Kernel nicht richtig initialisiert werden kann. Ähnliche Probleme treten manchmal beim Hin- und Herbooten zwischen verschiedenen Betriebssystemen auf. Meist hilft ein BIOS-Update in Kombination mit den aktuellsten Treibern (sprich: einem frischen Kernel oder Herstellertreiber). Das war mir dann zu aufwendig, ich deaktivierte den PXE-Boot und entschied mich für die Installation per USB-DVD-ROM.

Juchhu, er bootet

Die Installation der nackten openSUSE und die Nachinstallation von Xen sowie das erste Update mittels zypper lief problemlos durch — ich hätte ehrlich gesagt bei einem Minimalsystem nichts anderes erwartet. Xen wurde sauber in der Grub-Konfiguration eingetragen und ich selbst fügte dem Linux-Kernel noch die Einträge zum Durchschleifen von USB- und DVB-Karte hinzu:

pciback.permissive pciback.hide=(0000:06:00.0)(0000:06:00.1)(0000:06:00.2)(0000:06:01.0)

Zu früh gefreut

Dummerweise lies sich die DomU mit dem Videorecorder nicht starten. Das ist die einzige Domain, die im Dauereinsatz auf durchgeschleifte PCI-Karten zugreift. Der Aufruf von dmesg schuf Klarheit: Die beiden pciback.-Bootparameter waren unbekannt. Ein Blick in openSUSEs Kernelkonfiguration zeigte die Ursache: Der PCI-Backend-Treiber war als Modul kompiliert, was zur Folge hat, dass erst der Kernel lädt und PCI-Karten initialisiert und dann der Backend-Treiber diese nicht mehr maskieren kann. Ich installierte also die Kernelquellen, passte die Optionen für den Backend-Treiber an (“Backend driver support” und “PCI-device backend driver” fest einkompiliert statt Modul und “PCI Backend Mode (Passthrough)”), versah den Kernel mit einem eigenen Prefix und kompilierte ihn neu.

Nach mkinitrd, Anpassung der Grub-Konfiguration und Reboot war auch diese Hürde gemeistert. Es war Mitternacht, ein guter Zwischenstand, Zeit ins Bett zu gehen.

Das lässt mich kalt (der nächste Morgen)

Und wieder einmal sprang eine Festplatte nach dem Auskühlen nicht an. Wahrscheinlich ist das Öl in einem Lager etwas verharzt. Da die betreffende Festplatte Teil eines RAID5-Verbundes ist, verzichtete ich auf den Trick mit dem Fön und kaufte einfach eine neue. Sollte jemand auf dasselbe Problem stoßen: Zunächst startet man das Array ohne die defekte Festplatte (mit --run oder --force)…

root@kiste# mdadm --assemble --run /dev/md0 /dev/sdd1 /dev/sde1 /dev/sdf1
mdadm: /dev/md0 has been started with 3 drives (out of 4).

Dann partitioniert man die neue Platte und fügt die neue Partition dem Array hinzu:

root@kiste# mdadm --add /dev/md0 /dev/sdc1
mdadm: added /dev/sdc1

Ein Blick ins /proc zeigt dann den Synchronisiationsfortschritt:

root@kiste# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdc1[4] sdd1[1] sdf1[3] sde1[2]
      1465151808 blocks level 5, 64k chunk, algorithm 2 [4/3] [_UUU]
      [>....................]  recovery =  0.2% (1398528/488383936) finish=251.2min speed=32304K/sec

unused devices: 

Das RAID-Array kann jetzt bereits verwendet werden, allerdings ist die Performance unterirdisch. Zumindest auf das Kopieren oder Synchronisieren großer Datenmengen sollte man also noch verzichten.

Lästige Kleinigkeiten

Soweit, so gut. Einige Kleinigkeiten bleiben. So verwendet meine Videorecorder-DomU noch einem älteren openSUSE-Xen-Kernel, dessen USB-Massenspeicher-Treiber reproduzierbar abstürzt, wenn eine Festplatte oder ein DVD-ROM angeschlossen ist. Stöpsele ich nach dem Boot an, funktioniert alles einwandfrei. Hier werde ich wohl um einen frischen Kernel nicht herumkommen. Bis dahin lebe ich mit dem etwas aufwendigeren Reboot.

Warum tut man sich soetwas überhaupt an? Ich nutze Xen, weil es sich um die flexibelste Virtualisierungslösung handelt, insbesondere wenn PCI-Karten an unpriviligierte Domains durchgereicht werden sollen. Dazu kommt der geringe Overhead durch Xen selbst. Allerdings haben sich seitens Citrix in letzter Zeit einige Schludrigkeiten eingeschlichen. So ist der originale Linux-Kernel mit Xen-Patches noch auf Stand von 2.6.18, die Xen-Unterstützung im Linux-Kernel reicht gerade für den Betrieb einfacher DomUs und gerade kleinere Distributionen tun sich schwer mit der zeitnahen Integration von Xen-Patches in aktuelle Kernel. Auch Novells Nachlässigkeit bei der Konfiguration des PCI-Backends zeigt, dass man dort Xen wohl nicht mehr ganz so hoch priorisiert wie noch vor gut einem Jahr. Klar, dass Citrix zusammen mit den großen Distributoren die kommerziellen Xen-Varianten verkaufen möchte, aber nur eine breite Nutzerbasis in der Community kann auch dafür sorgen, dass ein Produkt ausgereift und gut getestet am Markt bestehen kann. Eine Mindestvoraussetzung dafür sollte sein, dass aktuelle Kernel bereitstehen und sich als stabil deklarierte Releases auf aktuellen Distributionen kompilieren lassen.

Ein großes Problem bei vielen Virtualisierungstechnologien ist die fehlende Möglichkeit, in einem Gastsystem “rohen” Zugriff auf einzelne Hardwarekomponenten zu erhalten. Zwar bieten VMware und andere das Durchreichen von USB-Geräten, doch das ist eine Lösung, die für physikalisch vom Netz des Wirts getrennte Firewalls oder RAID-Subsysteme nicht wirklich akzeptabel ist. Eine interessante Abhilfe bietet Xen, wo mit vertretbarem Aufwand Gäste direkten Zugriff auf PCI-Karten bekommen.

Anpassungen am Dom0-Kernel

Der Dom0-Kernel sollte in der Regel richtig konfiguriert sein. Hier muss unter “Xen” der “PCI-device backend driver” aktiviert sein und dessen Modus auf “Passthrough” stehen.

Anpassungen am DomU-Kernel

In vielen Fällen werden Sie einen eigenen DomU-Kernel benötigen. Die von mir und einigen anderen angebotenen DomU-Kernel integrieren nur die Frontend-Treiber für Xen-Block-Devices und Xen-Network-Devices, Sie benötigen jedoch einen Kernel, der einerseits den PCI-Frontend-Treiber mitbringt und andererseits Treiber für die zu unterstützenden Geräte. Als Ausgangsbasis können Sie einen normalen XenU-Kernel verwenden und die gewünschten Treiber zusätzlich auswählen:

Stillegen der PCI-Devices in der Dom0

Damit einzelne PCI-Geräte durchgereicht werden können, müssen diese per Bootparameter stillgelegt werden. Identifizieren Sie zunächst mit lspci -v die betreffenden Karten und ergänzen Sie dann die Appendzeile der Dom0:

title Xen 3.2.0rc4 - Linux 2.6.18.8
root (hd0,0)
kernel /boot/xen-3.2.0-rc4-pre.gz
module /boot/vmlinuz-2.6.18.8-xen0 root=/dev/hda1 ro pciback.permissive pciback.hide=(00:0c.0)(00:0c.1)(00:0c.2)(00:0d.0)(00:09.0)
boot

Nun ist ein Reboot des gesamten Systems erforderlich. Anschließend können Sie in der DomU mit lspci die durchgereichten Karten ermitteln, Treiber laden und so die Hardware direkt verwenden:

00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
00:0c.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 61)
00:0c.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 61)
00:0c.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63)
00:0d.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)

Anmerkungen:

Der hier zu sehende Gast war ein temporär aufgesetztes Testsystem mit einer Hauppauge DVB-C-Karte, der die Möglichkeit haben sollte, Videoaufnahmen zu machen, ohne dass Änderungen an der Dom0 erforderlich sind, und der via direktem USB-Zugriff diese Videos flott auf USB-Festplatten kopieren sollte. Hierfür kam ein als PCI-Steckkarte ausgeführter USB-Controller zum Einsatz. Ob es möglich ist, einzelne Roothubs dieses Controllers (immerhin werden diese als separate Geräte angezeigt) durchzureichen, habe ich nicht ausprobiert.

Nach meinem bisherigen Kenntnisstand funktioniert das PCI passthrough nicht bei Domains im Full Virtualization Mode. DomUs haben Kenntnis über die Speicheraufteilung und können demnach Adressen richtig zuordnen. Full Virtualization Mode Clients sehen dagegen Speicher ab 0 Byte.

Ich habe noch keine Performancetests von SATA-Controllern, die via Xen-Block freigegeben wurden, gegenüber dem Durchreichen dieser Controller durchgeführt. Allerdings sollte die Performance spürbar besser ausfallen, da der Weg über den Blockdevice-Treiber der Dom0 wegfällt.

Theoretisch sollte es möglich sein, auch von einer durchgereichten SATA-Karte zu booten. Damit verliert man aber einen der größten Vorteile von Xen, die weitgehende Abstraktion von der darunterliegenden Hardware. In Einzelfällen, in denen Performance vor Abstraktion geht, dürfte es ein guter Kompromiss sein, das Grundsystem von einem kleinen Image zu starten und dann die Datenverzeichnisse, auf denen Performance benötigt wird, via passthrough anzusprechen.

Der Screenshot des domU-Kernels entstand mit dem openSUSE-10.3-Kernel auf einer Ubuntu-7.10-domU. Eine etwas exotische Konfiguration, aber openSUSE liefert recht aktuelle Distributionskernel mit sauber integrierten Xen-Patches. In diesem Fall war ein Kernel >2.6.19 erforderlich, um die DVB-Treiber aus dem Mercurial-Repository integrieren zu können.

Bleibt zu hoffen, dass xVM nicht mit den langsam etablierten Xen-Schnittstellen bricht. Ich möchte in der Lage sein, auf einem normalen Xen eine openSOLARIS-Instanz auszuführen und umgekehrt unter xVM Linux-Instanzen mit xenifiziertem Distributionskernel. Dass ich viel Xen nutze, dürfte sich mittlerweile herumgesprochen haben. Ich durfte in der letzten Zeit so auch die Nachteile von Xen kennenlernen. Insbesondere Wünsche ich mir eine einfache Möglichkeit, leichtgewichtige Virtualisierung (aka Chroot-Erweiterungen) auf schwergewichtiger Virtualisierung (aka Xen) nutzen zu können — und so letztlich mehr aus der Hardware rauszuquetschen als mit Xen und dennoch deutlich flexibler zu sein als nur mit leichtgewichtiger Virtualisierung.

Scheint, dieser Traum könnte mit openSOLARIS-Zones auf Xen Wirklichkeit werden.

Noch habe ich 2.6.23 nicht getestet. Spannend bleibt insbesondere die Frage nach Aktualität und Xen-Kompatibilität: Zumindest in der Vergangenheit sind die Distributionskernel nicht immer durch 100%ige Kompatibilität zum Vanilla-Xen-Hypervisor aufgefallen. Bleibt zu hoffen, dass der Vanilla-Linux-Kernel zeitnah zum Original-Xen aktualisiert wird.

Siehe auch:

• News auf Golem.de
• Changes auf Kernelnewbies.org
• Changes und Download auf Kernel.org

Und etwas Eigenwerbung:

• Xen-Einführung bei PC-Magazin.de