vCPU Scaling Controls

vCPU Scaling Control Modes and Options

Turbonomic provides simple and advanced controls to automate compute resource management actions in compliance with your policies. It also provides a legacy control based on units of MHz.

The controls you choose depend on your operational policies regarding the VM configuration of sockets and cores per socket, and your choice of hypervisor. For example, your operational policies may dictate a certain VM configuration that must be respected when resizing a VM's compute resources. Changing sockets is the least disruptive, but for some workloads, it may be preferable to change cores per socket due to socket licensing or operating system constraints. For larger VMs where Non-Uniform Memory Access (NUMA) must be considered for performance reasons, it may be preferable to balance vCPUs across host sockets.

The following tables explain the exact operation for each mode.

Simple Controls

Simple controls change compute resources based on units of vCPU.

Advanced Controls

Advanced controls allow you to change sockets or cores per socket, and configure additional options.

Legacy Controls

Legacy controls change compute resources based on units of MHz.

Points to consider:

• If non-disruptive mode is enabled, disruptive actions are not automated and must be executed manually.

• Older Guest OSes and applications may be sensitive to changes in the vCPU architecture that could result in power-on issues or kernel panics/BSODs. Some workloads require manual help with such changes, so always test certain classes of applications and guest operating systems before enabling any automation that changes the vCPU architecture. Use the Turbonomic knowledge of the application domain and Guest OS to scope them out of policies.

Scaling Option: Change Virtual CPUs

In this scaling option, Turbonomic adds or removes compute resources in increments of vCPUs. To achieve this, it changes the number of VM sockets and enforces 1 core per socket (if not already enforced).

• If a VM requires a change to compute resources, Turbonomic generates a resize vCPU action that assumes 1 core per socket. If the VM currently does not have 1 core per socket, Turbonomic reconfigures it to 1 core per socket as part of action execution.

• If a VM is already optimally sized, but its current cores per socket is not 1, Turbonomic generates a reconfigure vCPU action to change cores per socket to 1, thereby bringing the VM into compliance with the policy.

This scaling option is ideal under the following scenarios:

• Your environment has a large number of small VMs where precise vCPU scaling is the priority.

• You have VMs that already have 1 core per socket and require on-demand upsizes on these VMs to be non-disruptive.

For example, a VM currently has 1 socket and 2 cores per socket, and applies a policy that changes vCPU in increments of 1.

• If Turbonomic determines that the VM needs to increase compute capacity by 1 vCPU (i.e., from 2 to 3 vCPUs), a resize up action changes sockets from 2 to 3, and cores per socket from 2 to 1.

  

• When the same VM needs to reduce compute capacity by 1 vCPU (i.e., from 3 to 2 vCPUs), a resize down action changes sockets from 3 to 2.

  

Scaling Option: Change Sockets

In this scaling option, Turbonomic adds or removes compute resources by changing VM sockets.

• If a VM requires a change to compute resources, Turbonomic generates a resize vCPU action that considers the current cores per socket value (if the 'Preserve existing VM cores per socket' option is set) or uses the user-specified cores per socket value. If the VM's current cores per socket value violates a policy (i.e., does not match the user-specified value), Turbonomic reconfigures the VM's cores per socket value as part of action execution, thereby bringing the VM into compliance with the policy, while at the same time providing the required change to compute resources.

• If a VM is already optimally sized, but its current cores per socket value violates a policy (i.e., does not match the user-specified value, if set), Turbonomic generates a reconfigure vCPU action to change cores per socket to the user-specified value, thereby bringing the VM into compliance with the policy.

Change Sockets and Preserve VM Cores Per Socket

In this scaling option, Turbonomic adds or removes compute resources by changing VM sockets in increments of 1, and preserves VM cores per socket.

This scaling option is ideal under the following scenarios:

• You require Turbonomic to leave the VM cores per socket configuration unchanged for operational policy reasons (such as compliance with an application support contract policy).

• You have VMs that need to upsize non-disruptively to meet rising application demand.

• You have VMs with even numbers of cores per socket and are required to scale in even increments of vCPUs.

For example, a VM currently has 1 socket and 4 cores per socket, and applies a policy that changes sockets and preserves VM cores per socket. Turbonomic has determined that the VM requires a change in compute capacity of 1 vCPU.

• To increase compute capacity by 1 vCPU, a resize up action adds 1 socket. Because this new socket must have 4 cores to preserve VM cores per socket, the end result is 2 sockets with a total of 8 vCPUs.

  

• It is not possible to reduce compute capacity by 1 vCPU because the VM is already at the smallest achievable size. Therefore, no action generates.

  

Change Sockets and Specify Cores Per Socket

In this scaling option, Turbonomic adds or removes compute resources by changing VM sockets in increments of 1, and reconfigures VM cores per socket according to the value that you specify.

This scaling option is ideal under the following scenarios:

• You require any odd number vCPUs for a VM to be an even number, by setting an even number of cores per socket.

• You want a quick, script-less bulk disruptive conversion of VMs to a specific cores per socket without negatively impacting compute capacity (vCPUs).

• You have older Guest OSes and applications that are sensitive to vCPU architecture changes that could result in power-on issues or kernel panics/BSODs. Some workloads require manual help with such changes so always test certain classes of applications and OSes before enabling any automation that changes the vCPU architecture. Use the Turbonomic knowledge of the application domain and Guest OS to scope them out of policies.

For example, a VM currently has 1 socket and 4 cores per socket, and applies a policy that changes sockets and enforces the user-specified 1 core per socket. Turbonomic has determined that the VM is already optimally sized, so a resize action is not necessary.

• Since the VM is in violation of policy, Turbonomic changes sockets from 1 to 4, and cores per socket from 4 to 1.

  

• When the VM is compliant with policy, no action generates.

  

Scaling Option: Change Cores Per Socket

In this scaling option, Turbonomic adds or removes compute resources by changing the VM cores per socket.

• If a VM requires a change to compute resources, Turbonomic generates a resize vCPU action that considers the current socket value (if the 'Preserve existing VM sockets' option is set), respects the user-specified socket value, or matches VM sockets to the host socket value. If the VM's current socket value violates a policy (i.e., does not match the user-specified or host socket value), Turbonomic reconfigures the VM's socket value as part of action execution, thereby bringing the VM into compliance with the policy while at the same time providing the required change to compute resources.

• If a VM is already optimally sized, but its current socket value violates a policy, Turbonomic generates a reconfigure vCPU action to change the sockets to the user-specified or host socket value, thereby bringing the VM into compliance with the policy.

Older Guest OSes and applications may be sensitive to vCPU architecture changes that could result in power-on issues or kernel panics/BSODs. Some workloads require manual help with such changes so always test certain classes of applications and OSes before enabling any automation that changes the vCPU architecture. Use the Turbonomic knowledge of the application domain and Guest OS to scope them out of policies.

Change Cores Per Socket and Preserve VM Sockets

In this scaling option, Turbonomic adds or removes compute resources by changing the VM cores per socket in increments of 1, and preserves VM sockets.

This scaling option is ideal under the following scenarios:

• You require Turbonomic to leave the VM sockets configuration unchanged for operational policy reasons (such as socket-based licensing or compliance with an application support contract policy).

• You have VDI VMs that are at their maximum Guest OS socket limitation, but require more compute resources.

• You have VMs that are configured with NUMA considerations.

  Note:

  You can also use the 'Match Host Sockets' scaling option (discussed below) for NUMA sensitive VMs.

For example, a VM currently has 1 socket and 4 cores per socket, and applies a policy that changes cores per socket and preserves VM sockets. Turbonomic has determined that the VM requires a change in compute capacity of 1 vCPU.

• To increase compute capacity by 1 vCPU, a resize up action changes cores per socket from 4 to 5.

  

• To reduce compute capacity by 1 vCPU, a resize down action changes cores per socket from 4 to 3.

  

Change Cores Per Socket and Match Host Sockets

In this scaling option, Turbonomic reconfigures VM sockets to match the number of host sockets, thereby balancing vCPUs evenly across physical sockets. It also changes VM cores per socket to maintain the same compute capacity (vCPU).

This scaling option is ideal under the following scenarios:

• You have large VMs that may realize a performance benefit from reflecting the physical host CPU architecture within the Guest OS so that the application can optimize thread memory access to within a NUMA node.

• You have NUMA sensitive VMs that are migrating between hosts with different CPU architectures. Turbonomic can place the VMs on the best host and then generate an action to reconfigure the VMs to match the host sockets automatically. You can attach a schedule to the policy to automate disruptive reconfigure actions within a maintenance window.

For example, a VM currently has 1 socket and 4 cores per socket, and is on a host with 1 socket. The VM applies a policy that changes cores per socket and matches host sockets. Turbonomic has determined that the VM is already optimally sized, so a resize action is not necessary.

When the host socket value changes from 1 to 2, the VM is suddenly in violation of policy. To bring the VM into compliance while maintaining the same vCPU capacity (since the VM is already optimally sized), Turbonomic must distribute 4 cores between 2 sockets. The end result is 2 sockets and 2 cores per socket.

Change Cores Per Socket and Specify Sockets

In this scaling option, Turbonomic reconfigures VM sockets according to the value that you specify, and changes VM cores per socket to maintain the same compute capacity (vCPU).

This scaling option is ideal if you have VMs that require a specific socket value for operational policy reasons (such as socket-based licensing or compliance with an application support contract policy).

For example, a VM currently has 1 socket and 2 cores per socket, and applies a policy that changes cores per socket and enforces the user-specified 2 sockets. Turbonomic has determined that the VM is already optimally sized, so a resize action is not necessary.

• Since the VM is in violation of policy, Turbonomic changes sockets from 1 to 2, and cores per socket from 2 to 1.

  

• When the VM is compliant with policy, no action generates.

  

Scaling Option: Change MHz Legacy Behavior

In this scaling option, Turbonomic adds or removes compute resources in increments of MHz (1800 MHz by default).

If a VM requires a change to compute resources, Turbonomic generates a resize vCPU action that assumes 1 core per socket, regardless of the VM's actual cores per socket.

If Turbonomic discovers the actual number of cores per socket as part of action execution, it adjusts the action accordingly.

For example, a VM currently has 4 vCPUs with 2 sockets and 2 cores per socket. Turbonomic may generate an action to resize from 4 to 5 vCPUs. However, as part of action execution, the VM socket count changes from 2 to 3, so the end result is 6 vCPUs. Conversely, the same VM may have an action to resize from 4 to 3 vCPUs, but nothing changes as part of action execution.

Hypervisor Support

For VMware vSphere, Turbonomic supports all vCPU scaling options, including changing a VM's number of sockets or cores per socket. Increasing the number of sockets is non-disruptive if CPU hot-add is enabled on a VM, while reducing the socket count always requires a restart and is therefore disruptive.

For Hyper-V and Nutanix AHV, cores per socket and hot-add features have varying degrees of support.

Tie Breakers

When a single VM applies multiple conflicting policies, Turbonomic uses the following tie breakers that follow the principle of least disruptive and most conservative:

• vCPU Scaling Control

  "Sockets" wins over "Cores per socket" wins over "Virtual CPU" wins over "MHz legacy behavior".

  Note:

  Policies created before the introduction of vCPU scaling controls (i.e., any policy before version 8.5.7) will continue to use the "MHz legacy behavior" option but will not be enforced when policy conflicts arise. You can remove these policies or update them to use the newer scaling controls.

• Sockets setting

  "Preserve existing VM cores per socket" wins over "User-specified core per socket".

• Cores Per Socket setting

  "Preserve existing VM sockets" wins over "User-specified socket" wins over "Match host sockets".

• User-specified value

  The lowest value wins.

• Increment Size value

  The lowest value wins.

For example, assume a VM belonging to two groups that apply different policies. Policy A changes cores per socket and matches host sockets, while Policy B changes sockets and preserves cores per socket. In this scenario, the VM applies Policy B. Changing sockets wins over changing cores per socket because it is less disruptive.

To see which policies are in effect after the tie-break decision, set the scope to a VM or group of VMs and then click the Policies tab.

Policy Cookbook

Tips:

• Use the following filters when searching for or creating VM groups:

  • Number of vCPUs

  • Number of Sockets

  • Cores per Socket

  • Target Type

  • Hot-Add Enabled

• For the least disruptive on-demand upsize of vCPU, enable hot-add on the VM and change sockets while preserving cores per socket.

• For the most precise compute resource management, change cores per socket.

• For NUMA considerations, change cores per socket and match host sockets.

• Check Guest OS application and license compatibility when changing vCPU architecture and before automating actions.

How to...

• Manage VM compute capacity by changing the number of vCPUs in increments of 2.

  A VM will be reconfigured if required to use 1 core per socket, and resized by changing sockets. Actions are disruptive if the VM does not already have 1 core per socket or if hot-add is not enabled.

  1. Create a group of VMs that can have 1 core per socket and scale in sockets.

  2. Assign the group a policy with the following settings:

     • vCPU Scaling Controls

       • Change: Virtual CPU

       • Increment size: 2

     • (Optional) vCPU Resize Min/Max Threshold

• Reconfigure all odd-numbered vCPU VMs to be even-numbered, and then manage compute in even numbers of CPUs.

  A VM will be reconfigured if required to use 2 cores per socket, and resized by changing sockets. Actions are disruptive if the VM does not already have 2 cores per socket or if hot-add is not enabled.

  1. Create a group of VMs that can have 2 cores per socket and scale in sockets.

  2. Assign the group a policy with the following settings:

     • vCPU Scaling Controls

       • Change: Sockets

       • User specified cores per socket: 2

     • (Optional) vCPU Resize Min/Max Threshold

• Ensure that large VMs always balance their vCPU cores across all physical host sockets (for example, NUMA VMs and Database Server VMs).

  A VM will be reconfigured if its socket count does not match the host socket count. The cores per socket count may be adjusted to maintain the overall compute capacity (number of vCPUs). Resize actions are disruptive because cores per socket will change. Reconfigure actions are non-disruptive if VM sockets are increasing, hot-add is enabled, and there are no changes to cores per socket.

  1. Create a group of VMs using the filters that you require to identity typically larger VMs.

  2. Assign the group a policy with the following settings:

     • vCPU Scaling Controls

       • Change: Cores per socket

       • Sockets: Match host sockets

     • (Optional) vCPU Resize Min/Max Threshold

• Keep VMs to 2 sockets only and manage compute by changing cores.

  VMs in the group will be reconfigured to 2 sockets if required, and resized by changing the cores per socket count while keeping the sockets fixed at 2, thus ensuring compliance with socket-based licensing. Resize actions are disruptive because cores per socket will change. Reconfigure actions are non-disruptive if VM sockets are increasing, hot-add is enabled, and there are no changes to cores per socket.

  1. Create a VM group containing the socket-licensed VMs.

  2. Assign the group a policy with the following settings:

     • vCPU Scaling Controls

       • Change: Cores per socket

       • User specified sockets: 2

     • (Optional) vCPU Resize Min/Max Threshold