Virtualisierung mit KVM
| Du bist hier : | Wiki home -> Events -> Linuxeinsteiger -> Virtualisierung mit KVM |
Skripte
Alle Skripe finden sich hier:
https://github.com/rleofield/KVM_scripts.git
Lizenz: LGPL
GNU Lesser General Public License
Hintergrund
KVM ist ein virtueller PC in Linux, eine 'virtuelle Maschine'. Es werden mit Software alle Teile eines handelsüblichen PC nachgebaut. Ein im 'Software-PC' installiertes Betriebssystem 'sieht' alle Teile des PC, die das Betriebssystem benötigt. Damit es es möglich, innerhalb von Linux gleichzeitig einen 2. PC, oder auch mehrere, mit einem beliebigen Betriebssystem laufen zu lassen.
KVM benutzt direkt den Prozessor. D.h. der 2. PC (der Gast) läuft daher genau so schnell, wie der eigentliche Ubuntu-PC (der Host). KVM basiert auf QEMU und ist in vielen Fällen syntaktisch gleich. QEMU brauchte zur Beschleunigung über die Hardware der CPU das Modul 'kqemu' mit, das mit KVM nicht mehr benötigt wird.
Prozessoren, die KVM unterstützen
KVM ist im Linux-Kernel enthalten und wird von Ubuntu und RedHat als Virtualisierungslösung favorisiert. Andere Virtualisierungslösungen werden hier nicht beschrieben.
Bezeichnungen:
- VM - virtuelle Maschine
- Host - PC, der PC, der die VM enthält
- Gast - die VM im PC
User-Space <-> Root-Rechte
Startet man ein Programm als normaler Benutzer, dann bekommt das Programm die Rechte des Benutzers zugewiesen. Dieses Programm kann nicht Files ändern, die zum Betrieb von Linux nötig sind. Die Sicherheit des PC wird damit verbessert.
Das Programm läuft im User-Space.
Im Gegensatz dazu gibt es die Root-Rechte.
Programme, die das Linux-System betreiben, inklusive kritischer Operationen im Netzwerk, benötigen die Rechte des privilegierten Benutzers 'root', um ausgeführt zu werden. Linux kennt verschiedene Möglichkeiten, um zeitweise dieses Recht an einen normalen Benutzer oder an eine Gruppe zu delegieren. Weiter unten wird davon Gebrauch gemacht.
Wird 'KVM' als normaler Benutzer gestartet, läuft auch die VM im 'User-Space'. Fehler in 'KVM' und in der laufenden VM können daher nicht dazu führen, dass das Linux auf dem Host-PC geschädigt wird.
Daher ist ein Betrieb von 'KVM' im 'User-Space' zu bevorzugen.
Im 'User-Space ist es aber nicht möglich, die Befehle zum Start des lokalen Netzwerkes für KVM auszuführen.
Man kann aber in Linux einige privilegierte Programme ausgewählten Benutzern und Gruppen zur Verfügung stellen.
Netz für die VM mit User Rechten starten
VNC Server in KVM
KVM kann intern eine eigenen VNC Server zur Ausgabe verwenden. Wie dieser Server in KVM eingesetzt wird, wird unten an den entsprechen Stellen beschrieben.
VNC - Virtual Network Client
Installation
Voraussetzungen für KVM
- Ein moderner Prozessor, der den 'PC im PC' direkt unterstützt (Prozessoren, die KVM unterstützen)
- Wie man selbst herausfindet, ob der eigene Prozessor für KVM geeignet ist:
$ grep -E '^flags.*\b(vmx|svm)\b' /proc/cpuinfo
- siehe auch:
- gut ausgebauter PC
- Der Gast-PC läuft im Speicher des Host-PC. Dieser muss daher über ausreichend RAM verfügen.
- 2 GB im Host-PC sind oft zu knapp bemessen, wenn der Gast-PC z.B. 1GB bekommen soll und der Host-PC noch Reserven haben soll.
- Etwa 4 GB RAM sind sinnvoll.
- Wenn möglich, dann ein 64-bit Linux verwenden. Damit gibt es keine Limits beim weiteren RAM-Ausbau.
- Getestet mit win2000, XP, win7 (32bit,64bit), win2008r2 (64bit), ubuntu, debian, sidux, arch/linux uvam.
Windows in KVM
Oft hat man noch Windows-Programme, die man nach dem Umstieg auf Ubuntu noch benötigt. Eine Möglichkeit ist WINE.
WINE ist auf Programme beschränkt, die die Win32 API verwenden. Mit neueren Programmen kann es daher Probleme geben. Erst die komplette Virtualisierung des vorhandenen PCs ermöglicht es, das bisherige Windows ohne Änderung weiter zu verwenden.
Allerdings erlaubt die Virtualisierung (noch) keine 3-D Anwendungen.
Bitte für den Betrieb von Betriebssystemen in einer VM die zugehörigen Lizenzen überprüfen!
Es ist immer besser eine Neuinstallation von Windows in einer VM vorzunehmen, weil bei der Installation die Hardware der VM korrekt erkannt wird. Ein Umzug eines installierten Windows ist möglich, kann aber zu Problemen bei der nachfolgenden Neu-Aktivierung führen.
Installation von KVM
Installation mit 'apt-get' oder 'Synaptic':
# apt-get install qemu-kvm
Danach kann man testen, ob die Installation erfolgreich war und ob die CPU auch KVM unterstützt.
$ kvm-ok INFO: Your CPU supports KVM extensions INFO: /dev/kvm exists KVM acceleration can be used
Wenn der Test nicht erfolgreich ist, aber die CPU nach der Spezifikation Virtualisierung unterstützt, kann es sein, dass im BIOS des PC die Unterstützung der Virtualisierung nicht eingeschaltet ist. Bitte im Handbuch des PC nachsehen, wie das gemacht wird.
KVM verwendet im wesentlichen die gleichen Kommandos wie QEMU:
Anpassen von KSM
KSM (Kernel Same page Merging) ist eine Eigenschaft des Linux-Kernels. Speicherseiten mit dem gleichen Inhalt werden automatisch eine einer 'copy-on-write' Region zusammengefasst. Damit können mehrere virtuelle Maschinen mit dem gleichen Betriebssystem sich RAM teilen, da viele Teile im Kern dieser VMs identisch sind.
KSM läuft im Hintergrund und braucht nicht weiter gewartet zu werden.
Die Konfigurationseingaben und Statusausgaben von KSM sind in diesem Verzeichnis zu finden:
/sys/kernel/mm/ksm/
Man kann die Werte für KSM direkt in diesen Files setzen. Beim nächsten Start sind die Werte aber wieder verloren.
Nur 2 Parameter kann man einstellen, ob man KSM benutzen möchte und in welchem Zeitintervall (in msec) der Kernel nach identischen Speicherseiten sucht.
Diese Konfiguration steht persistent in
/etc/default/qemu-kvm * KSM_ENABLED=1 * SLEEP_MILLISECS=200
Das sind Werte, mit denen auch ein langsamerer PC noch gut mit KVM/KSM arbeiten kann.
Hat man nur eine VM, kann man KSM ganz abschalten (KSM_ENABLED=0).
Entscheidungshilfe
einfach, wenige VMs, im eigenen geschütztem Netz
Werden nur einige VMs zum Test benötigt, ist diese Form die einfachste.
Man startet die VM über das Terminal, schaltet mit dem Start die benötigten Ports frei und kann schnell zum Erfolg kommen.
komfortabler, mehrere VMs, die auch mal länger laufen
Werden mehrere VMs gleichzeitig benötigt und möchte man einige VMs im lokalen Netz längere Zeit zur Verfügung haben, muss man einiges mehr machen.
Jede VM benötigt dann eine eigene MAC-Adresse und eine eigene IP-Adresse für das lokale Netz.
Einsatz von KVM mit Hilfe von Skripten
Man startet die VM auch über das Terminal, verwendet aber die vorgefertigten Skripte mit der Konfiguration.
Damit bekommt jede VM eine eigene Adresse, arbeitet im User-Space und ist im lokalen Netz.
Das ist die Konfiguration, die ich bei mir einsetze, die ich für sehr flexibel halte und die mit Hilfe der 'config.txt', des DHCP und DNS Servers gut wartbar ist.
Wichtige Abschnitte:
Netz für die VM mit User Rechten starten
Netzwerk
Default Netzwerk in 10.0.2.*
Per Default started KVM die virtuelle Maschine in einem eigenen Netzwerk, das mit einem Software-Router vom lokalen Netz des Host-PCs getrennt ist.
Die VM ist nur über das Display erreichbar, der Netzzugang, z.B. per SSH, ist blockiert.
Man kann aber beim Start der VM Ports mitgeben, die zur Kommunikation verwendet werden können.
Beispiele:
kvm win7.ovl -m 2048 -smp 2 -net nic -net user,hostfwd=tcp::3389-:3389
Es wird der Port 3389 einer VM mit Windows exportiert. Damit ist ein Zugriff auf dem Remote Desktop von Windows möglich.
kvm oneiric.raw -m 2048 -smp 2 -net nic -net user,hostfwd=tcp::22-:22
Es wird der Port 22 einer VM mit Ubuntu exportiert. Damit ist ein Zugriff über SSH möglich.
VM im lokalen Netz, (in 192.168.*.*)
Besser ist es, über eine Bridge die VM in das lokale Netz einzubinden.
# apt-get install bridge-utils # apt-get install uml-utilities
Einige Infos dazu:
https://help.ubuntu.com/community/KVM/Networking http://manpages.ubuntu.com/manpages/maverick/man5/bridge-utils-interfaces.5.html
Die in den Beispielen genannten Adressen sind anzupassen. Damit kann man allen virtuellen Maschinen Adressen aus dem lokalen Netz zuweisen.
DHCP und DNS
Damit mehrere VMs im lokalen Netz ohne Konflikte betrieben werden können, ist ein DHCP und ein DNS Server nötig.
Bieten die Server im Router nicht die ausreichende Flexibilität für DHCP und DNS, kann man beide Server auf dem Linux-Host selbst betreiben.
'dhcp3-server' ist der DHCP- Server und 'bind9' ist der DNS Server unter Linux.
# apt-get install bind9 # apt-get install dhcp3-server
Eine Beschreibung der Konfiguration von DHCP und BIND9 ist im Wiki in Arbeit.
Beispiel
Die bei mir eingesetzte Netzwerkkonfiguration sieht so aus.
Die fett dargestellten Adressen müssen angepasst werden.
$ cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet manual
auto br0
iface br0 inet static
address 192.168.10.7
network 192.168.10.0
netmask 255.255.255.0
broadcast 192.168.10.255
gateway 192.168.10.10
bridge_ports eth0
bridge_fd 9
bridge_hello 2
bridge_maxage 12
bridge_stp off
Und in '/etc'
$ cat /etc/resolv.conf # Generated by NetworkManager nameserver 192.168.10.7
'resolv.conf' wird vom Netzwerkmanager überschrieben. Deshalb ein Backup an einer Stelle anlegen, an der der Files nicht automatisch überschrieben werden kann. Z.B. in '/etc/network'.
Dort liegen auch die Varianten von 'interfaces' und das Backup von 'qemu-ifup', 'qemu-ifdown'.
So sieht der Folder bei mir aus, ohne die Subfolder:
$ ls -1 /etc/network interfaces interfaces.kvm interfaces.noKVM qemu-ifdown qemu-ifup resolv.conf
Nur 'interfaces' wird hier wirklich benötigt, alle anderen Files sind Backups für andere Konfigurationen und für die Files in '/etc'.
Ergebnis
Alle virtuellen Maschinen liegen im gleichen Netz, wie der eigene PC.
Daraus ergibt sich die Möglichkeit, z.B. einen eigenen Server im Home-Netz zu betreiben, der vom Arbeits-PC getrennt ist.
Ein MS-Windows-PC in der VM kann über Samba Files zur Verfügung stellen. uvam.
Da die VM in lokalen Netz liegt und auch über den Router Internetzugriff hat, sind entsprechende Vorkehrungen zu treffen, damit die Sicherheit gewährleistet werden kann. Die Sicherheit ist die gleiche, wie sie auch für einen normalen PC im lokalen Netz vorhanden ist.
Z.b. muss ein Windows in einer VM auch mit einem Virenscanner und der dort üblichen Firewall ausgerüstet werden.
KVM im Terminal
KVM kann im Terminal und über die Schnittstelle 'virsh' (s.u.) verwendet werden.
Wird KVM im Terminal gestartet, erfolgt die Ausgabe in einem X-Fenster,
welches die Simulation einer VGA Karte abbildet.
Alternativ zur Ausgabe über die simulierte VGA-Grafik, kann die Ausgabe über einen VNC Server erfolgen. Um die Ausgabe der VM zu sehen, muss zur Anzeige ein VNC-Client eingesetzt werden (z.B. 'vncviewer').
KVM kann dabei abgeschottet im eigenen Netz mit eigener IP (10.*.*.*) laufen oder im lokalen Netz (meist 192.168.*.*).
Ist die VM im lokalen Netz, dann diese wie eine weitere PC im lokalen Netz eingesetzt werden.
QEMU Monitor
Im Ausgabefenster kann mit Ctrl-Alt-2 der QEMU Monitor aufgerufen werden. Damit ist eine Steuerung der VM, z.B. Wechsel von externen Medien, möglich. Mit Ctrl-Alt-1 kommt man wieder zurück zur VGA-Ausgabe.
Im VNC-Client kann man mit Hotkeys auch den QEMU-Monitor erreichen. Bitte in der Dokumentation des VNC-Client nachsehen.
Für den VNC-Client 'vncviewer' bekommt man mit 'F8' ein Menü zum Senden von Hotkeys.
Image anlegen
Nach der Installation kann man sofort einen PC in einer virtuellen Maschine installieren.
Als Erstes wird ein Imagefile im Verzeichnis der neuen VM erzeugt.
$ cd /home/qemu/mint $ qemu-img create mint.raw 20G
Die Dateinamenserweiterung ist '.raw', da es sich um einen unkomprimierten File handelt, der ein 1:1 Abbild der Festplatte für die VM enthält. QEMU/KVM legt aber den File so an, dass leere Sektoren nicht mit gespeichert werden (sparse File). d.h. der neue File belegt fast keinen Platz auf der Festplatte des Host-PC.
Arbeitet man mit KVM mit den unten angegebenen Skripten kann zusätzlich zum Raw-Image ein Overlay-Image verwendet werden.
Overlay Images
Overlay Images werden eingesetzt, um den Zustand einer VM zu einem Zeitpunkt im Raw-Image zu konservieren. Alle Änderungen werden im Overlay abgelegt.
Overlays sind keine Snapshots. Snapshots werden im gleichen File angelegt, Overlays sind extra Files.
Man kann zu einem Raw-Image mehrere Overlays anlegen, um Varianten eines BS zu testen, z.B. eine kritische Installation in Windows.
Für ein Backup muss man nur einmal das Raw-Image im letzten Zustand sichern und dann nur noch das aktive Overlay.
Will man den alten Zustand wieder haben, löscht man das Overlay und erzeugt ein neues, leeres Overlay.
Mit 'commit' wird der neue Zustand der VM in das Raw-Image übertragen.
Mit folgendem Skript kann man das Commit ausführen:
Skript 'commit_and_new_ovl.sh'
#!/bin/bash SYSTEM=mint echo "Commit Ovl-Image: $SYSTEM.ovl" qemu-img commit $SYSTEM.ovl rm $SYSTEM.ovl echo "Neues Ovl-Image anlegen: $SYSTEM.ovl" qemu-img create -b $SYSTEM.raw -f qcow2 $SYSTEM.ovl echo "done"
Das Skript benötigt keine Root-Rechte. Die VM darf nicht laufen!
Ergebnis ist eine neues Raw-Image und ein neues, leeres Overlay.
Beide Files müssen wieder in ein eventuelles Backup übertragen werden.
Hinweis:
Mit der 'virsh' Schnittstelle können keine Overlays verwendet werden.
Einsatz von KVM mit der Schnittstelle Libvirt
externe Medien
USB Ports
Die VM mit VGA Ausgabe starten, d.h. nicht mit der Option VNC (siehe die Startskripte unten).
Im VGA Fenster mit 'Ctrl-Alt-2' in den QEMU-Montor wechseln.
DVD/CD Wechsel
In den QEMU-Monitor wechseln.
Die Informationen zu Block-Devices anzeigen
(qemu) info block ... ide1-cd0: type=cdrom ...
In der Ausgabe ist eine Zeile, die auf das DVD/CD-Laufwerk des Host verweist.
Die DVD/CD am Host-PC einlegen/wechseln und etwas warten, bis diese eingelesen wurde.
Aam Host-PC im Terminal mit 'df' das Device für die CD ermitteln. Es muss in der Ausgabe eine Zeile vorhanden sein, die das CD-Laufwerk. Ist eine CD eingelegt wird unter dem Mount-Point '/media' auch der Titel der CD angezeigt. Der Titel der CD wird zum Verzeichnis unter '/media'.
$ df /dev/sr0
'/dev/sr0' ist in diesem Beispiel das Device für dieCD.
In das Fenster mit dem QEMU Monitor wechseln und das CD-Device auf dem Host mit dem CD Device in der VM verbinden.
(qemu) change ide1-cd0 /dev/sr0
Nun kann in der VM auf die CD zugegriffen werden.
Ein 'unmount' ist nicht nötig. wird die CD nicht mehr benötigt, diese einfach aus dem CD-Laufwerk des Host wieder entfernen.
Wird für KVM die Libvirt Schnittstelle (siehe unten) verwendet, kann man auch über die GUI die CD wechseln, das ist einfacher.
VM im User-Space
Liegt die VM im lokalen Netz, kann es sinnvoll sein, diese mit den Rechten des Benutzers zu starten.
Zum Start der Netzwerkverbindung einer VM, wenn diese im lokalen Netz liegt sind 'root' Rechte nötig. Man kann deswegen eine VM nur mit 'root' Rechten betreiben.
Ist das aus Sicherheitsgründen nicht gewünscht, kann man das anpassen. Man muss die die Konfiguration des Netzwerkes dem Benutzer von KVM erlauben.
Netz für die VM mit User Rechten starten
Rechte festlegen
Folgender Text ist mit 'visudo' in '/etc'sudoers' einzutragen:
# visudo
Einzufügender Text:
%kvm ALL=NOPASSWD: /usr/sbin/tunctl, /usr/sbin/brctl, /sbin/ifconfig, /sbin/ifup, /sbin/ifdown
Das erlaubt den Mitgliedern der Gruppe KVM den Zugriff ohne Passwort auf die in der Liste angegebenen Programme zur Konfiguration des Netzes.
Probleme gibt es jetzt noch mit den Up- und Down-Files des Netzwerkes.
Die Befehle zur Netzkonfiguration müssen mit 'sudo' aufgerufen werden. Startet man als 'root' die VM, stört das 'sudo'. Man kann beide Versionen in den up-down Skripten eintragen und im Skript mit 'test' abfragen, ob man 'root' ist oder nicht.
Wenn beim Start (oder in 'nohup' s.u.) folgende Meldung kommt:
SIOCSIFADDR: Permission denied SIOCSIFFLAGS: Permission denied SIOCSIFFLAGS: Permission denied can't add tap0 to bridge br0: Operation not permitted
dann sind die Rechte in '/etc/sudoers' nicht korrekt gesetzt oder in den Files '/etc/qemu/if-up/-down' fehlt das 'sudo' (s.u.).
Rules in 'udev' anlegen
Folgender Text ist in '/lib/udev/rules.d/45-qemu-kvm.rules' einzutragen (u.U. File neu anlegen und mit 'chmod 644 /lib/udev/rules.d/45-qemu-kvm.rules' die Rechte setzen):
KERNEL=="kvm", GROUP="kvm", MODE="0660"
Eintrag dazu in bugs.launchpad
Fileliste in Oneiric Packages mit dem File '45-qemu-kvm.rules'
Skripte /etc/qemu-ifup und /etc/qemu-ifdown
Diese Files werden beim Start der VM aufgerufen und mit Hilfe der Rechte aus '/etc/sudoers' (s.o.) wird 'ifconfig' und 'brctl' aufgerufen.
/etc/qemu-ifup
und
/etc/qemu-ifdown
Hier sind die modifizierten Files:
/etc/qemu-ifup
#!/bin/bash
switch=$(/sbin/ip route list | awk '/^default / { print $5 }')
if test `id -u` -eq 0
then
echo "qemu up root"
/sbin/ifconfig $1 0.0.0.0 up
/usr/sbin/brctl addif ${switch} $1
else
echo "qemu up user"
sudo /sbin/ifconfig $1 0.0.0.0 up
sudo /usr/sbin/brctl addif ${switch} $1
fi
/etc/qemu-ifdown
#!/bin/bash
# NOTE: This script is intended to run in conjunction with qemu-ifup
# which uses the same logic to find your bridge/switch
switch=$(/sbin/ip route list | awk '/^default / { print $5 }')
if test `id -u` -eq 0
then
echo "qemu down root"
/usr/sbin/brctl delif $switch $1
/sbin/ifconfig $1 0.0.0.0 down
else
echo "qemu down user"
sudo /usr/sbin/brctl delif $switch $1
sudo /sbin/ifconfig $1 0.0.0.0 down
fi
Diese Anpassungen müssen nach einem Update von KVM wiederholt werden. Damit die Änderungen nicht verloren gehen, sollte man ein Backup haben. Ich speichere z.B. eine Kopie dieser Files z.B. in '/etc/network'.
Diese Skripte funktionieren nur mit '#!/bin/bash' nicht mit '#!/bin/sh', wenn man KVM als User startet. Der Updater/Installer schreibt wieder '#!/bin/sh'. D.h auch aus diesem Grund sollte man die Skripte an einer sicheren Stelle aufheben.
Einsatz von KVM mit Hilfe von Skripten
KVM hat sehr viele Optionen, die man beim Start mitgeben kann. Es ist nicht leicht, für jeden Anwendungsfall die korrekte Kommandozeile zusammenzustellen.
Hier wird die von mir verwendete Möglichkeit beschrieben, durch Parametrisierung in eine Konfigurationsfile eine größere Anzahl von VMs im lokalen Netz zu betreiben.
Will man Virtualisierung nur zum Test von verschiedenen Betriebssystemen nutzen, ist es auch sinnvoll MAC-Adressen, Netzwerknamen und IP-Adressen zu gruppieren, um spätere Konflikte zu vermeiden.
Dabei ist es egal, auf welchem PC im lokalen Netz diese VMs laufen, alle VMs haben eine vom Host unabhängige lokale IP und einen eindeutigen Namen im Netz.
Mit diesen Skripten ist es auch möglich, eine VM als Hintergrundprozess zu starten. D.h das Terminal, in dem die VM startet muss nicht offen bleiben.
Als Display kann die virtualisierte VGA oder VNC verwendet werden.
Mit VNC ist ein 'headless' Server möglich. Der Server für die VMs, d.h. der Host-PC, benötigt keinen X-Server/Client mehr.
Man kann auch ganz auf das interne Display verzichten und über eine Remote-Desktop-Lösung oder SSH die VM kontrollieren und betreiben.
Orte im Filesystem für die Konfiguration, die Skripte und die VMs
Als Basisverzeichnis einen Ort im Filesystem anlegen, an dem sich die alle VMs inklusive der Unterverzeichnisse befinden und der auf einer ausreichend großen Partition liegt.
Jede VM bekommt einen eindeutigen Namen (lucid, maverick, suse, debian, winxp, win2008de usw. ). Mit Hilfe des Namens werden die Parameter aus der Konfiguration gelesen. Der Name dient auch als Verzeichnis für eine VM und für den Namen des Image Files.
z.B. (VM-Basisverzeichnis):
/home/qemu
Hier ist auch der Konfigurationsfile (config.txt) für alle VMs.
dann liegen alle VMs inklusive einiger Files zum Start und zur Wartung unter
/home/qemu/lucid/lucid.raw /home/qemu/maverick/maverick.raw /home/qemu/suse/suse.raw /home/qemu/debian/debian.raw /home/qemu/winxp/winxp.raw /home/qemu/win2008de/win2008de.raw
Es ist unwichtig, wie das Basisverzeichnis bezeichnet wird. Wichtig ist, dass das Verzeichnis einer VM ein Unterverzeichnis des Basisverzeichnisses ist. Die Konfiguration einer VM wird beim Start im übergeordneten Verzeichnis gesucht.
Man kann auch einen anderen Ort für die Konfiguration angeben (ungetestet).
Die Images einer VM müssen wie die VM selbst genannt werden.
Die Dateinamenserweiterung der Images sind '.raw' oder '.ovl', je nach dem Einsatz der VM.
Der Konfigurationsfile 'config.txt'
Die Konfiguration einer VM für das lokale Netz ist ein einfacher Textfile mit den Spalten:
* System - Name der VM * IP - geplante IP Adresse, wird über DHCP vergeben * MAC - ge[lante MAC Adresse, muss eindeutig sein * VNC - reservierte Portnummer für VNC (5900+VNC), 100 Ports sind möglich * DNS Name - Name der VM im Netz, der DHCP zugewiesen wird * Ort - Name des Host, auf dem die VM installiert ist (hier pc7,tp,hp)
Nur die Spalten 'Name', 'MAC' und 'VNC' werden z.Zt. ausgewertet.
Das Startskript holt sich die MAC-Adresse und über DHCP wird die IP Adresse und der Name ermittelt. Der VNC Port wird verwendet, falls die VM mit VNC gestartet wird.
DIE MAC Adresse muss mit '52:54:00' beginnen, das ist der Standard QEMU MAC Prefix.
System IP MAC VNC DNS Name Ort test 192.168.10.31 52:54:00:EF:E0:01 20 vtest pc7 userver 192.168.10.32 52:54:00:EF:E0:02 21 vuserver pc7 dapper 192.168.10.33 52:54:00:EF:E0:04 22 vdapper pc7 debian 192.168.10.34 52:54:00:EF:E0:05 23 vdebian tp maverick 192.168.10.35 52:54:00:EF:E0:06 24 vmaverick hp sidux 192.168.10.36 52:54:00:EF:E0:08 26 vsidux pc7 arch 192.168.10.37 52:54:00:EF:E0:09 27 varch pc7 mav64 192.168.10.38 52:54:00:EF:E0:10 28 vmav64 pc7 #natty 192.168.10.39 52:54:00:EF:E0:11 29 vnatty pc7 win7fibu 192.168.10.66 52:54:00:EF:F0:07 46 vwin7fibu hp winw2k 192.168.10.69 52:54:00:EF:F0:0A 49 vwinw2k hp win2008de 192.168.10.80 52:54:00:EF:C0:00 50 vwin2008de tp
Beginnt eine Zeile mit # wird diese nicht gefunden. Das ist kein Kommentar, hat aber die gleiche Wirkung.
Das Startskript 'vnc_name_VNC.sh'
Das Startskript liegt direkt im Verzeichnis der VM. damit werden weitere Pfadgaben für die Images der VM nicht benötigt.
Aufgabe des Startskriptes ist es, die variablen Parameter zum Start von KVM, die nicht aus 'config.txt' gelesen werden, bereitzustellen.
Der B=Name des Skriptes setzt sich so zusammen, dass man die die wichtigsten Parameter am Namen erkennen kann. Wird das Skript ausgeführt, sieht man in der Prozessliste welche VM läuft.
Wird das Skript im Hintergrund ausgeführt, steht der Name in der Jobliste.
Teile des Namens
- vncstart - kann mit VNC gestartet werden
- name - Name der VM aus config.txt
- ## - Nummer des VNC Displays
Die Teile des Namens werden zur besseren Lesbarkeit mit '_' getrennt.
Als Beispiel wird ein Skript zum Start einer VM mit Linux Mint12 gezeigt:
'/home/qemu/mint12/vstart'
#!/usr/bin/env bash # SYSTEM=mint12 EXT=ovl # specify which NIC, VGA, RAM to use - see qemu.org for others model=rtl8139 RAM=1024 VGA=vmware VGA=cirrus #VGA=std #SMP="-smp 2" # wenn leer, dann kein VNC Display USEVNC="abbc" #USEVNC= # windows time #RTC="-rtc base=localtime" #linux time RTC= # USB Unterstuetzung an USB=-usb . ../startall.sh
Parameter, die gesetzt werden können:
- SYSTEM - eindeutiger Name der VM, wie in ../config,txt, hier 'mint12'
- EXT - Filenameerweiterung des Images: 'raw' oder 'ovl'
- model - Netzwerkkarte in der VM, siehe QEMU Doku für andere
- RAM - RAM in Megabyte in der VM
- VGA - vmware, kann besser sein als cirrus, aber langsamer
- VGA - cirrus, default, funktioniert in den meisten Fällen, ist aber auf 1024x768 limitiert
- VGA - std, original VGA, langsam, aber höhere Auflösungen möglich
- SMP - Zahl der CPUs in der VM, bis 8, wird mit -smp angegeben, z.B. "-smp 4"
- USEVNC - "irgendetwas", aber nicht "no", es wird die VGA Ausgabe verwendet (beim Start geht ein Fenster mit der Ausgabe auf)
- USEVNC - leer oder "no" - es wird die VNC Ausgabe verwendet (beim Start geht kein Fenster auf)
- RTC - "-rtc base=localtime", für Windows hat keine UTC Zeit, 'localtime' korrigiert das
- RTC - für eine Linux VM ist diese Korrektur nicht nötig
- USB= -usb - immer mit angeben, sonst kann man keine USB Devices über den QEMU-Monitor einbinden
Am Ende wird mit dem Bash-Kommando 'source' der File ../startall.sh eingebunden.
Das 'source' Kommando in der Bash ist ein einzelner Punkt am Anfang der Zeile.
Siehe auch:
$ man bash
Im Abschnitt 'SHELL BUILTIN COMMANDS' Zeile 2200
D.h. an dieser Stelle wird der Text des dort genannte Files eingebunden (internes copy/paste).
Das Skript benötigt keine Root-Rechte.
Das Hauptskript 'startall.sh'
Das Skript 'startall.sh' steht im Basisverzeichnis aller VMs.
/home/qemu
Es verwendet die Parameter aus dem Startskript, das direkt im Verzeichnis der jeweiligen VM liegt und, je nach VM, individualisiert ist.
Der Name des Logfiles kann hier angepasst werden. Alle Logs der VMs sind im File 'nohup', der im Verzeichnis der jeweiligen VM liegt.
Auch der Name des Konfigurationsfile kann angepasst werden.
Ablauf
- Suche in der Prozessliste nach 'kvm' und dem Raw-File der VM
- wenn gefunden, ist die VM bereits gestartet, Ende
- Suche in der Konfiguration nach der MAC Adresse
- nicht gefunden, der Name der VM ist nicht in config.txt oder es wurde keine MAC Adresse angegeben, Ende
- suche nach der Nummer des VNC Displays
- wenn die Variable USEVNC nicht leer ist
- wenn die Variable USEVNC nicht gleich 'no' ist
- wenn nicht gefunden, dann Vermerk im Logfile und es wird das VGA Display verwendet
- wenn gefunden, dann stelle VNCOPTIONS zusammen (-vnc :gefundene#)
- suche die ID des Benutzers (root oder normaler Benutzer)
- hole neues TUN Device (Tunnel Device für die VM)
- wenn mit root aufgerufen, dann ohne 'sudo'
- wenn als User aufgerufen, dann mit 'sudo'
- hole neues TUN Device (Tunnel Device für die VM)
- Kontrollausgabe der Werte
- Datum und Zeit ermitteln und in den Logfile schreiben
- Optionen für '-net nic' und -net tap' zusammenfassen und in den Logfile schreiben
- Festplatte (HD) angeben (-hda Name.raw od. Name.ovl)
- Kommando für KVM zusammenstellen, am Ende ist ein '$@', damit kann man das Kommando vstart.sh beim Aufruf auf der Kommandozeile erweitern
- KVM mit nohup ausführen
- wird mit '&' gestartet (vstart.sh&) läuft die VM im Hintergrund
- man kann damit das Terminal schließen und sich ausloggen, die VM läuft weiter
- KVM läuft mit der VM, das Skript wartet bis zum Beenden der VM
- die VM wurde mit den Mitteln der VM (über eine GUI, 'shutdown' u.ä. ) beendet
- TUN Device wieder entfernen
- Ende
Tipps
Wird kein VNC verwendet (USEVNC="no"), dann wird die VM in einem Fenster angezeigt. Das Fenster ist an die VM gekoppelt. Wenn man dieses Fenster schließt, wird die VM abgebrochen. Für das Betriebessystem in der VM ist das, als ob man am PC den Netzstecker gezogen hat.
Wird VNC verwendet, erfolgt keine Ausgabe in einem Fenster, man sieht nichts.
Um die VNC Ausgabe zu verwenden, muss man einen VNC-Client installieren, z.B. 'vncviewer'.
Die Ausgabe bekommt man dann über die VNC-Displaynummer, wobei sich die Display-Nummer (#) aus der Konfiguration in 'config.txt' ergibt.:
$ vncviewer :# (auf dem Host-PC) $ vncviewer vmhost2:# (von einem anderen PC in lokalen Netz, wenn die VM z.B. auf dem Host-PC 'vmhost2' gestartet wurde
Die VNC-Ausgabe ist im gesamten lokalen Netz ohne Login erreichbar. Der Traffic ist nicht verschlüsselt. D.h. man kann einen Host-PC zur Ausführung der VMs konfigurieren und sich die laufenden VMs über das Netz anzeigen lassen. Oder man setzt die Remote-Desktop Möglichkeiten ein.
Die Ausgabeformate von VNC und der VGA sind auf die Möglichkeiten der virtuellen Grafik beschränkt, was keine bei einigen Linux-Distros (Ubuntu,Centos,Fedora) keine großen Auflösungen erlaubt.
Hohe Auflösungen der Desktopausgabe erreicht man mit Remote-Desktops. Für Windows ist das 'rdesktop' und mit Linux ist das z.B. 'x2go'.
Wenn möglich sollte man zur Virtualisierung von Windows die Professional-Versionen einsetzen. In Linux muss man sich eine Remote-Desktop Lösung suchen. 'x2go' ist für Debian und die Derivate (Ubuntu) über die Paketverwaltung erhältlich.
Es kann nicht alleine gestartet werden. Es wird vom individuellen Startskript (vstart.sh) der VM mit eingebunden.
Beispiel für die Anlage einer neuen VM mit dem Startskript
Der Name der neuen VM ist 'mint'.
Der Startfile ist 'vnc_mint_57.sh'.
Als Erstes wird ein Imagefile im Verzeichnis der neuen VM erzeugt.
$ cd /home/qemu/mint $ qemu-img create mint.raw 20G
Die Dateinamenserweiterung ist '.raw', da es sich um einen unkomprimierten File handelt, der ein 1:1 Abbild der Festplatte für die VM enthält. QEMU/KVM legt aber den File so an, dass leere Sektoren nicht mit gespeichert werden (sparse File). d.h. der neue File belegt fast keinen Platz auf der HD des Host.
Ein andere Dateinamenserweiterung ist '.ovl'. Diese wird für Overlays verwendet, die auf einem Raw-Image basieren. Dazu mehr im entsprechenden Abschnitt.
Mit
$ ls -alsh
oder
$ qemu-img info mint.raw
kann man das prüfen. Ein einfaches 'ls -al' zeigt für die Größe eines Sparsefiles nur die Gesamtsumme aller 'Sektoren' an.
$ ls -al
-rw-r--r-- 1 rleo rleo 21474836480 2012-01-15 21:26 mint.raw
$ ls -als
0 -rw-r--r-- 1 rleo rleo 21474836480 2012-01-15 21:26 mint.raw
$ ls -alsh
0 -rw-r--r-- 1 rleo rleo 20G 2012-01-15 21:26 mint.raw
$ qemu-img info mint.raw
image: mint.raw
file format: raw
virtual size: 20G (21474836480 bytes)
disk size: 0
Danach startet man die Installation mit einem Image der Live-CD:
$ ./vnc_mint_06.sh -cdrom /pfad_zum_image/linuxmint-12-gnome-dvd-64bit.iso -boot d
Ist die Installation abgeschlossen, startet man die VM ohne die zusätzlichen Parameter:
$ ./vnc_mint_06.sh
Liste aller laufenden VMs
Skript 'isrunning.sh'. isrunning.sh
Das Skript liefert eine Liste aller VMs, die gestartet sind.
Liste aller nicht laufenden VMs
Skript 'notstarted.sh'. github: isnotrunning.sh
Das Skript liefert eine Liste aller VMs, die nicht laufen.
Hilfe zum Start des Startskriptes
Skript 'vstart.sh'. github: vstart.sh
Startet eine VM über den Namen.
Einsatz von KVM mit der Schnittstelle Libvirt
Virsh ist eine allgemeine Schnittstelle zur Virtualisierung.
Damit ist es möglich, von einer zentrale Stelle im Netz alle VMs zu verwalten. Virsh hat gegenüber der Lösung mit den Skripten Vor- und Nachteile, die hier angegeben werden.
In Arbeit.
Virsh über das Terminal
In Arbeit.
Virtual Machine Manager
In Arbeit.