User Name and Password fields does not appear on the vRealize Automation login page

VMware recently posted KB User Name and Password fields does not appear on the vRealize Automation login page, which is something that I’m experiencing in my lab.   When I load up vRA in Firefox I see:

2015-01-22_17-37-55

As you can see there is no login or password fields.  The KB article says there is no resolution so far and to disable the client, but I found that you can get the login and password fields to appear by dragging the horizontal scroll bar to the right.  If you look at the very bottom-right of the image above, you will see a little space where the scroll bar can move into.  After dragging the bar to the right, the login and password fields will appear and you can see that there is a small space to the left where the scroll bar has been moved:

2015-01-22_17-37-43

I’m using Firefox 35 on Windows 7.

Advertisements

Unable to perform a data collection on a vCloud Air OnDemand endpoint with vRealize Automation

I recently signed up for the newly released vCloud Air OnDemand service and wanted to provision VMs to it using vRealize Automation (vRA).  I followed the instructions found on page 13 of the IaaS Configuration for vCloud Air and vCloud Director guide, but  the instructions didn’t match what I was seeing as there was no “vCloud Director API URL” link to select.  https://brianragazzi.wordpress.com/2014/08/21/adding-a-vcloud-air-endpoint-to-vcloud-automation-center/ shows what the doc describes.  I filed a service request with VMware and they said that vRA endpoints only works with vCloud Air subscription based plans and not the OnDemand plan.  They also said that the OnDemand plan should be compatible with vRA endpoints in the upcoming months.

When I performed a data collection on the vRA vCloud Air endpoint, it would fail with the error:

Workflow ‘vCloudEndpointDataCollection’ failed with the following exception: There is an error in XML document (1, 2).

2015-01-21_11-36-11

They also said that they were having issues with the API that may have been what was preventing me from working through the instructions at Log In and Receive Access Token.  I’ll go ahead and post what I performed even though it didn’t work.  Maybe once the issue with the API gets resolved it will work or maybe it’s not related and I can update this post in the future.

The first thing we need to convert your login credentials into a Base64 encoded string.  The login credentials will be in the form of user@domain:password.  If you’re on a Linux system, you can convert this into a Base64 string by running:

$ echo ‘username@example.com:password’ | base64
dXNlcm5hbWVAZXhhbXBsZS5jb206cGFzc3dvcmQK

You can also go to https://www.base64encode.org/ to perform the encoding.

Now we need to make a call to the login URL at https://iam.vchs.vmware.com/api/iam/login:

curl -I -H 'Accept: application/xml;version=5.7' \
        -H 'Content-Type: application/xml;version=5.7' \
        -H 'Authorization: Basic dXNlcm5hbWVAZXhhbXBsZS5jb206cGFzc3dvcmQK' \
        -X POST https://iam.vchs.vmware.com/api/iam/login

Make sure to use the -I parameter or you won’t be able to see the authorization token that is sent back.  You should get something back like this:

HTTP/1.1 201 Created
Date: Thu, 22 Jan 2015 02:42:10 GMT
Server: Apache-Coyote/1.1
vchs-authorization: eyJhbGciOiJSU……NU8FTtGIlMln5Q
Content-Type: application/xml; version=5.7
Content-Length: 165
Set-Cookie: ROUTEID=.186; path=/; Domain=.vmware.com
Connection: close

The long string after vchs-authorization is our token.  Let’s go ahead and assign it to a variable since it’s so long and you need to send it in each subsequent request.

$ token=’eyJhbGciOiJSU……NU8FTtGIlMln5Q’

Now we will follow the example and list out our current service plans:

curl -I -H 'Accept: application/xml;version=5.7' \
        -H "Authorization: Bearer $token" \
        https://iam.vchs.vmware.com/api/sc/plans

Note that now we have a new header with our token.  I received the following response:

HTTP/1.1 302 Found
Date: Thu, 22 Jan 2015 03:37:45 GMT
Server: Apache/2.2.15 (CentOS)
Location: https://us-california-1-3.vchs.vmware.com/api/sc/plans
Connection: close
Content-Type: text/html; charset=iso-8859-1

302 is a temporary redirect and is redirecting to https://us-california-1-3.vchs.vmware.com/api/sc/plans.  So I changed my request to:

curl -I -H 'Accept: application/xml;version=5.7' \
        -H "Authorization: Bearer $token" \
        https://us-california-1-3.vchs.vmware.com/api/sc/plans

