© Gerti G., Photocase.com

Dank Libvirt-Toolkit wildert KVM auch unter den Gäste-Images der Mitbewerber. Der Newcomer KVM, überhaupt erst seit 2007 am Start, ist den etablierten Mitbewerbern wie VMware und Xen technologisch inzwischen dicht auf den Fersen.

Ein Grundproblem jeder Virtualisierung sind die gleichzeitigen Zugriffsversuche verschiedener virtueller Maschinen auf Hardware, die nur exklusiv verwendbar ist. Für dieses Problem gibt es gleich mehrere Lösungsansätze. So verwendet etwa VMwares ESX-Server [1] dafür eine Methode, die auch als “Full Virtualisation with Binary Translation” bekannt ist. Im privilegierten Ring 0 (siehe Kasten “Herrschaft über die Hardware”) läuft dabei ein so genannter Virtual Machine Monitor (VMM), während sich die Gastsysteme komplett im nicht privilegierten Ring 3 wiederfinden.

Herrschaft über die Hardware

Das generelle Problem bei der Virtualisierung mit mehreren Betriebssysteminstanzen, die voneinander nichts wissen, zeigt sich im Kleinen bereits innerhalb eines Betriebssystems mit mehreren Prozessen. Wollen mehrere davon direkt auf dieselbe Hardware zugreifen, führt das zwangsläufig zu Konflikten und ist deshalb zu verhindern. Damit das Betriebssystem nun entscheiden kann, welchen Prozessen es Vorrang bei Hardwarezugriffen einräumen soll, teilt es sie in Klassen ein, die man in Anlehnung an eine entsprechende bildliche Darstellung auch als Ringe bezeichnet (Abbildung 1). Abbildung 1: Ringstruktur in der x86-Architektur. Je nachdem, in welchem Ring ein Prozess läuft, hat dieser entweder komplette oder eingeschränkte CPU-Ressourcen zur Verfügung. Linux auf der x86-Rechnerarchitektur benutzt üblicherweise nur zwei dieser vier Privilegierungsebenen, Ring 0 und Ring 3. Im erstgenannten Ring 0 – man nennt ihn auch den Kernelspace – steht einem Prozess der komplette CPU-Befehlssatz zur Verfügung. Im Ring 3 – dem Userspace – ist dagegen ein direkter Zugriff auf die Hardware nicht möglich. Benötigt eine Userspace-Anwendung Zugriff auf ein Hardwaregerät, so muss sie den Umweg über einen Systemcall nehmen. Dabei findet ein Kontextwechsel statt und der Userspace-Prozess gibt die Kontrolle über die CPU an den Kernel ab, der den Ring 0 benutzt. Der Kernel führt dann den gewünschten privilegierten Zugriff durch und übergibt die Kontrolle über die CPU wieder an die Userspace-Applikation. Würde es ein Prozess aus Ring 3 versuchen, eine privilegierte Ring-0-Instruktion zu verwenden, würde er dadurch eine CPU-Exception auslösen und in der Folge abstürzen. Er ist also immer auf den Umweg über die Systemcalls angewiesen. Eine Übersicht aller zur Verfügung stehenden Systemcalls enthält die gleichnamige Manpage.

Führt ein solches Gastsystem nun einen privilegierten Befehl aus, von dem es gar nicht weiß, dass er ihm jetzt nicht mehr erlaubt ist, dann endet das in einem General Protection Fault. Diesen Fehler fängt nun aber der VMM im Ring 0 ab und münzt ihn in einen privilegierten VMM-Zugriff um. Das Ergebnis gibt er dann wieder zurück an das Gastsystem im Ring 3.

Der ganze Vorgang findet im Virtualisierungsmodus statt und verursacht in jedem Fall einen gewissen Overhead. Nicht privilegierte Zugriffe auf die CPU, beispielsweise von Applikationen, die im Usermode laufen, lassen sich dagegen verlustfrei unmittelbar ausführen (Direct Execution). Dieser Ansatz virtualisiert zwar die CPU, aber keine I/O-Geräte, die er nur emuliert. Dafür greift er auf Treiber des VMM-Kernels zurück. Das hat jedoch den entscheidenden Nachteil, dass sich auch nur jene Geräte ansprechen lassen, für die der VMM-Kernel einen Treiber zur Verfügung stellt.

