vRealize Orchestrator Index ‘0’ specified is out of bounds

Posted: August 30, 2017 | Author: Chris Greene | Filed under: vRealize Orchestrator | Tags: vRO | Leave a comment

I was trying use vRealize Orchestrator (vRO) 7.2 with vSphere 6.5 GA and U1 the other day and was receiving the following error when I selected vRO Servers under Inventory in the vSphere Web Client:

Read the rest of this entry »

Deploying vRealize Orchestrator 6.0.3

Posted: September 28, 2015 | Author: Chris Greene | Filed under: vRealize Orchestrator | Tags: vRO | Leave a comment

Today I had to deploy an instance for vRealize Orchestrator (vRO) 6.0.3 in my lab and ran into some snags that I thought I’d document here. I’ve always used the vRO/vCO configuration page to add vCenters and this functionality looks to have been removed. I believe that using this method would add vCenter instances to vRO as well as registering the vRO extension with the vCenters. Now you must use a vRO workflow to add vCenter and run a separate workflow to add the vRO extension to vCenter. There is also a workflow that can be ran to import SSL certificates and vCenter licenses. I found that the order in which you run these workflows matters as well. It took a bit of trial and error to get everything working. I may try to create a new workflow that combines each of the needed workflows into one to make the process more streamlined.

The following versions were used:

Platform Services Controller: 6.0 U1 acting as a subordinate CA.
vCenter: 6.0 U1
vRealize Orchestrator: 6.0.3

vRO OVA deployment

There are no real surprises when deploying the vRO OVA, but I wanted to point out that now you’re able to specify initial root and vcoadmin passwords. Previously you had to change them after you logged in for the first time. This should help if you’re wanting to automate the deployment of the appliance. There are blog posts out there explaining how to do this. You also don’t have to remember/lookup the provided default passwords.

vRO Appliance Configuration

Once the vRO VM is online, you’ll want to perform some initial configuration. It may be possible to automated as well. My vRO VM is vro6c.vmware.local so I’ll open a browser to https://vro6c.vmware.local:5480 and log in with the password I specified during the OVA deployment.

Go to System > Time Zone and specify the correct time zone for your environment:

Next I set the domain search path by going to Network > Address:

Lastly, I configure the appliance to use my local time source:

vRO vCenter Extension

Before we continue I want to point out that if you go into vCenter and select the vRealize Orchestrator icon, you’ll see the following:

This is because there is no vRO extension registered with vCenter. Let’s checkout the managed object browser (MOB) to verify. My MOB is accessible at https://vc6d.vmware.local/mob. Once I login and select content > Extension Manager > (more…) I see the following:

Notice that here is no “com.vmware.vco”? This is why there is no vRO information in the vSphere web client. We’ll rectify this shortly.

vRO Configuration

To access the main vRO landing page I’m going to go to http://vro6c.vmware.local (notice that it’s not HTTPS). If you specify HTTPS, the connection will fail.

In the past you would click the Orchestrator Configuration link to configure vRO, but now you need to configure vRO by running workflows from within the vRO client so let’s launch the client.

Select Start Orchestrator Client and click the client.jnlp download.

First we need to register our vCenter instance by running the following workflow:

Library > vCenter > Configuration > Add a vCenter Server instance

Once successful you should be able to view the vCenter instance:

At this point if you checked the vCenter’s MOB, the vRO extension would still not be registered.

Registering vRO’s extension with vCenter

Let’s finally register the vRO extension by running the following workflow:

Library > vCenter > Configuration > Register vCenter Orchestrator as a vCenter Server extension

This part was tricky because the second field only ask for the address of the orchestrator server. At first I only entered the IP address of the vCO server and while the workflow did succeed, it did not actually register the vRO extension. Also, if you don’t enter the correct port, the extension will register but won’t be visible in the web client. This was tripping me up for a while. I’d run it and it would succeed, but no extension. I looked at the MOB of an older vCO instance I have and it had the address of the vCO server registered as https://vco.vmware.local:8281 and once I tried that it worked. Port 8281 is the vRO application port. After a run you will see:

[2015-09-28 11:21:17.851] [I] Registered this extension with host vc6d.vmware.local

As I mentioned, just because the workflow completed successfully, it doesn’t mean it actually worked. We can run the following workflow to verify that it succeeded:

