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
|