This sounds like it can be modeled as multiple physical networks? That is, each "outer" vlan (400, 401, etc) is a separate physical network in the same zone. That could work, although it is probable that the zone configuration API bits prevent more than 4k VLANs per zone (that can be changed to per physical network).
As long as communication between guests on different physical networks happens via the public network, it should be Ok. I'd like to see the patch. Thanks On 10/12/12 1:09 AM, "Marcus Sorensen" <shadow...@gmail.com> wrote: >Guys, in looking for a free and scalable way to provide private networks >for customers I've been running a QinQ setup that has been working quite >well. I've sort of laid the groundwork for it already in changing the >bridge naming conventions about a month ago for KVM(to names that won't >collide if the same vlans is used twice on different phys). > >Basically the way it works is like this. Linux has two ways of creating >tagged networks, the eth#.# and the less used vlan# network devices. I >have >a tiny patch that causes cloudstack to treat vlan# devs as though they >were >physical NICs. In this way, you can do something like physical devices >eth0,eth1,and vlan400. management traffic on eth0's bridge, storage on >eth1.102's bridge, maybe eth1.103 for public/guest, then create say a >vlan400 that is tag 400 on eth1. You add a traffic type of guest to it and >give it a vlan range, say 10-4000. Then you end up with cloudstack handing >out vlan400.10, vlan400.11, etc for guest networks. Works great for >network >isolation without burning through a bunch of your "real" vlans. In the >unlikely event that you run out, you just create a physical vlan401 and >start over with the vlan numbers. > >In theory all-you-can-eat isolated networks without having to configure >hundreds of vlans on your networking equipment. This may require >additional >config on any upstream switches to pass the double tags around, but in >general from what I've seen the inner tags just pass through on anything >layer 2, it should only get tricky if you try to tunnel, route or strip >tags. > >This is especially nice with system VM routers and VPC (cloudstack takes >care of everything), but admittedly external routers probably will have >spotty support for being able to route double tagged stuff. I'm also a bit >afraid that if I were to get it merged in that it would just become this >undocumented hack thing that few know about and nobody uses. So I'm >looking >for feedback on whether this sounds useful enough to commit, how it should >be documented, and whether it makes sense to hint at this in the GUI >somehow.
