KVM im Test

Intention

Nach qemu sollte nun auch kvm getestet werden.

Mittlerweile gehören Prozessoren, mit denen kvm läuft, zum Standard, vermutlich wird man sich inzwischen schwer tun, noch ältere zu bekommen, die das nicht können.

Installation

Der Anfang ist eigentlich identisch zu qemu. Der Vollständigkeit halber sei das Vorgehen hier noch einmal erwähnt.

Wir besorgen uns wieder eine Debian-Netinstall-CD für unsere Architektur. Diese wird für die meisten Benutzer mittlerweile die "amd64" sein (NICHT die "ia64", das ist die falsche - nicht vom "amd" im Namen abschrecken lassen, die gilt auch für Intel-Prozessoren!!!). Man kann das Image unter http://www.debian.org/distrib/netinst herunterladen und mit vermutlich jedem aktuellen CD-Brennprogramm auf CD bannen. Voraussetzung für die weitere Installation ist natürlich dann ein Zugriff auf ein Debian-Repository über das Netzwerk, wer also nur eine langsame oder gar keine Verbindung dorthin hat, muss sich eine Debian-Komplett-DVD besorgen und damit die Installation durchführen.

Mit dieser CD starten wir den blanken Rechner und installieren erst mal alles mit den Standard-Einstellungen (sofern nicht individuelle Anpassungen z.B. fürs Netzwerk nötig sind). Nur die tasksel-Konfiguration machen wir komplett leer (per default ist dort "Standard" angekreuzt, auch das nehmen wir heraus).

Die Plattenaufteilung ist Geschmackssache, spielt für den weiteren Betrieb auch keine besondere Rolle, da qemu-kvm ohnehin mit ganz normalen Dateien im Filesystem arbeitet. Es sollte nur auf der Partition, die das Start-Betriebssystem enthält, ausreichend Platz sein, um dieses und spätere Aktualisierungen ordentlich unterzubringen. Da bei heutigen Plattengrößen das nicht mehr wirklich eine Rolle spielt, kann man z.B. mit 10 oder 20GB (oder mehr) arbeiten. Man kann auch die Option "Guided Partioning" wählen, da wird im wesentlichen alles automatisch ausgewählt.

Im Ergebnis haben wir jetzt eine ziemlich kleine Debian-Installation.

Zu dieser Installation fügen wir jetzt noch hinzu:

• wenn wir Installation und Konfiguration über den Rechner selbst machen wollen: ein X mit den erforderlichen Softwarepaketen (hier im Beispiel: kde mit allen Abhängigkeiten)
• das Paket libvirt-bin
• qemu-kvm
• empfehlenswert, aber für die Installation nicht relevant: smartmontools

Die Pakete können bei Debian über

apt-get install kde libvirt-bin qemu-kvm


installiert werden. Wenn wir NICHT über X arbeiten wollen, sondern über VNC, dann genügt uns das SDL-Paket, welches aufgrund der Abhängigkeiten bei der Installation von libvirt-bin mit installiert wird.

Jetzt haben wir alles, was wir für kvm brauchen. Separate Module brauchen wir nicht, die gehören inzwischen bereits zum Standardumfang des Kernels, der bei der Installation von der Netinstall-CD installiert wird. Ein Neustart zum Abschluss zeigt uns dann noch, ob wirklich alles funktioniert und führt uns, wenn alles in Ordnung ist, ins KDE, bei welchem wir uns mit dem Nicht-root-Benutzer, der bei der Installation angelegt wurde, anmelden können. Falls wir uns auch als root anmelden dürfen wollen, müssen wir die Datei /etc/kde3/kdm/kdmrc editieren und dort die Zeile

AllowRootLogin=False

in

AllowRootLogin=True

ändern.

Erster Test von kvm

Nachdem wir alles installiert haben, testen wir die Sache einfach mal. Als Verzeichnis für die Gast-Images können wir das bereits eingerichtete Verzeichnis /var/lib/libvirt/images nehmen.

Mit dem Befehl

qemu-img create -f qcow2 /var/lib/libvirt/images/dummy.img 4000M

erzeugen wir ein Harddisk-Image mit einer Größe von 4000 MBytes im Format qcow2. Mit qcow2 wird versucht, die Imagegröße immer möglichst klein zu halten. Nicht wundern also, wenn nach dem o.g. Befehl nur ein Image von ein paar KBytes entsteht. Dementsprechend schnell ist das Image auch erzeugt. 

