Customizing Naming Conventions

About service naming

There are several ways to specify names for deployed VMs, virtual services and stacks in vCommander. The complete list, in order of precedence, is as follows:

  • The name specified during manual deployment of a VM or virtual service (text replacement rules are not used in this case)
  • The name specified with the $VMNAME$ deployment parameter by an approval workflow script, or by an approver through the approval comments. If $VMNAME$ is specified more than once, the first occurrence is used.
  • The name specified by a requester on the New Service Request form (text replacement rules are not used in this case)
  • The deployed name of the VM or virtual service specified in the Service Catalog. You can specify distinct VM names for each service catalog entry.
  • The naming convention specified in Global Provisioning Configuration, as explained in this topic

The Virtual Service naming convention applies to AWS stacks as well.

Customizing the global naming convention

Access through:

Configuration menu > Service Request Configuration > Provisioning Configuration tab > Global Provisioning Configuration

Available to:

vCommander role of Superuser

Before you customize the global naming convention:

  • Make sure that any required custom attributes are set. One or more custom attributes can be part of the name. For example, if you want to include a location in the name, create "Location" as a custom attribute.
  • If required, set up text replacement rules for any custom attributes or variables.

Azure has strict rules for VM names. If you're deploying Azure services, to prevent automated deployment failure, you must ensure that your naming convention adheres to these rules. VM names must be between 3 and 15 characters, must contain only letters, numbers and hyphens, must start and end with a letter or a number, and must not contain spaces. The default VM naming convention in new installations of vCommander adheres to these rules.

To customize the name that is applied to a new VM, virtual service or stack when it's deployed:

  1. Go to Configuration > Service Request Configuration > Provisioning Configuration tab.
  2. Under Global Provisioning Configuration, enter a string under New VMs or New Virtual Services, using the syntax example shown in the next section.
  3. By default, when you use the #{uniqueNumber[*]} variable to generate unique names, names are unique within the parent element. If you want names to be unique across all managed systems, choose Globally from the menu. For more details, see Determining the scope for unique names below.
  4. Click Save.

Syntax example: Adding custom attribute values to VM names

Use a combination of text and supported variables to construct your naming conventions. The following example uses three variables plus text separators:

#{target.customAttribute['Location']}-#{target.customAttribute['Division']}-VM#{uniqueNumber[3]}

where:

This example would produce a VM name like the following:

Ottawa-Development-VM001

If a variable value contains spaces (such as the location New York), enclose the entire variable in double quotation marks:

"#{target.customAttribute['Location']}"-#{target.customAttribute['Division']}-VM#{uniqueNumber[3]}

It's helpful to add text separators such as "-" or "VM" to improve readability.

Setting up text replacement rules for service names

Access through:

Configuration menu > Service Request Configuration > Provisioning Configuration tab > Global Provisioning Configuration

Available to:

vCommander role of Superuser

When you create custom naming conventions for deployed VMs, virtual services and stacks, the names can become very long. You can set up rules that will allow vCommander to replace custom attribute values or variables.

For example, if you configure automatic VM names with the following format:

VM-#{target.guestOS}-#{uniqueNumber[3]}

Your VM names might look like this:

VM-Microsoft Windows Server 2008 R2 (64-bit)-001

Use text replacement rules to shorten your VM names.

Text replacement rules are applied to individual properties and not to the full name.

  1. Click Configure text replacement rules.
  2. In the Text Replacement Rules dialog, specify whether you want text substitution to replace an entire text string or a partial text string.

    The order of the text rules is important because they are applied in sequential order. After a text replacement string has been found for a particular property value, no other replacements will be considered. That means, for example, that if you want a complete text string to be replaced, you should configure "Equals" rules before "Contains" rules to ensure that the full text string is replaced.

    text_repl_dropdown

  3. Enter the text for the string and its replacement and click Add.

    The rule with its details appears in the list. If you have multiple rules, you can adjust the order in which they're applied.

  4. Click OK.

Example: Using a short form of the Guest OS in VM names

Here's an example naming convention that inserts the Guest OS into the VM name:

