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

RE: [Xen-devel] network root bridge problem


  • To: "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>
  • From: "James Harper" <JamesH@xxxxxxxxxxxxxxxx>
  • Date: Mon, 4 Oct 2004 09:27:44 +1000
  • Cc: <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 04 Oct 2004 00:38:41 +0100
  • List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
  • Thread-index: AcSpVYAknMo3COdAQGiPbmBx9jf7UwASf3sg
  • Thread-topic: [Xen-devel] network root bridge problem

> > In trying to get dom0 running diskless, i've come across the problem
> > where for a short time there is no network connectivity and so iscsi
is
> > unreachable. What is the accepted workaround? I can think of the
> > following:
> >
> > . do it in initrd. I'd rather not put this sort of setup info in the
> > initrd though.
> 
> You could allow your initrd to take configuration parameters from
> the kernel command line (they're available as environment
> variables in the linuxrc).

I just had another idea, what about hacking the bridge code to take
kernel parameters to autoconfig a bridge? eg 'br0=eth0'. In this way you
have br0 at boot time and can use it from the word go. Kernel boottime
dhcp would work etc. The only gotcha would be that you'd have to have
the Ethernet driver you require compiled into the kernel, but that would
be the case anyway if you were using kernel level dhcp.

> > . patch brctl to do it in one hit. Looks easy but is it safe?
Someone
> > mentioned that the whole exe may not be loaded at that point and so
> > could fail to load the rest if it needs to.
> 
> If you're hacking brctl you could mlock the pages.

I thought there would be a way.

> > . patch the kernel to support an 'add if to bridge + migrate
address'
> > ioctl. This is probably best and looks pretty easy via an extra
> > parameter to the existing addif ioctl.
> 
> Rather than doing this, I'd be inclined to hack the bridge code
> such that packets to a local IP are received rather than
> bridged. The current situation is at best inconsistent, where if
> a bridged interface has an IP address the host can still send
> packets with that IP on the interface, but it just can't receive.
> I'm not convinced that's the intended behaviour...

Hmmmm... that sounds like too much of a hack to me. I can understand the
current behaviour... the kernel would 'route' all packets received
straight to the bridge, bypassing the original interface.

James


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
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®.