After installing Pivotal Cloud Foundry (PCF) on vSphere, you’ll have a collection of at least 21 (probably closer to 60!) VMs with names that probably don’t match anyone’s convention. Although, as noted in the PCF documentation, there is a correct order to starting up and shutting down the VMs in PCF, the installer does not configure a vApp so that we can control that order. So, I dragged all the PCF VMs into a vApp and starting trying to determine which ones are in which role and quickly realized that it’s a pain.
Creating an AZ in Ops Manager on vSphere
As an aside, when you create your Availability Zone, you point it at a vSphere cluster and, optionally, a Resource Pool. Unfortunately, if you specify a vApp Name instead of a Resource Pool name, BOSH will fail to deploy the VMs. So, I’ve typically leave the Resource Pool field blank and then drag the VMs into a vApp post-deployment.
I put together a workflow that will help place the PCF VMs into correct startup/shutdown groups for you.
If you haven’t already, create a new vApp in your cluster and drag the Ops Manager, Ops Manager Director and all of the Elastic Runtime VMs into the vApp
Run the “PCFvAppStartupOrder” workflow, select your new vApp as the input, click Submit
If the PCF installation is scaled out to more VMs, just drag them to the vApp and rerun the workflow
The deployment, job and director custom fields are read for each VM in the vApp to get the VM’s assigned role
For the Ops Manager, the Notes field is read and if found, it is placed at the top of the startup sequnce
Unknown VMs are assigned a startup order higher than the last in the array. This way, they start last and power-off first
Unknown VMs are those where the “deployment” field does not start with “cf”; with exceptions for Ops Manager (Notes field) and Ops Manager Director (“director” field value is “bosh-init”)
Additional suggestions and notes
Adjust the resources for the vApp based on VMware best practices and what makes sense for your environment
Use this at your own risk, there is no implied warranty
If you’re here, you’ve probably already found VMKB2092228 and been frustrated by the lack of an easy and consistent way to configure all the NSX components to send log data. Me too.
I put together a vRO workflow to help configure (and reconfigure) syslog on NSX.
It prompts for the NSX manager connection info and Syslog server info
Creates a REST host for the NSX manager using the admin super-user account
Adds several REST operations to the NSX Manager REST host
Deletes and readds the syslog configuration on the NSX Manager
Optionally configures Activity Monitoring on the NSX Manager
Identifies each running Controller; deletes and readds the syslog config on each
Identifies each deployed and “Green” Edge (including DLRs); deletes and readds the syslog config on each
Removes the NSX Manager REST host created earlier
Notes
It must use the NSX Manager admin account – it’s the only superuser account that can update teh manager config.
If a Controller is not running when the workflow runs, its syslog config will not be updated
If an Edge’ state is not “green” or is not fully deployed, its syslog config will not be updated
By downloading any code, package or file, you acknowledge that:There is no explicit or implied warranty or support for the code. Neither Brian Ragazzi, his employer nor anyone else is responsible for any problems, errors, omissions, unexpected behavior, breakage, trauma, outage, fatigue, lost time, lost work or incontinence that may occur as a result of using the code or package.
Import package into vRO
Run the ConfigureSyslogNSX workflowWorkflow Step 1
***UPDATE*** The download link is currently broken. I seem to have lost the file, will fix the link as soon as I find or recreate it. Sorry about that. 😦
In part 1 of this series, we created a list of security groups and displayed that list to users during the request. In this post, we want to enhance that functionality by adding these features.
Creation of Security Groups and inclusion in Dropdown lists
Add a VM to a Security Group post-provisioning
Import existing Security Groups into vRA inventory
Add a Security Group to a Dropdown list
We’re going to do that by importing a vCO package with some new workflows and actions, then link up the workflows to Advanced Services and Resource Actions. As before, we’ll require the NSX and vCAC/vRA plugins for Orchestrator.
Preparation
Complete the creation of the VCNS.SecurityGroup.Names.production property dictionary and valuelist attribute from Part 1. We’re going to reuse those items. so make a note of the exact name of the property dictionary and the valuelist attribute. In my case, I’ve named the Property Dictionary VCNS.SecurityGroup.Names.production and also named the valuelist attribute for it VCNS.SecurityGroup.Names.production
Make sure vRA Advanced Services Server Configuration is complete and test the connection to the Orchestrator server. The default, built-in VCO is fine.
Login to vCO client as a vCO Admin. Set the mode to “Design” and navigate to the Inventory tab. Make sure that you have a connection listed under “vCAC Infrastructure Administration” and a connection listed under “NSX”.
Confirm that you have the necessary connections on the inventory tab
Get the Package
I’ve put together a handful of workflows and actions that use or expand the NSX plugin to provide information of functionallity back to vRA. Where possible, I reused existing library workflows, but in some cases, I had to use the API to create a REST call and consume that in an action.
By downloading any code, package or file, you acknowledge that:
There is no explicit or implied warranty or support for the code. Neither Brian Ragazzi, his employer nor anyone else is responsible for any problems, errors, omissions, unexpected behavior, breakage, trauma, outage, fatigue, lost time, lost work or incontinence that may occur as a result of using the code or package.
Download the zip file. It contains the package and a couple of images that can be used for the advanced services
Import the Package
Extract the zip file
In the vCO Client, navigate to the packages tab.
Click the “import package” button and select the extracted .package file
On the Package Import Information step, click “Import”
Package Import Information
On the Import package… step, check the “Select/Deselect all” box to check all of the items. Please note the server path, these should not be duplicates of anything else you have in your vCO inventory (unless you’ve already imported this package previously). Click “Import Selected elements”.
Select all items
Review the workflows and actions added to your inventory.
Configure Advanced Services – Create Security Group
This service enables the user to create a new NSX Security Group and automatically adds its name to the appropriate dropdown list of security groups. It can be added once for each different list of security groups. You’ll need to know the exact name of the Property Dictionary and valuelist attribute you created in Part 1.
NSX Management ServicesNSX Security Groups in vRA Items
While logged into vRA as a service architect, navigate to the Advanced Services tab, click “Custom Resources“
We need to make vRA aware of NSX Security Groups. Click the Add button.
In the Orchestrator Type field, enter “NSX:SecurityGroup“; for the Name, I suggest “NSX Security Group“, click Next
Add NSX Security Group as Custom Resource
On the details form, we’re not going to make any changes, but if you wanted to hide certain properties, you could here. Click “Add“.
Click “Service Blueprints”, then the “Add” button.
On the Workflow tab, select the AddNewSecurityGrouptoDropdown workflow, click next.
Select “AddNewSecurityGrouptoDropdown” workflow
On the Details tab, set the name to something like “Create new Production NSX Security Group“, because we’re going to create the security group and add its name to the “production”dropdown list. Click Next.
Set the Service Item Name
On the Blueprint Form tab, under the “Step” Form page (default), mouseover the text field labelled “Name of Custom Property Dictionary in vCAC/vRA”. Click the pencil “edit” icon when it appears.
Edit the Form Fields
Click the Constraints tab of the “Edit Form Field” window. On the Value field, select “Constant” and enter “VCNS.SecurityGroup.Names.Production” (or whatever suffix you used) for the Property Dictionary. Set the Visible value to “No” so it doesn’t show up. Click Submit on the Edit Form Field window.
Set the name of the Property Dictionary to be updated
Using the same method, set the Name of the Attribute appropriately and its visibility to no
Edit the “Value to be appended to the ValueList attribute” field. Set the label to “New Security Group Name“. Do not set a value or make this one invisible, we need the user to enter a value, submit to save.
Edit the vCACIaaSHost field – using the Constraints tab again– when setting the value, choose constant, then click Add by the green plus, to display a treeview, where you can choose your connection to the IaaS Server. Visible: No, submit to save.
Select connection to IaaS host
Edit the “NSX endpoint” field in the same way, selecting the NSX connection.
When done, all fields except “New Security Group Name” will have a value. Click Next.
On the Provisioned Resource tab, select “securityGroup [NSX Security Group]“. Click Add to save the service blueprint.
Repeat steps 5-15 for any other dropdown lists containing security groups; say “Non-Production” for instance
Highlight the Service Blueprint and click “Publish” to make the blueprint available for entitlements
Navigate to Administration, Services.
Add a new Service named “NSX Management” (for example) – I included a nifty image in the zip file
Under Catalog Items, click the “Create new Production NSX Security Group” item to edit it.
The Catalog item should inherit the Security Group icon from vCO, set its Service to “NSX Management”,click update to save.
Create or Edit an entitlement to include the new Service and/or catalog item.
Try it out, confirm that the Security Group was created in NSX, is visible in vCAC items and it name was added to the Property Dictionary
Configure Advanced Services – Import Security Group
This service allows you to make existing security groups visible as items in the vCAC Items view. Once this is done, we’ll add actions that allow you to add the security group to a dropdown list.
Click “Service Blueprints”, then the “Add” button.
Select the “GetNSXSecurityGroup” workflow, click Next
On the details tab, set the name to “Import NSX Security Group“, click Next
On the Blueprint form, set the “connection” to the NSX connection in vCO, then hide the field. Security Group Name will be a dropdown list of existing NSX Security Groups for the user to choose from. Click Next
On the Provisioned Resource tab, select “securityGroup [NSX Security Group]“. Click Add to save the service blueprint.
Just as before, publish the service blueprint, add it to a service and an entitlement.
Configure Advanced Services – Add Security Group to Dropdown list
With this service, we’ll let the user add the name of an existing Security Group to a drop down list. Unlike the first two, this is implemented as a Resource Action, meaning it’ll be executed against an existing item (a Security Group in this case)
Under Resource Actions, click “Add”
For the Workflow, select the “AddExistingSecurityGrouptoDropdown“, click Next
On the “Input Resource” tab, keep NSX Security Group, click Next
On the Details tab, set the Name to “Add Security Group to Production list” or similar, set the description, leave the Type options unchecked. click Next
Set Action Name and Description
On the Form tab, just like the first service blueprint, set the Property Dictionary and Attribute names as appropriate. VCNS.SecurityGroup.Names.production in my example, set visible to no on both.
Again, we’ll set the vCACIaaSHost to the connection to the Server and hide the field
Click Add to save the action.
Repeat steps 1-6 for each security group dropdown list (say “non-production” for instance)
Publish the action and add it to an entitlement
Add Action to Entitlement
Test by navigating toNSX under Items, highlight a Security group and Select “Add Security Group to…” from the Actions menu.
Yay! A Resource Action
Configure Advanced Services – Add VM to a Security Group
This service lets you add a provisioned VM to additional Security Groups. So, at provisioning-time, the VM is added to the Security Group selected by the user, but we may need to refine the security by adding that VM to additional Security Groups.
Under Resource Actions, click “Add“
For the Workflow, select the “AddVMtoSecurityGroup“, click Next
On the “Input Resource” tab, keep IaaS VC VirtualMachine, click Next
On the Details tab, set the name to “Add VM to a Security Group“, click Next
On the Form tab, set the connection Value to the NSX connection.
Leave the NSX Security Group field visible, click Add to save the action
Publish the action and add it to an entitlement
Test by selecting a machine under Items and “Add VM to a Security Group” from the Actions menu
VM Resource Action for Security Groups
You’ll be presented with the list of allNSX Security Groups to which you can add the selected VM
Select Security Group
Conclusion
This part of the series should help streamline the management of VMs and their membership in Security Groups. Obviously, items like removing a VM from a Security Group or even removing a Security Group are not included here. The NSX plugin is missing quite a bit of functionality available in the API, so those additional functions require significantly more configuration.
Thanks to John Dias for his information and examples posted here.
In this series, I’ll document how to automate the creation and (some of) the management of NSX security groups within NSX.
First, what’s the use case? Why is this interesting? Let’s assume that you’ve decided to use large “flat” networks instead of many small networks. One reason you may make that decision is because of the challenges with either having many blueprints (one per network!) or making changes to the workflows to reliably set the appropriate properties.
Background
In this solution, we’ll have to have vCAC 6.1 or vRealize Automation 6.2, NSX 6.x and vCenter/vRealize Orchestrator with the vCAC and NSX plugins installed and configured. We have two Logical Switches, one for Production and one for Non-Production. In addition, there’s a corresponding network profile and the business groups have reservations. Now, we have to ensure that there are security boundaries within the flat networks. We’ll accomplish this through Security Groups.
Caveats
We’ll create security groups and nod in the direction of security profiles, but will not be automating the creation of security profiles nor their assignment to the Security Group(s). That can be done by the security admins through the NSX interface or maybe later we’ll add that capability too. 😉
Procedure
Create Security Groups.
Open vSphere Web Client and navigate to Networking and Security, then Service Composer.
Click the “New Security Group” icon
Enter a Name and Description for your new Security Group and click Next
If you want to create rules for dynamic membership or include/exclude existing VMs, you can do so in the subsequent steps. Finish the wizard.
Repeat to create all of your security groups
Create Security Groups in NSX
Create Property Dictionaries invCAC/vRA.
Log into vCAC as an Infrastructure Admin and navigate to Infrastructure|Blueprints|Property Dictionary
Click “New Property Definition”, for the name enter “VCNS.SecurityGroup.Names.Production“. You can replace “Production” with a name of your choosing, so you can have multiple lists.
Select “DropDownList” as the control type and check to make it required, click the green check to save.
Create Property Dictionary
Click the “Edit” link in the Property Attributes column
Click “New Property Attribute”, select “ValueList” as the attribute type
Set the name to something appropriate, such as the same name as the Property Definition or “ValueList” or “SecurityGroups”
In the Value field, enter the names of the security groups you want included. Separate the group names by commas (no spaces). If you have groups whose names include spaces or commas, put them in quotes. Click the green check to save.
Repeat to create another property dictionary and attribute for the Non-Production list
Update Blueprints.
Edit your “production” blueprints by adding the “VCNS.SecurityGroup.Names.Production” custom property. Set the value to your default security group or leave it blank to require a selection. Be sure to check the “Prompt User” box. Click the green check to save.
Add Custom Property to Blueprint
Test
Submit a request for the affected blueprint and verify that the dropdown list of security groups looks like you expect it to. Remember, that unlike many other custom properties in vCAC (eg: Network Profiles), you CAN have multiple versions of this one and display different lists.
Dropdown list of Security Groups
After a VMis provisioned, verify in the vSphere Web Client that ithas been assigned to the expected security group
VM added to Security Group
Next
In the next parts of this series, I plan to address the problems of maintaining the dropdown list manually and having a single security group per machine.
Just a quick couple of points from the past couple of days:
vCloud Automation Center will be renamed vRealize Automation
The minimal vCAC deployment is NOT just for POCs, it is suitable for production up to ~1000 VMs
Going forward, code will be moved from .NET to Java on the appliance.
Also going forward, most work done by the DEMs and agents will be handled by Orchestrator. I like this, as it opens up even more opportunities for extensibility
For this sequence, we’ll still use part 1 to set up the Build Profile and Property Dictionary, but these steps will replace part 2 and some of part 3.
Review
Recall that for this example, the name should use the initials of the Business Group, “V” for Virtual, a single letter for the OS (“W” for Windows, “L” for Linux, “S” for Solaris, “O” for other), a three character “role” and a two digit sequence number for uniqueness.
Example Naming convention:
BG1VWAPP14
BG1 = Business Group initials
V = Virtual
W = Windows
APP = APPlication server
14 = Sequence number
vCenter Orchestrator Workflow
Create a Folder for your workflows outside of the “Library” and other folders
Inside this folder, create a new workflow. I named mine “vCAC.MachineName“. The workflow will be opened for editing.
Navigate to the “In” tab, add this attribute
Name
Type
Value
Description
CharacterToReplace
String
–
What Character in the original name will be replaced
Navigate to the “Inputs” tab, add these Parameters:
Name
Type
Description
OriginalName
string
ex: SUP-02
OperatingSystem
string
ex: Windows 2008 R2
Role
string
ex: SQL
Navigate to the “Outputs” tab, add this Parameter:
Name
Type
Description
newMachineName
string
Name created from component values
From the “Generic” pane, drag the “scriptable task” item to the blue arrow.
Default schema
Mouseover the scriptable task item in the schema and click the Pencil icon to edit the item
Edit the Scriptable Task
On the “IN” tab of the scripting task properties, click the “Bind to workflow parameter/attribute” button to add these parameters:
Scriptable Tasks IN Parameters
On the “OUT” tab of the scripting task properties, click the “Bind to workflow parameter/attribute” button to add these parameters:
Scriptable Tasks OUT Parameter
Open the Schema tab of the Workflow.
Paste the following:
var OS;
OS="O" //"O" not zero, for "Other" OperatingSystem = OperatingSystem.toUpperCase();
if (OperatingSystem.search("WIND")> -1) {OS="W"};
if (OperatingSystem.search("RHEL")> -1) {OS="L"};
if (OperatingSystem.search("SLES")> -1) {OS="L"};
if (OperatingSystem.search("SOLA")> -1) {OS="S"}; Role='V'+OS+Role.substring(0,3); //"V" for Virtual newMachineName = OriginalName.replace(CharacterToReplace,Role).toUpperCase();
I’m not much of a javascript coder, so this is probably not the best way to write this. But, it worked for me. Close the scriptable task editing window.
Back on the Schema tab of the workflow, let’s test our code. Click the “Run” button, enter some values in the fields and click submit.
Test Run workflow
When the workflow finishes, check the Variables tab on the right to confirm that the newMachineName parameter has the expected value.
Resulting newMachineName
If satisfied, click “Save and close” to save your new workflow
vCAC Workflow
There are only two changes to be made from the steps outlined here. The first is in Step 3, instead of using a variable named “PowerShellOutVar“, we’re just going to name it “OutVar” for obvious reasons. The second change is a replacement of step 7, do this instead:
From the DynamicOps.VcoModel.Activities toolbox, drag “InvokeVcoWorkflow” to the designer.
InvokeVcoWorkflow
Click the ellipsis button to display a list of the workflows in vCO, select the workflow we made earlier (vCAC.MachineName in this case). Note that you can filter on the Folder to make it easier to find.
Set the parameters
Direction
Name
expression/value
Input
OriginalName
vmName
Input
OperatingSystem
vmwareOS
Input
Role
machineRole
Output
newMachineName
OutVar
Variables & Parameters
Continue with the remainder of the steps, remembering that when you link it up in step 12, you’ve replaced “InvokePowerShell” with “InvokeVcoWorkflow“
In part 1, we configured the Machine Prefix, Property Dictionary and layout to accommodate our change. In part 2, we created and saved a powershell script to create the desired machine name from the inputs we provided. In part 3, we modified the Building Machine workflow stub to create and assign a new machine name. In this last part, we’ll finish by updating the blueprint and testing.
Recall that in Part 1, we created a Property Definition named “custom.machineRole” and a Property Layout named “machineRole.Selection”
Steps
Navigate to Infrastructure/Blueprints/Build Profiles
Create a new or edit an existing Build profile
From the “Add from Property Set”, select the appropriate “VMware*” property set for your O/S.
Save the updated Build Profile
Edit your vSphere Clone or Linked-Clone Blueprint
Confirm that the selected machine prefix is set to “Use Group Default” or is appropriate
Check the correct Build Profile for the Blueprint’s O/S. The objective here is to ensure the “VMware.VirtualCenter.OperatingSystem” property is set.
On the Properties page of the Blueprint settings, add the following Properties:
Name
Value
Prompt User
Reason
ExternalWFStubs.BuildingMachine
No
Execute the Workflow we’ve modified
custom.machineRole
Yes
The name of our Property Definition
VirtualMachine.Request.Layout
machineRole.Selection
No
The Property Name indicates that a custom layout should be employed and the value is the name of our Property Layout
Click OK to save the blueprint
Testing
Logon as a member of a Business Group that has an entitlement to the Blueprint we’ve worked on.
When requesting a VM from the blueprint, the request form should include the “Role” dropdown list with your values
The resulting request will include the “custom.machineRole” property set to the selected value
If you left the “write” lines in the PS script, you can check the C:\Scripts\nametest.txt file on the IaaS Server to ensure the values are passed and set correctly
Lastly, of course, check to see if the provisioned machine has the appropriate name
Once again…
You should visit Adam Bohle’s blog and his fantastic posts about this. He knows way more about it than I do. I stepped through his and Tom O’Rourke‘s procedures and wanted to document what it took. Those guys are the authority on vCAC.
In part 1, we configured the Machine Prefix, Property Dictionary and layout to accommodate our change. In part 2, we created and saved a powershell script to create the desired machine name from the inputs we provided. In part 3, we’ll modify the Building Machine workflow stub to create and assign a new machine name. We’ll be using the vCAC Designer, so make sure you have it installed and accessible.
Steps
Launch the vCAC Designer, Load the WFStubBuildingMachine workflow from the list.
In the “Building Machine Workflow” try/catch loop, double-click the “Building Machine” flowchart to expand it. Now, locate a double-click on the “Custom Code” flowchart to expand it. The Breadcrumb should read WFStubBuildingMachine > Building Machine Workflow > Building Machine > Custom Code
At the bottom of the designer pane, click “Variables” to display and add variables to this flowchart. Add the following variables to the Custom Code scope:
Name
Variable Type
vmName
String
vmwareOS
String
machineRole
String
PowerShellOutVar
String
machine
DynamicOps.ManagementModel.VirtualMachine
Did you notice that “mgmtContext” variable that was already in there? We’re going to use that later.
From the DynamicOps.Cdk.Activities pane, drag the “GetMachineName” object to the Custom Code flowchart box. Select/highlight it and in the properties pane, set the “Machine Id” value to VirtualMachineId, Set the Machine Name value to vmName
Again from the DynamicOps.Cdk.Activities pane, drag the “GetMachineProperty” object to the Custom Code flowchart box. Select/highlight it and in the properties pane, set the “Machine Id” value to VirtualMachineId, set the PropertyName to "VMware.VirtualCenter.OperatingSystem", set the PropertyValue to vmwareOS, leave IsRequired empty. I also set the DisplayName to GetVMwareOS because we’ll use several of the GetMachineProperty activities and need to be able to tell them apart.
Once again from the DynamicOps.Cdk.Activities pane, drag another “GetMachineProperty” object to the Custom Code flowchart box. Select/highlight it and in the properties pane, set the “Machine Id” value to VirtualMachineId, set the PropertyName to "custom.machineRole", set the PropertyValue to machineRole, leave IsRequired empty. Set the DisplayName to GetMachineRole so we can tell at a glance what it’s doing.
Drag the “InvokePowershell” activity to the Custom Code flowchart box, under the GetProperty activities.. Just like previously, select/highlight it and populate the properties on the right. This activity has several more properties than the others, but we’re only going to be using a few. First, check the “IsScript” box to indicate that the CommandText value points to a PowerShell script. Then, set the Commandtext value to the path (in quotes) to the PS script you saved on the IaaS Server; "C:\scripts\CreateNewMachineName.ps1". Lastly, click the ellipsis button beside PowerShellVariables to set them. Add the following PowerShell Variables (these should look familiar, from Part 2):
Name
Direction
Type
Value
vmwareOS
In
String
vmwareOS
machineRole
In
String
machineRole
originalName
In
String
vmName
PowerShellOutVar
OUT
String
PowerShellOutVar
Click Ok to save the Powershell Variables
From the “Primitives” section of the toolbox, drag “Assign” to the custom code flowchart box, under or beside the InvokePowershell action. Admittedly, this thing is somewhat confusing. It’s used to instantiate an object from the database for manipulation. You cannot just update the MachineName property in the request, you have to pull the machine object out, set the property on the object, then push the updated object back into the database. So, select/highlight your “Assign” statement object and set the “To” property to machine and the “Value” property to mgmtContext.VirtualMachines.Where(Function (vm) vm.VirtualMachineID = virtualmachineId).FirstOrDefault()Thanks to Tom O’Rourke for that LINQ query!
Drag another “Assign” statement next to the first. This one will be used to assign the value from our PowerShell script to the virtualmachinename property of the machine object. So, set the “To” property to machine.virtualmachinename and the “Value” to PowerShellOutVar
(Almost done) From the “DynamicOps.Repository” section of the toolbox, drag an “UpdateObject” activity object to the Custom Code area. Just as before, select/highlight it. Set “DataServiceContext” to mgmtContext. Set “Instance” to machine. That’s it.
Also from the “DynamicOps.Repository” section of the toolbox, drag a “SaveChanges” activity object to the Custom Code area. Just as before, select/highlight it. Set “DataServiceContext” to mgmtContext
Link it up! Use the tabs that appear on the side of the objects to connect them in the following order: Start -> GetMachineName -> GetVMwareOS -> GetMachineRole -> InvokePowerShell -> Assign (machine) -> Assign (machine.virtualmachinename) -> UpdateObject -> SaveChanges
Click “Send” to save your updated version of the workflow to the database
Important Aside
You should visit Adam Bohle’s blog and his fantastic posts about this. He knows way more about it than I do. I stepped through his and Tom O’Rourke‘s procedures and wanted to document what it took. Those guys are the authority on vCAC. Background
Machine Prefixes in vCAC allow administrators to set a standard name for machines provisioned by members of a Business Group. The default is simply an alphanumeric prefixing a number. For many (most?) organizations, this is not sufficient and the provisioned machine names should comply with a corporate standard.
Solution Overview
I’m looking for a fairly simple method to apply a compliant machine name that can be used by multiple Blueprints, Business Groups and Reservations.
For this example, the name should use the initials of the Business Group, “V” for Virtual, a single letter for the OS (“W” for Windows, “L” for Linux), a three character “role” and a two digit sequence number for uniqueness.
Example Naming convention: BG1VWAPP14
BG1 = Business Group initials
V = Virtual
W = Windows
APP = APPlication server
14 = Sequence number
Create a new Machine Prefix that will be used by your Business Group. I used the machine prefix BG1- and set the number of digits to two.
Machine Prefix to be used by Business Group
Did you notice the dash in the machine prefix? That’s important because in this example, I’m going to replace that dash with the additional information. This way, we retain the Business Group-specific prefix and the vCAC-generated sequence number.
We want to provide our users with a dropdown list of “roles”, so that they can indicate which is appropriate for the requested VM. We do this by using a property dictionary. Navigate to Infrastructure|Blueprints|Property Dictionary
Click “New Property Definition” and fill out the fields. In this case, lets name it custom.machineRole, set the Display Name to Role, the Control Type to DropDown and Required.
Setting up the Property Definition
Click the Green check to save
On our freshly-baked Property Definition, click “Edit” under Property Attributes
Click “New Property Attribute” and fill out these fields. Here, we’ll set the Type to ValueList, the name to custom.machineRole and the Value to “APP,CTX,DEV,ORA,SQL,VDI,WEB” (or whatever comma-delimited list you wish) Set the Property Attribute
Now, we need to ensure our dropdown is displayed correctly on the blueprint. So, we’ll create a Property Layout. Just like before, click “New Property Layout”, give it a name – I used “machineRole.selection”. Enter a meaningful description.Green check to save
Click Edit under “Property Instances” on our new Property Layout, and select custom.machineRole from the dropdown. Set the Order to 1 (since it’s the only one property definition we’re concerned with right now). Green check to save. Click OK to exit Property Instance editing.
Brian Ragazzi 