Welcome to the VCO Team website!

VMware Opens Online Virtualization and Cloud Solutions Marketplace featuring vCenter Orchestrator

2012-01-25T08:14:18Z

VMware Solution Exchange (VSX) Enables Customers to Discover, Evaluate and Expedite Buying Process for Joint Solutions through Direct Engagement with Partners and Developers. This are important news for vCenter Orchestrator. Here is what these involve:

vSphere customers will now find all the vCenter Orchestrator plug-ins in a single location. vCenter Orchestrator is bundled with some plug-ins but VMware and partners have provided several additional ones. The solution exchange will feature the latest version of all VMware and all VMware partners vCenter Orchestrator plug-ins.

For VMware partners it will be significantly easier to publish their plug-ins to make them available to the hundreds of thousands VMware vSphere Customers that are entitled to use vCenter Orchestrator.

The VMware Solution eXchange improves the customer experience with providing rich, multi-media content, white papers, user guides, blog postings and search tools allowing to engage with partners and developers to help ease the process of finding the right solution for their businesses.

The VMware Solution eXchange provides customers with the opportunity to use a five-star rating system and provide a written review about their experience with the solution.

For more information:

Visit the VMware Solution Exchange home page.
Visit the vCenter Orchestrator section.
Read the official press release.
The VMware vCenter Orchestrator blog
Twitter hashtag #VMwareVSX

@PowerScripting chat with vCO Managers

2012-01-17T13:33:21Z

Did you miss the @PowerScripting folks as they interviewed the vCO Management Team?

If so, don't worry - the session was recorded! See below for details:

Thomas Corfmat - vCO Product Manager
Hemant Gaidhani - vCO Product Marketing Manager

with bonus commentary from one of VMware's PowerShell gurus: Alan Renouf

Learn more about vCO and the new support/integrations with PowerShell.

Links/Resources:

PowerScripting Blog Article: http://powerscripting.wordpress.com/2012/01/16/episode-172-vcenter-orchestrator/
Video: http://static.bambuser.com/r/player.swf?username=PowerScripting
PodCast: http://feeds.feedburner.com/PowerScripting

VMware is hiring Integration Orchestration Development Engineers and Practice Managers

2012-01-12T12:49:46Z

If you are interested in a possible career change to work in the most exciting, most ground breaking company in the software industry here is a chace to do it !

Integration Orchestration Development Engineers

VMware is seeking several Integration Orchestration Development engineers and they must have strong infrastructure integration scripting knowledge using scripting languages like JavaScript, Perl, Python, PowerShell, Ruby, Bash, MSDOS, etc… This is a backend developer role with little to no client interfacing responsibilities. VMware is looking for candidates that have experience in tying together several technology point products into a cohesive solution, particularly through automation, scripting or custom modifications. The individuals will work under direction of VMware Architects, and take direction from on-site consulting teams that are collecting and coordinating customer requirements.

Integration Orchestration Practice Manager

VMware is seeking an Integration Orchestration Practice Manager that will supervise a team performing custom integration & orchestration (i.e. Automation). Candidates should come from a strong software development lifecycle (SDLC) background and ideally have managed teams consisting of skill sets within SOAP, REST, vendor SDK interfaces and strong infrastructure scripting languages such as JavaScript, Perl, Python, PowerShell, Ruby, Bash, MSDOS, etc... The candidate should have experience as an engineer or architect with Virtualized Datacenter design and implementations.

Learn ore about this here.

vCloud Director blocking tasks and notifications integration with vCO implementation

2012-01-12T12:19:54Z

You may already have seen the theory on how to extend vCloud Director capabilities with vCenter Orchestrator, you may even have completed the first steps to do it following this tutorial. What about having a complete real use case implementation example such as a vApp Approval, adding Windows VM in Active Directory ? It is now available.

The goal of publishing this package is to give a good starting point implementation with working examples that can be adapted for other requirements. This include setting all the AMQP configuration automatically for listening for a particular blocking task notification, converting the AMQP message to vCloud Director objects, extracting the necessary information from this object, including using the vCloud Director query service, and calling back vCloud Director to resume / cancel / fail the task.

In addition to this package we provided a walk through video.

http://www.youtube.com/watch?v=OXg2GmPGRW0

VMware released the vCenter Orchestrator SQL Plug-in

2011-12-09T08:52:52Z

If you ever wanted to integrate your workflows with a database with having your database records available as part of the inventory then this plug-in will help you to do so.

Chances are that at some point you will need to read or write information from an SQL database as part of your workflows. vCenter Orchestrator provides some scripter / developper capabilities such as the JDBC plug-in and the integration with the hybernate framework. These requires quite some development and test to have a well integrated solution.

With the vCenter Orchestrator SQL plug-in allows to:

expose in the vCO enventory your database records and to perform read, create, update, and delete operations without writing SQL statements.
generate workflows from these operations.

For more information pleae check the VMware vCenter Orchestrator SQL Plug-In: release notes, documentation and download.

VMware released the vCenter Orchestrator Plug-in for vSphere Auto Deploy

2011-12-09T08:34:51Z

If you are booting your ESXi servers from the network using vSphere Auto Deploy then this plug-in allows you to automate tasks for configuring and provisioning stateless ESXi hosts.

The plug-in exposes an inventory and CRUD opratons for:

ESXi depots
Host profiles
Rule sets

There are workflows to manage answer files and to reprovision a host using answer files, host profiles, new image.

For more information check the VMware vCenter Orchestrator Plug-In for vSphere Auto Deploy release notes, documentation and download

VMware released the vCenter Orchestrator Multi-Node Plug-in

2011-12-09T08:09:15Z

If you are designing enterprise wide Orchestration you may need to consider more than a single instance of vCenter Orchestrator. The vCenter Orchestrator Multi-Node Plug-in can help you doing so with offering the ability of a vCenter Orchestrator server to remote control other vCenter Orchestrator servers.

What this plug-in provides is:

Publish the remote vCenter Orchestrator library elements (Configurations, Packgaesm Workflows, Actions and Resources) in the master vCenter Orchestrator inventory
Publish the remote vCenter Orchestrator inventory elements (vCenter, vCloud Director, Microsoft AD, Cisco UCS, ...) in the master vCenter Orchestrator inventory
Provide remote operations to start, stop, cancel remote workflows
Provide remote operation to synchronize packages

These are advanced remoting capabilities providing a lot more flexibility than the existing nested remote workflow capability. Despite the name it is not a clustering capability.

For more information check the VMware vCenter Orchestrator Multi-Node Plug-In: release notes, documentation and download

VMware released the vCenter Orchestrator Plug-in for Microsoft Windows PowerShell

2011-12-09T07:57:33Z

If you have an investment in PowerShell cmdlets such as VMware vSphere PowerCLI but also snapins from other vendors the VMware vCenter Orchestrator plug-in for Microsoft Windows PowerShell can help you to integrate these as part of workflows steps in vCenter Orchestrator.

Citing the release notes:

The plug-in offers many capabilities to workflow developers, such as:

Invoking unmodified scripts by copying and pasting them into workflows
Invoking external scripts and passing workflow parameters as script inputs
Generating a new Orchestrator action from a PowerShell script
Generating a new Orchestrator action for a PowerCLI cmdlet
Browsing snap-ins and their associated cmdlets in the Orchestrator workflow editor
Invoking scripts from the Orchestrator JavaScript API
Converting vCenter Server objects in Orchestrator workflows to PowerShell objects and the reverse

The VMware vCenter Orchestrator plug-in for Microsoft Windows PowerShell 1.0 release runs on VMware vCenter Orchestrator 4.2. The plug-in is compatible with Windows PowerShell 1.0 and 2.0, and requires WinRM 2.0 or OpenSSH

For more information please check the VMware vCenter Orchestrator Plug-In for Microsoft Windows PowerShell: release notes, documentation and download

vCloud Director orchestrated infrastructure provisioning featuring VCE UIM vCO plug-in preview

2011-12-05T19:16:44Z

VCE, the company formed by Cisco and EMC with investments from VMware and Intel is showing a demonstration of their vCenter Orchestrator powered infrastructure provisioning for vCloud Director. This is done with using EMC Unified Infrastructure Manager (UIM) which is the single pane of glass managing the stand alone Vblock Element Management applications.

If you followed the vCenter Orchestrator plug-in releases you must have noticed the UCS Manager release. So, how is a UIM plug-in different ? It covers some of the functionality in the UCS Manager plug-in but also Cisco MCS and Nexus, EMC Unisphere & SMC and some vCenter functionality. The advantage of orchestrating the top management application is that all the integration between the different parts is already included and can be automated from vCO. The exception is for vCloud Director which is orchestrated directly from vCO vCloud Director Plug-in. This integration is done by a demo workflow provided with the UIM plug-in by the VCE folks and has the following steps:

Instantiate a Service from a UIM service offering using Vblock resources
Reserve and activate the service from the Service offering
Synchronize vCenter with the service
Add a provider Virtual Data Center to vCloud Director

As a result the vCloud Director administrator get additional resources he can allocate to be consumed by the different organizations Virtual Data Centers.

The UIM plug-in exposes an inventory listing:

Service offerings
Services
tasks
vBlocks
vCenters
vCenter Clusters

Watch the full workflow demonstration video here:

http://www.youtube.com/watch?v=pckoF0s3nHA

Building your custom cloud portal - Knowing when to use the vCloud API and the vCenter Orchestrator web service

2011-11-30T05:00:00Z

My team and I have helped customers to build private and public clouds using vCenter Orchestrator for the last 5 years. Adding vCloud Director in the picture tremendously helps with providing customers a scalable standardized cloud solution. Most people will think at orchestration as a single entry point on top of the cloud when in fact for several use cases it is recommended to have vCloud Director and vCenter Orchestrator running side by side.

If you are running out of the box vCloud Director user interface or API you can use vCloud notifications and blocking tasks to delegate underlying processes to vCenter Orchestrator as shown in this article. This works well when there is a requirement to extend existing vCloud Director functionalities.

If you are building your own customized portal using a web framework or a Service Management solution such as VMware Service Manager you may wonder when you should consume the vCloud Director API and when you should consume the vCenter Orchestrator web service.

Consuming the vCloud API should be preferred for:

All close to real time interactive operations such as:
- Listing Cloud objects and their properties (For example a Web portal user interface or data extraction)
- Running vCloud single step operations (For example Start / Stop vApp)
- Operations requiring direct connection from a client to the cloud API such as:
  - Uploading of resources to the cloud.
  - The ones being initiated by the cloud ecosystem.

Consuming the vCenter Orchestrator Web Service, which in turn can calls the vCloud API with using the vCloud Director plug-in for vCenter Orchestrator should be preferred for operations :

That should not or cannot be triggerred with extending the vCloud API / UI operations using AMQP:
- A workflow requiring input parameters not available in the vCloud API (For examplee vApp placement based on project code input).
- Operations that have no equivalent in the cloud API (For example : "Backup vApp")

Involving multiple steps, long running operations and computed decisions that should not affect regular operations in vCloud Director
- For example a workflow for the end users including vApp approval, vApp placement, pre-provisioning (i.e load balancer), provisioning, post provisioning (i.e adding the computer account in Microsoft Active Directory) that should not apply for the other applications leveraging the vCloud API.
Leveraging operations not covered in the vCloud API
- Preparing the physical infrastructure for the Virtual Infrastructure (For Example provisioning a Cisco UCS blade).
- Setting up resources in vCenter for vCloud Director
Requiring auditing
- Each step of the workflow, each decision is recorded so process compliance can be observed.
- vCenter Orchestrator communicate back and forth with an external Change Management application.
Requiring resiliency
- A process running in a vCO workflow can be on vCO host shut down or failure stopped and resumed on the same or a different vCO server.
- Workflows can trap error and apply remediation

On the same subject, at a higher level my colleague Massimo Re Ferre wrote a good article here.

Code snippets : Use vCenter Orchestrator API explorer to write your own custom getGuestCustomization workflow

2011-11-23T10:44:52Z

The vCenter Orchestrator plug-ins are coming with a lot of built in workflows and action scripts. The first thing to do when looking for functionality is to browse the library or use the search filter to find these.

