Xen devel - Oct 2005 - RE: [PATCH] network-bridge script support for multipleexternal interfaces

> The attached patch allows the network-bridge script to be 
> used to generate multiple bridges corresponding to different 
> physical interfaces. It adds a new parameter, "virtnum", used 
> to refer both to the loopback interface to be used and to set 
> defaults regarding the physical interface and bridge name.
> 
> Thus, if one wishes to start xen-br0 on eth0 and xen-br1 on 
> eth1, one need only call:
> 
> network-bridge start ## virtnum is 0 by default 
> network-bridge start virtnum=1
We need a way of controlling the set of paramters that network-bridge is
invoked with from xend-config.sxp. I''d be inclined just to list the
whole command line.

I''m not sure I like the idea of specifying ''virtnum''.

I think it might be better to be able to tell xend to invoke the script
multiple times e.g. :

(network-script "network-bridge netdev=eth0 bridge=xenbr0;
network-bridge netdev=eth1 bridge=xenbr1")

xend will need to insert "start"/"stop" into these lines as
appropriate.
Possibly we should modify the scripts to take foo=bar parameters before
or after the start/stop command. 

NB: Note that I''m using xenbr0 rather than xen-br0. We need to remove
the hyphen as it plays havoc with certain vendor''s scripts.

What do you think? Could you knock up a patch?
> ...well, that and set loopback.nloopbacks=2 in the Dom0 
> kernel parameters.
I think we should create two devices by default. They don''t cost much
and you can''t buy servers with <2 interfaces.


Thanks,
Ian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Ian Pratt wrote:
>>The attached patch allows the network-bridge script to be 
>>used to generate multiple bridges corresponding to different 
>>physical interfaces. It adds a new parameter, "virtnum", used 
>>to refer both to the loopback interface to be used and to set 
>>defaults regarding the physical interface and bridge name.
>>
>>Thus, if one wishes to start xen-br0 on eth0 and xen-br1 on 
>>eth1, one need only call:
>>
>>network-bridge start ## virtnum is 0 by default 
>>network-bridge start virtnum=1
> 
> We need a way of controlling the set of paramters that network-bridge is
> invoked with from xend-config.sxp. I''d be inclined just to list
the
> whole command line.
You mean list the whole command line when you display what parameters 
you were called with? Only issue with that is that it doesn''t show what
we defaulted to, presuming that we did any defaulting. Or do you mean 
listing all the parameters during invocation? I pretty much do that 
myself -- I actually use it as follows:

network-bridge start bridge=xenbr1 netdev=eth1 virtnum=1

...however, having reasonable defaults for parameters the user chooses 
not to supply is a Good Thing.
> I''m not sure I like the idea of specifying
''virtnum''.
What would you do instead? Search for the first veth* that isn''t up? 
Can''t say I like that as much.

Note, btw, that I *am* assuming that network-bridge gets called multiple 
times -- if you want both xen-br0 and xen-br1 on eth0 and eth1 as in my 
example above, you need two calls.
> I think it might be better to be able to tell xend to invoke the script
> multiple times e.g. :
> 
> (network-script "network-bridge netdev=eth0 bridge=xenbr0;
> network-bridge netdev=eth1 bridge=xenbr1")
...and need to have the script search for the veth* and vif* devices 
itself, or base their names on the number appended to the netdev device? 
I don''t really like that.
> xend will need to insert "start"/"stop" into these
lines as appropriate.
> Possibly we should modify the scripts to take foo=bar parameters before
> or after the start/stop command. 
> 
> NB: Note that I''m using xenbr0 rather than xen-br0. We need to
remove
> the hyphen as it plays havoc with certain vendor''s scripts.
Yes; I use xenbr0/xenbr1 myself, but did "xen-br*" for the patch so
that
it doesn''t do more than one thing.
> What do you think? Could you knock up a patch?
We probably ought to come to a decision on behaviour first.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel