[libvirt] 802.1q vlan-tagging support for libvirt

[David Lutterkort]

On Tue, 2009-04-07 at 18:39 -0300, Klaus Heinrich Kiwi wrote:
> 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)

Yes, I think that's how it should work; it would also mean that you'd
first set up eth0 as a separate interface, and new bridge/vlan interface
combos afterwards. AFAIK, for the bridge, only bootproto=none would make
sense.

> The things that concerns me the most are:
>  1) How scalable this really is

I don't know either ... we'll find out ;)

>  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.

The reason we are creating all those bridges isn't the VLAN's - it's
that we want to share the same physical interface amongst several
guests. And I don't know of another way to do that.

> 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?

You can use it directly, I just don't know how else you would share it
amongst VM's without a bridge.

David