KVM verzeichnet Geländegewinne - Seite 5

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
[...]
&lt;disk type='block' device='disk'&gt;
   &lt;driver name='phy'/&gt;
   &lt;source dev='/dev/VolGroup00/a'/&gt;
   &lt;target dev='/dev/sdb'/&gt;
  &lt;/disk&gt;
[...].

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

Listing 4: »virsh dump«
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>

Listing 4: »virsh
dump«

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