KVM verzeichnet Geländegewinne - Seite 4

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:

&lt;network&gt;
 &lt;name&gt;default&lt;/name&gt;
 &lt;bridge name="virbr0" /&gt;
 &lt;forward/&gt;
 &lt;ip address="192.168.122.1" netmask="255.255.255.0"&gt; 
  &lt;dhcp&gt;
   &lt;range start="192.168.122.2" end="192.168.122.254" /&gt; 
  &lt;/dhcp&gt;
 &lt;/ip&gt;
&lt;/network&gt;

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.

Listing 1: »brctl show«
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

Listing 1: »brctl
show«

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.

Listing 2: Netzwerkkonfiguration
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

Listing 2:
Netzwerkkonfiguration

01 [root@tiffy ~]# cat &gt; ifcfg-eth0 &lt;&lt;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 &gt; ifcfg-br0 &lt;&lt;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).

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

Listing 3:
»virsh«

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