vCPU Scaling Controls
Turbonomic represents the compute capacity of a VM in MHz and vCPUs. The following diagram shows how a VM with four vCPUs can be configured differently in terms of sockets and cores.
![Two diagrams showing how a VM with four vCPUs can be configured](../_graphics/vcpu_controls01.gif)
Turbonomic can resize the compute capacity by changing the number of sockets or cores per socket, depending on:
-
The policy that is assigned to the VM
On-prem VM policies include vCPU Scaling Controls that give you granular control over how VM compute resources are resized to maintain performance or reconfigured to comply with your operational policies. You can create policies for different VM groups based on their resource needs and characteristics, and decide whether to automate resize and reconfigure actions in those policies.
-
The hypervisor that manages the VM
Hypervisor targets have varying degrees of support for vCPU Scaling Controls. VMware vSphere supports all scaling controls, while Hyper-V and Nutanix AHV provide limited support. For details, see the Hypervisor Support section.
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 that 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-size 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.
vCPU Scaling Option |
Unit |
Sockets |
Cores Per Socket |
Resize Action |
Reconfigure Action |
---|---|---|---|---|---|
Change virtual CPUs |
vCPUs |
Turbonomic decides |
Reconfigured to 1 core per socket |
|
Not generated |
Advanced Controls
Use advanced controls to change sockets or cores per socket, and configure more options.
vCPU Scaling Option |
Unit |
Sockets |
Cores Per Socket |
Resize Action |
Reconfigure Action |
---|---|---|---|---|---|
Change sockets |
1 socket |
Turbonomic decides |
Preserve VM cores per socket |
Non-disruptive if hot-add is enabled and VM sockets are increasing |
Not generated |
Change sockets |
1 socket |
Turbonomic decides |
User-specified VM cores per socket |
|
Disruptive if VM cores per socket does not match a user-specified value |
Change cores per socket |
1 core per socket |
Preserve VM sockets |
Turbonomic decides |
Disruptive |
Not generated |
Change cores per socket |
1 core per socket |
Match host sockets |
Turbonomic decides |
Disruptive |
|
Change cores per socket |
1 core per socket |
User-specified VM sockets |
Turbonomic decides |
Disruptive |
|
Legacy Controls
Legacy controls change compute resources based on units of MHz.
vCPU Scaling Option |
Unit |
Sockets |
Cores Per Socket |
Resize Action |
Reconfigure Action |
---|---|---|---|---|---|
MHz legacy behavior |
MHz |
Turbonomic decides |
|
Non-disruptive if hot-add is enabled and VM sockets are increasing |
Not generated |
Points to consider
-
If non-disruptive mode is enabled, disruptive actions are not automated and must be run manually.
-
Older Guest OSes and applications may be sensitive to changes in the vCPU architecture that might 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, resize or reconfigure actions are not generated.
This scaling option is ideal under the following scenarios:
-
Your environment has many 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 (that is, 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 (that is, 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 (that is, 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 (that is, 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 of 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 might 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 (that is, 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 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 might 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 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 result is 2 sockets and 2 cores per socket.
![How Host Configuration and VM Configuration work to have VM become compliant with policy](../_graphics/vcpu_controls10.gif)
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.
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 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.
vCPU Scaling Option |
vSphere |
Hyper-V |
Nutanix AHV (Single Core) |
Nutanix AHV (Multi Core) |
---|---|---|---|---|
Change virtual CPUs |
Supported |
Supported |
Supported |
Not supported by hypervisor |
Change sockets – Preserve existing VM cores per socket |
Supported |
Supported |
Supported |
Supported |
Change sockets – User specified cores per socket |
Supported |
Not supported by hypervisor |
Not supported by hypervisor |
Not supported by hypervisor |
Change cores per socket – Preserve existing VM sockets |
Supported |
Not supported by hypervisor Note:
Turbonomic assumes one core per socket and only changes sockets. |
Not supported by Turbonomic |
Not supported by Turbonomic |
Change cores per socket – Match host sockets |
||||
Change cores per socket – User specified sockets |
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 that are created before the introduction of vCPU scaling controls (that is, 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 is 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.
-
Create a group of VMs that can have 1 core per socket and scale in sockets.
-
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 is 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.
-
Create a group of VMs that can have 2 cores per socket and scale in sockets.
-
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 is 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 change. Reconfigure actions are non-disruptive if VM sockets are increasing, hot-add is enabled, and there are no changes to cores per socket.
-
Create a group of VMs by using the filters that you require to identity typically larger-size VMs.
-
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 change. Reconfigure actions are non-disruptive if VM sockets are increasing, hot-add is enabled, and there are no changes to cores per socket.
-
Create a VM group containing the socket-licensed VMs.
-
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
-
-