vCloud Automation Center - a LabManager "rebirth"?

This week i had a very interesting conversation with a fellow at VMware. We talked about LabManager migrations and my experience in customer environments, when i was a consultant. There were two stages of migrations from VMware LabManager to vCloud Director in the past:

1. The organizational and administrative design
2. The migration of the virtual environment

The first one wasn´t easy to define, especially in large environments, caused by the different layers of administration. In VMware LabManager we had:

• Workspaces
• Organizations
• Configurations

In vCloud Director we have:

• Organizations 
• vApps

So there is an organizational layer missed. To be honest, there is one: the SYSTEM organization, but: you can´t limit the administrator account. So there is no chance to give the SYSTEM organization to the end-user or customer.

In fact the migration from VMware LabManager to vCloud Director needs to compromise.

The migration of the virtual machines wasn´t easy too, because you needed to enable the virtual machine operations in the VMware LabManager database what doesn´t sounds good without a tested and released tool.

Using vCloud Automation Center since the last DynamicOps version we talked about the administrative layers and a possible implementation. After a few minutes i thought that this could be the answer to the organizational migration of LabManager including Self-Service, API support (REST) and different endpoints (vSphere, vCloud) without administer "real" resources in vCloud Director as a SYSTEM administrator.

With this combination of resources delivered by the "internal IT" you are now able to create your own business logic for your lab environments. Starting with the Enterprise Groups to add resources to your environment you are able to build your Provisioning Group (like Workspaces in LabManager):

Based on those you can add Resource Reservations for this particular group:

And with all that in place you can now add the Blueprints (like Configurations in LabManager):

With the Self-Service Portal in vCloud Automation Center you are now able to control (based on the rights) the virtual machines, making snapshots or destroy them.

As you can see this is just a simple example, not explaining API methods or workflow enhancements (Microsoft TFS integration for example) but it should be a good way to "upgrade" your LabManager to a broader audience.

Feel free to ask in the comments :)

Using vCAC custom properties as vCO inputs

Based on the excellent blog post at vcoteam.info describing the decommission of services with vCenter Orchestrator integration, I searched for an option to deliver input values for workflows from vCAC to vCO.

A big thanks goes to my fellow Adam Bohle for providing me the essential answer :)

The "Extensibility Guide" describes different ExternalWFStubs for some states of the service lifecycle.

So this is where you can access external systems using the vCloud Automation Design Center. So the first step is to build or enhance a blueprint adding the ExternalWFStubXXX property. In my case I used the ExternalWFStubs.MachineProvisioned.

The next step is to add a new custom property "ValueToReceive" and let the user make some input (User Prompt = Yes).

So this was all from the vCAC side!

In vCO I designed a little workflow finding the virtual machine object with the vmName as IN-Parameter.

So in my case the value to receive is the vmName the user enters in the vCAC wizard. So let´s check out the vCAC Design Center workflow. First you have to "Load" the actual release of the WFStubMachineProvisioned workflow:

Now you can double click the "Custom Code" part of the loaded workflow and add two more variables: vmName (String) and VM (VirtualMachine).

The next step is to drag a "GetMachineProperty" element next to the "Start" element and open it with a double click:

Enter the values as shown in the screen and go back to the Custom Code (Navigation on top of the workflow).

Now drag the "InvokevCOworkflow" element next to the "GetMachineProperty" element, browse for the vCO workflow we designed first and enter "vmName" as Input and "myVm" as Output:

Now you can connect every step and you will see if there is any error. In my case I had to enter "virtualMachineId" in the VirtualMachineId field on the right upper side for the "InvokevCOworkflow" element:

When everything is okay (no error messages) you can now press the "Load" button and give the new workflow release a description. With this step the workflow is updated.

After the configuration you can now deploy a virtual machine ("Windows XP instance" in my environment) from the enhanced blueprint and the wizard will ask for a custom property called "ValueToReceive":

So this is the value our vCO workflow should receive. Keep in mind that this is just a functional example. You can do this with every option you want to provide ("Backup Network", "Additional Tools" etc.) to a vCO workflow.

When the machine is provisioned there should be a new workflow run with your value :)

Simple, isn´t it?

vCAC and vCO - a perfect match?!

Why is vCAC important to vCO you may ask... Because it´s the missing piece you need for intelligent rules, lifecycle management and role-based cloud usage!
Yes, you can build this with WaveMaker and any other Frontend, but you have to build the "business intelligence" and that´s what makes it really hard (trust me, I had several projects in the past).

So vCloud Automation Center allows you to provision VM´s and vApps in vSphere and vCloud environments based on roles and business groups. Sometimes this is enough. But, what if you want to integrate 3rd party systems, well know vCO workflows or partner applications based on vCO?

You can follow this excellent post, Tom O´Rourke and Joe Sarabia have written:

http://clearascloud.blogspot.de/2013/03/vmware-vco-workflows-integration-with.html

One thing that I missed to have a perfect match was the return value of the workflows. So I wanted to have the result displayed with the VM or in the self-service portal. So I checked for the options in the vCAC Designer and enhance the workflow with an additional option called "LogMachineEvent".

So I attached this WF element at the end and filled it with several parameters:

In my case the word "Ergebnis" (german for result) should be shown as info log message in the user´s selfservice portal. After uploading and xml/blueprint submission I was able to select the "Invoke vCO" option:

and received the result in my "recent events" log:

So just try it and it will become the perfect match :)

vCAC - vCloud Automation Center UI customization

