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.