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 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. > > >> > >> 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 > >> > > >
