Virtualisierung mit KVM

Ich habe auf meinem Server KVM ausprobiert. Da
Virtualisierungstechnologien immer kontrovers diskutiert werden, möchte
ich hier mal meine Erfahrungen aufschreiben.

KVM unterstützt die Hardwarevirtualisierung von Prozessoren sowie das
neuere IOMMU, welches direkten Zugriff auf IO Geräte zulässt.

KVM benutzt qemu als Unterbau. Somit sind die qemu und kvm Befehle bis
auf den Präfix identisch.

KVM in der Praxis

Als erstes muss eine virtuelle Festplatte angelegt werden:kvm-img create -f qcow2 hd1.img 100G

• -f qcow2: gibt das Format der Festplatte an


• hd1.img: ist der Dateiname


• 100G: Ist die Größe

Man kann auch normale Blockdevices benutzen, aber wegen der einfacheren
Handhabung entschied ich mich für Dateien, auch wenn dann zwei Dateisysteme
arbeiten müssen. Außerdem wächst das Volume dynamisch, wodurch am Anfang
nur wenige 100 Kilobyte verbraucht werden.

Um die Maschine zu starten und ein voll funktionsfähiges Netzwerk zu
haben, muss eine funktionsfähige Bridge erstellt werden. Hier bin
ich nach dem Tutorial im Hetzner Wiki vorgegangen, welches ich im
Vergleich zu anderen sehr verständlich und simpel fand: http://wiki.hetzner.de/index.php/KVM

Die Maschine startete ich dann folgendermaßen:
kvm -hda IMAGE.img -cdrom BOOTDISC -boot c -m RAMSIZE -vnc
IP:DISPLAY - -monitor stdio -net nic -net
tap,ifname=VIRTNET,script=no,macaddr=MACADDR -k de -smp ANZ -name
NAME

• -hda IMAGE.img: gibt das Festplattenimage an


• -cdrom BOOTDISC: die VM soll ein CD Laufwerk mit der CD BOOTDISC haben


• -boot c: Die VM soll von Festplatte starten. Angeblich wurden hier aus historischen Gründen die Windows Laufwerksbezeichnungen genommen. C für Festplatte, D für CD Laufwerk usw.


• -m RAMSIZE: Größe des Arbeitsspeichers in Megabyte


• -vnc IP:DISPLAY: vnc Server soll auf IP lauschen mit Displaynummer DISPLAY


• -monitor stdio: der QEMU Monitor soll auf stdio laufen


• -net nic: Erstellt eine Netzwerkkarte


• -net tap,ifname=VIRTNET,script=no,macaddr=MACADDR: Verbindet die Netzwerkkarte mit einem tap Hostinterface namens VIRTNET. Skripte sollen keine beim Booten ausgeführt werden und die Macadresse MACADDR soll verwendet werden


• -k de: Keyboard Layout de soll verwendet werden


• -smp ANZ: ANZ Threads soll die VM benutzen dürfen. Dies ist quasi die Anzahl der Prozessoren die kvm benutzen darf.


• -name NAME: NAME ist ein Bezeichner für die VM die besonders für libvirt benötigt wird. Dazu später mehr.

Per vncviewer lässt sich jetzt auf die Bildschirmausgabe verbinden. Das
ist äußerst unsicher, da sich jeder auf den VNC-Server verbinden kann.
Ich habe das nur zur Installation gemacht und die KVM später mit -
-nographic gestartet womit keine Ausgabe mehr auf irgend einem Xserver
oder ähnlichem mehr erfolgt. Es ist aber auch möglich sich per Klartext
Passwort zu authentifizieren oder sogar per SSL. Da ich die grafische
Ausgabe aber im Normalbetrieb nicht brauche habe ich darauf verzichtet.
Ursprünglich wollte ich Reversevnc benutzen womit sich der VNC Server
auf dem Reverse VNC Client verbindet. Somit könnte man nur durch
Man-in-the-Middle Angriffe o.ä. auf die Bildschirmausgabe zugreifen.
Leider wechselt beim Boot einmal der Videomodus und mein VNC Client
macht das nicht mit. Somit ist nach dem einmaligen Verbinden nach
wenigen Sekunden Schluss mit der Bildschirmausgabe.

