As referenced in the "Onyx Output Conversion" thread linked at the end of this article, one way to get started creating new workflows is to use Onyx to capture actions you perform in your vCenter client. This will help you identify the necessary objects and values for the various inputs of the methods you execute against those objects. Be sure to spend some time figuring out this tool and getting to know the API Explorer in vCO.

In order to get things started, create a new workflow named something like "Update HostSystem Service" or whatever you like. 

Once you've created the workflow, place a single Scriptable task named "Apply Action" in there and make all your connections.

Now, let's identify what we'll need for this workflow:

• ESXi server (VC:HostSystem) <- very important input 
• Service Name we wish to take action against
• Service action - what we want to do to the service
• Policy action - how we want the service to act when the ESXi server starts

Let's get started with editing the Apply Action Scriptable Task!

INPUT PARAMETER: First of all, add a new input to your scriptable task named "host". The type should be "VC:HostSystem". This will be the ESXi server that we will manage the service of.

Now that we have our HostSystem object, let's start coding!

{code}

// Get the hostServiceSystem object from the host:

var hostServiceSystem = host.configManager.serviceSystem;

// refresh services info to make sure all properties are fresh:

hostServiceSystem.refreshServices();

{/code}

We now have our hostServiceSystem object. This object is the one that has the methods that allow us to start/stop/restart the services so we're off to a good start. Next up, we need to make sure we get the service object that we wish to manage.

INPUT PARAMETER: Add another input to your scriptable task named "serviceName" - this should be a String.

{code}

// Get Service:

var serviceObj = null;

var services = hostServiceSystem.serviceInfo.service; // Retrieve a list of available services on this host

for each (svc in services){ // now try to match the service key with the service name we're passing in

     //System.log("Checking "+svc.key+" / "+serviceName); // Optionally uncomment the beginning of this line for additional logging

    if(svc.key == serviceName){

        System.log("Service Found! "+svc.label);

serviceObj = svc;

        break;

    }

}

if (serviceObj == null){ // Make sure we got the service object we are trying to manipulate - if null, throw exception

    throw "unable to locate service: "+serviceName+" on host: "+host.name;

}

{/code}

Okay, great. We found the service. Now let's do something with it.

Use the API Explorer to look at the "VcHostServiceSystem" object. This is the object we obtained in the first script snippet above. Take a look at the methods available (indicated by solid block dots).

Based on the API, it looks like we can: restart, start, stop, or uninstall a service. We can also update the Service Policy.

We'll need to account for each of these possible actions. As part of this, we'll need an input to prompt what we want to do. Additionally, we should pre-define our values so they cannot be mis-typed.

INPUT PARAMETER: Add another input to your scriptable task named "serviceAction" - this should be a String

ATTRIBUTE: Add a new attribute named "serviceActions" - this should be an Array of Strings with the following values:

• start
• stop
• restart
• uninstall

We'll use this attribute in our presentation to present a dropdown list of service actions. This allows us to prevent a user from typing an invalid value.

Now paste the following code at the bottom of the scriptable task.

{code}

switch(serviceAction){
    case "start": // Only run the startService method if the service is not running
        // before trying to start, make sure running is not true
        if (serviceObj.running != true){
            hostServiceSystem.startService(serviceObj.key);
        }
        break;

    case "stop": // Only run the stopService method if the service is running
        if (serviceObj.running == true){
            hostServiceSystem.stopService(serviceObj.key);
        }
        break;

    case "restart":
        hostServiceSystem.restartService(serviceObj.key);
        break;

    case "uninstall": // Not all services can be uninstalled so we use a try/catch here
        try{
            hostServiceSystem.uninstallService(serviceObj.key);
        }catch(err){
            System.error("Error uninstalling service "+serviceObj.key+" ("+err+")");
            Server.error("Error uninstalling service "+serviceObj.key,serviceObj.key);
        }
        break;

    default: // We should never get here so Provide some warning logging and optionally throw an exception if appropriate for your environment
        System.warn("Invalid service action selected");
        Server.warn("Invalid service action selected",serviceAction);
}

{/code}

Finally, we need to provide the ability to specify how the service starts up. 
INPUT PARAMETER: Add a new input to your Scriptable Task named "policyAction" - this should be a String

The updateServicePolicy takes two parameters - the id of our service object and the policy. It took a little playing with Onyx for me to find that the possible values for the policy are on, off, or automatic. We don't always want to take action on a policy so we'll be adding an extra value to our choice: No Change.

ATTRIBUTE: Add a new attribute named "policyActions" - this should be an Array of Strings with the following values:

• No Change
• on
• off
• automatic

We'll use this attribute in our presentation to present a dropdown list of policy actions. This allows us to prevent a user from typing an invalid value.

{code}

if(policyAction != null && policyAction != "" && policyAction != "No Change"){
    // only valid policy actions are: on, off, automatic
    try{
        hostServiceSystem.updateServicePolicy(serviceObj.key,policyAction);
    }catch(err){
        System.error("Error updating service policy "+serviceObj.key+" ("+err+")");
        Server.error("Error updating service policy "+serviceObj.key+" ("+err+")",serviceObj.key);
    }
}

{/code}

At this point, the workflow has 1 object input and 3 string inputs. All of which are passed in to the Scriptable Task.

Go ahead and try running your workflow right now...

See a problem? Right, you could mis-type the service name and may not even know which actions are available. Earlier in the article, we created a pair of Attributes that we store an array of strings containing a static set of values. We don't want to do this for the services since the services available on one host may not be available on other hosts and we want this workflow to be very reusable. So, we'll create an Action that retrieves an array of Service Names running on the given HostSystem.

Create a new Action named "getHostSystemServiceKeys". I will create this in a module named com.vmware.pso

The action should have an input named "host" of type "VC:HostSystem". I have also added a "logging" input of type "boolean" to allow for some System.log entries to take place if I need them.

For the Return Type, set that to "Array/string" since we'll be returning the names of all the services available to the HostSystem.

Now, for the script:

{code}

var hostServiceSystem = host.configManager.serviceSystem;
hostServiceSystem.refreshServices();
var services = hostServiceSystem.serviceInfo.service; // Return the array of service objects
var serviceKeys = new Array();
for each (svc in services){
    if(logging == true){
        System.log("Key: "+svc.key+" -- Label: "+svc.label+" -- Policy: "+svc.policy);
    }
    serviceKeys.push(svc.key); // Since this object type cannot be passed as an output/input, we'll just pass the names into the array
}
return serviceKeys;

{/code}

Okay, all of our code is in place. The only thing left is to cleanup our presentation so that our inputs are pre-populated with appropriate content after we have chosen our HostSystem.

Click on the Presentation tab and arrange as shown in the following screenshot:

Make the following changes on the properties tab of each input:

• (VC:HostSystem) host
  • Mandatory Input: Yes
• (string) serviceName (On General tab, under description, set value to "Service Name")
  • Predefined list of elements (Click the action icon, choose "getHostSystemServiceKeys". For first parameter, enter "#host". For second parameter, enter false)
