cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus <shadow...@gmail.com>
Subject Re: Reserved Guest VM CIDR Question
Date Mon, 06 Oct 2014 20:04:54 GMT
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 <shadowsor@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 <lbarfield@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 <lbarfield@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 <shadowsor@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" <lbarfield@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
>> >> >
>> >>
>> >
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message