cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <>
Subject Re: same vlan on different nics
Date Thu, 15 Nov 2012 21:01:42 GMT
That's fine, I can change the patch referenced for CLOUDSTACK-226 so that
it doesn't apply to KVM, and then changing the unique index will allow
things to work for KVM.

 If the only problem is the bridge naming, as was changed with KVM
(previously the same vlan on two different physical nics would end up with
the same bridge name which obviously wouldn't work), then this is fine, and
the bridge naming can be reviewed for Xen or other hypervisors as desired.
I just wanted to do a sanity check and make sure there wasn't any other
technical reason why someone couldn't choose to have two or more
independent networks on their physical interfaces. Or something already
known in the code that would break due to this.

On Thu, Nov 15, 2012 at 1:37 PM, Prachi Damle <>wrote:

> Chiradeep/Alex,
> Can we use the same vlan on two different physical networks in one
> datacenter?
> If it is possible to share the same vlan on different physical networks of
> the datacenter, we could update the DB unique constraint to (`vnet`,
> `data_center_id`, 'physical_network_id') as Marcus suggests.
> But if vnet ranges need to be separate, maybe we need some KVM specific
> solution...
> -Prachi
> -----Original Message-----
> From: Alena Prokharchyk
> Sent: Thursday, November 15, 2012 11:51 AM
> To:; Prachi Damle
> Subject: Re: same vlan on different nics
> Marcus,
> Prachi would be the best person to answer this question as she added the
> constraint to create-schema.sql:
> 8836a08e (prachi                    2011-11-08 11:23:37 -0800  658)
> CONSTRAINT `fk_op_dc_vnet_alloc__physical_network_id` FOREIGN KEY
> (`physical_network_id`) REFERENCES `physical_network'
> Commit id is 8836a08e.
> -Alena.
> On 11/15/12 7:40 AM, "Marcus Sorensen" <> wrote:
> >
> >
> >It looks like this was fixed (11fe086adab8e790018343252ed08aac9a27b1c6)
> >by making sure that a particular vlan range can only exist on one
> >physical network. Is there any technical reason for this? It looks like
> >the fix worked around the unique key restriction in the database
> >schema, is that the only limiting factor? We recently changed the
> >naming scheme of KVM bridges to allow the same vlan to be used on
> >different physical networks, so I can make the solution KVM specific.
> >
> >I'm just not sure why this limitation was created in the first place
> >(the schema, not the fix)  and want to gather some info before doing too
> much.
> >I'd rather just make the key unique to vlan on physical network and let
> >the individual doing the implementation decide if they want to do
> >multiple
> >layer2 domains to their boxes or not.
> >

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