[netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces

David Lutterkort lutter at redhat.com
Fri Jun 19 17:44:25 UTC 2009


On Fri, 2009-06-19 at 17:39 +0100, Daniel P. Berrange wrote:
> 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

Yes, that's what I was getting at in one of my mails yesterday. All
subordinate interfaces, except for VLAN's, are defined by including them
at the one place where they are used (e.g., inside <bridge/>); when
using a VLAN as a subordinate interface, the VLAN interface itself is
defined where it is used, but the interface underlying the VLAN
interface is only referred to.

Basically, by treating VLAN's akin to symbolic links, we do a have a
clean tree structure for interface nesting.

> 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

Agreed - these examples are in line with what I had in mind. The format
for VLAN's is a bit problematic still; you have
        
> <interface type="vlan">
>          <name>vlan42</name>
>          <vlan tag='42'>
>            <interface type='ethernet'>
>              <name>eth0</name>
>            </inteface>
>          </vlan>
>       </inteface>

but you can't really assign an arbitrary name to a VLAN interface; it's
also not necessary to indicate the type of the base interface.
Therefore, for VLAN's, I would use the much more concise notation

        <interface type="vlan" device="eth0" tag="42"/>
        
David





More information about the libvir-list mailing list