This document describes how to configure vRealize Orchestrator (vRO) and vRealize Automation (vRA) 7.X for integration with Turbonomic.
NOTE: This document specifically covers vRA 7 integrations. For vRA 6 integrations, refer to Configuring vRA (vRealize Automation) for Turbonomic Integration
Download the integration from http://download.vmturbo.com/appliance/download/updates/vra/vra7-6.0.0.package
The following software modules must be installed and configured in the runtime environment:
- vCenter Hypervisor, version 5.5 or newer
- vRealize Automation Appliance, version 7.1 or 7.2
- vRealize Orchestrator Appliance, version 7.1 or 7.2
- vRealize Automation Identity Appliance
- vRealize IaaS Server
- vRealize Orchestrator Client
- Turbonomic Operations Manager, version 5.9.1 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  and the same vCenter hypervisor must be successfully discovered and monitored by Turbonomic. If the vCenter target is discovered in Turbonomic using its host name, make sure the same host name is used in the URL of the corresponding vRA endpoint.
2. Importing the Turbonomic package in vRO
The integration module between vRO and Turbonomic is a collection of custom vRO workflows saved in the Turbonomic-vRA7-Integration.package binary file. To import the vRO package into the local machine, please follow these steps :
- Start the vRO client application (named jnlp) and authenticate against the vRO host:
Note: The vRO host above is turbonomic-vro7.corp.vmturbo.com
- In vRO client, switch to Design view, select Packages tab, click on the Import package… button and open the Turbonomic package file:
- 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. That will define the Turbonomic host used for integration and all necessary REST operations:
Notes: 1) The Turbonomic host address above is 10.10.172.101 and the access port is 8400. If you are using the default HTTP (80) or HTTPS (443) port, it can be omitted.
3) When using vRO 7.0 or vRO 7.1, please edit the workflow and remove the unnecessary attributes and bindings before running it.
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 newly created REST host must be set as an attribute for the main Turbonomic workflow. To accomplish this, please select Turbonomic Main Workflow, click on the Edit button, and then click on the Value field of the restHost attribute:
Note: Select the previously created Turbonomic REST Host instance and set it as the restHost attribute value.
The next step is to ensure the main Turbonomic 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 in vRA 7 by enabling the event broker :
- Go to Administration -> Property Dictionary -> Property Groups and add a new group:
- Add the following 6 properties to the new property group, as per the screenshot below:
Note: Set the Value field for all properties to “*” and make sure they are overridable.
- Go to Design -> Blueprints and edit the blueprint used for provisioning virtual machines:
- When editing the blueprint, go to Properties -> Property Groups sub-tab and select the new Property Group:
- Go to Administration -> Events -> Subscriptions and add a new subscription:
Note: As Event Topic please select Machine provisioning
- On the Conditions tab, make sure the workflow will run for the following conditions:
Note: If the subscription is configured only for a vRA blueprint, please add Data -> Blueprint name property to the list of the above conditions and set its value as equal to the particular blueprint name.
- Select Turbonomic Main Workflow on the Workflow tab:
- On the Details tab make sure the Blocking check-box is selected:
After successfully creating and publishing the vRA subscription, new virtual machines can be provisioned from vRA using the service catalog blueprints. For these VMs, the initial settings, such as name, ESX host and data store, will be overridden with the Turbonomic placement values.
4. Provisioning new Virtual Machines using the vRA web portal
In this section, we will assume the vRA infrastructure (e.g. compute resources, endpoints, blueprints, reservations, services, etc.) has been properly configured. For details about the infrastructure setup, please refer to .
The vRA administrator will point the web browser to vRA web portal (e.g. https://turbonomic-vra7.corp.vmturbo.com/vcac/org/turbo). After being successfully authenticated, he will 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 description, reason for request and the number of VM deployments can be filled in:
For every new virtual machine, the followings will occur:
- The IaaS master workflow will invoke Turbonomic 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 Turbonomic Main Workflow will override the VM name, the storage and the ESX Host. It will use the cluster and the enabled storages of the first reservation, linked to the vRA blueprint, as constraints when making the placement decision. The VM name is based on the Machine prefix attribute value already configured for the vRA blueprint.
Note: The ESX host will be enforced only when DRS is disabled, or enabled and not set to Automatic, for the vCenter cluster that will host the newly provisioned VM.
5. Using custom properties to pass in Turbonomic constraints
We can use the vRA custom properties mechanism to pass in the UUIDs of the constraints (e.g. segmentation policies) already defined in Turbonomic. The UUIDs will be later used in vRO, when making the placement request. To define the Turbonomic custom properties in vRA, the following steps must be performed:
- Go to Administration -> Property Definition, click on the New button and create a vRA custom property that starts with the “Turbonomic Property” prefix:
- Assign the vRA property to the blueprint that will be used to provision new workloads. To accomplish this, when editing the blueprint switch to the Properties sub-tab, click the New button and select the Turbonomic custom property. In addition, make sure the “Show in Request” check-box is checked:
- Go to the Catalog tab in vRA web admin and set the value of the Turbonomic constraint, before making the new Virtual Machine request:
The UUID of the Turbonomic constraint can be obtained by running the https:<Turbonomic_IP>/vmturbo/rest/markets/Market/policies REST API call:
6. Current Known Limitations
Below is a list of known limitations for the Turbonomic integration with vRA/vRO 7:
- If the vCenter target is added in Turbonomic using its host name, make sure the same name is used in the URL of the corresponding vRA endpoint;
- The Generate REST Host and Operations workflow uses the built in vRO workflow to add a new REST host. This workflow may differ between the vRO releases and the vRO administrator may be required to edit Generate REST Host and Operations workflow to add or delete the additional input parameters and bindings, as necessary;
- For the placement decision, Turbonomic will use the cluster and storages defined for the first vRA reservation that is linked to the blueprint via the reservation policy;
- If a storage is shared between different vCenter targets, that are defined both in Turbonomic and vRA (as endpoints), Turbonomic may not be able to detect them correctly. In this situation, the shared storage will be ignored when making the Placement decision.
- When configuring the Storage resources for the vRA reservation, make sure you select individual storages instead of the storage cluster. Currently, the Turbonomic Placement REST API call doesn’t support the storage cluster constraints.
 Mastering vRealize Automation 6.2, J. Powell, Packt Publishing, 2015
 VMware vRealize Orchestrator Essentials, D. Langenhan, Packt Publishing, 2015
 VMware vRealize Orchestrator Cookbook, D. Langenhan, Packt Publishing, 2015
 Enabling the Event Broker in vRA 7 - https://extendingclouds.com/enabling-the-event-broker/