vRealize Orchestrator Workflow: shutdownVSANCluster
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. There were some design considerations:
- Something to do with the C6100 IPMI implementation and the ESXi driver does not like being woken from standby mode. It’s annoying, but not the end of the world – I can use impitool to power the hosts on from shutdown. If you want to use host standby, there’s a hostStandby and hostExitStandby workflow in the package on github.
- I run VSAN on the cluster, so I need to enter maintenance mode without evacuating the data (which would take a long time and be pointless).
- All the running VMs on the cluster should be shut down before the hosts attempt to go into maintenance mode.
- I want a “what if” option, to see what the workflow would do if I ran it, without actually executing the shutdown – it’s largely for development purposes, but the power down/power on cycle takes a good half hour and I don’t want to waste time on a typo!
vRealize Orchestrator (vRO/vCO) and vCloud Director – fixing bugs in "Add a vDC"
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 220.127.116.11
- vCloud Director plugin 18.104.22.168
CPU allocations are incorrect for both "Add a VDC"
When you provide the CPU allocation model properties for the Allocation Pool model the first problem is decrypting the naming – it doesn’t match the names in the vCloud Director interface!
The "CPU (GHz)" value is the vCPU speed, and the "CPU Quota (GHz)" value is the CPU allocation
vRealize Orchestrator (vCO) Multi-node Plug-in use case: Remote Site Selection and Execution
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.
Backing up ESXi 5.5 host configurations with vCenter Orchestrator (vCO) – Workflow design walkthrough
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:
- Right click host to trigger
- Sync and then back up the configuration to file
- Copy the file to a datastore, creating a folder based on date and the host
Ideas for future extensions of this workflow include – trigger from cluster/datastore/host folder, email notifications, emailing the backup files and backup config before triggering a VMware Update Manager remediation. Hopefully all this will come in future posts – for now, lets get stuck into the creation of this workflow.