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". >
