Home > Blogs > VMware vCenter Orchestrator Blog > Monthly Archives: October 2011

Monthly Archives: October 2011

The VMware vCenter Orchestrator Appliance Is Now Available!

Whenever we run into a VMware customer who is not using vCenter Orchestrator, it usually comes down to one of two things: 

  1. Not being aware of vCO's existence (and yes, we admit we have a lot more education to do in that area)
  2. Getting stuck on one of the initial configuration steps (and let's face it, configuring directory services and databases is not everyone's cup of tea)

Well, we're extremely glad to announce that vCO is now available as a preconfigured virtual appliance. This appliance significantly reduces the time and skills required to deploy vCO, allowing you to get up and running in under 15 mins.

And even if directory services have no secret for you, you can find comfort in the fact that the new appliance provides a low-cost alternative to the traditional Windows-based installation. In a sense, the "free" (vCO is included with vCenter Server) just got "even more free" 😉

The vCenter Orchestrator Appliance is an OVF (Open Virtual Machine Format) that is pre-built and pre-configured with Novell SuSE Linux Enterprise Server, PostgreSQL, and OpenLDAP, and can run on vCenter Server 4.1 and higher.

It offers tremendous flexibility yet makes no compromises on performance, making it ideal for a wide variety of use cases:

  • Product evaluations and proofs-of-concept
  • Development
  • Test
  • Production, including on a large scale

The appliance offers all of the components included in the regular Windows-based installation, along with the flexibility to use either the pre-built directory services and database, or to use external ones like Active Directory or Oracle for example.  What's more, the appliance has been certified to run at the same performance as the traditional Windows version.

In short, the vCenter Orchestrator appliance makes it even faster, easier, and more affordable to integrate the VMware cloud stack with your IT processes and environment.

To give it a try for yourself, please check the following sources of information:

 

No Code Workflow Reconnects ESXi Hosts

This example shows that one can do useful things without writing JavaScript code in vCO.
 
Ever since the vSphere 5 upgrade, cold booting my home lab (which I generally do because I’m not going to pay to leave it running all the time plus it is noisy and it heats up my office) requires re-connecting my ESXi hosts. 

I was tempted to write a Perl script or use PowerCLI but given my focus on vCO and with the new the vSphere 5 plugin, I thought, “I’ll write a workflow!”
 
So I started by looking at what was there and thinking it would be cool to do this in vCO without writing any JavaScript.
 
I easily found the delivered workflows for “Disconnect host” and “Reconnect host”.  

Nocode-1

Trying those one at a time on one of my ESXi hosts and they worked perfectly.  Great.  These are my first building blocks.
 
Next I thought, “Ok, now I will sequence these two flows.”  No biggie.  I created a new workflow called “Disconnect Reconnect ESX Host”.  In the schema, I dragged a workflow item, select “Disconnect host” and repeated for “Reconnect host”.  Add the “End Workflow” item then link together.  

Nocode-2

Next I clicked “Validate” and took the quick fix option to create an input attribute for “ESX host” which both embedded workflows can now share.  

Nocode-3

Nocode-4

Nocode-5

I tried the flow on one of my ESXi hosts.  It worked great.  Cool.
 
So then I said, “Now I need to loop through all my ESX hosts in my lab cluster.”  Hmm, I remember Burke Azbill has shown me how to do this multiple times. J  And after a quick search I found it (again):  http://www.vcoteam.info/learn-vco/creating-workflow-loops.html
 
But I’m thinking that looks like too much work and I’m lazy.  Besides, I would rather fall back on my bad habits and just write a “foreach” loop in JavaScript and call the workflow in the script.  Not very “orchestrator-like” but I’m more of a “Perl” guy.  I resisted the temptation.
 
“Well, maybe I can just use what is there in vCO and not write something.  (I am so lazy.)  Hey, what about that Batch thing.  Yeah, baby.”

Nocode-6

Since I had just added a new workflow that takes a single ESX host as input which qualifies to run from the batch workflow, I ran the “Fill batch configuration element”. Now I will be able to reference my “Disconnect Reconnect ESX host” workflow.

Now I want to verify that I can run my new workflow from the “Run a workflow on a selection of objects”.  I chose ESX host as the object type, selected the Action “GetallHostSystemsofCluster”, using my cluster for the input and then chose my “Disconnect Reconnect ESX Host” workflow.  

Nocode-7

Outstanding, it cycled through my ESXi hosts disconnecting and then reconnecting each one very quickly.
 
Lines of code written: ZERO.
 
But you know I am really, really lazy.  How can I run this batch workflow without having to go through and configure all the inputs each time?  It was time for another workflow.  I remember Christophe Decanini telling me this could be done.
 
Ok time for one more workflow to setup and call the batch workflow the way I want for this job.  I called it “Disconnect Reconnect All ESX hosts of Cluster”.  Add one workflow item which is the “Run a workflow on a selection of objects”, add the “End Workflow” item and link it together.

Next I used a trick that Christophe Decanini taught me.  “Synchronize presentation” shows when you right-click on the embedded workflow.

Nocode-8

This adds all the attributes of the embedded workflow as inputs to the current workflow.  While this is pretty cool, remember that I want to run this without any inputs at all.  Ok, there is a quick fix for this.  Move all the inputs as attributes.  Click on the top input, then Shift-Click on the bottom input.  When all the inputs are selected, right-click and choose “Move as attribute”.

Nocode-9

Now the visual binding looks like this:

Nocode-10

This is a complex workflow but I only need a few of the parameters.

Now all that is left is to set the defaults that I want for my lab to run this specific job.  This was actually pretty easy by looking back at the successful run of the batch flow previously and observing the variables that were actually used and their values.  

Nocode-11

The objectType is a string and the value needs to be “Host”.  Not exactly intuitive but there it was in the variables from my previous run.  I used the same Action “GetallHostSystemsofCluster” as before and selected my cluster for the input to the Action and finally chose my “Disconnect Reconnect ESX Host” workflow.

Nocode-12

“Look Mom, no parameters for input!”  And it worked fantastic.  No loop code in JavaScript or multiple vCO scriptable tasks, decision items, etc…  Dirt simple really.

This is good enough for me but if I am going to share this with others, I don’t want the workflow referring to the cluster in my lab.  So the one last improvement is to use a Configuration instead to reference the cluster to use.  This way you can set the Configuration to reference your cluster.  Create a new folder and element for the Configuration.

Nocode-13

Then edit the Configuration and add an element setting the Type to VC:ClusterComputeResource. I called it “MyCluster” and set the default value to point to “Cluster1” in my lab.  Yes, this is quite the outstanding name, don’t you think?

Nocode-14

Finally, I went back to the workflow and updated the “cluster” attribute default value to reference the configuration element.  Click the little symbol in the Configuration column.

Nocode-15

Now pick the “MyCluster” Configuration element.

Nocode-16

Finally, I created of Package of my work and saved it out for safe keeping.

Cheers!

Bill Call
Central Region US Principal Systems Engineer
Solution Specialist vCloud/Chargeback

Bill has been at VMware a relatively long time (8+ years) and has worked with various automation tools over 25+ years in IT.