Turbonomic User Guide 8.5.0

Turbonomic 8.5.

0
User Guide
COPYRIGHT

Copyright © 2010 - 2022 Turbonomic, Inc. All rights reserved

LEGAL INFORMATION AND RESOURCES

https://www.turbonomic.com/company/legal/
ii Turbonomic, Inc. www.turbonomic.com

Contents
What’s New................................................................................................................................................................. 8
Introducing Turbonomic............................................................................................................................................. 11
How Turbonomic Works.............................................................................................................................................. 11
The Desired State................................................................................................................................................ 12
The Market and Virtual Currency........................................................................................................................13
Risk Index.............................................................................................................................................................14
The Turbonomic Supply Chain.............................................................................................................................15
Turbonomic Targets..................................................................................................................................................... 16
Resource Descriptions................................................................................................................................................. 19
Getting Started.......................................................................................................................................................... 23
Logging In to Turbonomic........................................................................................................................................... 23
The Home Page........................................................................................................................................................... 24
APPLICATION View...............................................................................................................................................25
ON-PREM View.................................................................................................................................................... 26
CLOUD View.........................................................................................................................................................27
Configuring Targets...................................................................................................................................................... 45
AWS Billing Families.............................................................................................................................................49
Azure Enterprise Agreements..............................................................................................................................51
Supply Chain of Entities.............................................................................................................................................. 53
Working With a Scoped View......................................................................................................................................54
Scoping the Turbonomic Session.........................................................................................................................55
Overview Charts.................................................................................................................................................. 58
Details View......................................................................................................................................................... 59
Scope Policies...................................................................................................................................................... 61
List of Entities...................................................................................................................................................... 64
Navigating With the Supply Chain.......................................................................................................................65
Viewing Cluster Headroom..................................................................................................................................66
Turbonomic Actions.....................................................................................................................................................67
Actions by Entity Type.........................................................................................................................................68
Action Types.........................................................................................................................................................76
Action Categories.................................................................................................................................................80
Action Modes.......................................................................................................................................................82
Working With the Generated Actions................................................................................................................. 82
Pending Actions................................................................................................................................................... 84
Turbonomic 8.5.0 User Guide iii

Contents
Actions Tips and Best Practices...........................................................................................................................93

Working With Policies................................................................................................................................................. 94
Placement Policies............................................................................................................................................... 95
Automation Policies........................................................................................................................................... 100
Entity Types - Applications.......................................................................................................................................127
Business Application.................................................................................................................................................. 127
Turbonomic as a Business Application.............................................................................................................. 129
Business Application Policies.............................................................................................................................130
Business Transaction..................................................................................................................................................131
Business Transaction Policies.............................................................................................................................133
Service........................................................................................................................................................................134
Service Policies...................................................................................................................................................138
Application Component.............................................................................................................................................140
Application Component Policies........................................................................................................................143
Application Topology................................................................................................................................................. 145
Entity Types - Container Platform............................................................................................................................ 147
Container................................................................................................................................................................... 150
Container Policies.............................................................................................................................................. 155
Container Spec...........................................................................................................................................................156
Container Spec Policies......................................................................................................................................157
Workload Controller.................................................................................................................................................. 160
Workload Controller Policies............................................................................................................................. 161
Container Pod............................................................................................................................................................ 162
Container Pod Policies....................................................................................................................................... 166
Namespace................................................................................................................................................................ 166
Container Cluster....................................................................................................................................................... 170
Kubernetes CPU Metrics............................................................................................................................................173
Entity Types - Cloud Infrastructure...........................................................................................................................176
Virtual Machine (Cloud)............................................................................................................................................ 177
Cloud VM Policies.............................................................................................................................................. 184
Database Server (Cloud)............................................................................................................................................189
Estimated On-demand Costs for Cloud Database Servers................................................................................ 196
Cloud Database Server Policies......................................................................................................................... 199
Estimated On-demand Costs for Cloud Database Servers................................................................................ 202
Volume (Cloud).......................................................................................................................................................... 205
Cloud Volume Policies....................................................................................................................................... 212
Database (Cloud)....................................................................................................................................................... 214
iv Turbonomic, Inc. www.turbonomic.com

Contents
Cloud Database Policies.....................................................................................................................................218

Estimated On-demand Costs for Cloud Databases........................................................................................... 220
Zone........................................................................................................................................................................... 224
Region........................................................................................................................................................................ 226
Entity Types - On-prem Infrastructure......................................................................................................................228
Virtual Machine (On-prem)....................................................................................................................................... 229
On-prem VM Policies.........................................................................................................................................235
Database Server (On-prem).......................................................................................................................................240
On-prem Database Server Policies.................................................................................................................... 242
Volume (On-prem).....................................................................................................................................................244
On-prem Volume Policies.................................................................................................................................. 245
Virtual Datacenter (Private Cloud)............................................................................................................................ 245
Business User.............................................................................................................................................................249
Business User Policies........................................................................................................................................251
Desktop Pool..............................................................................................................................................................253
Desktop Pool Policies.........................................................................................................................................254
View Pod....................................................................................................................................................................256
View Pod Policies...............................................................................................................................................258
Host............................................................................................................................................................................258
Host Policies.......................................................................................................................................................261
Chassis........................................................................................................................................................................263
Datacenter................................................................................................................................................................. 264
Storage....................................................................................................................................................................... 266
Storage Policies..................................................................................................................................................271
Logical Pool................................................................................................................................................................ 275
Logical Pool Policies...........................................................................................................................................277
Disk Array...................................................................................................................................................................278
Disk Array Policies..............................................................................................................................................280
Storage Controller......................................................................................................................................................282
Storage Controller Policies.................................................................................................................................283
IO Module..................................................................................................................................................................284
Switch.........................................................................................................................................................................285
Switch Policies....................................................................................................................................................286
Plans: Looking to the Future.................................................................................................................................... 287
Plan Management..................................................................................................................................................... 288
Setting Up Plan Scenarios......................................................................................................................................... 289
Plan Scenarios and Types.......................................................................................................................................... 295
Turbonomic 8.5.0 User Guide v

Contents
Optimize Container Cluster Plan....................................................................................................................... 298

Optimize Cloud Plan.......................................................................................................................................... 312
Migrate to Cloud Plan....................................................................................................................................... 318
Buy VM Reservations Plan.................................................................................................................................327
Alleviate Pressure Plan...................................................................................................................................... 333
Custom Plan.......................................................................................................................................................336
Configuring Nightly Plans.......................................................................................................................................... 346
Place: Reserve Workload Resources......................................................................................................................... 348
Creating a Reservation.............................................................................................................................................. 350
Managing Reservations............................................................................................................................................. 353
Dashboards: Focused Views..................................................................................................................................... 354
Built-in Dashboards................................................................................................................................................... 355
On-Prem Executive Dashboard..........................................................................................................................355
Cloud Executive Dashboard............................................................................................................................... 357
Container Platform Dashboard..........................................................................................................................358
Creating and Editing Custom Dashboards.................................................................................................................359
Creating and Editing Chart Widgets.......................................................................................................................... 362
Chart Types................................................................................................................................................................ 365
Actions and Impact Chart Types....................................................................................................................... 365
Status and Details Chart Types..........................................................................................................................372
Cloud Chart Types..............................................................................................................................................383
On-Prem Chart Types........................................................................................................................................ 403
Embedded Reporting................................................................................................................................................406
Creating Groups....................................................................................................................................................... 409
Working With Schedules.......................................................................................................................................... 412
Creating Schedules.................................................................................................................................................... 414
Templates: Resource Allocations for New Entities....................................................................................................417
Creating Templates.................................................................................................................................................... 418
VM Template Settings................................................................................................................................................419
Host Template Settings..............................................................................................................................................420
HCI Host Template Settings....................................................................................................................................... 422
Storage Template Settings......................................................................................................................................... 424
Billing and Costs.......................................................................................................................................................426
RI Purchase Profile.....................................................................................................................................................427
OS Migration Profile.................................................................................................................................................. 428
Price Adjustments......................................................................................................................................................429
Creating a Price Adjustment..............................................................................................................................430
vi Turbonomic, Inc. www.turbonomic.com

Contents
Price Override: Azure........................................................................................................................................ 433

Price Override: AWS.......................................................................................................................................... 435
Currency Settings.......................................................................................................................................................436
Administrative Tasks.................................................................................................................................................437
Managing User Accounts...........................................................................................................................................437
Configuring a Group for SSO Authentication.................................................................................................... 444
Maintenance: Logging and Troubleshooting............................................................................................................. 446
The Updates Page......................................................................................................................................................448
License Configuration................................................................................................................................................ 449
Email Settings............................................................................................................................................................ 451
Turbonomic 8.5.0 User Guide vii

What’s New
Turbonomic 8 is powered by our next-generation architecture, allowing the core platform to scale with large application
and infrastructure environments in a single-instance deployment. This eliminates complexity and provides scale-on-
demand capabilities, while continuing to assure application performance and health.
Version 8.5.0
• Cloud Native Improvements
◦ Actions to Resize Namespace Quota
Turbonomic treats quotas defined in a Namespace as constraints when making container resize decisions. If
existing container actions would exceed the namespace quotas, Turbonomic recommends actions to resize
up the affected namespace quota. In addition, if a container resize requires increased Namespace quotas,
Turbonomic blocks execution of the affected container resizes until you increase those quotas.
For details, see:
■ Workload Controller Actions (on page 161)
■ Resource Quotas (on page 167)
◦ For Azure Kubernetes Service (AKS), Execute Provision/Suspend Actions
For VMs/nodes that make up an Azure Kubernetes Service (AKS) cluster, you can now manually execute
recommended VM Provision and VM Suspend actions. For details, see Container Cluster Actions (on page
171)
◦ SLO Driven Horizontal Scaling
For horizontally scalable Kubernetes Services that collect performance metrics (or KPIs) for applications,
Turbonomic can now dynamically adjust the number of pod replicas that back those Services to help you meet
SLOs (Service Level Objectives) for your applications.
To take advantage of this feature, turn on horizontal scaling and specify SLO values in Service policies.
For details, see Actions for Kubernetes Services (on page 135).
• New Targets
◦ Support for Flexera One
8 Turbonomic, Inc. www.turbonomic.com

What’s New
Turbonomic now integrates its management of workloads with Flexera One License Management. To do this,
Turbonomic discovers the licenses and entitlements that you have configured in your Flexera environment. It
then creates groups and policies to represent these licenses and entitlements.
Turbonomic does not generate unique actions for entities it discovers through a Flexera target. Instead, it uses
the groups and policies to modify the actions it generates for the associated entities.
For details, see "Flexera One" in the Target Configuration Guide.
◦ Support for Google Cloud Platform (GCP)
This release introduces support for Google Cloud Platform (GCP). Turbonomic discovers your GCP environment
when you add the required accounts as targets, and recommends actions for VMs to assure performance at the
lowest possible cost.
For details, see "Google Cloud Platform" in the Target Configuration Guide.
◦ Support for IBM FlashSystem
This release introduces support for IBM FlashSystem storage platforms. Turbonomic discovers FlashSystem
enclosures, MDisks (arrays), pools, and volumes. Turbonomic includes these entities and their relationships
with other entities in the supply chain, from Hypervisor to Application. Analysis of FlashSystem entities
influences actions such as VM Storage Placement, to continuously manage application storage performance
and resources.
For details, see "IBM FlashSystem" in the Target Configuration Guide.
If you are updating to this version, you must enable these targets before you can use them. To enable these targets,
open the charts_v1alpha1_xl_cr.yaml file for editing and add the following entries to the list of probes:
◦ flexera:
enabled: true
◦ gcp:
enabled: true
◦ flashsystems:
enabled: true
For more information, see "Enabling and Disabling Probe Components" in the Installation Guide.
• AWS Improvements:
◦ AWS M6i instances
This release includes support for the new AWS M6i family of instances.
◦ Improved cost calculations for AWS
AWS Billing Targets now discover Compute Savings Plans, and incorporates that data in its calculations for
compute costs. You can see the associated costs in Cost by Service charts.
• Azure Improvements
◦ Azure Dv5 and Ev5 Instance Types
This release includes support for the Azure Dv5- and Ev5-series instance types.
◦ Azure App Service Discovery
Turbonomic now discovers the app services and plans that make up your Azure App Service deployment when
you add an Azure account. In the supply chain, app services appear as Service entities, while plans that define
compute resources for app services appear as Application Components.
Turbonomic 8.5.0 User Guide 9

What’s New
• Group Filtering
◦ For VM Groups, Filters for VM Installed VM Tools
When you create groups of VMs, you can specify filters to limit the items that the group will include. This
release introduces two new filters for VM groups:
■ Vendor Tools Installed:
For vCenter Server VMs. This can be true or false so it can limit group membership to VMs that do or do
not have VM Tools installed.
■ Vendor Tools Version:
A RegularExpression string that can limit group membership to VMs with matching version of VM tools.
Also note that vor vCenter Server VMs, the user interface shows the tools version number in the Information
chart for the VM.
◦ For VM groups, you can use the new multiple of vCPU filter
You can now create groups of VMs that have a number of vCPUs that are a multiple of a given number. For
example, you can create a group of all VMs with an even number of vCPUs. Or to create a group of all VMs that
have an odd number of vCPUs, use the filter, not multiple of 2. Then you can create policies to enforce an even
number of vCPUs for your VMs.
• Improved resource calculations for Cisco AppDynamics
Turbonomic analysis now uses percentile calculations when analyzing the vMem and vCPU utilization of VMs
discovered in your AppDynamics environment.
• Improved action details for VMs
Action details for VMs now show whether Hot-Add is enabled for the VM, and how long the VM has been in
your environment. The details also show vCPU, Socket, and Cores Per Socket changes that will result from the
recommended action.
• Fabric and vCenter Stitching
For Fabric targets, when Turbonomic discovers that blade servers housed in a particular chassis have been
designated as vCenter hosts, the supply chain will now stitch the blade servers and chassis to the corresponding
vCenter datacenter to establish their relationship. When you set the scope to that datacenter and view the Health
chart, you will now see the blade servers in the list of hosts. In addition, when the datacenter is included in a merge
policy (a policy that merges datacenters for the purpose of VM placement), the VMs in the blade servers apply the
policy, allowing them to move between datacenters as necessary.
• System Health Notifications
The Notification Center now includes a tab for System Health. This new tab displays the results of Health
Checks. The Health Checks report on issues with target connectivity. You can use this information to help with
troubleshooting.
• Cost Breakdown by Tag
This release includes the new Cost Breakdown by Tag chart. This chart shows the costs for tagged cloud entities that
Turbonomic has discovered in your Azure environment. For the tagged entities in scope, the chart shows how daily
costs change over time.
For details, see Cost Breakdown by Tag Charts (on page 386).

Introducing Turbonomic
Thank you for choosing Turbonomic, the premier solution for Application Resource Management (ARM) of cloud and
virtual environments.
Application Resource Management is a top-down, application-driven approach that continuously analyzes applications'
resource needs and generates fully automatable actions to ensure applications always get what they need to perform. It
runs 24/7/365 and scales with the largest, most complex environments.
To perform Application Resource Management, Turbonomic represents your environment holistically as a supply
chain of resource buyers and sellers, all working together to meet application demand. By empowering buyers (VMs,
instances, containers, and services) with a budget to seek the resources that applications need to perform, and sellers to
price their available resources (CPU, memory, storage, network) based on utilization in real-time, Turbonomic keeps your
environment within the desired state — operating conditions that achieve the following conflicting goals at the same
time:
• Assured application performance
Prevent bottlenecks, upsize containers/VMs, prioritize workload, and reduce storage latency.
• Efficient use of resources
Consolidate workloads to reduce infrastructure usage to the minimum, downsize containers, prevent sprawl, and
use the most economical cloud offerings.
Turbonomic is a containerized, microservices architected application running in a Kubernetes environment (or within
a VM) on your network or a public cloud VPC. You then assign services running on your network to be Turbonomic
targets. Turbonomic discovers the entities (physical devices, virtual components and software components) that each
target manages, and then performs analysis, anticipates risks to performance or efficiency, and recommends actions you
can take to avoid problems before they occur.
How Turbonomic Works

To keep your infrastructure in the desired state, Turbonomic performs Application Resource Management. This is an
ongoing process that solves the problem of assuring application performance while simultaneously achieving the most
efficient use of resources and respecting environment constraints to comply to business rules.

This is not a simple problem to solve. Application Resource Management has to consider many different resources
and how they are used in relation to each other, and numerous control points for each resource. As you grow your
infrastructure, the factors for each decision increase exponentially. On top of that, the environment is constantly
changing — to stay in the desired state, you are constantly trying to hit a moving target.
To perform Application Resource Management, Turbonomic models the environment as a market made up of buyers
and sellers. These buyers and sellers make up a supply chain that represents tiers of entities in your inventory. This
supply chain represents the flow of resources from the datacenter, through the physical tiers of your environment, into
the virtual tier and out to the cloud. By managing relationships between these buyers and sellers, Turbonomic provides
closed-loop management of resources, from the datacenter, through to the application.
See the The Supply Chain (on page 53) for a visual layout of the buyer and seller relationships.
Turbonomic uses Virtual Currency to give a budget to buyers and assign cost to resources. This virtual currency assigns
value across all tiers of your environment, making it possible to compare the cost of application transactions with the
cost of space on a disk or physical space in a data center.
The price that a seller charges for a resource changes according to the seller’s supply. As demand increases, prices
increase. As prices change, buyers and sellers react. Buyers are free to look for other sellers that offer a better price,
and sellers can duplicate themselves (open new storefronts) to meet increasing demand. Turbonomic uses its Economic
Scheduling Engine to analyze the market and make these decisions. The effect is an invisible hand that dynamically
guides your IT infrastructure to the optimal use of resources.
To get the most out of Turbonomic, you should understand how it models your environment, the kind of analysis it
performs, and the desired state it works to achieve.
The Desired State

The goal of Application Resource Management is to assure performance while maintaining efficient use of resources.
When performance and efficiency are both maintained, the environment is in the desired state. You can measure
performance as a function of delay, where zero delay gives the ideal QoS for a given service. Efficient use of resources is
a function of utilization where 100% utilization of a resource is the ideal for the most efficient utilization.
If you plot delay and utilization, the result is a curve that shows a correlation between utilization and delay. Up to a
point, as you increase utilization, the increase in delay is slight. There comes a point on the curve where a slight increase
in utilization results in an unacceptable increase in delay. On the other hand, there is a point in the curve where a

reduction in utilization doesn’t yield a meaningful increase in QoS. The desired state lies within these points on the
curve.
You could set a threshold to post an alert whenever the upper limit is crossed. In that case, you would never react to a
problem until delay has already become unacceptable. To avoid that late reaction you could set the threshold to post an
alert before the upper limit is crossed. In that case, you guarantee QoS at the cost of over-provisioning — you increase
operating costs and never achieve efficient utilization.
Instead of responding after a threshold is crossed, Turbonomic analyzes the operating conditions and constantly
recommends actions to keep the entire environment within the desired state. If you execute these actions (or let
Turbonomic execute them for you), the environment will maintain operating conditions that assure performance for
your customers, while ensuring the lowest possible cost thanks to efficient utilization of your resources.
The Market and Virtual Currency

To perform Application Resource Management, Turbonomic models the environment as a market, and uses market
analysis to manage resource supply and demand. For example, bottlenecks form when local workload demand
exceeds the local capacity — in other words, when demand exceeds supply. By modeling the environment as a market,
Turbonomic can use economic solutions to efficiently redistribute the demand or increase the supply.
Turbonomic uses two sets of abstraction to model the environment:
• Modeling the physical and virtual IT stack as a service supply chain
The supply chain models your environment as a set of managed entities. These include applications, VMs, hosts,
storage, containers, availability zones (cloud), and data centers. Every entity is a buyer, a seller, or both. A host
machine buys physical space, power, and cooling from a data center. The host sells resources such as CPU cycles
and memory to VMs. In turn, VMs buy host services, and then sell their resources (VMem and VCPU) to containers,
which then sell resources to applications.
See the The Supply Chain (on page 53) for a visual layout of the buyer and seller relationships.
• Using virtual currency to represent delay or QoS degradation, and to manage the supply and demand of services
along the modeled supply chain
The system uses virtual currency to value these buy/sell transactions. Each managed entity has a running budget —
the entity adds to its budget by providing resources to consumers, and the entity draws from its budget to pay for
the resources it consumes. The price of a resource is driven by its utilization — the more demand for a resource, the
higher its price.


These abstractions open the whole spectrum of the environment to a single mode of analysis — market analysis.
Resources and services can be priced to reflect changes in supply and demand, and pricing can drive resource allocation
decisions. For example, a bottleneck (excess demand over supply) results in rising prices for the given resource.
Applications competing for the same resource can lower their costs by shifting their workloads to other resource
suppliers. As a result, utilization for that resource evens out across the environment and the bottleneck is resolved.
Risk Index
Turbonomic tracks prices for resources in terms of the Risk Index. The higher this index for a resource, the more heavily
the resource is utilized, the greater the delay for consumers of that resource, and the greater the risk to your QoS.
Turbonomic constantly works to keep the Risk Index within acceptable bounds.
You can think of Risk Index as the cost for a resource — Turbonomic works to keep the cost at a competitive level.
This is not simply a matter of responding to threshold conditions. Turbonomic analyzes the full range of buyer/seller
relationships, and each buyer constantly seeks out the most economical transaction that is available.
This last point is crucial to understanding Turbonomic. The virtual environment is dynamic, with constant changes
to workload that correspond with the varying requests your customers make of your applications and services. By
examining each buyer/seller relationship, Turbonomic arrives at the optimal workload distribution for the current state
of the environment. In this way, it constantly drives your environment toward the desired state.

NOTE:
The default Turbonomic configuration is ready to use in many environments. However, you can fine-tune the
configuration to address special services and resources in your environment. Turbonomic provides a full range of
policies that you can set to control how the software manages specific groups of entities. Before you make such policy
changes, you should understand default Turbonomic operation. For more information about policies, see Working
With Policies (on page 94).
The Turbonomic Supply Chain

Turbonomic models your environment as a market of buyers and sellers. It discovers different types of entities in
your environment via the targets you have added, and then maps these entities to the supply chain to manage the
workloads they support. For example, for a hypervisor target, Turbonomic discovers VMs, the hosts and datastores
that provide resources to the VMs, and the applications that use VM resources. For a Kubernetes target, it discovers
services, namespaces, containers, container pods, and nodes. The entities in your environment form a chain of supply
and demand where some entities provide resources while others consume the supplied resources. Turbonomic stitches
these entities together, for example, by connecting the discovered Kubernetes nodes with the discovered VMs in
vCenter.
For information about specific members of the supply chain, see The Supply Chain (on page 53).
Supply Chain Terminology

Turbonomic introduces specific terms to express IT resources and utilization in terms of supply and demand. These
terms are largely intuitive, but you should understand how they relate to the issues and activities that are common for
IT management.
Term: Definition:
Commodity The basic building block of Turbonomic supply and demand. All the resources that
Turbonomic monitors are commodities. For example, the CPU capacity or memory that a
host can provide are commodities. Turbonomic can also represent clusters and segments
as commodities.
When the user interface shows commodities, it’s showing the resources a service
provides. When the interface shows commodities bought, it’s showing what that service
consumes.
Composed Of The resources or commodities that make up the given service. For example, in the user
interface you might see that a certain VM is composed of commodities such as one or
more physical CPUs, an Ethernet interface, and physical memory.
Contrast Composed Of with Consumes, where consumption refers to the commodities
the VM has bought. Also contrast Composed Of with the commodities a service offers for
sale. A host might include four CPUs in its composition, but it offers CPU Cycles as a single
commodity.
Consumes The services and commodities a service has bought. A service consumes other
commodities. For example, a VM consumes the commodities offered by a host, and an
application consumes commodities from one or more VMs. In the user interface you can
explore the services that provide the commodities the current service consumes.

Term: Definition:
Entity A buyer or seller in the market. For example, a VM or a datastore is an entity.
Environment The totality of data center, network, host, storage, VM, and application resources that you
are monitoring.
Inventory The list of all entities in your environment.
Risk Index A measure of the risk to Quality of Service (QoS) that a consumer will experience. The
higher the Risk Index on a provider, the more risk to QoS for any consumer of that
provider’s services.
For example, a host provides resources to one or more VMs. The higher the Risk Index on
the provider, the more likely that the VMs will experience QoS degradation.
In most cases, for optimal operation the Risk Index on a provider should not go into
double digits.
Turbonomic Targets
You can assign instances of the following technologies as Turbonomic targets:
• Applications and Databases
◦ Apache Tomcat 7.x, 8.x, and 8.5.x
◦ AppDynamics 4.1+
◦ AppInsights
◦ Dynatrace 1.1+
◦ IBM WebSphere Application Server 8.5+
◦ Instana
◦ JBoss Application Server 6.3+
◦ JVM 6.0+
◦ Microsoft SQL Server 2012, 2014, 2016, 2017, and 2019
◦ MySQL 5.6.x and 5.7.x
◦ NewRelic
◦ Oracle 11g R2 and 12c
◦ Oracle WebLogic 12c
• Cloud Native
◦ Kubernetes
◦ OpenShift 3.3+
• Fabric and Network
◦ Cisco UCS Manager 3.1+
◦ HPE OneView 3.00.04+
• Guest OS Processes
◦ SNMP

◦ WMI: Windows versions 2019, 2016, 2012 / 2012 R2, 2008 R2, 10, 8 / 8.1, and 7
• Hyperconverged
◦ Nutanix Community Edition
◦ VMware vSAN
• Hypervisors
◦ Citrix XenServer 5.6.x and 6.x
◦ Microsoft Hyper-V 2008 R2, Hyper-V 2012/2012 R2, Hyper-v 2016, Hyper-v 2019
◦ VMware vCenter 6.0, 6.5, 6.7, and 7.0+
• Orchestrator
◦ Action Script
◦ Flexera One
◦ ServiceNow
• Private Cloud
◦ Microsoft System Center 2012/2012 R2 Virtual Machine Manager and System Center 2016 Virtual Machine
Manager
• Public Cloud
◦ Amazon AWS
◦ Amazon AWS Billing
◦ Google Cloud Platform (GCP)
◦ Google Cloud Platform (GCP) Billing
◦ Microsoft Azure Service Principal
◦ Microsoft Enterprise Agreement
• Storage
◦ EMC ScaleIO 2.x and 3.x
◦ EMC VMAX using SMI-S 8.1+
◦ EMC VPLEX Local Architecture with 1:1 mapping of virtual volumes and LUNs
◦ EMC XtremIO XMS 4.0+
◦ HPE 3PAR InForm OS 3.2.2+, 3PAR SMI-S, 3PAR WSAPI
◦ IBM FlashSystem running on Spectrum Virtualize 8.3.1.2 or later (8.4.2.0 or later recommended)
◦ NetApp Cmode/7mode using ONTAP 8.0+ (excluding AFF and SolidFire)
◦ Pure Storage F-series and M-series arrays
• Virtual Desktop Infrastructure
◦ VMware Horizon
The following sections describe these targets. For information about assigning targets to Turbonomic, see the Target
Configuration Guide.
Hypervisors
Turbonomic can use a range of VM managers as targets. For general discussion, this document refers to the various
supported VM managers as hypervisors.

Turbonomic uses hypervisor targets to access information about the managed VMs, hosts, and datastores, and also to
execute commands such as provisioning, resizing, or reconfiguring entities in the environment. Through the hypervisor,
Turbonomic can perform system monitoring, report on wasted storage, recommend actions, execute moves for VMs and
VM storage, and execute VM reconfiguration (change CPU count, memory, etc.).
The entities Turbonomic discovers through hypervisor targets include:
• VMs
• Physical machines that host VMs
• Datastores that support the VMs
• Datacenters
Cloud Managers
Cloud Managers provide a layer of control to deliver virtual infrastructures that can be deployed automatically, or in a
self-service offering to customers. They define and manage virtual datacenters (VDCs) — provider VDCs to manage the
physical and virtual resources that support the cloud offering, and consumer VDCs that present limited resources to
customers.
You can create special Turbonomic user accounts for consumer VDC customers. Such an account has a limited scope,
and the user cannot see any of the resources outside of that scope. In this way, you can offer Turbonomic to cloud
customers without exposing any proprietary infrastructure data to them. For more information, see Managing User
Accounts (on page 437).
The entities Turbonomic discovers through cloud manager targets include:
• Consumer VDCs
Virtual resources that are available to customers.
• Provider VDCs
Physical resources that provide the infrastructure to support Consumer VDCs.
Storage Managers
Storage managers provide management and distribution of data storage across disk arrays. Storage managers can
support thin provisioning, deduplication, and HA architectures. Turbonomic monitors resource utilization across the
storage system to optimize placement and provisioning of volumes and disk arrays, as well as management of storage
controller resources.
The entities Turbonomic discovers through storage manager targets include:
• Storage Controllers (NetApp controllers/filers, VNX processors)
• Disk Arrays (aggregates, clustered aggregates, storage pools, RAID groups)
• Datastores (volumes or LUNs)
Fabric Managers
Fabric managers provide a point of control for fabrics that unify compute, network, storage, and virtual resources within
a single system.

The entities Turbonomic discovers through fabric managers targets include:

• UCS Domains
• Chassis
• Fabric Interconnects
• IO Modules
Resource Descriptions
To perform intelligent workload balancing, Turbonomic collects raw data from its target servers – hypervisors, cloud
management stacks, public cloud accounts, etc. Turbonomic polls its targets at 10-minute intervals to collect the latest
data samples. It then uses these 10-minute data points for analysis and to display data in the GUI.
The way Turbonomic collects host memory data from vCenter Server illustrates how this works. vCenter Server collects
peak metrics from its managed VMs at 20-second intervals. Every ten minutes Turbonomic polls vCenter Server to
collect its last round of data samples (30 samples in 10 minutes). To track a VM's utilization of host memory, Turbonomic
requests memory.active data samples from vCenter. From that polling, Turbonomic can track:
• Peak Memory Utilization - Turbonomic uses the greatest value in each polling sample. This gives the highest
percentage of active memory utilization for the selected VM (or group of VMs), calculated over the selected time
period. For a maximum value, Turbonomic uses the highest observed active memory value in the data sample.
• Average Memory Utilization - Turbonomic averages all the values in each polling sample.
The following table lists the metrics Turbonomic collects, and includes details about how they are collected or
measured. When the Turbonomic user interface plots charts of clusters or groups of devices, these charts show the
average of the percentage of allocated resources that are used.
Resource: Description:
1- 2- 4-CPU Rdy Wait time in the ready queue on the host, measured in ms. Turbonomic monitors 1-CPU,
2-CPU, 4-CPU, up to 32-CPU ready queues on hosts. Charts show 1 - 4 CPU values. The
charts show the percentage allocated ready queue capacity that is in use on the host. For
host charts, this is a measure of the total ready queue wait time for all the VMs running
on that host.
Balloon Ballooning capacity on the PM, measured in KBytes. This capacity is the greater of:
• 65% of the VMem configured for all powered-on VMs that the PM hosts
• The physical memory capacity of the PM
Charts show the percentage of the PM’s ballooning capacity that is in use.
Buffer For network environments that support buffered switch ports (Arista networks), this
resource measures utilization of a port buffer. For example, if a host connects to the
network through port 1 on a switch, and that port has enough traffic to cause packet
buffering, this resource will show utilization.
Connection The connections in use, as a percentage of the maximum connections allowed on the
database. Database configuration determines the capacity for this resource.
Cooling Allocated cooling indicates the highest acceptable running temperature for a physical
device, such as a chassis in a compute fabric.

CPU Host CPU capacity, measured in MHz. This shows what percentage of CPU cycles are
devoted to processing instructions.
• Host charts show the percentage of the host’s CPU capacity that is in use.
• VM charts show the percentage of the host’s CPU capacity that is consumed by the
given VM.
DBMem The memory in use by the database, as a percentage of the allocated capacity. Database
configuration determines the capacity for this resource. Note that for databases,
Turbonomic uses this resource to drive actions, instead of the VMem on the hosting VM.
This means that actions are driven by the actual memory consumption on the database.
Flow0 — InProvider For measuring network flow, the flow that is within a single provider — For example, the
Flow network flow between VMs that are hosted by the same physical machine. This measures
network flow between consumers that are on the same set of closely connected
providers. Charts show the percentage of capacity that is utilized. Note that Turbonomic
assumes an unlimited supply of InProvider Flow because this flow does not go across the
physical network.
Flow1 — InDPOD Flow For measuring network flow, the flow that is local to the given DPOD. This measures
network flow between consumers that are on the same set of closely connected
providers. Charts show the percentage of capacity that is utilized.
Flow2 — CrossDPOD For measuring network flow, the flow that is between different DPODs. This measures
Flow network flow between consumers that are on different sets of closely connected
providers. Charts show the percentage of capacity that is utilized.
Heap The heap capacity allocated for an Application Component. Charts show the percentage
of capacity that is used by an Application Component.
HotStorage For Nutanix platforms, the storage capacity on the server-attached flash.
IO Data rate through the host’s IO adapter, measured in KBytes/sec.
• Datacenter charts show the average percentage of the host IO capacity that is in use,
for all the hosts in the datacenter.
• Host charts show the percentage of the host’s total IO capacity that is in use.
IOPS Storage access operations per second. Charts show the percentage of allocated IOPS
capacity that is used on a datastore.
Latency Allocated capacity for latency on a datastore. This measures the latency experienced by
all VMs and hosts that access the datastore. Charts show the percentage of allocated
latency that is in use on the datastore.
Mem Host memory, measured in Kbytes.
• Host charts show the percentage of the host’s memory that is in use.
• VM charts show the percentage of the host’s memory that is consumed by the given
VM.
NET Data rate through the host’s Network adapter, measured in Kbytes/sec.
• Datacenter charts show the average percentage of the host NET capacity that is used
for all the hosts in the datacenter.

• Host charts show the percentage of the host’s total NET capacity that is in use.
nfu (AWS only) Normalized Factor Unit.
For RIs in AWS environments, the nfu is a measure of RI capacity that you can use to
compare or combine the capacity for different template families. For example, the
normalized factors for some template families include:
• nano: 0.25
• micro: 0.5
• small: 1
• medium: 2
• large: 4
Turbonomic measures RI utilization and coverage in terms of these normalized factors.
Power A measure of the power that is consumed by a physical device.
RI ratio (Azure only) For Azure environments, RI ratio is the number of RI units compared to the total number
of RI units for a given Turbonomic scope. Each workload is assigned RI units based on its
instance type. For example, here are some instance types with RI units:
• Standard_DS2_v2: 1
• Standard_B2ms: 3
RI ratio information appears in the tooltips of cloud RI charts. Information about the
Azure instance types and their RI workloads is provided in the RI Inventory chart.
Azure RI ratio and AWS NFU are equivalent concepts.
Response Time Response time in ms. You set response time capacity in the Policies view.
Swap The rate of memory swapping to disk, in bytes per second. The default capacity is
5,000,000 Byte/sec.
Threads Allocated thread capacity. Charts show the percentage of thread capacity that is
consumed by an Application Component.
TransactionLog The disk space devoted to transaction logging for a database.
Transactions Transactions per second. Charts show the percentage of allocated transaction capacity
that is in use.
Risk Index A measure of the impact on Quality of Service (QoS) that a consumer will experience.
The higher the Risk Index on a provider, the more risk to QoS for any consumer of that
provider’s services.
For all the resources that impact performance or risk, charts show the Risk Index for the
most utilized resource of a given entity. For example, if a host has a Risk Index of 6 for
MEM and 12 for CPU, the chart will show the higher value.
VCPU The allocated CPU capacity, measured in MHz. Charts show the percentage of VCPU
cycles that are devoted to processing instructions.
VMem The allocated memory capacity, measured in Kbytes. Charts show the percentage of
VMem that is in use.

Note that percentages of allocated VMem are measured against whichever is the less of:
The VMem limit (if set) or the allocated VMem capacity. This is also true in reports and
recommended actions. For example, assume a VM with allocated VMem of 8 GB, but a
limit of 4 GB. In this case, the percentage in a chart shows the percentage utilized of 4GB.
VStorage The allocated virtual storage capacity, measured in Kbytes. Charts show the percentage of
storage that is in use.

Getting Started
To get started with the platform, open a web browser to your Turbonomic installation. The Turbonomic platform serves
the user interface to your browser, where you can log in and get started managing your environment. In this way, you
can access the unique capabilities of Turbonomic from any internet connection.
Logging In to Turbonomic
To get started with the platform, open a web browser to your Turbonomic installation. The Turbonomic platform serves
the user interface to your browser, where you can log in and get started managing your environment. In this way, you
can access the unique capabilities of Turbonomic from any internet connection.
Before you can log in, your enterprise must have a valid Turbonomic account, or an instance of Turbonomic must be
installed in your environment. To get the IP address of your Turbonomic installation, contact your system administrator.
To log in to Turbonomic:
1. Navigate your Web browser to the Turbonomic installation.
For the URL, provide the IP address or machine name for the installation. This URL opens the Turbonomic Login
page. You should bookmark this URL for future use.
2. Provide the user name and password for your account.
Your system administrator creates user accounts. Contact your system administrator for login information.
After you log in, the browser opens to the Home Page (on page 24). This page is your starting point for sessions with
the Turbonomic platform. From the Home Page you can see the overviews of your environment.
To display this information, Turbonomic communicates with target services such as hypervisors, storage controllers, and
public cloud accounts. Note that your Turbonomic administrator sets up the target configuration. For information about
supported targets and how to configure them, see "Target Configuration" in the Target Configuration Guide.

Getting Started
The Home Page

When you launch Turbonomic, the Home Page is the first view you see. From there you can:
• Choose a View to see overviews of your environment:
◦ APPLICATION – See your environment in the context of your Business Applications (on page 127).
◦ ON-PREM – See details for the on-prem environment. Notice that the Supply Chain excludes cloud entities and
only shows the entities that are on-prem.
◦ CLOUD – See details for the cloud environment, including pending actions, a listing of your cloud accounts by
cost, the locations of cloud datacenters that you are using, estimated costs, and other cost-related information.
• Use the Supply Chain Navigator to inspect lists of entities
Click an entity tier in the Supply Chain to see a list of those entities. For example, click Virtual Machine to see a list
of all the VMs in your environment.
• Navigate to other Turbonomic pages, including:
◦ Search – Set the session scope to drill down to details about your environment
◦ Plan – Run what-if scenarios
◦ Place – Use Turbonomic to calculate the best placement for workloads, and execute the placement at the time
you specify
◦ Dashboards – Set up custom views with charts that focus on specifics in your environment
◦ Settings – Configure Turbonomic to set up business rules and policies, configure targets, define groups, and
perform other administrative tasks

Getting Started
Getting Home

Wherever you are in your Turbonomic session, you can always click the Home icon to return to the Home Page.
APPLICATION View
The APPLICATION view presents your environment in the context of your Business Applications (on page 127). See
the overall health of your applications, examine any performance and compliance risks, and execute the actions that
Turbonomic recommends to address these risks.

This view also shows the Business Transactions (on page 131) and Services (on page 134) that make up your
Business Applications. You can see finer details and set SLOs at these levels of the application model.
NOTE:
If certain application entities do not stitch into the supply chain infrastructure for some reason, Turbonomic displays
them in both the ON-PREM and the CLOUD views. Once Turbonomic can stitch them into the infrastructure, it
classifies them according to the class of the infrastructure and displays them in the correct views.

Getting Started
ON-PREM View
When you set your session to the Global Scope, you can then select the ON-PREM view. This shows an overview of your
on-prem environment. If you don't have any workload on the public cloud, then you should use this as your starting
point for a Turbonomic session. If you have a hybrid environment (on-prem and on the public cloud), then you can refer
to this view to see a detailed on-prem overview.

The Supply Chain shows all the on-prem entities in your environment. The charts show details about your environment,
including:
• Overviews of pending actions
When appropriate, the overview includes estimated one-time savings or costs associated with the actions.
• Top Cluster utilization
See a list of the most utilized clusters. The chart shows these clusters, along with a count of actions for each. To
drill down into the cluster details, click the cluster name. To see and execute the specific actions, click the ACTIONS
button for that cluster. To see all the clusters in your environment, click SHOW ALL.
• Optimized Improvements
Compare current resource utilization with the utilization you would see if you choose to execute all the pending
actions.
• Action history
You can see a history of all actions that have been recommended and executed, or of just the actions that have
been accepted and executed.

Getting Started
CLOUD View
When you set your session to the Global Scope, you can then select the CLOUD view. This shows an overview of your
cloud environment. If all your workload is on the public cloud, then you should use this as your starting point for a
Turbonomic session. If you have a hybrid environment (on-prem and on the public cloud), then you can refer to this view
to see a detailed cloud overview.

To view cloud cost information, you must have one or more public cloud targets set up in your Turbonomic installation.
For information about setting up public cloud targets, see " Private Cloud" in the Target Configuration Guide.
In addition, to view full cost information in AWS, you must have created a Cost and Usage report in your AWS account
and you must store it in an S3 bucket.
For more information, see Displaying AWS Spend In Turbonomic.
In this view, the Supply Chain shows all the cloud entities in your environment. The charts show details about your cloud
environment, including:
• Overviews of pending actions
The overview includes the estimated monthly savings or cost associated with those actions.
• Top Accounts utilization
See a list of the most utilized public cloud accounts. The chart shows these accounts, along with an estimate of the
monthly cost for each. To see all the cloud accounts in your environment, click SHOW ALL.

Getting Started
• Necessary Investments and Potential Savings

For the current set of pending actions, these charts show the impact in dollar value. Necessary Investments are
from actions to provision more workloads or to resize workloads up. Potential Savings are from actions to resize
down, or to purchase RI resources and put them into active use.
• Charts that show your current Reserved Instance strategy. For details, see RI Charts (on page 38).
• Billed Cost by Service
This chart shows costs over time for each cloud service that you use in your cloud accounts. For example, you can
see the cost for AWS CloudWatch, compared to the cost for AWS S3 storage.
Tracking Cloud Cost

Cost for Services
Turbonomic uses the billing reports from your cloud service providers, as they are associated with your cloud targets.
Turbonomic parses these reports to get cost breakdowns by service, service provider, Azure Resource Group, and cloud
account. You can see cost data in charts such as:
• Cloud Estimated Cost
• Cost Breakdown by Cloud Accounts, Component, or Service Provider
• Expenses
Workload Expenses
Workloads are the VMs running in your environment, or other hosted processes such as database servers and
containers. Turbonomic tracks the following expenses for your workloads:
• Compute
For compute expenses Turbonomic uses hourly expense per template as specified in the associated public cloud
account.
• Storage
Turbonomic discovers the storage tier that supports a given workload, and uses the tier pricing to calculate storage
cost.
• License
For AWS environments, Turbonomic can calculate OS costs. To calculate the OS cost for a VM, Turbonomic subtracts
the template cost from the published workload cost. It assumes the difference is the license cost for that workload.
If the OS is open source, then there will be no difference, and license cost is zero.
For Azure environments, Turbonomic can track OS costs for existing VMs. For RI Buy actions, Turbonomic does not
include the OS cost. For more information about Azure RIs, see Azure Enterprise Agreements (on page 51).
• IP
For some workloads, you might use IP services that incur a cost. For example, your cloud provider might charge to
grant a static IP to a VM. On AWS environments Turbonomic can include that cost in its calculation and analysis.
Turbonomic uses this cost information when making VM resize and placement decisions. You can see this information in
Expenses charts.

Getting Started
Costs for Dedicated Tenancy on AWS

When you create VMs on AWS, you can specify their tenancy. When you specify Dedicated Tenancy (DT), the VMs you
create are Amazon EC2 instances running on hardware that is dedicated to a single customer. To understand DT in the
context of Turbonomic, you should consider:
• For AWS, the Turbonomic supply chain shows an Availability Zone as a Host. The supply chain does not indicate
whether certain VMs have tenancy dedicated to specific resources in the given availability zone. Also, Turbonomic
does not discover or show the costs for dedicated hosting of your workloads.
• Pricing for DT workloads is different than pricing for Shared Tenancy. Turbonomic does not discover that difference,
and uses Shared Tenancy cost for the DT workloads. In action descriptions, the listed savings or investments will be
based on Shared Tenancy costs.
• Turbonomic discovers the true costs of RIs for DT workloads. However, because the on-demand VM costs are based
on Shared Tenancy, Turbonomic can overstate the savings you would get for purchasing and using RI capacity. In
most cases, recommendations to purchase RIs will be correct. However, the time to achieve ROI could take longer
than action descriptions and charts indicate.
• Some instance types that are valid for Shared Tenancy are not valid for DT. To see which instance types are valid for
your DT VMs, consult the AWS documentation or your AWS representative.
• Under some circumstances Turbonomic can recommend changing a workload to a valid instance type for the
tenant, even though the current type is already valid. This can happen when the instance type is not included in
the Offer File for the tenancy. For example, assume the t3a template family does not support dedicated tenancy.
However, assume that the user created a t3a instance with dedicated tenancy in the EC2 console. In that case,
Turbonomic will see this as a misconfiguration and recommend changing to a different instance type.
To address these issues, you can create groups that set a scope to your DT workloads. For example, you can use naming
conventions, tagging, or other means to identify your DT workloads. Then you can create dynamic groups based on
those indicators. With those groups, you can create policies and dashboards that correspond to the differences you see
in your DT environment. Use this approach to address issues for:
• Available Instance Types
To resize a workload, Turbonomic generates an action to change that workload to a different instance type. Because
Turbonomic does not discover the difference between instance types that are valid for DT and for Shared Tenancy,
it can recommend scaling a DT workload to an unavailable instance type. To avoid this, create a policy for the DT
group, and exclude the unavailable instance types.
• Displaying Costs
Turbonomic charts show the costs for your environment. If the scope includes Dedicated Tenancy workloads, then
the calculated cost will be incomplete. For example, since AWS does not return pricing data for converted RIs (that
is, RIs that have been exchanged at least once) that are on All Upfront payment plans, Turbonomic does not include
such RIs in its calculations of RI utilization or cost.
Use scope to minimize this effect. You can create separate dashboards for your DT and Shared Tenancy workloads.
Estimated On-demand Costs for Cloud VMs

Turbonomic considers a variety of factors when calculating Estimated On-demand Monthly Cost for a cloud VM.

Getting Started

AWS VMs and Azure VMs Without License Costs

Cost Calculation
For these VMs, the calculation for Estimated On-demand Monthly Cost can be expressed as follows:
On-demand Rate * Usage Not Covered by RIs * Uptime * 730 =

Estimated On-demand Monthly Cost
Where:
• On-demand Rate is the hourly cost for a VM's instance type without RI coverage.
◦ For AWS, this rate includes all license costs, but not storage or IP. You can obtain on-demand rates via Amazon
EC2 On-demand Pricing.
◦ For Azure, the rate does not include license costs, storage, or IP. You can obtain on-demand rates via Azure
Pricing Calculator.
NOTE:
Azure VMs covered by Azure Hybrid Benefit do not have license costs.
• Usage Not Covered by RIs is the percentage of hourly VM usage not covered by any RI. For example:
◦ RI Coverage = 20% (0.2)
◦ Usage Not Covered by RIs = 80% (0.8)
• Uptime is a percentage value that indicates how long a VM has been running over a period of time (age). Age refers
to the number of days that a VM has existed since first discovery. For VMs older than 30 days, Turbonomic only
calculates uptime over the last 30 days.
To estimate monthly on-demand costs, Turbonomic projects the current uptime value into the future. It assumes
that future uptime will be similar to the current uptime.
• 730 represents the number of hours per month that Turbonomic uses to estimate monthly costs.
The listed items above impact cost calculations, but not the actual scaling decisions that Turbonomic makes. These
decisions rely on other factors, such as resource utilization percentiles and scaling constraints set in policies.
Example
Assume the following data for a pending scale action for an AWS VM:

Getting Started

Current Values Values After Action Execution

On-demand Rate $0.012/hr $0.021/hr
RI Coverage 50% (0.5) 0% (0.0)
Usage Not Covered by RIs (calculated 50% (0.5) 100% (1.0)
based on RI coverage)
Uptime 95.3% (.953)
Turbonomic calculates the following:

• Current Estimated On-demand Monthly Cost:
0.012 * 0.5 * 0.953 * 730 = 4.1
• Estimated On-demand Monthly Cost after executing the action:
0.021 * 1.0 * 0.953 * 730 = 15
NOTE:
Turbonomic rounds the calculated values that it displays in the user interface.
Since the Estimated On-demand Monthly Cost is projected to increase from $4.1/month to $15/month, Turbonomic
treats the action as an investment and shows an estimated investment of $11/month.

Getting Started
Azure VMs with License Costs

Cost Calculation
For VMs with license costs, Turbonomic first calculates the On-demand Compute Rate, which it then uses to calculate
Estimated On-demand Monthly Costs.
1. On-demand Compute Rate Calculation
The calculation for On-demand Compute Rate can be expressed as follows:
On-demand Rate - (Reserved License Cost + On-demand License Cost) =

On-demand Compute Rate
Where:
• On-demand Rate is the hourly cost for a VM's instance type without RI coverage. This does not include license costs,
storage, or IP. You can obtain on-demand rates via Azure Pricing Calculator.
• Reserved License Cost and On-demand License Cost are the hourly costs for the VM's licenses. You can obtain
license costs via Azure Pricing Calculator or the Turbonomic user interface.
From the user interface, set the scope to the Azure VM and then see the Workload Cost Breakdown chart. In the
chart, set the time frame to Last 2 Hours, and then:
◦ Hover over the second to the last bar in the chart to obtain the current On-demand License Cost and Reserved
License Cost.

Getting Started

◦ Hover over the last bar (after the vertical line) in the chart to obtain the On-demand License Cost and Reserved
License Cost after you execute actions.

The On-demand Compute Rate and License Cost (On-demand and Reserved) are then used to calculate Estimated On-
demand Monthly Costs.
2. Estimated On-demand Monthly Cost Calculation
The calculation can be expressed as follows:
(On-demand Compute Rate * Usage Not Covered by RIs) + License Cost * Uptime * 730 =
Estimated On-demand Monthly Cost
Where:
• Usage Not Covered by RIs is the percentage of hourly VM usage not covered by any RI. For example:
◦ RI Coverage = 20% (0.2)
◦ Usage Not Covered by RIs = 80% (0.8)
• License Cost is the sum of On-demand License Cost and Reserved License Cost.
• Uptime is a percentage value that indicates how long a VM has been running over a period of time (age). Age refers
to the number of days that a VM has existed since first discovery. For VMs older than 30 days, Turbonomic only
calculates uptime over the last 30 days.

Getting Started
To estimate monthly on-demand costs, Turbonomic projects the current uptime value into the future. It assumes
that future uptime will be similar to the current uptime.
The listed items above impact cost calculations, but not the actual scaling decisions that Turbonomic makes. These
decisions rely on other factors, such as resource utilization percentiles and scaling constraints set in policies.
Example
Assume the following data for a pending scale action for an Azure VM with license costs:


On-demand Rate $0.45/hr $0.218/hr


Getting Started


On-demand License Cost $0/hr $0.088/hr
Reserved License Cost $0.184/hr N/A
1. Turbonomic first calculates the following:

• Current On-demand Compute Rate:
0.45 - (0.184 + 0) = 0.266
• On-demand Compute Rate after executing the action:
0.218 - (0 + 0.088) = 0.13
2. Turbonomic can now calculate Estimated On-demand Monthly Cost based on:
• On-demand Compute Rate

On-demand Compute Rate $0.266/hr $0.13/hr
• Usage Not Covered by RIs and Uptime


RI Coverage 100% (1.0) 0% (0.0)

Getting Started

Usage Not Covered by RIs 0% (0.0) 100% (1.0)
(calculated based on RI coverage)
Uptime 96.1% (.961)

(0.266 * 0.0) + 0.184 * 0.961 * 730 = 129
(0.13 * 1.0) + 0.088 * 0.961 * 730 = 153
NOTE:
Since the on-demand cost is projected to increase from $129/month to $153/month, Turbonomic treats the action as an
investment and shows an estimated investment of $24/month.

Getting Started
Resizing Cloud Workloads

To resize a workload (for example, a VM or an RDS instance) on the cloud, Turbonomic chooses the cloud tier that
best matches the workload requirements. This can be to reduce cost by choosing a smaller tier, or it can be to assure
performance by choosing a larger tier. To accomplish the resize, Turbonomic actually moves the workload to the new
tier. This can include moving to a new availability zone.
Note that resize decisions also take into account the discount you can realize by using RI purchases. Turbonomic can
recommend to purchase more RI resources. When considering workload resize actions, Turbonomic can recommend
resizing to a larger RI tier because the overall cost will be less.
As it considers a resize, Turbonomic also considers the storage and network requirements. Even if the compute
resources are underutilized on a workload, if the available tiers cannot support the workload's storage or network
requirements then Turbonomic will not recommend the change.
NOTE:
In AWS environments, under certain circumstances VM resizing can fail. If the restart of the VM initially fails,
Turbonomic waits 30 seconds and tries to restart again. Turbonomic will try to restart up to four times. If the restart
still fails, Turbonomic assumes the VM cannot start up on the new tier, and it restarts the VM on the old tier.
Scaling on the Public Cloud

On the cloud, scaling actions change the VM to a different instance type. These can include:
• Changing a VM to an instance type with different capacity
• Changing on-demand to RI

Getting Started
For these actions, the action list shows the current cost for the source workload, and also the projected cost given the
change. To show the current cost, Turbonomic uses the actual costs for that workload. However, to show the projected
cost it uses an estimate based on average utilization for the VM, for the costs of the given tier.
Note that scaling to an RI can result in running the VM on a larger instance when the cost is lower. This might occur even
though the VM does not need that capacity and there are other smaller tiers available.
In Azure environments, there are circumstances where a VM resize can be especially disruptive. In a given region, the
infrastructure can be made up of different clusters that have different sets of underlying hardware. Further, some tiers
that are available in the given region are only available on different clusters. If Turbonomic recommends resizing from a
tier on one cluster, to a tier on another cluster, then the resize action can take longer to complete than usual.
In both Azure and AWS environments, Turbonomic conforms to specific instance requirements as it generates resize
actions. For more information, see:
• Azure Instance Requirements (on page 183)
• AWS Instance Requirements (on page 181)
Reserved Instances (RIs)

Turbonomic analysis takes advantage of AWS and Azure Reserved Instances (RIs) to calculate optimal workload
placement and to arrive at the best possible costs for your deployments on the cloud.
NOTE:
For AWS environments, under very rare circumstances, you can have RIs on payment plans that do not resolve to 1-
year or 3-year terms. In this case, AWS does not return pricing data for those RIs. Turbonomic does not include such
RIs in its calculations of RI utilization or RI cost.
RI Charts
The Cloud View in the Homepage includes the following charts that show RI data:
• Pending Actions (on page 365)
If Turbonomic has found actions you can take to improve performance or to reduce cost, then you can see an
overview of them in the Pending Actions chart. To see a listing of the specific actions, click Show All at the bottom
of the chart. For more about actions, see Turbonomic Actions (on page 67).
• RI Utilization (on page 399)
This chart shows how well you have utilized the Reserved Instance inventory. The chart compares the capacity for all
Reserved Instances versus the RI consumption by virtual machines.
• RI Coverage (on page 392)
This chart compares the capacity of your current VM workload to the capacity of workload that is covered by RIs.
If you have a high percentage of on-demand workload, then you should be able to reduce your monthly costs by
increasing RI coverage. To increase coverage, you resize workloads to instance types that have existing RI capacity. If
you need more RI capacity, then Turbonomic will recommend the RIs that you should buy.
• RI Inventory (on page 394)
This chart lists the RI instance types that are active in your inventory. To see more information, click Show All at the
bottom of the chart.

Getting Started
• Recommended RI Purchases (on page 391)

This chart shows the projected inventory of pending RI purchases as generated by Turbonomic. To see more
information, click Show All at the bottom of the chart.
RI Purchases
Turbonomic can recommend that you purchase RI capacity to reduce costs for your current workload. The analysis looks
at workload history for template families to identify RI candidates. This considers the count of workloads in a family,
their hours of active-state condition, and RI costs. If a workload shows stable utilization over time, then Turbonomic
identifies it as an RI candidate, and it recommends purchasing RI capacity for that workload. To ensure enough historical
data for the analysis, Turbonomic generates RI Buy actions on a two-week cycle. It also generates a new set of RI Buy
actions if you change the RI inventory, or if you restart Turbonomic.
Be aware of the following:
• Different types of RIs have different costs, so the choice between using on-demand or RI pricing can vary depending
on the RI Pricing configuration in your Budgets and Costs settings. For more information, see RI Purchase Profile (on
page 427).
• Turbonomic can only estimate the cost that would result if you execute pending RI Buy actions. This is because the
full data is only available after you actually purchase the RIs. Estimates reflect costs you would see after scaling
workloads to the newly purchased RI capacity. For scaling to already-purchased RIs, the chart reflects the actual
costs.
• As Turbonomic calculates actions to purchase RI capacity, it assumes that any other pending actions for the
workload will also be executed. For example, assume a workload running on an r4.xlarge template. If Turbonomic
recommends changing that instance type to an m5.medium, it can recommend that you purchase an m5 RI to cover
the workload and reduce costs. This purchase could be on a region that currently doesn't have any m5 workloads —
The purchase recommendation assumes you will move the workload to that other region.
• Turbonomic uses a weighted history of workload activity and that suspended VMs are also considered. The longer
ago that the workload was suspended, the less weight it has in the RI Buy calculation.
• For AWS RIs:
◦ For environments that use the Instance Size Flexible rules, Turbonomic can recommend that you buy multiple
RIs of smaller instance types to cover the resource requirements of larger instance types. For example, rather
than buying one t2.small RI, Turbonomic can recommend that you buy four t2.nano RIs to offer an equivalent
discount.
◦ For environments that consolidate billing into Billing Families, Turbonomic recommends purchases for RIs that
are within the given billing family. For more information, see AWS Billing Families (on page 49).
Support for Government Workloads

AWS GovCloud (US) and Azure Government provide dedicated regions for US government customers and their partners
to architect secure cloud solutions and meet regulatory and compliance requirements.
Turbonomic discovers workloads in these regions when you add the required accounts as targets. For details on the
required accounts, see "AWS GovCloud Targets" in the Target Configuration Guide and "Azure Government Targets" in
the Target Configuration Guide.
Discovered workloads include:
• AWS VMs (including auto-scaling groups), volumes, database servers, and spot instances
• Azure VMs (including availability/scale sets), volumes, and SQL databases

Getting Started
Turbonomic recommends actions on VMs, volumes, and SQL databases to address performance issues and optimize
costs.
NOTE:
Turbonomic currently does not support Azure Government integration with Application Insights. You can add accounts
for Azure Government and Application Insights as targets, but Application Insights will only return performance data
for non-government workloads.
Information in Charts
Use the following charts to view information about your government accounts and workloads.
• Top Accounts chart
Use the Top Accounts chart as a starting point. This chart shows the following:
◦ Azure Government subscriptions discovered via the service principal and EA accounts that you have added as
targets
◦ AWS GovCloud master and member accounts that you have added as targets. Accounts with a star symbol are
master accounts.

For an AWS GovCloud account, the 30-day cost is shown as N/A since invoicing for that account is managed through
an associated AWS standard account. Adding this standard account as a target is optional. When added, it appears
in the Top Accounts chart and shows the total 30-day cost for the GovCloud account and the standard account itself.
• Necessary Investments and Potential Savings charts
Set the scope to a government account or subscription, and then see the Necessary Investments and Potential
Savings charts to evaluate the costs you would incur or save if you execute all the pending actions for your
government workloads.

Getting Started

• RI and Savings Plans Inventory chart
The government accounts that you added as targets enable Turbonomic to gain full insight into the AWS/Azure
RIs and AWS Savings Plans that you have purchased for your government workloads. Even as you selectively add
secondary targets, Turbonomic remains aware of all RIs and Savings Plans, and how they are utilized across the
board. This increases the accuracy of the allocation and purchase recommendations that Turbonomic generates for
your government workloads.

Workload Planning
You can run an Optimize Cloud plan to identify performance and efficiency opportunities for existing government
workloads, or a Migrate to Cloud plan to migrate government VM groups to another cloud provider.
For on-prem clusters, you can run a Migrate to Cloud plan to see how you can safely migrate the VMs in these clusters to
a government account/subscription and region.
Support for Azure App Service

When you add an Azure account, Turbonomic discovers the app services and plans that make up your App Service
deployment. In the supply chain, app services appear as Service entities, while plans that define the underlying compute
resources for app services appear as Application Components.

Getting Started
To discover app services and plans, Turbonomic requires the same permissions for monitoring other Azure workloads.
For a list of permissions, see "Azure Service Principal and Subscription Permissions" in the Target Configuration Guide.
App Service analysis and optimization will be introduced in a future release.
Cloud VM Uptime
For cloud VMs, Turbonomic includes uptime data in its cost calculations. This is especially important for VMs that do not
run 24/7 and are charged on-demand rates. With uptime data, Turbonomic can calculate costs more accurately based on
the amount of time a VM has been running.
The Action Details page shows uptime data for these VMs. Turbonomic calculates uptime based on the VM's age.

Key Concepts
• Uptime
A percentage value that indicates how long a VM has been running over a period of time (age).
• Age
The number of days that a VM has existed since first discovery. For VMs older than 30 days, Turbonomic displays a
value of 30+ days, but only calculates uptime over the last 30 days.

Getting Started
Examples
• A VM that was first discovered 5 days (or 120 hours) ago and has been running for a total of 60 hours during that
period has a current uptime value of 50%.
• A VM that was first discovered 2 months ago and has been running for a total of 180 hours over the last 30 days (or
720 hours) has a current uptime value of 25%.
Cost Calculations Using Uptime Data

Turbonomic uses uptime data to calculate estimated on-demand costs for your cloud VMs. For details about
calculations, see Estimated On-demand Monthly Costs for Cloud VMs (on page 29).
Uptime data impacts cost calculations, but not the actual scaling decisions that Turbonomic makes. These decisions rely
on other factors, such as resource utilization percentiles and scaling constraints set in policies.
Uptime Data in Charts

Turbonomic recalculates uptime data every hour and then updates the values shown in charts. The following charts
reflect the cost impact of uptime-based calculations:
• Potential Savings and Necessary Investment charts
The projected amounts in these charts include on-demand costs for cloud VMs.

When you click Show All in these charts and view details for a pending VM action, the Action Details page shows
on-demand costs before and after you execute the action, factoring in the VM's uptime value. The page also shows
the VM's age.

Getting Started

• Workload Cost Breakdown chart
This chart shows estimated costs over time, including on-demand costs for VMs.

• The Entity Information chart shows the latest uptime and age data for a specific cloud VM.

Getting Started

Configuring Targets
A target is a service that performs management in your virtual environment. Turbonomic uses targets to monitor
workload and to execute actions in your environment. When you configure a target, you specify the address of the
service, and the credentials to connect as a client to it.
For each target, Turbonomic communicates with the service via the management protocol that it exposes — The REST
API, SMI-S, XML, or some other management transport. Turbonomic uses this communication to discover the managed
entities, monitor resource utilization, and execute actions.
To configure a target, you will choose the target type, specify the target's address, and then provide credentials to
access the target.
After you configure a target and add it to your installation, Turbonomic validates the connection, and then discovers the
entities that target manages.
NOTE:
Turbonomic regularly checks that your targets are valid. If it discovers that a target is invalid it then posts that status
to the user interface. Under some circumstances, the target can become valid again, but the status does not update. If
you see an Invalid message for a given target, try to manually validate the target again (click VALIDATE).
Configuring a Target
1. Navigate to the Settings Page.

Click to navigate to the Settings Page. From there, you can perform a variety of Turbonomic configuration tasks.
2. Choose Target Configuration.

Getting Started

Click to navigate to the Target Configuration Page.
3. Review the list of targets.

This page lists all the targets that you currently have configured for Turbonomic. You can inspect these targets, you
can edit them (change address and credentials), and you can add a new target to Turbonomic.
4. Filter the list of targets.

To work with a long list of targets, you can filter by the target type. You can also type a string in the Search field to
filter the list, and you can sort the list by target status or target name.
5. Select one or more targets to work with.

Getting Started

When you select a target you can:
• Rediscover — Direct Turbonomic to fully discover the entities that this target manages. This will rebuild the
topology that is associated with this target.
• Validate — Direct Turbonomic to validate its connection with the target. For example, if you create a new user
account on the target, you can edit the target connection to use that account, and then revalidate.
• Delete — When you delete a target, Turbonomic removes all the associated entities from its model of the
inventory.
6. Expand an entry to see details, or click the entry to edit the target's configuration.
For example, if you entered the wrong username or password, you can change those credentials and validate the
target again.

7. Create a new target and add it to Turbonomic.

Getting Started

First, select the type of target to add. Then for the type you choose, select the specific target technology. For
example, select Hypervisor/vCenter to add a VMware vCenter Server target. Then provide the address and
credentials for that target.
For more details, including a list of supported targets and configuration requirements, see the Turbonomic Target
Configuration Guide.

Getting Started
AWS Billing Families

As you configure AWS targets, Turbonomic discovers AWS accounts that are consolidated into billing families. A billing
family has one master account, and zero or more member accounts. By recognizing billing families, Turbonomic more
accurately calculates cloud investments and savings, and makes more accurate recommendations for RI coverage.
In the Targets user interface, master accounts appear in bold, with a star next to them. You can expand the account
entry to see the related member accounts. If you expand the entry for a member account, then the related accounts
includes the family master, indicated by a star.
For RI purchases, different accounts in a billing family can share the same RI resources. At the same time, accounts in
other billing families cannot use those RIs. This adds flexibility to your RI coverage, while maintaining order over the
billing.
In Turbonomic, if you enable Billing Family Recognition, then you can see the billing family master and member accounts
in the Targets user interface, and Turbonomic can recommend proper RI purchases within the correct billing families.
To enable Billing Family Recognition, ensure the following as you configure your AWS targets:
• Use the proper role for each AWS target
To properly discover billing family information for a target, you must give Turbonomic credentials for an AWS role
that includes the permission, organizations:DescribeOrganization. With that permission, Turbonomic can:
◦ Discover master accounts and member accounts in different billing families
◦ Display the account names in the user interface
◦ Discover billing information for each family and account
◦ Recommend RI actions that respect billing family boundaries
• Configure targets for the complete billing family

Getting Started
One billing family can consolidate a number of AWS accounts. For Turbonomic to include these accounts in its
analysis, you must configure each one as a separate target. If you do not configure all the accounts in a billing
family, then Turbonomic cannot discover complete billing information for that family, and its analysis will be based
on incomplete information.
Turbonomic displays member accounts that have been configured as targets in regular text. For members that
Turbonomic discovers but have not been configured as targets, Turbonomic displays their names in grayed text.
If you have enabled Billing Family Recognition, you should keep the following points in mind:
• Billing families can grow
Turbonomic regularly checks the membership of your billing families. If it discovers a new member account, it
adds that account to the list of members. If you have already configured the account as a target, then Turbonomic
includes the new member in its analysis of billing families. If the new member is not already a target, then
Turbonomic lists the new member in grayed text.
• You can configure discounts per billing family
Turbonomic includes a feature to set a discount for a billing group, and to override that discount for specific
template families within that scope. For more information, see Cloud Discounts (on page 429) and Discount
Override: AWS (on page 435).
• You might see master accounts that have no member accounts
AWS treats every account you create as a part of a billing family. Assume you created an account, but you had no
reason to consolidate its billing with any other accounts. In that case, the account appears in the Turbonomic user
interface as a master account, but it has no member accounts.

Getting Started
Azure Enterprise Agreements

You can configure Turbonomic to manage Azure subscriptions within the context of an Enterprise Agreement (EA). An EA
defines specific pricing, including the pricing for Reserved Instances (RIs). When you configure an EA target, and set the
EA key to your Azure targets, Turbonomic uses that richer pricing information to calculate workload placement and RI
coverage for your Azure environment.
To enable Turbonomic management of Azure EA environments, you must configure:
• One Microsoft Enterprise Agreement target
• At least one Service Principal target that can discover the underlying Azure subscriptions
For information about Azure targets, see "Microsoft Azure" in the Target Configuraton Guide.
In the Targets View, you can identify the targets related to Azure EA as follows:
• EA Targets
The target that discovers the EA to track pricing and RI information. You can have one EA target per Turbonomic
deployment.
• Azure Subscription Targets
The targets that manage the workloads in your Azure environment. These are discovered by Service Principal
targets. Note that not all subscription targets necessarily participate in the EA. Expand these entries to see the
related Service Principal target. For members of the EA, you can see the related EA target as well.
Subscriptions that do not participate in the EA appear as Standalone targets.

Getting Started
NOTE:
In rare circumstances, you can have a subscription that is not in use – The subscription has no workloads
associated with it. In this case, Turbonomic identifies the subscrition as Standalone. This is because the target
cannot discover any cost or usage information that would relate the subscription to its EA.
• Service Principal Targets
The Azure target that you configure to discover Azure subscription targets. Expand the entry to see the discovered
targets. If you have configured an EA target, the entry lists that as well, along with the EA enrollment number.
Reserved Instances and Azure EA

For Azure envirnments, Turbonomic can only discover and use RIs if you have configured a Microsoft Enterprise Account
target, and if one or more subscriptions participate in that EA.
To discover and manage RIs in Azure environments, Turbonomic uses both the EA target and the associated subscription
targets. On its own, a subscription target exposes costs for pay-as-you-go pricing. The EA target discovers pricing for the
available RI instance types. Turbonomic combines this information to track:
• RI utilization
• RI coverage
• Virtual machine costs (accounting for RIs)
NOTE:
This release of Turbonomic does not support RI discovery and management for Classic VMs and Classic Cloud Services.
Also, it does not support RI discovery and management for Suppressed Core virtual machines.
Cost Calculations for Azure Environments

To understand the reported costs in your Azure environment, consider these points:
• For targets that participate in the EA, Turbonomic uses the terms of the given EA, and bases costs on the Offer ID
that is effective for the given subscription.
• For VMs in Azure, RI pricing does not include the cost of the OS license. However pricing for on-demand VMs does
include the license cost.
NOTE:
For Miscrosoft Azure EA environments, the projected cost for RI Purchase actions might not match associated
costs you find in the Microsoft Pricing Calculator.
Turbonomic actions can recommend RI purchases. For these recommendations, the action assumes a free Linux
OS, so the cost estimate does not include the OS cost. However, The Microsoft Pricing Calculator does include
costs for OS licenses. As a result, when you compare the Turbonomic cost estimates to the values in the Pricing
Calculator, it's likely that the two estimates will not match. This difference also affects the Break Even Point that
appears in the Recommended RI Purchases chart. Because the recommended purchases do not include Azure
costs for OS licenses, the listed Break Even Point can be optimistic.
• For workloads you migrated from on-prem to the Azure cloud, Turbonomic recognizes Azure Hybrid Benefit (AHUB)
savings for RIs and on-demand workloads. The costs you see in Turbonomic charts include this benefit. However,
remember that recommended actions do not include any license cost, so the actions will not reflect any proposed
AHUB savings (see above).

Getting Started
Supply Chain of Entities

To perform Application Resource Management, Turbonomic models your environment as a market of buyers and sellers
linked together in a supply chain. This supply chain represents the flow of resources from the datacenter, through the
physical tiers of your environment, into the virtual tier and out to the cloud. By managing relationships between these
buyers and sellers, Turbonomic provides closed-loop management of resources, from the datacenter, through to the
application.
Reading the Supply Chain

By looking at the Supply Chain, you can see:
• How many entities you have on each tier
Each entry in the supply chain gives a count of entities for the given type.
• The overall health of entities in each tier
The ring for each entry indicates the percentage of pending actions for that tier in the datacenter. Ring colors
indicate how critical the actions are - Green shows the percentage of entities that have no actions pending. To get
actual counts of pending actions, hover on a ring to more details.

Getting Started
• The flow of resources between tiers

The arrow from one entry to another indicates the flow of resources. For example, the Virtual Machine entry has
arrows to Hosts and to Storage. If the VMs are running in a Virtual Data Center, it will have another arrow to that as
well. This means that your VMs consume resources from hosts, storage, and possibly from VDCs.
Listing Entities From the Home Page

The Supply Chain shows the relationships of entities in your environment. When you're on the Home Page with a global
scope, the supply chain filters its display according to the view you have chosen:
• APPLICATIONS – All your Business Applications (on page 127)
• ON-PREM – All your on-prem entities
• CLOUD – All your entities on the public cloud
To see a list of entities, click an entity tier in the Supply Chain.

Working With a Scoped View

By default, the Home Page shows a Global view of your environment. To drill down into specifics of your environment,
you can set a scope to your Turbonomic session. A scoped view shows details about the specific entities in that scope.
Once you have set a scope, you can use the Supply Chain to zoom in on a related tier to see details about the entities on
that tier.
If you find the current scope to be useful, you can save it as a named group. Using named groups is an easy way to
return to different scopes that you have saved.
Things You Can Do

• Scoping the Turbonomic Session (on page 55)
• Navigating With the Supply Chain (on page 65)
• Viewing Cluster Headroom (on page 66)

Getting Started
Scoping the Turbonomic Session

The default scope for the Home Page shows an overview of the global environment. What if you want to focus on less
than the global environment? Assume you are responsible for a subset of workloads in your environment. This could be:
• Workloads managed on a single host cluster
• The workloads in a single datacenter
• A custom group of workloads you have created in Turbonomic
It's easy to set the session scope so that Turbonomic zooms in on the part of the environment that you want to inspect.
Once you set the scope, you can get a quick picture of system health for that scope. If you find a certain scope to be
useful, you can save it as a named group that you can return to later.
1. Navigate to the Search Page.

Click to navigate to the Search Page. This is where you can choose the scope you want.
2. Choose the type of entities to search.

In the Search Page, choose a type of entities that you want to search through. Find the list of entity types on the
left. Select All to search the complete environment. Or you can focus on entities by type, by groups, or by clusters.
When you select an entity type, the page updates to show all entities of that type.
3. Use Search to filter the listing.
For example, if you're showing All and you search for "Development", then you will see all clusters, groups, and
entities with "Development" in their names.

Getting Started

4. Expand an entry to see details.
For example, expand a group or an entity to see utilization details and pending actions.
NOTE:
For hosts in the public cloud, utilization and capacity for host and datacenter resources don't affect Turbonomic
calculations. When you expand an entry for a public cloud host, the details do not include information for these
resources.

5. Select one or more entries to set the focus of the Home Page.

Getting Started

If you choose a category of entities to limit the list, then you can select one or more of the entities for your session
scope. After you select the entities you want to include in your scope, click SCOPE TO SELECTION to set the session
scope to those entities.
If you choose Groups or Clusters, then you can select a single entry to set the scope for your session. When you
select an entry in the list, that sets the focus of the Home Page. For example, if you select a cluster in the Search
listing, you set the Home Page focus to that cluster. Use the Home Page bread crumbs to set a different scope, or
you can return to Search and set a different scope from there.

Getting Started
Overview Charts

The Overview Charts show your environment's overall operating health for the current session scope. A glance at the
Overview gives you insights into service performance health, overall efficiency of your workload distribution, projections
into the future, and trends over time.
The charts in this view show data for the current scope that you have set for the Turbonomic session. For the global
scope, the charts roll up average, minimum, and peak values for the whole environment. When you reduce the scope
(for example, set the scope to a cluster), the charts show values for the entities in that scope.
Some charts included in this view are:
• Pending Actions
See all the actions that are pending for the current scope.
• Health
Quickly see the health of the entities in this scope- How many entities have risks, and how critical the risks are.
• Optimized Improvements
A comparison of utilization in your environment before executing the pending actions, and then after.
• Capacity and Usage
This chart lists resources that are used by the current scope of entities, showing utilization as a percentage of the
capacity that is currently in use.
• Multiple Resources
See the utilization over time of various resources that are used by the current scope of entities.
• Top Entities
For example, Top Virtual Machines. These charts list the top consumer entities in the current scope.
• Risks Avoided
Each action addresses one or more identified risks or opportunities in your environment. This chart shows how
many risks have been addressed by the executed actions.

Getting Started
• Accepted Actions
This chart shows how many actions have been executed or ignored, and whether they have been executed manually
or automatically.
What You Can Do:

• Set scope: See Scoping the Turbonomic Session (on page 55)
• Create new charts: See Creating and Editing Chart Widgets (on page 362)
Setting Chart Focus

The charts update to reflect the focus that you have set for your viewing session. While viewing the Overview Charts,
you can set the focus in different ways:
• Set Supply Chain Focus
Choose a tier in the supply chain to set the view focus - see Navigating With the Supply Chain (on page 65)
• Set Scope
Use Search to set the scope of the viewing session - see Scoping the Turbonomic Session (on page 55)
Chart Time Frame

You can set a time frame from recent hours to the past year, and set that to the charts in the view. Use the Time Slider to
set specific start and end times within that range. The green section in the slider shows that you can set the time range
to include a projection into the future. For this part of the time range, charts show the results you would see after you
execute the current set of pending actions.
For most charts, you can also configure the chart to hard-code the time range. In that case, the chart always shows the
same time scale, no matter what scale and range you set for the given view.
Note that Turbonomic stores historical data in its database. As you run Turbonomic in your environment for more time,
then you can set a time range to show more history.
Details View
The Details View shows more details about the entities in your session scope. These charts focus on the utilization of
resources by these entities, so you can get a sense of activity in that scope over time.

Getting Started

What You Can Do:

• Set scope: See Scoping the Turbonomic Session (on page 55)
• Create new charts: See Creating and Editing Chart Widgets (on page 362)
Setting Chart Focus

The charts update to reflect the focus that you have set for your viewing session. While viewing the Overview Charts,
you can set the focus in different ways:
• Set Supply Chain Focus
Choose a tier in the supply chain to set the view focus - see Navigating With the Supply Chain (on page 65)
• Set Scope
Use Search to set the scope of the viewing session - see Scoping the Turbonomic Session (on page 55)
Chart Time Frame

You can set a time frame from recent hours to the past year, and set that to the charts in the view. Use the Time Slider to
set specific start and end times within that range. The green section in the slider shows that you can set the time range
to include a projection into the future. For this part of the time range, charts show the results you would see after you
execute the current set of pending actions.

Getting Started
For most charts, you can also configure the chart to hard-code the time range. In that case, the chart always shows the
same time scale, no matter what scale and range you set for the given view.
Note that Turbonomic stores historical data in its database. As you run Turbonomic in your environment for more time,
then you can set a time range to show more history.
Scope Policies

The Policy View gives you a look at the Automation Policies that are set for the entities in the current scope. For each
policy, you can see whether it has been enabled or disabled. In addition, you can create new policies and apply them to
that scope.
To edit a policy, click the policy name. You can then change the policy settings, or enable/disable the policy.
To see the current policy settings, expand a settings category. For each setting, you can see which policy determines the
value- Either the default policy or a custom policy that has been applied to this scope.
When you create a new policy, it automatically includes the current scope. You can add other groups to the policy scope
if you like. Note that you can enable more than one policy for the same scope. If two policies apply different values for
the same setting, then the most conservative value takes effect.
For more information, see Automation Policies (on page 100).

Getting Started
Entity Placement Constraints

When you drill down to a single entity, you can see details about the entity's relationships in the supply chain. This
shows you which entities provide resources to this entity. When considering providers for this entity, you can see the
name of each current provider, and how many alternative providers Turbonomic can choose from if the current one
becomes overutilized.
Reviewing the constraints on an entity helps you understand the actions that Turbonomic recommends. If an action
seems questionable to you, then you should look at the constraints on the affected entities. It's possible that some
policy or constraint is in effect, and it keeps Turbonomic from recommending a more obvious action.
Experimenting With Placement Constraints

For each provider or consumer in the list, you can open a Constraints fly-out that gives more details about limits on the
current element's supply chain relationships.
For example, assume the PROVIDERS list shows your VM's CURRENT PLACEMENT is on Host A, and for OTHER
POTENTIAL PLACEMENT you see that Turbonomic can choose from 4 hosts. When you click Constraints, the flyout
displays a list of host constraints that currently result in the four potential hosts for this VM.


Getting Started
The list information includes:

• CONSTRAINT TYPE
Most constraints are boundaries that are inherent in your environment such as a cluster boundaries or a networks,
or the can be constraint rules such as discovered HA or DRS rules authored Turbonomic placement policies
(sometimes called segments)
• SCOPE NAME
For a given rule or constraint, the scope to which it was applied.
• SOURCE
If this is a discovered constraint, the source shows the type of target that imposes this constraint. For example, for a
DRS rule the source will be vCenter.
• POTENTIAL PROVIDERS
For the given constraint, how many providers that constraint allows. To see a list of the potential providers, click the
POTENTIAL PROVIDERS value.
To dig deeper into how these constraints affect your entity, click FIND MORE PLACEMENT OPTIONS. This puts you into
a simulation mode that you can use to experiment with changing the effective constraints. For example, you might see
that a cluster boundary is limiting your placement possibilities, and you would like the option to place the current VM on
other clusters. Armed with this information, you could navigate to Policies and create a Merge Cluster policy.

In this mode you can enable and disable different combinations of constraints. As you do, the POTENTIAL PROVIDERS
label updates to show how many providers are available to your entity. To see the resulting list of providers, click the
POTENTIAL PROVIDERS label.

Getting Started
List of Entities

The list of entities is a quick way to drill down to details about your environment, so you can see specifics about
resource consumption or state. For example, you can see the amount of capacity that has been assigned to a VM that is
currently idle.
This list always updates to reflect the focus you have selected in the Supply Chain Navigator. When you select an entity
type in the supply chain, the entities list updates to show the entities of that type for your current scope. For example,
select Host to see a list of hosts in the current scope. For more information, see Navigating With the Supply Chain (on
page 65)

Getting Started
Navigating With the Supply Chain

After you have set the scope of your Turbonomic session, you can use the Supply Chain to change the focus of the main
view, and see details about different types of entities within the current scope.
Drilling Down in a Scoped Session

When you set a scope to your Turbonomic session, the Home Page shows information about your environment,
including:
• Overview
Charts and lists to give you an overview of your environment for the current scope. This overview corresponds to all
the entities in scope.
• Details - Charts that give you a more detailed look at your environment for the given scope
• Policies - Any policies that are defined for the entities in the current scope
• Entity Lists - Details about the entities in the current scope
• Pending Actions - Actions that are pending for any entities in the current scope
The Supply Chain shows the currently selected tier of entities. The change the focus of the scoped view, select different
tiers in the Supply Chain. The Policies, Entities List, and Pending Actions tabs update to focus on the tier you selected.
These tabs show information for all the entities of that type that are in the current scope. For example, if you click the
Host tier, these tabs update to show information about the hosts in your current scope.
To zoom in on a specific entity, you can click its name in the Entities List. This sets the scope to that specific entity. To
return to the previous scope, use the browser's Back button.

Getting Started
Viewing Cluster Headroom

Cluster headroom shows you how much extra capacity your clusters have to host workloads. When you set the scope to
a cluster, the Home Page then includes charts that show headroom for that cluster, as well as time to exhaustion of the
cluster resources.
To view cluster headroom:
1. Navigate to the Search page.
2. Choose the Clusters category.
3. Select the cluster you want to view.
4. When the Home Page displays, scroll down to show the headroom charts.
Make sure you have selected the Host tier in the supply chain navigator.
To calculate cluster capacity and headroom, Turbonomic runs nightly plans that take into account the conditions in your
current environment. The plans use the Economic Scheduling Engine to identify the optimal workload distribution for
your clusters. This can include moving your current VMs to other hosts within the given cluster, if such moves would
result in a more desirable workload distribution. The result of the plan is a calculation of how many more VMs the
cluster can support.
To calculate VM headroom, the plan simulates adding VMs to your cluster. The plan assumes a certain capacity for these
VMs, based on a specific VM template. For this reason, the count of VMs given for the headroom is an approximation
based on that VM template.
To specify the templates these plans use, you can configure the nightly plans for each cluster. For more information, see
Configuring Nightly Plans (on page 346)

Getting Started
Turbonomic Actions
After you deploy your targets, Turbonomic starts to perform market analysis as part of its Application Resource
Management process. This holistic analysis identifies problems in your environment and the actions you can take to
resolve and avoid these problems. Turbonomic then generates a set of actions for that particular analysis and displays it
in the Pending Actions charts for you to investigate.

Turbonomic can generate the following actions:
Action Description
Provision Introduce new resource providers to update the environment's capacity.
For example:
• Provisioning a host adds more compute capacity that is available to VMs.
• Provisioning a VM adds capacity to run applications.
Start Start a suspended entity to add capacity to the environment.
Resize Re-allocate resource capacity on an entity. For example, reduce vCPUs or vMem
on a VM, or add volumes to a disk array.
Buy RI For workloads that are good RI candidates, purchase RI capacity to move your
environment toward the RI coverage that you desire.
Increase RI coverage Increase RI coverage to reduce costs.
Reconfigure • Add necessary network access or reconfigure storage. For example, if a VM
is configured to access a network that is not available on the host, the VM
must reconfigure to use an available network.
• Reconfigure container pods.

Getting Started
Action Description
Move Change a consumer to use a different provider, such as moving a VM to a
different host. Moving a VM to a different storage means relocating any file-
based component that belongs to a virtual machine.
Suspend Stop and set resources aside without removing them from the environment.
For example, you might suspend an underutilized host to save it for some time
when you really need it, or suspend a virtual machine to save money.
Delete Remove storage (for example, datastores on disk arrays or unattached volumes).
Actions by Entity Type

Turbonomic generates actions based on how entity types use or provide resources, and what each entity type supports.
The following tables show the actions that each entity type supports:
Application Entity Types

Entity Type Supported Actions
Business Application None
Turbonomic does not recommend actions for a Business Application, but it
does recommend actions for the underlying Application Components and
infrastructure. The Pending Actions chart for a Business Application lists these
actions, thus providing visibility into the risks that have a direct impact on the
Business Application's performance.
Business Transaction None
Turbonomic does not recommend actions for a Business Transaction, but it
does recommend actions for the underlying Application Components and
infrastructure. The Pending Actions chart for a Business Transaction lists these
actions, thus providing visibility into the risks that have a direct impact on the
Business Transaction's performance.
Service For non-Kubernetes Services:
None
Turbonomic does not recommend actions for non-Kubernetes Services, but it
does recommend actions for the underlying Application Components and nodes.
The Pending Actions chart for Services list these actions, thus providing visibility
into the risks that have a direct impact on their performance.
For Kubernetes Services:
Provision or Suspend
For horizontally scalable Kubernetes Services that collect performance metrics
(or KPIs) for applications, Turbonomic can dynamically adjust the number of pod

Getting Started

replicas that back those Services to help you meet SLOs (Service Level Objectives)
for your applications.
Application Component Resize
Resize the following resources to maintain performance:
• Thread Pool
• Connections
• Heap
Turbonomic will recommend Heap resize actions if the Application
Component sells Heap and Remaining Garbage Collection (GC) Capacity, and
the underlying VM or container sells VMem.
NOTE:
The resources that Turbonomic can resize depend on the processes that
it discovers from your Applications and Databases targets. In the Target
Configuration Guide, refer to the topic for a specific target to see a list of
resources that can be resized.
Container Platform Entity Types

Container For details, see Container Actions (on page 151).
Container Spec None
A Container Spec retains the historical utilization data of ephemeral containers.
Turbonomic uses this data to make accurate container resize decisions, but does
not recommend actions for the Container Spec itself.
Namespace Resize Quota
Turbonomic treats quotas defined in a namespace as constraints when making
container resize decisions. If existing container actions would exceed the
namespace quotas, Turbonomic recommends actions to resize up the affected
namespace quota.
Note that Turbonomic does not recommend actions to resize down a namespace
quota. Such an action reduces the capacity that is already allocated to an
application – The decision to resize down a namespace quota should include the
application owner.
Workload Controller None
A Workload Controller executes container actions. When you set the scope to a
Workload Controller and view the actions list, the actions apply to containers.
Turbonomic does not recommend actions for the Workload Controller itself.

Getting Started

NOTE:
Turbonomic uses namespace or organization/space quotas as constraints when
making resize decisions. The Workload Controller aggregates container actions.
If those container resizes exceed current namespace quotas, Turbonomic
blocks execution of container resize actions until the namespace quotas are
sufficient. For more information about namespace quotas, see Resource
Quotas (on page 167).
Container Pod • Move
Move a pod between nodes (VMs) to address performance issues or improve
infrastructure efficiency. For example, if a particular node is congested for
CPU, you can move pods to a node with sufficient capacity. If a node is
underutilized and is a candidate for suspension, you must first move the
pods before you can safely suspend the node.
• Provision/Suspend
For horizontally scalable Kubernetes Services that collect performance
metrics (or KPIs) for applications, provision or suspend pods associated with
those Services to maintain SLOs for your applications.
When recommending node provision or suspend actions, Turbonomic will
also recommend provisioning pods (based on demand from DaemonSets) or
suspending the related pods.
For details, see Container Pod Actions (on page 164).
Container Cluster None
Turbonomic does not recommend actions for a Container Cluster. Instead, it
recommends actions for the containers, pods, nodes (VMs), and volumes in the
cluster. Turbonomic shows all of these actions when you scope to a Container
Cluster and view the Pending Actions chart.
Kubernetes node (VM) A Kubernetes node (cloud or on-prem) is represented as a Virtual Machine entity
in the supply chain.
• Provision
Provision nodes to address workload congestion or meet application
demand.
When recommending node provision actions, Turbonomic also recommends
pod provision actions that reflect the projected demand from required
DaemonSet pods, and respects the maximum number of pods allowed for a
node. This ensures that any application workload can be placed on the new
node and stay within the desired range of vMem/vCPU usage, vMem/vCPU
request, and number of consumers.
• Suspend
Suspend nodes after you have consolidated pods or defragmented node
resources to improve infrastructure efficiency.

Getting Started

When recommending node suspension actions, Turbonomic also
recommends suspending the DaemonSet pods that are no longer required to
run the suspended nodes.
For nodes in the public cloud, Turbonomic reports the cost savings or
investments attached to these actions. For details, see Actions for Kubernetes
Nodes (VMs) (on page 180).
Cloud Infrastructure Entity Types

Virtual Machine (Cloud) • Scale
Change the VM instance to use a different instance type or tier to optimize
performance and costs.
• Increase RI Coverage / Buy RI
If you have a high percentage of on-demand VMs, you can reduce your
monthly costs by increasing coverage. To increase coverage, you scale VMs
to instance types that have existing capacity. If you need more RI capacity,
then Turbonomic will recommend Buy RI actions.
For details, see Cloud VM Actions (on page 179).
For cloud VMs used as Kubernetes nodes:
• Provision
demand.
• Suspend
For nodes in the public cloud, Turbonomic reports the cost savings or
investments attached to these actions. For details, see Actions for Kubernetes
Nodes (VMs) (on page 180).
Database (Cloud) Scale
Scale DTU and storage resources to optimize performance and costs.
For details, see Cloud Database Actions (on page 216).

Getting Started

Database Server (Cloud) Scale
Scale compute and storage resources to optimize performance and costs.
For details, see Cloud Database Server Actions (on page 191).
Volume (Cloud) • Scale
Scale attached volumes to optimize performance and costs.
• Delete
Delete unattached volumes as a cost-saving measure.
For details, see Cloud Volume Actions (on page 207).
Zone None
Turbonomic does not recommend actions for a cloud zone.
Region None
Turbonomic does not recommend actions for a cloud region.
On-prem Infrastructure Entity Types

Virtual Machine (On-prem) • Resize
◦ Resize resource capacity
Change the capacity of a resource that is allocated for the VM. For
example, a resize action might recommend increasing the VMem
available to a VM. Before recommending this action, Turbonomic verifies
that the VM's cluster can adequately support the new size. If the cluster
is highly utilized, Turbonomic will recommend a move action, taking
into consideration the capacity of the new cluster and compliance with
existing placement policies.
◦ Resize resource reservation
Change the amount of a resource that is reserved for a VM. For
example, a VM could have an excess amount of memory reserved. That
can cause memory congestion on the host — A resize action might
recommend reducing the amount reserved, freeing up that resource and
reducing congestion
◦ Resize resource limit
Change the limit that is set on the VM for a resource. For example, a VM
could have a memory limit set on it. If the VM is experiencing memory
shortage, an action that decreases or removes the limit could improve
performance on that VM.
• Move
Move a VM due to:
◦ High resource utilization on VM or host

Getting Started

◦ Excess IOPS or latency in VStorage
◦ Workload placement violation
◦ Underutilized host (move VM before suspending host)
• Move VM Storage (Volume)
Move a VM's volume due to excess utilization of the current datastore, or for
more efficient utilization of datastores in the environment.
• Reconfigure
Change network and storage configuration. For example, Turbonomic
recommends this action if the VM is configured to use a network that it
cannot access.
• Reconfigure VM Storage
Reconfigure overutilized storage resources by adding VStorage capacity. For
underutilized storage resources, remove VStorage capacity.
For details, see On-prem VM Actions (on page 231).
For on-prem VMs used as Kubernetes nodes:
• Provision
demand.
• Suspend
Database Server (On-prem) Resize

Resize the following resources:
• Connections
• DBMem
• Transaction Log
Resize actions based on the Transaction Log resource depend on support for
vStorage in the underlying hypervisor technology. Because current versions
of Hyper-V do not provide API support for vStorage, Turbonomic cannot
support Transaction Log resize actions for database servers running on the
Hyper-V platform.
Volume (On-prem) Move

Getting Started

Move a VM's volume due to excess utilization of the current datastore, or for
more efficient utilization of datastores in the environment. To evaluate and
execute actions, set the scope to the VM to which a volume is attached.
Virtual Datacenter None
Turbonomic does not recommend actions for a Virtual Datacenter. Instead,
it recommends actions for the entities that provide resources to the Virtual
Datacenter.
Business User Move
Move a Business User between desktop pools to address:
• Resource congestion on the image
When utilization is consistently near capacity for image resources,
Turbonomic can recommend moving a Business User to a desktop pool that
serves larger images.
• Resource congestion on the desktop pool
When utilization is consistently near capacity for the desktop pool,
Turbonomic can recommend moving a Business User to a desktop pool that
has more available resources.
NOTE:
To support moves, you must configure placement policies that merge similarly
configured desktop pools. For details, see Desktop Pool Placement Policies (on
page 256).
Desktop Pool None
Turbonomic does not recommend actions for a desktop pool. It recommends
actions for the Business Users running active sessions in the pool.
View Pod None
Turbonomic does not recommend actions for a view pod. Instead, it recommends
actions for the Business Users that are running active sessions.
Host • Start
Start a suspended host when there is increased demand for physical
resources.
• Provision
Provision a new host in the environment when there is increased demand for
physical resources. Turbonomic can then move workloads to that host.
• Suspend
When physical resources are underutilized on a host, move existing
workloads to other hosts and then suspend the host.
• Reconfigure
Turbonomic generates this action in response to changing demand for
software licenses. For details, see License Policy (on page 99).

Getting Started

For details, see Host Actions (on page 260).
Chassis None
Turbonomic does not recommend actions for a chassis.
Datacenter None
Turbonomic does not recommend actions for a datacenter. Instead, it
recommends actions for the entities running in the datacenter.
Storage • Move
For high utilization of physical storage, move datastore to a different disk
array (aggregate).
• Provision
For high utilization of storage resources, provision a new datastore.
• Resize
Increase or decrease the datastore capacity.
• Start
For high utilization of storage resources, start a suspended datastore.
• Suspend
For low utilization of storage resources, move served VMs to other
datastores and suspend this one.
• Delete
Delete a datastore or volume that has been suspended for a period of time.
For details, see Storage Actions (on page 268).
Logical Pool • Resize
• Provision
• Move
• Start
• Suspend
Disk Array • Provision
For high utilization of the disk array’s storage, provision a new disk array
(recommendation, only).
• Start
For high utilization of disk array, start a suspended disk array
• Suspend
For low utilization of the disk array’s storage, move VMs to other datastores
and suspend volumes on the disk array (recommendation, only).
• Move

Getting Started

(Only for NetApp Cluster-Mode) For high utilization of Storage Controller
resources, Turbonomic can move an aggregate to another storage controller.
The storage controllers must be running.
For high IOPS or latency, a move is always off of the current disk array. All the
volumes on a given disk array show the same IOPS and Latency, so moving to
a volume on the same array would not fix these issues.
• Move VM
For high utilization of Storage on a volume, Turbonomic can move a VM to
another volume. The new volume can be on the current disk array, on some
other disk array, or on any other datastore.
For high IOPS or latency, a move is always off of the current disk array. All the
volumes on a given disk array show the same IOPS and Latency, so moving to
a volume on the same array would not fix these issues.
• Move Datastore
To balance utilization of disk array resources, Turbonomic can move a
datastore to another array.
Storage Controller Provision

For high utilization of the storage controller’s CPU, provision a new storage
controller, and then move disk arrays to it.
IO Module None
Turbonomic does not recommend actions for an IO Module.
Switch Resize
Resize PortChannel for a switch to increase bandwidth.
Action Types
Turbonomic performs the following general types of actions:
• Placement — Place a consumer on a specific provider (place a VM on a Host)
• Scaling — Resize allocation of resources, based on profitability
◦ Resize up, shown as a required investment
◦ Resize down, shown as savings
• RI Optimization — Purchase RIs for specific workloads or move to RI tiers that are more appropriate for your
applications' requirements
• Configuration — Correct a misconfiguration
• Start/Buy — Start a new instance to add capacity to the environment, shown as a required investment. For
workloads that are good RI candidates, purchase RI capacity to move your environment toward the RI Coverage that
you desire.
• Stop — Suspend an instance to increase efficient use of resources, shown as savings
• Delete — Remove storage (for example, datastores on disk arrays or unattached volumes)

Getting Started
Placement
Placement actions determine the best provider for a consumer. These include initial placement for a new entity, and
move actions that change a consumer to use a different provider. For example, moving a VM assigns it to a different
host. Moving a VM’s storage means the VM will use a different datastore.
Placement Constraints
When making placement decisions, Turbonomic checks for placement constraints to limit the set of providers for a given
consumer. It respects automatic placement constraints, including cluster boundaries and DRS rules. It also considers
user-configured constraints defined in a placement policy to ensure compliance to specific business requirements.
You can run plans to see what happens if you turn off constraints, or disable or enable certain placement policies.
Effective CPU Capacity

CPU processor speed is not necessarily an effective indicator of CPU capacity. For example, processor architecture can
make a slower CPU have a greater effective capacity. Newer models of machines can often have fewer cores or less clock
speed, but still have a higher effective capacity.
When placing VMs on hosts in the on-prem environment, Turbonomic discovers the effective CPU capacity of your hosts.
This increases the accuracy of placement calculations so that newer, more efficient hosts will show a greater effective
capacity than less efficient hosts that might have larger or faster processors.
To discover the effective capacity, Turbonomic uses benchmark data from spec.org. This benchmark data maps to
effective capacity settings that Turbonomic uses to make placement calculations.
You can see a catalog of these benchmark data and choose from listed processors when you edit Host templates. For
more information, see Selecting CPUs from the Catalog (on page 421).
Shared-Nothing Migration Actions

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 details, see Shared-Nothing Migration (on page 236).
Cross-vCenter vMotion
VMware vSphere 6.0 introduces functionality that enables migration of virtual machines between different vCenter
Server instances. Turbonomic supports this capability through Merge placement policies (see Creating Placement
Policies (on page 96)). It considers cross-vCenter locations when calculating placement, and can recommend or
execute moves to different vCenter servers.
Moves on the Public Cloud

On the public cloud you do not place workloads on physical hosts. In the Turbonomic Supply Chain, the Host nodes
represent availability zones. Turbonomic can recommend moving a workload to a different zone, if such a move can
reduce your cloud cost. These moves recognize constraints, such as availability of instances types and RIs in the given
zones.
In AWS environments, a VM can use Elastic Block Stores (EBS) or Instance Storage. If the VM's root storage is EBS, then
Turbonomic can recommend a VM move. However, because Instance Storage is ephemeral and a move would lose the
stored data, Turbonomic does not recommend moving a VM that has Instance Storage as its root storage.

Getting Started
If a VM is running within a billing family, then Turbonomic only recommends moving that VM to other regions within
that billing family.
In AWS environments that use RIs, Turbonomic recognizes Availability Zones that you have specified for your RI
purchases. For move and resize actions, Turbonomic gives precedence to these RIs in the given zone. All else being equal
for a given zone, if you have Zone RIs with reserved capacity and RIs that do not reserve capacity, Turbonomic will use
the Zone RI first.
Scaling
Scaling actions update capacity in your environment. For vertical scaling, Turbonomic increases or decreases the
capacity of resources on existing entities. For horizontal scaling it provisions new providers. For example, provisioning a
host adds more compute capacity that is available to run VMs. Provisioning a VM adds capacity to run applications.
Turbonomic can provision the following:
• Containers
• VMs
• Hosts
• Storage
• Storage Controllers (only for planning scenarios)
• Disk Arrays
Under certain circumstances, Turbonomic can also recommend that you provision a virtual datacenter.
Storage Resize Actions

Any storage resize action impacts both the storage entities and the entities managed by the given hypervisor. However,
not all hypervisors recognize changes to the storage capacity. After executing a storage resize, Turbonomic indicates that
the resize action has succeeded but a hypervisor might not show the corresponding change in storage capacity. If this
occurs, then you must refresh the hypervisor target so Turbonomic can discover the storage changes.
To avoid this situation, you can set the action mode to Manual or Recommend for storage resize actions. In that way, you
can perform the resizes yourself, and then manually refresh your hypervisors.
Scaling on the Public Cloud

On the cloud, scaling actions change the VM to a different instance type. These can include:
• Changing a VM to an instance type with different capacity
• Changing on-demand to RI
For these actions, the action list shows the current cost for the source workload, and also the projected cost given the
change. To show the current cost, Turbonomic uses the actual costs for that workload. However, to show the projected
cost it uses an estimate based on average utilization for the VM, for the costs of the given tier.
Note that scaling to an RI can result in running the VM on a larger instance when the cost is lower. This might occur even
though the VM does not need that capacity and there are other smaller tiers available.
In Azure environments, there are circumstances where a VM resize can be especially disruptive. In a given region, the
infrastructure can be made up of different clusters that have different sets of underlying hardware. Further, some tiers
that are available in the given region are only available on different clusters. If Turbonomic recommends resizing from a
tier on one cluster, to a tier on another cluster, then the resize action can take longer to complete than usual.

Getting Started
In both Azure and AWS environments, Turbonomic conforms to specific instance requirements as it generates resize
actions. For more information, see:
• Azure Instance Requirements (on page 183)
• AWS Instance Requirements (on page 181)
RI Optimization
Turbonomic can recommend purchasing RIs for specific workloads or moving to RI tiers that are more appropriate for
your applications' requirements. See the following charts in the dashboard for relevant information:
• RI Inventory chart: Shows a list of RI workloads that Turbonomic discovered, listed by tiers
• RI Utilization chart: Shows how well you have utilized your RI inventory
• RI Coverage chart: Shows the capacity of your current VM workload compared to the capacity of workload that is
covered by RIs
RI optimization actions are not executed by Turbonomic users. They reflect RI reassignment, which the cloud provider
will take care of.
Configuration
These are reconfigure and resize actions. Reconfigure actions can add necessary network access, or reconfigure storage.
Resize actions allocate more or less resource capacity on an entity, which can include adding or reducing VCPUs or
VMem on a VM, adding or reducing capacity on a datastore, and adding or reducing volumes in a disk array.
Turbonomic can reconfigure the following:
• VMs
• Containers
• Storage
• Disk Arrays
• Virtual Datacenters
Start/Buy
Turbonomic can recommend that you start a suspended entity to add capacity to the environment. It can also
recommend purchasing RI capacity to reduce costs for your current workload. For details, see RI Purchases (on page
39).
Stop
Stop actions suspend entities without removing them from the environment. Suspended capacity is still available to be
brought back online, but is currently not available for use. Suspended resources are candidates for termination.
Turbonomic can suspend the following:
• Application Components
• Container Pods
• Disk Arrays

Getting Started
• Hosts
• Storage (on-prem)
• Virtual datacenter
• VMs
Delete
Delete actions affect storage. For example, Turbonomic might recommend that you delete wasted files to free up
storage space, or delete unused storage in your cloud environment to reduce storage costs.
Wasted Storage in Azure Environments

In Azure environments, Turbonomic can identify unmanaged storage as unattached volumes, recommend that you
remove this unused storage, and then show estimated savings after you remove this storage and no longer pay for
it. The savings that Turbonomic shows are estimates based on the overall cost for that storage, since Azure does not
provide specific values for the cost per volume or cost for the amount of storage that is in use for a given volume. If the
estimated savings appear unusually high, then you should identify which storage the actions will remove, and review
your billing to calculate the costs with more precision.
Action Categories
Turbonomic groups entries in the Actions List by different categories. These categories do not strictly define the severity
of an issue, but they indicate the nature of the issue.
Performance Assurance
Ultimately, the reason to manage workloads in your environment is to assure performance and meet QoS goals. When
Turbonomic detects conditions that directly put QoS at risk, it recommends associated actions in the Performance
category. You can consider these critical conditions, and you should execute the recommended actions as soon as
possible.
Actions Risks/Opportunities
• Provision a new VM, Host, Datastore • <Resource> Congestion
• Increase or decrease the number of VCPUs High utilization of application resources. High
• Provision a new container or container pod utilization of resources on workload, host, or
• Resize heap for an Application Component datastore.
• Scale the resource capacity on an entity
Efficiency Improvement
Efficient utilization of resources is an important part of running in the desired state. Running efficiently maximizes
your investment and reduces cost. When Turbonomic discovers underutilized resources, it recommends actions to

Getting Started
consolidate your operations. For example, it can recommend that you move certain VMs onto a different host. This can
free a physical machine to be shut down.
• Move VM • Overprovisioning
• Start or suspend VM Excess resource capacity in a provider.
• Buy RI
• Scale down resource allocation
Prevention
Turbonomic constantly monitors conditions, and works to keep your environment running in a desired state. As it finds
issues that risk moving the environment out of this state, it recommends associated actions in the Prevention category.
You should attend to these issues, and perform the associated actions. If you do not, the environment may drift away
from the desired state, and the QoS for some services may be put at risk.
• Resize vCPU and vMem • <Resource> Congestion
• Move VM or storage High resource utilization on the named VM, host, or
• Start VM or host datastore. For example, CPU congestion or memory
congestion can occur on a VM or physical machine,
or an IOPS bottleneck can occur on a datastore.
• Workload Balancing
Excess workload on a given physical machine that
can be addressed by moving a VM to another host.
Compliance
A virtual environment can include policies that limit workload placement or availability of resources. It’s possible that
the environment configuration violates these defined policies. It’s also possible that an entity is mis-configured in some
way. For example, a VM might be configured to access a network that is not available in its current host cluster. In such
cases, Turbonomic identifies the violation and recommends actions that bring the entity back into compliance.
• Move VM • Misconfiguration
• Move container Container configuration is in violation of a policy.
• Provision VM, Host, Datastore • Placement Violation
The placement of a VM is in violation of a
Turbonomic policy or an imported Placement Policy.
• Misconfiguration
The configuration violates discovered requirements.
For example, a VM is configured to access a network
that is not available from the current cluster.

Getting Started
Action Modes
Action modes specify the degree of automation for the generated actions. For example, in some environments you
might not want to automate resize down of VMs because that is a disruptive action. You would use action modes in a
policy to set that business rule.
Turbonomic supports the following action modes:
• Recommend — Recommend the action so a user can execute it via the given hypervisor or by other means
• Manual — Recommend the action, and provide the option to execute that action through the Turbonomic user
interface
• Automatic — Execute the action automatically
For automated resize or move actions on the same entity, Turbonomic waits five minutes between each action to
avoid failures associated with trying to execute all actions at once. Any action awaiting execution stays in queue.
For example, if a VM has both vCPU and vMem resize actions, Turbonomic could resize vCPU first. After this resize
completes, it waits five minutes before resizing vMem.
The Pending Actions charts only count actions in Recommend or Manual mode.
Automated actions appear in the following charts:
• All Actions chart on the Home Page and the On-prem Executive Dashboard
• Accepted Actions chart on the Home Page
Setting Action Modes

To set action modes for specific entities, you can edit the Turbonomic automation policies. This is how you specify the
default action modes, or set special action modes for a given group or cluster. For more information, see Automation
Policies (on page 100).
Action Mode Overrides

Under some conditions, Turbonomic changes the action mode of an action from Manual to Recommend.
Turbonomic makes this change as a safeguard against executing actions that the underlying infrastructure cannot
support. For example, assume you have VM move actions set to Manual. Then assume Turbonomic analysis wants to
move a VM onto a host that is already utilized fully. In this case, there would be other actions to move workloads off
of the given host to make room for this new VM. However, because moves are Manual, the host might not be properly
cleared off yet. In that case, Turbonomic changes actions to move workloads to the host from Manual to Recommend.
For cloud environments, some instances require workloads to be configured in specific ways before they can move to
those instance types. If Turbonomic recommends moving a workload that is not suitably configured onto one of these
instances, then it changes the action mode from Manual to Recommend, and then describes the reason.
Working With the Generated Actions

When you start using Turbonomic, all the actions that the product generates appear as pending. You can view them in
the Pending Actions charts and then decide whether to execute and/or automate them. You can also disable them.

Getting Started

Turbonomic will never execute actions automatically, unless you tell it to. If you examine the default policies that ship
with the product, you will notice that these policies do not enable automation on any action. Turbonomic gives you full
control over all automation decisions.

When you first see the pending actions, you execute many of them to see immediate improvements in performance and
utilization. Over time, you develop and fine-tune your action-handling process to meet productivity goals and respond
to changing business needs. This process could lead to the following key decisions:
• Disabling actions that should never execute, such as those that violate business rules
Turbonomic will not consider recommending disabled actions when it performs its analysis.
• Allowing certain actions to execute automatically, such as those that assure QoS on mission-critical resources
Automation simplifies your task, while ensuring that workloads continue to have adequate resources to perform
optimally. As such, it is important that you set the goal of automating as many actions as possible. This requires
evaluating which actions are safe to automate, and on which entities.
• Continuing to let Turbonomic post certain actions so you can execute them on a case-by-case basis
For example, certain actions might require the approval of specific individuals. In this case, you would want
Turbonomic to post those actions for review and only execute the actions that receive an approval.

Getting Started
These are the actions that you would look for in the Pending Actions charts. They no longer show after you execute
them, if you disable or automate them, or if the environment changes in the next market analysis such that the
actions are no longer needed.
What You Can Do:

• View and execute pending actions: See Pending Actions (on page 84).
• See the different display views for the pending actions charts: See Pending Actions Charts (on page 365).
• Scope pending actions in the Home Page: See Pending Actions Scope (on page 86).
• See a running history of generated and executed actions: See Actions Charts (on page 367).
• Review the default policies that drive the actions the product generates.
• Create and run plans to simulate different conditions, and see what actions will keep things healthy under those
conditions: See Plan Management (on page 288).
Pending Actions
Turbonomic treats all the non-automated actions that it generates as pending and shows them in the Pending Actions
charts.

To get the best results from Turbonomic, execute these actions promptly and consider automating as many of them
as possible. You can execute these actions from the user interface or outside Turbonomic. To automate these actions,
create an automation policy (on page 104) or change the action mode to Automatic in the default policies (on page
100).
Turbonomic can execute up to five actions at a time, and queues any new incoming actions for later execution.

Getting Started
Default Pending Actions Charts

Each time you log in to the user interface, Turbonomic immediately shows the Pending Actions charts on the Home
Page's HYBRID view. These charts provide a summary of the actions that require your attention, and entry points to the
Pending Actions List (on page 88).
NOTE:
You can also add these charts to any of your dashboards (on page 354).

By default, a text chart and a list chart display in the Home Page, with the scope set to Global Environment.
You can change the chart type by clicking the icon on the upper-right corner of the chart. For details about the available
chart types, see Pending Actions Charts (on page 365).
Pending Actions - Text Chart

The text chart shows the estimated costs or savings associated with the pending actions, and the number of actions for
each action type (on page 76).

Getting Started

Pending Actions - List Chart

The list chart shows a partial list of pending actions, ordered by the severity of the associated problems.

Pending Actions Scope

To perform Application Resource Management, Turbonomic identifies actions you can take to avoid problems before
they occur. You can perform these actions manually, direct Turbonomic to perform the actions on command, or direct
Turbonomic to perform actions automatically as they arise.
There are several ways to scope pending actions in the Home Page.

Getting Started

To view all pending actions, click Show all Actions in the Pending Actions chart.
Click one of the following to narrow the scope of pending actions:
• An entity type in the supply chain.
Turbonomic generates actions based on how entity types use or provide resources, and what each entity type
supports. For details on the actions that each entity type supports, see Actions by Entity Type (on page 68).
Only entity types with risks (critical, major, or minor) have pending actions. Hover on the entity type to see a
breakdown of risks.
• An action type in the text chart
• An entity name in the list chart
NOTE:
If you are in the ON-PREM or CLOUD view, the text chart displays by default. Switch to the list chart to see the
entity names.
If you clicked Show all Actions or an action type, the Pending Actions List (on page 88) displays immediately.
If you clicked an entity type or an entity name, an Overview page displays first. In that page, click the Actions tab to view
the Pending Actions List.


Getting Started
The Pending Actions List includes additional features to narrow the scope further. You can search for specific actions
using meaningful keywords or use filters. For details, see Pending Actions List (on page 88).
Pending Actions List

The Pending Actions List includes all the actions that Turbonomic currently recommends for the given scope (for details,
see Pending Actions Scope (on page 86)).
You can select actions to execute, and you can expand action items to see more details.

A. Actions List
Each row in the actions list shows:
• The specific action that Turbonomic recommends.
• If applicable, the estimated investment needed to successfully execute the action or the resulting savings after
performing the action
• The action category (on page 80).
By default, actions display by the severity of the associated problems, indicated by the thin colored line before the
checkbox. Use the Filter functionality to change the order by other categories.
Select one or several actions to execute and click Apply Selected.
If you see an action with:
• A grayed-out checkbox ( )
The action is recommended-only, which means you have to perform the action outside Turbonomic. This occurs
when the action mode is Recommend or if the underlying technology for the entity does not support automation.
• A grayed-out checkbox and a prohibition symbol ( )

Getting Started
You need to perform some prerequisite steps outside Turbonomic before you can execute the action. Hover on the
checkbox to see the prerequisite steps.

B. Action Details
Click the arrow icon to expand the entry and view action details.

Action details include:
• A description of the recommended action, such as Scale Virtual Machine....
NOTE:
The action item gives the names of the affected entities. You can click on these entity names to drill down and set
the Home Page scope to that specific entity. To return after drilling down to an entity in the action details, use the
browser's Back button.
• Immediately below the description, a summary of requirements, risks, opportunities, or reasons for the
recommended action
• The impact of executing the action.
For more information, see Action Details (on page 91).
C. Search
For a long list of pending actions, use search to narrow the results.

Getting Started

D. Filter and Sort

When you click Filter, you can:
• Filter the list by action type (on page 76), action mode (on page 82), action category (on page 80), action
prerequisite, or any combination of these items.
• Sort the actions in ascending or descending order by severity, name of the action target, risk category, or savings
amount.
Turbonomic determines action severity by the amount of improvement the affected entities will gain by executing
the action. Action severities are:
◦ Minor — Issues that affect cost or workload distribution, but not impact the QoS your users will experience
◦ Major — Issues that can affect QoS and should be addressed
◦ Critical — Issues that affect the QoS that your environment can deliver, and you are strongly advised to address
them
For example:
• To see only the actions that you can execute through the Turbonomic user interface, filter the list by action mode
and select Manually executable.


Getting Started
• To see only resize actions that are manually executable and that give efficiency improvements, set the filter as
follows:

E. Download
Download the pending actions list as a CSV file.
Action Details
Each action in the Pending Actions list comes with a description and additional details to help you understand why
Turbonomic recommends it and what you would gain if you execute it.
At first glance, some individual actions might appear trivial and it is instinctively convenient to ignore them. It is
important to keep in mind that executing a single action can impact other workloads in a meaningful way, helping move
these other workloads closer to their desired state.
Example

In the image shown above, the action details indicate that scaling the virtual machine to a different instance type
impacts RI coverage in a meaningful way. By increasing RI coverage from 0% to 100%, the projected hourly on-demand
cost drops to $0, bringing estimated savings of $502 per month.

Getting Started
Utilization Charts
Turbonomic uses percentile calculations to measure resource utilization more accurately, and drive actions that improve
overall utilization and reduce costs for cloud workloads. When you examine the details for a pending action, you will see
charts that highlight resource utilization percentiles for a given observation period, and the projected percentiles after
you execute the action.
The charts also plot daily average utilization for your reference. If you have previously executed scaling actions on the
entity, you can see the resulting improvements in daily average utilization. Put together, these charts allow you to easily
recognize utilization trends that drive Turbonomic's recommendations.
Notes:
• You can set constraints in policies to refine the percentile calculations.
• After you execute an action, it might take some time for the charts to reflect the resulting improvements.
Entities with Utilization Charts

Utilization charts display for actions on the following entity types:
Entity Type Monitored Resources Notes

Virtual Machine • vCPU For on-prem VMs, you will see either
• vMem a VCPU or VMem chart, depending
on the commodity that needs to
scale. For cloud VMs and VMs in
Migrate to Cloud plans, both charts
display.
These charts also appear when you
scope to a given VM (on-prem or
cloud) and view the Details page.
They also appear in Migrate to Cloud
plan results.
Database (cloud) • DTU See Cloud Database Actions (on page
• Storage 216).
Database Server (cloud) • vCPU See Cloud Database Server Actions

• vMem and DB Cache Hit Rate (on page 191).

Getting Started
Entity Type Monitored Resources Notes

• IOPS
Volume (cloud) • IOPS These charts also appear when you
• Throughput scope to a given volume and view
the Details page.
See Cloud Volume Actions (on page
207).
Workload Controller • vCPU limits and requests See Container Actions (on page
• vMem limits and requests 151).
Actions Tips and Best Practices

To get the best results from Turbonomic’s Application Resource Management, you should set as many actions as
possible to Automated. If you want to approve any changes, set the actions to Manual.
At first glance, individual actions might appear trivial and it is instinctively convenient to ignore them. It is important to
keep in mind that executing a single action can impact other workloads in a meaningful way, helping move these other
workloads closer to their desired state. However, if you find that a recommended action is not acceptable (for example,
if it violates existing business rules), you can set up a policy with your preferred action.
In some cases, actions can introduce disruptions that you want to avoid at all costs. For example, during critical hours,
Turbonomic might execute a resize action on a mission critical resource, which then requires that resource to restart.
It is important to anticipate these disruptions and plan accordingly. For example, you can create a group for all critical
resources, scope the group in an automation policy, set the action mode to Automatic, and then set the schedule to off-
peak hours or weekends. For details on setting schedules, see Setting Policy Schedules (on page 113).
Resize Actions
Allow VMs that have hot-add enabled to automatically resize up.
Use Tuned Scaling to automatically resize VM and storage resources when the resize amount falls within an acceptable
range, and for Turbonomic to notify you when the amount falls outside the range so you can take the most appropriate
action. For details, see Tuned Scaling for On-prem VMs (on page 233).
After executing a storage resize, Turbonomic indicates that the resize action has succeeded but the hypervisor might not
show the corresponding change in storage capacity. If this occurs, perform a manual refresh of the hypervisor so it can
discover the storage changes.
Move Actions
Turbonomic recommends automating host and storage migration.
Use placement constraints if you have placement requirements for specific workloads in your environment (for example,
all production virtual machines moving only to specific clusters). Turbonomic can automatically import placement
policies when you add a target, or you can create new placement policies. For more information, see Placement Policies
(on page 95).

Getting Started
Working With Policies

Policies set business rules to control how Turbonomic analyzes resource allocation, how it displays resource status, and
how it recommends or executes actions. Turbonomic includes two fundamental types of policies:
• Placement Policies
To modify workload placement decisions, Turbonomic divides its market into segments that constrain the
valid placement of workloads. Turbonomic discovers placement rules that are defined by the targets in your
environment, and you can create your own segments.
• Automation Policies
Turbonomic ships with default settings that we believe will give you the best results from our analysis. These
settings are specified in a set of default automation policies for each type of entity in your environment. For some
scopes of your environment, you might want to change these settings. For example, you might want to change
action automation or constraints for that scope. You can create policies that override the defaults for the scopes you
specify.
The Policy Management page shows all the currently defined policies. From this page you can:
• Create new policies.
• Delete a user-created policy.
• Edit a default or user-created policy.
• Enable or disable discovered placement policies. For a Turbonomic segment (a placement policy that was created in
Turbonomic), you can edit the policy definition as well as enable/disable it.

To see the policies that are applied to a scope, go to the Search page and set the Turbonomic session to that scope. Then
show the Policy view. For more information, see Scope Policies (on page 61).

Getting Started
Things You Can Do

• Manage Imported Placement Policies – Importing Workload Placement Policies (on page 95)
• Create a Placement Policy – Creating Placement Policies (on page 96)
• Create a Scoped Automation Policy – Creating Scoped Automation Policies (on page 104)
Placement Policies
For planning and optimization, Turbonomic recommends actions to place workloads such as applications, or VMs on
their providers (hosts, datastores, disk arrays, networks, etc.). Turbonomic can recommend these actions, or execute
them automatically.
When calculating workload placement, Turbonomic respects cluster boundaries, networks, and provisioned data stores.
In addition, the configuration of your environment can specify logical boundaries, and within Turbonomic you can
create even more boundaries. These boundaries impose segments on the market that Turbonomic uses to model your
application infrastructure.
In finance, a market segment divides the market according to the criteria different groups of people use when they buy
or sell goods and services. Likewise in the Turbonomic market, a workload placement segment uses criteria to focus
the buying and selling of resources within specific groups of entities. This gives you finer control over how Turbonomic
calculates moves. When managing segments you can:
• Review the placement policies that Turbonomic has discovered. These are policies that have been defined in your
environment, outside of Turbonomic. See Importing Workload Placement Policies (on page 95).
• Create placement segments that restrict workload placement according to specific rules. See Creating Placement
Policies (on page 96).
NOTE:
You can enable or disable any imported policy or created workload placement segment to affect placement
calculations in the real-time environment or in plans.
Importing Workload Placement Policies

The hypervisors that you set as targets can include placement policies of their own. Turbonomic imports these
placement policies, and you can choose to enable or disable them as you wish. By default, Turbonomic enables
imported placement policies.
Turbonomic imports:
• vCenter Server DRS Rules
See " Other Information Imported from vCenter " in the Target Configuration Guide
• Virtual Machine Manager Availability Sets
See " Virtual Machine Manager" in the Target Configuration Guide
• Flexera One License Specifications
See " Flexera" in the Target Configuration Guide

Getting Started
NOTE:
In vCenter environments, Turbonomic does not import DRS rules if DRS is disabled on the hypervisor. Further, if
Turbonomic did import an enabled DRS rule, and somebody subsequently disables that DRS rule, then Turbonomic
will discover that the rule was disabled and will remove the imported placement policy.
Creating Placement Policies

Placement Policies set up constraints to affect how Turbonomic calculates the placement of workloads in your
environment. In this way, you can direct Turbonomic to recommend actions that satisfy business rules for your
enterprise.
Turbonomic discovers Placement policies that have been defined in your environment, and you can also create
Placement policies through the Turbonomic user interface. Note that you can enable or disable any Placement policy,
both for real-time analysis and for planning scenarios.
Turbonomic supports the following placement policies:
• Place — Determine which entities use specific providers
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.
• Don't Place — Consumers must never run on specific providers
For example, the VMs in a consumer group can never run on a host that is in the provider group. You can use such a
segment to reserve specialized hardware for certain workloads.
• Merge — Merge clusters into a single provider group
For example, you can merge three host clusters in a single provider group. This enables Turbonomic to move
workload from a host in one of the clusters to a host in any of the merged clusters to increase efficiency in your
environment.
• License — Set up hosts to provide licenses for VMs
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.

2. Choose Policies.

Click to navigate to the Policy Management Page.
This page lists all the policies that you currently have configured for Turbonomic.
3. Create a new Placement policy.

Getting Started

First, select the type of Placement policy to create, then specify the settings:
• Give the policy a name
• Choose the policy type and make the settings
• Save the policy when you're done
4. Create a Place policy.

These policies control where workload can be placed. For example, you can specify that a VM will only be placed
on a host that is a member of a specific cluster. Or you could specify that any applications in a specific group can
only be placed on a datastore that is a member of a specific group.
• Specify the consumer group — The group or cluster of entities that will be placed on the identified providers
• Specify the provider group — The group or cluster of entities that will provide resources to the consumers

Getting Started
• Limit workload entities to placement group — Set the policy to only place consumer entities on members of
the provider group
• Limit the maximum number of workload entities per placement entity to — Limit how many instances of the
consumer entities can be placed on a single provider
5. Create a Don't Place policy.

These policies identify groups or clusters that will never host the consumer entities. For example, you can specify
that a VM will never be placed on a host that is a member of a specific cluster. Or you can specify that a set of
non-critical applications will never be placed on specialized hardware, as a way to ensure availability for critical
applications.
• Specify the consumer group — The group or cluster of entities that will be excluded from the identified
providers
• Specify the provider group — The group or cluster of entities that will not provide resources to the consumers
6. Create a Merge policy.

You can create placement policies that merge multiple clusters into a single logical group for the purpose of
workload placement.
For example, your environment might divide hosts into clusters according to hardware vendor, or by some other
criteria. Workload placement typically does not cross such cluster boundaries. However, there might be no
technical reason to apply these boundaries to workload placement. By creating a larger pool of provider resources,
Turbonomic has even more opportunities to increase efficiency in your environment.
For merge policies, keep the following considerations in mind:
• For most policies that merge host and storage clusters, the clusters you place in the Merge segment must be
members of the same datacenter.
• For vCenter environments, you can create placement policies that merge datacenters to support cross-vCenter
moves. In this case, where a datacenter corresponds to a given vCenter target, the merged clusters can be in

Getting Started
different datacenters. In this case you must create two merge policies; one to merge the affected datacenters,
and another to merge the specific clusters.
Also note that the clusters you merge must use the same network names on their respective datacenters.
• For cloud environments, you can create policies to merge datacenters. Use these merge policies to support VM
moves that find better costs on other zones.
To create a Merge policy, choose the type of entity to merge, and then select the groups you will merge.
7. Create a License policy.

Assume you have purchased a number of licenses for a database – you pay for the right to run that database on a
certain number of hosts. You can create a license policy to identify the hosts that provide the license, and the VMs
that can consume that license.
After you create the policy, Turbonomic can recommend the following actions in response to changing demand for
licenses:
• When demand is low, Turbonomic recommends consolidating VMs on as few license-providing hosts as
possible to reduce your license costs. To consolidate, you move VMs to another host and then reconfigure
the original hosts to remove their licenses. Note that Turbonomic will not recommend suspending these
hosts. Since they remain active, they can be reconfigured to become providers when demand starts to exceed
capacity.
For example, if you have Host_01 providing a license to VM_01 and Host_02 providing a license to VM_02, you
will see two recommendations – move VM_02 to Host_01 and then remove the license in Host_01. You will
not see a recommendation to suspend Host_01.
• When demand exceeds capacity, and there are hosts in the policy that currently do not provide licenses,
Turbonomic recommends reconfiguring those hosts to become providers and then moving VMs to those hosts.
If all hosts are currently providing licenses, Turbonomic recommends adding licenses to the hosts to meet
demand.
These actions are more efficient than provisioning new hosts.
To create a License policy:
• Specify the license consumers (VMs).
• Specify the license providers (hosts).
In addition to creating a license policy, you must also create host automation policies to allow Turbonomic to
recommend reconfigure actions on hosts. In the automation policies, add the license-providing hosts and then
enable the Reconfigure action.
8. When you have made all your settings, be sure to save the Policy.

Getting Started
Automation Policies
As Turbonomic gathers metrics, it compares the metric values against specified constraint and capacity settings to
determine whether a metric exhibits a problem, and what actions to recommend or execute to avoid a problem.
Turbonomic uses Automation Policies to guide its analysis and resulting actions. These policies can specify:
• Action Automation
Whether to execute automatically or manually, or whether to just recommend the action. For more information,
see Action Automation (on page 114).
• Action Scripts
Whether to have Turbonomic execute the action, or execute the action with Action Scripts. For more information,
see Deploying Action Scripts (on page 119).
• Action Orchestration
Whether to have Turbonomic execute the action, have Turbonomic direct an orchestrator to execute the action, or
execute the action with Action Scripts. For more information, see Action Orchestration (on page 115).
• Constraints and Other Settings
Settings that affect the Turbonomic analysis of the state of your environment. These include operational, utilization,
and scaling constraints.
For more information, see Constraints and Other Settings (on page 126).
Default and Scoped Automation Policies

Turbonomic ships with default Automation Policy setting for the different types of entities it can discover in your
environment. The settings for these default policies should be adequate to meet your initial business requirements.
These policies apply to the global scope – Unless you override them, they affect all the entities in your environment. For
more information, see Working With Default Automation Policies (on page 100).
Turbonomic can include scoped Action Policies, which override the default settings for certain entities. With these
policies you specify one or more groups of entities as the policy scope. You can also set a schedule to the policy to
specify maintenance windows, or to support orchestration workflows that require approval before executing the given
action. For more information, see Working With Scoped Automation Policies (on page 103) and Setting Policy
Schedules (on page 113).
Working With Default Automation Policies

Turbonomic ships with default Automation Policy settings for the different types of entities it can discover in your
environment. The settings for these default policies should be adequate to meet your initial business requirements.
These policies apply to the global scope – Unless you override their settings, they affect all the entities in your
environment.
Over time you might learn that you want to make global changes to certain policy settings. For example, Enforce Non
Disruptive Mode is turned off by default. You might learn that in most cases you want to turn it on, and only turn it
off for select scopes. In that case, you would turn it on in the default Automation Policy for VMs, and then set scoped
policies for those groups of VMs for which you want to turn it off.

Getting Started
Relationships Between Default and Scoped Policies

Your default Automation Policies and scoped Automation Policies take effect in relation to each other. A default policy
has a global effect, while a scoped policy overrides the default policy for the entities within the indicated scope. You
should keep the following points in mind:
• Scoped policies set overrides to specific settings
A scoped policy can override a subset of settings for the entity type, and for the remainder Turbonomic will use the
default policy settings on the indicated scope.
• Among scoped policies, the most conservative setting wins
It's possible to set up policies with conflicts on individual entities. Assume two groups, Group_A and Group_B. Now
imagine that one entity is a member of both groups. What happens if you create two different Automation Policies,
one for Group_A and another for Group_B? In that case, the entity that is in both groups can have different policy
settings.
For example, the Group_A policy could set the Suspend action to Manual, while the setting for Group_B is
Recommend. Turbonomic always uses the most conservative setting. For this case, the Recommend setting is most
conservative, so it wins.
• Scoped policies always take precedence over default policies
Even if the dafault policy has a more conservative setting, the setting in the scoped policy wins for entities in that
scope.
• For a global effect, always use default policies
Because of the conservative setting wins rule for scoped policies, you should never use a scoped policy to set a
global effect. For example, you can create a scoped policy for the All VMs group. If you then specify a conservative
setting for that policy, no other scoped policy can specify a more aggressive setting – the conservative setting will
always win.
For this reason, you should always use default Automation Policies whenever you want to achieve a global effect.
Viewing and Editing Default Automation Policies

To view or edit your default policies:

2. Choose Policies.

Click to navigate to the Policy Management Page.
This page lists all the policies that you currently have configured for Turbonomic.
3. On the Policy Management page, click Defaults.

Getting Started

The page displays a list of all the default policies, by entity type.
4. Click the entity type whose default settings you wish to view or change.
A fly-out appears with all the settings for that default policy. You can navigate to view different settings
5. Optionally, edit settings for this default policy.
Navigate to the settings you want to change, and enter a different value for each.
6. When you're done, click Save and Apply.
Global Default Policy

Use these settings to modify Turbonomic analysis globally for any scope of your environment. These defaults affect both
scoped automation policies and default automation policies.
ACTION AUTOMATION
Disable All Actions

Attribute Default Setting
Disable All Actions OFF
When this is ON, Turbonomic dos not generate any actions for your environment. For example, assume you have
configured a number of polices that automate actions, but you want to stop making changes to the entire environment
for a period of time. Turn this ON to stop all execution with a single setting.
OPERATIONAL CONSTRAINTS
VM Growth Observation Period

Attribute Default Value
VM Growth Observation Period 1 month
Use this setting to specify how much historical data the Turbonomic analysis will use to calculate time to exhaustion of
your cluster resources.

Getting Started
Turbonomic runs nightly plans to calculate headroom for the clusters in your on-prem environment. To review your
cluster headroom in dashboards, set the view scope to a cluster. With that scope, the view includes charts to show
headroom for that cluster, as well as time to exhaustion of the cluster resources.
To calculate cluster growth trends, analysis uses historical data for the given clusters. With VM Growth Observation
Period, you can specify how much historical data the headroom analysis will use to calculate time to exhaustion of your
cluster resources. For example, if cluster usage is growing slowly, then you can set the observation to a period that is
long enough to capture that rate of growth.
If the historical database does not include at least two entries in the monthly data for the cluster, then analysis uses
daily historical data.
Allow Unlimited Host Provisioning

Allow Unlimited Host Provisioning OFF
By default, Turbonomic allows overprovisioning hosts up to 10 times their memory capacity, and up to 30 times their
CPU capacity. When this setting is ON, Turbonomic removes these overprovisioning limits to allow VM placements on
already overprovisioned hosts.
This setting does not stop Turbonomic from recommending actions to provision new hosts in clusters.
Enable Analysis of On-prem Volumes

Enable Analysis of On-prem Volumes OFF
By default, Turbonomic only monitors the state of on-prem volumes attached to VMs. When you turn on this setting,
Turbonomic will start collecting volume metrics and then use those metrics in its analysis. This setting is especially useful
when:
• Placing individual volumes on groups of storage using volume placement policies (on page 95). If this setting is
turned off, all on-prem volumes associated with a storage will move together rather than independently.
• Running Migrate to Cloud plans (on page 318). With this setting turned on, Turbonomic can generate more
accurate placement decisions for the VMs and volumes that you are planning to migrate.
Be aware that turning on this setting increases the memory and storage utilization of your Turbonomic instance.
Currently, instances that monitor more than 50,000 volumes will experience a significant drop in performance. For this
reason, this setting is turned off by default.
Working With Scoped Automation Policies

To override the current default Automation Policies, you can create scoped policies. These specify settings you want
to change for certain entities in your environment. For these policies, you assign the policy to one or more groups of
entities. In addition, you can assign a schedule to a scoped policy to set up maintenance windows or other scheduled
actions in your environment.

Getting Started
Reasons to create scoped Automation Policies include:

• Change the Analysis Settings for Certain Entities
Turbonomic uses a number of settings to guide its analysis of the entities in your environment. The default settings
might be fine in most cases, but you might want different analysis for some groups of entities. You can configure
scoped policies to modify Operational Constraints or Scaling Constraints. For more information, see Constraints and
Other Settings (on page 126).
• Phase In Action Automation
Assume you want to automate scaling and placement actions for the VMs in your environment. It is common to take
a cautious approach, and start by automating clusters that are not critical or in production. You can scope the policy
to those clusters, and set the action mode to Automatic for different actions on those VMs (see Action Modes (on
page 82)).
• Set Up Action Scripts Entities
Scoped policies can use Action Scripts to integrate actions with other technologies, or to execut costom processes in
relation to an action. For more information, see Deploying Action Scripts (on page 119).
For the steps to create a scoped policy, see Creating Scoped Automation Policies (on page 104).
Discovered Scoped Automation Policies

As Turbonomic discovers your environment, it can find configurations that set up scopes that need specific policies. For
example:
• HA Configurations
For vCenter Server environments, Turbonomic discovers HA cluster settings and translates them into CPU and
memory utilization constraints. The discovery creates a group of type folder for each HA cluster, and creates a policy
that sets the appropriate CPU and memory constraints to that policy.
• Availability Sets
In public cloud environments, Turbonomic discovers groups of VMs that should keep all their VMs on the same
template. In the Automation Policies list, these appear with the prefix AvailabilitySet:: on the policy names.
You can enable Consistent Resizing for the VMs in each group so Turbonomic can resize them to the same size.
Creating Scoped Automation Policies

Create a new scoped Automation Policy from the Policy Management Page.
1. Entry Point
Navigate to the Settings Page and then choose Policies.

Getting Started

This opens the Policy Management Page, which lists all the currently available policies.

Click NEW AUTOMATION POLICY and then select the policy type.


Getting Started
This sets the type of entity that your policy will affect. Note that Turbonomic supports different actions for different
types of entities. For example, you cannot add VMem to a storage device. Setting policy type is the first step you take to
focus on which actions you want to map to your workflows.
2. Policy Name
Name the policy.


Getting Started
3. Scope

The scope determines which entities this policy will affect. Choose one or more groups, or create new groups and add
them to the policy scope. These groups match the type of entity you have set for the policy.
In Turbonomic you can find nested groups (groups of groups). For example, the "By PM Cluster" group contains host
clusters, and each host cluster is a group. Do not set the policy scope to a parent of nested groups. When setting up
policies, be sure you set them to individual groups. If necessary, create a custom group for the settings you want to
apply.
NOTE:
A single entity can be a member of multiple groups. This can result in a conflict of settings, where the same entity can
have different Action Policy settings. For conflicts among scoped policy settings, the most conservative setting will
take effect. For more details, see Policy Scope (on page 112).

Getting Started
4. Policy Schedule

For use cases and information about how schedules affect policies, see Policy Schedules (on page 113).
The Select Schedule fly-out lists all the schedules that are currently defined for your instance of Turbonomic.
Expand a schedule entry to see its details. The details include a summary of the schedule definition, as well as:
• Used in Policies
The number of policies that use this schedule. Click the number to review the policies.
• Next Occurrence
When the schedule will next come into effect.
• Accepted Actions
How many scheduled actions have been accepted to be executed in the next schedule occurrence. Click the number
for a list of these actions.
• Awaiting Acceptance
The number of Manual actions affected by this schedule that are in the Pending Actions list, and have not been
accepted. Click the number for a list of these actions.

Getting Started
If none of the listed schedules is suitable for your policy (or if none exists), click New Schedule. See Creating Schedules
(on page 414).
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.
5. Automation and Orchestration

You can define automation and orchestration settings for different action types within the same policy. For example, for
a group of VMs in a policy, you can automate all Resize actions, but require Suspend actions to go through an approval
process via an Orchestrator (such as ServiceNow).

Getting Started

5.1. Action Type
See a list of actions that are viable for the policy, and then make your selections.
5.2. Action Generation and Acceptance
• Do not Generate Actions
Turbonomic never considers your selected actions in its calculations. For example, if you do not want to generate
Resize actions for VMs in the policy, analysis will still drive toward the desired state, but will do so without
considering resizes.
• Generate Actions

Getting Started
Turbonomic generates your selected actions to address or prevent problems. Choose from the following Action
Acceptance modes to indicate how you would like the actions to execute:
◦ Recommend — Recommend the action so a user can execute it via the given hypervisor or by other means
◦ Manual — Recommend the action, and provide the option to execute that action through the Turbonomic user
interface
◦ Automatic — Execute the action automatically
For automated resize or move actions on the same entity, Turbonomic waits five minutes between each action
to avoid failures associated with trying to execute all actions at once. Any action awaiting execution stays in
queue. For example, if a VM has both vCPU and vMem resize actions, Turbonomic could resize vCPU first. After
this resize completes, it waits five minutes before resizing vMem.
If you have a ServiceNow target, and that target includes an installation of the Turbonomic Actions application, you can
send the action to ServiceNow. Choose from the following options:
• Generate Action then Send Record to ServiceNow
• Generate Action then Request Approval from ServiceNow
For more information, see Action Orchestration (on page 115).
5.3. Before Execution, Action Execution, and After Execution
By default, generated actions execute without the need for orchestration. Turbonomic gives you the ability to set up
orchestration to affect the execution of actions.
For more information, see Action Orchestration (on page 115).
5.4. Execution Schedule
You can defer the execution of generated actions to a non-critical time window. For example, if a workload experiences
memory bottlenecks during the week, you can defer the necessary resize to the weekend. Even if the workload has
minimal utilization over the weekend, Turbonomic can recognize the need to resize, and will execute the action.
For more information, see Action Execution Schedules (on page 113).
6. Constraints and Other Settings

The settings you can make are different according to the type of entity this policy will affect. Each setting you add to the
policy takes precedence over the default value for that setting. For information about the settings you can make, see
Constraints and Other Settings (on page 126).

Getting Started

Policy Scope
You must declare a scope whenever you make a scoped Automation Policy. The scope determines which entities will be
affected by the policy settings. To set scope, you assign one or more groups to the policy. You can use discovered groups,
or you can create your own groups. For information about creating groups, see Creating Groups (on page 409).
Relationships Between Default and Scoped Policies

Your default Automation Policies and scoped Automation Policies take effect in relation to each other. A default policy
has a global effect, while a scoped policy overrides the default policy for the entities within the indicated scope. You
should keep the following points in mind:
• Scoped policies set overrides to specific settings
A scoped policy can override a subset of settings for the entity type, and for the remainder Turbonomic will use the
default policy settings on the indicated scope.
• Among scoped policies, the most conservative setting wins
It's possible to set up policies with conflicts on individual entities. Assume two groups, Group_A and Group_B. Now
imagine that one entity is a member of both groups. What happens if you create two different Automation Policies,
one for Group_A and another for Group_B? In that case, the entity that is in both groups can have different policy
settings.
For example, the Group_A policy could set the Suspend action to Manual, while the setting for Group_B is
Recommend. Turbonomic always uses the most conservative setting. For this case, the Recommend setting is most
conservative, so it wins.

Getting Started
• Scoped policies always take precedence over default policies

Even if the dafault policy has a more conservative setting, the setting in the scoped policy wins for entities in that
scope.
• For a global effect, always use default policies
Because of the conservative setting wins rule for scoped policies, you should never use a scoped policy to set a
global effect. For example, you can create a scoped policy for the All VMs group. If you then specify a conservative
setting for that policy, no other scoped policy can specify a more aggressive setting – the conservative setting will
always win.
For this reason, you should always use default Automation Policies whenever you want to achieve a global effect.
Policy Schedules
You can set a schedule for an automation policy, which sets a window of time when the policy takes effect. For example,
you can modify the Operational or Scaling Constraints for a given period of time. These settings affect Turbonomic
analysis, and the actions it generates. You can set up scheduled times when you want to change those settings.
Remember that for scoped automation policies, it is possible that one entity can be in two different scopes – This means
the entity can be under the effect of two different policies. For this reason, scoped policies keep the rule, the most
conservative setting wins. However, a more aggressive scoped policy takes precedence over the corresponding default
automation policy. For more details, see Policy Scope (on page 112).
You must consider these rules when you add schedules to policies. If the more conservative settings are in a default
automation policy, then the scheduled change takes effect. However, if the more conservative settings are in another
scoped policy, then the conservative settings win, and the scheduled changes do not take effect.
Policy Schedule and Action Execution Schedule

A scheduled policy can include actions. When the policy is in effect, Turbonomic recommends or automatically executes
those actions as they are generated. Some of those actions could be disruptive so you may want to defer their execution
to a non-critical time window. In this case, you will need to set an action execution schedule within the scheduled policy.
For example, you can set a policy that automatically resizes or starts VMs for your customer-facing apps for the entire
month of December, in anticipation of an increase in demand. Within this same policy, you can set the resize execution
schedule to Monday, from midnight to 7:00 AM, when demand is expected to be minimal.
For more information, see Action Execution Schedules (on page 113).
Action Execution Schedules

You can defer the execution of generated actions to a non-critical time window. For example, if mission-critical VMs
experience memory bottlenecks during the week, you can defer the necessary memory resizes to the weekend. Even
if the VMs have minimal utilization over the weekend, Turbonomic can recognize the need to resize, and will execute
resize actions. For this particular example, you will need to:
1. Create a scoped policy for the VMs.
2. Select VMem Resize Up from the list of actions and then set the action mode to either Automatic or Manual.
NOTE:
Execution schedules have no effect on recommended actions. It is therefore not necessary to set up an
execution schedule if all the actions in your policy will be in Recommend mode.
3. Set an Execution Schedule that starts on Saturday at 8:00 AM and lasts 48 hours.

Getting Started
Execution of Scheduled Actions

Turbonomic posts an action at the time that the conditions warrant it, which means that you might see the action in the
Pending Actions list even before the execution schedule takes effect. The action details show what schedule affects the
given action, and shows the next occurrence of that schedule.
• Automatic
When the schedule takes effect, Turbonomic executes any pending automated actions.
• Manual
Before the execution schedule, the action details for manually executable actions show the action state as PENDING
ACCEPT. If you accept the action (select it and click Apply Selected), then Turbonomic adds it to the queue of
actions to be executed during the maintenance window. The action details show the action state as AWAITING
EXECUTION. Turbonomic executes the actions when the schedule takes effect.
Keeping Actions Valid Until the Scheduled Time

If you have scheduled action execution for a later time, then conditions could change enough that the action is no longer
valid. If this happens, and the action remains invalid for 24 hours, then Turbonomic removes it from the list of pending
actions. This action will not be executed.
Turbonomic includes Scaling Constraints that work to stabilize action decisions for VMs. The resulting actions are more
likely to remain valid up until their scheduled window for execution. You can make these settings in default or scoped
policies.
NOTE:
When you configure an execution schedule for a resize action, to ensure Turbonomic will execute the action during
the scheduled time, you must turn off the Enforce Non Disruptive Mode setting for the policy. Even if you turn the
setting off for the global policy, you still must turn the setting off for your policy. Otherwise Turbonomic will not
execute the resize action. For information about non disruptive mode, see Non-disruptive Mode (on page 236).
Action Automation
To avoid problems in your environment, Turbonomic analysis identifies actions that you can execute to keep things in
optimal running order. You can specify the degree of automation you want for these given actions. For example, in some
environments you might not want to automate resize down of VMs because that is a disruptive action. You would use
action modes in a policy to set that business rule.
Action modes specify the degree of automation for the generated actions. For example, in some environments you
might not want to automate resize down of VMs because that is a disruptive action. You would use action modes in a
policy to set that business rule.
Turbonomic supports the following action modes:
• Recommend — Recommend the action so a user can execute it via the given hypervisor or by other means
• Manual — Recommend the action, and provide the option to execute that action through the Turbonomic user
interface
For automated resize or move actions on the same entity, Turbonomic waits five minutes between each action to
avoid failures associated with trying to execute all actions at once. Any action awaiting execution stays in queue.

Getting Started
For example, if a VM has both vCPU and vMem resize actions, Turbonomic could resize vCPU first. After this resize
completes, it waits five minutes before resizing vMem.
Action Mode Configuration

There are two ways to configure action modes:
• Change the action mode in a default policy. For details, see Working With Default Automation Policies (on page
100).
• Create an automation policy, scope the policy to specific entities or groups, and then select the action mode for
each action.
Turbonomic allows you to create dynamic groups to ensure that entities discovered in the future automatically add
to a group and apply the policy of that group. If a conflict arises as a result of an entity belonging to several groups,
the entity applies the policy with the most conservative action.
For details, see Creating Scoped Automation Policies (on page 104).
Action Orchestration
Action Orchestration specifies whether Turbonomic will execute an action, or whether Turbonomic will pass the action
request to an orchestrator or action script that will execute its own workflow to effect the change in your environment.
In this way, you can integrate supported orchestrators to execute of actions for specific scopes of entities in your
environment.
About Orchestrators
Action Orchestration targets assign workflows that execute multiple actions to make changes in your environment.
Turbonomic discovers workflows that you have defined on the orchestrator. You can then set up an automation policy
that maps workflows to actions. If the action mode is Manual or Automatic, then when Turbonomic recommends the
action, it will direct the orchestrator to use the mapped workflow to execute it.
Turbonomic supports integration with ServiceNow. You can configure policies that log Turbonomic actions in your
ServiceNow instance, and that submit actions for approval in ServiceNow workflows.
This section shows how to link orchestration workflows to automation policies. It assumes you have already configured
an appropriate Orchestration target. It also assumes that you have configured workflows on that target in such a way
that Turbonomic can discover the workflows and map them to automation policies. For information about Orchestration
target requirements, see the Target Configuration Guide.
NOTE:
For some orchestration workflows, it is necessary to schedule an action to execute only during a specific maintenance
window. Turbonomic policies can include schedules to enable this use case. However, you must be sure that you do
not set the schedule to the policy that declares the orchestration you want. Instead, you should use two policies for
the same scope – one to set up the orchestration, and another to schedule the time window during which the action
mode will be Automatic (to set up the maintenance window). For more information, see Setting Policy Schedules
(on page 113).

Getting Started
About Action Scripts

Action Scripts provide a script interface that can add custom processing to Turbonomic actions at different entry points.
For example, you can create a script that sends an email whenever Turbonomic recommends moving a VM, or you can
create a script that runs as a replacement for the action that Turbonomic would execute.
You deploy action scripts on a remote machine, and configure an Action Script target that communicates with this
Action Script server. Turbonomic discovers the exposed scripts and displays them as options you can choose when you
specify an Action Script in your orchestration policy.
For more information about Action Scripts, see Deploying Action Scripts (on page 119).
Specifying Action Orchestration

As you create a policy, you specify the entity type and the scope of entities the policy affects. You can also set modes for
specific actions. For example, you can set a mode of Manual for the Resize action for a given scope of VMs.
1. Expand Automation and Orchestration and click Add Action. Then select the action type you want to orchestrate.

Getting Started

There is no orchestration for this action by default. The following table describes the supported orchestration
workflows.
Workflow 3:
Workflow 2:
Workflow 1: Generate Action then
Generate Action then Send
Generate Actions Request Approval from
Record to ServiceNow
ServiceNow
Description Generate actions as usual, but Send a record of the Defer the generated actions to
use an Action Script to control generated actions to your ServiceNow workflow for
action execution. ServiceNow. approval.
Turbonomic passes control
for this action to your

Getting Started
Workflow 3:
Workflow 2:
ServiceNow
ServiceNow workflow as a
Change Request (CR).
Prerequisites An Action Script target • A ServiceNow target that • A ServiceNow target that
includes an installation of includes an installation of
the Turbonomic Actions the Turbonomic Actions
application application
• An appropriate workflow • An appropriate workflow
set up for Records as set up for Approvals as
part of the Turbonomic part of the Turbonomic
Actions installation Actions installation
• An Action Script target (if • An Action Script target (if
using an Action Script to using an Action Script to
control action execution) control action execution)
Action Choose from the following: Action acceptance
Acceptance • Recommend — Recommend the action so a user can automatically changes to
execute it via the given hypervisor or by other means "External Approval". If the
action is approved, the action
• Manual — Recommend the action, and provide the option
executes using the default
to execute that action through the Turbonomic user
Action Acceptance mode.
interface
For automated resize or move actions on the same entity,
Turbonomic waits five minutes between each action to
avoid failures associated with trying to execute all actions
at once. Any action awaiting execution stays in queue.
For example, if a VM has both vCPU and vMem resize
actions, Turbonomic could resize vCPU first. After this
resize completes, it waits five minutes before resizing
vMem.
Before The default is Do Nothing.
Execution Select Use Action Script to run an action script that is set up for the PRE entry point. The action
script name must match the entity type and action type. For example, you can post an email
notification to your team that an action has been generated.
Action The default is Native. Turbonomic executes the action with its default action processing.
Execution Select Use Action Script to let Turbonomic execute a matching action script in place of its default
action processing.
You must have created and deployed an action script that matches the given entry point (for
action execution, REPLACE), the given action, and the given entity type.
Execution There is no execution schedule by default. Turbonomic executes There is no execution
Schedule the action immediately. schedule by default.

Getting Started
Workflow 3:
Workflow 2:
ServiceNow
If the policy includes a schedule, Turbonomic executes the Turbonomic executes the
action at the scheduled time. action immediately.
If the policy includes a
schedule, Turbonomic
executes the action at the
scheduled time.
NOTE:
Turbonomic discovers
and enforces execution
schedules defined in
ServiceNow approval
workflows. To avoid
potential issues with
schedules, set the
execution schedule either in
ServiceNow or Turbonomic.
After The default is Do Nothing. The default is Do Nothing.
Execution Select Use Action Script to Other options include:
run an action script that is set • Create Record in ServiceNow
up for the POST entry point.
The action script name must Turbonomic registers the action in the ServiceNow log,
match the entity type and showing that the given action has been executed.
action type. • Use Action Script
Run an action script that is set up for the POST entry point.
The action script name must match the entity type and
action type.
2. When you have made all your settings, be sure to save the action policy.
Deploying Action Scripts

Action Scripts provide an interface that can add custom processing to Turbonomic actions.
Action scripts execute on a remote server (a VM or a container) that you have configured as a Turbonomic target. That
server includes a manifest file that identifies the scripts you have deployed, as well the entities and actions they can
respond to. Turbonomic discovers these scripts via the manifest and presents them as orchestration options for actions
in automation policies.
For example, assume you have defined a script with:
• name: MyVmMoveAction
• entityType: VIRTUAL_MACHINE
• actionType: MOVE

Getting Started
Following this example, you can use the API to add orchestration to a policy for move actions on VMs. Because you
have defined a script for that action, you can specify Action Script as the orchestration type, and you can choose the
MyVmMoveAction script as the orchestration workflow to perform.
To deploy your action scripts, you will:
• Set up the remote action script server (see Setting Up the Action Script Server (on page 120))
• Create the action script executables on the remote server (see Creating Action Scripts (on page 121))
• Deploy the Action Script Manifest on the remote server (see Deploying the Action Script Manifest (on page 122))
Setting Up the Action Script Server

Turbonomic uses remote servers to execute action scripts. Managing the processes remotely means that you do not
install custom code on the Turbonomic server, which eliminates associated security risks there. However, you are
responsible for maintaining the security of your action script server, to ensure the integrity of your custom code. To
accomplish this, the configuraton of the remote server must meet certain requirements.
Resource Requirements for the Server

The remote server can be a VM or a container. The capacity you configure for the server depends entirely on the
processes you intend to run on it. Turbonomic does not impose any special resource requirements on the server.
Configuring Command Execution

To support execution of your scripts, you must install any software that is necessary to run the scripts. This includes
libraries, language processors, or other processes that your scripts will invoke.
Turbonomic invokes the scripts as commands on the server. The server must run an SSH service that you have cnfigured
to support command execution and SFTP operations. At this time, Turbonomic has tested action scripts with the
OpenSSH sshd daemon.
The standard port for SSH is 22. You can configure a different port, and provide that for admins who configure the server
as an Action Script target.
Note that an action script can invoke any process you have deployed on the remote server. You do not have to run
scripts per se. However, you must be able to invoke the processes from the command line. The script manifest gives
Turbonomic the details it needs to build the command line invocation of each script.
Configuring the Action Script User Account

To execute the scripts on your server, Turbonomic logs on via a user account that is authorized to execute the scripts
from the command line. You provide the user credentials when you configure the Action Script target. To support this
interaction, the user account must meet the following requirements:
• Public Key
The user must have a public key in the .ssh/authorized_keys file. When you configure the Action Script target,
you provide this as the Private Token for the target.
• Security for the .ssh Directory
The Action Script User should be the only user with authorized access. You should set file permissions to 600.
• Supported Shells

Getting Started
The Action Script User shell can be either the Bourne shell (usually at /bin/sh) or the Bourne-Again shell (usually
at /bin/bash). Turbonomic passes parameters as it invokes your scripts. At this time it only supports script
execution through these shells.
Handling Action Script Timeouts

Turbonomic limits script execution to 30 minutes. If a script exceeds this limit, Turbonomic sends a SIGTERM to
terminate the execution of the process.
Note that Turbonomic does not make any other attempt to terminate a process. For example you could implement
the script so it traps the SIGTERM and continues to run. The process should terminate at the soonest safe opportunity.
However, if the process does not terminate, then you must implement some way to terminate it outside of Turbonomic.
Note that a runaway process continues to use its execution thread. This can block other processes (action scripts or
primary processes) if there are no more threads in the pool.
Creating Action Scripts

An action script can be any executable that a user can invoke from a command line. You can save these executable files
anywhere on the server – The Manifest indicates the path to the file (see Deploying the Action Script Manifest (on page
122)). The Action Script user that you have configured for the script server must have access to your script files, with
read and execution privileges.
To execute a script, Turbonomic builds the appropriate SSH command from the manifest information it has discovered.
It grants a timeout limit of 30 minutes by default, or the manifest entry can declare a different limit. If the execution
exceeds the limit, Turbonomic sends a SIGTERM to terminate the process.
Passing Information to the Action Script

Turbonomic uses two techniques to pass information about an action to the associated action script:
• Pass general information via environment variables
• Pass full action data via stdin
To pass general information into the script, Turbonomic sets environment variables on the Action Script server. You can
reference these environment variables in your scripts. For example, assume you want to send an email that includes the
name of the VM that is an action target. You can get that name via the VMT_TARGET_NAME environment variable.
The following list shows the environment variables that Turbonomic can set when it executes a script. Note that not
all of these variables apply for every action. For example, an action to scale VMEM does not include providers, so the
action does not include values for the VMT_CURRENT_INTERNAL, VMT_CURRENT_NAME, VMT_NEW_INTERNAL, or
VMT_NEW_NAME variables. If a given variable does not apply, Turbonomic sets it to an empty string.
• VMT_ACTION_INTERNAL
The UUID for the proposed action. You can use this to access the action via the REST API. For example, your script
could accept or cancel the action according to its own criteria.
• VMT_ACTION_NAME
The name of the action.
• VMT_CURRENT_INTERNAL
The internal name for the current provider.
• VMT_CURRENT_NAME
The display name for the current provider.

Getting Started
• VMT_NEW_INTERNAL
The internal name for the new provider.
• VMT_NEW_NAME
The display name for the new provider.
• VMT_TARGET_INTERNAL
The internal name of the entity this action will affect. You can use this to access the target entity via the REST API.
For example, you can get historical statistics or you can change settings for the entity.
• VMT_TARGET_NAME
The display name of the entity this action will affect.
• VMT_TARGET_UUID
The UUID of the entity this action will affect.
For some scripts, you might need a complete description of the associated action. For example, assume you want to
analyze the utilization metrics for a given resource. The environment variables for passing general information do not
include this information.
When it invokes an action script, Turbonomic passes the complete data for the associated action via stdin. Your
script can load this into a variable to access the specific data it needs. For example, the following loads stdin into
myActionData:
myActionData=$(cat -)
stdin contains a JSON string that represents of the full data associated with this action. For example, the
myActionData variable could contain a string similar to:
{"actionType":"RIGHT_SIZE","actionItem":[{"actionType":"RIGHT_SIZE","uui
d":"143688943343760","targetS
E":{"entityType":"VIRTUAL_MACHINE","id":"4200fcdb-eafe-2a4a-abf5-a7ad2b00555c"...
Deploying the Action Script Manifest

The Action Script Manifest identifies the scripts that you want to expose to Turbonomic. You provide the location of the
manifest as part of the Action Script Target configuration – After Turbonomic validates the target, it then discovers these
scripts and presents them in the Orchestration Policy user interface.
Creating the Scripts Manifest File

The Scripts Manifest is a file that declares an array of Script Objects for each script you want to expose. You can create
the manifest as either a JSON or a YAML file.

Getting Started
For example, following are two examples of the same manifest – One in YAML and the other in JSON. Notice that in
either case, the manifest is an array of two Script objects:
• YAML Manifest:
scripts:
- name: MyVmMovePrep
description: Execute this script in preperation to a VM Move
scriptPath: vmScripts/movePrep.sh
entityType: VIRTUAL_MACHINE
actionType: MOVE
actionPhase: PRE
- name: MyVmSuspendReplace
description: Execute this instead of a VM Suspend action
scriptPath: vmScripts/suspendReplace.sh
entityType: VIRTUAL_MACHINE
actionType: SUSPEND
actionPhase: REPLACE
• JSON Manifest:
{
"scripts": [
{
"name": "MyVmMovePrep",
"description": "Execute this script in preperation to a VM Move",
"scriptPath": "vmScripts/movePrep.sh",
"entityType": "VIRTUAL_MACHINE",
"actionType": "MOVE",
"actionPhase": "PRE"
},
{
"name": "MyVmSuspendReplace",
"description": "Execute this instead of a VM Suspend action",
"scriptPath": "vmScripts/suspendReplace.sh",
"entityType": "VIRTUAL_MACHINE",
"actionType": "SUSPEND",
"actionPhase": "REPLACE"
}
]
}
You can save the Scripts Manifest file to any location on your server, so long as the Scripts User has access to that
location, and has read and execute privileges. You will provide this location as the Script Path, which the Turbonomic
administrator will give as part of the Action Script target configuration.
Note that the filename extension for the manifest must match the file format (either YAML or JSON). For example, you
should name the file either MyManifest.yaml or MyManifest.json, respectively.

Getting Started
Declaring Script Objects

Each script object in the manifest can contain the following fields:
• name
Required – The name for this action script. After Turbonomic discovers your scripts, it displays this name as a
Orchestration Workflow choice in the user interface for creating orchestration policies.
• description
Optional – A description of the script. The Turbonomic user interface does not display this description.
• scriptPath
Required – The path to the executable for this entry. You can give an absolute path, or a path that is relative to the
location of the Scripts Manifest. The Action Script User that you set up for the Action Script server must have read
and execute privileges for the executable file.
• entityType
Required – The type of entity this script responds to. Can be one of:
◦ Switch
◦ VIRTUAL_DATACENTER
◦ STORAGE
◦ DATABASE_SERVER
◦ WEB_SERVER
◦ VIRTUAL_MACHINE
◦ DISK_ARRAY
◦ DATA_CENTER
◦ PHYSICAL_MACHINE
◦ CHASSIS
◦ STORAGE_CONTROLLER
◦ IO_MODULE
◦ APPLICATION_SERVER
◦ APPLICATION
◦ CONTAINeR
◦ CONTAINER_POD
◦ LOGICAL_POOL
◦ STORAGE_VOLUME
◦ DPOD
◦ VPOD
◦ DATABASE
◦ LOAD_BALANCER
To configure the same script to respond to actions on different entity types, declare separate entries for that script,
one for each entity type.
• actionType
Required – The type of action this script responds to. Note that different entity types can support different actions.
Can be one of:
◦ START

Getting Started
◦ MOVE
◦ SUSPEND
◦ TERMINATE
◦ SPAWN
◦ ADD_PROVIDER
◦ CHANGE
◦ REMOVE_PROVIDER
◦ PROVISION
◦ RECONFIGURE
◦ RIGHT_SIZE
◦ RESIZE_CAPACITY
◦ WARN
◦ RECONFIGURE_THRESHOD
◦ DELETE
◦ RESERVE_ON_PM
◦ RESERVE_ON_DS
• actionPhase
Required – Where in the life cycle of an action that you want your script to execute.
Can be one of:
◦ PRE
For an action that has been accepted, or an AUTOMATED action before it executes, this state is a preparation
phase where your script can execute just before the action itself executes.
Run your script to set up conditions just before the action executes.
◦ REPLACE
For action execution, your script executes in stead of the execution that Turbonomic would perform.
Run your script as a replacement for the Turbonomic action.
◦ POST
The action has completed execution, either in a SUCCEEDED, FAILING, or FAILED state.
FAILING means that the status was checked after the action execution fails, but before the POST script has
finished execution.
Run your script after the action has completed execution.
• timeLimitSeconds
Optional – How long to run the action before assuming a timeout. When execution exceeds this limit, Turbonomic
sends a SIGTERM to terminate the execution of the process.
If you do not provide a value, Turbonomic assumes a limit of 30 minutes (1800 seconds).

Getting Started
Constraints and Other Settings

Turbonomic collects metrics to drive the analysis that it uses when it calculates actions for your environment. It
compares current utilization and demand against allocated capacities for resources, so it can recommend actions that
keep your environment in optimal running condition.
Action policies include constraints and other settings that you can make to adjust the analysis that Turbonomic
performs. For example, you can set different levels of overprovisioning for host or VM resources, and Turbonomic will
consider that as a factor when deciding on actions.
Turbonomic ships with default policies that show all the constraints and settings you can make for each policy. These
take effect until you create and apply a policy with different values. For the steps in creating a new policy, see Creating
Scoped Automation Policies (on page 104). You can edit the defaults if you want to change analysis globally.

Entity Types - Applications
The supply chain strongly emphasizes our application-driven approach to managing your infrastructure. By showing
the entity types that make up your applications at the top of the hierarchy, it is easier for you to see the health of your
environment and evaluate actions from the perspective that matters – Application Performance.

Business Application
A Business Application is a logical grouping of Business Transactions (on page 131), Services (on page 134),
Application Components (on page 140), and other elements of the application model that work together to compose
a complete application as end users would view it. For example, a mobile banking app is a Business Application with
a Business Transaction that facilitates payments, a Service within the Business Transaction that records payment
information, and underlying Application Components (such as JVMs) that enable the Service to perform its functions.


You can monitor overall performance, make resourcing decisions, and set policies in the context of your Business
Applications.
NOTE:
The supply chain also models Turbonomic as a Business Application so you can monitor the performance of the
product. For details, see Turbonomic as a Business Application (on page 129).
Synopsis
Synopsis
Budget: Business Applications have unlimited budget.
Provides: The complete application to end users
Consumes from: Business Transactions, Services, Application Components, Database Servers, and the
underlying nodes
Discovery: Turbonomic discovers the following:
• AppDynamics Business Applications
• Dynatrace Applications
If you do not have these targets, you can create your own Business Applications using the
Application Topology feature. For details, see Application Topology (on page 145).
Monitored Resources
Turbonomic monitors the following:
• Response Time
The utilization of the server’s allocated response time
Measured in Milliseconds (ms)
• Transactions
The utilization of the allocated transactions per second for the given entity
Measured in transactions per second

The Response Time and Transaction charts for a Business Application show average and peak/low values over time. You
can gauge performance against the given SLOs. By default, Turbonomic estimates SLOs based on monitored values. You
can set your own SLO values in policies.
Actions
None
Turbonomic does not recommend actions for a Business Application, but it does recommend actions for the underlying
Application Components and infrastructure. The Pending Actions chart for a Business Application lists these actions,
thus providing visibility into the risks that have a direct impact on the Business Application's performance.
Turbonomic as a Business Application

The supply chain models Turbonomic as a Business Application. When you scope to the Turbonomic entity, you can see
the Business Transactions, Services, and Application Components that make up the product, the underlying nodes (such
as the product's VM and database server), as well as performance metrics.
NOTE:
After deploying Turbonomic, it might take at least ten minutes before it appears in the supply chain as a Business
Application.


Key Business Transactions, Services, and Application Components work together to:
• Analyze your environment continuously
• Recommend actions to assure performance and reduce cloud costs
• Keep the supply chain up-to-date
• Run plans against the current environment
The Pending Actions chart at every level of the application model shows actions for the underlying Application
Components and nodes, thus providing visibility into the risks that have a direct impact on the product's performance.
Business Application Policies

Turbonomic ships with default settings that we believe will give you the best results from our analysis. These settings
are specified in a set of default automation policies for each type of entity in your environment. For some scopes of your
environment, you might want to change these settings. For example, you might want to change action automation or
constraints for that scope. You can create policies that override the defaults for the scopes you specify.

Action Automation and Orchestration

None
Turbonomic does not recommend actions for a Business Application, but it does recommend actions for the underlying
Application Components and infrastructure. The Pending Actions chart for a Business Application lists these actions,
thus providing visibility into the risks that have a direct impact on the Business Application's performance.
Transaction SLO
Enable this SLO if you are monitoring performance through your Business Applications.
Attribute Default Setting/Value

Enable Transaction SLO Off
Turbonomic estimates SLO based on monitored values.
Transaction SLO None
If you enable SLO, Turbonomic uses the default value of
10. You can change this to a different value.
Transaction SLO determines the upper limit for acceptable transactions per second. When the number of transactions
reaches the given value, Turbonomic sets the risk index to 100%.
Response Time SLO

Enable this SLO if you are monitoring performance through your Business Applications.

Enable Response Time SLO Off
Response Time SLO [ms] None
Response time SLO determines the upper limit for acceptable response time (in milliseconds). If response time reaches
the given value, Turbonomic sets the risk index to 100%.
Business Transaction
A Business Transaction represents a capability within your Business Application that fulfills a response to a user-initiated
request. Its performance directly impacts user experience. You can monitor performance as experienced by your end
users in the context of Business Transactions. For more information, see Business Application (on page 127).

Synopsis

Synopsis
Budget: Business Transactions have unlimited budget.
Provides: Response time and transactions to Business Applications
Consumes from: Services (on page 134), Application Components (on page 140), Database Servers,
and the underlying nodes
• AppDynamics Business Transactions
• NewRelic Key Transactions
If you do not have these targets, you can create your own Business Transactions using the
Monitored Resources
• Response Time


• Transactions
The utilization of the allocated transactions per second for the given business transaction
The Response Time and Transaction charts for a Business Transaction show average and peak/low values over time. You
can gauge performance against the given SLOs. By default, Turbonomic estimates SLOs based on monitored values. You
can set your own SLO values in policies.
Actions
None
Turbonomic does not recommend actions for a Business Transaction, but it does recommend actions for the underlying
Application Components and infrastructure. The Pending Actions chart for a Business Transaction lists these actions,
thus providing visibility into the risks that have a direct impact on the Business Transaction's performance.
Business Transaction Policies


None
Turbonomic does not recommend actions for a Business Transaction, but it does recommend actions for the underlying
Application Components and infrastructure. The Pending Actions chart for a Business Transaction lists these actions,
thus providing visibility into the risks that have a direct impact on the Business Transaction's performance.
Transaction SLO
Enable this SLO if you are monitoring performance through your Business Transactions.

Response Time SLO

Enable this SLO if you are monitoring performance through your Business Transactions.


Service
A Service in the supply chain represents one or several Application Components that perform a defined, measurable
function as part of an internal or user-initiated request. Its performance is key to understanding application
performance, but only indirectly impacts user experience. You can measure performance as experienced internal to the
Business Application in the context of Services.
For more information, see Application Component (on page 140) and Business Application (on page 127).
Synopsis

Synopsis
Budget: Services have unlimited budget.
Provides: Response time and transactions to Business Transactions (on page 131) and Business
Applications

Synopsis
Consumes from: Application Components, Database Servers, and the underlying nodes
Discovery: For APM targets, Turbonomic discovers the following:
• AppDynamics Tiers
• Dynatrace Services
• Instana Services
• NewRelic APM Applications / NewRelic Services (New Relic ONE)
NOTE:
If you do not have an APM target, you can create your own Services using the
For Kubernetes, Turbonomic discovers Kubernetes Services through the Kubeturbo pod
that you have deployed in your environment.
Monitored Resources
• Response Time
Response time (in milliseconds) for the given service
For Kubernetes, this is the desired weighted average response time of all Application Component replicas
associated with a Service
• Transactions
Transactions per second for the given service
For Kubernetes, the maximum number of transactions per second that each Application Component replica can
handle.
The Response Time and Transaction charts for a Service show average and peak/low values over time. You can gauge
performance against the given SLOs. By default, Turbonomic estimates SLOs based on monitored values. You can set
your own SLO values in policies.
Actions for non-Kubernetes Services

Turbonomic does not recommend actions for non-Kubernetes Services, but it does recommend actions for the
underlying Application Components and nodes. The Pending Actions chart for Services list these actions, thus providing
visibility into the risks that have a direct impact on their performance.
Actions for Kubernetes Services

For horizontally scalable Kubernetes Services that collect performance metrics (or KPIs) for applications, Turbonomic can
dynamically adjust the number of pod replicas that back those Services to help you meet SLOs (Service Level Objectives)
for your applications.
For example, when current response time for an application is in direct violation of SLO, Turbonomic will recommend
provisioning pods to improve response time. When you examine a pending action to provision pods, you will see
Response Time Congestion as the reason for the action.


If applications can meet response time SLOs using less resources, Turbonomic will recommend suspending pods to
improve infrastructure efficiency.

Turbonomic generates these actions under the following conditions:
• Services are discovered by the Kubeturbo pod that you have deployed in your environment.
• Services collect performance metrics via Instana or DIF.
• You have created policies (on page 139) for the Services.


In those Service policies, be sure to:
◦ Turn on horizontal scaling (up and/or down).
◦ Enable Response Time and/or Transaction SLO, and then specify your desired SLO values.
■ Response Time SLO
This is the desired weighted average response time of all Application Component replicas associated with a
Service.
■ Transaction SLO
This is the maximum number of transactions per second that each Application Component replica can
handle.
NOTE:
If you specified SLOs but turned off horizontal scaling in the policy, no actions are generated but SLO values will
continue to display in the Response Time and Transaction charts for Services, for your reference. This allows you
to gauge performance against those SLOs.
Propagation of Service Policy Settings
Settings in a Service policy propagate to the associated pods and Application Components to establish their relationship
and provide context.
For example, assume you created a group of Services called AH-Service_GP and then applied the Service policy Ah-
Test_HScale to that group. When you set the scope to this group, Ah-Test_HScale displays as a policy in the entity
views for Services, Application Components, and Container Pods. You can click the policy name in any view to see or
modify the policy settings.


To prevent conflicts, SLO values in Service policies override any SLOs set in Application Components. In addition, the
Response Time and Transaction charts for Application Components show SLOs specified in the Service policy.
Action Automation Considerations
We recommend action automation under the following circumstances:
• Your applications run as a set of Kubernetes services backed by a deployment.
• Services deploy via a namespace without quotas.
• Newly provisioned pods are placed on nodes with the same CPU speed.
• You do not have an upstream Kubernetes HPA (Horizontal Pod Autoscaling) enabled for the same workload.
We recommend that you disable automation and manually execute actions under the following circumstances:
• Services deploy via a namespace with quotas.
• Newly created pods are scheduled on nodes with different CPU speeds.
• Services have non-resource constraints that could result in newly provisioned pods staying in the pending state.
Service Policies

Policies for Non-Kubernetes Services

• Action Automation and Orchestration
Turbonomic does not recommend actions for non-Kubernetes Services, but it does recommend actions for the
underlying Application Components and nodes. The Pending Actions chart for Services list these actions, thus
providing visibility into the risks that have a direct impact on their performance.
• Transaction SLO
Enable this SLO if you are monitoring performance through Services.

If you enable SLO, Turbonomic uses the default value
of 10. You can change this to a different value.
Transaction SLO determines the upper limit for acceptable transactions per second. When the number of
transactions reaches the given value, Turbonomic sets the risk index to 100%.
• Response Time SLO
Enable this SLO if you are monitoring performance through Services.

Response time SLO determines the upper limit for acceptable response time (in milliseconds). If response time
Policies for Kubernetes Services

• Action Automation and Orchestration
For horizontally scalable Kubernetes Services that collect performance metrics (or KPIs) for applications,
Turbonomic can dynamically adjust the number of pod replicas that back those Services to help you meet SLOs
(Service Level Objectives) for your applications.
To generate these actions, you must turn on horizontal scaling (up and/or down) and specify your desired SLOs in a
Service policy.
For details about these actions and the environments that are suitable for automating these actions, see Actions for
Kubernetes Services (on page 135).

Horizontal Scale Down Off (Disabled)


Horizontal Scale Up Off (Disabled)
• Transaction SLO
This is the maximum number of transactions per second that each Application Component replica can handle.

• Response Time SLO
This is the desired weighted average response time of all Application Component replicas associated with a Service.

• Minimum and Maximum Replicas
You can adjust the default values based on the characteristics of your applications or if you are planning for capacity.
The maximum value also acts as a safeguard against overprovisioning of replicas.

Minimum Replicas 1
Maximum Replicas 10000
Application Component
An Application Component is a software component, application code, or a unit of processing within a Service (on page
134) that consumes resources to enable it to perform its function for the Business Application (on page 127). For
example, Apache Tomcat is a Java Servlet container that hosts a range of Java applications on the web.
Turbonomic can recommend actions to adjust the amount of resources available to Application Components.

Synopsis

Synopsis
Budget: Application Components have unlimited budget.
Provides: • Response Time and Transactions to Services, Business Transactions (on page 131),
and Business Applications
• Response Time, Transactions, Heap, Remaining GC Capacity, and Threads to end
users
Consumes: Compute resources from nodes
• Apache Tomcat
• AppDynamics Nodes
• Dynatrace Processes
• NewRelic APM Application Instances
• Application Insights Components
• SNMP
• WMI
• Prometurbo or Data Ingestion Framework metrics for Kubernetes environments
Monitored Resources
The exact resources monitored will differ based on application type. This list includes all resources you may see.
• Virtual CPU (VCPU)
The utilization of the VCPU allocated to the hosting VM
Measured in Megahertz (MHz)
• Virtual Memory (VMem)

The utilization of the VMem allocated to the hosting VM

Measured in Kilobytes (KB)
• Transactions
Turbonomic discovers key transactions – transactions that the user marked as key to the application
• Heap
The utilization of the application server’s heap
• Response Time
• Connections
The utilization of the connection capacity. Only applicable to database servers
Measured in Connections
• Remaining Garbage Collection Capacity
The percentage of server uptime spent not performing garbage collection
Measured in uptime (%)
• Threads
The utilization of the server’s thread capacity
Measured in number of Threads
The charts for an Application Component show average and peak/low values over time. You can gauge performance
against the given SLOs. By default, Turbonomic does not enable SLOs in the default policy for Application Components. It
estimates SLOs based on monitored values, but does not use these values in its analysis.
NOTE:
In Kubernetes environments, SLOs defined in a Service policy override any SLOs set in the associated Application
Components to prevent conflicts. In addition, the Response Time and Transaction charts for Application Components
will show SLOs specified in the Service policy. For more information, see Actions for Kubernetes Services (on page
135).
Actions
Resize
Resize the following resources to maintain performance:
• Thread Pool
• Connections
• Heap
Turbonomic will recommend Heap resize actions if the Application Component sells Heap and Remaining Garbage
Collection (GC) Capacity, and the underlying VM or container sells VMem.

NOTE:
The resources that Turbonomic can resize depend on the processes that it discovers from your Applications and
Databases targets. In the Target Configuration Guide, refer to the topic for a specific target to see a list of resources
that can be resized.
Application Component Policies


For details about Application Component actions, see Application Component Actions. (on page 142)
Action Default Mode

Resize heap (up or down) Recommend
Resize thread pool (up or down) Recommend
Resize connections (up or down) Recommend
You can use Action Scripts (on page 119) for action orchestration. Third-party orchestrators (such as ServiceNow) are not
supported.
Transaction SLO
Enable this SLO to monitor the performance of your Application Components.
NOTE:
135).


Response Time SLO

Enable this SLO to monitor the performance of your Application Components.
NOTE:
135).

Heap Utilization
The Heap utilization that you set here specifies the percentage of the existing capacity that Turbonomic will consider
to be 100% of capacity. For example, a value of 80 means that Turbonomic considers 80% utilization to be 100% of
capacity.

Heap Utilization (%) 80
Turbonomic uses Heap utilization and Remaining GC Capacity (the percentage of CPU time not spent on garbage
collection) when making scaling decisions. Assume Heap utilization is at 80%, which is 100% of capacity. However, if
Remaining GC Capacity is at least 90% (in other words, CPU time spent on garbage collection is only 10% or less), an 80%
Heap utilization does not indicate a shortage after all. As a result, Turbonomic will not recommend Heap scaling.
If Heap utilization is low and Remaining GC Capacity is high, Turbonomic will recommend resizing down Heap. If the
opposite is true, then Turbonomic will recommend resizing up Heap.
Heap Scaling Increment

This increment specifies how many units to add or subtract when scaling Heap for an application component.

Heap Scaling Increment (MB) 128
Do not set the increment value to be lower than what is necessary for the Application Component to operate. If the
increment is too low, then it’s possible there would be insufficient Heap for the Application Component to operate.
When reducing allocation, Turbonomic will not leave an Application Component with less than the increment value. For
example, if you use the default 128, then Turbonomic cannot reduce the Heap to less than 128 MB.

Application Topology
Turbonomic gives you the ability to create your own Business Applications (on page 127), Business Transactions (on
page 131), and Services (on page 134) without the need to ingest additional application data into the platform.
This is especially useful in environments where there are gaps in the application stack shown in the Turbonomic supply
chain. For example, in the absence of an application monitoring target such as AppDynamics or Dynatrace, you will not
see Business Applications in your supply chain. User-created application entities address those gaps.
When you create a new application entity, you identify interrelated application entities and nodes in your existing
environment for which you want to measure performance, so Turbonomic can link them in a supply chain and represent
them as a unified group. You can monitor overall performance for the group in the context of the new application entity,
and drill down to the individual entities and nodes for finer details.

Turbonomic does not perform analysis on any user-created application entity, but it aggregates the underlying risks the
same way it does for auto-discovered entities.
After you create an application entity, Turbonomic counts it in the global supply chain and adds it to the relevant charts
(for example, if you created a new Service that has performance risks, you might see it listed in the Top Services chart).
Drill down to the newly created entity to monitor its performance. You can also use Search to find the application entity
and set it as your scope.
Creating Application Entities



2. Choose Application Topology.

3. Click New Application Topology and then choose Automatic or Manual.
• Automatic
Create a new application entity composed of tagged entities. For example, create a new Business Application
composed of VMs with the "Production" tag.
• Manual
Create a new application entity composed of a specific set of application entities and nodes.
4. Select the application entity type that you want to create.
5. If you chose Automatic:
Type an entity name prefix to help you easily identify the application entities that Turbonomic will create for you,
and then specify the tags that will identify the underlying entities.
If you chose Manual:
Give the application entity a name and then add the underlying application entities and nodes.
6. Click Create Definition.

Entity Types - Container Platform
Turbonomic discovers and monitors the entities that make up your container platform, and recommends actions to
assure performance for the applications that consume resources from these entities.

For a Cloud Native environment, Turbonomic discovers:
Entity Type Kubernetes Object or Reference Notes

Service (on page 134) Service A logical set of pods that represents
a given application. In Kubernetes,


the Service exposes a single entry
point for the application process.
While the Pods that comprise the
service are ephemeral, the service
is persistant. The Service entity
also gives historical tracking of
the number of replicas that run to
support the Service.
Container (on page 150) Container The individual containers that deploy
in your environment. Because the
container instances that support a
service can change at any time, these
are considered ephemeral.
Container Pod (on page 162) Pod These are the smallest deployable
units of computing that you can
create and manage in Kubernetes.
One Container Pod can contain
multiple Container entities. These
are also considered ephemeral.
Container Spec (on page 156) A container's Spec Persistent entities that collect
containers with like properties. In
Kubernetes the container's Spec
includes the size specifications
ot limits and requests. In the
Turbonomic supply chain, the count
of replicas maps to the count of
Container entities that a Container
Spec encompasses. In Turbonomic,
the persistent Container Spec
maintains historical data for its
ephemeral containers, and all the
replicas that have run in the past.
Workload Controller (on page Controller A persistent entity that maps to
160) the different controllers in your
Kubernetes environment, such
as Deployments or Stateful Sets.
A single Workload Controller can
contain one or more Container Spec
entities, and it can be related to one
or more running replica pods.
In the Supply Chain, the Workload
Controller exposes the impact of
Namespace quotas on Container
Spec resize actions. The Workload
Controller aggregates resize actions
for the containers that are in its


supply chain. In this way, a single
action on a Workload Controller
can encompass multiple Container
actions.
Namespace (on page 166) Namespace A logical group of workloads each
namespace must be unique within
a given Container Cluster. You can
specify Resource Quotas for a
Namespace, which limit compute
resource capacity available to its
workloads. Turbonomic will block
execution of resize actions that
would exceed Namespace quotas,
and identify the quota increase you
need to accomodate the workload
resize.
For OpenShift, a Namespace is
equivalent to a Project.
Container Cluster (on page 170) Cluster A collection of VMs (referred to as
Nodes in Kubernetes). The Container
Cluster scope aggregates actions
so you can see cluster health in
one view. THis gives you an idea of
cluster health from the perspective
of your workloads.
Virtual Machine (on page 177) Node The machines that provide compute
resources to workloads. Turbonomic
recommends actions on VMs to
manage resources for the cluster.
Actions to move pods horizontally
scale workloads and nodes.
Turbonomic recommends these
actions to prevent node congestion,
or to exploit opportunities to
consolidate resources.
Turbonomic can discover node
roles and Master Nodes. It creates
policies to keep nodes of the same
role on unique host or Availability
Zone providers, and policies to
disable suspension of Master Nodes.
Turbonomic also discovers and
displays Node Pools, and OpenShift
Machine Sets.


Volume (on page 205) PV If a Container Pod is attached to a
volume, Turbonomic discovers it as
a Persistent Volume (PV), and shows
which Pods are connected to the PV.
This section describes the Turbonomic entities that are unique to Cloud Native infrastructures. You can find descriptions
of Service, Virtual Machie, and Volume entities in other sections of the User Guide.
Container
An application container is a standalone, executable image of software that includes components to host an application.
Synopsis

Synopsis
Budget: A container obtains its budget by selling resources to the hosted application.

Synopsis
Provides: Resources for the applications to use:
• Virtual CPU
• Virtual Memory
Consumes: Resources from container pods, virtual machines, and virtual datacenters.
Discovered through: For Kubernetes, Turbonomic discovers containers through the Kubeturbo pod that you
have deployed in your environment.
For Dynatrace and AppDynamics hosted on containers:
• Dynatrace: Turbonomic discovers containers through the metadata of processes.
• AppDynamics: Turbonomic discovers containers through container objects.
Monitored Resources
Turbonomic monitors the following resources for a container:
VMem
The virtual memory utilized by the container against the memory limit (if no limit is set, then node
capacity is used). Measured in Megabytes (MB)
VMem Request
If applicable, the virtual memory utilized by the container against the memory request. Measured in
Megabytes (MB)
VCPU
The virtual CPU utilized by the container against the CPU limit (if no limit is set, then node capacity is
used). Measured in millicores (mCores)
VCPU Request
If applicable, the virtual CPU utilized by the container against the CPU request. Measured in millicores
(mCores)
VCPU Throttling
The throttling of container vCPU that could impact response time, expressed as the percentage of
throttling for all containers associated with a Container Spec. In the Capacity and Usage chart for
containers, used and utilization values reflect the actual throttling percentage, while capacity value is
always 100%.
Actions
Resize
Resize containers to assure optimal utilization of resources. By default, containers resize consistently, which allows all
replicas of the same container for the same workload type to resize any resource consistently.
For vCPU limit resizes, Turbonomic will recommend a resize up action, even if utilization percentile is low, to address
slow response times associated with vCPU throttling. Especially for sudden throttling spikes, it will persist the related
resize actions so you can evaluate these actions even after the spikes have gone away, and then execute them to prevent
spikes from re-occurring. As throttling drops, Turbonomic will not recommend a resize down action right away, as this
could result in subsequent back-and-forth upsize and downsize recommendations. Instead, it evaluates past throttling

to decide when a resize down action is finally safe to execute. To ensure the timeliness of these actions and arrive at the
optimal resize values to recommend, Turbonomic calculates fast and slow moving throttling averages, and then displays
smoothed and daily averages in charts.
Action Visibility, Merging, and Execution

Turbonomic shows and executes container resize actions via Workload Controllers (on page 160). You will not see
actions when you set the scope to containers.
Resize
Actions also propagate to application entities and the underlying container infrastructure to show the impact of these
actions on the health of your applications and container environment.
Executing several container resize actions can be very disruptive since pods need to restart with each resize. For replicas
of the container scale group(s) related to a single Workload Controller, Turbonomic consolidates resize actions into
one merged action to minimize disruptions. When a merged action has been executed (via the associated Workload
Controller), all resizes for all related container specifications will be changed at the same time, and pods will restart
once.
After you set the scope to Workload Controllers, go to the Pending Actions chart and then click Show All to see the full
list of resize actions that you can execute. This list includes individual and merged actions. You can filter the list to focus
on specific actions, such as actions to address resource congestion or vCPU throttling.

By default, container resize actions are set in Manual mode at the Workload Controller level. This means that
Turbonomic will not execute any action automatically, and you can manually select the actions that you want to execute.
If you prefer to execute actions outside Turbonomic, create Workload Controller policies and set the resize action mode
to Recommend. To automate actions, create Workload Controller policies and set the resize action mode to Automatic.
For each action, click DETAILS and expand the Details section to view time series charts that explain the reason for the
action. These charts highlight utilization percentiles and smoothed throttling averages for a given observation period.
Turbonomic uses percentile calculations to make accurate resize decisions.


These charts also:
• Plot daily average percentiles and throttling, for your reference.
• Show projected percentiles after you execute the action. If you have previously executed resize actions on the same
Workload Controller, the charts show the resulting improvements in daily average utilization.
Put together, these charts allow you to easily recognize trends that drive Turbonomic's resize recommendations.
NOTE:
You can set scaling constraints in Container Spec policies to refine the percentile calculations. For details, see
Aggressiveness and Observation Periods (on page 158).
Tuned Scaling for Containers

Turbonomic can automate resizes if the resize values fall within a normal range, and then post more conservative
actions when resize values fall outside the range. To do this, you would set specific action modes and tuned scaling
values in policies.
For example, consider resizing vMem limits. As memory demand increases, Turbonomic can automatically execute
vMem limit resizes that fall within the normal range. If the Container Spec requests memory beyond the normal range,
Turbonomic will either ignore the action or post it for you to review, depending on the tuned scaling settings that you
configured.
Assume the following tuned scaling settings in policies:


• The Operational Constraints settings in the Container Spec policy specify 100 MB to 500 MB as the normal range.
• With the Resize action mode in the Workload Controller policy set to Automatic, Turbonomic will automate resize
up actions that are below the max threshold and resize down actions that are above the min threshold.
NOTE:
If the action mode is Recommend, Turbonomic will post the actions for you to review. You can only execute these
actions outside Turbonomic.
• In the Container Spec policy, since the action mode for vMem Limit Resize Above Max and vMem Limit Resize
Below Min is set to Disabled, Turbonomic will not generate resize actions that fall outside the normal range.
• Since vMEM increment constant is not defined in the Container Spec policy, Turbonomic uses the default value of
128 MB.
With these two policies in effect:
• If a Container Spec with 200 MB of vMEM limit needs to resize to 328 MB, Turbonomic automatically resizes to 328
MB.
• If a Container Spec with 200 MB of vMEM limit needs to resize to 72 MB, Turbonomic does not generate the action.
vMEM limit remains at 200 MB.
NOTE:
Action policies include scope to determine which entities will be affected by the given policy. It's possible for two or
more policies to affect the same entities. As is true for other policy settings, Turbonomic uses the most conservative
settings for the affected entities.
For tuned scaling, the effective action mode will be the most conservative, and the effective tuned scaling range will
be the narrowest range (the lowest Max and highest Min) out of the multiple policies that affect the given entities.
For more information, see Policy Scope (on page 112).

Container Policies

Resize
Resize
Default Mode
Action
Container Workload Controller
Resize N/A Manual (automatable)
For details, see Container Actions (on page 151).
Consistent Resizing
• For groups in scoped policies:

Consistent Resizing Off
When you create a policy for a group of containers 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, assume container A shows top utilization of CPU, and container B shows top utilization of memory.
Container resize actions would result in all the containers with CPU capacity to satisfy container A, and memory
capacity to satisfy container B.
For an affected resize, the Actions List shows individual resize actions for each of the containers in the group. If you
automate resizes, Turbonomic executes each resize individually in a way that avoids disruption to your workloads.
• For auto-discovered groups:
Turbonomic discovers Kubernetes groups such as Deployments, ReplicationControllers, ReplicaSets, DaemonSets,
and StatefulSets, and automatically enables Consistent Resizing in a read-only policy for each group. If you do not
need to resize all the members consistently, create another policy for the group and turn off Consistent Resizing.

Container Spec
A Container Spec is a shared definition for all ephemeral container replicas. It is a persistent entity that retains the
historical utilization data of containers, which Turbonomic leverages to make container sizing decisions. Utilization data
includes:
• vCPU used by all container replicas
• vCPU request capacity (if applicable)
• vMem used by all container replicas
• vMem request capacity (if applicable)
Synopsis

Synopsis
Budget: N/A
Provides: N/A
Consumes: N/A
Discovered through: Kubeturbo Mediation Pod
Monitored Resources
When you view the resources for a Container Spec, you will see the historical usage of any instance of a container
running for the workload (assuming the workload name stays the same). The chart shows the trend of usage even with
restarts or redeployments.
Actions
None

A Container Spec retains the historical utilization data of ephemeral containers. Turbonomic uses this data to make
accurate container resize decisions, but does not recommend actions for the Container Spec itself.
NOTE:
To view container resize actions, set the scope to the Workload Controller for related containers. Go to the Pending
Actions chart and click Show All to see the full list. For more information about container actions, see Container
Actions (on page 151).
Container Spec Policies


The following settings affect tuned scaling:
Setting Default Mode

vCPU Request Resize Below Min Recommend
vCPU Limit Resize Above Max Recommend
vCPU Limit Resize Below Min Recommend
vMem Request Resize Below Min Recommend
vMem Limit Resize Above Max Recommend
vMem Limit Resize Below Min Recommend
The default mode of Recommend means that when resize values in actions fall outside the normal range (as defined in
Container Spec policies), Turbonomic will post the actions for you to review. You can only execute these actions outside
Turbonomic. If you set the action mode to Disabled, Turbonomic will not generate the actions.
For an overview of tuned scaling, see Tuned Scaling for Containers (on page 153).
Resize Thresholds
Turbonomic uses resize thresholds as operational constraints to set up tuned scaling for Container Specs. For an
overview of tuned scaling, see Tuned Scaling for Containers (on page 153).

VCPU Request Resize Min Threshold (mCores) 10
VCPU Limit Resize Min Threshold (mCores) 500
VCPU Limit Resize Max Threshold (mCores) 64000
VMEM Request Resize Min Threshold (MB) 10
VMEM Resize Min Threshold (MB) 10


VMEM Resize Max Threshold (MB) 1048576
Increment Constants
Turbonomic recommends changes in terms of the specified resize increments.

Increment constant for VCPU Limit and VCPU Request 100
(mCores)
Increment constant for VMEM Limit and VMEM Request 128
(MB)
For example, assume the vCPU request increment is 100 mCores and you have requested 800 mCores for a container.
Turbonomic could recommend to reduce the request by 100, down to 700 mCores.
For vMem, you should not set the increment value to be lower than what is necessary for the container to operate. If
the vMem increment is too low, then it’s possible that Turbonomic would allocate insufficient vMem. For a container
that is underutilized, Turbonomic will reduce vMem allocation by the increment amount, but it will not leave a container
with zero vMem. For example, if you set this to 128, then Turbonomic cannot reduce the vMem to less than 128 MB.
Rate of Resize
(For the default policy only)

Rate of Resize High
When resizing resources for a container, Turbonomic calculates the optimal values for vMem and vCPU. 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, as follows:
• Low
Change the value by one increment, only. For example, if the resize action calls for increasing vMem, and the
increment is set at 128, Turbonomic increases vMem by 128 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).
Aggressiveness and Observation Periods

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


Aggressiveness 99th Percentile
When evaluating vCPU and vMEM 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 99th percentile. The percentile utilization
is the highest value that 99% 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. This is important in the cloud, so that
analysis can better exploit the elasticity of the cloud. 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 container. Without using a percentile,
Turbonomic never resizes below the recognized peak utilization. For most containers there are moments when
peak CPU reaches high levels. Assume utilization for a container peaked at 100% just once. Without the benefit of a
percentile, Turbonomic will not reduce allocated CPU for that container.
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 99% of the samples CPU never exceeded 50%. If
you set Aggressiveness to 99th Percentile, then Turbonomic can see this as an opportunity to reduce CPU allocation
for the container.
In summary, a percentile evaluates the sustained resource utilization, and ignores bursts that occurred for a small
portion of the samples. You can think of this as aggressiveness of resizing, as follows:
◦ 100th Percentile – The least aggressive, recommended for critical workloads that need maximum guaranteed
performance at all times.
◦ 99th Percentile (Default) – The recommended setting to achieve maximum performance and savings.
◦ 90th Percentile – Most aggressive, recommended for non-production workloads that can stand higher resource
utilization.
• Max Observation Period

Max Observation Period Last 30 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.)
A shorter period means there are fewer data points to account for when Turbonomic calculates utilization
percentiles. This results in more dynamic, elastic resizing, while a longer period results in more stable or less elastic
resizing. You can make the following settings:
◦ Less Elastic – Last 90 Days
◦ Recommended – Last 30 Days
◦ More Elastic – Last 7 Days
• Min Observation Period

Min Observation Period 1 Day

This setting ensures historical data for a minimum number of days before Turbonomic will generate an action based
on the percentile set in Aggressiveness. This ensures a minimum set of data points before it generates the action.
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
◦ Recommended – 1 Day
◦ Less Elastic – 3 or 7 Days
Workload Controller
A Workload Controller is a Kubernetes controller that watches the state of your pods and then requests changes where
needed. You can execute container resize actions when you set the scope to a Workload Controller.
Synopsis

Synopsis
Budget: N/A
Provides: N/A
Consumes: N/A

Monitored Resources
Turbonomic does not monitor resources for Workload Controllers.
Actions
None
A Workload Controller executes container actions. When you set the scope to a Workload Controller and view the
actions list, the actions apply to containers. Turbonomic does not recommend actions for the Workload Controller itself.
NOTE:
Turbonomic uses namespace or organization/space quotas as constraints when making resize decisions. The Workload
Controller aggregates container actions. If those container resizes exceed current namespace quotas, Turbonomic
blocks execution of container resize actions until the namespace quotas are sufficient. For more information about
namespace quotas, see Resource Quotas (on page 167).
For resize actions on a Workload Controller, the actions details include descriptions of the affected Container Spec
entities, and how the resources will change for each. If the resize exceeds current namespace quotas, then Turbonomic
blocks the Wokload Controller action. The action details list the Namespace actions that block execution of this resize in
the Related Actions list.

For more information about container actions, see Container Actions (on page 151).
Workload Controller Policies



Resize
Default Mode
Action
Container Workload Controller
Resize N/A Manual (automatable)
For details, see Container Actions (on page 151).

Executing several container resize actions can be very disruptive since pods need to restart with each resize. For replicas
of the container scale group(s) related to a single Workload Controller, Turbonomic consolidates resize actions into
one merged action to minimize disruptions. When a merged action has been executed (via the associated Workload
Controller), all resizes for all related container specifications will be changed at the same time, and pods will restart
once.
Action orchestration is currently not supported.
Container Pod
A ContainerPod is a Kubernetes pod, which is a group of one or more containers with shared storage or network
resources and a specification for how to run the containers together.

Synopsis

Synopsis
Budget: A container pod obtains its budget by selling resources to containers.
Provides: Resources for containers to use:
• Virtual CPU
• Virtual Memory
Consumes: Resources from virtual machines and namespaces.
Discovered through: Turbonomic discovers Kubernetes pods through the Kubeturbo pod that you have
deployed in your environment.
Monitored Resources
Turbonomic monitors the following resources for a container pod:
VMem
The virtual memory utilized by the pod against the node physical capacity. Measured in Megabytes (MB)
VCPU

The virtual CPU utilized by the pod against the node physical capacity. Measured in millicores (mCores)
VMem Request
The virtual memory request allocated by the pod against the node allocatable capacity. Measured in
Megabytes (MB)
VCPU Request
The virtual CPU request allocated by the pod against the node allocatable capacity. Measured in
millicores (mCores)
VMem Request Quota
If applicable, The amount of virtual memory request the pod has allocated against the namespace quota.
Measured in Megabytes (MB)
VCPU Request Quota
If applicable, The amount of virtual CPU request the pod has allocated against the namespace quota.
Measured in millicores (mCores)
VMem Limit Quota
If applicable, The amount of virtual memory limit the pod has allocated against the namespace quota.
VCPU Limit Quota
If applicable, The amount of virtual CPU limit the pod has allocated against the namespace quota.
Measured in millicores (mCores)
Move Actions
Move a pod between nodes (VMs) to address performance issues or improve infrastructure efficiency. For example, if
a particular node is congested for CPU, you can move pods to a node with sufficient capacity. If a node is underutilized
and is a candidate for suspension, you must first move the pods before you can safely suspend the node.
The following items affect the Move actions that Turbonomic recommends for pods:
• Constraints
Turbonomic respects the following constraints when making placement decisions for pods:
◦ Kubernetes taints for nodes and tolerations for pods are treated as constraints. For example, if a pod has a
toleration attribute that restricts it from moving to a certain node, Turbonomic will not move that pod to the
restricted node.
◦ Turbonomic imports Kubernetes node labels and treats them as constraints. For example, if a pod has a defined
node label, Turbonomic will move that pod to a node with a matching label.
◦ Turbonomic recognizes pod affinity and anti-affinity policies.
◦ You can create placement policies to enforce constraints for pod move actions. For example, you can have a
policy that allows pods to only move to certain nodes, or a policy that prevents pods from moving to certain
nodes.
For more information, see Creating Placement Policies (on page 96).
• Eviction Thresholds
Turbonomic considers the memory/storage eviction thresholds of the destination node to ensure that the pod can
be scheduled after it moves. Eviction thresholds for imagefs and rootfs are reflected as node effective capacity
in the market analysis.

• Temporary Quota Increases

If a namespace quota is already fully utilized, Turbonomic temporarily increases the quota to allow a pod to
move, while maintaining that one replica continues to run. You can disable temporary increases in quotas, but be
aware that this will result in failure to move pods. To disable increases, set the following in the yaml resource for
Kubeturbo deployment:
update-quota-to-allow-moves=false
Provision and Suspend Actions

Turbonomic can recommend provisioning or suspending pods under the following conditions:
• For horizontally scalable Kubernetes Services that collect performance metrics (or KPIs) for applications,
Turbonomic can dynamically adjust the number of pod replicas that back those Services to help you meet SLOs
(Service Level Objectives) for your applications.
• When recommending node provision actions, Turbonomic also recommends pod provision actions that reflect the
projected demand from required DaemonSet pods, and respects the maximum number of pods allowed for a node.
This ensures that any application workload can be placed on the new node and stay within the desired range of
vMem/vCPU usage, vMem/vCPU request, and number of consumers.
The action details for a pod provision action shows the related node that you need to provision. Click the node
name to set it at your scope.
• When recommending node suspension actions, Turbonomic also recommends suspending the DaemonSet pods
that are no longer required to run the suspended nodes.
The action details for a pod suspension action shows the related node that you need to suspend. Click the node
name to set it at your scope.

Container Pod Policies


For details about container pod actions, see Container Pod Actions (on page 164).
Action Default Mode

Move Manual
Action orchestration is currently not supported.
Placement Policies
You can create placement policies to enforce constraints for pod move actions. For example, you can have a policy that
allows pods to only move to certain nodes, or a policy that prevents pods from moving to certain nodes.
Namespace
A namespace is a logical pool of resources in a Kubernetes environment that manages workloads based on specific
requirements or business needs. For example, administrators can pool resources for different organizations within the
enterprise, and assign different policies to each pool.

Synopsis

Synopsis
Budget: N/A
Provides: N/A
Consumes: N/A
Resource Quotas
A namespace can include the following compute resource quotas:
VMem Request Quota
The total amount of virtual memory request for all pods allocated to the namespace against the
namespace quota. Measured in Megabytes (MB)
VCPU Request Quota
The total amount of virtual CPU request for all pods allocated to the namespace against the namespace
quota. Measured in millicores (mCores)
VMem Limit Quota
The total amount of virtual memory limit for all pods allocated to the namespace against the namespace
quota. Measured in Megabytes (MB)
VCPU Limit Quota
The total amount of virtual CPU limit for all pods allocated to the namespace against the namespace
quota. Measured in millicores (mCores)
When they are configured, these quotas define the capacity for the given namespace. Turbonomic recognizes these
quotas as it calculates actions in your environment.

If containers in the namespace require more compute resources, and those requirements exceed the namespace
quotas, then Turbonomic recommends increasing the quotas. It will block execution of the underlying container
actions until the namespace quotas are sufficient. In the details for a quota resize action, you can see the list of blocked
container actions.
For more about actions to increase namespace quotas, see Actions (on page 169).
When you run Optimize Container Cluster plans, Turbonomic can calculate increased namespace quotas in the plan
results. For more information, see Optimize Container Cluster Plan (on page 298).
Turbonomic treats quotas defined in namespaces as constraints when making sizing decisions for containers. When you
scope to a namespace in the supply chain, the Capacity and Usage chart shows Capacity as the namespace quotas. Used
values are the sum of resource limits and/or requests set for all pods in the namespace.

For a namespace that does not have defined quotas, Capacity for the commodity is infinite (as shown in the image
below). Used values are the sum of resource limits and/or requests set for all pods in the namespace. If these are not
set, Used value is 0 (zero).

NOTE:
If you download the data in the chart, the downloaded file shows infinite capacities as unusually large values (for
example, 1,000,000,000 cores instead of the ∞ symbol).

Labels and Annotations

Turbonomic discovers namespace labels and annotations as tag properties. You can filter namespaces by labels or
annotations when you use Search or create Groups.
Monitored Resources
Turbonomic monitors actual utilization of VMem, VCPU, VMem Requests and VCPU Requests against cluster capacity.
You can see utilization data in the Capacity and Usage and Namespace Multiple Resources charts. With this data, you
can understand how pods running in the namespace are consuming resources.
To see which namespaces use the most cluster resources, set the scope to a container cluster and see the Top
Namespaces chart. You can use the data in the chart for showback analysis.
Actions
Resize Quota
Turbonomic treats quotas defined in a namespace as constraints when making container resize decisions. If existing
container actions would exceed the namespace quotas, Turbonomic recommends actions to resize up the affected
namespace quota.
Note that Turbonomic does not recommend actions to resize down a namespace quota. Such an action reduces the
capacity that is already allocated to an application – The decision to resize down a namespace quota should include the
application owner.
Turbonomic only recommends a resize for namespace quotas if underlying actions to resize containers require the
increased quota. Note that Turbonomic aggregates container actions in Workload Controller entities. When you have
a recommendation to resize namespace quotas, Turbonomic blocks execution of the resize actions for the affected
Workload Containers. The action details show these blocked actions in the Related Actions list.


For more information about namespace quotas, see Resource Quotas (on page 167).
For more information about container resize actions, see Workload Controller Actions (on page 161).
For more information about container resize actions, see Container Actions (on page 151).
Container Cluster
A Container Cluster is a Kubernetes cluster that Turbonomic discovers through Kubeturbo. With this entity type,
Turbonomic can fully link the entire container infrastructure with the underlying nodes, and then present all actions
on containers and nodes in a single view. This gives you full visibility into the actions that impact the health of your
container environment.
Synopsis

Synopsis
Budget: N/A
Provides: N/A

Synopsis
Consumes: N/A
Monitored Resources
Turbonomic does not monitor resources for Kubernetes clusters. Instead, it monitors resources for the containers, pods,
nodes (VMs), and volumes in the cluster.
Actions
None
Turbonomic does not recommend actions for a Container Cluster. Instead, it recommends actions for the containers,
pods, nodes (VMs), and volumes in the cluster. Turbonomic shows all of these actions when you scope to a Container
Cluster and view the Pending Actions chart.

For actions on nodes:
• For actions to suspend or provision nodes in the public cloud, Turbonomic includes cost information (investments
or savings) attached to those actions. Note that Turbonomic generates these actions not to optimize costs, but to
assure performance and efficiency for your container infrastructure. Turbonomic reports costs to help you track
your cloud spend.
To view cost information, set the scope to a cluster in the public cloud and view the Necessary Investments or
Potential Savings charts. You can also set the scope to the global cloud environment to see total costs, or to
individual container clusters or nodes.
• For VMs/nodes that make up an Azure Kubernetes Service (AKS) cluster, you can manually execute recommended
VM Provision and VM Suspend actions. This adjusts the count of nodes in a given node pool, where Provision raises
the node count, and Suspend lowers it. You can execute these actions if the cluster is also discovered through an
Azure target (along with the KubeTurbo target).
• Node pools and machine sets are ways to deploy and scale compute resources for Kubernetes services hosted in the
public cloud and the OpenShift 4.x container platform on any infrastructure.
For Kubernetes services in the public cloud, Turbonomic uses default labels with the following patterns to discover
the node pool types within each cluster:
◦ Azure Kubernetes Service (AKS): agentpool

◦ Amazon Elastic Kubernetes Service (EKS):

//alpha.eksctl.io/nodegroup-name
eks.amazonaws.com/nodegroup
◦ Google Kubernetes Engine (GKE): cloud.google.com/gke-nodepool
For OpenShift 4.x, Turbonomic creates node pools based on machine sets.
For both discovered and auto-created node pools, Turbonomic aggregates and visualizes actions for all the nodes in
a pool to help you identify performance issues and optimization opportunities at the node pool level. Use the Top
Node Pools chart to see actions and detailed information. By default, this chart displays when you set the scope to
your global environment and then click the Container Cluster entity in the supply chain.

The chart shows the number of nodes and aggregated actions for each node pool. For node pools in the public
cloud, the chart also shows the costs you would incur if you provision nodes and then scale their volumes, or the
savings you would realize if you suspend nodes. To view individual actions, click the button under the Actions
column. To see more details, including the full list of nodes for each pool, click the node pool name.
You can automate the execution of these actions through Turbonomic with OpenShift 4.x Machine Operator, or via
an Action Script. You can also manually execute node actions for AKS, EKS, or GKE via the cloud provider.
NOTE:
The following capabilities will be introduced in a future release:
◦ Actions to provision or suspend nodes via a plan simulation
◦ Policies for node pools
◦ Execution of node actions for AKS, EKS and GKE through Turbonomic
Cluster Health
To assess the health of each cluster, see the Top Container Platform Clusters chart in the predefined Container Platform
Dashboard.
For each cluster, the chart shows the sum of resources used by containers and the underlying nodes. Click the Actions
button to see a list of pending actions.


The Top Namespaces chart shows the namespaces that use the most cluster resources. You can use the data in the chart
for showback analysis.

Kubernetes CPU Metrics

To meet user requirements and align with Kubernetes specifications, Turbonomic uses millicore (mCore) as the base unit
for CPU metrics for your Kubernetes platform.


These include metrics for the following CPU-related commodities:
• vCPU
• vCPU Request
• vCPU Limit Quota
• vCPU Request Quota
Turbonomic displays these commodities in charts, actions, policies, and plans. For example:
• In the Capacity and Usage chart for container platform entities, capacity and used values for CPU-related
commodities are shown in mCores.
• In the supply chain, when you scope to a Workload Controller to view pending resize actions (on page 151) for a
container, you will see utilization and resize values in mCores.
• When you create Container Spec policies (on page 157), resize thresholds and increment constants for CPU-
related commodities are set in mCores.
• For an Optimize Container Cluster plan, the plan results (on page 301) for CPU-related commodities are shown in
mCores.
For nodes (VMs) and Application Components:
• For nodes stitched to your Kubernetes platform, the base unit for vCPU Request is also mCore, since this commodity
is provided only to Kubernetes.
• For both nodes and Application Components (standalone or stitched to your Kubernetes platform), the base unit for
vCPU is MHz, since this is a generic commodity. For example, when you view a pod move action, vCPU metrics for
the current and destination nodes for the pod are expressed in MHz.
The following table summarizes the base units of CPU measurement that Turbonomic uses.

CPU Commodity
Entity
vCPU vCPU Request vCPU Limit Quota vCPU Request Quota
Container mCore mCore mCore mCore
Container Spec mCore mCore N/A N/A
Workload Controller N/A N/A mCore mCore
Container Pod mCore mCore mCore mCore
Namespace mCore mCore mCore mCore
Container Cluster mCore mCore N/A N/A
Node (VM) MHz mCore N/A N/A
Application MHz N/A N/A N/A
Component
This feature is available starting in version 8.2.5. For customers updating to version 8.2.5 or later:
• This feature does not require you to update your Kubeturbo image after the update.
• For time series charts, metrics generated after the update are actual mCore values, but pre-update metrics are the
same (unconverted) values in MHz displayed in mCore units. This results in unexpected data in charts immediately
after the update.
For example:
If vCPU Limit for a Container Spec was resized from 1300 MHz to 1200 MHz before you updated Turbonomic, data
points in charts correctly show these values in MHz.
Immediately after the update:
◦ When you view the Virtual CPU chart for the Container Spec, Turbonomic will show a capacity value of 1200
mCores (which is 1200 MHz in reality) for the last data point before the update, and the equivalent value of 500
mCores for the first data point after the update. This gives the impression of a resize down action between the
data points, even if no such action was executed.
◦ Assume Turbonomic recommends an action to resize VCPU Limit for the Container Spec from 500 to 700
mCores. When you view the details for this action via the associated Workload Controller, the time series chart
will show unexpected data.
■ For the actual recommended action, the data point shows current capacity as 1200 mCores, instead of 500
mCores. The new value after executing the action correctly shows as 700 mCores.
■ For the last resize action before the update, the data point shows the same MHz values (1300 and 1200),
but in mCore units.
■ One day after the update, a new data point displays in the chart, indicating that capacity was resized from
1200 mCores to 500 mCores, even if no actual resize action was executed.
Over time, data points with unexpected values will begin to fall out of range and newer data points will reflect
actual mCore values.
• For increment constants in Container Spec policies, the default value of 100 remains unchanged, but the unit
changes from MHz to mCores. This means that each resize action will now increase or decrease capacity by 100
mCores, instead of 100 MHz.

Entity Types - Cloud Infrastructure
Turbonomic discovers and monitors the entities that make up your cloud infrastructure, and recommends actions to
assure application performance at the lowest possible cost.


Virtual Machine (Cloud)

A virtual machine (VM) is a software emulation of a physical machine, including OS, virtual memory and CPUs, and
network ports. VMs host applications, or they provide resources to container platforms.
Synopsis

Synopsis
Budget: A VM gains its budget by selling resources to the applications it hosts.
Provides: Resources for hosted applications to use:
• VMEM (Kbytes)
• VCPU (MHz)
• VStorage

Synopsis
• IOPS (storage access operations per second)
• Latency (capacity for disk latency in ms)
• Memory and CPU Requests (for Kubernetes environments)
Consumes: Resources from cloud zones
Discovered through: Cloud targets
Monitored Resources
Turbonomic monitors the following resources for a cloud VM:
• Storage Amount
The utilization of the datastore's capacity
• Storage Access Operations Per Second (IOPS)
The utilization of IOPS allocated for the VStorage on the VM
Measured in IOPS
• Net Throughput
Rate of message delivery over a port
Measured in KB/s
• Net Throughput Inbound
Rate of message received over a port
Measured in KB/s
• Net Throughput Outbound
Rate of message sent over a port
Measured in KB/s
• I/O Throughput
The throughput to the underlying storage for the entity
Measured in KB/s
• Latency
The utilization of latency allocated for the VStorage on the VM
Measured in milliseconds (ms)

Cloud VM Actions
• Scale
Change the VM instance to use a different instance type or tier to optimize performance and costs.
• Increase RI Coverage / Buy RI
If you have a high percentage of on-demand VMs, you can reduce your monthly costs by increasing coverage. To
increase coverage, you scale VMs to instance types that have existing capacity. If you need more RI capacity, then
Turbonomic will recommend Buy RI actions.
For scale actions, you can choose Cloud Scale All, Cloud Scale for Performance, or Cloud Scale for Savings.
• You can direct Turbonomic to only execute cloud VM scaling actions that improve performance (Cloud Scale for
Performance) or reduce costs (Cloud Scale for Savings). The default action mode for these actions is Manual. When
you examine the pending actions, only actions that satisfy the policy are allowed to execute. All other actions are
read-only.
• Cloud Scale All enables all scaling actions, including those that result in efficiency improvements and increased
costs.
NOTE:
The Move/Compute Scale action available in version 7.22.5 or earlier has been separated into two actions starting
in version 7.22.6 – Move (for on-prem VMs) and Cloud Compute Scale (for cloud VMs). In version 8.0.5, Cloud
Compute Scale has been renamed Cloud Scale All.
If you disabled Move/Compute Scale and then updated to 7.22.6 or later, only Move actions are disabled. To
apply the same action to cloud VMs, create policies for the affected VMs and then disable Cloud Scale All.
• When policy conflicts arise, Cloud Scale All overrides the other two scaling options in most cases. For more
information, see Relationship Between Scoped and Default Policies (on page 101).
Cloud VMs with Failed Sizing

For workload on the public cloud, if Turbonomic tries to execute a scale action but the action fails, then Turbonomic
places the affected VM in a special group named Cloud VMs with Failed Sizing. Under normal circumstances this group
will be empty. But in case some actions have failed, you can review the contents of this group to inspect the individual
VMs. As soon as Turbonomic successfully executes a scale action on a VM in this group, it then removes the VM from
the group.
NOTE:
When Turbonomic places a VM in this group, it restarts the VM to ensure that it is running correctly with its original
configuration.
By default Turbonomic does not include any action policies for this group. Whatever action mode is set to the given
VMs remains in effect while the VMs are in this group. You can create a policy and scope the policy to this group. For
example, assume you see typical failures for actions that Turbonomic tries to execute during working hours. In that case,
you can create a scheduling window that enables scale actions during off hours. That can help to automatically execute
the actions and remove the VMs from this group.
Note that the VMs in this group could already be in a scope that is affected by another actions policy. Remember that
with competing policies, the most conservative policy wins. When working with the Cloud VMs with Failed Sizing group,
this can have unintended consequences. Assume you have VMs with automated scale actions, and you create a policy
the sets the action mode to Manual for this group. Assume a failed scale action places a VM into this group. In that case
the more conservative action mode takes effect, and the VM will use Manual mode. Because of a failed scale action, the
VM does not automate subsequent scale actions.

Actions for Kubernetes Nodes (VMs)

Provision
Provision nodes to address workload congestion or meet application demand.
When recommending node provision actions, Turbonomic also recommends pod provision actions that reflect the
projected demand from required DaemonSet pods, and respects the maximum number of pods allowed for a node. This
ensures that any application workload can be placed on the new node and stay within the desired range of vMem/vCPU
usage, vMem/vCPU request, and number of consumers.
The action details for a node provision action show the related DaemonSet pods that are required for the node to run.
Click a pod name to set it at your scope.

Suspend
Suspend nodes after you have consolidated pods or defragmented node resources to improve infrastructure efficiency.
When recommending node suspension actions, Turbonomic also recommends suspending the DaemonSet pods that are
no longer required to run the suspended nodes.
The action details for a node suspension action show the related DaemonSet pods that are no longer needed to run the
suspended nodes. Click a pod name to set it at your scope.

For nodes in the public cloud, Turbonomic reports the cost savings or investments attached to these actions. For
example, you can see the additional costs you would incur if you provision nodes and then scale their volumes, or
the savings you would realize if you suspend nodes. Note that performance and efficiency are the drivers of these
actions, not cost. Cost information is included to help you track your cloud spend. For this reason, you will not see cost-
optimization actions, including recommendations to re-allocate Reserved Instances or delete unattached volumes.
To view cost information, set the scope to a node and see the Necessary Investments and Potential Savings charts. You
can also set the scope to a container cluster (on page 170) or the global cloud environment to view aggregated cost
information.
AWS VMs
AWS Instance Requirements

In AWS some instances require workloads to be configured in specific ways before they can move to those instance
types. If Turbonomic recommends moving a workload that is not suitably configured onto one of these instances, then
it sets the action to Recommend Only, and describes the reason. Turbonomic will not automate the move, even if you
have set the action mode for that scope to Automatic. You can execute the move manually, after you have properly
configured the instance.
Note that if you have workloads that you cannot configure to support these requirements, then you can set up a policy
to keep Turbonomic from making these recommendations. Create a group that contains these workloads, and then
create a placement policy for that scope. In the policy, Excluded Templates to exclude the instance types that do require
ENA support. For information about placement policies, see Automation Policies (on page 100). For information about
excluding instance types, see Cloud Instance Types (on page 187).
The instance requirements that Turbonomic recognizes are:
• Enhanced Network Adapters

Some workloads can run on instances that support Enhanced Networking via the Elastic Network Adapter (ENA),
while others can run on instances that do not offer this support. Turbonomic can recommend moving a workload
that does not support ENA onto an instance that does. To make that move, you must perform the required
configuration of the workload before you can execute the move. If you move a non-ENA VM to an instance that
requires ENA, then AWS cannot start up the VM after the move. Before executing the move, you must enable ENA
on the VM.
For information about ENA configuration, see "Enabling Enhanced Networking with the Elastic Network Adapter
(ENA) on Windows Instances" in the AWS documentation.
• Linux AMI Virtualization Type
An Amazon Linux AMI can use ParaVirtual (PV) or Hardware Virtual Machine (HVM) virtualization. Turbonomic can
recommend moving a PV workload to an HVM instance that does not include the necessary PV drivers.
To check the virtualization type of an instance, open the Amazon EC2 console to the Details pane, and review the
Virtualization field for that instance.
• 64-bit vs 32-bit
Not all AWS instance can support a 32-bit workload. Turbonomic can recommend moving a 32-bit workload to an
instance that only supports a 64-bit platform.
• NVMe Block
Some instances expose EBS volumes as NVMe block devices, but not all workloads are configured with NVMe
drivers. Turbonomic can recommend moving such a workload to an instance that supports NVMe. Before executing
the move, you must install the NVMe drivers on the workload.
In addition, Turbonomic recognizes processor types that you currently use for your workloads. For move or resize
actions, Turbonomic keeps your workloads on instance types with compatible processors:
• GPU-based instances:
Turbonomic recognizes when your workload is on a GPU-based instance. To ensure the workload always stays on a
compatible processor, Turbonomic does not recommend resize actions.
• ARM-based instances
If your workload is on an ARM-based instance, then Turbonomic will only recommend resizes to other compatible
ARM-based instance types.
Resizing Storage Capacity in AWS Environments

When a VM needs more storage capacity Turbonomic recommends actions to move the it to an instance that provides
more storage. Note that AWS supports both Elastic Block Store (EBS) and Instance storage. Turbonomic recognizes these
storage types as it recommends storage actions.
If the root storage for your workload is Instance Storage, then Turbonomic will not recommend a storage action. This is
because Instance Storage is ephemeral, and such an action would cause the workload to loose all the stored data.
If the root storage is EBS, then Turbonomic recommends storage actions. EBS is persistent, and the data will remain after
the action. However, if the workload uses Instance Storage for extra storage, then Turbonomic does not include that
storage in its calculations or actions.
Action Details for AWS Workloads

In AWS environments, Turbonomic considers a VM's used and reserved memory to calculate virtual memory utilization,
and drives actions based on the calculated value. This may not always match the values seen in CloudWatch or at the OS
level of the VM.

According to the AWS FAQ, "In C5, portions of the total memory for an instance are reserved from use by the Operating
System including areas used by the virtual BIOS for things like ACPI tables and for devices like the virtual video RAM.".
When Turbonomic recommends moving to one of these instances, the action details use the capacity that is reported by
the instance template. However, subsequent reporting of the Mem capacity for the given instance uses the values that
Turbonomic discovers in the environment.
Azure VMs
Azure Resource Group Discovery

To discover Azure Resource Groups, you can set up the following targets:
• Microsoft Azure service principle targets
• Microsoft Azure Enterprise Agreement (EA) targets
For Azure environments that include Resource Groups, Turbonomic discovers the Azure Resource Groups and the tags
that are used to identify these groups.
In the Turbonomic user interface, to search for a specific Azure Resource Group, choose Resource Groups in the Search
Page.
You can set the scope of your Turbonomic session to an Azure Resource Group by choosing a group in the Search results
and clicking Scope To Selection.
You can also use Azure tags as filter criteria when you create a custom Turbonomic resource group. You can choose the
Azure Resource Groups that match the tag criteria to be members of the new custom group.
To find the available tags for a specific Azure Resource Group, add the Basic Info chart configured with Related Tag
Information to your view or custom dashboard. See Basic Info Charts (on page 373).
Azure Instance Requirements

In Azure environments, some instance types require workloads to be configured in specific ways, and some workload
configurations require instance types that support specific features. When Turbonomic generates resize actions in Azure,
these actions consider the following features:
• Accelerated Networking (AN)
In an Azure environment, not all instance types support AN, and not all workloads on AN instances actually enable
AN. Turbonomic maintains a dynamic group of workloads that have AN enabled, and it assigns a policy to that group
to exclude any templates that do not support AN. In this way, if a workload is on an instance that supports AN, and
that workload has enabled AN, then Turbonomic will not recommend an action that would move the workload to a
non-AN instance.
• Azure Premium Storage
Turbonomic recognizes whether a workload uses Premium Storage, and will not recommend a resize to an instance
that does not support Azure Premium Storage.
In addition, Turbonomic recognizes processor types that you currently use for your workloads. If your workload is on a
GPU-based instance, then Turbonomic will only recommend moves to other compatible GPU-based instance types. For
these workloads, Turbonomic does not recommend resize actions.

Performance Metrics for Azure VMs

To analyze the utilization of Azure VM resources, Turbonomic collects performance metrics (such as memory and CPU
usage) from Azure periodically. It collects metrics in the following ways:
• Azure storage account
• For VMs with basic diagnostics enabled, Turbonomic collects performance metrics that Azure publishes via this
storage account.
• Azure Monitor Log Analytics
Rather than enabling diagnostics on a per-VM basis, you may have created Azure Monitor Log Analytics workspaces
to centralize the management of your Azure VM configurations. Turbonomic discovers these workspaces when you
add Azure targets, and then retrieves performance metrics periodically.
IOPS-aware Scaling for Azure VMs

Turbonomic considers IOPS utilization when making scaling decisions for Azure VMs. To measure utilization, Turbonomic
takes into account a variety of attributes, such as per-disk IOPS utilization, whole VM IOPS utilization, cache settings, and
IOPS capacity for the VMs. It also respects IOPS utilization and aggressiveness constraints that you set in VM policies. For
details, see Aggressiveness and Observation Periods (on page 186).
Analysis impacts VM scaling decisions in different ways. For example:
• If your instance experiences IOPS bottlenecks, Turbonomic can recommend scaling up to a larger instance type to
increase IOPS capacity, even if you do not fully use the current VCPU or VMEM resources.
• If your instance experiences underutilization of VMEM and VCPU, but high IOPS utilization, Turbonomic might not
recommend scaling down. It might keep you on the larger instance to provide sufficient IOPS capacity.
• If the instance experiences underutilization of IOPS capacity along with normal utilization of other resources, you
might see an action to resize to an instance that is very similar to the current one. If you inspect the action details,
you should see that you are changing to a less expensive instance with less IOPS capacity.
Cloud VM Policies

For details about cloud VM actions, see Cloud VM Actions (on page 179).
Cloud Scale
Action Default Mode AWS Azure

Cloud Scale All Manual
Cloud Scale for Performance Manual
Cloud Scale for Savings Manual

Other Actions
Action Default Mode AWS Azure

Buy RI Recommend
Provision Kubernetes node (VM) Manual
Suspend Kubernetes node (VM) Manual
Scaling Target Utilization

For VCPU, VMEM, and IO/Net Throughput Utilization:
These advanced settings determine how much you would like a scope of workloads to utilize their resources. These are
fixed settings that override the way Turbonomic calculates the optimal utilization of resources. You should only change
these settings after consulting with Technical Support.
While these settings offer a way to modify how Turbonomic recommends actions, in most cases you should never
need to use them. If you want to control how Turbonomic recommends actions to resize workloads, you can set the
aggressiveness per the percentile of utilization, and set the length of the sample period for more or less elasticity on the
cloud.

Scaling Target VCPU Utilization 70
The target utilization as a percentage of VCPU capacity.
Scaling Target VMEM Utilization 90
The target utilization as a percentage of memory
capacity.
Scaling Target IO Throughput Utilization 90
The target utilization as a percentage of IO throughput
(Read and Write) capacity.
Scaling Target Net Throughput Utilization 90
The target utilization as a percentage of network
throughput (Inbound and Outbound) capacity.
For IOPS Utilization:

Turbonomic uses this setting in conjuction with aggressiveness constraints to control scaling actions for VMs. You can set
the aggressiveness per the percentile of utilization, and set the length of the sample period for more or less elasticity on
the cloud.

Scaling Target IOPS Utilization 70
(Azure VMs only) For Azure environments, the target percentile value
Turbonomic will attempt to match.
For details on how IOPS utilization affects scaling decisions, see IOPS-aware Scaling for Azure VMs (on page 184).

Aggressiveness and Observation Periods

Turbonomic uses these settings to calculate utilization percentiles for vCPU, vMEM, and IOPS (Azure VMs only). It then
recommends actions to improve utilization based on the observed values for a given time period.
• Aggressiveness

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 95th percentile. The percentile utilization is the
highest value that 95% of the observed samples fall below. Compare that to average utilization, which is the average
of all the observed samples.
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.
For the above example, assume a single CPU burst to 100%, but for 95% of the samples CPU never exceeded 50%. If
you set Aggressiveness to 95th Percentile, then Turbonomic can see this as an opportunity to reduce CPU allocation
for the VM.
◦ 100th and 99th Percentile – More performance. Recommended for critical workloads that need maximum
guaranteed performance at all times, or workloads that need to tolerate sudden and previously unseen spikes
in utilization, even though sustained utilization is low.
◦ 95th Percentile (Default) – The recommended setting to achieve maximum performance and savings. This
assures application performance while avoiding reactive peak sizing due to transient spikes, thus allowing you
to take advantage of the elastic ability of the cloud.
◦ 90th Percentile – More efficiency. Recommended for non-production workloads that can stand higher resource
utilization.
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.

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:

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 None
◦ Less Elastic – 7 Days
Cloud Instance Types

Cloud Instance Types None
By default, Turbonomic considers all instance types currently available for scaling when making scaling decisions
for VMs. However, you may have set up your cloud VMs to only scale to or avoid certain instance types to reduce
complexity and cost, improve RI utilization, or meet application demand. Use this setting to identify the instance types
that VMs can scale to.
Click Edit to set your preferences. In the new page that displays, expand a cloud tier (a family of instance types, such
as a1 for AWS or B-series for Azure) to see individual instance types and the resources allocated to them. If you have
several cloud providers, each provider will have its own tab.
Select your preferred instance types or cloud tiers, or clear the ones that you want to avoid. After you save your
changes, the main page refreshes to reflect your selections.
Consistent Resizing
Enable Consistent Resizing Off
For groups in scoped policies:

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,
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.
For an affected resize, the Actions List shows individual resize actions for each of the VMs in the group. If you automate
resizes, Turbonomic executes each resize individually in a way that avoids disruption to your workloads.
Use this setting to enforce the same template across all VMs in a group when resizing VMs on the public cloud. In this
way, Turbonomic can enforce a rule to size all the VMs in a group equally.
For auto-discovered groups:
In public cloud environments, Turbonomic discovers groups that should keep all their VMs on the same template,
and then creates read-only policies for them to implement Consistent Resizing. The details of this discovery and the
associated policy vary depending on the Cloud Provider.
• Azure
Turbonomic discovers Azure availability sets and scale sets.
◦ For availability sets, Turbonomic does not enable Consistent Resizing, but it can recommend scale actions for
individual VMs in the availability set.
When a scale action for a VM in an availability set fails due to insufficient resources in the compute cluster, the
action remains pending. When you hover over the pending action, you will see a message indicating that action
execution has been temporarily disabled due to a previous execution error in the availability set. Turbonomic
assumes that all other VMs in the availability set will fail to scale due to the same resource issue, so it creates
a temporary policy that disables action execution for the availability set. Specifically, this policy sets the action
mode for scale actions to Recommend and stays in effect for 730 hours (one month). This means that for
the duration of the policy, Turbonomic will continue to generate read-only, non-executable scale actions for
individual VMs, so you can evaluate their resource requirements and plan accordingly. You can delete this policy
if you need to re-enable action execution in the availability set.
◦ For scale sets, Turbonomic automatically enables Consistent Resizing across all the VMs in the group. You can
choose to execute all the actions for such a group, either manually or automatically. In that case, Turbonomic
executes the resizes one VM at a time. If you do not need to resize all the members of a given scale set to a
consistent template, create another policy for that scope and turn off Consistent Resizing.
• AWS
Turbonomic discovers Auto Scaling Groups and automatically enables Consistent Resizing across all the VMs in each
group. You can choose to execute all the actions for such a group, either manually or automatically. In that case,
Turbonomic executes the resizes one VM at a time. If you do not need to resize all the members of a given Auto
Scaling Group to a consistent template, create another policy for that scope and turn off Consistent Resizing.
Reasons to employ Consistent Resizing for a group include:
• Load Balancing
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.
• High Availability (HA)
A common HA configuration on the public cloud is to deploy mirror VMs to different availability zones, where the
given application runs on only one of the VMs at a given time. The other VMs are on standby to recover in failover
events. Without Consistent Resizing, Turbonomic would tend to size down or suspend the unused VMs, which
would make them unready for the failover situation.

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.
• If one VM (or more) is in a group with Consistent Resizing turned on, and the same VMs are in a group with
Consistent Resizing turned off, the affected VMs assume the ON setting. This is true if you created both groups, or if
Turbonomic created one of the groups for Azure Scale Sets or AWS Auto Scaling Groups.
• 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 managed on both Azure and AWS 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.
Instance Store Aware Scaling

Instance Store Aware Scaling Off
For AWS environments:

The template for your workload determines whether the workload can use an instance store, and it determines the
instance store capacity. As Turbonomic calculates a resize or move action, it can recommend a new template that does
not support instance stores, or that does not provide the same instance store capacity.
To ensure that resize actions respect the instance store requirements for your workloads, turn on Instance Store Aware
Scaling for a given VM or for a group of VMs. When you turn this on for a given scope of VMs, then as it calculates move
and resize actions, Turbonomic will only consider templates that support instance stores. In addition, it will not move a
workload to a template that provides less instance store capacity.
Database Server (Cloud)

In AWS public cloud environments, a Database Server is a relational database that you have configured using AWS
Relational Database Service (RDS). Turbonomic discovers RDS instances through your AWS targets, and then generates
scaling actions as needed.
NOTE:
Azure SQL Databases discovered by Turbonomic appear as Database entities in the supply chain. For details, see
Database (Cloud) (on page 214).

Synopsis

Synopsis
Budget: A cloud Database Server has unlimited budget.
Provides: Database services to cloud applications and end users
Consumes: Compute and storage resources in the availability zone
Discovered through: AWS targets
Permissions
Turbonomic requires the following permissions for AWS RDS Database Servers:
• Monitoring permissions:
◦ cloudwatch:GetMetricData
◦ pi:GetResourceMetrics
◦ rds:DescribeDBInstances
◦ rds:DescribeDBParameters
◦ rds:ListTagsForResource
◦ rds:DescribeOrderableDBInstanceOptions
• Action execution permissions:
◦ rds:ModifyDBInstance
For a full list of permissions, see "Amazon Web Services" in the Target Configuration Guide.
Monitored Resources
Turbonomic monitors the following resources for a cloud Database Server:
The utilization of VMem allocated to the Database Server's instance type
The utilization of VCPU allocated to the Database Server's instance type
• Storage Amount

The amount of Amazon EBS storage utilized by the Database Server

• Storage Access
IOPS utilized by the Database Server
• DB Cache Hit Rate (if available)
The percentage of database responses served through cache hits
• Connections
The number of connections to the Database Server
Actions
Scale
Scale compute and storage resources to optimize performance and costs.
To recommend accurate scaling actions, Turbonomic analyzes resource utilization percentiles and collects relevant
metrics (such as connections utilization) from AWS. It also takes into consideration constraints defined in policies (on
page 199).
Consider the following scenarios and actions:
• To address vCPU congestion, Turbonomic can recommend scaling a Database Server to the instance type that can
adequately meet demand at the lowest possible cost. If vCPU is underutilized, it can recommend scaling to a smaller
instance type.
• To address IOPS congestion, Turbonomic can recommend increasing provisioned IOPS or scaling the Database
Server to a different storage type. For gp2 storage, it can recommend increasing disk size to increase provisioned
IOPS. After executing these actions, Turbonomic will not recommend new actions for the next six hours, in
compliance with AWS's "cooldown" period for EBS storage.
• Turbonomic analyzes DB cache hit rate before making vMem scaling decisions. To perform its analysis, it collects
cache hit rate metrics for Database Servers with Performance Insights enabled.
For Database Servers with cache hit rate metrics, Turbonomic considers at least 90% cache hit rate to be optimal.
This percentage value is not configurable.
◦ A cache hit rate value equal to or greater than 90% indicates efficiency. For this reason, Turbonomic will not
recommend an action even if vMem utilization is high. If vMem utilization is low, it will recommend scaling to a
smaller instance type.
◦ When the cache hit rate is below 90%, Turbonomic will also not recommend an action, provided that vMem
utilization remains low. If vMem utilization is high, then it will recommend scaling to a larger instance type.
Notes on Performance Insights and cache hit rate metrics:
◦ Performance Insights is enabled by default on a majority of AWS Database Servers. In the Turbonomic user
interface, you can use Search and then apply the Performance Insights filter to see which Database Servers
have Performance Insights enabled.
◦ If Performance Insights is disabled or is not supported for your AWS Database Server engines or regions,
Turbonomic will not have cache hit rate metrics to analyze and will therefore not generate actions in direct
response to vMem utilization. For a list of supported engines and regions, see this AWS page.
◦ An action to scale to a different instance type in response to vCPU utilization might also include vMem changes,
but vMem utilization alone (without cache hit rate metrics) will not drive actions.
Turbonomic also considers Connections utilization and capacity when making scaling decisions. It collects utilization
metrics from CloudWatch and calculates capacity based on the maximum number of simultaneous connections
configured for the Database Server. The maximum number varies by Database Server engine type and memory

allocation, and is set in the parameter group associated with a Database Server. Turbonomic currently supports
Database Servers associated with parameter groups that use default values. For example, consider a MySQL Database
Server that is on a db.t3.large instance type with 8 GB (8589934592 bytes) of memory, and is associated with
a parameter group that uses the default value {DBInstanceClassMemory/12582880}. In this case, Turbonomic
calculates capacity as 682 connections (or {8589934592/12582880}). When Turbonomic generates an action due
to vMem underutilization and sees that Connections utilization is only 15% of capacity (or roughly 100 connections), it
picks a smaller instance type that is adequate for both the vMem and Connections requirements of the Database Server.
For example, it could pick db.t2.small, which provides 2 GB of memory and a maximum of 170 connections.
Actions in Charts
Use the Necessary Investments and Potential Savings charts to view pending Database Server actions. These charts
show total monthly investments and savings, assuming you execute all the actions.
Click Show All for each chart to review and execute the actions.
The table lists all the actions that are pending for Database Servers, and the savings or investments for each action.
For details on how Turbonomic calculates savings or investments, see Estimated On-demand Costs for Cloud Database
Servers (on page 196).
Utilization Charts
Turbonomic uses percentile calculations to measure resource utilization more accurately, and drive scaling actions that
improve overall utilization and reduce costs. When you examine the details for a pending scale action on a Database
Server, you will see charts that highlight utilization percentiles for a given observation period, and the projected
percentiles after you execute the action.

Database Server, you can see the resulting improvements in daily average utilization. Put together, these charts allow
you to easily recognize utilization trends that drive Turbonomic's scaling recommendations.
You can set scaling constraints in Database Server policies to refine the percentile calculations.

For details, see Scaling Sensitivity (on page 199).
Non-disruptive and Reversible Scaling Actions

Turbonomic indicates whether a pending action is non-disruptive or reversible to help you decide how to handle the
action.
The following table describes the disruptiveness and reversibility of the actions that Turbonomic recommends:
Action Disruptive Reversible

Scaling to a different instance type Yes Yes
Scaling up storage amount No No

Action Disruptive Reversible

Scaling up storage access No Yes
(provisioned IOPS)
Scaling to a different storage type + Yes No
Scaling up storage amount
Scaling to a different storage Yes Yes
type + Scaling up storage access
(provisioned IOPS)
Scaling to a different storage type + Yes No
Scaling up storage amount + Scaling
up storage access (provisioned IOPS)
You can set action modes in policies to specify the degree of automation for these actions.
Unavailable Instance Types

A scale action could fail if the target instance type is unavailable in the availability zone for some reason. Your AWS
environment might show the instance type as available, but when the scaling action executes, the following error
displays in AWS:
Cannot modify the instance class because there are no instances of the requested class
available in the current instance's availability zone. Please try your request again at a
later time.
NOTE:
For details about this error, see this AWS page.

When this error occurs, Turbonomic modifies the default Database Server policy to exclude the instance type from its
scaling list. When the Database Server is available again, Turbonomic adds it back to the scaling list. For details about
this list, see Cloud Instance Types (on page 201).
Estimated On-demand Costs for Cloud Database Servers

Turbonomic considers a variety of factors when calculating Estimated On-demand Monthly Cost for an AWS RDS
Database Server.

Non-Aurora Database Servers

Cost Calculation
For non-Aurora Database Servers, the calculation for Estimated On-demand Monthly Cost can be expressed as follows:
(On-demand Compute Rate * 730) + (Provisioned Database Storage Rate * Provisioned
Database Storage Amount) + (Provisioned IOPS Rate * Provisioned IOPS Amount) = Estimated
On-demand Monthly Cost
Where:
• On-demand Compute Rate is the hourly cost for a Database Server's instance type
You can obtain on-demand rates via Amazon RDS Pricing.

• Provisioned Database Storage Rate is the hourly cost for a Database Server's provisioned database storage
You can obtain provisioned database storage rates via Amazon RDS Pricing.
• Provisioned IOPS Rate is the monthly cost for a Database Server's provisioned IOPS
Provisioned IOPS apply only to Database Servers on Provisioned IOPS SSD (io1) storage. You can obtain information
about Provisioned IOPS SSD storage via the RDS User Guide.
You can obtain provisioned IOPS rates via Amazon RDS Pricing.
The listed items above impact cost calculations and the scaling decisions that Turbonomic makes. These decisions also
rely on other factors, such as resource utilization percentiles and scaling constraints set in policies.
Example
Assume the following data for a pending scale action for SQL Server Express Edition (Single A-Z deployment):

Provisioned Database Storage Rate $0.133/hr $0.133/hr
Provisioned Database Storage 20 GB 20 GB
Amount
Provisioned IOPS Rate $0.00 $0.00
Provisioned IOPS Amount 0 0

(0.024 * 730) + (0.133 * 20) + (0.00 * 0) = 20.18
(0.048 * 730) + (0.133 * 20) + (0.00 * 0) = 37.7
NOTE:
The Estimated On-demand Monthly Cost is projected to increase from $20.18/month to $37.7/month, as shown in the
Details section of the pending action.

Turbonomic treats the action as an investment and shows an estimated investment of $17.52/month.


Aurora Database Servers

Cost Calculation
For Aurora Database Servers, the calculation for Estimated On-demand Monthly Cost can be expressed as follows:
Database Storage Amount) + (I/O Request Rate * (Hourly Billed I/O Operation Count * 730))
= Estimated On-demand Monthly Cost
Where:
You can obtain on-demand rates via Amazon Aurora Pricing.
You can obtain provisioned database storage rates via Amazon Aurora Pricing.
• I/O Request Rate is the cost per one million read/write I/O requests
You can obtain I/O request rates via Amazon Aurora Pricing.
• Hourly Billed I/O Operation Count is the average sum of read and write I/O operations per hour over the last
month
The listed items above impact cost calculations. Except for I/O request rate, these items affect the actual scaling
decisions that Turbonomic makes. These decisions also rely on other factors, such as resource utilization percentiles and
scaling constraints set in policies.
Example
Assume the following data for a pending scale action for Aurora MySQL-Compatible Edition:

Provisioned Database Storage 100 100
Amount
I/O Request Rate $0.20/one million requests $0.20/one million requests
Hourly Billed I/O Operation Count 2000 2000


(0.164 * 730) + (0.10 * 100) + ((0.20 / 1000000) * (2000 * 730)) = 130.01
(0.041 * 730) + (0.10 * 100) + ((0.20 / 1000000) * (2000 * 730)) = 40.22
NOTE:
Since the Estimated On-demand Monthly Cost is projected to decrease from $130.01/month to $40.22/month,
Turbonomic treats the action as a cost-saving measure and shows estimated savings of $89.79/month.
Cloud Database Server Policies


For details about cloud Database Server actions, see Cloud Database Server Actions (on page 191) and Non-disruptive
and Reversible Scaling Actions (on page 194).
Action Default Setting/Mode

Database Server Scaling Actions On
Disruptive irreversible scaling Recommend
Disruptive reversible scaling Recommend
Non-disruptive irreversible scaling Recommend
Non-disruptive reversible scaling Recommend
Scaling Sensitivity
Turbonomic uses a percentile of utilization over the specified observation period. This gives sustained utilization and
ignores short-lived bursts.
Turbonomic uses these settings to calculate utilization percentiles for VCPU, VMEM and DB Cache Hit Rate, and IOPS. It
then recommends actions to improve utilization based on the observed values for a given time period.
• Aggressiveness


For example, consider decisions to reduce capacity. Without using a percentile, Turbonomic never resizes below
the recognized peak utilization. Assume utilization peaked at 100% just once. Without the benefit of a percentile,
Turbonomic will not reduce resources for that Database Server.
For the above example, assume a single burst to 100%, but for 95% of the samples, utilization never exceeded 50%.
If you set Aggressiveness to 95th Percentile, then Turbonomic can see this as an opportunity to reduce resource
allocation.
◦ 99th Percentile – More performance. Recommended for critical Database Servers that need maximum
guaranteed performance at all times, or those that need to tolerate sudden and previously unseen spikes in
utilization, even though sustained utilization is low.
assures performance while avoiding reactive peak sizing due to transient spikes, thus allowing you to take
advantage of the elastic ability of the cloud.
◦ 90th Percentile – More efficiency. Recommended for Database Servers that can stand higher resource
utilization.
By default, Turbonomic uses samples from the last 14 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.

uses historical data from up to the number of days that you specify as a sample period. If the Database Server has
fewer days' data then it uses all of the stored historical data.
◦ More Elastic – Last 7 Days or Last 3 Days
Turbonomic recommends an observation period of 14 days so it can recommend scaling actions more often. Since
Database Server scaling is minimally disruptive, scaling often should not introduce any noticeable performance
risks.


◦ Less Elastic – 1, 3, or 7 Days

By default, Turbonomic considers all instance types currently available for scaling when making scaling decisions for
Database Servers. However, you may have set up your Database Servers to only scale to or avoid certain instance types
to reduce complexity and cost, or meet demand. Use this setting to identify the instance types that Database Servers
can scale to.
NOTE:
Turbonomic automatically discovers and enforces Database Server tier exclusions configured in your AWS
environment. You do not need to configure these tier exclusions in policies. To see a list of tier exclusions that are
currently enforced, set the scope to one or several Database Servers and click the Policies tab.

Click Edit to set your preferences. In the new page that displays, expand a cloud tier (a family of instance types, such as
db.m1) to see individual instance types and the resources allocated to them.
NOTE:
This policy setting is not available in plans.

This is the target utilization as a percentage of capacity.

VCPU 70
VMEM 90
IOPS 70
Storage Amount 90

cloud.
Estimated On-demand Costs for Cloud Database Servers

Turbonomic considers a variety of factors when calculating Estimated On-demand Monthly Cost for an AWS RDS
Database Server.

Non-Aurora Database Servers

Cost Calculation
For non-Aurora Database Servers, the calculation for Estimated On-demand Monthly Cost can be expressed as follows:
Database Storage Amount) + (Provisioned IOPS Rate * Provisioned IOPS Amount) = Estimated
On-demand Monthly Cost

Where:
You can obtain on-demand rates via Amazon RDS Pricing.
You can obtain provisioned database storage rates via Amazon RDS Pricing.
• Provisioned IOPS Rate is the monthly cost for a Database Server's provisioned IOPS
Provisioned IOPS apply only to Database Servers on Provisioned IOPS SSD (io1) storage. You can obtain information
about Provisioned IOPS SSD storage via the RDS User Guide.
You can obtain provisioned IOPS rates via Amazon RDS Pricing.
Example
Assume the following data for a pending scale action for SQL Server Express Edition (Single A-Z deployment):

Amount
Provisioned IOPS Rate $0.00 $0.00
Provisioned IOPS Amount 0 0

(0.024 * 730) + (0.133 * 20) + (0.00 * 0) = 20.18
(0.048 * 730) + (0.133 * 20) + (0.00 * 0) = 37.7
NOTE:
The Estimated On-demand Monthly Cost is projected to increase from $20.18/month to $37.7/month, as shown in the
Details section of the pending action.


Turbonomic treats the action as an investment and shows an estimated investment of $17.52/month.

Aurora Database Servers

Cost Calculation
For Aurora Database Servers, the calculation for Estimated On-demand Monthly Cost can be expressed as follows:
Database Storage Amount) + (I/O Request Rate * (Hourly Billed I/O Operation Count * 730))
= Estimated On-demand Monthly Cost
Where:
You can obtain on-demand rates via Amazon Aurora Pricing.
You can obtain provisioned database storage rates via Amazon Aurora Pricing.
• I/O Request Rate is the cost per one million read/write I/O requests
You can obtain I/O request rates via Amazon Aurora Pricing.
• Hourly Billed I/O Operation Count is the average sum of read and write I/O operations per hour over the last
month
The listed items above impact cost calculations. Except for I/O request rate, these items affect the actual scaling
decisions that Turbonomic makes. These decisions also rely on other factors, such as resource utilization percentiles and
scaling constraints set in policies.
Example
Assume the following data for a pending scale action for Aurora MySQL-Compatible Edition:



Provisioned Database Storage 100 100
Amount
I/O Request Rate $0.20/one million requests $0.20/one million requests
Hourly Billed I/O Operation Count 2000 2000

(0.164 * 730) + (0.10 * 100) + ((0.20 / 1000000) * (2000 * 730)) = 130.01
(0.041 * 730) + (0.10 * 100) + ((0.20 / 1000000) * (2000 * 730)) = 40.22
NOTE:
Volume (Cloud)
A cloud volume is a storage device that you can attach to a VM. You can use an attached volume the same as a physical
hard drive.

Synopsis

Synopsis
Budget: A cloud volume gains its budget by selling resources to the VMs that it serves.
Provides: Storage resources for VMs to use:
• Storage Access
• Storage Amount
• IO Throughput
Consumes: Storage services provided by Zones or Regions
Discovered through: AWS and Azure targets
Monitored Resources
Turbonomic monitors the following resources for a cloud volume:
• Storage Access

The percentage of the volume's capacity for storage access operations (measured in IOPS) that is in use.
• IO Throughput
The percentage of the volume’s capacity for IO throughput (measured in MB/s) that is in use.
• IO Throughput Read
The percentage of the volume’s capacity for IO throughput Read (measured in MB/s) that is in use.
• IO Throughput Write
The percentage of the volume’s capacity for IO throughput Write (measured in MB/s) that is in use.
NOTE:
Turbonomic discovers Storage Amount (disk size) for AWS/Azure volumes, but does not monitor utilization.
For a Kubeturbo (container) deployment that includes AWS/Azure volumes, Kubeturbo monitors Storage Amount
utilization for the volumes. You can view utilization information in the Capacity and Usage chart.
Actions
• Scale
Scale attached volumes to optimize performance and costs.
• Delete
Delete unattached volumes as a cost-saving measure.
Scale Actions
Turbonomic can recommend:
• Scaling within the same tier (scale up or down), or from one tier to another
Examples:
◦ An action to scale down IOPS for a high performance volume, such as Azure Managed Ultra
◦ An action to scale a volume from the io1 to the gp2 tier
These actions can reduce costs significantly while continuing to assure performance. In addition, they are non-
disruptive and reversible.
NOTE:
For details about action disruptiveness and reversibility, see Non-disruptive and Reversible Scaling Actions (on
page 210).
• Scaling from one tier to another and then within the new tier, in a single action
For example, to achieve higher IOPS performance for VMs that are premium storage capable, you might see an
action to scale the corresponding volume from Standard to Premium, and then scale up volume capacity from
32GB to 256 GB. This action increases costs and is irreversible, but is more cost effective than scaling up within the
original tier.
NOTE:
Not all VM types are premium storage capable. For details, see the Azure Documentation.
When there are multiple disks attached to a volume, every volume scale action can potentially disrupt the same VM
multiple times and some of the actions may fail due to concurrency. To mitigate these issues, Turbonomic identifies
all volume actions associated with a particular VM and combines them into a single unit for execution, thus reducing

disruptions and the chance of failures due to concurrency. This approach applies to scale actions in Manual or
Automated mode.
You can create policies to control the scaling actions that Turbonomic generates.
• Turbonomic includes a policy setting that lets you choose between two outcomes – better savings (default) and
better reversibility. If you choose reversibility, which can increase costs, Turbonomic will prioritize actions to change
tiers whenever possible.
• Set scaling constraints if you want volumes to only scale to or avoid certain tiers. For details, see Cloud Storage Tiers
(on page 214).
Delete Actions
If you delete an Azure volume and then later deploy a new one with an identical name, charts will include historical data
from the volume that you deleted.
Exceptions for Azure Site Recovery and Azure Backup Volumes
Turbonomic discovers Azure Site Recovery and Azure Backup volumes when you add Azure targets. Even though these
volumes are always unattached, Turbonomic will never recommend deleting them because they are critical to business
continuity and disaster recovery.
To identify Azure Site Recovery volumes, Turbonomic checks an Azure resource called Recovery Services vault, which
includes information specific to the volumes. It also checks for the ASR-ReplicaDisk tag, which Azure automatically
assigns to the volumes.
For Azure Backup volumes, Turbonomic checks for the RSVaultBackup tag.
It is important that you do not remove these tags. If these tags have been removed for some reason, create a volume
policy for the affected volumes and disable the Delete action in that policy.
Volume Actions in Charts

Use the Necessary Investments and Potential Savings charts to view pending volume actions. These charts show total
monthly investments and savings, assuming you execute all the actions.

The table shows the following:
• Actions that are pending for each volume
• Savings or investments for each volume
• For Delete actions in the Potential Savings chart:
◦ Number of days a volume has been unattached

This information helps you decide whether to take the action.
Turbonomic polls your cloud volumes every 6 hours, and then records their state (attached or unattached)
at the time of polling. It does not account for changes in state between polls. An unattached period of 1 day
means that Turbonomic has discovered the volume as unattached in the last four polls.
Once Turbonomic discovers an unattached volume, it immediately recommends that you delete it. If a currently
unattached volume is not deleted and is subsequently discovered as attached, Turbonomic removes the Delete
action attached to it, and then resets the unattached period.
NOTE:
For volumes that have been deleted from the cloud provider and are no longer discoverable, Turbonomic
removes them from its records after 15 days.
To see the last known VM attached to the volume, click DETAILS.

◦ For Scale actions in the Potential Savings or Necessary Investments chart:
■ Whether actions are non-disruptive or reversible

■ Changes the actions will effect (for example, changes in tiers and/or resource allocations)
When you click the DETAILS button for a scaling action, you will see utilization charts that help explain the
reason for the action.

Utilization Charts for Volume Scaling Actions
Turbonomic uses percentile calculations to measure IOPS and throughput more accurately, and drive scaling actions that
improve overall utilization and reduce costs. When you examine the details for a pending scaling action on a volume,
you will see charts that highlight resource utilization percentiles for a given observation period, and the projected
percentiles after you execute the action.
volume, you can see the resulting improvements in daily average utilization. Put together, these charts allow you to
easily recognize utilization trends that drive Turbonomic's scaling recommendations.
NOTE:
You can set scaling sensitivity in volume policies to refine the percentile calculations. For details, see Scaling Sensitivity
(on page 212).
Non-disruptive and Reversible Scaling Actions

Turbonomic indicates whether a pending action is non-disruptive or reversible.

• Non-disruptive
Executing storage scaling actions can sometimes be disruptive if the VM must be rebooted to execute a storage
change. For example, Azure Standard and Premium scaling actions are disruptive. When a storage action is
disruptive, expect a single reboot (usually 2-3 minutes of downtime).
The following scaling actions are non-disruptive:
◦ Scaling IOPS and throughput on Azure Ultra storage
◦ All scaling actions on AWS storage
• Reversible
Executing storage scaling actions can sometimes be irreversible if the volume must grow in size to subsequently
increase IOPS or throughput capacity. In this case, shrinking that volume's size later would not be possible. If you
prefer reversible volume actions, create a volume policy and choose Better Reversibility.

Cloud Volume Policies


For details about cloud volume actions, see Cloud Volume Actions (on page 207).
Action Default Mode

Scale Manual
Delete Manual
Prefer Savings Over Reversibility

Executing storage scaling actions can sometimes be irreversible if the volume must grow in size to subsequently increase
IOPS or throughput capacity. In this case, shrinking that volume's size later would not be possible. If you prefer reversible
volume actions, create a volume policy and choose Better Reversibility.
Scaling Sensitivity
• Aggressiveness

Turbonomic uses Aggressiveness when evaluating IOPS and throughput.

For example, consider decisions to reduce capacity. Without using a percentile, Turbonomic never scales below
Turbonomic will not reduce resources for that volume.
allocation.

◦ 99th or 100th Percentile – More performance. Recommended for critical volumes that need maximum
guaranteed performance at all times, or those that need to tolerate sudden and previously unseen spikes in
utilization, even though sustained utilization is low.
◦ 90th Percentile – More efficiency. Recommended for volumes that can stand higher resource utilization.
By default, Turbonomic uses samples from the last 30 days. Use the Max Observation Period setting to adjust the
number of days.

uses historical data from up to the number of days that you specify as a sample period. If the volume has fewer
Choose from the following settings:

Choose from the following settings:
◦ Less Elastic – 1, 3, or 7 Days
Scaling Target IOPS/Throughput Utilization

This is the target utilization as a percentage of capacity.

Scaling Target IOPS/Throughput Utilization 70

Cloud Storage Tiers

By default, Turbonomic considers all storage tiers currently available for scaling when making scaling decisions for
volumes. However, you may have set up your cloud volumes to only scale to or avoid certain tiers to reduce complexity
and cost, or meet demand. Use this setting to identify the tiers that volumes can scale to.

Cloud Storage Tiers None
Premium) to see individual instance types.
Database (Cloud)
A Database is a fully managed database engine running in Azure environments. Turbonomic discovers SQL Databases
through your Azure targets. In particular, it discovers the single database resource type that uses the DTU (Database
Transaction Unit) purchase model. With this model, Azure bundles CPU, memory, and IOPS as a single DTU commodity.
Turbonomic monitors DTU and storage utilization for these databases, and drives scaling actions to improve utilization
and reduce costs.
NOTE:
For more information about DTUs, see the Azure documentation.
AWS RDS databases appear as Database Server entities in the supply chain. For details, see Database Server (Cloud)
(on page 189).

Synopsis
Synopsis
Budget: A database has unlimited budget.
Provides: Transactions to end users
Consumes: DTU and storage resources in the Azure region
Discovered through: Azure targets
Monitored Resources
Turbonomic monitors the following resources for a cloud database.
The monitored resources depend on the pricing model in place for the given database entity. To monitor DTU utilization,
the database must be a member of a DTU pricing model. To monitor individual VCPU, VMEM, or IOPs/Throughput
resources, the database must be a member of a vCore pricing model.
• DTU

For a DTU purchase model

DTU capacity for the database. DTU represents CPU, memory, and IOPS/IO Throughput bundled as a single
commodity.
For a vCore purchase model
The utilization of VMem allocated to the Database instance
The utilization of VCPU allocated to the Database instance
• Storage Access (IOPs/Throughput)
The IOPS and IO throughput utilized by the Database instance
• Storage
Storage capacity for the database.
Turbonomic drives scaling actions based on the utilization of these resources, and treats the following limits as
constraints when it makes scaling decisions:
• Maximum concurrent sessions
Maximum number of database connections at a time.
• Maximum concurrent workers
Maximum number of database processes that can handle queries at a time.
Actions
Scale
Scale DTU and storage resources to optimize performance and costs.
A single action can scale both DTU and storage. In some cases, Turbonomic might recommend scaling up storage, even
if there is no storage pressure on the database, to take advantage of storage provided at no extra cost. For example,
Turbonomic might recommend scaling from the S3 to the S0 tier because of low DTU and storage utilization. Since the
S0 tier includes 250 GB of storage at no extra cost, Turbonomic will also recommend scaling up to this storage amount.
If you want to scale DTU but keep the storage amount unchanged, adjust the values for aggressiveness (percentile) and
observation period in your database policies.
Actions in Charts
Use the Necessary Investments and Potential Savings charts to view pending database actions. These charts show total
monthly investments and savings, assuming you execute all the actions.

The table shows the following:
• Actions that are pending for each database
• Savings or investments for each database
Utilization Charts for Scale Actions

Turbonomic uses percentile calculations to measure DTU and storage utilization more accurately, and drive scaling
actions that improve overall utilization and reduce costs. When you examine the details for a pending scaling action on
a database, you will see charts that highlight DTU and storage utilization percentiles for a given observation period, and
the projected percentiles after you execute the action.
database, you can see the resulting improvements in daily average utilization. Put together, these charts allow you to
easily recognize utilization trends that drive Turbonomic's scaling recommendations.
NOTE:
You can set scaling constraints in database policies to refine the percentile calculations. For details, see Aggressiveness
and Observation Period (on page 218).

Cloud Database Policies


For details about cloud database actions, see Cloud Database Actions (on page 216).
Action Default Mode

Cloud DB Scale Manual
Scaling Sensitivity
Turbonomic uses these settings to calculate utilization percentiles for DTU and storage. It then recommends actions to
improve utilization based on the observed values for a given time period.
• Aggressiveness

For example, consider decisions to reduce capacity. Without using a percentile, Turbonomic never resizes below
Turbonomic will not reduce resources for that database.
allocation.
◦ 99th Percentile – More performance. Recommended for critical databases that need maximum guaranteed
performance at all times, or those that need to tolerate sudden and previously unseen spikes in utilization,
even though sustained utilization is low.

◦ 90th Percentile – More efficiency. Recommended for databases that can stand higher resource utilization.
By default, Turbonomic uses samples from the last 14 days. Use the Max Observation Period setting to adjust the
number of days.

uses historical data from up to the number of days that you specify as a sample period. If the database has fewer
◦ More Elastic – Last 7 Days or Last 3 Days
Turbonomic recommends an observation period of 14 days so it can recommend scaling actions more often. Since
Azure SQL DB scaling is minimally disruptive, with near-zero downtime, scaling often should not introduce any
noticeable performance risks.
NOTE:
For more information about Azure scaling downtimes, see the Azure documentation.

◦ Less Elastic – 7 Days

By default, Turbonomic considers all instance types currently available for scaling when making scaling decisions for
databases. However, you may have set up your cloud databases to only scale to or avoid certain instance types to reduce
complexity and cost, or meet demand. Use this setting to identify the instance types that databases can scale to.


Premium) to see individual instance types and the resources allocated to them.
NOTE:
This policy setting is not available in plans.

The utilization that you set here specifies the percentage of the existing capacity that Turbonomic will consider to be
100% of capacity.
The settings you make depend on the pricing model in place for the workloads in the policy scope. To meet a target
DTU utilization, the workloads must be members of a DTU pricing model. To meet individual VCPU, VMEM, or IOPs/
Throughput targets, the workloads must be members of a vCore pricing model.
Attribute DTU Pricing: Default Value vCore Pricing: Default Value

Scaling Target DTU Utilization 70 N/A
VCPU N/A 70
VMEM N/A 90
IOPs/Throughput N/A 70
Storage Amount Utilization 90 90
cloud.
Estimated On-demand Costs for Cloud Databases

Turbonomic considers a variety of factors when calculating Estimated On-demand Monthly Cost for an Azure SQL
Database.


Azure SQL DTU Databases

Cost Calculation
For Azure SQL DTU Databases, the calculation for Estimated On-demand Monthly Cost can be expressed as follows:
(On-demand Compute Rate * 730)) + (Provisioned Database Storage Rate * (Provisioned
Database Storage Amount - Performance Level Included Storage)) = Estimated On-demand
Monthly Cost
Where:
• On-demand Compute Rate is the hourly cost for a Database's instance type
You can obtain on-demand rates via Azure SQL Database Pricing.
• Provisioned Database Storage Rate is the cost for 1 GB / mo. of a Database's provisioned storage
You can obtain provisioned database storage rates via Azure SQL Database Pricing.
• Performance Level Included Storage is the storage amount included in the price of the selected Performance Level
of a DTU Database
You can obtain information on DTU storage limits via DTU Storage Limits.
Example
Assume the following data for a pending scale action for an Azure SQL DTU Database:


Provisioned Database Storage Rate $0.221 per 1 GB/Mo. $0.221 per 1 GB/Mo.
Performance Level Included Storage 250 GB 250 GB
Amount

($0.20125 * 730) + ($0.221 * (300 - 250)) = $157.96/Mo.
($0.020125 * 730) + ($0.221 * (250 - 250)) = $14.69/Mo.
NOTE:
The Estimated On-demand Monthly Cost is projected to decrease from $157.96/month to $14.69/month, as shown in
the Details section of the pending action.

Turbonomic treats the action as a saving, and shows an estimated savings of $143.27/month.

Azure SQL vCore Databases

Cost Calculation
For Azure SQL vCore Databases, the calculation for Estimated On-demand Monthly Cost can be expressed as follows:

(On-demand Compute Rate * 730) + (SQL License Rate * 730) + (Provisioned Database Storage
Rate * (Provisioned Database Storage Amount + Log Space Allocated)) = Estimated On-demand
Monthly Cost
Where:
• On-demand Compute Rate is the hourly cost for a Database's instance type
You can obtain on-demand rates via Azure SQL Database Pricing.
• SQL License Rate is the hourly cost for a Database's SQL license
You can obtain SQL license rates via Azure SQL Database Pricing.
Note: "Pay as you go" prices in the link above represent the sum of compute and license costs, while "Azure Hybrid
Benefit Price" values represent compute costs only.
• Provisioned Database Storage Rate is the cost for 1 GB / mo. of a Database's provisioned storage
• Log Space Allocated is the log storage space automatically allocated to single Database instance by Azure.
Example
Assume the following data for a pending scale action for an Azure SQL vCore Database:

SQL License Rate $0.799728/hr $0.199932/hr
Amount

($1.068 * 730) + ($0.799728 * 730) + ($0.115 * (32 + 9.6)) = $1368.23/Mo.
($0.304 * 730) + ($0.199932 * 730) + ($0.115 * (5 + 1.5)) = $368.62/Mo.
NOTE:

Zone
A Zone represents an Availability Zone in your public cloud account or subscription. A zone is a location within a given
region that serves as a datacenter to host the workloads that you run in your environment.
Synopsis

Synopsis
Budget: Turbonomic assumes a Zone has infinite resources.
Provides: Compute and storage resources to VMs.
Consumes: Region resources.
Discovered through: Turbonomic discovers Zones through public cloud targets.
Monitored Resources
For public cloud environments, Turbonomic discovers the resources that an availability zone provides, including:
• Templates
The templates and template families that each zone or region delivers. This includes template capacity and cost for
workload resources.
• Account Services
These include storage modes, services the accounts offer for enhanced metrics, and services for different storage
capabilities.

• Relational Database Services (RDS)

The RDS capabilities each cloud account provides.
• Storage Tiers
Turbonomic discovers the storage tier that supports your workloads, and uses the tier pricing to calculate storage
cost.
• Billing
Turbonomic discovers the billing across the zones and regions to predict costs in the future, and to track ongoing
costs. This includes comparing on-demand pricing to Reserved Instance billing.
Turbonomic monitors the following resources for a Zone:
• Virtual Memory
The percentage utilized of memory capacity for all the workloads in the zone.
• Virtual CPU
The percentage utilized of VCPU capacity for all the workloads in the zone.
• Storage Access
For environments that measure storage access, the percentage utilized of access capacity for the zone.
• Storage Amount
The percentage utilized of storage capacity for the zone.
• IO Throughput
For environments that measure IO throughput, the percentage utilized of throughput capacity for the zone.
For environments that measure IO throughput read, the percentage utilized of throughput capacity for the zone.
For environments that measure IO throughput write, the percentage utilized of throughput capacity for the zone.
• Net Throughput
For environments that measure Net throughput, the percentage utilized of throughput capacity for the zone.
For environments that measure Net throughput Inbound, the percentage utilized of throughput inbound capacity
for the zone.
• Net Throughput Outbound
For environments that measure Net throughput Outbound, the percentage utilized of throughput outbound
capacity for the zone.
Actions
None
Turbonomic does not recommend actions for a cloud zone.

Region
A Region represents a geographical area that is home to one or more Availability Zones. Regions are often isolated from
each other, and you can incur a cost for data transfer between them.
Synopsis

Synopsis
Budget: Turbonomic assumes a Region has infinite resources.
Provides: Hosting and storage resources to Zones.
Consumes: NA
Discovered through: Cloud service accounts, such as accounts on Amazon AWS, or subscriptions on Microsoft
Azure.
Monitored Resources
Turbonomic does not monitor resources directly from the region, but it does monitor the following resources,
aggregated for the Zones in a region:
• Virtual Memory
The percentage utilized of memory capacity for workloads in the zones.
• Virtual CPU
The percentage utilized of VCPU capacity for workloads in the zones.
• Storage Access

For environments that measure storage access, the percentage utilized of access capacity for the zones.
• Storage Amount
The percentage utilized of storage capacity for the zones.
• IO Throughput
For environments that measure IO throughput, the percentage utilized of throughput capacity for the zones.
For environments that measure IO throughput read, the percentage utilized of throughput capacity for the zones.
For environments that measure IO throughput write, the percentage utilized of throughput capacity for the zones.
• Net Throughput
For environments that measure Net throughput, the percentage utilized of throughput capacity for the zones.
For environments that measure Net throughput Inbound, the percentage utilized of throughput inbound capacity
for the zones.
• Net Throughput
For environments that measure Net throughput Outbound, the percentage utilized of throughput outbound
capacity for the zones.
Actions
None
Turbonomic does not recommend actions for a cloud region.

Entity Types - On-prem Infrastructure
Turbonomic discovers and monitors the entities that make up your on-prem infrastructure, and recommends actions to
assure performance for the applications that consume resources from these entities.


Virtual Machine (On-prem)

A virtual machine (VM) is a software emulation of a physical machine, including OS, virtual memory and CPUs, and
network ports. VMs host applications, or they provide resources to container platforms.
Synopsis

Synopsis
Budget: A VM gains its budget by selling resources to the applications it hosts. If utilization is high
enough, Turbonomic can allocate more resources to the VM, provision another instance,
or move the VM to a host that has more resources.
If utilization falls off, the VM loses budget. On the public cloud, if the budget isn't enough
to pay for the host services, Turbonomic can post an action to suspend the VM.
Provides: Resources for hosted applications to use:
• VMEM (Kbytes)
• VCPU (MHz)

Synopsis
• VStorage
• Memory and CPU Requests (for Kubernetes environments)
Consumes: • Physical host resources, including CPU and Mem
• Storage
Discovered through: Hypervisor targets
Monitored Resources
Turbonomic monitors the following resources for a VM:
• Virtual Storage (VStorage)
The utilization of the virtual storage capacity allocated for the VM
The utilization of IOPS allocated for the VStorage on the VM
Measured in IOPS
• Latency
The utilization of latency allocated for the VStorage on the VM
For VMs that host Kubernetes pods:
• Memory Request Allocation
The memory available to the VM to support the ResourceQuota request parameter for a given VDC (Kubernetes
namespace).
• CPU Request Allocation
The CPU available to the VM to support the ResourceQuota request parameter for a given VDC (Kubernetes
namespace).
• Virtual Memory Request
The memory currently requested by containers. The capacity for this resource is the Node Allocatable capacity (the
amount of resources available for pods).
• Virtual CPU Request

The CPU currently requested by containers. The capacity for this resource is the Node Allocatable capacity (the
amount of resources available for pods).
• MemAllocation
The memory ResourceQuota limit parameter for a given VDC (Kubernetes namespace).
• CPUAllocation
The CPU ResourceQuota limit parameter for a given VDC (Kubernetes namespace).
Actions
• Resize
◦ Resize resource capacity
Change the capacity of a resource that is allocated for the VM. For example, a resize action might recommend
increasing the VMem available to a VM. Before recommending this action, Turbonomic verifies that the VM's
cluster can adequately support the new size. If the cluster is highly utilized, Turbonomic will recommend a
move action, taking into consideration the capacity of the new cluster and compliance with existing placement
policies.
◦ Resize resource reservation
Change the amount of a resource that is reserved for a VM. For example, a VM could have an excess amount
of memory reserved. That can cause memory congestion on the host — A resize action might recommend
reducing the amount reserved, freeing up that resource and reducing congestion
◦ Resize resource limit
Change the limit that is set on the VM for a resource. For example, a VM could have a memory limit set on
it. If the VM is experiencing memory shortage, an action that decreases or removes the limit could improve
performance on that VM.
• Move
Move a VM due to:
◦ High resource utilization on VM or host
◦ Excess IOPS or latency in VStorage
◦ Workload placement violation
◦ Underutilized host (move VM before suspending host)
• Move VM Storage (Volume)
Move a VM's volume due to excess utilization of the current datastore, or for more efficient utilization of datastores
in the environment.
• Reconfigure
Change network and storage configuration. For example, Turbonomic recommends this action if the VM is
configured to use a network that it cannot access.
• Reconfigure VM Storage
Reconfigure overutilized storage resources by adding VStorage capacity. For underutilized storage resources,
remove VStorage capacity.
Actions for Kubernetes Nodes (VMs)

Provision
Provision nodes to address workload congestion or meet application demand.

When recommending node provision actions, Turbonomic also recommends pod provision actions that reflect the
projected demand from required DaemonSet pods, and respects the maximum number of pods allowed for a node. This
ensures that any application workload can be placed on the new node and stay within the desired range of vMem/vCPU
usage, vMem/vCPU request, and number of consumers.
The action details for a node provision action show the related DaemonSet pods that are required for the node to run.
Click a pod name to set it at your scope.

Suspend
Suspend nodes after you have consolidated pods or defragmented node resources to improve infrastructure efficiency.
When recommending node suspension actions, Turbonomic also recommends suspending the DaemonSet pods that are
no longer required to run the suspended nodes.
The action details for a node suspension action show the related DaemonSet pods that are no longer needed to run the
suspended nodes. Click a pod name to set it at your scope.

Tuned Scaling for On-prem VMs

For resizing VMs and Storage, Turbonomic includes tuned scaling action settings. These settings give 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 post more conservative actions (Manual or
Recommend) when the issue lies outside of the scaling range.
For example, consider resizing VMs to add more memory. As memory demand increases on a VM, Turbonomic can
automatically allocate more memory. If the hosted application is in a runaway state (always requesting more memory)
and ultimately falls outside of the normal range, Turbonomic will not automate memory resize for the VM.
To configure tuned scaling, create a VM or Storage policy (see Creating Automation Policies (on page 104)). Under
Action Automation, configure the action mode for the various resize actions, which are listed in the table below for your
reference. Note that Resize Up and Resize Down settings are for conditions within the tuned scaling range, while Above
Max and Below Min settings are for outlying conditions. Finally, under Operational Constraint, specify the tuned scaling
range.
Entity Type Resize Actions Operational Constraints

VM • VCPU Resize Up • VCPU Max Size
• VCPU Resize Down • VCPU Min Size
• VCPU Resize Above Max • VMEM Max Size
• VCPU Resize Below Min • VMEM Min Size
• VMEM Resize Up
• VMEM Resize Down
• VMEM Resize Above Max

Entity Type Resize Actions Operational Constraints

• VMEM Resize Below Min
Storage • Storage Resize Up • Storage Max Size
• Storage Resize Down • Storage Min Size
• Storage Resize Above Max
• Storage Resize Below Min
For example, assume the following settings:

With this policy in effect, Turbonomic will post the following actions:
• A VM with 6 VCPUs requests 2 new VCPUs: Automatic
• A VM with 8 VCPUs requests 2 new VCPUs: Manual
• A VM with 2 VCPUs requests to resize down to 1 VCPU: Disabled (Turbonomic does not post the action)
Action policies include scope to determine which entities will be affected by the given policy. It's possible for two or
more policies to affect the same entities. As is true for other policy settings, tuned scaling uses the most conservative
settings for the affected entities. The effective action mode will be the most conservative, and the effective tuned
scaling range will be the narrowest range (the lowest MAX and highest MIN) out of the multiple policies that affect the
given entities. For more information, see Policy Scope (on page 112).
You can schedule automation policies to take effect during a certain window of time. You can include tuned scaling
settings in a scheduled window, the same as you can schedule other policy settings. For more information, see Policy
Schedule (on page 113).

On-prem VM Policies

For details about on-prem VM actions, see On-prem VM Actions (on page 231).
Default
Action vCenter XenServer Hyper-V RHEV
Mode
vCPU Resize Down (uses tuned scaling (on page Manual
233))
vMem Resize Down (uses tuned scaling) Manual
Move Manual
vMem Resize Above Max (uses tuned scaling) Recommend
Provision Recommend
vMem Resize Up (uses tuned scaling) Manual
vCPU Resize Below Min (uses tuned scaling) Recommend
vCPU Resize Above Max (uses tuned scaling) Recommend
Storage Move Recommend With

VMM:
Otherwise:
Start Recommend
vMem Resize Below Min (uses tuned scaling) Recommend
Reconfigure (Change network and storage Recommend

configurations)
vCPU Resize Up (uses tuned scaling) Manual
Suspend Recommend
You can use Action Scripts (on page 119) 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.

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:
Hypervisor VMEM for Resize

For on-prem environments, Turbonomic discovers VMEM utilization and can recommend actions to resize the VMEM
capacity on a VM. For environments that do not include Applications and Databases as targets, the data that analysis
uses to make these recommendations comes from the underlying hypervisors. However, that data is not always
sufficient to result in accurate resize recommendations. Use the Use Hypervisor VMEM for Resize setting to determine
how to generate VMEM recommendations.

Hypervisor VMEM for Resize On
• On
When your environment includes Applications and Databases as targets, Turbonomic uses the VMEM metrics those
targets discover. If a scope of VMs does not fall under those targets, then analysis will generate VMEM resize actions
for that scope. In this case, analysis uses the VMEM metrics it discovers from the underlying hypervisors.
• Off
When your environment includes Applications and Databases as targets, Turbonomic uses the VMEM metrics those
targets discover. If a scope of VMs does not fall under those targets, then analysis will not generate VMEM resize
actions for that scope.
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.


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 mode for VM and storage moves to either Manual or
Automatic, and then enable the feature in a VM policy.

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 (Operational Constraints)

Turbonomic uses these settings to set up tuned scaling actions for the VM. For an overview of tuned scaling, see Tuned
Scaling for On-prem VMs (on page 233).

VCPU Resize Max Threshold (in Cores) 62
Tuned Scaling Range Upper Limit
VCPU Resize Min Threshold (in Cores) 2
Tuned Scaling Range Lower Limit
VMEM Resize Max Threshold (MB) 131072
Tuned Scaling Range Upper Limit


VMEM Resize Min Threshold (MB) 512
Tuned Scaling Range Lower Limit
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.

Resize VStorage Disabled
Increment constant for VStorage [GB] None
If you enable resize, Turbonomic uses the default value
Resize Increments
These increments specify how many units to add or subtract when resizing the given resource allocation for a VM.

Increment constant for VMEM [MB] 1024
Increment constant for VCPU [MHz] 1800
For resize increments, you should consider the following:

• For VMem, you should not set the increment value to be lower 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.
• For VCPU, the increment affects resize of VCPU limits and reservations in MHz, and it also affects the addition/
removal of cores for VCPU capacity on a VM.
For limits and reservations, Turbonomic recommends changes in terms of the specified resize increment. For
example, assume the increment is 1800 MHz and you have reserved 3000 MHz for a VM. Turbonomic could
recommend to reduce the reservation by 1800, down to 1200 MHz.
For VCPUs, Turbonomic can only resize allocation one core at a time. This means a resize is to the nearest core count
that matches or exceeds the resize increment. Assume the cores all have a clock speed of 2000 MHz. If the resize
increment is 1800 MHz, then a resize up will recommend to add one more core at 2000 MHz.
Rate of Resize
When resizing resources for a VM, Turbonomic calculates the optimal values for VMem, VCPU and VStorage. 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.


Rate of Resize Medium (2)
• 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
Enable Consistent Resizing Off
For groups in scoped policies:

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,
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:
For consistent resizing in on-prem environments, 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.
Reasons to employ Consistent Resizing for a group include:
• Load Balancing
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.
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.
Ignore NVMe Constraints

Turbonomic recognizes when a VM instance includes an NVMe driver. To respect NVMe constraints, it will not
recommend a move or resize to an instance type that does not also include an NVMe driver. If you ignore NVMe
constraints, then Turbonomic is free to resize or move the instance to a type that does not include an NVMe driver.

Ignore NVMe Constraints Off
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.
NOTE:
For VMM targets, Turbonomic 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 (on page 95).
Database Server (On-prem)

For on-prem, a Database Server is a database discovered through one of the associated database application targets or
through APM solutions.

Synopsis

Synopsis
Budget: On-prem Database Servers have unlimited budget.
Provides: • Response Time, Transactions, DBmem, Cache Hit Rate, and TransactionLog to end
users
• Connections to Application Components
Consumes: VM resources, including VCPU, VMem, and VStorage
Discovered through: • AppDynamics targets
• Database Server targets
• Dynatrace MySQL and MSSQL processes
• NewRelic Infrastructure Integration (NRI): MySql, MsSql, MongoDB, OracleDB
Monitored Resources
Turbonomic monitors the following resources for an on-prem Database Server:


• Transactions
Measured in transactions per second.
• DBMem
The memory utilized by the database, as a percentage of the memory capacity that is allocated to the database.
Note that this resource is more accurate than the VMem resource on the hosting VM. With this resource,
Turbonomic can drive resize and move actions based on the memory consumed by the database, not the memory
consumed by the VM.
• Connections
The utilization of the connection capacity. Only applicable to database servers
Measured in Connections
• DB Cache Hit Rate
The percentage of accesses that result in cache hits.
Measured as a percentage of hits vs total attempts (%)
Actions
Resize
Resize the following resources:
• Connections
• DBMem
• Transaction Log
Resize actions based on the Transaction Log resource depend on support for vStorage in the underlying hypervisor
technology. Because current versions of Hyper-V do not provide API support for vStorage, Turbonomic cannot
support Transaction Log resize actions for database servers running on the Hyper-V platform.
On-prem Database Server Policies


Action Default Mode
Resize Manual
Resize DBMem (Up/Down) Manual
You can use Action Scripts (on page 119) and third-party orchestrators (such as ServiceNow) for action orchestration.

Transaction SLO

Response Time SLO


DBMem Utilization
The utilization that you set here specifies the percentage of the existing capacity that Turbonomic will consider to be
100% of capacity.

DBMem Utilization (%) 100
For example, a value of 80 means that Turbonomic considers 80% utilization to be 100% of capacity. Turbonomic
recommends actions that avoid utilization beyond the given value.
DBMem Scaling Increment

This increment specifies how many units to add or subtract when scaling DBMem.

DBMem Scaling Increment (MB) 128
Do not set the increment value to be lower than what is necessary for the database server to operate. If the increment
is too low, then it’s possible there would be insufficient DBMem. When reducing allocation, Turbonomic will not leave
a database server with less than the increment value. For example, if you use the default 128, then Turbonomic cannot
reduce DBMem to less than 128 MB.

Volume (On-prem)
A volume is a storage device that you can attach to a VM. You can use an attached volume the same as a physical hard
drive.
Synopsis

Synopsis
Budget: An on-prem volume gains its budget by selling resources to the VMs that it serves.
Provides: Storage resources for VMs to use.
Set the scope to a volume and view the Entity Information chart to see a list of VM-
related files (such as VMDKs) contained in the volume.
Set the scope to a VM to see a list of volumes attached to the VM.
Consumes: Datacenter resources
Discovered through: Hypervisor targets
Actions
Move
Move a VM's volume due to excess utilization of the current datastore, or for more efficient utilization of datastores in
the environment. To evaluate and execute actions, set the scope to the VM to which a volume is attached.
NOTE:
The default global policy includes a setting that directs Turbonomic to use relevant metrics when analyzing and
recommending actions for volumes. For details, see Enable Analysis of On-prem Volumes (on page 103).

On-prem Volume Policies

Placement Policies
By default, all on-prem volumes associated with a storage will move together rather than independently. You can create
placement policies to to place individual volumes on groups of storage. To ensure successful placement, be sure to also
turn on the setting Enable Analysis of On-prem Volumes in the default global policy.
For more information, see Creating Placement Policies (on page 96) and Enable Analysis of On-prem Volumes (on page
103)

Action Default Mode
Move Manual
Cloud Storage Tiers

This policy setting works with plans that simulate migration of on-prem volumes to the cloud. When you create the
policy, be sure to set the scope to on-prem volumes and then select the cloud storage tiers that they can migrate to.
Turbonomic treats these tiers as constraints when you run a Migrate to Cloud plan that includes the volumes defined in
the policy.

Cloud Storage Tiers None
Premium) to see individual instance types.
Virtual Datacenter (Private Cloud)

A virtual datacenter (vDC) is a collection or pool of resources that groups the resources around specific requirements or
business needs. In private cloud environments, Turbonomic discovers the infrastructure that provides resources to the
cloud, and the workloads that run on the cloud. To manage these resources, private clouds organize the infrastructure
into Provider and Consumer Virtual Datacenters.

NOTE:
Different targets use different names to refer to Virtual Datacenters. In the Turbonomic supply chain, these entities
are all represented by Consumer and Provider VDCs, as follows:
Turbonomic vCloud Director vCenter Server VMM

Consumer VDC Organization VDC Resource Pool (Child) Tenant or TenantQuota
Provider VDC Provider VDC Resource Pool (Root) Cloud
Provider Virtual Datacenters

A provider virtual datacenter (vDC) is a collection of physical resources (hosts and datastores) within a cloud stack. The
cloud administrator has access to these resources, and defines the datacenter members. A Provider vDC is created to
manage resources that will be allocated to external customers through one or more Consumer vDCs.
Synopsis

Synopsis
Budget: A Provider vDC gains its budget by selling resources to the Consumer vDCs that it hosts.
If utilization falls off, the datacenter loses budget. Ultimately, if the budget isn’t enough
to pay for the services it consumes, Turbonomic will recommend decommissioning the
Provider vDC.
Provides: Physical resources such as hosts and datastores to Consumer vDCs.

Synopsis
Consumes: Hosts and datastores from the physical infrastructure
Discovered through: Turbonomic discovers vDCs through private cloud stack managers such as vCloud Director.
Monitored Resources
Turbonomic monitors the following resources for a Provider vDC:
• Memory (Mem)
The utilization of the Datacenter's memory reserved or in use
• CPU
The utilization of the Datacenter's CPU reserved or in use
• Storage
The utilization of the storage attached to the Provider vDC.
Actions
None
Turbonomic does not recommend actions for a Virtual Datacenter. Instead, it recommends actions for the entities that
provide resources to the Virtual Datacenter.
Consumer Virtual Datacenters

A Consumer Virtual Datacenter (vDC) is a collection of resources that are available for external customers to manage
workload through the private cloud. It is an environment customers can use to store, deploy, and operate virtual
systems. Consumer Datacenters use the resources supplied by a Provider Datacenter.

Synopsis

Synopsis
Budget: A Consumer vDC gains its budget as a function of its activity. The higher the utilization of
the vDC, the more Turbonomic assumes the vDC is selling its services to a user.
If utilization is high enough on a Consumer vDC, Turbonomic can increase resources for
the vDC. If utilization falls off, Turbonomic can reduce resource capacity, or ultimately
recommend terminating the vDC.
Turbonomic can also resize VMs through the Consumer vDC in response to changes in VM
utilization.
Provides: Resources to host virtual systems.
Consumes: Provider vDC
Discovered through: Turbonomic discovers vDCs through cloud stack managers such as vCloud Director.
While users can see some of the physical resources that support the Consumer vDC, consumer-level users cannot
modify these physical resources. Users of Consumer vDCs make changes to how the virtual devices are deployed in
that environment, but they must ask the Provider vDC administrator to add more physical resources to be used by the
Consumer vDC. Likewise, Turbonomic can change resources on the VMs running in the vDC, but it does not make any
changes to physical resources through this vDC.
Monitored Resources
Turbonomic monitors the following resources for a Consumer vDC:
• Memory (Mem)

The utilization of the Datacenter's memory reserved or in use

• CPU
The utilization of the Datacenter's CPU reserved or in use
• Storage
The utilization of the storage attached to the Consumer vDC.
Actions
Turbonomic does not recommend actions to perform on a Consumer vDC. Instead, it recommends actions to perform on
the entities running in the Provider vDC.
Business User
For Virtual Desktop Infrastructure (VDI) environments, a Business User is a user account that is entitled to launch one or
more active VDI sessions. As it discovers desktop pools, Turbonomic creates Business User entities for each user that is
entitled to a pool. One business user can be entitled to more than one desktop pool.
To properly work with Business User entities, Turbonomic discovers user information through the LDAP server that
manages users for the VDI environment. Note that the account Turbonomic uses to connect to the LDAP server must be
trusted for the same domains as are the users in your environment.

Synopsis

The Supply Chain shows relationships of Business Users to Desktop Pools and also to VMs. One Business User can have
access to multiple Desktop Pools. When a Business User has an active session, the Supply Chain shows a direct link
between the user and the VM that hosts the session. However, Turbonomic does not consider this direct connection
when analyzing compute resources. Instead, Business Users utilize Desktop Pool resources, and the Desktop Pools use
compute resources from the underlying Virtual Datacenters.
Synopsis
Budget: A Business User has unlimited budget.
Provides: N/A
Consumes: Resources from the underlying desktop pools:
• Sessions
• Pool Memory
• Pool Storage
• Pool CPU
When a Business User has an active session, the Supply Chain shows it in relation to the
VM that hosts the session. The Business User consumes the VM's compute resources to
support the session requirements for ImageCPU, ImageMem, and ImageStore resources.
Discovered through: The LDAP server that manages these users. You can specify the LDAP server as part of the
target configuration, or Turbonomic can discover it in association with the VDI target.

Monitored Resources
Turbonomic monitors the following resources for a Business User:
• ImageCPU
CPU utilization, as a percentage of CPU capacity for the user's desktop image or images.
• ImageMem
Memory utilization, as a percentage of Memory capacity for the user's desktop image or images.
• ImageStorage
Storage utilization, as a percentage of storage capacity for the user's desktop image or images.
Business User Actions

Move
Move a Business User between desktop pools to address:
• Resource congestion on the image
When utilization is consistently near capacity for image resources, Turbonomic can recommend moving a Business
User to a desktop pool that serves larger images.
• Resource congestion on the desktop pool
When utilization is consistently near capacity for the desktop pool, Turbonomic can recommend moving a Business
User to a desktop pool that has more available resources.
NOTE:
To support moves, you must configure placement policies that merge similarly configured desktop pools. For details,
see Desktop Pool Placement Policies (on page 256).
Business User Policies


For details about Business User actions, see Business User Actions (on page 251).
Action Default Mode

Move Recommend
Image Target Utilization

Turbonomic tracks utilization of desktop image resources for the Business Users in your Virtual Desktop Infrastructure
(VDI) environment.


Image CPU Target Utilization 70
The target utilization as a percentage of CPU capacity.
Image MEM Target Utilization 90
The target utilization as a percentage of memory
capacity.
Image Storage Target Utilization 90
The target utilization as a percentage of storage capacity.
Aggressiveness and Observation Period

Turbonomic uses these settings to calculate utilization percentiles. It then recommends actions to improve utilization
based on the observed values for a given time period.
• Aggressiveness

When evaluating utilization of compute and storage resources, Turbonomic considers a given utilization percentile.
For example, assume a 95th percentile. The maximum utilization would be the highest value that 95% of the
observed samples fall below.
Using a percentile, Turbonomic can recommend more relevant actions, so that analysis can better exploit elasticity
in your environment. A percentile evaluates the sustained resource utilization, and ignores bursts that occurred for
a small portion of the samples. You can think of this as aggressiveness of resizing, as follows:
◦ 100th Percentile – The least aggressive, recommended for critical workloads that need maximum guaranteed
performance at all times.
◦ 95th Percentile (Default) – The recommended setting to achieve maximum performance and savings.
◦ 90th Percentile – The most aggressive, recommended for non-production workloads that can stand higher
resource utilization.

To refine the calculation of resource utilization, 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.)
A shorter period means there are fewer data points to account for when Turbonomic calculates utilization
percentiles. This results in more dynamic, elastic moves to different Desktop Pools, while a longer period results in
more stable or less elastic moves. You can make the following settings:
◦ (Default) Most Elastic – Last 7 Days

Desktop Pool
For Virtual Desktop Infrastructure (VDI) environments, a desktop pool is a collection of desktops that users can select
from. The desktop pool can provide logical grouping of desktops according to user roles, assignment type (dedicated or
floating), and the source of resources (physical host or VM).
Synopsis

The desktop pool gets compute and storage resources from the underlying Virtual Datacenter. For VMware Horizon
View, the VDI architecture includes one or more vCenter Server instances. When it discovers the Horizon View target,
Turbonomic also discovers the supporting vCenter Server instances, and their corresponding Virtual Datacenters. These
are the source of compute and storage resources for the associated desktop pools.
Synopsis
Budget: A Desktop Pool gets its budget by selling resources to Business Users.
Provides: Resources for Business Users to use:
• PoolMEM
• PoolCPU
• Sessions
Consumes: • Compute and storage resources from the associated Virtual Datacenters
• Sessions from the underlying View Pod
Discovered through: The VDI management target.
For VMware Horizon View, the target is the View Connection Server.

Monitored Resources
Turbonomic monitors the following resources for a Desktop Pool:
• Pool CPU
The CPU available to the pool that is in use by active sessions.
• Pool Memory
The memory available to the pool that is in use by active sessions.
• Pool Storage
The storage capacity available to the pool that is in use by active sessions.
• Active Sessions
How many active sessions are on the pool as a percentage of the pool's capacity as defined in the Turbonomic
policy.
• Total Sessions
How many active and disconnected (non-terminated) sessions are on the pool, as a percentage of the pool's
capacity.
Actions
None
Turbonomic does not recommend actions for a desktop pool. It recommends actions for the Business Users running
active sessions in the pool.
Desktop Pool Policies


None
Turbonomic does not recommend actions for a desktop pool. It recommends actions for the Business Users running
active sessions in the pool.
Observation Settings
Turbonomic uses these settings to decide whether to move Business Users from one desktop pool to another.
• Daily Observation Windows

Daily observation windows 3 windows per day

When evaluating utilization of pool resources, Turbonomic divides each day into different observation windows,
calculates an average for each, and uses the highest value. In this way, Turbonomic can account for high-use periods
in the day to base calculations off of the most representative usage of the desktop images.
Assume three observation windows:
Window Time range Average utilization

W1 00:00 – 08:00 10%
W2 08:00 – 16:00 80%
W3 16:00 – 24:00 40%
Average utilization for this day without the benefit of observation windows would be 44%. By using observation
windows we can see that the representative utilization of pool resources is closer to 80%. That is because
Turbonomic discovers an average utilization of 80% during the high-usage time of day.
When calculating whether to move business users from one desktop pool to another, Turbonomic averages the
observation windows over the time you set for the Max Observation Period. For this reason, you should try to set
up observation windows that capture the best representation of work habits amongst your business users.

To refine the calculation of resource utilization, 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 Turbonomic database has fewer
days' data, then it uses all of its stored historical data.)
A shorter period means there are fewer data points to account for when Turbonomic calculates utilization. This
results in more dynamic, elastic resizing, while a longer period results in more stable or less elastic resizing. You can
make the following settings:
Pool Utilization
These settings affect the actions Turbonomic recommends as it manages business users and active accounts on the
desktop pool. Turbonomic recommends actions that avoid using these resources beyond the given settings.

Pool CPU Utilization 95
Pool Mem Utilization 95
Pool Storage Utilization 95
The values you set here specify what percentage of the existing capacity that Turbonomic will consider to be 100% of
capacity. For example, setting 70 for Desktop Pool Pool CPU Utilization means that Turbonomic considers 70% utilization
of that CPU to be 100% of capacity and 35% utilization to be 50% of capacity.

Placement Policies
Under some circumstances, you can have Business Users who need larger desktop images. This appears as users with
high utilization of the image resources. In this case, Turbonomic can recommend moving the Business Users to a
different desktop pool that serves up larger images.
To support moving Business Users, you must create a placement policy that merges desktop pools. Be sure to merge
only desktop pools that are similarly configured – they should run the same operating system and applications, and
differ only in allocated memory and/or CPU.
To merge desktop pools:
1. Create a new placement policy.
2. Choose Merge as the policy type.
3. For the consumer type to merge, choose Desktop Pool.
4. Choose the pools that you want to merge.
5. Save the policy.
View Pod
For Virtual Desktop Infrastructure (VDI) environments, a View Pod groups together a given set of Desktop Pools.
Synopsis

Synopsis
Budget: A View Pod has unlimited budget.
Provides: Active Sessions.
Consumes: N/A
Discovered through: The VDI management target.
For VMware Horizon View, the target is the View Connection Server.

Monitored Resources
Turbonomic monitors the following resources for a Desktop Pool:
• Active Sessions
How many active sessions are on the pool as a percentage of the pool's capacity as defined in the Turbonomic
policy.
• Total Sessions
How many active and disconnected (non-terminated) sessions are on the pool, as a percentage of the pool's
capacity.
Actions
None
Turbonomic does not recommend actions for a view pod. Instead, it recommends actions for the Business Users that are
running active sessions.
Active Session Capacity for View Pods

Each View Pod entity has a set capacity of active sessions. By default, Turbonomic assumes a capacity of 8,000. So that
Turbonomic can generate reliable actions for Business User entities, you must set this capacity to match the active
session capacity that your Horizon administrator has deployed for the given view pod.
Once you know the correct active session capacity for your view pod, create an automation policy that sets the capacity.
For complete information about creating automation policies, see Creating Scoped Automation Policies (on page 104).
For information about view pod policies, see View Pod Policies (on page 258).
1. Create a new scoped automation policy.
Navigate to the Settings Page and choose Policies. Then click NEW AUTOMATION POLICY, and select View Pod as
the policy type. Be sure to name the new policy.
2. Set the policy scope to your view pod.
To define its scope, you assign a group to the policy. You will have to create the group for this view pod:
• Expand the SCOPE section and then click ADD VIEW POD GROUPS.
• Choose the group that contains only the view pod you want to configure.
If it has already been created, choose the group from the list. If the group does not appear, click NEW GROUP
to create a static group that includes only the view pod you want to configure. For more information about
creating groups, see Creating Groups (on page 409).
Choose the group you want and click SELECT. This returns you to the Configure View Pod Policy fly-out.
3. Set the view pod capacity.
Expand the UTILIZATION CONSTRAINTS section and click ADD UTILIZATION CONSTRAINT. From the drop-down
list, choose Active Sessions Capacity. In the capacity field, enter the capacity that you have calculated for your
desktop pools.
4. Save your work
When you're done, be sure to click SAVE AND APPLY.

View Pod Policies


None
Turbonomic does not recommend actions for a view pod. Instead, it recommends actions for the Business Users that are
running active sessions.
Active Sessions Capacity

This setting controls the number of active sessions a given view pod can support.

Active Sessions Capacity 8000
For each view pod, you should set this value to match the active session capacity that has been deployed in your VDI
environment for the given view pod. For more information, see Active Session Capacity for View Pods (on page 257).
Host
For on-prem environments, a host is a server that runs processes, including hypervisor processes to host virtual
workloads. Note that a host is not necessarily a physical piece of hardware. A VM can be set up as a server that runs
a hypervisor, and in turn it can host other VMs within its processing space. However, it’s most usual to use physical
hardware as your hosts.
NOTE:
To support vSAN storage in your environment, you can deploy HCI Hosts. Turbonomic discovers the vSAN as a storage
entity that consumes resources from the underlying hosts. For more information, see vSAN Storage (on page 268).
On the public cloud a host is an availability zone. This is where your cloud workloads run. For details, see Zone (on
page 224).

Synopsis

Synopsis
Budget: A host gains its budget by selling resources to the workloads that run on it. The more
workloads running on a host, the more budget the host has to purchase storage and
datacenter resources. If utilization of a host is high enough, Turbonomic can recommend
that you provision a new one. If utilization falls off, the host loses budget. Ultimately, if
the budget isn’t enough to pay for the services it consumes, Turbonomic will recommend
to suspend or power off the host.
Provides: Host resources for VMs to use:
• Mem (Kbytes)
• CPU (MHz)
• IO (throughput on the I/O bus)
• Net (network throughput)
• Swap (swap rate capacity measured in bytes/sec)
• Ballooning (sharing of memory among hosted VMs)
• CPU Ready Queue (wait time on the queue in ms)
Consumes: Datacenter resources (physical space, cooling, etc.) and storage.
Discovered through: Turbonomic discovers hosts through hypervisor targets. For some hypervisor vendors, the
host is the target, and for others the hosts are managed by the specified target.
Monitored Resources
Turbonomic monitors the following resources on a host:
• Memory (Mem)
The utilization of the PM's memory reserved or in use


• CPU
The utilization of the PM's CPU reserved or in use
• IO
The utilization of the PM's IO adapters
Measured in Kilobytes per second (KB/s)
• Net
The utilization of data through the PM's network adapters
• Swap
The utilization of the PM's swap space
• Balloon
The utilization of shared memory among VMs running on the host. ESX-only
• CPU Ready
The utilization of the PM’s allocated ready queue capacity (measured in Kbytes) that is in use, for 1, 2, and 4 CPU
ready queues. ESX-only
Actions
• Start
Start a suspended host when there is increased demand for physical resources.
• Provision
Provision a new host in the environment when there is increased demand for physical resources. Turbonomic can
then move workloads to that host.
• Suspend
When physical resources are underutilized on a host, move existing workloads to other hosts and then suspend the
host.
• Reconfigure
Turbonomic generates this action in response to changing demand for software licenses. For details, see License
Policy (on page 99).
NOTE:
Turbonomic discovers VMware HA configurations in clusters, and considers the reserved resources in its calculations.
For tolerated host failures, or a reserved percentage of cluster resources, Turbonomic automatically sets utilization
constraints for that cluster. If you configure a failover host, Turbonomic reserves that host for HA and will not move
VMs to it.

DRS Automation Settings

Turbonomic automatically discovers DRS automation settings for vSphere hosts managed through vCenter. When you set
the scope to a vSphere host and then view the Entity Information chart, the following information displays:
• Vendor Automation Mode
The chart shows the automation mode discovered from vCenter – Not Automated, Partially Automated, or Fully
Automated.
• Vendor Migration Level
Turbonomic assigns a vendor migration level based on the migration level discovered from vCenter. The chart only
shows the assigned migration level (i.e., the Turbonomic Vendor Migration Level).
Turbonomic Vendor Migration Level vCenter Migration Level

1 (Conservative) 5
2 (Less Conservative) 4
3 (Moderate) 3
4 (Less Aggressive) 2
5 (Aggressive) 1
Host Policies

For details about host actions, see Host Actions (on page 260).
Action Default Mode vCenter XenServer Hyper-V RHEV UCS (blades only)
Start Recommend
Suspend Recommend
Provision Recommend
Reconfigure Recommend
You can use Action Scripts for action orchestration.

For ServiceNow:
• Host provision actions will not generate a CR.
• For host suspend actions to succeed, it must be enabled in the given hypervisor, and there must be no VMs
currently running on that host.

Utilization Constraints
Utilization constraints affect the actions Turbonomic recommends as it manages your environment. Turbonomic
recommends actions that avoid using these resources beyond the given settings. The values you set here specify what
percentage of the existing capacity that Turbonomic will consider to be 100% of capacity.

Memory Overprovisioned Percentage 1000
Net Throughput 50
Ready Queue Utilization 50
Memory Utilization 100
IO Throughput 50
CPU Overprovisioned Percentage 1000
CPU Utilization 100
Swapping Utilization 20
For example:
• Setting 50 for Net Throughput means that Turbonomic considers 50% utilization of that throughput to be 100% of
capacity and 25% utilization to be 50% of capacity
• Setting 1000 for Memory Overprovisioned Percentage means that overprovisioning memory by 5 times the physical
capacity shows up as 50% utilization of the Mem Overprovisioned capacity in Turbonomic
• Setting 100 for Memory Utilization means that Turbonomic capacity reflects the physical capacity for this resource
Desired State
The desired state for your environment is an n-dimensional sphere that encompasses the fittest conditions your
environment can achieve.

Diameter 10
Center 70
The multiple dimensions of this sphere are defined by the resource metrics in your environment. Metric dimensions
include VMem, storage, CPU, etc. While the metrics on the devices in your environment can be any value, the desired
state, this n-dimensional sphere, is the subset of metric values that assures the best performance while achieving the
most efficient utilization of resources that is possible.
The Desired State settings define the center of the sphere as well as its diameter. This is a way for you to customize what
Turbonomic considers to be the desired state.
Setting the center of the sphere chooses the priority for Turbonomic analysis. If you set the balance in favor of efficiency,
Turbonomic tends to place more VMs on fewer physical hosts, and to give them storage capacity from fewer data stores.
As a result, high utilization can have more impact on QoS. With a balance in favor of performance, Turbonomic tends to
spread virtual loads across more physical devices. This can result in the provisioning of excess resources.

The diameter setting determines the range of deviation from the center that can encompass the desired state. If you
specify a large diameter, Turbonomic will have more variation in the way it distributes workload across hosting devices.
As you move each slider, a tooltip displays the numerical value of the setting. Center indicates the percentage of
resource utilization you want, within the range you specify as Diameter. For example, if you want utilization of 75%, plus
or minus 10%, then you would set Center = 75 and Diameter = 20. Turbonomic recommends actions that tend toward
this desired state much as possible, given the dependencies within the current environment.
NOTE:
The setting for Target Utilization can have an effect on plans that you run. If you disable provisioning and suspension
for hosts and datastores, then you should always set Center and Diameter to their default values.
Placement Policies
You can create placement policies that merge multiple clusters into a single logical group for the purpose of workload
placement.
For example, you can merge three host clusters in a single provider group. This enables Turbonomic to move workload
from a host in one of the clusters to a host in any of the merged clusters to increase efficiency in your environment.
NOTE:
For vCenter, Turbonomic automatically imports any vSphere Host DRS rules when DRS is enabled, and displays them
on the Settings > Policies page under Imported Placement Policies.
For more information, see Importing Workload Placement Policies (on page 95).
Chassis
A chassis houses the servers that are part of a computing fabric. It provides compute, memory, storage, and bandwidth
resources.
Synopsis

Synopsis
Budget: A Chassis has unlimited budget.
Provides: Chassis resources (physical space, cooling, etc.).
Consumes: N/A
Discovered through: Turbonomic discovers Chassis through fabric manager targets.

NOTE:
When Turbonomic discovers that blade servers housed in a particular chassis have been designated as vCenter hosts,
the supply chain stitches the blade servers and chassis to the corresponding vCenter datacenter to establish their
relationship. When you set the scope to that datacenter and view the Health chart, you will see the blade servers
in the list of hosts. In addition, when the datacenter is included in a merge policy (a policy that merges datacenters
for the purpose of VM placement), the VMs in the blade servers apply the policy, allowing them to move between
datacenters as necessary.
Monitored Resources
Turbonomic monitors the following resources for the servers in a chassis:
• Power
Electricity being consumed by the Chassis
Measured in Watts (W)
• Cooling
The percentage of the acceptable temperature range that is utilized by this chassis. As the chassis temperature
nears the high or low running temperature limits, this percentage increases.
Actions
None
Turbonomic does not recommend actions for a chassis.
Datacenter
A datacenter is the sum of VMs, PMs, datastores, and network devices that are managed by a given hypervisor target. A
datacenter provides compute, memory, storage, and bandwidth resources.
NOTE:
For public cloud environments, a datacenter is the cloud region. The hosts that get resources from the datacenter are
availability zones within that region. For details, see Region (on page 226) and Zone (on page 224).

Synopsis

Synopsis
Budget: A Datacenter has unlimited budget.
Provides: Compute, memory, storage, and bandwidth resources
Consumes: N/A
Discovered through: Turbonomic discovers Datacenters through hypervisor targets.
NOTE:
When Turbonomic discovers that blade servers housed in a particular chassis have been designated as vCenter hosts,
the supply chain stitches the blade servers and chassis to the corresponding vCenter datacenter to establish their
relationship. When you set the scope to that datacenter and view the Health chart, you will see the blade servers
in the list of hosts. In addition, when the datacenter is included in a merge policy (a policy that merges datacenters
for the purpose of VM placement), the VMs in the blade servers apply the policy, allowing them to move between
datacenters as necessary.
Monitored Resources
Turbonomic does not monitor resources directly from the datacenter, but it does monitor the following resources,
aggregated for the hosts in a datacenter:
• Memory (Mem)
The utilization of the PM's memory reserved or in use
• CPU
The utilization of the PM's CPU reserved or in use
• IO
The utilization of the PM's IO adapters


• Net
The utilization of data through the PM's network adapters
• Swap
The utilization of the PM's swap space
• Balloon
The utilization of shared of memory among VMs running on the host. ESX-only
• CPU Ready
The utilization of the PM’s allocated ready queue capacity (measured in Kbytes) that is in use, for 1, 2, and 4 CPU
ready queues. ESX-only
Actions
None
Turbonomic does not recommend actions for a datacenter. Instead, it recommends actions for the entities running in
the datacenter.
Placement Policies
For vCenter environments, you can create placement policies that merge datacenters to support cross-vCenter moves. In
this case, where a datacenter corresponds to a given vCenter target, the merged clusters can be in different datacenters.
In this case you must create two merge policies; one to merge the affected datacenters, and another to merge the
specific clusters.
Storage
Turbonomic represents storage as Datastores. A Datastore is a logical grouping of one or more physical storage devices
that serve workload storage requirements.

Synopsis

Synopsis
Budget: A Datastore gains its budget by selling resources to the VMs it serves. If utilization of a
Datastore is high enough, Turbonomic can recommend that you provision a new one.
Provides: Host resources for VMs to use:
• Storage amount
Consumes: Disk arrays (or aggregates)
Discovered through: Turbonomic discovers on-prem Datastores through hypervisor targets and storage
controllers.
Monitored Resources
Turbonomic monitors the following resources for a datastore:
• Storage Amount
The utilization of the datastore's capacity
• Storage Provisioned
The utilization of the datastore's capacity, including overprovisioning.
The summation of the read and write access operations per second on the datastore
Measured in Operations per second
NOTE:
When it generates actions, Turbonomic does not consider IOPS throttling that it discovers on storage entities.
Analysis uses the IOPS it discovers on Logical Pool or Disk Array entities.
• Latency
The utilization of latency on the datastore

Storage Actions
• Move
For high utilization of physical storage, move datastore to a different disk array (aggregate).
• Provision
For high utilization of storage resources, provision a new datastore.
• Resize
Increase or decrease the datastore capacity.
• Start
For high utilization of storage resources, start a suspended datastore.
• Suspend
For low utilization of storage resources, move served VMs to other datastores and suspend this one.
• Delete
Delete a datastore or volume that has been suspended for a period of time.
Storage resize actions use Turbonomic tuned scaling settings. This gives you increased control over the action mode
Turbonomic will use for the affected actions. For an overview of tuned scaling, see Tuned Scaling for On-prem VMs (on
page 233).
You can create placement policies to enforce constraints for storage move actions. For example, you can have a policy
that allows storage to only move to certain disk arrays, or a policy that prevents storage from moving to certain disk
arrays.
vSAN Storage
Overview

For environments that use hyperconverged infrastructure to provide storage on a vSAN, Turbonomic can discover the
storage provided by a host cluster as a single Storage entity. This Storage entity represents the full storage capacity that
is provided by that host cluster.

Turbonomic supports VMware vSAN, but does not support stretched VSAN clusters. Adding stretched clusters can cause
the generation of incorrect storage recommendations and actions.
Turbonomic supports VMware vSAN.
vSAN Storage Capacity

When you consider vSAN capacity, you need to compare Raw Capacity with Usable Capacity.
• Raw Capacity
• Turbonomic discovers Raw Capacity configured in vCenter and uses it to calculate Usable Capacity. Raw Capacity
displays in the Entity Information chart.
• Usable Capacity
Turbonomic calculates Usable Capacity and then uses the calculated value to drive scaling actions. Turbonomic can
recommend scaling the Storage Amount, Storage Provisioned, or Storage Access capacity. Usable Capacity displays
in the Capacity and Usage chart.
Usable Capacity Calculation

To calculate Usable Capacity, Turbonomic considers a variety of attributes, including:
• Raw Capacity and Largest Host Capacity
Turbonomic compares the Raw Capacity for all the hosts in the cluster and then uses the largest value as Largest
Host Capacity.
• RAID Factor
Turbonomic calculates RAID Factor based on the Failures to Tolerate (FTT) value and Redundancy Method that it
discovers. FTT specifies how many failures a given cluster can tolerate, while Redundancy Method specifies the RAID
level for the cluster.
FTT Redundancy Method RAID Factor

0 RAID1 1
1 RAID1 1/2
2 RAID1 1/3
1 RAID5/6 3/4
2 RAID5/6 2/3
NOTE:
If discovery fails for some reason, Turbonomic uses a RAID Factor of 1.
• Host Capacity Reservation, Slack Space Percentage, and Compression Ratio
You can control the values for these attributes in storage policies. For details about these attributes and their effect
on usable capacity calculations, see Hyper-converged Infrastructure Settings (on page 274).
The calculation for Usable Capacity can be expressed as:
Usable Capacity = (Raw Capacity - Largest Host Capacity * Host Capacity Reservation) *
Slack Space Percentage * RAID Factor * Compression Ratio
If the result of the calculation is zero or a negative value, Turbonomic sets the Usable Capacity to 1 MB.

Capacity and Usage Chart for vSAN Storage

The Capacity and Usage chart for vSAN storage shows two Storage Amounts - Consumed (bought) and Provided (sold).
This is because vSAN storage can buy and sell commodities to hosts.
For the Provided Storage Amount, the Capacity value corresponds to Usable Capacity, while the Used value indicates
utilization.
Entity Information Chart for vSAN Storage

The Entity Information chart includes the following information:
• HCI Technology Type
The technology that supports this storage cluster. For this release, Turbonomic supports VMware vSAN technology.
• Capacity
Turbonomic displays rounded values for the following, which might be slightly different from the values it discovers
from vCenter:
◦ Raw Capacity
The sum of the Raw Capacity that each storage capacity device provides.
◦ Raw Free Space
How much of the Raw Capacity is not currently in use.
◦ Raw Uncommitted Space
In terms of Raw Capacity, how much space is available according to your thin/thick provisioning.
• Redundancy Method and Failures to Tolerate
Redundancy Method specifies the RAID level employed for the cluster. RAID level impacts how much Usable
Capacity you can see for a given Raw Capacity. You can use a RAID calculator to determine how the RAID level
impacts your Usable Capacity.
Failures to Tolerate specifies how many capacity device failures a given cluster can tolerate. In practical terms, this
means how many hosts can come down at the same time, without affecting storage. This value should match the
RAID level.
Actions to Add vSAN Capacity

To scale up storage amount, you add additional hosts that are configured to include their storage in the vSAN array.
When you scope the session to the vSAN storage, you can see actions to scale:
• Storage Amount
• Storage Access
The action to scale up the storage indicates the amount of storage you need to add. It appears as a recommended
action. In fact, to add storage you must add a new host.
When you scope the session to hosts that provide the capacity devices to the storage, you can see the following actions
that are related to scaling up the storage capacity:
• Scale up StorageAmount for Storage [MyVsanStorageCluster]
• Provision Host [VSAN_HostName]

The action to provision a host includes details about the storage cluster. Because you need to manually add hosts to
your on-prem environment, this appears as a recommended action.
Planning With vSAN Storage

For Hardware Replace and Custom plans, you can use HCI Host templates to add vSAN capacity. These represent the
hosts that add storage capacity to a vSAN cluster. For more information, see HCI Host Template Settings (on page
422).
Under certain circumstances, Add Virtual Machines plans can fail to place workloads, or it can fail to generate actions to
increase storage capacity by provisioning new hosts.
• If you scope the plan to a user-created group that only provides vSAN storage, or to a discovered storage cluster
group, then the plan can fail to place VMs with multiple volumes. This can occur for VMs that use conventional
storage (not vSAN) along with vSAN storage.
• If you scope the plan to a vSAN host group and add VMs, the plan can fail to increase storage capacity by
provisioning new hosts. For example, assume you scope the plan to a vSAN host group and add 20 VMs to the
environment. In that case, you need hosts to provide compute capacity for the VMs, and you also need hosts to
provide storage capacity. The plan can represent the compute provisioning correctly, but it can incorrectly fail to add
more storage capacity to the vSAN.
• If the vSAN RAID type is Raid6/FTT=2, if you scope the plan to any vSAN groups then the plan will fail to place any
of the VMs.
Storage Policies

The following are the storage actions and automation support for environments that do not include Disk Array Storage
Controllers as targets. For details about these actions, see Storage Actions (on page 268).
Default Hyper-
Action vCenter XenServer RHEV
Mode V
Delete (Volume) Recommend
Suspend Manual
Delete (Datastore) Disabled
Move Recommend
Provision Recommend
Start Recommend

Default Hyper-
Action vCenter XenServer RHEV
Mode V
Resize (Up, Down, Above Max, or Below Min - using tuned Recommend
scaling)
For datastores on disk arrays:
Default Dell NetApp Pure

Action HP 3Par VNX VMAX Nutanix
Mode Compellent ONTAP Storage
Delete (Volume) Recommend Not
supported
Suspend Manual
Delete (Datastore) Disabled Not

supported
Move Recommend Not
supported
Provision Recommend
Start Recommend
Resize (Up, Down, Recommend

Above Max, or Below
Min - using tuned
scaling)
You can use Action Scripts for action orchestration.

For ServiceNow:
• Storage suspend and vSAN storage resize actions will not generate a CR.
• Currently Turbonomic can only execute a CR for storage provision actions on Pure and Dell Compellent storage.

Storage Amount Utilization 90
IOPS Utilization 100
Latency Utilization 100
For example, setting 90 for Storage Amount Utilization means that Turbonomic considers 90% utilization of the physical
storage to be 100% of capacity.

Storage Settings
Directories to Ignore \.dvsData.*|\.snapshot.*|\.vSphere-HA.*|\.naa.*|
\.etc.*|lost\+found.*
Files to Ignore Empty String
Storage Latency Capacity [ms] 100
Storage Overprovisioned Percentage 200
IOPS Capacity 50000
• Wasted Storage Management

You can make settings to control how Turbonomic tracks and reports on wasted storage in your environment.
Wasted storage is any disk space devoted to files that are not required for operations of the devices or applications
in your environment. Wasted storage may indicate opportunities for you to free up disk space, and provide more
storage capacity to running VMs and applications.
NOTE:
It’s possible that a single datastore can be managed by more than one instance of vCenter Server. Browsing over
such a datastore can result in conflicting values for wasted storage in reports and in the Improve Overall Efficiency
dashboard. You should not enable datastore browsing for a scope that includes such a datastore.
If there are groups of datastores you don’t want to track for wasted storage, set the given scope and disable
datastore browsing there. If you prefer not to use Turbonomic resources to track wasted storage, leave the global
setting checked.
The settings for Directories to Ignore and Files to Ignore specify directories and files that Turbonomic will not
consider when looking for wasted data storage space. Separate items in these lists with the OR bar (“|”).
• Storage Latency Capacity
This sets the maximum storage latency to tolerate on a datastore, in ms. The default setting is 100 ms.
Turbonomic measures the latency experienced by all VMs and hosts that access the datastore. Assume a default
setting of 100 ms. If a datastore exhibits latency of 50 ms, then the Turbonomic will show latency utilization of 50%.
For VMAX environments, Turbonomic discovers SLO for storage latency that you set in VMAX and uses it in analysis.
However, if you set a higher storage latency value in a Turbonomic policy, analysis will use that value instead.
• Storage Overprovisioned Percentage
Storage Overprovisioned Percentage sets how much overprovisioning Turbonomic assumes when recommending
actions for VM datastores. For example, if a datastore has a 30 GB capacity, and Storage Overprovisioned
Percentage is set to 200, Turbonomic will treat the datastore as though it has a capacity of 60 GB, or 200% of the
actual datastore capacity.
• IOPS Capacity
IOPS Capacity is the IOPS setting for individual datastores. To set a specific capacity for one group of datastores,
select that group as the property scope and override the global setting for that scope.
Note that IOPS capacity for a disk array takes precedence — Datastores that are members of a disk array always
have the IOPS capacity that is set to the disk array.

Turbonomic considers these settings when calculating utilization percentage. For example, assume IOPS Capacity of
500 for datastores. If utilization on a datastore is 250 IOPS, then the datastore is at 50% of capacity for that metric.
Scaling Constraints
This setting controls how many GB to add or subtract when resizing the allocation for a datastore.

Increment Constant for Storage Amount [GB] 1 GB
Hyperconverged Infrastructure Settings

Turbonomic considers these settings when calculating capacity and utilization for hyperconverged environments.

Host Capacity Reservation 1
Host IOPS Capacity 50000
Slack Space Percentage 25
Compression Ratio 1
Usable Space Includes Compression Off
NOTE:
Turbonomic uses Host Capacity Reservation, Slack Space Percentage, and Compression Ratio to calculate vSAN usable
capacity and drive scaling actions. For more information about usable capacity and how it is calculated, see vSAN
Storage (on page 268).
• Host Capacity Reservation

When a host must be taken out of service for maintenance, vSphere will evacuate the data from that host and move
it to other hosts in the cluster to maintain the integrity of the replication demanded by the storage policy. For this to
happen, there must be enough free raw capacity available to accept the data being evacuated.
Turbonomic uses this setting to determine how many hosts worth of capacity it should subtract from the raw
capacity amount before calculating usable capacity. This is not the same as redundancy. It does not specify how the
array distributes data to maintain integrity.
• Host IOPS Capacity
In addition to calculating usable capacity, Turbonomic needs an estimate of datastore IOPS capacity (storage
access). Turbonomic uses the value that you set to provide an estimate of effective IOPS capacity for each host in
the cluster. Total IOPS capacity is the number of hosts in the cluster multiplied by Host IOPS Capacity.
• Slack Space Percentage
It is recommended that a vSAN datastore never be filled to prevent vSphere from moving objects/files around the
cluster to balance the datastore across all the hosts.
Turbonomic reduces usable capacity by the percentage that you set.
• Compression Ratio
vSAN supports both deduplication and compression, which may increase the amount of usable capacity on the
datastore. Turbonomic does not try to predict the deduplication or compression ratio, but you can choose to include

a compression ratio into the usable capacity calculation. This captures the ratio achieved both by compression and
deduplication.
The compression ratio that you set acts as a multiplier on the raw capacity to calculate usable capacity. For
example, a compression ratio of 2 would double the amount of usable capacity. The default value of 1 means no
compression.
• Usable Space Includes Compression
Turn this on if you want Turbonomic to consider the compression ratio when calculating storage utilization and
capacity. Whether this is on or off, Turbonomic always considers compression when calculating utilization of
StorageProvisioned.
Placement Policies
Turbonomic supports placement policies for storage and storage clusters.
• You can create placement policies to enforce constraints for storage move actions. For example, you can have a
policy that allows storage to only move to certain disk arrays, or a policy that prevents storage from moving to
certain disk arrays.
• You can create placement policies that merge multiple clusters into a single logical group for the purpose of
workload placement.
Logical Pool
A logical pool represents storage resources that are managed together and presented as a single storage system.
Turbonomic analysis identifies performance and efficiency opportunities for a logical pool. For example, it can
recommend moving resources into or out of a logical pool, or aggregating resource capacity within the pool.

Synopsis

Synopsis
Budget: N/A
Provides: Storage resources
Consumes: Disk array resources
Discovered through: Storage targets
Monitored Resources
Turbonomic monitors the following resources for a logical pool:
• Storage Amount
The utilization of the logical pool's capacity.
The utilization of the logical pool's capacity, including overprovisioning.
The summation of the read and write access operations per second on the logical pool.
• Latency
The utilization of latency on the logical pool.

Logical Pool Actions

• Resize
• Provision
• Move
• Start
• Suspend
Logical Pool Policies


Action Default Mode
Suspend Disabled
Start Disabled
Resize Recommend
Move Disabled
Provision Disabled
Storage Settings
IOPS Capacity 50000
• Storage Latency Capacity

This sets the maximum storage latency to tolerate on a logical pool, in ms. The default setting is 100 ms.
• Storage Overprovisioned Percentage
Storage Overprovisioned Percentage sets how much overprovisioning Turbonomic assumes when recommending
actions for logical pools.
• IOPS Capacity
IOPS Capacity is the IOPS setting for individual logical pools.

NOTE:
Turbonomic discovers storage latency and IOPS capacities that you set in your environment (for example VMAX) and
uses them in its analysis. These capacities will be overridden by values that you set in Turbonomic policies.
Disk Array
A Disk Array (an aggregate) is a data storage system made up of multiple disk drives. For example, a RAID is an aggregate
that implements redundancy and other data management features. A disk array provides storage volumes to serve the
storage requirements of physical machines. It uses the resources of one storage controller, which manages the disk array
operation.
Synopsis

Synopsis
Budget: A disk array gains its budget by selling resources to the datastores it serves. If utilization
of a disk array is high enough, Turbonomic can recommend that you provision a new one.
Provides: Storage resources for datastores to use:

• Storage amount
Consumes: Storage controllers
Discovered through: Turbonomic discovers disk arrays through storage controller targets.

Monitored Resources
Turbonomic monitors the following resources for a disk array:
NOTE:
Not all targets of the same type provide all possible commodities. For example, some storage controllers do not
expose CPU activity. When a metric is not collected, its widget in the UI will display no data.
• Storage Amount
The utilization of the Disk Array's capacity.
The utilization of the Disk Array's capacity, including overprovisioning.
The summation of the read and write access operations per second on the disk array
• Latency
The utilization of latency, computed from the latency of each device in the disk array.
Disk Array Actions

• Provision
For high utilization of the disk array’s storage, provision a new disk array (recommendation, only).
• Start
For high utilization of disk array, start a suspended disk array (recommendation, only).
• Suspend
For low utilization of the disk array’s storage, move VMs to other datastores and suspend volumes on the disk array
• Move
(Only for NetApp Cluster-Mode) For high utilization of Storage Controller resources, Turbonomic can move an
aggregate to another storage controller. The storage controllers must be running.
For high IOPS or latency, a move is always off of the current disk array. All the volumes on a given disk array show
the same IOPS and Latency, so moving to a volume on the same array would not fix these issues.
• Move VM
For high utilization of Storage on a volume, Turbonomic can move a VM to another volume. The new volume can be
on the current disk array, on some other disk array, or on any other datastore.
For high IOPS or latency, a move is always off of the current disk array. All the volumes on a given disk array show
the same IOPS and Latency, so moving to a volume on the same array would not fix these issues.
• Move Datastore
To balance utilization of disk array resources, Turbonomic can move a datastore to another array.

Disk Array Policies


The following table describes the default action mode for disk array actions and automation support for environments
that have Disk Array Storage Controllers as targets.
Default Dell HP NetApp Pure

Action VMAX VNX Nutanix XTremIO
Mode Compellent 3Par ONTAP Storage
Move Disabled (C-Mode,
only)
Provision Recommend (C-Mode,

only)
Resize Recommend
(up)
Start Recommend
Suspend Disabled
Action Automation for NetApp Storage Systems

For NetApp storage systems, the actions Turbonomic can automatically perform depend on the NetApp version you are
running, and whether the system is running in cluster mode:
Automated Action 7-Mode Cluster-Mode
Move VM between datastores, on the same disk array Yes Yes
Move VM between datastores on different disk arrays Yes Yes
Move Datastore between disk arrays on the same storage No Yes

controller
Move Datastore between disk arrays on different storage No Yes

controllers
Resize Storage Yes Yes
Resize Disk Array No — Resize up, only No — Resize up, only

In addition, for a system running in Cluster-Mode, Turbonomic can recommend moving an aggregate to another storage
controller.

Storage Settings
Set capacity for specific storage resources.

IOPS Capacity 5000
A generic setting for disk array IOPS capacity (see Disk
Array IOPS Capacity below).
VSeries LUN IOPS Capacity 5000
7.2k Disk IOPS Capacity 800
10k Disk IOPS Capacity 1200
15k Disk IOPS Capacity 1600
SSD Disk IOPS Capacity 50000
Disk Array IOPS Capacity 10000
NOTE:
Turbonomic discovers storage latency and IOPS capacities that you set in your environment (for example VMAX) and
uses them in its analysis. These capacities will be overridden by values that you set in Turbonomic policies.
• IOPS Capacity
The capacity of IOPS (IO operations per second) that your storage devices can support. Turbonomic considers these
settings when calculating utilization percentage. For example, assume IOPS Capacity of 5000 for a disk array. If
utilization on the array is 2500 IOPS, then the disk array is at 50% of capacity for that metric.
Note that the IOPS setting for an array will determine IOPS calculations for all the storage on that array. If you made
different IOPS settings for individual datastores hosted by the array, Turbonomic ignores the datastore settings and
uses the disk array settings.
◦ Various Disk IOPS Capacity settings (SSD Disk IOPS, 7.2k Disk IOPS, etc)

IOPS capacity settings for the different types of physical drives that are discovered on a disk array. If the storage
controller exposes the types of disks in the array, Turbonomic uses multiples of these values to calculate the
IOPS capacity of the disk array.
◦ Disk Array IOPS Capacity
Some disk arrays do not expose data for their individual disks — This is typical for flash arrays, or arrays that
aggregate storage utilization across multiple tiers. Turbonomic uses this setting for the IOPS capacity of such
disk arrays. Set it to the global scope to specify IOPS capacity for all disk arrays. To override this setting, set a
disk array or group of disk arrays as the property scope, and then set the value you want for IOPS Capacity.
NOTE:
The user interface shows a disk array entity for any array that is discovered through a valid disk array or storage
controller target. It also shows placeholder disk arrays for disk arrays that are not discovered through a configured
target. For example, you might have disk arrays that Turbonomic does not natively support. Or you might
have storage that is not hosted by any disk array. Such placeholder disk array entities appear with the string
"DiskArray-" prefixed to their names. The user interface allows you to set IOPS Capacity to these placeholders, but
those settings have no effect. To set IOPS Capacity for that storage, you must set it to the individual datastores.
• Storage Overprovisioned
This setting indicates how much overprovisioning Turbonomic assumes when recommending actions for disk
arrays. For example, if a disk array has a 30 TB capacity, and DiskArray Overprovisioned Percentage is set to 200,
Turbonomic will treat the datastore as though it has a capacity of 60 TB, or 200% of the actual disk array capacity.
Storage Controller
A Storage Controller is a device that manages one or more disk arrays. The storage controller provides CPU cycles to
perform storage management tasks for each disk array it manages.
Synopsis

Synopsis
Budget: A storage controller gains its budget by selling resources to the disk arrays it manages.
If utilization of the storage controller’s CPU resources is high enough, Turbonomic can
recommend that you provision a new one and move disk arrays (aggregates) to it.
Provides: CPU resources to manage disk arrays.
Consumes: NA
Discovered through: Turbonomic directly accesses storage controller targets.

Monitored Resources
Turbonomic monitors the following resources for a storage controller:
• CPU
The utilization of the Storage Controller's allocated CPU
• Storage Amount
The utilization of the storage controller's capacity. The storage allocated to a storage controller is the total of all the
physical space available to aggregates managed by that storage controller.
NOTE:
In NetApp environments, the storage controller shows 100% utilization when there are no more disks in a SPARE
state that the storage controller can utilize in an aggregate. This does not indicate that the storage controller has no
capacity.
Actions
Provision
For high utilization of the storage controller’s CPU, provision a new storage controller, and then move disk arrays to it.
Storage Controller Policies


Actions for individual Disk Array Storage Controllers:
Default Dell HP NetApp Pure

Action VNX VMAX Nutanix XTremIO
Mode Compellent 3Par ONTAP Storage
Provision Disabled



Maximum allowed utilization of storage that is managed
by the Storage Controller.
CPU Utilization 100
Maximum allowed utilization of Storage Controller CPU
(from 20 to 100).
Storage Settings
Set capacity for specific storage resources.

IOPS Capacity 5000
IO Module
An IO Module connects the compute resources on a chassis to the fabric domain via the Fabric Interconnect. It provides
the servers on the chassis with Net resources. Typical installations provide two IO Modules per chassis.
Turbonomic supports IO Modules when you have installed the Fabric Control Module license.
Synopsis

Synopsis
Budget: An IO Module gains its budget by selling Net resources to a physical machine.
Provides: Net resources
Consumes: Chassis and Fabric Interconnect

Synopsis
Discovered through: Turbonomic discovers IO Modules through the fabric managers that use them.
Monitored Resources
Turbonomic monitors the following resources for an IO Module:
• NetThroughput
Measured in Megabits per second (Mb/s)
Actions
None
Turbonomic does not recommend actions for an IO Module.
Switch
A switch connects servers in a computing fabric to the fabric’s network and storage resources. It provides network
bandwidth to the servers in the platform.
Synopsis

Synopsis
Budget: A switch gains its budget by selling Net resources to the IO Modules.
Provides: Net resources
Consumes: N/A
Discovered through: Turbonomic discovers switches through managers of fabric platforms (such as UCS) that
use them.

Monitored Resources
Turbonomic monitors the following resources for a switch:
• NetThroughput
Measured in Mb/s
• PortChannel
Amalgamation of ports with a shared net throughput and utilization
Measured in Mb/s
Actions
Resize
Resize PortChannel for a switch to increase bandwidth.
Switch Policies

For environments that have Fabric Managers as targets:
Action Default Mode Cisco UCS

Resize Recommend
Start Recommend
Provision Recommend
Suspend Disabled
Move Disabled

Switch Net Throughput 70

Plans: Looking to the Future

Use the Plan Page to run simulations for what-if scenarios that explore possibilities such as:
• Reducing cost while assuring performance for your workloads
• Impact of scaling resources
• Changing hardware supply
• Projected infrastructure requirements
• Optimal workload distribution to meet historical peaks demands

• Optimal workload distribution across existing resources
How Plans Work

To run a plan scenario, Turbonomic creates a snapshot copy of your real-time market and modifies that snapshot
according to the scenario. It then uses the Economic Scheduling Engine to perform analysis on that plan market. A
scenario can modify the snapshot market by changing the workload, adding or removing hardware resources, or
eliminating constraints such as cluster boundaries or placement policies.
As it runs a plan, Turbonomic continuously analyzes the plan market until it arrives at the optimal conditions that
market can achieve. When it reaches that point, the Economic Scheduling Engine cannot find better prices for any of the
resources demanded by the workload — the plan stops running, and it displays the results as the plan's desired state.
The display includes the resulting workload distribution across hosts and datastores, as well as a list of actions the plan
executed to achieve the desired result.
For example, assume a scenario that adds virtual machines to a cluster. To run the plan, Turbonomic takes a snapshot of
the current market, and adds the VMs to the specified cluster. Turbonomic then runs analysis on the plan market, where
each entity in the supply chain shops for the resources it needs, always looking for a better price — looking for those
resources from less-utilized suppliers. This analysis continues until all the resources are provided at the best possible
price.
The results might show that you can add more workload to your environment, even if you reduce compute resources
by suspending physical machines. The recommended actions would then indicate which hosts you can take offline, and
how to distribute your virtual machines among the remaining hosts.
Idle Workloads
Plans calculate optimal placement and optimal resource allocation for the given workload. However, plans do not
include idle workloads. This is because an idle VM shows no utilization, so the plan cannot determine optimal placement
or what percentage of allocated resources that workload will require when it restarts.
Plan Management


The Plan Management Page is your starting point for creating new plans, viewing saved plans, and deleting saved plans
that you don't need anymore. To display this page, click Plan in the Turbonomic navigation bar.
• Create new plans
To create a new plan, click the NEW PLAN button. See Setting Up Plan Scenarios (on page 289).
• View saved plans
After you create and run a plan, Turbonomic saves it and then shows it in the Plan Management Page. You can open
the saved plan to review the results, or you can change its configuration and run it again.
NOTE:
You can also view saved plans from the Search page, under the Plans category.
• Delete saved plans
To delete a saved plan, turn on the plan's checkbox and then click the Delete button.
• Configure nightly plans
Turbonomic runs nightly plans to calculate headroom for the clusters in your on-prem environment. For each cluster
plan, you can set which VM template to use in these calculations. See Configuring Nightly Plans (on page 346).
Setting Up Plan Scenarios

A plan scenario specifies the overall configuration of a plan. Creating the plan scenario is how you set up a what-if
scenario to see the results you would get if you changed your environment in some way.
This topic walks you through the general process of setting up a plan scenario.
1. Plan Entry Points

You can begin creating a plan scenario from different places in the user interface:
• From the Plan Page
Navigate to the Plan Page and click NEW PLAN. This plan has no scope. You will specify the scope after selecting the
plan type.

• From the Home Page
To start a plan scenario from the Home Page, you must first go to the Search page to set the scope.


◦ Cloud scope
If you set the scope to a specific Account, Billing Family, VM Group, or Region, you can start an Optimize Cloud
or Buy VM Reservations plan.
◦ On-prem scope
If you set the scope to a specific Cluster, Datacenter, Group, Storage Cluster, or Virtual Datacenter, you can start
any plan. You may need to go through additional steps, depending on your chosen plan type. For example, if
you scope to a cluster and choose the Add Virtual Machines plan type, the plan wizard prompts you to select
the most suitable templates for the VMs you plan to add to the cluster.
◦ Container cluster scope
If you set the scope to a specific Container Platform Cluster, you can start an Optimize Container Cluster plan.
For details, see Scoping the Turbonomic Session (on page 55).
After setting the scope, the Plan button appears in the Home Page.

2. Plan Types
Select from the list of plan types. For more information, see Plan Scenarios and Types (on page 295).


Turbonomic opens the appropriate plan wizard.
3. Plan Wizards
Each plan type includes a wizard to guide you through creating the scenario. The wizard leads you through the required
configuration steps to create a plan that answers a specific question. After you make the required settings, you can skip
ahead and run the plan, or continue through all the optional steps.


4. Plan Scope
All plans require a scope. For example, to configure a Hardware Refresh plan, you set the scope to the hosts that you
plan to replace.

It usually helps to focus on a subset of your environment. For a very large environment, scoped plans run faster.
To narrow the scope, select a group from the list on the left side of the page. The page then refreshes to include only the
entities belonging to that group.
Use Search or Filter to sort through a long list.

5. Additional Plan Information

The wizard prompts you for any additional information required to run the plan. For example, for a Hardware Refresh
plan, you need to identify the hosts that will replace the scoped hosts.

6. Run the Plan

After you provide the minimum required information for running a plan, the wizard shows you the following options:

• Run Plan: Immediately run the plan.
• Next: [Step]: Continue with the rest of the wizard and then run the plan.
• Skip to Configuration: Skip the rest of the wizard and go to the Plan Page to:
◦ Customize the plan settings.
◦ See a preview of the plan scenario.
◦ Run the plan.

NOTE: For a custom plan, the only option available is Configure Plan. Click this button to open the Plan Page,
configure the plan settings, and then run the plan.
7. The Plan Page

The Plan Page first displays if you skip the wizard or as soon as you run a plan.
For a plan with a large scope, it might take some time before you see the results. You can navigate away from the Plan
Page and check the status in the Plan Management Page. You can also cancel a plan that is in progress.
The Plan Page shows the following sections:

Plan Page
Description
Sections
A. Plan name Turbonomic automatically generates a name when you create a new plan. Change the name to
something that helps you recognize the purpose of this plan.
B. Plan scope Review the scope that you set in a previous step.
NOTE:
It is not possible to change the scope of the plan in the Plan Page. You will need to start over if you
want a different scope. To start over, go to the top-right section of the page, click the More options
icon ( ), and then select New Plan.
C. Configure additional settings for the plan. You can name the plan, change workload demand and the
Configuration supply of resources, and specify other changes to the plan market. The toolbar items that display
toolbar depend on the plan you are creating.
D. Review the plan's configuration settings. You can remove any setting by clicking the x mark on the
Configuration right. Use the toolbar on top to change the settings. As you make changes to the plan scenario, those
summary changes immediately appear in the Configuration summary.

Plan Page
Description
Sections
E. Additional See what else you can do with the plan.
options • Run / Run Again:
◦ If a plan has not run, click Run and then check the plan results.
◦ If the plan has run and you want to run it again with a different set of configuration settings,
click Run Again. This runs the plan scenario against the market in its current state.
• : Click to see more options.

◦ New Plan: Configure a new plan. You can choose this option if you want to change the scope
of the current plan, which requires that you start over and configure a new plan.
◦ Reset view: Restore charts to their default views. For example, if you changed the
commodities displayed in the Optimized Improvements or Comparison charts, you can
discard those changes by choosing this option.
◦ Delete plan: Choose if you no longer need the plan.
F. Plan results Review the results in the charts provided.
For a plan that has not run, you will see a Scope Preview chart and a one-time message instructing
you to run the plan.
8. Plan Management
All the plans you have created display in the Plan Management Page (on page 288).
Plan Scenarios and Types

To simulate different plan scenarios, Turbonomic provides the following general types of plans:


Optimize Container Cluster

Run an Optimize Container Cluster plan to identify performance and efficiency opportunities for a single Kubernetes
cluster. The results show the optimal number of nodes you need to assure performance for your existing workloads, and
the impact of actions on the health of your container workloads and infrastructure.
Optimize Cloud
For the scope of your public cloud environment that you want to examine, run a plan to see all the opportunities you
have to reduce cost while assuring performance for your workloads. This includes suggestions to buy RIs, comparisons of
template and storage usage, and a comparison of current to optimized cost.
Buy VM Reservations
Run the Buy VM Reservations plan to see the most cost-effective RI purchases that will continue to assure performance
for your cloud VMs.

Migrate to Cloud
A Migrate to Cloud plan simulates migration of on-prem VMs to the cloud, or migration of VMs from one cloud provider
to another.
NOTE:
For migrations within your on-prem environment, use the Virtual Machine Migration plan type.
Optimize On-prem
See the effects of executing certain actions, such as scaling virtual machines, suspending hosts, or provisioning storage,
to your on-prem environment.
Add Virtual Machines

Adding virtual machines increases the demand that you place on your environment's infrastructure. You can set up a
plan to add individual VMs or groups of VMs in your environment, or based on templates.
Hardware Refresh
Choose hosts that you want to replace with different hardware. For example, assume you are planning to upgrade the
hosts in a cluster. How many do you need to deploy, and still assure performance of your applications? Create templates
to represent the upgraded hosts and let the plan figure out how many hosts you really need.
Host Decommission
If your environment includes underutilized hardware, you can use a plan to see whether you can decommission hosts
without affecting the workloads that depend on them.
Virtual Machine Migration

Use this plan type to simulate workload migrations within your on-prem environment.
You can see whether you have enough resources to move your workload from its current provider group to another. For
example, assume you want to decommission one datacenter and move all its workload to a different datacenter. Does
the target datacenter have enough physical resources to support the workload move? Where should that workload be
placed? How can you calculate the effect such a change would have on your overall infrastructure?
To calculate this information, create a plan that:
• Limits the plan scope to two datacenters (or clusters) — the one you will decommission, and the one that will take
on the extra workload
• Removes all the hardware from the decommissioned datacenter
• Calculates workload placement across datacenter (or cluster) boundaries
• Does not provision new hardware to support the workload
Merge Clusters
See the effects of merging two or more clusters. For example, you can see if merging the clusters would require
provisioning additional storage to support current demand, or if ignoring cluster boundaries would improve
performance and efficiency.

Alleviate Pressure
Choose a cluster that shows bottlenecks or other risks to performance, and check to see the minimal changes you can
make by migrating some workloads to another cluster. The cluster that is showing risks is a hot cluster, and the cluster
you will migrate to is a cold cluster.
Custom Plan
With a custom plan, you skip directly to the plan configuration after specifying the plan scope, and set up whatever type
of scenario you want.
You would also choose Custom Plan if you need to run plans that include containers and container pods.
Optimize Container Cluster Plan

Run an Optimize Container Cluster plan to identify performance and efficiency opportunities for a single Kubernetes
cluster. The results show the optimal number of nodes you need to assure performance for your existing workloads,
and the impact of actions on the health of your container workloads and infrastructure. For example, you can see how
container resize actions change the limits and requests allocated per namespace, or how node provision/suspend
actions impact allocatable capacity for the cluster. For a cluster in the public cloud, the results also include the cost
impact of node actions.

You can scope the plan to a:

• Standalone container cluster
• Container cluster in an on-prem or public cloud environment
• Container cluster stitched to applications via Data Ingestion Framework (DIF)
Scoping to a group within a Kubernetes cluster (such as a group of nodes) is currently not supported.
Configuring an Optimize Container Cluster Plan

You can start an Optimize Container Cluster plan when you open the Plan page or set the scope to a Kubernetes cluster.
For an overview of setting up plan scenarios, see Setting Up Plan Scenarios (on page 289).

1. Scope
Select a Kubernetes cluster to optimize.

Scoping to a group within a Kubernetes cluster (such as a group of nodes) is currently not supported.
NOTE:
After selecting a cluster, you can skip the next step (Optimization Settings) and run the plan. Turbonomic runs the Full
Optimization scenario in this case.

2. Optimization Settings
Choose from the given optimization scenarios.

• Full Optimization
Turbonomic will recommend all relevant actions to optimize the cluster. For example, it can recommend
provisioning nodes or resizing containers to meet application demand, or moving pods from one node to another to
reduce congestion.
Turbonomic can recommend the following actions:
◦ Resize namespace compute resource quotas
◦ Resize container limits and requests
◦ Move pods
◦ Provision or suspend nodes
◦ Scale volumes
NOTE:
For a cluster in the public cloud, Turbonomic shows the cost impact of actions on nodes and volumes, to help you
track your cloud spend. Turbonomic only reports the costs attached to these actions, and does not perform cost
analysis on the cluster.
For a cluster in an on-prem environment, Turbonomic can also recommend the following actions:
◦ Move VMs
◦ Provision or suspend hosts
◦ Provision or suspend storage
• Optimize Container Spec Size
Turbonomic will only recommend resizing container limits and requests. This is ideal for application owners who
manage the containers that their applications run on, but not the underlying container infrastructure.
• Optimize Cluster Resources, Placement, and Nodes
Turbonomic will recommend all relevant actions, except resizing container limits and requests. This is ideal for
teams who oversee the health of your container infrastructure, and want to evaluate the impact of not rightsizing
workloads.
After selecting an optimization scenario, you can:
• Run the plan.
Or
• Choose Skip to Configuration to configure additional settings. See the next section for details.

(Optional) Additional Plan Settings

You can fine tune your selected optimization scenario or include additional scenarios before you run the plan.
• Enable or disable actions
Fine tune your optimization scenario by enabling or disabling actions for containers, pods, or nodes. For example,
you may have selected Full Optimization, but only for containers, nodes, and pods that are allowed to move. In this
case, you would disable move actions for the pods that should never move.
For clusters in on-prem environments, you can also enable or disable actions for hosts and storage.
IMPORTANT:
To avoid seeing inaccurate plan results, do not disable all actions.
• Add pods
See resource changes if you add more pods to the cluster. For example, you might need to provision nodes to
accommodate the new pods.
Select an existing pod within or outside the selected Kubernetes cluster, and then specify how many copies to add.
The plan simulates adding pods with the same resources as the selected pod.
• Remove pods or nodes
See the effect of removing pods or nodes from the cluster. For example, pod density could improve significantly if
you remove pods that you no longer need, or certain pods might become unplaced if you remove nodes.
Working with Optimize Container Cluster Plan Results

After the plan runs, you can view the results to see how the plan settings you configured affect your environment.


General Guidelines
Familiarize yourself with these common terms that appear in many sections of the plan results:
• A container pod represents the compute demand from a running pod.
• A Kubernetes node (virtualized or bare metal) is represented as a VM.
• Used (or Usage) values represent actual resource consumption. For example, a node that consumes 100 MB of
memory has a used value of 100 MB.
• Utilization values represent used/usage values against capacity. For example, a node that consumes 100 MB of
memory against a total capacity of 500 MB has a utilization value of 20%.

Optimize Container Cluster Summary

This chart shows how your container environment and the underlying resources will change after you execute the
actions that the plan recommends. The chart shows the following information:
• Container Pods
Count of active container pods in the plan.
• Virtual Machines
Count of active nodes in the plan. This chart does not count "non-participating" entities in the real-time market,
such as suspended nodes.
• Pod Density
Average number of pods per node.
For the total number of pods against the node capacity (maximum pods per node), see the Number of Consumers
data in the following charts:
◦ Nodes (VMs) Optimized Improvements
◦ Nodes (VMs) Comparison
◦ Container Cluster Optimized Improvements
◦ Container Cluster Comparison
• Cluster CPU Capacity
Total CPU capacity for the cluster. The 'After Plan' result indicates how much CPU capacity will result in the optimal
number of nodes required to run workloads.
• Cluster Memory Capacity
Total memory capacity for the cluster. The 'After Plan' result indicates how much memory capacity will result in the
optimal number of nodes required to run workloads.

• Cluster Allocatable CPU

Total amount of cluster CPU available for pod requests. The 'After Plan' result indicates how much of the allocatable
CPU capacity will change if you provision or suspend nodes.
• Cluster Allocatable Memory
Total amount of cluster memory available for pod requests. The 'After Plan' result indicates how much of the
allocatable memory capacity will change if you provision or suspend nodes.
• Cluster CPU Overcommitment
(Only for containers with CPU limits) This indicates whether the CPU limits exceed the capacity of the underlying
nodes. A value greater than 100% indicates overcommitment. Turbonomic manages cluster resources by actual
utilization and limit rightsizing so that you can run more workloads with less risk.
Turbonomic only calculates overcommitment in plans. The calculation can be expressed as:
Overcommitment = Sum of CPU limits for all containers / Sum of CPU capacity for all
nodes
• Cluster Memory Overcommitment

(Only for containers with memory limits) This indicates whether the memory limits exceed the capacity of the
underlying nodes. A value greater than 100% indicates overcommitment. Turbonomic manages cluster resources by
actual utilization and limit rightsizing so that you can run more workloads with less risk.
Turbonomic only calculates overcommitment in plans. The calculation can be expressed as:
Overcommitment = Sum of memory limits for all containers / Sum of memory capacity for
all nodes
Optimize Container Cluster Actions

This chart summarizes the actions that you need to execute to achieve the plan results. For example, you might need
to resize limits and requests for containers (via the associated Workload Controllers) to address performance issues. Or,
you might need to move pods from one node to another to reduce congestion.
Smarter redistribution and workload rightsizing also drive cluster optimization, resulting in the need to provision node(s)
based on application demand, or to defragment node resources to enable node suspension.
Turbonomic can recommend the following actions:
• Resize namespace compute resource quotas
• Resize container limits and requests

NOTE:
Executing several container resize actions can be very disruptive since pods need to restart with each resize.
For replicas of the container scale group(s) related to a single Workload Controller, Turbonomic consolidates
resize actions into one merged action to minimize disruptions. When a merged action has been executed (via the
associated Workload Controller), all resizes for all related container specifications will be changed at the same
time, and pods will restart once.
• Move pods
• Provision or suspend nodes
• Scale volumes
NOTE:
For a cluster in the public cloud, Turbonomic shows the cost impact of actions on nodes and volumes, to help you
track your cloud spend. Turbonomic only reports the costs attached to these actions, and does not perform cost
analysis on the cluster. See the Optimized Savings and Optimized Investments charts for more information.
For an on-prem cluster, Turbonomic can also recommend the following actions:
• Move VMs
• Provision or suspend hosts
• Provision or suspend storage
Optimized Savings

For a cluster in the public cloud, Turbonomic shows the savings you would realize if you execute the actions (such as
node suspension) that the plan recommends to increase infrastructure efficiency. Note that efficiency is the driver of
this action, not cost. Cost information is included to help you track your cloud spend.
The chart shows total monthly savings. Click Show All to view the actions with cost savings.

Optimized Investments

For a cluster in the public cloud, Turbonomic shows the costs you would incur if you execute the node and volume
scaling actions that the plan recommends to address performance issues. For example, if some applications risk losing
performance, Turbonomic can recommend provisioning nodes to increase capacity. This chart shows how these actions
translate to an increase in expenditure. Note that performance and efficiency are the drivers of these actions, not cost.
Cost information is included to help you plan for the increase in capacity.
The chart shows total monthly investments. Click Show All to view the actions that require investments.
Nodes (VMs) Optimized Improvements

This chart compares the following before and after the plan:
• Utilization of the following for all nodes:
◦ vMem
◦ vCPU
◦ vMem Request

◦ vCPU Request
• Number of pods consuming resources against the maximum pod capacity for all the nodes
Nodes (VMs) Comparison

This chart compares node resource utilization (one metric at a time) before and after the plan.
Namespace Quotas Optimized Improvements

This chart shows pod utilization of resource quotas defined in namespaces. Resource quotas include:
• CPU Limit Quota
• Memory Limit Quota
• CPU Request Quota
• Memory Request Quota
For namespaces without defined quotas, utilization is 0 (zero).

With or without quotas, you can see the sum of pod limits and requests per namespace. Go to the top-right section of
the Plan Results page, click the download button, and select Namespace. Utilization data in the downloaded file shows
these limits and requests. You can also compare usage values in the Namespaces Comparison chart.
Namespaces Comparison

This chart compares namespace quota usage (one metric at a time) before and after the plan.
Use this chart to see how container resizing changes the limits and requests allocated per namespace, whether you
leverage quotas or not.
To achieve the 'After Plan' results, click Show All. In the Details page that opens, go to the Name column and then click
the namespace link. This opens another page with a list of pending actions for the namespace.


Namespace Resources Comparison

This chart shows how much cluster resources per namespace are utilized by pods. Utilization can be expressed as
follows:
Utilization = Sum of actual vMem/vCPU used by pods / vMem/vCPU capacity for the cluster
This information helps you understand which namespaces use the most cluster resources. You can also use it for
showback analysis. vMem and vCPU utilized by pods in the namespaces would change when the number of nodes
changes as a result of executing the plan actions.
This chart is especially useful if you do not have resource quotas defined in your namespaces.
Container Cluster Optimized Improvements

This chart shows the following, assuming you execute all actions in the plan:
• Changes to the utilization of cluster resources
• Overcommitment values

Container Cluster Comparison

This chart compares the following before and after the plan:
• Utilization of cluster resources (one metric at a time)
• Overcommitment values
Optimized Improvements for Hosts, Storage, and Virtual Machines

Use these charts if you ran the plan on an on-prem Kubernetes cluster. These charts show how the utilization of
resources would change assuming you accept all of the actions listed in the Plan Actions chart
Hosts, Storage Devices, and Virtual Machines Comparison

Use these charts if you ran the plan on an on-prem Kubernetes cluster. These charts show how the utilization
of a particular commodity (such as memory or CPU) for each entity in the plan would change if you execute the
recommended actions.
NOTE:
For the Storage Devices Comparison chart, if you set the view to VM Per Storage and click Show all, the total number
of VMs sometimes does not match the number in the Summary chart. This happens if there are VMs in the plan that
use multiple storage devices. The Storage Devices Comparison chart counts those VMs multiple times, depending on
the number of storage devices they use, while the Plan Summary chart shows the actual number of VMs.
Downloading Plan Results

To download results for nodes, namespaces, or the container cluster, click the download button at the top-right section
of the Plan Results page.


You can also download the plan results shown in individual charts. Click the Show All button for a chart, and then the
download button at the top-right section of the Details page.

For charts that display infinite capacities (for example, the Namespaces Comparison chart), the downloaded file shows
an unusually high value, such as 1,000,000,000 cores, instead of the ∞ symbol.
Re-Running the Plan

You can run the plan again with the same or a different set of configuration settings. This runs the plan scenario against
the market in its current state, so the results you see might be different, even if you did not change the configuration
settings.
Use the toolbar on top of the Configuration section to change the configuration settings.

NOTE:
It is not possible to change the scope of the plan in the Plan Page. You will need to start over if you want a different
scope. To start over, go to the top-right section of the page, click the More options icon ( ), and then select New
Plan.
When you are ready to re-run the plan, click Run Again on the top-right section of the page.
Optimize Cloud Plan

Run the Optimize Cloud plan to see how you can maximize savings while still assuring performance for your applications
and workloads. This plan identifies ways to optimize your costs by choosing the best templates (most adequate compute
resources), regions, accounts, or resource groups to host your workloads. The plan also identifies workloads that can
change over to RI pricing plans, and it compares your current costs to the costs you would get after executing the plan
recommendations.

Configuring an Optimize Cloud Plan

1. Scope
You can scope by:


• Accounts
Choose an AWS account or Azure subscription for the plan's scope. If you choose an Account for the scope, then the
plan will not calculate RI Buy actions. To optimize RI purchases for a limited scope, choose a Billing Family.
• Billing Families
Include RI purchases in the planning for a scope that is limited to a single billing family. The plan calculates RI
purchases through the billing family's master account.
• Cloud Providers
See how you can optimize all your AWS or Azure workloads.
• Resource Groups
Turbonomic discovers Azure resource groups. You can select one or more resource groups for the plan scope.
• Regions
Focus the plan on a provider's region.
2. Optimization Settings

Choose from the given optimization options. Note that if you set a plan's scope to a resource group, Turbonomic will
optimize services without recommending new RI purchases.
If your goal is to buy RIs for VMs at their current sizes, use the Buy VM Reservations plan type. For details, see Buy VM
Reservations Plan (on page 327).
NOTE:
If you turn on the Disable All Actions setting in the global default policy and then run an Optimize Cloud plan with VM
scaling and RI purchases enabled, the plan results show inaccurate RI recommendations.
Turn off Disable All Actions to resolve this issue. Be aware that after you turn off this setting, it will take Turbonomic a
week to reflect accurate results in Optimize Cloud plans.

3. Reserved Instances Settings

For Plan RI Inventory, the RIs for the current scope are selected by default. Click Edit to make changes.
For RI Purchase Profile, the settings that you have set up for real-time analysis are selected by default. You can change
the settings to see how they affect costs. For more information about RI Purchase, see RI Purchase Profile (on page
427).
• OFFERING CLASS
For AWS environments, choose the offering class that corresponds to the RI types that you typically use in your
environment.
• TERM
For AWS and Azure environments, choose the payment terms you contract for your RIs. TERM can be one of 1 Year
or 3 Year. Typically, longer term payment plans cost less per year.
• PAYMENT
The payment option that you prefer for your AWS RIs:
◦ All Upfront – You make full payment at the start of the RI term.
◦ Partial Upfront – You make a portion of the payment at the start of the term, with the remain cost paid at an
hourly rate.
◦ No Upfront – You pay for the RIs at an hourly rate, for the duration of the term.
Working With Optimize Cloud Plan Results

After the Optimize Cloud plan runs, you can view the results to see how you can maximize savings or make other
improvements to your cloud environment.

The plan results:

• Compare current to optimized costs, including on-demand compute, reserved compute, on-demand database, and
storage costs
• Compare current and optimized breakdowns of templates used
• Compare breakdowns of storage tiers in use
• Project the RI coverage (how many workloads use RI) and utilization (percentage of RIs that are active)
• Identify candidates for Reserved Instance (RI) pricing, and show the cost benefits you can see by running those
workloads on templates that are reserved on your public cloud provider.
Viewing the Results

The plan results include the following charts:
• Cloud Cost Comparison
This chart highlights any difference in cost as a result of optimization. For example, undersized VMs risk losing
performance and should therefore scale up. This could contribute to an increase in cost. On the other hand,
oversized VMs can scale down to less expensive instances, so cost should go down. The values under the % column
indicate the percentage of VMs that are affected by optimization cost calculations.
Turbonomic can also recommend that you purchase RI capacity to reduce costs. The analysis looks at workload
history to identify RI candidates. This considers the count of workloads in a family, plus their hours of active-state
condition, to arrive at the RI capacity you should purchase. Since RI costs are incurred at the account level, the
Cloud Cost Comparison chart will present RI costs or charges when you scope to an account or group of accounts
(including a billing family).

For AWS clouds, Turbonomic can get the information it needs to display license costs for database instances. For
Azure clouds, Turbonomic does not display database license costs because Azure does not make that information
available.
• Workload Mapping
This chart shows the types of tiers you currently use, compared to the tiers the plan recommends, including how
many of each type, plus the costs for each.

To see a detailed breakdown of the template costs, click SHOW CHANGES at the bottom of the chart.
• Volume Tier Breakdown
This chart shows the distribution of storage that supports your workloads in Current and Optimized graphs.

The difference in the result reflects the number of unattached volumes. To see a list of unattached volumes, click
Show changes at the bottom of the chart.
• Plan RI Inventory
This chart shows the RI workloads that Turbonomic discovers and lists them by tiers. For a tabular listing, click Show
All at the bottom of the chart. In the tabular listing, you can see if an RI expired before the specified purchase date.


• Recommended RI Purchases
This chart shows the RIs the plan recommends to buy. To see the details, click SHOW ALL at the bottom of the chart.

Viewing Plan Actions

Click the Plan Actions tab on top of the page to view a list of actions that you need to execute to achieve the plan
results.


Re-Running the Plan

settings.

• Actions
Use this to enable or disable automatic Scale actions for the virtual machines in the plan.
• RI Profile
Change RI Purchase Profile settings that match the cloud settings you have set up for real-time analysis. For details,
see Reserved Instance Settings (on page 314).
NOTE:
Plan.
Migrate to Cloud Plan


A Migrate to Cloud plan simulates migration of on-prem VMs to the cloud, or migration of VMs from one cloud provider
to another. This plan focuses on optimizing performance and costs by choosing the most suitable cloud resources for
your VMs and the volumes they use. If analysis discovers VMs that are good candidates for Reserved Instances (RIs),
then it recommends migrating to those instances, and can even recommend purchasing more RI capacity.
The plan calculates costs according to the billing and price adjustments that you have negotiated with your cloud
provider. Costs include compute, service (such as IP services), and license costs. The plan also calculates RI purchases for
VMs that can benefit from such pricing.
NOTE:
If your instance of Turbonomic is inoperative for a period of time, that can affect the cost calculations. To calculate
costs for a VM that it will migrate to the cloud, Turbonomic considers the VM's history. For example, if the VM
has been stable for 16 of the last 21 days, then Turbonomic will plan for that VM to use an RI. In this way, the plan
calculates the best cost for the migration. However, if Turbonomic is inoperative for any time, that can impact the
historical data such that the plan will not recognize a VM as stable, even though it is.
Points to consider:
• AWS includes EC2 Spot Instances that offer steep discounts. A plan that migrates from AWS to Azure will not migrate
VMs that run on Spot Instances.
• Do not use this plan type to migrate within the same cloud provider (for example, moving VMs from one Azure
subscription to another) as a way to test the effect on pricing. The results from such a plan would not be reliable.
• For migrations within your on-prem environment, use the Virtual Machine Migration plan type.
• Before migrating, consider turning on a setting in the default global policy that enables metrics collection for on-
prem volumes attached to VMs. This allows Turbonomic to make more accurate placement decisions for the VMs
and volumes you are migrating. For details, see Enable Analysis of On-prem Volumes (on page 103).
The plan results show:
• Projected costs
• Actions to execute your migration and optimize costs and performance
• Optimal cloud instances to use, combining efficient purchase of resources with assured application performance
• VMs that are good candidates for Reserved Instance (RI) pricing, and the cost benefits you would realize by running
those VMs as RI instances
• RIs you should purchase (if you need more RI capacity)
Configuring a Migrate to Cloud Plan

1. Scope
Select the VMs that you want to migrate. You can select VM groups and/or individual VMs.


If you select an Auto Scaling Group, Turbonomic simulates migrating the VMs individually, and not as a group.
2. Where to Migrate
Choose a billing account (AWS account or Azure subscription).

Choose a region. Turbonomic shows all the regions that you can access from your target cloud accounts.

By default, Turbonomic considers all instance types in the selected region when making placement decisions for the
scoped VMs and the volumes they use. However, you may have set up constraints in policies that limit migration to
certain instance types. If there are VMs and volumes in your scope that are affected by those policies, Turbonomic will
only consider the instance types defined in the policies.

3. Licensing (OS Migration Profile)

Select an OS Profile for this migration.

On the cloud, instances usually include an OS platform to run processes on the VM. As you migrate VMs to the cloud,
you can specify the OS you prefer to run. You can keep the same OS that the original VM has, or map it to a different OS.
• Include OS cost
As Turbonomic calculates placement for the migrated workloads, it will include costs for instances that provide the
same OS that the VM already has.
• BYOL (Bring your own license)
This is the same as the Include OS cost option, except the plan does not include OS licensing costs in any of the cost
calculations for on-cloud placement.
• Custom OS
For each of the listed OS types, map the migrated VM to the OS you choose. The OS types are:
◦ Linux – Any open source distribution of Linux. For the migration, Turbonomic will choose instances that provide
the Linux platform that the cloud service provider delivers as a free platform. Note that this is always BYOL,
because it assumes a free OS license.
◦ RHEL (Red Hat Enterprise Linux)
◦ SLES (SUSE Linux Enterprise Server)
◦ Windows
If you enable BYOL for RHEL, SLES, or Windows, Turbonomic assumes that you are paying for the OS license, and will
not include the license cost in the plan results. If you do not enable BYOL, Turbonomic gets the license cost from the
service provider and includes that cost in the plan results.

4. Reserved Instances Settings

For Plan RI Inventory, the RIs for the current scope are selected by default. Click Edit to make changes.
For RI Purchase Profile, the settings that you have set up for real-time analysis are selected by default. You can change
the settings to see how they affect costs. For more information about RI Purchase, see RI Purchase Profile (on page
427).
• OFFERING CLASS
environment.
• TERM
• PAYMENT
hourly rate.
Working With Migrate to Cloud Plan Results

The Migrate to Cloud plan results show the cloud resources and costs for the VMs you plan to migrate, and the actions
required for migration.


Turbonomic shows results for two migration scenarios:
• Lift & Shift
Lift & Shift migrates your VMs to cloud instances that match their current resource allocations.
• Optimized
As Turbonomic runs the plan, it looks for opportunities to optimize cost and performance. For example, it might
discover overprovisioned VMs after analyzing the historical utilization of VM resources. If you were to migrate such
VMs to instances that match their current allocations, then you would spend more than necessary. For an optimized
migration, Turbonomic can recommend migrating to less expensive instances while still assuring performance, and
then show the resulting savings. In addition, when you examine the actions for an optimized migration, you will see
charts that plot the historical utilization data used in the analysis.
Results Overview
The Results Overview section shows the following:
• Unplaced VMs
If the plan's scope includes VMs that cannot be migrated, the results include a notification indicating the number of
VMs. Click Show Details to see the list of VMs and the reasons for their non-placement.

The charts in the plan results do not count these VMs.
Turbonomic displays adjusted CPU values for unplaced VMs. These values are the actual metrics used in analysis
and are calculated using benchmark data. CPU values shown in other places (such as the Capacity and Usage chart)
are unadjusted values obtained from targets.
• Cloud Cost Comparison Chart

This chart highlights any difference in cost as a result of optimization. For example, undersized VMs risk losing
performance and should therefore scale up. This could contribute to an increase in cost. On the other hand,
oversized VMs can scale down to less expensive instances, so cost should go down. The values under the % column
indicate the percentage of VMs that are affected by optimization cost calculations.

NOTE:
For Azure, the results do not include the license cost for the migrated VMs.
• Virtual Machine Mapping Chart
This chart gives a breakdown of the instance types that the plan recommends for the migration, including how
many of each is needed.

Click Show Changes to see a table with details for each VM in the plan. The table maps VMs to instance types. It
also shows the properties and monthly cost for each instance type, and indicates whether Turbonomic recommends
buying an RI. Under the Actions column, click Details to compare Lift & Shift and Optimized actions.
• Volume Mapping Chart
This chart gives a breakdown of the volume types that the plan recommends for the migration, including how many
of each is needed.


Click Show Changes to see a table with details for each volume in the plan. The table maps the volumes you plan to
migrate to the volume types that Turbonomic recommends. It also shows the properties and monthly cost for each
volume type. Under the Actions column, click Details to compare Lift & Shift and Optimized actions.
• Recommended RI Purchases Charts
These charts list the RIs the plan recommends for the migration, including how many of each is needed.

To identify RI candidates, Turbonomic considers the history of a VM (by default, the last 21 days), and it looks for:
◦ Activity
If the VM's VCPU utilization percentile is 20% or higher, then Turbonomic considers it an active VM.
◦ Stability
If there have been no start, stop, or resize actions for the VM for 16 of the last 21 days, then Turbonomic
considers it stable.
◦ RI Inventory (AWS only)
For AWS environments, Turbonomic compares the RI candidates to your current inventory of RI resources,
plus your desired RI coverage. If the inventory can support the VM, then Turbonomic considers it an AWS RI
candidate. If the inventory cannot support the VM, or if supporting it would exceed your desired RI coverage,
then Turbonomic can recommend purchasing more RI capacity.
NOTE:
The plan assumes that an RI will always be less expensive than its on-demand counterpart. However, this is not
always the case. There might be billing details from service providers that could lead to recommendations to
migrate to an RI that is more expensive than running on demand.

Click Show All to see a table with details for each RI. The table shows the properties, up-front cost, and break-even
period for each RI investment. It also indicates the monthly savings you would realize when you buy a specific RI.
Under the Actions column, click Details to compare Lift & Shift and Optimized actions.
Plan Actions
Turbonomic shows separate tabs for Lift & Shift and Optimized migration actions. You can download the list of actions
as a CSV file.

For Optimized migrations, when you expand an action on a VM, you will see charts that track VCPU and VMem
utilization for that VM. With these charts, you can easily recognize the utilization trends that Turbonomic analyzed to
determine the most efficient instance for the VM.

For more information about these charts, see VCPU and VMem Utilization Charts for VMs (on page 92).

Re-Running the Plan

settings.
NOTE:
Plan.
Buy VM Reservations Plan

Run the Buy VM Reservations plan to see RI purchase opportunities that can significantly reduce on-demand costs for
your cloud VMs. When calculating RI purchases, Turbonomic evaluates all RI purchasing options for your selected scope
and usage data for the VMs in that scope. It then compares your current costs to the costs you would get after executing
the plan recommendations.
Configuring a Buy VM Reservations Plan


1. Scope

You can scope by:
• Accounts
Choose AWS accounts or Azure subscriptions for the plan's scope.
• Billing Families
Include RI purchases for a billing family. The plan calculates RI purchases through the billing family's master account.
• Cloud Providers
See purchase opportunities for your AWS or Azure environment.
• Regions
Focus the plan on a cloud provider's region.

2. RI Settings

Purchase RI Settings
Allow the plan to buy Reserved Instances based on the following configurations:
• Profile
The settings that you have set up for real-time analysis are selected by default. You can change the settings to see
how they affect costs. For more information, see RI Purchase Profile (on page 427).
• Virtual Machine Usage
Specify the time frame you want the plan to use when it calculates your RI purchases.
• Terminated Virtual Machines
◦ Only use data from active VMs – Select this option if you terminate your VMs permanently.
◦ Use data from active and deleted VMs (Support CI/CD pipeline) – Select this option if you want to use data
from a CI/CD pipeline that regularly deploys and terminates VMs.
Plan RI Inventory
Select your RI inventory for the plan. You can use the default selection or any of the available RIs for your scope.
Working With Buy VM Reservations Plan Results

After the Buy VM Reservations runs, you can view the results to see RI purchase and optimization opportunities for your
cloud environment.


Viewing the Results

The plan results include the following charts:
• Cloud Cost Comparison
This chart highlights changes to your existing RI coverage and utilization if you execute all the actions that the plan
recommends. Actions include increasing coverage or purchasing RIs. Your cloud provider will adjust RI allocations
when the actions have completed.
◦ Analysis evaluates ways to increase your current RI coverage so you can take full advantage of discounted
pricing offered through RIs.
◦ If you need more RI capacity to reduce your costs further, the plan will recommend RI purchase actions. The
analysis looks at historical VM usage and uptime to arrive at the RI capacity you should purchase.
You can compare current and after-action costs, including on-demand compute, reserved compute, and total costs.
Purchasing RIs increases your reserved compute cost, but can lower your on-demand compute cost significantly as
RI coverage increases. The end result is a reduction to your total cost.
• Virtual Machine Mapping

This chart shows the instance types for the VMs included in the plan.


Click Show Changes to see details for each VM with RI coverage changes. The table maps VMs to instance types,
and shows how changes in RI coverage can reduce on-demand cost.
• RI Inventory
This chart shows the RIs that you have configured for the plan and lists them by instance types. For a tabular listing,
click Show All at the bottom of the chart.

• Recommended RI Purchases
This chart lists the RIs the plan recommends you to purchase, including how many of each is needed.


Click Show All to see details for each RI. The table shows the properties, up-front cost, and break-even period for
each RI investment. It also indicates the monthly savings you would realize when you buy a specific RI.
Viewing Plan Actions

Click the Plan Actions tab on top of the page to view a list of actions that you need to execute to achieve the plan
results.

Re-Running the Plan

settings.
• Purchase RI Settings
Update your purchase settings to see how they impact results. For example, you can configure a longer timeframe
so that the plan can include additional VM usage data in its analysis. For details, see Purchase RI Settings (on page
329).
• Plan RI Inventory
Use the default selection or any of the available RIs for your scope.
NOTE:
Plan.

Alleviate Pressure Plan

Use the Alleviate Pressure plan to find out how to migrate workloads from a stressed or hot cluster over to a cluster with
more headroom. This plan shows the minimal changes you need to make to reduce risks on the hot cluster.
The plan results:
• Show the actions to migrate workloads from the hot cluster to the cold one
• Compare the current state of your clusters to the optimized state
• Show resulting headroom for both the hot and the cold clusters
• Show trends of workload-to-inventory over time for both clusters
Alleviate Pressure plans make use of the headroom in your clusters. Headroom is the number of VMs the cluster can
support, for CPU, Memory and Storage.

To specify the templates these plans use, you can configure the nightly plans for each cluster. For more information, see
Configuring Nightly Plans (on page 346)
NOTE:
To execute, this plan must ignore certain constraints. The plan ignores cluster constraints to allow migrating workloads
from the hot cluster to the cold one. It also ignores network constraints, imported DRS policies, and any Turbonomic
that would ordinarily be in effect.
Configuring an Alleviate Pressure Plan

1. Scope
The wizard first gives you a list for you to choose the hot cluster. This is the cluster that shows risks to performance. The
list sorts with the most critical clusters first, and it includes the calculated headroom for CPU, Memory, and Storage in
each cluster.

2. Cold Cluster
After you select the hot cluster, choose the cold cluster.


Working With Alleviate Pressure Plan Results

After the plan runs, you can view the results to see how the migration of workloads off of your hot cluster affects your
environment.

Viewing the Results

The results include the following charts:
• Plan Actions
You can see a list of actions to reduce the pressure on the hot cluster. It's typical to see actions to move workloads
from the hot cluster over to the cold cluster. If some VMs are overprovisioned, you might see actions to reduce the
capacity for those workloads.
• Hosts Optimized Improvements
This chart compares the current state of the hot cluster to its state after executing the plan actions. It displays the
resource utilization of the cluster's hosts both before and after the plan.
• Headroom
With these charts, you can compare the headroom between the hot and cold clusters.
• Virtual Machines vs Hosts and Storage

This chart shows the total number of virtual machines, hosts, and storage in your on-prem environment, and tracks
the data over time. Chart information helps you understand and make decisions around capacity and utilization,
based on historical and projected demand.
Re-Running the Plan

settings.

The toolbar items that display are similar to the toolbar items for a custom plan. For details, see Configuring a Custom
Plan (on page 337).
NOTE:
Plan.
Custom Plan
For an overview of setting up plan scenarios, see Settings Up User Plan Scenarios (on page 289).


When you create a custom scenario, you specify the plan scope as an initial step, and then skip the plan wizards and
jump straight into setting up the plan parameters. You can name the plan, change workload demand and the supply of
resources, and specify other changes to the plan market.
Configuring a Custom Plan

1. Scope
Specify the plan scope and then click Configure Plan at the bottom of the page.

2. Plan Configuration
Use the Plan Configuration toolbar to fine-tune your plan settings. You can change workload demand and the supply of
resources, and specify other changes to the plan market.

2.1. Add
Add virtual machines, hosts, or storage to your plan. For example, when you add hosts, you increase the compute
resources for the plan.


Copy from an Entity or Template
Choose an entity or template to copy. This describes the new entities that Turbonomic will add to the plan. For example,
you can run a plan that adds new VMs to a cluster. If you copy from a template, then the plan adds a new VM that
matches the resource allocation you have specified for the given template.
• Option 1: Copy from an entity

• Option 2: Copy from a template
If no existing template is satisfactory, create one by clicking New Template.


NOTE:
Turbonomic automatically adds any new template you create to the Template Catalog page (Settings >
Templates).
It is not possible to use templates for containers or container pods.
Use the Filter option to show entities or templates with certain properties (name, number of CPUs, etc.). This makes it
easier to sort through a long list.
Number of Copies to Add
After choosing an entity or template, it appears as an entry in the Configuration summary. Then you can set how many
copies to add.

2.2. Replace

Replacing virtual machine is a way to change the properties of VMs in your plan market. When you replace workload,
you select one or more VMs that you want to change, and then you select a template to use in their place. The list
of changed VMs displays in the Configuration Summary. You can delete individual entries from the this summary if
necessary.
Replacing hosts or storage is a way to plan for a hardware upgrade. For example, if you replace your hosts or datastores
with a more powerful template, the plan might show that you can use fewer hosts or datastores, and it will show the
best placement for workloads on those entities. You begin by selecting the entities you want to replace, and when you
click REPLACE you can then choose a template that will replace them. Note that you can only choose a single template
for each set of entities you want to have replaced. You can configure different replacements in the same plan, if you
want to use more than one template.

2.3. Remove

Removing virtual machines frees up resources for other workloads to use.
Removing hosts or storage means you have fewer compute or storage resources for your workloads. If you think you
have overprovisioned your environment, you can run a plan to see whether fewer hosts or less storage can still support
the same workload.
2.4. Actions

See the effect of enabling or disabling actions on the entities included in the plan. For example, you might plan for more
workload but know that you don't want to add more hardware, so you disable Provision of hosts for your plan. The
results would then indicate if the environment can support the additional workload.
2.5. Ignore Constraints

Choose to ignore constraints (such as placement policies) for VMs in your environment.

By default, VMs are constrained to the cluster, network group, datacenter, or storage group that their hosts belong to.
You can choose to ignore these boundaries.
For example, by default a plan does not consider moving VMs to physical hosts outside of the current cluster. If you
disable the Cluster constraint for a VM in your plan, then the plan can evaluate the results of hosting those VMs on
any other physical machine within the scope of your plan. If the best results come from moving that VM to a different
cluster, then the plan will show that result.
NOTE:
If you are adding hosts to a plan, and use host templates, then you must turn on Ignore Constraints.

2.6. Placement Policies

By default, the plan includes all the placement policies that apply to the plan scope. Also, these policies are in their real-
time state (enabled or disabled).

You can use these settings to enable or disable existing policies, or you can create new policies to apply only to this plan
scenario. For information about creating placement policies, see Placement Policies (on page 96).
2.7. Utilization
Setting utilization by a certain percentage is a way to increase or decrease the workload for the scope of your plan and
any entity added to the plan, or for specific groups. Turbonomic uses the resulting utilization values as the baseline for
the plan.

Max Host Utilization levels specify the percentage of the physical resource that you want to make available in the given
plan. By default, hosts have utilization set to 100%. For a given plan, you can set the utilization to a lower value. For
example, assume you want to simulate High Availability of 25% for some hosts in the plan. In that case, you can select
these hosts and set their utilization levels to 75%.
Max Storage utilization levels specify the percentage of the physical resource that you want to make available in the
given plan. By default, storage has utilization set to 100%. For a given plan, you can set the utilization to a lower value.
For example, assume you have one data store that you want to share evenly for two clusters of VMs. Also assume that
you are creating a plan for one of those clusters. In that case, you can set the datastores to 50% utilization. This saves
storage resources for the other cluster that will use this storage.
2.8. Baseline
Use these settings to set up the baseline of utilization metrics for your plan.


By default, the plan runs against the current state of your environment. You can set up the plan to add or remove
entities, or otherwise affect the plan calculations. But the utilization metrics will be based on the current state of the
plan. If you run the same plan multiple times, each run begins with a fresh view of your inventory.
You can select from the list of snapshots to load the utilization statistics from a previous time period into the plan. Use
this to run the plan against utilization that you experienced in the past. For example, assume a peak utilization period for
the month before the winter holidays. During the holidays you want to plan to add new capacity that can better handle
that peak. You would set the baseline to the utilization you saw during that pre-holiday peak.
2.9. Desired State

The desired state is a condition in your environment that assures performance for your workloads, while it utilizes
your resources as efficiently as possible and you do not overprovision your infrastructure. Turbonomic uses default
Desired State settings to drive its analysis. You should never change the settings for real-time analysis unless you are
working directly with Technical support. However, you can change the settings in a plan to see what effect a more or less
aggressive configuration would have in your environment.

You can think of the desired state as an n-dimensional sphere that encompasses the fittest conditions your environment
can achieve. The multiple dimensions of this sphere are defined by the resource metrics in your environment. Metric
dimensions include VMem, storage, CPU, etc. While the metrics on the entities in your environment can be any value,

the desired state, this n-dimensional sphere, is the subset of metric values that assures the best performance while
achieving the most efficient utilization of resources that is possible.
The Desired State settings center this sphere on Performance (more infrastructure to supply the workload demand), or
on Efficiency (less investment in infrastructure to supply the workload demand). The settings also adjust the diameter
of the sphere to determine the range of deviation from the center that can encompass the desired state. If you specify a
large diameter, Turbonomic will have more variation in the way it distributes workload across hosting devices.
For more information, see The Desired State (on page 12).
Working With Custom Plan Results

After the plan runs, you can view the results to see how the plan settings you configured affect your environment.

Viewing the Results

The results include the following charts:
• Plan Summary Chart
This chart compares your current resources to the resources you would get after executing the plan.

NOTE:
Under some circumstances, this chart might not count "non-participating" entities in the real-time market, such
as suspended VMs or hosts in a failover state. The following charts, on the other hand, count all entities in the
real-time market, regardless of state:
◦ Scope Preview chart (displays before you run the plan)
◦ Optimized Improvements and Comparison charts
If the plan's scope includes VMs that cannot be placed, the results include a notification indicating the number of
VMs. Click Show Details to see the list of VMs and the reasons for their non-placement.
Click Show all at the bottom of the chart to see savings or investment costs, or to download the chart as a CSV file.
• Plan Actions Chart
This chart summarizes the actions that you need to execute to achieve the plan results. For example, if you run an
Alleviate Pressure plan, you can see actions to move workloads from the hot cluster over to the cold cluster. If some
VMs are overprovisioned, you might see actions to reduce the capacity for those workloads.
The text chart groups actions by action type (on page 76). The list chart shows a partial list of actions (on page 67).

To view action details or download the list of actions as a CSV file:
◦ Click an action type in the text chart or an individual action in the list chart.
◦ Click Show All at the bottom of the chart.
• Optimized Improvements Charts for Hosts, Storage, and Virtual Machines
The Optimized Improvements chart shows how the utilization of resources would change assuming you accept all of
the actions listed in the Plan Actions chart.

◦ In many of these charts, you can change the commodities on display. To do this, go to the top-right section
of the chart, click the More options icon ( ), and then select Edit. In the new screen that displays, go to the
Commodity section and then add or remove commodities.

To restore the default commodities, use the Reset view option at the top-right section of the page.
◦ Click Show all at the bottom of the chart to see a breakdown of the current chart data by entity (for example,
show CPU, Memory, and IO Throughput utilization for each host), or to download chart data as a CSV file.
• Comparison Charts for Hosts, Storage Devices, and Virtual Machines
A Comparison chart shows how the utilization of a particular commodity (such as memory or CPU) for each entity in
the plan would change if you execute the actions listed in the Plan Actions chart.

◦ To change the commodity displayed in the chart, go to the top-right section of a chart and then select from the
list of commodities.
To restore the default commodity, go to the top-right section of the page, click the More options icon ( ), and
then select Reset view.
◦ Click Show all at the bottom of the chart to show a breakdown of the current chart data by entity (for example,
show Virtual Memory utilization for each virtual machine), or to download the chart as a CSV file.
NOTE:
For the Storage Devices Comparison chart, if you set the view to VM Per Storage and click Show all, the total
number of VMs sometimes does not match the number in the Plan Summary chart. This happens if there are VMs
in the plan that use multiple storage devices. The Storage Devices Comparison chart counts those VMs multiple
times, depending on the number of storage devices they use, while the Plan Summary chart shows the actual
number of VMs.
Re-Running the Plan

settings.

For details about these settings, see Configuring a Custom Plan (on page 337).

NOTE:
Plan.
Configuring Nightly Plans

Turbonomic runs nightly plans to calculate headroom for the clusters in your on-prem environment. For each cluster
plan, you can set which VM template to use in these calculations.
For information about viewing cluster headroom, see Viewing Cluster Headroom (on page 66).
To set templates to use for the nightly plans:
1. Navigate to the Plan Page and click NIGHTLY PLAN CONFIGURATION.


This displays a list of all the nightly plans. Turbonomic creates a nightly plan for each cluster.
2. Click the plan that you want to configure.
A fly-out appears that lists all the available templates.
3. Select the template you want for this plan.
Choose the template and click Select.

Place: Reserve Workload Resources
From the Workload Placement Page, you can set up reservations to save the resources you will need to deploy VMs at a
future date. Turbonomic calculates optimal placement for these VMs and then reserves the host and storage resources
that they need.
To reserve VMs, you will need to choose a VM template, specify any placement constraints, set how many instances to
reserve, and then indicate whether to reserve now or in the future. Because reserved VMs do not yet exist, they do not
participate in the real-time market.
About VM Templates for Reservations

VM templates specify the resource requirements for each reserved VM, including:
• Compute and storage resources allocated to each VM
• Consumed factor. This is the percentage of allocated CPU, memory, or storage that the reserved VM will utilize.
For more information about these templates, see VM Template Settings (on page 419).
About Placement of Reserved VMs

To determine the best placement for the VMs you want to reserve, Turbonomic runs a plan using the last-generated
data in nightly-run headroom plans.
NOTE:
If you have changed your environment by adding targets or changing policies, wait until the next run of headroom
plans for the affected scope before you create reservations.
When making placement decisions, Turbonomic considers the following:

• Placement constraints set in the reservation
• Demand capacity
Turbonomic calculates demand based on the resource allocation and consumed factor set in VM templates. For
example, if you want to create a reserved VM from a template that assigns 3 GB of virtual memory and a consumed
factor of 50%, Turbonomic calculates 1.5 GB of demand capacity for the reservation.
• Overprovisioned capacity

For reserved VMs, this corresponds to the resource allocation set in VM templates. Continuing from the previous
example, Turbonomic assumes 3 GB of overprovisioned capacity for a reserved VM created from a template that
assigns 3 GB of virtual memory.
For providers (hosts and storage), Turbonomic calculates overprovisioned capacity. The default overprovisioned
capacity is 1000% for host Mem and CPU, and 200% for storage. A host with 512 GB of memory will have an
overprovisioned capacity of 5 TB (5120 GB).
Providers must have sufficient demand and overprovisioned capacity to place a reservation. Turbonomic analyzes the
current and historical utilization of cluster, host, and storage resources to identify viable providers for the VMs when
they are deployed to your on-prem environment. In this way, Turbonomic can prevent congestion issues after you
deploy the VMs.
NOTE:
Turbonomic persists historical utilization data in its database so it can continue to calculate placements accurately
when market analysis restarts.
The initial placement attempt either succeeds or fails.

• Successful Initial Placements
If the initial placement attempt is successful, Turbonomic adds the reserved VM to your inventory.
In the previous example, a reserved VM that requires 1.5 GB of demand capacity and 3 GB of overprovisioned
capacity can be placed on a host with 512 GB of memory (5 TB of overprovisioned capacity), assuming no
constraints will prevent the placement.
Note that actual and reserved VMs share the same resources on providers. This means that provider capacity will
change as demand from the actual VMs changes. Turbonomic polls your environment once per day to identify
changes in provider capacity. It then evaluates if it can continue to place the reserved VMs within the same cluster,
and then shows the latest placement status.
For example, if the host for a reserved VM is congested at the time of polling, Turbonomic might decide to move
the VM to another host in the cluster that has sufficient capacity. In this case, the placement status stays the
same (Reserved). Should you decide to deploy the VM at that point, you need to deploy it to the new host. If,
on the other hand, there is no longer a suitable host in the cluster, the placement fails and the status changes to
Placement Failed. Deploying the VM at that point will result in congestion. Turbonomic will not retry fulfilling the
reservation.
• Failed Initial Placements
If the initial placement attempt is unsuccessful (for example, if all providers have seen historical congestion),
Turbonomic shows that the placement has failed and will not retry fulfilling the reservation.
Current and Future Reservations

You can create a current or future reservation from the Workload Placement Page.
• Current Reservation
Turbonomic calculates placement immediately and then adds the reserved VMs to your inventory if placement is
successful.
This reservation stays in effect for 24 hours, or until you delete it.
• Future Reservation
Set the reservation for some time in the future.

Turbonomic does not calculate placement at this time — the future reservation saves the definition, and
Turbonomic will calculate placement at the time of the reservation start date.
This reservation stays in effect for the duration that you set, or until you delete it.
Displaying the Workload Placement Page

To see the reservations that are currently in effect and to create new reservations, click the PLACE button in the
Navigation Menu.

Creating a Reservation
Reservations set aside resources for anticipated workload. While a reservation is in the RESERVED state, Turbonomic
continually calculates placement for the reserved VMs.
To create a reservation:
1. Navigate to the Workload Placement page.

2. Create a new reservation.

In the Workload Placement page, click CREATE RESERVATION.

Turbonomic displays a list of templates. Choose the template you want, and click NEXT: CONSTRAINTS.
3. Optionally, specify placement constraints.
In the Constraints section and choose which constraints to apply to this reservation.
Constraints are optional, but note that these constraints are how you ensure that the template you have chosen is
viable in the given locations that Turbonomic will choose.
The constraints you can choose include:
• Scope
Choose the datacenter or host cluster that you will limit the reservation to.
• Placement Policy
This list shows all the placement policies have been created as Turbonomic Segments. Choose which
placement policies the reservation will respect.
• Networks
Turbonomic discovers the different networks in your environment. Use this constraint to limit workload
placement to the networks you choose.
When you are done setting constraints, click NEXT: RESERVATION SETTINGS.
4. Make the reservation settings, and create the reservation.
To finalize the reservation, make these settings:
• RESERVATION NAME
The name for the reservation. You should use unique names for all your current reservations. This name
also determines the names of the reservation VMs that Turbonomic creates to reserve resources in your
environment. For example, assume the name MyReservation. If you reserve three VMs, then Turbonomic
creates three reservation VMs named MyReservation_0, MyReservation_1, and MyReservation_2.
• VIRTUL MACHINES COUNT
How many VMs to reserve.
NOTE:
You can include up to 100 VMs in a single reservation.
• RESERVATION DATE
The time period that you want the reservation to be active. Can be one of:
◦ Reserve Now
Use this to calculate the ideal placement for a workload that you want to deploy today. Turbonomic
begins planning the reservation immediately when you click CREATE RESERVATION. The reservation stays
in effect for 24 hours – At that time Turbonomic deletes the reservation.
◦ Future Reservation
This executes the reservation for the date range you specify. Turbonomic begins planning the reservation
on the day you set for START DATE. The END DATE determines when the reservation is no longer valid. At
that time, Turbonomic deletes the reservation.
When you are finished with the reservation settings, click CREATE RESERVATION. Turbonomic displays the new
reservation in the Workload Placement page. Depending on the reservation settings and your environment, the
reservation can be in one of the one of the following states:
• UNFULFILLED

The reservation request is in the queue, waiting for an ongoing reservation request to complete.
• INPROGRESS
Turbonomic is planning the placement of the reservation workloads.
• FUTURE
Turbonomic is waiting for the START DATE before it will start to plan the reservation.
• RESERVED
Turbonomic has planned the reservation, and it found providers for all the VMs in the reservation. As your
environment changes, Turbonomic continues to calculate the placement for the reservation VMs. If at any
time it finds that it cannot place all the VMs, it changes the reservation to PLACEMENT FAILED.
• PLACEMENT FAILED
Turbonomic cannot place all the reservation VMs. As your environment changes, Turbonomic continues to
calculate placement for the VMs. If at any time it finds that it can place all the VMs, it changes the reservation
to RESERVED.
• INVALID
An error occurred while planning the placement of the reservation VMs.
NOTE:
The list of reservations refreshes whenever you open the Workload Placement page. To see changes in
reservation state, navigate away from the page, and navigate back to it again.

Managing Reservations

The PLACE page displays the current list of reservations. You can expand items in the list to see some details, or you can
click to view the full details. You can also select items to delete them, which cancels the reservation or deployment.
For an entry in the RESERVED state, you can click the entry name to open the Reservation Settings fly-out.
To delete a reservation, select it in the list and click the DELETE icon.
To see details about the provider entities, or the datacenter that is hosting the reserved VMs, click that entity name.
Deploying Workloads to the Reserved Resources

When you reserve resources, you know that they will be available for you to deploy actual VMs in your environment. To
deploy these VMs, you should:
1. Note the placement that your reservation has calculated.
Expand the reservation entry in the Workload Placement page and note the hosts and storage that will provide
resources for your VMs.
2. Delete the reservation.
Before you deploy the reserved VMs, you should delete the reservation. This frees up the Turbonomic market to
manage the placement of the VMs you are about to deploy.
3. Deploy the actual VMs.
In your Hypervisor user interface, deploy the VMs to the hosts and storage that you noted. When you are done,
Turbonomic will manage their placement the same as it manages the rest of your environment.

Dashboards: Focused Views

Dashboards give you views of your environment that focus on different aspects of the environment's health. At a glance,
you can gain insights into service performance health, workload improvements over time, actions performed and risks
avoided, and savings in cost. For cloud environments, you can see utilization of reserved instances, potential savings,
required investments, and the cost/performance of specific cloud accounts.
The Dashboards page lists all the dashboards that are available to you, including built-in and custom dashboards that
your account can access. To view a dashboard, click its name in the list.
From the Dashboard page, you can also create your own custom dashboards.
NOTE:
In charts that show tables, if the table contains more than 500 cells, then the User Interface disables the option to
export the chart as PDF. You can still export the chart as a CSV file to load in a spreadsheet.

Built-in Dashboards
Built-in Dashboards are scorecards of your environment. They demonstrate how well you are improving performance,
cost, and compliance, as well as opportunities for further improvements that are available.
Turbonomic ships with these dashboards:
• On-Prem Executive Dashboard
• Cloud Executive Dashboard
• Container Platform Dashboard
NOTE:
Turbonomic ships these dashboards with default configurations. To edit a dashboard, you must log in with the
administrator user account. Users logged in with that account can add or remove chart widgets, and change widget
scopes. For information about editing dashboards, see Creating and Editing Custom Dashboards (on page 359).
On-Prem Executive Dashboard


The On-Prem Executive Dashboard shows the overall performance, capacity, and compliance in your on-prem
infrastructure. This includes insights into:
• Actions History
◦ The On-Prem Environment chart widget shows you an overview of your on-prem environment that Turbonomic
is managing and controlling. The chart displays the workloads and the infrastructure that Turbonomic
discovered.
◦ The Workload Improvements chart widget shows how the efficiency, performance, and policy risks associated
with your workloads have disappeared as you have increased your adoption of Turbonomic Workload
Automation. The chart tracks how your workloads have grown as your execution of actions have increased or
decreased as your environment achieves and maintains its desired states over time.
◦ The All Actions chart widget shows the number of actions that Turbonomic has generated versus the ones
executed. This gives you an understanding of where there were more opportunities for improvement that were
not taken in the past versus those that are available today.
• Opportunities
◦ The Workload by Performance, Workload by Compliance, and Workload by Efficiency chart widgets indicate
workload health by showing the risks that are currently in your environment and each classification of those
risks. You can click Show Action on the chart to reveal all of the outstanding actions that need to be taken to
resolve those risks on your workloads.
◦ The Necessary Investments and Potential Savings chart widgets together project how the current actions to
improve performance, efficiency, and compliance will impact your costs.
• Current State
◦ This chart shows the top clusters in your on-prem environment by CPU, memory, and storage capacity or
utilization. In the default view, the chart shows the top clusters by CPU headroom (available capacity). It also
shows time to exhaustion of cluster resources, which is useful for future planning (for example, you might need
to buy more hardware).
◦ The Virtual Machines vs Hosts and Storage and the Virtual Machines vs Hosts and Storage -Density chart
widgets show how your overall density has improved in your on-prem environment. A high count of VMs per
host or storage means that your workloads are densely packed.

Cloud Executive Dashboard

NOTE:
For the Version 7 family of Turbonomic, cloud features are Early Access, only. These features appear in the user
interface and the documentation, but this version does not enable them for use.
The Cloud Executive Dashboard shows your overall cloud expenditures and how you can improve performance and
reduce cost. This includes insights into:
• Actions History
◦ The Cloud Environment chart widget shows you an overview of your cloud environment that Turbonomic is
managing and controlling. The chart displays the workloads, cloud service providers, and cloud accounts that
you currently have set up as Turbonomic targets.
◦ The Workload Improvements chart widget shows how the efficiency, performance, and policy risks associated
with your workloads have disappeared as you have increased your adoption of Turbonomic Workload
Automation. The chart tracks how your workloads have grown as your execution of actions have increased or
decreased as your environment achieves and maintains its desired states over time.
◦ The Cumulative Savings chart widget shows you the cost savings for executed cloud actions compared to the
cloud actions that you have not executed (missed savings).
• Opportunities
◦ The Workload by Performance, Workload by Compliance, and Workload by Efficiency chart widgets indicate
workload health by showing the risks that are currently in your environment and each classification of those
risks. You can click Show Action on the chart to reveal all of the outstanding actions that need to be taken to
resolve those risks on your workloads.
◦ The Necessary Investments and Potential Savings chart widgets together project how the current actions to
improve performance, efficiency, and compliance will impact your costs.
◦ Cloud Estimated Cost chart widget shows estimated monthly costs and investments for the cloud. Monthly cost
amounts are summarized as amounts with and without actions.

• Current State
◦ The Top Accounts chart widget shows all of the cloud accounts in your cloud environment and what the
utilization is for each account. You can see the number of workloads, estimated monthly costs, saved by
actions, and actions taken. In the default view, the chart shows the top cloud accounts and you can click Show
All button to see all of the accounts. In the Show All list, you can also download the account cost data as a CSV
file or PDF.
◦ The Cost Breakdown by Tag chart widget shows the tags you have assigned to your cloud resources and the
costs associated with each of these tagged categories. The Cost Breakdown by Cloud Service Provider chart
widget is an Expenses chart widget that shows your expenses for each cloud service provider.
◦ Usage of Reserved Instances
Reserved Instances (RIs) reduce cost by offering a subscription-based payment plan. Turbonomic discovers
these RI plans and tracks usage patterns to identify workloads that are good RI candidates. The Cloud Executive
Dashboard shows whether you are getting the most out of your current RI strategy.
The RI Utilization chart widget shows how well you have utilized the reservation inventory. The chart compares
the capacity for all reservations versus the RI consumption by virtual machines.
The RI Coverage chart widget compares the capacity of your current VM workload to the capacity of workload
that is covered by Reserved Instances.
Container Platform Dashboard


The Container Platform Dashboard shows the overall performance, capacity, and health of your container infrastructure.
This includes insights into:
• Top Container Platform Clusters
Assess the health of your clusters and sort them by risk level.
• Top Namespaces
Identify namespaces that are running out of quota, and how much resources each namespace is using in both
quotas and actual utilization.
• Top Services
Assess the impact of Services on the performance of your applications.
Creating and Editing Custom Dashboards

A custom dashboard is a view that you create to focus on specific aspects of your environment. You can create
dashboards that are private to your user account, or dashboards that are visible to any user who logs into your
Turbonomic deployment.
Two common approaches exist for creating custom dashboards:
• Scope First
You can create a dashboard in which all of the chart widgets focus on the same scope of your environment. For
example, you might want to create a dashboard that focuses on costs for a single public cloud account. In that case,
as you add chart widgets to the dashboard, you give them all the same scope.
• Data First
You might be interested in a single type of data for all groups of entities in your environment. For example, each
chart widget in the dashboard can focus on Cost Breakdown by Cloud Service, but you set the scope of each chart
widget to a different cloud region or zone.
Of course, you can mix and match, according to your needs. You can set any scopes or data sources to the chart widgets
in a dashboard to set up whatever organization and focus that you want.
NOTE:
If you set a scope to your Turbonomic session, the specified scope does not affect your custom dashboards. For
information about scoped views, see Working With a Scoped View (on page 54).
Creating a Dashboard
To create a custom dashboard:
1. Navigate to the Dashboards Page.

Click to navigate to the Dashboard Page.
This page lists all dashboards that are available to you.
To view a dashboard, click its name in the list.
2. Create a new dashboard.


Click NEW DASHBOARD to add a new dashboard to your Turbonomic session. The dashboard appears with a
default name and without chart widgets. The time range in the Time Slider is set to 24 hours by default.

3. Name the dashboard.
Give a name that describes the dashboard. If you will share the dashboard with all Turbonomic users, the name
will help them decide whether to view it.
4. Add chart widgets to the dashboard.

Add as many chart widgets to the dashboard as you want. See Creating and Editing Chart Widgets (on page 362).
5. Optionally, set the dashboard access.
Click Gear to change the setting.
Dashboard access can be:
• Only Me – The dashboard is only available to your Turbonomic user account.
• All Users – Every Turbonomic user can see this dashboard.
By default, access is set to Only Me.
As soon as you create a new dashboard, it appears in the list on the Dashboard Page. Users with access to it can click the
dashboard name in the list to view it.
At any time, if you are an administrator or the dashboard owner, you can view and make the following changes to the
dashboard:
• Add, edit, or delete widgets
• Change the dashboard name
• Change the dashboard access setting
For executive dashboards, only an administrator (username=administrator) can edit an executive dashboard.
Editing a Dashboard
If you have created a dashboard, you can change the name of the dashboard, its access settings, and its chart widgets.
To change the chart widgets, see Creating and Editing Chart Widgets (on page 362).

To edit a dashboard's name or change its access settings:


2. Click the name of the dashboard that you want to edit.
3. Click Gear in the dashboard.
In the dashboard's Edit fly-out, make your changes.

For the dashboard's access, you can set:
• Only Me – The dashboard is only available to your Turbonomic user account.
• All Users – Every Turbonomic user can see this dashboard.
4. When you are done, close the fly-out panel.
Your changes take effect when you close the fly-out.
Deleting a Dashboard
If you are an administrator or the dashboard owner, you can delete a custom dashboard. You cannot delete executive
dashboards.
To delete a custom dashboard:

This page lists all dashboards that are available to you.
2. Delete one or more dashboards.
In the list, choose the checkbox for each dashboard you want to delete and click Trash can.

Creating and Editing Chart Widgets

Turbonomic displays information about your environment in various chart widgets. To focus on the information you
need, you can add new chart widgets to scoped views and dashboards, and you can edit existing chart widgets. You can
also pull the corners of chart widgets to resize them and change the display order of chart widgets in dashboards.
When you create or edit a chart widget, you can choose a variety of settings. For example, in the Top Utilized chart
widget, if you choose Clusters as the Entity Type, you can then choose Utilization as the Data Type and Storage
Provisioned as the Commodity.
Creating a Chart Widget

To create a new chart widget:
1. Click Add Widget to open the Widget Gallery.

On a dashboard, click Add Widget at the top-right corner. In a scoped view, click Add Widget on the right above
the charts.
2. Choose a chart widget in the Widget Gallery.
The Widget Gallery is a list of thumbnail previews of chart widgets.
You can scroll through the gallery or search it. For example, if you type "Health" in the Search field, the results are
two chart widgets, Health and Workload Health. You can choose chart widgets from these categories:
• Actions and Impact
• Status and Details
• Cloud
• On-Prem
To see the possible displays of a specific chart widget, use the horizontal scroll bar at the bottom of the thumbnail
to scroll through the display choices.
To choose a chart widget to add it to your dashboard, click the thumbnail preview.
The Widget Preview window with the Edit fly-out opens.
3. Configure the settings for your chart widget.
Chart widget settings determine the data that the chart widget will show.
In the Edit fly-out, choose the settings and click Update Preview to display the result in the Widget Preview pane.
When you are satisfied with your settings, click Save. The chart widget is added to your dashboard.
For information about settings, see Chart Widget Settings (on page 363).
For example:


To delete a chart widget from your dashboard, choose Delete in the More options menu at the top-right corner of
the chart widget.
Methods to Access Chart Widget Settings

Two methods exist for accessing the chart widget settings in the Edit fly-out:
• You can access the settings in the Edit fly-out when you add a chart widget to your dashboard after you click a
thumbnail preview.
• For an existing chart widget in a dashboard, you can choose Edit in the More options menu at the top-right corner.

Chart Widget Settings

Chart widget settings vary according to the type of chart widget. Also, depending on the value that you choose for a
setting, additional settings may appear. The following is a list of frequently-used chart widget settings:
• Scope

The set of entities in your environment that this chart widget represents. By default, the chart widget scope is set to
Global Environment.
For every type of chart widget, you have the option to set the chart's scope. To do so:
1. Click Click to change scope to open the Select Scope fly-out.
2. In the Select Scope fly-out, choose the entity, group, or account that you want.
The ACCOUNTS tab is available depending on the type of chart widget.
Your choice appears in the Scope field.

• Timeframe
The timeframe for historical data or projections in the chart. Choices for the chart's timeframe are: Default, Last 2
Hours, Last 24 Hours, Last 7 Days, Last 30 Days, and Last Year.
If you set the timeframe to Default, the dashboard Time Slider controls the timeframe setting. For example, if
your dashboard Time Slider is set to one month (1M), then all chart widgets with the Default timeframe in that
dashboard are set to one month and show information for one month. Note that the dashboard Time Slider does
not override the other specific timeframe settings.
• Chart Type
The chart widget's display type. Most chart widgets can display horizontal bar or ring charts. Other display choices
can include tabular data, band chart, stacked bar, line, or area charts.
NOTE:
For summary charts like horizontal bar and ring charts, when the legend has more than four categories, the
remaining categories are represented as a fifth category named "Other."
• Entity Type
The type of entities or their data that you want to display in this chart widget. Choices vary (for example,
Applications, Hosts, Virtual Data Centers, Storage Devices, and so on).
• Commodity

The resources that you want this chart widget to monitor. Some charts can monitor multiple commodities. Choices
vary (for example, CPU, Memory, Virtual Storage, and so on).
Chart Types
Turbonomic provides many different types of charts in the Widget Gallery. To design dashboards, you should be familiar
with the data each chart presents. These charts provide information on actions, impact, status of your environment, and
details about specific entities, cloud, and on-prem environments.
Actions and Impact Chart Types

These chart widgets provide information on actions, pending actions, risks that you avoided, improvements, and
potential savings or investments.
Pending Actions Charts

Pending Actions charts show the actions that Turbonomic recommends to improve the current state of your
environment.
Chart Type
You can set the display to:
• Text
• Ring Chart
• Horizontal Bar
• List
Examples:
• Text
The text chart shows the number of actions for each action type. It gives a quick visual indication of the kinds of
actions that are pending. For details, see Action Types (on page 76).


• Ring Chart
The ring chart counts the number of actions for each action type. It gives a quick visual indication of the kinds of
actions that are pending. For details, see Action Types (on page 76).

• Horizontal Bar
The horizontal bar chart counts the number of actions for each action type. It gives a quick visual indication of the
kinds of actions that are pending. For details, see Action Types (on page 76)


• List
The list chart shows an abbreviated listing of the actions for the chart's scope. For details about the different actions
generated by the product, see Actions (on page 67).

At the bottom of the chart, click Show All Actions to see a full list of pending actions that are in the scope of the chart,
along with action details and controls to execute actions. For details, see Pending Actions List (on page 88).
Actions Charts
Actions charts keep a history of pending (not executed) and executed actions. These charts use historical data from the
Turbonomic database. You can set the chart to show hourly, daily, or monthly data points.
Filter
You can filter the chart to show All Actions (pending and executed actions) or only Executed Actions.

Chart Type
• Tabular
• Area Chart
• Text
• Stacked Bar Chart
Stacked Bar Chart

For the Stacked Bar Chart, each bar represents a time period. Hover over the bar to see the number of unique actions
for that time period. In the default view, the bars represent actions per hour in the last 24 hours. The 2:00 PM bar, for
example, shows actions between 2:00 PM and 2:59 PM.
A pending action that remains valid for an extended period of time is counted once for each hour, day, and month
it remains pending. This also applies to pending actions that go away as conditions in the market change, but are
generated again in the future. Once a pending action is executed, it is counted once (this time, as an executed action) on
the hour, day, and month of execution.
Consider the following scenarios.
• An action was generated at 1:25 PM and then executed two hours later at 3:25 PM.
◦ For per-hour views (Last 24 Hours or Default), the action will be counted three times – as a pending action in
the 1:00 PM and 2:00 PM bars, and as an executed action in the 3:00 PM bar.
◦ For per-day (Last 7 or 30 Days) or per-month (Last Year) views, the action will be counted once (as an executed
action) on the day or month of execution.
• An action was generated at 6:20 PM but went away (without being executed) in the next hour. The same action was
generated again the next day at 9:10 AM and was executed immediately.
◦ For per-hour views, the action will be counted twice – as a pending action in the 6:00 PM bar and as an
executed action in next day's 9:00 AM bar.
◦ For per-day views, the action will also be counted twice – as a pending action on Day 1 and an executed action
on Day 2.
◦ For per-month views, the action will be counted once (as an executed action) on the month of execution.
Use the chart to evaluate the rate of action execution, which underscores the importance of executing actions in a
timely manner. As pending actions persist, they become more challenging to track and your environment stays in a risky
state longer. To reduce potential delays in executing actions, consider action automation.

Tabular Chart
To see the full list (on page 88) of actions, click Show All at the bottom of the chart.

Risks Avoided Charts

As you execute the actions Turbonomic has recommended, you improve your environment's health and avoid risks to
performance or cost. These charts show how many risks you have avoided over time. For example, the charts can show
how many over-provisioning and congestion risks you avoided.
Chart Type
• Text
• Ring Chart
• Horizontal Bar
Optimized Improvements Charts

Turbonomic automatically executes or recommends actions, depending on the policies that you set up. For the
recommended actions, you can use Optimized Improvements charts to show how utilization of resources would change
assuming you accept all of the pending actions (on page 365).
Entity Type
Entity types you can choose include:
• Business Applications
• Business Transactions
• Services
• Chassis
• Containers
• Container Pods

• Container Specs
• Namespaces
• Workload Controllers
• Data Centers
• Databases
• Database Servers
• Disk Arrays
• IO Modules
• Internet
• Logical Pool
• Networks
• Hosts
• Regions
• Storage Devices
• Storage Controllers
• Switches
• Virtual Data Centers
• Volumes
• Zones
Commodity
Depending on the entity type, you can add different resource commodities that you want to measure. For a chart of
Hosts, you can measure commodities such as CPU, Memory, and even network flow between VMs that are on the same
host (In-Provider Flow) or on other hosts (In-DPOD or Cross-DPOD Flow).
Display
Optimized Improvements charts show two bar charts for the entities that are in scope – one for current consumption,
and the other for the consumption you would expect to see if you execute all the actions.
Example: An Optimized Improvements chart for applications


Potential Savings or Investments Charts

These charts show potential savings or necessary investments in your cloud expenditure, assuming you execute all the
pending actions that Turbonomic identifies as a result of its analysis.
For example, if some workloads risk losing performance, Turbonomic might recommend scaling actions for the virtual
machine to increase resources. The Necessary Investments chart shows how these actions translate to an increase in
expenditure.
On the other hand, if there are pending actions to scale a virtual machine, which result in reduced monthly costs, the
Potential Savings chart shows the reduced cost that would result from those actions.
This chart also track RI optimization actions. Virtual machine scaling actions may result in a freed up RI, which can now
be applied to a different virtual machine. RI optimization actions reflect the potential savings resulting from reassigning
the RI to a different virtual machine. These actions are not executed by Turbonomic users. They reflect RI reassignment,
which the cloud provider will take care of.
The projected amounts include on-demand costs for VMs. For information about on-demand cost calculations, see
Estimated On-demand Monthly Costs for Cloud VMs (on page 29).
Type
You can choose Potential Savings or Necessary Investments.
Chart Type
• Text
• Ring Chart
• Horizontal Bar
For the ring chart, you can click an action type (for example, Scale Volumes) in the chart or legend to display a filtered
view of the actions list.
Show All
Click Show all at the bottom of the chart to see a breakdown of savings or investments by action/entity type and entity.
By default, the actions are shown in order of largest amounts so you can easily identify which ones will incur the highest
costs or introduce the most savings.
For example, you can see the savings you would realize if you execute all Scale actions on the virtual machines included
in the chart's scope.

The table then breaks down the total savings by individual virtual machines, and includes links to the specific actions
that you need to perform to realize those savings.


You can also compare instance types, costs, and RI coverage before and after executing the actions, alllowing you to
easily identify actions with the most savings.
Status and Details Chart Types

These chart widgets provide information on the status of your environment and details about specific entities.
Health Charts
Health charts show the current status of your environment, by entity type. For example, you can choose to show the
health of all hosts in your environment, or the health of all the workloads running on a public cloud region.
Entity Type
• Services
• Chassis
• Containers
• Container Pods
• Container Specs
• Namespaces
• Data Centers
• Databases
• Disk Arrays
• IO Modules
• Internet
• Logical Pool
• Networks
• Hosts
• Regions

• Storage Devices
• Switches
• Volumes
• Zones
Chart Type
• Text
• Ring Chart
• Horizontal Bar
Basic Info Charts

The Basic Info charts provide an overview of a single entity or individual Azure resource group that you have chosen as
your scope.
Type
You can choose:
• Entity Information
This chart shows basic information (ID, Name, Type, State, Severity, Target Name, and so on) for the scoped entity or
Azure resource group.
• Related Tag Information
This chart lists any available tag information for the scoped entity or Azure resource group. For example, in a cloud
environment, if a virtual machine has tags applied to it, the chart shows those tags for the virtual machine.
Display
The chart shows the information as Tabular.
Capacity and Usage Charts

These charts list the resources for the selected entity type, showing their allocated capacity and how much of that
capacity is in use.
Entity Type

• Services
• Containers
• Container Pods
• Container Specs
• Namespaces
• Data Centers
• Disk Arrays
• Logical Pool
• Networks
• Hosts
• Regions
• Zones
• Storage Devices
• Volumes
Commodity
Depending on the entity type, you can add different resource commodities that you want to measure. For example, for a
chart of Virtual Machines, you can measure commodities such as virtual CPU, memory, and storage.
NOTE:
For a cloud database server, the chart might show incorrect used values for vMem and Storage Amount after an
action executes. It could take up to 40 minutes for the correct values to display.
Display
Multiple Resources Charts

Multiple Resources charts show the historical utilization of commodities for the scoped entity or a group of entities. The
vertical bar shows the current moment – plots that extend to the right project utilization into the future.
Entity Type
• Services

• Containers
• Container Pods
• Container Specs
• Namespaces
• Data Centers
• Disk Arrays
• Logical Pool
• Networks
• Hosts
• Regions
• Zones
• Storage Devices
• Volumes
Commodity
Depending on the entity type, you can add different resource commodities that you want to measure. For example, for a
chart of volumes, you can measure commodities such as IO throughput, storage access, and storage amount.
Show Peaks
Edit the chart and choose the Show Peaks checkbox to include peak information in the chart.
Display
The chart shows the historical utilization and, if chosen, the peak information as a Line chart.
Resources Charts
Resources charts show the utilization of a resource over time, for the entities in the chart's scope. The chart title shows
the resource that you are plotting, as well as the chart's current scope.
To see finer details about your environment, you can set up charts that show utilization of specific commodities. For
example, you can set up a dashboard with a number of Resources charts with their scopes set to the same cluster. Such
a dashboard gives you a detailed look at the health of that cluster. Or you could make a dashboard with each chart
scoped to a different cluster, but have all the charts show the same resource utilization.
Ring Chart
For certain entity types (such as hosts, storage, and disk arrays), you will see a ring chart on the left that indicates the
current overall utilization of a particular resource. Hover over the ring chart to see the following information:


• Free: Available capacity
• Used: Utilized capacity
• Reserved: Unavailable capacity due to utilization constraints
The sum of Free and Used capacity equals the total allocated capacity.
In addition to showing the currently discovered free and used capacity, Turbonomic also calculates Reserved capacity
based on utilization constraints set in policies.
For example, for a cluster with 100 GB of allocated storage, Turbonomic might discover 80 GB of free capacity, and 20
GB of used capacity. If the cluster is currently applying a storage policy that has a utilization constraint of 90%, then
Turbonomic will show 10 GB of reserved capacity.
Commodity
You can set a Resources chart to one of the following resources:
• Ballooning
Percentage of the host's ballooning capacity that is in use.
• CPU / CPU Allocation / CPU Provisioned
Percentage of CPU cycles that are devoted to processing instructions.
• Connection
The connections in use, as a percentage of the maximum connections allowed on the database. Database
configuration determines the capacity for this resource.
• DBCacheHitRate
Percentage utilization of the database server’s allocated cache hit rate, where a greater value indicates fewer disk
reads for data.
• DBMem
The memory in use by the database, as a percentage of the allocated capacity. Database configuration determines
the capacity for this resource. Note that for databases, Turbonomic uses this resource to drive actions, instead
of the VMem on the hosting VM. This means that actions are driven by the actual memory consumption on the
database.
• Disk Array Access
• Host LUN Access
• Heap
The heap capacity allocated for an application. Charts show the percentage of capacity that is used by an
Application Component.
• IO Throughput
Data rate through the host’s IO adapter, measured in KBytes/sec.
• Memory / Memory Allocation / Memory Provisioned

Host memory, measured in Kbytes.

• Number of Disks
• Number of Replicas
For details, see Number of Replicas chart (on page 378).
• Net Throughput
Data rate through the host’s Network adapter, measured in Kbytes/sec.
• Port Channel
• Q16 / Q1 / Q2 / Q32 / Q4 / Q64 / Q8 VCPU
• Remaining GC Capacity
Percentage of CPU time not spent on garbage collection (GC).
• Response Time
Percentage utilization of a resource’s allocated response time.
• SLA Commodity
• Storage Access
Storage access operations per second.
• Storage Allocation
• Storage Amount
• Storage Latency
Percentage of allocated latency that is in use on the storage.
How much the given storage is over-subscribed. Storage Provisioned capacity is the storage capacity multiplied by
the Storage Overprovisioned Percentage (200 by default). The higher this value, the greater the risk that storage is
over-committed.
• Swapping
The rate of memory swapping to disk, in bytes per second.
• Tenancy Access
• Threads
Percentage of thread capacity that is consumed by an Application Component.
• Transaction
Percentage of an application’s allocated transaction capacity that is in use.
• TransactionLog
The disk space devoted to transaction logging for a database.
• Virtual CPU
The allocated CPU capacity, measured in MHz.
• Virtual Memory
The allocated memory capacity, measured in Kbytes.
Note that percentages of allocated VMem are measured against the VMem limit (if set) or the allocated VMem
capacity, whichever is less. This is also true in reports and recommended actions. For example, assume a VM with
allocated VMem of 8 GB, but a limit of 4 GB. In this case, the percentage in a chart shows the percentage utilized of
4 GB.

• Virtual Storage
The allocated virtual storage capacity, measured in Kbytes.
Options
Choose Show Utilization to see averages and peaks/lows, or Show Capacity to see averages and peaks/lows versus
capacity.
The Show Summary option adds a ring chart to the view, showing the current utilization of the selected commodity.
Chart Type
You can set the following types of display:
• Line Chart
A line plot showing resource utilization over time. The vertical green bar shows the current moment – Plots that
extend to the right project utilization into the future.
• Band Chart
Lines plot average capacity and average used. The chart shows a band where its thickness indicates peaks and lows.
Number of Replicas Chart

This chart shows the replicas of Application Components running over a given time period.
Use this chart if:
• SLO-driven scaling is enabled for a Service, and provision or suspend actions are executed by Turbonomic. These
actions adjust the number of replicas to help you meet your SLO goals.
Or
• Kubernetes Horizontal Pod Autoscaler (HPA) is enabled for a Deployment, ReplicaSet, or StatefulSet that is exposed
as a Service. Turbonomic discovers adjustments to the number of replicas made by HPA.
The chart shows following information:
• Capacity values
The number of desired pod replicas configured in the Workload Controller that backs the Service. This can be
configured in Deployment, ReplicaSet, StatefulSet, ReplicationController or DeploymentConfig.
The chart plots the maximum observed capacity within the given time period.
• Used values
The number of ready pods owned by the Workload Controller. Pods in other states (for example, pending pods) are
not counted.
The chart plots the average used values within the given time period. Hover over the chart to see the minimum and
maximum used values.
Top Utilized Charts

Top Utilized charts show the entities or groups with the most utilization.

Entity Type
• Accounts (on page 380) (public cloud)
• Services
• Zones
• Chassis
• Clusters (on page 380) (of hosts)
• Containers
• Container Pods
• Container Specs
• Namespaces
• Data Centers
• Databases
• Disk Arrays
• IO Modules
• Internet
• Logical Pool
• Networks
• Hosts
• Resource Groups (on page 381)
• Regions
• Storage Devices
• Switches
• Volumes
• Wasted Files
Data Type
Depending on the entity type (for example, Clusters), you can choose Headroom or Utilization information in the chart.
Commodity
Depending on the entity type, you can add one or more different resource commodities that you want to measure.

Display
The chart lists the top entities by utilization of the commodities that you or the system has set. Depending on the entity
type and scope, you can sort the information. To view the utilization details, hover over the entity to display the tooltip.
For cloud entities, the estimated cost for those entities also display.
To drill down to an entity, click the entity name in the chart. This sets the scope to that entity.
Click the ACTIONS button for an entity to examine the actions that are pending for it, and then decide which ones are
safe to execute.
Example: A top clusters chart which can be sorted by CPU headroom or CPU exhaustion.

Top Clusters Chart

This chart shows the top clusters in your on-prem environment by CPU, memory, and storage capacity or utilization.
In the default view, the chart shows the top clusters by CPU headroom (available capacity). It also shows time to
exhaustion of cluster resources, which is useful for future planning (for example, you might need to buy more
hardware).
Click the ACTIONS button for a given cluster to see the actions that Turbonomic recommends to keep cluster resources
in the desired state, and then decide which ones are safe to execute.
Click Show All to see all of the clusters. In the Show All list, you can also download capacity data as a CSV file. Click a
cluster name to set the scope to that cluster and view more details about its current capacity and health.
Top Accounts Chart

This chart lists all the managed accounts in your cloud environment. For each account, it shows the cost for all services
in the last 30 days. Services include compute, storage, IP, database, reservations, and data transfer. It also shows the

savings you would realize if you execute the pending actions. Click the ACTIONS button to examine these actions and
decide which ones are safe to execute. You can also click an account name to set the scope to that account.
Click Show all to view additional information, including the total monthly cost for all managed accounts, and the
number of actions that have been executed for individual accounts or workloads, along with the resulting savings. You
can also download the accounts list as a CSV file.
NOTE:
Specific RIs can provide savings for multiple accounts. However, individual accounts show the full RI savings, which
can result in exaggerated savings for that account.
For AWS GovCloud environments, you will see all the GovCloud accounts (master and member accounts) and the
associated standard accounts that you have added as targets. The standard accounts are not required, but adding
them lets you see the 30-day costs for your GovCloud workloads. For Azure Government, you will see the subscriptions
discovered via the service principal and EA targets that you have added. For more information, see Support for
Government Workloads (on page 39).
Top Resource Groups Chart

This chart highlights the estimated monthly cost for the top resource groups in your cloud environment and the savings
you would realize if you execute the pending actions. Click the ACTIONS button to examine these actions and decide
which ones are safe to execute. Click a resource group to set the scope to that group.
The chart also counts actions that have been executed for individual groups, and then shows the resulting savings.
Workload Health Charts

Workload Health charts show the health of workloads from the compliance, efficiency improvement, and performance
assurance perspectives. These charts use current (real-time) data for the workloads chosen for the chart widget scope.
Chart Type
• Text
• Ring Chart
• Horizontal Bar
Breakdown
You can choose:
• Workload by Compliance
A virtual environment can include policies that limit availability of resources. It’s possible that the environment
configuration violates these defined policies. In such cases, Turbonomic identifies the violation and recommends
actions that bring the entity back into compliance.
• Workload by Efficiency Improvement
Efficient utilization of resources is an important part of running in the desired state. Running efficiently maximizes
your investment and reduces cost. When Turbonomic discovers underutilized workloads, it recommends actions to
optimize operations and save money.

• Workload by Performance Assurance

Ultimately, the reason to manage workloads in your environment is to assure performance and meet QoS goals.
When Turbonomic detects conditions that directly put QoS at risk, it recommends associated actions to assure
performance. You can consider these critical conditions, and you should execute the recommended actions as soon
as possible.
Workload Health charts indicate actions that you should consider to improve the health of workloads. To see a list of
actions, click Show Actions at the bottom of the chart.
Environment Charts
Environment charts provide an overview of your environment. They show the targets that you are managing and count
the entities that Turbonomic has discovered through those targets. For example, you can display the cloud service
providers, hypervisors, and the number of workloads.
Environment Type
You can choose one of the following views:
• Hybrid (both on-prem and cloud)
• Cloud
• On-Prem
Display
The chart shows the information as a Text chart type.
Workload Improvements Charts

Workload Improvements charts track the health of workloads in your environment over time, and map the health to the
number of actions Turbonomic has executed in that time period.
In the chart, you can see the significance and value of executed actions:
• Workloads Overall
This is the total number of workloads over time.
• Workloads with Performance Risks
These are the workloads that are not performing well.
• Inefficient Workloads
These are the workloads that are running on under-utilized hosts or are not being utilized.
• Workloads Out of Compliance
These are the workloads that are violating a placement policy. Workloads that are not in compliance might be
running on a host or placed on storage, for example, that violate a placement policy.
• Executed actions
Actions that Turbonomic executed.
The vertical line shows when the last data point was polled in your environment.

Environment Type
You can choose one of the following views:
• Hybrid (both on-prem and cloud)
• Cloud
• On-Prem
Display
The chart shows the information as a Line chart.
Cloud Chart Types

These chart widgets provide information on the status of your cloud environment.
For many cloud chart widgets that display costs and savings, Turbonomic uses the billing reports from your cloud service
providers to build a picture of your overall costs. The data includes all costs that the service provider includes in the
billing report. Turbonomic parses these reports into the formats that it uses for the cloud chart widgets.
NOTE:
In order for Turbonomic to access AWS monthly reports, you must have created a Cost and Usage report in your AWS
account and you must store it in an S3 bucket.
Billing Breakdown Charts

Billing Breakdown charts show your expenditure on cloud services, so you can track overall cost, cost by region, or cost
by cloud accounts. Turbonomic discovers pricing for cloud services through the cloud accounts and Azure subscriptions
that you configured as targets.
Chart Type
• Text
• Ring Chart
• Horizontal Bar
Expenses Charts
To help you manage costs for your public cloud environment, Turbonomic tracks compute, storage, license, and IP costs
for the workloads in your environment. Are you spending too much on your cloud resources? You can see how your
expenses evolve and keep track of these costs over time.
Turbonomic uses the cost for services and workload expenses to track your cloud spend. See Tracking Cloud Cost (on
page 28) for more information about service cost data, compute, storage, license, and IP costs.

Commodity
You can choose:
• Expenses
See your hourly expenses over time, as well as overall monthly and yearly costs.
• Average Expenses
See your average cost per Virtual Machine, as well as overall monthly and yearly costs.
• Billed Cost by Service Provider
See costs over time for each cloud service provider that you use in your cloud environment. For example, you can
compare the costs you incur on AWS to costs on Azure.
You can open more than one account from a single service provider. If you are running workloads on different
service providers, then this chart shows the distribution of costs across them.
• Billed Cost by Account
See costs over time for each account that you have set up as a target in Turbonomic.
Each public cloud target that you configure for Turbonomic represents a public cloud account. You can choose one
or more specific accounts depending on your configured public cloud targets. This chart gives you a quick read out
of your costs. You can see whether one account shows unusually high cost, or perhaps an account is hardly used at
all and you can consider closing it down.
• Billed Cost by Service
This chart shows costs over time for each cloud provider service that you use in your cloud environment. For
example, you can see costs for your Amazon EC2 instance or AWS Cost Explorer.
To evaluate your use of different services, you can follow your expenditure for each one. Note that for AWS clouds
the service names begin with "Amazon" or "AWS". Other services show the names as they are presented in the
service provider's billing report. You can also set the scope of this chart to an Azure Resource Group or a group of
Resource Groups.
• Workload Cost Breakdown
This chart shows costs over time for each component of your cloud utilization. The vertical line indicates when the
last data point was polled from your environment. Data points to the right of the vertical line are projections into
the future.
You can see costs for:
◦ On-Demand Compute
◦ RI Compute
◦ Spot Compute
◦ On-Demand License
◦ Reserved License
◦ Storage
◦ IP (static IPs for workloads)
This chart reflects on-demand costs for VMs based on uptime and other factors. For details about on-demand cost
calculations, see Estimated On-demand Monthly Costs for Cloud VMs (on page 29).

Chart Type
• Line Chart
• Area Chart
Reading a Cost Breakdown Chart

The chart tracks cost over time and displays a tooltip with the date for the data point and the given values.

Cost information comes from billing reports. As you change the time scale, Turbonomic divides the reported information
into the appropriate time units to match that scale. However, the source remains the same - Changing the scale does not
affect the source data, or increase data polling.
Cloud Tier Breakdown Charts

Cloud Tier charts show the cloud tiers that Turbonomic discovers for the chart widget scope. For example, if the Chart
Widget Scope is set to All Cloud VMs and the Entity Type is set to Virtual Machine, the chart shows all the cloud tiers
that the workloads use.
Entity Type
You can choose any entity type in the list.
Chart Type
• Text
• Ring Chart
• Horizontal Bar
Location Charts
Location charts show cloud provider regions in a world map for which there are discovered workloads. Click on any
region to examine more detailed information in a scoped view.

Display
The chart shows the regions in countries in a Map chart.
Cost Breakdown by Tag Charts

Cost Breakdown By Tag charts show the costs for tagged cloud entities that Turbonomic has discovered in your Azure
environment. For the tagged entities in scope, the chart shows how daily costs change over time.
You choose a tag key to track, and then choose which tag values to include in the chart. Each data point aggregates the
costs for all the entities with a given tag/value pair. You can display the cost breakdown in a stacked bar chart or an area
chart.
Example: For this stacked bar chart, the tag poolName is workload-type and the tag Values are ptpool, ptpool2, and
mixwin.

Scope
To display these charts, add them to the default views in the Home Page or to your custom dashboards. By default,
these charts are scoped to your global environment. You can change the scope to view granular data.
Timeframe
Set the amount of historical data the chart will show.
Chart Type
• Area Chart

For more detail, hover over a data point. A tooltip appears to show specific values for that date. Click the legend items to
show/hide data for specific values.
Tag Settings
Choose the Tag/Value pairs you want to display in the chart.
Note that tag Key and Value are case insensitive. Each data point in the chart aggregates the costs for all entities with
the given tag Key/Value pair, regardless of case.
• Key
The tag name that you want to chart. Turbonomic discovers the tags you have configured in your environment.
You can choose one Key for the chart.
• Values
The values that you have configured in your environment for the given Key.
You can choose multiple values. To shorten the list of values, type a filter string in the Values field.
Cumulative Savings and Investments Charts

Actions for your cloud workloads usually have cost savings or investments attached to them. For example, deleting
unattached volumes can lower your costs significantly (savings), while scaling a VM to a different tier to improve
performance could incur additional costs (investments).
These charts highlight:
• Total realized savings and investments as a result of executing actions
• Total missed savings and investments when actions are not executed
Information in these charts can help shape your action handling policies. For example, you can start automating actions
so you don't miss opportunities to assure performance at the lowest possible cost.
Scope
These charts display in the built-in Cloud Executive Dashboard and are scoped to your global environment. You can
change the scope to view granular data. You can also add these charts to the default views in the Home Page or to your
custom dashboards.
Another way to view granular data is to set the scope (in the supply chain or by using Search) to one or several accounts,
billing families, groups, or workloads.
Scale Actions
For actions to scale workloads (VMs, Database Servers, databases, or volumes), Turbonomic calculates savings and
investment per workload based on the hourly cost of the workload price difference, taking into account workload
uptime (on page 42) and the effect of consecutive scale actions on the same workload.
• Calculated investments and savings are the total of all past scaling actions, with the exception that a scale in one
direction reduces the amounts of previous actions in the opposite direction, until one or more previous actions
have no more effect.
To illustrate:

Consider three consecutive scale actions for a VM and their effect on the calculation.
1. A cost increase of $1.00 counts as an investment of $1.00.
2. A subsequent cost decrease of $0.25 is factored in as:
◦ Savings of $0.25 to the total amount in the Cumulative Savings chart
◦ An investment of $0.75 to the total amount in the Cumulative Investments chart
3. Another cost decrease of $1.00 is factored in as:
◦ Savings of $1.25 to the total amount in the Cumulative Savings chart
◦ An investment of $0.00 to the total amount in the Cumulative Investments chart
By the time the third action was executed, the initial $1.00 investment has been "undone" (investment amount is
$0.00) and is no longer considered when calculating savings and investments for the VM.
• Calculation temporarily stops for the hours that a workload is offline, and then resumes when the workload is
online again and is running with the same configuration.
• Calculation stops for terminated workloads or workloads that Turbonomic no longer discovers.
Volume Delete Actions

For actions to delete volumes, Turbonomic calculates savings accumulated over one year since volume deletion, based
on the hourly cost of the deleted volume. It also estimates missed savings based on the hourly cost of the workload
price difference and the number of hours that pending actions remain in the system.
Chart Type
• Text and Area Chart
• Area Chart
• Text and Bar Chart
• Text
You can edit the chart to switch between the Cumulative Savings and Cumulative Investments views. You can also
change the displayed data to just Savings or Investments if you do not wish to see how the savings or investment costs
accumulate over time.
In this example, Turbonomic shows monthly realized and missed savings.


In the chart legend, you can click Realized Savings or Missed Savings to display a filtered view. Click the item again to
reset the chart.
Click Show All at the bottom of the chart to view and download data in tabular format.
Savings and Investments Charts

Actions for your cloud workloads usually have cost savings or investments attached to them. For example, deleting
unattached volumes can lower your costs significantly (savings), while scaling a VM to a different tier to improve
performance could incur additional costs (investments).
These charts highlight:
• Total realized savings and investments as a result of executing actions
• Total missed savings and investments when actions are not executed
Information in these charts can help shape your action handling policies. For example, you can start automating actions
so you don't miss opportunities to assure performance at the lowest possible cost.
Scope
To display these charts, add them to the default views in the Home Page or to your custom dashboards. By default,
these charts are scoped to your global environment. You can change the scope to view granular data.
Another way to view granular data is to set the scope (in the supply chain or by using Search) to one or several accounts,
billing families, groups, or workloads.

Scale Actions
For actions to scale workloads (VMs, Database Servers, databases, or volumes), Turbonomic calculates savings and
investment per workload based on the hourly cost of the workload price difference, taking into account workload
uptime (on page 42).
• Calculation temporarily stops for the hours that a workload is offline, and then resumes when the workload is
online again and is running with the same configuration.
• Calculation stops for terminated workloads or workloads that Turbonomic no longer discovers.
Volume Delete Actions

For actions to delete volumes, Turbonomic calculates savings since volume deletion, based on the hourly cost of the
deleted volume. It also estimates missed savings based on the hourly cost of the workload price difference and the
number of hours that pending actions remain in the system.
Chart Type
• Text and Area Chart
• Area Chart
• Text and Bar Chart
• Text
You can edit the chart to switch between the Savings and Investments views. You can also change the displayed data to
Cumulative Savings or Cumulative Investments to see how the savings or investment costs accumulate over time.
In this example, the chart shows realized and missed savings per month over the last year. It indicates higher rates of
realized savings in the last two months as more actions are executed rather than kept pending.

In the chart legend, you can click Realized Savings or Missed Savings to display a filtered view. Click the item again to
reset the chart.
Click Show All at the bottom of the chart to view and download data in tabular format.

Recommended RI Purchases Charts

Recommended RI Purchases charts show the projected inventory of pending Reserved Instance purchases as generated
by Turbonomic. The charts show the Reserved Instance workloads that Turbonomic discovers, and lists them by the
available templates.
To see the RI information for each template, click Show all at the bottom of the chart. If your scope includes both AWS
and Azure cloud targets, click AWS or Azure. Click any column heading to sort the list. For example, you can sort the list
by the break-even period (The time at which RI savings will exceed the purchase cost of the RI, rounded to the month).
When you choose one or more checkboxes, the total count, up-front cost, and savings appear at the top.
Chart Type
• Text
• Ring Chart
• Horizontal Bar
Examples:
• Horizontal Bar

• Viewing the AWS Show all list

• Viewing the Azure Show all list


RI and Savings Plans Coverage Chart

This chart shows the percentage of VMs covered by Reserved Instances (RI) and AWS Savings Plans. If you have a high
percentage of on-demand VMs, you should be able to reduce your monthly costs by increasing coverage. To increase
coverage, you scale workloads to instance types that have existing capacity.
NOTE:
For cloud environments that only have RI data, the chart's name is RI Coverage. Similarly, for environments with only
Savings Plans data, the chart's name is Savings Plans Coverage.
See the following topics for more information:

• RI Coverage (on page 392)
• Savings Plans Coverage (on page 393)
RI Coverage Chart
This chart shows the percentage of VMs covered by Reserved Instances (RI). If you have a high percentage of on-
demand VMs, you should be able to reduce your monthly costs by increasing RI coverage. To increase coverage, you
scale workloads to instance types that have existing RI capacity. If you need more RI capacity, then Turbonomic will
recommend RI purchase actions.
Scope
If you set the scope to a specific AWS account, this chart shows the RI coverage for the workloads for the account, plus
any RIs for the billing family. For Azure, if you set the scope to a specific Azure subscription, this chart shows the RI
coverage for the workloads for the subscription, plus any shared RIs and single-scope RIs owned by this subscription.
Data Points
The data point on the solid vertical line shows the latest data that was polled from your environment. Data points to the
left of the vertical line represent historical data, while data points to the right are projections into the future.
Hover on a data point in the chart to see the following information:


• The date and time for the data point
• The percentage of RI coverage, based on NFUs or ratios.
◦ NFU (AWS only)
NFU is a measure of RI capacity that you can use to compare or combine the capacity for different instance
families.
Turbonomic measures RI coverage in terms of these normalized factors. The chart shows the number of RIs
calculated as NFUs that cover workload capacity compared to the total number of NFUs for the workloads in
the chart's scope. Each workload is assigned normalized factor units depending on its instance type.
◦ Ratio (Azure only)
Ratio refers to the number of RI units that cover workload capacity compared to the total number of RI units for
the workloads in the chart's scope. Each workload is assigned RI units based on its instance type.
Savings Plans Coverage Chart

This chart shows the percentage of VMs covered by AWS Savings Plans. If you have a high percentage of on-demand
VMs, you should be able to reduce your monthly costs by increasing Savings Plans coverage. To increase coverage, you
scale workloads to instance types that have existing Savings Plans capacity.
Scope
To view data for AWS Savings Plans, you must:
• Set the scope to your global environment.
• Choose a timeframe that shows daily or monthly data points (Last 7 Days, Last 30 Days, or Last Year)
AWS measures your Savings Plans commitment in $/hour, but shows daily and monthly costs in Cost Explorer.
Turbonomic polls Cost Explorer periodically to obtain the latest cost data, and then uses that data to calculate
Savings Plans utilization or coverage per day. For this reason, you will not see Savings Plans data if you choose a
timeframe that shows hourly data points (Last 2 Hours or Last 24 Hours).
NOTE:
AWS timestamps data in UTC, but the chart presents data in your local time. This difference could result in the
appearance of a missing day in the chart, but has no effect on data completeness (the chart always reflects the
complete data set).

Data Points
The chart shows historical data, represented by data points to the left of the solid vertical line. Data for the current
day is not available since the latest data that AWS provides is always a few days old. In addition, Turbonomic does not
project coverage into the future.

• The percentage of Savings Plans coverage
Discount Inventory Chart

This chart shows your discounted pricing commitments with your cloud providers. Turbonomic supports discovery of the
following:
• AWS Reserved Instances (RIs) and Savings Plans for regular and GovCloud (on page 39) workloads
• Azure reservations for regular and Azure Government (on page 39) workloads
NOTE:
It could take Turbonomic up to a day to discover newly purchased Azure reservations.
• GCP committed use discounts
Chart Type

• Text
• Ring Chart
• Horizontal Bar

Show All
Click Show All at the bottom of the chart to see detailed information for the discounts in scope. If your scope includes
multiple cloud providers, each provider will have its own tab.

Each row in the table corresponds to a discount. Note that there can be several discounts for an Azure subscription or
AWS/GCP account, and each discount displays as its own row. Table columns show basic information obtained from the
cloud provider, such as the name/ID of the discount, the subscription/account that uses that discount, instance type and
location, term, and expiration dates. Click a subscription/account to narrow the scope.
The table supports the following general functionality:
• Totals: At the top of the page, you will see the total number of discovered discounts. For AWS RIs and Azure
reservations, you will also see total costs and savings. As you select one or more checkboxes, the information
changes to reflect the totals for your selections.
• Column Sorting: Click any column heading to sort the list.
• Download: Click the Download icon at the upper right section of the page to download the table as a CSV file.
For AWS RIs and Azure reservations:
• When you add an Azure EA account or an AWS master account as your primary cloud target, Turbonomic gains full
insight into the discounts for your billing families. Even as you selectively add Azure subscriptions or AWS member
accounts as secondary targets, Turbonomic remains aware of all discounts and how they are utilized across the
board, and can thus recommend more accurate discount optimization and purchase actions.
NOTE:
If you do not add an AWS master account, Turbonomic always shows a partial inventory, regardless of scope.
• For each RI or reservation:

◦ Turbonomic calculates current utilization, estimated savings and effective cost.
◦ The Linked VMs column shows how many VMs in the subscription or account use the discount. Click the
number to view the VMs.

◦ If you selectively added Azure subscriptions or AWS member accounts as secondary targets, the exact number
of VMs using a particular discount is unknown. In the Linked VMs column, you will see a star symbol (*)
indicating that there are VMs from non-added accounts that use that discount.
RI Inventory Chart
This chart shows the Reserved Instances (RIs) in your cloud environment (including AWS GovCloud and Azure
Government (on page 39)) and lists them by the instance types they use.
NOTE:
It could take Turbonomic up to a day to discover newly purchased Azure RIs.
Chart Type

• Text
• Ring Chart
• Horizontal Bar
Show All
Click Show All at the bottom of the chart to see detailed information for the RIs in scope. If your scope includes both
AWS and Azure accounts, each provider will have its own tab.


Each row in the table corresponds to an RI. Table columns show basic information obtained from the cloud provider,
such as reservation/order ID, instance type name and count, location, term, and expiration date. Turbonomic calculates
estimated utilization and savings, and effective cost.
The table also supports the following general functionality:
• Totals: At the top of the page, you will see the total RI count, cost, and savings. As you select one or more
checkboxes, the information changes to reflect the totals for your selections.
• Column Sorting: Click any column heading to sort the list.
• Download: Click the Download icon at the upper right section of the page to download the table as a CSV file.
The table presents richer details when you set the scope to the global environment. For details, see the next section,
Full RI Inventory.
Full RI Inventory
When you add an Azure EA account or an AWS master account as your primary cloud target, Turbonomic gains full
insight into the RIs for your billing families. Even as you selectively add Azure subscriptions or AWS member accounts
as secondary targets, Turbonomic remains aware of all RIs and how they are utilized across the board, and can thus
recommend more accurate RI actions for the cloud environment that it discovered.
Set the scope to your global environment to view your full RI inventory.
NOTE:
If you do not add an AWS master account, Turbonomic always shows a partial RI inventory, regardless of scope.
When you click Show All at the bottom of the chart, pay attention to the following information shown in the table:
• For RIs in added accounts (Azure subscriptions or AWS member accounts):

◦ Subscription column (for Azure) or Account column (for AWS)
This column shows the account name for the RI. Click the name to set the scope to that account. Note that
there can be several RIs for an account, and each RI displays as its own row.
NOTE:
If there is a failure to re-validate the account for some reason, Turbonomic shows it as a non-added account
in the RI Inventory page.
◦ Linked VMs column
This column shows how many VMs in the account use the RI. Click the number to view the VMs.
A star symbol (*) after the number indicates that there are VMs from non-added accounts that also use the RI.
Since you have not added those accounts, the exact number of VMs is unknown.
◦ Estimated utilization column

This column shows the percentage of RI capacity currently used by VMs in all accounts. Turbonomic estimates
the percentage if there are VMs in non-added accounts that use the RI (since the exact number of VMs is
unknown).
• For RIs in non-added accounts:

◦ Account column (for AWS) or Subscription column (for Azure)
This column shows a grayed-out, non-clickable name to indicate that you have not added the account as a
target. Turbonomic is aware of this account and if the given RI is shared with other accounts because you have
added a master or EA account.
◦ Linked VMs
If the number under this column is 1 or more, the number indicates VMs from added accounts that use the RI.
Click the number to view the VMs.
If the number is 0 (zero), and is not followed by a star symbol (*), then the RI is currently not used anywhere.
A star symbol (*) after the number indicates that there are VMs from other non-added accounts that also use
the RI. Since you have not added those accounts, the exact number of VMs is unknown.
◦ Estimated utilization column
This column shows the percentage of RI capacity currently used by VMs in all accounts. Turbonomic estimates
the percentage if there are VMs in non-added accounts that use the RI (since the exact number of VMs is
unknown).
NOTE:
In Azure environments, there can be delays in billing information updates that Azure makes available to
Turbonomic. If this happens, analysis might use partial billing data in its calculations and show incomplete costs
for RIs from non-added Azure subscriptions.
Partial RI Inventory
Turbonomic shows a partial RI inventory if:
• You added some of your AWS member accounts as targets, but not an AWS master account.
In this case, Turbonomic will not reflect RIs for member accounts that you have not added as targets.
• You change the scope (in the RI Inventory chart) from your global environment to individual AWS member accounts
or Azure subscriptions.
In this case, Turbonomic will only reflect RIs for the selected account or subscription.
Savings Plans Inventory Chart

If you added targets that are AWS accounts with read-only access to the AWS Savings Plans API, Turbonomic uses this
chart to present the Savings Plans that it discovered in your cloud environment (including GovCloud (on page 39)) and
the instance types they use.

Chart Type
• Text
• Ring Chart
• Horizontal Bar
Show All
Click Show All at the bottom of the chart to see detailed information for the Savings Plans in scope.
Each row in the table corresponds to a Savings Plan. Table columns show basic information obtained from AWS, such as
Savings Plan ID/type, instance family, location, term, and inclusive dates.

RI and Savings Plans Utilization Chart

This chart shows how well you have utilized your current RI and AWS Savings Plans inventory (on page 394). The
desired goal is to maximize the utilization of your inventory and thus take full advantage of the discounted pricing
offered through RIs and Savings Plans.
NOTE:
For cloud environments that only have RI data, the chart's name is RI Utilization. Similarly, for environments with only
Savings Plans data, the chart's name is Savings Plans Utilization.
See the following topics for more information:

• RI Utilization (on page 399)
• Savings Plans Utilization (on page 400)
RI Utilization Chart
Use this chart to see how well you have utilized your current Reserved Instance inventory. The desired goal is to
maximize the utilization of your inventory and thus take full advantage of the discounted pricing offered through
Reserved Instances.
Scope
You can set the scope to your global cloud environment or to individual accounts/subscriptions, billing families, or
regions. Scoping to an account/subscription shows the RI utilization for the workloads for the entire billing family or for
single and shared subscriptions.
Data Points
The data point on the solid vertical line shows the latest data that was polled from your environment. Data points to the
left of the vertical line represent historical data, while data points to the right are projections into the future.


• The percentage of RI utilization, based on NFUs or ratios.
◦ NFU (AWS only)
NFU is a measure of RI capacity that you can use to compare or combine the capacity for different instance
families.
Turbonomic measures RI utilization in terms of these normalized factors. The chart shows the number of RIs
calculated as NFUs that are consumed by cloud workloads compared to the total number of RIs in the chart's
scope.
◦ Ratio (Azure only)
Ratio refers to the number of RI units in use compared to the total number of RI units in the chart's scope. Each
workload is assigned RIs based on its instance type.
Savings Plans Utilization Chart

Use this chart to see how well you have utilized your current Savings Plans inventory. The desired goal is to maximize the
utilization of your inventory and thus take full advantage of the discounted pricing offered through Savings Plans.
Scope
To view data for AWS Savings Plans, you must:
• Set the scope to your global environment.
• Choose a timeframe that shows daily or monthly data points (Last 7 Days, Last 30 Days, or Last Year)
AWS measures your Savings Plans commitment in $/hour, but shows daily and monthly costs in Cost Explorer.
Turbonomic polls Cost Explorer periodically to obtain the latest cost data, and then uses that data to calculate
Savings Plans utilization or coverage per day. For this reason, you will not see Savings Plans data if you choose a
timeframe that shows hourly data points (Last 2 Hours or Last 24 Hours).
NOTE:
AWS timestamps data in UTC, but the chart presents data in your local time. This difference could result in the
appearance of a missing day in the chart, but has no effect on data completeness (the chart always reflects the
complete data set).
Data Points
The chart shows historical data, represented by data points to the left of the solid vertical line. Data for the current
day is not available since the latest data that AWS provides is always a few days old. In addition, Turbonomic does not
project utilization into the future.


• The percentage of Savings Plans utilization, based on the total utilized and committed costs per day
Cloud Estimated Cost Charts

Cloud Estimated Cost charts show estimated monthly costs and investments for the cloud. Monthly cost amounts are
summarized as amounts with and without actions.
Display
The chart shows the information as a Text chart.
Storage Summary Charts

To help you manage your costs on the public cloud, these charts show the distribution of storage for the given scope,
cost, potential savings, and information about unattached storage. In this way, you can see how storage utilization
affects your costs. For these charts, Turbonomic calculates the costs based on the cost information from the cloud
targets.
For a detailed breakdown, click Show all at the bottom of the chart. If your scope includes both AWS and Azure cloud
targets, click AWS or Azure to see the details. Click any column heading to sort the list. When you choose one or more
checkboxes, the total appears at the top.
NOTE:
For Azure environments with VMs in Scale Sets, for any VMs that are powered off, the associated storage shows a
utilization of zero GB. This is an accurate presentation of the data that the Azure environment returns for such a
powered-off VM. However, it is likely that some of the storage capacity is currently utilized.
Chart Unit
Choose one of the following:
• Count to see how many storage tiers or volumes exist by storage type.
• Cost to see the monthly cost by storage type.

Chart Displays
Examples:
• Costs
The chart shows the monthly costs for all storage tiers or volumes. You can also choose Count to list how many
storage tiers or volumes exist by storage type. This display is available for real-time views and dashboards.
• Unattached Storage
The chart shows how many unattached storage tiers or volumes exist. You can also choose Cost to list the monthly
costs of the unattached storage. This chart is available for real-time views and dashboards.
Monthly Savings or Investments Totals Charts

Monthly Savings or Investments Totals charts help you examine the monthly savings or investments for executed cloud
actions. For example, if an executed action causes an increase in the price, this is an investment. These charts also show
the missed monthly savings or missed performance investments that you could have achieved for recommended cloud
actions, if you executed them.
For this chart's scope, you can choose an account or subscription, a group of accounts or subscriptions, or use the
default, Global Environment. If you use the default Global Environment, the chart will automatically use all cloud
accounts for its scope. Other examples of scope settings are: An AWS billing family, an Azure subscription, the All AWS
Accounts predefined group, or the All Azure Accounts predefined group.
For all actions except Suspend, savings and investments are estimated based on the hourly cost of workload price
differences and 730 hours per month of workload usage. Savings from Suspend actions are estimated based on the
hourly cost of workload price differences and actual suspend times as defined in the suspension policy.
Missed savings and investments are estimated based on the hourly cost of workload price differences and the number
of hours that recommended actions exist in the system.
Monthly Savings or Investments Totals charts calculate data on a monthly basis since your update of Turbonomic to
version 6.4.2. Historical data stored in the database prior to version 6.4.2 is not included.
Chart Type
• Tabular
Examples:
• Stacked Bar
This chart shows the monthly totals of savings or investments for each of the last seven days. It also shows the
missed monthly savings or performance investments that you could achieve by executing recommended cloud
actions.


In the chart legend, you can also choose an item to change the display of the chart. Click the item again to reset the
chart. For example, if you want to examine investment information, click Investments in the legend.
• Tabular
This chart shows the monthly totals of savings or investments for each of the last seven days. It also shows the
missed monthly savings or performance investments that you could achieve by executing recommended cloud
actions.

On-Prem Chart Types

These chart widgets provide information on the status of your on-prem environment.
Density Charts
Density charts show the number of resource consumers (virtual machines or containers) per provider (host or storage).
If available, choose the Show Density checkbox to see the ratio of consumers to providers.
These charts also show the desired count of virtual machines, assuming you want to fill the headroom completely. Note
that the Desired Workloads values are the results of running plans. These plans can calculate workload moves within a
cluster to gain more efficiency, but they always respect the cluster boundaries – the plans never move VMs to hosts on
different clusters.

Chart Type
• Line Chart
Ports Charts
Ports charts show the most utilized northbound or southbound ports in your on-prem environment over a given time
period. These charts are useful in Fabric environments where you license port channels.
Display
Headroom Charts
Headroom charts show how much extra capacity your clusters have to host workloads.
You can specify the following types of Headroom charts:
• CPU Headroom
• Memory Headroom
• Storage Headroom
Commodity
You can choose:
• CPU Headroom
• Memory Headroom
• Storage Headroom
Display
The chart shows the information as an Area chart.
Example:


Exhaustion Time Chart

This chart shows the current growth of workloads and projects when workloads will exceed the capacity of your current
infrastructure. This is useful for future planning (for example, if you might need to buy more hardware).
You can track CPU, memory, and storage as well as the average monthly Virtual Machine growth and the average VM
template. The amount of time is presented as days. For example, storage will be used up in 41 days.
Display
The chart shows the information as a Text chart.

Embedded Reporting
The Turbonomic platform includes an Embedded Reporting component that you can choose to enable when you install
the platform. Use Embedded Reporting to understand application resource management trends, and to share insights
with stakeholders via reports and dashboards.
Embedded Reporting runs as its own component, as part of the Turbonomic platform. This architecture enhances
performance and reduces storage requirements. It stores a history of your managed environment and then presents
selective snapshots of this history via a set of standard dashboards and reports. You can create your own dashboards
and reports to focus on other areas of concern.
Dashboards and charts are powered by the Grafana® observability platform. With Grafana, it's easy to navigate the
existing dashboards, and to make your own charts and dashboards with no coding required. If you are new to Grafana
and need help getting started, read the documentation available at:
https://grafana.com/docs/grafana/latest/
Enabling Embedded Reporting

To view and create reports, you must enable Embedded Reporting as part of the Turbonomic installation process. For
details, see the Installation Guide.
If you have enabled Embedded Reporting in a Turbonomic instance that is older than version 8.1.1 (7.22.x to 8.1.0), and
then updated that instance to version 8.1.1 or later, be aware of the following:
• Version 8.1.1 or later includes a new Embedded Reporting schema that provides additional reporting capabilities.
• Reports will begin their historical data from the time that you completed the update.
• The Embedded Reports page includes a folder named Old Reports, which is marked with the date of the update.
This folder contains all of your reports before the update, using historical data from before the change to the new
schema.
• The On-Prem Virtual Machine Rightsizing Recommendations report appears in the Old Reports folder, but it is
empty. The table used by this report has been rewritten as part of the new schema, and historical data for the
report is not saved after you update.
• If you want to merge the old reports with your new reports, please contact your support representative for
assistance.

Embedded Reporting
Required Roles
Turbonomic implements role-based access control for Embedded Reporting.
• To manage reports, a user must have the Report Editor role and must not be a scoped user. Only one user per
Turbonomic instance is allowed to have this role (by default, the local administrator user). You can grant Report
Editor privileges to another user, from the User Management page.
NOTE:
It can take up to 30 minutes before the Reports page shows the Report Editor username. This usually occurs if you
have changed the Report Editor multiple times.
• To access reports, a user must have the Administrator or Site Administrator role, or a non-administrator role
without a defined scope. For example, a user with the Observer role but without a scope can access reports.
The default Shared Observer and Shared Adviser roles require scopes, so users with these roles cannot access
reports.
Embedded Reporting Main Page

When you have enabled Embedded Reporting, the Turbonomic Navigation Bar displays the REPORTS icon.

Click this icon to open the Embedded Reports page in a new browser tab. This tab displays the Search dashboards by
name view.

You can search for specific dashboards or browse folders to find the dashboards you want. You can also create custom
reports.
NOTE:
If you have requested and installed the required Grafana license (free of charge), then users of your Turbonomic
installation can view PDF versions of these dashboards.
If a chart in a dashboard includes multiple pages, the PDF file will not contain all the pages of data for that table. This
behavior is implemented in Grafana. To generate output for a multi-page table, download the table data as CSV.

Embedded Reporting
Custom Reports
To create custom reports, you must run SQL queries against the Embedded Reports database (Turbo Timescale).

The database schema includes certain tables against which you can run queries. For detailed documentation for the
schema, visit:
https://turbonomic.github.io/reporting-docs/

Creating Groups
Groups assemble collections of resources for Turbonomic to monitor and manage. When setting scope for your
Turbonomic session, you can select groups to focus on those specific resources. For example, if you have a number of
VMs devoted to a single customer, you can create a group of just those VMs. When running a planning scenario you can
set the scope to work with just that group.
Turbonomic discovers groups that exist in your environment. These groups include PM clusters, and entities grouped by
different logical boundaries. For example, Turbonomic discovers Storage by Disk Array, Physical Machines by Datacenter,
and VMs by Network. In addition, Turbonomic discovers pools such as virtual datacenters, or folders that implement
specific HA policies.
You can also create custom groups. Turbonomic supports two custom-grouping methods:
• Dynamic — You define these groups by specific criteria. You can group services according to naming conventions (all
VM names that start with ny), resource characteristics (all physical machines with four CPUs), or other criteria such
as time zone or number of CPUs.
These groups are dynamic because Turbonomic updates the group as conditions change.
• Static — You create these groups by selecting the specific group members.
NOTE:
You should never use the Turbonomic user interface to delete discovered groups. If you do, later analysis cycles will
discover them again, and add them to your environment. But until it recreates those groups, any analysis that relies
on those groups can give unexpected results.
You can delete any custom group you have created. Before you do, you should verify that you do not have any charts,
plans, or policies that use the group you want to delete to set their scopes. After you delete the group, such charts,
plans, or policies will loose their scope. For example, a policy with no scope has no effect.
To create a group:

2. Choose Groups.

Creating Groups

Click to navigate to the Group Management Page.

This page lists all the custom groups that you currently have configured for Turbonomic. You can:
• Expand an entry to see group details
• Select an entry to delete the group
• Click a group name to edit it
For a dynamic group, you can edit the set of criteria that select the group members. For a static group, you can
add or subtract specific members.
• Create new groups
To work with a long list of groups, you can filter by group type. For example, only show groups of VMs, or groups of
host machines. You can also type a string in the Search field to filter the list.
3. Expand an entry to see group details.

The details show you information about related entities such as how many hosts provide resources for a group of
VMs. If there are any pending actions for the group, the details list those actions as well.

Creating Groups
4. Create a new group.

Click NEW GROUP.

Next, choose a group type.
Then, specify the group settings:
• Give the group a unique name. To prevent issues, you should never use duplicate names for groups of the
same entity type.
• Set whether the group will be static or dynamic.
To create a static group, select the member entities from the list. To filter the list, set group criteria.
To create a dynamic group, set group criteria. The list updates to show the resulting group members.
• Specify group criteria.
These criteria are entity attributes that determine group membership. You might create a group of all VMs that
have 4 VCPUs. You can choose properties of the member entities, and you can choose properties of entities
that are related to the members. For example, you can make a group of VMs that are hosted by PMs with the
substring "Development" in their names.
As you set criteria, the list of entities updates to show the member entities. You also can sort the list by
severity (per the most critical entity in group) or group name.
Note that you can use regular expression to express your match strings.
• When you are finished, save the group.
Save adds this group to the My Groups collection.

Working With Schedules
Turbonomic schedules specify a specific time range during which certain events can occur. Turbonomic currently uses
schedules in scoped policies to set up windows of time when the policy can execute certain actions, or when the policy
changes settings that affect analysis and action generation.
NOTE:


The Schedules page lists all the currently defined schedules. From this page you can:
• Select an entry to delete the schedule.
• Select an entry to defer the next occurrence.
Turbonomic calculates when the next scheduled window will open. If you want cancel the scheduled occurrence
one time, you can select the schedule and defer the upcoming occurrence. This defers the schedule wherever it
is applied. If the schedule is applied to more than one policy, this will defer all the policies that use this schedule.
Before you defer a schedule, you should expand the details and review all the policies that use this schedule.
• Expand an entry to see schedule details
The details include a summary of the schedule definition, as well as:
◦ Used in Policies
The number of policies that use this schedule. Click the number to review the policies.
◦ Next Occurrence
When the schedule will next come into effect.
◦ Accepted Actions
How many scheduled actions have been accepted to be executed in the next schedule occurrence. Click the
number for a list of these actions.
◦ Awaiting Acceptance
The number of Manual actions affected by this schedule that are in the Pending Actions list, and have not been
accepted. Click the number for a list of these actions.
• Create new schedules

See Creating Schedules (on page 414).
Deleting Schedules
Before you delete a schedule, you should view its details to make sure no policies use it. If you delete a schedule that is
in use by any policies, Turbonomic disables the affected policies until you edit them to either:
• Apply a different schedule to the policy and save the change, or...
• Save the policy with no schedule
Saving with no schedule confirms that you intend for this policy to apply at all times. Because scheduled policies
are for special cases, this is usually not what you intend. For example, a scheduled maintenance window can have
aggressive action modes that you do not want to enable during peak hours. If you save the policy with no schedule,
then the aggressive settings will take effect at all times.
Turbonomic posts a confirmation dialog before deleting a schedule that is currently in use.
Creating Schedules
To create a new schedule:

2. Choose Schedules.

Click to navigate to the Schedule Management Page.
This page lists all the schedules that you currently have configured for Turbonomic. You can edit the schedules in
the list, or you can create new schedules.

3. Create a new schedule.

Click New Schedule to open the new schedule fly-out. Then name the schedule.
4. Set the recurrence for the schedule.
Choose whether the scheduled period occurs just once, or whether it repeats over time. The settings vary
according to the recurrence you choose:
• Does Not Recur
This is a one-time schedule window. A non-recurring window has a start date, and no end date. The window
starts on the day and time you specify, and remains open for the given duration.
• Daily

Repeat this schedule every given number of days. For example, repeating 30 days is similar to repeating
monthly, except it repeats by the count of days, not by the calendar month.
The schedule begins on the Start Date, and continues repeating until the End Date. If End Date is "None", the
schedule repeats perpetually.

• Weekly

Repeat this schedule every given number of weeks, on the week days you specify. For example, to repeat
every weekend, set it to repeat every one week on Saturday and Sunday.
• Monthly

Repeat this schedule every given number of months, to begin on a given day in the month. For example, you
can schedule a maintenance window to begin on the first Saturday of each month.
5. Set the Start Time and Duration.
These settings specify how long the scheduled window remains open. You set the duration in terms of hours and
minutes. Using a duration instead of an end time removes ambiguities such as starting before midnight and ending
after. However, you should make sure the duration is not longer than the recurrence.
6. Set the time zone.
This gives a reference for the schedule's start time. The Turbonomic server uses that reference when it opens and
closes the schedule window. Users see the same time zone setting no matter where they are located – They should
convert the schedule time to their local time if they want to track when the schedule opens in their working day.
7. When the settings are complete, save the schedule.

Templates: Resource Allocations for New
Entities

Turbonomic uses templates to describe new entities that it will deploy in your environment or in plans. The templates
specify resource allocations for these entities. For example, you can run a plan that adds new VMs to a cluster. If you
add ten copies of a template, then the plan places ten new VMs that match the resource allocation you have specified
for the given template. For your cloud environment, you can see templates to match the instance types in your cloud
accounts and subscriptions.
A VM template definition can include one or more images that Turbonomic uses to deploy the VM in your environment.
The image identifies the actual deployment package, including a path to the physical files (for example an OVA).

Templates: Resource Allocations for New Entities
The Template Catalog shows all of the templates that have been specified or discovered for your installation of
Turbonomic. From this page, you an also create new templates and edit existing ones.
Creating Templates
Templates specify the resources for entities that Turbonomic can deploy in your environment, or in plans.
A VM template definition can include one or more images that Turbonomic uses to deploy the VM in your environment.
The image identifies the actual deployment package, including a path to the physical files (for example an OVA).
The Template Catalog shows all of the templates that have been specified or discovered for your installation of
Turbonomic. From this page, you an also create new templates and edit existing ones.
Creating and Editing Templates

To create a new template, navigate to the Template Catalog and click NEW TEMPLATE. To edit a template, click the
template's name. When you create a new template, the first step is to choose the entity type.

2. Choose Templates.

3. Create or edit a template
To create a new template, navigate to the Template Catalog and click NEW TEMPLATE. To edit a template, click the
template's name.
4. If you're creating a new template, choose the entity type.

5. Make the settings for your template.

For each type of template, you set allocations for different resources. You can make templates of the following
types:
• Virtual Machine
• Host
• Storage
• Container
6. Make the settings for your template, and then save your changes.
When the template window opens, it displays the most common resource settings. You can expand the settings to
see the full collection for that template type.
7. Save your changes.
After you have made your settings and named the template, click CREATE or SAVE.
VM Template Settings
A VM template describes the resource allocation that you want to provide for a type of VMs. When Turbonomic deploys
the associated VM to your environment or in a plan, it uses these values to determine the size of the VM. Turbonomic
uses the Size settings to calculate the best placement for a VM of this type.
A VM template can optionally include an image description. When Turbonomic uses the template to deploy a VM to
your environment, it uses the image to access the actual bits that install as the VM instance.
NOTE:
Turbonomic generates a special template called headroomVM, which it uses to calculate cluster headroom. The
Template Catalog shows the template as editable, but you should not edit it because Turbonomic will overwrite your
changes the next time it generates the template.
VM Size
• CPU
The virtual CPUs assigned to the VM. Specify the number of Cores and the VCPU clock speed – Turbonomic
multiplies these values to calculate the host CPU resources it will allocate when placing the VM.
The Utilization value sets the percentage of allocated CPU that the placed VM will consume. To ensure the host has
left over resources for infrastructure tasks, you should assign less than 100%.
• Memory
The amount of memory to allocate for the VM, in MB.
The Utilization value sets the percentage of allocated memory that the placed VM will consume. To ensure the host
has left over resources for infrastructure tasks, you should assign less than 100%.
Note that you should never allocate less memory than is required for the VM's guest OS.

• Storage
The storage resources to allocate for this VM.
◦ disk/rdm – If you choose rdm, then the VM can use VMware Raw Device Mapping for its storage.
◦ IOPS – The capacity for IO operations you give the VM for this datastore.
◦ Size – The amount of storage capacity, in GB.
The Utilization value sets the percentage of allocated memory that the placed VM will consume. To ensure the
storage has left over resources for infrastructure tasks, you should assign less than 100%.
Note that you can allocate multiple datastores to the VM.
• Network
The amount of the host’s network throughput to assign to the VM, in Mb/s.
• IO
The amount of throughput on the host’s IO bus to assign to the VM, in Mb/s
Host Template Settings

Host templates describe models of physical hosts that you can deploy in the on-prem datacenter. As part of capacity
planning, you might want to see how to replace your current hosts with different models. To do that, you create
templates to represent the hosts you want, and then use those templates when running hardware replacement plans.
The host template is a collection of these settings:
• CPU
The processor for this host model. Note that CPU size and speed are not the only factors to determine processing
power. To address this, you can specify the host CPU in the following ways:
◦ Select from Catalog

When you enable Select from Catalog, you can open up a catalog of CPU models that Turbonomic uses to map
the model to an effective capacity for the CPU.
◦ Cores and CPU Speed

When you disable Select from Catalog, you can specify the number of Cores and the CPU clock speed –
Turbonomic multiplies these values to calculate the host CPU resources.
• Memory
• Network
The host’s network throughput, in MB/s.
• IO

The host’s IO bus throughput, in MB/s

• Price
If you know the price of the host model that you're specifying for the template, you can enter it here. When running
a plan, Turbonomic can use the price to calculate costs or savings when adding or removing host machines in an on-
prem datacenter.
Selecting CPUs from the Catalog

speed, but still have a higher effective capacity. This can affect planning in two ways:
• When planning hardware replacement, the plan knows the template's effective capacity. This means the plan knows
how to best place workloads on the new hardware.
• For already deployed hosts, Turbonomic discovers the effective capacity and uses that information when calculating
workload placement.
To build the catalog of CPU capacity, Turbonomic uses benchmark data from spec.org. When you set up the CPU for a
host template, you can search this catalog for the processor you want, and set it to the template.
NOTE:
Turbonomic also uses the effective processor capacity when calculating workload placement in real-time. For more
information, see Effective CPU Capacity (on page 77).


HCI Host Template Settings

HCI host templates describe models of physical hosts that support participation in a vSAN. Along with the host compute
specifications, you also include specifications for storage capacity and redundancy (RAID level and failover). You can use
these templates to plan for changes to your vSAN capacity.
NOTE:
For Hyper-V environments, if you run a Hardware Replace plan that replaces hosts with HCI Host templates, the
results can be inconsistent or the plan can fail to place all the VMs in the plan scope. This typically occurs when
Turbonomic detects a configuration issue with VMM or Hyper-V. As a result,Turbonomic treats the VMs as not
controllable and will not attempt to place them.
The HCI Host template is a collection of these settings:

• CPU

The processor for this host model. Note that CPU size and speed are not the only factors to determine processing
power. To address this, you can specify the host CPU in the following ways:
◦ Select from Catalog

When you enable Select from Catalog, you can open up a catalog of CPU models that Turbonomic uses to map
the model to an effective capacity for the CPU.
◦ Cores and CPU Speed

When you disable Select from Catalog, you can specify the number of Cores and the CPU clock speed –
Turbonomic multiplies these values to calculate the host CPU resources.
• Memory
• Network
The host’s network throughput, in MB/s.
• IO
The host’s IO bus throughput, in MB/s
• Storage
The capacity for this storage.
◦ IOPS – The effective IOPS capacity.
◦ Size – Raw storage capacity, in GB. A plan that uses this template will compute the effective storage capacity.
• Redundancy
The redundancy method for this storage on the virtualized SAN. This combines the RAID level and the number of
host failures to tolerate.
• Price
If you know the price of the host model that you're specifying for the template, you can enter it here. When running
a plan, Turbonomic can use the price to calculate costs or savings when adding or removing host machines in an on-
prem datacenter.
Selecting CPUs from the Catalog

speed, but still have a higher effective capacity. This can affect planning in two ways:
• When planning hardware replacement, the plan knows the template's effective capacity. This means the plan knows
how to best place workloads on the new hardware.
• For already deployed hosts, Turbonomic discovers the effective capacity and uses that information when calculating
workload placement.
To build the catalog of CPU capacity, Turbonomic uses benchmark data from spec.org. When you set up the CPU for a
host template, you can search this catalog for the processor you want, and set it to the template.

NOTE:
Turbonomic also uses the effective processor capacity when calculating workload placement in real-time. For more
information, see Effective CPU Capacity (on page 77).

Storage Template Settings

Storage templates describe models of storage that you can deploy in the on-prem datacenter. As part of capacity
planning, you might want to see how to replace your current storage with different models. To do that, you create
templates to represent the storage you want, and then use those templates when running hardware replacement plans.
The storage template is a collection of these settings:
• Storage
The capacity for this storage.
◦ IOPS – The capacity for IO operations on this storage.
◦ Size – The amount of storage capacity, in GB.
• Price

If you know the price of the storage model that you're specifying for the template, you can enter it here. When
running a plan, Turbonomic can use the price to calculate costs or savings when adding or removing storage in an
on-prem datacenter.

Billing and Costs
As you work with Turbonomic, you can set up costs that Turbonomic uses in its calculations. This setup includes:
• Reserved Instance Settings
To recommend placing workloads on Reserved Instances (RIs), Turbonomic uses the real pricing plans that are
available to the targets public cloud accounts. Setting up an RI Purchase Profile adds even more detail to the pricing
structure that Turbonomic uses in its calculations.
• OS Migration Profiles
For Migrate to Cloud plans, Turbonomic calculates the best placement for workloads that you want to move onto
the public cloud. The migration includes choosing the OS for each migrated VM. The OS Profile that you configure
here configures the default for how to manage the OS choices in migration plans.
• Price Adjustment
Cloud service providers can offer their own price lists, including special costs for services or discounts for workloads.
However, Turbonomic does not discover these adjustments. For example, to reflect any discounted prices in the
Turbonomic display and in Turbonomic analysis, you must manually configure those discounts. In Turbonomic, you
configure such discounts via Price Adjustments for specific billing groups in your cloud environment.

Billing and Costs
RI Purchase Profile

To recommend placing workloads on Reserved Instances (RIs), Turbonomic uses the real pricing plans that are available
to the targets public cloud accounts. Setting up an RI Purchase Profile adds even more detail to the pricing structure that
Turbonomic uses in its calculations.
The RI Purchase Profile determines the costs that Turbonomic will use for all RI decisions in your environment. As it
sees opportunities to move workloads to an RI term, Turbonomic determines the costs based on the purchase profile,
and includes the cost information in action descriptions. Turbonomic also uses this information to calculate projected
changes in cost, and to calculate costs for plan results.
Note that the settings you make here globally affect all of your public cloud environment.
To set up the RI Purchase Profile, navigate to Settings > Billing and Costs, and display the RESERVED INSTANCE
SETTINGS tab. Then make the settings for your purchase profile:
• OFFERING CLASS
environment.
• TERM
• PAYMENT
hourly rate.
When you are satisfied with your RI Purchase Profile settings, click APPLY SETTINGS. Or to reset the form, click RESET
DEFAULTS.

Billing and Costs
OS Migration Profile
For Migrate to Cloud plans, Turbonomic calculates the best placement for workloads that you want to move onto the
public cloud. The migration includes choosing the OS for each migrated VM. The OS Profile that you configure here
configures the default for how to manage the OS choices in migration plans.
To set up the OS Profile that plans will use by default, navigate to Settings > Billing and Costs, and display the OS
MIGRATION PROFILE tab. Then make the settings for your OS profile:

The OS Migration Profile determines how Turbonomic will map the OS of each workload as it places that workload on
the cloud destination. This includes how to choose VM templates that provide the OS you want, and whether to include
the license cost in the Migrate to Cloud plan results. To configure an OS Migration Profile, choose from:
• Include OS cost
As Turbonomic calculates placement for the migrated workloads, it will include costs for instances that provide the
same OS that the VM already has.
• BYOL (Bring your own license)
This is the same as the Include OS cost option, except the plan does not include OS licensing costs in any of the cost
calculations for on-cloud placement.

Billing and Costs
• Custom OS
For each of the listed OS types, map the migrated VM to the OS you choose. The OS types are:
◦ Linux – Any open source distribution of Linux. For the migration, Turbonomic will choose instances that provide
the Linux platform that the cloud service provider delivers as a free platform. Note that this is always BYOL,
because it assumes a free OS license.
◦ RHEL (Red Hat Enterprise Linux)
◦ SLES (SUSE Linux Enterprise Server)
◦ Windows
If you enable BYOL for RHEL, SLES, or Windows, Turbonomic assumes that you are paying for the OS license, and will
not include the license cost in the plan results. If you do not enable BYOL, Turbonomic gets the license cost from the
service provider and includes that cost in the plan results.
When you are satisfied with your changes, click APPLY SETTINGS. Or to reset the form, click RESET DEFAULTS.
Price Adjustments
Cloud service providers can offer their own price lists, including special costs for services or discounts for workloads.
However, Turbonomic does not discover these adjustments. For example, to reflect any discounted prices in the
Turbonomic display and in Turbonomic analysis, you must manually configure those discounts. In Turbonomic, you
configure such discounts via Price Adjustments for specific billing groups in your cloud environment.
Turbonomic applies these price adjustments to:
• Costs for workload template families, including:
◦ Compute
◦ RI Compute
• Costs for services, including:
◦ Azure Active Directory
◦ Azure Stack
◦ Bandwidth
◦ VM Licenses
◦ AWS CloudWatch
◦ AWS DynamoDB
◦ And others
Note that in AWS environments, Turbonomic does not apply any discounts or other price adjustments to Spot Compute
costs.
The general steps to configure a price adjustment are:
• Create the price adjustment:
◦ Specify the adjustment scope
To do this, you choose which cloud service provider is giving you the adjustment, and then choose a billing
group to set the scope of the adjustment.

Billing and Costs
◦ Choose the Type

The price adjustment can be a Discount or an Increase. In most cases you will specify discounts for the price
adjustment. While this sets the type for the overall adjustment, you can override the type for specific line
items.
◦ Specify a Price Adjustment setting
The Price Adjustment is the overall adjustment that your cloud service provider offers for the billing groups
in your current scope. For example, AWS might offer you a 10% discount for a given account. For that billing
group, you would specify a 10% Discount for the Price Adjustment setting.
• Specify Price Overrides
While your service provider might offer a general price adjustment for the billing group you chose, it might also
offer further discounts for select services or template families. Or it might offer discounts for some template
families, but price increases for some other services. You can configure these differences as Price Overrides.
NOTE:
Turbonomic uses the adjustments that you configure to display costs in the user interface. However, the values for
hourly cost per entity, total hourly cost, total monthly cost, or total yearly cost can show inaccuracies on the order of a
fraction of a percent. This is due to rounding when calculating the adjusted cost per entity.
Creating a Price Adjustment

A price adjustment configures adjusted workload pricing that you have negotiated with your Cloud Provider. After you
configure an adjustment, Turbonomic applies it to pricing in the affected cloud scope.
To create a price adjustment in Turbonomic, you identify the adjustment's scope – the subscriptions or billing families
the adjustment applies to – and then set the type and percentage for the price adjustment. This specifies an overall
adjustment for the workloads that fall within the billing group. You can later drill into the adjustment to specify
overrides for specific template families or services.
Notes:
• To use a price adjustment with a given billing group, you must increase the memory allocated to the VM that hosts
your Turbonomic instance. The Turbonomic Installation Guide recommends that you provide a minimum of 16 GB
when you install the product. To use price adjustments, Turbonomic recommends that you increase the allocated
memory as follows:
◦ For the first price adjustment assigned to one or more billing groups, increase by 4 GB.
◦ For each subsequent price adjustment assigned to one or more billing groups, increase by an additional 1 GB.
• Whenever you add, edit, or remove a Price Adjustment that is in use, you must allow sufficient time for Turbonomic
to fully discover all of the affected environment, and to propagate the changes throughout that environment. In an
average environment, this can take up to 30 minutes. As an alternative, you can manually execute rediscovery for
the affected cloud subscription or account.
To create a price adjustment:



Billing and Costs
Click to navigate to the Settings Page. From there, you can perform a variety of configuration tasks.
2. Choose Billing and Costs.

Click to navigate to the Billing and Costs page.
3. Display the PRICE ADJUSTMENT tab.
Click the PRICE ADJUSTMENT tab to see all of the adjustments that have been configured for your environment. In
this list you can:
• Click an entry to see details and edit the adjustment
• Select an entry to delete the adjustment
• Create new price adjustments
4. Create the price adjustment.

First click NEW PRICE ADJUSTMENT, then specify the following settings to configure a price adjustment:
• Give the adjustment a name.
• To set the scope for this adjustment, choose its Billing Groups.
Click in the BILLING GROUPS field to display the Billing Groups fly-out.
In the Billing Groups fly-out, choose the cloud service provider you want to work with and then choose the
billing group for the scope of this adjustment.

Billing and Costs

A Billing Group is a set of cloud service provider accounts that are consolidated into a single billing schedule.
Billing group details depend on your service provider:
◦ Azure: For Azure environments, Turbonomic lists each Azure subscription as a billing group.
◦ AWS: To consolidate billing, AWS supports billing families of AWS accounts, where there is a master
account and other member accounts. Turbonomic lists each billing family as a billing group. You can
choose a billing family to set the scope of this adjustment.
After you have chosen your billing group, click SAVE to return to the Add New Price Adjustment fly-out.
• Set the Type for this price adjustment – Choose either Discount or Increase.
• Specify a percentage of adjustment as the Price Adjustment.
Enter the percentage in the PRICE ADJUSTMENT field. The acceptable value depends on the type of
adjustment:
◦ For a discount: 0 - 99.99%
◦ For an increase: 0 - 999.99%
This is the general percentage of adjustment (increase or discount) for the current scope. For any costs within
the adjustment scope, Turbonomic will apply this percentage as it calculates the optimal workload capacity
and placement.
NOTE:
If you set an overall adjustment of 0%, then Turbonomic enforces a Type setting of Discount. The end result
is the same, because an increase or a discount of 0% is the same.
5. Specify any price overrides for this price adjustment.

Billing and Costs

The PRICE ADJUSTMENT percentage you just specified applies as a default in the adjustment scope. However, you
might have negotiated different prices for specific services or template families in your cloud environment. To
configure these special prices, click PRICE OVERRIDES to open the Cloud Cost Adjustment fly-out. The overrides
you can specify depend on the cloud service provider that manages the discount scope you have set:
• Azure – See Price Override: Azure (on page 433)
• AWS – See Price Override: AWS (on page 435)
6. Save your work.
After you have configured the price adjustment, click SAVE.
Price Override: Azure

To override the PRICE ADJUSTMENT setting for Azure billing groups, Turbonomic analysis can use settings for different
services that Azure provides to subscriptions.
Assume your price adjustment specifies a discount of 10% for an Azure subscription. But then assume the subscription
includes extra discounts for some of the services the subscription provides. Then you can create overrides to add the

Billing and Costs
extra discounts for those services. For more information about Azure subscriptions and cost calculations, see Azure
Enterprise Agreements (on page 51).
In the Cloud Cost Adjustment table, you can perform the following:
• Override the price adjustment for a service or template family.
To add an override, choose the line item for a service, or expand the row for a template family and:
◦ Set the Type. Double-click and then choose Discount or Increase. Press Enter to confirm your setting.
◦ Specify the percentage for this override, and then press Enter to confirm your override. The value you enter
here is an absolute value for the discount or increase Turbonomic will apply for this line item.
When you're done setting these overrides, click Save.
• To remove all overrides and revert back to the PRICE ADJUSTMENT Discount, click CLEAR ALL OVERRIDES.
• To download a report of the discounts for each service, click DOWNLOAD and choose CSV or PDF.
The table lists the following information about your discounts:
• SERVICES
The different cloud services to which you can set an override discount. To see individual workload templates:
◦ For Azure, expand Virtual Machines
◦ For AWS, expand AWS EC2 Compute or EC2 Reserved Instance
• TYPE
Whether this price adjustment will be an increase or a discount. By default, this field shows the setting that you
have made for the Price Adjustment. However, you can change it as an override for an individual entry.
• PRICE ADJUSTMENT %
The percentage that you have specified for the Price Adjustment setting. This is the general adjustment that
Turbonomic applies by default to the given service.
• OVERRIDE %
If you have entered a value, this is the price adjustment Turbonomic applies to the given service.
• ORIGINAL RATE (LINUX)
The Cloud Service Provider's cost for VM templates, per hour. To see these costs, expand the workload services to
show specific templates. The cost assumes no charge for the OS license, as though the VM runs Linux.
• EFFECTIVE ADJUSTMENT %
The actual adjustment for the given service.
• ADJUSTED RATE (LINUX)
The discounted cost for VM templates, per hour. To see these costs, expand Virtual Machines to show specific
templates. The cost assumes no charge for the OS license, as though the VM runs Linux.

Billing and Costs
Price Override: AWS

To override the PRICE ADJUSTMENT setting for AWS billing groups, Turbonomic analysis can use settings for different
services that AWS provides to your accounts.
In AWS, you can set up a billing family that includes a master account and a given set of member accounts. Turbonomic
treats the AWS billing family as a Billing Group. For more information about billing families and accounts, see AWS Billing
Families (on page 49).
Assume you have configured a price adjustment with a discount of 10% for a billing family, to match the overall discount
that AWS offers you for that scope. But then assume the account includes extra discounts for some of the services your
billing families provide. Then you can create overrides to add the extra discounts to those services.
Turbonomic uses the adjusted costs in its analysis as it calculates actions. For example, assume a price adjustment of
10% for a billing group, and a discount of 20% for the M4.Large family of templates. As Turbonomic places a workload,
it will consider both the template capacity and the template cost. Even if an M4 template is larger than the workload
actually needs, the M4 template could be less expensive because of the added discount. In that case, Turbonomic will
place the workload on the less expensive template.
NOTE:
The Cloud Cost Adjustment table lists the services that are available to you for the AWS billing family that you have
set up as the discount scope. The services this table displays depend on whether the billing family uses the given
service, and whether there is any recorded cost at the time that you display the table. For this reason, under some
circumstances you might see different services listed in the table.
Under all circumstances, the table lists the services, AWS EC2 Compute, AWS EC2 Reserved Instance, and AWS RDS.
Also, for the Cloud Cost Adjustment table to display CSP Cost and Effective Cost, you must have created a Cost and
Usage report in AWS, and you must store it in an S3 bucket.
In the Cloud Cost Adjustment table, you can perform the following:
• Override the price adjustment for a service or template family.
To add an override, choose the line item for a service, or expand the row for a template family and:
◦ Set the Type. Double-click and then choose Discount or Increase. Press Enter to confirm your setting.

Billing and Costs
◦ Specify the percentage for this override, and then press Enter to confirm your override. The value you enter
here is an absolute value for the discount or increase Turbonomic will apply for this line item.
When you're done setting these overrides, click Save.
• To remove all overrides and revert back to the PRICE ADJUSTMENT Discount, click CLEAR ALL OVERRIDES.
• To download a report of the discounts for each service, click DOWNLOAD and choose CSV or PDF.
The table lists the following information about your discounts:
• SERVICES
The different cloud services to which you can set an override discount. To see individual workload templates:
◦ For Azure, expand Virtual Machines
◦ For AWS, expand AWS EC2 Compute or EC2 Reserved Instance
• TYPE
Whether this price adjustment will be an increase or a discount. By default, this field shows the setting that you
have made for the Price Adjustment. However, you can change it as an override for an individual entry.
• PRICE ADJUSTMENT %
The percentage that you have specified for the Price Adjustment setting. This is the general adjustment that
Turbonomic applies by default to the given service.
• OVERRIDE %
If you have entered a value, this is the price adjustment Turbonomic applies to the given service.
• ORIGINAL RATE (LINUX)
The Cloud Service Provider's cost for VM templates, per hour. To see these costs, expand the workload services to
show specific templates. The cost assumes no charge for the OS license, as though the VM runs Linux.
• EFFECTIVE ADJUSTMENT %
The actual adjustment for the given service.
• ADJUSTED RATE (LINUX)
The discounted cost for VM templates, per hour. To see these costs, expand Virtual Machines to show specific
templates. The cost assumes no charge for the OS license, as though the VM runs Linux.
Currency Settings
By default, Turbonomic uses the dollar symbol ($) when displaying the costs and savings that it discovers or calculates
for your cloud workloads. You can set a different symbol to match your preferred currency. For example, if your cloud
provider bills you in euros, change the currency symbol to €. To do this, go to Settings > Billing and Costs and then click
the Currency tab.
Turbonomic saves your preference in the local storage of the browser that you used to access the user interface. It
reverts to the default symbol if you use another browser or view the user interface in incognito/private mode.
Currency symbols are for display purposes only. Turbonomic does not convert monetary amounts when you switch
symbols.

Administrative Tasks
To perform Turbonomic administrative tasks, you will navigate to different pages from Settings.The different tasks you
can perform for Turbonomic include:
• Managing User Accounts (on page 437)
Create and manage user accounts for Turbonomic.
• Viewing the Update page (on page 448)
See information about your current version.
• License Configuration (on page 449)
Review the status of your current license, and apply any license upgrades.
Managing User Accounts

As an administrator, you specify accounts that grant users specific access to Turbonomic. User accounts determine the
following for a given user login:
• User Authentication
To configure an account, you set the type of authentication the account will use:
◦ Local User – Configure the username and password and save those credentials on the Turbonomic server.
◦ External User – Single user accounts that authenticate through Single Sign-on (SSO) or through Microsoft Active
Directory (AD).
◦ External Group – A group of user accounts that authenticate through SSO or AD.
• User Authorization
Properties that determine the range of access and features for a given user:
◦ Role – Access to specific Turbonomic features
◦ Scope – How much of the environment this user can manage
As you configure user accounts, you can set up access to specific clusters in your environment. You can even set up
accounts for tenant customers, and only show them the virtual workloads they own in their specific virtual datacenters.

IMPORTANT:
You can configure Turbonomic to use SSO authentication. When SSO is enabled, Turbonomic only permits logins via
the SSO IdP. Whenever you navigate to your Turbonomic installation, it redirects you to the SSO Identity Provider (IdP)
for authentication before displaying the Turbonomic user interface.
Before you enable SSO for your Turbonomic installation, you must configure at least one SSO user with Turbonomic
administrator privileges. If you do not, then once you enable SSO you will not be able to configure any SSO users
in Turbonomic. To authorize an SSO user as an administrator, use EXTERNAL AUTHENTICATION to do one of the
following:
• Configure a single SSO user with administrator authorization.
Add an external user. The username must match an account that is managed by the IdP.
• Configure an SSO user group with administrator authorization.
Add an external group. The group name must match a user group on the IdP, and that group must have at least
one member.
For information about configuring SSO user groups in SAML, see Configuring a Group for SSO Authentication (on page
444). For information about configuring SSO authentication for Turbonomic, see "Single Sign-On Authentication" in
the Turbonomic Installation Guide.
To work with Turbonomic accounts:

2. Choose User Management.

Click to navigate to the User Management Page.


This page lists all the user accounts that you currently have configured for Turbonomic. You can:
• Click to manage LOCAL USERS or EXTERNAL AUTHENTICATION
• Select an entry to delete the account
• Click a name to edit the account
• Create new user or group account
• Configure Active Directory settings
3. Filter the list of users.

To work with a long list of users, you can filter by role (for example, only show administrator or only show observer
users). You can also type a string in the Search field to filter the list, and you can sort the list by name.
4. Work with Local user accounts.

Turbonomic stores local accounts and their credentials on the Turbonomic platform. Local authentication is for
individual users, only.
When you choose LOCAL USERS, Turbonomic displays a list of all the local user accounts you have configured for
this installation.
5. Create or edit a local user account.


To add a new local user, click NEW LOCAL USER. To edit an existing account, click the account name in the list. To
configure a local account, specify:
• Authentication:
Provide the username and password. Turbonomic stores these credentials on the local server.
• Authorization – User Role:
◦ Administrator
Can use all Turbonomic features, and can modify settings to configure the Turbonomic installation.
◦ Site Administrator
Can use all Turbonomic features, and can modify site-specific settings to configure the Turbonomic
installation. Can administer Groups, Policies, Templates, Billing/Costs, Users (cannot create users
with Administrator role), Target Configuration, but cannot administer Email, Licenses, Updates, and
Maintenance.
◦ Automator
Can use all of the Turbonomic features including Plan and Place, but cannot configure the Turbonomic
installation or create policies.
◦ Deployer
Can view all Turbonomic charts and data, can use Place to reserve workloads, and can create policies and
templates. However, this role cannot run plans or execute any recommended actions.

◦ Advisor
Can view all Turbonomic charts and data, and can run plans, but cannot use Place to reserve workloads, or
execute any recommended actions.
◦ Observer
Can view the environment, including the Home Page, and Dashboards. Can also use Search to set a scope
to the session. For scope, only VM groups and Resource Groups are supported.
◦ Operational Observer
Can view the environment, including the Home Page, Dashboards, Groups, and Policies. Can also use
Search to set a scope to the session.
◦ Shared Advisor
A scoped user. Can only see VMs and Applications, and cannot execute Turbonomic actions. Can view the
Home Page and Dashboards.
◦ Shared Observer
Home Page and custom Dashboards, but not Executive Dashboards. This is the most restricted user.
◦ Report Editor
Can create, edit, and delete reports. If you have a Grafana Enterprise license, can also schedule the e-
mailing of reports. Due to limits to the reporting license, only one user per instance is allowed to have this
role (by default, the local administrator user). To assign this role to another user, you must first remove it
from the current user. Be sure that the new user is not a scoped user.
• Authorization – Scope (optional)
The scope limits what the user can monitor. For example, you can scope to a group that contains only the
physical machines that support this user’s VMs or applications. Click ADD SCOPE and choose which groups or
clusters this user can see.
NOTE:
Under most circumstances, a scoped user cannot see actions for entities that are outside of the configured
scope. However, when zooming in to Host entities, the user can see actions for storage that is outside of the
user's scope if the hosts use that storage.
6. Work with EXTERNAL AUTHENTICATION to set up SSO or AD accounts.


For External Authentication, you configure Turbonomic to use SSO or AD services to manage the credentials and
authentication of users. You can create external accounts to authorize user groups or individual users.
NOTE:
If a user is a member of multiple groups, then Turbonomic logs the user on via the first SSO or AD that
successfully authenticates the user. Also note that Turbonomic does not support nested AD groups – AD logins
must be for users in a top-level group.
To enable SSO, you must configure access to the given IdP. For information about configuring SSO, see "Single Sign-
On Authentication" in the Turbonomic Installation Guide.
To enable AD you must specify either an AD domain, an AD server, or both. Turbonomic uses this connection for all
AD users.
7. Enable AD authentication.

To enable AD, click CONNECT TO AD and configure:
• Active Directory Domain – To authenticate AD groups, specify a domain so that AD can find a given user via the
User Principal Name (UPN). If you specify a domain, but not a server, authentication uses any AD server from
that domain.
• Active Directory Server – To disable AD groups, specify a server but do not specify a domain. If you specify a
domain and a server, authentication will use that server, and will also support groups.
When you configure an AD server, by default Turbonomic assumes the AD server port to be 389 or 636.
To specify a custom port for the AD server, add the port number to the AD server IP address. For example,
10.10.10.123:444 sets port 444.
• Secure – Use a secure connection when communicating with AD servers. Note that the AD domain must be
configured to use LDAPS, and you must have imported a certificate into the Turbonomic server. For more
information, see "Enforcing Secure Access" in the Turbonomic Installation Guide.
8. Create or edit an SSO or AD account.


This account can be for a user group or for a single user. To add a new account, click NEW EXTERNAL GROUP or
NEW EXTERNAL USER. To edit an existing account, click the account name. To configure an external account,
specify:
• Authentication:
Provide the group or user name for this account. The name you provide must meet certain requirements,
depending on the type of account you are creating:
◦ External Group - SSO
Provide a name that matches a group the IdP manages.
◦ External Group - AD
The group name must match a group that is accessible from the domain and servers that you configured
in EDIT AD.
◦ External User - SSO
Provide a user name that matches a user managed by the IdP.
◦ External User - AD
The username must be a valid User Principal Name (UPN). For example, [email protected].
• Authorization – User Role:
◦ Administrator
Can use all Turbonomic features, and can modify settings to configure the Turbonomic installation.

◦ Site Administrator
Can use all Turbonomic features, and can modify site-specific settings to configure the Turbonomic
installation. Can administer Groups, Policies, Templates, Billing/Costs, Users (cannot create users
with Administrator role), Target Configuration, but cannot administer Email, Licenses, Updates, and
Maintenance.
◦ Automator
Can use all of the Turbonomic features including Plan and Place, but cannot configure the Turbonomic
installation or create policies.
◦ Deployer
Can view all Turbonomic charts and data, can use Place to reserve workloads, and can create policies and
templates. However, this role cannot run plans or execute any recommended actions.
◦ Advisor
Can view all Turbonomic charts and data, and can run plans, but cannot use Place to reserve workloads, or
execute any recommended actions.
◦ Observer
Can view the environment, including the Home Page, Dashboards, and Groups (VM Groups and Resource
Groups only). Can also use Search to set a scope to the session. For scope, only VM groups and Resource
Groups are supported.
◦ Operational Observer
Can view the environment, including the Home Page, Dashboards, Groups, and Policies. Can also use
Search to set a scope to the session.
◦ Shared Advisor
Home Page and Dashboards.
◦ Shared Observer
Home Page and custom Dashboards, but not Executive Dashboards. This is the most restricted user.
◦ Report Editor
Can create, edit, and delete reports. If you have a Grafana Enterprise license, can also schedule the e-
mailing of reports. Due to limits to the reporting license, only one user per instance is allowed to have this
role (by default, the local administrator user). To assign this role to another user, you must first remove it
from the current user. Be sure that the new user is not a scoped user.
• Authorization – Scope (optional)
The scope limits what members of this group can monitor. For example, you can scope for access to only
the hosts that support this group’s VMs or applications. Click DEFINE SCOPE and choose which entities this
members of this group can see.
Configuring a Group for SSO Authentication

To use SSO authentication in Turbonomic, you should configure user groups on the IdP. The IdP can authenticate the
group members, and then Turbonomic can assign the user role and scope according to that group's authentication.
To manage personnel changes, you only need to manage the membership in the IdP group. For example, if a user

leaves your organization, you only need to remove the member from the group on the IdP. Because authorization on
Turbonomic is by group, that user will not have any authorization settings stored on the Turbonomic server.
IMPORTANT:
Before you enable SSO for your Turbonomic installation, you must configure at least one SSO user with Turbonomic
administrator privileges. If you do not, then once you enable SSO you will not be able to configure any SSO users
in Turbonomic. To authorize an SSO user as an administrator, use EXTERNAL AUTHENTICATION to do one of the
following:
• Configure a single SSO user with administrator authorization.
Add an external user. The username must match an account that is managed by the IdP.
• Configure an SSO user group with administrator authorization.
Add an external group. The group name must match a user group on the IdP, and that group must have at least
one member.
For more information about configuring SSO authentication, see "Single Sign-On Authentication" in the Turbonomic
Installation Guide.
Specifying a Group in the SAML Response

To support SSO, Turbonomic recognizes IdP responses that comply with SAML 2.0. To create user groups, for each user
response you include an attribute named group, and give the group name as the attribute value. For example, assuming
the following users, setting the group attribute for each user assigns that user to the appropriate group.
Users: Group Attribute:

• George Attribute Name=group, AttributeValue=Beatles
• Paul
• John
• Ringo
• Smokey Attribute Name=group, AttributeValue=Miracles
• Pete
• Ronnie
• Claudette
• Bobby
• Marv
As you specify the user response, to add the user to a group you include a group attribute. For example, to add a user to
a group named turbo_admin_group, you would include the following attribute in that user’s SAML response:
<saml2:Attribute
Name="group"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml2:AttributeValue
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">
turbo_admin_group
</saml2:AttributeValue>
</saml2:Attribute>

Setting Group Authorization in Turbonomic

To set an account role and scope to a user group, you must use the group name that you specify as the value in the
given SAML group attribute. In the above example, the group value is turbo_admin_group. To set authorization for that
group:
1. Open the User Management page to EXTERNAL AUTHENTICATION.
Navigate to Settings > User Management, and display the EXTERNAL AUTHENTICATION view.
2. Create a new External Group
Click NEW EXTERNAL GROUP.
3. Provide the group name.
Be sure to use the name that you specify in the group attribute of the SAML response. For the above example, use
the name turbo_admin_group.
4. Specify the group's authorization
For the above example, since this is turbo_admin_group, you should set the ADMINISTRATOR role, and you should
not set any scope (grant full access to the environment).
After you configure this group in Turbonomic, then any member of turbo_admin_group that the IdP returns will
have full administrator privileges on your Turbonomic installation.
Maintenance: Logging and Troubleshooting

The Maintenance Options Page provides tools to set logging levels and to export data for technical support, and import
diagnostic files from Technical Support. Many of these tools are for advanced users. You should contact Turbonomic
technical support before you use them.
To execute these actions, navigate to the Maintenance Options page:

Click to navigate to the Settings Page.
2. Choose Maintenance Options.


Data Retention

Turbonomic gathers metrics from your environment to provide historical reports. To optimize data storage, it
consolidates the data into three groups - Hourly, Daily, and Monthly. Daily statistics consolidate Hourly data, and
Monthly statistics consolidate Daily data. Turbonomic also saves plans, reports, and audit log entries.
You can always modify the default values to meet your requirements. Remember that the longer the retention period,
the more storage is required.
HTTP Proxy

If your environment requires an HTTP proxy for Turbonomic to access the web, provide the credentials here.
Diagnostics

If you are experiencing problems with Turbonomic, your support engineer might request that you export diagnostic
data. You can export the data and then send it to the support engineer as requested.

Feedback and Diagnostics

Turbonomic relies on feedback from customers to continuously improve the product. One way that we receive feedback
is by collecting anonymized and non-confidential data as users go about using the product. Your participation in this
initiative is voluntary (and you can opt out at any time), but it does help Turbonomic deliver a better user experience for
customers.
You can enable this feature to participate. Note that you must have the Administrator role to enable or disable this
feature. If enabled, Turbonomic collects browser event data for all users logged in to the product, and reviews the data
on an ongoing basis to make improvements.
For example, when a product user opens the Plan page in the user interface, Turbonomic records the loading of that
page as a browser event and then collects non-confidential data, such as how long it took to load the page and on
which browser. Turbonomic will never collect sensitive data, such as the user's IP address or location. If page loading is
consistently slow over time and across users, Turbonomic can introduce measures to improve performance.
When you install the product for the first time, you are given the option to enable this feature. For product upgrades,
Turbonomic keeps the previous version's setting. You can always change the setting from the Maintenance Options
page.
NOTE:
To learn more about Turbonomic's privacy policy, visit https://www.turbonomic.com/privacy-policy.
Logging Levels

You can set the level of logging for different components of the Turbonomic platform. You should be aware that setting
more verbose logging levels increases the disk space required to store the log files. You normally change these settings
only while you're working with a Turbonomic support engineer.
The Updates Page

Use the Updates page to get information about your Turbonomic version.
The ABOUT button shows the current version and build of your Turbonomic installation. It also lists the platform
components by name and version.

NOTE:
For complete update instructions, see the Installation Guide.
To navigate to the Updates page:


Click to navigate to the Settings Page.
2. Choose Updates.

License Configuration

To activate the full range of Turbonomic features, you must purchase the appropriate license. When you purchase the
license, Turbonomic sends the license file to you in an e-mail message.
NOTE:
Turbonomic bases its licensing on the number of workloads a given license supports. If your environment exceeds that
count of workloads, then you are no longer in compliance with your Turbonomic requirements, and some features will
be restricted. For example, you will not be able to configure new targets. You should upgrade your license as soon as
possible.
To upgrade your license to support a larger environment, contact your Turbonomic representative to get the correct
license, and to make sure you know how to install it correctly.

A product license enables specific features as well as a specific number of workloads that you can manage. You can add
additional licenses to Turbonomic as a way to increase the number of workloads you installation can manage. Note that
as you add more licenses, they must all support the same feature set.
The License Configuration page shows you:
• The number of active workloads you can manage under this license
• How many workloads are currently active
• The set of features this license enables
• A list of current, active licenses
To navigate to the License Configuration page:

2. Choose License.

To activate a license or to update your current license:
1. Obtain your license.
Turbonomic sends the license file to you in an e-mail message. Save the license file on your local machine so you
can upload it to your Turbonomic installation.
2. Apply the license to your Turbonomic installation.
First click IMPORT LICENSE. Then browse to the license file that you saved and open it. Or you can drag the file into
the Enter License fly-out.
After you have uploaded the file, click SAVE.
After you have activated your license, you can then add more licenses to increase your workload coverage, or you can
license a higher feature set.
NOTE:
As you apply new licenses to Turbonomic, you must be sure that they are for the same edition or feature set. If you try
to apply an incompatible license file, Turbonomic displays an Invalid Feature Set error. To apply the new license you
must either delete your current license so you can install the new feature set, or you must obtain a different license
file that matches your current feature set.
After you install a new license, you should clear your browser cache and reload the Turbonomic user interface.
To increase your licensed workload coverage:

1. Obtain your additional license.
Note that your additional licenses must match the feature set of your current license.
To upgrade your license to a higher feature set:
1. Obtain your new license for the new features.
You should obtain a license that supports at least the same number of workloads as your current license.

2. Delete your current license from Turbonomic.

On the license page, select all the licenses that you currently have installed, then click DELETE.
Email Settings
Configure email settings to enable email communication from Turbonomic.

2. Navigate to the Email Settings Page.
From here, you can configure:
• SMTP Settings
• General Email Settings
SMTP Settings

The SMTP Settings fields identify the mail relay server you use on your network to enable email communication from
Turbonomic.
If the server requires authentication, provide the username and password here. You can also choose the following
encryption options for notifications:
• None
• Ssl
• Tls

General Email Settings

Use this setting to specify the return address (the FROM address) for emails that Turbonomic generates and sends.

Turbonomic User Guide 8.5.0

Uploaded by

Copyright:

Available Formats

Turbonomic User Guide 8.5.0

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Turbonomic User Guide 8.5.0

Uploaded by

Copyright:

Available Formats

Turbonomic 8.5.

Copyright © 2010 - 2022 Turbonomic, Inc. All rights reserved

LEGAL INFORMATION AND RESOURCES

ii Turbonomic, Inc. www.turbonomic.com

Turbonomic 8.5.0 User Guide iii

Actions Tips and Best Practices...........................................................................................................................93

iv Turbonomic, Inc. www.turbonomic.com

Cloud Database Policies.....................................................................................................................................218

Turbonomic 8.5.0 User Guide v

Optimize Container Cluster Plan....................................................................................................................... 298

vi Turbonomic, Inc. www.turbonomic.com

Price Override: Azure........................................................................................................................................ 433

Turbonomic 8.5.0 User Guide vii

8 Turbonomic, Inc. www.turbonomic.com

Turbonomic 8.5.0 User Guide 9

10 Turbonomic, Inc. www.turbonomic.com

How Turbonomic Works

Turbonomic 8.5.0 User Guide 11

The Desired State

12 Turbonomic, Inc. www.turbonomic.com

The Market and Virtual Currency

Turbonomic 8.5.0 User Guide 13

14 Turbonomic, Inc. www.turbonomic.com

The Turbonomic Supply Chain

Supply Chain Terminology

Turbonomic 8.5.0 User Guide 15

16 Turbonomic, Inc. www.turbonomic.com

Turbonomic 8.5.0 User Guide 17

18 Turbonomic, Inc. www.turbonomic.com

The entities Turbonomic discovers through fabric managers targets include:

Turbonomic 8.5.0 User Guide 19

20 Turbonomic, Inc. www.turbonomic.com

Turbonomic 8.5.0 User Guide 21

22 Turbonomic, Inc. www.turbonomic.com

Turbonomic 8.5.0 User Guide 23

The Home Page

24 Turbonomic, Inc. www.turbonomic.com

Turbonomic 8.5.0 User Guide 25

26 Turbonomic, Inc. www.turbonomic.com

Turbonomic 8.5.0 User Guide 27

• Necessary Investments and Potential Savings

Tracking Cloud Cost

28 Turbonomic, Inc. www.turbonomic.com

Costs for Dedicated Tenancy on AWS

Estimated On-demand Costs for Cloud VMs

Turbonomic 8.5.0 User Guide 29

AWS VMs and Azure VMs Without License Costs

On-demand Rate * Usage Not Covered by RIs * Uptime * 730 =

30 Turbonomic, Inc. www.turbonomic.com

Current Values Values After Action Execution

Turbonomic calculates the following:

0.012 * 0.5 * 0.953 * 730 = 4.1

• Estimated On-demand Monthly Cost after executing the action:

0.021 * 1.0 * 0.953 * 730 = 15

Turbonomic 8.5.0 User Guide 31

Azure VMs with License Costs

On-demand Rate - (Reserved License Cost + On-demand License Cost) =

32 Turbonomic, Inc. www.turbonomic.com

Turbonomic 8.5.0 User Guide 33

Current Values Values After Action Execution