In the last 6 months, I've done quite a bit of vRA6, 7 and vRO. During this time, I've had to learn quite a bit about both products, and how they interact with each other and with other REST based APIs, such as ServiceNow. Having been set in my ways in vRA 6 of using workflow stubs to break out to vRO in order to extend vRA functionality, I was concious of the fact that VMware will be removing .NET workflow stubs in future releases of vRA 7, and that the preferred method of extending out to vRO in vRA7 is to make use of the event broker service. Also, vRA7 makes use of converged blueprints, which from an extensibility point of view, actually means that we have to do things slightly differently in code than what we got used in in vRA/vRO6.
In VMware vRealize Automation 7 (vRA), blueprints are converged, rather than the single vs. multi machine blueprints that we were used to in vRA6. This presents an interesting challenge when requesting new catalog items from vRO.
In vRA6, if you wanted to request a new catalog item from vRO, you would run the “Request catalog item” workflow and simply pass any property values along with your request and those property values would be applied to the resulting item in vRA. For instance, when requesting a new VM with 2 vCPUs specified as part of the request, you could specify the following custom property in as part of the request from vRA6:
provider-VirtualMachine.CPU.Count = 2;
In vRA7, you could still use the “Request a catalog item” workflow, however you’ll find that the “provider-<propertyName>“ properties passed with the request are not honoured and will have no effect on the resulting virtual machine. The reason this is happening is because of the converged blueprint. You now need to specify the VM for which the property value is mean to be set. It’s no longer assumed that you only have one virtual machine as part of your blueprint.
I've built up and tore down my vRealize Automation lab several times in the past month in order to familiarize myself with some of the pitfalls. As a result, I've run into some installation gotchas that I noted down, and decided to post them here.
VMware vRealize Automation makes it easy for us to provide our end users with the ability to request and manage their own virtual machines using a “self-service” portal. With very little configuration required, we can add vSphere virtual machine templates to a vRA service catalog for users to consume. vRA can then handle the request management for new virtual machines and when approved by the appropriate approvers, even provision the new VMs by cloning the template.
There seems to be some confusion as to whether or not the Identity Appliance that ships as part of vRealize Automation (previously known as vCloud Automation Center, which will be referred to as vCAC 6 for the rest of this article) is required when deploying vCAC 6.1 in conjunction with vSphere 5.5 and later.
As of vSphere 5.1, Single Sign-On (SSO) is a pre-requisite to installing the components for and including vCenter Server. It’s no secret that VMware’s initial implementation of SSO in vSphere 5.1 was terrible. It was over complicated in terms of its implementation requirements, even requiring its own database, to be manually set up using SQL scripts. Thankfully, VMware addressed many if not all of the SSO issues in its release vSphere 5.5, with SSO now being a much more simple and robust component in your vSphere 5.5 environment.