incubator-cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hari Kannan <>
Subject RE: [Discuss] Cpu and Ram overcommit.
Date Sun, 06 Jan 2013 23:57:15 GMT
While elaborating this feature, the following issue came to mind:

Admin could set various overcommit ratios (could setup a different ratio for each cluster,
for example) - however, unless he sets up host tags, does he or the end user have any control
over where the VM actually gets placed? If, so where is the use for this feature? I see it
as follows:

- Each cluster (depending on the hypervisor platform, storage or h/w configuration) can handle
a different number of VMs per host/cluster - trying to normalize them can be inefficient,
as the ratio has to be setup for the lowest common denominator - hence, we are providing a
finer granularity for better utilization of resource, irrespective of what the placement algorithm

- when combined with dedicated resources, it gets better - with dedicated resources, we will
have the capability to tell account A will use cluster X. If this account is paying for "gold"
quality of service, perhaps, those clusters would have a ratio of 1. If they are paying for
"bronze" QoS, their cluster ratio could be 2. 

To make it better, I wonder if we could introduce the notion of cluster tags? With cluster
tags, you could setup various overcommit ratios for each of the cluster (if needed) and by
matching service offerings, we could provide various quality of service to end users/accounts

If a cluster has a tag, each host "inherits" the tag - i.e. it is equivalent to setting each
host with the same tag as cluster tag
Any individual host could also have a tag - in which case, the default (inherited) cluster
tag, if present, is overwritten with the more specific tag provided for the host

Does it make sense? 

If it does, does it make sense to introduce tags to pods/zones? I feel probably not, but thought
I would ask any way

For clarification, my understanding of host tags as it stands currently is depicted at this

Please review and provide feedback


-----Original Message-----
From: Hari Kannan [] 
Sent: Wednesday, December 26, 2012 1:06 PM
Subject: RE: [Discuss] Cpu and Ram overcommit. 

What should the behavior be if admin changes the overcommit factor for a cluster that conflicts
with the current situation. For example, lets assume Cluster X has an over commit factor of
1.5x for memory and the admin wants to change this to 1x - i.e no overcommit (or changes from
2x to 1.5x) - however, based on the "older" factor, CS might already have assigned more VMs
- when the admin reduces the overcommit value

1. if there is no conflict, there is no issue 2a. if there is a conflict (i.e. current allocation
would conflict with the new value) - should we reject this change?  (preferred) 2b. or accept
the change but not add more VMs anymore

-----Original Message-----
From: Bharat Kumar []
Sent: Wednesday, December 26, 2012 4:39 AM
Subject: Re: [Discuss] Cpu and Ram overcommit. 

Nitin thanks for your suggestions.

My comments inline

On Dec 26, 2012, at 3:22 PM, Nitin Mehta <> wrote:

> Thanks Bharat for the bringing this up. 
> I have a few questions and suggestions for you.
> 1. Why do we need it per cluster basis and when and where do you configure this ? I hope
when we change it for a cluster it would not require MS reboot and be dynamically understood
- is that the case ?
    Depending on the applications running in a given cluster the admin needs to adjust the
over commit factor. for example if the        applications running in a cluster are ram intensive
he may want to decrease the ram overcommit ratio for this cluster without effecting the other
clusters. This can be done only if the ratios can be specified on a per cluster basis. 
Also to change these ratios MS restart will not be required.
> If we make it cluster based allocators will have to check this config for each cluster
while allocating and can potentially make allocators expensive. Same logic applies for dashboard
calculation as well.
> What granularity and fine tuning do we require - do you have any use cases ?
   The intent of having cluster based over provisioning  ratios is to deploy VMs selectively
depending on the type of application the vm will run. By selectively i mean the admin will
want to specify in which clusters to run the VM. This will narrow down the number of clusters
we need to check while deploying.  I still don't know the exact way in which we should control
the vm deployment. This definitely needs further discussion, will be clear once we narrow
down all the possible use cases.

> 2. What would happen in case of contention ?
In case of contention the the hypervisor specific methods to handle the contention will come
into effect. This feature assumes that admin has thought of the possible scenarios and has
chosen the overcommit ratios accordingly.
> 3. Please remember to take care of alerts and dashboard related functionality. Along
with this also list Zone/Pod.../host/pool API also use this factor. Please make sure that
you take care of that as well.
Thanks for the suggestions. 

> -Nitin
> On 26-Dec-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
>> 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