Configuring vRA (vRealize Automation) for Turbonomic Integration

Document created by bsong Expert on May 3, 2016Last modified by robert.clark on Nov 3, 2017
Version 8Show Document
  • View in full screen mode

This document describes how to configure vRealize Orchestrator (vRO) and vRealize Automation (vRA) appliance(s) for integration with Turbonomic.


NOTE: This document specifically covers vRA 6 integrations. For vRA 7 integrations, refer to Turbonomic Integration with vRA/vRO 7


1. Prerequisites


The following software modules must be installed and configured in the runtime environment:


  • vCenter Server, version 4.1 or newer
  • vRealize Automation Appliance, version 6.2.x
  • vRealize Orchestrator Appliance, version 6.0.x
  • vRealize Automation Identity Appliance
  • vRealize IaaS Server
  • vRealize Orchestrator Client
  • Turbonomic, version 5.5 or newer


The vRO appliance must be configured as an endpoint in the vRA web portal [1, 2]. In addition, vRO must be integrated with vCenter [1] and the same vCenter hypervisor must be successfully discovered and monitored by Turbonomic.


2. Importing the Turbonomic package in vRO


The integration module between vRO and Turbonomic is a collection of custom vRO workflows saved in the com.vmturbo.mediation.vra.package binary file.  To import the vRO package into the local machine, please follow these steps [3]:


  • Start the vRO client application (named client.jnlp) and authenticate against the vRO host:

Note: The vRO host above is


  • In the vRO client, switch to the Design view, select the Packages tab, click on the Import package… button and open the Turbonomic package file (attached at the bottom of this post and available here:


  • Accept the default certificate, import the vRO package, then click on the Workflows tab and verify the workflows were successfully created under the Turbonomic vRA Integration main folder:


3. Preparing the Turbonomic main workflow for execution


After importing the Turbonomic package, the vRO administrator must execute the Generate REST Host and Operations workflow. It will define the Turbonomic host used for integration and all necessary REST operations:

Notes: 1) The Turbonomic host address above is and the access port is 8400. The default port for Turbonomic running in production is 80 and can be omitted.

2) The host URL must always specify the protocol (http:// or https://) used for making REST API calls.



On the Host Authentication wizard page, please select Basic as the preferred authentication type and, on the next page, enter the Turbonomic administrator credentials:


Finally, click on Submit button and ensure the workflow is successfully executed.

The next step is to set the newly created REST host as an attribute for the main Turbonomic workflow. To accomplish this, please select Turbonomic Main Workflow, click on the Edit button, scroll down to the list of attributes and then click on the Value field of the restHost attribute:



Select the previously created Turbonomic REST Host instance and click on Save and close button.


The last step is to ensure the main VMTurbo workflow is hooked into the IaaS master workflow and is invoked during the Building Machine stage, when provisioning new virtual machines from the vRA web portal. This is done by configuring and running the Assign a state change workflow to a blueprint and its virtual machines predefined workflow, located under Library\vCloud Automation Center\Infrastructure Administration\Extensibility folder, in the vRO client:

Note: The vCAC host entry is the IaaS server entry already configured in vRO.


One or more vRA blueprints can be mapped to the Turbonomic main workflow. It is important to verify those blueprints were not already configured for other vRO workflows. If that is the case, the vRO administrator will have to execute Remove a state change workflow from a blueprint and its virtual machines before performing the new mapping operation. In the following screenshot Win2008 Blueprint 1 is selected as the blueprint that will trigger the Turbonomic main workflow:


To select the proper workflow, on the next wizard page, use Turbonomic Main Workflow as a filter in the Chooser pop-up:

After successfully running the mapping workflow new VMs can be provisioned from vRA. The initial settings, such as VM names, ESX hosts and data stores, will be overridden with VMTurbo values.

4. Provisioning new VMs using the vRA web portal


In this section we will make the assumption that the vRA infrastructure (e.g. compute resources, endpoints, blueprints, services, etc.) has been properly configured. For details about the infrastructure setup, please refer to [1].

The vRA administrator will point the web browser to vRA web portal (e.g. After being successfully authenticated, go to Catalog tab and click the associated Request button for one of the services that uses a blueprint already mapped to Turbonomic Main Workflow:


Before submitting the request, additional values such as the number of new VMs, the VM CPUs and Memory in MB can be provided:


It is a good practice to verify, on the Properties tab, that the value of ExternalWFStubs.BuildingMachine property matches the ID of Turbonomic Main Workflow in vRO. For every new VM, the following will occur:


  • The IaaS master workflow will invoke VMTurbo Main Workflow at the BuildingMachine stage;
  • The Turbonomic Main Workflow will perform REST API calls to Operations Manager, configured as a REST host in vRO, and get the placement information for the VM.
  • The WMTurbo Main Workflow will override the VM name, the storage and the ESX Host. It will use the vCenter cluster selected by vRA as a constraint when making the placement decision. The VM name is based on the Machine prefix attribute value already set for the vRA blueprint.


Notes: 1) Because the VMTurbo doesn’t take into consideration the vRA storage constraints, please make sure all the vCenter data stores, discovered by Operations Manager, are available for the vRA reservation used to provision new VMs from vRA web portal.

            2) The ESX host will be enforced only when DRS is disabled, or enabled and not set to Automatic, for the vCenter cluster that will contain the provisioned VM.




5. References


[1] Mastering vRealize Automation 6.2, J. Powell, Packt Publishing, 2015

[2] VMWare vRealize Orchestrator Essentials, D. Langenhan, Packt Publishing, 2015

[3] VMWare vRealize Orchestrator Cookbook, D. Langenhan, Packt Publishing, 2015

6 people found this helpful