Library > vCenter > Configuration > List the vCenter Orchestrator extensions of vCenter Server

If your registration was successful, you’ll see output similar to:

[2015-09-28 11:24:01.488] [I] Extension key: com.vmware.vco
[2015-09-28 11:24:01.489] [I] vco-192.168.3.119@vmware.com: https://192.168.3.119:8281

Now if I access the vCenter MOB again at https://vc6d.vmware.local/mob and select content > Extension Manager > (more…), I see the following:

If I select the com.vmware.vco extension and then client, I see:

Yay. Unfortunately, the vSphere web client won’t show the vRO information yet. The vSphere web client service needs to be restarted in order to get the vRO info to show up. We can do this by logging into the vCenter machine and running:

service vsphere-client restart

In my lab I’m using the vCenter appliance. For windows you can restart the service in the control panel.

I’ve noticed that sometimes it may take a few minutes before the vRO instance to show up in the web client. You may see the following error before then:

Error occurred while processing request. Check vSphere WebClient logs for details.

I saw the error for about 15 minutes. Once whatever causes the error to go away, you should see the following in the web client:

vRO SSO Configuration

The last thing I want to demonstrate is a workflow for changing vRO’s authentication mechanism to SSO, importing the necessary certs and vCenter licenses. I’m going to configure vRO to use SSO authentication against my vSphere 6.0 U1 platform services controller (PSC). This can be done by running the following workflow:

Library > Configuration > vSphere > vSphere configuration

As you can see below, this workflow imports the needed certificates, licenses and configures vRO use my PSC’s SSO. You have to add the vCenter server instance before running this workflow. The component manager URL will be your PSC (vc6d-psc.vmware.local for me) with the /cm path:

If we log into the vRO configuration app, we can see that the configuration was successful.

Even though we’ve changed the authentication method, we still need restart the vRO server before the changes will take effect.

Once the server has been restarted you should be able to log into the vRO client using a user that is in your vRO admin group.

Creating a vRealize Service Blueprint to create Infoblox DNS records

Posted: July 14, 2015 | Author: Chris Greene | Filed under: vRealize Automation, vRealize Orchestrator | Tags: vCA, vRO | Leave a comment

In my last post I described how to create Infoblox DNS host records using the vRealize Orchestartor (vRO) HTTP-REST plug-in. One of the use cases I presented at the end of this post was to create a vRealize Automation (vRA) advanced service to provide creating Infoblox DNS records as a vRA catalog item. A day after that post I was asked to present on vRA and since we’ve been working with Infoblox a lot lately, I thought that this is something I could show.

Modifying the original workflow

Since I’ve already detailed how to create the workflow, I’m not going to cover it again, but we will have to modify the inputs of the workflow so that it makes more sense when calling it from vRA. We can start off at section Modifying the workflow in the previous post. Instead of having a single input named content with the full payload of our REST request, let’s go ahead and change it so that we have two inputs: hostname & ipaddress. I’m not going to cover in detail how to add/modify attributes and other changes to the workflow. It’s pretty tedious, I’m in a hurry, you probably already know how or can find the info in one of the previous posts or online.

Right-click the workflow and select Edit.

Select the Inputs tab, highlight the content attribute and click delete.

Select Add Parameter, select arg_in_0 and give the attribute a name of hostname.

Enter Hostname in the description field. Repeat this step for the ipaddress parameter so that it looks like:

Now we need to bind these inputs to our Scripting workflow element. Select the

Schema tab
Scripting workflow element
In tab
Check hostname and ipaddress and press Select.

With the Scripting workflow element still active, select the Scripting tab and add the following line of code:

var content = ‘{“ipv4addrs”:[{“ipv4addr”:”‘ + ipaddress + ‘”}],”name”:”‘ + hostname + ‘”}’

The content variable is the REST payload we will be sending to the Infoblox server. Previously this was passed in as an input in its entirety. Now we are building the content variable up via the ipaddress and hostname inputs. The rest of the code is the same as in the previous post.

Now you can save and close the workflow.

Creating the vRA Advanced Service

Access the vRA portal and select the Advanced Services tab. If you don’t see this tab, perform the following:

Select Administration
Identity Store and Users & Groups
Enter your user id.
Select your user id.
Select View Details

On the next screen check Service Architect and press update. If you reload the browser, you should see the Advanced Services tab. I don’t know vRA permissions too well so if you still don’t see it, try to give yourself more permissions.

Select

Advanced Services
Service Blueprints
Add

From here we can browse to the vRO workflow we previously created and select next.

Name the service and press next.

You don’t have to do anything on the next screen, but notice how it created fields for the Hostname and IP Address that it pulled from the workflow’s inputs.

On the next screen press Add.

Creating a Catalog Item

We need to publish the service blueprint so that it becomes visible as a catalog item. Highlight the new blueprint and select Publish.

Select

Administration
Catalog Management
Catalog Items

Now our service blueprint is available as a catalog item and has a source of Advanced Designer Service. Select Configure.

Here I’ve added an Infoblox icon and added the catalog item to the Infrastructure service.

You can manage services by clicking the Services menu item under the Administration tab.

Add an entitlement to the service/catalog item

If your user account doesn’t already have access to the service where you placed the catalog item or you did not place the catalog item into a service, you’ll need to add an entitlement.

Select.

Administration
Catalog Management
Entitlements
The business group your in
Edit

Either add the service where you placed the catalog item or add the catalog item individually:

Requesting the catalog item

Now we are ready to request the catalog item from the Catalog tab. Simply select Request on the Create DNS Record item.

Give the request a description. Fill in the details and press submit.

You can see the status of your request on the Requests tab.

You will also see the workflow run in vRO:

The new DNS record should now be in Infoblox.

Creating Infoblox host records with vRealize Orchestrator’s HTTP-REST Plug-in

Posted: July 7, 2015 | Author: Chris Greene | Filed under: vRealize Orchestrator | Tags: Infoblox, vRO | Leave a comment

In a previous post I described how to resolve an Infoblox managed IP address. In this post I’m going to show how to create an Infoblox host record. In the past we used the Infoblox plug-in to perform DNS management, but lately we’ve been replacing the functionality provided by the Infoblox plug-in with the HTTP-REST plug-in. We did this for the following reasons:

The Infoblox plug-in comes with workflows that have specific requirements that we couldn’t always meet.
The workflows also have additional functionality, but it wasn’t needed in our environment.
The Infoblox plug-in has to be compatible with the version of the Infoblox NIOS and vRO/vCO that you’re using. We currently have a compatibility issue that would only be resolved by upgrading the Infoblox NIOS, but our team doesn’t manage it and it’s not scheduled to be upgraded for months. By using the HTTP-REST plug-in we eliminate this issue completely.
The HTTP-REST plug-in comes with vRO/vCO so there is nothing additional to install.
It gives our team more exposure to consuming services via REST APIs.
It gives our team more control in the way we consume Infoblox services. We were using an older version of the Infolbox plug-in so they may have added additional functionality, but now we can perform name resolution and create various types of name records.

I’m not going into as much detail as I did in Resolving an Infoblox IP Address with vRealize Orchestrator’s HTTP-REST Plug-in so if you get stuck, please see that post.

Add a REST host

In the vRO client, go to Library > HTTP-REST > Configuration and run the “Add a REST host” workflow

If successful, you will now see a green check next to the workflow run:

Add a REST Operation

In the vRO client, go to Library > HTTP-REST > Configuration and run the “Add a REST Operation” workflow.

If we were to use the curl command to make the API call to create the host record, it would look like this:

curl -k -u vco_user:superpass -H “Content-Type: application/json” \

-X POST https://10.62.1.10/wapi/v1.2.1/record:host -d \

‘{“ipv4addrs”:[{“ipv4addr”:”10.62.1.20″}],”name”:”test.vmware.local”}’

To do this in vRO, we need to specify the following:

Template URL: /record:host
HTTP method: POST
Content type: application/json

Notice how the template URL value is what is appended to the HTTP-REST host of https://10.62.1.10/wapi/v1.2.1

If successful, you will now see a green check next to the workflow run and under the variables tab you can see the specified values:

Generate a new workflow based on the newly created REST operation

Now that we have our REST operation defined, we need to create a vRO workflow that we can use.

In the vRO client, go to Library > HTTP-REST and run the “Generate a new workflow from a REST operation” worfklow.