Xen bietet zwei andere Verfahren zur Virtualisierung an. Die erste Variante bezeichnet man ebenfalls als Full Virtualisation. Allerdings benötigt der Virtual Machine Monitor, der unter Xen auch Hypervisor heißt, dafür eine CPU, die ihn speziell unterstützt [2]. Deswegen spricht man bei dieser Spielart auch von “Hardware Assisted Full Virtualisation”. Ob die CPU diesen Virtualisierungssupport anbietet, lässt sich leicht mit dem folgenden Befehl rausbekommen:

grep --color -e svm -e vmx /proc/cpuinfo

Selbstverständlich ist ebenfalls sicherzustellen, dass die Funktion im Bios nicht deaktiviert ist.

Bei Xen kümmert sich die CPU ums Virtuelle

Anders als im Beispiel mit dem Virtual Machine Monitor von VMwares ESX-Server muss der Xen-Hypervisor keine Befehlsaufrufe aktiv abfangen. In seinem Fall kümmert sich nämlich die CPU selbst darum, die Aufrufe zu virtualisieren. Aktuelle Prozessoren mit dem nötigen Virtualisierungssupport kennen hierfür einen so genannten Root Mode und einen Non-Root Mode.

Beginnt eine Gastmaschine im Non-Root Mode eine privilegierte Aktion, so fängt der Prozessor diese Anweisung ab und schickt sie an den Hypervisor (siehe Abbildung 2). Der führt den Befehl nun im so genannten Root Mode stellvertretend für das Gastsystem aus und wechselt danach wieder in den Non-Root-Modus. Dieses Verfahren ist wesentlich performanter, da der Hypervisor nicht jede Aktion der Gastmaschine aktiv überprüfen muss, um bei privilegierten Aktionen eventuell einzugreifen.

Abbildung 2: Xen arbeitet mit einem dedizierten Hypervisor, der unmittelbar auf der Hardware aufsetzt, und einem privilegierten Managementsystem.

Mit Hilfe einer modifizierten Qemu-Anwendung (»qemu-dm«) findet auch hier eine Emulation diverser I/O-Geräte statt. So sieht eine Xen-virtuelle Maschine beispielsweise immer eine RTL8139-Netzwerkkarte und eine Cirrus-Logic-VGA-Grafikkarte. Eine Übersicht der emulierten Hardware listet die Manpage von Qemu auf. Die Emulation hat natürlich einen gewissen Performanceverlust zur Folge. Abhilfe versprechen paravirtualisierte Treiber, die der Beitrag weiter unten vorstellt.

Seine volle Leistungsstärke spielt Xen allerdings erst mit der so genannten Paravirtualisation aus. “Para” bedeutet in diesem Zusammenhang so viel wie “miteinander”. Dafür ist – anders als bei der Full Virtualisation – der Betriebssystem-Kernel des Gastsystems um Hypercalls zu erweitern. Bei diesen Hypercalls handelt es sich um eine Art Software-Trap für privilegierte Anweisungen der Gastsysteme an den Hypervisor. Sie sind vergleichbar mit Systemcalls, die der Userspace an den Kernel sendet.

Zweiteilige Treiber

Im Fall von Xen kommen bei der Paravirtualisierung in den virtuellen Maschinen Frontend-Treiber zum Einsatz, die jeweils mit Hilfe eines korrespondierenden Backend-Treibers in einem privilegierten System die Hardware direkt ansprechen.

Die nötige Kommunikation zwischen Front- und Backend findet über einen Event Channel statt. Dabei handelt es sich einfach um einen gemeinsam genutzten Speicherbereich.