VM-#{target.guestOS}-#{uniqueNumber[3]}

With this naming convention, your VM names would look like this:

VM-Microsoft Windows Server 2008 R2 (64-bit)-001

You can shorten this with text replacement rules.

Click Configure global text replacement rules, and enter the full name of a Guest OS in the first text field.

In the second text field, enter a short version of the guest OS name.

Text Replacement Rules

Now, your VM names would look like this:

VM-Win2008R2-001

Example: Adding the datacenter and host to VM names

This example naming convention includes the datacenter and host name:

#{target.datacenter.name}-#{target.host.name}-#{uniqueNumber[4]}

This example appends a four-digit unique number to the VM name.

Again, as shown in the previous example, you can use text variables to shorten the datacenter and host names.

Using the uniqueNumber variable to create unique service names

vCommander's unique numbering is configurable to the number of digits you set, so that vCommander can do pattern-matching of existing naming conventions and continue to increment them forward. Once the limit is hit, no further names can be added unless you add additional digits to the unique numbering, or otherwise change the naming convention vCommander uses. vCommander won't cycle back and fill in the gaps with any unique names that have not been used.

For example, if you have set your default naming convention to be ACME-VM#{uniqueNumber[3]} and you already have a VM named ACME-VM046, the first VM vCommander deploys that uses automatic naming will be deployed as ACME-VM047. When you reach ACME-VM999, no further names will be available for use, unless you change the naming convention.

Determining the scope for unique names

When you use the #{uniqueNumber[*]} variable to create unique VM and virtual service names, names can be unique either within the parent element, or globally across all managed systems.

When you specify that VM and virtual service names must be unique within the parent element, the following rules apply:

  • For vCenter, names will be unique within the target deployment folder. For VM children of a virtual service, the parent element is the virtual service.
  • For SCVMM, names will be unique on the target host. If a host is configured to be highly available, VM names will be unique across all hosts in the cluster.
  • For public cloud managed systems, names will be unique in the target region per account.

When you specify that names must be unique globally, the names of all new VMs and virtual services deployed in vCommander will be unique across all managed systems; names are not reused (with the exception of Unmanaged VM names). Globally unique names are useful if you add computer objects to your directory service when new VMs are deployed, for example, or if you use VM names to generate host names.

Using variables in the global naming convention for services

You can use variables in the global naming convention for VMs, virtual services and stacks.

global-naming

Notes:

  • You can't use any variables when customizing a VM or virtual service name during manual deployment.
  • VM and virtual service names are not dynamically updated to reflect infrastructure changes. For example, let's say you used #{target.datacenter.name} in the naming convention. If the name of the datacenter changes or the VM is moved to a different datacenter after the VM is provisioned, the VM name isn't updated.
  • Dates returned by variables are of the form yyyy/mm/dd hh:mm:ss.
  • Clicking vars-20x20 in any text field that supports variables opens the Variable Assistant, which allows you to select variables for the current context and provides help for each variable. The most commonly used variables are provided in the Variable Assistant, but other variables are available. If you need to provide other information in the naming convention, contact Customer Support for assistance.

Using variables in deployed component and service names in the Service Catalog

When you create a service catalog entry, you can use the global naming convention, or you can customize the name for the deployed components and the deployed service. You can use a specific set of variables in the deployed name.

Clicking vars-20x20 in any text field that supports variables opens the Variable Assistant, which allows you to select variables for the current context and provides help for each variable.

You can customize the deployed name for a service component on the page for each service component, as shown here:

Add Service page

You can customize the name for the deployed service on the Deployment page of the wizard, as shown here:

deployed-name-serv-var

Notes:

  • You can't use any variables when customizing the service name during manual deployment.
  • VM and virtual service names are not dynamically updated to reflect infrastructure changes. For example, let's say you used #{target.datacenter.name} in the deployed VM name. If the name of the datacenter changes or the VM is moved to a different datacenter after the VM is provisioned, the VM name isn't updated.
  • Dates returned by variables are of the form yyyy/mm/dd hh:mm:ss.