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

Tag Archives: VMware vCenter Orchestrator

How Much Javascript Do I REALLY need to know for VCO?

I find vCenter Orchestrator to have an extensive library of workflows, actions, and plugins to do what I need.  However, sometimes I do have to use the customizable Scriptable Task element to customize the behavior of a vCenter Orchestrator workflow.  Thankfully, this is super easy to do as the Scriptable Task is a very powerful element that allows me a full range of programmatic manipulation using the simple, open language of javascript.

When I use the Scriptable Task 99% of the time what I need to do centers around if/then/else, loops, data structures (arrays, objects), common method calling (the System object, the Server object, and plugin objects) variable retrieval (vm.config.hardware.numCPU), and string transformation (character strip, match, substring, format, etc).  So what does that really look like?  In this example our vCloud Automation center needs to add a machine to AD as part of the post provisioning process.  The “ou” parameter is passed in to the vCO flow, and we will use the AD plugin to search for the AD:OrganizationalUnit object and assign that object to the “group” variable. The group variable gets bound as an “Attribute” in our workflow and then passed in to the “Create a computer…” workflow element in order to add the server to the specified OU.  But first we must do some basic error checking to determine if the group exists first.

This could be a 7-10 element flow if you used the flow control elements and the Active Directory Plug-In actions in a flow.

OR – we could just use a Scriptable Task, grab those input vars, and use the AD object from the AD plugin in javascript!

A little if/then/else error checking, and then pluck the first matching group off of the returned array – DONE!

WHEW* simple right?  ;-)

Also, some best practices around flow creation with Scriptable objects is that you are creating re-usable packages.  So each one should be a short block of about 20-30 lines, and you should try to rename them that describes what they do.  For example:

It’s easier to understand what this does:

Than this:

Laying out your flow with Scriptable Tasks first, renaming them, and then filling in the javascript afterwards might also help you plan your workflow and save you time in the long run.

If this post just scared you a little (and I completely understand if it did), you can read more on best practices at www.eloquentjavascript.net.  Also, if you’re looking to refresh some of your javascript skills I recommend spending an hour on CodeCademy.com, which has a free, interactive javascript course you can take using your browser.  Remember to focus on the data structures and language elements I specified above.

Article by: Jennifer Galvin – Sr. Systems Engineer

VMware vCenter Orchestrator 5.5 is now GA!

As part of the of the vSphere 5.5 announcement, we are extremely glad to share the general availability of vCenter Orchestrator 5.5 !

Large organization will greatly benefit from the enhanced cloud-scale architecture, out-of-the box high availability of the platform, and major improvements to the REST API.

Additionally, workflow developers can enjoy a more efficient development experience thanks to the new debugging and failure diagnostic capabilities in the vCenter Orchestrator client.

We continue enriching the vCO plug-in intelligences and number of integrations with variety of partner applications, including management systems from EMC, F5 Networks and NetApp. Please, refer to the VMware Solution Exchange for a complete listing of the available vCenter Orchestrator plug-ins.

 Optimized for growing clouds

vCenter Orchestrator 5.5 is greatly optimized for growing clouds thanks to significant improvements in scalability and high availability. The cluster mode configuration enables a collection of vCO orchestration nodes to work together, sharing a common database and provides high availability of the workflow execution in case of orchestration node failure. In addition, our extended REST API allows automatic installation and configuration of the necessary vCO server nodes. It also provides dynamic scale-up and scale-down of the orchestration capacity when vCenter Orchestrator is being used in conjunction with an external load balancer.

Workflow Debugging

The vCenter Orchestrator 5.5 client is fully equipped with a workflow debugger, allowing vCO workflow developers to easily test and fix their custom workflows. In case you want to re-run an extensive workflow from a common point of failure, you are able to configure and resume the execution from the last failed state of the workflow.

Security Enhancements:

The vCenter Orchestrator 5.5 appliance contains a complete set of security improvements, including Operating System updates and security hardening script enhancements, which seamlessly secure your orchestration deployment and reduces the platform surface of vulnerability.

Last but not least, you’ll still be able to leverage all of the workflow you’ve already created in the previous release and be able to run them seamlessly in version 5.5.

These are just the major new capabilities but you’ll find plenty of additional enhancements that make the automation and integration of your software-defined datacenter easier than ever before. For a full list of new features and capabilities, please refer to the detailed overview or the release notes.

As a reminder, in 2013, we continued to integrate vCO with the products from VMware Cloud Suite. Cloud administrators are now able to establish a self-healing datacenter and automatically remediate any infrastructure failure by simply leveraging the vCenter Operations remediation workflow package.

Additionally, vCenter Orchestrator offers bi-directional integration with vCloud Automation Center (vCAC). vCO workflows can be coupled with resources managed by vCAC, either as part of the provisioning and decommissioning process, or as a Day-2 operation available in the  vCAC self service portal.

So don’t hesitate to try it today and let us know what you think via blog comments, Twitter (#vCO) or the vCO Community.

Cheers!

The vCO Team

VMware vCenter Orchestrator makes a splash at VMworld US 2013 – Day 1

VMworld US 2013 kicked off Monday with a keynote by Pat Gelsinger, CEO of VMware, mentioning the importance of management and automaton in the Software-Defined Data Center (SDDC).  Also mentioned was the inclusion of vCloud Automation Center (vCAC) in the Standard, Advanced and Enterprise editions of the upcoming vCloud Suite release.  With bidirectional integration between vCenter Orchestrator (vCO) and vCAC, native vCO workflows can be coupled with resources managed by vCAC, either as part of the provisioning process, or as a Day 2 operation.  The upcoming vCAC Extensibility Package for vCO affords customers the ability to use vCO as a configuration tool for vCAC extensibility. Instead of manually reconfiguring stub workflows in vCAC to call vCO, the configuration workflows in the Extensibility package will do it for you.  Customers choose a workflow to be executed at a given point in a machine’s lifecycle (i.e. run a workflow before the machine is built), then select the blueprint(s) that should call the specified workflow.  vCO then calls into vCAC and programmatically wires up the specified vCO workflow to the blueprint(s).  Alternatively, vCO can expose and assign its own workflows as Day 2 operations to the contextual Machine Menu in vCAC (think right-click or hover menu), then enable that machine menu item on specified vCAC blueprints.  Very powerful stuff!

In addition to the reference in the keynote, two vCO-specific breakout sessions were held on Monday:

VMworld US 2013 session VCM4875 – Part 1: Getting Started with vCO

VCM4875 - Part 1: Getting Started with vCenter Orchestrator

This session was vCenter Orchestrator’s opportunity to shine, and the room was filled to capacity. The session was presented jointly by James Bowling, Cloud Architect at General Datatech LP, and Savina Iliena, VMware Product Manager for vCenter Orchestrator server.

James talked about his own experiences with vCO, and demonstrated a few things he put together, bravely presenting them in a live demo.  Savina took over in the second half of the session to talk about the new features coming in vCO 5.5, specifically the new Debugger and the High Availability configuration.  This news was well received by the crowd, and by the end, you could tell they were excited to try out vCO in their own environments.

 

PHC6050 – Moving Beyond Infrastructure: Meeting Demands on App Lifecycle Management in the Dynamic Datacenter

F5′s Charlie Cano presenting on vCenter Orchestrator at VMworld US 2013

This session was co-presented by Charlie Cano of F5 and Dan Mitchell of VMware.  The session focused primarily on vCO’s capabilities around provisioning, configuration and remediation using their brand new vCO plug-in.

Charlie started the session off by asking how many folks owned vCO, and only a few hands went up.  He informed them they own vCO if they own vCenter, which seems to have caught a number of them by surprise.

F5 did a great job getting the initial release of their new plugin completed in time for VMworld. Thanks to Charlie Cano at F5!

 

Be sure to check out the other vCenter Orchestrator sessions at VMworld US 2013:

 

 


VCM5695 – Part 2: How to Build a Self-Healing Data Center with vCenter
Orchestrator
   presented by Dan Mitchell, VMware Product Manager and Nick Colyer of CatamaranRX
   Wednesday, Aug 28, 8:30 AM – 9:30 AM – Moscone West, Room 2006

…and as always, stay current with the latest product updates via Twitter by following @vCOTeam, @StartsWithV and @VMwareCloudAuto

 

The More vCO @ VMworld 2013 – The Better: vOTING Guide

Dear vCO Fans,

The best season of the year is just few months away. Yes, it is real – It is VMwolrd season of 2013. Please, be aware that there is a Public Session voting process in place at www.vmworld.com.

It is pretty easy to get lost while browsing so many great ideas available for voting. There is no need to worry – the usual suspects are also in place with creative abstracts (Christoph, Joerg, William , James Bowling …). Beside this, there are lot of new folks proposing catchy titles, revealing the power of vCO.

Please, take your time to review through the list of vCO related ideas.

4875 vCenter Orchestrator: A Beginner’s Guide – James Bowling, iland

5242 Extending vCloud Automation Center with vCenter Orchestrator; Rich Bourdeau, VMware

5287 Open up the vCloud hood using PowerCLI, Hyperic, vCenter Operations Manager and vCenter Orchestrator to reveal the inner cloud; Phil Ditzel, VMware;Cathal Cleary, VMware

5352 Automating the Software Defined Datacenter with vCAC, vCO and Storage Automation, Jeremy Goodrum, NetApp; Joerg Lew, VMware

5360 vCenter Orchestrator Best-Practices – Joerg Lew, Christophe Decanini, VMware

5365 “7 Design Patterns for vCenter Orchestrator Workflows” – Joerg Lew, VMware

5472 vCO – Say hi to Razor and Software Defined Storage, Magnus Nilsson, EMC; Jonas Rosland, EMC

5586 Optimize Application deployment time and lifecycle management via vCloud automation Center (vCAC) and vCenter Orchestrator (vCO), Boskey Savla, iGate Technologies, Inc. Indranil Bal, iGate Technologies, Inc.

5695 How to Build a Self – Healing Data Center with vCenter Orcestrator (vCO), Dan Mitchel, VMware

5703 Supercharging vSphere Web Client with vCenter Orchestrator (vCO) Dan Mitchell, VMware, James Bowling, vSential

5717 How to Automate ANYTHING with vCenter Orchestrator (vCO): Dan Mitchell

5731 Become a Rock Star with PowerCli and vCenter Orchestrator; Josh Atwell, VCE

5923 vCenter Orchestrator: Customize Your vSphere Web Client Experience – James Bowling, vSential

So be sure to go to www.vmworld.com to review submissions and vote before 6 May 2013.

And to all submitters… thank you and best of luck!

Cheers,

The vCO Team

 

 

vCenter Operations integration with vCenter Orchestrator in 5 minutes or less

Ever imagined if you could automatically resolve the operational issues that vCenter Operations has identified using vCenter Orchestrator workflows? That’s what the vCenter Operations remediation workflow package is about.

vCenter Operations performs constant analysis of the datacenter health, and launches alerts when certain problems or risks arise. These alerts can be sent externally via mail, or as SNMP trap messages. On the other hand, through its scripting API and its library of workflows that can be downloaded from VMware Solutions Exchange, vCenter Orchestrator is powerful enough to perform reconfiguration actions at almost any level of vCenter. And guess what? It can receive SNMP traps using its SNMP plug-in. I guess you already get the idea. And here is the picture to visualize it:

You said 5 minutes or less

Really anyone can write his/her own implementation of this scenario, using a vCenter Orchestrator appliance and the SNMP plug-in. However, it can take some time to track down what exactly happens on the SNMP level, parse all the valuable information, code the mapping between trap messages and remediation workflows in a clear and maintainable fashion. That’s why we decided to spare that effort to any user who does not necessarily feel the urge to be a code-hero. So we created a vCO .package with the following goals in mind:

  • Be easy to work with
  • Be easy to configure
  • Do the task, of course, of launching workflows on events from vCenter Operations
  • No programming required

So here we are – ready to share the vCenter Operations remediation workflow package!

Here’re all the things you need to try this out:

Installation/Prerequisites

To quickly run this solution, the following items must be installed:

Installation

Basic vCenter and vCenter Orchestrator configuration skills are required, in order to install the vCenter Orchestrator VA and the SNMP plugin.

  1. Deploy the virtual appliance ovf in your datacenter.
  2. Install the SNMP plugin from the vCenter Orchestrator Configurator interface.
  3. Install the vCenter Operations integration package in vCenter Orchestrator, using the vCenter Orchestrator client.

Setup/Post-installation configuration

(In vCenter Operations)

  • Set the vCenter Operations server to be sending SNMP traps to the vCenter Orchestrator server address.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

(In vCenter Orchestrator)

  • Register vCenter Operations server. Register the vCenter Operations server (vCenter Operations Analysis VM IP address) in the SNMP inventory of vCenter Orchestrator, using the “Library/SNMP/Device Management/Register an SNMP device” workflow (only add the address and optionally a friendly name, leave defaults to the other settings).

 

 

 

 

 

 

 

 

 

 

 

 

  • Apply Policy. Go to the “Policy Templates” tab in the “Administer” menu, select “Library/SNMP/vCenter Operations SNMP Trap” element, and perform “Apply Policy…” operation. As SNMP device parameter, specify the vCenter Operations server that was added in the previous step.

 

 

 

 

 

 

 

 

 

 

 

 

  • Start the policy. Start the newly created policy. If you want this policy to start automatically with server restart, edit it and change the Startup parameter on the General tab.
  • Attach remediation workflows. Go to the “Configuration elements” tab in “Design” menu, and locate the “SNMP/vCOps Configuration” element. In the attributes tab, you can find the mapping between vCenter Operations alerts (in the Name column) and workflows in the “Value” column.

There are two sample remediation workflows included in the package:

  • Default Action – it only prints the trap parameters in the log.
  • Capacity Remediation Action – It is a real remediation action, that takes the trap-specific inputs (like EntityName, EntityType, Criticality, etc.), takes only the ones needed, and forwards them to the real remediation workflow – “Library/vCOps Remediation/Capacity Remediation Action/vCOps Remediation Datastore Capacity”. This is a non-intrusive workflow, that finds the Datastore object, corresponding to the datastoreName parameter, checks for its powered off VMs, analyses their disk usage, and the disk usage of their snapshots, then prepares an email report and sends it to the user. For this workflow to work, you have to add your email in the “toAddress” attribute in the General tab of the workflow. You also have to setup the right smtp server in the settings of the Mail plugin in vCenter Orchestrator Configurator. This workflow has to be assigned to the “riskCapacityNew” alert, so it can be triggered correctly.
  • Filtering. As there may be a lot of Alerts coming from vCenter Operations, we provide the possibility to filter the incoming traffic, and not launch any workflows, unless the filtering criteria are met.

This can most easily be accomplished with the help of the “Library/vCOps Remediation/Configuration/Configure Filters” workflow, although it is also possible to achieve the same directly in the “SNMP/vCOps Filters” configuration element. This workflow could fail validation on prior to vCenter Orchestrator 5.1 systems, and the workaround is to manually open the “SNMP/vCOps Filters” configuration element, and set empty array for each of the five attributes (just click the “Not Set” value and immediately hit the “Accept” button after this).

The examples

Although we are only providing non-intrusive examples, any workflow can be assigned to any alert, moving or deleting VMs based on some criteria, defined by the user. In fact, vCenter Orchestrator provides a library of thousands of out-of-the-box workflows that can integrate various third party management systems.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Implementation details

For the ones eager for technology detail – here is what happens under the cover:

  • A vCenter Orchestrator policy is waiting for trap messages from vCenter Operations.
  • Once a trap is received, the policy translates the trap to a javascript alert object, thus simplifying it quite a lot.
  • Then it checks in a map (associative array, actually) if there is an alert definition for the incoming SNMP OID.

For example:  “1.3.6.1.4.1.6876.0.31″ -> “riskCapacityNew”

  • It checks if there are filter conditions defined, and if the trap matches them, if defined.
  • The policy finds if there is workflow assigned to this alert, in the “vCOps Configuration” configuration element.
  • Launches the workflow if such a workflow has been defined.

How are the project goals achieved

  • All the complications, technical details and scripting resides in the policy.
  • Great flexibility can be achieved by setting of correct configuration and filters.
  • All configuration is moved to configuration elements.
  • There is a workflow for even easier configuration of the filtering.

Congratulations! Your system is now installed and configured.

No programming involved.

 

 

 

 

 

 

 

 

 

 

Summary

vCenter Operations is fully integrated with vCenter Orchestrator so you can leverage more of what you already have. Automated workflow triggers let you associate workflows created in vCenter Orchestrator with vCenter Operations alerts. For example, these workflows can be used to automatically delete old VM snapshots when available capacity falls below a critical threshold or to add resources when workload demands are rising above normal. You’re always in control and can customize workflows with simple drag and drop operations. With vCenter Operations you can finally pull the trigger on automation.

Many ways to start vCenter Orchestrator workflows

I noticed a tweet recently by someone who was “surprised that vCenter Orchestrator has so few ways to trigger the starting of a workflow.” This came as a surprise, because there ARE many ways you can trigger our workflows. I’d like to take this opportunity to educate the community on just how many ways there really are…

vCenter Orchestrator provides the following base methods of triggering workflows:

  • vCenter Orchestrator Client
    • Scheduler
    • Policies
  • Web Interface
    • WebOperator Webview
    • Perspectives Plug-in
    • Custom Webview
    • Wavemaker
  • vCenter Orchestrator API
    • vCenter Orchestrator SOAP Web Service
    • vCenter Orchestrator REST Web Service

vCenter Orchestrator Client

The vCenter Orchestrator Client allows administrators and permitted groups to launch workflows manually on a local or remote vCenter Orchestrator server. The functionality of running remote workflows is greatly enhanced when using the Multi-Node plug-in. Use of the vCenter Orchestrator Client is most common during the design, test, and troubleshooting of workflows. Additionally, the client offers the following methods of automated workflow triggering:

  • Scheduler: provides the ability to schedule workflows to be running at user-defined intervals. Use-cases would include recurring maintenance tasks such as disconnecting media from all VMs prior to backup, deleting old snapshots, automatically creating snapshots, etc…
  • Policies: Allows plug-ins such as the SNMP, AMQP, and vCenter to trigger workflows based on defined criteria. Use-cases would include remediating systems based on SNMP traps that exceed defined thresholds, responding to vCloud Director blocking tasks that have been posted to an AMQP bus, and starting a workflow based on state Change or thresholds of vCenter objects.

Web Interface

Lightweight administration may be performed using vCenter Orchestrator’s built-in webview functionality. The system uses Tapestry and Dojo technologies.

  • Weboperator: The Weboperator that ships with the product gives administrators the ability to browse the entire workflow library, start and/or schedule workflows. It also allows them to:
    • Tasks: View, Suspend, Cancel, and Delete tasks (Scheduled workflows)
    • Workflows: Start/Schedule, view schema, variables, and events, respond to workflows waiting for input
    • Policies: Start/Stop/Reset and view defined Parameters
  • Perspectives: The Perspectives fling allows an administrator to define a set of workflows to be accessible to an LDAP Group. For example, one could define 5 administrative/maintenance workflows to be visible to the Backup Admins group. Upon logging into the web interface, these Backup Admins would be able to start workflows, schedule them, view workflow execution events, schemas, etc…
  • Custom webview: Custom webviews are created by developers to present specific workflows in custom layouts not afforded by the auto-generated layouts presented by the Weboperator and Perspectives. Service providers have used this method for public offerings, providing “Cloud” services years before “Cloud” was the big keyword.
  • Wavemaker: There have been numerous blog posts on creating web interfaces for vCenter Orchestrator using this free product.

API

vCenter Orchestrator has always had a SOAP API available for interacting with it from remote systems. As of version 5.x, it also now has a more powerful REST API. The first visible use of the REST API is the vSphere Web Client. When properly configured, one can launch any number of workflows directly from the vSphere Web Client. Other VMware products that incorporate the ability to launch workflows include vSphere Service Manager and vCloud Automation Center. 3rd parties have also built in support to their products so that vCenter Orchestrator workflows may be launched.

Using either of these APIs, any number of scripting and/or programming languages are capable of triggering vCenter Orchestrator workflows. Examples may be found on blogs as well as in the VMware Communities.   A quick search on google reveals examples of using PowerShell, PERL, Python, PHP, C#, JAVA, .NET, and Ruby to interact with a vCenter Orchestrator server.

As we can see above, there are many different methods of triggering vCenter Orchestrator workflows. Providing standard APIs around SOAP and REST greatly increases ones ability to incorporate vCenter Orchestrator into existing systems.

How to deal with long running external processes

When building vCenter Orchestrator Workflows, chances are that you eventually have to integrate external systems with longer running (multiple minutes, hours, maybe even days) processes.

Examples for that are:

  • Software Deployment processes
  • Clone tasks
  • When you have to rely on processes that only occur once a day (like an automatic discovery in a monitoring system)
  • “semi-automatic” processes: The workflow creates a ticket, that is going to be processed manually, and continues with the automation after the ticket is closed.

 While it’s quite easy to initiate/trigger the external system to start that long running task, it is more challenging to programmatically figure out when the external task completed (and the continue with the workflow).
vCenter Orchestrator External systemsThis article shows different strategies to wait for long running external tasks and their advantages and drawbacks.

“Synchronous” processing:

Here the workflow in vCenter Orchestrator triggers a long running process in an external system, and when this process finishes, the external system actively “tells” vCenter Orchestrator that it’s done.
vCenter Orchestrator Synchronous processing This can be achieved through two (and a half) different ways:

  1. The external system is integrated via a Plugin that provides Trigger elements or Events for vCenter Orchestrator Policies.
    If that is the case, you can use a “Waiting event” element in the workflow while waiting for the external task to complete.
    Example: The “Wait for Task” Workflow in the vCloud Director Plugin does exactly this. It is used by all the workflows of the vCloud Director Plugin that trigger long running tasks in vCloud Director.
    vCenter Orchestrator plugin waitinga “and a half”) If there is no special Plugin for the system you call out to, but this external system “speaks” AMQP or SNMP, you can use these plugins. The AMQP Plugin provides a Workflow “Wait for a message” for this for example.
  2. Use a “User Interaction” element, that is answered by the external system via vCenter Orchestrator’s SOAP or REST API.

