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.
So during the keynote at VMworld in Barcelona on Tuesday morning, 18 October 2016, VMware showed a demo of how a VMware Cloud infrastructure is stood up in AWS and following that, showed how a virtual machine was migrated with vMotion into the AWS hosted VMware Cloud. This seemed impressive. However, something’s been bothering me and I’ve been to the VMware booth to get an answer but came up short.
The question I have is around processor architecture. If I’m running Intel in my local vSphere environment and AWS/VMware decided to run AMD in the VMware Cloud on AWS, how would you get that vMotion migration to work? It can’t right?
Is there an option to select the processor vendor for the newly deployed VMware Cloud on AWS?
Answers on o postcard or comment section below! Go!
And we have an answer!! Thank you Alex Jauch (@ajauch)!
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.