On-prem VM policies

Turbonomic ships with default automation policies that are believed to give you the best results based on our analysis. For certain entities in your environment, you can create automation policies as a way to override the defaults.

Automation workflow

For details about on-prem VM actions, see On-prem VM Actions.

Action

Default Mode

vCenter

Hyper-V

PowerVM

Move

Manual

Auto actions

Auto actions

N/A

Provision (container platform nodes only)

Manual

Recommended-only actions

Recommended-only actions

N/A

Reconfigure

Recommend

Recommended-only actions

Recommended-only actions

N/A

Resize Down PU

Recommend

N/A

N/A

Recommended-only actions

Resize Down VP

Recommend

N/A

N/A

Recommended-only actions

Resize Up PU

Recommend

N/A

N/A

Recommended-only actions

Resize Up VP

Recommend

N/A

N/A

Recommended-only actions

Start

Manual

Auto actions

Auto actions

N/A

Storage Move

Recommend

Auto actions

With VMM:

Auto actions

Otherwise:

Recommended-only actions

N/A

Suspend (container platform nodes only)

Manual

Auto actions

Auto actions

N/A

vCPU Resize Above Max*

Recommend

Auto actions

Auto actions

N/A

vCPU Resize Below Min*

Recommend

Auto actions

Auto actions

N/A

vCPU Resize Down*

Manual

Auto actions

Auto actions

N/A

vCPU Resize Up*

Manual

Auto actions

Auto actions

N/A

vMem Resize Above Max*

Recommend

Auto actions

Auto actions

N/A

vMem Resize Below Min*

Recommend

Auto actions

Auto actions

N/A

vMem Resize Down*

Manual

Auto actions

Auto actions

N/A

vMem Resize Up*

Manual

Auto actions

Auto actions

N/A

* Turbonomic uses these settings, in conjunction with resize operational constraints, to set up tuned scaling for on-prem VMs.

You can use Action Scripts and third-party orchestrators (such as ServiceNow) for action orchestration.

Non disruptive mode

VM actions include the modifier, Enforce Non Disruptive Mode. When you enable this modifier, Turbonomic ensures that a resize action in Automatic or Manual mode will not require a reboot or any other disruption to the affected VM. If the action will disrupt the VM, Turbonomic posts the action in Recommend mode.

Attribute

Default Setting

Enforce Non Disruptive Mode

Off

This setting has no effect on actions set to Recommend mode. Turbonomic will continue to post those actions for you to evaluate.

You can enforce non disruptive mode in the default VM policy, and then schedule action policies to automate resize actions during downtimes. Be aware that scheduled actions do not respect the enforced non disruptive mode — Scheduled resize actions will execute during the scheduled window even if they require a reboot. This is useful for setting up certain action behaviors, but you must be aware that enforced non disruptive mode has no effect on scheduled actions.

Note:

When you configure a schedule window for a VM resize action, to ensure Turbonomic will execute the action during the scheduled time, you must turn off the Enforce Non Disruptive Mode setting for that scheduled policy. Even if you turn the setting off for the global policy, you still must turn the setting off for your scheduled policy. Otherwise Turbonomic will not execute the resize action.

Shared-nothing migration

If you have enabled both storage and VM moves, Turbonomic can perform shared-nothing migrations, which move the VM and the stored VM files simultaneously. For example, assume a VM on a host also uses local storage on that host. In that case, Turbonomic can move that VM and move its data to a different datastore in a single action.

Attribute

Default Setting

Shared-Nothing Migration

Off

Currently, the following targets support shared-nothing migrations:

  • vSphere, versions 5.1 or greater

  • VMM for Hyper-V 2012 or later

Because of this feature's potential impact on performance, it is turned off by default. Turbonomic recommends enabling it only on VMs that need it. To do this, you must first set the action acceptance mode for VM and storage moves to either Manual or Automatic, and then enable the feature in a VM policy.

Configure Virtual Machine Policy wizard with Shared Nothing Migration highlighted

If a policy that enables this feature conflicts with a more conservative policy, the latter policy wins. For example, if compute move is set to Manual, storage move is set to Recommend, and shared-nothing migration is turned on, shared-nothing migration is in effect but remains in Recommended state.

Note:

Turbonomic does not simulate shared-nothing migrations in plans.

Resize thresholds

Turbonomic uses these settings to set up tuned scaling actions for on-prem VMs. Tuned scaling gives you increased control over the action mode for various resize actions. With this feature, you can automate resize actions within a normal range (the tuned scaling range), and direct Turbonomic to take more conservative actions when a resize is outside of the range.

For details, see Tuned Scaling for On-prem VMs.

Attribute

Default Value

vCPU Resize Max Threshold (in Cores)

64 Cores

Tuned Scaling Range Upper Limit

vCPU Resize Min Threshold (in Cores)

1 Core

Tuned Scaling Range Lower Limit

VMEM Resize Min Threshold

512 MB

Tuned Scaling Range Lower Limit

VMEM Resize Max Threshold

131072 MB

Tuned Scaling Range Upper Limit

Move enabled GPUs

