Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of shadowsor@gmail.com designates
 209.85.212.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CALFpzo4CHpKJDRCSCLFH0wdJ+2jotJn0OqWDqAQBWdos+bGtTA@mail.gmail.com>
References: 
 <CALFpzo4T1MUALRk80H7cpYCy-ZeHzRMFR4K_1OtEcZSexLeupA@mail.gmail.com>
	<C66C814C1ABFA8449FF65CB44953A8B4012CBB65BC22@SJCPMAILBOX01.citrite.net>
	<CALFpzo4CHpKJDRCSCLFH0wdJ+2jotJn0OqWDqAQBWdos+bGtTA@mail.gmail.com>
Date: Thu, 30 Aug 2012 11:47:09 -0600
Message-ID: 
 <CALFpzo48wP_Z7QWZOsR+tpA05iROzb+3Uc85ejRJs0kHG3Pgrg@mail.gmail.com>
Subject: Re: VPC for KVM (was VM router spawning multiple public nics)
From: Marcus Sorensen <shadowsor@gmail.com>
To: Edison Su <Edison.su@citrix.com>
Cc: "cloudstack-dev@incubator.apache.org"
 <cloudstack-dev@incubator.apache.org>, Anthony Xu <Xuefei.Xu@citrix.com>,
	Kelven Yang <kelven.yang@citrix.com>,
	Vijayendra Bhamidipati <vijayendra.bhamidipati@citrix.com>
Content-Type: text/plain; charset=ISO-8859-1

Ok, I think I get it. For example when I'm looking at IpAssocCommand
it calls _virtRouterResource.assignPublicIpAddress to actually run the
sh.  So with SetupGuestNetworkCommand, I'll create that in
LibvirtComputingResource, and within that I'll make a call to
VirtualRoutingResource to do the work... is that right?

