cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abhinandan Prateek <Abhinandan.Prat...@citrix.com>
Subject Re: Functional Specification for the multiple IPs per NIC
Date Thu, 21 Feb 2013 04:07:07 GMT
Good, that will ease the testing and validation of Xen plugins !

-abhi

On 20/02/13 5:31 PM, "Jayapal Reddy Uradi" <jayapalreddy.uradi@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.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