vCNS Inventory data collection fails when using an external vCO endpoint in vCAC 6.1

I recently installed vCAC 6.1, configured it to use an external vCO endpoint and disabled vCAC’s internal vCO instance.  I noticed that when I did a data collection against vCNS it would fail with the error: Workflow ‘vSphereVCNSInventory’ failed with the following exception: Could not reach vCenter Orchestrator endpoint {0}. Trying the next highest priority endpoint.


Under Infrastructure > Monitoring > Log



Apparently vCAC’s internal vCO instance has the NSX plug-in installed, but for standalone vCO instances you have to install the NSX plug-in.  You can get the plug-in for vCNS 5.5 here:

I’m using the following software versions:

  • vCAC 6.1
  • vCenter 5.5
  • vCNS 5.5.3

Once you install the NSX plug-in, you will see the following workflows in the vCO client:


Let’s run a data collection against vCO so vCAC knows about the new workflows:


As long as you set up the vCO endpoint correctly, it should succeed:

Now go into a Compute Resource where your vCNS Manager is registered to and run a data collection:



It may take a few minutes but you should see that it succeeds:


If it still fails, you may need to restart the VMware DEM-Worker – worker service on the IaaS machine.

Using the vCO client, you can see that running the data collection in vCAC caused the Create NSX endpoint to run.  It will give the endpoint the name of your vCO endpoint in vCAC:


Switching over to the Inventory tab you can see the NSX endpoint and browse the inventory:












Using vCenter Orchestrator with RabbitMQ and vCloud Director – Part 5


In this post we will create the workflow that will run when vCD sends a message to the AMQP server.  At the end we will see the data that vCloud passes to the workflow.  We will simply print out some of this data, but this info can be used in many ways.  For example, it could be used for a provisioning process that performs various tasks such as creating a computer object in AD, creating an IP/DNS entry, registering the VM in a configuration management tool, etc.  This is what we do in our private cloud.  Users log into vCloud Director, select their VM and from there vCO talks to all the necessary components to get the VM ready for the user.

Configuring the Workflow Runner Workflow

From anywhere within the vCO client, right-click a folder and select New workflow:


Provide the workflow a name:


After you press OK, you’ll be on the Inputs page.

  1. Select the new parameter icon (right-arrow with plus sign)
  2. Select arg_in_0
  3. Enter organization
  4. Press OK


Now we need to set the object type of our organization attribute.

  1. Select string
  2. Enter organization
  3. Select vCloud:Organization
  4. Press Accept


Repeat for the vapp, user and blockingTask attributes.  It should look like this:


Select the Schema tab and drag a Scriptable task object from the Generic group onto the blue line between the Start and End elements:


Select the IN tab and select organization, vapp, blockingTask and user:


Click on the Scripting tab and enter the following in the scripting field:


You should be able to press Save and close and not receive any errors.

Now we can configure the Workflow runner workflow to call the workflow we just created.  You can easily find the workflow by:

  1. Entering Workflow runner in the search box in the upper-right corner of the vCO client.
  2. Select the highlighted workflow
  3. Select Go to selection
  4. Select Close


Edit the workflow and on the General tab under attributes we want to set vcdHost and wf.  Here we can see that they are both not set:


Select Not set for the vcdHost attribute then

  1. Double-click vCloud Director to expand it.
  2. Select your vCloud Director host.  Mine is vcd55.vmware.local
  3. Press Select


Select Not set for the wf attribute then

  1. Enter the name of our test workflow.
  2. Select it
  3. Press Select


It should look like this:


We need to make a quick change to make sure the vcdHost and wf attributes get passed correctly.  I’m not sure why this needs to be done.

  1. Click the Schema tab.
  2. Select the Retrieve message object.
  3. Select the Out tab.
  4. Select both the vcdHost and wf parameters and delete them.

It should look like this:



You can now save and close.

Back to vCloud Director

If we’ve done everything correctly up to this point and we start a vApp in vCloud Director, the Workflow runner workflow should run and then start our vcd Test workflow.  Here we can see see that the Workflow runner workflow ran successfully.  You can also see some data is was able to parse from the blocking task:


We can see the same thing with the vcd Test worflow that we ran.   We simply display a few attributes and resume the blocking task, which tells vCloud Director that it can continue with starting the vApp: