Hot resize

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:

    <resize_without_reboot_policy>
	<xen>
		<centos5 type="integer">14</centos5>
		<centos6 type="integer">14</centos6>
        <centos7 type="integer">14</centos5>
	</xen>
	<kvm>
		<centos5 type="integer">12</centos5>
		<centos6 type="integer">0</centos6>
        <centos7 type="integer">0</centos6>
	</kvm>

    Binary

    0000

    0001

    0010

    0011

    0100

    0101

    0110

    0111

    1000

    1001

    1010

    1011

    1100

    1101

    1110

    1111

    Decimal

    0

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    14

    15

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: 

  • XEN 

    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. 

  • KVM 

    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_rate parameter in the on_app.yml file. 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.