Updating vCenter Orchestrator using an ISO repo

In this post I’m going to show how to update vCenter Orchestrator (vCO) to a specific version.  Often when you need to update a VMware appliance such as vCO you simply update to the latest version, but sometimes this isn’t possible because of compatibility issues, needing to keep environments in sync, etc.  In my case I needed to update from vCO 5.5.2 to 5.5.3, but when I tried to update it said the latest version was 7.0.  This is a pretty simple process, but I had to document it for work so I thought I’d document it here as well.

Download the ISO repo

For some reason vCO 5.5.3 isn’t listed in the drop-down box on VMware’s download site, but I changed the URL to https://my.vmware.com/web/vmware/details?downloadGroup=VCL_VCOVA_553&productId=408&rPId=7354 and it allowed me to access the 5.5.3 download page.

2016-01-05_10-48-31.jpg

Apply the update

  1. Mount the ISO to the VM.
  2. Access the Orchestrator administrative page.  For example: https://vco.vmware.local:5480
  3. Select the Update tab > Settings and select Use CDROM Updates2016-01-05_11-11-16.jpg
  4. Select Save Settings
  5. Select the Update tab > Status > Check Updates and now you will see version of vCO that’s on your ISO repo as opposed to whatever the latest version is.2016-01-05_11-12-34.jpg
  6. Reboot the appliance to apply the update by selecting the System tab > Information > Reboot2016-01-05_11-17-27.jpg

 


vCenter Orchestrator workflow to renew vCloud Director vApp leases

In vCloud Director (vCD), vApp leases are defined at the organization level and can’t be overridden at the vApp level.  In our dev/test cloud we set leases so that vApps will expire after a certain amount of time.  We do this so that unused vApps will expire and users can continue to deploy new vApps without the need for further increasing their vApp quota.  Users receive emails that their vApps are about to expire and they can renew them at any time, but I thought I’d look into a way of creating an exception list for vApps that should never expire.

I decided on using vCenter Ochestrator (vCO) to accomplish this for the following reasons:

  • We already use heavily in our vCD environment.
  • A vCO workflow has a graphical interface for adding/deleting vApps from the exception list.
  • The workflow will reside on the vCO server and not on some other server where it’s more likely to be forgotten.
  • I can use the built-in vCO scheduler to run the workflow.
  • If needed, I can make an API call to run the workflow externally.

The workflow

I’m not going to document each step of creating the workflow, but I’ll list what each workflow component looks like so you can see the inputs, outputs and code.

Workflow overview

2015-08-26_10-45-35


Workflow attributes

2015-08-26_10-46-18


vApps Left?

Inputs

2015-08-26_10-47-10

Scripting

2015-08-26_10-47-43


Get current vApp

Inputs

2015-08-26_10-48-33

Outputs

2015-08-26_10-49-11

Scripting

2015-08-26_11-11-24


vApp exist?

Inputs

2015-08-26_10-51-02

Scripting

2015-08-26_11-07-41


Update Leases

Inputs

2015-08-26_11-12-21

Outputs

2015-08-26_10-52-15

Scripting

2015-08-26_10-52-42

leaseSettingsSection = currentVapp.getLeaseSettingsSection()

System.log("Updating runtime lease for vApp: " + currentVapp.name + ". Current lease is: " + leaseSettingsSection.deploymentLeaseInSeconds)
System.log("Updating storage lease for vApp: " + currentVapp.name + ". Current lease is: " + leaseSettingsSection.storageLeaseInSeconds)

newDeploymentLeaseInSeconds = currentVapp.parent.parent.toAdminObject().settings.vAppLeaseSettings.deploymentLeaseSeconds
newStorageLeaseInSeconds    = currentVapp.parent.parent.toAdminObject().settings.vAppLeaseSettings.storageLeaseSeconds

leaseSettingsSection.deploymentLeaseInSeconds = newDeploymentLeaseInSeconds
leaseSettingsSection.storageLeaseInSeconds    = newStorageLeaseInSeconds

var task = currentVapp.updateSection(leaseSettingsSection)


VclWaitTaskEnd

Inputs

2015-08-26_10-53-17

Adding vApp(s) to the workflow

Edit the workflow:

2015-08-12_10-40-52

Select the vApp attribute’s value:

2015-08-12_10-42-53

2015-08-12_10-43-28

Browse to vCloud Director > vCD instance > Organizations > Org that your vApp(s) are in > vDCs > vDC your vApp(s) are in > vApps

2015-08-12_11-49-42

Add each of the vApps that you want to renew the leases on.

2015-08-12_11-53-47

Once you’re done, you’ll see the list of vApps in the vApps attribute array:

