listNicIps/listNicSecondaryIps API lists the only the secondary ip addresses . do we need to list the both primary and secondary ip addresses in the list API ?
The current load balancing 'assignToLoadBalancerRule' API takes list virtualmachineids argument and configures the LB for primary IP addresses. To configure the LB for secondary ip addresses adding an optional argument to API. The optional argument vmIpaddrs takes the list of ip addresses of the corresponding virtualmachineids vm list parameter. When vmipaddrs is not passed LB is configured for the VMs primary ip addreses. Thanks, Jayapal > -----Original Message----- > From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com] > Sent: Monday, January 28, 2013 9:15 PM > To: cloudstack-dev@incubator.apache.org > Subject: RE: Functional Specification for the multiple IPs per NIC > > Hi Chiradeep. > > Thanks for the review comments. > > I will change API names to 'addIpToNic' and 'removeIpToNic' , update the FS > with API names. > I will also look into the meta data for secondary ip and include this > section in > the FS. > > Regards, > Jayapal > > > > > -----Original Message----- > > From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] > > Sent: Monday, January 28, 2013 1:05 PM > > To: cloudstack-dev@incubator.apache.org > > Subject: Re: Functional Specification for the multiple IPs per NIC > > > > I didn't notice the API specification before in the FS. > > The verb 'associate' is used with the public ip (for static nat), so > > it will introduce confusion. I prefer "add" or "assign" > > Similarly, 'unassociate' doesn't make any sense > > > > Also, why insist on 'secondary' in the API? A nic cannot be created > > without any ip addresses (at least currently), so I would leave out > > the 'secondary' part in the API as well. > > > > Last, the instance meta-data makes available the primary ip, the > > secondary ips should be made available as well. > > See > > http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG-chapter- > > instanceda > > ta.html#instancedata-data-categories > > > > On 1/18/13 3:40 AM, "Abhinandan Prateek" > > <abhinandan.prat...@citrix.com> > > wrote: > > > > >Jayapal, > > > > > > The FS seems to be updated with the feedback received on the > > >forum, I guess you can start implementation. > > > > > >-abhi > > > > > >On 18/01/13 4:33 PM, "Jayapal Reddy Uradi" > > ><jayapalreddy.ur...@citrix.com> > > >wrote: > > > > > >>Update the FS with the below discussions. > > >> > > >>Please find updated FS below. > > > >>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+a > > dd > > >>res > > >>s > > >>+per+NIC > > >> > > >>Thanks, > > >>Jayapal > > >> > > >>> -----Original Message----- > > >>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] > > >>> Sent: Thursday, January 17, 2013 12:51 PM > > >>> To: CloudStack DeveloperList > > >>> Subject: Re: Functional Specification for the multiple IPs per NIC > > >>> > > >>> I hope we consider the case when the ip is removed from the nic > > >>>while there is a PF rule to that ip. > > >>> > > >>> On 1/16/13 9:10 PM, "Jayapal Reddy Uradi" > > >>><jayapalreddy.ur...@citrix.com> > > >>> wrote: > > >>> > > >>> >Hi Chiradeep, > > >>> > > > >>> >Now the VM NIC will have multiple IPs so for creating PF for > > >>> >secondary ip address we will pass VM id and (optional argument) > > >>> >VM ip address > > >>>to > > >>> >the API. > > >>> >When VM ip address is passed it checks the whether the ip belongs > > >>> >to the VM or not and configures the PF for the VM IP address. > > >>> > > > >>> >When VM ip address argument is not passed to the API then it > > >>> >works in older way. > > >>> >When VM NIC has NO secondary ip address also we can pass VM id > > >>> >and VM primary ip address to VM ipaddress argument to API to > > >>> >configure > > PF. > > >>> > > > >>> >Thanks, > > >>> >Jayapal > > >>> > > > >>> > > > >>> > > > >>> >> -----Original Message----- > > >>> >> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] > > >>> >> Sent: Thursday, January 17, 2013 1:45 AM > > >>> >> To: CloudStack DeveloperList > > >>> >> Subject: Re: Functional Specification for the multiple IPs per > > >>> >> NIC > > >>> >> > > >>> >> Note also that the createPortForwardingRule API takes a vm id > > >>> >>and network id, based on the assumption of a single ip per NIC. > > >>> >>This may need an additional parameter of ip (or make the vm id > optional). > > >>> >> > > >>> >> On 1/15/13 9:35 AM, "Anthony Xu" <xuefei...@citrix.com> wrote: > > >>> >> > > >>> >> >Thanks for bringing this up, > > >>> >> > > > >>> >> >For security group, we may need to handle following things, > > >>> >> > > > >>> >> >As you mentioned, > > >>> >> >Anti-spoofing rules need to be updated, when secondary IP is > > >>> >> >associate/dissociate to NIC. > > >>> >> > > > >>> >> >And > > >>> >> >Security group rule can base on cidr and it can base on > > >>> >> >account/security group, For example a security group rule can > > >>> >> >allow all VMs in another account/security group to access VMs > > >>> >> >in this security group. > > >>> >> > > > >>> >> >In this case, > > >>> >> > > > >>> >> >When secondary IP is associate/dissociate to NIC. The related > > >>> >> >security group rule based on account/security group need to be > > >>> >> >resent to reflect the IP change in this security group. > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> >Anthony > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> >> -----Original Message----- > > >>> >> >> From: Jayapal Reddy Uradi > > >>> >> >> [mailto:jayapalreddy.ur...@citrix.com] > > >>> >> >> Sent: Tuesday, January 15, 2013 5:17 AM > > >>> >> >> To: cloudstack-dev@incubator.apache.org > > >>> >> >> Subject: RE: Functional Specification for the multiple IPs > > >>> >> >> per > > >>>NIC > > >>> >> >> > > >>> >> >> Please find the updated FS in below link. > > >>> >> >> > > >>> >> > > >>> > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+a > > >>> d > > >>> >> >> dr > > >>> >> >> ess+per+NIC > > >>> >> >> > > >>> >> >> I want to discuss the MIPN case for shared networks. > > >>> >> >> > > >>> >> >> I observed VM specific security groups iptables rules in > > >>> >> >> basic zone, in which we are allowing egress traffic from > > >>> >> >> the guest VM primary > > >>> >> >> (dhcp) address only. > > >>> >> >> If we add another IP to the NIC we should update the > > >>> >> >> security groups to allow the egress traffic from the new ip. > > >>> >> >> > > >>> >> >> Example Current rule: It allows traffic from the i-2-3 > > >>> >> >> VM's > > >>> >> >> 10.147.41.239 IP only. > > >>> >> >> 0 0 i-2-3-TEST-eg all -- * * 10.147.41.239 > > >>> >> >> 0.0.0.0/0 PHYSDEV match --physdev-in vif7.0 > > >>>--physdev-is- > > >>> >> >> bridged > > >>> >> >> > > >>> >> >> We should update security group rules each time we associate > > >>> >> >> secondary IP to NIC. > > >>> >> >> > > >>> >> >> Please let me know if you have any comments or suggestion > > >>> >> >> for the above . > > >>> >> >> > > >>> >> >> Thanks, > > >>> >> >> Jayapal > > >>> >> >> > > >>> >> >> > > >>> >> >> > > >>> >> >> > > >>> >> >> > -----Original Message----- > > >>> >> >> > From: John Kinsella [mailto:j...@stratosec.co] > > >>> >> >> > Sent: Wednesday, December 19, 2012 10:59 PM > > >>> >> >> > To: cloudstack-dev@incubator.apache.org > > >>> >> >> > Subject: Re: Functional Specification for the multiple IPs > > >>> >> >> > per NIC > > >>> >> >> > > > >>> >> >> > 'morning Hari. I can think of at least one use case where > > >>> >> >> > allowing > > >>> >> >> the "user" > > >>> >> >> > to specify the IP would be required - when migrating an IP > > >>> >> >> > from one > > >>> >> >> CAP to > > >>> >> >> > ACS or from one VM to another. > > >>> >> >> > > > >>> >> >> > Anyways - I think what the real answer to your question is > > >>>would > > >>> >> >> > be > > >>> >> >> to have > > >>> >> >> > a granular security model around the API calls. At that > > >>> >> >> > point you > > >>> >> >> could specify > > >>> >> >> > what users/groups have the ability to assign specific IPs > > >>> >> >> > to a > > >>> >> >> specific instance. > > >>> >> >> > So I'd vote to implement for now, and attack a granular > > >>> >> >> > api security > > >>> >> >> model > > >>> >> >> > sooner rather than later. > > >>> >> >> > > > >>> >> >> > John > > >>> >> >> > > > >>> >> >> > On Dec 18, 2012, at 4:15 PM, Hari Kannan > > >>> >> >> > <hari.kan...@citrix.com> > > >>> >> >> > wrote: > > >>> >> >> > > > >>> >> >> > > Regarding " User can specify the IP address from the > > >>> >> >> > > guest subnet > > >>> >> >> if > > >>> >> >> > > not CS picks the IP from the guest subnet " comment in > > >>> >> >> > > the FS > > >>> >> >> > > > > >>> >> >> > > I don't see a need to do this - because, it is a shared > > >>> >> >> > > network, > > >>> >> >> how > > >>> >> >> > > does he know what is used up and what is not? So, he > > >>> >> >> > > could go > > >>> >> >> through > > >>> >> >> > > a sequence of steps only to get an error message back > > >>> >> >> > > that it is > > >>> >> >> not > > >>> >> >> > > possible (and keep doing this until success) > > >>> >> >> > > > > >>> >> >> > > One possibility is telling him what is available - it > > >>> >> >> > > may not be a > > >>> >> >> big > > >>> >> >> > > deal to reveal the used/unused IPs in isolated network > > >>> >> >> > > (although it would be hard to show from a large CIDR > > >>> >> >> > > what is used/available), > > >>> >> >> but > > >>> >> >> > > we wont even be able to tell him what is used/unused in > > >>> >> >> > > a shared network - > > >>> >> >> > > > > >>> >> >> > > Any thoughts? > > >>> >> >> > > > > >>> >> >> > > Hari Kannan > > >>> >> >> > > > > >>> >> >> > > -----Original Message----- > > >>> >> >> > > From: John Kinsella [mailto:j...@stratosec.co] > > >>> >> >> > > Sent: Tuesday, December 18, 2012 10:36 AM > > >>> >> >> > > To: cloudstack-dev@incubator.apache.org > > >>> >> >> > > Subject: Re: Functional Specification for the multiple > > >>> >> >> > > IPs > > >>>per > > >>> >> >> > > NIC > > >>> >> >> > > > > >>> >> >> > > Is there any logic behind 30? At some point, we're going > > >>> >> >> > > to > > >>>be > > >>> >> >> asked, > > >>> >> >> > > so I'd like to have a decent answer. :) > > >>> >> >> > > > > >>> >> >> > > On the rest of this, I'd like to get some level of > > >>> >> >> > > consensus on the > > >>> >> >> design. > > >>> >> >> > What looks best to me: > > >>> >> >> > > * Improve UserData/CloudInit support in CloudStack (I'm > > >>> >> >> > > willing to work on this, consider it important) - allow > > >>> >> >> > > expiration of data, > > >>> >> >> wider > > >>> >> >> > > variety of data supported > > >>> >> >> > > * Create the multi-IPs-per-NIC code to get IPs via > > >>> >> >> > > CloudInit (Need > > >>> >> >> to > > >>> >> >> > > think through Windows equivalent) > > >>> >> >> > > * Update the password changing script to use CloudInit > > >>> >> >> > > > > >>> >> >> > > Thoughts? Or Jayapal have you already started work on > > >>> >> >> > > the multi-IP > > >>> >> >> > feature? > > >>> >> >> > > > > >>> >> >> > > On Dec 18, 2012, at 2:03 AM, Jayapal Reddy Uradi > > >>> >> >> > <jayapalreddy.ur...@citrix.com> wrote: > > >>> >> >> > > > > >>> >> >> > >> Regarding IP limit, it can be made as configurable > > >>> >> >> > >> using global > > >>> >> >> settings and > > >>> >> >> > default value will be 30. > > >>> >> >> > >> > > >>> >> >> > >> > > >>> >> >> > >> Thanks, > > >>> >> >> > >> Jayapal > > >>> >> >> > >> > > >>> >> >> > >>> -----Original Message----- > > >>> >> >> > >>> From: Chiradeep Vittal > > >>> >> >> > >>> [mailto:chiradeep.vit...@citrix.com] > > >>> >> >> > >>> Sent: Monday, December 17, 2012 12:59 PM > > >>> >> >> > >>> To: CloudStack DeveloperList > > >>> >> >> > >>> Subject: Re: Functional Specification for the multiple > > >>> >> >> > >>> IPs per > > >>> >> >> NIC > > >>> >> >> > >>> > > >>> >> >> > >>> In basic/shared networks the allocation is bounded by > > >>> >> >> > >>> what is already > > >>> >> >> > >>> "used- up". To prevent tenants from hogging all the > > >>> >> >> > >>> available ips, there needs to be limits. > > >>> >> >> > >>> > > >>> >> >> > >>> On 12/15/12 8:38 AM, "John Kinsella" > > >>> >> >> > >>> <j...@stratosec.co> > > >>>wrote: > > >>> >> >> > >>> > > >>> >> >> > >>>> I'd remove the limitation of having 30 IPs per interface. > > >>> >> >> > >>>> Modern OSes can support way more. > > >>> >> >> > >>>> > > >>> >> >> > >>>> Why no support for basic networking? I can see a > > >>> >> >> > >>>> small hosting provider with a basic setup wanting to > > >>> >> >> > >>>> manage web > > >>> servers... > > >>> >> >> > >>>> > > >>> >> >> > >>>> John > > >>> >> >> > >>>> > > >>> >> >> > >>>> On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi > > >>> >> >> > >>>> <jayapalreddy.ur...@citrix.com> wrote: > > >>> >> >> > >>>> > > >>> >> >> > >>>>> Hi All, > > >>> >> >> > >>>>> > > >>> >> >> > >>>>> Current guest VM by default having one NIC and one > > >>> >> >> > >>>>> IP address > > >>> >> >> > assigned. > > >>> >> >> > >>>>> If your wants extra IP for the guest VM, there no > > >>> >> >> > >>>>> provision > > >>> >> >> from > > >>> >> >> > >>>>> the CS. > > >>> >> >> > >>>>> > > >>> >> >> > >>>>> Using multiple IP address per NIC feature CS can > > >>>associate > > >>> >> >> > >>>>> IP address for the NIC, user can take that IP and > > >>> >> >> > >>>>> assign it to > > >>> >> >> the VM. > > >>> >> >> > >>>>> > > >>> >> >> > >>>>> Please find the FS for the more details. > > >>> >> >> > >>>>> > > >>> >> >> > >>>>> > > >>> >> >> > >>>>> > > >>> >> >> > > > >>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+ > > >>> >> >> > IP > > >>> >> >> > >>>>> + > > >>> >> >> > >>>>> a > > >>> >> >> > >>> dd > > >>> >> >> > >>>>> res > > >>> >> >> > >>>>> s+per+NIC > > >>> >> >> > >>>>> > > >>> >> >> > >>>>> Please provide your comments on the FS. > > >>> >> >> > >>>>> > > >>> >> >> > >>>>> > > >>> >> >> > >>>>> Thanks, > > >>> >> >> > >>>>> jayapal > > >>> >> >> > >>>> > > >>> >> >> > >>>> Stratosec - Secure Infrastructure as a Service > > >>> >> >> > >>>> o: 415.315.9385 > > >>> >> >> > >>>> @johnlkinsella > > >>> >> >> > >>>> > > >>> >> >> > >> > > >>> >> >> > >> > > >>> >> >> > > > > >>> >> >> > > Stratosec - Secure Infrastructure as a Service > > >>> >> >> > > o: 415.315.9385 > > >>> >> >> > > @johnlkinsella > > >>> >> >> > > > > >>> >> >> > > > > >>> >> >> > > > >>> >> >> > Stratosec - Secure Infrastructure as a Service > > >>> >> >> > o: 415.315.9385 > > >>> >> >> > @johnlkinsella > > >>> >> > > > >>> > > > >> > > >
