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.
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.
After its execution this script will create a new Subscription element in the AMQP plug-in inventory:
This subscription is ready to be used for a policy that will listen for vApp creation messages:
The workflow is started by the policy on every message and does the rest of the work:
The user must define the vCloud Director as a REST host in the inventory:
And then use it in the scripts to build the request URL:
The VMware vCloud Director REST API responses are XML documents but handling them is easy with E4X (ECMAscript for 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:
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.
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.
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:
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:
After all inputs and attributes are defined, I start the workflow and look into the vSphere Client to check the state of the deployment:
Also I check my vCloud Direcor App catalog for the new vApp template:
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)