cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abhinandan Prateek <Abhinandan.Prat...@citrix.com>
Subject Re: [Discuss] Cpu and Ram overcommit.
Date Fri, 18 Jan 2013 10:23:18 GMT
Bharat,
  
   I guess you can start work on this.

   FS is here 
https://cwiki.apache.org/CLOUDSTACK/cpu-and-ram-overcommit.html

-abhi

On 18/01/13 3:23 PM, "Bharat Kumar" <bharat.kumar@citrix.com> wrote:

>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 [mailto:bharat.kumar@citrix.com]
>Sent: Thursday, 17 January 2013 11:01 PM
>To: cloudstack-users@incubator.apache.org
>Cc: cloudstack-dev@incubator.apache.org
>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 <Alex.Huang@citrix.com> 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 [mailto:bharat.kumar@citrix.com]
>>> Sent: Tuesday, January 08, 2013 3:16 AM
>>> To: cloudstack-users@incubator.apache.org
>>> Cc: cloudstack-dev@incubator.apache.org
>>> 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 <bharat.kumar@citrix.com>
>>> 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.
>> 
>


Mime
View raw message