From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Epiphany/1.7.1 Description of problem: Running /etc/init.d/xend start trashes networking in the host. Stopping xend does not remove the xen bridging device as shown in ifconfig. A reboot is required to fix. Perhaps related to bug 158367 (see comment 10) Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: x Additional info:
I cannot reproduce that problem here. If you have details about your configuration that would allow me to figure out what the problem is, please reopen the bug.
What details do you need? I have a standard network card and I followed the FedoraXenQuickstart on the wiki.
from ifconfig: xen-br0 Link encap:Ethernet HWaddr 00:01:0A:0A:52:24 inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.255 inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:27 errors:0 dropped:0 overruns:0 frame:0 TX packets:36 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3028 (2.9 KiB) TX bytes:2710 (2.6 KiB) from /var/log/messages: Jul 1 22:43:07 box kernel: Bridge firewalling registered Jul 1 22:43:07 box kernel: eth0: Setting promiscuous mode. Jul 1 22:43:07 box kernel: device eth0 entered promiscuous mode Jul 1 22:43:07 box kernel: xen-br0: port 1(eth0) entering learning state Jul 1 22:43:07 box kernel: xen-br0: topology change detected, propagating Jul 1 22:43:07 box kernel: xen-br0: port 1(eth0) entering forwarding state In addition to the crash, and the "xend stop" problem above, xend-debug.log wrongly has execute permission.
Could you send me the output of "ip addr sh ; ip ro sh" before and after starting xend ?
Sure: [root@box ~]# ip addr sh ; ip ro sh 1: lo: <LOOPBACK,UP> 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: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:01:0A:0A:52:24 brd ff:ff:ff:ff:ff:ff inet 10.0.0.1/24 brd 10.0.0.255 scope global eth0 inet6 fe80::211:2fff:fe0a:4676/64 scope link valid_lft forever preferred_lft forever 3: sit0: <NOARP> mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0 10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.1 169.254.0.0/16 dev eth0 scope link default via 10.0.0.138 dev eth0 [root@box ~]# /etc/init.d/xend start [root@box ~]# ip addr sh ; ip ro sh 1: lo: <LOOPBACK,UP> 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: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:01:0A:0A:52:24 brd ff:ff:ff:ff:ff:ff inet 10.0.0.1/24 brd 10.0.0.255 scope global eth0 inet6 fe80::211:2fff:fe0a:4676/64 scope link valid_lft forever preferred_lft forever 3: sit0: <NOARP> mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0 4: xen-br0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue link/ether 00:01:0A:0A:52:24 brd ff:ff:ff:ff:ff:ff inet 10.0.0.1/32 brd 10.0.0.255 scope global xen-br0 inet6 fe80::200:ff:fe00:0/64 scope link valid_lft forever preferred_lft forever 10.0.0.0/24 dev xen-br0 proto kernel scope link src 10.0.0.1 169.254.0.0/16 dev xen-br0 scope link default via 10.0.0.138 dev xen-br0
Running /etc/init.d/xendomains gives the error: Starting auto Xen domains:/etc/init.d/xendomains: line 50: log_success_msg: command not found
At boot, xen says something about trying with pci=biosirq. Appenind pci=biosirq to kernel options from grub doesn't help - it says it again. Should I add this somewhere else?
I'm using a 3Com Corporation 3Com 3C920B-EMB-WNM Integrated Fast Ethernet Controller (rev 40) By trashed I mean "nothing but loopback works".
The networking part of this bug is now resolved - starting xend no longer trashes networking. However, running xm create xen1 does freeze the machine. A cold reboot is needed.
Since the original bug is now fixed, marking this as closed. I have opened a new bug, bug 163468, that addresses the crash.