cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nitin Mehta <>
Subject Re: [Discuss] Cpu and Ram overcommit.
Date Tue, 08 Jan 2013 11:45:57 GMT
Hari - Please find my answers inline.

On 07/01/13 5:27 AM, "Hari Kannan" <> wrote:

>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 decides
>- 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?

It does make sense :). However I think the cluster tag is always
inherited. If the host has a tag it should not overwrite the cluster tag
but add to its list.
Another question is that do these tags get inherited only for hosts or
also the storage ? In case of storage motion coming do we then restrict
the migration of these vms to supported clusters only ?
Also if the storage also inherits the tags then even the volume migration
will happen in supported clusters only. I think it makes 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

At this point not. Do we set anything at pod level which will affect say
QOS or similar ? I guess not so no use having pod tags.

>For clarification, my understanding of host tags as it stands currently
>is depicted at this link
>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
>> 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 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