.@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 xen
gs: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 mult
ge-
>> 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 n
; 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
>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
>>&g
s 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:
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
>
nal 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
>>+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:
ass 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...@ci
anuary 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
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 NI
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 a
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
>&
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
>
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 a
c.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 dec
request for
>additional private IP, nothing more.
>
>-kd
>
>
>
>>-Original Message-
>>From: Hari Kannan [mailto:hari.kan...@citrix.com]
>>Sent: Tuesday, December 18, 2012 4:32 PM
>>To: cloudstack-dev@incubator.apache.org
>>Subject: RE: Functional Specification
>Subject: RE: Functional Specification for the multiple IPs per NIC
>
>Hi Kelcey,
>
>The question is not whether CS knows this or not - the question is how does
a
>"user" know it..
>
>Here is the workflow I envision -
>
>User requests a VM
>As part
>From: Hari Kannan [mailto:hari.kan...@citrix.com]
>Sent: Tuesday, December 18, 2012 4:15 PM
>To: cloudstack-dev@incubator.apache.org
>Subject: RE: Functional Specification for the multiple IPs per NIC
>
>Regarding " User can specify the IP address from the guest subnet if
&
: Tuesday, December 18, 2012 4:15 PM
>To: cloudstack-dev@incubator.apache.org
>Subject: RE: Functional Specification for the multiple IPs per NIC
>
>Regarding " User can specify the IP address from the guest subnet if not
CS
>picks the IP from the guest subnet " comment in the F
l
>
>> -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 bas
gt; Thanks
>
>> -Original Message-
>> From: John Kinsella [mailto:j...@stratosec.co]
>> Sent: Tuesday, December 18, 2012 11:05 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: Functional Specification for the multiple IPs per NIC
>>
>> W
the instance metadata.
> -Original Message-
> From: Kelcey Damage (BT) [mailto:kel...@backbonetechnology.com]
> Sent: Tuesday, December 18, 2012 11:17 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Functional Specification for the multiple IPs per NIC
>
>
: Tuesday, December 18, 2012 11:05 AM
>To: cloudstack-dev@incubator.apache.org
>Subject: Re: Functional Specification for the multiple IPs per NIC
>
>Well, not quite. The question I might be clearly asking is: Do we build
MIPN
>now with intention to rewrite, or do we update the metada
-Original Message-
>> From: John Kinsella [mailto:j...@stratosec.co]
>> Sent: Tuesday, December 18, 2012 10:56 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: Functional Specification for the multiple IPs per NIC
>>
>> cloud-init's (m
I guess we are all in agreement them :)
>-Original Message-
>From: John Kinsella [mailto:j...@stratosec.co]
>Sent: Tuesday, December 18, 2012 10:56 AM
>To: cloudstack-dev@incubator.apache.org
>Subject: Re: Functional Specification for the multiple IPs per NIC
>
&
e made as configurable using global
>>> settings and default value will be 30.
>>>
>>>
>>> Thanks,
>>> Jayapal
>>>
>>>> -----Original Message-
>>>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
>
>-Original Message-
>From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
>Sent: Tuesday, December 18, 2012 10:50 AM
>To: CloudStack DeveloperList
>Subject: Re: Functional Specification for the multiple IPs per NIC
>
>Yes, that is a mere matter of updating the
ge (BT)"
wrote:
>
>
>>-Original Message-
>>From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
>>Sent: Tuesday, December 18, 2012 10:39 AM
>>To: CloudStack DeveloperList
>>Subject: Re: Functional Specification for the multiple IPs per NIC
>&g
>-Original Message-
>From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
>Sent: Tuesday, December 18, 2012 10:39 AM
>To: CloudStack DeveloperList
>Subject: Re: Functional Specification for the multiple IPs per NIC
>
>Sorry, not sure why cloud-init is be
Replies inline
>-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?
t;> 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 all
>> 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 w
eveloperList
> 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 A
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" wrote:
>I'd remove the limitation of having 30 IPs per interface. Modern OSes can
>support way mo
On Sat, Dec 15, 2012 at 3:55 PM, John Kinsella wrote:
> Good point, there…maybe what we need here is to beef up the password server
> idea to provide a standardized conduit to get info down to a VM. Similar to
> EC2's user-data.
>
> Data I could see this framework providing:
> * System password
Agreed, this sounds like a good direction to go, and would also fill the role
of 'guest agents(VMware tools, etc) as this would handle the standard use cases.
+1
I hope more people get in on this discussion.
Sent from my iPhone
On Dec 15, 2012, at 12:55 PM, John Kinsella wrote:
> Good point,
Good point, there…maybe what we need here is to beef up the password server
idea to provide a standardized conduit to get info down to a VM. Similar to
EC2's user-data.
Data I could see this framework providing:
* System passwords
* Additional IPs (so need to be able to return data sets, JSON
I forgot to add...
I second the notion that Basic Networking should be supported. I think this
feature targets basic more so anyways. With basics single network, direct
public IPs, managing aliases would allow far more flexibility to the platform.
Especially any one trying to host an SSL endpoi
This is a prime example where guest scripts make sense for automating the
interface alias creation. I still think I'm missing something however, does
this include a new fetch IP API?
Also the 30 IP limit seems out of place, when I can go in right now and give
any guest VM 256+ interface aliases
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
wrote:
> Hi All,
>
>
Just to be clear, this feature is to simply track multiple IPs in the ui/db
correct?
There is no mechanism to prevent an existing tenant from creating up aliases on
their subnet. So currently users can manually setup all the IPs they want in
guest VMs.
Sent from my iPhone
On Dec 14, 2012, at
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 fin
44 matches
Mail list logo
