cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus <shadow...@gmail.com>
Subject Re: [ACS44]cherry-pick: dfb59cd6cc0292a88cb619e53f34cdb713879ffd
Date Tue, 03 Jun 2014 21:26:03 GMT
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.su@citrix.com> wrote:

> Need to cherry pick it into 4.3.1 also.
>
> > -----Original Message-----
> > From: Edison Su [mailto:Edison.su@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".
>

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