The workflow stops at the “User interaction” element, and waits for the answer.

Here the external system of course needs the ability to somehow call the vCenter Orchestrator API to answer the user interaction.

This way has a nice side effect: If something goes wrong in the external process, a human administrator can fix it and easily answer the element manually.

Having the external system actively call back to vCenter Orchestrator doesn’t waste any time when the external process is done. And it is not necessary for the workflow itself to examine that process (as it will be necessary with the next strategy).

“Asynchronous” polling:

If the external system which runs the long running process can not actively call back to vCenter Orchestrator, then there is only one other way to examine when it is finished: Polling.
vCenter Orchestrator asynchronous pollingTo allow a polling in general, a workflow in vCenter Orchestrator must be able to figure out that the external process has finished. This sometimes can be done by checking the external system directly, e.g. because its API allows to monitor these processes, or you can check for a certain state of the external system.

In case it is not possible to check the external system directly if the process has finished (because it only provides a “fire-and-forget” sort of API for instance), then you might use some “helper”: Check if a certain file exists in a specified place, or if there is a certain entry in a database (remember the SQL Plugin for vCenter Orchestrator!), or even if there just is a new email in the mailbox vcoresponses@mycompany.com.

When you made sure how the workflow can figure out that the external process is completed, the next challenge is to organize to schedule the polling. Here again there are different strategies possible:

  1. A loop in a JavaScript element that uses System.sleep()While this is a simple solution for short running processes, it is not recommended for to monitor longer running processes: System.sleep() keeps the workflow in a running state. So it keeps using system resources on the vCenter Orchestrator server.Example: The widely used “vim3waitTaskEnd”-Action in the vCenter Library that monitors the (usually short running) tasks in vCenter which have been triggered by vCenter Orchestrator.
    To save resources (and to not risk reaching the maximum number of concurrent running workflows, 300 in vCenter Orchestrator 5.1), it’s better to have the polling workflow in a not “running” state while waiting for the next poll. This can be achieved using following strategies:
  2. Use a “Waiting Timer” element
    You first calculate the date & time when the workflow shall continue (with the next polling iteration), and then use a “Waiting timer” element. This will let the workflow get into a “waiting” state, so it’s state gets persisted in the vCenter Orchestrator database, and it does not use any runtime resources (“waiting” workflows also don’t count to the maximum number of running workflows!). When the calculated time is reached, vCenter Orchestrator will automatically “re-awake” the workflow again.
    vCenter Orchestrator use Waiting Timer
  3. Use the Workflow scheduler
    vCenter Orchestrator allows to schedule workflows to run automatically at a given date/time, optionally with a recurrence, e.g. for every hour. Now you even can schedule workflows programmatically, using the “Schedule workflow” element in the schema. This can be used nicely for the polling workflows, it is even possible that the polling workflow schedules itself for the next run.Find an example how to do this (in a slightly other scenario, but you’ll can transfer it easily) in the communities: http://communities.vmware.com/thread/318791

