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 >> >
