cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Logan Barfield <lbarfi...@tqhosting.com>
Subject Re: Reserved Guest VM CIDR Question
Date Mon, 06 Oct 2014 20:13:37 GMT
Yeah, that was my result as well.

It seems like you should be able to specify a 'guestcidr' when creating the
network, or at least with 'updateNetwork' without the network being in the
"Implemented" state.  I'm sure there's a reason for it being that way, but
it doesn't make much intuitive sense.

Unless I'm missing the point of the IP reservation feature this issue is
probably just the result of bad design decisions somewhere.

Does anyone know why it's required for the network to be "Implemented"
before specifying the reserved CIDR?  Does "Implemented" indicate that the
Virtual Router has been created/online, or that a VM has been deployed on
the network?  If it's just a Virtual Router check, is there a way to force
the Virtual Router to be created when creating the network, instead of
having it deploy when the first VM is created?


Thank You,

Logan Barfield
Tranquil Hosting

On Mon, Oct 6, 2014 at 4:04 PM, Marcus <shadowsor@gmail.com> wrote:

> 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