2015-08-12_11-54-51

Example of a successful run:

2015-08-26_10-54-48

Scheduling the workflow

2015-08-26_11-33-35

Select your workflow:

2015-08-12_11-58-41

Set the scheduling times for whatever makes sense in your environment:

2015-08-12_11-59-37

Finished schedule:

2015-08-12_12-00-05


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.

2014-11-11_10-07-54

Under Infrastructure > Monitoring > Log

2014-11-11_10-08-41

 

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:

https://my.vmware.com/group/vmware/info?slug=security_products/vmware_vcloud_networking_and_security/5_5

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:

2014-11-11_10-13-18

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

2014-11-11_10-20-48

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

2014-11-11_10-20-59
Now go into a Compute Resource where your vCNS Manager is registered to and run a data collection:

2014-11-11_14-27-40

 

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

2014-11-11_12-14-52

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:

2014-11-11_14-28-33

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

2014-11-11_10-15-07

 

 

 

 

 

 

 

 

 

 


Using vCenter Orchestrator with RabbitMQ and vCloud Director – Part 5

Overview

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:

2014-10-21_19-37-02

Provide the workflow a name:

2014-10-21_19-40-39

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

2014-10-21_19-38-03

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

2014-10-21_19-43-47

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

2014-10-21_21-00-15

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

2014-10-21_20-32-25

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

2014-10-21_21-00-37

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

2014-10-21_21-04-33

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

2014-10-21_20-37-53

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:

2014-10-21_20-48-41

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

2014-10-21_20-50-39

Select Not set for the wf attribute then

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

2014-10-21_20-52-31

It should look like this:

2014-10-21_20-43-22

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:

2014-10-21_20-55-24

 

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:

2014-10-21_21-08-12

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:

2014-10-21_21-09-39


Using vCenter Orchestrator with RabbitMQ and vCloud Director – Part 4

Overview

In this post we are going to install the vCloud Director Notification Package, subscribe to a RabbitMQ queue and then configure vCenter Orchestrator to monitor to the newly created queue.

Installing the vCloud Director Notification Package

The vCloud Director Notification Package has various workflows, actions, etc that will allow us to parse AMQP notification messages from vCloud Director and act on them.  By avoiding this heavy lifting, we can focus on using the parsed values in our workflows. Go to https://communities.vmware.com/docs/DOC-20446 and select the download link for com.vmware.coe.vcd55.notifications.package.zip. Unzip the archive and you’re left with a file named com.vmware.coe.vcd55.notifications.package.

From the the vCO client:

  1. Select Administer from the drop-down menu
  2. Select the Packages tab
  3. Select Import package
  4. Select the file com.vmware.coe.vcd55.notifications.package
  5. Select Open

2014-10-21_17-32-17

Select Import on the following screen:

2014-10-21_17-32-48

I’ve already imported the package so there is nothing selected, but you should have a lot of items with green arrows that will be imported:

2014-10-21_17-32-58

Once the import is finished, you’ll see a new package with various workflows, actions, etc:

2014-10-21_17-34-14

 

Subscribing to a RabbitMQ queue

In the vCO client go to the workflow tab and then Library > AMQP > Configuration.  Right-click the Subscribe to queues workflow and set select Start Workflow. Give the queue a name and select Next

2014-10-21_18-00-05

2014-10-21_18-00-39

Select your broker and click Next.

2014-10-21_18-02-21

Select Not Set and enter the name of your test queue in the in the New value field.  Once you’ve entered your queue name select Accept.

2014-10-21_18-02-48

My Queue section looks like:

2014-10-21_18-03-02

Press submit and it should complete successfully:

2014-10-21_18-03-34

 

Creating a new policy

Here is where we will create a policy that will tell vCO to monitor a RabbitMQ queue for messages and to run a workflow when a new message is found.

  1. Select the Run menu
  2. Select the Policies tab
  3. Create the new policy

2014-10-21_18-16-49

Edit the new policy:

2014-10-21_18-17-16

  1. Select Add policy element
  2. Select AMQP:Subscription
  3. Press OK

Type the name of your queue, select it and press Select.

2014-10-21_18-18-57

Select the AMQP:Subscription line and then select Add trigger event.

2014-10-21_18-33-22

Select OnMessage and then Select Trigger.

2014-10-21_18-20-17

It should now look like this (not sure what’s up with the blue background):

2014-10-21_18-36-56

Select OnMessage and below you will notice that no workflow is set.  Click on the magnifying glass to search for a workflow to run:

2014-10-21_19-08-29

Select the highlighted workflow:

2014-10-21_19-10-09

