Tag Archives: vCO

Kerberos authentication for the PowerShell plugin in vCO 5.5

1 The ability to have vCO kick off PowerShell scripts is pretty awesome!  And the fact that you can kick these off contextually inside of the vSphere Web Client is even more awesome!  Even more awesome than that, yes, that’s a lot of awesome is the new features offered with vCenter Orchestrator 5.5 – So, I’ve taken the plunge on one of my environments and upgraded.  Since then I’ve been slowly migrating workflows over – one of which utilized the PowerShell plug-in.  Now, since the appliance mode of vCO requires you to do a rip and replace rather than an upgrade (because I’m using the embedded database) I had to reinstall the PS plugin, therefore forcing me to reconfigure the Kerberos settings on vCO.   During this I realized that things are a little bit different than when I first blogged about vCO and PowerShell here.  Below is how I got it to work…

First up is the WinRM setup on your PowerShell host.  This process  hasn’t changed from 5.1, however I’ll still include the steps and commands that need to be run below.  Remember these are to be executed on the Windows box that you wish to run the PowerShell script from.

  • To create a winrm listener and open any required firewall ports
  • winrm quickconfig
  • To enable kerberos authentication
  • winrm set winrm/config/service/auth @{Kerberos=”true”}
  • Allow transfer of unencrypted data
  • winrm set winrm/config/service @{AllowUnencrypted=”true”}
  • Up the max memory per shell – I needed to do this to get things working
  • winrm set winrm/config/winrs @{MaxMemoryPerShellMB=”2048″}

No on to the krb5.conf file – this is where things get a bit different.  In vCO 5.1 we were required to edit the krb5.conf file located in /opt/vmo/jre/lib/security/ – well, if you go looking for that directory on 5.5 you won’t find it.  Instead, we need to create our krb5.conf file in /usr/java/jre-vmware/lib/security/  As far as what goes in the file it is the same and is listed below…(obviosoly substituting your own domain for lab.local and your own dc for the kdc definition).

default_realm = LAB.LOCAL
udp_preferences_limit = 1   [realms]
kdc = dc.LAB.LOCAL
default_domain = LAB.LOCAL
}   [domain_realms]

After you have saved the file in the proper directory we need to modify the permissions.  The following line should get you the proper permissions to get everything working.

chmod 644 /usr/java/jre-vmware/lib/security/krb5.conf

Just a few other notes!  You might want to modify your /etc/hosts file and be sure that you are able to resolve the fqdn’s of both your dc and the PowerShell host you plan to use.  Also, when adding the PowerShell host be sure to select Kerberos as your authentication type and enter in your credentials using the ‘[email protected]’ format.

For now, that should get you automating like a champ!

Why Orchestrate?

Orchestrate-FacilitateAs you all can probably tell by reading my blog lately I have went head first down a path that lead me directly to vCenter Orchestrator.  Honestly, since doing that I haven't looked back.  I've known about the application for quite some time but never could find a use case for it in my environment.  Sure, getting the same results every time is great, that's the most obvious reason to script anything, but I had already been achieving this with Perl, PowerCLI and PowerShell, so why orchestrate?

This is an attitude I had for quite some time.  I'll just keep plugging away at all of the tasks I need to do throughout my day, finding efficiencies here and there for things, scripting some, manually pounding away on the keyboard for others; no biggie!  Then something happened – and by something I mean our environment grew…substantially.  We for the most part doubled in size over the course of a few months and things started getting really crazy really fast.  Those daily tasks, or one-off things that I had been doing started to become a hold up to the rest of the team and the business.  Let's take a simple example of deploying a new application or VM into your environment…

Wait, I thought VMware was supposed to improve provisioning time?

Well it certainly has, I can deploy servers in a matter of minutes now, have them on the right network, with our base load of software – and even with some of the Software Defined Datacenter pieces implemented I can have security and compliance built right into this deployment process as well.  But, the fact of the matter is I still have a lot of other things I need to do in order to call my server or VM completely deployed.  That's where vCenter Orchestrator comes in.

So I'm secure, provisioned and have a base software load installed and configured, what else is there?

Backup/Replication/DR – Some products will point to a datastore and/or cluster as their target which means this may be already setup for you when a new VM is deployed.  However I don't have my backup solutions configured that way.  I like to add my VMs to jobs which are based on RPO, therefore this is something I need to do manually after it has been provisioned

Monitoring/Reporting – Again, some products will automatically pick up new VMs and begin monitoring them.  I do have vCOPs setup, however there are many other tools I use to monitor specific application level statistics and performance, in which I need to go and setup manually after I deploy the VM.

Active Directory placement and group policy – For the Windows VMs I like these to be sitting in the proper OU after I deploy them, without this they will never receive the proper group policy – again, needs to be setup after the fact.

So how does vCO help with this?

vCenter Orchestrator by itself doesn't – but coupled with all the plug-ins available it becomes a pretty powerful tool.  If any of the services that provide you with those additional tasks have some sort of way to programmatically perform tasks such as an API, PowerShell cmdlets, SQL backends, etc – you should be able to find a vCO plug-in or simply use straight up JavaScript to interact with these programs and automate all that needs to be done.  In fact you could use the vCenter plug-in and design out the whole deployment process from start to finish using nothing but vCenter Orchestrator.  And for some icing on the cake, you can still initiate these workflows from directly inside the vSphere Web Client.

So this is just one small example of how I've been using vCenter Orchestrator.  Honestly, I'm finding more and more use cases for vCO everyday and reaping the benefits of orchestration and automation – which usually involve myself and a coffee watching scripts run ūüôā  So, my question to you is…

Do you orchestrate?

My First vCenter Orchestrator Workflow ‚Äď Part 6 – Resources

booksOK! ¬†Finally the end of this series! ¬†Honestly without the existence of the following resources there is no chance in hell that I would have been able to even develop a simple workflow, let along start scripting and what not. ¬†I was a couple weeks into vCO before I even learned that you can switch to ‘design’ mode ūüėČ

So, if you are looking for some awesomeness on vCO, have a look at the following…

Official vCenter Orchestrator Documentation – Should really be your first go to reference for all that is vCO

Automating vSphere with VMware vCenter Orchestrator – Although official docs SHOULD be your first go to item – I find that this book written by Cody Bunch actually IS my first go to reference.

www.vcoteam.info – Great blog with a ton of script examples and whatnot! ¬†Bookmark this…

www.vcoportal.de – Ditto to the above line, might better bookmark this on while you in your bookmarks…This is a fabulous blog!

VMware vCenter Orchestrator blog – the official blog from VMware centered around vCO.

VMware API and SDK documentation – this always helps when trying to determine what type of objects or properties any given function requires.

Good Ol’ Twitter – Follow @cody_bunch, @josh_atwell, @vCOteam, @technicalvalues – there are a ton more but these are the ones that I can think of off the top of my head – just search for #vCO and find someone to ask your question to – community seems to be always willing to help.

Thanks for reading and hopefully you can find some usefulness out of vCO as I did! ¬†I encourage everyone to explore what it has to offer, which the same results, everytime! ¬†Check out the full series below…

My first vCenter Orchestrator Workflow

My First vCenter Orchestrator Workflow ‚Äď Part 5 – A little bit of SQL

orchestratepart5Thus far in this¬†series¬†of posts we have installed and configured vCenter Orchestrator as well as setup and utilized a couple of plugins; the vCenter plug-in and the PowerShell plug-in. ¬†Before the series ends I wanted to go through one more plug-in. ¬†The SQL plug-in. ¬†The SQL plug-in is used for, well, you guessed it; running SQL queries against a database. ¬†If you remember in Part 4 we setup a workflow that took two input parameters; a host and a location code. ¬†The script then went on to create a new port group on a vSwitch named locationcode-VM_Network. ¬†The logic in itself works fine and the workflow validates, the only problem I see with it is that the user needs to enter the ‘location code’ manually as an input. ¬†Now I know you are all very careful and take your time when doing things, but I’m not, and more than likely after doing this 40 or 50 times you can count on me keying in that location code wrong ūüôā – Enter the SQL plugin.

