An IP address is an integral part of the server architecture and is required by all servers, LB VIPs, NATs etc. Many customers still make use of spreadsheets, which is very difficult to automate when you have to manually enter data, and this eventually leads to inconsistencies due to the file not getting updated when a IP address is assigned, changed or deleted.

What you need is a robust high performance, highly available IP solution that you can manage from a single interface and provides  features like:

• Manage a large pool of IP addresses
• Improve availability, and simplified administration.
• User based roles and permissions.
• Provide vital operational and troubleshooting data:
  • IP address history, MAC address, Owner, Location, OS, etc.
• Reports summarizing IP address resources and utilization.

There are many IPAM solutions out there with SovLabs support for the following:

• Infoblox
• Solarwinds
• Bluecat
• BT Diamond IP
• Microsoft

I will be using the SovLabs Infoblox module in my example but if you have read this far you probably asked yourself “Infoblox has native integration with vRealize Automation, why use the SovLabs Infoblox module?”  I did some research and hopefully this information is useful in your decision making:

Differentiators between SovLabs Infoblox IPAM and Infoblox native integration vRA:

• SovLabs do not require the Infoblox cloud adapter
• SovLabs has different modules, which seamlessly integrates with each other and enhances the IPAM functionality:
  • Separate DNS and IPAM modules to allow each to be driven independently even between different providers.
  • Ability to create multiple independent DNS profiles that can drive DNS for multiple different providers independent of IPAM.  DNS is able to register against multiple domains out of the box and drive host records, CNAMEs, PTR and A records independently.
• SovLabs has pre-validation logic for IP and DNS forward/reverse duplication detection.
• SovLabs Template engine can be used for custom comments, fields in Infoblox based on vRA metadata.
• SovLabs is design for ease of use.  No Infoblox schema changes or lengthy install and upgrade process.
• SovLabs is completely policy driven, no need for custom workflow development.

The SovLabs module also has many other features which can viewed on the website here, but some of the highlights are:

• Obtain and reserve unique IP address(es) and release automatically during appropriate machine lifecycle
• Reserves unique IP address(es) and assigns to the VM NIC(s) based on IPAM profile(s)
• IPAM profiles can span multiple networks, each consisting of a network name, subnet CIDR block and gateway address
• IPAM configurations are interchangeable between endpoint providers; avoid lock-in by easily adding additional IPAM providers with other IPAM modules from SovLabs
• No custom workflows required, completely policy driven
• SovLabs IPAM configurations may also be used with SovLabs network load balancer modules

Prerequisites:

1. Infoblox user on (all) Infoblox appliance(s) with the following permissions:
   • API and GUI access configured
   • Add/remove Host Records, A Records and/or PTR Records
2. Infoblox WAPI version must be 1.2+

   Access https://{infoblox-fqdn}/wapidoc/ and look in the upper-left corner

3. Login to the vRA tenant
   1. Add license for Infoblox IPAM module
   2. Validate the following show up on the Catalog page:
      1. Add Infoblox Endpoint
      2. Add IPAM Profile

 

Configuration:

1. Add InfoBlox Endpoint
   1. Login to vRA Tenant
   2. Select Catalog -> SovLabs vRA Extensibility
   3. 
   4. Click Request button on “Add Infoblox Endpoint”
   5. 
   6. Infoblox Endpoint
   7. Enter Configuration label
      • Only AlphaNumeric characters, no spaces or special characters except: - and _
   8. Enter hostname
      • FQDN of Infoblox server
   9. HTTPS = yes
   10. Port – 443
   11. WAPI version = pick from dropdown box based the version your found through prerequisites
   12. DNS View = optional, which DNS views this endpoint supports
       • Not using Infoblox for DNS in this example
   13. Network View = optional, which Network views this endpoint supports
       • All my networks are crated under the default view
   14. Credential Configuration
   15. Enter username
       • Username should have API access and permissions to add/remove records to/from Infoblox
   16. Enter password
   17. Click Next
   18. Advanced Options
       • These are optional and can be left blank which will populate with default value.
   19. Host record template
   20. A record template
   21. PTR record template
   22. Fixed Address template
   23. Click Submit
