Hi Prashant, My comments in line.
On Jan 22, 2013, at 12:02 AM, Prashant Kumar Mishra <prashantkumar.mis...@citrix.com> wrote: > 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. Cs will not suggest any overcommit ratios to the admin, It is left to the admin to decide the values of overcommit ratios. > 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. No there is no way to specify the overcommit values for all the clusters globally, In fact we are actually making the overcommit configuration more granular. > > 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 I think we should go with A i.e. don't allow a host without overcommit capability to join a cluster with overcommit. Similarly to change the overcommit value ( to > 1)of a cluster previously not overcommitting, all the hosts in the cluster should be capable of overcommiting. > > 4-How we are calculating fine tune overcommit factor , is it based on > previous records. We don't calculate the overcommit values these are set by the admin. > > 5- How we are handling hypervisor Memory exhaustion . If you mean what will happen at the time of contention for resources, all the VMs at the time of contention will be using the minimum amount of memory guaranteed to it in case of xenserver. The overcommit values should be set carefully after taking the scenario of contention into account. > 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. > I think we will use dedicated resources for now and may be in future implement something like cluster tags. > 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. >> >