If you do not get exactly what you are looking for, there are chances that some of the existing workflows and actions will contain close enough examples. If you do not find any of these you can still use the API explorer to create your own.

Today there was a community post about getting VM Guest information using the vCloud Director plug-in for vCO. While I answered there I thought it would be helpful to publish it here. Here is how I do it:

For the sake of simplicity I am assuming starting with a vApp input in the workflow set as an input of a scriptable box.

First I need to get the VMs within this vApp.

In the API explorator look at the vApp methods & properties:

You can see there is vApp.getChildrenVms();

To avoid doing typos press ctrl espace after the "." : This will bring the completion window like this:

Now that you have got the VMs in the vApp you need to get their guestCustomization:

Once you have identified the right method to do it, you need to check VclGuestCustomizationSection to know what properties are available.

So if for example we need the Guest OS computer name we can use the computername property.

So to get guest information:

{code}

var vms = vApp.getChildrenVms();

for each (var vm in vms) { //iterating the vms
var getGuestCustomizationSection = vm.getGuestCustomizationSection();
System.log(getGuestCustomizationSection.computerName);
}

{/code}

The methodology above applies to any vCenter Orchestrator plug-in.

to be re-usable, versionable this peace of code can be embedded in an action that would return an array of vm names (strings)

{code}

var vmNames = new Array();

var vms = vApp.getChildrenVms();

for each (var vm in vms) { //iterating the vms
var getGuestCustomizationSection = vm.getGuestCustomizationSection();
vmNames.push(getGuestCustomizationSection.computerName);
}

return vmNames;

{/code}

VMware released the vCenter Orchestrator Plug-in update for vCloud Director 1.5

2011-11-17T20:34:30Z

I will re-iterate what I have said about nine months ago : Today VMware released the most complete automation solution for vCloud Director as a free download ! This is a plug-in for vCenter Orchestrator allowing to orchestrate vCloud Director 1.5 with a large collection of out of the box workflows. The previous version of this plug-in (1.02) is used at several service providers and enterprise customers.

As before in terms of functionality the plug-in allows:

Tenants to automate catalogs and vApp provisioning and decommissioning operations within their organization.
Service providers to automate the configuration and management of the tenant organizations, their virtual data centers and their resources.
Service providers to automate the addition and carve up of new Virtual Infrastructure resources such as Provider vDC, External networks and network pools.

Technically the plug-in implements the User, Admin, and Admin Extensions APIs using the latest release of the vCloud Java SDK. The vCloud Java SDK communicates with vCloud Director REST API. All this complexity happens in the background by being abstracted for the vCO Admin. The plug-in provides a total of 138 building block workflows and 250 actions. Some high level workflows are also provided and are great examples of the combination of these.

So what is new ?

The blocking tasks and notifications. Using this plug-in in combination with the AMQP plug-in allows vCO to dynamicaly respond to vCloud Director tasks and notifications.
The query service. The query service allows to gather information on a lot of objects very quickly.
47 new out of the box workflows and 142 new actions allowing to develop complex automation in a lot less time than with any other solution.
The support of the 1.5 API adds a LOT of new objects (close to 500 instead of about 160 before !!!).


Network related workflows	VM related workflows

There were also a lot of other improvements such as better cache handling / object fetching, new objects in the inventory and several fixes.

The vCenter Orchestrator virtual appliance can be deployed in minutes for being used in combination with this plug-in to automate your cloud and integrate it with other solutions.

If you are new to vCenter Orchestrator, you can leverage the video tutorials to create your own workflows. Then you can share your experience, ask questions on the VMware vCenter Orchestrator Communities.

The VMware vCenter Orchestrator plug-in for vCloud Director 1.5 release runs on VMware vCenter Orchestrator 4.1 and the subsequent update releases, as well as VMware vCenter Orchestrator 4.2.

For more information, check the vCenter Orchestrator Plug-in for vCloud Director release notes.

The vCenter Orchestrator Plug-in for vCloud Director is is available for download here and the user guide for the plug-in is here.

Unattended deployment of vCenter Orchestrator Appliance

2011-11-14T16:38:51Z

The vCO appliance makes it very easy to deploy vCenter Orchestrator in minutes. My colleague William Lam went a bit further with providing a script that let you pre-define a lot of the configuration settings.

The script leverage the OVF format to set a number of parameters such as the appliance network settings, placement on the virtual infrastucture datastores and network.

You can find out more about it here.

I am looking forward to see more vCO articles from William since he has a very successfull VMware scripting blog with a lot of interesting articles. I encourage you to browse it if you did not knew it yet.

Get trained on vCenter Orchestrator: 10 classes planned in EMEA

2011-11-09T23:06:07Z

If you are in EMEA and would like to be trained on using vCenter Orchestrator to create custom workflows here is your chance.

VMware is providing not one but 10 instructor lead training classes in EMEA in the next months !

I can attest the training content is really good since I have given this training recently. Also the EMEA trainer is the person who developped the content and has several years of experience with implementing vCO solutions at enterprise customers.

To find out all the details please visit vcoportal.

VMware released vFabric Application Performance Manager featuring vCenter Orchestrator integration

2011-11-02T21:57:05Z

vFabric Application Performance Manager is VMware solution for cloud applications performance monitoring and remediation.

This is a nice solution for monitoring throughput, latency, hit rate and error rates, it provides code level diagnostics and a nice user interface to fix problems quickly.The automation expert reading here certainly expect more and will be pleased to know it also offer built-in automation and policy-based alerting and remediation.

If you go on the product page features you can see that this is the kind of flexible remediation we want to see in such a product:

How is this integration implemented you may wonder ? A screenshot is worth a thousand words !

vCenter Orchestrator provides the most advanced, the most flexible VMware cloud orchestration and as such the most capapble remediation automation extension for vFabric Application Performance Manager !

For more information on vFabric Application Performance Manager please visit the product page.

Code snippets : Change the name of a vCloud Director organization

2011-11-02T20:43:12Z

Sometimes the user interfaces are limiting you by design. The APIs are often more permissive and if you know what you are doing you can do great things.

Previously we showed you how to hot clone vCloud Director vApps. We even did a video tutorial for it. Now it is time to do something else the vCloud Director User Interface will not let you do : rename an organization.

My test org has my name so my colleagues know it is mine. For a demo I needed to rename it. I opened the organization properties and saw the read only organization name.

In less then a minute I created a new workflow just doing this:

Ran it.

And voilà. Org renamed.

Now there may be very good reasons not to do this on a production org such as the change of the URL to access this org.

Hopefully this can be usefull and can add one more bullet point to this article. All the item listed there and a lot more have been done with vCO already.

How to handle vCenter Orchestrator logs?

2011-10-31T05:00:00Z

vCenter Orchestrator uses a powerful log service. This article explains the basics of this service and possible configuration changes.

This article will identify the log files currently in use for a typical vCO server installation. Additionally, it will address the following areas of interest:

Server Log rollover control: MaxFileSize and MaxBackupIndex
Enable REST call logging in the vCloud Director Plug-in
Enable logging to a SYSLOG server
Setting the server and all components to debug mode

The vCenter Orchestrator application server log files are located in install_directory\app- server\server\vmo\log

The server.log file the most relevant file for auditing the vCenter Orchestrator application server components, the plug-in adapters and the scripts contained in workflows, policies and actions. For convenience the script-logs.log only contains logs produced by the scripts.

Log levels and persistence

Each of the vCenter Orchestrator application server components, plug-in adapter provides logs in different levels including fatal, error, warning, info and debug.

During normal operations it is recommended to use the default info level to maximize the server performance while keeping quite detailed level information. Using the debug level for a single component or for all server components is recommended for troubleshooting.

A vCenter Orchestrator script in an action, workflow or policy can generate an error, warning, info and debug log by invoking the System.log(), System.warn(), System.error() and System.debug() methods with a single log content string parameter.

A vCenter Orchestrator script in an action, workflow or policy can generate an error, warning, info and debug log and an action, workflow or policy event by invoking the Server.log(), Server.warn(), Server.error() and Server.debug() methods with an event description string parameter and an event content string parameter.

The events will be saved in vCenter Orchestrator database and stay attached to their action, workflow or policy until deleted by the purge daemon when reaching a total of 5000 events or more than 100 runs for a given workflow. These values can be changed in the vmo.properties configuration file using the max-log-events and max-workflow-tokens values. Substantial increases will lead to database performance decrease requiring database admin regular maintenance operations such as re-indexing the event and workflow token tables.

Log configuration

vCenter Orchestrator uses Apache log4j allowing to configure and enable granular logging at runtime without modifying the application. The target of the log output is a configured by default to a set files but can be changed to different output targets such as a remote Unix Syslog daemon.

The log configuration file is named log4j.xml and is located in install_directory\app- server\server\vmo\conf.

Before editing this file, stop the vCenter Orchestrator Configuration service - Edit the file - then re-start the service.

Changes made by editing the configuration file manually may be lost when using vCenter Orchestrator web configuration to perform log configuration changes. This should be avoided once manual changes have been provided.

Common configuration changes use cases

The server log files may be rolling over in a short period of time when the log verbosity is increased substantially. This can be prevented by changing the default size and number of files as follows (Here multiplying the MaxFileSize and the MaxBackupInded by four times the default value).

{code class="brush: xml; gutter: false;" }
<param name="MaxFileSize" value="8192KB"/>
<param name="MaxBackupIndex" value="16"/>
{/code}

When troubleshooting vCenter Orchestrator with vCloud Director setting the vCloud Director Plug-in in debug mode logs the REST calls and responses. This can be changed in the following section as follows:
{code class="brush: xml; gutter: false;" }
<category additivity="true" name="com.vmware.vmo.plugin.vcloud">
<priority value="DEBUG"/>
</category>
{/code}

Using log centralization to a Unix Syslog Daemon for all the cloud management applications is recommended. This can be done by adding the following section:
{code class="brush: xml; gutter: false;" }

<appender name="SYSLOG" class="org.apache.log4j.net.SyslogAppender">
<param name="SyslogHost" value="X.X.X.X"/>
<param name="Facility" value="USER"/>
<param name="FacilityPrinting" value="true"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern"
value="%t %5r %-5p %-21d{yyyyMMdd HH:mm:ss,SSS} %c{2} [%x] %m %n"/>
</layout>
</appender>
{/code}

X.X.X.X must be changed to the Syslog server and USER replaced with the right log facility for your specific environment.

Scroll down to the bottom of the file and locate the following section:
{code class="brush: xml; gutter: false;"}

<root>
      <priority value="INFO"/>

      <appender-ref ref="CONSOLE"/>
      <appender-ref ref="FILE"/>
   </root>
{/code}
Next, add the following in that empty line between INFO and CONSOLE:
{code class="brush: xml; gutter: false;" }
<appender-ref ref="SYSLOG"/>
{/code}

Enabling DEBUG mode

During overall server troubleshooting it is recommended to set the server and all the components in debug mode. This can be done by changing the log level in the three following sections.

In the section:
{code class="brush: xml; gutter: false;" }
<appender class="org.jboss.logging.appender.RollingFileAppender" name="FILE">
{/code}

Update this line as follows:
{code class="brush: xml; gutter: false;" }
<param name="Threshold" value="DEBUG"/>
{/code}

In the section:
{code class="brush: xml; gutter: false;" }
<appender name="CONSOLE">
{/code}

Update this line as follows:
{code class="brush: xml; gutter: false;" }
<param name="Threshold" value="DEBUG"/>
{/code}

In the section:
{code class="brush: xml; gutter: false;" }

{/code}

Update this section as follows:

{code class="brush: xml; gutter: false;" }
<category additivity="true" name="ch.dunes">
<priority value="DEBUG"/>
</category>
{/code}

Putting a vCO server in debug mode slow down considerably the server. It is recommended to use DEBUG mode temporarely.

Developing Your First VMware vCO Workflow Video Series

2011-10-27T12:25:23Z

One of our contributing authors, Sergio Sanchez, has just published a three-part video series on Developing your first VMware vCO Workflow. In this series, Sergio steps you through the process of creating a new workflow to power on a VM and send e-mail from scratch. A couple library actions, a decision box, scriptable tasks, and error handling will be used throughout the series. The actions taken during this video series will be common across nearly all custom workflow development you perform in the future so it serves as a great basis to get you started.

Concepts covered during the course of the series include:

Part 1
http://www.youtube.com/watch?v=_J5w7Nvv9PQ

Create a workflow
Defne input parameters
Create the schema

Part 2
http://www.youtube.com/watch?v=EcOVTg236ag

Bind workflow elements with input parameters and attributes

Part 3
http://www.youtube.com/watch?v=TOcGYTsh6Eg

JavaScript code for the scriptable task elements
Create the workflow presentation
Validate the workflow

Code snippets : Create your database plug-in

2011-10-20T05:00:00Z

Need vCO to fetch some data from a database for integration purposes ? There is an easy solution with creating a plug-in ...

Jöerg Lew wrote an excellent article on the different options to integrate vCO with a database here. Creating a hibernate based plug-in is definitely the best way to map a database as vCO objects but it is a lot of effort and can get quite complex.

Since there is another much simpler way to create a database plug-in (with read only rights on the database) I thought I should share it.

First thing is to create your plug-in structure. Create a directory with a name and a "dar" extension.

In this directory create two directories: VSO-INF and resources. In VSO-INF create a text file name vso.xml. This is the file defining the plug-in interface.

Optionaly add a 32x32 pixel picture in the resources directory. This is the picture that will be used in the vCO client.

Now edit the vso.xml file as follows.

This is an example on how to create your database plug-in:
{code class="brush:xml"}
<module name="LogEventDB" display-name="Log event database plug-in" version="1.0.0" build-number="001" image="db-32x32.png" xsi:noNamespaceSchemaLocation="http://www.vmware.com/support/orchestrator/plugin-4-1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<description>This is an example on how to create your database plug-in</description>
<enumerations>
<dynamic-enumeration type="logevent">
<datasource type="jdbc" driver-class="net.sourceforge.jtds.jdbc.Driver" connection-url="jdbc:jtds:sqlserver://localhost:1433/vco;instance=sqlexpress" username="vco" password="vmware" refetch-timeout="300">
<datasource-select>SELECT severity, logtimestamp, shortdescription, longdescription, originatorusername FROM vmo_logevent ORDER BY logtimestamp</datasource-select>
<datasource-id id-element="shortdescription"/>
<datasource-entry name="severity" element-name="severity" display="Severity"/>
<datasource-entry name="logtimestamp" element-name="logtimestamp" display="Log Timestamp"/>
<datasource-entry name="shortdescription" element-name="shortdescription" display="Short Description"/>
<datasource-entry name="longdescription" element-name="longdescription" display="Long Description"/>
<datasource-entry name="originatorusername" element-name="originatorusername" display="Originator Username"/>
</datasource>
<description>Dynamic list from logevent</description>
</dynamic-enumeration>
</enumerations>
</module> {/code}

Some explanations on the code:

Module name: The prefix of all the objects in this plug-in.
Display name: The name that will show up in vCO configuration.
version, build: Used by the vCO configuration to update on new version.
Image: The image you have in the resources directory, used as the icon for the plug-in.
Description: Will show up in the API explorer.
Dynamic Enumeration logEvent: This is an object of the plug-in.
Datasource type="jdbc" ... : This is where your object will be fetched from. Here it is with using the JDBC driver that allows to connect to Microsoft SQL Server, Oracle, PostgreSQL, mySQL and other databases (drivers must be downlaoded separately). You will need to change the connection-url. You can generate this URL automatically and test it on your database with running the "JDBC URL generator" workflow in the workflow library. Make sure to set up your username and password as well.
Datasource-select : This defines the data source for your object properties in the form of a SELECT statement
datasource-id : This defines the ID of the object. this will be the one showing as a label once you have selected an object. It does not necessarely have to be an unique ID.
datasource-entry: This defines the name of a property of an object, the matching column from the SELECT statement and the display name shown to the end user.

As you can see this is not very complicated and in my example I am fetching the vCO log events.

Once you have completed this copy the JDBCPlug-in.dar in [your vCO install directory]/app-server/server/vmo/plugins

Open your vCO web configure and go in the plug-ins tab. You should see this.

Restart your vCO service to enable the plug-in.

Open the vCO client. If you look in the inventory you will not see the plug-in since we have not created an inventory in the vso.xml. Create a new workflow, edit it, add a scriptable box. Click on Search API, enter logeventdb or the custom name you gave to your plug-in:

it will find the LogEventDB:logevent object. Double click on it.

It will show you the plug-in with the nice icon you had set in the first step and the LogEventDB:logevent object.

Now let's use it as an input parameter. Create a new workflow with a scriptable task. In the workflow inputs tab, add an input called "log", search for logEvent. You will find 2 objects: vCO native LogEvent and the one from your plug-in. Select yours.

Edit your scriptable task box to add the log input and enter the following script:

System.log(log.logtimestamp + " : " + log.shortdescription);

Link the elements, validate, save.

Start your workflow. Enter something in the filter (here I look for my username). You will see all the records from your SELECT statement listed. Select one and submit.

It will display the Log Timestamp and the short description as defined in the script. You could use any of the information in these columns to feed information into a workflow.

EMC VMAX, VNX, VMware vSphere, vCloud Director integration powered by vCenter Orchestrator

2011-10-19T21:36:10Z

EMC released a Compute as a Service white paper documenting design considerations leveraging vCenter Orchestrator and its vCloud Director, AMQP and REST plug-in

With these components EMC created a workflow running the following operations:

Provision storage from EMC Symmetrix VMAX or EMC VNX based on the vCenter High Availability cluster.
Create the datastore.
Create the provider virtual datacenter.
Create the organization virtual datacenter within the provider virtual datacenter.
Create the catalog on the organization datacenter

The whitepaper shows the workflow design, a simple custom web portal to start it and the workflow execution record.

For more information check the EMC Compute as a Service white paper. vCenter Orchestrator is covered from page 27 to page 34.

VMware released the vCenter Orchestrator Virtual Appliance

2011-10-19T08:16:48Z

You have now no more excuses for not using vCenter Orchestrator: you can now have it up and running in a few minutes.

With the vCenter Orchestrator Virtual Appliance the configuration is now reduced to the bare minimum (on the Windows version there is quite a lot of configuration to do and important pre-requisites including a directory service and database).

This is ideal for loading a vCO dev / test environment (including a mobile lab on your laptop) either by importing the provided OVF in vCenter or in Workstation or Fusion (For fusion you will need to use ovftool in command line).

Here is my Fusion lab after importing the vCO 4.2 VA:

Once you will have imported and started it you will be greated by a "To manage this appliance browse to [hostname]" message. Once you open this in your browser you have a new page with links to everything you need to operate the appliance and get to useful online resources.

Configuration

The first thing you should do is to go to Orchestrator Configuration.

You will be prompted twice to set the Appliance configuration & root password and the access to the web configuration. You will also have the usual browsers certificate warnings. Apart from the orchestrated technologies the appliance is free from external dependencies with embedding OpenLDAP, postgreSQL and sendmail servers. You will see these configured.

The appliance is coming with the same plug-ins as bundled with vCO 4.2 such as vCenter Server 5. There are a few things that still may require configuration:

To make the vCenter 5 plug-in active a vCenter host needs to be configured. You can add either a vCenter 5 VA or a Windows based vCenter 5.
For other plug-ins you will need to download them from here (or the resource link on the appliance main page), install and configure them through the vCO web configuration.
The appliance is coming with a 90 days license. If you have a vCenter license you can enter the key or point to your vcenter to get unlimited usage granted.
if you want to use an appliance for production use you will certainly need to set an external directory (openLDAP, Microsoft AD, Novell eDirectory or Sun java Directory) and database (PostgreSQL, Oracle or Microsoft SQL server).

One great thing about the appliance is that the vCenter Orchestrator service restarts very quickly. On my setup it is done in close to 20 seconds whereas on a similar Windows setup it requires between 2 and 3 times more.

The appliance configuration allows to change IP & timezone from the UI & to perform future appliance updates.

vCenter Orchestrator Client

Apart from the convenience provided by the super easy configuration there is a feature I really like about this appliance: When you click on "Start Orchestrator Client" the browser will download a JNLP file which will be loaded by java webstart. The first time you will be promped for a certificate, then the client will start almost instantanously. The great thing is the client will start on any JAVA enabled platforms. I am running the client on MacOS 10 but it can run on Linux or Windows as well !

Once prompted by the client you have to enter the hostname or the IP of the server you want to connect to and one of the default account set in openLDAP (user: vcoadmin, password / vcoadmin). There is no user interface driven option offered to change manage openLDAP users and their passwords. You can always do it in command line if you have experience with handling LDIF files. here is the client running on MacOS and for the first time available to VMware customers.

Get it now !

VMware Labs released the vCenter Orchestrator CIM Plug-in

2011-10-18T13:06:06Z

Here is yet another vCenter Orchestrator (vCO) plug-in. This time to enable a set of discovery and monitoring features.

Citing the CIM plug-in summary page:

ESX includes a CIM Object Manager (CIMOM) that implements a set of server discovery and monitoring features. With the VMware CIM SMASH/Server Management API, clients that use industry-standard protocols can do the following:

Enumerate system resources
Monitor system health data

The plugin is general enough to support other CIM compliant services and is not limited only to ESX. However the primary goal for developing the plugin was to expose ESX CIMOM in the vCenter Orchestrator. This affected the API design.

Features

Enables the following use-cases without being limited to them.

Reporting Manufacturer, Model, and Serial Number
Reporting the BIOS Version
Monitoring State of All Sensors
Monitoring State of All Sensors By Using Only the Implementation Namespace
Reporting Fan Redundancy
Reporting CPU Cores and Threads
Reporting Memory Slots

For more information and access to the download please visit the CIM plug-in page on VMware labs.

Getting Started With Perspectives Webview

2011-10-05T05:00:00Z

Getting started with Perspectives Webview

If you have been following VMware vCenter Orchestrator (vCO) for a while, it is likely that you have already seen the Perspectives webview in action. It has been used in one or more vCO demos as a web-based interface to launch a specific set of workflows. A web-based interface for launching workflows is a common requirement in organizations and likely a more secure method.

What is Perspectives? How can you start using it? Learn more in our previous article: VMware Labs released the Perspectives Plug-in

Read on to learn how to install, configure, and use the Perspectives Web View!

Overview

Perspectives provides a clean, consistent interface that may be used to present a limited number of workflows for execution. It is a plug-in that consists of:

Database
Webview
Workflows
Actions

The database stores various details surrounding each of the Perspectives you have created, things like LDAP Group, which workflows the group has access to, etc... The Webview presents the appropriate workflows in the form of Task lists to members of the LDAP groups with access to those workflows. Actions provide scripting support to the workflows and webview.

Now that you have a general idea of what Perspectives provides, it's time to get it installed and ready to use!

INSTALLATION

Download and Install the Perspectives Plugin
Link: http://labs.vmware.com/flings/perspectives-plug-in-for-vcenter-orchestrator