Under Operation select “Not set” and choose the “Create Host Record” operation:

Again, make you sure you see the green check next to the workflow run so that you know it was sucessful:

Modifying the workflow

Now we have a workflow that we can run manually or call from other systems such as vCloud Director or vRealize Automation, but first we need to modify the workflow slightly so that we can add some additional functionality such as error handling.

When using the curl command the string that comes after -d is the data that we are sending to the Infoblox server. In this case it’s the string ‘{“ipv4addrs”:[{“ipv4addr”:”10.62.1.20″}],”name”:”test.vmware.local”}’:

curl -k -u vco_user:superpass -H “Content-Type: application/json” \

-X POST https://10.62.1.10/wapi/v1.2.1/record:host -d \

‘{“ipv4addrs”:[{“ipv4addr”:”10.62.1.20″}],”name”:”test.vmware.local”}’

If we look at the Inputs tab of our workflow we will see that it takes a single variable named content:

If we were to run the workflow manually, it would need to look like this:

In our environment this workflow is actually called from another workflow that builds the content string from values extracted out of a vCloud Director VM. Depending on your use case, you may need to modify this workflow so that it takes a hostname/IP address and then builds the content string.

Let’s take a look at the scripting section of the workflow. Edit the workflow and go to:

Schema tab
Scripting object
Scripting tab
Code we added

In section 4 I do the following:

Convert the value that the Infoblox sends back after creating the host record into a JSON string.

var jsonContent = JSON.parse(contentAsString)

If the value of statusCode 201, log a message stating that DNS record was created successfully. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html for the definition of the HTML code 201.

If the value of statusCode does not equal 201, extract the returned text from the JSON value jsonContent and log a message stating that there was an error creating the DNS record.

contentAsString = jsonContent.text;
System.log(“Failed to create DNS host record: ” + statusCode + ” : ” + contentAsString);

The variables statusCode and contentAsString are stored in the scripting elements output:

as well as the workflows output:

The calling workflow then says that if the statusCode is 201, everything is okay. If not, it uses the value of contentAsString to inform the user what went wrong.

The input, outputs and scripting sections can differ in your situation. What I’ve done is just what was requested of me. When you work as part of a team that develops vRO workflows, someone else may be developing a workflow that calls your workflow and they say, “I want to send you x, y & z and I want you to return a, b, & c to me.”

Use cases

I’d like to cover some of these use cases in future posts, but here are some ways that I think this workflow could be used:

Running the workflow manually. If this was done, I’d probably edit the inputs so that it would take a hostname and IP address instead of the content string.
Take advantage of the vCenter/vRO integration where you could right-click a VM in vCenter and run a workflow that would extract the hostname/IP from the VM and create a DNS entry. You could also have a similar workflow to create other types of DNS records such as CNAMEs (aliases).
Add a custom action to a vRealize Automation VM so that you could manage the VM’s DNS records.
Use vRealize Automation’s Advanced Services to create a service that would allow the management of DNS records.

Unable to start/edit vCenter Orchestrator Policies

Posted: May 29, 2015 | Author: Chris Greene | Filed under: vRealize Orchestrator | Tags: vRO | Leave a comment

After a vCenter Orchestrator (vCO) restart, I noticed that some vCO policies weren’t running. The polices that weren’t running were set to run as a normal user account and not the service account that the running policies were configured with. Here is how the policies looked. Notice that the start, stop and edit buttons are not active.

The issue was that the user account that the policies were running as had expired and the policy was configured to auto-start with the server. I was stuck since I had no way of editing the policy and it started automatically. I didn’t have time to research this so I opened a case with VMware support and they provided me the solution below:

Stop vCO server service
Connect to the vCO Oracle Database
Run the following statement, substituting <vco_schema> and <policy_name> with the actual values:
1. UPDATE <vco_schema>.vmo_policy SET startmode = 0, state = ‘stopped’ WHERE name = <policy_name>;
Restart the vCO server service

After performing these steps I was able to edit the policy, correct the account to run as and successfully start it.

Resolving an Infoblox IP Address with vRealize Orchestrator’s HTTP-REST Plug-in

Posted: April 17, 2015 | Author: Chris Greene | Filed under: vRealize Orchestrator | Tags: vRO | Leave a comment

