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.

(more…)

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.

The list of OOTB actions has grown a lot.. (a sample below)

Couple this with the vRO Management Pack and you can have some serious proactive and reactive automation taking place based on effective monitoring.

If you were already considering using vROps for automation then perhaps this will tip the balance and if you were in the no camp then perhaps you will reconsider?

Either way 6.7 looks great (loving the dark theme)

You can check out more about the overall changes and improvements in the follow sites.

Release notes – https://docs.vmware.com/en/vRealize-Operations-Manager/6.7/rn/vRealize-Operations-Manager-67.html 

Nice blog summary – https://lukaswinn.net/2018/04/12/welcome-to-vrealize-operations-6-7/ 

Like many other geeks out there, I received an Amazon Echo device this Christmas, and whether it’s a fad or not, I’ve spent a few happy hours setting up my Hue lights and some other automation. The room in the house with the most automation is my office – the novelty may wear off, but walking in each morning and saying “Alexa, turn on my office” and having everything wake up for me is really cool.

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. (more…)

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!

Installing the Content Packs

In order to get the full picture of what’s going on during a vRA deployment you will likely need to correlate logs from vRA, vRO and NSX. Installing and configuring these is pretty easy.

I am going to assume the vSphere integration has already been configured, and all ESXi hosts are forwarding their logs to Log Insight already. (more…)

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!

(more…)

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. Use it at your own risk! (more…)

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.

As per Jose’s advice, I duplicated the “com.vmware.library.vCloud.Host/addHost” action, named it “addHost_vCA_G2”:

I then modified the following line to include “/api/compute”:

newHost.url = "https://" + host + ":" + port;

Becomes

newHost.url = "https://" + host + ":" + port + "/api/compute";

I then duplicated the “Add a connection” workflow to create “Add a connection (vCloud Air Gen2)” and swapped the old action for the new action:

Now I can add vCloud Air (PAYG/Gen2) as an endpoint in the normal way:

The out-of-the-box “IaaS vCD VM” Resource Mapping now works in vRA and I can create custom Resource Actions against the vCloud:VM object type.

Once again, big thanks to Jose for this solution!

@sammcgeown @grantorchard duplicate “Add a connection” WF & duplicate “AddHost” action. Append + “/api/compute” pic.twitter.com/oWXayI3fpT

— Jose Luis Gomez (@pipoe2h) April 19, 2016

I ran into this issue as described in 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!)

The article itself does not give a work-around for this issue, but it’s possible to resolve it by editing the customer tenant Orchestrator Server configuration (Administration > vRO Configuration > Server Configuration) to use the external load balanced URL for the appliances (or for a PoC/small deploy with a single appliance, the appliance URL).

If you use the in-built vRealize Orchestrator instance shipped with the vRealize Automation appliance then you might run into this issue when working with the REST client:

Connection pool shut down (Workflow:Get-IdentityToken / Scripting (item3)#14)

The vRA appliance version I have (6.2 – note to self, need to update lab!) includes the plugin version 1.0.4 for REST. According to the release notes, this was fixed in 1.0.5 – typical!

So the solution is to upgrade the REST API plugin 🙂