Hmm, well that used to work, but I just tried it with a 4.4 release and it completely ignored the startip and endip parameters. I know at one point there was a db entry allocated for every ip in the range. It was not a good way to keep the info (large networks == lots of entries), so it may have been refactored out recently and as a result this may no longer work. Just speculation.
On Mon, Oct 6, 2014 at 2:00 PM, Marcus <shadow...@gmail.com> wrote: > Here's an example: > > create network vpcid=7276bcca-469c-4d23-9dd1-3391e964c453 > displaytext=testnet zoneid=5e5f35d3-acb1-4142-84c2-e7f0ea7a36f4 > name=testnet networkofferingid=82c67af0-f92e-479d-b1b4-8732abeef9b7 > gateway=10.10.10.1 netmask=255.255.255.0 startip=10.10.10.100 > endip=10.10.10.110 > > This results in a 10.10.10.0/24 network created in this vpc, with > cloudstack allocating 10.10.10.100 through 10.10.10.110. I'm using it in a > VPC, but it should work the same for any guest network.seqselect * from > > { > "network": { > "account": "admin", > "acltype": "Account", > "broadcastdomaintype": "Vxlan", > "broadcasturi": "vxlan://10124", > "canusefordeploy": true, > "cidr": "10.10.10.0/24", > "displaynetwork": true, > "displaytext": "testnet", > "dns1": "199.58.198.240", > "domain": "ROOT", > "domainid": "d86c4370-bbdf-11e2-8bb5-52540014c04d", > "gateway": "10.10.10.1", > "id": "97b72d89-d81b-4582-a049-469dc42ad806", > "ispersistent": true, > "issystem": false, > "name": "testnet", > "netmask": "255.255.255.0", > "networkdomain": "cs2cloud.internal", > "networkofferingavailability": "Optional", > "networkofferingconservemode": false, > "networkofferingdisplaytext": "customer internal networks", > "networkofferingid": "82c67af0-f92e-479d-b1b4-8732abeef9b7", > "networkofferingname": "VPC Private Without Load Balancer", > "physicalnetworkid": "51617cd5-4715-495d-8931-f5d56e2af2bc", > "related": "97b72d89-d81b-4582-a049-469dc42ad806", > "restartrequired": false, > "specifyipranges": false, > "state": "Implemented", > "strechedl2subnet": false, > "tags": [], > "traffictype": "Guest", > "type": "Isolated", > "vlan": "10124", > "vpcid": "7276bcca-469c-4d23-9dd1-3391e964c453", > "zoneid": "5e5f35d3-acb1-4142-84c2-e7f0ea7a36f4", > "zonename": "testzone" > } > } > > > On Mon, Oct 6, 2014 at 1:49 PM, Logan Barfield <lbarfi...@tqhosting.com> > wrote: > >> Specifying IPs doesn't work, and in the network details I see that >> "specifyipranges" is set to false. >> >> I should probably note that this is using Advanced Networking with an >> Isolated Guest Network. >> >> >> Thank You, >> >> Logan Barfield >> Tranquil Hosting >> >> On Mon, Oct 6, 2014 at 3:34 PM, Logan Barfield <lbarfi...@tqhosting.com> >> wrote: >> >> > Hi Marcus, >> > >> > I'll give that a shot. I didn't know if those parameters specified the >> > network CIDR or the guest CIDR. >> > >> > >> > Thank You, >> > >> > Logan Barfield >> > Tranquil Hosting >> > >> > On Mon, Oct 6, 2014 at 3:15 PM, Marcus <shadow...@gmail.com> wrote: >> > >> >> Do startip and endip createNetwork parameters not work for that (when >> >> creating the network? That should carve out a subset of the network for >> >> cloudstack use and leave the rest untouched. >> >> On Oct 6, 2014 12:57 PM, "Logan Barfield" <lbarfi...@tqhosting.com> >> >> wrote: >> >> >> >> > 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 >> >> > >> >> >> > >> > >> > >