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