See inline > -----Original Message----- > From: Marcus Sorensen [mailto:shadow...@gmail.com] > Sent: Tuesday, December 18, 2012 10:35 PM > To: cloudstack-dev@incubator.apache.org > Subject: Re: [DISCUSS] Scaling up CPU and RAM for running VMs > > The FS looks good and addresses the things I'd want it to (scaling should be > limited to within cluster, use offerings). > > As you mention, there's a real problem surrounding no support for scaling > down CPU, and it's just as much a problem with the guests as it is with hvms > at the moment, it seems. This makes it hard to just set a VM as a dynamic > one, since at some point you'll likely trigger it to scale up and have to > reboot > to get back down. My suggestion if this goes through however is that instead > of marking a vm for auto scale, we can either attach multiple compute > offerings (with a priority or "level") to a VM, along with triggers (we can't > really trigger on memory, but perhaps cpu utilization over a specific time, > e.g. > if cpu is at 80% for x time, fall back to the next offering), or we can > create a > specific single compute offering that allows you to specify a min and max > memory, cpu, and a trigger at which it scales (this latter one is my > preference). > > The whole thing is problematic though, because people can inadvertently > trigger their VM to scale up when they're installing updates or compiling or > something and then have to reboot to come back down. If we can't take > away resources without manual intervention, we shouldn't add them. For > this reason I'd like to see the focus (at least initially) on simply being > able to > change to larger compute offerings while the VM is up. With this in place, if > someone really wants to autoscale, they can use the api in a combination of > fetching the VM stats and the existing changeServiceForVirtualMachine. Or > we can put that in, but I think any implementation will be a poor experience > without being able to go both ways. >
This is a good suggestion but as you have mentioned first priority is to have the basic stuff working (increasing CPU/RAM for running VMs). Also another thing is that HVs (at least Vmware) require that a VM is configured appropriately when it is stopped in order to support increasing CPU/RAM while it is running. We can either do this for all VMs irrespective of the fact whether the CPU/RAM is going to be actually increased OR do it only for selective VMs (maybe based on compute offering). If this is going to be common across all HVs the latter can be done. > I don't know, maybe I'm off in left field here, I'd be interested in hearing > the > thoughts of others. > > You mention 'upgradeVirtualMachine', which should be mentioned on the > customer facing API is called 'changeServiceForVirtualMachine', just to > reduce confusion. > upgradeVirtualMachine is an existing command (see UpgradeVMCmd.java), was planning to reuse it. But yes if the name sounds confusing we can deprecate it and create a new command with the name you have suggested. > > On Tue, Dec 18, 2012 at 9:18 AM, Koushik Das <koushik....@citrix.com> > wrote: > > > Created first draft of the FS > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dynamic+scaling > > +of+CPU+and+RAM > > Also created jira issue > > https://issues.apache.org/jira/browse/CLOUDSTACK-658 > > > > Comments? There is an 'open issue' section where I have mentioned some > > issues that needs to be closed > > > > Thanks, > > Koushik > > > > > -----Original Message----- > > > From: Koushik Das [mailto:koushik....@citrix.com] > > > Sent: Saturday, December 15, 2012 11:14 PM > > > To: cloudstack-dev@incubator.apache.org > > > Subject: [DISCUSS] Scaling up CPU and RAM for running VMs > > > > > > 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 > >
