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