Automation 101: vCenter Orchestrator – Set Custom Attributes

vCenter Orchestrator… It’s power is only exceeded by it’s mystery. Or so we thought… We’ve touched on vCO a number of times in the past. So much so that I’m actually writing a book on it (Yes that was a shameless plug…).  What follows now was a special request from Maish Saidel-Keesing brought about by a conversation about when and where to use vCO.

Specifically, he wanted to know not only if it were possible to set custom attributes, but to first check if they’re present, then if not, set them, and to do this on a re-occurring basis. What follows will be a lot of text followed by a download link to the completed workflow.

The steps I used to get to Maish’s end goal were:

1. Look at the existing workflows
2. Duplicate the “Add custom attribute to multiple virtual machines” workflow
3. Add some logic
4. Test

Existing workflows

The vCenter library for vCO ships with a number of really handy workflows. Taking a look over them, you can generally find one that will fit your needs readily. In this case that workflow is “Add custom attribute to multiple virtual machines”. The Schema of which is shown here:

Rather simple, no? You can actually run this one directly to add or set custom attributes to any of your VMs. However, remember, we need to check if they’re present first, and turns out, we want to check all of our virtual machines, so…

Duplicate the workflow

We duplicate the workflow, right click, duplicate. Yeah… that easy.

Add logic

Now comes the fun part! First let’s look at the new schema, and then discuss the various bits:

Not much more complicated than the first one, right? There is quite a bit going on here however. Let’s first look at the “Set variables” scripting block. It takes vms and count as inputs, and returns the same as outputs. There is also some scripting:

Set variables

count = 0;

// Get an instance of the VcPlugin
var myVcPlugin = new VcPlugin();

// Get a list of all VMs
vms = myVcPlugin.allVirtualMachines;

You can pretty well tell from the comments what’s going on, but take a closer look at the VcPlugin line. What we’re doing here is grabbing onto the vCenter API as it’s exposed in vCO, sort of like adding the PowerCLI snap-in to PowerShell.

Loop VMs

If you’re familiar with UML, this is a “decision” block. More specifically, in vCO this one is a “Custom decision block”. Basically it means you can use some code to make the decision for you. Again we take as inputs vms and count and use the following code to make the decision:

// Check if we have processed all VMs
if ( count < vms.length ){
    return true;
} else {
    return false;
}

Straight forward, true if there are VMs left to go, otherwise end the loop.

Set custom attributes

The next script block is where the rubber meets the road. This time we take all of the variables as input to work with. Then we check to see if the attribute is set. If it’s not, it will be:

// Check if the custom value is set, if so, start loop over. Otherwise set it.
$customValueSet = System.getModule(“com.vmware.library.vc.customattribute”).getCustomField(vms[count],customAttributeName);

if ( $customValueSet == null){
    System.getModule(“com.vmware.library.vc.customattribute”).setOrCreateCustomField(vms[count], customAttributeName, newValue);
}

Increase counter

This one could likely have been embedded into the code above. However, it was added to increase the clarity of what’s going on in the workflow. Literally when using the “Increase” counter schema object, you can only set the variable it increases, so that’s what was done, both input and output are “count”

Testing

While the testing was a bit more drawn out than this, but we’ll do the Rachel Ray special and show you what it looks like at the start and at the end with the hope it does well in your oven.

Start:

End:

Download

The exported workflow should you want to use it as is can be downloaded here.

Why this over PowerCLI?

Yes yes I know this can be done in PowerCLI. So why not? Well, consider a number of things: How many VMs are you processing today with the script? How many in the next month? Next year? What will that do to the time the script takes to run? What if the script fails during the run, will it pick up where it left off? Maybe it’s not as important with this workflow, but consider some of the other things you may do.

vCO will pick up here it left off using tokens and it’s robust scheduler. It also has some more robust logging available should something be “not right”. (Yes you can make PowerCLI pick up where it left off and such, and be verbose in the logs…)

More!

Joerg Lew took and applied some real use cases to this:
http://www.vcoportal.de/2011/06/vco-custom-attributes/

If you found this useful or have applied it in your own unique way, let me know!

Summary

Seems the vCO posts are some of the more impressively log posts. However, it is quite the useful tool once you get the hang of it. If you’ve a question or comment, drop a line in the comments or ping me on Twitter here.