Your commit 5e80e5d33d9a295b91cdba9377f52d9d963d802a actually does the fix mgmt server side and makes this patch irrelevant, as we are now passing a proper vlan:// in this command. However, Daan's fix will make the data in the db consistent for upgraders and fresh installers, which will fix this and all other bugs like it.
On Tue, Jun 3, 2014 at 3:26 PM, Marcus <shadow...@gmail.com> wrote: > I don't think that's the root cause, but it shouldn't hurt. The root cause > seems to be that we're telling the agent that the broadcastUri for the vlan > is 'vlan://100' (as reported by Anders), but the IpAssocCmd passes > broadcast URI as just '100'. This is a bit messy to workaround the mgmt > server inconsistency in the agent, but it won't hurt. Fixing the > inconsistency would be better, and Daan has applied a patch that should > blanket fix that during the 4.4 upgrade. > > > On Tue, Jun 3, 2014 at 2:44 PM, Edison Su <edison...@citrix.com> wrote: > >> Need to cherry pick it into 4.3.1 also. >> >> > -----Original Message----- >> > From: Edison Su [mailto:edison...@citrix.com] >> > Sent: Tuesday, June 03, 2014 1:37 PM >> > To: dev@cloudstack.apache.org >> > Subject: [ACS44]cherry-pick: dfb59cd6cc0292a88cb619e53f34cdb713879ffd >> > >> > CLOUDSTACK-6464: >> > The root cause is that, in 3.0.x, if guest network is >> "vlan://untagged", then >> > kvm agent will use whatever value in "private.network.device", while in >> 4.x, >> > kvm agent will use "guest.network.device". So if both value are not the >> same >> > in the agent.properties, then kvm agent will use incorrect bridge to >> create vif. >> > The fix will be, kvm agent code needs to honor traffic type passed down >> > from mgt server in startcommand, in case of "vlan://untagged". >> > >
