Logan,

The reason why reservation is not enabled in create stage is the case of 
External network devices. 
When using external devices like NetScaler, CloudStack will not have a 'real' 
cidr unless the network has been implemented.
So a cidr like /24 used at time of create may turn to /20 when the network has 
been implemented and then it make no sense for reservation in initial stage.
What I will suggest is to create a network offering with 'Persistent' as true.
So your network will be implemented when you create it and VR will be up. Once 
the network has been implemented you can apply reservation.


Thanks,
Saksham


-----Original Message-----
From: Logan Barfield [mailto:lbarfi...@tqhosting.com] 
Sent: Tuesday, October 7, 2014 12:27 AM
To: dev@cloudstack.apache.org
Subject: Reserved Guest VM CIDR Question

We have decided internally to set up a CIDR reservation with all new accounts 
to give us the ability to easily attach dedicated hosts to existing VM networks.

We were thinking it would be easier to set up the reservation before deploying 
VMs.  Setting up reservation after the fact can get complicated if a VM happens 
to be outside the intended reservation range.

The issue we're having is that reservation is not allowed until the network is 
in the "Implemented" state (i.e. after the first VM is deployed).

Why is reservation not allowed upon initial network creation?  If we try to 
apply reservation after the first VM is online the command will fail 
occasionally because the first VM is deployed outside the CIDR range.

Example:

Guest Net: 10.1.1.0/24
Reserved CIDR: 10.1.1.0/25

- Attempt reservation before deploying a VM: Fails due to network not being 
"Implemented"
- Attempt reservation after many VMs are deployed: Fails due to VMs being 
outside Reserved CIDR (e.g., 10.1.1.150), and requires a lot of work to change 
the VM's IP
- Attempt reservation after first VM is deployed: Either succeeds, or fails if 
the first VMs IP is outside of the reserved CIDR.

How can we fix this without hacking work arounds into the deployment logic?
 (ex: Check network for 10.1.1.10, if it doesn't exist deploy the VM on that 
IP, if it already exists deploy it wherever.)

Thank You,

Logan Barfield
Tranquil Hosting

Reply via email to