How to extend vCAC with vCO Part 2 – Hello world Script in Guest

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.

media_1400313923381.jpg
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

media_1400364761239.jpg

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.

Login to vCO and create a new folder to keep your workflows.

media_1400194859034.png

Login to to the vCO client and browse to the following workflow

media_1400194895172.png

Right click and Duplicate the Workflow Template to a your folder and give it a new name Run Script in Guest

media_1400195026393.png

Browse to your folder and right click your new workflow and select edit

media_1400195119587.png

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.

media_1400195274469.jpg

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.

media_1400195808538.jpg

Also delete the additonalInputFieldbyBlueprint Parameter as we don’t use it in this example

media_1400196115995.jpg

Now click the Schema tab and click edit on the Display inputs task.

media_1400195896918.jpg

On the In tab delete the vCloudVAPP Parameter. Then close this pop up window.

media_1400195970373.jpg

Now go to the scripting tab and delete the following lines of code

media_1400317732040.jpg

Now drag and drop a scriptable task into the workflow as shown

media_1400196268140.jpg

Now click edit on the Scriptable task

media_1400196328474.jpg

Enter the following info on the Info tab

media_1400196828242.png

Now change to the Out tab and click to create three new attributes named myscript mycustomfield, mycommand

media_1400197124090.jpg

It should look like this when your done

media_1400361984785.png

Now select the Visual Binding tab and drag the vCACvmProperties to the IN box so it looks like this:

mycommands

Now click the scripting tab and add the following lines

media_1400369097816.png
myscript = vCACVmProperties.get('my.script');
mycustomfield = vCACVmProperties.get('my.custom.field');
mycommand = vCACVmProperties.get('my.command');

Now let’s drag in that action we imported earlier.

media_1400365255951.jpg

Now click the General Tab and add a new Attibute named VMowner of type string

media_1400365564020.jpg

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

media_1400365744691.png

Now lets drag in another scriptable task and click edit

media_1400365786496.jpg

Enter the following on the Info Tab

media_1400314589049.png

Now click the Out tab and create a new attribute named args

media_1400316067173.png

Now click the Visual bindings tab and add the following connections

args

Now select the Scripting tab and enter the following line and click close

media_1400316196419.png
args = myscript + " " + mycustomfield + " " + VMowner

Now let’s add the run program in guest workflow to our workflow

media_1400199251991.jpg

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.

Setup

Verify that your visual bindings look like this:

runguestbindings

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.

media_1400366112849.jpg

Next select the following for input Parameters and values for pollingRate and timeout and click Promote

promotevmtoolsawait

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.

attributes

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

media_1400366763826.jpg

Now run the following workflow to add this to your vCAC blueprint

media_1400366984176.png

Change to Machine Provisioned and Set the vCAC host and click next

media_1400367048235.png

Now browse to select your blueprint click add then Select.

media_1400367382038.png

Be sure there is only your blueprint in the list and click accept. Then click next.

media_1400367433957.png

Now select the workflow we just created and select no for the two options and click Submit

media_1400367516072.png

When you look in vCAC the Blueprint should have a new custom property

media_1400367797543.jpg

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

media_1400368857269.png

Download the workflow here: org.vmtocloud.runscriptinguest.zip

Remember sharing is caring!

26 Replies to “How to extend vCAC with vCO Part 2 – Hello world Script in Guest”

  1. Pingback: How to extend vCAC with vCO Part 1 – Installation | VMtoCloud.com

  2. Hi, what was the last action you added to the workflow before you added the state change workflow. i cant read it.

  3. 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

  4. 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?

  5. 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.

  6. 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.

  7. 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?

  8. 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!

Leave a Reply to Marty Cancel reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.