and received:

HTTP/1.1 405 Method Not Allowed
Date: Thu, 22 Jan 2015 03:44:22 GMT
Server: Apache-Coyote/1.1
X-TraceId: 04abda8b-1821-441c-8dd6-77d2159a9e98-54bd7a33-15413
X-TraceUrl: /insight/services/traces/04abda8b-1821-441c-8dd6-77d2159a9e98-54bd7a33-15413?type=json
X-insight-endpoint-name: default
X-insight-application-name: localhost|ROOT
X-insight-server-name: 04abda8b-1821-441c-8dd6-77d2159a9e98
X-insight-source: HTTP
Content-Type: text/plain;charset=UTF-8
Content-Length: 66
Via: 1.1 us-california-1-3.vchs.vmware.com
Vary: Accept-Encoding

Here is where I stopped as I didn’t want to put more effort into it if the API service is having issues.  This is the first time I’ve looked at the vCloud Air API so maybe I’m missing something.  I’ll update this post when I have a solution or if someone knows the solution, please leave it in the comments.  Thanks.


Re-associating vCloud Director VMs with the correct resource pool

Our team was upgrading ESXi hosts in our vCloud Director environment and all of the VMs must have not have migrated when placing the hosts into maintenance mode so they manually migrated the VMs.  Since we have multiple org vDCs, we have multiple resource pools.  As you may know, when you try to migrate VMs that are in multiple resource pools, the migration wizard only allows you to place the VMs in a single resource pool.  I started seeing the following system alert on all of the vCloud Director VMs:

2015-01-15_20-52-07

I checked vCenter and sure enough all of the VMs were in the root resource pool (the cluster), and no longer in the correct resource pool.  If you migrate the VMs one at a time, the migration wizard automatically places the VM in the correct resource pool, but the team didn’t want to do this as it would take too much time.  If you do have to migrate the VMs manually, you can migrate VMs in bulk and have the migration wizard place the VMs in the correct resource pool if you use the following process:

  1. Select a resource pool.
  2. Select the Related Objects tab.
  3. Select Virtual Machines.
  4. Select all of the Virtual Machines.
  5. Select Migrate.

2015-01-15_21-03-23

Here you can see that the wizard automatically selected the correct resource pool:

2015-01-15_21-03-50

You still have to go through each resource pool and perform the migrations, but the VMs will retain the correct resource pool.  Of course, you could script it all as well.

So I was in the position of having all of the VMs in the wrong resource pool, which causes alarms in vCloud Director and could impact the performance of the virtual machines.  I could have went into vCloud Director and found each of the VMs individually, but this would have taken forever so I decided to use PowerCLI to re-associate the VMs with the correct resource pool.

You’ll need to be connected to vCloud and all of your vCenter instances:

connect-ciserver cloud.corp.local

connect-viserver vc.corp.local

Paste the following function into PowerCLI:


