Ob das auf dem eigenen Server gegeben ist, läßt sich mit “grep -cE ‘vmx|svm’ /proc/cpuinfo” schnell herausfinden: Eine 0 bedeutet “nichts gefunden”, also Nein. Alle anderen Zahlen deuten auf einen geeigneten Prozessor hin.

Nun geht’s an das Installieren, unter Debian geht’s mal wieder ganz einfach:

apt-get install kvm

Das Paket bridge-utils brauchen wir auch, wird aber netterweise gleich mit KVM angezogen.

Das komplizierteste ist nun das einrichten der Network Bridge. Dazu müssen wir die Netzwerk-Konfiguration in /etc/network/interfaces etwas anpassen. Aus jedem eth0 müssen wir ein br0 machen (nicht bro wie brother, sondern br null ) und im Interface br0 muss dann noch die Zeile “bridge_ports eth0″ mit rein.

Vorher:

auto eth0
iface eth0 inet static
address ...

Nachher:

auto br0
iface br0 inet static
bridge_ports eth0
address ...

Das war’s auch schon. Nach einem Reboot sollte der Rechner wie gewohnt im Netz erreichbar sein, jedoch nun über das Interface br0 statt eth0. Falls nicht empfehle ich den Einsatz eines guten Rescue-Systems, sofern der Server in einem Rechenzentrum steht.

Weiter geht’s mit KVM:

Zuerst brauchen wir mal ein ISO von einer Installations-CD, das wir am besten mit WGET von Debian besorgen. Hier genügt übrigens die Mini-Winzig-Install-CD, da wir eh alles über’s Netz laden.

Danach brauchen wir noch ein Image, das im virtuellen System unsere Festplatte darstellt. Natürlich würde sich hier auch eine Partition funktionieren, doch arbeite ich hier doch lieber mit einer Image-Dateien je virtuellen Maschine, wobei meine Image-Datei immer so heißt, wie die Maschine darin.

Also, hier ein 10 GB Image File:

dd if=/dev/urandom of=/home/hostname.img bs=1M count=10k

Schneller geht es übrigens mit dem Befehl kvm-img:

kvm-img create /home/hostname.img 10G

Das Kommando erlaubt das Anlegen von großen Sparse-Files. Dabei werden die Blöcke der Datei nicht wirklich auf der Platte belegt, sondern erstmal nur Verzeichnis und Inode angelegt. Das Belegen der Blöcke im Datenbereich geschieht erst, wenn Daten dort wirklich geschrieben werden.

Dadurch ist kvm-img deutlich schneller als dd, welches ja wirklich 10 GB Datei auf Platte schreiben will. Allerdings sollte man sich darüber bewußt sein, dass das Dateisystem Schaden nehmen kann, wenn man mehr Speicher vorbelegt als bei Benutzung später vorhanden ist.

Gut, den Container haben wir und unsere Installations-CD als ISO-Datei haben wir auch. Der nächste Schritt wäre nun das Starten der virtuellen Maschine:

kvm -name Hostname -smp 1 -m 512 \
-hda /home/hostname.img \
-cdrom /home/debian-cd.iso \
-boot d \
-net nic,macaddr=00:16:3E:00:00:01 -net tap \
-vnc 0.0.0.0:0

Die virtuelle Maschine startet nun mit einem Prozessor (-smp) und 512 MB Ram (-m). Die erste Platte (-hda) ist unsere Image-Datei, als CD-Rom wurde das ISO der Debian-CD gewählt. Gebootet wird von CD-ROM (d).

Mit den beiden -net Optionen erzeugen wir eine virutelle Netzwerkkarte mit angegebener MAC-Adresse, die im Hostsystem über ein TAP-Interface mit der Bridge br0 verbunden wird. Wir haben dann also kein NAT, sondern das virtuelle System verhält sich über die Bridge so, als wäre es selbst direkt mit dem Netzwerk verbunden.

Mit -vnc wird zuletzt angegeben, dass der Bildschirm der virtuellen Maschine per VNC steuerbar sein soll. Die IP 0.0.0.0 sagt, dass der VNC auf allen IPs des Hostsystems erreichbar sein sollte, mit :0 lege ich den Standardport (5900) fest.

So, nun sollte der Zugriff per VNC über die IP-Adresse des Host-Systems möglich sein:

vncviewer kvm-host:5900

Der Installation der virtuellen Systems sollte damit nichts mehr im Wege stehen. Für den produktivbetrieb sollten jedoch einige Optionen geändert werden:

-boot c

