Although it’s fairly limited, you can add AWS as an endpoint for vRealize Automation 7  and consume EC2 AMIs as part of a blueprint. You can even add the deployed instances to an existing Elastic Load Balancer at deploy time. In this post I’ll run through the basics to get up and running and deploy your first highly available (multiple Availability Zone, load balanced) blueprint.

Preparing AWS for use as a vRA endpoint

There are some obvious pre-requisites for attaching an AWS endpoint - for example, you need to have a VPC configured. There are plenty of resources out there for creating a VPC, so I won’t extend this post by replicating them. This is what I’m using:

In my post yesterday I promised to post my VMworld session picks, so here it is! I have filled my schedule, and even added some alternate picks when there were too many good sessions to go for. My session picks are focussing around:

• vRealize Automation
• NSX
• VSAN
• PowerCLI, APIs and automation

Now, before anyone tells me I’ve picked too many and I won’t make it to all of them - I know! I can guarantee I’ll get distracted/tired/hungry and won’t make all of them, but if I could…

I’m not sure if I’ll take advantage of the cheap certifications this year - in previous years I’ve take VCIX-NV , VCP-NV and VCAP5-DCD all with great results, so it’s something I’d consider, although at this point I’m not 100% sure what exam I’d take (I’ve done a lot of betas recently!)

I ran into this problem at a customer site where all the Log Insight nodes were changed due to some IP address conflicts. I think the problem occurred because the IP addresses were all changed and the VMs shut down, without time for the application to update the node IPs.

The symptoms:

• The web interface was down, a netstat -ano | grep -i “443” showed the service was listening
• _service loginsight status|restart|stop|start _hung and then timed out on the Master node
• The loginsight service was not running on the Worker nodes
• /var/log/loginsight/runtime.log contains warning messages about “Cassandra cluster not ready yet”

• Running /usr/lib/loginsight/application/lib/apache-cassandra-*/bin/nodetool status showed the two data nodes down (DN) and used the old IP address

All of the nodes were up with their new IP addresses, however Cassandra on the Master node was still looking for the old IP addresses for the Worker nodes. The Worker nodes were in a similar state, knowing their own new IP addresses but not being able to update the Master node because they didn’t have the Master node’s new IP address.

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

The new Event Broker service in vRA7 is one of the most exciting features of this latest release, the possibilities for extensibility are huge. At this point it time you can still use the old method of using workflow stubs to customise machine lifecycle events, but at some point in the future this will be deprecated and the Event Broker will be the only way to extend.

Just a quick little post this morning! Anyone who works with the vRealize Automation APIs should definitely check out Grant Orchard and Roman Tarnavski’s awesome little side project, Platypus .

It only took me a couple of minutes to get it running on my MacBook - here’s how!

Download and install AppCatalyst

Open a new terminal window

Create a new VM called “photon"