Caution: Articles written for technical not grammatical accuracy, If poor grammar offends you proceed with caution ;-)
Have you ever needed more control over what custom properties get assigned to specific component machines of a multi-machine blueprint, or want to use the same component blueprints for all component machine of a multi-machine blueprint? The Ultimate Multi-Machine Blueprint Extension aims to help with that.
The Ultimate Multi-Machine Blueprint Extension allows you to utilize the same source component blueprint for multiple component machines while at the same time controlling which custom propertied get assigned to each of the components. This allows you customize each of them differently during deployment.
This extension works well with the Custom Hostname and the Custom vCenter Folders extension to round out the use of Multi-Machine Blueprints.
Example Use Cases:
- Use a single machine blueprint for all components of a multi-tiered multi-machine blueprint and customize the name of each component.
- Use a single machine blueprint for all components of a multi-tiered multi-machine blueprint and customize the guest agent actions of each component machine.
- Use a single machine blueprint for all components of a multi-tiered multi-machine blueprint and override the template for each component to deploy from a different source vCenter template for each component.
The goal of this extension is to limit blueprint sprawl and leverage the multi-machine construct to customize the component machines and rely less on customizing the single machine blueprints making them more re-usable.
This extension was designed and built as a collective effort by Tom Bonanno and Sid Smith. If you have any feedback please let us know.
Features
- Define which component machines to apply custom properties to in a multi-machine blueprint.
- Utilize a singular blueprint for all component machines in a multi-machine blueprint.
Change Log
v1.0.2
- Fixed bug that caused properties with Multiple periods not to be processed properly.
v1.0.1
- Initial Release
Remember we have performed a large amount of testing, but this is a v1.0 extension so please test and let us know if you find any issues.
Download
Ultimate Multi-Machine Blueprints Extension
Installation
These installation instructions assume the following:
- You have a working vCenter Orchestrator in your environment.
- You have a working knowledge of administering vCO.
- The vCloud Automation Center 5.2 or 6.0 plugin for vCO has been installed, and a vCAC host has been added.
- You have the vCenter Orchestrator instance configured as an endpoint in vCAC.
- vCAC 5.2 or 6.0 is preconfigured with at least one working Blueprint. Two individual Blueprints and a Multi-Machine Service Blueprint are better in order to see the full functionality.
Installing the Ultimate Multi-Machine Blueprint Extension Package
- Launch the vCO Java client, switch to Design Mode.
- Go to the Packages Tab (Orange Square with White Circle)
- Click on the Import Packages icon in the upper left of the right pane. (Orange Circle w/ green arrow)
- Browse and select the com.dailyhypervisor.vcac.ultimateMMBlueprints.1.0.0.package file and click open.
- Click Import
- After vCO processes the package review the files being imported. Please make sure that the items being imported are selected if they are a newer version then the ones that may already exists in your vCO environment. If you have installed other modules published on dailyhypervisor please pay extra attention here. Some shared workflows and actions from the Custom Hostname & Active Directory OU Extensions are updated in this package. Make sure you update them to the latest version.
- Go to the Workflow tab then expand Dailyhypervisor –> vCAC –> Ultimatae Multi-Machine Blueprints –> Installation
- Run the Install Ultimate Multi-Machine Extension. When Prompted select the vcac IaaS server.
- Follow the instructions described by the workflow to download and install the external workflow XML file into vCAC. (Download the XML for each of the components and copy them on to the vCAC server under the vCAC install directory –> Server –> ExternalWorkflows –> xmldb).
Configuration
I’m going to make some additional assumptions. I assume that you will have:
- A Single Machine vCenter Blueprint already created.
- Other relevant vRA(vCAC) constructs such as Business Groups, Reservations, Network Profiles, Name Prefixes, etc already created and working.
For information on how to create these construct you can visit our vRA(vCAC) Walk-Through Page
In my initial use case I’m using the Custom Hostname extension to demonstrate the flexibility of this extension. In this scenario I will be using a singluar blueprint for all the components of my multi-machine which include an App Component, DB Component , and WEB Component. As a result I want to be able to name the provisioned machines based on their function. To do this we need to identify their intended function and apply the appropriate naming properties to the machines so they are properly named.
To start I have a build profile attached to my single machine blueprint that defined the custom hostname I would like to use, it is:
The {APP} portion will be used to differentiate the component machines and their functions. Normally I would have three blueprints one for each function and this property would be defined on each blueprint. With the Ultimate MM Blueprint extension this is no longer required.
In the image below you can see my multi-machine build information screen. You will notice in the blueprint column I have re-used the same blueprint for each, however I have given each of them a unique name. APPHOST, DBHOST, & WEBHOST. This is how we identify the components function. You can name them however you like, but these will become more important shortly. Each of these is also provisioned to a unique network which is a standard multi-machine blueprint feature, but I just wanted to demonstrate the end result.
I also have a build profile attached to my multi-machine service this defines the custom properties I want to assign to the component machine and their values. IT looks like the following:
Do you see the relationship. I append the property with the name I assigned the component vm. The property after the period can be any property. So if I wanted I could also have the following properties:
APPHOST.VirtualMachine.SoftwareN.ScriptPath – It’s relevant value
DBHOST.VirtualMachine.SoftwareN.ScriptPath – It’s relevant value
WEBHOST.VirtualMachine.SoftwareN.ScriptPath – It’s relevant value
In the end you can use whatever properties you want and target the components by simply appending “component_name.” before the property you would like to apply to the component machine. If you think about this it opens up the ability to customize your component machines to any degree you need.
Have you ever wanted to prompt the requester to input the hostname for each of the components manually? With this it becomes possible simply propmt the requester to input the name and assign it to APPHOST.Hotname, DBHOST.Hostname, & WEBHOST.Hostname. You would of course want to use the property dictionary to make the names more user friendly.
Finally you also need to define the following custom property to trigger the workflow to execute:
Property: UltimateMultiMachine.Execute Value: True
We hope this extension helps on your journey to more flexible multi-machine blueprints. Feel free to let us know how you are using it, we would love to hear the different use cases.
Hi,
This is awesome, good stuff all working for me without issue.
I can not seem to wrap my head around the link between the XML file that has the property for UltimateMultiMachine.Execute and the “entity”/”model” Exactly at what point can I see the link between this property and the workflow that would be executed?
The property that is in the XML file it what gets defined within the vRA UI as a custom property to tell vRA that it should execute the workflow.
Cool, that’s understood , but I feel like I am missing something else , since the xml file does not reference the workflow where / when / how does vco know which workflow to run
The XML references a workflow that is executed from within the IaaS repository. The IaaS Repository workflow is what actually calls the vRO workflow.
Firstly A BIG THANK YOU for the awesome work. This is really great.
I’ve used the custom hostname with great success. The vCenter Folders work well too (although I’d like to be able to use the requester short name to make a folder, maybe in the next release?)
My difficulty is with the Ultimate Multi-Machine Blueprint Extension. The APP variable is applied but it seems it is done AFTER the VM has been named.
e.g.
[2015-07-09 11:29:11.574] [I] DBHOST
[2015-07-09 11:29:11.581] [I] APP: DB
[2015-07-09 11:29:11.648] [I] Create property APP : DB on virtualMachine entity Devundefined002
The ‘undefined’ part of the name is where DB should be placed. i.e. {GRP}{APP}{###}
Any ideas? (vRA 6.6.2)
Thanks again for all the really great work
You can fix that. On the IaaS host under the folder C:Program Files (x86)VMwarevCACServerExternalWorkflowsxmldb there are xml files for both workflows. Inside the files there is a priority=”1″. You can change this so the UltimateMM has a priority of 1 and the custom hostname or vCenter folders has a priority higher that 1 such as 2 and it will work no problem.
Hi Sid & Tom,
Is it possible to give a custom name (specified at deployment) for each of the individual components?
For example, if I have 2 App servers, 2 Web servers and 2 DB servers, can I ask a user to specify a hostname to each of these servers? I am trying to follow the example above, but I’m not able to get it to work.
It doesn’t seem to be possible to do it out-of-the-box with vRA 6.2, since if I add a “Hostname” custom property to my single machine blueprints that are re-used in my multi-machine blueprint, I can only provision 1 machine of each type, probably since the vRA interface only asks me for 1 hostname per blueprint type.
Thanks!