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

Monthly Archives: February 2012

Getting up to speed on VMware vCenter Orchestrator: Cody Bunch book just released!

One question we get over and over again from vCenter Orchestrator users is "how do I get up to speed on vCO?"  The answer to that question can vary significantly because it really depends on a user's skill-set, how much he/she plans to automate with vCO, and whether that user prefers learning on their own or by attending a class.

Well, that question just got significantly easier to answer today thanks to the release of Cody Bunch's new book from VMware Press: Automating vSphere with VMware vCenter Orchestrator

 

Vcobook

Cody Bunch, one of our customers and the award-winning author of the blog ProfessionalVMware.com, provides an extremely valuable first-hand account of how to get up to speed with vCO and how other users can leverage it for their automation initiatives.  Not only does the book walk you through the initial installation, configuration and product overview, but it provides many examples of workflows that offer immediate value to help you manage your vSphere environment and perform cross-system automation.

The Kindle version is available today and, if you prefer the old-style approach, the print edition will be available in just a few weeks.  

If it weren't for the upcoming iPad 3 announcement, I can't think of any news that's as exciting in early 2012 😉

Happy reading and workflow development!

PS.  Looking for additional sources of information to complement the book?  Here are a few that are must-haves for your reference list:

 

Little big updates for our swiss-knife plug-ins

Three important vCO plug-ins have seen their first update release recently. These plug-ins are:

  • AMQP plug-in
  • HTTP-REST plug-in
  • SOAP plug-in

Most of the work done for those updates comes from the feedback collected from the users, through both our public communities and our Socialcast group.

Sknife3

And these are the main new features included within the update releases:

AMQP plug-in

  • SSL support has been added for RabbitMQ brokers.
  • The current API has been extended with delete and unsubscribe operations.
  • Other minor improvements and bug fixes.

See https://www.vmware.com/support/orchestrator/doc/amqp-plugin-101-release-notes.html

HTTP-REST plug-in

  • NTLM authentication support has been added to the existing BASIC and DIGEST.
  • Other minor improvements and bug fixes.

See https://www.vmware.com/support/orchestrator/doc/rest-plugin-101-release-notes.html

SOAP plug-in

  • NTLM authentication support has been added to the existing BASIC and DIGEST.
  • SSL support has been extended to the WSDL file download and parsing process.
  • A flexible SOAP request/response interception mechanism has been added and it’s available from scripting.
  • SOAP element attributes defined inside the WSDL file now are also available from the workflow presentations, both when invoking SOAP operations directly or when generating a workflow from them.
  • Access to root request/response element attributes has been enabled.
  • Other minor improvements and bug fixes.

See https://www.vmware.com/support/orchestrator/doc/soap-plugin-101-release-notes.html

Enjoy the new releases and don’t hesitate to provide your valuable feedback!

SNMP plug-in for vCenter Orchestrator

The SNMP plug-in allows vCenter Orchestrator to connect and receive information from SNMP enabled systems and devices.

These devices could include communication equipment (routers, switches, etc.), network printers, UPS devices and many others. Events from vCenter can also be received over the SNMP protocol.

The SNMP plug-in provides two different manners of communication with the SNMP devices – queries for the values of specific SNMP variables and listening for events (SNMP traps) that are generated from the devices and pushed to the registered SNMP managers.

Inventory

The SNMP plug-in adds inventory objects to vCO, that consist of a trap host and a set of SNMP devices.

Snmp.01.Inventory

The trap host node represents vCO listening for SNMP traps. It holds the basic configuration of vCO, acting as SNMP manager. It can be either online or offline, which is configurable with workflows.

The list of devices that follow the trap host holds configuration information that is needed for the access to these devices.

Each device can have a set of specific queries, which can be started, in order to obtain data from the device.

Device management

The list of SNMP devices is managed by the workflows in the Device Management section of the vCO workflow library.

Snmp.02.DeviceManagement

They reflect the whole lifecycle of an SNMP device:

1. Register an SNMP device

Snmp.03.RegisterDevice

