vRealize Orchestrator

I was doing some testing with adding an external vRealize Orchestrator 8.4 endpoint to vRealize Automation Code Stream 8.4, and it turns out there’s a redirect that happens with the vRO 8.4 appliance that makes the endpoint validation fail. When you enter the URL and click ACCEPT CERTIFICATE the UI will throw an error: Server error on getting certificates. Http failure response for https://<vRA FQDN>/codestream/api/endpoint-certificate?url=https://<vRO FQDN>: 400 Bad Request

Using vRealize Orchestreator MP in vROps Product Version - vRealize Operations 7.x and 8.x A few years ago VMware released the Orchestrator MP which is a superb way to directly call vRO workflows from vROps by way of alerts and actions. This opens the door to all manner of ideas for conditional automation using vROps. The limitation Recently for a customer we planned to use the vRO MP to assist a customer with a very unique/niche challenge.

Just a quick post today to cover a new vRO action and workflow I’ve uploaded to GitHub that configures vCenter High Availability in the basic mode. This is based on William Lam’s excellent PowerShell module that does the same, but using vRO. I also hope to release a version for the advanced mode based on my PowerShell script in the near future. TL;DR - package is availabile on GitHub The workflow itself is pretty self explanatory, with my deployment action, which returns a VC:Task, and the standard “wait for a task to end” action.

There are many improvements, changes and new additions to vROps in version 6.7 but one of the aspects that stands out to me personally is the direction VMware are taking with the product. Aside from the obvious addition of cloud costings and comparisons and a reworked capacity planning (from the ground up) and new hook in to Wavefront (which I really like) there has been some real effort to improve how you can further automate things from vROps.

I already have a vRealize Orchestrator workflow to shutdown my workload cluster. What I want to do is trigger that by a voice command from Alexa. Now, the correct and proper thing to do here would be to create a new Alexa skill, write the function in Lambda and connect that to my Orchestrator REST API and execute the workflow. That way I could control the “intents” and “utterances” and have verbal feedback.

My vSphere lab is split into two halves - a low power management cluster, powered by 3 Intel NUCs, and a more hefty workload cluster powered by a Dell C6100 chassis with 3 nodes. The workload servers are noisy and power hungry so they tend to be powered off when I am not using them, and since they live in my garage, I power them on and off remotely. To automate the process, I wanted to write an Orchestrator workflow (vRO sits on my management cluster and is therefore always on) that could safely and robustly shut down the workload cluster.

Back in January 2015 I wrote an article on how to modify the Java heap settings for the vCenter Orchestrator client when working with very large workflows. Since vRealize Orchestrator 7.x has been released, we no longer have an installable client, just a Java WebStart file (.jnlp) that you run, or a package that you can download - but nothing that installs. Note that none of this is official or supported by VMware as far as I know - it’s the results of my experimentation which has shown some performance improvement by increasing the configured memory pool.

Big thanks to Jose Luis Gomez for this solution, his response to my tweet was spot on and invaluable! I’ve been trying to configure vCloud Air as a vCloud Director host in vRealize Orchestrator in order to create some custom resource actions for Day 2 operations in vRealize Automation. What I found was that there’s *very* little information out there on how to do this, and I ended up writing my own custom resource mapping for the virtual machines to VCAC:VirtualMachine objects - at least that way I could add my resource action.

<img class=“alignright size-thumbnail wp-image-6186” src="/images/2015/07/vRA-Product-Icon-Mac_0.png" alt=“vRA” width=“150” height=“150” - a properties object. I wanted to create a workflow that I could enable to log all of the keys, values and types of the properties object for each stage of the vRA7 MachineProvisioning workflows, and create a reference for myself on the payload for each stage. To do this I created a new workflow “debugProperties” and added an input variable called “payload”, type Properties.

VMware KB2140539 where requesting an XaaS (vRealize Orchestrator) blueprint fails with: Failed to retrieve form from provider The KB describes it occuring when “more than one VMware vRealize Orchestrator instance is configured for different tenants”. The issue I faced is not the same - in my case, I had the system default tenant configured to use the embedded vRO, and the customer tenant configured to use the system default (which would be the embedded vRO!