Home > Blogs > VMware vCenter Orchestrator Blog > Tag Archives: vco

Tag Archives: vco

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.

Master of the integration – conquer VMware vCloud Director blocking tasks with the powerful vCenter Orchestrator plug-ins

One of the upcoming features of VMware vCloud Director is Blocking Tasks (call-outs). This enables a system administrator to configure many operations to block. They can be ublocked later by another application or can expire after a timeout. These blocking tasks generate AMQP messages that can be used to automate actions over them. This blog post shows vCO flexing muscles over blocking tasks. Doing this requires several plug-ins: AMQP, HTTP-REST, ActiveDirectory and Mail.

Whenever a vApp is created by an user in the vCloud Director the task is suspended and the user's manager receives a notification mail providing link for approval of the operation. When he approves, the vApp creation task continues in the vCloud Director. This is achieved by using a different plug-in on every step. AMQP plug-in is used to handle the blocking tasks notification messages. The HTTP-REST plug-in is used to communicate with the VMware vCloud Director over its RESTful interface. Active Directory is needed to find the user’s manager in the company's active directory database. Finally, the approval email is sent using the Mail plug-in. Webviews are used to build a simple web-based interface that the manager uses to approve or reject the vApp creation.

At the end of this article you can find links to a vCO package containing theexample and a video demonstrating the scenario. Jump right to the video at the end or read the details below describing  some technical aspects.

The message sent by the vCloud Director for the pending vApp creation is handled first by the AMQP plug-in. The next few lines of JavaScript show how to configure the subscription for the message. Note how the routing key is constructed. The detailed strucutre of the routing key is described in the vCloud Director documention.

Image1_setup_scripting

After its execution this script will create a new Subscription element in the AMQP plug-in inventory:

Image2_subscription_inventory

This subscription is ready to be used for a policy that will listen for vApp creation messages:

Image3_policy

The workflow is started by the policy on every message and does the rest of the work:

Image4_workflow

The user must define the vCloud Director as a REST host in the inventory:

Image5_rest_inventory

And then use it in the scripts to build the request URL:

Image6_rest_script

The VMware vCloud Director REST API responses are XML documents but handling them is easy with E4X (ECMAscript for XML):

Image7_xml

When the manager follows the web link in the notification mail he is brought to a web page showing again the request details enabling him to take an action on it:

Image8_webview1

Behind the scene the approve and reject buttons are handled by a script that answers the user interaction of the blocked workflow. When decision is taken the workflow continues and notifies the VMware vCloud Director to resume or cancel the pending task.

To get your hands dirty with this demo follow the link to the package that contains the example. It won’t work out of the box because the AMQP broker and the VMware vCloud Director configuration must be updated to match yours. Also the message handling policy must be manually created since policies cannot be distributed in a package.

Here is a video demonstrating the whole scenario:

 

Browsing the Netflix catalog using the vCO HTTP-REST plug-in

Here is another example how to use the new vCO HTTP-REST plug-in. Let's  browse the Netflix movie catalog using vCO. We will implement a workflow that retrieves all available titles given a simple query.

First thing we need to do is define our Netflix REST host.

NetflixRegister

Then we define operation for searching the catalog:

CteateOperation

Netflix REST  API is documented here. The REST operation made accepts a single URL parameter called term. It can be any string. The created REST host and the operation could be seen in the vCO inventory:

Inventory

Let's test the operation using the generic Invoke a REST operation workflow.

Invoke

The successful execution of the workflow looks like this:

InokationResult

It looks like there are many titles found for "Transformers".

Let's generate a workflow from this operation using Generate a new workflow from a REST operation.

Generate

We need to specify the operation, give a name for the new workflow and specify the destination folder for the generation result. Let's customize the new workflow to only return the titles.

CustomizeWorkflow

We edit the first scripting activity in the workflow by adding the following few lines:

var doc = new XML(contentAsString);

var titles = doc..catalog_title..title.@regular;

for (i in titles) {

    System.log(titles[i]);

}

 

This JavaScript code parses the xml response from Netflix. JavaScript has native support for xml which makes it very easy to extract information from xml documents. This feature is called E4X (ECMAscript for XML). Here is the result from execution of the customized workflow:

New_workflow_Execution

Consuming RESTful web services is very easy with the vCO HTTP-REST plug-in. With a few easy steps you are able to create a customized building block in the form of a workflow. Using ECMAscript for XML for handling XML you can easily manipulate the response. 

Delivering VMs into vCloud Director with vCO

