Hi Prachi, When I said actual I was referring to the minimum memory available to a VM.
Bharat. On Feb 6, 2013, at 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. >> >> >> >> >> >