With this workflow SNMP devices can be added to the vCO inventory. Device address is the most important parameter of the workflow. All the others are optional or have default values. It can be either IP address or DNS name, although using IP address is recommended, because SNMP is often used as diagnostic and problem-alerting protocol, and the dependency on DNS decreases it’s level of reliablity.

The name parameter is used to define user-friendly name. If skipped, the device address is used to generate a name autmatically.

By default, devices are registered for SNMP v2c version, on port 161, with community name “public”. In advanced mode these settings can be changed.

Supported versions are v1, v2c and v3. The support for v3 is limited to AuthPriv security level, with MD5 authentication and privacy with DES pass-phrase same as the MD5 password.

2. Edit an SNMP device

Snmp.04.EditDevice

The “Edit an SNMP device” workflow allows to change the properties of an already registered SNMP device. It has the same fields as the “Register an SNMP device” workflow, with the exclusion of the advanced mode radio button.

3. Unregister an SNMP device

Snmp.05.UnregisterDevice

This is a very simple workflow with only one field – a chooser of the device to unregister. When a device is unregistered, all the queries attached to it are lost.

Query management

Each device can have a list of queries attached to it.

Snmp.06.QueryManagement

They hold settings of object identifiers, query types, etc. They can be used as building blocks in more complex workflows.

1. Add a query to an SNMP device

Snmp.07.AddQuery

This workflow creates an SNMP query and attaches it to an SNMP device in the vCO inventory.

The allowed types are GET, GETNEXT and GETBULK. OID is the object identifier of the variable that we want to query. Only numeric OIDs are supported, with the single exception of OIDs that start with “iso”.

Examples of supported types of OIDs are: “1.3.6.1.2.1.1.5.0”, “.1.3.6.1.2.1.1.5.0”, “iso.3.6.1.2.1.1.5.0”.

If the name parameter is skipped, a name is automatically generated, using the type and the OID, like “GET 1.3.6.1.2.1.1.5.0”.

2. Copy an SNMP query

Snmp.08.CopyQuery

This is a convenient workflow, that allows to copy existing queries between registered devices.

3. Edit an SNMP query

Snmp.09.EditQuery

This workflow allows to modify existing SNMP queries. It has the same parameters as the “Add a query to an SNMP device” workflow.

4. Remove a query from an SNMP device

Snmp.10.RemoveQuery

This is a single parameter workflow, that allows to delete queries that are no longer necessary.

5. Run an SNMP query

Snmp.11.RunQuery

With this workflow, an SNMP query can be run. The result is retrieved as an array of properties in the following format (which is also logged to the vCO system log):
Element 1:

=============

oid: 1.3.6.1.2.1.1.5.0

type: String

snmp type: Octet String

value: myhostname

The type of the result is a high-grain selection between String, Number and Array. More specific type can be retrieved from the snmpType property, where the original type of the result is stored.
If more detailed result information is needed, any custom workflow may run queries in the same manner as “Run an SNMP query” and work directly with the returned SnmpResult object, which has the following structure:

Snmp.12.SnmpResult

Trap host management

These workflows handle how vCO is listening for SNMP Traps.

Snmp.13.TrapHostMgmt

1. Set the SNMP trap port

Snmp.14.SetPort

This workflow stops the trap host, sets the new port and then starts the trap host. It is important to note that the default port for SNMP traps is 162, but in Linux systems, it is not possible to open ports bellow 1024, without super user permissions. That’s why the default port for listening to SNMP traps in the SNMP plug-in is 4000. It can be changed to other one with this workflow, if 4000 is unavailable, or 162 is accessible.

2. Start the trap host

Parameterless workflow, that starts the trap host.
3. Stop the trap host

Parameterless workflow that stops the trap host.

Generic SNMP request workflows

They perform the basic SNMP requests, without the need to create a specific query.

1. Get SNMP value

Snmp.15.SnmpGet

Performs basic SNMP GET request, with the provided object identifier.

2. Get next SNMP value

Very common to the “Get SNMP value”, this workflows performs SNMP GETNEXT request.

3. Get bulk SNMP values

Snmp.16.GetBulk

Performs SNMP GETBULK query. Specific for this workflow is the “Number of results” field, which specifies how many result elements will be retrieved in one GETBULK request. The default is 10.

SNMP traps

