Test verschiedener Virtualisierungslösungen in Debian Testing/Unstable

Entstanden bei der Vorbereitung des gleichnamigen Vortrages für die [http://www.fosdem.org FOSDEM Konferenz] - an einigen Stellen noch etwas rauh - siehe TODO Markierungen...

Stand: 23.2. 2008

TableOfContents

Einleitung

Im Rahmen der Vorbereitungen für den Vortrag "Update on Virtualization in Debian" auf der [http://www.fosdem.org FOSDEM 2008] haben wir die verschiedenen Pakete von Virtualisierungslösungen in Debian getestet.

An einigen Stellen ist hier das Backporten von ganz aktuellen Debian Paketen von Unstable auf Testing/Stable beschrieben. Dies erfordert immer, dass in der Datei /etc/apt/sources.list auch ein Eintrag für die Unstable Quellpakete existiert. Dieses hat keinen Einfluss auf die auf einem stabilen System installierten Binaries, so lange man nicht einen Backport erzeugt und manuell installiert.

Folgende Zeile ist dazu notwendig: 

deb-src http://ftp.de.debian.org/debian unstable main non-free contrib

Es ist möglich, dass für die verschiedenen Entwicklungsversionen von Debian die unterschiedlichen Begriffe genutzt werden.

Debian ist hauptsächlich in drei Zweige unterteilt, und diese haben jeweils Codenamen: Stable(Etch), Testing(Lenny) und Unstable(Sid) - es gibt auch noch oldstable und experimental, aber diese lassen wir der Einfachheit halber zunächst weg. Die Codenamen von Stable und Testing ändern sich jeweils, wenn es einen neuen Release gibt, Unstable bleibt immer Sid.

Bei dem upgrade der stabilen Version auf die neustes kam ein kleiner Bug in den Weg, der aber mit den [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466027 Informationen im Bugreport] leicht zu beheben war:

Virtualbox

Für den Newcomer am Markt für Desktop-Virtualisierungslösungen, die unter einer freien Lizenz verfügbar sind, gibt es schon seit einer ganzen Weile Pakete in Debian Testing.

Das Paket virtualbox-ose lässt sich auch leicht installieren, und läuft sofort auf Anhieb, sobald man auch die Kernel-Module für den laufenden Kernel erzeugt und installiert hat. Dies erfolgt ganz leicht mit dem Befehl 

m-a a-i virtualbox-ose-source

Zum Zeitpunkt unseres Tests gab es wegen der kurz zuvor erfolgten Umbenennung des Kernel-Modules eine kleine Ungereimtheit, da bei Fehlen der Kernelmodule die Fehlermeldung und auch das README des Programmes auf ein Modul namens vboxdrv verwies. Dieser Bug wurde aber binnen eines Tages nach dem er gemeldet wurde auch gefixt.

Einzige kleine Hürde ist dann noch das Einrichten des bridged Networking - die einfachste Variante des Netzwerkes für eine Gast-VM, bei der der Gast einfach in das gleiche Ethernet Segment, in dem auch die Interfaces des Hostes liegen, angehängt wird. Es erfordert allerdings ein bisschen manuelle Arbeit.

Man benötigt ein besonderes Setup für das Netzwerk - meine /etc/network/interfaces sieht dabei so aus: 

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth1
iface eth1 inet dhcp

auto tap0
iface tap0 inet manual
    up ifconfig $IFACE 0.0.0.0 up
    down ifconfig $IFACE down
    tunctl_user administrator

auto br0
    iface br0 inet dhcp
    bridge_ports all tap0

Genauer steht es [http://mydebian.blogdns.org/?p=83 hier] FIXME: genau beschreiben, was da getan werden muss?!

Außerdem sind auch die virtualbox-ose-guest* - Pakete verfügbar. Uns ist zwar deren Installation problemlos geglückt, aber der Versuch, daraus einen Nutzen zu ziehen, schlug fehl.

Die Installation erfolgt folgendermaßen: 

apt-get install virtualbox-ose-guest-source
m-a a-i virtualbox-ose-guest-source
apt-get install virtualbox-ose-guest-utils

In unseren Tests haben wir aber keinen weiteren Nutzen daraus ziehen können. Der einzige Effekt, den wir nach der Installation beobachtet haben ist, dass die VM den Host dazu gebracht hat, 100% CPU-Last zu verbrauchen.

Fazit

Virtualbox ist eine durchaus ansprechende Virtualisierungslösung für den Desktop, die mit einer guten Performance glänzt und leicht zu bedienen ist. Es hat noch ein paar kleine Macken, die man aber leicht beseitigen oder umschiffen kann. Schade ist, dass die Nutzung vorhandener Partitionen und LVM Volumes einem recht schwer gemacht wird - der Verweis auf die Binärversion mit PUEL Lizenz von den Entwicklern mit der Frage "brauchst Du denn GPL Software" lässt ein bisschen vermuten, dass sie, obwohl sie ihre Software unter der GPL veröffentlichen, das ganze noch nicht recht verstanden haben.

Im Auswärtigen Amt wird es eingesetzt, um die Migration der Desktop-Systeme von Windows zu Linux zu unterstützen, und tut dort einen guten Job.

TODO: Talk/Folien von Torsten Werner auf CLT verlinken

Grafische Oberfächen für Qemu

Es gibt inzwischen eine Auswahl mehrerer Frontends für Qemu in Debian. Sie haben alle einen unterschiedlichen Funktionsumfang, und, weniger gut, haben auch alle ein eigenes Format, um die Konfigurationen einzelner VM's abzuspeichern.

Qtemu

Neu in Debian ist das QT-basierte Programm QTemu. Esa ist übersichtliuch und erschließt sich auf den ersten Blick, wie man eine virtuelle Instanz einrichtet und startet.

Schade ist, dass mit dem GUI viele Optionen und Einstellungsmöglichkeiten von Qemu gar nicht zugreifbar sind - und es ist noch nicht einmal möglich, Live-CD's zu testen ohne eine Festplattendatei einzurichten.

Qemu-launcher

Das Programmpaket qemu-launcher liefert eine grafische Oberfläche, die auf den ersten Blick mit einer Masse an Optionen den Benutzer verwirrt. Hat sich der Blick vom Erkunden der vielen Optionen erholt, stellt man aber bald fest: Hier bekommt der langjährige Qemu-Fan eine Oberfläche, die ihn ausnahmslos alle für Qemu verfügbaren Laufzeitoptionen, die er aus der Kommandozeilen-Nutzung kennt, verändern und in Konfigurationen abspeichern lässt.

Mit dem (auch unabhängig von qemu-launcher nutzbaren) Zusatzwerkzeug qemu-control hat man zur Laufzeit einer VM die gleiche Funktionalität auch für den Qemu-Monitor. Dies ist nicht die grafische Ausgabe, sondern die Steuerungseinheit, mit der man im laufenden Betrieb verschiedene Eigenschaften einer VM beeinflussen kann, und außerdem den Status abspeichern und Screenshots erzeugen kann.

Auch Kqemu, das Beschleunigungsmodul für Qemu lässt sich mit dem qemu-launcher aktivieren, und wenn man in dem Reiter Launcher Settings im Feld Path to Qemu den Wert /usr/bin/kvm setzt, kann man auch kvm starten.

Wenn man allerdings im Reiter Emulator das Feld Provide a control panel aktiviert hat, wird nicht dieser Pfad genutzt, sondern das, was im Feld Path to qemu-ctl steht. Qemu-control unterstützt KVM nicht out of the box. Allerdings ist es nur ein kleines Perl-Programm, so dass man es einfach anpassen kann. Wir habe einfach die Datei /usr/bin/qemuctl nach ~/bin/kvm-ctl kopiert, die Zeile 52 die so aussah: 

$command = "qemu '".join( "' '", @ARGV)."' -monitor stdio";

so abgeändert: 

$command = "kvm '".join( "' '", @ARGV)."' -monitor stdio";

Alternativ könnte man auch einfach ein link zu kvm mit dem Namen qemu in den Suchpfad legen, da das qemu Kommando, wie man sieht, keinen vollen Pfad enthält - man kann sich aussuchen, was man schöner findet - die optimale Lösung wäre es, dem qemuctl eine option hinzuzufügen, mit der man das auszuführende Binary explizit angeben kann - zum Beispiel --binary

Qemulator

Ebenfalls neu in Debian ist das Paket qemulator. Mit diesem lassen sich fast genau so viele Eigenschaften von Qemu beeinflussen und als Voreinstellungen zu mehreren Setups abspeichern wie mit dem Qmemu-Launcher. Leider eben nur fast so viele, und damit nicht alle, die verfügbar sind, und die man teilweise braucht.

Der Qemulator stürzte bei unserem ersten Test prompt ab, lief in weiteren Versuchen dann aber stabil. Trotzdem bleibt die Frage, ob man ihn wirklich braucht, da der qemu-launcher insgesamt vollständiger und ausgereifter daherkommt und auch noch mit qemu-control kombiniert werden kann.

Fazit

Mit Lenny wird man also zwischen mehreren Frontends wählen können - und müssen. Dabei ist recht klar: für Anfänger eignet sich QTemu etwas besser - für Profis ist qemu-launcher das Werkzeug der Wahl, das keine Wünsche offen lässt.

Schade ist, dass "selbstverständlich" jede dieser Oberflächen zum Abspeichern der Konfigurationen von VM's ein eigenes Format nutzt, so dass man nicht ohne weiteres von einem zum anderen System umsteigen kann - man muss sich dessen bewusst sein, bevor man mit einem nicht ausreichend getesteten Werkzeug eine Vielzahl von Konfigurationen anlegt. Da die Konfigurationen allerdings allesamt in Plain Text, bei Qtemu in XML vorliegen, kann man sich natürlich, mit Hilfe der jeweiligen Entwickler, die die teilweise unter kryptischen Namen abgespeicherten Optionen erklären müssen, ein Konvertierungswerkzeug schreiben, wenn es doch einmal zum Wechsel kommen soll.

inline:qemu-gui-collage.png

TODO: besser beschneiden das bild!

Kqemu

Auch schon seit Etch verfügbar ist das Beschleunigungsmodul für Qemu, mit dem namen KQemu. Trotzdem haben wir es noch einmal getestet. Mit Nutzung dieses Moduls erhöht sich die Performance von Qemu spürbar - allerdings ist Qemu damit dann kein vollständiger Emulator mehr - er nutzt Features der vorhandenen CPU direkt, und kann daher, wenn die Funktion eingeschaltet ist, nicht mehr komplett andere Prozessorarchitkturen zur Verfügung stellen.

Installiert wird er mit den Befehlen: 

apt-get install kqemu kqemu-source
m-a a-i kqemu-source

Dann bearbeitet man noch die Datei /etc/udev/rules.d/020_permissions.rules.

TODO: was musste da eingetragen werden? 

modprobe kqemu
groupadd kqemu-users

Nun kann Qemu mit Kqemu-Beschleunigung gestartet werden.

In unserem Test in mit den Unstable Paketen lief dies noch nicht so richtig rund - wir haben in der Vergangenheit aber schon einige gute Erfahrungen mit Kqemu-Beschleunigung, so ist anzunehmen, dass es sich um ein temporäres Problem handelt, dessen Grund in der Kombination der Pakete in dieser instabilen Version zurückzuführen ist.

libvirt

[http://www.libvirt.org Libvirt] ist eine, von Redhat entwickelte, generische Bibliothel zur Steuerung verschiedener Virtualisierungs-Umgebungen. Sie enthält Unterstützung für Xen, Qemu (mit und ohne Kqemu), und KVM.

Sie stellt eine API bereit, mit deren Hilfe Entwickler in verschiedenen Sprachen Programme zur Steuerung von virtuellen Systemen entwickeln können, und einige Kommandozeilen-Werkzeuge. Das prominenteste Werkzeug, das die libvirt nutzt, ist der im nachfolgenden Abschnitt besprochene virt-manager, der ebenfalls von Redhat entwickelt wird.

Die zu libvirt gehörenden Pakete in Debian installiert man mit dem folgenden Befehl: 

apt-get install libvirt-bin libvirt-doc python-libvirt libvirt-dev libvirt0

Zum Zeitpunkt unseres Tests fehlten in Debian Testing allerdings noch die Xen Funktionen, da der Maintainer der Pakete libvirt hauptsächlich zusammen mit KVM nutzt. Also haben wir die aktuellsten Quellen der Debian Pakete aus dem Subversion Repository neu gebaut. Voraussetzung hierfür sind allerdings die aktuellsten Xen Pakete, in einer Version von mindestens 3.2-3, sowie das dezentrale Versionskontroll-System git.

Im Zweifel muss man auch die Xen Pakete einmal neu bauen aus den Quellen von Unstable: 

apt-get install git-arch
apt-get source xen-3
cd xen-3
dpkg-buildpackage -r fakeroot
dpkg -i ../*.deb

Die Libvirt Pakete erstellt man mit diesen Befehlen: 

git-clone git://git.debian.org/git/pkg-libvirt/libvirt.git
apt-get build-dep libvirt
dpkg-buildpackage -r fakeroot
dpkg -i ../*.deb

TODO: Workaround für Xen nennen!

virt-manager

Der auf der Libvirt basierende Virt-Manager ist ein grafisches Werkzeug zum Steuern von virtuellen Systemen. Da es die libvirt nutzt, kann man es potentiell auch für alle von dieser unterstützten Systeme nutzen.

Virt-Manager und libvirt sind die Standard-Werkzeuge zum Installieren und Steuern virtueller Instanzen unter Fedora- und SuSE-Linux basierten Systemen.

Die Virtmanager Pakete in Debian haben es zum Zeipunkt unseres Tests noch nicht bis nach Testing geschafft, aber die Pakete aus Unstable lassen sich problemos backporten und in Lenny nutzen. 

apt-get source virt-manager
apt-get build-dep virt-manager

Danach konnten wir virt-manager problemlos zum installieren und steuern von Qemu-Instanzen nutzen(leider muss man auch hier, ähnlich wie qtemu, der in einem anderen Abschnitt beschrieben ist eine Fetsplattendatei zwingend angeben, auch wenn man nur eine Live-CD testen möchte)- für Xen Instanzen waren wir allerdings nicht sehr erfolgreich, obwohl wir, wie im vorigen Abschnitt beschrieben, extra eine libvirt mit Xen Unterstützung kompiliert hatten.

TODO: noch einmal neu testen!

kvm

KVM ist eine aktuelle Virtualisierungs-Technologie, die sehr schnell Einzug in den Mainline Linux Kernel genommen hat. KVM ist abhängig von den Funktionen zur Hardware-Unterstützung von Virtualisierung, die in aktuellen Prozessoren von AMD und Intel enthalten ist.

Da neben der Implementierung auf einer niedrigen Ebene im Linux-Kernel auch eine Kontroll-Schnittstelle notwendig ist, und außerdem die Hardware-gestützten Virtualisierung noch keine virtuellen Festplatten und Netzwerk-Interfaces bereitstellt, nutzt KVM Code von Qemu für diese Zwecke.

KVM läuft auch in Lenny "einfach so", nachdem die Pakete installiert und für den laufenden Kernel passende Module erstellt wurden: 

apt-get install kvm
m-a a-i kvm-source

Als GUI lässt sich hier der Virt-Manager nutzen, und potentiell, aber von uns nicht getestet, auch jedes Qemu Frontend.

Xen

Der Zustand und die Nutzung von aktuellsten Xen Paketen in Debian Lenny/Unstable ist etwas kompliziert - und daher sind die folgenden Kapitel recht umfangreich ausgefallen.

neueste Xen 3.2 Pakete installieren und nutzen

In Debian Lenny sind auch schon Xen Pakete der Version 3.2 vorhanden.

Man installiert sie mit 

apt-get install libxen-dev libxenstore3.0 xen-docs-3.2 xen-hypervisor-3.2-1-i386-nonpae xen-hypervisor-3.2-1-i386 xen-utils-3.2-1 xenstore-utils

Ein noch bestehendes Problem ist, dass XenSource seit einer Weile keine Patches für aktuelle Kernel-Versionen mehr liefert. Man konzentriert sich angeblich lieber darauf, die nötigen Funktionen in den Mainline Kernel zu bekommen. Nur dass dies leider schon seit langer Zeit geplant und in Arbeit ist, und bisher kann ein aktueller Mainline Kernel nur für Xen Gäste, aber nicht für eine Xen dom0 genutzt werden.

Das Debian Projekt hat aus verständlichen Gründen(jede Kernelversion bedeutet einiges an Aufwand, sie zu unterstützen, zu testen, und Sicherheits-Updates zur Verfügung zu stellen) beschlossen, immer nur genau eine Kernel-Version auszuliefern.

Die alten Kernel-Pakete in Debian mit Xen Support sollen nicht mehr gut mit Xen 3.2 funktionieren. Ein Workaround um dieses Problem ist, sich aus den XenSource Quellen einen Kernel von der alten Version zu bauen, oder aus dem XenSource Binärpaket zu kopieren. 

mkdir xen-source-build
cd xen-source-build
wget http://bits.xensource.com/oss-xen/release/3.2.0/xen-3.2.0.tar.gz
tar xvfz xen-3.2.0.tar.gz
apt-get install python-dev bcc binutils-static transfig swig gcc zlib1g-dev
apt-get install binutils transfig ncurses-dev tetex-base tetex-extra gs-common
apt-get install bin86 ghostscript libvncserver-dev libsdl1.2-dev 
apt-get install libncurses5-dev graphviz libc6-dev python-all-dev libx11-dev
apt-get install bridge-utils gawk gettext pciutils-dev tetex-bin tetex-brev
apt-get install tetex-doc tetex-frogg tetex-frogg-doc
hg clone http://xenbits.xensource.com/linux-2.6.18-xen.hg
cd xen-3.2.0/ 
make world
sudo cp -a  dist/install/lib/modules/2.6.18.8-xen /lib/modules/
sudo mkinitramfs -o /boot/initrd-2.6-xen.img 2.6.18.8-xen
}} 

Dann benötigt man einen Grub Eintrag zum Booten dieses Kernels mit Xen 3.2 in
der Datei /boot/grub/menu.lst:

{{{
title Xen 3.2 / XenLinux 2.6
   kernel /xen-3.2-1-i386.gz console=vga 
   module /vmlinuz-2.6.18.8-xen root=/dev/mapper/xnote-root ro console=tty0 
   module /initrd-2.6-xen.img

Mit dieser Kombination von Debian-Paketen für den Hypervisor und dom0 Kernel von XenSource kann man einen Xen Server booten und nutzen.

Xen Gast-Kernel aus Mainline-Quellen

kernel      = '/boot/vmlinuz-2.6.24-1-xen-686' 
ramdisk      = '/boot/initrd.img-2.6.24-1-xen-686' root        = '/dev/xvda2 ro' 
disk        = [  'phy:/dev/xnote/xen3.2-test-swap,xvda1,w', 'phy:/dev/xnote/xen3.2-test-disk,xvda2,w' ]

Vanilla Kernel in Xen dom0 nutzen

Anhand diesem Hinweis und den daran verlinkten Informationen: http://lists.alioth.debian.org/pipermail/pkg-xen-devel/2008-February/001693.html 

apt-get install git-arch
git-clone git://git.et.redhat.com/linux-2.6-dom0-pvops.git
make menuconfig 
make
sudo make deb-pkg
sudo dpkg -i ../linux-2.6.24_2.6.24_i386.deb
mkinitramfs -o /boot/initrd.img-2.6.24  2.6.24

Zunächst einmal in DomU testen:

In Dom0

In dom0 haben wir noch ein ungelöstes Problem, hier hilft nur, noch einmal zu einem späteren Zeitpunkt zu probieren...

Neuigkeiten Xen-tools

XenMan

Nix neues, immer noch keine Debian Gast installation, und selbst eine HVM Domain mit live cd habe ich nicht hinbekommen.

Wiki: VirtualizationInDebianTesting (last edited 2008-04-15 17:34:34 by Andreas Schockenhoff)