It seem that there is a bit of confusion around using vCO workflows with multi-machine blueprints. Before I discuss how to build vCO workflows for multi-machine blueprints I want to discuss the differences between single machine and multi-machine blueprints and how they relate to each other.
Single Machine Blueprints
Single machine blueprints are pretty straight forward. When a custom property is defined on a single machine blueprint it only affects that machine. Makes sense right? When we trigger a vCO workflow to run during a state transition of a single machine it interacts with only that machine. It is important to be mind full of the vCO workflows that are assigned to single machine blueprints that may be used as a component machine of a multi-machine blueprint.
Multi-Machine Blueprints
Multi-Machine blueprints are extremely versatile allowing single machine blueprints to be grouped together for and requested in a single deployment. They are so versatile that you can add single machine blueprints of different types that are possible deployed to different types of Endpoint and across geographies. This however also makes them somewhat complex requiring you to be careful and thoughtful as to how you structure custom properties and the vCO workflows that you may choose to run on them.
Custom properties that are defined at the Multi-Machine blueprint are passed down to the component virtual machines that are a part of them. This can be very useful, but can also be a bit dangerous. Take the hostname property. If we define a hostname using this property at the Multi-Machine level it will cause chaos during the deployment and cause the deployment to fail because all machine will inherit the property and the value and ultimately have the same name.
This is the case with any different properties when used at the multi-machine level. You also need to be mindful of the effect of that property across different platform, provisioning types as well as geographies. This becomes even more complicated when executing state transition workflows that run vCO workflows. If you attach a workflow to the multi-machine it will in turn become attached to every component machine as well. This can be very useful if you want to execute the workflow on every component machine, however if that workflow is utilizing an entity that doesn’t exists at the parent multi-machine level it will again cause chaos for your deployment. The good news is it doesn’t have to as long as the vCO workflows are built to support the intended result.
In the following walk-through I will be using the Custom vCenter Folders Extension to demonstrate what you can do to account for the Multi-Machine and Single Machine aspects of vCO workflows.