I was planning on looking at the same. With KVM, it requires that you launch the vm with a max number and a current number. Then you can increase up to max.
I agree that it will be important to migrate before scaling if necessary. The scenario would likely be common and make the feature less useful if it couldn't find resources in the cluster to fill the request. Perhaps there could be various options such as "migrate to host with available resources" or "migrate other vms to fufill request, smallest/largest first", or "least cpu usage first" etc. That way if someone has a VM that needs to scale up CPU it's not taking a performance penalty or outage by migrating, if the admin chooses. On Dec 15, 2012 10:45 AM, "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. > > Comments/suggestions? > > Thanks, > Koushik >
