Re: [libvirt] 802.1q vlan-tagging support for libvirt

On Thu, 2009-04-02 at 16:34 -0700, David Lutterkort 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) 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 -- Klaus Heinrich Kiwi <klausk(a)linux.vnet.ibm.com&gt; Linux Security Development, IBM Linux Technology Center