So the setup is as follows; I have a database containing a table with the following columns; locationcode and deployed (boolean). ¬†What I would like to do is have an input parameter that would allow me to select the location code from a list of non-deployed locations in a¬†drop-down¬†box (rather than manually enter this information in), and in turn pass the location code to my PowerShell script. ¬†Once the script has ran I’d like to update the deployed column for that specific location, ensuring it isn’t displayed in the list again in turn ensuring I can’t deploy the same location twice. ¬†Make sense? ¬†I know it’s a lot to follow but the concepts of setting it up are pretty much the same no matter what you are looking to do.

Alright – enough background – Let’s get into it. ¬†I’m not going to go through the installation of the SQL Plug-in – it’s exactly the same installation process as the Powershell plug-in which we covered in Part 4. ¬†Similar to how we setup our Powershell host we need to setup our SQL server database connection inside of vCO. ¬†To do this fire up your vCO client and navigate through the workflow tree to Library->SQL->Configuration and select the ‘Add a database’ workflow, right click and Start Workflow. ¬†There are a few parameters as you can see that we need to pass to the workflow in order for it to¬†successfully¬†run. ¬†First, give this connection a name and select your desired Database Type – in my case MS SQL. ¬†Also here we need to pass a Connection URL. ¬†Now if you don’t know anything about jdbc connection urls no fear, it’s not that difficult. ¬†Simply enter it in the the following format…


So, for a SQL Server with named DC.lab.local running on the default port 1433 and ¬†database named ServerDeploy you would use the following…



After clicking Next we are once again presented with our Shared/Per User session mode – again, I chose shared to use one simple set of credentials rather than a per user authentication. ¬†When you are ready click ‘Submit’ to add your new database to vCO’s inventory. ¬†One thing to note here is that this step is not¬†necessary¬† ¬†If we wanted we could perform all of this at run time inside code, however for tutorial purposes and learning purposes it’s sometimes easier to do it this way.

Alright, nuff config! ¬†It’s time now to get started on our task at hand; Querying the database for non-deployed servers and pushing the result as a¬†drop-down¬†box as an input parameter to our workflow that we created in Part 4. ¬†First off there is a simple change we need to make to our existing workflow. ¬†Here’s a tip – don’t feel like buffalo-ing your original workflow, simply right click on it and ¬†select ‘Duplicate Workflow’ to copy it. ¬†OK, first off we need a new attribute. ¬†We originally have locationcode setup an input parameter of type string – and we still need this, however the result we get back from our database will be an array of strings. ¬†So, on the General tab of your workflow create a new attribute called ¬†databaseParameter of type SQL:Database and assign it the value of the Database we created earlier (this should allow you to browse the inventory to do so). ¬†Once you are done that simply Save & Close and continue on with any validation errors.


So here comes the real magic! ¬† We need to take that database attribute and pass it to a newly created action which will in turn spit out an array of string attributes (our locations in our database). ¬† Again, you could do the following all in script embedded within your workflow, but you never know when you are going to need to reuse something so I’ve decided to create a new action to do so. ¬† ¬†To create an new action be sure you are on ‘Design’ view from within your client and click on the actions tab in the left hand side menu. ¬†Where you place your action doesn’t really matter, I chose to right click com.vmware.library.sql and create my action inside that module. ¬†Just remember where you put it and what you named it:).