Das erwähnte privilegierte System heißt in der Xen-Terminologie Domain 0 und ist ein reguläres Linux-System mit einem modifizierten Kernel, der im CPU-Ring 1 läuft. Es setzt direkt auf dem Hypervisor auf und ist in der Lage, alle Hardwaregeräte anzusprechen, die ein normales Linux-System ansprechen kann. Das heißt also auch, man kann auf alle Linux-Treiber zurückgreifen. Dadurch lässt sich eine sehr große Anzahl an Geräten unterstützen. Den Zugriff auf die CPU und den Arbeitsspeicher steuert der Hypervisor direkt. Da bei dieser Technologie weder Geräte zu emulieren noch irgendwelche Befehle umzuschreiben sind, laufen die virtuellen Gastsysteme mit nahezu nativer Performance.

Die paravirtualisierten Treiber, die bei der Full Virtualisation zum Einsatz kommen, sind auf bestimmte Subsysteme ausgerichtet, üblicherweise Block- und Netzwerk-I/O, die direkt mit dem Hypervisor kommunizieren können. Somit entfällt die lästige Emulation für diese Subsysteme, was eine wesentlich bessere Performance zur Folge hat. Diese paravirtualisierten Treiber gibt es nicht nur für Linux-Systeme, mittlerweile stehen auch Treiber für Windows-Maschinen zur Verfügung.

Nachteil: Modifizierte Gäste

Ein entscheidender Nachteil bei Xen ist jedoch, dass für die performante Paravirtualisierung das Betriebssystem in den Quellen verfügbar sein muss. Somit lassen sich als Gastsysteme lediglich Linux, Open Solaris und einige BSD-Varianten verwenden. Außerdem hat es der Xen-Hypervisor bisher nicht in den offiziellen Linux-Kernel geschafft, obwohl das wohl nur noch eine Frage der Zeit ist. Inzwischen haben die Xen-Entwickler ihren Code so angepasst, dass er auf das generische Virtualisierungs-API Paravirt Ops zurückgreifen kann, das der Linux-Kernel 2.6.20 eingeführt hat.

Auf diese Weise ist zurzeit auch der Betrieb von Xen-Gastmaschinen unter einem KVM-Hypervisor möglich. Dafür braucht man das Tool Xenner [4]. Das ist vor allem deshalb interessant, weil beispielsweise Fedora seit Version 9 keinen Xen-Dom-0-Kernel mehr bereitstellt. Der Zugriff auf das Paravirt Ops-API aus dem Dom-0-Kernel ist momentan aber nur für den Linux-Kernel 2.6.29 geplant. Gelangen die Patches rechtzeitig in den offiziellen Kernel von Andrew Morton, so wird Fedora 11 auch wieder einen Xen-Dom-0-Kernel anbieten.

Ein weiteres Problem von Xen ist, dass hier immer zwei privilegierte Systeme nebeneinander existieren – der Hypervisor selbst und der Dom-0-Host. Das ist für potenzielle Angreifer nicht uninteressant, weil der Admin so im Bereich Security doppelte Arbeit leisten muss.

KVM im Kommen

Aus diesen und anderen Gründen, findet in letzter Zeit eine andere Virtualisierungslösung mehr Beachtung. Im Februar 2007 hat Linus Torvalds KVM (Kernel-based Virtual Machine) in den offiziellen Linux-Kernel 2.6.20 aufgenommen. Bei KVM handelt es sich um ein Kernelmodul, das ebenfalls auf den Virtualisierungssupport der eingesetzten CPU angewiesen ist (Abbildung 3). Wie bei der Full Virtualisation mit Xen benötigt KVM eine Intel-VT- oder AMD-V-CPU. Um den erweiterten Befehlssatz des eingesetzten Prozessors nutzen zu können, braucht der KVM-Hypervisor jeweils ein eigenes Kernelmodul, »kvm-intel« beziehungsweise »kvm-amd«.

Abbildung 3: Bei KVM ist der Linux-Kernel selbst der Hypervisor, es gibt kein weiteres privilegiertes System.

