[DE] [gelöst] Netzwerkproblem mit virtuellen Maschinen (KVM)

[bluelupo]

Hi zusammen,
ich habe mit der Virtualisierungslösung Qemu/KVM ein kniffliges Problem mit dem Netzwerk der zwei VM's und dem Wirt.

Ausgangssituation:
Es sollen am Wirt (Host) zwei virtuelle PC's laufen (was einzelnen auch funktioniert) im gleichen Netzwerk wie der Wirt (192.168.178.0). Von allen Maschinen soll ein SSH Zugriff möglich sein in beiden Richtungen.

Das Netzwerk habe ich via Bridging (hier beschrieben) eingerichtet. Jede der beiden VM's hat eine feste IP.

virtpc01: 192.168.178.101
virtpc02: 192.168.178.102

Der Host hat die IP 192.168.178.100. Die Brigde ist eingerichtet und aktiv. Die tap-Devices sind an die bri0 gebunden.

Code: [Select]


# brctl show
bridge name     bridge id               STP enabled     interfaces
bri0            8000.000180788235       no              eth0
                                                        tap0
                                                        tap1


ifconfig am Wirt zeigt folgendes:

Code: [Select]


# ifconfig
bri0      Link encap:Ethernet  Hardware Adresse 00:01:80:78:82:35  
          inet Adresse:192.168.178.100  Bcast:192.168.178.255  Maske:255.255.255.0
          inet6-Adresse: fe80::201:80ff:fe78:8235/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:11568 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9992 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX bytes:2978649 (2.8 MiB)  TX bytes:1117469 (1.0 MiB)

eth0      Link encap:Ethernet  Hardware Adresse 00:01:80:78:82:35  
          inet6-Adresse: fe80::201:80ff:fe78:8235/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:151777 errors:0 dropped:0 overruns:0 frame:0
          TX packets:107896 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:133677877 (127.4 MiB)  TX bytes:10658901 (10.1 MiB)
          Interrupt:20 Speicher:fe9c0000-fe9e0000

lo        Link encap:Lokale Schleife  
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:16436  Metrik:1
          RX packets:389 errors:0 dropped:0 overruns:0 frame:0
          TX packets:389 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX bytes:28284 (27.6 KiB)  TX bytes:28284 (27.6 KiB)

tap0      Link encap:Ethernet  Hardware Adresse 52:bd:27:03:82:0a  
          inet6-Adresse: fe80::50bd:27ff:fe03:820a/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:268 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2181 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:500
          RX bytes:32264 (31.5 KiB)  TX bytes:340988 (332.9 KiB)

tap1      Link encap:Ethernet  Hardware Adresse 26:cf:94:3c:21:a9  
          inet6-Adresse: fe80::24cf:94ff:fe3c:21a9/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:140 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2012 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:500
          RX bytes:17314 (16.9 KiB)  TX bytes:321773 (314.2 KiB)


Starte ich nun erste VM virtpc01 (aptosid) mit nachfolgenden folgenden Kommando kann ich via ssh vom Wirt auf den Gast (virtpc01) zugreifen, umgekehrt ebenso.

Code: [Select]


$ kvm -hda ./aptosid-virtpc01.img -net nic,macaddr=52:54:00:12:34:56 -net tap,ifname=tap0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown -m 1024 -soundhw es1370 -name virtpc01


Nun wird die zweite VM virtpc02 (aptpsid) gestartet mit einer anderen MAC-Adresse.

Code: [Select]


$ kvm -hda ./aptosid-virtpc02.img -net nic,macaddr=52:54:00:12:34:57 -net tap,ifname=tap1,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown -m 1024 -soundhw es1370 -name virtpc02

Die VM virtpc02 kommt hoch, aber es ist kein Netzwerk vorhanden (eth0) und es lässt sich auch nicht via "ifup eth0" aktivieren (Fehlermeldung: No such device). ifconfig zeigt am virtpc02 nur das Loopbackdevice "lo" an. Deshalb ist auch diese VM nicht per ssh vom Wirt erreichbar (No route to host).

Was ist hier bei der Netzwerk Konfiguartion des Wirtes und der Gäste falsch? Ich habe als Screenshot noch von beiden VM's die Netzwerkinfos aus dem qemu-Monitor mit angehängt (info network).

EDIT: Noch ein Hinweis zu den VM's. Die zweite VM ist eine Kopie der ersten (cp aptosid-virtpc01.img aptosid-virtpc02.img). Danach habe ich nur noch den Hostnamen und die IP von virtpc02 angepasst.

[ralfi]

Hi bluelupo,

ich weiss zwar nicht ob das nur ein Schreibfehler ist aber das ifup/down script muss man doch von qemu benutzen so wie es der Screenshot auch beschreibt. Aber ich denke, das wirst Du schon richtig gemacht haben.

Ich habe ein ähnliches Symptom auch, wenn ich eine VirtualBox-Maschine zwischen zwei PCs mit unterschiedlicher Hardware kopiere. Da hilft dann nur eine Neukonfiguration des Netzwerk-Interfaces, auf der kopierten Maschine ist das dann bspw. eth1. Woran das liegt habe ich noch nicht rausbekommen. Ich würde es zunächst mal mit einem neu erstellten zweiten Image probieren.

[mig]

Hi

Könnte da clientseitig eine umbenamsung von eth0 durch udev erfolgt sein?

Mach auf der virtuellen Maschine ein ifconfig -a
dann siehst du welchen Namen udev der virtuellen NIC gegeben hat.

in cat /etc/udev/rules.d/70-persistent-net.rules kann man das ändern

Lg MiG

[bluelupo]

Hi zusammen,
ich hab das Problem gelöst. Es lag zum einen an meiner frei erfundenen MAC-Adresse die ungültig war und zum zweiten war im KVM-Startscript /etc/kvm/kvm-ifup der Shebang auf #!/bin/sh gesetzt (muß auf #!/bin/bash gestzt werden). Bei Debian ist /bin/sh ein Link auf /bin/dash und das hat zur Folge das das Startscript hängen bleibt.

Alle Details habe ich einen neuen Wikiartikel beschrieben: http://wiki.aptosid.de/index.php/Virtuelles_Netzwerk_in_einer_Qemu-KVM_Umgebung_einrichten

[ralul]

Ist meistens so, dass ein Fehler entweder schnell gefunden ist oder sich sogar selbst heilt, aber sowie noch was dazu kommt, ist die Kacke am Dampfen, weil man schwer die Richtung findet den Fehler zu suchen. Und bei drei Fehlern auf einmal explodiert dann auch gerne mal ein Atomkraftwerk in Tschernobyl....

[ralfi]

Na der Wiki-Beitrag ist ja auch richtig schnuffich ...