incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: [DISCUSS] Scaling up CPU and RAM for running VMs
Date Wed, 19 Dec 2012 14:24:45 GMT
On Wed, Dec 19, 2012 at 3:34 AM, Koushik Das <koushik.das@citrix.com> wrote:
> See inline
>
>> -----Original Message-----
>> From: Marcus Sorensen [mailto:shadowsor@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.das@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.das@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
>> >
>

Mime
View raw message