However, all these strategies generate a linear growing: For every external process started one workflow waiting/monitoring/polling this process is generated. If you now have a lot of these, and/or very long running processes, then you might want to avoid this growing. Even that is possible with vCenter Orchestrator, by using Configuration Elements in a creative way. (In case you need a short “refresh” about Configuration Elements, read this article: http://blogs.vmware.com/orchestrator/2012/02/configuration-elements-revisited.html)

The idea is that a workflow starts a new external process, stores information about this process to a Configuration Element and then just finishes. Another SINGLE polling workflow then reads this Configuration Element, checks all external processes, and in case some of them finished it calls workflow that follows the external process.

So it does not matter if 5 or 500 external processes have to be monitored, there is always only one polling workflow active.

You can see, vCenter Orchestrator provides a lot of mechanisms you can use to build reliable workflow solutions even for difficult integration situations.

Article Author: Joerg Lew

Important vCenter Orchestrator Plug-in Updates

With the recent vCenter Orchestrator 5.1 and vSphere 5.1 availability, it’s obviously important to ensure that not just individual products but all of your integrations are up-to-date.

Besides the already released plug-ins for vCenter Server 5.1 (built-in) and vCloud Director 5.1, we are are glad to announce the availability of several plug-in updates to make your entire vCloud suite up-to-date:

1. The vCenter Update Manager plug-in has been updated to support version 5.1 and vCenter Single Sign On. This plug-in is essential for scanning and remediating vSphere inventory objects against baselines.

2. The vCO Multi-Node plug-in has been updated to support vCO 5.1, vCenter Single Sign On, and the new vCO REST API capabilities to leverage the remote invocation of new systems types such as actions and packages.  What’s more, this new version also provides better performance and corrects some previous defects.

3. The vCO Plug-in for vSphere Auto Deploy 5.1 supports… vSphere Auto Deploy 5.1!  Need we say more?

4. The vCO Plug-in for Microsoft Active Directory 1.0.2 provides support for vCenter Single Sign On and contains an import fix for concurrent workflow execution.

5. The vCO AMQP Plug-in 1.0.2 offers significant performance improvements and fixes a known issue with the vCO server restart.

6. The vCO Plug-in for vCenter Server 5.0.2 contains important performance improvements for customers who are running vCO with vCenter Server 5.0.

  • vCO Plug-in for vCenter Update Manager 5.1: download
  • vCO Multi-Node Plug-in for 5.1: download
  • vCO Plug-in for vSphere Auto Deploy 5.1: download
  • vCO Plug-in for Microsoft Active Directory 1.0.2: download
  • vCO AMQP Plug-in 1.0.2: download
  • vCO Plug-in for vCenter Server 5.0.2: download

As always, be sure to check VMware Solution Exchange for a complete list of plug-ins available from VMware and our partners.  That’s your best place to find the latest integration solutions such as the ServiceNow plug-in recently published by InterraIT.

Cheers!

The vCO Team

VMware vCenter Orchestrator 5.1 is now GA!

As part of the broader announcements around vSphere 5.1, we are extremely glad to announce the general availability of vCenter Orchestrator 5.1!

As we mentioned last year, 2011 was all about bringing you new plug-ins (and more plug-ins…) to simplify multi-system integrations.

Whereas the emphasis on plug-ins has not stopped, we are extremely excited to announce that vCO 5.1 includes some major new capabilities!

 

Launch Workflows Directly from the vSphere Web Client

vSphere administrators and operators can now launch vCO workflows directly from the vSphere Web Client, thereby saving precious time and preventing the need to switch into and out of multiple user interfaces. Operators can use the vSphere Web Client to launch any workflow, whether pre-built, custom, and whether it interacts with VMware or partner applications! Operators can run workflows from the vSphere inventory browser in just a couple of clicks. Based on the object from which it is run (for instance a host or a VM), a workflow’s input parameters get populated automatically to save time and eliminate errors. Operators can run multiple workflows concurrently, or schedule them as recurring or future off-hour tasks. For larger organizations, administrators can allow different groups of operators to have access to different categories of workflows.

 

Develop Workflows More Easily

Workflow developers can also benefit from a simpler, faster, and more enjoyable development experience thanks to a complete redesign of the Workflow Designer. The new Designer allows workflow developers to use multiple screens, detach windows, customize workflow icons, and perform many more operations in just a single click. Auto-attach and auto-layout capabilities also greatly reduce development time. And to simplify workflow administration, vCO 5.1 introduces new capabilities such as version control and automatic generation of workflow documentation in PDF.

 

Richer Integration Capabilities

vCenter Orchestrator 5.1 includes a new REST API that does everything covered by the current SOAP API… and more! The new REST API provides more control and flexibility when launching workflows programmatically. It also introduces support for new capabilities around content management such as workflow and package importing and exporting. In short, vCO administration itself can now be more easily automated.

These are just the major new capabilities but you’ll find plenty of additional enhancements that simplify and enhance the automation of your virtual and cloud infrastructure. For a full list of new features and capabilities, please refer to the detailed overview or the release notes.

And finally, while vCO 5.1 is a major enhancement over version 4.2, you’ll still be able to leverage all of the work you’ve already created in the previous release.

So don’t wait any longer! Try it today and let us know what you think via blog comments, Twitter (#vCO) or the vCO Community.

Cheers!

The vCO Team

 

 

VMware Releases Four New VMware vCenter Orchestrator Plug-ins!

As 2011 comes to an end and the holidays approach quickly… it just felt right to thank the fast-growing vCO user community with a set of new shiny toys.  Not to mention that, like people with children know all too well, we've heard these requests over and over again throughout the year… ;-)

So on this holiday note, we are extremely pleased to release four new plug-ins that should help you achieve your 2012 cloud automation resolutions!

1. The first one is the VMware vCenter Orchestrator SQL Plug-In.  Who hasn't had a need to automate operations on database tables and records?  Well, now you can do so without actually having to write any SQL statements.

2. The second is the VMware vCenter Orchestrator Plug-In for vSphere Auto Deploy.  Considering the move to a stateless ESXi architecture?  If so then this plug-in is definitely for you. 

3. Third is the vCenter Orchestrator Multi-Node Plug-In.  As you increase the scale or geographical reach of your automation solutions, you may need to deploy more vCO server instances.  In that case, this new plug-in makes it a lot easier to manage several vCO instances from a single point.

4. And last but not least… is the vCenter Orchestrator Plug-In for Microsoft Windows PowerShell!  It lets you leverage your existing PowerShell and PowerCLI scripts and opens up so many new capabilities… that we'll need several postings to tell you all about it ;-)   So be on the lookout for additional articles on this topic very soon.  In the meantime, we obviously encourage you to take it for a first spin.

For additional information on these new plug-ins and to download them, please visit the following sites:

We hope that these new plug-ins will keep you occupied during the holidays.  Seriously, we'd actually prefer that everyone took a well-deserved break, but we know how hard it is not to play with new technology ;-)

So on this note, the entire vCO team wishes you the very best for the holidays and 2012.

Cheers!

PS.  As always, you can find documentation on vCO and all available plug-ins on the vCO Documentation site.