2. Add IPAM profile
   1. Select Catalog -> SovLabs vRA Extensibility
   2. 
   3. Click Request on Add IPAM Profile
   4. 
   5. Enter configuration label
      • Only AlphaNumeric characters, no spaces or special characters except: - and _
   6. Enter Description
      • I like to add the name of the network and subnet information here.
   7. Type = Infoblox
      • Since we are using Infoblox, that is what i picked.
   8. Provider host = select configuration label for previously created Infoblox endpoint
   9. Nic number = 0
      • On which NIC do you want to assign the IP address for the VM
   10. Subnets, Gateways and Network names
       1. The network name should match the vDS port group name.
       2. Enter values subnet, gateway and network name with comma separated and click on green + Sign
   11. Excluded IPs
       1. If you want to exclude some IP address, then enter them here individually.
   12. DNS Configuration
   13. Enter Primary DNS
   14. Enter Secondary DNS
   15. Enter DNS Suffix
   16. Enter DNS search Suffix
   17. Wins Configuration
   18. Enter WINS Server if necessary
   19. Click Submit

Enable the module:

Now we need to enable the custom properties module on our blueprint

1. Login to vRA
2. Click on the Infrastructure -> Reservations -> Network Profiles
3. Edit the network profile that best matches the IPAM profile created above
4. Click DNS tab
   1. Verify that the DNS suffix is set.
5. Click on the Infrastructure -> Reservations
6. Edit the reservation associated with the network profile review above in step 3.
   1. Click network tab
   2. Uncheck the network paths
   3. Also clear out the network paths dropdown value.
