Archive for November, 2013

vCloud Orchestrator, Automating Org,vDC,vApp Provisioning via CSV Part2–reading CSV files

November 11, 2013 Leave a comment

In part 2 of this series, we will explore the required java script code required to read CSV file and load the information into vCO.


To use the code, drop a scriptable task element in the workflow, and make sure to link all the required parameters to it from the previous workflows:


The code will read the following CSV file format:


the csv has the following format: VMname,OS Edition,No. of CPU. Memory, No. Of Disks, HD1 size in GB, HD2 Size in GB, HDX size in GB.

now the JavaScript code required to read this file is:

var csvFileName = "c:\\Orchestrator\\customer.csv"; 

var fileReader = new FileReader(csvFileName);; 
var line=fileReader.readLine(); 
Server.log (line);

    while (line != null){ 
Server.log ("loop Started");
var lineValues = line.split(","); 
var linelength = lineValues.length
var vmname = lineValues[0];
var MyTemplateName = lineValues[1];
var MyNoCPU = lineValues[2];
var MyNoMemory = lineValues[3];
var MyNoDisks = lineValues[4];

var myaddVMWorkflowToken = new WorkflowToken() ;
myaddVMWorkflowToken = MyAddVMWF.execute(addVMworkflowParameters);
myaddVMworkflowTokens = new Array(); 

The first section read the file and opens it then starts reading the file line by line, the While loop will start looping through the file contents line by line and splitting each line using “,” as a delimiter.

once the information is loaded, we are ready to take actions in each line, the actions will be running workflows to create the VM and assign the proper NIC, Memory and CPU to it.

The Second part, Will call another workflow, but let us explore why we are doing that…

Running External Workflow using JavaScript and wait for its completion:

The work flows that we will run is a custom workflow that we will create to lookup the data from vCloud Director, what do we mean, let us explore:

To create a VM from a template VM, we will create a vDC with all the templates that we need:


We will use those VMs as templates that we can close, but let us explore first the built-in workflow in orchestrator “Add vApp Virtual Machine”:

This Workflow takes the following inputs as parameters:


a vApp where the VM will be placed, the source vm that will be cloned and the new VM name, the problem is that the vm input is from type vCloud:VM, but the VM name we read from the CSV file is string, so we need to search for the template by its name and return the object vCLoud:VM type with that name to this workflow.

Note: I wish if there is something like powershell (get-vm –name “myvm”) byt there isn’t , if you know a better way, I will be glad to do so.

So, how we can search the VM by name, we will create a new workflow with a scriptable task as following:


and takes the following inputs:


Configured with the following parameters:


and the scriptable task element runs the following code and configured with the following local inputs:



var CloneVMWFParameters = new Properties();
var queryService = AttSourceVapp.getHost().getQueryService();
var expression = new VclExpression(VclQueryVMField.NAME, INPTemplateNameString , VclExpressionType.EQUALS);
var filter = new VclFilter(expression);
var params = new VclQueryParams();
var resultSet = queryService.queryRecords(VclQueryRecordType.ADMINVM, params);
    var records = resultSet.getRecords(new VclQueryResultAdminVMRecord());
Server.log (records.length);
for each (var record in records) { 
        if (record.vdc == vdc.getReference().href) { 
            var VMref = new VclReference(); 

        VMref.href = record.href; =; 
        VMref.type = record.type;
      myVMname = host.getEntityByReference(VclFinderType.VM, VMref);


var myCloneVMWorkflowToken = new WorkflowToken() ;
myCloneVMWorkflowToken = AttvappVMWF.execute(CloneVMWFParameters);
myCloneVMWorkflowTokens = new Array(); 

     The workflow creates a variable CloneVMWFParameters of type properties and creates a new query to search for a VM with the name of the template, it will make sure that this VM is located inside the vDC where templates are stored (if (record.vdc == vdc.getReference().href) ) then returns the VMobject with its href and name and type.

we then construct a a workflow properties to call the “Add vApp Virtual Machine workflow” with the vApp, VM object and New VM Name and then execute it and wait for its completion.

Reverting back to the initial code, we talked about:

var myaddVMWorkflowToken = new WorkflowToken() ;
myaddVMWorkflowToken = MyAddVMWF.execute(addVMworkflowParameters);
myaddVMworkflowTokens = new Array(); 

So we are creating the var addVMworkflowParameters as properties and we construct the properties with following parameters (INPdestinationVapp name “the vApp was just created”, INPTemplateNameString “the name of the template VM, this name was read from the CSV”, and the INPVMNameString which is the new VM name”).

Now our caller workflow will query the vcloud director for the template name, return the VM object corresponding to it, and then call the “Add vApp Virtual Machine” workflow with the parameters and copy the VM to the destination vApp.

If you have a smarter way to do it, let me know, I got the feeling that there might be a better way to do it.

In part 3, we will add NICs, Memory and HDs and in part 4 we will take a look on how to send email notification and add approval cycle, so stay tuned Winking smile.


vCloud Orchestrator, Automating Org,vDC,vApp Provisioning via CSV Part1

November 5, 2013 Leave a comment

Part 2  here:

Hi There, during the past months I was working on this insane idea of automating the cloud provisioning. I eat,drink and breath (probably piss) cloud but I had a dream about automating the provisioning cycle and making it smart.

In this blogging series we will explore how you can use your vSphere, vCenter, vCloud and vCloud Orchestrator to provisioning clouds on the fly.

I know that there are a lot of blogs out there that speaks about how you can put some workflows to provide simple provisioning, this blog will take it a notch higher by doing it in a practical way. you don’t expect in real life people to login and supply cloud’s information, everything is in Excel.

By the end of this blog series we will:

– Configure cloud provisioning to provision Org, vDC and vApp using a single user input and link 3 workflows.

– Provision a VMs based on settings supplied in a CSV file, we will customize the HD sizes and no. of those VMs based on the settings supplied in the CSV.

– We will add a twist to add approval cycle to the process and send email to the approver with the CSV file to review and a link to approve the request, cool ha Winking smile.

If you are old or new to orchestrator I guess you will like this series, we will touch on core concepts as well as new/advanced concepts with some Javascripting as well, so let us get started:

Part 1: Linking “Add Org” , “Add a vDC” and “Compose a vApp”:

before we get started, make a folder in your vCO and call it for example (Full cloud provisioning) and duplicate the “Add Org” , “Add a vDC” and “Compose a vApp”.

Create a workflow, call it Full Cloud Provisioning or any name you want, and add the workflows to it to create an org, then a vDC and a vApp, and link them together.


once the workflows are linked, we need to work our way through the in-parameters so we can have them set properly.

The workflows will required various inputs including the default vCloud host, Org/vDC name and various types of settings like lease duration, storage profile..etc, the most important thing for this blog post is the name, so link the inputs in the Add Org workflow as following:


you can set the other settings like (LDAP mode, SMTP host..etc) as attributes and pass them to the input parameters and that will make those inputs not needed thus not visible by the user, you can do the same of number of VMs, storage/memory/CPU limits, or you can have them in the presentation, for the purpose of my lab, I linked them to attributes in the my workflow, so they are static for every customer, but you might want to customize that based on your environment:


here is how I set my parameters:


Passing out-parameters to Input parameters in vCloud Orchestrator:

Before delving in this, let us discuss first the vCO attributes/input types. If you noticed in the above screenshot, you will find that we have (for example) an attribute called host and its type is vCloud: host, so what is the type thing?!

Attributes/inputs are defined in types based on their usage, so if you are doing same mathematical operations, you create a variable of type (Number), to hold text data you create a variable of type (String).

In vCO, we have additional set of types, like the vCloud:host or vCloud:vDC (those are for example, we have zillions of other types), which allows you to set these variables, parameters or inputs to carry specific type of data in them.

For Example, the host type, will always expect to carry in or out a vcloud:host data, you can’t pass text (string) to it but you can take it out as string, and same for a vDC, it will always expect to carry in/out a vDC.

Why I Explored this first, because if you set everything correctly and run the workflow, you will find that the add vDC workflow expects to be hosted within organization, and we need to specify the organization where this vDC will be hosted (and the same applies for vApp since it needs a vDC), but we can’t specify the vDC because it has been not create yet and the same is true for the organization, so how can we fix that ?!

I spent a month trying to figure this one out, I came from .net/Opalis background where we can pass the outs of one workflow/program to the inputs of another workflow/program, but this is not the case in vCO, you can’t do that.

To do that, you will need to create a parameter of the same type that you want to pass the out parameters to it , where it could be carried to the next workflow as in-parameters, you must pay attention to the type or the data won’t pass.

so for example, I created a parameter called MMvDC (I should have named it MyOrg) with the type vCloud: Organization, to carry the organization name from my “Add Org” workflow to the create vDC workflow, the same for mVDCName attribute of type vCloud:vDC to carry the vDC name from the Add a vDC workflow to the Compose a vApp workflow.

The next step is to bind the out parameters to those attribute, so to carry the organization name, I need to link this attribute with the out parameter, and since attributes are accessible across all workflows, I can use this attribute in any upcoming workflow and this is how we can skip entering organization/vDC names in subsequent workflows because they will receive those inputs with the correct types in there in parameters:


Now in the Add vDC workflow, you can see that it needs input (org) as type vCloud: organization, but I can supply this input on the fly from the previous workflow by linking the MMvDC attribute to the org input:


You can also see that I linked the vDCout parameter to the myVDCname attribute to carry the VDC to the compose vApp workflow.


by doing the above trick and working out the required inputs/parameters, the resulting workflow and presentation will be something like this:


So all what you need to do is supply organization name, and vCO will go and create in vCloud director an organization, a vDC and vApp inside that vDC to host VMs.

In the next blogpost, we will explore how we can read a CSV file and create VMs inside that vApp Winking smile.

%d bloggers like this: