Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of shadowsor@gmail.com
 designates 209.85.220.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CACKLxkD76LpZW71NOi1AHprA43Pjn4BwxjFEEn49Or62ApYGEg@mail.gmail.com>
References: 
 <CACKLxkD76LpZW71NOi1AHprA43Pjn4BwxjFEEn49Or62ApYGEg@mail.gmail.com>
Date: Mon, 6 Oct 2014 13:15:57 -0600
Message-ID: 
 <CALFpzo7rgpu2dQ2wE1cb9rMNLL__4gUQEiamWN8Da5owF-mNiw@mail.gmail.com>
Subject: Re: Reserved Guest VM CIDR Question
From: Marcus <shadowsor@gmail.com>
To: dev@cloudstack.apache.org
Content-Type: multipart/alternative; boundary=001a1133c43a8ffa2a0504c5e93c

--001a1133c43a8ffa2a0504c5e93c
Content-Type: text/plain; charset=UTF-8

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
>

--001a1133c43a8ffa2a0504c5e93c--