We use Infoblox for DNS management in our private cloud environment, and as part of the provisioning process we add a new DNS entry for the VM, but before we add a new DNS entry we want to make sure one doesn’t already exist. In our dev/test environment I was using the vRealize Orchestrator (vRO) SSH plug-in to run the nslookup command on the vRO server, parse the result and determine if a DNS entry existed. In our production environment I wasn’t able to do this so I decided to look into using the vRO HTTP-REST plug-in. We are using an older version of the Infoblox plug-in so it’s possible that newer versions have this functionality built-in.

Even if you’re not using Infoblox in your environment, this example will show you how easy it is to use the vRO HTTP-REST plug-in. Using vRO context menu actions in vCenter, you could also run a workflow that extracts IPs off of VMs in vCenter and registers them with Infoblox.

The below actually looks like a lot more work than it is. Since I already knew how to get results from Infoblox using curl, it took about 10 minutes to do the same in vRO.

Performing an Infoblox REST API call with curl

In the past I found out how to use the curl command to make REST API calls to perform options on Infoblox. Looking up an IP address is straightforward:

curl -k -u user:pass -X GET https://192.168.1.10/wapi/v1.0/record:host?ipv4addr=192.168.1.20

Let’s break this down:

-k is insecure mode. This ignores self-signed certificates.
-u user:pass are the credentials.
-X is the type of HTTP request.
https://192.168.1.10 is the Infoblox host.
record:host specifies that we are looking up a host record.
The IP at the end is the IP was are looking up.

This command results in:


[    

  {
        "_ref": "record:host/ZG5zLmhvc3QkLl9kZWZhdWx0LmNvbS5zZWFnYXRlLm9rbGEuY2xkLmNsb3VkbGcwMTYwNTA:superserver.vmware.local/Internal%20seagate", 
        "ipv4addrs": [
            {
                "_ref": "record:host_ipv4addr/ZG5zLmhvc3RfYWRkcmVzcyQuX2RlZmF1bHQuY29tLnNlYWdhdGUub2tsYS5jbGQuY2xvdWRsZzAxNjA1MC4xMC40OC4xNi41MC4:192.168.1.20/superserver.vmware.local/Internal%20seagate", 
                "configure_for_dhcp": true, 
                "host": "superserver.vmware.local", 
                "ipv4addr": "192.168.1.20"
            }
        ], 
        "name": "superserver.vmware.local", 
        "view": "Internal"
    }
]

Now let’s create a vRO workflow to do the same thing as the curl command.

The steps we need to do are:

Create a REST host.
Create a REST operation.
Testing the operation by invoking it.
Creating a new workflow based off of the host and operation.
Modifying the new workflow to add extra functionality that we need.
Run the new workflow and validate it returns the expected result.

Add a REST host

In the vRO client, go to Library > HTTP-REST > Configuration and run the “Add a REST host” workflow

Add a REST Operation

We need to create a REST operation that reproduces what we did with the curl command:

curl -k -u user:pass -X GET https://192.168.1.10/wapi/v1.0/record:host?ipv4addr=192.168.1.20

Our HTTP-REST host is “https://192.168.1.10/wapi/v1.0” and the template URL will be “record:host?ipv4addr={ip}” where {ip} is the name of the IP parameter that we pass in.

In the vRO client, go to Library > HTTP-REST > Configuration and run the “Add a REST Operation” workflow.

Invoke a REST Operation

Let’s test out our newly defined REST Operation.

In the vRO client, go to Library > HTTP-REST and run the “Invoke a REST Operation” workflow.

The result is:


[2015-04-16 17:14:10.013] [I] Request: DynamicWrapper (Instance) : [RESTRequest]-[class com.vmware.o11n.plugin.rest.Request] -- VALUE : com.vmware.o11n.plugin.rest.Request@7a3c931b
[2015-04-16 17:14:10.014] [I] Request URL: https://192.168.1.10/wapi/v1.0/record:host?ipv4addr=192.168.1.20
[2015-04-16 17:14:13.341] [I] Response: DynamicWrapper (Instance) : [RESTResponse]-[class com.vmware.o11n.plugin.rest.Response] -- VALUE : com.vmware.o11n.plugin.rest.Response@6b3fbd4e
[2015-04-16 17:14:13.341] [I] Status code: 200
[2015-04-16 17:14:13.341] [I] Content as string:

