incubator-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 Mon, 19 Nov 2012 22:07:08 GMT
One question, are the schema-XtoX.sql files generated after/around code
freeze from the difference in the old and current schema files, or are they
manually created as schema changes occur?

On Thu, Nov 15, 2012 at 2:01 PM, Marcus Sorensen <>wrote:

> 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