This package is for using with the vCenter Orchestrator plug-in for vCloud Director 5.1
vCenter Orchestrator (vCO) provides a large library of workflows and actions out of the box. This library grows with each new plugin that gets installed. As a result, it becomes easier to build very powerful workflows with little to no knowledge of an API. This document will focus on a custom workflow built using library items and additional scripting.
The overall goal of the Custom Deploy vApp workflow is to provide a single call workflow that is capable of instantiating a vApp Template from vCloud Director (vCD) and performing a number of operations on the resulting vApp before actually deploying and powering it on. The workflow is intended to be an example and starting point for deployments that require any or all of these features. It can also be called via 3rd party connectors using the SOAP API.
These operations include:
- Check Org for vApp name already existing in any vDCs, if so append number until unique
- Instantiate, but do not deploy or power on immediately
- Apply custom naming convention to each VM in the vApp
- Base VM name on vApp name
- Customize the Guest OS Customization script
- Specify IP for VM
- Create Computer Account in specific OU of Active Directory
- Add specified domain\user to local administrators group
- Connect VM to Network
- Change Hard Disk Size
- Add extra Disk to VM
- Modify the VM CPU count
- Modify the VM Memory
- Deploy vApp
The package and custom workflow requires a functional vCO server with the vCloud Director 5.1 plugin installed and configured. Additionally, the Active Directory plugin should be installed and configured to facilitate the Computer Account creation in AD. A functional vCD environment should be available with 1 or more vApp Templates containing at least one Windows VM. All of which should be configured as discussed throughout this document. (Note: step-by-Step installation/configuration is out of scope here)
While this workflow has been developed and tested successfully, it should always be executed and tested using the vCO Client before attempting to call via the SOAP API. This allows for determining appropriate inputs and faster troubleshooting. Once the workflow has completed successfully in the target environment, it is safe to begin integration with other systems.
Prepare for use:
- Enable domain join for virtual machines in the organization you plan to use this workflow (If you wish to take advantage of the feature that pre-creates a computer account in the domain as well as adding a domain user to the local administrators group)
- Add the following the the Guest OS Customization Script for a Windows vAppTemplate VM: (this will allow for the addition of the specified domain user account to the local administrators group. Note the use of variables @domain@ and @username@ - vCO will replace these during the workflow)
if '%1%' == 'postcustomization' (net localgroup administrators @domain@\\@username@ /add)
- Confirm you have a network with access to the domain. Specify that network when deploying a Windows VM with this workflow
- REVIEW the code inside the GREEN Scriptable task objects to make adjustments as needed: "VM Customization" and "Set Custom IP"
All of my tests with this workflow were centered around deploying a Windows 2008 R2 64-bit VM to a network, adding it to a domain. Inside the "VM Customization" Scriptable task is a section of code that allows you to specify your own modifications for Linux based customization scripts if needed.
The implementation of the workflows is documented in the vCAT 3.0 Workflow Examples Document
Disclaimer: These samples workflows are provided AS IS and are not considered production quality and are not officially Supported. Use at your own risk. Feel free to modify and expand and share your contributions.