vCloud Automation Center – vCAC 5.1 – Custom Properties Demystified

Caution: Articles written for technical not grammatical accuracy, If poor grammar offends you proceed with caution ;-)

vCAC utilizes custom properties in many different ways. They can be very useful if properly understood. To start with there are two high level classifications for custom properties. Those are:

• Reserved Custom Properties – These are properties that vCAC understands and utilizes as part of it’s operations. vCAC has hundreds of reserved custom properties that it utilizes. These can be explored further at the end of the vCAC 5.1 Operating Guide.
• Non-Reserved Custom Properties – These are properties that you can create on your own. These can simply be utilized to attach metadata to a machine, or they can be utilized within custom workflows and scripts.

Reserved Custom Properties

Reserved custom properties come in four different types:

• Internal Properties – Internal custom properties are for vCAC use. These properties hold information relevant to features within vCAC such as approvals which don’t leverage any external systems.
• External Properties – External custom properties are used for configuration outside vCAC. Properties that utilized to customize a provisioned machine are external custom properties. An example of this would be a property that defined the drive letter and label to be assigned to a disk inside a machine. (Note: If the values change on the provides machines they do not get updated in vCAC. The properties are utilized at provisioning time to perform the configuration only)
• Read-Only Properties – Read only custom properties represent values such as the UUID of a virtual machine that cannot be changed or altered on the virtual machine or within vCAC.
• Updated Properties – Updated custom properties represent items that can be changed and the updates reflected in vCAC. For example if the memory associated with a virtual machine were update through vCetner, when vCAC did it’s next docovery it would detect the change and update the property value for memory associated with the virtual machine.

Reserved custom properties are integral to the operation of vCAC. The properties are utilized by the built-in workflows to perform specific tasks as well as enable features. All machines in vCAC have a minimal set of properties that are attached to them for vCAC to be able to perform it’s functions. If we look at a vCenter virtual machine you will see these properties association with each one:

• VirtualMachine.Admin.AgentID – An “Internal” custom property used only by vCAC.
• VirtualMachine.Admin.HostIdentity – This represents the “vSphere Host” the machine resides on and is an “updated” custom property.
• VirtualMachine.Admin.TotalDiskUsage – An “Internal” csutom property used only by vCAC.
• VirtualMachine.Admin.UUID – A “Read Only” custom property that represents the UUID if the virtual machine.
• VirtualMachine.CPU.Count – An “External” custom property used to allocate CPU resources to the virtual machine.
• VirtualMachine.LeaseDays – An “Internal” custom property used to track the lease of the virtual machine.
• VirtualMachine.Memory.Size – An “External” custom property used to allocate memory to the virtual machine.
• VirtualMachine.Storage.Name – An “Updated” property that tracks the datastore the virtual machine resides on.
• VMware.VirtualCenter.OperatingSystem – An external property that is actually defined by the administrator to inform vCenter of the Operating System for the Virtual Machine.
• Vrm.ProxyAgent.Uri – An “Internal” vCAC custom property.

Depending on the type of provisioning being used there may be more properties that what is listed above, but this is what a basic machine provisioned with cloning to vCenter would look like. You can further customize the machine by adding additional custom properties. Some get automatically added based on the configuration of vCAC. If you were to leverage approvals properties would be automatically added based on that configuration. You can also manually add additional properties to perform other actions. An example would be:
 
VMware.VirtualCenter.Folder – This property can be defined to dictate the folder that the virtual machine should be placed in within Virtual Cetner.
 
There are hundreds of properties that you can utilize that come with vCAC to further configure the behavior of vCAC.

Non-Reserved Custom Properteis

You can also crate your own properties that get attached to the virtual machines that don’t automatically trigger any event to occur. The properties can simply be attached as meta-data that you want to use to track information or they can be utilized by custom workflows or scripts that you create. AN example of this would be:
 
Cost.Center – If you wanted to track the cost center a machine was to be billed you, you could define a property like this. You can then leverage this for reporting or as part of an integration to a billing system.
 
You can call your properties anything you like however there are a few things to keep in mind:

• Properties are case sensative
• Do not use special characters
• Do not use reserved vCAC properties
• Do not use spaces

When defining custom properties you can choose to define a value that will be attached to machine, or you can elect to “prompt” the user to input a value for the property. There is also a feature named the “Property Dictionary” that allows you to crate drop down lists, check boxes, and other inputs that can be selected by users at request time. The “Property Dictionary” will be covered as a separate article.

Custom Property Placement

You can place custom properties within many different areas of vCAC. It’s important to understand where you can place your properties and how the different layers override with one another. Understanding this will allow your vCAC configuration to be very efficient and flexible. Custom Properties can be placed in the following areas:

• EndPoints
• Compute Resources
• Reservations
• Provisioning Groups
• Build Profiles
• BluePrints
• Storage (Within BluePrints)

There are many reasons why you may want to place a property in anyone of the above areas. If you wanted to define something that was very specific to the vCenter environment as a whole you may put it at the “EndPoint” that manages the vCenter. If you wanted to define a property that was location specific you might use the “Compute Resource” considering these represent hosts or clusters which are tied to physical servers at a physical location. maybe it’s specific to the group so you may leverage the “Provisioning Group”, or if it’s specific to the machine build you could place it at the “BluePrint”. These are just a few examples, but make no mistake the ability to place values at these various locations gives you great flexibility to meet your specific needs.

Build Profiles

Build profiles allow you to create sets of properties that can re-used over and over by attaching them to blueprints. This make it’s easy to create re-usable content as you configure vCAC. Let’s say you wanted to define an additional disk configuration that you were going to utilize for all SQL Server Blueprints that you created. You could create a “Build Profile” that had all the properties to create the additional disks including the size of the disks, the disks drive letter, and label that is to be assigned.

Property Overrides

Depending on your needs you may want to define the same property at different locations withing vCAC with the understanding that one will override the other. To be effective at doing this you need to understand how overriding works within vCAC. Below is a chart of what wins when the same property is defined at different areas within vCAC. You can download a PDF version of this chart here.
 

Down he left side of the chart you will see the the levels where competing properties are defined and along the top is all the areas. An “X” will be in the box for the property that wins.