cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prashant Kumar Mishra <prashantkumar.mis...@citrix.com>
Subject RE: [Discuss] Cpu and Ram overcommit.
Date Mon, 21 Jan 2013 18:32:03 GMT
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.

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
go.

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

4-How we are calculating   fine tune overcommit factor , is it based on previous records.

5- How we are handling hypervisor  Memory  exhaustion .
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.

Thanks 
Prashant kumar Mishra



-----Original Message-----
From: Bharat Kumar [mailto:bharat.kumar@citrix.com] 
Sent: Friday, January 18, 2013 3:23 PM
To: cloudstack-users@incubator.apache.org
Cc: cloudstack-dev@incubator.apache.org
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 [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