Page History

Introduction:

Currently in cloudstack we can add multiple public ip ranges. we want to provide similar flexibility for management and guest ip ranges.
Presently we can add multiple guest ip IP ranges within the same subnet (Basic zone) in Basic Zone and Advanced sg enabled zones, but we cannot add ip IP ranges form different subnets.This feature provides this functionality for adding guest ip ranges (for IP ranges from different subnets in Basic zone ) and management ip range for both the advanced and basic zonesand advanced SG enabled networks. In case Advanced sg enabled network adding ip range to a sg enabled network form different subnet implies we add two or more subnets in the same vlan.

Use case:

There may be cases where some part of the subnet is allocated for some other purpose and the admin wants to use the rest of the ip range or admin may want to add more ip IP address once the old ones are exhausted. Admin may want to add the ip IP ranges form the same subnet or from different one. Currently in cloudstack there is no flexibility to do this for management and guest ip ranges (ip ranges from different subnets)IP ranges.

Design description:

...

Addition of guest IPs in Basic and Advanced SG enabled zones.

presently the createVlanIpRange api API is used to add the guest ip IP range to a network (shared) in basic zone. The ips IPs mentioned in this range are assigned to the guest VMs. These are public ips IPs and allow guest to communicate with the internet. Presently we can add multiple ranges form the same subnet but not from a different one. This feature will extend the createVlanIpRange to add guest ips IPs from a different subnet, to a shared network in basic zone.
In the present implementation one subnet can have only one gateway. we do no allow overlapping subnets.

APIs:

for description of existing parameters please refer this page. http://incubator.apache.org/cloudstack/docs/api/apidocs-4.0.0/root_admin/createVlanIpRange.html

Validation.
#1 Will fail if the zone is not a basic zone or if forvirtual network is true.
#2 Will fail if the ip is from a different subnet, netmask and gateway should be providednew subnet is subset or superset of the existing subnet.

Implementation detail.
In cases where a ip IP range form a different subnet is added, we need to configure an nic a ipalias on the DHCP server with a ip IP form the this new subnet or add this ip from different to the existing nic. This is required as the ip IP to the guest VMs is allocated using a DHCP server. So the router should have a interface on the new subnet to listen for the DHCP request coming form VMs in the new subnet.

execution flow.
#1 validate the inputs.
#2 if Add the ip new range is form the new subnet add the new range.
pick one of the ips form the new range and configure a interface with this ip on the VR.
configure the DHCP server to listen on this new interface.(Also need to configure the DHCP server to work with the new interface.)
#3 if not form a different subnet add themto the DB.
#3 When the first ip from the new subnet is allocated to the VM, create a new ip alias to the existing nic on the VR. This ip alias (example eth0:1) will have one of the IPs from the new subnet.

Note. The admin should manually configure the gateway of the new subnet before adding the ip IP range.

For Basic and Advanced Zone Management(pod) IPs.
Currently there is no way to add additional pod ip ranges. This feature will enable adding pod IP ranges from same subnet or different subnet. The pod ipranges are assigned to router vms and systemvms. The ip configuration is passed in as boot args. So in this case we need not configure the DHCP server.

API

Description of parameters.

validation.
#1 We modify the checkpodAttributes function in configurationManagerImpl by removing the check for IP ranges which do not belong to the same cidr (cidr of the pod.)

execution flow.
#1 validate the input.(This will be done using the checkpodAttributes function of the configureationManagerImpl).
#2 Add the new range.

DB changes:

removing the the guest IPs.

We intend to use the deleteVlanRange API to delete the IP ranges. The operations will be atomic. this will fail if any IP form the remove range is being used. While removing we acquire a lock on the valn that is being removed. The Ip Alias created on the virtual router will be removed when the last VM or Nic form the subnet is removed.

DB changes:

created a new table nic_ip_aliase which is used to store the details of the ipalias created on the router per subnet.

Supported Hypervisors.

KVM, XenServer, VMware

Note:
The implementation as of now supports only Ipv4 addresses No Database changes are required.