I was recently confronted with a customer concern that AWS instances that we provisioned from vRA did not accurately reflect the dynamically generated custom hostname they were assigned. When one of the sys admins issued the hostname command at the instance’s shell, they noticed the vSphere template name the AMI was produced from get returned and not the custom hostname. I had to admit how much of an oversight this was because I have paid attention to and even cared about what hostname appears inside of an AWS instance about as many times as I’ve desired to hear about or watch anything regarding the Kardashians. The answer to this is absolutely never if you even had to wonder. Despite this, the client pays the bills and saw this omission as a matter of extreme importance. Time to wave the consultant magic wand and make the impossible possible.
I considered the obvious use of custom properties in vRA to pass the dynamically generated hostname to the guest using a software component, however no property contained the custom hostname at provisioning time. I could have passed the hostname using a vRO workflow, however passing the name to the guest would have required SSH or some other transfer mechanism to reach the OS. Why make things that overly complicated when I could just leverage tagging I thought? As part of our provisioning workflow, we were assigning several tags to the AWS instance via vRO, with one of those tags being “Name” with a value containing the machine’s dynamically generated custom hostname. Alas, I had a solution.
I realized that with the AWS CLI, I could capture the “Name” tag and pass this to the OS for a hostname change. I needed to apply this solution to both Windows and RHEL 7.X Linux to satisfy this client’s requirements. What I came up with was a set of scripts, one in bash and the other Powershell which used the instance metadata and the AWS CLI to pass the custom hostname to the OS, where netdom or the editing of Linux config files did the rest. I used a vRA software component to launch the scripts, and assigned each of the constants to a property in the software component. After the script runs, I had the software component reboot the instance. Once provisioned, the hostname is displayed in the shell.
To make this work, the following needs to happen:
- Make sure you set a tag on the instance with a key of “Name” and a value containing whatever hostname you wish to use
- If you are using vRA, then call the script via a software component. Otherwise, call the script via init or as a remote artifact if you wish
- Web access is assumed. You may need to configure your enterprise proxy accordingly if you use one. Otherwise, you could retrieve the tools and other dependencies and host them on your internal web or file server
- Create an IAM user with privileges to read instance tags. No other privileges are required for this
- BACK UP YOUR DATA. I can’t emphasize this enough. Don’t be foolish enough to execute scripts without testing and backing up your data first
Feel free to reuse and fork the scripts which can be found here: