Hot resize enables scaling of such resources as RAM and CPU without rebooting the virtual server.
Such ability depends on many factors:
- template properties (whether template itself supports such functionality)
- type of virtualization of the compute resource on which the virtual server is running
- used hardware
- other peculiarities of the overall cloud environment
Below you can find hot resize template matrix and several considerations about max memory.
Hot resize matrix for templates
Hot resize matrix is reflected in resize_without_reboot_policy parameter, introduced since OnApp 3.3.1 which can be checked with API call for templates . The API request will return the following parameter:
resize_without_reboot_policy - all specifically tested templates (all newly added templates and some of the most frequently used ones) will have this parameter which indicates the hot resize possibility for a particular template considering its OS version and virtualization type:
The indicated integer is a decimal representation of a 4-bit binary code, which indicates whether CPU or RAM can (1) or cannot (0) be resized without reboot, where:
- 1st bit defines the ability to increase cpu
- 2nd bit defines the ability to decrease cpu
- 3rd bit defines the ability to increase RAM
4th bit defines the ability to decrease RAM
Be aware that bits are counted from right to left.
- Some of the older and less common templates may not be tested according to Hot Resize Matrix, hence the resize_without_reboot_policy parameter will not be set, and allow_resize_without_reboot parameter will define whether the template supports resize without reboot.
- allow_resize_without_reboot defines the template's resize capabilities but does not consider the virtualization type, thus may not be entirely accurate.
- For the test results which consider the templates' resize without reboot possibilities under different virtualization types refer to this document.
Max memory considerations
When a template and virtualization type supports a resize of RAM, the amount of memory allocated to a VS cannot exceed the max_memory parameter or the virtual server will be rebooted.
The max_memory value depends on the type of a compute resource virtualization and is calculated as follows:
max_memory = current memory × 16
For example, if a virtual server is allocated with 2 GB of RAM, the VS may be scaled up to 32 GB without a reboot.
max_memory = current memory (is set after each reboot)
Thus, you may scale RAM down and then back to the original value without reboot; value exceeding max_memory will require reboot, and will constitute current memory afterwards.
There are several workarounds to scale up RAM for virtual servers running on KVM:
1) To hot resize KVM CentOS 6.x x64 virtual servers:
- Enable ballooning release resource type (Control Panel > Settings > Compute zones > Edit Compute Zone)
- Additional Set max memory slider appears automatically. Move the slider to the right to enable max memory parameter for every VS within the compute zone. When you enable the Set max memory option, the limit for VSs is calculated as follows:
max_memory = current memory × compute resource max memory rate
The default compute resource max memory rate is eight (8). To modify the default max memory rate, change a value of the
kvm_max_memory_rateparameter in the
on_app.ymlfile. If the calculated max memory limit is more than 90% of free RAM available on a compute resource, then the limit is equal to 90% of free RAM available on the compute resource. You can also customize a max memory limit for a particular virtual server. For more information, refer to Set Max Memory.
2) If you enable Autoscale Virtual Server and set autoscaling rule for RAM, then the max_memory value will be ignored and RAM can be increased within the value set in 24hr limit (up_to parameter) field without reboot. The RAM increase can be either triggered by the set autoscaling rule or manually, using the Edit menu.
NOTE: If you manually increase the RAM over the 24hr limit value - the virtual server will be rebooted.