[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] xen 2.0.1, 2.4.27, 2.6.9, non-bridge



On Sat, 1 Jan 2005, Derrik Pates wrote:

> Adam Heath wrote:
> > For 2.0, the way the bridge is configured breaks the existing networking, 
> > upon
> > which nfsroot is running.
>
> I don't see how. The only thing I've run into is the fact that the
> included script that's supposed to configure up xen-br0 doesn't transfer
> the config properly to xen-br0 from eth0, and doesn't change eth0's IP
> to 0.0.0.0; I'm intending to just remove the script from my Xen systems,
> and just configure the bridge device the right way from the word go.

Configuring a bridge is a multi-step process.  At one point during the
process, normal communication is severed over eth0, while the bridge itself is
not yet fully functional.

At this point, the root filesystem is no longer available, and the machine
falls over.

I'd prefer to not do it with an initrd, as that's an added step, and extra
complexity.

> > However, with *both* 2.4.27 *and* 2.6.9, I am getting kernel panics.  I have
> > not run the oops on 2.4 thru ksymoops.  The built in oops decode logic in
> > 2.6.9 shows a null pointer in the arp_send routine.
>
> Well, that's an interesting bug; while I'm not a developer, I'd suggest
> running the Oops text through ksymoops (with an appropriate System.map),
> and sending the decoded Oops to the list along with anything else relevant.

I'll do that tomorrow, when I'm more resting.

For reference, here is the combinations I've tried.

xen 2.0.1(tarball)
2.4.27-xen0: both 2.4.27 and 2.6.9 xenU
2.6.9-xen0: 2.6.9 xenU

I haven't tried 2.4 U with 2.6 0, it's late, will try tomorrow.  I doubt that
it will have much affect, however.

> > As a side node, it'd be nice if the network backend allowed for a 
> > pointopoint
> > topology, or the existing method.  Ie, I'd like it switchable.
>
> Hack the script; there's nothing magical about the bridge setup, you can
> use traditional IP routing if you want. As pointed out in the
> documentation, the virtual network interfaces are simply like having
> NICs in between real systems, with a crossover cable interconnecting;
> you can do anything network-wise from there, the default assumption is
> simply that you'll want to start with bridging, because it's simple, and
> just like what most people are expecting.

Yeah, I've hacked the script.  As I said, it's doing a /32 netmask, and a host
route over the vifX.X interface.  If I turn off proxy_arp(but leave
ip_forwarding turned on), I can ping the hard-coded ip address(of the new
xenU) from dom0.  It's not until I enable proxy_arp that it falls over.


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.