vCloud Automation Center – vCAC 5.2/6.0 – Custom Hostnaming Extension v3.1

Overview

One of the most frequent asks when using vCAC is, “How do I deploy machines using my company’s hostnaming standards automatically using vCAC?”  Since the out-of-the box hostnaming only provides a way to do prefix-suffix, the answer to this question usually is that it will require customization.

This solution is intended to provide a way to implement this functionality by using a small, highly versatile custom extension which can handle 95% of use cases without writing custom code.

The rest of this article contains instructions on installing and configuring the vCAC Custom Hostnaming Extension.  This extension allows administrators to model very specific custom hostnaming schemes for their vCAC virtual machines, multi-machine services, and vCloud Director vApps using vCAC custom properties, with dynamic creation of stock machine prefixes and index tracking for each unique hostname combination.

This extension is proof-of-concept or demo grade.  While it runs well and consistently, it has not been put through a formal quality assurance process, so please use with caution.  Please see the disclaimer and other information in the readme.txt file in the package.

 

Changelog

v3.1

  • Resolved reprovisioning issue so that the machine will no longer be renamed
  • Fixed compatibility with VirtualMachine.Admin.NameCompletion property
  • Simplified installation and configuration
  • Refactored the workflows for much more modular design

v3.0

  • Ported to vCenter Orchestrator
  • Added check for existing VM with same name (if exists, will increment)
  • Added ability to leave out the index number for the first instance of a name
  • Solved concurrency issues which caused duplicate names when requesting more than one of the same blueprint

v2.0

  • Added support for vCloud Director vApps
  • Added dynamic Machine Prefix creation and tracking for every unique combination (this affects configuration, so please read if you’re coming from version 1.0)

v1.0

  • Initial release

 

Download

vCAC Custom Hostnaming Extension 3.1

 

Installation

These installation instructions assume the following:

  • You have a working vCenter Orchestrator in your environment.
  • You have a working knowledge of administering vCO.
  • The vCloud Automation Center 5.2 or 6.0 plugin for vCO has been installed, and a vCAC host has been added.
  • You have the vCenter Orchestrator instance configured as an endpoint in vCAC.
  • vCAC 5.2 or 6.0 is preconfigured with at least one working Blueprint.  Two individual Blueprints and a Multi-Machine Service Blueprint are better in order to see the full functionality.

Follow the steps below to perform the installation:

  1. Download com.dailyhypervisor.vcac.customhostname.package from the link above and copy it onto the local filesystem of the system where you will run the vCenter Orchestrator client.
  2. Import com.dailyhypervisor.vcac.customhostname.package into your vCO instance.
  3. Run the workflow Daily Hypervisor > vCAC > Custom Hostname > Install custom hostname extension.
  4. Choose the vCAC host where you’d like to install the extension and click Submit.
  5. Follow the instructions described by the workflow to download and install the external workflow XML file into vCAC.

 

Configuration

