Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of Alex.Huang@citrix.com
 designates 66.165.176.63 as permitted sender)
From: Alex Huang <Alex.Huang@citrix.com>
To: Nitin Mehta <Nitin.Mehta@citrix.com>,
	"cloudstack-dev@incubator.apache.org" <cloudstack-dev@incubator.apache.org>,
	Prashant Kumar Mishra <prashantkumar.mishra@citrix.com>, Abhinandan Prateek
	<Abhinandan.Prateek@citrix.com>
CC: Chip Childers <chip.childers@sungard.com>, Kelven Yang
	<kelven.yang@citrix.com>
Date: Sat, 9 Mar 2013 09:06:04 -0800
Subject: RE: [DISCUSS] Scaling up CPU and RAM for running VMs
Thread-Topic: [DISCUSS] Scaling up CPU and RAM for running VMs
Thread-Index: Ac4csbQTuTYL8mAnTZKwBwYruGzMuwANkvtA
Message-ID: 
 <B1DF26ECC0458748AC97CECE2DA98D41013175C60CCE@SJCPMAILBOX01.citrite.net>
References: <CD5FCAA6.12F35%nitin.mehta@citrix.com>
 <CD610DB0.1324F%nitin.mehta@citrix.com>
In-Reply-To: <CD610DB0.1324F%nitin.mehta@citrix.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Nitin,

The other approach to this is to utilize the syncing feature in the job que=
ue.  I've cced Kelven to see if he can give you more detail.  His code is c=
apable of syncing operations on a single object so you don't have to add pr=
ocessing states.

Given that all of your operations and vm snapshot operations must have come=
 in through the job queue, you might already have that ability to not inter=
fere with each other. =20

VM States are different because there can be outside changes (through other=
 vm managers) that cause vm life cycle to behave differently.

--Alex

