[netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
Daniel P. Berrange
berrange at redhat.com
Fri Jun 19 16:39:57 UTC 2009
On Thu, Jun 18, 2009 at 05:53:59PM +0000, David Lutterkort wrote:
> On Thu, 2009-06-18 at 18:06 +0100, Daniel P. Berrange wrote:
>
> > VLANs are tricky, because you can define VLANs on a physical
> > inteface or a bond interface, and you then may want to also
> > add a bridge on top of a VLAN, eg take 2 physical NICs, eth0
> > and eth1, here are some possible combes
> >
> > - One NIC for storage, another for host mgmt, and put
> > the guests all on VLANs
> >
> > eth0 -> br0 IP addr used for storage
> > eth1 -> br1 IP addr used for host mgmt
> > eth1.42 -> br1.42 IP addr, used to talk to guests
> > eth1.43 -> br1.43 No IP, guest traffic only
> > eth1.44 -> br1.44 No IP, guest traffic only
>
> I don't think that's the right notation, don't you mean 'eth1.42 -> br2'
> etc. ?
Yes that was a mistake.
> > I think the currently approach of modelling bond, bridges and NICs
> > makes this a little hard, particularly if the netcf API only exposes
> > 'connections' and not interfaces, because some of these setups are
> > not really connections, only building blocks for 'n' other connections
>
> 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>
Here is a proposal that is a compromise between the single hierarchy, and
completely flat. The break point is only introduced where VLANs appear,
which is acceptable because when defining VLAns, you don't need to define
the underlying inteface at the same time - it can exist in its own right
ahead of time. Only nic+bond or nics+bridge or nic+bond+bridge need to
be atomically defined at once.
There are 4 possible arrangements of physical NIC, bond and vlan,
each of which can use a bridge. This gives 8 total configs
1. Physical NIC
2. Physical NIC + bridge
3. Physical NIC + bond
4. Physical NIC + bond + bridge
5. Physical NIC + vlan
6. Physical NIC + vlan + bridge
7. Physical NIC + bond + vlan
8. Physical NIC + bond + vlan + bridge
Of those, the last 4 are the 'hard' ones since there are 'n'
source points and 'm' end points. The end points are the core
object the public API wants to deal in.
The first 4 configs can all be expressed in terms of a single
interface object, since there is a single end point. The last
4 configs suggest one base interface followed by 'n' additional
interfaces, with the break being where the 1 -> 'n' relation
appears. The idea of having the intermediate 'end point' appear
as an interface object in the public API makes sense, because
these can exist in their own right, before VLANs are added.
Only bonds/bridges need to be defined as a single entity.
So the possible configs would appear as XML like
1. Physical NIC
<interface type='ethernet'>
<name>eth0</name>
</interface>
2. Physical NIC + bridge
<interface type="bridge">
<name>br0</name>
<bridge>
<interface type='ethernet'>
<name>eth0</name>
</interface>
</bridge>
</interface>
3. Physical NIC + bond
<interface type="bond">
<name>bond0</name>
<bond>
<interface type='ethernet'>
<name>eth0</name>
</interface>
<interface type='ethernet'>
<name>eth1</name>
</interface>
</bond>
</interface>
4. Physical NIC + bond + bridge
<interface type="bridge">
<name>br0</name>
<bridge>
<interface type="bond">
<name>bond0</name>
<bond>
<interface type='ethernet'>
<name>eth0</name>
</interface>
<interface type='ethernet'>
<name>eth1</name>
</interface>
</bond>
</interface>
</bridge>
</interface>
5. Physical NIC + 2 * vlan
<interface type="ethernet">
<name>eth0</name>
</interface>
<interface type="vlan">
<name>vlan42</name>
<vlan tag='42'>
<interface type='ethernet'>
<name>eth0</name>
</inteface>
</vlan>
</inteface>
<interface type="vlan">
<name>vlan48</name>
<vlan tag='48'>
<interface type='ethernet'>
<name>eth0</name>
</inteface>
</vlan>
</inteface>
6. Physical NIC + 2 * vlan + bridge
<interface type="ethernet">
<name>eth0</name>
</interface>
<interface type='bridge'>
<name>br42</name>
<bridge>
<interface type="vlan">
<name>vlan42</name>
<vlan tag='42'>
<interface type='ethernet'>
<name>eth0</name>
</inteface>
</vlan>
</inteface>
</bridge>
</interface>
<interface type='bridge'>
<name>br42</name>
<bridge>
<interface type="vlan">
<name>vlan42</name>
<vlan tag='42'>
<interface type='ethernet'>
<name>eth0</name>
</inteface>
</vlan>
</inteface>
</bridge>
</interface>
7. Physical NIC + bond + 2 * vlan
<interface type="bond">
<name>bond0</name>
<bond>
<interface type='ethernet'>
<name>eth0</name>
</interface>
<interface type='ethernet'>
<name>eth1</name>
</interface>
</bond>
</interface>
<interface type="vlan">
<name>vlan42</name>
<vlan tag='42'>
<interface type='bond'>
<name>bond0</name>
</inteface>
</vlan>
</inteface>
<interface type="vlan">
<name>vlan48</name>
<vlan tag='48'>
<interface type='bond'>
<name>bond0</name>
</inteface>
</vlan>
</inteface>
8. Physical NIC + bond + 2 * vlan + bridge
<interface type="bond">
<name>bond0</name>
<bond>
<interface type='ethernet'>
<name>eth0</name>
</interface>
<interface type='ethernet'>
<name>eth1</name>
</interface>
</bond>
</interface>
<interface type='bridge'>
<name>br42</name>
<bridge>
<interface type="vlan">
<name>vlan42</name>
<vlan tag='42'>
<interface type='bond'>
<name>bond0</name>
</inteface>
</vlan>
</inteface>
</bridge>
</interface>
<interface type='bridge'>
<name>br42</name>
<bridge>
<interface type="vlan">
<name>vlan42</name>
<vlan tag='42'>
<interface type='bond'>
<name>bond0</name>
</inteface>
</vlan>
</inteface>
</bridge>
</interface>
Of course, you could actually have a hybrid of 7/8, where some vlans
where bridged, and others direct endpoints. That's trivally handled
there of course.
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 :|
More information about the libvir-list
mailing list