Using vRealize Orchestreator MP in vROps

Product Version - vRealize Operations 7.x and 8.x

A few years ago VMware released the Orchestrator MP which is a superb way to directly call vRO workflows from vROps by way of alerts and actions. This opens the door to all manner of ideas for conditional automation using vROps.

The limitation

Recently for a customer we planned to use the vRO MP to assist a customer with a very unique/niche challenge. vRO was a key component to the challenge and we identified a possible solution using the vRO MP in vROPs which for all intents and purposes looked ideal.

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.

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.

@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:

1. 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. Anyone who’s done a distributed vRA install will know that this is a massive improvement over the current state of affairs.
2. The vRealize Automation appliances will be clustered automatically for core services such as identity, cafe (portal), vPostgres and embedded vRealize Orchestrator (Embedded vRO is now recommended for production).
3. A new identity service. No more vSphere SSO or PSC – VMware Identity Management (vIDM) is a new, highly scalable and performing federated identity platform. Any SAML identity source, and more than 3m users supported per source.
4. An initial setup wizard that creates your first tenant, configuring things like fabric groups, business groups and vSphere endpoints automatically. It will even import your existing vSphere templates as clone blueprints.
5. The old CDK is gone! Instead you can use any event within vRA that is pushed through the RabbitMQ message bus to trigger extensibility through workflow subscriptions.
6. vRealize Orchestrator has a new HTML5 Control Center which is your single admin point for plugin configuration as well as adding metrics and monitoring for all workflows being executed.
7. There’s no need for unique tenant URLs – the new vIDM platform allows a single logon interface for all tenants. (Though you can keep your URLs if you want!)
8. vIDM can also be used to control authentication from IP source, e.g. to restrict logon to a specific subnet regardless of whether the credentials are valid or not. This has some cool ramifications for having the web layer in a DMZ, for example.
9. Functionality is slowly being migrated from the old IaaS/DynamicOps layer to the appliance – this is fantastic news. The migrated portions (such as vSphere Endpoint configuration) are now accessible through the vRA API, as well as gaining the speed and stability that the appliances provide.
10. The new blueprint designer is awesome. Added to that what was AppD is now called App Services and allows you to take a base blueprint (e.g. a CentOS VM) and drag and drop software components that you’ve scripted on top (e.g. Apache, then PHP). You can also drag and drop XaaS (vRO workflows) onto the blueprint, as well as existing blueprints to create nested blueprints.
11. Much fuller integration between NSX and vRA. There’s a whole raft of improvements in the integration between vRA and NSX – e.g. you can drag a new routed network onto a blueprint and it will automatically create a new Logical Switch and Distributed Logical Router to attach the Logical Switch to. Similarly load balancing applications is a drag and drop operation, as is applying existing security groups.
12. All blueprints can be imported and exported in YAML, which opens up exciting possibilities for storing versioned blueprints and retrieving programmatically.
13. There are over 60 lifecycle events out of the box on which you can trigger Orchestrator workflows, but you can create custom filters based on properties and events to extend functionality – the only limitation is what you can imagine!

There are still several months of development to go between now and the GA of vRA 7 and the development seems to be moving at a great pace. Between beta 1 and beta 2 there was a huge amount of change, and even the version demoed today had new features and UI.

As a PowerShell fan I find using the vCO PowerShell plugin makes my life a whole lot easier. What isn’t easy however, is  the configuration of vCO and a PowerShell jump host. Having done it a few times, this is my method for ensuring a secure working connection using HTTPS and Kerberos.

Configure the Orchestrator Appliance

Since we’re planning on using Kerberos authentication, we’d better ensure that the time is correct AND syncs to the same source as the domain.

In my previous post Backing up ESXi 5.5 host configurations with vCenter Orchestrator (vCO) – Workflow design walkthrough I showed how to create a workflow to back up host configurations, but it was limited to one host at a time. For this post I’m going to show how to create a new workflow that calls the previous one on multiple hosts using a ForEach loop to run it against each one. This was actually easier than I had anticipated (having read posts on previous versions of vCO that involved created the loops manually).

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.