cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bharat Kumar <>
Subject Re: [Discuss] Cpu and Ram overcommit.
Date Tue, 22 Jan 2013 05:45:02 GMT
Hi Prashant,

My comments in line.

On Jan 22, 2013, at 12:02 AM, Prashant Kumar Mishra <>

> Hi,
> I have reviewed  Cpu and Ram overcommit  and below are my review comments:
> 1-In case admin set overcommit ratio very low which may cause underutilization, will
CS suggest admin to set overcommit ratio to some fine-tuned value  base on previous  record.
Cs will not suggest any overcommit ratios to the admin, It is left to the admin to decide
the values of overcommit ratios.  

> 2-If admin want to set all the cluster to a common overcommit factor , are we going to
provide any global parameter for that
> Use case: 
> Say there is n cluster , and they all are qualifying  admin requirement of having overcommit
ratio say 1.5x ( of course there can be some cluster say 2% of n , supports overcommit factor
>1.5x, but to utilize these 2 % of cluster admin have to go one by one which is not very
likely to happen ) instead of going to update one by one admin would like to set all in one
No there is no way to specify the overcommit values for all the clusters globally, In fact
we are actually making the overcommit configuration more granular. 
> 3-To add host which strategy is going to be in use
> A.) Don't allow adding a host which has no capability of overcommitting resources to
a cluster.
> B.) Add the host but do not consider it for vm allocation until it is updated. if we
are changing a non-overcommit cluster to a overcommit cluster and if it has incapable hosts,
we will allow them to be a part of the cluster but disable further allocation of VMs to these
hosts until they are upgraded to have the overcommit capability
I think we should go with A i.e. don't allow a host without overcommit capability to join
a cluster with overcommit. Similarly  to change the overcommit value ( to > 1)of a cluster
previously not overcommitting, all the hosts in the cluster should be capable of overcommiting.

> 4-How we are calculating  fine tune overcommit factor , is it based on previous records.
We don't calculate the overcommit values these are set by the admin.
> 5- How we are handling hypervisor  Memory  exhaustion .
If you mean what will happen at the time of contention for resources, all the VMs at the time
of contention will be using the minimum amount of memory guaranteed to it in case of xenserver.
The overcommit values should be set carefully after taking the scenario of contention into

> 6-while deploying  vms how we are going to make sure that it will go  to a specific cluster
, are we going to use cluster level tag, Or we are going to use dedicated resource method
as described in FS.
I think we will use dedicated resources for now and may be in future implement something like
cluster tags.

> Thanks 
> Prashant kumar Mishra
> -----Original Message-----
> From: Bharat Kumar [] 
> Sent: Friday, January 18, 2013 3:23 PM
> To:
> Cc:
> Subject: RE: [Discuss] Cpu and Ram overcommit. 
> Hi  All,
> I have included  the information form the discussions in the functional spec  and I think
we have sufficient  information  to start the implementation.
> -----Original Message-----
> From: Bharat Kumar []
> Sent: Thursday, 17 January 2013 11:01 PM
> To:
> Cc:
> Subject: Re: [Discuss] Cpu and Ram overcommit. 
> Alex thank you for your suggestions, I  will add them to the functional spec.
> Bharat.
> On Jan 16, 2013, at 4:19 AM, Alex Huang <> wrote:
>> Bharat,
>> A few comments.
>> - On your caveats, I think you should deploy 2b.  Accept the change but not add more
VMs anymore.  You can provide a warning.
>> - As for repeated alerts, that's a problem with the alert mechanism.  It should not
repeat alerts.  Fix it there.
>> On implementation:
>> - You need to add something more generic such as a cluster-details to cluster that
allows you retrieve what you want to add to it.  I don't see any reason to keep adding columns
to cluster/pods.  Cluster/pods are organization units.  We should add a details table (might
already there) to keep component details because no one else will use this detail information.
 I don't see why we need to add database columns for this.
>> - How are you planning to handle hypervisors that cannot overcommit cpu or ram? 
To me this needs capabilities added to the hypervisor caps table.
>> - This is a planner specific change.  Make sure the changes are localized in the
planner.  If there's anything you need to change in CloudStack core/server, please point that
out in a subtask for your bug and let me know.
>> --Alex
>>> -----Original Message-----
>>> From: Bharat Kumar []
>>> Sent: Tuesday, January 08, 2013 3:16 AM
>>> To:
>>> Cc:
>>> Subject: Re: [Discuss] Cpu and Ram overcommit.
>>> Hi Hari,
>>> A host can have more than one tag so we need not overwrite the 
>>> inherited cluster  tag of a host, if a host specific tag is added.
>>> Bharat
>>> On Dec 26, 2012, at 11:32 AM, Bharat Kumar <>
>>> wrote:
>>>> Hi all,
>>>> Presently in Cloudstack  there is a provision for cpu overcommit and 
>>>> no
>>> provision for the ram overcommit. There is no way to configure the 
>>> overcommit ratios on a per cluster basis.
>>>> So we propose to add a new feature to allow the ram overcommit and 
>>>> to
>>> specify the overcommit ratios ( cpu/ram ) on a per cluster basis.
>>>> Motivation to add the feature:
>>>> Most of the operating systems and applications do not use the 
>>>> allocated
>>> resources to 100%. This makes it possible to allocate more resource 
>>> than what is actually available.  The overcommitting of resources 
>>> allows to run the underutilized VMs in fewer number of hosts, This saves money
and power.
>>> Currently the cpu overcommit  ratio is a global parameter which means 
>>> there is no way to fine tune or have a granular control over the overcommit ratios.
>>>> This feature will enable
>>>> 1.) Configuring the overcommit ratios on a per cluster basis.
>>>> 2.) ram overcommit feature in xen and kvm. ( It is there for
>>>> VMware.)
>>>> 3.) Updating the overcommit ratios of a cluster.
>>>> Regards,
>>>> Bharat Kumar.

View raw message