Home > Blogs > VMware vCenter Orchestrator Blog > Tag Archives: vCloud Director

Tag Archives: vCloud Director

Your Guide to “Orquestación” Goodness at VMworld 2012 Barcelona

 

You can decide to refresh your Spanish (or even better yet, your Catalan) and memorize the following sentence:

¿Por favor, donde son las demos y sesiones sobre vCenter Orchestrator?

Or you can make it easy on yourself and use the list below to help with your orchestration immersion planning at VMworld 2012 in Barcelona 🙂

Below is a list of events you won’t want to miss…

 

Breakout Sessions and Group Discussions

INF-VSP2033  Auto Scaling and Cloud Bursting in the Hybrid IaaS cloud

OPS-CIM1274  What’s New in vCenter Orchestrator 5.1

OPS-CSM1379  Extending vCloud Director

OPS-CIM2892  Making IaaS and APaaS Available to the IT Masses: Rolling Out Self Service for the Cloud

OPS-CIM2179  Transforming Your Cloud with VMware: Day One – Building Your Cloud

GD-41  vCloud Director Architecture, Integration and Orchestration with Chris Knowles

 

Hands-on Labs

HOL-OPS-07  vCenter Orchestrator “The undiscovered country”

HOL-PRT-01  Automate IP Address Assignment & DNS Registration with Infoblox

HOL-INF-09  Deliver your IT Services in the Cloud

 

Booths

EMC, F5 Networks, Infoblox, Radware, VCE and VMware for some really cool demos…

 

We had some great discussions with many customers in San Francisco and are hoping to repeat that in Barcelona.  So please, come by the VMware vCO/DynamicOps booth to see the latest 5.1 release, share your experiences, and get your questions answered.

¡Hasta pronto!

The vCO Team

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:

 

Delivering VMs into vCloud Director with vCO

When starting with vCloud Director the most asked question I receive is: "How can we deploy our customized VMs into the vCloud Director?". The reason is that a VM template or vApp is used for vCloud Director.

With this example I want to show how easy it is to build a VM and deliver it to the vCloud Director using vCenter Orchestrator and it´s plug-ins.

Of course, there are several methods to automate these imports:

  • clone a customized VM into a VMware template for vCD import
  • choose and transform an existing VM into a vApp

The following simple example is based on the workflows "Create simple virtual machine" and "Import VM as vApp" and a little scriptable task for MoRef (ID of the VM) translation. Both workflows are standard workflows, delivered with the vCO library and vCD plug-in.

Bildschirmfoto 2011-06-04 um 10.54.02

To keep it simple I used some static inputs (datastore, host-system etc.). In real environments I automate these too, like choosing the datastore based on free space and left space. With these static parameters the inputs are reduced to:

Bildschirmfoto 2011-06-04 um 11.01.06

In most environments there are some specific steps for the customized deployment of a virtual machine, like Altiris trigger for Windows or ssh deployment commands for Linux, but there is no deployment server in my lab 🙂

The small scriptable task in the middle is used for delivering the MoRef ID of the new VM as input for the "Import VM as vApp" workflow:

Bildschirmfoto 2011-06-04 um 11.08.50

After all inputs and attributes are defined, I start the workflow and look into the vSphere Client to check the state of the deployment:

Bildschirmfoto 2011-06-04 um 10.53.30 

Also I check my vCloud Direcor App catalog for the new vApp template:

Bildschirmfoto 2011-06-04 um 11.13.16

And finally my new VM is deployed and registered in the vCloud Director as a new vApp template in my Application catalog. For sure this is only an example to show the direction. In normal use cases there a few things more to do:

  • ensure that applications are proper installed and able to get cloned
  • define a application catalog for the right departments (HR for example)
  • setting the right users and groups

So, get your feet on the street and test it!