• (string) serviceAction (On General tab, under description, set value to "Service Action")
  • Predefined list of elements (Enter #serviceActions for the value)
• (string) policyAction (On General tab, under description, set value to "Policy")
  • Predefined list of elements (Enter #policyNames for the value)
  • Default value (Set to "No Change")

Save and Close! Now try it out!

Solution/Package:

 Solution Package File - Download Here

Reference/Inspiration:

Onyx Output Converstion

Turning on SSH Service and Using SSH plug-in

With the release of vCloud director 1.5 a new important API feature was introduced : the query service. Quoting the "What's new" whitepaper:

VMware vCloud Director 1.5 also introduces a VMware vCloud API query service,
which can significantly improve developer efficiency, by minimizing the number of API requests and the amount
of data transferred for an API client to obtain needed information. Example query parameters include sorting
and ordering, pagination, filtering, projection, and expressions.

Following the development of vCloud Director prior to its first release I have begged for having this feature as a public API on several occasions. I now use it on a regular basis in my workflows. This article explains the reasons you may have to leverage the query service and gives an example on how to use it.

First you may wonder why you should use it. The short answer is because it is more efficient for finding objects based on their properties.

The longuer answer is that with using the vCloud API:

You need to drill down through the hierarchy of objects to find a particular object and its properties and need to handle things such as sorting and filtering in your code.

If you need to get to a list of objects such as vApps your vCLoud API client will issue an HTTP GET per object. Each vApp XML object representation can be a few KBytes with its OVF envelope. Multiply this by thousands of objects and you can imagine how many requests and how much data can be transfered just to get a simple information for a few vApps you want to filter on a certain property.

The query service is done server side. Your client sends a simple query which is executed on the server and sending back only the requested, filtered information. The information is sent in pages, meaning that you can at any time stop to get the next pages if you have the information needed.

Using the query service means less complex operations for the developer, and much better performance for getting the information.

Now let's see a practical example using the query service with vCO.

I needed to delete a vApp Template but then I needed to remove it from the catalogs it was in. If you are familiar with the vCloud workflow library you may know there is a "Delete Catalog Item and linked item". This is fine when you have a catalog item you want to delte with its vApp Template but it does not work the other way around.

First solution: Using the vCloud API

{code}

var catalogItemsOut = new Array();
var org = vAppTemplate.parent.parent;
var catalogs = org.getCatalogs()

for each (var catalog in catalogs) {
    var catalogItems =  catalog.getCatalogItems();
    for each (var catalogItem in catalogItems) {
        if (catalogItem.entity.href == vAppTemplate.getReference().href) {
            System.log(catalogItem.name + " : " + catalogItem.entity.href);
            catalogItemsOut.push(catalogItem);
        }
    }
}   
return catalogItemsOut;

{/code}

From the vAppTemplate getting the parent VDC, then the parent Organization. From there getting all the catalogs, all their catalog items and check if they reference the vApp Template.

Second solution: Using the query service

{code}
var catalogItems = new Array();

var vcdHost = vAppTemplate.getHost();
var queryService = vcdHost.getQueryService();
var expression = new VclExpression(VclQueryCatalogItemField.ENTITY, vAppTemplate.getReference().href , VclExpressionType.EQUALS);
var filter = new VclFilter(expression);
var params = new VclQueryParams();
params.setFilter(filter);
 
var resultSet = queryService.queryRecords(VclQueryRecordType.CATALOGITEM, params);

while (resultSet != null)  {
    var records = resultSet.getRecords(new VclQueryResultCatalogItemRecord());
    for each (var record in records) {
        var catalogItemRef = new VclReference();
        catalogItemRef.href = record.href;
        catalogItemRef.name = record.name;
        catalogItemRef.type = record.type;
          var catalogItem = (vcdHost.getEntityByReference(VclEntityType.CATALOG_ITEM, catalogItemRef));
        catalogItems.push(catalogItem);
    }
    resultSet = resultSet.getNextPage();
}
return catalogItems;

{/code}

First get the vCloud Director host from the vApp Template, then create an expression looking for the catalog item entity having an HREF equals the one of the vAppTemplate. For each record create a reference to the catalog item, get the object form the reference and add it to the array of catalogItems.

I have a small remote vCloud Director Cloud test environment with two catalogs and a total of 16 catalogs. Does using the query service makes a difference in such a small environment ?

Running a workflow looking for the same Template using the two solutions it takes:

• About 7 seconds and about 400 lines of XML to get all the objects with the vCloud API (1 VDC, 1 Organization, catalogs and their catalog items)
• About 1 second and 12 lines of XML (QueryResultRecords)

To see the XML exchanged the Debug mode is activated on the vCloud Director plug-in (as described in this article)

The catalog and catalog items objects are a lot smaller than objects such as the vApps so you can imagine how much difference it can do when querying in an environment with thousands of vApps.

Now you may think the clear winner is always the Query service but it is not always the case. If you run the workflow using the vCloud API a second time it runs in less than a second and no XML in the logs. In fact the vCloud Director plug-in cache is coming to the rescue. The objects are already in the vCO server allocated memory and no exchange need to be done with the vCloud Server. This is very useful but it has a couple of drawbacks:

• The heavy lifting of getting the necessary objects must have been done at least once in the last 30 minutes (cache TTL).
• The objects state does not get update from the vCloud server until you refresh these objects, which mean downloading them again using the updateInternalState() method. For example any vCD library workflow will update the changed objects but other calls to the vCD server won't (vCloud Director UI or API).

Here are a few query service scripts I have contributed on VMware communities.

• Get a list of all vApps (sorted)
• List VMs in vApp
• Get a VM Managed Object Reference
• Get external networks

Also, be sure to check out another perspective to using queries in this article by William Lam: 

http://blogs.vmware.com/vsphere/2012/04/quickly-finding-objects-using-the-vcloud-api-query-service.html

This is the first common release for the Windows (Build 555) and Appliance (Build 612841) version.

This release contains several improvements and bug fixes such as:

• The app-server/server/vmo/log/script-logs.log now automatically include the workflow the log is coming from using the format:
  {code}<Date> <Severity> [SCRIPTING_LOG] [<Workflow> (<Execution start date>)] <Message>{/code}
• SSH plug-in does not fail anymore transfering files.
• Issues fixed in library workflows.

Also note he that for security reason the vCenter Orchestrator 4.2.1 and its subsequent releases no longer support the default remote login to the Orchestrator configuration interface. The remote login ability can be restored if needed.

Please check the vCenter Orchestrator 4.2.1 release notes for further information.

Download the vCenter Orchestrator 4.2.1 Virtual Appliance

Quoting the product page

VMware vCenter Configuration Manager, a key part of the VMware vCenter Operations Management Suite, automates configuration management across virtual, physical and cloud environments. Enterprises can use vCenter Configuration Manager to continuously audit the configurations of VMware Infrastructure (including VMware ESX, ESXi, vCenter, vCloud Director and vShield) as well as Windows, Linux and Unix operating systems. Easily maintain configuration compliance against internal standards, security best practices, vendor hardening guidelines and regulatory mandates.

Now, how does it relate to Orchestration ?

Functionaly VCM provides a piece that was missing in the VMware orchestrated products portfolio: the configuration management engine delivering compliance to the physical devices, the hypervisors, the virtual infrastructure, the cloud infrastructure and the guest Operating systems. An important item on the feature page is the following :

vCenter Configuration Manager API coupled with VMware vCenter Orchestrator supports integration with other VMware and 3rd party products

Technicaly VCM is exposing a REST API. vCenter Orchestrator has a REST plug-in, VCM ships with vCO workflows will be available on the VMware solution exchange market place to automate patching and compliance assessment of vCenter templates, offline and online VMs. It has also a set of specific VCM operation workflows for assessing compliance, operating patches, monitoring operations, running remote commands.

Using the API it is possible to extend these operations to vCloud Director VM patching and software installation. Eventually these will come as an out of the box feature in a future version of the workflows or as part of the workflow library shipping with a dedicated vCM plug-in.

It is a good thing that most of the VMware cloud and management applications are now released with a build in integration with vCenter Orchestrator. This definitely helps to build agile, orchestrated clouds.

For more information check vCenter Configuration Manager product page.

If you like the VMware vCenter Orchestrator (vCO) Appliance because it is easy to deploy, configure and use then you may want to improve it with enabling additional features.

I like very much the vCO appliance but I recognize it has a few shortcomings:

• The vCO web start client does not work well on Mac since it does not preserve the client preferences.
• I am missing local shell control and live logs.
• I do not like to author my workflows as one of the hundreds "vcoadmin" out there. The appliance is missing user management.

Let's address these. Warning: The following is not documented, not supported and may not work in future vCO versions. It is intended for lab / educational usage.

First make sure your appliance is started. Note the appliance IP / hostname and remember the password you set to login as root from the console.

Installing the vCO client from the appliance

The appliance is not exposing all its gems. It is hiding a collection of vCenter Orchestrator clients for windows, Linux and MacOS.

If you open a browser and type in http://appliance/vco-client-install/ you will end ip on this page:

You can download and install the client for Windows (exe), Linux (bin). Or MacOS (zip).

Make sure you install it on a system that will only need to connect to the vCO server of the appliance and not any other version of vCO (i.e any Windows base version). The system it is going to be installed on may not support any upgrade when installing a newer version of vCO.

Remote shell and remote logs

If like me you are not a fan of using the VM local console for administration purposes and find the web access to be too limited you may want to have a remote shell.

A simple way to enable remote shell is to permit the root login for ssh. To do so on the appliance command line type:

{code}sed -i 's/PermitRootLogin no/PermitRootLogin yes/g' /etc/ssh/sshd_config{/code}

And then:

{code}service sshd restart{/code}

Now you can use your favorite ssh client to connect to the appliance (ssh root@appliance)

There are several interesting things to do in command line on the vCO server but one is very important when developping / testing workflows : have a live view of the vCO server log file. To do so type:

{code}tail /opt/vmo/app-server/server/vmo/log/server.log -f{/code}

You will see the last lines of the log file. If you try to run a workflow you will see it scrolling live.

Basic user management

The appliance has a simplified configuration using a built-in database and directory service. The directory service has a vcoadmins and vcousers group to allow to author and run workflows. In each of these groups there is a single member (vcoadmin and vco user). There are two issues with that. The first one is security. Someone may use the vcoadmin user name with the default vcoadmin password. The second one is that if everyone use the vcoadmin account to create content they loose the benefit of knowing or letting know who really created the workflows.

For the first issue Jörg Lew wrote a detailed article here. Changing the vCO Admin password is nice, adding new vCO admin would be better. It would even be better if you could do it with a workflow. This is what I did with providing this package. You can find the package in the VMware communities HERE.

Once imported you have a few options to manage your users:

These workflows use SSH to connect remotely. Make sure you enable remote shell.

First run the configuration workflow.

Enter the hostname or IP of the appliance, the user to SSH remotely (default = root), the password (the one you set for the appliance), the LDAP Admin user (default = vcoadmin) and its password (default = vcoadmin).

Make sure you have the credentials to access to the vCO web configuration since you will need to change the password there as well.

Run the "change user password" workflow.

Select the vcoadmin (use the filter) and pick up a password (do not mistype since I did not use password check). Remember it !

Once submitted and successful (if not you have certainly wrongly entered the configuration in the previous step)  you can close the client and open the vCO web configure (htps://appliance:8283).

You will notice some red warnings.

Requiring to update the password in this tab:

Apply the change. The LDAP tab should go back to green.

Now the Plug-in tab has still a warning.

Update the password there as well:

Since your vCO server may still be authenticating in LDAP using the previous credentials you need to restart the service.

Now that your vCO server is secure you can authenticate as vcoadmin / your new password using the client. Now it is time to create a new user for you.

Run the "Create a new user" workflow.

Fill with your username and display name, pick up a password. Submit.

The last step is to run the workflow "Add user to group".

Select your new user and the vcoadmins group. Submit. Now close the client and log back in with your newly created user.

You can now create your workflows ussing your user.

Another new VMware plug-in release for vCenter Orchestrator, this time for vCenter Chargeback Manager.

You can use the plug-in to run Orchestrator workflows that automate vCenter Chargeback processes. In this release, the plug-in contains sample workflows.

You can also create custom workflows that implement the plug-in API to automate tasks in your vCenter Chargeback Manager environment.

The vCenter Chargeback Manager plug-in API provides various Javascript objects such as cost models, fixed costs, and hierarchies, that are created in you vCenter Chargeback Manager instance. You can also create and manage reports and reporting schedules in your vCenter Chargeback Manager instance by using the plug-in API.

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

These operations include:

• Check Org for vApp name already existing in any vDCs, if so append number until unique
• Instantiate, but do not deploy or power on immediately
• Apply custom naming convention to each VM in the vApp
• Base VM name on vApp name
• Customize the Guest OS Customization script
• Specify IP for VM
• Create Computer Account in specific OU of Active Directory
• Add specified domain\user to local administrators group
• Connect VM to Network
• Change Hard Disk Size
• Add extra Disk to VM
• Modify the VM CPU count
• Modify the VM Memory
• Deploy vApp

The package and custom workflow requires a functional vCO server with the vCloud Director 1.5 plugin installed and configured. Additionally, the Active Directory plugin should be installed and configured to facilitate the Computer Account creation in AD. A functional vCD environment should be available with 1 or more vApp Templates containing at least one Windows VM. All of which should be configured as discussed throughout this document. (Note: step-by-Step installation/configuration is out of scope here)

While this workflow has been developed and tested successfully, it should always be executed and tested using the vCO Client before attempting to call via the SOAP API. This allows for determining appropriate inputs and faster troubleshooting. Once the workflow has completed successfully in the target environment, it is safe to begin integration with other systems.

Find the workflow package and more information on the VMware vCenter Orchestrator communities.

The virtual Insanity blog has a good article describing the VMware virtual Customer Lab (vCL) consisting in a fully automated cloud solution where users can checkout VMware software solutions for 14 days of testing and training/education.

The article explains what is the vCL and how it works. A part of the solution involves a vCO powered request / approval portal. Read more about it here.

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

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

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.

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

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.

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

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

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

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

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.

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}

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.

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.

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.

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.

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.

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.

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;" }

<!-- ============================== -->
   <!-- Append messages to the syslog-->
   <!-- ============================== -->
   <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;"}

<!-- ======================= -->
   <!-- Setup the Root category -->
   <!-- ======================= -->
   <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;" }
<!-- VMware vCO -->
{/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.

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

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 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.

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 !

• vCenter Orchestrator Virtual Appliance
• vCenter Orchestrator Virtual Appliance Release notes
• vCenter Orchestrator virtual Appliance User guide

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.

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!

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:

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.

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 !

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!

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.

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.

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 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 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.

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.

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.

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.

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.

• 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.

• 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.

1. Open your vCO client, search for the "Add a broker" workflow. Start it and set it as follows:
   
   
   
2. 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.
   
   
   
3. 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]


4. 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:
   
   
   
5. 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.
6. 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.
7. 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
     
     
8. 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}

9. Add an end, link it, validate the workflow.
   
   
10. 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

1. In the Policy Templates tab, expand out the tree to display the Library\AMQP\Subscription entry
   
   
2. Right click on the Subscription Policy Template and click Apply Policy
   
   
   
3. 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:
   
   
   
4. 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:
   
   
   
5. 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.
   
   
6. 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.
   
   
   
7. Under the Source Parameter column, click not set and use the chooser to set that value to self:
   
   
   
8. Once you have the Subscription specified, you may click Save and Close

To Create a new Policy Manually

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

Starting the Policy

1. Right click on policy / start.
   
   
2. Check the policy log tab to see if workflows where started.
   
   
   
3. 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.

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.

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.

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.

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 !

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.

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.

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)