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.

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. On popular demand of many who could not attend the session due to time-zone differences, we have recorded the session and you can watch the same right here. It is recommended that you watch the video in HD quality for a great experience.

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!

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

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. ( Automating vRA IaaS Blueprint creation with vRO )

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

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. In front of these a load balancer or DNS entry points to the active node only. Fail-over is still a manual task, but it does provide better protection than a single instance.

Providing a highly available single sign on for vRealize Automation is a fundamental part of ensuring the availability of the platform. Traditionally, (vCAC) vRA uses the Identity Appliance and relies on vSphere HA to provide the availability of the SSO platform, but in a fully distributed HA environment that’s not really good enough. It’s also possible to use the vSphere 5.5 SSO install in a HA configuration - however, many companies are making the move to the latest version of vSphere and don’t necessarily want to maintain a 5.5 HA SSO instance.

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)

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.5.2.1
• vCloud Director plugin 5.5.1.2

CPU allocations are incorrect for both “Add a VDC”

When you provide the CPU allocation model properties for the Allocation Pool model the first problem is decrypting the naming - it doesn’t match the names in the vCloud Director interface!