Das System kann man dann ohne Besonderheiten zu beachten normal
installieren. Nur die Virtio Module habe ich im Gast geladen obwohl dies
durch IOMMU nicht nötig ist. Auf Systemen die kein IOMMU haben erhöht
dies aber die IO Performance drastisch durch Paravirtualisierung.

Ich habe mir auch den libvirtd angeschaut in Verbindung mit dem
Clientprogramm virt-manager. Die libvirt stellt eine einfache Verwaltung
für verschiedenste Virtualisierungstechnologien bereit. Xen und KVM, zum
Beispiel, werden unterstützt. Neben vielen Konsolentools die die
Verwaltung mehrerer Virtueller Maschinen erlauben gibt es noch den
grafischen virt-manager der einen Überblick über die verschiedenen VMs
gibt. Das Programm hat mir von Aufbau sehr gut gefallen und es lässt
sich remote über SSH benutzen. Ein integrierter VNC Viewer löst dann
auch die VNC Problematik ohne weitere Konfiguration. Leider war das
erstellen von Virtuellen Maschinen sehr mühsam und wenig
konfigurations-freundlich. Ich habe der VM meine Bridge einfach nicht
nahe legen können und das Programm hat z.B. auch die Checkbox ignoriert
die verhindern sollte gleich den ganzen Festplattenplatz zu allozieren.

Außerdem hatte das Programm große Probleme wenn man Vorgänge abbrechen
wollte. Es resultierte im Hängen des Clients. Der libvirtd vergaß dann
auch Informationen und merkte nicht, dass er bereits Laufwerke gelöscht
hat. Eigentlich sehr schade da das Programm sonst einen sehr guten
Eindruck machte.

Probleme mit KVM

Ich habe das Problem mit den VMs, dass sie bei intensivem
Netzwerkverkehr freezen. Ich verwenden den Debian Standardkernel auf dem
Host sowie in der VM (2.6.26.x). Das Problem ist bekannt und sollte
durch wesentlich neuere Kernel behebbar sein. Ich kam leider noch nicht
dazu es mit einem aktuellen Kernel auszuprobieren und baute erstmal
einen Workaround indem ich mit Traffic-Shaping die zur Verfügung
stehende Bandbreite auf dem tap Hostinterface senkte. Nach nur kurzem
Testen merkte ich, dass es mit 12 Mbit erstmal auch bei mehrstündigen
Übertragungen stabil läuft. Ob ich eine höhere Bandbreite benutzen kann
weis ich nicht, da ich wegen der Abschaltung unseres alten Servers etwas
unter Zeitdruck stehe und deswegen nicht allzu viel Zeit zum testen
hatte. Bei Gelegenheit werde ich aber auf jeden Fall neuere Kernel
verwenden.

Alternativen

Das Problem mit KVM trieb mich dazu zu überlegen ob ich OpenVZ
ausprobieren soll. OpenVZ ist keine richtige Virtualisierung sondern
stellt den Hostkernel für Virtual Environments bereit. Damit soll sich
ein sehr geringer Ressourcenverlust von gerade mal 1-3% bei IO Zugriffen
ergeben. OpenVZ bietet sehr feine Ressourcenverteilung. Man kann genau
angeben wie viel CPU Zeit eine VE bekommen soll. Dazu gibt es noch eine
Reihe anderer Performancewerte. Nachteil von OpenVZ ist, dass nur Linux
als Gast und Host unterstützt wird und man natürlich weniger Flexibel
ist. Außerdem müssen alle Gäste den gleichen Kernel haben. OpenVZ soll
aber sehr sicher sein was die Zugriffskontrolle aus den Gästen anbelangt
obwohl keine richtige Virtualisierung stattfindet. Dinge wie SELinux
sind dann aber, glaube ich, nicht mehr möglich.

Falls jemand Fragen oder Tipps hat: Immer her damit!

Autor: Gero Kriependorf