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.