Anders als bei Xen ist der Hypervisor aber nicht unterhalb des Betriebssystems angesiedelt, sondern das Betriebssystem selbst, in Gestalt des KVM-Kernelmoduls, ist hier der Hypervisor. Die virtuellen Maschinen laufen als reguläre Userspace-Prozesse und lassen sich über die Gerätedatei »/dev/kvm« ansprechen. Als Emulator für I/O-Hardware kommt wieder ein modifiziertes Qemu zum Einsatz. Für den performanten Zugriff auf bestimmte Subsysteme existieren auch hier spezielle Treiber, die den Hypervisor direkt ansprechen. Unter KVM heißen sie Virtio-Treiber.

Libvirt vereinfacht das Management

Alle in diesem Artikel behandelten Beispiele benutzen das Libvirt-Toolkit [3] unter Fedora 10, das auch in anderen Distributionen zur Verfügung steht (Abbildung 4). Hierbei handelt es sich um eine Art Virtualisierungslayer zwischen dem eigentlichen Virtualisierungsbackend und dem Userspace in Form von Management-Tools (siehe Kasten “Images konvertieren”). Libvirt unterstützt als Backends neben Xen und KVM zurzeit auch noch LXC und OpenVZ. Mit »virt-manager«, »virt-install« und »virsh« stehen Tools bereit, mit denen sich unabhängig vom Virtualisierungsbackend neue Systeme einrichten, verwalten und monitoren lassen. Auch der sichere Zugriff auf einen Remote-Hypervisor ist mittels TLS oder X.509-Zertifikaten möglich. Zur Authentifizierung greift Libvirt auf SASL und Kerberos zurück.

Abbildung 4: Über den »virt-manager« lassen sich auch neue Hardware-Ressourcen zu einer bereits installierten Maschine hinzufügen.

Über eine recht neue Funktion kann Libvirt auch Festplatten-Speicherpools erzeugen. So lassen sich diverse Blockgeräte aus einem Netzwerk (NFS-Server, I-SCSI-Server, LVM-Gruppen) zu einem einheitlichen Pool zusammenfassen, auf den der Admin bei der Konfiguration virtueller Maschinen zurückgreift. Außerdem vereinfacht Libvirt die Netzwerkkonfiguration für die virtuellen Maschinen. So ist es beispielsweise mit »virt-manager« sehr einfach möglich, beliebige private Netzwerke den einzelnen Maschinen zuzuweisen und sie mittels einer Adressen-Umsetzung (Network Address Translation, NAT) mit der Außenwelt zu verbinden.

Alle Einstellungen, die der Admin mit diesem Tool vornimmt, darf jedes unterstütze Virtualisierungsbackend verwenden. Das heißt, man muss sich nicht mehr mit jeweils spezifischen Konfigurationstools für die verschiedenen Backends herumschlagen, wenn das Backend seinerseits die Libvirt verwendet.

virt-convert -v -i vmx --os-type=windows --os-variant=winxp winxp.vmx 

virt-image --name winxp --vnc -i winxp.xml

virsh define p2v-rhel5u2-200812231735.conf
virsh start rhel5u2

In der Praxis

In den folgenden Beispielen geht es um die Installation einer KVM-Instanz. Die virtuelle Maschine für das Beispiel lässt sich leicht mittels »virt-manager« installieren. Neben dem Namen der Maschine sind dafür auch die Installationsquelle, der Arbeitsspeicher und die Anzahl der virtuellen CPUs (VCPUs) anzugeben. Beim Storagebackend stehen eine Imagedatei im Ordner »/var/lib/libvirt/images« und eine reguläres Blockdevice zur Auswahl. Ansonsten ist daran zu denken, den SE-Linux-Typ für die Datei korrekt zu setzen:

[root@tiffy ~]# semanage fcontext -a -t virt_image_t '/Pfad/zur/Image-Datei' 
[root@tiffy ~]# restorecon -v '/Pfad/zur/Image-Datei' 