OK, you should now be in the Action editor. ¬†This is where we are going to place the code that does all the querying of the database. ¬†As I said earlier we need to pass this Action a database parameter and it will return an array of string. ¬† The setup of input parameters and return types, along with all the other work we are going to do is all done on the scripting tab. ¬†First off define your return type of an Array/string. ¬†Secondly add an input parameter of type SQL:Database. ¬†You can see all of this outlined in the capture below…


Hey! ¬†That was easy! ¬†Now it’s time for a little scripting. ¬†vCO script is nothing but Javascript which calls the rich set of API’s that vSphere provides, along with the functions and properties of all the plug-ins provided in vCO. ¬†The script I used is displayed below…

var resultingArray = new Array();
var query = "SELECT locationcode FROM Locations WHERE deployed = 0";
var resultingActiveRecords = databaseParameter.readCustomQuery(query);
for each (var resultRecord in resultingActiveRecords) {
var locationcode = resultRecord.getProperty("locationcode");
return resultingArray;

Simply paste this into the script pane of your action. ¬†As you can see it’s a pretty simple script. ¬†Creates and array, queries our database, pushes the locationcode column value of each record returned into that array and finally returns the array. ¬†So – time to Save and Close and head back to our workflow.

So at this point we are left with 2 tasks.  The first being the creation of the drop-down box as an input.  To do this we will need to change the way our original input parameter, locationcode, is displayed.  This is done on the Presentation tab of our script editor.  Be sure you have selected locationcode in the Presentation tree that the top of the screen and select the icon to add a new property to it.  There are many several different properties listed but the one we are after is called Predefined list of elements.  Under the value field of our new property select the icon to assign an action.  In the popup find/filter for our action we created earlier, assign the actions parameter to our database parameter and click Apply.


There done right…well, kinda, you could run the workflow now and it would populate our input and it would go ahead and run the PowerCLI script and the VM Network would be created, however if you remember it was my intent to go back at the end of the workflow and update our database to ensure that the same locationcode could not be selected twice. ¬†To do this we will need to drag a new Scriptable task element to run after we invoke our PowerCLI script. ¬†Inside this scriptable task we will need to import a couple of local attributes in order to accomplish the sql we need to do, the locationcode, and the databaseParameter.


As for the script it’s going to look very similar to the syntax that we placed inside of our action with the exception of and executeCustomQuery function¬†in place¬†of the readCustomQuery and the actual query itself is different. ¬†The following is what I used…

var query = "UPDATE locations SET deployed= 1 WHERE locationcode= '" + locationcode+ "'";

And now at last we are done!! ¬†Go ahead and run your workflow, either from within the vCO client or the Web Client and you should now see a¬†drop-down¬†selection for the locationcode. ¬†Once it’s selected once the script will run, create the VM Network, then update our database to ensure that the selected locationcode is not shown again in the¬†drop-down.


So that my friends is the end of the line for me on creating my first vCenter Orchestrator Workflow but it is most¬†definitely¬†not the end of the line with vCO. ¬†With access to a huge set of vSphere API’s along with all of the¬†functionality¬†and properties provided by its’ plugins, throw in some sweet integration with the vSphere Web Client I’m beginning to see my usage of vCO ramp up within my current role. ¬†This series has hardly even grazed the surface in terms of vCO’s functionality so I urge you all to go out there and learn as much as you can about this product. ¬†I’ll do one more post in the series and outline some of the resources that I’ve found along the creation of this workflow so expect to see that soon.

My first vCenter Orchestrator Workflow

My First vCenter Orchestrator Workflow ‚Äď Part 4 ‚Äď A look at the Powershell Plug-in

Orchestrate-FacilitateAlright! ¬†So far throughout this series of posts we have installed, configured and setup vCenter Orchestrator; as well as created and tested the integration between both vCO and the vSphere Web Client. ¬†So what’s next in my venture? ¬†Well if you can remember back to Part 1 of the series I set out on a quest to develop a workflow that would take an un-configured host and go through a series of tasks to create datastores, rename networks, setup hostname, etc… ¬†Basically configure it the way I wanted. ¬†Now there are built-in workflows in vCO to do this, however I had already done this work inside of a PowerShell script – so my main goal was to get vCO to execute that script. ¬†And this leads us to part 4!

So first off as I said above there are a ton of great built in workflows inside of vCO that can do pretty much anything. ¬†Some things however, such as the ability to run a Powershell script, are missing! ¬†Thankfully there is a thriving developers community built around vCO and it’s SDKs allowing third party vendors to release their own sets of workflows in the form of a plug-in. ¬†So as you probably guessed by now we will need to install a plugin to handle our Powershell script execution.

This plugin is called the vCenter Orchestrator Plug-in for Microsoft Windows Powershell and can be found over on VMware’s site. ¬†You will need to download this file. ¬†Once you have your hands on the vmoapp file we need to go into the vCenter Orchestrator Configuration page (https://IP_OF_vCO:8283/) to install it. ¬†Select Plug-ins from the left hand menu, then browse down to the Install new plug-in section. ¬†Upload your file and click ‘Upload and install’, accept the EULA and away you go… If you browse back to the main Plug-ins page you will notice that it states the plugin will be installed at the next server startup; so if you wish you can do this task manually by going to Startup Options -> Restart Service.


At this point we can fire up our vCO client. ¬†Having a look in the Library of¬†workflows¬†we can now see a PowerShell folder. ¬†Expanding this out further let’s us see some of the workflows that come packaged with the plug-in. ¬†So we now have a few configuration steps we need to go through before executing scripts with this plug-in.

First off we need setup a PowerShell host. ¬†A PowerShell host is simply a Windows machine with Powershell installed located somewhere in your environment that will handle the storing and executing of the scripts. ¬†There is a great article on all of the steps here but I will go through explaining them all as well. ¬† Keep in mind this might not be the most secure of ways to go about everything – but this is simply a lab so I’m not too worried – for those concerned w/ security implications check out the full lengthy thrilling winrm read on the msdn ūüôā ¬†¬†

So, once you have chosen which machine you would like to be your Powershell host go ahead and drop to a command prompt on that machine and run the following list of commands.

  • To create a winrm listener and open any required firewall ports
  • winrm quickconfig
  • To enable kerberos authentication
  • winrm set winrm/config/service/auth @{Kerberos=”true”}
  • Allow transfer of unencrypted data – told you wasn’t the most secure ūüôā
  • winrm set winrm/config/service @{AllowUnencrypted=”true”}
  • Up the max memory per shell – I needed to do this to get things working
  • winrm set winrm/config/winrs @{MaxMemoryPerShellMB=”2048″}

And there we are! ¬†Things should be setup fine now on our host end to allow the connections from our vCO server. ¬†Now we need to configure kerberos on the vCO end of things. ¬†To do this you will need to console into your vCO server and get on the command line there – hope your comfortable with vi ūüôā

Basically we need to create a file under /opt/vmo/jre/lib/security called krb5.conf Рto do so simply

cd /opt/vmo/jre/lib/security
vi krb5.conf

This file will need to look as follows – obviously change to fit your environment – if you happen to be using an default configuration of the autolab then you are good just to copy the following…

default_realm = LAB.LOCAL
udp_preferences_limit = 1
kdc = dc.lab.local
default_domain = LAB.LOCAL

Once you are done simply hit :wq to save and exit.  In order to grant vCO permission to access our newly created krb5 file you will also need to change ownership of the file using the following command

chown vco.vco krb5.conf

And, in order for changes to take affect, restart the vCO service – you can do this from the configuration page->Startup Options or simply

service vcod restart

Whew! ¬†Ok! ¬†Getting somewhere….Now we need to add the host into our configuration of the Powershell plug-in. ¬† I find the easiest way to do this is to simply run the ‘Add a Powershell Host’ workflow however you can develop the script/code on the fly to add the host during your own workflow if you want. ¬† The way I have documented however is as follows…

Browse to the PowerShell plug-in configuration by expanding Library->PowerShell->Configuration in the workflows view of your vCO Client. ¬†Right click ‘Add a PowerShell host’ and select Start Workflow.


Here we need to add a few key pieces of information.  Enter a name for your PowerShell host Рthis can be whatever you wish, then enter the HOSTNAME of the host you setup (kerberos will not work with IP)   and click Next.


The only item that needs to be changed on the Host Type screen is Authentication; be sure Kerberos is selected and click ‘Next’.


In the User Credentials screen you have a couple of options in regards to Session mode. ¬†Again since this is a lab environment I selected Shared Session, however if you were looking at a more production type deployment you might want to explore the Per User settings which will execute commands under the credentials of the current user connected to vCO. ¬†Enter in some credentials with access to vCO and click ‘Submit’. ¬†The workflow should kick off and you can watch it flow through the different elements. ¬†When done, hopefully you have a nice green¬†check mark¬†beside it!

Now that we have¬†successfully¬†installed the Powershell plug-in and added a Powershell host lets go ahead and create a script on our Powershell host to run in order to make sure everything works. ¬†Although my end goal is to completely configure a host – ¬†for simplicity¬†sake¬†I’ll use a small snippet of the complete script. ¬†So I have placed the following script on my PowerShell host to simply add a new VM Network to vSwith0. ¬†As you can see the script is pretty simple, takes two parameters, a host and a location code. ¬†The location code is used to represent uniquness in my environment and is actually used multiple times in the complete script for the hostname, datastores, etc….

param ($hosttoconfigure, $locationcode)
add-pssnapin VMware.VimAutomation.Core
$username = "Host Username"
$password = "Host Password"
$success = Connect-VIServer $hosttoconfigure -username $username -Password $password
Get-VirtualSwitch -Name vSwitch0 | New-VirtualPortGroup -Name "$locationcode-VM_Network" -confirm:$false

So let’s get started on our workflow to call this script. ¬†Again, create a new workflow and call it what you will. ¬† Once you are in the workflow editor move to the Inputs tab. ¬†Here we will get the information from the user that we require in the script. ¬†So go head and add a couple of inputs to the workflow, one being hosttoconfigure (Type VC.HostSystem) and locationcode (Type String).


By selecting our host parameter and clicking the eye icon we can set the ‘Show in Inventory’ presentation property on the host input. ¬†This will basically allow the user to browse through their vCenter to select the host when running the workflows, so might as well go ahead and do that as well.


The Powershell workflow that we will be using is called ‘Invoke and external script’ and requires 3 parameters; One, a Powershell Host which we have setup previously, the second is the script to execute, and the third is the arguments to pass to the script.


Once on the Schema tab go head and drag the ‘Invoke an external script’ workflow into yours. ¬† When you see the parameter setup black bar pop up click ‘Setup’ and we can have a look at the parameters.


Through this screen we can basically promote or link the parameters from the Script workflow to our main workflow. ¬†You can see that I’ve done a few things. ¬†One, I’ve set the host parameter to a value (same as creating an attribute) and browsed through my inventory to select my Powershell host that we created previously. ¬†Secondly I manually inputted the path to my Powershell script in the externalScript parameter. ¬†Thirdly I selected to skip the arguments parameter at this time. ¬†I’ve done this because I need to pass the hostname as well as the locationcode parameter from my main workflow to this parameter which we will do with a separate element called a Scriptable task. ¬†Go ahead and click ‘Promote’.


So now we have our main input parameters setup (locationcode and hosttoconfigure) as well as our script setup and ready to go.  We just need to tackle that arguments parameter.  As I said we will do this with a separate Scriptable Task workflow so go ahead and drag that into your schema, just before your Invoke External Script.   A scriptable task is just that, kind of a blank canvas to do any sort of scripting (javascript) that you desire.


So let’s go ahead and click the pencil icon to edit our scriptable task. ¬†There are few IN parameters that we are going to need inside of our script; The first is hosttoconfigure and the second is locationcode.


Now move on to the OUT parameters.  We will need to create a new out parameter to store our arguments, so click the link for a new parameter and create a new workflow attribute called scriptArgs of type string.

Now we need to move to the Scripting tab. ¬†This is where we can concatenate a property of the hosttoconfigure parameter and the locationcode to populate our newly created scriptArgs variable. ¬†Honestly it’s a one-liner. ¬†I’m sure there is a way to create this workflow without even requiring this whole Scriptable task but this is the way I got to to work (again, my FIRST vCO workflow). ¬†Copy/Paste the following into your scripting tab.

scriptArgs = hosttoconfigure.Name + " " + locationcode;

Ok, you can close out of your Scriptable task workflow now.  We are almost there.  All that we have left to do is map the External Script workflow paramater arguments to our Scriptable task elements parameter scriptArgs.  Thankfully this is an easy thing to do.


Once again go into your External Script element and click on the Visual Binding tab.  Here, as shown above, we simply need to drag the scriptArgs in attribute over to the arguments in parameter.


Guess what! ¬†Your done! ¬†If everything has been setup properly and I’ve done a good job at explaining what to do then you should be able to Save and Close your workflow and actually run it on a host (a test host of course). ¬†The result – you should get a VM Network setup on vSwitch0 – oh and a pretty green checkmark beside your workflow ūüôā

At this point I’m going to cut off this post since it’s getting pretty long. ¬†That being said I’m not going to end the series! ¬†I’m always looking at ways to better automate things and you know, having users type in that location code just isn’t good enough for me, a lot of room for error there; they could type it in wrong, do the same location twice, on and on and on… ¬†And hey, I have a database already setup with my location codes in it and whether or not they have already been deployed. ¬†So, stay tuned for Part 5 of my series where we will go through configuring the SQL plug-in and setting up our location input parameter to be populated by an SQL table – as well as update that same table on completion of our script.

My first vCenter Orchestrator Workflow

My First vCenter Orchestrator Workflow – Part 3 – Create a test workflow and see the awesomesauce

imgOrchestrateOk we are finally getting somewhere now with this series! So far we have downloaded, installed, and configured our vCO appliance. As well, we have registered our vCO instance with both vCenter and our SSO instance. This post will take us through verifying and testing our installation by creating and setting up a small workflow that we can then assign to some inventory objects inside of vCenter. This will allow us to perform that right-click magic in the Web Client and see for ourselves some of the awesome integration vCO and vCenter have.


With that said let’s get started on our test workflow. To do so you will need one of clients available to vCO. As you can see in the¬†screenshot vCO provides you with a couple of options to start the client; one simply runs a java applet and the other let’s you install a¬†client directly on your machine – whichever method you chose you end up sitting at the exact same login screen. Once you get there you should¬†be able to simply input your vCO IP as the Host name and your proper credentials.

OK! So here we are, the vCO workflow development interface. Look a little¬†foreign¬†to you? No worries, it did to me as well. Actually, it¬†still kind of does, this is just “My First” vCO workflow remember! So for the most part I’ve only really explored the workflow icon (shown¬†below). ¬†The others are simply Home (home), Scheduler (Allows scheduling of workflows), Policies ( Allows other plugins to trigger the kick¬†off of workflows), and Inventory (You will see your vCenter inventory objects here). For now, we need the Workflows section active.vCOWorkflowWorkspace


So after you expand the Library tree you should see several folders by default. These folders contain all of the workflows that vCO is aware¬†of. Obviously we can add more by creating our own or installing plug-ins (covered in Part 4). For now we will just create one of our own¬†workflows. Before going to crazy I always like to create my own folder for things like this. I get a bit¬†nit-picky¬†about file management¬†sometimes ūüôā To do so is pretty simple – Right Click Library -> Add New Folder and give it a name!



So now it’s time to create our workflow – Again Right-Click the folder you want to store it in and Select New Workflow and name it. At this¬†point a new window, the workflow editor will open up. There is a lot of information and tabs here and to be honest I’m not going to explain¬†what they all are. Partly because it would make this post much too long, but mostly because I don’t have a grasp on what they all are :).¬†The main tab that we will be working in is called Schema. This is where we setup all of the flow elements inside our workflow. Once there¬†you will see our main window is displaying the flow of everything, and¬†the left hand side is showing all of the workflows that we can add to¬†our workflow. The one I am interested in is ‘Reboot host’ As you can see you can browse through the tree of All Workflows to get to it or¬†you can simply use the filter box at the top to search for specific workflows. Once you find it you simply add it to your workflow by¬†dragging it into your flow window.


vCOPromoteInputsAfter doing so you will see a black bar along the top of the screen asking about the activities parameters. Something to know – workflows¬†have inputs and outputs – these are pretty self explanatory. When we created the workflow initially it had inputs and output, and then when¬†we dragged the Reboot Host workflow into ours it also had inputs and outputs. So what this is asking is if we would like to move the Reboot¬†Hosts inputs into our workflows inputs. In this case this is something we want to do. So go ahead and click ‘Setup’. Now we see our¬†‘Promote Workflow Input Parameters’ window. This will allow us to do a few different things; First of all, we can promote or move our inputs¬†from the reboot host workflow to our workflow, and secondly we can decide to assign default values to them at the same time. As you can see,¬†the ‘Reboot Host’ workflow takes two inputs; one being the host and the other being the force switch. Leave host as it is but if you want you¬†can set a default value of ‘Yes’ to force by selecting the value option and then the yes option. Then click ‘Promote’.

If you look at your Inputs section now you will see that only host is listed. This is because we require the user to tell us or select the¬†host we wish to reboot. But wait, what about force?!?! Well, by assigning a default value to this input parameter we have actually converted¬†this to an attributes. Attributes are available on the General tab. Anyways – this workflow is now complete! Go ahead and select ‘Save and¬†Close’. You will notice that vCO will also handle a bit of version history for us! Awesome stuff!

Alright! We are done with vCO for now. Let’s flip back to our web client and assign this workflow to be executed on certain objects.¬†Navigate through the web client to the vCenter Orchestrator section, then Select vCO Home and look in the Manage tab. This is where we will¬†add our newly created workflow to our right-click context menu when associated with host. Click the + sign to add a new workflow. In the¬†Available workflows browse through the tree until you find your workflow and click ‘Add’, then select the inventory objects to run it on – in¬†our case, just a host and click ‘OK’


So, after all of this we are now ready for the awesomesauce! Get back into your Hosts and Clusters view and right-click on a host. Once the¬†‘All vCenter Orchestrator Actions’ menu loads have a look at what you see! Reboot Craziness!!! Your workflow!! If you see fit, go ahead and¬†select it to kick off the workflow. You may be prompted for a token delegation – if so go ahead and click ‘Approve’ – I have no idea what this¬†is ūüôā When your workflow window opens you can see that your host has already been pre-populated with our right-click. You can click Finish¬†to start the workflow¬†immediately or Next to setup a schedule of sorts. ***Warning – this will reboot your host *** – don’t know if that’s needed but whatever ūüôā


So there you go! We’ve¬†successfully¬†created a test workflow in which we integrated into and executed from the vSphere Web Client. Pretty awesome stuff! I hope you are starting to see some of the benefits of vCO now! Next we will get back on track with our workflow and dig a bit deeper into creating workflows by installing the Powershell plugin and getting vCO to execute a script for us!

My first vCenter Orchestrator Workflow