cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nitin Mehta <Nitin.Me...@citrix.com>
Subject Re: [DISCUSS] Scaling up CPU and RAM for running VMs
Date Sat, 09 Mar 2013 10:34:35 GMT
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