cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kelven Yang <kelven.y...@citrix.com>
Subject Re: [DISCUSS] Scaling up CPU and RAM for running VMs
Date Wed, 13 Mar 2013 18:01:29 GMT
Nitin,

Sorry to reply late, have been busy working on a patch release for
customer. 

AsyncJob manager does provide a mechanism that you can do synchronized the
job execution against a object. You may check out
AsyncJobManager.syncAsyncJobExecution().

Kelven

On 3/12/13 11:27 AM, "Nitin Mehta" <Nitin.Mehta@citrix.com> wrote:
>syncAsyncJobExecutionThanks Alex.
>
>Kelven / Alex - I took a look into this and it seems that the framework
>has the capability to do this and this would solve the problem for scaling
>up vm and vm snapshots.
>But, we currently don't do synchronization for the vm object. Doing this
>means all the vm operations will be syncronized now. Are we fine with that
>?  
>
>Thanks,
>-Nitin
>
>On 09/03/13 10:36 PM, "Alex Huang" <Alex.Huang@citrix.com> wrote:
>
>>Nitin,
>>
>>The other approach to this is to utilize the syncing feature in the job
>>queue.  I've cced Kelven to see if he can give you more detail.  His code
>>is capable of syncing operations on a single object so you don't have to
>>add processing 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
>>interfere with each other.
>>
>>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
>>> 
>>> Hi Alex,
>>> I had one more question. Say the MS is shut down or restarted, when do
>>>we
>>> clear this attribute in this case ?
>>> 
>>> On 08/03/13 6:01 PM, "Nitin Mehta" <Nitin.Mehta@citrix.com> wrote:
>>> 
>>> >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
>>> >>
>>> >
>>
>


Mime
View raw message