To configure vCAC to use the custom hostnaming extension, perform the following steps:

  1. Go to Enterprise Administrator > Build Profiles.
  2. Click on New Build Profile.
  3. On the New Build Profile page, click the drop down for “Add from property set”, and choose our new custom hostname property set.  Click Load.
  4. You will now have all of the custom hostnaming extension properties in your Build Profile.  Below is an explanation of each property.
     
    Custom.Common.SetCustomHostname.Execute
    The existence of this property triggers the custom hostnaming workflow to run.  This must be specified to leverage the extension’s functionality.
    Note:  The value is set to “true” by default, but this is just aesthetic.  Setting it to “false” will not stop the workflow from running.  This property only needs to exist to trigger the workflow, regardless of its value.

    Custom.Common.ComponentMachine.HostnameString
    This property’s value represents the hostnaming scheme you are using for a component or single machine.  The format of this string looks something like this:  {part1}-{part2}-{##}-vm.  The parts enclosed in curly brackets represent the name of a custom property whose value you’d like to plug in to that slot.  The ## indicates that you would like a two digit auto-incrementing index placed in that slot.  Anything not in curly brackets is placed in the hostname as-is.

    Custom.Common.AppService.HostnameString
    This property is identical to the one above, except that this scheme gets applied to a multi-machine service or vCloud Director vApp instead of a component or single machine.

    Custom.Common.ComponentMachine.NoIndexOnFirst
    Adding this property and setting the value to “true” causes the workflow not to add the index to the hostname on the first instance of each unique name.

    Custom.Common.AppService.NoIndexOnFirst
    This property is identical to the one above, except that it applies to a multi-machine service or vCloud Director vApp instead of a component or single machine.

    Custom.Common.Hostname.OwnerShortNameIdentifier
    If this property is specified, it indicates to the custom hostnaming workflow that this value is the identifier of the part of the hostname string where the short username (no domain and backslash) of the owner should be placed.  For instance, if you specified this property with a value of USR, any part of the hostname string where {USR} is specified will be replaced with the owner’s short username.

  5. Let’s configure an example custom hostname scheme to get a working understanding of the functionality.  We will build a single machine hostname scheme.  The next step is to refine the property set in our build profile.Since we are configuring for a single machine, delete the Custom.Common.AppService.HostnameString and Custom.Common.AppService.NoIndexOnFirst properties altogether.
  6. Also, let’s exclude the owner short username and index removal functionality for this example, so delete Custom.Common.Hostname.OwnerShortNameIdentifier and Custom.Common.ComponentMachine.NoIndexOnFirst.
  7. Edit the Custom.Common.ComponentMachine.HostnameString property value to model the following use case:
    • This scheme has four parts:  a location identifier, a group identifier, an application identifier, and an auto-incrementing index, respectively.
    • Use LOC for location, GRP for group, and APP for application.

    Your hostname string should look like this:  {LOC}{GRP}{APP}{###}.  Name your Build Profile.  You will end up with a new Build Profile as shown below.

  8. Now we need to configure the custom properties for each variable identifier in the string.  Location ties most closely to the Compute Resource or Reservation, so let’s take advantage of the custom property hierarchy and specify it there.

    I set LOC (our location identifier) to JAX to represent Jacksonville.

  9. Group will be specified at the provisioning group level, so in my Development Provisioning Group, I created a property named GRP with the value DEV.
  10. The APP identifier’s value will be unique to the Blueprint.  So I went to my Apache Web Server Blueprint, created a property named APP, with a value of LAMP.  Also, be sure to select the Build Profile we created in order to tie the hostname string and workflow trigger property to builds from this Blueprint.

By putting three # symbols in for the index, we are indicating that is will be three digits. Since it will be the first time using this hostname combination, the extension should dynamically create a new Machine Prefix, and the index should start at 001 and increment from there.

So, if I request an Apache Web Server on the Jacksonville Compute Resource, as a member of the Development group, my end result should be…

JAXDEVLAMP001

A test reveals that the custom hostnaming extension does its job.

Custom Multi-Machine Service and vCloud Director vApp Naming

Custom multi-machine service and vApp naming works in an almost identical way.  However, there are two differences to note.

  1. It uses a different hostname string property.  Instead of Custom.Common.ComponentMachine.HostnameString as in our previous example, the workflow looks for Custom.Common.AppService.HostnameString.  The reason for this is to allow component machines to have different naming schemes than their parent.  Component machines inherit properties from the parent multi-machine service or vApp, and when the same property is specified on both levels, the parent property overrides that of the component machine.  Therefore, without separate properties, component machines would be forced to implement the same hostnaming scheme as the parent multi-machine service or vApp.
  2. Multi-machine services do not inherit all of the same properties as component machines.  Namely, they do not inherit properties from placement entities, such as Compute Resources and Reservations.  This is because multi-machine services themselves do not reside anywhere or consume resources.  They are simply a logical grouping of actual machines.  The component machines are the ones that are actually placed on infrastructure, and it’s possible to configure a multi-machine service with component machines that can or will end up on different resources, even in different locations.  So it becomes impossible to logically tie multi-machine services to singular infrastructure. vApps, on the other hand, do support locations, as vCloud Director and vCAC both consider them as located in the organization vDC, along with their component virtual machines.In other words, if you were to use the value of Custom.Common.ComponentMachine.HostnameString in our previous example as the value of Custom.Common.AppService.HostnameString in a multi-machine service, you would get an error, because it will not find a property named LOC.

 

Adding the Owner’s Short Username to a Custom Hostnaming Scheme

One additional function you can use that we did not explore in our example is adding an owner’s short username (without the domain and backslash) as a part of the hostname.

To do this, you can simply specify one additional property, Custom.Common.Hostname.OwnerShortNameIdentifier.  Set the value of this property to the identifier you will use in your hostname string to specify where to place the username.

Here’s an example Build Profile created for this scenario:

If I logged in as CORP\Administrator and requested a machine from a Blueprint with this scheme enabled, and assuming that I have already provisioned 27 instances, leaving the next index as 28, I could expect the machine to be named like this:

Comments

  1. This is an awesome solution. Thanks for posting Tom!

  2. I am getting an error on the first command:

    Could not load file or assembly ‘file:///C:\Users\XXX\YYYY\vCACCustomHostnamingExtension\VMware.vCAC.Custom.Common.Activities.dll’ or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0×80131515)
    Warning: Non-zero return code. Command failed.

    Any clue what is going on here? Thanks.

    • Tom Bonanno says:

      Check the downloaded package and/or its contents. Sometimes when you download a package from the internet or copy it that contains DLLs or EXEs, you have to go into the properties of the package or the content files and “Unblock” them.

  3. Hi Tom,

    Have you had success using this procedure on vCloud director vApps?, I want to configure a multi-machine on vCAC that gets its name (vApp container) based on the user requesting it, but follow a conventional machine prefix for the components. Following the article I created a build profile using these properties:
    Custom.Common.AppService.HostnameString {USR}{#}
    Custom.Common.Hostname.OwnerShortNameIdentifier USR
    Custom.Common.SetCustomHostname.Execute true

    Then I add the build profile only to the container blueprint, and change the prefix to a custom one as described in the article. After deploying the blueprint, the component VM gets the correct name but the container is named to “custom100″ instead of getting the username.

    Any help is appreciated.

    Thanks,

    Juan.

    • Tom Bonanno says:

      I’ll check into this as soon as I can.

      • Some extra information from the Log Viewer:

        Error 9/18/2013 12:48 PM Repository Repository vcac-web Resource not found for the segment ‘WorkflowOperations’.
        Error 9/18/2013 11:44 AM DEM-Worker DEM Worker 1 vcac-server Workflow “SetCustomHostname” failed with the following exception: Object reference not set to an instance of an object.
        Error 9/18/2013 11:44 AM DEM-Worker DEM Worker 1 vcac-server Workflow “SetCustomHostname” failed with the following exception: Object reference not set to an instance of an object.

    • Tom Bonanno says:

      Juan,

      I didn’t initially create this to be compatible with vCD vApps. I’m going to apply a fix and repost with vCD vApp support sometime today. Thanks for bringing this to my attention.

  4. Tom Bonanno says:

    Blog post has been updated!

    v2.0
    -Added support for vCloud Director vApps
    -Added dynamic Machine Prefix creation and tracking for every unique combination (this affects configuration, so please read if you’re coming from version 1.0)

  5. Kevin Atwood says:

    Would it be possible to use a drop down for APP Selection?

  6. Thanks for taking the time to add vCloud director support. I guess the naming customization applies only to components, so in the case of vCloud director my vApp names can only be set to whatever I define in the machine prefixes, which is kind of limited, am I correct?

    • Tom Bonanno says:

      Sorry for the late reply. No, this works for both the vApp itself and the components. Different properties control each, as explained in the guide.

  7. Hi Tom, why don’t you use a custom script in the BuildingMachine workflow step? With that you would not need a CDK license. And according to vcacteam.info you would still be in the more support “extensibility” area (instead of “customisation”). Regards, Ronald

  8. Ross Davies says:

    Hi Tom,

    I’m working on a similar solution to fit my companies naming convention and came across this post! – great work! I am awaiting the arrival of our CDK licence key to begin coding, but I’m interested in how you generate the unique number using this solution? Would you mind sharing how you achieved this??

    • Tom Bonanno says:

      Hi Ross,

      Do you have vCenter Orchestrator available in your environment? I’m finishing up a ported version for vCO which does not require CDK, and all of the magic in the workflow schema and scriptable tasks is wide open to view and/or edit to your liking. I’m aiming to publish it by the end of the week.

      • Ross Davies says:

        Hey Tom,

        I do have orchestrator available in my enviroment. I’m looking forward to seeing the updated vCO workflow version of this, although I have just purchased the CDK – I’m sure that I’ll still need to call custom stubs, even if they only contain a calll-out to a vCO workflow. We have multiple, layered standards that I think I’ll only be able to satisfy if I can control exactly which blueprints they run on!

        Let me know once its posted :)

      • Ross Davies says:

        Hey Tom,

        Thanks again for this creating this great plugin! I’ve been playing around with it and I have hit a problem that I hope you have seem (and resolved in the past)!

        If I request multiple VMs, or request VMs in quick succession that would use the same naming convention the sequence number does not get iterated quick enough and all requests get issued the same name… Have you seen this before? If so how did you resolve it? I’m working on a vCO workflow to check the execution status of another workflow and wait for a random time period if anything else is running but its not a foolproof method – as the workflow token takes a fraction of a second to create and may not be there at the time of my test…

  9. What should be the “default machine prefix” because it is overwriting the the customhostname

    • If you are not seeing the name you expected something is not working properly. The machine prefix should only be utilized to increment the unique prefix from. It would not be overriding, it in fact is not being overridden itself by the workflow.

    • Phil Balfanz says:

      I am having the same problem on vCAC 6.0. You have to define a Build Prefix what should it be set to? All my machines are coming out customXXX.

      • Tom Bonanno says:

        The dynamic machine prefixes the workflow creates should not be used for the default out-of-the-box prefix. I recommend choosing something generic or descriptive, such as unnamedXXX or somerthing like that for all Blueprints and/or Provisioning Groups. Then the workflow should change it based on the hostname string property you specified. If it doesn’t work, I recommend checking to make sure the External-SetCustomHostname.xml file has been installed properly on the manager server, and that you’ve restarted the vCloud Automation Center Service.

  10. Tom Bonanno says:

    v3.0 is up!

    – Ported to vCenter Orchestrator
    – Added check for existing VM with same name (if exists, will increment)
    – Added ability to leave out the index number for the first instance of a name

  11. Tom,
    Let’s say I want create my own system name on the fly what’s the best way to pass it from vCO to vCAC when provisioning a new system against a blueprint. To be clearer I would want the same behavior as if you prompted the user to enter a hostname in the traditional vCAC UI.

    • Tom Bonanno says:

      Mr. Remy,

      How’s it going man? Good to see you on here.

      Actually, you could just leverage this package, and, in the BuildingMachine stub, BEFORE this workflow runs, set a custom property of your choice which will represent the hostname. Then set your Custom.Common.ComponentMachine.HostnameString property to {YourCustomPropertyName}. That should do it.

  12. vCO 5.5 embedded w/ vCAC 6.0. Trying to edit the vCAC Environment element is reporting a “missing element” so I can’t select the vCAC host. I assume that this is because the package would only partially import, due to the server having newer versions of the elements under the Library \ vCloud Automation Center.

    Thoughts on how to fix?

    • Tom Bonanno says:

      Have you added a vCAC host to the inventory using the vCAC plugin?

    • arch_eddie says:

      I too am trying to run the custom hostname extension using the built-in vCO in vCAC 6.0.0
      Same problem where several items within the package are not flagged for import . . . server version newer.
      So I imported what I could and then ran the Daily Hypervisor > vCAC > Custom Hostname > Install custom hostname extension,
      and it fails with no messages at all.

      • arch_eddie says:

        … the vCAC Host has been successfully added. First WF prompt in “Install custom hostname extension” asks for the vCAC host, which I am able to apply successuly. It fails thereafter on Submit.

  13. Sascha Milic says:

    Hi Tom,
    thanks for the workflow, supporting the customers Naming Convention is always a good thing. Now I’ve 2 issues even that I followed exactly (and without errors) your installation and configuration guide. First: the workflow is simply not triggered and Second: The “LOC” Custom Property is not provided/inherited from the Resource Part, strange (the two others work fine). Any idea?

    Thanks a lot,
    Sascha

    • Tom Bonanno says:

      I recommend checking to make sure the External-SetCustomHostname.xml file has been installed properly on the manager server, and that you’ve restarted the vCloud Automation Center Service.

      The only way “LOC” would not be inherited is for one of two reasons:
      1. It is a multi-machine service name so the location does not apply.
      2. The machine is landing on a resource that is not tagged with the property.

  14. First of all, thanks for your efforts in keeping development on this going. Secondly, is this confirmed working in the GA 6.0 version of vCAC because I cannot seem to get it to use custom over default prefixing. I am using the integrated vCO and installed the downloaded template from the workflow to the IAAS host. The install goes through without incident, but the custom naming never takes effect. Services and hosts have been restarted.
    Thanks again for all the work…

  15. Brandon B. says:

    Great stuff. What is the best way to undo the workflow? Can you add a workflow to uninstall the naming convention extension?

    • Tom Bonanno says:

      You can remove it in the DB, but there’s really no need. It doesn’t take up much space. I might add uninstall into a newer version, but, for now, simply deleting the trigger property from each Blueprint and/or Build Profile will stop it from running.

  16. Tom Bonanno says:

    v3.1 is released!

    - Resolved reprovisioning issue so that the machine will no longer be renamed
    - Fixed compatibility with VirtualMachine.Admin.NameCompletion property
    - Simplified installation and configuration
    - Refactored the workflows for much more modular design

    • Ross Davies says:

      Hey Tom,

      I’m running into an issue with the current version of your workflow – I have found the issue but have not yet found a way to resolve it. In the formulate hostname script you initialize a for loop using hostnameStringProp.length to define the loops condition. This string function does not seem to be present in my vCO appliance(s). From some debugging output I have added when you run that function the returned value is ;

      [2014-03-05 10:11:54.930] [D] DEBUG: hostnameStringProp.length = function length() {/*
      int length()
      */}

      Which results in the loop not being processed and necessary variables not being populated;

      [2014-03-05 10:11:54.930] [D] DEBUG: newNameString = ”
      [2014-03-05 10:11:54.930] [D] DEBUG: shortOwnerName = ‘undefined’
      [2014-03-05 10:11:54.930] [D] DEBUG: ownerName = ‘undefined’
      [2014-03-05 10:11:54.930] [D] DEBUG: ownerEntity = ‘undefined’
      [2014-03-05 10:11:54.930] [D] DEBUG: indexPlaceholder = ”
      [2014-03-05 10:11:54.930] [D] DEBUG: indexLength = ’0′
      [2014-03-05 10:11:55.191] [I] Hostname is already in use, and there is no index to increment (Workflow:Set custom hostname / Formulate hostname (item4)#184)

      Any suggestions?

      • Tom,

        I found out the issue , but I don’t know why it happens… for some reason the hostnameStringProp input parameter was not being evaluated as a string. I added the following line of code to force it to be seen as a sting and all works just fine now!

        var hostnameStringProp = “”+hostnameStringProp+”"
        for (var i = 0; i < hostnameStringProp.length; i++)

        Let me know if there is anything else that you think could have caused this (or a better workaround if you find one!)

        Ross

        • Tom Bonanno says:

          Okay, this problem is not just happening to you. It’s the second time I’ve seen it and haven’t been able to get to the bottom of it so far. I’m going to look into it some more. What makes it difficult is that I’m not seeing the same problem in either of my two environments for some reason.

          • Tom Bonanno says:

            Okay, so for anyone else having this problem, it is due to a bug in vCO/Javascript having to do with string concatenation. This bug has been fixed, so updating vCO to the latest maintenance release should do the trick.

          • Which maintenance release are you at that is working?

          • Doh! Never mind I got it working with 5.5.1

Trackbacks

  1. [...] that Tom has worked out a way to do this that works in both vCAC 5.2 and 6.0.  You can find it here.  Make sure you set a good amount of time aside for working through [...]

Leave a Reply

WordPress Appliance - Powered by TurnKey Linux