[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |