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.me...@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.hu...@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.me...@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.kan...@citrix.com> wrote: >>> > >>> >>Hi Nitin, >>> >> >>> >>Please see below >>> >> >>> >>Hari >>> >> >>> >>-----Original Message----- >>> >>From: Nitin Mehta [mailto:nitin.me...@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.mis...@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....@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 >>> >> >>> > >> >
