[libvirt] 802.1q vlan-tagging support for libvirt

[Klaus Heinrich Kiwi]

On Thu, 2009-04-02 at 16:34 -0700, David Lutterkort wrote:
> Hi Klaus,
> 
> On Thu, 2009-04-02 at 15:50 -0300, Klaus Heinrich Kiwi wrote:
> > My understanding is that libvirt would use vconfig to create tagged
> > interfaces, while using a physical interface as trunk (e.g., eth0 is the
> > trunk, eth0.20 the interface with the '20' vlan tag).
> > 
> > Then it would add the tagged interface (eth0.20) to a bridge with the
> > guest virtual interface.

I was thinking about the semantics I described above. It ultimately
means that we'll have a bridge for each VLAN tag that crosses the trunk
interface. So for example if guests A, B and C are all associated with
VLAN ID 20, then:

eth0 -> eth0.20 -> br0 -> [tap0, tap1, tap2]

(where tap[0-3] are associated with guests A, B, C respectively)

Adding a new guest to a VLAN would mean searching the host system and
check if there is already a bridge running on that VLAN ID. Create a new
one if needed, or use the existing one.

The things that concerns me the most are:
 1) How scalable this really is
 2) The semantics are really different from how physical, 802.1q-enabled
switches would work.

Because (2) really creates new switches for each new VLAN tag, I wonder
how management would be different from what we have today with physical
switches (i.e., defining a port with a VLAN ID, assigning that port to a
physical machine) - unless we hide it behind libvirt somehow.

Still, things like SNMP-management can have issues with such approach
(snmp-based network managers would go crazy identifying several
switches/bridges per box - not really useful from a management PoV).

Are there other options? Since a tagged interface like eth0.20 is kind
of a virtual interface itself, would it be appropriate to use those
directly?

Or maybe extending the existing bridging code to be 802.1q-aware?

 Thanks,

 -Klaus



> as Dan said, the actual functionality will be provided by netcf[1]
> 
> VLAN is very high on the list of things that need to be done next - and
> any help with that would be much appreciated ;)
> 
> David
> 
> [1] https://fedorahosted.org/netcf/
> 
-- 
Klaus Heinrich Kiwi <klausk at linux.vnet.ibm.com>
Linux Security Development, IBM Linux Technology Center