Caution: Articles written for technical not grammatical accuracy, If poor grammar offends you proceed with caution ;-)
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 utilized 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.
I love the packages you have built they are great and the first thing i wanted to say was thank you for all of the work.
First question, I was just wondering in the custom host name package i can use the {usr} to add the user id to the host name. Is there any way to do that with the custom folder name? What I am trying to do is basically /Portal/{Group}/{user} (i.e. /Portal/Telecom/jgrifith ). This would make it very easy to track ownership at a glance in vcenter.
Second question is there and way to actually pick the users provisioning group without have to have an additional property. You would think the group the server is being ordered under is naturally part of the request.
Awesome!!! Was looking for this type of solution for months… Worked first time! You rock!
Very nice package!! I have one issue though. Im using it in vRA 6.2 on a MM with 2 machines. The first machine is moved into the {ParentMultiMachineName} the other is dropped one level above that. I can see that it gets a “Folder already exists” error in vCenter on the second machine.
Have you come across this?
I haven’t. What version of vRA are you running it on?
Running vRA 6.2…i have seen this a couple of times (not consistantly). Where the 2 first VM’s in a MM blueprint are created “at the same time”. They both starte the create folder and one of them fails, ending up in the parent folder not in the {ParentMultiMachineName} folder.
(Download the XML for each of the components and copy them on to the vCAC server under the vCAC install directory –> Server –> ExternalWorkflows –> xmldb). —– I’m missing something because I cannot find the location to drop the XML files on my vRA 6.2 appliance.
The location is on the IaaS windows host, not on the vRA Appliance.
First of all. This is a great extension, exactly what I was looking for. Will make my demos much more impact-full.
It works fine in my environment, except the part that is supposed to move my NSX Edge devices in a specific folder.
The Workflow “Move NSX Edge to MM Custom Folder” fails at “Move virtual machines to folder”. The reason seems to be that the Action Element before “LookupVmFolder” always returns a NULL value and subsequently I get
“TypeError: Cannot call method “moveIntoFolder_Task” of null.”
Am I missing something? Has anybody seen this before?
I am using vRA 6.2,1, ext. vRO 6.0.1, vRA Plug-in 6.2.1, vSphere 5.5 (yet)
Thanks,
Jurgen
It seems there are some changes to some of the OOB workflow sin vCO. We will be testing and updating the extensions we have posted, stay tuned for more info.
I saw this behaviour, turned out that I hadn’t configured the vCenter plugin for vCO…
Nice workflow! But does this workflow work correct for vRA 6.2 with vCO 6.0? Because when I add the 2 properties to the MMblueprint and I request the MMblueprint. I see for each of the underlaying blueprint + the MMblueprint himself a Set custom VCenter Folder Name job (no errors). But no folder in vCenter is made.
The MMblueprint Set custom VCenter Folder Name job ends in the lowest End workflow Schema. And all the jobs from the blueprints ends in the most right End workflow Schema. Any idea what the problem may be?
It seems that some dependent workflows may have changed. I have heard from a few others regarding this workflow and some others on vRA 6.2 having issues. I am going to check into it and get them fixed up soon, just haven’t had the time to dig into it.
I’m having problems getting the move NSX Edge and Remove Folder workflows to run. The naming of the custom folder works fine, but I never see the other two workflows get called during the provisioning and de-provisioning process. I’ve re-run the install workflow a few times and have removed and re-added the XML files, but nothing seems to make a difference. Any ideas?
Any Updates on the NSX Edge placement ?
Hi Sid.
have you had the chance to look in to this ?
Sorry I have not. I will take a look at it within the next 1-2 days sorry for all the delayed responses.
For me this workflow works fine with vRA 6.2.2. After introducing this workflow into our cloud team:) asap the architects ask me if it is possible to dynamically put vm’s into the folder stucture:
/tenant/bussinessGroup/{multiblueprint}.
ATM I’ve tried it with the follow script but without the right results:
vcFolder = {multiblueprint}
____________________________________________________
var CRs = Server.findAllForType(“VCACCAFE:CatalogResource”);
Loop:
for each (CR in CRs){
if(CR.name == vcFolder){
var vcacCafeInfoString = CR.organization;
break Loop;
}
}
var tenant = CR.Organization.toString();
System.log(tenant);
var posi = tenant.search(“Tenant: “);
var posf = tenant.search(“,”);
var tenantName = tenant.substring(posi+8,posf);
System.log(tenantName);
var posi = tenant.search(“Business group: “);
var businessName = tenant.substring(posi+16);
businessName = businessName.replace(/ /g, “_”);
System.log(businessName);
vcTenant = tenantName + “\” + businessName
____________________________________________________
Is there a other why to get this done? So i can make my team again happy with the news that is it possible to dynamically put VM’s into the folder structure: /tenant/BG/
Thanks Robert
Robert,
Are you trying to place single machine deployments in with the multi-machine or additional Multi-Machine component VM’s(It handles additional component machines or it should 😉 Can you run me through the use case in a bit more detail and I will see what I can do.
-Sid
Hey Sid,
First thanks x100 for the fast reply and for the help:)
The vRA of our company offers some different tenants like: dev1, devAPP, prePRD, prd etc. Some “huge” tenants have some BG’s to logical separation between for example VM importance.
So blueprints/Multi blueprints can be shared cross BG’s within the same tenant. One of our biggest problem was the fact that in vCenter all the vRA VM’s were deployed in the VRM folder until I introducted your customer vcenter workflow. It helps us a lot in the first place for making vcenter a bit more manageable. Certainly the {multiblueprint} option. But now the IT architect asking me if it is possible to use the vRA logical separation between tenants and BG’s also in the vcenter folder structure.
For example
So if someone request a blueprint in tenant: devAPP, BG: Windows. The vcenter folder path will be /devAPP/Windows/%VM%
Same blueprint in the BG: playground. The vcenter folder path will /devAPP/playground/%VM%
If he request a Multi blueprints in tenant: devAPP, BG BigData. The vcenter folder path will be /devAPP/BigData/{multiblueprint}/%VM%
What I try to do is to build this into your workflow: Set custom vCenter Folder Name.A nice part of your workflow is when a BG is new and the folder isnt in vCenter it will be automated be made by the creation of the VM.
I hope this explanation is readable.
Robert
So this is very possible. Because you can define properties to be used as a portion of the folder path you could essentially define a {tenant} component and then define that property under the tenant on an object that is tenant specific such as business groups.
yeaahh thanks done! 🙂
Hi Sid, I have installed vRA 7.0 and thought that I would try using your Custom Hostname extension. The script runs through to where it runs the ‘Read an IaaS entity by custom filter’ workflow element and fails with the following error: Error in (Workflow:Read an IaaS entity by custom filter / Read entity (item1)#0) read operations are not allowed for model name ‘ManagementModelEntities.svc’ and entity set name ‘PropertySetXml’
I appreciate vRA 7.0 has just been release, however would appreciate if you had any idea of what is causing this error.
I have managed to resolve this error. It appears that VMware has once again changed the way that thinks work in vRA 7.0. It would have helped if I had read all the documentation!!!! If you read the following document it states that there are now restricted actions, and if you need to use any of the restricted actions you need to modify the operations.properties file located under the Resources tab within the vRO client under the Design view. http://pubs.vmware.com/vra-70/topic/com.vmware.ICbase/PDF/using-vra-plugin-70-guide.pdf
To get the package to work I had to remove the create, read and update entries.
Hope this helps others that may run into this problem.
Sid
We have been using the custom Hostname Package for over a year and it has been working great. Recently we tried using Custom vCenter Folder Extension and it works, but it changes the order of executing of workflows. We have a building stub workflow in our VCAC and we need both workflows (Hostname & vCenter folder) to execute before it kicks off. The Hostname workflow was kicking off before the build stub, but after we added the vCenter folder extensions both workflows kickoff after the building stub which requires the Hostname. Not sure what controls this, but is there a way to set it so the workflows execute before the building stub?
Yes you have to edit the xaml file and change the priorities for the workflows. This only applies to vra 6.x and earlier. The vaml files are located on the IaaS host and there are specific ones for each of the workflow. They are currently both set to a priority of 1 and you will need to make the xaml for the folders workflow to a priority of 2. The folder where the xamls are located is at:
c:Program Files(x86)VMwarevCACServerExternalWorkflowsxmldb
Sid, in a vRA 7 environment do I need to create the subscriptions for these workflows so the package works? I ran the installation workflow and created the properties in a blueprint, but the vRA are never calling the vRO workflows.
This workflow is for vCAC 6.1. For a 7.x version please look here https://developercenter.vmware.com/samples?id=973
i have a query. If we look at the workflow “Move NSX Edge to MM Custom Folder” and under schema scriptable task “Get Folder Path Pro” i see below script.
nsxFolder = vmProps.get(“Custom.nsx.Folder”);
System.log(nsxFolder);
shouldn’t Custom.nsx.Folder be replaced by Custom.nsxFolder ??