On Thu, Aug 30, 2012 at 11:31 AM, Marcus Sorensen <shadowsor@gmail.com> wrote:
> Just want to clarify:
>
> "We can add implementation of
> SetupGuestNetworkCommand/SetNetworkACLCommand/SetSourceNatCommand/Site2SiteVpnCfgCommand
> in VirtualRoutingResource."
>
> So the Xen implementation of SetupGuestNetworkCommand is in
> CitrixResourceBase.java, and the VMware one is in VmwareResource.java,
> but you're saying I should put an implementation of these in
> VirtualRoutingResource.java for KVM? Sorry, still trying to piece
> together how everything relates.
>
> On Thu, Aug 30, 2012 at 10:42 AM, Edison Su <Edison.su@citrix.com> wrote:
>> Yes, it is.
>>
>>> -----Original Message-----
>>> From: Marcus Sorensen [mailto:shadowsor@gmail.com]
>>> Sent: Thursday, August 30, 2012 8:45 AM
>>> To: Edison Su
>>> Cc: cloudstack-dev@incubator.apache.org; Anthony Xu; Kelven Yang;
>>> Vijayendra Bhamidipati
>>> Subject: VPC for KVM (was VM router spawning multiple public nics)
>>>
>>> I notice there's also an 'IpAssocVpcCommand', I'm assuming that should
>>> be added to the list?
>>>
>>> On Wed, Aug 29, 2012 at 6:37 PM, Edison Su <Edison.su@citrix.com> wrote:
>>> > You can find the VPC reference implementation from
>>> CitrixResourceBase.java, which is the implementation for Xenserver.
>>> Just take a look at how the VPC related commands are implemented.
>>> > Take SetNetworkACLCommand as an example:
>>> > The function execute(SetNetworkACLCommand cmd) in citrixResourceBase:
>>> > 1. parse SetNetworkACLCommand
>>> > 2. call scripts/vm/hypervisor/xenserver/vmops, function routerProxy
>>> > 3. routerproxy will call scripts/network/domr/router_proxy.sh
>>> > 4. router_proxy.sh will login into router vm, execute a shell script
>>> inside router VM to program rules.
>>> >
>>> > In KVM, we can directly call router_proxy.sh or directly login into
>>> router vm, we just need to prepare the parameters for this script.
>>> > The reference code is in VirtualRoutingResource.java, all the network
>>> related command(extended from NetworkElementCommand) will be redirected
>>> to VirtualRoutingResource.
>>> > We can add implementation of
>>> SetupGuestNetworkCommand/SetNetworkACLCommand/SetSourceNatCommand/Site2
>>> SiteVpnCfgCommand in VirtualRoutingResource.
>>> >
>>> >
>>> >> -----Original Message-----
>>> >> From: Marcus Sorensen [mailto:shadowsor@gmail.com]
>>> >> Sent: Wednesday, August 29, 2012 4:34 PM
>>> >> To: cloudstack-dev@incubator.apache.org
>>> >> Cc: Edison Su; Anthony Xu; Kelven Yang; Vijayendra Bhamidipati
>>> >> Subject: Re: VM router spawning multiple public nics
>>> >>
>>> >> Great, thanks. I've already got a working implementation of
>>> >> adding/removing nics from regular instances that I've been playing
>>> >> with, so I'm getting vaguely familiar with the various data types
>>> and
>>> >> things surrounding the networking. I don't know if this is quite
>>> >> within my reach just yet but I'll see how far I get.
>>> >>
>>> >> On Wed, Aug 29, 2012 at 3:19 PM, Alena Prokharchyk
>>> >> <Alena.Prokharchyk@citrix.com> wrote:
>>> >> > On 8/29/12 1:34 PM, "Edison Su" <Edison.su@citrix.com> wrote:
>>> >> >
>>> >> >>Hi Anthony & Alena,
>>> >> >>   Could you help to provide information about VPC, how it works,
>>> >> >
>>> >> >
>>> >> > Here is the functional spec on the feature:
>>> >> >
>>> >> > wiki.cloudstack.org/display/RelOps/Inter-
>>> VLAN+Routing+functional+spec
>>> >> >
>>> >> >
>>> >> > VpcVirtualNetworkApplianceManagerImpl is the manager responsible
>>> for
>>> >> VPC
>>> >> > Virtual router operations (plug/unplug nics, etc)
>>> >> >
>>> >> >
>>> >> >
>>> >> >> which commands needed to implemented on the hypervisor side?
>>> >> >
>>> >> >
>>> >> >
>>> >> > 1) PlugNicCommand/UnplugNicCommand - does Nic hotplug/unplug
>>> >> (currently
>>> >> > works for VR vm only). In VPC called when add nic for Public/Guest
>>> >> > networks.
>>> >> > 2) SetupGuestNetworkCommand - sets up dhcp range, dns information,
>>> >> > networkDomain information on the Nic to make it
>>> >> > 3) SetNetworkACLCommand - creates network ACL on the virtual
>>> router
>>> >> > 4) SetSourceNatCommand - used for setting source nat on the Public
>>> IP
>>> >> on
>>> >> > the VPC VR.
>>> >> > 5) Site2SiteVpnCfgCommand - for setting up S2S VPN
>>> >> >
>>> >> >
>>> >> > Anthony/Kelven/Vijay did implementation for Xen/vmWare resources,
>>> >> they can
>>> >> > help you answering all hypervisor related questions. If you need
>>> more
>>> >> > details on business logic + Vpc VR management, I can help with
>>> that.
>>> >> >
>>> >> >
>>> >> > -Alena.
>>> >> >
>>> >> >>
>>> >> >>> -----Original Message-----
>>> >> >>> From: Marcus Sorensen [mailto:shadowsor@gmail.com]
>>> >> >>> Sent: Wednesday, August 29, 2012 10:16 AM
>>> >> >>> To: cloudstack-dev@incubator.apache.org
>>> >> >>> Subject: Re: VM router spawning multiple public nics
>>> >> >>>
>>> >> >>> I'd be willing to give it a shot if someone could point me in
>>> the
>>> >> >>> right direction and be available to answer questions.
>>> >> >>>
>>> >> >>> On Wed, Aug 29, 2012 at 10:39 AM, Edison Su
>>> <Edison.su@citrix.com>
>>> >> >>> wrote:
>>> >> >>> > Yah, KVM doesn't support VPC yet. Will you help to add VPC
>>> >> support on
>>> >> >>> KVM?:) Just implement a few VPC related commands...
>>> >> >>> >
>>> >> >>> >> -----Original Message-----
>>> >> >>> >> From: Marcus Sorensen [mailto:shadowsor@gmail.com]
>>> >> >>> >> Sent: Wednesday, August 29, 2012 6:49 AM
>>> >> >>> >> To: cloudstack-dev@incubator.apache.org
>>> >> >>> >> Subject: Re: VM router spawning multiple public nics
>>> >> >>> >>
>>> >> >>> >> I can confirm that the patch has fixed my particular issue.
>>> >> >>> >>
>>> >> >>> >> This is likely unrelated and I think it doesn't even use the
>>> >> same
>>> >> >>> >> code, but I began to play with the VPC stuff a bit and
>>> noticed
>>> >> that
>>> >> >>> I
>>> >> >>> >> don't get any interfaces except for link local.  I'd probably
>>> >> chalk
>>> >> >>> >> that up to it not being ready for KVM, but I thought it was
>>> >> worth a
>>> >> >>> >> mention.  I'd be happy to try to help get it ready if someone
>>> >> has
>>> >> >>> time
>>> >> >>> >> to nudge me in the right direction.
>>> >> >>> >>
>>> >> >>> >> On Tue, Aug 28, 2012 at 3:15 PM, Edison Su
>>> >> <Edison.su@citrix.com>
>>> >> >>> wrote:
>>> >> >>> >> >
>>> >> >>> >> >
>>> >> >>> >> >> -----Original Message-----
>>> >> >>> >> >> From: Marcus Sorensen [mailto:shadowsor@gmail.com]
>>> >> >>> >> >> Sent: Tuesday, August 28, 2012 2:00 PM
>>> >> >>> >> >> To: cloudstack-dev@incubator.apache.org
>>> >> >>> >> >> Subject: Re: VM router spawning multiple public nics
>>> >> >>> >> >>
>>> >> >>> >> >>  I thought about this solution myself, but below this
>>> portion
>>> >> of
>>> >> >>> >> code
>>> >> >>> >> >> it looks like it uses the hash map to determine which nic
>>> >> number
>>> >> >>> to
>>> >> >>> >> >> add the IP to, so with multiple 'untagged' networks it
>>> would
>>> >> have
>>> >> >>> no
>>> >> >>> >> >> way of knowing which nicnum in the router corresponds with
>>> >> the
>>> >> >>> >> correct
>>> >> >>> >> >> untagged vlan.
>>> >> >>> >> >>
>>> >> >>> >> >>                 nicNum =
>>> >> vlanAllocatedToVM.get(ip.getVlanId());
>>> >> >>> >> >>                 networkUsage(routerIp, "addVif", "eth" +
>>> >> nicNum);
>>> >> >>> >> >>                 result =
>>> >> >>> >> >> _virtRouterResource.assignPublicIpAddress(routerName,
>>> >> >>> >> >>                         routerIp, ip.getPublicIp(),
>>> >> ip.isAdd(),
>>> >> >>> >> >> ip.isFirstIP(),
>>> >> >>> >> >>                         ip.isSourceNat(), ip.getVlanId(),
>>> >> >>> >> >> ip.getVlanGateway(),
>>> >> >>> >> >>                         ip.getVlanNetmask(),
>>> >> >>> ip.getVifMacAddress(),
>>> >> >>> >> >>                         ip.getGuestIp(), nicNum);
>>> >> >>> >> >>
>>> >> >>> >> >> if ip.getVlanId() returns untagged (as it does on networks
>>> >> with
>>> >> >>> no
>>> >> >>> >> >> vlan id), and we tried to put multiple untagged keys in
>>> >> >>> >> >> vlanAllocatedToVM (as with multiple untagged networks), we
>>> >> get
>>> >> >>> the
>>> >> >>> >> >> wrong nicNum, no?
>>> >> >>> >> >
>>> >> >>> >> > In the ipassoc case, if there are multiple untagged
>>> networks,
>>> >> all
>>> >> >>> of
>>> >> >>> >> them are use the same
>>> >> >>> >> > Public bridge. Then multiple ip address will be added on
>>> eth2
>>> >> >>> inside
>>> >> >>> >> router VM.
>>> >> >>> >> > If it works physically, then it works.
>>> >> >>> >> >
>>> >> >>> >> >>
>>> >> >>> >> >> On Tue, Aug 28, 2012 at 2:48 PM, Edison Su
>>> >> <Edison.su@citrix.com>
>>> >> >>> >> wrote:
>>> >> >>> >> >> >
>>> >> >>> >> >> >
>>> >> >>> >> >> >> -----Original Message-----
>>> >> >>> >> >> >> From: Marcus Sorensen [mailto:shadowsor@gmail.com]
>>> >> >>> >> >> >> Sent: Tuesday, August 28, 2012 1:40 PM
>>> >> >>> >> >> >> To: cloudstack-dev@incubator.apache.org
>>> >> >>> >> >> >> Subject: Re: VM router spawning multiple public nics
>>> >> >>> >> >> >>
>>> >> >>> >> >> >> Yes, that looks like it would work for me, however
>>> that's
>>> >> not
>>> >> >>> >> >> >> something that would ever make it into master, right?
>>> >> >>> Essentially
>>> >> >>> >> >> >> killing tagging for the public, private, and guest
>>> traffic
>>> >> >>> labels?
>>> >> >>> >> >> >> There's also still the issue of not being able to
>>> >> >>> differentiate
>>> >> >>> >> >> >> between multiple untagged networks, if we wanted to add
>>> an
>>> >> IP
>>> >> >>> to
>>> >> >>> >> a
>>> >> >>> >> >> >> router it might not know which untagged interface to
>>> apply
>>> >> it
>>> >> >>> to.
>>> >> >>> >> >> >
>>> >> >>> >> >> > Physically, all the "untagged" network will be created
>>> on
>>> >> >>> >> >> public/guest/private bridge(the name we put in
>>> >> >>> >> >> private/public/guest.bridge.name in agent.properties").
>>> >> >>> >> >> > Because, there is no way to create a new untagged bridge
>>> by
>>> >> >>> agent
>>> >> >>> >> >> itself. Agent code only knows how to create a new
>>> tagged(vlan)
>>> >> >>> >> bridge.
>>> >> >>> >> >> > So the fix should be pushed into master.
>>> >> >>> >> >> >
>>> >> >>> >> >> >>
>>> >> >>> >> >> >> On Tue, Aug 28, 2012 at 2:32 PM, Edison Su
>>> >> >>> <Edison.su@citrix.com>
>>> >> >>> >> >> wrote:
>>> >> >>> >> >> >> >
>>> >> >>> >> >> >> >
>>> >> >>> >> >> >> >> -----Original Message-----
>>> >> >>> >> >> >> >> From: Marcus Sorensen [mailto:shadowsor@gmail.com]
>>> >> >>> >> >> >> >> Sent: Tuesday, August 28, 2012 12:23 PM
>>> >> >>> >> >> >> >> To: cloudstack-dev@incubator.apache.org
>>> >> >>> >> >> >> >> Subject: Re: VM router spawning multiple public nics
>>> >> >>> >> >> >> >>
>>> >> >>> >> >> >> >> Thanks for pointing me in the right direction. I've
>>> >> >>> reviewed
>>> >> >>> >> this
>>> >> >>> >> >> >> code
>>> >> >>> >> >> >> >> in a bit more detail, and it seems like it's
>>> >> accomplishing
>>> >> >>> the
>>> >> >>> >> >> >> >> following:
>>> >> >>> >> >> >> >>
>>> >> >>> >> >> >> >> 1. get all network interfaces currently connected to
>>> >> the
>>> >> >>> >> running
>>> >> >>> >> >> VM
>>> >> >>> >> >> >> >> (a.k.a vnet devices via libvirt)
>>> >> >>> >> >> >> >> 2. find out which vlans these network interfaces are
>>> >> >>> bridged
>>> >> >>> >> to,
>>> >> >>> >> >> >> store
>>> >> >>> >> >> >> >> this in a hash map of vlan ids and nics
>>> >> >>> >> >> >> >> 3. get all ip addresses to be added to the VM
>>> >> >>> >> >> >> >> 4. for each ip, get the configured vlan id for the
>>> ip,
>>> >> >>> compare
>>> >> >>> >> it
>>> >> >>> >> >> to
>>> >> >>> >> >> >> >> the hash map of existing vlan ids and nics
>>> >> >>> >> >> >> >> 5. if the required vlan id is not found in the hash
>>> map,
>>> >> >>> >> create a
>>> >> >>> >> >> >> new
>>> >> >>> >> >> >> >> nic
>>> >> >>> >> >> >> >> 6. assign the ip to the nic identified by the vlan
>>> id
>>> >> key
>>> >> >>> in
>>> >> >>> >> the
>>> >> >>> >> >> >> hash
>>> >> >>> >> >> >> >> map
>>> >> >>> >> >> >> >>
>>> >> >>> >> >> >> >> In this case, we're getting a vlan id returned in
>>> step
>>> >> 2
>>> >> >>> for a
>>> >> >>> >> >> >> bridged
>>> >> >>> >> >> >> >> nic whose network is defined as untagged in the
>>> >> cloudstack
>>> >> >>> db,
>>> >> >>> >> >> >> >> therefore in step 5 we never match as already having
>>> a
>>> >> nic
>>> >> >>> for
>>> >> >>> >> >> >> >> 'untagged'. I wrote a big long response discussing
>>> this
>>> >> >>> issue,
>>> >> >>> >> >> but
>>> >> >>> >> >> >> as
>>> >> >>> >> >> >> >> I began to dig further I realized that aside from my
>>> >> >>> >> particular
>>> >> >>> >> >> case,
>>> >> >>> >> >> >> >> untagged vlans in general are just broken (for
>>> example
>>> >> they
>>> >> >>> >> can't
>>> >> >>> >> >> be
>>> >> >>> >> >> >> >> dealt with uniquely in the current IpAssocCommand
>>> code,
>>> >> >>> given
>>> >> >>> >> the
>>> >> >>> >> >> >> hash
>>> >> >>> >> >> >> >> map) and it would require more effort than I have
>>> time
>>> >> for
>>> >> >>> now
>>> >> >>> >> to
>>> >> >>> >> >> >> make
>>> >> >>> >> >> >> >> things work. If the code were already in place to
>>> >> >>> >> differentiate
>>> >> >>> >> >> >> >> between multiple untagged nics I think that fixing
>>> my
>>> >> >>> problem
>>> >> >>> >> >> would
>>> >> >>> >> >> >> be
>>> >> >>> >> >> >> >> trivial, but since its not, I'll just find an
>>> >> alternative
>>> >> >>> >> >> solution.
>>> >> >>> >> >> >> >>
>>> >> >>> >> >> >> >
>>> >> >>> >> >> >> > The untagged network usually means "untagged", no
>>> vlan
>>> >> on
>>> >> >>> the
>>> >> >>> >> >> >> bridge...
>>> >> >>> >> >> >> > In your case, the untagged network actually has
>>> >> vlan(tagged)
>>> >> >>> on
>>> >> >>> >> >> the
>>> >> >>> >> >> >> bridge, thus getting things confused.
>>> >> >>> >> >> >> > Will this patch(http://pastebin.com/HJXzZwKp) work
>>> for
>>> >> you?
>>> >> >>> >> >> >> >
>>> >> >>> >> >> >> >> On Mon, Aug 27, 2012 at 10:46 PM, Marcus Sorensen
>>> >> >>> >> >> >> <shadowsor@gmail.com>
>>> >> >>> >> >> >> >> wrote:
>>> >> >>> >> >> >> >> > ...
>>> >> >>> >> >> >> >> >             Integer nicPos = 0;
>>> >> >>> >> >> >> >> >             for (InterfaceDef nic : nics) {
>>> >> >>> >> >> >> >> >                 if
>>> >> >>> >> >> >> >>
>>> (nic.getBrName().equalsIgnoreCase(_linkLocalBridgeName))
>>> >> {
>>> >> >>> >> >> >> >> >
>>> vlanAllocatedToVM.put("LinkLocal",
>>> >> >>> >> nicPos);
>>> >> >>> >> >> >> >> >                 } else {
>>> >> >>> >> >> >> >> >                     String vlanId =
>>> >> >>> >> >> >> >> getVlanIdFromBridge(nic.getBrName());
>>> >> >>> >> >> >> >> >                     if (vlanId != null) {
>>> >> >>> >> >> >> >> >
>>> vlanAllocatedToVM.put(vlanId,
>>> >> >>> >> nicPos);
>>> >> >>> >> >> >> >> >                     } else {
>>> >> >>> >> >> >> >> >
>>> >> >>> vlanAllocatedToVM.put(Vlan.UNTAGGED,
>>> >> >>> >> >> >> nicPos);
>>> >> >>> >> >> >> >> >                     }
>>> >> >>> >> >> >> >> >                 }
>>> >> >>> >> >> >> >> >                 nicPos++;
>>> >> >>> >> >> >> >> >             }
>>> >> >>> >> >> >> >> >             IpAddressTO[] ips =
>>> cmd.getIpAddresses();
>>> >> >>> >> >> >> >> >             int i = 0;
>>> >> >>> >> >> >> >> >             String result = null;
>>> >> >>> >> >> >> >> >             int nicNum = 0;
>>> >> >>> >> >> >> >> >             for (IpAddressTO ip : ips) {
>>> >> >>> >> >> >> >> >                 if
>>> >> >>> >> >> (!vlanAllocatedToVM.containsKey(ip.getVlanId()))
>>> >> >>> >> >> >> {
>>> >> >>> >> >> >> >> >                     /* plug a vif into router */
>>> >> >>> >> >> >> >> >                     VifHotPlug(conn, routerName,
>>> >> >>> >> ip.getVlanId(),
>>> >> >>> >> >> >> >> >                             ip.getVifMacAddress());
>>> >> >>> >> >> >> >> >
>>> >> vlanAllocatedToVM.put(ip.getVlanId(),
>>> >> >>> >> >> >> nicPos++);
>>> >> >>> >> >> >> >> >                 }
>>> >> >>> >> >> >> >> > ...
>>> >> >>> >> >> >> >> >
>>> >> >>> >> >> >> >> > Looks like the getVlanIdFromBridge might be a bit
>>> >> >>> misleading.
>>> >> >>> >> I
>>> >> >>> >> >> am
>>> >> >>> >> >> >> >> > running my guest public traffic on a 'cloudbr470',
>>> >> which
>>> >> >>> is
>>> >> >>> >> a
>>> >> >>> >> >> >> bridge
>>> >> >>> >> >> >> >> > to eth2.470, yet I configured this network as
>>> >> 'untagged'
>>> >> >>> >> >> because I
>>> >> >>> >> >> >> >> > have a vlan 470 available on eth3 for cloudstack
>>> to
>>> >> >>> >> autoassign
>>> >> >>> >> >> >> (eth3
>>> >> >>> >> >> >> >> > is where all of my stuff will be autoassigned). So
>>> >> I'm
>>> >> >>> not
>>> >> >>> >> 100%
>>> >> >>> >> >> >> sure
>>> >> >>> >> >> >> >> > yet what's going on here but it seems as though
>>> the
>>> >> above
>>> >> >>> is
>>> >> >>> >> >> not
>>> >> >>> >> >> >> >> > setting any 'Vlan.UNTAGGED', since it finds a vlan
>>> >> number
>>> >> >>> >> for
>>> >> >>> >> >> >> >> > eth2.470, but when it enumerates the IPs for the
>>> >> router,
>>> >> >>> it
>>> >> >>> >> >> then
>>> >> >>> >> >> >> runs
>>> >> >>> >> >> >> >> > ip.getVlanId() and doesn't find a nic for the
>>> >> untagged IP
>>> >> >>> >> and
>>> >> >>> >> >> >> creates
>>> >> >>> >> >> >> >> > one.
>>> >> >>> >> >> >> >> >
>>> >> >>> >> >> >> >> >
>>> >> >>> >> >> >> >> > I realize this is perhaps an uncommon case, but a
>>> bug
>>> >> >>> >> >> nonetheless.
>>> >> >>> >> >> >> >> > I'll play with the code a bit and see if I can
>>> come
>>> >> up
>>> >> >>> with
>>> >> >>> >> a
>>> >> >>> >> >> >> >> > solution. I'm thinking I can look at the nic's
>>> >> broadcast
>>> >> >>> URI
>>> >> >>> >> >> and
>>> >> >>> >> >> >> see
>>> >> >>> >> >> >> >> > if it's supposed to be untagged, then add to
>>> >> >>> >> vlanAllocatedToVM
>>> >> >>> >> >> >> >> > appropriately, off the top of my head something
>>> like:
>>> >> >>> >> >> >> >> >
>>> >> >>> >> >> >> >> >                     String vlanId =
>>> >> >>> >> >> >> >> getVlanIdFromBridge(nic.getBrName());
>>> >> >>> >> >> >> >> >                     if (vlanId != null &&
>>> >> >>> >> >> >> >>
>>> > !nic.getBroadcastUri().toString().contains("untagged")
>>> >> {
>>> >> >>> >> >> >> >> >
>>> vlanAllocatedToVM.put(vlanId,
>>> >> >>> >> nicPos);
>>> >> >>> >> >> >> >> >                     } else {
>>> >> >>> >> >> >> >> >
>>> >> >>> vlanAllocatedToVM.put(Vlan.UNTAGGED,
>>> >> >>> >> >> >> nicPos);
>>> >> >>> >> >> >> >> >                     }
>>> >> >>> >> >> >> >> >
>>> >> >>> >> >> >> >> >
>>> >> >>> >> >> >> >> >
>>> >> >>> >> >> >> >> > On Mon, Aug 27, 2012 at 6:42 PM, Edison Su
>>> >> >>> >> >> <Edison.su@citrix.com>
>>> >> >>> >> >> >> >> wrote:
>>> >> >>> >> >> >> >> >> Possible bug in in kvm code:
>>> >> LibvirtComputingResource-
>>> >> >>> >> >> >> >> >execute(IpAssocCommand cmd)-> VifHotPlug, which is
>>> >> only
>>> >> >>> place
>>> >> >>> >> >> >> adding
>>> >> >>> >> >> >> >> nic into router vm.
>>> >> >>> >> >> >> >> >> Turn on agent log, then take a look what happened.
>>> >> >>> >> >> >> >> >>
>>> >> >>> >> >> >> >> >>> -----Original Message-----
>>> >> >>> >> >> >> >> >>> From: Marcus Sorensen
>>> [mailto:shadowsor@gmail.com]
>>> >> >>> >> >> >> >> >>> Sent: Monday, August 27, 2012 5:10 PM
>>> >> >>> >> >> >> >> >>> To: cloudstack-dev@incubator.apache.org
>>> >> >>> >> >> >> >> >>> Subject: VM router spawning multiple public nics
>>> >> >>> >> >> >> >> >>>
>>> >> >>> >> >> >> >> >>> I've got two zones running the same build of
>>> >> cloudstack
>>> >> >>> (a
>>> >> >>> >> >> >> recent
>>> >> >>> >> >> >> >> copy
>>> >> >>> >> >> >> >> >>> of master). One of them creates routers that
>>> turn
>>> >> into
>>> >> >>> >> ugly
>>> >> >>> >> >> >> >> >>> multi-headed beasts, and by that I mean that any
>>> >> time I
>>> >> >>> >> >> create a
>>> >> >>> >> >> >> >> port
>>> >> >>> >> >> >> >> >>> forwarding or iptables rule for that router I
>>> get a
>>> >> new
>>> >> >>> >> >> public
>>> >> >>> >> >> >> NIC
>>> >> >>> >> >> >> >> >>> with an identical IP address, I have an instance
>>> >> with a
>>> >> >>> >> few
>>> >> >>> >> >> tens
>>> >> >>> >> >> >> of
>>> >> >>> >> >> >> >> >>> NICs.  My guess is that some script isn't
>>> detecting
>>> >> >>> that
>>> >> >>> >> >> there's
>>> >> >>> >> >> >> >> >>> already a NIC with the public IP on it.  It
>>> looks
>>> >> fine
>>> >> >>> in
>>> >> >>> >> the
>>> >> >>> >> >> >> >> >>> database, there is only one public NIC defined
>>> in
>>> >> the
>>> >> >>> nics
>>> >> >>> >> >> table.
>>> >> >>> >> >> >> >> >>> I'll troubleshoot it tomorrow, but if anyone
>>> knows
>>> >> >>> where I
>>> >> >>> >> >> >> should
>>> >> >>> >> >> >> >> >>> begin the headstart would be appreciated.
>>> >> >>> >> >> >> >> >>>
>>> >> >>> >> >> >> >> >>> Thanks
>>> >> >>
>>> >> >
>>> >> >