Customize Naming Conventions

There are several ways to specify names for deployed VMs, virtual services, resource groups, and application stacks in Commander.

Order of precedence for deployed service names

The order of precedence for ways to assign deployed names to services 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 (see Add workflow steps), or by an approver through the approval comments (see Approve or reject service requests).
• The name specified by a requester on the New Service Request form (text replacement rules aren't used in this case). For more information, see Service Request Form Elements.
• The deployed name of the VM or virtual service specified in the service catalog blueprint. You can specify distinct names for each component in a published service.
• The naming convention specified in Global Provisioning Configuration, as explained in this topic.

The Virtual Service naming convention applies to application stacks deployed to public clouds as well.

Public cloud naming restrictions

To prevent automated deployment failure, your naming conventions must adhere to public cloud naming restrictions.

Customize the global naming convention

You can customize the global naming convention which will determine the name that's applied to a newly deployed VMs, virtual services, or application stacks.

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.
• Make sure you're aware of public cloud naming restrictions. See Public cloud naming restrictions.

1. Click the Provisioning 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 cloud accounts, choose Globally from the menu. For more details, see Determine 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:

where:

• Location and Division are custom attributes that we have already created and added as required fields on the service request form (see Service Request Form Elements). Note that custom attribute values must be enclosed with single quotation marks (' ').
• #{uniqueNumber[3]} is a variable that identifies the VM with a unique three-digit number. See also Use the uniqueNumber variable to create unique service names below.

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:

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

Set up text replacement rules for service names

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

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

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.

To set up text replacement rules for service names:

1. Click the Provisioning tab.
2. In the Global Provisioning Configuration section, click Configure text replacement rules.
3. 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, 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.

4. 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.

5. 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.

To use a short form of the Guest OS in VM names:

1. Click Configure global text replacement rules, and enter the full name of a Guest OS in the first text field.
2. In the second text field, enter a short version of the guest OS name, and click Add.
3. Repeat steps 1 and 2 for each Guest OS name you want to shorten, then click OK.

Now, your VM names will be shortened. For example, the name for a VM for a Microsoft Windows Server 2008 R2 (64-bit) 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:

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.

Use the uniqueNumber variable to create unique service names

Commander's unique numbering is configurable to the number of digits you set, so that Commander 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 Commander uses. Commander 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 Commander 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.

Determine 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 cloud accounts.

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 accounts, 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 Commander will be unique across all cloud accounts; 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.

Use variables in the global naming convention for services

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

• 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.

Use 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.

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

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

• If you use multiple naming variables for the deployed name in templates for services and components, the deployment will fail if the naming format exceeds 2048 characters.
• 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.