Accepted Solutions
I'll be honest but this was one of the biggest learning curves I had when I first got into using vRA. It's quite hard at first to visually understand what is going on.
vRA will manage your catalog items, that is, you have created a blueprint, that probably includes a virtual machine that can be provisioned against a 'hypervisor' cluster. You entitle this blueprint for a business group and it appears on the service catalog portal. A user can log in and request this catalog item and without you having to do much else it will build the VM on the underlying hypervisor.
Under the hood vRA is working with vRO in the background to make this magic happen. Therefore; for this basic scenario you don't really need to be aware of anything else, as long as the compute resources are ready to use you are good.
However, if you want to add any cusomization to the deployments workflow, such as IP addressing, generating hostnames or any other custom logic then you need to work heavily with vRA's Event Broker Service and vRO workflows;
This document provides a basic understanding:
Machine Life Cycle Extensibility
Essentially, when a machine is requested in vRA, it will go through a series of phases during the provisioning lifecycle. There are dozens of different phases depending on how the deployment is handled (i..e Cloning, PXE booting, SCCM, etc). But there are always 6 phases that run regardless, these are Requested, Building Machine, Machine Provisioned, Machine Activated, Unprovision Machine, Machine Disposing. Most phases also have a PRE, POST and EVENT state.
At any point during these lifecycle phase + state you can inject a workflow which contains custom logic that can be executed. This is accomplished by first creating a workflow that contains the custom logic (Javascript code) and then creating a 'subscription' to that workflow using the Event Broker Service.
Here is a diagram I created based on the link above, which includes what happens during each lifecycle phase (I left out the phase states for simplicity).
Why do we have phases states? A good example of this is if you wanted to re-configure the VM for some reason once it has been built. Up until the Building Machine PRE phase state the VM does not exist, but at the Building Machine POST state the VM has been created.
This topic is a beast but let me know if I haven't answered your question or if you have anything further you'd like to know.
Gavin
I'll be honest but this was one of the biggest learning curves I had when I first got into using vRA. It's quite hard at first to visually understand what is going on.
vRA will manage your catalog items, that is, you have created a blueprint, that probably includes a virtual machine that can be provisioned against a 'hypervisor' cluster. You entitle this blueprint for a business group and it appears on the service catalog portal. A user can log in and request this catalog item and without you having to do much else it will build the VM on the underlying hypervisor.
Under the hood vRA is working with vRO in the background to make this magic happen. Therefore; for this basic scenario you don't really need to be aware of anything else, as long as the compute resources are ready to use you are good.
However, if you want to add any cusomization to the deployments workflow, such as IP addressing, generating hostnames or any other custom logic then you need to work heavily with vRA's Event Broker Service and vRO workflows;
This document provides a basic understanding:
Machine Life Cycle Extensibility
Essentially, when a machine is requested in vRA, it will go through a series of phases during the provisioning lifecycle. There are dozens of different phases depending on how the deployment is handled (i..e Cloning, PXE booting, SCCM, etc). But there are always 6 phases that run regardless, these are Requested, Building Machine, Machine Provisioned, Machine Activated, Unprovision Machine, Machine Disposing. Most phases also have a PRE, POST and EVENT state.
At any point during these lifecycle phase + state you can inject a workflow which contains custom logic that can be executed. This is accomplished by first creating a workflow that contains the custom logic (Javascript code) and then creating a 'subscription' to that workflow using the Event Broker Service.
Here is a diagram I created based on the link above, which includes what happens during each lifecycle phase (I left out the phase states for simplicity).
Why do we have phases states? A good example of this is if you wanted to re-configure the VM for some reason once it has been built. Up until the Building Machine PRE phase state the VM does not exist, but at the Building Machine POST state the VM has been created.
This topic is a beast but let me know if I haven't answered your question or if you have anything further you'd like to know.
Gavin
If you feel this has answered your initial question, then kindly mark as answered 