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.mis...@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.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 . ? > > 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....@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 >