[
{
"_ref": "record:host/ZG5zLmhvc3QkLl9kZWZhdWx0LmNvbS5zZWFnYXRlLm9rbGEuY2xkLmNsb3VkbGcwMTYwNTA:superserver.vmware.local/Internal",
"ipv4addrs": [
{
"_ref": "record:host_ipv4addr/ZG5zLmhvc3RfYWRkcmVzcyQuX2RlZmF1bHQuY29tLnNlYWdhdGUub2tsYS5jbGQuY2xvdWRsZzAxNjA1MC4xMC40OC4xNi41MC4:192.168.1.20/superserver.vmware.local.
com/Internal",
"configure_for_dhcp": true,
"host": "superserver.vmware.local",
"ipv4addr": "192.168.1.20"
}
],
"name": "superserver.vmware.local",
"view": "Internal"
}
]

We can see that the status code is 200, which means OK, and you may recognize the rest as being in the json format. I’ll discuss this more later.

Create a new workflow off of our REST operation

Now that we know that our REST operation works, we want to create a workflow off of it so that we can modify it for our own needs.

In the vRO client, go to Library > HTTP-REST and run the “Generate a new workflow from a REST operation” worfklow.

Modifying our new workflow

Now we need to modify our workflow to make it return the fully qualified domain name (FQDN) of the IP address that we searched for.

Edit the “Infoblox IP Lookup” workflow.

Select the Outputs tab
Select Add Parameter

Select arg_out_0 to rename it.

Name it fqdn

It should now look like:

Remember when we invoked the REST operation to test it and it returned json as output (well, technically it returns a string that we convert to json)? Now we need to parse the json results and get the info we need. Since vRO uses Javascript as it’s scripting language, this is really easy to do.

Let’s add the additional code we need.

Select the Schema tab.
Select the Scripting object.
Select the Scripting tab.

Go to the bottom and add the following code:

// Convert the results from Infoblox into a json object. 
var jsonContent = JSON.parse(contentAsString)

// The json object will be an array.  Let's print out how many results we found.  It should only be one.  
System.log("results: " + jsonContent.length)

// If our status code is 200 and we received exactly one result, access the name key, which contains our DNS name
// and then set the fqdn variable to the DNS name.  The fqdn variable will be returned to the calling workflow.
if (statusCode == '200') {
  if (jsonContent.length == 1) {
    fqdn = jsonContent[0].name
    System.log("IP resolved to " + fqdn);
  }
  else {
    fqdn = ''
    System.log("IP doesn't exist in infoblox" + jsonContent.length)
  }
}

It should look like this:

Configure the output of the workflow to return the fqdn variable.

Select the Out tab.
Select the fqdn variable.
Select finish.

Run the Infoblox IP Lookup workflow and enter an IP you want to lookup:

The output should be the same as when you invoked the REST operation, but now at the end you should see:

[2015-04-17 12:02:41.476] [I] IP resolved to superserver.vmware.local.

You can then use this result however you want. In our case, we either keep the existing entry or delete it and create a new one depending on if it matches the new VM we are creating.

orchestration.io

vRealize Orchestrator Index ‘0’ specified is out of bounds

Deploying vRealize Orchestrator 6.0.3

vRO OVA deployment

vRO Appliance Configuration

vRO vCenter Extension

vRO Configuration

Registering vRO’s extension with vCenter

vRO SSO Configuration

Creating a vRealize Service Blueprint to create Infoblox DNS records

Modifying the original workflow

Creating the vRA Advanced Service

Creating a Catalog Item

Add an entitlement to the service/catalog item

Requesting the catalog item

Creating Infoblox host records with vRealize Orchestrator’s HTTP-REST Plug-in

Add a REST host

Add a REST Operation

Generate a new workflow based on the newly created REST operation

Modifying the workflow

Use cases

Unable to start/edit vCenter Orchestrator Policies

Resolving an Infoblox IP Address with vRealize Orchestrator’s HTTP-REST Plug-in

Performing an Infoblox REST API call with curl

Add a REST host

Add a REST Operation

Invoke a REST Operation

Create a new workflow off of our REST operation

Modifying our new workflow

Recent Posts

Archives