- Login to http://yourvCOserver:8282 as vmware / vmware if you have not changed the default password
- Click on the Plug-in tab in the right pane
- Browse for and upload the Perspectives dar file, then click the Apply Changes button in the bottom-right corner of the right pane
Click on Perspectives in the left pane, then Configure Perspectives plugin database for “Same as vCO” and Apply Changes. (you may optionally create a separate database for perspectives if you wish.
Restart the vCenter Orchestrator Server service to complete plugin installation
Initialize the system by logging in as a vCO Admin to:
http://yourVCOserver:8280/vmo/perspectives/default.html
Upon login, you'll be prompted to Create your first perspective - click that link to get started

Perspectives created through this web interface using the default workflows are valid for vCO Admins only. Even when specifying another group, that group will be unable to login to the webview using this method.
Give the perspective a name - Admin Workflows would be appropriate since non-vCO admins cannot be assigned permission via the default library workflows without modification.
Choose your vCO Admin Group, and specify one or more Workflows. For this example, I'll specify the Enter maintenance mode, Exit maintenance mode, Suspend virtual machine and wait, and Start virtual machine and wait workflows
Click Submit. The Web view will automatically restart, requiring you to log back in.

Perspectives required that first initial run to get the database started and initial objects set.
Upon login as a vCO Admin, you'll be presented with the All perspectives view:

The all perspectives view presents you with a list of all the perspectives that have been created so far. Additionally, it provides a link to "Manage perspectives" at the bottom of the list and a "Manage" link in the top bar at the right of the screen.
Reminder: Using these links within the interface to create new perspectives results in admin-only perspectives as the permissions are not properly assigned to other LDAP groups unless core workflows are modified. Instead, stay tuned for our upcoming artcile on Creating Custom Perspectives.
Choose the Perspective you wish to use and click it to load the Perspectives Dashboard:

Each Perspective Dashboard is a two-paned view as shown above. The left pane lists the Tasks (Workflows) that are available for the user to execute. The right pane provides details on the selected task and options to:

Start Task

This screen provides you with a form to fill in the workflow inputs. Upon clicking the Submit button, the workflow is executed immediately.
Schedule Task

This screen provides you with a form with a variety of scheduling options. After clicking next, you are presented with the form to provide the workflow inputs (see Start Task above). Upon clicking submit, the workflow will be scheduled as specified. (see Scheduled runs below)
Active Runs

If the workflow is actively running, this screen will display details of that execution.
Scheduled runs
Completed runs
Events

Your first perspective is now operational! Congratulations! If you wish to Edit, Remove, Clone, or Create additional Administrative Perspectives, read-on.

Perspectives Management

At the top right corner of the Perspectives page is a "Manage" link that takes you in to the Perspectives Management Dashboard.

Each of the tasks shown above are similar to the tasks that were shown earlier; they are each workflows. These workflows create or modify perspectives. In our earlier example, you may want to go back in and remove a few workflows or add some additional ones to the Admin Workflows perspective. This management interface will allow you to do just that.

This article has covered the installation and configuration of the Perspectives webview. In the next article on Perspectives, you'll learn how to create your own custom initialization workflow that will help you deliver a Perspectives based web interface to your clients for custom workflows that you are delivering to them. In the resulting Perspectives, you'll have an Admin interface used by client administrators to set general configuration settings around the solution and you'll have a User interface that allows the client end-users to launch your workflows!

VMware Labs released the Perspectives Plug-in

2011-10-04T09:18:54Z

You may wonder what "Perspectives" application this may be orchestrating. In fact this plug-in offers a simple way for the VI administrator to give the vCO users access to specific workflows through a web interface.

Citing the official documentation:

"Perspectives is an Orchestrator Web view that allows a limited group of users to run or schedule certain tasks through a Web browser, without logging in to the Orchestrator client. vCenter administrators can use
Perspectives to create subsets of the standard Orchestrator workflow library and define the LDAP groups of users who can access each of these subsets. A user perspective is the set of workflows that an LDAP user group can run. The members of the vCO Admin group can run all tasks in all user perspectives and can perform tasks that are related to the Perspectives Web view management."

Basically the VI Administrator can create a separate perspective with workflows for each LDAP group of users and this way he can give a web access to these workflows to the users in this group. Perpectives allows these users to run these workflows, schedule them, check active, scheduled. completed wokflow runs and events.

Here is an example of my vCloud Director vApp Backup Admin perspective that allows me to define a Backup Virtual Data Center for all backups started by the backup operator.

Here is the vCloud Director vApp Backup Operator perspective that allows the backup operator to backup and restore vApps on demand or on schedule and to check active, scheduled. completed wokflow runs and events.

Running the backup manualy.

And scheduling the vApp Backup

OK, so we now have a great way to make available workflows to end users using Perspectives. Now do not forget this is a fling and does not come with GSS support. You can certainly test this out with small groups of users in your company but do not intend to use it for a public cloud ... You may wonder why such great functionality is not built in. In fact Perspectives was released previously with a vCO build for the Lifecycle Manager product but it was not advertised, not understood and not leveraged by end users. Without communicating internal information a fling is a way for VMware to release an attempt of implementing a functionality that could not make it in the main release (or could not stay in this case) for various reasons such as not meeting all the quality and system tests requirements. See this as an early preview as what may come next.

For further information, documentation and plug-in download please visit the VMware labs Perspectives fling page.

Code snippets : Change the name of a workflow run

2011-10-04T08:39:00Z

In some use cases you may want to customize the name of the workflow run/execution to suit your needs. For example it may be more practical to browse the workflow runs with having the name of the object the operation ran on such as "Deploy vApp tcWebServer" instead of the default "Deploy vApp". It can also be usefull if you use the workflow run as a way to identify a particular one from an external application having an ID for it. You can always add this ID as an input variable and search matching IDs in all the workflow runs but it makes it a bt more complicated. The issue with this is that the workflow run uses the name of his parent workflow by design. Some of my colleagues found ways to hack into the vCO database but there is a simpler solution.

Warning: The following is not documented, not supported and may not work in future vCO versions.

Edit the workflow you want to have custom workflow run name. Add a __tokenName input

Now in the presentation add a "Show parameter input" set to false to this will not show up when starting a workflow and a "Default value" with custom title (Here the original name of the workflow + name of the main input parameter and the user name.

Save & close, test your workflow. Voila !

No Code Required For Functional Workflows

2011-10-03T18:31:21Z

If you think you have to be a development guru that knows programming languages in order to create functional workflows with vCenter Orchestrator (vCO) then think again! With hundreds of worfklows and actions to use as building blocks with a vanilla install of vCO, you can be on your way to creating workflows in no time. While it is true that JavaScript is used for the scriptable tasks within Orchestrator, you don't actually have to write any code for some simple, but functional, workflows.

Our colleague, Bill Call, has put together just such a workflow. He has been kind enough to write it up in the format of a tutorial over at the VMware Blogs so be sure to check it out!

How to provide vCenter Orchestrator customized workflows to your customers ?

2011-09-27T07:34:44Z

Providing customized workflows to an internal or an external customer is a process following a typical software development lifecycle with specific orchestration requirements and best practices for setting up the environments and managing the content lifecycle.

1.1 Workflow Development life cycle

This section summarizes briefly the different steps to observe to deliver custom workflows (or any custom application).

1.1.1 Requirement gathering

Gathering requirement consists of interviewing the customer on project characteristics such as planning, budget, scope, prioritization and constraints but also particular specific technical requirements such as:

The operations to be automated (must be defined, documented, reliable, repeatable)
The system environment, the external system to be integrated, their interfaces
The data flows
The users and roles

1.1.2 Functional specifications and Effort estimate

Functional specifications and level of effort consists of a restatement of the requirements with a matching high-level workflows based implementation and an effort estimate for each resulting task. The tasks may be broken down into different milestones to adjust to the aforementioned project characteristics. This should be documented and signed off by the customer. In the case of an external customer effort will be translated to cost and be included with the functional specifications in a Statement of Work.

1.1.3 Design

Upon agreement between the customer and the delivery team the solution is designed following the high level implementation defined in the functional specification. This consists of architecting how the different elements of the solution work together with the external systems, the use of existing components such as plug-ins and workflows, and the development of custom ones.

1.1.4 Development

The development consists of breaking down the different development tasks and assigning them to available development resources that will create the elements of the solution.

1.1.5 Test

The test consists of checking that the solution is reliable and conforms to the functional specifications. Testing requires setting up an environment that simulates the target environment.

1.1.6 Implementation

The solution implementation consists of installing and configuring the solution in a pre-production and / or production environment and demonstrating that it works as expected.

1.1.7 Support

The solution support consists of handling support requests, checking that the solution conforms to the specification, and if not troubleshooting and providing bug fixes to the customer.

1.2 Orchestration Content life cycle

The orchestration content life cycle is the process of staging the elements of the solution from development to test, test to pre-production and pre-production to production.

Figure 1. Orchestration Content Life Cycle

Packages are used for exporting content from one Orchestrator server and importing them to another server. Packages can contain workflows, policies, actions, web views, configurations, and resources. Packages and/or their individual elements can also be synchronized directly from one server to another one as long as they are interconnected.

At creation time, Packages manage dependencies between package elements by adding automatically the missing elements. During a package import the server analyzes and displays differences giving control to the admin on which element to import or not. Packages use X509 certificates to monitor which users export and redistribute elements.

After meeting the required quality criteria for a release the package should be exported and stored either on a backed up file system or on a repository vCenter Orchestrator server (a server used specifically for storing packages). At export time to the file system there are options to:

Encrypt the package.
Set Digital Rights management (prevent customer who imported the package from seeing the JavaScript code, modify or re-package elements).
Not export the elements version history.

It is also possible to use the synchronization feature to synchronize the packages from one vCenter Orchestrator server to another one.

vCenter Orchestrator configuration elements should be used for all the attributes that have dependencies on the environment. This allows moving the orchestration content from an orchestration server to another one without having to edit the workflows to modify the attribute values. It is recommended to provide configuration workflows with the solution to set these once and to update the configuration attribute values when needed.

1.3 Orchestrated Cloud Environments

There are specific environments for some of the solution development life cycle. Here the orchestrated environment are clouds but these could be virtual iinfrastructure as well.

Figure 2. Orchestrated Cloud Environments

1.3.1 Developer environment

The recommended development environment is as follows:

One development server per developer. It is not recommended to share a single development server between different developers for the following reasons:
- The server may have to be restarted to install or upgrade plug-ins under development thus creating downtime.
- The server may have to be configured for a particular environment for a given developer.
- Changing the same element (For example: editing a workflow) at the same time is not supported.

It is recommended to use the developer workstation as the vCO development server:
- Integration within the development tool chain (For example the plug-in development environment).
- The vCenter Orchestrator client used to develop the workflows relies on its connection to the server. If there is a network disconnection the changes done since the last save are lost.

For unit testing purposes the developer server should be configured in a cloud development environment plus additional integrations when required. This can either be a simple small environment per developer or shared amongst developers. Ideally this environment should be local but can be remote. For example a vCenter orchestrator Client and server can be installed on a laptop and used to connect over the Wide Area Network to vCloud Director.

The vCenter Orchestrator client is not optimized for connecting over the Wide Area Network to a vCenter Orchestrator server and not working through a firewall. If remote access is required to a vCenter Orchestrator server than remote desktop should be used to start a vCenter orchestrator client install on the same server as the vCenter Orchestrator server.

1.3.2 Test Environment

There should be at least a vCenter Orchestrator server dedicated for testing:

This server is mainly use for testing the solution and report bugs back to the development team.
This should be a newly installed vCenter Orchestrator server with the same specifications as the target production vCenter Orchestrator server. This can be deployed from a template, reverted to snapshot when decommissioning an existing test environment or by creating a new vCenter Orchestrator Database.
The cloud environment should be different than the developer environment and as close as possible in configuration to the production environment.

1.3.3 Pre-production environment

For validating the solution with the customer there should be a vCenter Orchestrator test server in a pre-production environment (connected to the production environment but not orchestrating business critical items or orchestrating copies of these). This server will be used for final validation testing and demonstration to the customer.

1.3.4 Production Environment

If the end customer is a cloud provider and the orchestration solution applies to multiple organizations workflows should be used as a cloud back-end extension with respecting the organization multi-tenancy.

If the end customer is an organization tenant and the orchestration solution is to automate and integrate with his specific environment than a vCenter Orchestrator should be deployed within his organization and connected to an external network having access to the vCloud Director API.

1.3.5 Support Environment

In order to provide support in a timely manner it is necessary to stand up the customer environment quickly. While this could be rebuilt from the customer delivered packages and plug-ins archives, keeping a copy of the customer environment as a vApp allows resuming the specific environment quickly.

Monitoring the vCenter Orchestrator Java Virtual Machine

2011-09-19T10:00:36Z

Ever wondered how your vCenter Orchestrator is doing on memory usage ? vCenter Orchestrator Java Virtual Machine allocates a default of 2 GB Heap space.

It will consume more heap space as processes are running and will ultimately call the garbage collector to keep in memory only the used items.

If you are running a lot of workflows on your server or if you are experimenting custom workflows and plug-ins you may want to know how much of this memory is consumed. The easiest way is to download this utility.

You can copy it in $INSTALL_DIR/app-server/server/vmo/deploy/ then restart your server and check the server.log file. Every ten seconds the memory usage will be written in the log as follow:

2011-09-19 11:59:22.149+0200 INFO [Server] JBoss (MX MicroKernel) [4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)] Started in 28s:819ms 2011-09-19 11:59:22.233+0200 INFO [STDOUT] ============================ VMO server ready ============================== 2011-09-19 11:59:32.010+0200 INFO [MEMORY_DUMP] 281.561 MB / 1.926 GB 2011-09-19 11:59:42.010+0200 INFO [MEMORY_DUMP] 282.606 MB / 1.926 GB

If you want to follow this real time instead of checking the logs after the facts you can download VisualVM, install it on your vCO server and run it to monitor the ch.dunes.jboss.Main. Below is a capture of vCO running hundreds or workflows in parallel.

Now if you are getting serious about this because you need to include vCenter Orchestrator in your enterprise monitoring solution you should use the Java Management Extensions (JMX). To enable JMX for a vCenter Orchestrator server started as a service:

Create a jmxremote.password file in install_directory\app- server\server\vmo\conf. The file takes the form of a username and a password separated by a space on each line. An example is: monitor password
Create a jmxremote.access file in install_directory\app- server\server\vmo\conf. The file takes the form of a username and a permission separated by a space on each line. An example is: monitor readonly
Secure each of the jmxremote files on Windows as described here: http://download.oracle.com/javase/6/docs/technotes/guides/management/security-windows.html, and for non-Windows systems simply use the following command:
chmod 600 jmxremote.password jmxremote.password

Note: Essentially, each of the jmxremote files must only be accessible to the owner. Final security properties on a Windows server should show Full Access to the owner (default is Administrators group) and no other users, groups, or SYSTEM listed for access. Additionally, windows explorer will add a lock icon next to the filename.

Edit install_directory\app- server\bin\wrapper.conf by adding the lines below after line "wrapper.java.additional.9 ...":

wrapper.java.additional.10=-Dcom.sun.management.jmxremote.authenticate=true wrapper.java.additional.11=-Dcom.sun.management.jmxremote.password.file= ../server/vmo/conf/jmxremote.password wrapper.java.additional.12=-Dcom.sun.management.jmxremote.access.file=../server/vmo/conf/jmxremote.access wrapper.java.additional.13=-Dcom.sun.management.jmxremote.ssl=false wrapper.java.additional.14=-Dcom.sun.management.jmxremote.port=1099 wrapper.java.additional.15=-Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl wrapper.java.additional.16=-Djboss.platform.mbeanserver

Note: The numbers in wrapper.java.additional.## must be in order without gap between them, otherwise wrapper ignores them. If the last property is wrapper.java.additional.10 then all above properties should be shift by 1 starting at wrapper.java.additional.11
JMX monitoring will be available after restarting the vCenter Orchestrator server.

Testing of the monitoring
JConsole is a GUI application from the Java Development Kit designed for monitoring Java applications.
The jconsole executable is in JDK_HOME/bin, where JDK_HOME is the directory where the JDK is installed. If this directory is in system path, the tool can be started by typing jconsole in a command (shell) prompt. Otherwise, it is necessary to change the current directory.
JConsole will list local processes and give the option to enter a remote one with the hostname:port syntax.
Once connected it is possible to monitor in details the memory, threads and managed beans.
The following table represents a subset of MBeans that can be used for monitoring the performance of a vCenter Orchestrator instance.

Workflow Execution
Mbean	ch.dunes.workflow.engine.mbean.WorkflowEngine
Description	Statistics about active workflows
Attribute	Description
ExecutorsActiveCount	Number of currently active workflows
ExecutorsQueueSize	Number of workflows queued
Web views
Mbean	jboss.web:type=Cache,host=[hostname],path=/vmo
Description	webview statistics
Attribute	Description
accessCount	Number of accesses to the cache
cacheMaxSize	Max size of resources which will have their content cached
cacheSize	Max size of resources which will have their content cached
desiredEntryAccessRatio	Entry hit ratio at which an entry will never be removed from the cache.
hitsCount	Number of cache hits
Apache Tomcat Global Request Processor Metrics
Mbean	jboss.web:type=GlobalRequestProcessor,name=http-[hostname]-[port]
Description	Apache Tomcat Global Request Processor Metrics
Attribute	Description
bytesSent	Bytes sent by all the request processors running on the Apache Tomcat container
bytesReceived	Bytes received by all the request processors running on the Apache Tomcat container
processingTime	Total processing time (in milliseconds) since startup
errorCount	Error count on all the request processors running on the Apache Tomcat container
maxTime	Maximum time it took to process a request
requestCount	Request count on all the request processors running on the Apache Tomcat container
vCO web service
Mbean	jboss.web:type=Manager,path=/vmware-vmo-webcontrol,host=[hostname]
Description
Attribute	Description
activeSessions	Number of currently active sessions
expiredSessions	Number of sessions that have expired
maxActive	Maximum number of sessions that have been active at the same time
processingTime	Total processing time (in milliseconds) since startup
sessionAverageAliveTime	Average time (in seconds) that expired sessions had been alive
sessionCounter	Total number of sessions created by this manager
sessionMaxAliveTime	Longest time (in seconds) that an expired session had been alive
WebViewEngine
Mbean	jboss.web:j2eeType=Servlet,name=VSO-WebViewEngine,WebModule=//localhost/vmo,J2EEApplication=none,J2EEServer=none
Description
Attribute	Description
maxTime	Maximum time taken (in milliseconds) for processing a request
processingTime	Total processing time (in milliseconds) since startup
sessionMaxAliveTime	The longest time (in seconds) that an expired session had been alive
requestCount	Total number of requests served since startup
Web Tread pool
Mbean	jboss.web:type=ThreadPool,name=http-[hostname]-[port]
Description
Attribute	Description
currentThreadCount	Number of threads created on the Apache Tomcat container
currentThreadsBusy	Number of busy threads on the Apache Tomcat container

Possible implementation through JMX includes VMware vFabric Hyperic. It can be used to collect, store metrics from JMX and custom MBeans, and produce graphs over a long period of time.

vCenter Orchestrator has a throttling mechanism limiting the number of running workflows to 300 (default value). if additional workflows are started they will be stored in an execution queue. Even under heavy load I have never seen memory usage after garbage collecting over 1500 MB. Now this depends a lot in how the plug-ins and associated workflows were designed. In a next article I will write guidelines on how to minimize vCO resource footprint.

VMware published the vCenter Orchestrator Plug-ins Documentation Center

2011-09-17T13:40:19Z

VMware released nine plug-ins for vCenter Orchestrator this year (and there is more than a quarter left !) and decided that it would be best for customers to have all of the docs gathered in one place in a more user friendly and searchable format.

vCenter Orchestrator Plug-ins Documentation Center allows from one single page to browse the different plug-ins documentation.

Also these documentation guides are also made available in .epub and .mobi formats. These file formats allow to read the documentation on their mobile devices and Kindles.

For more information check the vCenter Orchestrator Plug-ins Documentation Center.

VMware released an update for the vCenter Orchestrator for vCloud Director 1.01

2011-09-17T13:05:29Z

VMware release a version 1.02 of the vCenter Orchestrator Plug-in for vCloud Director (1.0 or 1.01).

This is a maintenance release.

Quoting the release notes :

Version 1.0.2 of the vCloud Director plug-in improves the performance, addresses a number of issues, and includes the sample workflow package. To upgrade the plug-in, you must install version 1.0.2 on top of your existing installation.

It is recommended to update to this version since it corrects a problem happening when workflows waiting for a vCloud Director task are running concurrently and other issues. It is stated as being for vCenter Orchestrator 4.1 but it is also compatible with the recently released vCenter Orchestrator 4.2.

You can get further details with reading the release notes. You can get it from the download page.

Infoblox released a Tech Note on their vCenter Orchestrator plug-in

2011-09-16T07:06:14Z

Following their press-release and VMworld 2011 presentation Infoblox has now published a technical note which can help you to learn how the Infoblox VMware vCenter Orchestrator Plug-in alleviates the challenges of IP Address Management within rapidly expanding virtualized environments.

Quoting a part of the Tech Note:

The plug-in was developed for and is delivered with the VMware vCenter Orchestrator (vCO), which works in tandem with the VMware vCloud Director (vCD). The vCD provides automated IP addressing and related management capabilities in real time as virtual machines are created and destroyed.

Using the Infoblox VMware plug-in solution, an IT professional managing a virtualized environment can now:
• Provision systems in minutes, instead of days, with automated IP address provisioning for Cloud infrastructure and services by enabling automatic IP allocation and de-allocation as VMs are spun up and shut down
• Simplify troubleshooting and reduce downtime with real-time visibility into physical and virtualized network
infrastructure
• Manage movement between VM clusters easily with synchronization of critical DNS, DHCP and IP address services
• Eliminate errors introduced by manual processes

Find the full Tech note here.

VMware released the vCenter Orchestrator SNMP Plug-in

2011-09-14T06:44:30Z

This SNMP plug-in allows vCenter Orchestrator to connect and receive information from Simple Network Management Protocol enabled systems.

In terms of capabilities the plug-ins allows to:

Register SNMP hosts, Add SNMP GET, GETNEXT and GETBULK queries to retrieve device from host MIBs (Management Information Base) using OIDs (Object Identifier): Running these workflows will add new items to the inventory.

Set policies to listen to trap events coming from SNMP hosts and to start remediation workflows

Send SNMP traps to monitoring systems

The included workflows are the following:

All these workflows are documented here.

Note the sample workflows that wait on getting a trap from vCenter when a datastore is full and start a remediation workflow removing all unused files.

You can use the plug-in to get information and traps from several network devices such as routers, switches, network printers, and UPS devices. The plug-in can also receive events from vCenter Server over the SNMP protocol.

The plug-in provides full coverage of SNMPv1 and SNMPv2c, and partial coverage of SNMPv3. The VMware vCenter Orchestrator SNMP Plug-In 1.0 release runs on VMware vCenter Orchestrator 4.1 and later.

For further information check vCenter Orchestrator SNMP Plug-in: release notes, documentation, and download.

VMware released the vCenter Orchestrator Plug-in for vCenter Server 5.0

2011-09-14T06:16:56Z

vCenter Orchestrator 4.2 shipped with vCenter 5 including a vCenter 4.1 plug-in. While being usable with vCenter 5 it does not leverage the new functionality of vCenter 5. This has now being taken care of with the release of the vCenter 5 plug-in. Not only the plug-in exposes 100% of the vCenter 5 API it also provides a lot of additional workflows for networking and host configuration.

Some of these workflows include:

Connect a virtual machine NIC number to distributed virtual port group
Create distributed virtual switch
Update port group in standard virtual switch
Attach host system to distributed virtual switch
Add datastore on NFS
Add datastore on iSCSI/FC/local SCSI
Add datastore to cluster
Create VMDK anti-affinity rule

The full list of available workflows for the vCenter 5 plug-in (and other vCenter Orchestrator plug-ins) is available here.

The vCenter Orchestrator Plug-In for vCenter Server 5.0 runs on VMware vCenter Orchestrator 4.1 and later.

vCenter Orchestrator Plug-in for vCenter Server 5.0: release notes, documentation, and download.

Take cloud automation scripting to another level with cloud orchestration

2011-09-12T05:00:00Z

I am always asked why choose orchestration over scripting. The short answer is that orchestration has a lot more to offer; the long answer is below.

I started to work in IT in 1995 after getting my analyst-programmer degree. Naturally I used scripted automation right away and never stopped since then. I have used batch, shell, vbscript, kix, perl and various other scripting languages to automate desktop and server automated provisioning and operations in physical and then virtual environments in the early 2000s. With such a profile I joined a Swiss orchestration start-up on a Wednesday and delivered my first workflows the week after ... I have provided such workflows to large service providers and enterprise customers that are running them in production. Orchestration became my most important tool and I can not imagine automation anymore without it.

Scripting people have preferences for different scripting languages such as JavaScript, Perl, PowerShell, Python. Each of these have advantages and drawbacks. All of these are used in one way or another at VMware and we provide SDKs supporting these. vCenter Orchestrator uses JavaScript for his scripting engine. Javascript has a simplistic syntax and is widely used for web pages interaction and web apps (HTML5 and Flash).

The specific value of a scripting language versus another is, in my opinion, irrelevant as long as you can get to the same result with a similar effort. It took me a few days to go from Perl to a JavaScript level good enough to do what I needed.

What is making a big difference is the orchestration platform around the scripting engine and how it will help the different actors in the business including the different actors developing, operating and using the solution.

For the end Users

vCenter Orchestrator workflows span across IT departments and can delegate operational procedures to the end user.

To do this the workflow engine implements security access control with setting permissions on different workflows or even different parts of the same workflow. Some operations can be run as the user while others can run as service accounts.

The end user can use workflows with a web front-end either directly through the web views or indirectly through the web service which includes:

Presentation forms with content validation. This allows to run scripts to control inputs as they are typed, manage dependencies between fields, calculate defaults.

A real time inventory of all orchestrated objects providing single sign on capabilities, a cache mechanism and automatic updates.
This provides a single pane of glass across all the systems allowing the end user to select object and check their main characteristics before submitting a workflow.


vCenter Orchestrator Webview inventory	Service Manager CMDB linking diagram leveraging Orchestrator Inventory

For the system administrators

High availability:

A workflow can resumes where it stopped if the vCenter Orchestrator host fails
vCO can fail over to another vCO server and fail back

vCenter Orchestrator is a stateless workflow engine server. All the process flows and data flows are stored in a database.

Compliance:

Each workflow has a life record containing start, end time, state, inputs, outputs, variables that can be used during or after execution
All workflows have events that can trace all the operations information, warnings, errors
The Log4J facility allows fine grained monitoring configuration
All the workflows are centralized and versioned. No scripts scattered across all the orchestrated entities.

Ease of understanding / development / maintenance:

Out of the box VMware supported workflows: vCenter Orchestrator plug-in library contains several hundreds supported open source workflows.
No need to have script experience to understand what the sequencing, the logic and operations in a workflow. A workflow can be understood by management.

vCenter Orchestrator Workflow example

For the workflow developer

It is much easier to troubleshoot / maintain / modularize - reuse workflows than scripting : As an example: Before using vCenter Orchestrator I had spent a large effort on a very long script to handle site disaster recovery. It was difficult for me to troubleshoot and maintain it particularly when I had to do it a few months after the first time I put it in production . With vCenter Orchestrator I delivered something similar to the Perl script, except I did it in one week and it was multithreaded and load balancing the VM copy operations on different ESX servers. I reused part of this workflow in several occasions and I have met with the customer years after delivery: he was still running it and had done his own changes / improvement on it).

