Caution: Articles written for technical not grammatical accuracy, If poor grammar offends you proceed with caution ;-)
vCAC has what is referred to as the “Master Workflow” which makes up the Virtual Machine Lifecycle. The Master workflow is the top level workflow states that a virtual machine will go through, throughout it’s life. These workflow states tie pretty closely to the Workflow stubs that are shipped with the designer, but they are not a direct match to them. I often see confusion around the workflow states and the workflow stubs. I’m hoping to clear up the confusion around this and help everyone understand the difference between them.
Master WorkFlow States
The vCAC Master workflow states are as follows:
- Request State
- Approval State
- Provision State
- Manage State
- Expired State
- Decommissioned State
Their are many more states than what are listed here, but these are the 6 top level states a machine will go through. Each of these may have sub-states, and their are also states in between these, but in the end a machine is requested, Approved (optional), provisioned, managed, expired (optional), and then decommissioned.
What’s in a state?
- Request State – This state is not customized using workflows, but it’s customized using GUI configurations such as Blueprints, Property Dictionary, Build Profiles, etc.
- Approval State – This much like the request is customized using the GUI. Using approval groups, and approval policies.
- Provisioning State – This is where is starts to get interesting. There is a lot that happens in this Master Workflow state. This state can be customized both in the GUI and the Workflow designer. In the GUI it’s partially affected by the Blueprint. In the Blueprint you can choose what provisioning mechanism, Template, and Customization Specification will be used, but you can also further customize it by defining custom properties. Properties that may interact with the guest agent, properties that may control other aspects of the provisioning.
The flow of what happens within the Provisioning State would be Building Machine, Customize Machine, Customize OS, Customize Guest, and then Machine Provisioned. Two of these states have Workflow Stub associated with them. “Building Machine” has the WorkflowBuildingMachineStub associated with it, and the workflow by default executes pre building machine state. Once the “Building Machine” workflow stub executes, vCAC then starts the actual provisioning process. Once the machine is provisioned we then enter the “Customize Machine” state. This is where things like the CPU are adjusted, additional disks added etc. Once that is complete we then move on to the “Customize OS” state. This is where the Customization Specification is applied.
Next during the “Customize Guest” state is where the guest agent performs all the actions that it is instructed to to perform such as partitioning/formatting a Disk, running a script, etc. Once that is complete the machine enters the “Machine Provisioned” state. The “WorkflowStubMachineProvisioned” workflow executes at the pre machine provisioned state. Once complete the machine is set to the On state which is where the machine enters into the “Managed State” of the Master Workflow.
- Manage State – This is where the machine spends most of it’s life. While in the “Managed State” machine operations are available for use. Some of the capabilities are Power On, Power Off, Reboot, SnapShot, Extend Lease, Expire, Destroy, Reconfigure, etc. In this state you can create custom machine operations using the workflow designer or CDK.
- Expired State – The Expired State has a workflow stub associated with it that executes pre “Machine Expired” state.
- Decommission State – The decommission state has a workflow stub associated with it that executes pre “Machine Disposed” state.
As you can see the Machine Provision Master State as well as the Manage Machine Master State have a significant amount of sub items that are leverage for customization. It’s important to point out that the sun states I refer to in my explanation are specific to cloning a VM using the VMware Clone Workflow. Other provisioning workflows may have different sub states. An example would be WIM provisioning. It goes through the creation of a VM container, then the mounting of an ISO, the the installation of the OS etc, all of which are states the machine transitions through.
Based on some issues I’m having getting the guest agent to run on windows clones, my observation has been that the “Customize OS” state comes after the customization spec has been run, and is actually the stage where the guest agent runs. Unfortunately for me, it never finishes that stage and my deployment fails.
I have been having a similar problem. Did you find a resolution?
I don’t recall if I ever got the guest agent working in 5.2, but in 6.0 you have to disable UAC on the guest template and “unblock” the agent file before unzipping it (right-click, properties, unblock).
Great post, thanks for the information! I am confused about the workflow stub items. Am I right in thinking that once you modify the workflow stub, any scripts etc. that you define as part of that workflow will run every time you provision a machine, regardless of the blueprint type?
Sid, there’s a ton of great information in this post. Is it still valid for vRA 6.1 / 6.2? If not, could we request an update? 🙂 Thanks!
Yes it still holds true.