Wählt man als Backend ein Blockdevice, so darf es sich dabei auch um ein Logical Volume (LV) handeln. LVs bieten den Vorteil, dass sie sich problemlos in ihrer Größe verändern lassen und dass Snapshots die Datensicherung ungemein vereinfachen. Bevor der Installer des Systems startet, ist jedoch noch das Netzwerk der virtuellen Maschine einzurichten.

Netzwerk-Konfiguration

An dieser Stelle stehen zwei Möglichkeiten zur Wahl: eine Bridge oder ein eigenes privates Subnetz mit NAT-Konfiguration. In der Default-Einstellung bekommt die Maschine ein privates Subnetz 192.168.122.0/24 zugewiesen. Über ein Device »virbr0« auf dem KVM-Host kommuniziert die Maschine fortan mittels NAT mit der Außenwelt.

Das beschriebene Netzwerksetup ist in der Libvirt-Konfigurationsdatei »/usr/share/libvirt/networks/default.xml« hinterlegt:

<network>
 <name>default</name>
 <bridge name="virbr0" />
 <forward/>
 <ip address="192.168.122.1" netmask="255.255.255.0"> 
  <dhcp>
   <range start="192.168.122.2" end="192.168.122.254" /> 
  </dhcp>
 </ip>
</network>

Das Subnetz lässt sich über die Konfigurationsdatei anpassen oder mit einer zweiten Datei hinzufügen (Abbildung 5). Der Befehl »virsh net-define/usr/share/libvirt/networks/default.xml« aktiviert die Änderungen. Zum Verteilen der IP-Adressen greift »libvirt« auf »dnsmasq« zurück, im Fehlerfall ist also sicherzustellen, dass dieser Dienst tatsächlich aktiv ist. »virsh« kann dann alle bekannten Netzwerke auflisten:

[root@tiffy ~]# virsh net-list --all
Name         State   Autostart
-----------------------------------------
default       active   yes
ovirtbr0       active   yes
[root@tiffy ~]#

Etwas irreführend ist dabei, dass das NAT-Gerät als Bridge aufgeführt ist. Aber der folgende Aufruf in Listing 1 bestätigt, dass der Bridge keine Netzwerkkarten zugeordnet sind, sondern die Kommunikation via NAT einzurichten ist, wobei sich Libvirt selbstständig um die NAT-Regeln kümmert.

01 [root@tiffy ~]# brctl show
02 bridge name   bridge id      STP   enabled interfaces
03 ovirtbr0    8000.000000000000  no
04 virbr0     8000.000000000000  yes
05 
06 [root@tiffy ~]# iptables -t nat -L
07 Chain PREROUTING (policy ACCEPT)
08 target   prot opt source        destination
09 
10 Chain POSTROUTING (policy ACCEPT)
11 
12 target   prot opt source        destination
13 MASQUERADE all -- 192.168.122.0/24  !192.168.122.0/24
14 MASQUERADE all -- 192.168.50.0/24   !192.168.50.0/24
15
16 Chain OUTPUT (policy ACCEPT)
17 target   prot opt source        destination

Natürlich kann auch der Virt-Manager sowohl bestehende Netzwerke verändern als auch neue einrichten. Hierfür wählt der Anwender einfach über den Menüpunkt »Edit | Details« einer Hypervisor-Verbindung den »Virtual-Networks«-Tab aus. Auf die gleiche Weise kann er im Übrigen auch einfach eventuell vorhandene Storagepools über das Netzwerk einbinden.

Abbildung 5: Bestehende virtuelle Netze lassen sich über den Virt-Manager anpassen, genauso kann der Admin neue Netzwerke hinzufügen.

Alternatives Bridging

Wer lieber echtes Bridging konfigurieren will, sodass die virtuelle Maschine eine IP-Adresse aus dem Host-Subnetz bekommt, muss etwas Handarbeit leisten. Zuerst sind die entsprechenden Init-Skripte für die Netzwerkgeräte zu erzeugen (Listing 2). Hat man diese Änderungen mittels »service network restart« dem System übermittelt, so lassen sich abschließend die notwendigen IPtables-Regeln schreiben:

[root@tiffy ~]# iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT 

Ein erneuter Aufruf von »brctl« bestätigt, dass »eth0« nun zur Bridge gehört:

[root@tiffy ~]# brctl show
bridge name bridge id       STP enabled
ovirtbr0  8000.000000000000 no
virbr0    8000.000000000000 yes
br0       8000.000e0cb30440 no eth0

Die Netzwerkkarten verbinden nach dem Start die virtuellen Maschinen durch eine Art virtuelles Crossover-Kabel mit der Bridge und man sieht diese Geräte dann ebenfalls in der »brctl«-Ausgabe der Bridge zugeordnet.

01 [root@tiffy ~]# cat > ifcfg-eth0 <<EOF
02 DEVICE=eth0
03 HWADDR=00:16:76:D6:C9:45
04 ONBOOT=yes
05 BRIDGE=br0
06 EOF
07 
08 [root@tiffy ~]# cat > ifcfg-br0 <<EOF
09 DEVICE=br0
10 TYPE=Bridge
11 BOOTPROTO=dhcp
12 ONBOOT=yes
13 DELAY=0
14 EOF

Soll man sich nun für ein Bridge- oder NAT-Netzwerk entscheiden? Der Vorteil von NAT-Netzwerken ist, dass sie out of the Box funktionieren und keine Handarbeit mehr notwendig ist. Außerdem sind die Maschinen nicht direkt im Subnetz sichtbar. Der Nachteil besteht darin, dass für jeden Dienst, der in einer virtuellen Maschine läuft, eine entsprechende NAT-Regel einzurichten ist. Dieses Problem kennt eine Bridge nicht, da die Maschinen direkt im Subnetz erscheinen. Das heißt jedoch auch, dass sie besonders zu schützen sind, ganz so, als ob es sich um physische Rechner handelte.

Sind alle Eigenschaften der Maschine im Virt-Manager festgelegt, startet der eigentliche Installer. Hat die Installation geklappt, lässt sich die Maschine danach über den »virt-manager« oder auch auf der Kommandozeile wie folgt starten:

[root@tiffy ~]# virsh start node9
Domain node9 started

Die Konfiguration für die Maschine findet sich im Verzeichnis »/etc/libvirt/qemu«, allerdings kann der Benutzer sich diese auch mit Hilfe von »virsh« anzeigen lassen (Listing 3).

01 [root@tiffy ~]# virsh dumpxml node9
02 <domain type='kvm' id='5'>
03  <name>node9</name>
04  <uuid>7475d088-836d-2fad-1674-f438c83d62ff</uuid>
05  <memory>524288</memory>
06  <currentMemory>524288</currentMemory>
07  <vcpu>1</vcpu>
08  <os>
09   <type arch='i686' machine='pc'>hvm</type>
10   <boot dev='cdrom'/>
11  </os>
12  <features>
13   <acpi/>
14   <pae/>
15  </features>
16  <clock offset='utc'/>
17  <on_poweroff>destroy</on_poweroff>
18  <on_reboot>restart</on_reboot>
19  <on_crash>restart</on_crash>
20  <devices>
21   <emulator>/usr/bin/qemu-kvm</emulator>
22   <disk type='file' device='disk'>
23    <source file='/var/lib/libvirt/images/node9-sda.img'/>
24    <target dev='vda' bus='virtio'/>
25   </disk>
26   <interface type='bridge'>
27    <mac address='00:16:3e:12:34:63'/>
28    <source bridge='ovirtbr0'/>
29    <target dev='vnet0'/>
30    <model type='virtio'/>
31   </interface>
32   <serial type='pty'>
33    <source path='/dev/pts/9'/>
34    <target port='0'/>
35   </serial>
36   <console type='pty' tty='/dev/pts/9'>
37    <source path='/dev/pts/9'/>
38    <target port='0'/>
39   </console>
40   <input type='mouse' bus='ps2'/>
41   <graphics type='vnc' port='5900' autoport='yes' keymap='en-us'/>
42  </devices>
43 </domain>

