There are multiple options for how vRealize Automation (vRA) 6.X can manage the hostnames of its provisioned machines. When you’re trying to figure out which one makes the most sense for your organization, understanding the 5 most common options is a great place to start. In this article, I’ll help you put these options into context by identifying the specific scenarios and challenges that each option is best suited to solve. We’ll also walk through their setups, so that you can try them out and get a good feel for each one.
In this article, we’ll cover the following options for managing hostnames with vRealize Automation:
- Machine Prefix feature
- “Hostname” custom property
- DailyHypervisor.com’s Custom Hostnaming Extension
- vRealize Orchestrator workflow
- Professional services
1. Built-in Machine Prefix feature
Ideal Scenarios
The out-of-the-box Machine Prefix feature is good for simple scenarios. It marries a single name string of your choosing to an auto-incrementing number of how ever many digits you specify.
Because Machine Prefixes can be attached to either Business Groups or Blueprints, they are a good fit for 2 basic scenarios:
- You have a 1:1 relationship between your Business Groups and your hostname formats
and/or - You have a 1:1 relationship between your Blueprints and your hostname formats
Let’s expand on that second bullet point just a bit. There’s an important scenario where a blueprint-based Machine Prefix can be a perfect fit: when you wish to reduce the amount of information that’s embedded within the hostname. I recently read a fun article on the diminishing usefulness of meaning-laden hostnames over at VMtoCloud.com. The concept is that with the advent of technologies like SRM, cross-vCenter vMotion, and now cross-cloud vMotion, any location or ownership information that’s embedded within a hostname can quickly become stale. Such stale information can cause big headaches, especially if it’s used to cue down-stream processes, like reporting, alerting, and more automation.
Given that changing a hostname is anything but trivial, one alternative is to move this important information into something much more dynamic and flexible, like vRA custom properties, or vSphere Tags (my personal favorite). Not only do you gain the ability to change and update the information, but it also gets you out of the business of fighting with complicated hostname schemes. If your vRA/IaaS initiative has considerable momentum or executive sponsorship, then now might be a great time to shake things up, and simplify how things are done.
Setup
To find your Machine Prefixes, start by going to the Infrastructure tab at the top of the screen. On the left-hand side, click Blueprints, and then Machine Prefixes
In the example screen above, you can see that I’ve created 3 Machine Prefixes. The first one uses a name string of “dev“ and then 4 numeric digits. If I provision a VM using this Machine Prefix, it will be named dev0001. If I provision another one, it will be named dev0002, and so on. If I need to start off the numbering at 100 because I already have dev0001-dev0099 in my existing environment, I can simply change the “Next Number” field to 100.
Every Business Group must have a default Machine Prefix. In the example below, I’ve assigned the “dev” Machine Prefix to the “Dev” Business Group.
Within a Blueprint, you also have the option of overriding the Machine Prefix from the user’s Business Group. In the screen below, clicking the dropdown arrow lets you choose an overriding Machine Prefix. For example, I might want to always use the “sles” Machine Prefix for this Blueprint.
2. Hostname Custom Property
Ideal Scenarios
This is another very simple option. It allows you to prompt the user to enter the hostname when they are requesting their item from the catalog. It is good for scenarios where the vRA users are trusted to make such decisions 😉 Since this option flies in the face of automation by introducing another human touch-point (and the inevitability of human error) I generally only recommend this option for lab environments.
Setup
The setup for this option, however, is dead simple. Just edit the Blueprint, add a property called “Hostname”, and be sure to check the “Prompt User” checkbox. That’s it!
And here’s how is looks to the requesting user:
3. DailyHypervisor.com’s Custom Hostnaming Extension
Ideal Scenarios
Since the 2 options we’ve discussed so far are fairly basic, one of the bloggers over at DailyHypervisor.com, Tom Bonanno, created an excellent vRA extension that can easily mirror the majority of the corporate naming standards you’re likely to run across. This option doesn’t require any scripting and can be setup in a matter of minutes. For as powerful as this option is, it is very simple to use.
Ideal for scenarios that require:
- Accommodating most corporate naming standards, where the hostname is comprised of codes for things like location, server type, OS, etc.
- Quick time to value (minutes).
- Cost efficiency (it’s free).
There are, however, a few considerations to keep in mind:
- It cannot accommodate every naming scenario. For something very unusual or complex, you may need to look elsewhere.
- There’s some inherent risk that we have to accept when we use community-based tools. For example, the author is single-threaded in terms of providing updates/fixes if unforeseen circumstances or new vRA versions should introduce an issue.
- You can’t call VMware Support for help/fixes.
If you’re OK with these considerations, then this option is very slick, and could be just what you need.
Setup
First off, you’ll need to make sure you’ve configured your vCAC plug-in within vRO. If you haven’t done so yet, or aren’t sure, here is a blog series from one of my colleagues that can walk you through it:
- http://extendingclouds.com/2013/12/18/vcac-vco-a-marriage-made-in-the-clouds/
- If you’re running the embedded vRO instance on the vRA 6.1/6.2 Appliance, you can skip running the “Add a vCAC host” workflow, as that is already done.
- If you’re running vRA 6.1/6.2, you’ll need to perform an additional step: Add an IaaS Host.
Once you’ve successfully configured vRO’s vCAC plug-in, you’re ready to install the DailyHyervisor.com extension. I won’t spend time re-inventing the wheel – the author of the extension, Tom, has already posted an install/config guide, HERE.
After you install it, you configure it by setting a few custom properties on various elements in vRA, like Blueprints, Business Groups, and Compute Resources. It automatically creates Machine Prefixes for the hostnames it generates, so you can manage the “Next Number” field just like we discussed above in the Setup section of Option 1.
4. vRealize Orchestrator Workflows
Ideal Scenarios
This option calls a vRealize Orchestrator (vRO) workflow during provisioning. The vRO workflow can then execute any logic you like in order to put together the hostname, which makes this option extremely flexible. In Part 2 of this article, I’ll show you how this option can accommodate the most common hostname scenarios, similar to the DailyHypervisor extension, as well as a couple examples of more-exotic scenarios.
Ideal for scenarios that require:
- Accommodating any naming standard, even if it’s unusual or very complex.
- Complete control of the code (since you’re the author!), including which updates and features get developed, and when.
- Cost efficiency (it’s free… well as free as your time is anyway).
And here’s what you need to keep in mind:
- Requires creating a vRO workflow, which includes some light JavaScript coding.
- You bear the responsibility for developing the workflow, maintaining it, and regression testing it with each new vRA release.
- You still can’t call VMware Support (unless you have VMware’s SDK Support).
Some of these caveats may not be as big of a deal as they first sound if your organization is already well down the path of automation (though not necessarily vRealize Automation ;-). If your team is already used to writing a lot of scripts, then these “caveats” are probably old news.
Setup
I wanted to include 3 different scenarios here, to illustrate just how much flexibility this option can provide. When I started writing down the setup of all 3, however, I realized they needed their own article. To that end, you may follow this link:
Manage Hostnames with vRealize Automation – Part 2: Use a small vRO workflow
Here are the 3 example scenarios we’ll setup in Part 2:
- Example A – Typical hostname scenarios
- This example is very similar to the DailyHypervisor functionality, described previously. Hostnames will be comprised of codes for things like location, server type, OS, etc. We’ll store the values for these codes in custom properties on various elements in vRA, like Blueprints and Compute Resources. The end of the hostname will be some number of digits for an auto-incrementing number.
- Example B – Hostname includes a portion of the IP address
- Same as Example A, but instead of an auto-incrementing number, we’ll use the 3rd and 4th octets of the provisioned VM’s IP address.
- Example C – Hostnames are already pre-created in DNS
- After vRA assigns the provisioned machine an IP address, the workflow then looks up the corresponding hostname from DNS, and assigns it to the machine.
5. Professional Services
Ideal Scenarios
Professional services can be a great option if your organization has some of the requirements described in the previous 2 options, but find one or more of their caveats to be showstoppers.
Ideal for scenarios that require:
- Accommodating any naming standard, even if it’s unusual or complex.
- Quick time to value. If you work with VMware or with a VMware partner that does a lot of this type of work, hostname customization should be no problem. Often, I see customers jump-start their automation efforts by having professional services knock out a handful of common integrations, like hostnames and IPAM.
- Robust automation that incorporates lessons learned from performing similar engagements for numerous other customers.
- The option to call a support organization for help/fixes, be it VMware Support (when using VMware Professional Services), or that of your VMware partner.
To expand on that last bullet point, if you need a custom hostname solution that is supported by VMware Support, then you’ll need to contact VMware’s Professional Services.
Weigh Your Options
While I would love to simply point you to “the best” vRA hostname option, each organization’s needs are unique, and each option has its place. After reading this article, if the right one for your organization isn’t jumping out at you, then go ahead and try them out – actually working through their setup steps and playing with each option’s capabilities will give you a rich context in which to determine the factors that matter the most to you.
Have fun automating and best of luck as you weigh your options!