When starting with vCloud Director the most asked question I receive is: "How can we deploy our customized VMs into the vCloud Director?". The reason is that a VM template or vApp is used for vCloud Director.

With this example I want to show how easy it is to build a VM and deliver it to the vCloud Director using vCenter Orchestrator and it´s plug-ins.

Of course, there are several methods to automate these imports:

  • clone a customized VM into a VMware template for vCD import
  • choose and transform an existing VM into a vApp

The following simple example is based on the workflows "Create simple virtual machine" and "Import VM as vApp" and a little scriptable task for MoRef (ID of the VM) translation. Both workflows are standard workflows, delivered with the vCO library and vCD plug-in.

Bildschirmfoto 2011-06-04 um 10.54.02

To keep it simple I used some static inputs (datastore, host-system etc.). In real environments I automate these too, like choosing the datastore based on free space and left space. With these static parameters the inputs are reduced to:

Bildschirmfoto 2011-06-04 um 11.01.06

In most environments there are some specific steps for the customized deployment of a virtual machine, like Altiris trigger for Windows or ssh deployment commands for Linux, but there is no deployment server in my lab 🙂

The small scriptable task in the middle is used for delivering the MoRef ID of the new VM as input for the "Import VM as vApp" workflow:

Bildschirmfoto 2011-06-04 um 11.08.50

After all inputs and attributes are defined, I start the workflow and look into the vSphere Client to check the state of the deployment:

Bildschirmfoto 2011-06-04 um 10.53.30 

Also I check my vCloud Direcor App catalog for the new vApp template:

Bildschirmfoto 2011-06-04 um 11.13.16

And finally my new VM is deployed and registered in the vCloud Director as a new vApp template in my Application catalog. For sure this is only an example to show the direction. In normal use cases there a few things more to do:

  • ensure that applications are proper installed and able to get cloned
  • define a application catalog for the right departments (HR for example)
  • setting the right users and groups

So, get your feet on the street and test it!

 

 

Automate (the Cloud) or Die

If you ask 10 different people for their definition of Cloud computing, you’ll likely get 10 different answers, not to mention the occasional wise remark about an open-air or floating datacenter.  While all response details will vary, each answer is guaranteed to include two fundamental concepts: “self-service” and some “behind-the-scene magic to fulfill my request (right now, please… as I’m in a hurry)”.

From a cloud consumer perspective, the instant gratification is what makes the cloud magic so attractive.  For a CIO or CFO, it’s the short-term promise of greatly reduced capital AND operational expenditures. 

For the public and private cloud providers (the IT Infrastructure and Operations groups), that magic is more often associated with a downright terrifying set of expectations and realities:

  • Drastically reduced service delivery times
  • Larger, unpredictable volumes of provisioning and decommissioning operations
  • Greater complexity in not just provisioning but maintaining complex, dynamic, multi-layered services

The only constant in cloud environments, and only in the best of cases, is the size of the provider’s IT staff.  If you believe that the current IT management models will work, think again (and read To Unlock the Power of the Cloud, Rethink IT Management).  Regardless of the tools or number of staff available in an IT organization, there’s only one kind of magic that can scale to meet the demand and economics of cloud computing: Automation.

The alternative is simple: death.  OK, so we’re only talking a virtual death here, but yes, you can definitely expect your internal or external customers to procure IT services elsewhere if you don’t automate.  Virtual computing resource price lists are only a click away and it’s getting easier to move around workloads.

Obviously, automation is not a new concept.  It’s much, much older than virtualization and even precedes the software era (yeah, seriously 🙂 ).  Since the introduction of software, the most common form of automation has been and continues to be scripting.  Even today, it continues to serve a very valuable role for many discrete operations (more to come about this subject in an upcoming blog).  But when it comes to automating much of the magic in the cloud, there is no better solution today than a well orchestrated, cloud-purposed, IT management suite.

And this is where vCenter Orchestrator comes in.  Our mission is quite simple: to enable the VMware cloud stack to integrate with our customer’s environments AND processes, thereby dramatically reducing their costs and accelerating service execution.  In short, To Automate the Cloud.

Practically, what does this mean?  Well, thanks to increased R&D investments along with contributions from VMware partners, be on the lookout throughout the year for many more out-of-the-box workflows similar to the VMware vCloud Director and Cisco UCS Manager plug-ins.

We are also quite aware that automation will not become pervasive until it can be deployed in minutes rather than hours or days (remember, it’s all about instant gratification).  So yes, we are working on that too.

In the meantime, thanks for continuing to use vCenter Orchestrator and, to end with another but less dramatic cliché, the best is yet to come 😉