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.ku...@citrix.com] Sent: Friday, January 18, 2013 3:23 PM To: cloudstack-users@incubator.apache.org Cc: cloudstack-...@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.ku...@citrix.com] Sent: Thursday, 17 January 2013 11:01 PM To: cloudstack-users@incubator.apache.org Cc: cloudstack-...@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.hu...@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.ku...@citrix.com] >> Sent: Tuesday, January 08, 2013 3:16 AM >> To: cloudstack-users@incubator.apache.org >> Cc: cloudstack-...@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.ku...@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. >