Cody Bunch, Author of the upcoming book about vCO, postet an great article about how to set Custom Attributes in vCenter’s Inventory within Workflows:
http://professionalvmware.com/2011/06/automation-101-vcenter-orchestrator-set-custom-attributes/
Reading that made me think about use-cases for Custom Attributes and vCO in real-world projects:
- “Implicit” documentation: Custom Attributes that include contact information of the Virtual Machine Owner, Purpose of the VM, …
- Containing Metadata about the VM: Relations to certain Backup-Jobs/Strategies, Test/Dev/Production-State, isInMaintenance, creation and expiration date, …
- “progress bar”: During a longer running deployment process, the workflow updates the deployment stage (thanks, Andreas 🙂 !)
The Scheduler in vCO can be used to run maintenance workflows for the custom attributes on a regular base, e.g. to force the VM Owner to check his contact data for updates, decommission expired virtual machines, …
Two things to keep in mind:
- The custom attributes are plain strings!
So be carfeul when working with dates, numbers or enum-information there, you have to do some effort to parse the strings to convert it back to the source/target JavaScript datatype in vCO. - Custom Attributes are changeable via vSphere client!
User’s can edit these fields without any knowledge about the workflows at all, which allows the user to bypass any business logic in your workflows.
So make sure to validate the information you read from the attributes (and consider other places to store information which is essential for the business logic of your workflows).
(You could also think about some security issues when somebody inserts bad values which cause your workflows to behave bad.)
A small example how to validate a date which is stored in a custom attribute:
//Get expiration date string, cast/parse to date
var datStr = System.getModule("com.vmware.library.vc.customattribute").getCustomField(managedEntity, custField); System.debug("datStr: " + datStr);
try {
var expirationDate = new Date(Date.parse(datStr));
System.debug("isDate: " + (expirationDate instanceof Date));
System.debug("value: " + expirationDate);
if (!expirationDate) throw "No valid expiration date in custom fields for " + managedEntity.name;
} catch (ex) {
throw "Cannot parse expiration date for VM " + vm.name;
}
return expirationDate;
For the future: There are some signs in the API for another, more powerful way to add metadata to vCenter Inventory Objects: Tags. See the “sneak preview” on Steve Jin’s great blog:
http://www.doublecloud.org/2011/06/tagging-an-invisible-feature-in-vsphere/
http://www.doublecloud.org/2011/06/tagging-what%e2%80%99s-the-alternative/
Steve Jin: VMware VI and vSphere SDK
David Flanagan: JavaScript – The Definitive Guide
).
Marijn Haverbeke: Eloquent JavaScript
Cody Bunch: Automating vSphere: With VMware vCenter Orchestrator
Hi Jörg,
just a few comments from me.
The (actual) three custom attributes shown (and editable) in vCenter (global, vm, host) should only be used for showing informations, or you have to restrict access to this fields to prevent changing.
But most other objects have this property too. E.g. I’m using custom attributes of VcDatastore to mark a DS claimed by a special VM to reduce filer requests. This values are not visible in VC and so they could not be changed easily.
It is a nice hidden special value store, but don’t blast it :-). Values are stored in vCenter DB.
Regards, Andreas
Thx for clarification!
Also vCO has custom attributes on any inventory object. You can use these to extend these objects with new properties and they accept any vCO object for a value. For example you can add a custom attribute called “Original template” on a VM / vAPP linking directly to the object.
Good one! And thanks for the real world example (vCO helping out some lacks in vCD? 🙂 )