[netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
Daniel Veillard
veillard at redhat.com
Fri Jun 19 17:05:23 UTC 2009
On Fri, Jun 19, 2009 at 05:39:57PM +0100, Daniel P. Berrange wrote:
> 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.
Hum, since an XML can only have one single root, I suggest to put a
wrapper around multiple definitions and if you call it <interfaces>
that looks a bit like my own proposal but more recursive.
I still suggest to change having name as an attribute on the
<interface> tags because it allows to easilly do the ID/IDREF matching.
for references.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel at veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
More information about the libvir-list
mailing list