cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "saksham srivastava" <>
Subject Re: Review Request: IP Address Reservation within a Network
Date Fri, 01 Feb 2013 12:40:48 GMT

> On Feb. 1, 2013, 11:07 a.m., Murali Reddy wrote:
> > Also its not clear to me, how you are ensuring that IP is allocated only from the
guest CIDR range when its different from the network CIDR?

Murali, thanks a lot for your reviews. I am answering all your queries here.

For this feature a column guest_cidr is added in networks table. So there are now 2 columns
in the table "cidr" and "guest_cidr".

1) For non isolated guest networks there has been no change at all, the "cidr" column continues
to be the way it used to be i.e. the network cidr.
   and "guest_cidr" always continues to be null, throughout the life cycle.


2) For isolated guest networks :

Whenever a network is created, "cidr" will have network cidr and "guest_cidr" will be null.(The
way it has been working).

When there is no reservation, "guest_cidr" is null, and "cidr" continues to be the network

When first time reservation happens, a valid guestvmcidr is passed as parameter in updateNetwork

"guest_cidr" copies the value of network cidr from "cidr" column
and "cidr" gets populated with guestvmcidr
so "cidr" is now the effective IP range for guest vms.

Now for the next time when reservation is reapplied, the "guest_cidr" already has network
cidr and 
"cidr" gets again re-popluated by the new guestvmcidr passed in the API.
Same continues for every subsequent reservation.

Guest VMs always pick IPs from "cidr" as usual and thus reservation gets applied.

In short "guest_cidr" will now always have the network cidr
"cidr" will always have the guestvmcidr value

When the network is reimplemented like in case of upgrade to ext offerings :

 "cidr" is set to network cidr by copying the value from "guest_cidr"
 "guest_cidr" is reset to null to avoid an inconsistent state after the reimplementation.
 After reimplementation "cidr" will have the new network cidr and "guest_cidr" will be null
and reservation can now be reapplied.
 The reason of doing this was not to touch Gurus and NetworkManagerImpl at all and also not
to alter the functionality of "cidr" and continue 
 it to serve as the address space for Guest VMs.
 guestcidr is the network cidr
 cidr is the effective cidr for guest vms
 reserved_ip_range is list of IPs to be used for non cloudstack purposes.

 The reason to add reserved_ip_range is to help reduce the IP calculations by admin.
 For instance :
 guestcidr =
 reservediprange : ,
 So to ease the calculation for the admin and also list the reservation range which is the
prime aim of this feature, reservediprange is added.

 I would sincerely agree to document both the request and response to avoid any ambiguity.

- saksham

This is an automatically generated e-mail. To reply, visit:

On Feb. 1, 2013, 10:34 a.m., saksham srivastava wrote:
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> -----------------------------------------------------------
> (Updated Feb. 1, 2013, 10:34 a.m.)
> Review request for cloudstack, Murali Reddy and Chiradeep Vittal.
> Description
> -------
>     CLOUDSTACK-705 IP Address reservation for Isolated Guest Networks
> CloudStack uses Guest CIDR for dhcp-range for the Guest VMs. The entire CIDR is used
by CloudStack for assigning IPs to Guest VMs.
> IP Address Reservation will allow part of address space to be used for non CloudStack
hosts/physical servers also, by restricting the address space of CloudStack Guest VMs.
> Reservation can be configured using update Network API by specifying guestvmCidr as an
additional parameter.
> Reservation will be applicable for Isolated Guest Networks including VPC.
> reservediprange in the response will return the IP range that can be used for non Cloudstack
> This addresses bug CLOUDSTACK-705.
> Diffs
> -----
>   api/src/com/cloud/network/ a70bf02 
>   api/src/com/cloud/network/ e3be941 
>   api/src/com/cloud/network/ 786afb1 
>   api/src/com/cloud/network/vpc/ 68e062c 
>   api/src/org/apache/cloudstack/api/ d895191 
>   api/src/org/apache/cloudstack/api/command/user/network/ 978c71b

>   api/src/org/apache/cloudstack/api/response/ 40d6850 
>   server/src/com/cloud/api/ 2dcd09c 
>   server/src/com/cloud/network/ 5c70caa 
>   server/src/com/cloud/network/ 8020e7a 
>   server/src/com/cloud/network/vpc/ 26e882e 
>   server/test/com/cloud/network/ af0b03f 
>   server/test/com/cloud/vpc/ 382068a 
>   server/test/com/cloud/vpc/ 25799d1 
>   setup/db/create-schema.sql a847b43 
>   setup/db/db/schema-40to410.sql 6d5b262 
> Diff:
> Testing
> -------
> Tested manually the following scenarios:
> Applying reservation when there are running VMs inside the guest_vm_cidr.
> Applying reservation when there are running VMs outside the guest_vm_cidr.(not allowed)
> Applying reservation when external device like Netscaler is configured in the guest_cidr.
> Applying reservation in VPC tiers.
> Applying reservation outside the range of guest_cidr.(not allowed)
> Thanks,
> saksham srivastava

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message