DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.

DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
Currently in cloudstack we can add multiple public IP ranges in Advanced zone. we want to provide similar flexibility for management and guest IP ranges.
Presently we can add multiple guest IP ranges within the same subnet in Basic Zone but we cannot add IP ranges form different subnets.
This feature provides this functionality for adding guest IP ranges in Basic zone and management IP range for both the advanced and basic zones.
There may be cases where admin may want to add more IP address once the old ones are exhausted. Admin may want to add the IP ranges form the same subnet or from different one. Currently in cloudstack there is no flexibility to do this for management Ips and guest IP ranges.
presently the createVlanIpRange API is used to add the guest IP range to a network (shared) in basic zone. The IPs mentioned in this range are assigned to the guest VMs. These are public 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 from a different subnet, to a shared network in basic zone.
API Name |
API parameters |
API response |
Available only for root admin |
|---|---|---|---|
createVlanIpRange |
Using the existing parameters. no new parameters will be added |
returns the IP ranges |
yes |
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 if the IP is from a different subnet, netmask and gateway should be provided.
Implementation detail.
In cases where a IP range form a different subnet is added, we need to configure an nic with a IP form the this new subnet or add this IP to the existing nic. This is required as the 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 Add the new range to the DB.
#3 When the first ip from the new subnet is allocated to the VM, create a new virtual interface to the existing nic on the VR. This virtual interface (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 range.
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. When the subnet is removed the ip alias corresponding to this subnet will be removed form the VR.
No Database changes are required.
KVM, XenServer, VMware