Once you select the workflow you’ll notice that you have two new parameters that are not set:

2014-10-21_19-11-38

Click on not set for subscription and then select the highlighted entry below:

2014-10-21_19-12-03

Now do the same for messageBody:

2014-10-21_19-12-15

The result should look like:

2014-10-21_19-12-20

Start the policy by right-clicking on your policy and selecting Start policy. 

2014-10-21_19-15-27

The policy should now have a green arrow on it:

2014-10-21_19-16-36

In the next post we will configure the workflow that will run when a new message is found.


Using vCenter Orchestrator with RabbitMQ and vCloud Director – Part 3

Overview

In this post we are going to use vCO to create a RabbitMQ broker, exchange and a queue.  We will then bind to the queue so that we can send messages to the queue and retrieve them.

Adding a Broker

In the vCO client go to the workflow tab and then Library > AMQP.  Right-click the Add a broker workflow and set select Start Workflow. Give the broker a name and select Next.

2014-10-08_20-58-42

Fill in the RabbitMQ host, leave the virtual host as / unless you want to change it and know what you’re doing.  The credentials are guest / guest.

2014-10-08_20-59-25

If the workflow is successful, you will see:

2014-10-08_20-59-55

Declaring an Exchange

In the vCO client go to the workflow tab and then Library > AMQP.  Right-click on Declare an exchange and select Start Workflow.

  1. Select Not Set and browse to your broker
  2. Expand AMQP and select your broker
  3. Select Select

2014-10-08_21-08-52

Press Next and enter the following:

2014-10-21_20-05-33

Press Submit and if it completes successfully, you’ll see a green check.

2014-10-08_21-13-17

If you go to your RabbitMQ web interface, you’ll see the exchange we just created:

2014-10-08_21-15-17

Declaring a Queue

In the vCO client go to the workflow tab and then go to Library > AMQP.  Right-click on Declare a queue and select Start Workflow.

Select your broker as before:

2014-10-08_21-17-49

Fill in the following info:

2014-10-08_21-18-18

Select Submit and you should get a green check if the workflow completes successfully.

In the RabbitMQ web interface we can see the new queue:

2014-10-08_21-20-18

Binding to the Queue

In the vCO client go to the workflow tab and then go to Library > AMQP.  Right-click on Bind and select Start Workflow.

Select your broker and select Next:

2014-10-08_21-17-49

Fill in the following and press Submit.

2014-10-08_21-52-47

The routing key is “true.*.*.*.com.vmware.vcloud.event.blockingtask.create.vappDeploy”.  See Notification Message Format for more information on this. Once we have blocking tasks in vCloud set up, every time a vApp is deployed, a blocking task will go into this queue.  Now if we click on the queue in the RabbitMQ web interface, we will see the new binding:

2014-10-08_21-53-43

Sending a message to the queue

In the vCO client go to the workflow tab and then go to Library > AMQP.  Right-click on Send a text message and select Start Workflow.

Select your broker and select Next:

2014-10-08_21-17-49

Fill in the following and select Next:

2014-10-08_21-54-30

Type in a message and select Submit.  Sometimes here Submit isn’t highlighted so you have to press Back then Submit

2014-10-08_21-35-04

Back in the RabbitMQ web interface we see that a new message has arrived:

2014-10-08_21-35-48

We can also scroll down to the Get messages section and press Get Messages.

2014-10-08_21-55-24

Here we can see our message.  Set Requeue to No so that the message is removed off of the queue.

vCloud Director Configuration

Let’s do something a little more interesting and configure vCloud Director (vCD) to send messages to RabbitMQ when a vApp is deployed.  From the vCD portal, enter the following:

2014-10-08_21-39-12

Configure the blocking task:

  1. Select the Administration menu item
  2. Select Extensibility
  3. Check Start vApp (Deploy from API)
  4. Press Apply

2014-10-08_21-41-57

Go ahead and start any vApp.  You’ll see the status change to Pending processing…

2014-10-08_21-46-35

This time the payload has a lot of vCD related information such as the ids for the org, user, etc of the vApp that was attempted to be deployed:

2014-10-08_22-30-15

You could work with this data in the current format, but it’s much easier to use the vCD Notification Package.  This package will extract all the details from the blocking task and populate variables such as user, org, org vDC, etc.  It also allows you to run vCO workflows where you can use the data that was extracted out of the blocking task to do whatever you want.  For example, you could add the deployed system to a CMDB, call out to Infoblox to update the DNS, etc.  You probably want to use a different blocking task (vApp creation) type for this however.  There are two different types for creating vApps.  I’ll cover the vCD Notification Package and creating RabbitMQ subscriptions from vCO in the next post.