On Wed, Dec 19, 2012 at 3:34 AM, Koushik Das <koushik....@citrix.com> wrote: > 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. >
Please don't break backward compatibility without the whole list discussing the implications on a dedicated thread. We had previously agreed that we were going to maintain API compatibility between 4.0.0-incubating and our next feature release. If we break it, we have to release as 5.0.0-incubating instead of 4.1.0-incubating. >> >> 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 >> > >