Um installieren zu können, können wir entweder unsere oben angelegte Installations-CD nehmen oder wir legen die ISO-Datei z.B. nach /var/lib/libvirt:

wget -O /var/lib/libvirt/debian-7.3.0-amd64-netinst.iso cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-7.3.0-amd64-netinst.iso

Mit

kvm -M pc -drive file=/var/lib/libvirt/images/dummy.img,if=ide,index=0 -drive file=/var/lib/libvirt/debian-7.3.0-amd64-netinst.iso,media=cdrom,index=1 -vnc 0.0.0.0:0 -k de


starten wir unser neues Image. Mit einem VNC-Viewer können wir auf unser virtuelles Fenster zugreifen, dabei muss die IP-Adresse des Rechners angegeben werden. Beim Start des Images sehen wir den virtuellen PC, welcher dann versucht, vom virtuellen CD-Laufwerk (welches mit die ISO-Datei simuliert wird) zu booten. Wir sollten also im VNC-Viewer den Startbildschirm der Debian-Installation sehen und im weiteren Verlauf in der Lage sein, in der virtuellen Umgebung eine komplette Debian-Installation durchzuführen.

Wer es ganz eilig hat oder sofort sehen will, ob seine kvm-Installation funktioniert, kann auch fertige Disk-Images erhalten, und zwar über den Link http://wiki.qemu.org/Testing. Dort findet sich unter anderem auch ein i386-Linux-Image (linux-0.2.img.bz2). Das kann man sich einfach z.B. auch unter /var/lib/libvirt/images ablegen, dort mit bunzip2 entpacken und aufrufen, dann allerdings NICHT mit der oben genannten Kommandozeile, sondern über

kvm -M pc -drive file=/var/lib/libvirt/images/linux-0.2.img,if=ide,index=0 -vnc 0.0.0.0:0 -k de

Die weiteren Parameter für den kvm-Aufruf finden sich in der manpage zu kvm.

kvm im Netzwerk

Die Konfiguration von kvm fürs Netzwerk ist eigentlich simpel, da es sich selbst mit internen IP-Adressen versorgt. Mit dem Parameter "-net nic,vlan=0" wird dem Gast eine Netzwerkkarte (Default-Modell: E1000) zugewiesen.

Häufig wird es aber so sein, dass man mehrere kvm-Session gleichzeitig betreibt und diese jeweils IP-Adressen bekommen sollen, unter denen die Gäste dann auch erreichbar sein sollen. Das funktioniert am besten über Bridging des Netzwerkinterfaces des Hosts zu den virtuellen Netzwerkkarten sowie zur physischen Netzwerkkarte. Dazu ist zunächst in der Datei /etc/network/interfaces die physische Netzwerkkarte auszukommentieren. Anstelle der physischen Netzwerkkarte wird ein Bridge-Interface eingeführt, welches per default erst einmal die physische Netzwerkkarte bedient.

#auto eth0
#iface eth0 inet static
#  address 10.1.1.2
#   network 10.1.1.0
#   netmask 255.255.255.0
#   broadcast 10.1.1.255
#   gateway 10.1.1.1

auto br0
iface br0 inet static
   address 10.1.1.2
   network 10.1.1.0
   netmask 255.255.255.0
   broadcast 10.1.1.255
   gateway 10.1.1.1
   bridge_ports eth0
   bridge_fd 9
   bridge_hello 2
   bridge_maxage 12
   bridge_stp off


Bei einem Neustart des Rechners sehen wir, dass das Bridge-Interface initialisiert wird. Mit ifconfig sieht man die neue Konfiguration des Netzwerks:

kvmtest:/var/local# ifconfig
br0       Link encap:Ethernet  HWaddr 00:60:08:6a:33:4d
          inet addr:10.1.1.2  Bcast:10.1.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2835176 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4239402 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:447734595 (426.9 MiB)  TX bytes:1151708996 (1.0 GiB)

eth0      Link encap:Ethernet  HWaddr 00:60:08:6a:33:4d
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2835074 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4240094 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:487438184 (464.8 MiB)  TX bytes:1151765134 (1.0 GiB)
          Interrupt:11 Base address:0xb000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:149 errors:0 dropped:0 overruns:0 frame:0
          TX packets:149 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:8676 (8.4 KiB)  TX bytes:8676 (8.4 KiB)

