Oh, if it's not already obvious, we're onboard for collaborating on this feature and can help implement the KVM hypervisor portions. :-)
On Thu, Dec 20, 2012 at 8:44 AM, Marcus Sorensen <shadow...@gmail.com>wrote: > > > > On Thu, Dec 20, 2012 at 4:52 AM, Koushik Das <koushik....@citrix.com>wrote: > >> See inline >> >> Thanks, >> Koushik >> >> > -----Original Message----- >> > From: Chip Childers [mailto:chip.child...@sungard.com] >> > Sent: Wednesday, December 19, 2012 7:55 PM >> > To: cloudstack-dev@incubator.apache.org >> > Subject: Re: [DISCUSS] Scaling up CPU and RAM for running VMs >> > >> > 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 think it could be done either way. The straightforward way is via > offering that allows for max/current CPU and max/current RAM to be entered > (basically exposing how the hypervisor settings themselves work). But you > could also do a global setting of some sort that says 'set everything to a > max of X CPU and Y RAM', so that every service offering can be upgraded > live. As you mention, it will require at least a restart of the VMs to > apply, so perhaps users could just switch service offerings anyway. It > could be handy to allow people to upgrade service offering when it was > unplanned for, though. > > >> > > >> > >> 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. >> >> In that case will add a new async API changeServiceForVirtualMachine (or >> if anyone else comes up with a better name) which will work for both >> running and stopped VMs. upgradeVirtualMachine would continue to exist till >> 5.0.0 happens. >> > > Would this break backward compatibility? If an API call goes from > upgrading VMs only while they're off, and still upgrades VMs only while > they're off, but also upgrades VMs with a newer, specific service offering > type while they're on, does that break backward compatibility? Or let's say > we simply removed the check to make sure the VM was off, and instead just > checked if the VM was started with the newer compatible settings... would > that break backward compatibility? The call still does what it did before > when used as before (changes service offering while the VM is off). > > Regarding upgradeVirtualMachine, I saw no mention of it in the API docs, > and found that in the code, changeServiceForVirtualMachine was mapped to > UpgradeVMCmd.java, which is why I mentioned the confusion. > 'upgradeVirtualMachine' only exists as an internal method of the > userVmService. See the file "client/tomcatconf/commands.properties.in" > > changeServiceForVirtualMachine=com.cloud.api.commands.UpgradeVMCmd > > > >> >> > >> > >> >> > >> 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+scalin >> > >> g >> > >> > +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 >> > >> > >> > > >> > >