Workflow development studio:
- vCenter Orchestrator drag and drop workflow development environment with its library of modular, re-usable workflows
- API explorer: A single interface to check all orchestrated objects and methods.

Content life cycle management: vCenter orchestrator provides -
- A packager managing dependencies: This allows simple distribution of a set of functionality you need to deliver to your customer.
- Version history: This allows to manage workflow versions when shared across different packages or synchronized across vCenter Orchestrator servers.
- Signed Certificates and Digital Right Management: This allows you to protect the workflows you have developed against changes, redistribution or copy of the source code.
- Synchronization: Synchronize the workflows, packages across vCO servers. Need to move workflows from dev to test or test to pre-prod. Synchronization do it automatically for you.

Content synchronization between vCenter Orchestrator servers

Environment abstraction: server specific configurations elements allows to copy a workflow from a vCenter Orchestrator server (i.e Development / test environment) to another one (i.e customer prod) and it automatically uses the specific environment it performs operations on or use specific settings for this environment.

vCenter Orchestrator Server specific configurations example

Resources centralization: File resources can be loaded in vCenter Orchestrator and be used from there making them highly available (vs having them in a filesystem somewhere). For example a registry file can be stored for being applied to a VM post installation.

Custom properties: Attach key, value pairs to any orchestrated object. This allows to extend each object with custom properties allowing their lifecycle management.

