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
>> >> >
>> >>
>> >
>> >
>>
>
>