Damit booten wir von Festplatte statt CD-Rom. Die Buchstaben c und d entsprechen übrigens nicht den Windows-Laufwerksbuchstaben, sondern c ist immer Platte, d ist immer CD-Rom. Das a steht übrigens für Floppy (anzugeben mit -fda file) und das n für Network Boot.

-vnc localhost:0

Damit sorgen wir dafür, dass nicht jeder per VNC auf unsere Maschine kommt. Diese hört jetzt nur noch auf 127.0.0.1 und kann somit problemlos sicher und verschlüsselt per SSH-Port-Forwarding angesprochen werden.

-pidfile /var/run/kvm-hostname.pid -daemonize

Damit bleibt der KVM-Prozess nach dem Start der virtuellen Maschine nicht hängen, sondern startet als Daemon im Hintergrund. Durch das PID-File läßt sich der Prozess später auch wieder finden.

Das CD-Rom kann dann für den Produktivbetrieb noch entfernt werden, fertig sieht das dann so aus:

kvm -name Hostname -smp 1 -m 512 \
-hda /home/hostname.img \
-boot c \
-net nic,macaddr=00:16:3E:00:00:01 -net tap \
-vnc localhost:0 \
-pidfile /var/run/kvm-hostname.pid -daemonize

Übrigens läßt sich so nicht nur Linux installieren, auch Windows läuft prima unter KVM als Gast.

Bei mehreren Systemen ist zu beachten, dass Name, MAC-Adresse, VNC-Port sowie Name des PID-Files je System eindeutig gewählt werden müssen. Das Windows-System (also 2. virtuelles System) würde in meinem Beispiel zur Installation also so gestartet:

kvm -name Windows -smp 1 -m 512 \
-hda /home/windows.img \
-cdrom /home/windows-cd.iso \
-boot d \
-net nic,macaddr=00:16:3E:00:00:02 -net tap \
-vnc 0.0.0.0:1

So, nun noch viel Spaß beim tüfteln mit KVM

Bei der VNC-Verbindung gibt es oft Probleme mit der deutschen Tastatur. Das liegt daran, dass das lokale System die Tastencodes bereits in deutsche Zeichen umwandelt, diese per VNC überträgt, das virtuelle System dieser wieder empfängt und in der Annahme, es sind normale Keycodes einer Tastatur, diese wieder in auf Deutsch wandelt. Die Umwandlung findet also doppelt statt.

Es gibt 2 einfache Lösungen hierfür: Entweder das lokale ODER das virtuelle System auf englischer Tastatur laufen lassen. Besser wäre der Parameter ‘-k de’ beim Start von KVM:

kvm -name [...] \
-vnc 0.0.0.0:1 \
-k de

Kommentare

• Am 8. Juni 2009 schrieb proxmox: ... oder gleich Proxmox VE nehmen - KVM auf Debian Lenny - http://pve.proxmox.com
• Am 8. Juni 2009 schrieb Mike: Danke für den Tipp. Libvirt steht in einigen Tagen als Thema an. In ca. 2 Wochen kommt dann ein Artikel, der die ganzen Themen (crypt, images, kvm, libvirv, ...) zusammenfasst. Wenn Proxmox bietet, was ich dort vorstelle (und nutze), lass ich das gerne mal ein paar Wochen auf meiner Maschine zum Test laufen...
• Am 15. Juni 2009 schrieb Butschek.de » KVM mit libvirt: [...] berichtete ich über Kernel-based Virtual Machine (KVM), welches ja per Kommandozeile sehr variabel eingesetzt werden kann, jedoch von Haus aus keine [...]
• Am 10. September 2009 schrieb Oerb: Hmm ich plag mich gerade noch mit dem Tunneln von VNC:1 - x rum. Irgend wie lüpt das nicht. Ne IDEE/ Vorschlag? :-)
• Am 10. September 2009 schrieb Oerb: Huch... jetzt passts und sieht dann so aus ssh -L 5901:XXX.XXX.XXX.XXX:5901 -4 user@server danach kann man dann am Client mit localhost:5901:1 auf die VNC:1 des KVM-SERVERS zugreifen
• Am 10. September 2009 schrieb Mike: Wenn du es mit -vnc localhost:0 gestartet hast, hört VPN auf 127.0.0.1 Port 5900 (=default, der Parameter gibt +/- vom Default an, daher 0 = default). Der Tunnel wird dann wie du es oben beschrieben hast aufgebaut, in meinem Beispiel (localhost:0) mit: ssh -L PORT:127.0.0.1:5900 user@host Wobei PORT eben der lokale Port ist. Der kann auch 5900 sein, muss es aber nicht. Bei 5900 sieht es dann so aus: -L 5900:127.0.0.1:5900

Empfohlene Themen:

• KVM mit libvirt