function reassociatevCDRPs {
  <#
  .SYNOPSIS
    Places vCloud Director virtual machines into the correct vCenter resource pools.  
  .DESCRIPTION
    Places vCloud Director virtual machines into the correct vCenter resource pools.  This can be helpful when the VMs are moved from their resource pool during a task such as manual vMotion. 
  .EXAMPLE
  reassociatevCDRPs -org all -promptOnMove $false
  .EXAMPLE
  reassociatevCDRPs -org admin -promptOnMove $true
  #>

  param(
    [Parameter(Mandatory=$true)] 
    [string] $org = "all",
    [Parameter(Mandatory=$true)] 
    [string] $promptOnMove = $false
  )

    $ovdcLookupTable = @{}
    $vmsToMove       = @{}

    # Build lookup tables
    $orgIds = @{}
    $orgNames = @{}
    search-cloud -querytype organization | % { $orgIds[$_.name] = $_.id; $orgNames[$_.id] = $_.name }

    $orgVdcIds       = @{}
    $orgVdcNames     = @{}
    search-cloud -querytype AdminOrgVdc | % { $orgVdcNames[$_.id] = $_.name; $orgvDCIds[$_.name] = $_.id }

    $vCDVMs = search-cloud -querytype adminvm

  $searchCommand = "search-cloud -querytype adminvm"

  if ($org -ne 'all') {
    # Throw an error if the organization is not found in the vCloud instance.  Otherwise add a filter to the search-cloud command to only work on the supplied organization.
    if (! $orgIds[$org]) { throw "Organization $org not found." }  
    $searchCommand += " -filter org==$($orgIds[$org])"
  }

  $vcdVMs = invoke-expression $searchCommand

    $vcdVMs | % { 
      $vcdVM = $_
      
      # Get the resouce pool name in the format of: orgVDC Name (UUID)
      $vcdRPName = "$($orgVdcNames[$vcdVM.Vdc]) ($($_.Vdc.split(':')[3]))" 

      $vcVM = get-vm -id "VirtualMachine-$($vcdVM.moref)"
      $vcRP = $vcVM.resourcepool 
      $vcRPName = $vcRP.name
      
      if ($vcdRPName -ne $vcRPName) {  # Test to see if vCD's resource pool matches vCenter's resource pool. 
        echo "$($vcdVM.name) is in the resource pool '$($vcRPName)' and should be the '$($vcdRPName)' resource pool."
        # Add to list of VMs that need to be moved.   
        $vmsToMove[$vcVM] = get-resourcepool $vcdRPName
      }

    }

    $vmsToMove.keys | % { 
      if ($promptOnMove -eq $true) {
        $response = read-host "Move $($_.name) to the correct resource pool ($($vmsToMove[$_])) ( [y]es, [n]o, [a]ll )?"
        if ($response -eq 'n') { # If the user selects not to move the VM, try the next VM in the list.
          return 
        } 
        elseif ($response -eq 'a') {
          $promptOnMove = $false
        } 
      }
      $resourcePool = $vmsToMove[$_] 
      echo "Moving $vm into resource pool $resourcePool"
      move-vm $_ -Destination $resourcePool | out-null
      #echo "result: $($?)"
    }

}

To correct all VMs with no prompting:

reassociatevCDRPs -org all -promptOnMove $false

To move VMs to a specific org and to prompt before each move:

reassociatevCDRPs -org “org name” -promptOnMove $true

This script won’t move shadow VMs, but those are easy… for each cluster just select them all and drag them into the cluster’s System vDC (uuid) resouce pool.  vShield Edges also won’t be moved.  Those will likely need to be moved into the System vDC resource pool as well or if they are a fenced vApp, they will go into an org vDC resource pool.  Or you can just de-deploy them and they should go to the correct resource pool.


Configuring the built-in vRealize Orchestrator in vRealize Automation 6.2

Overview

This post will show you how to configure the built-in version of vRealize Orchestrator (vRO) that comes with vRealize Automation 6.2 (vRA).  In upcoming posts I’ll build on this and show how you can have vRA call vRO during virtual machine provisioning to rename and add a VM to Puppet.  My goal is to continue making posts that will show how you can use vRA and vRO to create a portal that will provide virtual machine provisioning to multiple types of environments and integrating with technologies such as Puppet, Infoblox, Service Now, NSX, etc.

At this point I assuming that the vRA appliances have already been deployed and configured.

The version of vRO that comes with vRA 6.2 is actually 6.0, which hasn’t been released as a standalone package yet, so if you wanted to get your hands on it early, you could deploy a vRA appliance, disable the vRA services, enable the vRO services and connect to it to check it out.  See External vRealize Orchestrator appliance becomes unavailable after upgrading to VMware vRealize Automation 6.2 in a distributed environment for more info on this.

Verifying vRO Services

Normally to start configuring vRO you would go to landing page at https://vra62a.vmware.local:8281/vco/, but if you try to do this on the vRA appliance, you’ll receive an error.  This is because the vRO configurator service is not running by default.

1) ssh or open a console to the vRA core appliance.

2) Verify that the vco-configurator service is not running:

vra62a:~ # service vco-configurator status
Status-ing tcServer
Instance name:         configuration
Runtime version:       7.0.55.A.RELEASE
tc Runtime Base:       /var/lib/vco/configuration
Status:                NOT RUNNING

3) Start the service:

vra62a:~ # service vco-configurator start
Starting tcServer
Using CATALINA_BASE:   /var/lib/vco/configuration
Using CATALINA_HOME:   /opt/vmware/vfabric-tc-server-standard/tomcat-7.0.55.A.RELEASE
Using CATALINA_TMPDIR: /var/lib/vco/configuration/temp
Using JRE_HOME:        /usr/java/jre-vmware
Using CLASSPATH:       /opt/vmware/vfabric-tc-server-standard/tomcat-7.0.55.A.RELEASE/bin/bootstrap.jar:/opt/vmware/vfabric-tc-server-standard/tomcat-7.0.55.A.RELEASE/bin/tomcat-juli.jar
Using CATALINA_PID:    /var/lib/vco/configuration/logs/tcserver.pid
Tomcat started.
Status:                RUNNING as PID=17717

