incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: [DISCUSS] Scaling up CPU and RAM for running VMs
Date Tue, 12 Feb 2013 14:21:39 GMT

Nitin - 

Looking for your help here please!

-chip


On Tue, Feb 12, 2013 at 12:37:20PM +0530, Prashant Kumar Mishra wrote:
> 
> 
> -----Original Message-----
> From: Prashant Kumar Mishra [mailto:prashantkumar.mishra@citrix.com] 
> Sent: Tuesday, February 05, 2013 5:16 PM
> To: cloudstack-dev@incubator.apache.org
> Cc: Nitin Mehta
> Subject: RE: [DISCUSS] Scaling up CPU and RAM for running VMs
> 
> Need  reply  to complete  my Test cases.
> 
> -----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 . ?
>  
> 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 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 .
> 
> 4 - what is expected behavior in case of  powers off the vm during the operation .? is
it different for different hypervisors.?
> 
> 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) ?
> 
> 6- Apart from  "scaleVirtualMachine"    any other APIs are getting changed ?
> 
> 7-Scale down is allowed ? (still open issue in FS)
> 
> 8-Are we going to introduce custom compute offering (still open issue in FS) ?
> 
> 9- what are the guide line for upgrade  ?
> 
> 10-Any DB changes ?
> 
> 11- which Usage events are getting introduced for billing .?
> 
> 12-hypervisor support ,is it only for VMware (as per FS)  or its getting extended for
XS/KVM also ?
> 
> 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