> -----Original Message-----
> From: Nitin Mehta
> Sent: Saturday, March 9, 2013 2:35 AM
> To: cloudstack-dev@incubator.apache.org; Prashant Kumar Mishra;
> Abhinandan Prateek; Alex Huang
> Cc: Chip Childers
> Subject: Re: [DISCUSS] Scaling up CPU and RAM for running VMs
>=20
> Hi Alex,
> I had one more question. Say the MS is shut down or restarted, when do we
> clear this attribute in this case ?
>=20
> On 08/03/13 6:01 PM, "Nitin Mehta" <Nitin.Mehta@citrix.com> wrote:
>=20
> >Alex - Thanks very much for pointing out earlier this week that for
> >scaling up the vm we shouldn't change the vm lifecycle. I also read
> >http://markmail.org/message/6c6njactsklot62h
> >and understand that scaling up a vm is a vm operation and shouldn't be
> >mixed with vm lifecycle. So as you suggested in the thread that if I
> >need to prevent other Vm operations happening during this operation I
> >would need to introduce an attribute
> >
> >1. For this I would need to introduce a column in vm_instance table
> >which would be set during scale up operation.
> >2. To prevent other operations from happening this attribute needs to
> >be checked in all the other vm operations. There is no single common
> >piece of code where I can put the check so I have to explicitly check
> >for this attribute in all the operations code right ? I see that for "vm
> snapshot"
> >operation we have put this check in vm state transition method but this
> >method is called only for vm lifecycle changes. So when "vm snapshot"
> >happens the user might also scale up the vm. There might be a need for
> >them to be exclusive.
> >3. If I need to say lock capacity before the operation and modify it
> >after the operation is done (say during failure) how do I do it w/o
> >coupling the code changes or is it ok for now to do so ?
> >
> >
> >Thanks,
> >-Nitin
> >
> >On 15/02/13 5:42 AM, "Hari Kannan" <hari.kannan@citrix.com> wrote:
> >
> >>Hi Nitin,
> >>
> >>Please see below
> >>
> >>Hari
> >>
> >>-----Original Message-----
> >>From: Nitin Mehta [mailto:Nitin.Mehta@citrix.com]
> >>Sent: Tuesday, February 12, 2013 7:15 AM
> >>To: Prashant Kumar Mishra; cloudstack-dev@incubator.apache.org;
> >>Abhinandan Prateek
> >>Cc: Chip Childers
> >>Subject: Re: [DISCUSS] Scaling up CPU and RAM for running VMs
> >>
> >>Apologize for the delayed response. Was involved in other issues.
> >>Please find answers inline.
> >>
> >>>
> >>>-----Original Message-----
> >>>From: Prashant Kumar Mishra [mailto:prashantkumar.mishra@citrix.com]
> >>>Sent: Thursday, January 24, 2013 12:26 PM
> >>>To: cloudstack-dev@incubator.apache.org
> >>>Cc: Nitin Mehta
> >>>Subject: RE: [DISCUSS] Scaling up CPU and RAM for running VMs
> >>>
> >>>Hi Nitin,
> >>>I am planning to take the QA job for this feature. Have reviewed the
> >>>functional spec, gone through community discussion  and have the
> >>>following questions
> >>>
> >>>1-What is expected behavior of CS for Operating systems which do not
> >>>support dynamic scaling . ?
> >>
> >>Will throw a not supported exception
> >>
> >>Hari: How do we know which OS is supported or not? Is it going to be
> >>part of the "capabilities" of hypervisor? Or where will this be
> >>specified/configured?
> >>PS: I know we plan to implement this only on VMware for now, but when
> >>installed/shipped, how will CS know the supported Hypervisor/OS?
> >>
> >>>
> >>>2-How much resources can be scaled up, is it limited by availability
> >>>of resource on host .?
> >>>
> >>>[Koushik Das ]
> >>>"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".
> >>>[/Koushik Das]
> >>
> >>It is not limited by the resources on host but on the available
> >>capacity in any of the host within the cluster.
> >>
> >>Hari: I'm not sure I understand the question - how is this any
> >>different than requesting a new VM? Or upgrading from offering A to
> >>Offering B that exists today (although VM needs to be shutdown)?
> >>
> >>>
> >>>it seems  its totally depend on service offering , please correct me
> >>>if I am wrong.
> >>>
> >>>3-  Scheduled snapshot of volumes during the operation .
> >>>
> >>>[NITIN]
> >>>For vmware, the entire vm is locked by HV and this can be an issue. I
> >>>will leverage on current implementations for existing interactions
> >>>like scheduled snapshots events during live migration and will
> >>>replicate the same.
> >>>[/NITIN]
> >>>
> >>>Can you elaborate what is expected in case of VMware .
> >>
> >>What I mean is there is an existing functionality which is implemented
> >>the same way. I will just do it the same way.
> >>
> >>>
> >>>4 - what is expected behavior in case of  powers off the vm during
> >>>the operation .? is it different for different hypervisors.?
> >>
> >>There is nothing much to do for powered off vms because we will just
> >>update the DB. When the vm is started it will pick up these values
> >>from the DB.
> >>This functionality already exists.
> >>
> >>>
> >>>5- what is expected in case of migration fails( In FS no description
> >>>about this),
> >>>       -CS will  retry to migrate it again if yes how many time ?
> >>>      - will it mark as a failure and can't  scale up(even resources
> >>>are available in cluster) ?
> >>
> >>We will retry N (configurable) times and if unsuccessful we will throw
> >>an exception to the user.
> >>
> >>Hari: Can you please elaborate why a migration might fail? And, is the
> >>"N" configurable times a new global?
> >>
> >>>
> >>>6- Apart from  "scaleVirtualMachine"    any other APIs are getting
> >>>changed ?
> >>
> >>No
> >>
> >>>
> >>>7-Scale down is allowed ? (still open issue in FS)
> >>
> >>No for time being.
> >>
> >>>
> >>>8-Are we going to introduce custom compute offering (still open issue
> >>>in
> >>>FS) ?
> >>
> >>No for now
> >>
> >>>
> >>>9- what are the guide line for upgrade  ?
> >>
> >>There is nothing for upgrade because we do not introduce new values in
> >>DB.
> >>
> >>>
> >>>10-Any DB changes ?
> >>
> >>See #9 above.
> >>
> >>>
> >>>11- which Usage events are getting introduced for billing .?
> >>
> >>Will update the FS.
> >>
> >>>
> >>>12-hypervisor support ,is it only for VMware (as per FS)  or its
> >>>getting extended for XS/KVM also ?
> >>
> >>There are subtasks opened for XS and KVM. I am doing it only for Vmware=
.
> >>
> >>>
> >>>Thanks
> >>>Prashant Kumar Mishra
> >>>
> >>>
> >>>-----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
> >>
> >