Beim Aufrufen der Gäste ist es jetzt wichtig, dass diese separate virtuelle Netzwerkkarten bekommen, damit sie im Netzwerk auch wirklich unterscheidbar sind. Das geschieht durch die Benutzung des "macaddr"-Parameters, bei welchem dem Aufrufparameter "-net nic,..." gesagt wird, welche MAC-Adresse (also welche physische Kartenadresse) der Netzwerkkarte zugewiesen wird. Normalerweise sollen MAC-Adressen nur ein einziges Mal in der Welt existieren - da die MAC-Adresse aber ohnehin nur bis zum nächsten Router benutzt wird, genügt es im Normalfall, wenn wir uns unsere eigene Liste verwendeter MAC-Adressen merken. Wichtig: Die ersten Stellen sollten nicht verändert werden, da sie den Hersteller der Karte angeben. Wenn wir für die ersten Stellen z.B. "00:60" benutzen, könnte es sein (auch wenn es unwahrscheinlich ist), dass wir in Konflikt mit einer 3COM-Netzwerkkarte geraten, die die gleiche MAC-Adresse besitzt.

Von kvm wird als Standard-MAC-Adresse benutzt: 52:54:00:12:34:56. Diese können wir unserem ersten kvm-Gast zuweisen. Dem nächsten können wir z.B. die MAC-Adresse 52:54:00:12:34:57 geben. Die MAC-Adressen werden übrigens hexadezimal notiert, nach der 59 kommt also nicht die 60, sondern die 6A.

Dementsprechend lautet der Aufruf für unseren ersten kvm-Gast:

kvm -drive file=/var/lib/libvirt/images/dummy.img,if=ide,index=0 -drive file=/var/lib/libvirt/debian-7.3.0-amd64-netinst.iso,media=cdrom,index=1 -vnc 0.0.0.0:0 -net nic,vlan=0 -net tap,vlan=0,ifname=tap0 -k de

für unseren zweiten Gast dann:

kvm -drive file=/var/lib/libvirt/images/dummy.img,if=ide,index=0 -drive file=/var/lib/libvirt/debian-7.3.0-amd64-netinst.iso,media=cdrom,index=1 -vnc 0.0.0.0:0 -net nic,vlan=0,macaddr=52:54:00:12:34:57 -net tap,vlan=0,ifname=tap1 -k de

Das Gastsystem kann jetzt jeweils separat konfiguriert werden - ebenso wie für die MAC-Adresse gilt aber natürlich auch für die IP-Adressen, dass man sich hier eine Liste machen muss, um Überschneidungen zu verhindern.

Beispiel für zwei Openfiler-Gastsysteme, hier erfolgt die IP-Konfiguration in der Datei /etc/sysconfig/network-scripts/ifcfg-eth0:

Gast 1:

DEVICE=eth0
IPADDR=10.1.1.2
NETMASK=255.255.255.0
NETWORK=10.1.1.0
BROADCAST=255.255.255.255
GATEWAY=10.1.1.1
ONBOOT=yes
TYPE=Ethernet
HWADDR=52:54:00:12:34:56

Gast 2:

DEVICE=eth0
IPADDR=10.1.1.3
NETMASK=255.255.255.0
NETWORK=10.1.1.0
BROADCAST=255.255.255.255
GATEWAY=10.1.1.1
ONBOOT=yes
TYPE=Ethernet
HWADDR=52:54:00:12:34:57

Sobald die Gastsysteme mit dieser Konfiguration gestartet wurden, können wir sie von irgendeinem anderen Rechner im Netzwerk anpingen. Auf diesem Rechner können wir dann auch gleich anhand der ARP-Tabelle sehen, dass die MAC-Adressen passend zugeordnet wurden:

remotehost:~#arp -a
? (10.1.1.2) at 52:54:00:12:34:56 [ether] on eth0
? (10.1.1.3) at 52:54:00:12:34:57 [ether] on eth0
? (10.1.1.5) at 00:60:08:6A:33:4D [ether] on eth0

Die letzte Zeile gehört dabei zu unserem Host, hier sehen wir die MAC-Adresse der physischen Netzwerkkarte (eine 3COM 3c905 Boomerang), diese haben wir bereits weiter oben beim "ifconfig" gesehen.