7. Click OK
8. Now we need to enable the custom properties module on our blueprint
9. Click on Design -> Blueprint
10. Edit Blueprint
11. Click on the blueprint vSphere machine on the Design Canvas.
12. Click on properties tab
13. In the properties group section click +Add
14. Check the box for:
    • SovLabs-EnableLifecycleStubs
    • Check the appropriate IPAM property group (starts with SovLabs-IPAM- and ends with -nic#)
    • Do not attach more than 1 IPAM profile property group to a blueprint VM object
15. Click OK
16. Repeat these steps for all blueprints that should get an IP address through IPAM.

Now deploy a VM and verify in Infoblox that the IP address is assigned to the network in the default view.

If you are a VMware administrator you know what a pain it is to manage snapshots.  Virtualization makes it easy to snapshot a VM before a patch or an upgrade is applied to an application or OS and gives you that peace of mind that you can revert back if it fails.   The reality is that users never clean up there snapshots and it starts getting used as a backup method in environments which places the burden on VMware admins to manage the clean up efforts.  VMware recommends not using snapshots for more than 3 days since it can cause serious performance, storage and corruption problems in your environment.

So how you do you handle snapshots?  A lot of customers just give up and take the chance of nothing going wrong, or they end up disabling this very valuable feature so users cannot use it all.  None of these methods are good.

SovLabs modules provides policies that control the expiration and deletion of VM snapshots as well as the ability to provide notifications to the VM owner. The VM owner is not given the option to extend the time of how long the snapshot lives and it will be automatically removed based on the lifespan in days set by the vRA administrator.

Configuration:

1. Add SovLabs vCenter Endpoint
   1. This configuration was covered in my previous post which can be viewed here.
2. Add SovLabs vRA CAFE Endpoint
   1. Select Catalog -> SovLabs vRA Extensibility
   2. 
   3. Click Request on “Add SovLabs vRA CAFE Endpoint”
   4. 
   5. Enter Configuration label
      • Only AlphaNumeric characters, no spaces or special characters except: - and _
   6. Version and Hostname are  auto-generated and based on querying vRA CAFE, verify that the information is correct
   7. If you have not configure this endpoint module then you need to create credentials.
   8. Click Submit
3. Add SovLabs vRA IaaS Endpoint
   1. Select Catalog -> SovLabs vRA Extensibility
   2. 
   3. Click Request on “Add SovLabs IaaS CAFE Endpoint”
   4. 
   5. Enter Configuration label
      • Only AlphaNumeric characters, no spaces or special characters except: - and _
   6. Version, Hostname  and Domain are auto-generated and based on querying vRA CAFE, verify that the information is correct
   7. If you have not configure this endpoint module then you need to create credentials.
   8. Click Submit
4. Add Notification Configuration
   1. Select Catalog -> SovLabs vRA Extensibility
   2. 
   3. Click Request on “Add Notification Configuration”
   4. 
   5. New message server = yes
      1. new fields will appear
   6. 
   7. Enter Configuration label
      • Only AlphaNumeric characters, no spaces or special characters except: - and _
   8. Enter message server address
   9. Enable SSL if required
   10. Enter message port
   11. Select message type
   12. Select message server protocol
   13. Select yes from drop down box if your SMTP requires authentication.
       1. Select yes from new credentials
       2. Enter configuration label
       3. Enter username and password
   14. Enable STARTTLS if required
   15. Set network timeout
   16. Since I selected message type as email, you need to setup your email groups.
       1. Select yes to create new group
       2. Enter email group configuration label
       3. Enter To and/or CC and BCC addresses
   17. Click Next
   18. 
   19. Enter notification configuration label
       • Only AlphaNumeric characters, no spaces or special characters except: - and _
   20. Select type = SNAPSHOT
   21. Select state = Whether or not to send notifications when a new snapshot is found (NEW), when a snapshot is about to be deleted (WARNING), and/or when a snapshot has been deleted (DELETE)
   22. Select format
   23. Enter From address
   24. Enter Title
   25. Enter Body
       • In the documentation they have some notification examples which you can just copy/paste and customize, which is very helpful.
   26. 
   27. Click Submit
5. Add Notification Group Configuration
   1. Select Catalog -> SovLabs vRA Extensibility
   2. 
   3. Click Request on “Add Notification Group Configuration”
   4. 
   5. Enter Configuration label
      • Only AlphaNumeric characters, no spaces or special characters except: - and _
   6. Select Type = snapshot
   7. Select Notification = previously create notification configuration.
6. Add Snapshot Configuration
   1. Select Catalog -> SovLabs vRA Extensibility
   2. 
   3. Click Request on “Add Snapshot Configuration”
   4. 
   5. Enter Configuration label
      • Only AlphaNumeric characters, no spaces or special characters except: - and _
      • sovlabs_snapshot_config_BG_all_2days
   6. Select SovLabs vRA CAFE Endpoint from dropdown.  This was configured earlier.
   7. Select SovLabs vRA IaaS Endpoint from dropdown. This was also configured earlier.
   8. Select Notification Group.  Make sure you have a notification group of type snapshot define. This was also configured earlier.
   9. Select if you want to manage snapshots for all business groups = yes
   10. Enter snapshot lifespan in days
       1. Per VMware’ recommendation try to stay within less than 3 days
   11. Enter the days before expiration a warning notification should be send out.
   12. 
   13. Click Next
   14. Set the snapshot scheduler.  So the scheduler you set here goes out and checks each VM if they have a snapshot that might be expiring or is expired and needs to be deleted.  Once create, a vRO schedule task is created which runs every 15min to make sure that the snapshot scheduler sends out the notification at the specified time.
   15. 
   16. Leave schedule as active
   17. Set schedule type = daily
       • most customers would pick daily
   18. Set the time to run in military format
   19. Can leave schedule end date blank to run forever.
   20. Click Submit

Enable the module:

1. Based on the set scheduler, an inventory update will automatically run and send notifications.
   • If a snapshot’s age has met the expiration day, it will automatically get deleted.
2. The last SovLabs Snapshot Configuration deleted, deletes the vRealize Orchestrator scheduled task for Snapshot Management.  It automatically creates it again if a snapshot configuration is created and scheduled task is not found.

Disable the module:

1. Login to the vRA tenant
2. Select Catalog -> SovLabs vRA Extensibility
3. Click Request on “Manage Snapshot Scheduler”
   1. Select Suspend from the Action dropdown list.
   2. Click Submit
   3. (if you want to resume this module again you can perform the same actions as above but select Action “resume” from dropdown list.

 

This modules allows you to make use of VMware’s DRS to sub-divide your vSphere clusters for consumption by defining DRS groups, affinity and anti-affinity rules. A good use case for this would the deployment of a VM that needs to be tied to specific host due to licensing or hardware constraints, or VMs behind load balancers that you want to make sure run on different ESXi hosts.

The module has many features which can viewed on the website here, but some of the highlights are:

• Create and manage vSphere DRS profile configurations directly in vRA and tie them to existing blueprints to enable affinity or anti-affinity relationships between VMs provisioned and existing DRS host groups.
• Automatic cleanup of appropriate linked VM rules and groups during VM de-provisioning lifecycles
• Allows for VM provisioning into specific pre-defined DRS host groups
• Dynamically creates VM group(s) and rule(s) during VM provisioning based on the corresponding SovLabs DRS profile configuration

Prerequisites:

• vCenter Server is properly configured
• vCenter cluster is properly configured and the host groups defined

Configuration:

1. Add vCenter Endpoint
   1. Login to vRA Tenant
   2. Select Catalog -> SovLabs vRA Extensibility
   3. 
   4. Click Request button for “Add SovLabs vCenter Endpoint”
   5. 
   6. Enter configuration label
      • Only AlphaNumeric characters, no spaces or special characters except: - and _
   7. Select vCenter version
   8. Enter PSC FQDN
   9. Embedded PSC = yes/no
   10. Enter vCenter Server FQDN
       • this should get populated
   11. Create credentials = yes
       1. This is not the vRA credentials so if you have not set this up through the catalog item request then you have to do so first.
   12. Enter username
   13. Enter password
   14. Click Submit
2. Add DRS Profile
   1. Login to vRA Tenant
   2. Select Catalog -> SovLabs vRA Extensibility
   3. 
   4. Click Request on “Add DRS Profile”
   5. 
   6. Enter configuration label
      • Only AlphaNumeric characters, no spaces or special characters except: - and _
   7. Select vCenter Endpoint
   8. Select Cluster
      • If the clusters do not show up, make sure you have Host groups defined in DRS or that the credentials are entered correctly.  Credentials can be updated through the SovLabs Catalog “Manage Credential Configuration”
   9. Select host group
      • I create 2 hosts groups within the cluster, with separate hosts in each, which will be assignment to each blueprint.
   10. Select Rule
       • I selected should run on hosts in group
   11. Click Submit

 

Enable the module:

Now we need to enable the custom properties module on our blueprint

1. Click on Design -> Blueprint
2. Edit Blueprint
3. Click on the blueprint vSphere machine on the Design Canvas.
4. Click on properties tab
5. In the properties group section click +Add
6. Check the box for:
   • Check the appropriate vSphere DRS property group (starts with SovLabs-DRS-)
   • Do not attach more than 1 vSphere DRS property group to a vSphere machine blueprint
7. Click OK
8. Repeat these steps for all blueprints that should use this custom naming.

 

 

In a previous life I had to setup a lot of VM’s with Load Balancer connectivity for development, QA testing and production.  This was always a slow painful process because even though I was able to quickly deploy the VM’s, I had to open a ticket with the network team and provided lots of detailed information to create the Pool and VIP entries, and then wait to receive the IP address so that I could ask the AD team to create the DNS entry. Fun times!

With the F5 load balancer SovLabs module, this is no longer the case and you can automatically perform the following tasks, all within the same catalog request for your application through vRA:

• Create the F5 Pool
  • The Pool name is created with the SovLabs custom naming module, so it can match the current naming standards of your networking team.
• Add the pool members
  • Automatically add all the vSphere machines within the blueprint as pool members
• Create the VIP
  • Automatically retrieve the VIP IP Address from your IPAM solution
  • The VIP name is created with the SovLabs custom naming module, so it can match the current naming standards of business and/or application.
  • Automatically create the DNS A-record for the VIP name

The module has many features which can viewed on the website here, but some of the highlights are:

• First-class citizen design; drag directly into vRA Blueprint Canvas  (This is awesome)
• Associate machine components by linking to the F5 Virtual component in the vRA Blueprint Canvas
• Option to reuse an existing F5 BIG-IP virtual server or create a new one
• Supports nested vRA Blueprints
• Supports vRA scale in, scale out for deployments
• SovLabs Restipes can create/delete F5 BIG-IP VIP/Pool/Nodes and assign Nodes to/from Pool
• Ability to specify F5 BIG-IP VIP name, IP address, and port at request time
• Option to integrate IPAM and/or DNS for F5 BIG-IP VIP assignment and DNS registration with Infoblox, BlueCat, Microsoft, SolarWinds, Men and Mice, BT Diamond IP at request time
• Supports multiple DNS domains for optional DNS registration at request time
• Option to integrate naming standard/sequence definitions for F5 BIG-IP VIPs and Pools at request time
• When a Catalog item is destroyed, F5 entries will automatically be cleaned up.

 

Prerequisites:

1. A user account configured in F5 BIG-IP® that has Administrator role/access:
   • Add/Remove F5 BIG-IP Virtual Servers
   • Add/Remove F5 BIG-IP Pools
   • Add/Remove F5 BIG-IP Nodes and Pool node members
   • Optional: Add F5 BIG-IP Virtual Server iRules, Add F5 BIG-IP Server/Client SSL Profiles, Add F5 BIG-IP Pool Health Monitors
2. Login to the vRA tenant
   1. Add license for F5 module
   2. Validate the following show up on the Catalog page:
      • Add F5 Endpoint
      • F5 Virtual
      • Manage Credential Configurations
      • Manage Restipe Configurations

 

Configuration:

1. Add F5 Endpoint
   1. Login to vRA Tenant
   2. Select Catalog -> SovLabs vRA Extensibility
   3. 
   4. Click Request button on “Add F5 Endpoint”
   5. 
   6. F5 Endpoint
   7. Enter Configuration label
      • Only AlphaNumeric characters, no spaces or special characters except: - and _
   8. Enter hostname
      • FQDN or IP address of the F5 management address
   9. HTTPS = yes
   10. Port = 443
   11. Credential Configuration
   12. Create credentials = yes
       • If you have not setup any yet which is the case for me
   13. Enter Configuration label
       • Only AlphaNumeric characters, no spaces or special characters except: - and _
   14. Enter username and password
       • I am using the build it admin account
   15. 
   16. Click Submit
2. Manage Restipe configuration
   1. What is a restipe you might ask, well I had the same question or should I say look on my face?  The documentation states the following ““infrastructure as code” approach for defining the steps used to create, reuse, remove and scale F5 BIG-IP structures, such as VIPs, Pools, and Nodes/Member”
   2. You do not have to create or update a recipe and will be used for specific use case, so for now you can skip this, but I did want to provide information below on how to access it.
   3. Select Catalog -> SovLabs vRA Extensibility
   4. 
   5. Click Request on Manage Restipe configuration
   6. 
   7. You can either create a new restipe, or update/delete respites.
      • 
      •  If you select action = update it will populate the restipe field with the default functional restipe that SovLabs provides.  Bonus!
      • If you do make an update, I would recommend copy out the restipe text and save a file to have a backup.
   8. If you need to create a custom restipe, then read the SovLabs Restipe guide here.

F5 example:

I have a blueprint with 2 x vSphere machine objects.  Each VM has a Puppet Node group assigned which installs Apache through the SovLabs Puppet enterprise module.

• I created a new Naming standard for the F5 VIP names, which will also be assigned automatically to MS DNS.
• I created a new Naming standard for the F5 Pool names

 

Enable the module:

The F5 plugin is a first class citizen in vRA which allows for it to be dragged into a blueprint through the design canvas, sweet!   This is a first for SovLabs and makes this plugin very easy to consume.

1. Login to the vRA tenant
2. Click on the Design tab > Blueprints
3. Create a new blueprint or select an existing blueprint name and click Edit
   1. Under Categories (on left pane), click on Other Components
   2. Drag and drop F5 Virtual – SovLabs Modules onto the Design Canvas
   3. Tie the F5 Virtual  VIP canvas item to the vSphere Machine canvas item by dragging the arrow FROM F5 Virtual  VIP TO the vSphere Machine.
   4. 
   5. Click on the F5_Virtual canvas item and a window pane will appear on the bottom
   6. Click Step tab
   7. 
   8. Modify fields as desired by setting the default values for fields and other advanced settings and clicking on Apply for each field
      By setting default fields or having advanced settings on the fields, what a requester sees and can select is controlled upon request time of the vRA blueprint
      1. General
      2. Select F5 Endpoint, which we created earlier in this blog
      3. Select the Restipe F5Config-Default.
         • I did not have to make any changes to the default restipe provide by SovLabs.
      4. Virtual Server
      5. Create new VIP = yes
      6. 
      7. Select Partition
         • In my case I selected Common
      8. Register VIP in DNS using Virtual name and IP = yes
         • So easy with just a checkbox!
      9. Automatically assign Virtual name = yes
         • This requires that you have a naming standard created using the SovLabs custom naming module.
         • Select Naming Standard for Virtual Machine = select custom naming label from drop down box.
      10. Enter domain name for DNS registration
      11. Automatically assign Virtual IP = yes
          • This requires that you have an IPAM profile created using the SovLabs IPAM module.
          • Select IPAM Profile for Virtual IP = select from the drop down box.
      12. Virtual port = 0
      13. Select SSL Profile (Client)
          • This will populate with the SSL profiles that your networking team has configured on the selected F5 endpoint, which means they do not have worry about loosing control of these important configuration.
      14. Select SSL Profile (Server)
          • This will populate with the SSL profiles that your networking team has configured on the selected F5 endpoint, which means they do not have worry about loosing control of these important configuration.
      15. Select Virtual iRules
          • This will populate with the iRules that your networking team has configured on the selected F5 endpoint, which means they do not have worry about loosing control of these important configuration.
      16. Pool
      17. Automatically assign pool name = yes
          • This requires that you have a naming standard created using the SovLabs custom naming module.
      18. Select Naming Standard for Virtual Machine = select custom naming label from drop down box.
      19. Load Balancing method = round-robin
      20. 
      21. Assign Health Monitors = yes
          • I added http for my test
      22. Health Monitor Availability Requirement
          • Pick if you want a single health monitor to match or multiple.
4. Click Save
5. Click Finish

To add additional node level settings during request time:

1. Click on Design -> Blueprint
2. Edit Blueprint
3. Click on the blueprint vSphere machine on the Design Canvas.
4. Click on the Properties tab
5. In the Property Groups section:
   •  Check the SovLabs-F5NodeConfigurations property group
6. Click OK

 

Manage the vRA users ability to make changes to the virtual F5 configuration during request:

By default, when a user requests a blueprint, which has the F5 module added, they will only see blank fields where the Blueprint Architect previously configured the F5 settings.  These settings can then be altered by the user.

But what if you do not want to user to make any changes and just want them to use all the settings of the F5 that was configured in the blueprint.

1. Click on Design -> Blueprint
2. Edit Blueprint
3. Click on the F5_Virtual on the Design Canvas.
4. Select the Step tab
5. For any of the configuration settings that you want to set a permanently for this blueprint, or even make invisible, follow these steps
6. Select the settings field which could either be a dropdown box, text field or check box. This will display additional information on the right hands side.
   1. 
   2.  Set required yes or no
   3. Set the default value to display.
   4. Click on Advanced settings
      • 
      • Set required = constant = no
      • Set read only = constant = yes
      • Set visible = constant = no
        1. If you do not want to users to see the field during the request.
   5. Click Apply
7. Click Save
8. Click Finish

 

Scale out and Scale in capabilities:

One last cool part is the automatic scale-out and scale-in of your deployed application.  As you can see I have a deployed Catalog item which consists of two CentOS Web servers, which I deployed Apache on through the Puppet Enterprise SovLabs module, as well as the F5 load balancer configuration.

1. Select on the top level catalog item
2. Click Actions
3. 
4. Click Scale Out
5. 
6. Select the virtual machine
7. 
8. Select the number of instance that you want to scale out to.
9. Click Submit.
10. Click OK to confirm the number of scale out instance and total number of instances.

This request will now automatically perform the following tasks:

• Add a new VM
  • Pull IP address from SovLabs IPAM endpoint
  • Create custom name from SovLabs custom naming module
  • Add the DNS a-record to MS DNS through SovLabs DNS module
  • Install Apache on the VM through SovLabs Puppet Enterprise module
• Add server to F5 pool
  • Add the custom name and IP Address associated to the newly created VM object to the F5 pool through the SovLabs F5 module.

Scale out was successful and only took just over 10minutes to complete with an application installation.

The new VM was added to catalog item in vRA as well as to the existing F5 pool.  Awesome, and same can be done for Scale in!

As you can see the configuration of this module is super simple and it provides a big relief from the mundane work of manual provisioning, not just for the VMware admins and application owners but also for the network team, while still keeping control of the F5 configuration.

My previous post showed how to run through all the pre-requisites, installation and licensing of the SovLabs modules.  Now it is time to configure it and I am starting off with the Custom Naming module.

This you might think is not important, but you always need to specify a name for a computer and the more descriptive this is, the easier it is to identify it without having to reference some type of database, spreadsheet or your own custom notes.

The problem with most automated solutions is that it provides a very basic custom naming solution out of the box with some characters for the pre-fix and numbers for post-fix.

If you have a complex Company naming standing then this will not work for you.  SovLabs custom naming modules makes use of the SovLabs template engine  which allows for static text in combination with dynamic content such as vRA custom properties and/or custom logic. Another cool feature is that you can assign different naming standards to your blueprint, so your departments are not force to use the same naming convention.  There are a lot of other great features to justify this module and they can be reviewed here.

My naming convention example:

LLLT-OEEEAAA##

L = location

T = Type

• (p)hysical
• (v)irtual

O = OS

• (w)indows
• (l)inux

E  = Environment  (in brackets is what will be used)

• (pr)o(d)uction
• (dev)elopment
• (q)uality (a)ssurance
• (st)a(g)e

A = Application

• Various 3 character code.  This could either be provided to user in dropdown during request or can be a custom text field. There are many options available here.

## = numbers sequence

• Begins with 01 and is specific to each combination of identifying prefixes.

For all these identifiers i am going to create a custom property and assign it in vRA.

• SovLabs.Naming.Location           -> Assigned to Endpoint
• SovLabs.Naming.Type                  -> Assigned to Endpoint
• SovLabs.Naming.OS                      -> Assigned to VM object in Blueprint
• SovLabs.Naming.Environment  -> Assigned to Business group
• SovLabs.Naming.Application     -> Assigned to VM object in Blueprint

Configuration:

1. First off we need to define our Naming Sequence
   1. (This can be used in one or more Naming Standards)
   2. Login to vRA tenant
   3. Catalog -> SovLabs vRA Extensibility Modules
   4. 
   5. Click Request button on “Add naming sequence”
   6. 
   7. Enter Configuration Label
      • Only AlphaNumeric characters, no spaces or special characters except: – and _
   8. Select sequence type
      • Mostly you will just pick Decimal
   9. Reuse sequence values = no
      • This you would select yes if you want to use the sequence number again once the computer is deleted.
   10. Max sequence length = 2
   11. Initial value = 01
   12. Sequence padding = 0
   13. Unique key
       • I want to use all the variables to make up the unique key.
       • {{SovLabs.Naming.Location}}{{SovLabs.Naming.Type | substring: 0,1}}-{{SovLabs.Naming.OS | substring: 0,1}}{{SovLabs.Naming.Environment}}{{SovLabs.Naming.Application}}
   14. Click Submit
2. Now we need to define our Naming Standard
   1. Login to vRA tenant
   2. Catalog -> SovLabs vRA Extensibility Modules
   3. 
   4. Click Request on Add Naming Standard – SovLabs Module
   5. 
   6. Enter the Configuration label
      • Only AlphaNumeric characters, no spaces or special characters except: – and _
   7. Select the naming sequence
      • The only option available right now is the one I just created
   8. Template
      • This is based on the custom property names I created for my standard naming convention example.
      • The template must include the sequence(s):  {{sequence.sequencename}}

      • {{SovLabs.Naming.Location}}{{SovLabs.Naming.Type | substring: 0,1}}-{{SovLabs.Naming.OS | substring: 0,1}}{{SovLabs.Naming.Environment}}{{SovLabs.Naming.Application}}{{sequence.standard_2_digit}}

   9. 
   10. Click Submit

You can review, update or delete your configuration under your catalog items.

• Select Items -> SovLabs Extensibility Modules
• Select the module name in left menu
• Highlight the item
• Click Actions -> Select Delete or Update

 

Enable the module:

Now we need to enable the custom properties module on our blueprint

1. Click on Design -> Blueprint
2. Edit Blueprint
3. Click on the blueprint vSphere machine on the Design Canvas.
4. Click on properties tab
5. In the properties group section click +Add
6. 
7. Check the box for:
   • SovLabs-EnableLifecycleStubs
   • Starts with SovLabs-NamingStandard- for single machine scenarios
   • Starts with SovLabs-NamingStandardMultiMachineContainer for multi-machine container scenarios
8. Click OK
9. Repeat these steps for all blueprints that should use this custom naming.

 

Now deploy a VM and watch the magic happen. Effortless, predictable, consistent and best of all no manual input of trying to figure out a name.