Page History

...

• Ability to scale up CPU and/or RAM for running user VMs based on predefined compute offerings
• Ability to scale up CPU and/or RAM for running system VMs based on predefined system compute offerings
• If scaling up requires a migration it will be limited within the cluster only - if the current host where VM is running has capacity then simply the resources will be scaled up, if not live migration will be done within the cluster and then resources will be scaled up. If no suitable host is found operation will fail. In future if live migration across across clusters is possible then this constraint can be relaxed.
• Ability to mark the VM for scale up at creation time (see open issue#1)
• Ability to scale down CPU and RAM (see open issue#2)
• No check for guest OS compatibility (can be considered only if there is a concise document/API listing for supported guest OS's for each hypervisor)
• Only supported for newly created VMs, existing VMs (from prior CS releases) won't have the capability to scale up*- ability to scale up CPU and/or RAM for running system VMs based on predefined system compute offerings*
  - scale up would be scoped to the same cluster - if the current host where VM is running has capacity then simply the resources will be scaled up, if not live migration will be done within the cluster and then resources will be scaled up. If no suitable host is found operation will fail. In future if live migration across across clusters is possible then this constraint can be relaxed.
  - ability to mark the VM for scale up (see open issue#1)
  - ability to scale down CPU and RAM (see open issue#2) - no check for guest OS compatibility (can be considered only if there is a concise document/API listing for supported guest OS for each hypervisor)

- only supported for newly created VMs, existing VMs (from prior CS releases) won't have the capability to scale up- ability to scale up CPU and/or RAM for running user VMs based on predefined compute offerings
- ability to scale up CPU and/or RAM for running system VMs based on predefined system compute offerings
- scale up would be scoped to the same cluster - if the current host where VM is running has capacity then simply the resources will be scaled up, if not live migration will be done within the cluster and then resources will be scaled up. If no suitable host is found operation will fail. In future if live migration across across clusters is possible then this constraint can be relaxed.
- ability to mark the VM for scale up (see open issue#1)
- ability to scale down CPU and RAM (see open issue#2)
- no check for guest OS compatibility (can be considered only if there is a concise document/API listing for supported guest OS for each hypervisor)
- only supported for newly created VMs, existing VMs (from prior CS releases) won't have the capability to scale 

Hypervisor support

- Currently planning to do it for Vmware. Support for other HVs can also be added based on HV capabilities.

...

ReconfigureVMCommand: This will have the updated CPU and RAM values as members

*Allocation logic: *Refer  Refer to flow chart below

Web Services APIs

list changes to existing web services APIs and new APIs introduced with signatures and throughout documentation

...

• either demonstrate it visually here or link to relevant mockups

Open Issues1. Should VM be always marked for dynamic scaling? If so should this be a VM property or part of compute offering? Should dynamic scaling be treated as premium service, in that case having it in compute offering makes more sense from usage/billing perspective?)2. Should scale down be allowed? It can be explicitly prevented since none of the HVs/guest OS supports it.3. There is also an option of having a custom compute offering where user can specify values for CPU/RAM. But am not sure if this option can be misused in any possible way. Also how to capture usage in these scenarios?

Appendix

Appendix A:

Appendix B: