actually this specific commit isn't the one I thought it was. This one is a relatively innocuous catch-all that forces things to the guest bridge if all else fails. I'm not sure it will configure things 'right', but it will help from things going on a protected network like mgmt if things fail.
On Wed, Jun 4, 2014 at 1:32 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > I read here that this commit is not needed. Can we think of scenarios > where it is? > > On Tue, Jun 3, 2014 at 11:29 PM, Marcus <shadow...@gmail.com> wrote: > > 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". > >>> > >> > >> > > > > -- > Daan >
