https://issues.apache.org/jira/browse/CLOUDSTACK-658
master
It is not always possible to exactly identify the CPU and RAM requirements at the time of deploying a VM. But for various reasons it may be required to scale up these resources later on. At that time there is no other way but to restart the VM with increased resources. Dynamic scaling for CPU and RAM feature would allow to change these resources for a running VM avoiding any downtime.
Currently CS allows updating CPU/RAM by changing to a different compute offering for stopped VMs. This feature will enable the same for running VMs.
This document describes the specifications and design of the feature.
Currently planning to do it for Vmware and Xenserver. Support for other HVs can also be added based on HV capabilities.
For KVM - Marcus Sorrensun has sponsored to do this.
A new command class needs to be introduced for actually changing CPU/RAM at agent layer. This needs to be handled for the supported HVs.
ReconfigureVMCommand: This will have the updated CPU and RAM values as members
Allocation logic: Refer to flow chart below. There are 3 primary use cases:-
For dynamic scaling to work virtual machine should have XS tools / VMware tools installed on it. To ensure this Admin/User should provide an input whether tools are installed on the template(during registering the template or can be done using update template API) that is used to deploy vm. If the user deploys a virtual machine with a template that does not have XS tools / VMware tools and later if tools are installed on the VM then this can informed to Cloudstack by updating the virtual machine (using updatevirtualmachine API). After installation of tools and updating the virtual machine, user needs to stop and start the vm from cloudstack in order to work dynamic scaling of CPU and RAM for that VM. The reason why we need to stop start the VM after updating is we need to set static max memory to some higher value before VM starts so that we can dynamically scale the VM upto static max.
Following APIs needs to be changed:
scaleVirtualMachine - There is an existing API upgradeVirtualMachine and takes vm_id and compute_offering_id as inputs. This is a sync call currently and will not be used anymore since we need it to be async. I plan to deprecate this api in the next big release (5.0).
With this feature I will introduce another API named scaleVirtualMachine which will be similar to upgradeVirtualMachine in every aspect except that it would be async. In addition it will be callable when the vm is in running state as well to dynamically scale the vm.
In case of a migration this will internally use the migrateVirtualMachine API logic.
scaleSystemVm - There is an existing API upgradeSystemvm and takes system vm_id and compute_offering_id as inputs. This is a sync call currently and will not be used anymore since we need it to be async. I plan to deprecate this api in the next big release (5.0).
With this feature I will introduce another API named scaleSystem vm which will be similar to upgradeSystemvm in every aspect except that it would be async. In addition it will be callable when the system vm is in running state as well to dynamically scale the vm.
registerTemplate/updateTemplate - An additional optional boolean parameter "isdynamicallyscalable" is introduced, the value is true if template contains XS/VMWare tools inorder to support dynamic scaling of VM cpu/memory
updateVirtualMachine - An additional optional boolean parameter "isdynamicallyscalable" is introduced, the value is true if VM contains XS/VMWare tools inorder to support dynamic scaling of VM cpu/memory
Xenserver
To facilitate scaling up RAM for the VMs in xenserver Dynamic Memory Control(DMC) to change the amount of host physical memory assigned to any running virtual machine without rebooting it.
During the deployment of VM, if we set memory-dynamic-min = memory-dynamic-max = requested RAM(say K) then the guest VM gets K amount of RAM, later we can increase the RAM by setting a higher value then K within the memory static range.
Note : From XS following are the constraints (read xenserver admin guide)
DeployVmCmd -
During the initial deployment of the VM we set memory variable as follows :-
ScaleVmCmd -
During scaling up of vm, the new requested RAM is set to mem-dynamic-min and mem-dynamic-max. Static min and max do not change unless the vm is stopped and started.
While scaling "up" the vm say from service offering "x" to "y" we will change
and ensure that
TBD
Appendix A:
Appendix B: