RE: [PATCH] network-bridge script support for multipleexternal interfaces

RE: [PATCH] network-bridge script support for multipleexternal interfaces

[Ian Pratt]

> 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

Re: [PATCH] network-bridge script support for multipleexternal interfaces

[Charles Duffy]

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.

RE: [PATCH] network-bridge script support for multipleexternal interfaces

[Ian Pratt]

> > 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.

I'd settle for being able to specify:

(network-script "network-bridge netdev=eth0 bridge=xenbr0
virtnum=0","network-bridge netdev=eth1 bridge=xenbr1 virtnum=1")

[not totally convinced about the naming of virtnum. vifnum?]

[What's the correct sxp syntax for specifying a list of strings?]


Ian

Re: [PATCH] network-bridge script support for multipleexternal interfaces

[Charles Duffy]

Ian Pratt wrote:
> I'd settle for being able to specify:
> 
> (network-script "network-bridge netdev=eth0 bridge=xenbr0
> virtnum=0","network-bridge netdev=eth1 bridge=xenbr1 virtnum=1")

Thus far I haven't done any messing with xend's code, and am not 
entirely sure I want to. This patch was intended *only* to include an 
updated helper, such that xend could later be extended by someone else 
to actually call that helper multiple times. Personally, to call the 
helper more than once, I've just written some new init scripts.

I'm willing to consider poking at xend, but *only* if someone who 
actually owns it says "okay, I'll merge a patch that does that if you 
implement it *like so*". Even if that means I'm doing more work to do it 
the maintainer's way, having specs from upstream means there's a much 
better chance of what I'm doing actually getting merged.

> [not totally convinced about the naming of virtnum. vifnum?]

I agree that vifnum is better.

> [What's the correct sxp syntax for specifying a list of strings?]

If they're being adequately lispy and my memory doesn't deceive me, the 
strings are just separated by spaces... as in (foo "bar" "baz" "qux") 
<to call foo w/ arguments bar, baz and qux>, '("foo" "bar" "baz") <to 
return a list with foo, bar and baz as contents>, or such.