Superior Cloud Orchestration

vCenter Orchestrator has the most complete cloud integration (vCenter, VMware vCloud Director, AMQP, Update Manager)
Third party APIs support through the use of generic SOAP and REST plug-ins. Integration is easy.
Specific third parties integration (Microsoft Active Directory, CISCO UCS) as seen at VMworld (NetApp, Infoblox, Radware). More will come as the plug-in SDK has now been released.
Cached inventory supporting automatic object updates.
2 ways communication: workflows can start operations on orchestrated systems or workflows can be triggered based on policy events received form the orchestrated systems such as inventory object updates.

Designed for the cloud

vCenter Orchestrator is java based and as a "natural" integration with Java / Spring. vCenter Orchestrator Customers build their own plug-in leveraging their java code.
vCO is platform independent, it can run on its own in a virtual appliance.

A clear choice for the most demanding customers

Large service providers use vCenter Orchestrator as their cloud workflow engine (i.e T-Systems presentation at VMworld and I know at least two others do).
Enterprise customers use it for their private cloud, integrations, virtual infrastructure and cloud lifecycle and operation automation.

Already installed

vCenter Orchestrator was installed as part of the vCenter Installation. It is waiting for you to take advantage of it for free with configuring it as did thousands of VMware customers (also here).

Does not prevent you from using other scripts

vCenter Orchestrator can start external command lines, SSH or use SOAP / REST. The scripts can be centralized as resource files in vCenter Orchestrator to benefit from high availability.

OK, great but how much ?

An advanced orchestration engine, plug-in adapters, library of workflows cost a fortune compared to a scripting engine. vCenter Orchestrator is coming free with vCenter.

Configure the AMQP plug-in to monitor vCloud Director

2011-09-09T05:00:00Z

OK, so we told you about the great new plug-in that VMware has made available for vCO to work with AMQP, but now what? You'll need a couple things to get started before you can run off and code a bunch of cool workflows so let's step through this initial process...

Get and Install AMQP Server (RabbitMQ)
Configure Publisher (vCloud Director 1.5)
Configure Consumer (vCenter Orchestrator)
- Apply Policy Template to create new Policy
- How to create new Policy manually
- Starting the Policy

Get and install an AMQP server.

For the tutorial I used a Debian based Linux and got rabbitMQ and installed it doing: sudo apt-get install rabbitmq-server

If you do not have an AMQP server yet you can do this or get RabbitMQ from here. There are versions for different platforms. If you did not install your AMQP broker yet you can follow these directions.

The AMQP plug-in documentation does not mention which versions are compatible. The plug-in was done using AMQP version 0-9-1 and tested against RabbitMQ. This tutorial was done using version 2.4 but newer version should work as well.

AMQP configuration

The AMQP installation provides a default configuration allowing to start the server and use it right away. This is what I used in this tutorial.

If you intend to run AMQP in production it is recommended to configure the server to make it secure.

Publisher Configuration

We need to feed the message bus. Configure your message publisher with your AMQP host information. In this tutorial vCloud Director 1.5 is used as the publisher.

Log in as a system administrator to vCloud Director (A tenant administrator cannot configure AMQP settings) and go to Administration / System Settings / Blocking Tasks. On the settings tab Enable Notifications and the AMQP Settings as follows (or differently if you customized the settings - be sure to use the FQDN or IP of your AMQP server).

The default password is guest.

Once done, click on Test AMQP Connection. If successful your vCloud Director Server will now send notification messages for all kind of events.

Step by step AMQP consumer vCO configuration.

Open your vCO client, search for the "Add a broker" workflow. Start it and set it as follows:
This will create a new broker connection in the inventory. We are now going to declare a message queue for vCO. Search and start the "Declare a queue" workflow. Select the broker you have just created, name your queue and its options.
The vCloud Director is publishing the messages to an Exchange named systemExchange. [edited] We do not need to declare an exchange since it was already declared by vCloud Director. It seems vCD does not necessarely declare the exchange. To make sure it is done declare it on vCO side run the "Declare an exchange" workflow and select the following options. [/edited]

What we need to do next is to bind the systemExchange to the vCO queue. For this search for the "bind" workflow and declare the binding as follows:
The vCloud notification messages routing key has the following syntax format:
{operationSuccess}.{entityUUID}.{orgUUID}.{userUUID}.{subType1}.{subType2}...{subTypeN}.{taskName}

The queue routing key supports the "*" and "#" wildcard characters to match a single segment and zero or more segments. For example true.*.*.*. com.vmware.vcloud.event.vm.create or true.#.com.vmware.vcloud.event.vm.create will route a notification to the queue with this binding key every time any user from any organization successfully creates a VM). In the example above we route every messages to the vco queue.
Now that we have a vco queue we need to subscribe to it so the AMQP plug-in can receive new messages automatically. Search for "Subscribe to queues" workflow, start and set as follows:

When a message queue is subscribed the existing and new messages stored in this queue are consumed: the become available in vCO and are deleted from the queue. Now we need to create a workflow consuming these messages. For educational purposes we are just going to list all the information available in these messages to monitor vCD.
Create a new workflow and call it "Display AMQP Message properties". Edit the workflow.
- Add an input parameter "subscription" of type AMQP:Subscription.
- Add a Scriptable task (Generic tab), rename it "Consume message"
- Link the subscription input as input to the scriptable task
Copy the following code into it.
{code} var props = subscription.retrieveLastOnMessageTrigger();
var messageBody = props.get('body'); var headers = props.get('headers'); var properties = props.get('properties');
System.log("notification.type : " + headers.get("notification.type")); System.log("notification.orgUUID : " + headers.get("notification.orgUUID")); System.log("notification.entityType : " + headers.get("notification.entityType")); System.log("notification.entityUUID : " + headers.get("notification.entityUUID")); System.log("notification.userUUID : " + headers.get("notification.userUUID")); System.log("notification.operationSuccess : " + headers.get("notification.operationSuccess")+ "\n"); System.log("messageBody : " + messageBody + "\n"); System.log("receivedRoutingKey : " + properties.get("receivedRoutingKey")); System.log("messageCount : " + properties.get("messageCount")); System.log("deliveryMode : " + properties.get("deliveryMode")); System.log("priority : " + properties.get("priority")); System.log("deliveryTag : " + properties.get("deliveryTag")); System.log("contentType : " + properties.get("contentType")); System.log("contentEncoding : " + properties.get("contentEncoding")); System.log("receivedExchange : " + properties.get("receivedExchange")); System.log("contentLength : " + properties.get("contentLength"));{/code}
Add an end, link it, validate the workflow.
Save and close. The workflow should look like below:

Now that we have a subscription to the message queue and a workflow to consume messages we need to create a policy starting this workflow on new messages. The AMQP Plug-in provides a Subscription Policy Template that we can apply.

Apply a Policy Template to create new Policy

In the Policy Templates tab, expand out the tree to display the Library\AMQP\Subscription entry
Right click on the Subscription Policy Template and click Apply Policy
When prompted for the inputs, select your vco Subscription that was created earlier, for the first two fields you may keep the defaults. Click Submit when done:
Next, the new policy must be edited to specify which workflow is to be executed. Click the Policies tab on the left, then select and edit the Subscription policy:
On the General tab, for startup: Select On server startup, start the policy. This tells vCO to start the policy each time the server is started or rebooted.
Next, click on the Scripting tab, then select the OnMessage trigger event. In the bottom pane, click the magnifying glass icon to browse for and select the Display AMQP Message properties workflow that was created earlier.
Under the Source Parameter column, click not set and use the chooser to set that value to self:
Once you have the Subscription specified, you may click Save and Close

To Create a new Policy Manually

NOTE: This step is not required if you applied the policy template as described in the previous section. This section is provided for reference on how to manually create a policy.

In the policy tab right click / Create a new policy
Name it as such:
Click on "Add policy element" (gear icon on the left)
Select AMQP:Subscription for type (the list below may vary depending on which plug-in is active on your server)
Type vco in the Filter to find the vco subscription you created previously.
Rename the policy element to "Subscription"
With Subscription selected click on "Add trigger event..."
Select "onMessage:
Type "amqp in the filter" and select the workflow you have created to consume the message.
Click on the workflow "not set: workflow parameter
Select "self"
On the general tab you can optionally set your policy to start on server startup.
Save and close.

Starting the Policy

Right click on policy / start.
Check the policy log tab to see if workflows where started.
Open the "Display AMQP Message properties" workflow logs tab on the workflow runs to check the content of the messages.
You should see something like this:

{code} [2011-08-17 21:55:54.724] [I] Started from policy : Handle vCD Messages [2011-08-17 21:55:54.893] [I] notification.type : com/vmware/vcloud/event/task/complete [2011-08-17 21:55:54.894] [I] notification.orgUUID : 853ebd05-a19a-438e-9d85-1b528c69ca12 [2011-08-17 21:55:54.894] [I] notification.entityType : com.vmware.vcloud.entity.task [2011-08-17 21:55:54.894] [I] notification.entityUUID : 634a2aaa-0e4c-47c5-9ad7-dc20df251f83 [2011-08-17 21:55:54.894] [I] notification.userUUID : c1d18808-7685-439b-84b5-654862c0f5c0 [2011-08-17 21:55:54.895] [I] notification.operationSuccess : false [2011-08-17 21:55:54.895] [I] messageBody : {/code}

{code class="brush: xml; gutter: false;" }

2011-08-17T15:44:35.573-04:00
false

{/code}

{code} 2011-08-17T15:44:35.573-04:00 false [2011-08-17 21:55:54.895] [I] receivedRoutingKey : false.634a2aaa-0e4c-47c5-9ad7-dc20df251f83.853ebd05-a19a-438e-9d85-1b528c69ca12.c1d18808-7685-439b-84b5-654862c0f5c0.com.vmware.vcloud.event.task.complete.vappDeploy [2011-08-17 21:55:54.895] [I] messageCount : 0 [2011-08-17 21:55:54.895] [I] deliveryMode : 2 [2011-08-17 21:55:54.896] [I] priority : 0 [2011-08-17 21:55:54.896] [I] deliveryTag : 18 [2011-08-17 21:55:54.896] [I] contentType : application/xml [2011-08-17 21:55:54.896] [I] contentEncoding : UTF-8 [2011-08-17 21:55:54.896] [I] receivedExchange : systemExchange [2011-08-17 21:55:54.897] [I] contentLength : 0 {/code}

The first block is the information in the headers. It contains:

the operation (here a task completed)
the type of the object concerned (a task)
the Universally Unique Identifiers for this task, the organization it belongs to and the user who started it
the result of the operation (here the task failed)

Using the header is useful for triaging events to take different actions (for example log success, log errors and start a remediation workflow). The UUIDs can be useful for matching against the catalog of object stored in a CMDB.

The second block is the body of the message. It contains additional information such as:

The URL link to the vCD server
Links, names and IDs of the entity, user, org
Time of the event

(Here the administrator unsuccessfully deployed a vApp 2011-08-17 15:44:35.573 US Eastern time in the organization Christophe). This allows to have basic human readable information without getting further information in a CMDB and optionally use the links to to get further information and take action on objects using the vCloud API.

The last block contains properties on the message such as the routing key and the exchange it was received from. This can be useful information to fine tune the binding between the exchange and queue to avoid handling messages that are of no interest.

VMware released a vCenter Orchestrator Training course

2011-09-06T19:25:13Z

Growing interest in vCenter and vCloud Orchestration has led to the creation of a new training course for vCenter Orchestrator.

This three days hands on training is available in classroom, onsite or online. It is aimed at vCenter Orchestrator beginners and requires vSphere administrators and basic scripting skills. Areas covered are installation and configuration, architecture, use of the library workflows and development of custom workflows interacting with external systems.

For knowing some of the folks involved in designing and giving the course (Brian and Jörg) we heartily recommend it.

Find the complete program please visit VMware mylearn and check the course datasheet.

Free preview of "Automating vSphere: With VMware vCenter Orchestrator" by Cody Bunch

2011-08-30T18:12:18Z

Download the VMware Press FREE Preview sampler. Containing advance chapters from upcoming VMware Press books and from author Cody Bunch, Mike Laverick, and Mostafa Khalil.

Automating vSphere: With VMware vCenter Orchestrator by Cody Bunch, ISBN: 9780321799913, December 2011

CHAPTER 6: Introduction to Workflow-Fu

Administering VMware Site Recovery Manager 5.0 by Mike Laverick, ISBN: 9780321799920, December, 2011

CHAPTER 9: Configuring the Protected Site
CHAPTER 16: Upgrading from SRM 4.1 to SRM 5.0

Storage Design and Implementation in vSphere 5.0 by Mostafa Khalil, ISBN: 9780321799937, February 2012

CHAPTER 6: ALUA

Check this out here.

Infoblox announced a vCenter Orchestrator plug-in

2011-08-30T17:53:23Z

Quoting the Infoblox press-release:

Today at VMworld® 2011, Infoblox Inc. announced it is delivering a fully integrated plug-in for the VMware vCloud® Orchestrator community. Working with VMware vCloud Director™, the integrated solution provides automated IP addressing and related management capabilities in real-time as virtual machines are created.

As a result, the Infoblox plug-in accelerates private and public cloud deployment, simplifies management and bridges network and virtual IT team silos by enabling automated assignment of IP addresses to virtual machines. Additionally, VMware vCloud™ Director integrated with Infoblox delivers cloud infrastructure resources on-demand to provide maximum business agility using virtualized resources.

Note the slip-up "vCloud Orchestrator"

The plug-in allows to:

Provision systems in minutes instead of days with automated IP address provisioning for Cloud infrastructure and services
Improve reliability with automated HA/DR for critical underlying network services
Simplify troubleshooting and reduce downtime with real-time visibility into physical and virtualized network infrastructure, including distributed VM-based Cloud stacks
Manage movement between VM clusters easily with synchronization of critical DNS, DHCP and IP address services
Eliminate errors introduced by manual processes

See the full press release here.

vCenter Orchestrator at VMworld 2011

2011-08-29T15:46:02Z

An article listing the vCenter Orchestrator sessions, demos and hands on labs has been posted on the vCO blog.

This year Orchestrator is present and used in the background in a lot more places than in the past.

Sessions:

Go to CIM3235 to hear about how customers use vCenter Orchestrator as an automation and integration platform for vCloud Director and how VMware IT did it.
Go to TEX2923 to learn about workflow development techniques from one of the most experienced vCenter Orchestrator partner / trainer and from VMware engineering.
Go to TEX1442 to know how to develop Orchestrator plug-ins and use vCO web service from VMware ecosystem engineering and vCenter Orchestrator engineering.

Solution Exchange Booth:

EMC, Infoblox, NetApp and Radware present vCenter Orchestrator integration: Ask them what integrations they are working on and when they plan to deliver these.
VMware Cloud Service Management demo: See cloud Orchestration and ask about Orchestration future plans at VMware.

Also play with Orchestrator in the different hands on labs.

Enjoy VMworld and you are welcome to comment here if you spot vCenter Orchestrator !

VMware releases vCloud Architecture Toolkit (vCAT) version 2.0

2011-08-29T10:00:00Z

As part of the Cloud Infrastructure and Management Center of Excellence Team who worked on this project we are glad to announce the release of the new vCloud Architecture Toolkit. Amongst many enhancements, this version covers vCenter Orchestrator best practices that have been proven in real-world enterprise and service provider cloud deployments.

Official announcement:

On Monday August 29, 2011 VMware is releasing version 2.0 of the VMware vCloud Architecture Tookit (vCAT). vCAT is designed to help customers construct a working VMware vCloud solution leveraging technologies, best-practices and tools that have been proven in real-world enterprise and service provider cloud deployments. It provides the foundation for building enterprise, service provider and hybrid clouds with a detailed explanation of architectural elements, component details and examples of working VMware vCloud deployments.
To date VMware customers and vCloud Powered Service Providers around the globe have used vCAT to guide their vCloud deployments and offer technical validation, saving them both time and money. vCAT has also been essential for VMware VSPP partners, serving as the foundation for the design and architecture of VSPP Cloud environments, and offering technical validation for Service Providers who desire to partner with VMware.
Version 2.0 of the Toolkit has been expanded to provide more detail on operational and organization considerations for building and running a VMware vCloud, design guidelines and examples to help customers build hybrid cloud environments, and updated to reflect the latest product releases from VMware – including vSphere 5 and vCloud Director 1.5.

To learn more, and download the Toolkit, visit the vCAT Toolkit page.

Extend vCloud Director with vCenter Orchestrator

2011-08-29T08:00:00Z

In a previous article we demonstrated how vCenter Orchestrator can leverage the vCloud Director plug-in to automate tasks or create new functionality by combining them. These workflows are initiated by vCenter Orchestrator.

Now if you would like to have vCO triggering workflows based on vCloud Director events (For example an end user task started from the vCloud Director UI, a system event or a task started from the vCloud API) you will be able to leverage the vCloud Director 1.5 Messages feature (See details here). It allows vCloud Director to post events notification to an AMQP message broker.

Since VMware released the AMQP vCO plug-in it will be possible to consume these messages and act upon them. Additionally, since vCO has a large library of plug-in adapters it becomes a multipurpose vCloud Director extension.

Event notifications can be used to monitor tasks, update external databases, start an external process in any of the many systems that can be orchestrated by vCenter Orchestrator. This happens after the event has occurred.

vCloud Director tasks can also be configured to wait on a vCO workflow to complete and then to resume, abort gracefully or fail the task before it has a chance to start. This allows vCO to:

Complete an approval or an operation that must run before the vCD task.
Replace the task by another one (vCloud Director or other).
Replace any parameters of the task.

For example:

Approve a vApp deployment by the end user manager and by the IT team.
Deleting the Active Directory Computer Account of all the VMs within a vApp when it is deleted.
Getting IP Addresses from an external System and use them for provisioning the VMs of a vApp.
Upgrade all the VMware tools in a vApp when capturing the vApp as a vApp Template.
Shutdown and Power of if shutdown fails instead of Powering off.
Record VM shutdown and power on time to calculate vApp time utilization.
Run a post deployment script in the VMs.
Run the Antivirus on a newly uploaded vApp Template.
Remediate a failure and send SNMP trap on remediation failure

Basically the possibility are endless. You get the best of breed Cloud and Cloud Orchestration platform and integration.

VMware released vCenter Orchestrator 4.2

2011-08-29T07:59:09Z

A few days ago vCenter Orchestrator 4.2 was released as part of vSphere 5 and as previous releases for no extra cost.

This release focus is on bug fixing and improving documentation and providing it in different formats. 2011 effort was mostly on orchestrating more technologies with releasing a lot more plug-ins (7 listed as of now).

Resources:

vCenter Orchestrator 4.2 release notes
vCenter Orchestrator 4.2 documentation
vCenter Orchestrator 4.2 download (included in vCenter Server 5.0 and modules)

Work with vCO over SSL

2011-08-25T19:50:00Z

With the increasing popularity of VMware vCenter Orchestrator, there is a growing desire to use it over SSL connections. While vCO supports this type of connectivity out of the box, it is not necessarily pre-configured automatically to have a proper SSL certificate. Regardless of how or where you import the default certificate, you are unlikely to get away from warnings such as:

Firefox Warning:

Internet Explorer Warning:

After clicking "Continue to this website (not recommended). ", you still get the "Certificate Error" red notification in the address bar -

even if you import the certificate as a trusted store! While you are able to continue working via a web browser, a third party system accessing the API over HTTPS may not be as cooperative!

The purpose of this tutorial is to give you step-by-step guidance on resolving the issue above by creating a certificate that matches your vCO's server name.

The following steps require the use of the keytool program found in your JRE install. Don't worry about getting it because if you're reading this, then you must have vCO installed and the file is already on your server!! Here are some important paths for you to be aware of:

Keytool: <vCO install folder>\jre\bin\keytool.exe
jssecacerts file: <vCO install folder>\jre\lib\security\jssecacerts