Use this setting to construct a regex statement to identify which GPU models should support workload placement automation. By default, .*_(?:a16|t4).*$ is the regex pattern used for this field.

On-prem virtual machines with vGPU types that match the specified pattern are enabled for moves. Leave this field blank to disable moves for all VMs in the selected scope.

To enable vMotion for vGPU Virtual Machines, you must change the vgpu.hotmigrate.enabled advanced setting. For more information, see the VMware documentation.

Increment constant for processing units

For PowerVM, processing unit is a unit of measurement for shared processing power across one or more virtual processors. One shared processing unit on one virtual processor accomplishes approximately the same work as one dedicated processor.

Turbonomic recommends VM PU resize actions in multiples of this increment constant value. For example, if Turbonomic determines that a VM with 1.0 PU needs 1.2 PU and the increment is set to 0.5, then a resize up action is not generated. Increasing this increment reduces the frequency of resize actions so that when they appear the change is more significant.

Attribute

Default Value

Increment constant for Processing Units

0.1

Increment constant for virtual processors

For PowerVM, virtual processor (VP) is the guest OS representation of the capacity of the VM. VPs have a one-to-one correlation with PUs. Therefore ,1 VP that is utilized in a VM equates to 1 PU being used. However, VPs do not have to be equal to PUs on a system. VPs are a virtual representation. Therefore, they can be overprovisioned.

Turbonomic recommends VM VP resize actions in multiples of this increment constant value. For example, if Turbonomic determines that a VM with 2 VPs needs 1 VP and the increment is set to 2, then a resize down action is not generated. Increasing this increment reduces the frequency of resize actions so that when they appear, the change is more significant.

Attribute

Default Value

Increment constant for Virtual Processors

1

Resize VStorage

The default setting disables resize actions. This is usually preferred because VStorage resize requires that you reformat the storage. The increment constant takes effect if you enable resizing.

Attribute

Default Setting/Value

Resize VStorage

Disabled

Increment constant for VStorage

None

If you enable resize, Turbonomic uses the default value of 1024 GB. You can change this to a different value.

vCPU scaling controls

For details, see VCPU Scaling Controls.

Resize increments

These increments specify how many units to add or subtract when resizing the given resource allocation for a VM.

Attribute

Default Value

Increment constant for VMem

1024 MB

Increment constant for VStorage

1024 GB

Note:

vCPU resize increments are configured in conjunction with vCPU scaling controls. For details, see VCPU Scaling Controls.

For VMem, you should not set the increment value to be less than what is necessary for the VM to operate. If the VMem increment is too low, then it’s possible that Turbonomic would allocate insufficient VMem for the machine to operate. For a VM that is under utilized, Turbonomic will reduce VMem allocation by the increment amount, but it will not leave a VM with zero VMem. For example, if you set this to 1024, then Turbonomic cannot reduce the VMem to less than 1024 MB.

Rate of resize

When resizing resources for a VM, Turbonomic calculates the optimal values for VMem, VCPU, and V Storage, but it does not necessarily make a change to that value in one action. Turbonomic uses the Rate of Resize setting to determine how to make the change in a single action.

Using the Low (1) or Medium (2) value creates actions to bring the VM partially to the Desired State, resulting in more actions and possibly more total downtime. It is recommended to use the default value of High (3) to give the VM the correct resources all at once, which achieves the benefits of performance and efficiency in one action. Fewer actions results in less possible downtime.

Attribute

Default Value

Rate of Resize

High (3)

  • Low

    Change the value by one increment, only. For example, if the resize action calls for increasing VMem, and the increment is set at 1024, Turbonomic increases VMem by 1024 MB.

  • Medium

    Change the value by an increment that is 1/4 of the difference between the current value and the optimal value. For example, if the current VMem is 2 GB and the optimal VMem is 10 GB, then Turbonomic will raise VMem to 4 GB (or as close to that as the increment constant will allow).

  • High

    Change the value to be the optimal value. For example, if the current VMem is 2 GB and the optimal VMem is 8 GB, then Turbonomic will raise VMem to 8 GB (or as close to that as the increment constant will allow).

Consistent resizing

Attribute

Default Setting

Consistent Resizing

Off

When you create a policy for a group of VMs and turn on Consistent Resizing, Turbonomic resizes all the group members to the same size, such that they all support the top utilization of each resource commodity in the group. For example, if you have deployed load balancing for a group, then all the VMs in the group should experience similar utilization. In that case, if one VM needs to be resized, then it makes sense to resize them all consistently.

Assume VM A shows top utilization of CPU, and VM B shows top utilization of memory. A resize action would result in all the VMs with CPU capacity to satisfy VM A, and memory capacity to satisfy VM B.

Note:

If the VMs in the group have different core speeds, then CPU scaling actions might not be consistent. For example, if you set the maximum target CPU size to 2, Turbonomic might recommend resizing to more than 2 CPUs to account for the VMs with slower cores.

To avoid this problem, be sure that the group only includes VMs with the same core speed.

For an affected resize, the Actions List shows individual resize actions for each of the VMs in the group. To avoid the possibility of resizing VMs disruptively at the same time, you must create automation policies with non-overlapping schedules. For example, if VMs A and B are in the same consistent resizing group, create two policies that resize the VMs at different times of the day.

  • For Policy 1, set the scope to a group containing VM A and enable resize automation between, say, 01:00 and 01:45.

  • For Policy 2 set the scope to a group containing VM B and enable resize automation between 02:00 and 02:45.

When working with Consistent Resizing, consider these points:

  • You should not mix VMs in a group that has a Consistent Resizing policy, with other groups that enable Consistent Resizing. One VM can be a member of more than one group. If one VM (or more) in a group with Consistent Resizing is also in another group that has Consistent Resizing, then both groups enforce Consistent Resizing together, for all their group members.

  • For any group of VMs that enables Consistent Resizing, you should not mix the associated target technologies. For example, one group should not include VMs that are on Hyper-V and vCenter platforms.

  • Charts that show actions and risks assign the same risk statement to all the affected VMs. This can seem confusing. For example, assume one VM needs to resize to address vCPU risk, and 9 other VMs are set to resize consistently with it. Then charts will state that 10 VMs need to resize to address vCPU risks.

Aggressiveness and observation periods

Turbonomic uses these settings to calculate utilization percentiles for vCPU, vMEM, IOPS, and VPs. It then recommends actions to improve utilization based on the observed values for a given time period.

  • Aggressiveness

    Attribute

    Default Value

    Aggressiveness

    75th Percentile

    When evaluating performance, Turbonomic considers resource utilization as a percentage of capacity. The utilization drives actions to scale the available capacity either up or down. To measure utilization, the analysis considers a given utilization percentile. For example, assume a 75th percentile. The percentile utilization is the highest value that 75% of the observed samples fall below. Compare that to average utilization, which is the average of all the observed samples.

    Using a percentile, Turbonomic can recommend more relevant actions. For scheduled policies, the more relevant actions will tend to remain viable when their execution is put off to a later time.

    For example, consider decisions to reduce the capacity for CPU on a VM. Without using a percentile, Turbonomic never resizes below the recognized peak utilization. For most VMs, there are moments when peak CPU reaches high levels, such as during reboots, patching, and other maintenance tasks. Assume utilization for a VM peaked at 100% just once. Without the benefit of a percentile, Turbonomic will not reduce allocated CPU for that VM.

    With Aggressiveness, instead of using the single highest utilization value, Turbonomic uses the percentile you set. For the above example, assume a single CPU burst to 100%, but for 75% of the samples CPU never exceeded 50%. If you set Aggressiveness to 75th Percentile, then Turbonomic can see this as an opportunity to reduce CPU allocation for the VM.

    In summary, a percentile evaluates the sustained resource utilization, and ignores bursts that occurred for a small portion of the samples.

    By default, Turbonomic uses samples from the last 30 days. Use the Max Observation Period setting to adjust the number of days. To ensure that there are enough samples to analyze and drive scaling actions, set the Min Observation Period.

  • Max Observation Period

    Attribute

    Default Value

    Max Observation Period

    Last 90 Days

    To refine the calculation of resource utilization percentiles, you can set the sample time to consider. Turbonomic uses historical data from up to the number of days that you specify as a sample period. If the database has fewer days' data then it uses all of the stored historical data.

    You can make the following settings:

    • Less Elastic – Last 90 Days

    • Recommended – Last 30 Days

    • More Elastic – Last 7 Days

    Turbonomic recommends an observation period of 30 days following the monthly workload maintenance cycle seen in many organizations. VMs typically peak during the maintenance window as patching and other maintenance tasks are carried out. A 30-day observation period means that Turbonomic can capture these peaks and increase the accuracy of its sizing recommendations.

    You can set the value to 7 days if workloads need to resize more often in response to performance changes. For workloads that cannot handle changes very often or have longer usage periods, you can set the value to 90 days.

  • Min Observation Period

    Attribute

    Default Value

    Min Observation Period

    None

    Especially for scheduled actions, it is important that resize calculations use enough historical data to generate actions that will remain viable even during a scheduled maintenance window. A maintenance window is usually set for "down" time, when utilization is low. If analysis uses enough historical data for an action, then the action is more likely to remain viable during the maintenance window.

    • More Elastic – None

    • Less Elastic – 7 Days

Placement policies

Turbonomic supports placement policies for on-prem VMs, as follows:

  • You can create placement policies to enforce constraints for VM placements.

    For example, the VMs in a consumer group can only run on a host that is in the provider group. You can limit the number of consumers that can run on a single provider - for hosts in the provider group, only 2 instances of VMs in the consumer group can run on the same host. Or no more than the specified number of VMs can use the same storage device.

  • For VMs that require paid licenses, you can create placement policies that set up certain hosts to be the VMs' preferred license providers. Turbonomic can then recommend consolidating VMs or reconfiguring hosts in response to changing demand for licenses.

For more information, see Creating Placement Policies.

Note:

For VMM targets, IBM automatically imports your Availability Sets, representing them as placement policies for the affected infrastructure. To see these availability sets, go to the Settings > Policies page and click Imported Placement Policies.

For more information, see Importing Workload Placement Policies.