There are two ways to receive SNMP traps in the SNMP plug-in. With workflow, which is waiting for a single trap message, or with policy, which can handle traps continuously.

1. Wait for a trap on an SNMP device

Snmp.17.WaitForTrap

This workflow features a trigger, which stops the execution of the workflow and waits for an SNMP trap to continue. When such a trap is received, the workflow is resumed. It can be used as part of more complex workflows, or as a sample that can be customized or extended for a specific need. The OID field identifies either the Enterprise OID of the trap, or any variable OID. If no OID is provided, the workflow resumes after receiving any trap from the specified SNMP device. Otherwise, it is waiting for a trap with the provided OID.

2. SNMP trap policy

Snmp.18.TrapPolicy

A policy can be used if it is necessary to continuously listen for traps from an SNMP device. For that purpose, the “SNMP Trap” policy template must be applied. After this, a policy with the specified name appears in the Policies group. To start listening for traps, this policy must also be started. If necessary, it’s “Startup” option may be edited, to allow starting the policy on server startup.

Snmp.19.Policy

Then a specific workflow or scripting code may be associated with this policy for integration in a more complex scenario.

SNMP traps can be sent to other systems with the “Send an SNMP trap” workflow.

Snmp.20.SendTrap

The manager address and port fields point to the receiving system. If the port field is left empty, it will be substituted to 162.

The enterprise OID is not mandatory. It identifies the type of the device that is sending the trap.

Type can be String, Number or Array. String values are sent as SNMP Octet String. Number values are sent as Gauge32. And the Array values are sent as multiple variable binding traps of Octet String SNMP type. Array values are represented as comma-separated list of oid:value pairs in the Value field of the workflow.

 

vCenter Orchestrator at VMware Partner Exchange 2012

With VMware Partner Exchange 2012 (PEX) starting today in Las Vegas, the intent of this short blog post is to highlight the presence of vCenter Orchestrator (vCO) at the event. If you are attending PEX, we welcome you to join us at the solutions exchange and several breakout sessions covering vCO.

First and foremost, stop by the VMware Booth (#1300) to check out live demos of the vCO and its plug-ins together with VMware Service Manager. You can also check out VMware Solution Exchange – the online marketplace that hosts all vCO plug-ins in a single location – including the ones developed by our partners like Infoblox, Radware, or VCE/EMC.

Next, you can also attend several breakout sessions to hear about vCO:

The vCenter Orchestrator team has been working hard on its misson to "automate the cloud". You can join us in this journey in various ways – extend your services offerings by including vCO, develop your own vCO plug-ins, evangelize vCO. Come on board!

 

Configuration Elements revisited

What are Configuration Elements?

A configuration element is a list of attributes you can use to configure constants across a whole Orchestrator server deployment. That’s what the vCO documentation states. In other words, the configuration elements are the easiest way offered by vCO to organize and establish a set of constant values which will be accessible from any key element of vCO (workflows, policies and web views).

Ce_1

A configuration element is a vCO entity composed basically of a list of attributes which are defined by a name, a type, and (once it’s configured) a value. Moreover, configuration elements support versioning, user permissions and access rights like other vCO entities.

How to create Configuration Elements

The creation of configuration elements is detailed on the official documentation, so there’s no need to describe it here (see http://pubs.vmware.com/vsphere-50/topic/com.vmware.vsphere.vco_dev.doc_42/GUID1A027CCA-B462-4580-A7E5-F0431CF75C3A.html).

How to use Configuration Elements

As example let’s define a workflow with some inputs, attributes and a scripting block that require to access to some configuration element to get the value from its attributes. The sample workflow would be used to send e-mail notifications from vCO, for example when some external event occurs or some specific condition is satisfied.

So on the one hand the workflow “Send notification message” defines these inputs:

  • To: the addressee of the notification (an e-mail address)
  • Subject: the subject of the notification e-mail
  • Body: the notification message itself

Also it contains this attribute:

  • From: the sender of the notification (a default e-mail address)

And furthermore, before sending the notification the workflow attaches a predefined footer to the body of the e-mail.

Ce_4

On the other hand the configuration element “Email” defines these attributes:

  • default_sender: the sender’s e-mail address, which will be different for different environments (e.g. development, integration or production)
  • default_subject: the default subject of the notification e-mail
  • default_footer: the default footer of the notification message, which may contain for example a legal notice text

Ce_1

Now let’s match the workflow elements with the configuration element attributes.

To set the value of an attribute
In that case it’s a workflow attribute but it’s exactly the same process for attributes of policies and web views.
You have to go to the General tab of the workflow in edit mode and select the option of linking the value of the attribute to a configuration element attribute. Then you choose the proper configuration element and the desired attribute.

Ce_6

Once you select the attribute it appears linked on the workflow’s attribute value.

Ce_7

In this way you linked the attribute “from” of the workflow to the value of the attribute “default_sender” of the configuration element “Email”. And after that you can use the attribute “from” like any other attribute inside the workflow.

To set the default value of an input parameter
The easiest way starts like setting the value of an attribute. You create an attribute called “default_subject” in the workflow and you link it to the value of the attribute “default_subject” of the configuration element “Email”. After that you go to the Presentation tab of the workflow in edit mode, select the input “subject” and add the property ”Default value”. Then you link the value of that property to the workflow attribute “default_subject” that you have just created.

Ce_8

Once you select the attribute it appears set on the “Default value” property value.

Ce_9

In this way you linked the input “subject” of the workflow to the value of the attribute “default_sender” of the configuration element “Email”.

To set the value of a variable inside a scripting block
The easiest way again starts like setting the value of an attribute. You create an attribute called “footer” in the workflow and you link it to the value of the attribute “default_footer” of the configuration element “Email”. After that you go to the “Schema” tab of the workflow in edit mode, select the Scriptable task element and add as a local input parameter the workflow attribute “footer”.

Ce_10

In this way you linked the scripting task input “footer” to the value of the attribute “default_footer” of the configuration element “Email”.

And once you have all the inputs of the Scriptable task element set properly you can actually write the code that will send the email (for example you could use the Mail plug-in and its EmailMessage object).

Ce_11

How to access Configuration Elements directly via scripting

The previous section describes how you can access to configuration elements via workflow attributes. That’s the easiest way but it has some minor drawbacks (or major if you use configuration elements a lot from your workflows). The two main drawbacks are:

  • You must define an extra workflow attribute for each configuration element attribute that you want to use inside that workflow.
  • You must set those workflow attributes as input parameters of each Scriptable task which you can get the attribute’s value from.

Alternatively, to avoid using extra workflow attributes, you can make us of a custom action that implements the logic for accessing to the proper configuration element attribute and getting its value. For example you can define an action like this, inside the module “org.company.mymodule”:

Ce_12

This action receives as parameters the path to find the configuration element, the name of the configuration element and the name of the attribute that you want to get from the configuration element. With that information the action tries to find the proper configuration element and return the value of the desired attribute.

The best is that you can invoke the action very easily from the presentation of a workflow (e.g. the case of the “Default value” property):

Ce_13

And you can invoke it also very easily from inside any Scriptable task without passing any extra input parameter to the Scriptable task itself:

Ce_14

The main benefits of that method are:

  • You avoid the extra workflow attributes.
  • You can invoke the action directly from workflow presentation elements.
  • You can invoke the action directly from any Scriptable task.
  • You could replace the logic of the action that gets the values from the configuration elements and use, for example, an external properties file or a database. Since you are writing the code here you have infinite possibilities.

And the only drawbacks are:

  • You have to make sure that the action is included inside your package.
  • You have to make sure that the proper configuration elements are included inside your package as well.

How to import/export Configuration Elements

You can import/export configuration elements in two ways:

  • Import/export a single configuration element
  • Import/export a set of configuration elements inside a package

The first way, import/export a single configuration element, is not very common. Here you probably want to import or export some specific configuration settings at development time to try them somewhere else. In that case, when you export the configuration element you get a file which contains the definition of the configuration element with both the list of attributes (names and types) and the values for those attributes. And when you import that file you create a new configuration element in vCO with again both the list of attributes and their values.

Ce_2

Ce_3

The second way, import/export a set of configuration elements inside a package, is the most usual because the configuration elements are used from other vCO entities. That’s why if you create a package containing a workflow, action, policy, or web view that uses an attribute from a configuration element, vCO automatically includes the configuration element in the package. Nevertheless there is a small difference with exporting a single configuration element, the difference is that in that case the values of the attributes are not exported! In another words, if you import a package containing a configuration element into another vCO, the configuration element attribute values are not set. This is because the configuration elements are supposed to define vCO server-specific settings. And for example, if you set the server-specific attributes directly in a workflow, the workflow probably won’t work with the same settings if you import it into a different server or environment. That’s why after importing a package that contains configuration elements you have to set them with values appropriate to the new server, otherwise some elements could fail (workflows, policies, etc.) because they might not find the attribute values that are required.

Conclusion

The configuration elements are a powerful mechanism offered by vCO to define constant values across multiple vCO entities. They are easy to create and easy to use in many common scenarios. And the only thing to be aware of is that when exporting and importing them inside a package, their attributes need to be set to the proper values of the new environment.

SQL plug-in comes on the stage to leverage basic database operations

SQL_plug-in_blog_icon

Are you still excited about SAOP and Rest plug-ins? Another powerful plug-in has already come on the stage! The VMware vCenter Orchestrator SQL plug-in provides fast and straightforward way to perform basic database operations like insert, select, update and delete of table records.

Let's learn more about its core features.

Packaged workflows

The SQL plug-in provides a complete set of workflows that allow you to:

  • Perform plug-in configuration
  • Generate basic create, read, update and delete record workflows for every table

SQL_plug-in_workflows

Plugin-in configuration

The SQL plug-in is configured by "Add/Update/Remove a database" workflows. In order to add a database we need to provide database name, type, connection URL and authentication credentials. We can also choose whether to provide username and password or to use the current vCO user credentials.

SQL_plug-in_add_database

After submitting all required information, the new database should appear on the Inventory.

SQL_plug-in_inventory

The inventory tree consists of all databases that have been configured so far. Under each database it is possible to see all tables in the default database schema and all table columns. Apart from adding, updating and deleting database configurations we are able to mange the list of tables that we want to see on the database inventory tree manually via "Add tables to database" and "Remove а table from database" workflows.

Generation of basic CRUD workflows for a specified table

Having your database properly configured you are able to generate basic create,read,update and delete workflows for each table. Let's choose the "ip_list" table.

SQL_plug-in_table_context_menu

Choose "Generate CRUD workflows for a table" workflow.

SQL_plug-in_generate_crud

Choose Destination directory and columns you will never populate with values (Read-only columns) if any.

SQL_plug-in_generated_workflows

The generated work workflows should appear on the workflows view in the "Generated" folder.

Perform database CRUD operations directly

Once we have generated the CRUD workflows for the tables we need, we are able to manage table records as simple as running workflows.

  • Creating an "ip_addresses" record

Run the Create active record for 'ip_addresses' workflow and fill in the necessary information.

SQL_plug-in_create_workflow

If we want to be sure that there is no such record in the ip_addresses table the "Validate for record uniqueness" radio button should be selected.

 

  • Reading records from "ip_addresses" table

Run the Read active record for 'ip_addresses' workflow and fill in all fields to search by.

SQL_plug-in_read_workflow

We need to fill in all fields we want to search by. There is also an option to guarantee unique result. If more than one records match the search criteria the workflow execution will fail with exception.

  • Updating a record from "ip_addresses" table

Run the Update active record for 'ip_addresses' workflow. First we have to fill in at least one field and then to click on the "Yes" load record button.

SQL_plug-in_update_workflow_1

If unique result is found, the record values are populated. We can modify some of the values and then to click on the Submit button.

SQL_plug-in_update_workflow_2

  • Deleting "ip_addresses" records

Run the Delete active record for 'ip_addresses' workflow. It will delete all records that match values we fill in the input fields.

SQL_plug-in_delete_workflow

All generated workflows could be used in higher level workflows when designing complete business scenarios. It is also possible to go with the plug-in scripting API in order to gain more flexibility needed in some complex use cases.

For additional information on this plug-in and to download it, please visit the following sites: