Anthony, What is the best way to work on xenserver "vmops". I am writing new methods in vmops file for security groups rules for the vm secondary ips. If I add a new method how to call this method from the host. I am not able to call 'vmops <methodname> <args>' on the host.
Security groups iptables changes for MIPN: --------------------------------------------------- In security groups in order to allow VM secondary IPs to reach out changing the iptables rules as below. The current rules are comparing the source/destination of the VM ip and allowing only the traffic to/from the VM with VM IP. With MIPN feature VM nic can have multiple IPs. So the iptables rules source/destination ip option is changed to IPSET match. VM ip addresses (primary and secondary) are added to the ipset. Ex: -A i-2-61-def -s 10.147.41.238 -m physdev --physdev-in vif12.0 --physdev-is-bridged -j i-2-61-VM-eg With ipset: -A i-2-61-def -m set --set i-2-61 src -m physdev --physdev-in vif12.0 --physdev-is-bridged -j i-2-61-VM-eg Also arptables rules for secondary ip addresses are added. Please let me know if you have any comments. Thanks, Jayapal > -----Original Message----- > From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com] > Sent: Wednesday, January 30, 2013 9:52 AM > To: cloudstack-dev@incubator.apache.org > Subject: Re: Functional Specification for the multiple IPs per NIC > > Jayapal, > We should not create multiple APIs for diff outputs, when a param can give > you control over output from an existing API. > > -abhi > > On 30/01/13 12:58 AM, "Chiradeep Vittal" <chiradeep.vit...@citrix.com> > wrote: > > > > > > >On 1/29/13 8:23 AM, "Jayapal Reddy Uradi" > ><jayapalreddy.ur...@citrix.com> > >wrote: > > > >> > >>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 ? > > > >Yes. Why do we need a listNicSecondaryIps API? Why not just enhance > >listNics? > > > >> > >>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. > > > >I think this can be handled with an enhancement separate from this > >feature. Let us leave the API as is. > > > >> > >> > >>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/Multipl > >>> > >>> e+ > >>> > >>> >> >> > 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 > >>> > >>> >> > > >>> > >>> > > >>> > >> > >>> > > > >> > >
