[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] dom0 networking disabled
Hi Greg On Sat, Mar 17, 2007 at 06:58:33AM -0400, Greg Saunders wrote: > I think I have a similar situation to the one Kirk Brown had. > > I've intalled Etch . . . > > Linux 2.6.18-4-amd64 #1 SMP Wed Feb 21 14:29:38 UTC 2007 x86_64 GNU/Linux > Nice! I run the debian amd port in a few places - it rocks! > .. . . and also the xen-linux-system-2.6.18-4-xen package and the > bridge-utils package. But I haven't tried installing any domUs because I > can't even get an internet connection when I boot up using "Xen > 3.0.3-1-amd64 / Debian GNU/Linux, kernel 2.6.18-4-xen-amd64". Assuming I > should have internet connection when running the Xen kernel (like I do when > I run the original Etch kernel), here's what I've done: > > > I've changed my /etc/network/interfaces file from . . . > > auto lo > iface lo inet loopback > > allow-hotplug eth0 > iface eth0 inet dhcp > > auto eth0 > > .. . . to . . . > > auto lo > iface lo inet loopback > > iface xenbr0 inet dhcp > bridge_ports eth0 > > auto xenbr0 > > One possible problem might be that the dhcp has timed out before the bridge has entered full operation mode. I didn't want to complicate things when I was outlining a solution to Kirk, but as Tim Post pointed out elsewhere in this post, I probably should have added a few timeout settings. Can you try the following: auto lo iface lo inet loopback auto xbr0 iface xbr0 inet dhcp bridge_fd 0 bridge_maxwait 0 bridge_helo 0 bridge_ports eth0 I'm not overly confident that this is the problem since the bridge is unlikely to send out a dhcp request if it's not yet operating. But it's still worth a try. Also, I'd use xbr0 or br0 for the name of your bridge. It's easier to see problems where they occur because the xen scripts use the name xenbr0 when they create a bridge. Actually, it just tripped me up when trying to troubleshoot your situation, and got me to thinking that you hadn't rebooted, hadn't edited xend-config.sxp properly, hadn't ... > Note that there are couple of differences there from what Kirk Brown had: > I'm using DHCP; I had an "allow-hotplug eth0" line in my original > interfaces file, which I don't know if I should leave, remove, or maybe > change to "allow-hotplug xenbr0". > Okay, well I believe that 'allow-hotplug' is needed by laptops that use certain wireless cards, pcmcia cards, and such. However, if this is a laptop and eth0 is a wireless card, then you've probably got bigger problems to worry about. I've read in a few different places that bridging generally doesn't work with wireless cards. See: http://linux-net.osdl.org/index.php/Bridge#It_doesn.27t_work_with_my_Wireless_card.21 If eth0 is a PCI card, then just remove the allow-hotplug stuff. If you've got a hotplug PCI system, you can always work out if/how to put the allow-hotplug back in later. > > My /etc/xen/xen-config.sxp file looks like this: > > > (network-script network-dummy) > (vif-script vif-bridge) > (dom0-min-mem 196) > (dom0-cpus 0) > That looks fine. > > The Kirk Browm message that started the thread I'm trying to continue has a > section called "***** IFCONFIG AFTER NETWORK-BRIDGE *****". I don't know > what "AFTER NETWORK-BRIDGE" means, but when I enter the command . . . > Generally "after network bridge" would mean after the xend daemon has been started. This starts when you boot up - it's startup script is /etc/init.d/xend. The configuration file xen-config.sxp is xend's config file. > ifconfig -a > > .. . . I get this: > > eth1 Link encap:UNSPEC HWaddr > 32-4F-C0-00-18-E2-1D-61-00-00-00-00-00-00-00-00 > BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > > 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:18 errors:0 dropped:0 overruns:0 frame:0 > TX packets:18 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:1060 (1.0 KiB) TX bytes:1060 (1.0 KiB) > > sit0 Link encap:IPv6-in-IPv4 > NOARP MTU:1480 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > > xenbr0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 > inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:16 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 b) TX bytes:3888 (3.7 KiB) > This doesn't look right for a couple of reasons. First, we are trying to add an interface called eth0 to our bridge, but there is no sign here that eth0 even exists on your system. Second, what the hell is going on with the HWaddr for eth1. That's not an ethernet MAC at all. It should be of the form 00:11:43:66:16:1A not 32-4F-C0-00-18-E2-1D-61-00-00-00-00-00-00-00-00. 'encap:UNSPEC', wtf? I'm guessing eth1 this is a wireless card. But I'm more worried that there is no indication that eth0 exists. Even if eth0 is enslaved to a bridge, you should still see an entry for eth0, and it should be UP, but should not have an address. Eg: eth0 Link encap:Ethernet HWaddr 00:04:75:98:E5:49 inet6 addr: ... UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 ... > The . . . > > brctl show > > .. . . command reveals: > > bridge name bridge id STP enabled interfaces > xenbr0 8000.000000000000 no > > > I take it there's something I'm missing, either to do with the brctl > command or extra requirements to use DHCP, or "hotplug" . . . or did I not > dance naked around the computer in quite the right way? > To summarize: . Explain what eth0 is and what eth1 is (wireless, PCI, etc) . Try again using the timeout settings in interfaces. . Also, do you have physical access to this machine or is it in a remote hosting center? If you've got physical access then we can step through creating a bridge manually - not something you really want to try when logged in remotely :-) _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |