incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Koushik Das <koushik....@citrix.com>
Subject RE: [DISCUSS] Scaling up CPU and RAM for running VMs
Date Wed, 19 Dec 2012 08:56:06 GMT
See inline

> -----Original Message-----
> From: David Nalley [mailto:david@gnsa.us]
> Sent: Sunday, December 16, 2012 3:56 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [DISCUSS] Scaling up CPU and RAM for running VMs
> 
> On Sat, Dec 15, 2012 at 12:43 PM, Koushik Das <koushik.das@citrix.com>
> wrote:
> > 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.
> 
> Thanks for starting this conversation early in the process, Koushik.
> 
> I'd want to make just 'how much' resources can be scaled up a configuration
> option. Is 2x reasonable? probably, is 50x reasonable, probably not.
> Or actually - thinking about this - perhaps this becomes part of the service
> offering. You can start at 2cores/4gb but have a place to scale up to without
> restart, but you know from the outset exactly how far that is. Actually - since
> you can't scale it back down, that makes even more sense to me. (I know you
> can't scale back down in KVM, not so sure about VMware) I am worried
> about the effect of this on usage statistics, but still sounds very useful.
> 

Having a range for CPU/RAM in compute offering is definitely another way of doing it. But
creating the higher limit would be tricky. I am not sure if it is always known to users how
much they want to scale up to at the time of deploying VM. Moreover if the higher limit is
known then the VM can be deployed with that value itself. Also in case of having a range in
the offering the usage part needs to be handled appropriately. Currently usage is purely based
on the offering and individual values are not stored.

> Maybe you solve the allocation problem by actually allocating for the max
> allocatable - of course if that goes into usage metrics, and then on to billing
> perhaps it isn't as attractive.
> 
> --David

Mime
View raw message