incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <>
Subject Re: [DISCUSS] IP Address Reservation within a network
Date Fri, 18 Jan 2013 23:39:30 GMT
The current way of inferring a cidr from gateway and netmask is odd. I
support the addition of a 'cidr' parameter to the createNetwork API. If it
is supplied then that should be the basis of specifying the cidr rather
than the gateway/netmask combo.

On 1/17/13 8:07 AM, "Sowmya Krishnan" <> wrote:

>Hi Saksham,
>To comment on your question:
>>>	Should shared guest networks also allow for IP reservation considering
>>>the current scenario where Start IP and End IP are mandatory during
>>>shared guest network creation.
>Isn't this functionality already implicitly present for shared networks
>since we specify network and start, end IPs during creation?
>Few comments on the FS:
>1. What is the reason for using Start IP and End IP in place of CIDR? Is
>it to make it consistent with shared Network? Considering the edge case
>which you've mentioned in the FS - Case 5, the Guest VM CIDR would occupy
>the entire n/w and no reservation will be possible in that n/w for that
>range. Isn't it better to use CIDR?
>2. While reserving IPs for new or existing n/w, is it allowed to have
>non-contiguous IP ranges? Ex: I want to reserve -
> This in effect leads to non-contiguous Guest IP Range. In
>this case will we end up having multiple Guest CIDRs for the network?
>3. After updating a guest n/w with reserved IPs, will the network be
>re-implemented? It should ideally not..
>4. While updating a guest n/w with reserved IPs following checks should
>be performed:
>   4a. Only expansion is possible
>   4b. The range is contiguous (if answer to 2 is No)
>   4c. If using default CIDR, newly defined Guest CIDR should match the
>existing one
>5. In case of network offerings using external devices, user cannot
>currently define CIDR - this constraint will continue to exist for IP
>reservation too? Or will extending IP range be allowed in the existing
>n/w and then allow reservation over the new range defined?
>6. In the DB, is it necessary to store both Start IP-End IP along with
>guest_vm_cidr? Wouldn't effective cidr suffice since it's derived?
>-----Original Message-----
>From: Saksham Srivastava []
>Sent: Tuesday, January 15, 2013 10:37 PM
>Subject: [DISCUSS] IP Address Reservation within a network
>Please find the  FS for the feature at
>Few of the points I want to bring for discussion:
>1) Extending the functionality to shared network
>	Should shared guest networks also allow for IP reservation considering
>the current scenario where Start IP and End IP are mandatory during
>shared guest network creation.
>2) Extending the GuestVm CIDR once a network is setup.
>	Ideally GuestVM CIDR can be extended to be equal to Guest CIDR. But
>Extending the range requires evaluation of each IP in the extended range
>whether it has been allocated or not.
>	Ping test is a primitive solution as ICMP denying hosts may not respond.
>Need suggestions on that.
>Saksham Srivastava
>-----Original Message-----
>From: Saksham Srivastava []
>Sent: Thursday, January 10, 2013 12:19 PM
>Subject: RE: [DISCUSS] IP Address Reservation within a network
>Using VLSM at the zone creation the admin can create multiple subnets
>from a parent subnet, but that is not what we are targeting at.
>CloudStack admin should not be interested to create a subnet for Non
>CloudStack hosts IMHO.
>This particular requirement is to only have a definite subnet for
>CloudStack Guest VMs and all other IPs in the parent subnet can be
>assigned to non CloudStack purposes.
>From: Kelcey Damage (BT) []
>Sent: Friday, January 04, 2013 11:56 PM
>Subject: RE: [DISCUSS] IP Address Reservation within a network
>So I see this and now wonder why do we even specify the guest CIDR at
>zone creation? Why not just use VLSM at network creation? Or some other
>instance in time controlled by the client/admin provisioning process.
>>-----Original Message-----
>>From: Saksham Srivastava []
>>Sent: Friday, January 04, 2013 9:41 AM
>>Cc: Manan Shah; Chiradeep Vittal
>>Subject: RE: [DISCUSS] IP Address Reservation within a network
>>The admin can specify the CIDR to be used for guest VMs (Guest CIDR)
>>during advanced zone creation.
>>This CIDR is used by default for the Guest Networks.
>>The proposed plan is to have a new parameter say "CS-GuestVM CIDR"
>>which will be a subset of the Guest CIDR.
>>For instance at the time of zone creation the Guest CIDR is
>>"CS-GuestVM CIDR" is specified as So the remaining IPs can
>>now be used for Non Cloudstack VMs/Physical servers.
>>The plan is to now use  only  as the CIDR for Cloudstack
>>Currently when the user wants to create a new Guest network , he
>>specifies the gateway and subnet mask.
>>The proposal is that he will have additional options to specify the
>>and end range for guest vms. The remaining IPs can then  be used for
>>Non Cloudstack vms.
>>Also the ranges will be frozen once the network is created.
>>-----Original Message-----
>>From: Chiradeep Vittal []
>>Sent: Thursday, January 03, 2013 12:59 PM
>>To: CloudStack DeveloperList
>>Cc: Manan Shah
>>Subject: Re: [DISCUSS] IP Address Reservation within a network
>>The proposed workflow seems counter-intuitive to me from an end-user
>>How about: reserve a range of *usable* ip addresses. Then the admin is
>>free to use the remainder of the range.
>>1. Is it one range or multiple?
>>2. Are there update semantics, or are the ranges frozen once the
>>network is created?
>>On 12/31/12 2:11 AM, "Saksham Srivastava"
>>>Hi all,
>>>I have started looking into this feature and would like to have the
>>>community feedback/suggestions on it.
>>>I would be sharing the FS shortly.
>>>On Saturday 22 December 2012 06:51 AM, Manan Shah wrote:
>>>> Hi,
>>>> I would like to propose a new feature for IP Reservation within a
>>>> I have created a JIRA ticket and provided the requirements at the
>>>>following location.  Please provide feedback on the requirements.
>>>> JIRA Ticket:
>>>> Requirements:
>>>> +within+a+Network
>>>> Regards,
>>>> Manan Shah

View raw message