libvirt

Mit libvirt werden wir endlich ohne großen Aufwand in die Lage versetzt, unsere virtuellen Maschinen automatisch starten, stoppen und verwalten zu können.

Für eine sinnvolle Arbeit mit libvirt brauchen wir das Paket virtinst, welches wir uns auf die bekannte Weise per "apt-get install virtinst" holen.

Damit haben wir jetzt "virt-install" zur Verfügung, mit welchem wir die passende libvirt-Konfiguration erzeugen. Wenn wir unser Dummy-Image mit dem CD-ROM zum Laufen bringen wollen, so wie wir es oben getan haben, dann erledigen wir das mit dem Befehl:

virt-install --name=dummy --ram=128 --disk path=/var/lib/libvirt/images/dummy.img --cdrom=/var/lib/libvirt/debian-7.3.0-amd64-netinst.iso --vnc --vncport=0 --vnclisten=0.0.0.0 --keymap=de --virt-type=kvm

Damit wurde erledigt:

• Erstellen der /etc/libvirt/qemu/dummy.xml, welche die Konfiguration für unsere virtuelle Maschine enthält
• Start der virtuellen Maschine mit den jetzt über die XML-Datei fix definierten Parametern

Mit dem Programm "virsh" haben wir auch eine ordentliche Oberfläche für die Verwaltung unserer virtuellen Hosts ("domains").

In dieser Oberfläche können wir z.B. in dem Fall, dass bei dem vorigen Schritt etwas schiefgegangen ist und wir noch mal von vorn anfangen wollen, mit dem Befehl "destroy dummy" und "undefine dummy" den Eintrag wieder komplett entfernen.

Normalerweise werden wir beabsichtigen, dass die virtuellen Server automatisch starten. Daher gehen wir in die "virsh" und geben dort ein: "autostart dummy". Damit wird ein Link angelegt von /etc/libvirt/qemu/dummy.xml nach /etc/libvirt/qemu/autostart/dummy.xml.

Häufig vorkommen wird auch die Aufgabe, dass auf der Grundlage einer Standard-Installation Clones eingerichtet werden sollen. Auch das ist kein Problem: im Paket virtinst findet sich das Programm "virt-clone". Mit diesem können wir folgendermaßen einen Clone unseres Dummy-Hosts erstellen (dieser muss vorher gestoppt sein!):

virt-clone -o dummy -n newdummy --auto-clone

Erstellt wird dabei im Image-Verzeichnis die Datei dummy-clone.img. Falls uns dieser Name nicht gefällt: Einfach Datei umbenennen und den Verweis darauf in der Datei /etc/libvirt/qemu/newdummy.xml anpassen. Anschließend haben wir eine komplette Kopie des Hosts, mit dem wir genauso weiterarbeiten können wie mit dem Original. Natürlich müssen wir hier ggf. die IP-Konfiguration anpassen (falls wir im Original keine DHCP-Konfiguration hatten - in diesem Fall arbeitet natürlich auch der neue Host mit DHCP, da er beim Clonen eine neue MAC-Adresse bekommen hat, wird er auch vom DHCP-Server eine andere IP-Adresse erhalten).
Weitere Sachen, die wir selbst ändern müssen:

• Hostname (/etc/hostname)
• Name der Netzwerkkarte (/etc/udev/rules.d/70-persistent-net.rules), denn durch die neue MAC-Adresse erkennt udev die Netzwerkkarte als eine neue und gibt ihr automatisch den Namen eth1, die Originale von unserem Dummy steht weiterhin als eth0 drin. In der Datei einfach die Zeile mit dem Originaleintrag auskommentieren und im neuen Eintrag das "eth1" zu "eth0" umbenennen. Nach dem Reboot steht die neue Netzwerkkarte als eth0 zur Verfügung.

Anmerkung zum aktuellen libvirt in Debian Squeeze:
Die Gastprozesse werden beim Herunterfahren des Systems NICHT automatisch beendet, für die stellt sich das quasi wie ein Druck auf den Resetknopf dar. Das ist in der Debian unstable behoben, da wird ein separates Start/Stop-init.d-Script für die Gastprozesse mitgeliefert.

Hilfe, meine virtuelle Platte wird zu klein!

