vRA 8.8 Custom Names

Last modified date

With the release of vRA 8.8 you can now make use of Custom Names by enabling this feature through the UI. I have written before about vRA Custom Names since the release of version 8.6.1. However, in that version the Custom Names feature was hidden and could only be enabled with some API reverse engineering (hence I had to temporarily remove the [blogpost]).

Before you do this in your production environment, please note that depending on your choices, no custom naming is configured for any existing project. I suggest thinking this through before enabling the new feature and do some testing in your lab first.

To deploy or upgrade to vRA 8.8, you have to update vRSLCM to 8.8 first.

Enable Custom Names

To enable the new Custom Names option, go to Infrastructure, Custom Names

Click on the [Learn More] button to read the official documentation before proceeding.

Click Enroll Now to continue. In the next screen you can choose whether or not to migrate custom naming templates from other any projects.

The Do not migrate method is recommended because the project and resource-level improvements are significant. To take advantages of the changes, you must build new custom naming templates.

The Migrate method creates one template for each project that has a template. Depending on the number of projects with templates, migration might result in many templates to manage. It is also possible that some templates fail to migrate due to unsupported formats. Migration is not guaranteed for all the naming templates. Migration can result in an unmanageable number of project-level templates.

Based on the above and my environment, I chose “Do not migrate”

After Custom Naming Enrollment was successful, you are congratulated and get a thumbs up.

As stated in the beginning; If you check one of your projects and go to Custom Naming, you will notice there is no Custom Naming found / configured.

2.       Naming Convention

First let’s have a look at my naming convention which looks like this:

<Physical/virtual><Guest OS><Environment><Servertype><LocationCode><####>, where

Physical/virtual 
pphysical server
vvirtual Server
Guest OS 
lLinux
wWindows
Environment 
dDevelopment
tTest
aAcceptance
pProduction
Servertype 
aapplication
ddatabase
ggeneric
Iinfra
wweb
Location code 
010Rotterdam
020Amsterdam
030Utrecht
070Den Haag
####<Random Generated Number>

An example hostname could be vldg0100002 where:
v              virtual server
l               linux
d             development
g              generic
010         location code
0002       random generated number

Within my cloud template the v for virtual and l for Linux are defined statically. The other elements of the resource name are selected at deployment time by making use of a Property Group called “pgDeploy” (See below).

Without the new Custom Names feature the random generated number would continue to add up, no matter what Environment, Location or serverType you chose during deployment. If you had network resources in your blueprint, this would also make use of the same random number generator.

With Custom Names, you can now define Naming Templates and add Matching Patterns so every combination of elements can have their own starting number. For example, a web- or application server each has its own (start)numbering and can also be independent of the chosen location.

Cloud template

In my Cloud template I have created a property called name under the vSphere Machine resource, combining all the input properties to create the main part of the name. The random numbering will be added through the custom naming feature.

VM:
  type: Cloud.vSphere.Machine
  properties:
    name: vl${input.pgDeploy.vmEnvironment + input.pgDeploy.vmServertype + input.pgDeploy.vmLocationcode}

I did not configure anything specific for the network Resource

From the above Cloud Template snippet, you can see that I am using a Property Group called “pgDeploy”. More on that below.

The full Cloud Template can be found on my [github].

Property Group “pgDeploy”

I have created a Property Group “pgDeploy” of type “Input Values”, available for any project with the following Properties:

NameDisplay NameTypeDefault Value
vmServertypeServertypestring 
vmEnvironmentEnvironmentstring 
vmLocationcodeLocationstring 

The vmServerType Property is a Key Value Pair based on the naming convention described above.

The vmEnvironment Property is a Key Value Pair based on the naming convention described above.

The vmLocationcode Property is a Key Value Pair based on the naming convention described above.

4.       Create Custom Name and Naming Templates

With the above information, it is finally time to configure the Custom Naming!
Go to Infrastructure, Custom Names and Click “New Custom Name”

In my example I have chosen to create an Organization Custom Name, but if you have some special requirements, you can also create a project based Custom Name. The differences are as follows:

Organization: Create a default naming template that is applied to all deployments that do not have a project-level naming template.You cannot create more than one organization template. If the organization scope is not available, one already exists.

Projects: Create a naming template specific to the assigned projects. If both an organization and a project template exist, the project naming template takes precedence over the organization template.

Click New Naming Template. You will notice you can select different resource types:

  • Machine
  • Network
  • Storage
  • Load Balancer
  • Gateway
  • NAT
  • Security Group

For all these Resource Types you can setup custom naming, including their own Starting counter value and increment step. Next to that you can define matching patterns to configure unique numbering within each resource type.

I have configured a Naming Template for Machine and Network. For the Machine Resource Type, I chose ${resource.name}${####} where the ${resource.name} variable is configured in the cloud template as described above.

Based on my naming convention, I have created different matching patterns that will allow for a unique numbering for every combination of elements. This list can grow quite larger if you have a complex naming convention and the screenshot does not contain all possible combinations.

Note that you cannot change the Template format after it has been created, nor the Pattern Text, but you can add and remove matching patterns afterwards.

The final result under Custom Names looks as follows:

Deployment.

Currently I have the following deployments

For my new deployment I chose the following deployment inputs:

The first new deployments did not have any problem, but later I ran into some issues where the name was already in use (0004 to 0008).

As far as I know you cannot change the starting Counter Value if you have already created a Matching Pattern. As a workaround you can delete the matching pattern and create a new one with a higher starting Counter value.

You can also have a look at your project to see what Custom Naming is used.

If you click on the >> Icon you can have a closer look at the Template Format and Current Counter Value.

I hope everyone is happy with this new feature and this blogpost helped you getting started!
A last tip to end this blog: even though there are a lot of possibilities with this new feature, I would advise to keep your naming convention as straight forward as possible and not make it too complex.


Henk Engelsman

2 Responses

  1. Hello,

    Thank you very much for this great example.

    Do you have any recommendation how to handle this additional requirement:
    – Some projects need additional “vmServerType” values.
    – If possible, no custom cloud templates for these specific projects to “only” match Naming requirement

    I am looking forward to your reply.

    Best Wishes
    Markus