Home > Blogs > VMware vCenter Orchestrator Blog > Monthly Archives: January 2012

Monthly Archives: January 2012

Find ALL vCenter Orchestrator Plug-ins on the new VMware Solution Exchange!

Earlier today, VMware announced the general availability of the new VMware Solution Exchange.  This online marketplace allows customers, partners and developers to easily find and evaluate virtualization and cloud solutions based on VMware software.

For all of us working on vCenter Orchestrator, this launch is a very exciting day… for many different reasons:

1. It now makes it super easy for customers to find all vCO plug-ins in a single location.  As you already know (but we're repeating it anyways), vCO is delivered with vCenter Server and includes several plug-ins (e-mail, SSH, XML, etc.) with the default installation.  But many more plug-ins are released throughout the year and require separate downloading.  With VMware Solution Exchange, you'll be sure of browsing a central list that has the very latest plug-ins.

2. When we say single location, we mean one that includes ALL vCO plug-ins, whether published by VMware or our partners.  As you know, several partners like Infoblox, Radware, or VCE/EMC have recently released plug-ins (with more coming soon).  It will now be significantly easier for all partners to publish their plug-ins and reach the hundreds of thousands of vCenter customers that are entitled to use vCO.

VCO plug-ins
3. Customers can browse through rich, multi-media reference materials such as Youtube video overviews, white papers, user guides, blog postings and much more.  In other words, you'll never be more than a click away from access to more in-depth materials that help you evaluate and use a new vCO plug-in.  And because VMware always encourages feedback from the community, customers will have the ability to rate and provide comments on all listings.

4. Customers can more easily find partners with expertise in the deployment and use of a particular solution.  If you have an urgent project and are looking for a systems integrator or general partner to help you get started, vCO plug-in listings provide links to partners with vCO expertise.VCO partners


5. Last but not least, we started speaking about VMware Solution Exchange to a few customers and partners many, many months ago… and we're relieved to finally answer "Is it there yet?" with a resounding YES!  ;-)

We hope you share our excitement and happy browsing through the new VMware Solutions Exchange!


The vCO Team

vCO Multi-Node plug-in


Because no vCO can be left behind…

In many cases we need more than one vCO to manage different infrastructures with similar means (for example one vCO per datacenter). However this brings additional overhead in using  different vCOs and keeping them up to date. The answer to these  problems is the newly released vCO Multi-Node plug-in. It covers the following  use cases:

  • Remote vCO Management – In order to remotely  deploy and delete packages or workflows.
  • Remote Workflow Execution –  To execute workflows  on the remote vCOs.

vCO Servers Configurations

Add vCO Server

Before start working with a vCO server you need to add it to the local vCO. This is done using the Add a vCO server workflow. Hit start workflow and you will see the following workflow presentation:


Here you need to add ip/host, port (standard is being selected) and optionally user and poassword (if using the vCO server in shared mode).

The difference between shared and not shared mode is which user credentials are used to connect to the other vCO

  • Shared Mode – in this mode all users are using the same credentials to connect to the remote vCO
  • Session Per User – in this mode the currently logged user credentials are used to connect to the remote vCO

When add a vCO server the vCO Multi-Node plug-in generates proxy workflows for the entrie set of workflows residing on the remote vCO. These workflows can be found under the folder with name VCO@HOST:PORT Note: Because of workflow generation it can take up to 1 minute to add a vCO server.

Update vCO Server

If there is a need to reconfigure a vCO Server the Update a vCO server workflow can be used. Here is how it looks:


Delete vCO Server

To delete a vCO Server start Delete a vCO server workflow.


Here only server to delete needs to be selected Note: When delete a vCO server the vCO Multi-Node plug-in deletes also the generated remote workflows

Remote vCO Management

vCO has functionality to import/export packages from one vCO server to another. This functionality currently is available through vCO client, but it is limited to single vCO server. There are certain scenarios when it is needed to update multiple vCO servers with the same package. Example of such a scenario is moving from development to production environment. Using functionality available the user will need to repeat package import step for each individual production servers. vCO Multi-Node plug-in provides a set of workflows to automate the process of deploying packages/workflows from one vCO to another. Those workflows can be found in Library/Orchestrator/Remote Management.


Deploy package on remote vCO server

The vCO Multi-Node plug-in provides following workflows for automation of package deployment

  • Deploy package from local server – used to deploy package from master vCO server to remote one;
  • Deploy package’s from local server – used to deploy multiple packages at once.

What follows is example of package deployment using Deploy package from local server. Parameters that must be provided are:

  • Package – package which will be deployed. The package must be available on the master vCO server;
  • Remote vCO servers – list of servers where the package will be deployed;
  • Override – if the package already exists on the target server and this parameter has been set to “Yes”, the old content of the package will be deleted before to start deploying the package.


Result of deployment can be checked in workflow’s log.


After successful deployment package will appear in remote vCO server inventory tree under System/Packages node.


Delete a package

The easiest way to delete package from remote vCO server is to locate it in the inventory tree and execute workflow Delete a package.



Delete package, installed on multiple remote vCO servers

Workflow Delete a package by name is used to delete package that is installed on more than one remote vCO servers. This workflow expects as parameter the name of the package to be deleted and list of remote vCO servers to be processed.


Manage Remote Workflows

In addition there are two workflows available for managing  workflows separately from the package.

  • Deploy workflow from local server
  • Delete Remote Workflow

Remote Workflow Execution

The challenge in execution of remote workflows is in dealing with their input and output parameters. These are generally speaking of types that the local vCO server does not know of and can not handle. The way in which the vCO Multi-Node plug-in addresses this challenge is to generate locally so called “proxy workflows” for remote workflows. A proxy workflow takes input parameters from the inventory of the vCO Multi-Node plug-in and when executed, converts these to the types required by the remote workflow and invokes the remote workflow.

Proxy Workflow Creation

A proxy for individual remote workflow is created by the workflow Library/Orchestrator/Remote Execution/Create a proxy workflow. When this worfklow is executed it displays the following dialog:


When the workflow is executed, it creates a local proxy workflow with the same name as the selected remote workflow. The proxy is located under a local folder named VCO@ – e.g. VCO@ The path of the generated proxy relative to this server specific folder is the same as the path of the remote workflow relative to the root of the remote workflow tree.

Creation of Proxies for a Remote Workflow Folder and Server

Generation of proxy workflows for a big number of remote workflows by the procedure described above is doable but tedious. Therefore the vCO Multi-Node plug-in provides means to generate proxies for a whole remote workflow folder and for all workflows on a remote vCO server. Generation of proxies for a remote folder is done by the workflow Create Proxy Worfklows from Folder as seen below


The “Include subfolders” checkbox determines whether the selected folder will be processed recursively (default) or not.

Proxy Workflow Execution

When a proxy workflow is executed, its input parameter objects must be selected from the same server where the correspondent remote workflow resides. For example a virtual machine parameter must be selected from the local representation of the inventory of a vSphere plug-in installed on the said remote vCO server. Type checking of input parameters during selection is somewhat limited by the fact that all objects from the inventories of remote plugins have the same local type. So it is possible for example to select a cluster object instead of a virtual machine object. Types are however checked more rigorously when the proxy workflow is started and if a mismatch is found then the proxy will fail before starting the remote workflow.

Remote and Proxy Workflows Maintenance

If/when remote workflows change, there may be need to bring local proxies up to date or to entirely discard them if/when not needed any more. For the purposes of such maintenance the vCO Multi-Node plug-in provides some utility workflows in the already mentioned folder Library/Orchestrator/Remote Execution/Server Proxies, namely :

  • Refresh Proxy Workflows for VCO Server – Ensures that local proxy workflows for the selected server are up to date with the remote workflows that they represent.
  • Cleanup Proxy Workflows for VCO Server – Deletes all local proxies for workflows residing on the selected server.
  • Delete All Finished Worfklow Runs – Delete all finished workflow tokens for a remote workflow.

Multi Workflow Execution

As part of vCO Multi-Node plug-in there is a possibility to execute a workflow on many vCO servers. Due its complexity this task is separated in two steps

Step 1 – Generate a multi proxy action

In order to execute a workflow on many vCO servers first we need to generate a proxy action which can do this. Select Create a multi-proxy action workflow and run it:


The parameters of this workflow are:

  • Action Name – the name of the action to be created NOTE: The action name must contains only alpha-numeric characters whithout separators NOTE: Always a new actions is generated, even if action with the same name already exists
  • Action Module – the module where the action should be put
  • Is remote workflow? – should the workflow which is source of the proxy action should be retrieved from the local vCO or from remote
  • Remote workflow – the workflow for which the proxy will be generated

The action generated accepts the same parameters as the source workflow, but promoted to arrays (multi-selection). The values in this array should go by index. (For example in case of Rename VM – the new name of the first selected VM is the first selected name, etc) The vCO server on which the actual execution happens is deduced by the values of the parameters.

Step 2 – Use the generated action as part of bigger block (workflow)

The action generated will be something like:


This action can be now embedded directly to a local workflow.

For more info about VMware vCenter Orchestrator Multi-Node Plug-In: release notesdocumentation and download


Auto Deploy plug-in


The Auto Deploy plug-in allows simplified and automated provisioning of physical hosts with ESXi software by interacting with Auto Deploy server. The user is able to browse rules and rule sets defined within the Auto Deploy server, configured public depots and all available host profiles within the vCenter Server that can be used. The plug-in provides a set of pre-defined workflows for Auto Deploy hosts configuration, public depots configuration, rules management, answer files management and reprovisioning of ESXi hosts.

Using Auto Deploy plug-in together with vCenter Server plug-in users can benefit from pre-defines workflows by decreasing the effort and time of provisioning and reprovisioning of stateless hosts with ESXi software.


  • Configured Auto Deploy server registered to a specific vCenter Server must be available.
  • Make sure that the network where the vCO, Auto Deploy server and public depots reside allows enough bandwidth to transfer large amount of data (ESXi software packages).
  • It may take some time to complete some workflows like creating, modifying rules or reprovisioning of ESXi hosts with image profiles that have not been used at least once. The second time an image profile is used will go much faster as the the software packages from the depots will be cached by the Auto Deploy server.
  • Make sure that Auto Deploy server is configured to reuse connections:


On the Linux version you need to change the following properties in the /etc/vmware-rbd/httpd/conf/httpd.conf file and restart Auto Delpoy server:

  1. KeepAlive = On
  2. MaxKeepAliveRequest = 0
  3. KeepAliveTimeout = 300 (or more)


Depot configuration

Only online depots are supported currently which means that depots should be accessible through a URL. The plug-in provides workflows for configuring access to such public depots so that later they can be used during the process of provisioning and reprovisioning of stateless hosts.


After completion of the 'Add a depot' workflow the depot will be added to the Inventory.


Auto Deploy host configuration

The plug-in provides a way of configuring Auto Deploy hosts by simply pointing to the associated vCenter Server host. The plug-in will automatically discover the registered Auto Deploy server (if available) and it will appear in the plug-in's inventory.


After completion of the 'Add an Auto Deploy host' workflow the Auto Deploy host will be added to the Inventory.


Rule management

Actually the way Auto Deploy works is via rule management on Auto Deploy server. The plug-in provides an easy way for creating, modifying or activating rules within the rule engine of Auto Deploy server. There are also predefined workflows for retrieving rules that impact a specific host and workflows for testing and repairing the rule set compliance.


Host profiles and answer files

The plug-in provides a way for managing answer file corresponding to a certain host profile using a XML format. The user should know the actual keys of the parameters in order to modify specific values from the answer files for a specific host.

In case the host doesn't have an answer file, a simple XML template will be presented so that the user can fill the empty placeholders with real values and modify the XML content. In case an answer file already exists for the particular host it will be displayed and ready for edition. The user can also provide a XML content as an already prepared XML file. Answer files will be saved and later used when a host profile with user interactions is applied on the specific host.


Provision an ESXi host

In order to provision a stateless ESXi host for the first time the host must be configured to perform PXE boot. Provided that Auto Deploy server and infrastructure environment has been configured properly the following additional steps must be performed:

  1. Create a deploy rule that impacts the target ESXi host.
  2. Activate the new created rule so that the rule engine evaluates the rule when receiving requests from the target ESXi host.
  3. Reboot the ESXi host to initiate the boot process.

Create rule

Use the workflow 'Create a deploy rule' to create a new rule. It won't be active.


Select an image profile from the already configured depots:


Optionally, select a datacenter, host folder or cluster within the vCenter Server inventory where the ESXi host will be registered:


After clicking of Submit button the process of creating the new rule will start. If the image profile is used for the first time it may take some time to finish the workflow. Of course later, if the same image profile is used again in some other workflow it will finish much faster. After successful completion of the workflow the new rule will be shown in the plug-in's inventory.


The next step is to activate the rule using the workflow 'Activate a deploy rule and a working set' so that it becomes active. Actually the rule will be added to the working rule set first and then the whole working rule set will be activated. It is not possible just to activate a single rule. This means that all rules in the order they are placed in the working rule set will be added to the active rule set.


After activation the rule is added both to the working and active rule set. It becomes non-editable and from now on it is evaluated by the rule engine on requests from the ESXi hosts. If you want to modify already activated or non-editable rule you must use 'Copy a deploy rule' workflow which actually hides the original rule and replaces it with completely new one.


After rebooting the ESXi host it will perform PXE boot and Auto Deploy server will provision it with the software images defined by the created rule. As we set also a vCenter Server location in the rule, the ESXi host will be registered in the specified host folder after booting.



Reprovision an ESXi host with a new image

This use case shows a simple use case when by modifying a single rule the ESXi host can be provisioned with a new software images (virtual infrastructure bundles). There are predefined workflows for reprovision ESXi hosts with new image, answer files and a new location. All of them assume that a modification on single rule is needed. Use the workflow 'Reprovision a host with a new image' to reprovision ESXi host with a new image.


If the image profile is used for the first time the workflow will take more time to complete. The workflow will reboot the ESXi host automatically and the host will load the new specified image:



The Auto Deploy plug-in provides basic building blocks as workflows and actions for interacting with Auto Deploy server and managing stateless ESXi hosts. The workflows can be used 'out of the box' or custom high level workflows can be composed according to the real use cases in order to automate  and greatly decrease the time and effort to provision and reprovision stateless ESXi hosts.


More info about VMware vCenter Orchestrator Plug-In for vSphere Auto Deploy: release notesdocumentation and download


Seamless integration with PowerCLI and PowerShell plug-in

The initial setup and main use cases of Powershell Plug-in for vCenter Orchestrator could be found in the previous post here .

In addition, PowerShell plug-in being able to run any PowerShell script doesn’t need some special things to work with PowerCLI scripts. The only thing one should do is to call the “AddPsSnapin” with “VMware.VimAutomation.Core” and it would be possible to use such cmdlets and scripts.



…But probably you would not like to throw away the work you have already done by creation of custom Workflows using the VC Plug-in. You will more probably like to extend it with PowerShell/PowerCLI scripts.

The good news is that you can mix both. This is made possible by a small module we call “Converter”. It actually converts PowerCLI objects into VC Plug-in objects and vice versa. Almost every object that can be seen into the VC Plug-in inventory can be converted.
Exemplary workflows that demonstrate the conversion functionality you will find in “Library/PowerShell/Samples/Converter”. There are a lot of building blocks if you look at its schema, but do not be scared. You only need to call a single action to achieve the conversion.

“convertToVcoObj” action converts the input to a VCO object. And “convertToPsObj” action converts VC:<Object> to PowerShellRemotePSObject.

What does this mean you would say.

This means that if RemotePSObject representing VM is passed as argument the “convertToVcoObj” will return Array/Any with size 1 and VC:VirtualMachine at index 0, which is reffering the same VM that the original RemotePSObject is reffering. Next you can use this object as an argument to any WF/Action that accepts VC:VirtualMachine or you can directly call methods on it.

The following diagram demonstrates this.    



The following table shows which types the Converter supports:

PowerCLI type vCO Object Type
VMware.VimAutomation.ViCore.Impl.V1.Inventory.VirtualMachineImpl VC:VirtualMachine
VMware.VimAutomation.ViCore.Impl.V1.Inventory.TemplateImpl VC:VirtualMachine
VMware.VimAutomation.ViCore.Impl.V1.Inventory.DatacenterImpl VC:Datacenter
VMware.VimAutomation.ViCore.Impl.V1.DatastoreManagement.DatastoreImpl VC:Datastore
VMware.VimAutomation.ViCore.Impl.V1.Inventory.ClusterImpl VC:ClusterComputeResource
VMware.VimAutomation.ViCore.Impl.V1.Inventory.VMHostImpl VC:HostSystem
VMware.VimAutomation.ViCore.Impl.V1.Inventory.ResourcePoolImpl VC:ResourcePool
VMware.VimAutomation.ViCore.Impl.V1.VM.SnapshotImpl VC:VirtualMachineSnapshot
VMware.VimAutomation.ViCore.Impl.V1.Inventory.FolderImpl VC:DatastoreFolder
VMware.VimAutomation.ViCore.Impl.V1.Inventory.FolderImpl VC:DatacenterFolder
VMware.VimAutomation.ViCore.Impl.V1.Inventory.FolderImpl VC:HostFolder
VMware.VimAutomation.ViCore.Impl.V1.Inventory.FolderImpl VC:VmFolder

If you wonder what actually the converter does behind the scenes look at the diagram below.



  • More info about VMware vCenter Orchestrator Plug-In for Microsoft Windows PowerShell: release notes, documentation, blog post and download