The following commands will directly modify the existing keystore file without the need to change any configuration files. Before proceeding, please be sure to create a backup copy of your jssecacerts file.

Stop your vCO Server Service
Open a command prompt as administrator (Use the start menu to find command prompt, then right click and choose to 'run as administrator')
Delete the current "dunes" key from the keystore using the following command:
{code}keytool -delete -alias dunes -keystore "c:\program files\vmware\orchestrator\jre\lib\security\jssecacerts" -storepass "dunesdunes"{/code}
Generate a new certificate for the "dunes" key (10 year cert shown in sample line below - adjust validity in days as desired)
{code}keytool -genkey -keyalg RSA -alias dunes -keystore "c:\program files\vmware\orchestrator\jre\lib\security\jssecacerts" -storepass "dunesdunes" -validity 3650{/code}
When prompted for your first and last name, enter the FQDN of your vCO server. This is very important as it will tie the certificate to the server! For my example here, I will enter vco-411.vcoteam.lab (my test server in my test domain):
{code}What is your first and last name?
[Unknown]: vco-411.vcoteam.lab{/code}
For each of the remaining prompts (Organizational Unit, Organization, City, State, Country Code), simply enter the appropriate values for your organizaiton
After specifying the information above, you will be prompted for confirmation... Type "yes" and hit <ENTER>
When prompted for the password for <dunes> hit <ENTER> to use the same as the keystore password (dunesdunes).
Go back to your vCenter Orchestrator Configuration and Start the vCenter Orchestrator Server service via the "Startup Options" tab.

Your vCO server now has a self-signed certificate that should match it's Fully Qualified Domain Name (FQDN). Open up your browser to the vCO server on HTTPS and use the native methods to add the certificate to your local store. This will only be required one time.

As an example:

With Internet Explorer (IE):

Open your browser to https://yourvCOServer.domain.ext:8281/
When prompted, click "Continue to this website (not recommended)."
Now IE should have the "Certificate Error" listed to the right of your address bar - left click there and choose "View Certificates"

NOTE: you may need to have the vCO server added as a trusted site in order to get the "Install Certificate" button to be visible. In the following screenshots, the left image is before the vCO server is trusted and the right is after it is trusted:
Click the Install Certificate button
The "Certificate Import Wizard" will launch - click "Next":
On the next screen, choose to "Place all certificates in the following datastore, then browse and choose "Trusted Root Certification Authorities" and click "Next"
On the final screen, click "Finish"
Now, close IE and then re-open it and visit the vCO server over SSL. You should no longer be prompted with warnings or have a Certificate Error to the right of the address bar

At this point, other applications and systems (such as VMware Service Manager) should be able to successfully connect to the vCO SOAP API over SSL with no trouble!

OPTIONAL - Get CA Signed Cert
To generate CSR:
keytool -certreq -alias dunes -keypass "dunesdunes" -keystore "c:\Program Files\VMware\Orchestrator\jre\lib\security\jssecacerts" -storepass "dunesdunes" -file myCertRequest.csr

Send "myCertRequest.csr" to CA, you may need to convert the certificate you receive to DER if this is not the default, then import the response in the following way:
keytool -importcert -alias dunes -keypass "dunedunes" -file vcoCertificate.crt -keystore "c:\Program Files\VMware\Orchestrator\jre\lib\security\jssecacerts" -storepass "dunesdunes"

When using a CA issued cert, you may also be required to import the CA cert, and any intermediate CA certs, into the vCO server. These may be imported using the SSL tab under the vCO Configuration interface.

NOTE: If you choose to create a new keystore file and use it instead of the original jssecacerts, then replace jssecacerts in the above commands and replace "dunesdunes" with your own desired values (you're on your own here!...) Once you have completed the creation of your new keystore with your password, you will need to update the server.xml file as outlined in Chapter 7 (page 65) of the vCenter Orchestrator Installation and Configuration guide.

SSL Related Resources:

Although not directly releated to the SSL certificate the webservice uses, the following is an important post regarding signed certificates from your corporate Active Directory Certificate Authority, you may wish to view Mike's Article: http://michael.requeny.com/2011/08/18/vcenter-orchestrator-import-signed-certificate/
For more information on the keytool program, visit Oracle.

VMware released the vCenter Orchestrator Plug-in SDK

2011-08-25T18:15:23Z

VMware released a software development kit allowing the creation of plug-in adapters for vCenter Orchestrator.

For the company having development resources it means that they can develop plug-ins for their private usage or for the 200.000+ vCenter customers. For end users this translates into the future availability of a lot more plug-ins.

Quoting the SDK page:

The VMware vCenter Orchestrator Plug-in SDK 4.2 is designed to jumpstart developers who are new to vCO plug-in development. It consists of the following components:

Eclipse add-on for vCO plug-in development
vCO sample plug-ins
vCO sample plug-in support services
Installation and Configuration Guide
Best Practice Guide
Videos

Very good candidate for orchestration are applications offering:

Java based API
Web services (SOAP, REST)

Resources from the vCenter Orchestrator Plug-in SDK 4.2 communities:

Video: Installing & Configuring the SDK (4:30 min)

http://www.youtube.com/watch?v=7b6XOPm4NmA

Video: Modifying & Installing Plug-ins (3:37 min)

http://www.youtube.com/watch?v=m82cPdWkBa4

Tips: Export and import input parameters

2011-08-25T13:41:35Z

VMware vCenter Orchestrator (vCO) keeps your last workflows inputs as long as you keep your vCO client open. It is very practical since it avoids filling all the input fields on each subsequent run of the same workflow.

Now if you close your client you have to refill these inputs except if ...

You use the following tip:

When your input are filled. Hold Alt and right click, A contextual menu appear. In some cases, you may only get the contextual menu if you click in the area just below an input field as highlighted by red in the following screenshot:

Export your input to a file.

When you need them again just import them back.

VMware released the AMQP plug-in

2011-08-17T06:39:49Z

VMware just released another new vCenter Orchestrator plug-in. The AMQP plug-in.

Quoting part of the release notes:

The VMware vCenter Orchestrator AMQP plug-in allows organizations to automatically trigger workflows based on AMQP messages. Advanced Message Queuing Protocol (AMQP) is a highly-scalable publish and subscribe message protocol that is increasingly used in cloud architectures. It is the default messaging protocol for vCloud Director 1.5. With the AMQP plug-in, organizations can define policies that automatically trigger specific workflows based on certain AMQP messages. For example, as part of a vApp pre-provisioning activity in vCloud Director, Orchestrator can detect the provisioning request and automatically fetch the IP address from an external system before allowing vCloud Director to proceed with the provisioning activity. When Orchestrator detects that the vApp provisioning is completed, Orchestrator can update configuration management databases and other management systems with information about the new vApp instance.

The AMQP plug-in provides the ability to monitor and publish AMQP messages, as well as to conduct administrative tasks such as configuring AMQP brokers and managing queues. The AMQP plug-in supports VMware RabbitMQ as well as other implementations of AMQP.

The VMware vCenter Orchestrator AMQP Plug-In 1.0 release runs on VMware vCenter Orchestrator 4.1.

The main operations supported by this plug-in are:

Add / remove / update / validate a Message broker
Declare an Exchange, delete an exchange
Declare a queue, delete a queue
Bind a queue to an exchange using a routing key
Receive and send a message

Here is an example of a vCO policy starting a workflow on a new message and passing it an AMQP subscription.

vCO can also publish messages to a queue so an external application can consume them.

For more information, check the vCenter Orchestrator AMQP Plug-in release notes. The vCenter Orchestrator Plug-in for vCenter Update Manager is available for download. For instructions about installing and configuring the plug-in, see the vCenter Orchestrator AMQP Plug-in User's Guide. For questions and comments, use the VMware vCenter Orchestrator Plug-ins community forum.

For RabbitMQ information check the RabbitMQ page.

How to Retrieve Workflow Execution Details

2011-07-28T14:04:42Z

A common task among vCenter Orchestrator (vCO) developers is to check the results of workflows that have already executed. This can be done in the vCO Client by clicking the plus sign next to the Workflow you are checking on, but this isn't always the most desirable method. For instance, you may have a vCO Policy/Task setup to check the executions of other workflows at a recurring interval. The following code can help guide you to gathering the desired information.

To use this sample code:

Create a new workflow called something like "Get Workflow Execution Details"
Add a single Scriptable Task element to the workflow
Add a new Input Parameter named "requestFlow" of type "workflow" to the scriptable task. (Be sure this is an Input Parameter so that when you execute this workflow, you will be prompted to select a workflow to get details from)
Add the appropriate connectors and End Task
Paste the following code into the scriptable task
Validate the workflow, save, close, and execute!

Code Sample:

{code} var tokens = requestFlow.executions; // Each execution is a "workflowToken" object
for each (token in tokens){

if (token.isStillValid){

System.log("");

System.log("==== Checking token ====");

System.log("Start Date: "+token.startDate);

if(token.endDate != null){

System.log("End Date: "+token.endDate);

}

System.log("Business State: "+token.businessState); // Indicates the business state as defined by the workflow dev in each of the elements of the workflow (not always specified)

System.log("State: "+token.state); // Indicates the system state of this workflow

/* State values are likely to be one of the following:

waiting <- waiting for user input

failed <- an exception was thrown to cause the workflow to fail

completed <- workflow competed running successfully

canceled <- user right-clicked and canceled the workflow

running <- workflow is still processing

System.log("");

System.log("==== Token Inputs ====");

var inputParams = token.getInputParameters();

if (inputParams != null){

for each (key in inputParams.keys){

var value = inputParams.get(key);

System.log(key + ": " + value + " ("+System.getObjectType(value)+")");

}

System.log("");

System.log("==== Token Attributes ====");

var attributes = token.getAttributes();

if(attributes != null){

for each (key in attributes.keys){

var value = attributes.get(key);

System.log(key + ": " + value + " ("+System.getObjectType(value)+")");

}

System.log("");

System.log("==== Token Outputs ====");

var outputParams = token.getOutputParameters();

if (outputParams != null){

for each (key in outputParams.keys){

var value = outputParams.get(key);

System.log(key + ": " + value + " ("+System.getObjectType(value)+")");

}

}else{

System.log("WARNING - INVALID TOKEN ENCOUNTERED");

}} {/code}

Note: The properties/methods used above may not be available via the SOAP API.

For your convenience, .workflow file attached (Right Click and Save Link As...) get workflow execution details.workflow

Release Management for VM Clones with vCO

2011-07-10T10:51:40Z

Last week I was member of a roundtable for designing SAP application delivery. The main things they discussed about were VM templates and their clones. SAP has an own application abstraction layer (ACC - adaptive computing controller) which hosts an API. With this knowledge I designed a little whiteboard workflow with the vCenter Orchestrator as clone intelligence and automation instance for future release management.

As you can see the software delivery application could be every other deployment system (HP Radia, Altiris etc.) with an API for vCO automation. The only decision you have to made is where to store the knowledge about the configurations (VM and application). In my opinion the best way is to keep all entries in the CMDB to allow a real life cycle for the virtual machines. With an EoL flag it´s really easy to purge old releases and keep their original VM template for potential restores.

So with vCO you have the power to adopt all the nice processes in your IT environment!

Radware ADC Virtualization & VMware Orchestrator — An Integration Demo

2011-07-04T18:52:15Z

Radware is one of the few VMware partners leveraging extensively vCenter Orchestrator in combination with their products. Find below a demo video presenting the integrated solution.

Quoting their site:

This short demo walks through a sample workflow scenario to illustrate how Radware’s solutions can help you maintain tight integration between your virtual/physical ADC environment and VMware vCenter Orchestrator/vSphere. In just a few easy steps you can dynamically configure, provision, load balance, and monitor your virtualized environment.

http://www.youtube.com/watch?v=4rkV3ebQens

vCenter Orchestrator new plug-ins covered in "This week in virtualization"

2011-06-30T13:59:07Z

Brian Knudtson (@bknudtson) talks about new VMware vCenter Orchestrator plug-ins and the vCenter Converter 5.0 beta.

Listen to the podcast here.