automation

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. With this in mind, I wanted to use the Event Broker to do something that I am asked on almost every customer engagement - custom hostnames beyond what the Machine Prefixes mechanism can do.

A series of webcasts on vRealize Operations Manager 6.x, helping you learn about anything and everything about the solution. Some of the examples include, vROps Policies, Alert Definitions, Automated Action Framework, integration to third party etc. This would include power point and live demonstrations. The session would range anywhere between 60 to 90 minutes. With 100+ registrations and more than 70 live attendees, it was definitely a great start to this series.

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 🙂

@vaficionado) – if that list of names doesn’t fill you with confidence for vRA.Next, then I suggest you follow them on twitter and trust me that it’s a crack team! So, my highlights: Completely automated deployment…almost. The deployment of appliances and installation of IaaS components and pre-requisites will be wizard driven, the Window Servers will need to exist and have an agent installed, and the MSSQL server will also need to be installed.

Recently the team I am working with came across an interesting bug/issue with actions missing from deployed VMs. We had checked and double checked the entitlements yet the actions that should be available to the end-user/customer were not listed. Everything appeared to point to a permissions issue until one of the team members noticed something with regards to blueprints in the catalog. Before I continue with what we observed and how we “fixed” it please bear in mind the blueprints were created programmatically.

Note: This falls under the “I don’t think this is supported” category – use this method at your own peril! As part of some testing I’ve been doing for vRealize Automation DR scenarios, I wanted to test changing the IP address of a HA PSC pair using a script (think SRM failover to a new subnet). What I didn’t want to do was simply edit the connections directly – quite often with the VMware appliances there are scripts on start-up to ensure the configuration is correct and consistent – what I wanted was to be able to find a more supported and reliable way.

The recommendations for the vRealize Appliance have changed with 6.2, the published reference architecture now does not recommend using an external Postgres database (either vPostgres appliance, a 3rd party Postgres deployment or using a third vRealize Appliance as a stand-alone database installation). Instead the recommended layout is shown in the diagram below. One instance of postgres on the primary node becomes an active instance, replicating to the second node which is passive.

vSphere 6 HA SSO (PSC) with NetScaler VPX Load Balancer for vRealize Automation Deploying vRealize Automation 6.2 Appliance Cluster with Postgres Replication Deploying fully distributed vRealize Automation IaaS components - Part 1: Pre-requisites Deploying fully distributed vRealize Automation IaaS components - Part 2: Database, Web and Manager services Deploying fully distributed vRealize Automation instance - Configuring NetScaler Monitors Providing a highly available single sign on for vRealize Automation is a fundamental part of ensuring the availability of the platform.

Recently I have been looking at William Lam’s excellent post on automating the deployment of vROps. After having a play around with it, to suit my own needs, I made some modifications to the Powershell script so it would support distributed switches. # William Lam # Edited by Simon Eady to support vDS # www.virtuallyghetto.com # Deployment of vRealize Operations Manager 6.0 (vROps) ### NOTE: SSH can not be enabled because hidden properties do not seem to be implemented in Get-OvfConfiguration cmdlet ###

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.