Re: [netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
On Thu, 2009-06-18 at 19:05 +0100, Daniel P. Berrange wrote:
> 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.
There's two reasons why I prefer that rather than splitting everything
into multiple standalone <interface> tags:
1. When as many components of the overall interface/connection are
in one place, more validation can be done in RelaxNG, i.e.
statically
2. Because of this, it is easier for application writers to test
and validate the XML they generate - most issues can be caught
by validating against the RelaxNG, and fewer issues depend on
doing things in the right order (for example, with the nested
format, you cna never get into a situation where you enslave an
undefined bond into a bridge)
I assume what you find unpleasant is that when you generate the XML you
need to embed one interface in another, though that seems to me mostly
an issue in what order you do your sprintf's.
IMHO there should not be nesting for <bridge>/<bond>
tags.
For <bond>, there's nothing to worry about, since all you can add to a
bond are physical interfaces (since all the possible nesting gets
confusing, I drew a little picture)
vlans can't contain their underlying device, since there can be many
vlan's used in multiple interfaces for a device. This is the one place
in the format I suggested where we need an external reference check: we
need to make sure that the interface underlying the vlan is already
configured.
Bridges, of course, are hopeless, since they are omnivorous. But again,
with the nested format, all sanity checking can happen in RelaxNG,
except for the referential integrity of vlan's.
They should just refer to their
slave device by name. So that last example would be better shown as a set
of independant intefaces
<interface type='bond'>
<name>bond0</name>
<bond mode="active-backup">
<interface name='eth0'/>
<interface name='eth1'/>
</bond>
</interface>
This requires that you check that the interfaces named there are
physical NIC's at runtime.
<interface type='vlan'>
<name>bond0.42</name>
<vlan tag='42'>
<interface name='bond0'>
</bridge>
</interface>
I don't think there's a good case for setting the name of a VLAN
explicitly. vconfig let's you choose from one of four naming modes, but
I am not even sure it's worth exposing those in the XML.
<interface type="bridge"
startmode="onboot">
<name>br0</name>
...
<bridge stp="off">
<interface name="bond0.42"/>
</bridge>
<interface>
At this point, you need to check that bond0.42 is defined, without any
address setup.
If you added more vlans, then they just appear as more interfaces at
the top level
I would really like to stick to a model where toplevel interfaces are
the ones that aren't contained in other interface definitions anymore.
David
Attachments:
- nesting.png (image/png — 21.3 KB)
