Hi all, I agree with Nitin on this. I think we should accept the new value and allocate only if the system has enough capacity to deploy more VMs based on the new overcommit ratios.
On Dec 27, 2012, at 9:56 AM, Nitin Mehta <nitin.me...@citrix.com> wrote: > Please find the answer inline > > On 27-Dec-2012, at 2:36 AM, Hari Kannan wrote: > >> 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 >> > > Hari - your question is what happens if we decrease the factor - correct ? > Well, currently we allow doing that (say change from 2X to 1X) . Lets say If > the allocation is beyond the factor already (say 1.5 X) then what it means is > no future allocation will be allowed and secondly the dashboard would start > showing >100% allocated which might confuse the admin (in our example it > would show 150%). The admin would also start getting alerts for capacity > being already exhausted. > But, say the allocation done till now is still within the new factor (say > 0.8X is allocated currently) then allocation would still be allowed and > dashboard would show 80% allocated so in this case everything seems to be > correct and we should allow admin changing the factor. > > Bottom-line - it depends on how much is already allocated in the current > system. If it is within the new factor then np but if not then also there is > no issue but dashboard reporting would look confusing. > > >> 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 [mailto:bharat.ku...@citrix.com] >> Sent: Wednesday, December 26, 2012 4:39 AM >> To: cloudstack-dev@incubator.apache.org; >> cloudstack-us...@incubator.apache.org >> 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 <nitin.me...@citrix.com> 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 >> accordingly. >>> >>> 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. >>> >> >
