cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sheng Yang <>
Subject Re: [RFC][FS]PVLAN for isolation within a VLAN
Date Thu, 18 Apr 2013 00:49:23 GMT
In fact that's the requirement for this design. We need this very strict
restriction to implement isolation for the VMs. PVLAN is the way we used to
approach this requirement.

Community VLAN is more like normal VLANs, which shared the information in
between. That's not of our concern currently.

The main work for this would be add ability to OVS(which controlled by
CloudStack) to setup flow-table to achieve the same effect of PVLAN, as you
can see in the "design" section, which I've detailed the way of doing it.


On Wed, Apr 17, 2013 at 2:18 AM, Murali Reddy <>wrote:

> Sheng,
> Thanks for the FS. Couple of points in FS that made me curious of the
> rational behind it.
> Why do you want to all the end user VM's (except for DHCP server VM) in
> shared network to be connected only to I-port's. This means that even VM's
> of same user can not talk to each other, right? Is'nt it too restrictive?
> How about having community secondary VLAN per user with which they gets
> the isolation and their VM's can talk to each other? Only down side is
> there is additional effort of managing pool of secondary community VLAN's
> or there are other challenges?
> Approach proposed for Xen and KVM which does not support PVLAN is
> interesting. So do you expect the admin to setup these flows on each
> KVM/Xen hypervisor? Or CloudStack will be responsible for set-up of flow
> tables as well?
> Thanks.
> On 17/04/13 5:01 AM, "Sheng Yang" <> wrote:
> >Hi all,
> >
> >I am current working on a new mechanism to archive isolation for advance
> >shared network. It took advantage of PVLAN feature of Cisco switch, to
> >achieve isolation using a simpler way.
> >
> >Here is the FS. You probably need to read references(in the link) to get
> >an
> >idea of PVLAN first.
> >
> >
> >
> >Thanks!
> >
> >--Sheng
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message