On Thu, Jun 18, 2009 at 07:05:29PM +0100, Daniel P. Berrange wrote:
> On Thu, Jun 18, 2009 at 05:53:59PM +0000, David Lutterkort wrote:
> >
> > For that, you'd nest them where they are used, e.g. one connection to
> > establish the base ethernet interface (that might not exist at all):
> >
> > <interface type="ethernet" startmode="none">
> > <name>eth0</name>
> > <mtu size="1492"/>
> > <mac address="aa:bb:cc:dd:ee:ff"/>
> > <dhcp peerdns="no"/>
> > </interface>
> >
> > and one for the bridge with a vlan enslaved:
> >
> > <interface type="bridge" startmode="onboot">
> > <name>br0</name>
> > ...
> > <bridge stp="off">
> > <interface type="vlan" device="eth0" tag="42"/>
> > </bridge>
> > </interface>
> >
> > Similarly, a bond enslaved to a bridge, together with a vlan on that
> > bond also enslaved to the bridge would look like
> >
> > <interface type="bridge" startmode="onboot">
> > <name>br0</name>
> > ...
> > <bridge stp="off">
> > <interface type="bond">
> > <name>bond0</name>
> > <bond mode="active-backup">
> > <interface type="ethernet">
> > <name>eth1</name>
> > </interface>
> > <interface type="ethernet">
> > <name>eth0</name>
> > </interface>
> > </bond>
> > </interface>
> > <interface type="vlan" device="bond0" tag="42"/>
> > </bridge>
> > </interface>
>
> I think this is a really unpleasant format to deal with. IMHO there should
> not be nesting for <bridge>/<bond> tags. They should just refer to their
> slave device by name. So that last example would be better shown as a set
> of independant intefaces
Rationalizing the reason why I don't like this format. The relationship of
NICs essentially forms a DAG. This format is attempting to define a tree
from the POV of a single leaf node. So to deal with multiple leaf nodes
you either end up having signficantly overlapping configs between leaves,
or have one leaf defining the main branch, and other leaves only defining
sub-branches. I don't think either is really satisfactory, and can be
avoiding by defining a flat list of interfaces, and encoding the parent/
child relationships in each. An application using this, still retains the
flexibility to display the information in the structure that is most
suitable for its needs, be it paths from the POV of a leaf, paths from
the POV of a root, the entire tree in one, or flat lists, or some other
hybrid.
> <interface type='bond'>
> <name>bond0</name>
> <bond mode="active-backup">
> <interface name='eth0'/>
> <interface name='eth1'/>
> </bond>
> </interface>
So this shows children, while the XML for the physical interface could
show the inverse.
<interface type='physical'>
<name>eth0</name>
<master>
<interface name='bond0'/>
</master>
</interface>
The API contract might wish to specify the order for defining new
interfaces, eg whether to require the bond0 to be defined first
and then physical interfaces added, whether physical members must
be defined first & then the bond, or whether creation of the bon0
automatically implies that interfaces for eth0/eth1 appear in the
list.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list