WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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