workflow

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.

When you are using a VMware orchestration platform with an official VMware plugin to manage a VMware product, you don’t really expect to have to fix the out-of-the-box workflows. However, during some testing of some workflows with a client the other day we ran into a couple of issues with the vCloud Director plugin workflows. Software versions used vCloud Director 5.5.1 (appliance for development) and 5.5.2 (production deployment) vRealize Orchestrator Appliance 5.

One of the use cases I’ve been working on with a customer is based on the vRO/vCO multi-node plug-in and involves the master vRO/vCO node calling proxy workflows based on a parameter - in this case the target site. As you can see from this very simple diagram, a Cloud Management System (CMS) calls a workflow on the Master node, which then executes a proxy workflow on the correct site. The trick is getting the Master Orchestrator node to pick the right proxy workflow.

As a little learning project, I thought I’d take on Simon’s previous post about backing up ESXi configurations and extend it to vCenter Orchestrator (vCO), and document how I go about building up a workflow. I’m learning more and more about vCO all the time, but I found it has a really steep entry point, and finding use cases is hard if you haven’t explored capabilities. The steps I want to create in this post are: