You can scale down memory in KVM, but not CPU without a reboot. I'd like to see this implemented as the ability to jump between service offerings without reboot, and perhaps have a custom service offering that allows for any custom number to be put in. That way people who utilize cloudstack can choose between making only certain offerings/combinations available (control the scale amount as David said), or opening it up for full customization.
On Sat, Dec 15, 2012 at 3:25 PM, David Nalley <da...@gnsa.us> wrote: > On Sat, Dec 15, 2012 at 12:43 PM, Koushik Das <koushik....@citrix.com> > wrote: > > Currently CS supports changing CPU and RAM for stopped VM. This is > achieved by changing compute offering of the VM (with new CPU and RAM > values) and then starting it. I am planning to extend the same for running > VM as well. Initially planning to do it for Vmware where CPU and RAM can be > dynamically increased. Support of other HVs can also be added if they > support increasing CPU/RAM. > > > > Assuming that in the updated compute offering only CPU and RAM has > changed, the deployment planner can either select the same host in which > case the values are dynamically scaled up OR a different one in which case > the operation fails. In future if there is support for live migration > (provided HV supports it) then another option in the latter case could be > to migrate the VM first and then scale it up. > > > > I will start working on the FS and share it out sometime next week. > > Thanks for starting this conversation early in the process, Koushik. > > I'd want to make just 'how much' resources can be scaled up a > configuration option. Is 2x reasonable? probably, is 50x reasonable, > probably not. > Or actually - thinking about this - perhaps this becomes part of the > service offering. You can start at 2cores/4gb but have a place to > scale up to without restart, but you know from the outset exactly how > far that is. Actually - since you can't scale it back down, that makes > even more sense to me. (I know you can't scale back down in KVM, not > so sure about VMware) I am worried about the effect of this on usage > statistics, but still sounds very useful. > > Maybe you solve the allocation problem by actually allocating for the > max allocatable - of course if that goes into usage metrics, and then > on to billing perhaps it isn't as attractive. > > --David >
