https://bugzilla.novell.com/show_bug.cgi?id=350079
Summary: Networking problem with the vif-bridge layout when using
NetworkManager in dom0 (Xen)
Product: openSUSE 10.3
Version: Final
Platform: i386
OS/Version: openSUSE 10.3
Status: NEW
Severity: Major
Priority: P5 - None
Component: Xen
AssignedTo: cgriffin@novell.com
ReportedBy: nice@titanic.nyme.hu
QAContact: qa@suse.de
Found By: Other
I use the vif-bridge layout on my laptop (never tried the other layouts).
The interfaces are controlled by NetworkManager and eth0 is my primary
interface to the world (although i have a wireless adapter too).
eth0 is designated to be xenbr0's interface to the world.
When the system is fully started up, the interface eth0 (which is a virtual
interface for dom0, and the original eth0 is renamed to peth0) is in the state
down, which means that NetworkManager cannot connect. Knetworkmanager showh my
wired network as being disconnected. If I start a bridged VM in domU, the guest
OS will be able to connect to the network, since peth0 and xenbr0 are up (BTW
vif0.0 is also up, but it's not enough for dom0 since eth0 (former veth0 I
believe IS DOWN)).
See some commend outputs depicting the problem:
milleniumfalcon:~ # brctl show
bridge name bridge id STP enabled interfaces
xenbr0 8000.00ffb0e33f6b no vif0.0
peth0
vif1.0
tap0
milleniumfalcon:~ # ip link show
1: lo: mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: wmaster0: mtu 1500 qdisc ieee80211 qlen
1000
link/ieee802.11 00:18:de:a3:12:52 brd ff:ff:ff:ff:ff:ff
3: wlan0: mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:18:de:a3:12:52 brd ff:ff:ff:ff:ff:ff
4: peth0: mtu 1500 qdisc pfifo_fast qlen 1000
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
5: vif0.0: mtu 1500 qdisc noqueue
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
6: eth0: mtu 1500 qdisc noop
link/ether 00:17:08:42:e9:36 brd ff:ff:ff:ff:ff:ff
7: vif0.1: mtu 1500 qdisc noop
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
8: veth1: mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
9: vif0.2: mtu 1500 qdisc noop
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
10: veth2: mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
11: vif0.3: mtu 1500 qdisc noop
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
12: veth3: mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
13: xenbr0: mtu 1500 qdisc noqueue
link/ether 00:ff:b0:e3:3f:6b brd ff:ff:ff:ff:ff:ff
14: vif1.0: mtu 1500 qdisc pfifo_fast qlen 32
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
15: tap0: mtu 1500 qdisc pfifo_fast qlen 500
link/ether 00:ff:b0:e3:3f:6b brd ff:ff:ff:ff:ff:ff
Fortunately there is a workaround: If I do '/etc/init.d/network restart'
NetworkManager will be able to connect:
milleniumfalcon:~ # /etc/init.d/network restart
Shutting down the NetworkManager done
Shutting down the DHCP DBUS Daemon done
Shutting down the NetworkManagerDispatcher done
Starting the DHCP DBUS Daemon done
Starting the NetworkManagerDispatcher done
Starting the NetworkManager done
milleniumfalcon:~ # ip address show
1: lo: mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: wmaster0: mtu 1500 qdisc ieee80211 qlen 1000
link/ieee802.11 00:18:de:a3:12:52 brd ff:ff:ff:ff:ff:ff
3: wlan0: mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:18:de:a3:12:52 brd ff:ff:ff:ff:ff:ff
4: peth0: mtu 1500 qdisc pfifo_fast qlen 1000
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
inet6 fe80::fcff:ffff:feff:ffff/64 scope link
valid_lft forever preferred_lft forever
5: vif0.0: mtu 1500 qdisc noqueue
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
inet6 fe80::fcff:ffff:feff:ffff/64 scope link
valid_lft forever preferred_lft forever
6: eth0: mtu 1500 qdisc noqueue
link/ether 00:17:08:42:e9:36 brd ff:ff:ff:ff:ff:ff
inet 172.23.6.33/22 brd 172.23.7.255 scope global eth0
inet6 fe80::217:8ff:fe42:e936/64 scope link tentative
valid_lft forever preferred_lft forever
7: vif0.1: mtu 1500 qdisc noop
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
8: veth1: mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
9: vif0.2: mtu 1500 qdisc noop
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
10: veth2: mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
11: vif0.3: mtu 1500 qdisc noop
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
12: veth3: mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
13: xenbr0: mtu 1500 qdisc noqueue
link/ether 00:ff:b0:e3:3f:6b brd ff:ff:ff:ff:ff:ff
14: vif1.0: mtu 1500 qdisc pfifo_fast qlen 32
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
inet6 fe80::fcff:ffff:feff:ffff/64 scope link
valid_lft forever preferred_lft forever
15: tap0: mtu 1500 qdisc pfifo_fast qlen 500
link/ether 00:ff:b0:e3:3f:6b brd ff:ff:ff:ff:ff:ff
inet6 fe80::2ff:b0ff:fee3:3f6b/64 scope link
valid_lft forever preferred_lft forever
After the workaround, my computer behaves like without Xen except that eth0's
link doesn't go down if I unplug the cable, which is not a wonder since it's
connected to the virtual bridge and won't be disconnected by plugging out a
cable from the virtual bridge's other port.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
