[
https://issues.apache.org/jira/browse/CLOUDSTACK-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545712#comment-13545712
]
Wido den Hollander commented on CLOUDSTACK-658:
-----------------------------------------------
I'd like to add that KVM with the correct version of libvirt also supports this.
"virsh help":
setmem change memory allocation
setvcpus change number of virtual CPUs
It is also supported by libvirt-java:
*
http://libvirt.org/sources/java/javadoc/org/libvirt/Domain.html#setMemory%28long%29
*
http://libvirt.org/sources/java/javadoc/org/libvirt/Domain.html#setVcpus%28int%29
If the correct Commands are added inside the CloudStack management server it
won't be hard to add KVM support as well.
> Scaling up CPU and RAM for running VMs
> --------------------------------------
>
> Key: CLOUDSTACK-658
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-658
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
> Reporter: Koushik Das
> Assignee: Nitin Mehta
> Fix For: 4.1.0
>
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