Was tun? Besser wäre es gewesen, das Image gleich mit der passenden Größe zu versehen. So brauchen wir jetzt VIEL Platz und ein wenig Zeit.

Diese Prozedur ist leider nicht ganz so einfach, aber so schwierig ist es wiederum auch nicht.

Ab Version 0.13 ist qemu-img (aus dem qemu-utils-Paket) bzw. kvm-img (aus dem qemu-kvm-Paket) in der Lage, ein Resize des Images zu machen. Allerdings wird bei diesem Resize nur die Dateigröße angepasst. Das virtuelle System bekommt davon erst mal nichts mit.

An dieser Stelle noch die "alte" Prozedur (alles findet von Haus aus in /var/lib/libvirt/images statt, das erspart mir an dieser Stelle, ständig die Pfade angeben zu müssen):

1. erst mal sichern wir uns unsere dummy.img:
   cp dummy.img dummy.img.sik
2. kvm-img convert dummy.img -O raw dummy.raw
3. kvm-img create -f raw temp.raw 124000M
4. cat dummy.raw temp.raw > dummyneu.raw
5. jetzt legen wir uns die bisher generierten Dateien zur Seite und lassen nur die neu erzeugte große Datei liegen:
   mv dummy.img dummy.img.org
   mv dummy.raw dummy.raw.org
   mv temp.raw temp.raw.org
6. jetzt wird es spannend - wir testen mit dem erzeugten neuen raw-File, ob der virtuelle Host noch funktioniert:
   kvm -M pc -drive file=/var/lib/libvirt/images/dummyneu.raw,if=ide,index=0,boot=on -net nic,vlan=0 -net tap,vlan=0,ifname=tap0 -vnc 0.0.0.0:0 -k de
7. der Host sollte sauber hochkommen. Nach einem Login und Aufruf von "cfdisk" oder "fdisk" sollte eine neue Aufteilung der virtuellen Platte in der Form zu sehen sein, dass der bisherige Teil so erscheint wie vor dem Erweitern, der neue Teil erscheint als unbelegter Plattenplatz
8. wenn alles in Ordnung ist, stoppen wir den virtuellen Host und erweitern die Partition mit gparted. Dazu besorgen wir uns das passende ISO-Image von http://gparted.sourceforge.net/download.php und legen uns die gleich wieder nach /var/lib/libvirt.
9. Anschließend starten wir unseren virtuellen Host mit dem gparted-Image als virtuelles CD-Laufwerk:
   kvm -M pc -drive file=/var/lib/libvirt/images/dummyneu.raw,if=ide,index=0,boot=on -drive file=/var/lib/libvirt/gparted-live-0.8.0-3.iso,media=cdrom,index=1 -boot d -net nic,vlan=0 -net tap,vlan=0,ifname=tap0 -vnc 0.0.0.0:0 -k de
10. Beim Zugriff mit VNC werden wir in eine X-Oberfläche mit gparted geführt. Das sollte eigentlich selbsterklärend sein. Nach dem Umstellen der Partitionierung bestätigen wir alles mit "Apply", dann dauert es eine Weile, bis gparted die neue "Platte" geprüft und alles abgeschlossen hat.
11. Wir wiederholen Schritt 6:
    kvm -M pc -drive file=/var/lib/libvirt/images/dummyneu.raw,if=ide,index=0,boot=on -net nic,vlan=0 -net tap,vlan=0,ifname=tap0 -vnc 0.0.0.0:0 -k de
12. Wenn nichts schiefgegangen ist, zeigt uns "cfdisk" jetzt die gewünschte Partitionierung und "df" entsprechend deutlich mehr freien Platz als vorher.
13. Vermutlich werden wir jetzt noch die /etc/fstab anpassen müssen, um die korrekte UUID für die Swap-Partition einzutragen
14. Zum Abschluss konvertieren wir das Image wieder ins qcow2-Format:
    kvm-img convert dummyneu.raw -O qcow2 dummy.img
    Dieser Schritt dauert wieder etliche Zeit, da ja das raw-Format komplett umgepackt werden muss - bei größeren virtuellen Partitionen nimmt das nun mal Zeit in Anspruch. Die resultierende Datei dürfte jetzt ungefähr genauso groß sein wie die Originale (die wir in Schritt 1 bzw. 5 als dummy.img.org bzw. dummy.img.sik gesichert haben)