Updated on 8/20/2014 to fix some problems with some of the steps with help from loyal followers of this site.
In this lesson we will use the vCAC to vCO extensibility that we setup in Part 1. In many customers that I work with provisiong the virtual machine and operating system are only one part of the problem. To fully automate the provisioning of infrastructure in any organization there are going to be additional tasks that need to occur. These tasks can occur both in the guest operating system after the VM is provisioned, for example running installation scripts in the guest to install management agents. Or outside the guest like adding the server to an Active Directory OU before the VM is added to the domain so the correct Group policy is applied. This is where vCO comes in. In this simple example I will show you how to pass properties from the vCAC blueprint and pass that into the guest operating system at provisioning time. This is a very powerful tool as you could use this to run your own scripts that you may already have. You would just need to modify those to accept a custom property as the argument for the script to run.
NOTE: THIS WILL NOT WORK IF YOU HAVE NOT FOLLOWED PART 1
Start by adding a simple shell script (Linux) or command file (Windows) to your template. In the following examples I am going to pass two properties to a Script to run in the guest.
Linux example:
echo $1 $2 >> results.log
Save as myscript.sh
Windows Example:
echo %1 %2 >> results.log
Save as myscript.cmd
You should test the above to verify they work before you shut down your template. For example sh myscript.sh Hello vmtocloud
Now let’s login to vCAC and add some custom properties to our Blueprint. We will pass these properties to vCO to run a command in the guest VM at provisioning time.
my.custom.field Hello my.script /myscript.sh my.command /bin/sh
Login to vCO client and the first thing we will need to do is import an action courtesy of Tom Bonnano of @dailyhypervisor, download and unzip the file from the link below and then browse to the com.vmware.library.vcac folder and right click and import the action getVirtualMachineOwnerUsername
To use a vCO workflow with vCAC you need to start with special provided workflow and then build your workflow from that. This special workflow will get all the custom properties from the vCAC blueprint and make them available for you to work with in your work flow. The custom properties are more than what we added to the blueprint in the previous step. There are also out of the box properties that are already populated. You can see the complete list here. In this lesson I will use one of the out of the box properties and the ones we created to give you the full perspective.
Right click and Duplicate the Workflow Template to a your folder and give it a new name Run Script in Guest
Click the inputs tab and you can see some of the parameters that are coming from vCAC. Notice the vCACVMProperties. This is where we are getting all the custom properties from.
Since we are not using vCloud Director in this example let’s remove that portion to make this easier. Highlight that Parameter and delete it.
Now change to the Out tab and click to create three new attributes named myscript mycustomfield, mycommand
Now select the Visual Binding tab and drag the vCACvmProperties to the IN box so it looks like this:
Now click the scripting tab and add the following lines
myscript = vCACVmProperties.get('my.script'); mycustomfield = vCACVmProperties.get('my.custom.field'); mycommand = vCACVmProperties.get('my.command');
Now go back to the Schema Tab and click to edit the GetVirtualMachineOwner Action and go to the visual bindings tab and connect the following then close
Now select the Scripting tab and enter the following line and click close
args = myscript + " " + mycustomfield + " " + VMowner
Select the following parameters to move to values in your workflow but make sure vCenterVm is and change Program path to mycommand and arguments to args. It should look like this.
Verify that your visual bindings look like this:
We’re almost there. Everything would be done at this point but we need some way to know that the VM is up and ready for use to run a command in the guest. Drag the vim3getVMtoolsstarted action into the workflow. You will find this under com.vmware.library.vc.vm.tools folder on the left.
Next select the following for input Parameters and values for pollingRate and timeout and click Promote
Now let’s go to the General tab and setup some of our attributes. You need to set the VMusername and VMPassword that the run program in guest will use as well as the polling rate and timeout that vCO will check if the VM tools is started. You also need to enter something for the working directory. / for Linix and C:\ for windows.
Now go back the the schema tab and click validate, you should see the following screen, if not review your workflow otherwise and Save and Close
Fire off a new request and when you login to the provisioned VM you should see that the script executed with the following in results.log
Download the workflow here: org.vmtocloud.runscriptinguest.zip
Pingback: How to extend vCAC with vCO Part 1 – Installation | VMtoCloud.com
Hi, what was the last action you added to the workflow before you added the state change workflow. i cant read it.
GetVMtooolsstarted. I also updated the post. Not sure why my images are uploading so bad.
Thanks.
i need anothere help. i’m trying to use these steps to run a vco workflow that gets the input from the custom properties from a blueprint. but its seems to be failing. basically i’m trying to move the windows servers to a particulat ou and also add the requester/owner of the vm as a local admin.
can you give me any pointers on how to do this please.
For the AD OU creation/move take a look at this http://dailyhypervisor.com/vcloud-automation-center-active-directory-machine-account-management-extension/
For local admin add: https://www.vmtocloud.com/add-requester-to-administrator-group-of-windows-vm-in-vcac-6/
Also can you tell me the polling rate you used for the wait action item?
I used 1 minute and retry rate of 10. So it will try every minute and then after 10 tries will fail. The completed workflow is here if you want to take a look. Again sorry for the bad resolution on screen shots. https://www.vmtocloud.com/wp-content/uploads/2014/05/org.vmtocloud.runscriptinguest.zip
Ryan, this is very very helpful. Unfortunately I’m learning on the fly, so I’m sure i’m missing some stuff. Your script dives pretty deep, where I’m just trying to get one property from vCAC and the VRMOwner to add the local user. Any chance you could double check my work? I don’t have any access to a site to upload my file, but I did create a thread on the vcac forum.
https://communities.vmware.com/message/2411123#2411123
So after fighting with this for a while, there were to key errors that I hit:
1. When you set vCenterVm1 to skip when setting up the run script in guest workflow, you sets it to Null, causing the vm input parameter to be null, meaning var host = vm.sdkConnection; bombs out for vm being null.
2. Also in the Run Script in Guest workflow, you tie the arguments attribute to the arguments input. But arguments is null, you stored the output from build args into the args attribute.
Just though you’d like to know.
Right. Neither the steps nor the package works for me. Keep getting the error “Error executing vCenter Orchestrator workflow: TypeError: Cannot read property “hostId” from null “. Was there a workaround you found?
If you go into visual bindings, you’ll need to link it with the vm attribute you got back from vcenter.
That was it, Thank you for pointing this out. I updated the post with your suggestion.
Hi folks, I am looking at it now. This may be a problem with the vCAC plugin version or vCO build I am using as compared to yours. I will post update as soon as I figure it out. Sorry for the inconvenience this may have caused.
Thanks Ryan. My vCO build is 5.5.1 (5.5.1.1617127), vCAC plugin version is 6.0.1.1768706 and vCAC Infrastructure Administration is 6.0.1.1768690
I updated the post with corrections. It should be working now. There was a problem with the visual bindings on the run program in guest workflow. See visual binding screen shot in this post. Also uploaded the new version so you can import it into your vCO install.
Unfortunately, it is still the same. Workflow “WFStubMachineProvisioned” failed with the following exception: Error executing vCenter Orchestrator workflow: TypeError: Cannot read property “hostId” from null. Attempted to create the workflow multiple times with no luck. Looks like it has something to do with the parameter “envrionment” but skipping or leaving it to default doesn’t do any good.
This worked for me with the following changes:
1. my.script property set to myscript.sh in vCAC
2. value for workingDirectory left blank in vCO
3. Action used is vim3WaitToolsStarted
Thanks for this post!
Hi Surabhi,
Thank you for your feedback. I updated the blog with vim3WaitToolsStarted. For the my.script property I have a question, which flavor of Linux are you running. I am wondering if this is different for CentOS/RHEL vs another flavor or if this is a typo on my part.
Thanks for the informative post. I am a novice with vCAC (6.1) and vCO (5.5), so forgive my naivety for asking this question: What are the reasons you would runs script in the way you’ve described here instead of doing it with the vCAC Guest Agent? I am struggling with which approach is considered the better practice when doing things like installing management agents on newly provisioned (via cloning) VMs. Thanks!
Hi Marty,
It’s a great question but unfortunately I don’t have a better answer than “it depends” It all depends on the customer and their environment. For example some customers do not want any agents or software installed in their templates so I use this vCO route to run post provisioning actions in the guest. Some customers don’t mind agents so I use the guest agent. There are also a few customers that don’t even want the VMtools installed so I can not even use the run process in guest action as that requires VMtools to be installed. I have done this using SSH or powershell to the guest. It all depends what regulation the customer has.
I followed the directions here and the provisioning fails with this error:
Workflow ‘WFStubMachineProvisioned’ failed with the following exception: Error executing vCenter Orchestrator workflow: ReferenceError: “VMowner” is not defined..
vCAC Appliance version 6.1.1.0 Build 2216936
External Orchestrator – version 5.5.2.1 Build 2179237
Any suggestions?
Hi David,
Did you already apply the updated workflow package for vCAC 6.1.1? It is available on the VMware.com download site. Also did you import the action GetVirtualmachineOwnerUsername from here: https://www.vmtocloud.com/wp-content/uploads/2014/05/getVirtualMachineOwnerUsername.zip you will need to unzip it and then import it with the vCO client.
I have this plug-in: VMware vCenter Orchestrator vCAC Plug-in 6.1.0
I cannot find the one for 6.1.1 on the site. If you could please send me the link if you can find it. I have imported the getVirtualMachineOwnerUsername as documented in Part 2.
Ryan,
I even downloaded and used your workflow instead of the one I manually created. Same error.
Getting error: [SCRIPTING_LOG] ReferenceError: vm is not defined for waiting for the DNS name
Have rebuilt multiple times and importing your workflow has the same results.
vCenter 5.5
vRA 6.2 Build 2299574
Plugins:
“vCAC”>6.2.0.2210392
“vCACCAFE”>6.2.0.2246705
“Configurator”>6.0.0.2289455
“DynamicTypes”>1.0.0.2209353
“VCO”>5.5.2.2219581
“Library”>5.5.1.2066071
“VC”>6.0.0.2289456
Any thoughts?
hey Mark, did you ever figure out that “vm is not defined for waiting for the DNS name” error? I am getting the same thing. no luck yet. thanks!