Good, that will ease the testing and validation of Xen plugins ! -abhi
On 20/02/13 5:31 PM, "Jayapal Reddy Uradi" <jayapalreddy.ur...@citrix.com> wrote: >Got what I needed. >As below called from xenserver, a method 'default_network_rules' in >vmops plugin >xe host-call-plugin host-uuid=3231a0d3-1e9f-4fea-8c56-a8c3a02ed1b0 >plugin=vmops fn=default_network_rules args:vmName=i-2-18-VM >args:vmIP=10.147.41.241 args:vmMAC=06:7a:e4:00:00:09 args:vmID=18 > >Thanks, >Jayapal > >> -----Original Message----- >> From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com] >> Sent: Friday, February 15, 2013 9:12 AM >> To: cloudstack-dev@incubator.apache.org >> Cc: Anthony Xu >> Subject: Re: Functional Specification for the multiple IPs per NIC >> >> Jayapal, >> Vmops is a plugin that get instrumented into the xenserver host. You >>need >> to invoke the plugin from CirtixResourceBase. Usually the vmops plugin >>will >> invoke one of the script that is on that particular host Again copied by >> cloudstack when that host was added. >> >> Anthony, >> It will be good if you can review the changes Jayapal is going to >>make to >> security groups for additional ips. >> >> -abhi >> >> On 14/02/13 8:13 PM, "Jayapal Reddy Uradi" >> <jayapalreddy.ur...@citrix.com> >> wrote: >> >> >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 >> >> >>> > >>> >> > >> >> >>> > >>> > >> >> >>> > >> >> >> >>> > > >> >> >> >> >> > >> > >
