Home > Blogs > VMware vCenter Orchestrator Blog > Monthly Archives: September 2011

Monthly Archives: September 2011

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.

Snmp-vc-01-ServerSettings

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

Snmp-vc-02-DefaultTraps

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

Snmp-vc-03-AddAlarm

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

Snmp-vc-04-AddTrigger

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.

Snmp-vc-05-AddAction

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.

Snmp-vc-06-AddDevice

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.

Snmp-vc-07-policy

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.

Snmp-vc-08-waitTrap

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.

Snmp-vc-09-trapWaiting

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.

Snmp-vc-10-trapReceived

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.

It’s (Almost) All About Plug-ins (in 2011)…

If you missed VMworld Las Vegas, are reading this blog for the first time, or are just new to vCenter Orchestrator, then maybe you haven't heard the news… 

This year, it's all about plug-ins.

That's why we are very glad to announce two new vCO plug-in releases:

  • VMware vCenter Orchestrator Plug-in for vCenter Server 5.0
  • VMware vCenter Orchestrator SNMP Plug-in

As promised in a previous post, the vCenter Server 5.0 plug-in adds over 50 out-of-the-box workflows to extend capabilities around networking and storage operations, and to incorporate new features like Storage DRS into fully-automated, end-to-end cloud provisioning scenarios.  As previous versions, the plug-in provides 100% coverage of the 5.0 vSphere API.  With this new plug-in, organizations can now automate a broader number of use cases, such as dynamic scaling-up and scaling-down of vSphere resources, while taking full advantage of the new vCenter Server 5.0 capabilities.

And to complement this new release, we are also glad to announce a sparkling new SNMP plug-in that enables organizations to automatically trigger workflows based on SNMP messages.  SNMP (Simple Network Management Protocol) is one of the most widely used protocols to manage network devices and systems in IP networks and the default alerting mechanism for vCenter Server and ESX/ESXi. 

With the SNMP plug-in, you'll be able to define policies that automatically trigger specific workflows when SNMP traps are received by vCO. For instance, an administrator could configure a workflow that, upon detecting that a vCenter datacenter is nearing full capacity, would reclaim unused resources or provision additional compute and storage resources.  Of course, the SNMP plug-in is able to process events beyond vCenter Server, so the triggers for workflows can come from virtually any device or system that supports SNMP.

Finally, be sure to check our plug-in documentation site often to get information on update releases.  This week, new updates are available for the Cisco UCS Manager, Microsoft Active Directory and VMware vCloud Director plug-ins. 

For additional information, please see the following sites:

PS.  We'd like to take all of the credit, but we're far from the only ones building plug-ins.  In addition to Infoblox's recent announcement, we're glad to highlight Radware and Uptime Software, who have already released vCO plug-ins. Be sure to give them a try! 

Master of the integration – conquer VMware vCloud Director blocking tasks with the powerful vCenter Orchestrator plug-ins

One of the upcoming features of VMware vCloud Director is Blocking Tasks (call-outs). This enables a system administrator to configure many operations to block. They can be ublocked later by another application or can expire after a timeout. These blocking tasks generate AMQP messages that can be used to automate actions over them. This blog post shows vCO flexing muscles over blocking tasks. Doing this requires several plug-ins: AMQP, HTTP-REST, ActiveDirectory and Mail.

Whenever a vApp is created by an user in the vCloud Director the task is suspended and the user's manager receives a notification mail providing link for approval of the operation. When he approves, the vApp creation task continues in the vCloud Director. This is achieved by using a different plug-in on every step. AMQP plug-in is used to handle the blocking tasks notification messages. The HTTP-REST plug-in is used to communicate with the VMware vCloud Director over its RESTful interface. Active Directory is needed to find the user’s manager in the company's active directory database. Finally, the approval email is sent using the Mail plug-in. Webviews are used to build a simple web-based interface that the manager uses to approve or reject the vApp creation.

At the end of this article you can find links to a vCO package containing theexample and a video demonstrating the scenario. Jump right to the video at the end or read the details below describing  some technical aspects.

The message sent by the vCloud Director for the pending vApp creation is handled first by the AMQP plug-in. The next few lines of JavaScript show how to configure the subscription for the message. Note how the routing key is constructed. The detailed strucutre of the routing key is described in the vCloud Director documention.

Image1_setup_scripting

After its execution this script will create a new Subscription element in the AMQP plug-in inventory:

Image2_subscription_inventory

This subscription is ready to be used for a policy that will listen for vApp creation messages:

Image3_policy

The workflow is started by the policy on every message and does the rest of the work:

Image4_workflow

The user must define the vCloud Director as a REST host in the inventory:

Image5_rest_inventory

And then use it in the scripts to build the request URL:

Image6_rest_script

The VMware vCloud Director REST API responses are XML documents but handling them is easy with E4X (ECMAscript for XML):

Image7_xml

When the manager follows the web link in the notification mail he is brought to a web page showing again the request details enabling him to take an action on it:

Image8_webview1

Behind the scene the approve and reject buttons are handled by a script that answers the user interaction of the blocked workflow. When decision is taken the workflow continues and notifies the VMware vCloud Director to resume or cancel the pending task.

To get your hands dirty with this demo follow the link to the package that contains the example. It won’t work out of the box because the AMQP broker and the VMware vCloud Director configuration must be updated to match yours. Also the message handling policy must be manually created since policies cannot be distributed in a package.

Here is a video demonstrating the whole scenario: