Automation

In this coming episode, Sunny will DIVE DEEP into the interesting topic of introducing automation into operations.

While we all know that, automating day to day operations tasks is becoming the choice of an IT organization, it is hard for them to find a solution which can completely understand their business policies and provide them the efficiency they need from automating simple operational tasks.

Based on our research, we found that, one of the most time consuming activity done by an Virtual Infrastructure Administrator is to juggle resources between the changing business requirements and ensure that every VM which is being hosted in their environment is BEING SERVED WELL.

With the release of vSphere 6.5, VMware upped the game for vCenter High Availability (vCHA) and introduced an active/passive/witness cluster setup to provide a failover cluster for vCenter Server Appliances. The diagram below shows the architecture of the solution.

Deploying vCHA can be done in two modes - “Basic” and “Advanced”. You can use Basic mode if the vCenter you want to be HA is managing the hosts it resides on - in this scenario the wizard configures your vCenter and deploys the Passive and Witness nodes for you. If you have a management cluster for your vCenter Server, or you are deploying a nested environment, you need to use the advanced mode - in this scenario you must configure your active node, deploy clones for the passive and witness nodes, then enable the configuration.

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.

Time to publish the recording for the 10th episode of vROps Webinar Series. This time around we spoke about vRealize Operations Manager Resful API and how to use it. Post 20 minutes of slide-ware, I jumped into the lab and thanks to the demo god, we demonstrated a number of use cases and browsed through the documentation to make it easier for you to consume and use the same.

Big thanks to @sunny_dua  for doing the session while I was MIA you are a legend buddy!

Recently I was asked to develop some vRealize Orchestrator workflows against the F5 BIG-IP iControl REST API, but I was not able to test freely against a production appliance. After a lot of attempts to get in contact with F5 for a 90-day trial of the full version, or to purchase a lab license, I came up empty handed. The free version you can download from F5’s website is version 11.3, which does not feature the iControl REST API, which was released in 11.4.

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. But this still didn’t expose the vCloud Director functionality for those machines. To do this I needed vCloud Air added as a vCloud Director host.

<img class=“alignright size-thumbnail wp-image-7206” src="/images/2016/03/aaf-logo.png" alt=“aaf-logo” width=“150” height=“150” gems deep inside, vROps in this case is not without exception.

The Automation Action Framework (AAF) is one of these, a really powerful vROps in-built automation tool.

Now when I have discussed this capability with my peers and friends many ask why not use vRO etc? My reply is quite simple, “what if you do not have vRO or the in house skills to utilise it properly?” also “With the AAF you do -not- need any scripting knowledge or have to setup any workflows.”

<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. Next I added a single scriptable task and cycled through the properties. Some of the properties’ values are actually other properties objects, so there’s a function to test the type and iterate through if required.

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!)