vRealize Automation – vCAC 6.1 – Custom vCenter Folder Extension
Overview vCAC by default will place all provisioned machines into a vCenter folder named VRM. You can override this using the custom property VMware.Virtua
From the archive. Originally published on dailyhypervisor.com on November 12, 2014.
Overview
vCAC by default will place all provisioned machines into a vCenter folder named VRM. You can override this using the custom property VMware.VirtualCenter.Folder to tell vCAC where to place the provisioned machine. While this is great that you can tell vCAC where to place the provisioned machine it isn’t very flexible. I built the Custom vCenter Folder Extension to fix that and make folder placement as flexible as you need it to be. VM folder placement is just about organizing virtual machines. It provides a way to control access to these machines through vCenter as well. Many organizations control permissions to these environments using these folders and need to be able to place any machine where they need for these purposes.
Multi-Machine blueprints is another area where this extension adds value. You can control placement of virtual machines by defining the VMware.VirtualCenter.Folder property on a Multi-Machine blueprint folder, but all VM’s for all Multi-Machine apps are placed in the same folder creating confusion as to which VM’s belong to which Multi-Machine application. Now if you add NSX into the mix and you have Multi-Machine components spread all over the place with no way to easily determine which VM’s as well as NSX Edges go to which application.
When used with Multi-Machine blueprints the Custom vCEnter Folder Extension can place all component Virtual Machines as well as Deployed NSX Edge appliances in a folder named after the Multi-Machine application if you desire making it easy to identify related components of an application. This also allows you to easily permission vCenter access to the components of the application if necessary.
Features
- Dynamic Folder Names based on custom naming scheme
- Multi-Machine folder placement including NSX Edge applince
- Automatic Multi-Machine folder removal when Multi-Machine app is destroyed
Change Log
v1.0.1
- Initial Release
Download
vCAC Custom vCenter Folder 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 Custom vCenter Folder 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.customfolders.1.0.1.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 –> Custom vCenter Folder –> Installation
- Run the Install Custom vCenter Folder Extension workflow. 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 for all three components. (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
Once the installation is complete you will need to do some configuration in vCAC to be ready to use the extension. To start there are two custom properties that you will need to configure.
- In vCAC go to Infrastructure –> Blueprints –> Build Profiles. Select New Build Profile.
- When the New Build Profile dialog opens input a Name the select DHCustomvCenterFolders from the Add from property set and click Load. After you click load two custom properties will be loaded.
Custom.vCenterFolder.Execute – This property value is set to True. The property is what triggers the workflow to run.
Custom.vCenterFolder.Scheme – This property defines the folder structure you would like to use. If you have used the custom hostname or AD OU extension you will be familiar with this. You will need to define the scheme in the following format:
\{Top Level Folder}\{Next Level Folder}\{So forth and so on} - If you are using this with a Multi-Machine blueprint you can also add {ParentMultiMachineName} as a special item. This will use the name of the Multi-machine service as a folder name.
An Example use of this would be:
\{Group}\{LOC}\{CLUS}\{ParentMultiMachineName}
In this example I would need to define a custom property for each of the items in the {}. For these I would create a custom property on the Business Group and the property name would be “Group” and the value might be Production. Then I would create a property named “LOC” on the vCenter endpoint with a a value of MDT for the location. Then I would create a property named CLUS on the Compute resource named Services. When I deploy a machine the folder would be:
\Production\MDT\Services\MMName
The deployed VM’s would be placed in this folder. For Multi-Machine blueprints all component machines would be placed in the fold with the MMName. If NSX is in use the NSX Edge would also be placed in this folder. You can create whatever structure you like and place the properties wherever you like to get the intended result you are looking for. The workflow an determine if you are using it on a single machine or a Multi-Machine blueprint. You will need to enable the Build Profile on the Blueprints you would like to apply it to. You can have multiple folder schemes that get applied to different blueprints.
Because of the nature of vCAC you can apply a Multi-Machine folder scheme on a Multi-Machine Blueprint that includes the [ParentMultiMachineName} item while also having folder schemes on the component machines that so not. When the standard virtual machines are used as part of a Multi-Machine blueprint the Multi-Machine blueprint scheme will override the scheme defined on the component machines.
In the below image I have Multi-Machine Component machines deployed to \Cloud Services\MDT\Services\MMName. You will also notice that two of the Multi-Machine blueprints used NSX and one did not.
When using the {ParentMultiMachineName} item the folder for the Multi-Machine app will be removed when the Multi-Machine app is destroyed. Below is the basic flow for the extension.
BuildingMachine
During the BuildingMachine state a determination is made as to what the folder structure should be and is written back to the machine request using the VMware.VirtualCenter.Folder property. vCAC then creates the folder during the CloneMachine state using the Set custom vCenter Folder Name vCO workflow.
MachineProvisioned
During the MachineProvisioned state the NSX Edge appliance is moved to the Multi-Machine folder if NSX is configured for the Multi-Machine Blueprint using the Move NSX Edge to MM Custom Folder vCO workflow.
MachineDestroyed
During the MachineDestroyed state the Multi-Machine folder is removed using the Remove custom vCenter Folder vCO workflow.