On 01/22/2013 07:00 AM, Nitin Mehta wrote:
Hari - I am yet to update the FS. I will do that very soon. Answer to your
questions inline.
On 22/01/13 10:50 AM, "Hari Kannan" <hari.kan...@citrix.com> wrote:
Hello Nitin, Koushik,
I'm following up on this feature - is the FS located here still
accurate/up to date?
I also wish to get clarification on a couple of things:
1. There is a reference - open issue 1: "Ability to mark the VM for scale
up at creation time " - what is the intent behind this capability? Why
cant every VM be capable of scaling? Also, given the capability of
scaling up is actually a property of {OS, Hypervisor} what would be the
intent behind having this as a property of a service offering? How was
this "closed"?
We would not be doing this. The intent earlier was because Vmware required
this property to be set upfront (while deploying vm itself). We will set
this property for every vm be default.
2. We also know that XS and KVM support this for Linux (max needs to be
pre-defined) - so, I assume we are supporting both these platforms, in
addition to VMware?
I am not planning to do this. I think for KVM Marcus was going to pitch in.
For KVM you indeed need to set "maxmem" and "currentmem". Maxmem is the
value until which you can increase the memory while the VM is running.
If you want to increase beyond that you need to restart the VM.
Wido
3. In case there is no capacity in cluster to scale up, just making sure
that the existing VM will not have any impact, right?
Yes, there won't be any impact. Don't worry about it :)
Hari
-----Original Message-----
From: Marcus Sorensen [mailto:shadow...@gmail.com]
Sent: Thursday, December 20, 2012 9:47 AM
To: cloudstack-dev@incubator.apache.org
Subject: Re: [DISCUSS] Scaling up CPU and RAM for running VMs
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+scal
in
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
