qemu, bridged Netzwerke (tap0 - tapN) und Timeouts

Hallo,

ich wollte hier mal fragen, ob jemand auch schon das gleiche Problem hatte.

Mein Server ist openSuSE 11.1 und die qemu Instanzen auch. Mein netzwerk sieht so aus:

vmhost:~ # ifconfig
br0 Link encap:Ethernet HWaddr 86:04:33:69:59:6E
inet addr:192.168.100.2 Bcast:192.168.100.255 Mask:255.255.255.0
inet6 addr: fe80::ec89:ddff:fe95:6d8b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:875641 errors:0 dropped:0 overruns:0 frame:0
TX packets:899094 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:108668911 (103.6 Mb) TX bytes:111690575 (106.5 Mb)

eth0 Link encap:Ethernet HWaddr 00:118:5C:74:AA
inet addr:192.168.178.2 Bcast:192.168.178.255 Mask:255.255.255.0
inet6 addr: fe80::211:d8ff:fe5c:74aa/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:20005379 errors:0 dropped:0 overruns:0 frame:0
TX packets:15436329 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:585896475 (558.7 Mb) TX bytes:1713054380 (1633.6 Mb)
Interrupt:17

eth1 Link encap:Ethernet HWaddr 00:10:B5:86:95:11
inet addr:192.168.150.2 Bcast:192.168.150.255 Mask:255.255.255.0
inet6 addr: fe80::210:b5ff:fe86:9511/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4842670 errors:0 dropped:0 overruns:0 frame:0
TX packets:11194000 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:428455875 (408.6 Mb) TX bytes:2271092960 (2165.8 Mb)
Interrupt:18 Base address:0xe000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:334051 errors:0 dropped:0 overruns:0 frame:0
TX packets:334051 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:412976027 (393.8 Mb) TX bytes:412976027 (393.8 Mb)

tap0 Link encap:Ethernet HWaddr 86:04:33:69:59:6E
inet6 addr: fe80::8404:33ff:fe69:596e/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:125286 errors:0 dropped:0 overruns:0 frame:0
TX packets:128508 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:38301160 (36.5 Mb) TX bytes:41395106 (39.4 Mb)

tap1 Link encap:Ethernet HWaddr DEE2:14:E6:CB
inet6 addr: fe80::dcde:d2ff:fe14:e6cb/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:31597 errors:0 dropped:0 overruns:0 frame:0
TX packets:48668 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:4195957 (4.0 Mb) TX bytes:5460268 (5.2 Mb)

tap2 Link encap:Ethernet HWaddr EE:09:1F:19:60:18
inet6 addr: fe80::ec09:1fff:fe19:6018/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:5799 errors:0 dropped:0 overruns:0 frame:0
TX packets:14281 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:581362 (567.7 Kb) TX bytes:2870926 (2.7 Mb)

vmhost:~ # route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.100.0 * 255.255.255.0 U 0 0 0 br0
192.168.178.0 * 255.255.255.0 U 0 0 0 eth0
192.168.150.0 * 255.255.255.0 U 0 0 0 eth1
link-local * 255.255.0.0 U 0 0 0 eth0
loopback * 255.0.0.0 U 0 0 0 lo
default 192.168.178.1 0.0.0.0 UG 0 0 0 eth0

Mein ifup Script dafür sieht so aus:

!/bin/sh

echo "Executing /etc/qemu-ifup"
echo "Bringing up $1 for bridged mode..."
ifconfig $1 0.0.0.0 promisc up
echo "Adding $1 to br0..."
brctl addif br0 $1
sleep 2

Die Ausgabe dieses Scripts sieht so aus:

Executing /etc/qemu-ifup
Bringing up tap3 for bridged mode...
Adding tap3 to br0...

tap3, weil vorher schon 3 Instanzen liefen.

Ich bekomme regelmäßig Timeouts wenn ich vom vmhost auf einen der Instanzen gehe (SSH). Andere Dienste sind auch
betroffen. Die Systemzeit habe ich mit ntp schon korrigiert, da ich woanders gelesen hatte, dass dies ein Problem sein könnte.
Ist es aber nicht.

Ich habe noch eine Firewall am Laufen, die ich über Yast konfiguriere.

Mit diesen Timeouts ist das Ganze qemu Geraffel nicht wirklich zu gebrauchen :-(

Was mache ich falsch ?

Danke

Lothar

Was machst du überhaupt? Was läuft in den Qemu-Instanzen?

Es sind jeweils Standard Installationen von openSuSE 11.1. Sollen aber auch andere werden.

Unter Anderem betreibe ich gewisse Funktionalitäten auf separaten Servern um diese leichter
verschieben zu können. Und dabei auch Erfahrung zu sammeln (mit qemu).

Weiter möchte ich den eigentlichen Server nicht mit immer mehr Software unübersichtlich machen.
Sonst gibts nur noch Gründe wegen Softwareentwicklung / Buildserver etc.

Lothar

Könnte es nicht auch einfach ein Hardware Problem profaner Art sein (Zuviele Gäste, zu wenig RAM)?

Auf jeden Fall ist für einen Server eher der VMWARE Server geeignet als viele Qemu-Instanzen.

Nee, den RAM verbrauch habe ich schon verringert (-m). Was ich noch mal testen will, ist, nur eine Instanz laufen lassen.

Habe noch geprüft, ob es an der CPU Auslastung liegt. Nein, der Rechner (Host) tut nichts und trotzdem bekomme ich
die Timeouts. Der swap ist etwa mit 400kB belegt, aber bei 3 qemu Instanzen mit je 265 MB RAM sollte der Swap auch
nicht verwendet werden (RAM auf Host = 3GB).

vmhost:~ # ps ax | grep qemu
3936 ? S 685:36 qemu -M pc -hda jedi.img -m 256 -kernel-kqemu -net nic -net tap -daemonize -nographic
3945 ? R 885:04 qemu -M pc -hda cvs-server.img -m 256 -kernel-kqemu -net nic -net tap -daemonize -nographic
13106 ? S 2:46 qemu -M pc -hda buildserver-openSuSE-10.1.img -m 256 -kernel-kqemu -net nic -net tap -daemonize -nographic

Ich habe irgendwo gelesen, dass ich maximal 4 Instanzen mit -kernel-kqemu laufen lassen kann. Stimmt das ?

Lothar

Wie gesagt, keine Ahnung. Qemu ist aber eigentlich auch nicht gerade für Servervirtualisierung bekannt.

Das ist hier wie mit dem Kettcar zur Arbeit fahren.

Von daher würde ich wirklich mal erst ein entsprechendes Produkt testen, bevor du dir hierbei einen Wolf suchst.

Es hat mit dem Bridging zu tun. Ein Dauerping aus einem der Instanzen half, die Verbindung zu dieser Instanz zu stabilisieren.
Nur dann ging ein gleichzeitiger Ping oder SSH auf eine andere Instanz völlig in die Hose

Muss also ehr bei irgend einer Netzwerk Gruppe nachfragen.

Lothar