Category Archives: vRealize Orchestrator

New Pluralsight Course – Introduction to Workflow Development with VMware vRealize Orchestrator

I’m pleased to announce that as of last week, Pluralsight have released my first Training Course on VMware vRealize Orchestrator. I’ve been working with this product since the early days and I couldn’t be more thrilled to have completed a 2 hour course teaching people how to get up and running quickly.

Here is quick a video overview of the Course:

I aimed this course at getting people into workflow development. This means I don’t focus on product installation and plugin installations, but more on specifically how you can develop and code the workflows.

The course contains the following 7 modules:

  1.  Getting Started – A tour of vRealize Orchestrator and the components.
  2. Building Workflows – Approach to workflow design, followed by some basic workflow creation.
  3. Scriptable Tasks – Learn some basic Javascript and start using Scriptable tasks.
  4. Input Presentation and Additional Javascript – Learn some basic ways to use the presentation view, as well as more javascript.
  5. Actions – Turn scriptable tasks into reusable actions.
  6. VMware Tools and HW Upgrade – A basic real world example for combining workflows in a real world use case.
  7. Snapshot creation and automated deletion – Create a snapshot and then schedule it for automatic deletion at a future date.

In addition to my course, I also work with a large number of customers in my role at Ahead. For anyone looking to get started with Orchestrator, Ahead also now offers an AHEADStart for VMware vRealize Orchestrator which takes care of all the plumbing and gets people up and running with the product.

Please enjoy the course and I would absolutely love any feedback. Teaching in this format has been completely new to me and took some learning and getting used to. I can certainly tell when comparing the first 2 modules to the last 2, the difference as I got more comfortable. I plan to circle back and write about my experience for anyone else looking to do a course in this manner.

Finally, I can’t say enough great things about working with the Pluralsight team. Simply great people.



It’s ON with Turbonomic and vRO

There have been a lot of changes for VMTu Turbonomic.  I believe most in the industry are aware of the bold name change.  This name is more representative of what the product does based on the economic model it is known for.  Besides that with the latest version, Turbonomic also released vRealize Automation workflows to integrate with their product.  You have to be a member of the Green Circle, which is free, but you can download them here.  There are instructions on importing the workflows, setting up Operations Manager as a REST host, etc.  I was excited to see this but, unfortunately, my environment only uses vRealize Orchestrator.
Below is the schema for vRA workflow:


First is a scriptable task to gather inputs for vRA.  The inputs are all vRA specific so I could remove these. At the end it, the workflow is pushing back properties to vRA so I removed “Override vRA Settings” at the end.

Inputs removed from original VMTurbo Main workflow:



My workflow ended up like this, removing vRA dependencies and ending with 2 scriptable tasks to convert the datastore and host to VC:objects instead of strings.  These scripts will be covered in another post.


My inputs end up moving from general attributes and are templateName, clusterName and datacentreName. In the future I will likely add a scriptable task at the beginning of the workflow to determine these as they will come from inputs generated by my Windows or Linux Master Build workflow.

Inputs converted from attributes:


I also now have outputs for the actual VC: Datastore VC: Host System objects for your clone workflow in vRO. These were created via the scriptable tasks which take the strings returned from Turbonomic and do a lookup to match them to the vCenter objects.

Outputs created:



What’s great about having this functionality from Turbonomic is now the best host and the best datastore will be selected based on analytics from Operations Manager. I originally was picking my datastore based on amount of free space but now using the REST API I can have the least utilized host and datastore supplied to by clone workflow.

Download the modified workflows here.

I’ll be going over these workflows in the upcoming webinar “Overcoming Private Cloud Challenges in Healthcare IT”, September 29th at 2:00PM EST.  Register here

vRealize Orchestrator Appliance – Guest File Operations Part 1 – (Copying a file to guest VM)

One of the things you will often find you need to do with vRO is to get a file to a guest VM, or just run a file from inside the VM. Now for Windows you can use Powershell remote features in many cases, but what if your server isn’t on the network yet? Until version 5.1 we had to rely on VIX as a way to do this, but now VMware has added a number of new workflows under “Guest Operations” which are much more reliable.

vCO Guest Operations

vRO Guest Operations

“Copy file from vCO to guest” is the one I’m going to be using in this example.

First of all copy the workflow into a sandbox area. This way you can move a bunch of the inputs to attributes and not have to key them in each time (e.g. The local administrator username, password, and test VM).

In my example, I’m going to create a text file called test.txt in a new folder under /opt called “vcofiles”.

My target machine is a Windows 2008 R2 server, where I will copy the file and place it in the C:\temp\ folder with the name “testcopy.txt”

