Oh, I see, there are two kinds of commands: One doesn't need to get information from libvirt, which just login into router vm and program rules. For these commands, we can put them into virtualRoutingResource. Another does need to get infor from libvirt, such ipassoc, which need to get nic infor from libvirt, and plug in vif if needed. For these commands, need to be implemented in libvirtcomputingresource. While if it needs to access/program router, then add put that code in virtualroutingresource.
Does it make sense? > -----Original Message----- > From: Marcus Sorensen [mailto:shadow...@gmail.com] > Sent: Thursday, August 30, 2012 10:47 AM > To: Edison Su > Cc: cloudstack-dev@incubator.apache.org; Anthony Xu; Kelven Yang; > Vijayendra Bhamidipati > Subject: Re: VPC for KVM (was VM router spawning multiple public nics) > > 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 <shadow...@gmail.com> > wrote: > > Just want to clarify: > > > > "We can add implementation of > > > SetupGuestNetworkCommand/SetNetworkACLCommand/SetSourceNatCommand/Site2 > SiteVpnCfgCommand > > 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...@citrix.com> > wrote: > >> Yes, it is. > >> > >>> -----Original Message----- > >>> From: Marcus Sorensen [mailto:shadow...@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...@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:shadow...@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.prokharc...@citrix.com> wrote: > >>> >> > On 8/29/12 1:34 PM, "Edison Su" <edison...@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:shadow...@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...@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:shadow...@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...@citrix.com> > >>> >> >>> wrote: > >>> >> >>> >> > > >>> >> >>> >> > > >>> >> >>> >> >> -----Original Message----- > >>> >> >>> >> >> From: Marcus Sorensen [mailto:shadow...@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...@citrix.com> > >>> >> >>> >> wrote: > >>> >> >>> >> >> > > >>> >> >>> >> >> > > >>> >> >>> >> >> >> -----Original Message----- > >>> >> >>> >> >> >> From: Marcus Sorensen [mailto:shadow...@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...@citrix.com> > >>> >> >>> >> >> wrote: > >>> >> >>> >> >> >> > > >>> >> >>> >> >> >> > > >>> >> >>> >> >> >> >> -----Original Message----- > >>> >> >>> >> >> >> >> From: Marcus Sorensen > [mailto:shadow...@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 > >>> >> >>> >> >> >> <shadow...@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...@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:shadow...@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 > >>> >> >> > >>> >> > > >>> >> >
