incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jayapal Reddy Uradi <jayapalreddy.ur...@citrix.com>
Subject RE: Functional Specification for the multiple IPs per NIC
Date Wed, 20 Feb 2013 12:01:43 GMT
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.Prateek@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.uradi@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.Prateek@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.Vittal@citrix.com>
> >> wrote:
> >>
> >> >
> >> >
> >> >On 1/29/13 8:23 AM, "Jayapal Reddy Uradi"
> >> ><jayapalreddy.uradi@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.uradi@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.Vittal@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.Prateek@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.uradi@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.Vittal@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.uradi@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.Vittal@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.Xu@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.uradi@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:jlk@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.kannan@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:jlk@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.uradi@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.Vittal@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"
> >> >>> > >>> >> >> > >>> <jlk@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.uradi@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
> >> >>> > >>> >> >
> >> >>> > >>> >
> >> >>> > >>
> >> >>> > >
> >> >>
> >> >
> >


Mime
View raw message