Prachi, For Hypervisor not supporting overcommit, the cluster of those hypervisors cannot have a overcommit. It should not affect the current capacity calculation. Bharat will be able to elaborate on this.
-abhi On 06/02/13 1:11 AM, "Prachi Damle" <prachi.da...@citrix.com> wrote: >Hi Bharat / Abhi, > >Even currently we always store actuals in the DB in op_host_capacity >table. During allocation, the overprovisioning ratios are applied >dynamically to find the overprovisioned "total" capacity. >So it's good that even the new way will follow that. > >>Major differences are >>1.) In new way we store what we actually allocate in the DB rather than >>the one in the service offering. >>2.) All calculations are done based on the actuals. >>3.) Depending on the overcommit values we scale down and then allocate. > >This is based on the XenServer overcommit support. What will happen for >rest of the hypervisors, since currently capacity calculation is a >generic logic? > > >-Prachi > >-----Original Message----- >From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com] >Sent: Monday, February 04, 2013 10:44 PM >To: cloudstack-dev@incubator.apache.org >Subject: FW: Regarding Cpu and memory overcommit feature. > > >On 01/02/13 4:22 PM, "Bharat Kumar" <bharat.ku...@citrix.com> wrote: > >>Hi All, >> >>I have made changes to the way capacity is calculated in Cloudstack , >>please review and comment. >> >>I will illustrate this with an example. >> >>let us say we have a host with >>Actual Total capacity=4GB ram, >> >>and the overcommit ratio be 2. >> >>Current way >>Total capacity= 4*2= 8GB. >>Values after deploying 4 VMs with 1GB in service offering. >>Allocated per vm =1GB. >>Used=4GB >>Available=8-4=4GB > >>now if we decrease the overcommit ratio to 1 Total Capacity = 4*1=4GB. >>used Capacity = 4GB. >>Available = 4-4=0. (implies 100% usage. can also go to more than 100%) > > >We should store the actuals in the db with over commit ratio. And rest of >the values of available memory and used memory can be calculated form >that. >So the new method mentioned below looks consistent. > >-abhi > >> >>XenServer uses DMC for memory overcommit, to use this feature we have to >>set the minimum and maximum ram that we want to allocate. >>The memory used by the VMs can vary between the minimum and maximum. In >>case of contention they will be allowed to use the minimum memory >>allocated >>to them. Minimum memory is the reserved memory which is guaranteed for >>the VM. >> >>New WAY. >>Total Capacity= 4GB. >>Values after deploying 4VMs with 1GB in service offering. >>Allocated per VM = 1GB/ overcommit = 512MB. (This is set as the minimum >>and 1GB is the maximum.) >>Used = 4* minimum allocated per vm = 2GB. >>Available = 4-2= 2GB. >>Value that is visible to admin as available = Available * overcommit >>ratio =2*2= 4GB. >>Now if we decrease the overcommit ratio to 1 >>Available capacity =total - used = 4-2= 2GB. (This 2GB will be made >>available by the XenServer using DMC.) >>(we can still deploy VMs in this case ) >> >>Major differences are >>1.) In new way we store what we actually allocate in the DB rather than >>the one in the service offering. >>2.) All calculations are done based on the actuals. >>3.) Depending on the overcommit values we scale down and then allocate. >> >>Advantages >>1.) The usage can never go beyond 100% and is independent of changes in >>overcommit values. >>2.) We can deploy more VMs. >> >>Also please comment if we need to show actuals on the dashboard or the >>over provisioned values and why. >> >>Regards, >>Bharat. >> >> >> >> >> >