Now you can access the vRO landing page by going to

https://vra62a.vmware.local:8281/vco/

4) Select Orchestration Configuration

2015-01-09_11-02-37

5) The default username and password is vmware/vmware

You’ll be required to change the password.

2015-01-09_10-41-16

6) There isn’t much we need to do in here for now.  If you’d like, you can go to the Authentication section and change the vRO admin group so you can log in with a domain account.

2015-01-09_12-51-28

This built-in version of vRO comes with the vRA plug-in already installed as well as other plug-ins that used to have to be installed separately:

2015-01-09_10-45-51

7) Before we try to connect to vRO with the client, make sure that the vRO server is running:

vra62a:~ # service vco-server status
Status-ing tcServer
Instance name:         app-server
Runtime version:       7.0.55.A.RELEASE
tc Runtime Base:       /var/lib/vco/app-server
Status:                RUNNING as PID=4587

8) If it’s not, you can start it with:

service vco-server start

Connect with the vRO client

1) Go to the vRO landing page at https://vra62a.vmware.local:8281/vco/

2 ) Select Start Orchestrator client

2015-01-09_11-02-37

3) I believe that the username format needs to be in the same format that you would use to log into the vRA web portal.  This depends on how you set up your identity source.  I’m using an identity type of Active Directory where my domain is vmware.local with an alias of vmware.

2015-01-09_12-58-02

In this section you will see both vCAC and vRA used interchangeably.

4) Once you’re in the vRO client, select Run and then the workflows tab:

2015-01-09_14-09-03

Here you can see the workflow folders that are provided by the vRA plug-in.

5) Next, select the Inventory tab and you can see that the vCAC host has been automatically:

2015-01-09_14-14-58

So all we need to do is to add the vRA IaaS host.  There is a new workflow that we can run that automatically picks up the IaaS host, which makes the process simpler.  This process was more complicated and didn’t work as well in prior versions of vRA.

6) From the Inventory tab, browse to Library > vCloud Automation Center > Configuration > Run the workflow “Add the IaaS host of a vCAC host”

2015-01-09_14-20-51

  1. Select “Not set”
  2. Browse to your vRA/vCAC host
  3. Confirm

2015-01-09_14-22-43

7) The next page should be pre-populated:

2015-01-09_14-18-29

8) I’m using shared session mode:

2015-01-09_14-19-21

9) vmware.local is the name of my domain:

2015-01-09_14-19-30

10) Submit the workflow and hopefully it will succeed:

2015-01-09_14-26-41

11) Now the inventory tab will show you the new IaaS host where you can browse the contents:

2015-01-09_14-08-13

Conclusion

In this post we configured vRO be be aware of vRA so we can have a two way communication between the two.  In an upcoming post, we will install the vRO customizations into vRA.


Keeping time up to date on the vRealize Automation appliances

In my lab I’ve had some issues with my vRealize Automation (vRA) / vCloud Automation Center (vCAC) appliances not having the correct time even though time was configured in the appliance admin pages.  I was able to get the time to be consistently correct by creating a cron job on each of the appliances.  Here is the process for creating a cron entry to sync the appliance’s time with an external time server.

1) ssh or open a console to the appliance.  Login as root.

2) Open the crontab for root: crontab -e

When you run the crontab command on the appliances it launches the VI editor.  If you need more info on VI, you can search for it.  Here is a cheatsheet: http://www.albany.edu/faculty/hy973732/ist535/vi_editor_commands.pdf

3) Enter insert mode by entering a lower case i

4) Paste in the following or add to the existing entries:

# ------------- minute (0 - 59)
 # | ----------- hour (0 - 23)
 # | | --------- day of month (1 - 31)
 # | | | ------- month (1 - 12)
 # | | | | ----- day of week (0 - 6) (Sunday=0)
 # | | | | |
 */5 * * * * /usr/sbin/sntp -P no -r 192.168.1.254

5) Save the file by pressing escape :wq <enter> or escape ZZ

*/5 means to update the time every 5 minutes and 192.168.1.254 is my time server.

You can find more about the sntp command at http://www.tutorialspoint.com/unix_commands/sntp.htm