We had an issue today where the vRealize Automation (vRA) 7 Event Broker Service (EBS) would time out. The timeouts would happen intermittently, during different stages of the provisioning lifecycle. We noticed that something was not right when extensibility workflow calls to vRealize Orchestrator (vRO) would return after the vRO workflows completed, but the provisioning lifecycle state for the virtual machine would fail to change or progress and eventually time out with an EBS timeout message.
Custom properties in VMware vRealize Automation (vRA) provide us with the ability to set data on vRA objects and to change configurations that affect the behaviour of objects in vRA. For example, when set on a vSphere Virtual Machine component contained in a composite blueprint in vRA 7, the property "VirtualMachine.Admin.ThinProvision" results in the virtual machine deployed with thin provisioned disks in vSphere. The "VirtualMachine.Admin.ThinProvision" property is a custom property that the out of the box vSphere provisioning workflow uses when set, and we do not have to do anything other than specifying a "true" value for the property to have an effect on the resulting virtual machine. VMware has developed the built-in workflows to make use of custom properties such as "VirtualMachine.Admin.ThinProvision" when they are specified on various components. These properties are documented in the "Custom Properties Reference" documentation provided with vRA 6 and 7.
Custom properties that ship out of the box with vRA, however, are only a small part of where the concept of custom properties can be used to extend the capabilities of your automation solution. Just as the built-in workflows make use of custom properties, so can your workflows take advantage of custom properties that you define using vRealize Orchestrator (vRO).
I have been dabbling in the world of vRO plugin development. Yes, I know, vRO is a product that doesn't get much love from the VMware community, and I do not think that is fair. People seem to have decided that the product is too complicated and where possible would rather write a PowerCLI script to automate things. The truth is, that when you take a little bit of time to look at vRO, you will find that it is not that complicated to develop vRO workflows and the possibilities are endless. I know, so I'm telling people that vRO isn't that complicated in a blog post which is targeted at myself for when I run into this issue in the future! So, if you are finding workflow development too complicated a task, this post is not for you, as I doubt you will be interested in plug-in development.
Following on from my original vRetreat blog post, I thought it would make sense to report on some of the technical IT discussions that happened on the day, For this blog post, I am going to be focusing on the presentation by Darren Swift from Zerto.
So who and what is Zerto? Well, as started on the "About Zerto" page on their website, "Zerto provides enterprise-class disaster recovery and business continuity software specifically for virtualised datacenters and cloud environments."
In simple terms, Zerto provides hypervisor-level replication and automation with no hypervisor vendor-specific lock-in. It provides continuous replication (no snapshots) of virtual machines between hypervisors and replaces traditional array-based replication solutions that were not built to deal with virtualised environments.
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.
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.