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 Error getting certificates!

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.

This series was originally going to be a more polished endeavour, but unfortunately time got in the way. A prod from James Kilby (@jameskilbynet) has convinced me to publish as is, as a series of lab notes. Maybe one day I’ll loop back and finish them… Requirements Routing Because I’m backing my vCloud Director installation with NSX-T, I will be using my existing Tier-0 router, which interfaces with my physical router via BGP.

It has been a while since I have had time to write a blog post, the last quarter of last year was pretty crazy from a work point of view. Regardless, it is now a New Year and my tech focus is turning very much on CMP related things particularly vRealize Automation. (I am also very much looking forward to learning more about VMware’s CaS which I saw demo’d at the UK VMUG late last year by Grant Orchard)

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.

This series was originally going to be a more polished endeavour, but unfortunately time got in the way. A prod from James Kilby (@jameskilbynet) has convinced me to publish as is, as a series of lab notes. Maybe one day I’ll loop back and finish them… Prerequisites PostgreSQL server deployed and configured Two vRO 7.4 appliances deployed Before powering them on, add an additional network card on the vcd-sql network

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.

In this humble consultant’s opinion, Log Insight is one of the most useful tools in the administrator’s tool belt for troubleshooting vRealize Automation. I have lost count of the number of times I’ve been asked to help troubleshoot an issue that, when asked, people don’t know which log they should be looking at. The simple fact is that vRealize Automation has a lot of log files. Correlating these log sources to provide an overall picture is a painful, manual process - unless you have Log Insight!

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.