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

Tag Archives: vCenter Server

VMware vCenter Orchestrator 5.5 is now GA!

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

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

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

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

 Optimized for growing clouds

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

Workflow Debugging

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

Security Enhancements:

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

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

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

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

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

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


The vCO Team

Important vCenter Orchestrator Plug-in Updates

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

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

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

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

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

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

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

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

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

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


The vCO Team

VMware vCenter Orchestrator 5.1 is now GA!

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

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

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


Launch Workflows Directly from the vSphere Web Client

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


Develop Workflows More Easily

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


Richer Integration Capabilities

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

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

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

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


The vCO Team



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


SNMP plug-in – integration with vCenter Server

In this post we will show how you can use the SNMP plug-in to receive various vCenter Server alarms in vCO and include these events as part of more complex orchestration logic.

vCenter Server configuration

First, you must register the vCO server in the list of SNMP trap receivers in vCenter Server. This list is accessible in the vSphere client, in vCenter Server Settings, which is accessible from the Administration menu.


You can have up to four different receivers, one of which must link to the address of your vCO server and the port defined in the Trap Host node in the SNMP inventory in vCO.

Configure Alarms

After you have registered the vCO server, vCenter Server can send SNMP traps to it. Some traps will start to be sent immediately. Many alarms in vCenter Server are configured to send traps by default.

Some default alarms are defined on the root of the vCenter Server inventory (1), from where they propagate to all child objects. If you go to the Alarm management tab (2), you can check the definitions (3) of the default alarms. Selecting a specific alarm (4), you can check on its Actions tab (5) if sending SNMP traps is active for this specific alarm (6).


These settings can be changed on the object where the alarm is defined. If the fields are not editable, then this is an inherited alarm, and you need to find the parent object that defines the alarm to change the settings.

Create custom alarms

Sometimes you may need to monitor something specific that is not part of the default alarms, or you only want to monitor it for a certain host, virtual machine or other object. Then you need to add a custom alarm to the object (a datastore in this example).


Then, you need to add some triggers which define under what conditions this alarm should be triggered.


Finally, you need to add an action that will send a trap. Note that you may need to add handlers to state changes. For example, the green to yellow state change does not send a trap, as by default only the yellow to red state change is defined to send a trap.


After this, the vCenter Server instance is ready and is sending traps to vCO.

Configure vCO to receive traps

On the receiving end, you first need to add the vCenter Server instance to your inventory with the “Register an SNMP device” workflow.


Then you can either apply a policy, which will be receiving all kinds of traps and running scripts on each of them, or start a workflow, which will be waiting for a specific trap.

The policy is applied from the Policy Template “SNMP Trap”, and takes as a parameter the SNMP device that you just registered.


This exact policy is only printing the trap data to the system log, but it could do other tasks, such as, call actions or workflows that should handle the received traps.

You must start the policy after it is created, or set it to auto-start if you need it to work after server restart.

You can leave this policy to be listening for traps for the moment, and check the other possibility to receive traps – the “Wait for a trap on an SNMP device” workflow.


After you enter the device and OID parameters and run the workflow it reaches a trigger where it suspends and starts waiting. It can be resumed only by the specified SNMP trap.


If the OID field from the workflow presentation was left empty, then the workflow will be resumed by any trap, just like the the policy. Any trap filtering on the policy must be done programatically, after the trap is received. Listening to all incoming traps can help you easily get the correct OID that will be sent from vCenter Server for a specific alarm. These OIDs are also listed in the MIBs that are described in vSphere Datacenter Administration Guide, in the “Monitoring Your Virtual Infrastructure” section, chapter “SNMP and vSphere”.

If everything is configured correctly, vCO should start receiving SNMP traps and trap data will be logged from the policy, like in this example, which is monitoring datastore space usage.


The SNMP plug-in is not limited only to use with vCenter Server. It can be used with any SNMP-enabled system or device. This is just one scenario that shows how the SNMP plug-in, together with the workflow library from the vCenter Server plug-in, can be used as the basis for the automation of various datacenter administration tasks.