cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alena Prokharchyk <>
Subject Re: [PROPOSAL] Introduce API returning you an answer from CloudStack storage/host allocators whethere there is enough resources for vm deployment
Date Mon, 03 Feb 2014 18:03:14 GMT
Thank you everyone for responding with your concerns and ideas. After
analyzing all the input and talking to Alex, I would like to recall the
original proposal as:

1) The call doesn't actually do any resource reservation, there is no
guarantee that subsequent VM call wouldn't fail if executed some time
2) It's not very useful to the check for a SINGLE vm, only to deploy this
single vm later. What would make more sense - to check if we can
accomodate "n" number of vms, and may be even to reserve the capacity for

After reviewing all the suggestions, we should probably do this in the

1) Introduce the call reserveCapacityForVirtualMachine. You can execute
the call with "count" parameter to reserve the capacity for "n" vms w/o
actually deploying them on the backend(no actual volume creation on
storage, no vm start on the host).
2) Enhance deployVm call with "count" parameter. Before actual vm
deployment, reserveCapacity underlying method should be called to reserve
the capacity for all "n" vms requested in the call.
3) Improve InsufficientCapacity error messages returned when deployVm
fails to return more clear reason for vm deployment failure.

Let me know what you all think,

On 2/3/14, 9:55 AM, "Alex Huang" <> wrote:

>What's really needed is a reserve API.  It would be a big undertaking
>though as that concept is not in any of the network and storage plugins.
>> -----Original Message-----
>> From: David Nalley []
>> Sent: Monday, February 3, 2014 6:10 AM
>> To:
>> Cc: Prachi Damle
>> Subject: Re: [PROPOSAL] Introduce API returning you an answer from
>> CloudStack storage/host allocators whethere there is enough resources
>> vm deployment
>> Hi Alena:
>> I am not sure that I see a ton of value in this - and let me explain
>> 1. This could potentially be an information disclosure issue - Could I
>> potentially see how much storage or other resources are available.
>> Does
>> 2. At any scale things are going to potentially change rapidly, so a
>>delay of 5
>> minutes may mean that the content is outdated and no longer valid.
>> 3. Most importantly deploying a single machine isn't interesting, and
>> would I bother checking. (And this also brings up one of the things I
>> lacking in the deployVM API call.) What I'd be interested in knowing is
>> whether I could deploy 5, 50, or 500 machines. Perhaps adding a count
>> parameter to the deployVirtualMachine would help (and the corresponding
>> API call to check that resources are
>> available.)
>> --David
>> On Fri, Jan 31, 2014 at 7:26 PM, Alena Prokharchyk
>> <> wrote:
>> > Currently there is no way to know if there is enough resources for vm
>> deployment, before actual deployVm call is made. The sequence is the
>> following:
>> >
>> > 1) Deploy Vm is called
>> > 2) DB record is created for the Vm
>> > 3) Storage/Host allocators determine whethere there are enough
>> resources for vm to be deployed, and return deploy destination to the
>> stack.
>> > 4) If allocator returns valid deploy destination, VM gets actually
>> created/started on the backend. If allocators don't return the
>> the DB record created on step 2) gets destroyed, and ResourceAllocation
>> exception is thrown back to the API caller.
>> >
>> > The API I'm going to introduce, would help you to determine whether CS
>> physical resources - hosts, storages - can potentially accomodate vm
>> deployment (considering template/service/diskOffering) at a given time,
>> w/o actually calling the deploy vm. Some admins might find this call
>>useful as
>> they can always make this check before submitting the deployVm, so in
>> it returns NO, you can fail the deployment immediately, w/o calling
>> deployVm. Also you can make this call to determine what is lacking for
>> vm deployment, and expand your physical resources accordingly.
>> >
>> > Please let me know if see any pitfalls in the proposal, as well if
>>you see any
>> other use cases that can be solved using this API.
>> >
>> > Prachi, can you please point me to an existing method (or interface)
>> defined in Allocators code serving this purpose?
>> >
>> > Thanks,
>> > -Alena.

View raw message