Re: [Xen-devel] Network-bridge script with bonding and vlan

[Ewan Mellor <ewan@xxxxxxxxxxxxx>]

On Fri, Oct 21, 2005 at 02:16:49PM +1300, Greg Brackley wrote:

> ----- Original Message ----- 
> From: "Ewan Mellor" <ewan@xxxxxxxxxxxxx>
> >Firstly, I would wait for the new network-bridge script to be pushed, or 
> >at
> >the very least use the one that Kurt Garloff posted to the list yesterday.
> 
> I've been following that thread. From my limited understanding of the xen 
> bridged networking I see it decomposed into three areas:
> 
> 1. The hardware driver support
> 2. The bridge
> 3. The xen virtual device support (backend-front driver)
> 
> In a trivial case, the hardware support might just have eth0. In my case I 
> want to have eth0, eth1, bond0, and several eth0.xx VLAN interfaces.  I 
> understand most people are configuring these with their distribution 
> specific network support.
> 
> In the trivial case, the bridge is xenbr0 (was xen-br0).  In my case I 
> think I want one bridge per domain (including one for xen0). I'm trying to 
> use FC4 network configuration to do this, because I don't see how the xen 
> script helps do this. I see that I need to create a bridge per domain (and 
> the standard scripts assume one per machine).

The new script allows for one bridge per outgoing interface, I think, so in
your case one bridge per VLAN ought to be possible.  Why do you need one
bridge per domain?  What are you bridging in this case?  The topology we use
uses a bridge to plex all of the guests onto a specific outgoing interface --
so what are you bridging to require one per domain?

> In the trivial case the xen support is vif0.0->veth0, and vifN.0->eth0 
> (where N is a non-zero domain number).

Do your arrows refer to incoming packets?  If so, I think that is right,
though veth0 is renamed to eth0 now, so that dom0 sees a "normal" eth0
interface.

> The scripts seem to treat xen0 as a special case, and I'm not sure why.

Domain 0 is the privileged domain i.e. the one that manages the creation of
other domains.  It comes up on boot, and is where things like the script in
question are running.  That is why it is a special case.  Also, it is arranged
so that dom0's interface appears to have the MAC address of the underlying
NIC -- you can't do this with the guest domains, of course.

> In a production system (c.f. a development system) I feel it would be 
> desirable to be able to mix and match the three different areas. It seems 
> that the scripts assume a fixed xen0 configuration (of 1 interface and one 
> bridge, and one vif),

Now, N interfaces, N bridges, N vifs for domain 0 (where N is the same in each
case).

> and don't allow the running of vif script for domain 0.

No, this wouldn't really make sense, and would be difficult to arrange.

> In the configuration that I'm trying to get going, I am not renaming veth0 
> in domain0. Instead I just treat veth0 as the main interface for that 
> domain, and give it an IP address and route to it. Is that bad idea?  By 
> not doing renaming of interfaces, I am trying to avoid having to copy over 
> addresses.

I've no idea whether that makes sense, but why are you trying to do it?


The bottom line, I think, is that Xen does not try to do everything with
network configuration.  We are happy to help, and happy to provide example
scripts for simple configurations, but I don't think that we will ever try to
detect every distro, and configure every convoluted VLAN configuration.
That's why the network handling is scripted -- so that you can get your hands
dirty if needs be.  Now I'm not saying that I wash my hands of you!  But if
you really do need a topology that's way beyond the capabilities of the
network-bridge script, then you ought to think about writing a different
script rather than try and shoehorn the wrong things in the wrong places.
Maybe we'll accept your script into the repository if it's clean and general
enough, but whether you maintain it or we do, I don't think that it
(necessarily) belongs in network-bridge.

Ewan.

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