Bridged Guests losing network connectivity
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Confirmed
|
High
|
Unassigned |
Bug Description
Binary package hint: qemu-kvm
Opening at the request of Serge Hallyn.
Running 10.04 with KVM and Libvirt, starting VMs with "virsh start <domain>"
I've tested with OpenBSD 4.7 and Debian Lenny 5.0.5, both of them are having this issue.
I notice that networking with the bridge works fine at first for my guests, but after a while, the bridge stops functioning, and I can't reach it via SSH, nor can I ping/ssh out.
Also, when this happens, the ARP entry on the firewall I'm using to SSH to the guest changes from the Guest's MAC to the Host's MAC address.
On OpenBSD, if I run the /etc/netstart script to re-initialize the interface, the bridge starts functioning again, as if I restarted the VM, but quickly fails again (10-20 minutes). I have to reboot the Debian machine to get networking functioning again.
Here is my /etc/network/
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet dhcp
auto br0
iface br0 inet static
address 192.168.8.166
netmask 255.255.252.0
network 192.168.8.0
broadcast 192.168.11.255
gateway 192.168.8.1
bridge_ports eth1
bridge_fd 9
bridge_hello 2
bridge_maxage 12
bridge_stp off
And my /etc/libvirt/
<network>
<name>
<bridge name="virbr%d" />
<forward/>
<ip address=
<dhcp>
<range start="
</dhcp>
</ip>
</network>
# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT tcp -- anywhere anywhere tcp dpt:bootps
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere 192.168.122.0/24 state RELATED,ESTABLISHED
ACCEPT all -- 192.168.122.0/24 anywhere
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere anywhere reject-with icmp-port-
REJECT all -- anywhere anywhere reject-with icmp-port-
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
192.168.8.0 0.0.0.0 255.255.252.0 U 0 0 0 br0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 192.168.8.1 0.0.0.0 UG 0 0 0 br0
# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.00188b3e8dc0 no eth1
vnet0
virbr0 8000.000000000000 yes
IFCONFIG -- With Guest OS Running
# ifconfig -a
br0 Link encap:Ethernet HWaddr 00:18:8b:3e:8d:c0
inet addr:192.168.8.166 Bcast:192.
inet6 addr: fe80::218:
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:236817 errors:0 dropped:0 overruns:0 frame:0
TX packets:2654 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:17692813 (17.6 MB) TX bytes:362935 (362.9 KB)
eth0 Link encap:Ethernet HWaddr 00:18:8b:3e:8d:be
inet addr:192.168.1.151 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::218:
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:76541 errors:0 dropped:0 overruns:0 frame:0
TX packets:62301 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:10233726 (10.2 MB) TX bytes:21694280 (21.6 MB)
eth1 Link encap:Ethernet HWaddr 00:18:8b:3e:8d:c0
inet6 addr: fe80::218:
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:241821 errors:0 dropped:0 overruns:0 frame:0
TX packets:10075 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:22612242 (22.6 MB) TX bytes:1391493 (1.3 MB)
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:4013 errors:0 dropped:0 overruns:0 frame:0
TX packets:4013 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:4101296 (4.1 MB) TX bytes:4101296 (4.1 MB)
virbr0 Link encap:Ethernet HWaddr 62:47:ad:6a:ce:a5
inet addr:192.168.122.1 Bcast:192.
inet6 addr: fe80::6047:
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:0 (0.0 B) TX bytes:468 (468.0 B)
vnet0 Link encap:Ethernet HWaddr fe:54:00:53:2d:a1
inet6 addr: fe80::fc54:
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7445 errors:0 dropped:0 overruns:0 frame:0
TX packets:237663 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:977842 (977.8 KB) TX bytes:20968868 (20.9 MB)
# cat /etc/libvirt/
<network>
<name>
<bridge name="virbr%d" />
<forward/>
<ip address=
<dhcp>
<range start="
</dhcp>
</ip>
</network>
# qemu --version
QEMU PC emulator version 0.12.3 (qemu-kvm-0.12.3), Copyright (c) 2003-2008 Fabrice Bellard
# libvirtd --version
libvirtd (libvirt) 0.7.5
# uname -a
Linux ubuntu-kvm 2.6.32-24-server #42-Ubuntu SMP Fri Aug 20 15:38:55 UTC 2010 x86_64 GNU/Linux
# cat /etc/libvirt/
<domain type='kvm'>
<name>
<uuid>
<memory>
<currentMemor
<vcpu>1</vcpu>
<os>
<type arch='x86_64' machine=
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
<clock offset='utc'/>
<on_poweroff>
<on_reboot>
<on_crash>
<devices>
<emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/
<target dev='hda' bus='ide'/>
</disk>
<disk type='block' device='cdrom'>
<driver name='qemu'/>
<target dev='hdc' bus='ide'/>
<readonly/>
</disk>
<interface type='bridge'>
<mac address=
<source bridge='br0'/>
<model type='e1000'/>
</interface>
<console type='pty'>
<target port='0'/>
</console>
<console type='pty'>
<target port='0'/>
</console>
<input type='mouse' bus='ps2'/>
<graphics type='vnc' port='-1' autoport='yes' keymap='en-us'/>
<video>
<model type='cirrus' vram='9216' heads='1'/>
</video>
</devices>
</domain>
Changed in qemu-kvm (Ubuntu): | |
importance: | Undecided → High |
assignee: | nobody → Serge Hallyn (serge-hallyn) |
affects: | qemu-kvm (Ubuntu) → linux (Ubuntu) |
Changed in linux (Ubuntu): | |
assignee: | Serge Hallyn (serge-hallyn) → nobody |
Thanks very much for opening this bug.
Can you append the /etc/netstart script from openbsd here?
I notice that while you have the libvirt-defined virbr0, your VM is using
a hand-build br0 (which has stp off). Is there any particular reason for
this? It looks like you want the guests locked into eth1 only, is that
right?
1. If that is NOT what you necessarily wanted, then you might try editing
your VM xml to have:
<interface type='network'> '52:54: 00:53:2d: a1'/>
<mac address=
<source network='default'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
instead of
<interface type='bridge'> '52:54: 00:53:2d: a1'/>
<mac address=
<source bridge='br0'/>
<model type='e1000'/>
</interface>
and see whether that works.
2. Alternatively, you could see whether having libvirt create the equivalent of interfaces, and then create a file qemu/networks/ private. xml (symlinked into qemu/networks/ autostart as well) containing something like:
br0 works better (or just turn on stp on br0). You could change eth1 to have a
static address, remove br0 from /etc/network/
/etc/libvirt/
/etc/libvirt/
<network> default< /name> "192.168. 123.1" netmask= "255.255. 255.0"> 192.168. 123.2" end="192. 168.123. 254" />
<name>
<bridge name="virbr%d" />
<forward mode="route" dev="eth1"/>
<ip address=
<dhcp>
<range start="
</dhcp>
</ip>
</network>
3. Depending on the results of that, I may post a recipe for testing
attaching a veth tunnel to virbr0 and br0 and testing continuity through
that.
4. If none of these work, we can try backported kernels (from /launchpad. net/~kernel- ppa/+archive/ pre-proposed) and/or /launchpad. net/~serge- hallyn/ +archive/ lucid-kvm- test)
https:/
qemu-kvm (from https:/
packages.