Remote-Konfiguration

Wer nachträglich Eigenschaften der Maschine verändern möchte, kann die Virsh-Ausgabe einfach in eine Datei umleiten und mittels »virsh define /Pfad/Datei« die Änderungen bekannt machen. Der »virt-manager« nimmt die Änderungen auch über ein GUI entgegen, das dabei auf der lokalen Arbeitsstation laufen darf, während die virtuelle Maschine auf einem ganz anderen Host installiert ist (Abbildung 6). Für die nötige Verbindung des Virt-Managers stehen vier Authentifizierungsmethoden zur Auswahl:

• SSH
• TLS/SSL zusammen mit x509
• Kerberos/GSSAPI
• Username und Passwort-Digest-MD5

Alle vier Varianten haben ihre Vor- und Nachteile. Im einfachsten Fall erzeugt der Admin auf der Workstation einen SSH-Schlüssel und überträgt ihn auf den Rechner, auf dem die virtuelle Maschine zu installieren ist:

[root@tiffy ~]# ssh-keygen -t rsa
[root@tiffy ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@remotehost 

Abschließend ist auf dem entfernten Rechner sicherzustellen, dass sowohl der SSH- als auch der Libvirt-Daemon auf eingehende Anfragen warten. Wer nun den »virt-manager« startet, sieht die neu eingerichtete Verbindung und darf sich via Libvirt auf dem entfernten Hypervisor anmelden. Die entfernten Maschinen lassen sich auch auf der Kommandozeile mittels »virt-install« einrichten. Das könnte so aussehen:

[root@tiffy ~]# virt-install 
  --hvm
  --connect qemu+ssh://root@tiffy.tuxgeek.de/system 
  --name demo 
  --ram 512 
  --disk path=/var/lib/libvirt/images/demo.img,size=5     
  -network network:default 
  --vnc 
  --location ftp://grobi.tuxgeek.de/pub/fedora/f10/ 

Das Virsh-Tool bietet auch eine Connect-Option an, mit der es auf entfernte Rechner zugreifen kann. Welche Möglichkeiten für die Verwaltung das Tool bietet, hängt auch von dem eingesetzten Hypervisor ab. So verwendet die Kombination aus »libvirt« und KVM gegenwärtig noch nicht alle Möglichkeiten, die »libvirt« mit Xen kennt. Die Dinge sind aber im Fluss, sodass in Kürze mit weiteren Implementierungen zu rechnen ist. Beispielsweise beherrscht KVM-78 in Kombination mit Libvirt-0.5 bereits heute die Möglichkeit, virtuelle Maschinen im laufenden Betrieb zwischen verschiedenen Hosts zu migrieren.

Abbildung 6: Über eine sichere SSH-Verbindung kann der Administrator auch auf den Hypervisor einer Remote-Maschine zugreifen.

Ressourcen-Management

Das Beispiel in Listing 4 demonstriert einige Virsh-Optionen einer virtuellen Maschine auf Xen-Basis. Die Libvirt-Konfigurationsdatei sieht der KVM-Konfiguration sehr ähnlich. Möchte man beispielsweise der Maschine Arbeitsspeicher wegnehmen, so geht dies mit Virsh so:

[root@node5 ~]# virsh setmem node0 256000

Der folgende Befehl beweist, dass das System aktuell danach nur noch 256 MByte der verfügbaren 512 MByte RAM verwendet:

[root@node5 ~]# virsh dominfo node0
Id:     2
Name:   node0
UUID:   10110f93-0038-9e64-3213-6088ba492f21 
OS Type:        linux
State:  blocked
CPU(s): 1
CPU time:       20.4s
Max memory:524288 kB
Used memory:  255792 kB

Braucht die Maschine mehr Plattenplatz? Auch kein Problem:

[root@node5 ~]# virsh attach-disk node0 /dev/VolGroup00/b /dev/sdb 

Hiermit bekommt die virtuelle Maschine das Blockdevice »/dev/VolGroup00/b« aus der Domain 0 als »/dev/sdb«-Device zugewiesen.

[root@node5 ~]# virsh dumpxml node0
[...]
<disk type='block' device='disk'>
   <driver name='phy'/>
   <source dev='/dev/VolGroup00/a'/>
   <target dev='/dev/sdb'/>
  </disk>
[...].

Ein Blick in die neue Konfiguration der Maschine bestätigt dies.

01 [root@node5 ~]# virsh dumpxml node0
02 <domain type='xen' id='2'>
03  <name>node0</name>
04  <uuid>10110f9300389e6432136088ba492f21</uuid>
05  <bootloader>/usr/bin/pygrub</bootloader>
06  <os>
07   <type>linux</type>
08   <kernel>/var/lib/xen/boot_kernel.J2aQPO</kernel>
09   <initrd>/var/lib/xen/boot_ramdisk.Z54Wy3</initrd>
10   <cmdline>ro root=/dev/VolGroup00/LogVol00 noipv6 rhgb quiet</cmdline>
11  </os>
12  <memory>524288</memory>
13  <vcpu>1</vcpu>
14  <on_poweroff>destroy</on_poweroff>
15  <on_reboot>restart</on_reboot>
16  <on_crash>restart</on_crash>
17  <devices>
18   <interface type='bridge'>
19    <source bridge='xenbr0'/>
20    <mac address='AA:BB:CC:DD:01:00'/>
21    <script path='vif-bridge'/>
22   </interface>
23   <disk type='block' device='disk'>
24    <driver name='phy'/>
25    <source dev='/dev/VolGroup00/node0'/>
26    <target dev='xvda'/>
27   </disk>
28   <console tty='/dev/pts/1'/>
29  </devices>
30 </domain>

Live-Migration

Die bereits erwähnte Live-Migration von virtuellen Systemen initiiert:

[root@node5 ~]# virsh migrate --live node0 xen+ssh://node1 

Voraussetzung hierfür ist, dass beide physikalischen Hosts, in diesem Beispiel also »node5« und »node1«, Zugriff auf das Blockdevice haben, auf dem die virtuelle Maschine »node0« hinterlegt ist. Dies lässt sich im einfachsten Fall über einen I-SCSI-Export lösen. Findet der Zugriff hierauf über ein dediziertes Gigabit-Netz statt, kann die zu erwartende Performance sogar die eines Fiber-Channel-Zugriffs übertreffen. (jcb)

Ovirt – ein Ausblick

Auf dem Virtualisierungsmarkt ist zurzeit viel Bewegung. Bevorzugen die meisten Distributionen gegenwärtig noch Xen, geht der Trend bereits eindeutig in Richtung KVM, auch wenn hier noch einiges an Arbeit zu leisten ist. Wohin die Reise geht, lässt sich auf der Ovirt-Homepage [5] verfolgen. Bei Ovirt handelt es sich um ein noch recht junges Open-Source-Projekt. Es vereint diverse bekannte Open-Source-Tools unter einer Haube und zaubert daraus eine Software, mit der man virtuelle Maschinen erstellen und verwalten kann. Dabei fasst es die Hardware-Ressourcen eines ganzen Netzes in so genannten Pools zusammen. Die daraus konfigurierten virtuellen Maschinen booten ein KVM-Image – wahlweise von einem lokalen Medium oder aus dem Netzwerk über einen PXE-Server. Auch wenn die aktuelle Versionsnummer 0.96 noch eine recht junge Historie bescheinigt, bietet Ovirt doch bereits jetzt Funktionen an, die man bisher noch bei keinem anderen Management-Tool für virtuelle Maschinen im Open-Source-Bereich gesehen hat. Abbildung 7: Mit Ovirt steht ein neues Management-Tool für virtuelle Maschinen und Ressourcen zur Verfügung, das Funktionen bietet, die man bisher im Open-Source-Lager nicht kannte.