«

»

Jan 27 2015

Problem connection vCenter Orchestrator to vRealize Automation

“VMTurbo"
While standing up a vRealize Automation (formerly known as vCloud Automation Center) 6.2 environment a few days back i received an error when trying to connect an external vCenter Orchestrator 5.5.2 (vCO) soon to be renamed to vRealize Orchestrator (vRO) to the vRA Advanced Services.

Screen Shot 2015-01-24 at 04.35.01

The following message was seen in the vRA virtual appliance (VA) catalina.out log file located in the directory /storage/log/vmware/vcac

  • DATE & TIME,861 vcac: [component=”cafe:advanced-designer” priority=”ERROR” thread=”tomcat-http–89″ tenant=”demo”] com.vmware.vcac.platform.service.rest.resolver.ApplicationExceptionHandler.handleUnexpectedException:921 – Could not create URI object: Expected closing bracket for IPv6 address at index 15: https://[https://10.10.100.101]:8281/vco/api
  • DATE & TIME,219 vcac: [component=”cafe:shell” priority=”ERROR” thread=”tomcat-http–12″ tenant=””] com.vmware.vcac.shell.ErrorManagerImpl.logToApacheCommons:59 – <4d8da59e> Unexpected exception was caught
  • DATE & TIME,245 vcac: [component=”cafe:shell” priority=”WARN” thread=”tomcat-http–86″ tenant=””] com.vmware.vcac.shell.shindig.customizations.ExtendedProxyHandler.loadGadgetForRequest:281 – Proxy request https://com.vmware.csp.core.designer.service.plugin.vproxy//designerAdmin/theme/images/vborder.png failed to parse the associated gadget https://com.vmware.csp.core.designer.service.plugin.vproxy//designerAdmin/theme/Standard.css. The gadget will be ignored: org.apache.shindig.gadgets.process.ProcessingException: org.apache.shindig.common.xml.XmlException: Content is not allowed in prolog. At: (1,1)
  • DATE & TIME,258 vcac: [component=”cafe:shell” priority=”WARN” thread=”tomcat-http–21″ tenant=””] com.vmware.vcac.shell.shindig.customizations.ExtendedProxyHandler.loadGadgetForRequest:281 – Proxy request https://com.vmware.csp.core.designer.service.plugin.vproxy//designerAdmin/theme/images/circles.png failed to parse the associated gadget https://com.vmware.csp.core.designer.service.plugin.vproxy//designerAdmin/theme/Standard.css. The gadget will be ignored: org.apache.shindig.gadgets.process.ProcessingException: org.apache.shindig.common.xml.XmlException: Content is not allowed in prolog. At: (1,1)

The thing that immediately caught my attention was the following:

  • https://[https://10.10.100.101]:8281/vco/api

I for sure didn’t type https so i have no idea why vRA was trying to access the vCO using double https? I took the following steps while trying to identify the problem:

  • Connected to the vCO server from my desktop using Firefox –  successful
    Screen Shot 2015-01-24 at 04.57.38
  • Connected from the vRA VA using the curl -v -k command where -v is for verbose mode and -k is to skip SSL certification validation:
    • curl -v -k https://10.10.100.101:8281
      * About to connect() to 10.10.100.101port 8281 (#0)
      * Trying 10.10.100.101… connected
      * Connected to 10.10.100.101 (10.10.100.101) port 8281 (#0)
      * successfully set certificate verify locations:
      * CAfile: none
      CApath: /etc/ssl/certs/
      * SSLv3, TLS handshake, Client hello (1):
      * SSLv3, TLS handshake, Server hello (2):
      * SSLv3, TLS handshake, CERT (11):
      * SSLv3, TLS handshake, Server key exchange (12):
      * SSLv3, TLS handshake, Server finished (14):
      * SSLv3, TLS handshake, Client key exchange (16):
      * SSLv3, TLS change cipher, Client hello (1):
      * SSLv3, TLS handshake, Finished (20):
      * SSLv3, TLS change cipher, Client hello (1):
      * SSLv3, TLS handshake, Finished (20):
      * SSL connection using DHE-RSA-AES256-SHA
      * Server certificate:
      * subject: C=US; O=VMware; OU=VMware; CN=vCO01.rtp.nutanix.com
      * start date: DATE & TIME GMT
      * expire date: DATE & TIME2025-01-17 19:53:09 GMT
      * issuer: C=US; O=VMware; OU=VMware; CN=vCO01.domain.com
      * SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
      > GET / HTTP/1.1
      > User-Agent: curl/7.19.7 (x86_64-suse-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8j zlib/1.2.7 libidn/1.10
      > Host: 10.10.100.101:8281
      > Accept: */*
      >
      < HTTP/1.1 301 Moved Permanently
      < Server: Apache-Coyote/1.1
      < Location: https://10.10.100.101:8281/vco/
      < Content-Length: 0
      < Date: DATE & TIME GMT
      <
      * Connection #0 to host 10.10.100.101 left intact
      * Closing connection #0
      * SSLv3, TLS alert, Client hello (1):

Both tests were successful so after searching for an online solution decided to take the easy way out and reboot the vRA VA and apparently that solved the problem. I’m sorry i can’t give you an explanation to why this happens but at least you know what to do if it happens.

3 comments

  1. Sean Pearce

    What happens if you connect to both urls now, after the reboot? I note the curl example was a ‘permanent redirect’… What happens if you append /vco or /vco/api as per your original url?

  2. magander3

    Hi,
    really don’t know and don’t have access to the environment now. The reason for using curl was just to verify connectivity from the vRA appliance and not create any permanent session. Adding /vco or /vco/api is not required in the vRA configuration.

    thanks

  3. Robert

    Seems like a syntax validation problem within vRA. For some reason the IPv4 address you typed was interpreted as IPv6 address. The issue is discribed on Wikipedia pretty well: http://en.wikipedia.org/wiki/IPv6_address quote: “Colon (:) characters in IPv6 addresses may conflict with the established syntax of resource identifiers”

    I’m not sure how the identification v4/v6 is done in vRA but I guess that’s what happend. Did you eventually, while typeing in the IPv4 address, at some point accidently type in a colon which you deleted later on? E.g. copy paste IPv4+Port into the “host” field? If so that could be the reason. Eventually the VMware dev decided it’d be a good idea to use colon characters in the address for identification of IPv6 adresses but forget to do a switch-back to IPv4 if the colon is deleted. If so, then that switch routine should be visible in the Javascript validation within vRA.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">