If you run the workflow then these are my input parameters:


The problem is that if you run this you will get an error similar to this:

“No permissions on the file for the attempted operation (Workflow: Copying files from vCO appliance to guest/Scriptable task…”



In order to fix this you first need to give the correct rights to the folder and file on your vCO Appliance.

1. Login as root onto the appliance
2. Give Read/Write/Execution rights to the new folder


3. Give Read/Write rights to the Text file you made


Unfortunately we aren’t quite done yet. You also need to tell orchestrator which locations it can read/write/execute from. This involves editing the “js-io-rights.conf” file located in “/opt/vmo/app-server/server/vmo/conf”


Add the line “+rwx /opt/vcofiles/” as shown above.

If anyone isn’t too sure on the linux commands to do this:

  • Type “cd /opt/vmo/app-server/server/vmo/conf” and press enter.
  • Type “vi js-io.rights.conf” and press enter.
  • Use the arrow keys to move the cursor where you want and press the insert key
  • Press Enter and type in the line “+rwx /opt/vcofiles”
  • Press ESC
  • Type “:wq” and press enter.

4. Now, there’s one more thing. You need to restart the vCO service for this to take effect.

Login to the vCO configuration manager, go to startup, and click restart service.


5. Now run your workflow and see if your text file copied across.


You can see a quick video demo of this on youtube. (apologies for the mouse pointer issue..)

Thanks for reading. Let me know if you have any questions.


vRealize Orchestrator Workflow: Change VM Port Group for VM on Standard vSwitch

*Note: This is a repost due to moving my posts from to”

I was surprised recently to find that no builtin workflow existed for changing the backing information for a VM if you aren’t using a VDS. Now, before I go any further, I’m a big fan of moving to a vSphere Distributed Switch mode, but there are certainly cases where you might encounter a standard vSwitch environment which you need to automate port group changes upon.

The Approach:

Essentially when it comes to changing NIC settings on a VM, you have to change the “Backing” information for the NIC associated with the VM. In my case this was for VMs which were just built as part of an overall automation process, and had only one NIC.

Step 1: Create Action Item.

I created an action item which has 2 inputs.

“vm” of type VC:VirtualMachine – This is basically so you can select the VM in vCO that you want to modify

“vSwitchPGName” of type String – This is so you can pass in the string value of the portgroup name for the vSwitch.


The code I then used is below. I’ve commented it but please let me know if you have any questions.

var spec = new VcVirtualMachineConfigSpec(); // Initialize a Virtual Machine Config Spec first
var myDeviceChange = new Array(); // Create an array to hold all of your changes
var devices = vm.config.hardware.device;

//Find devices that are VMXNET3 or E1000
for (var i in devices)
		if 	(
				(devices[i] instanceof VcVirtualVmxnet3) ||
				(devices[i] instanceof VcVirtualE1000) 
			System.log("The device we are going to modify is: " + devices[i]);
			var nicChangeSpec = new VcVirtualDeviceConfigSpec(); //This is the specification for the Network adapter we are going to change
			nicChangeSpec.operation = VcVirtualDeviceConfigSpecOperation.edit; //Use edit as we are going to be modifying a NIC
			nicChangeSpec.device = new VcVirtualE1000;
			nicChangeSpec.device.key = devices[i].key; 
			System.log("NicChangeSpec key is : " + nicChangeSpec.device.key);

			nicChangeSpec.device.addressType = devices[i].addressType;
			nicChangeSpec.device.macAddress = devices[i].macAddress;

			System.log("Adding backing info" ) ;
			//Add backing information

			nicChangeSpec.device.backing = new VcVirtualEthernetCardNetworkBackingInfo();
			System.log("Backing info for nicChangeSpec is : " + nicChangeSpec.backing);
			nicChangeSpec.device.backing.deviceName = vSwitchPGName; //Change the backing to the portgroup input
			System.log("Backing info for deviceName on nicChangeSpec is : " + nicChangeSpec.device.backing.deviceName);

			//Push change spec to device change variable


spec.deviceChange = myDeviceChange;
System.log("DeviceChange Spec is: " + spec.deviceChange);
return vm.reconfigVM_Task(spec);

Step 2:

I created a simple workflow which calls this action item and then has a vim3WaitTaskEnd so we can be sure the task is completed before moving on to any other workflows. This is useful if you are going to be incorporating this action into a larger process.

Update Port Group for vSwitch

Running the workflow gives you this simple presentation.

vSwitchPG 2

And that’s basically all there is to it. Select your VM, type in your PortGroup name, and voila!

For a vDS, VMware included a workflow out of the box in vCO so there is no need to create any of the above.