At the VMworld 2012 the vCloud Suite bundle was announced. Within this new suite package a new automation tool has arrived: vCloud Automation Center aka vCAC. Many of you know that this was the former dnynamicOps aqcuisition.

With vCloud Automation Center you can do some really cool things and I will show more of it in the upcoming posts. Based on the "old" dynamicOps 4.5 bits I tried to figure out how to customize the vCAC self-service portal which looks like this:

As you can see, it´a really smart frontend with some nice slider, buttons and of course functions. Based on the IIS config you can find the folder which contains the self-service portal files:

Under "App_Themes" you can now create a new one. Now you can edit the web.config file and add your themes there. In the web.config file is a description what to do :)

With this step you can now choose what designs you will offer:

I also checked the used objects (javascript console) to find out which .css file is used. As you can see, the design URL "/DCACSelfService/Content/Styles/all.css" defines all the layout stuff.

So the App_Theme only manages the calendar. I changed my profile in "custom" and used the downloaded jQuery theme for the calendar which isn´t colored:

As you can see, it´a bit tricky but you don´t need a master degree to design your own layout. So have fun with all the colors :)

UPDATE: One thing to keep in mind! Like all of my posts this one is no official supported solution :)

vCO - VcOptionValue which value type?

Got some tricky task this week: Change the advanced parameter "NFS.MaxVolumes" of a ESX host to 256. First thought was: my post for VcOptionValue on the virtual machine. So I searched for the scripting class and wrote some like this:



var configMgr = myHost.configManager;

for(i in configMgr.advancedOption.queryOptions("NFS.MaxVolumes")){
            System.debug(configMgr.advancedOption.queryOptions("NFS.MaxVolumes")[0].key);
}

var oValues = new Array();
oValues[0] = new VcOptionValue() ;
oValues[0].key = "NFS.MaxVolumes";
oValues[0].value = 256;


try {
            configMgr.advancedOption.updateOptions(oValues);
}catch (e){

           System.log("Could not setAdvanced Settings. Error: " + e);
}



which should be run. But after firing this in vCO there comes an error message like: "wrong parameter" and "internal error". I looked into the vCO logs, the vSphere client and the vpxd.log but all messages didn´t show the exact problem.

After some investigation i found out that the type definition of the value is necessary! So there are some like int, float or long. In my case "long" was the answer. So the code has to look like this:




var configMgr = myHost.configManager;

for(i in configMgr.advancedOption.queryOptions("NFS.MaxVolumes")){
            System.debug(configMgr.advancedOption.queryOptions("NFS.MaxVolumes")[0].key);
}

var oValues = new Array();
oValues[0] = new VcOptionValue() ;
oValues[0].key = "NFS.MaxVolumes";
oValues[0].value_LongValue = 256;


try {
            configMgr.advancedOption.updateOptions(oValues);
}catch (e){

           System.log("Could not setAdvanced Settings. Error: " + e);
}

So, after the next test everything was fine :)

WaveMaker - handling SSL certificates

In the past some people ask for the SSL certificate handling of WaveMaker. This is mostly caused by WebService integration. With my new vCO 5.1 appliance I had the problem again. After generating a new certificate for the vCenter Orchestrator here I connected the WaveMaker and had to learn a hard lesson: no more HTTP API connection with SOAP! Checking the cause in the browser I could see that there is always a HTTPS redirection :)

So I had to import the certificate of the vCenter Orchestrator like this:

sudo keytool -import -alias vco51.vcloud.lab -file /Users/cjohannsen/Desktop/vco51.vcloud.lab -storepass changeit -keystore /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/security/cacerts 

As you can see the WaveMaker uses the JDK certificate store. So I had to export the vCO certificate (i used Firefox) and import it in the certificate store. The store password is originally "changeit". After a WaveMaker restart I tried to connect the https path:

https://vco51.vcloud.lab:8281/vmware-vmo-webcontrol/webservice?wsdl

and everything was fine.

With this its really easy to access the SOAP API. Next post will show how to connect the REST API with WaveMaker :)

vCloud Director - get chain length and consolidate a vCloud:VM

As you may know it isn´t possible to consolidate a VM as an organization administrator. In most environments the customer gets an Org (Cola for example) and can deploy vApps etc. but isn´t able to consolidate a vCloud:VM (i use the vCO syntax for explicit wording).

If you want to provide this function in a customer portal, with WaveMaker for example, you need to check the chain length and when the user decides the consolidate method has to be called.

I build a workflow:

The workflow has three steps: determination of the chain length, user decision to consolidate or not and the consolidate call itself. The first part (getChain script) looks like this:



myVm.updateInternalState();

System.log("VM name: "+myVm.name);

var doc = new XML(myVm.toXml());
default xml namespace = doc.namespace();
var n8 = new Namespace("http://www.vmware.com/vcloud/extension/v1.5");

System.log("ChainLength: "+doc.VCloudExtension.*::VmVimInfo.*::VirtualDisksMaxChainLength);

var chainLength = doc.VCloudExtension.*::VmVimInfo.*::VirtualDisksMaxChainLength;

if(myVm.vmStatus.value != 8){
throw("VM is not powered off!");
} 

As you can see I update the state of "myVM" (vCloud:VM) and setting the variable "chainLength" (number). The chain length is used as external input for the user interaction, so it´s possible to decide based on the count.

After the submission the myVm.consolidate() method is called and the workflows waits for it.

With my host.login() workflow you can combine the Org based login with the consolidation of vCloud:VM´s :)