Highlighted
Enthusiast
Enthusiast

Unable to View Item Details of Provisioned Azure Deployments

Jump to solution

Hi all,

I'm using the out of the box Azure blueprints to deploy devices. They provision as expected but when I try to view the Item Details for them the loading mask spins for awhile and eventually errors out with something like:

pastedImage_0.png

This behavior is seen on two instances I have, one a 7.2, and another a 7.3. Opening up catalina.out on the vRealize Automation appliance I see this peppered in the log:

2018-01-25 14:52:52,384 vcac: [component="cafe:shell" priority="ERROR" thread="tomcat-http--1" tenant="azure" context="k9OI17bf" parent="" token="k9OI17bf"] com.vmware.vcac.shell.service.ErrorServiceImpl.logToApacheCommons:59 - <a28f4ddb> Unexpected exception was caught

com.google.gwt.core.shared.SerializableThrowable: The connection to vCenter Orchestrator server timed out.

        at Unknown.xf(item-0.js) ~[?:?]

        at Unknown.Cf(item-0.js) ~[?:?]

        at Unknown.Kf(item-0.js) ~[?:?]

        at Unknown.new RId(item-0.js) ~[?:?]

        at Unknown.pQc(item-0.js) ~[?:?]

        at Unknown.nQc(item-0.js) ~[?:?]

        at Unknown.w9d(item-0.js) ~[?:?]

        at Unknown.z9d(item-0.js) ~[?:?]

        at Unknown.Mae(item-0.js) ~[?:?]

        at Unknown.Pae(item-0.js) ~[?:?]

        at Unknown.eval(item-0.js) ~[?:?]

        at Unknown.xg(item-0.js) ~[?:?]

        at Unknown.Ag(item-0.js) ~[?:?]

        at Unknown.eval(item-0.js) ~[?:?]

Only KB I can find around this is a 6.2 fix. Since my instances are 7.x I'm a little worried about applying this.

I have noticed that when I try to load a type Azure:VirtualMachine from a workflow run it takes forever to pull (might be the way the get logic was implemented, or the API call behind the scenes used), so I can see why this occurs.

Anyone run into this before?

1 Solution

Accepted Solutions
Highlighted
Enthusiast
Enthusiast

Here is the change we made:

-  cd /usr/lib/vcac/server/webapps/o11n-gateway-service/WEB-INF/classes/META-INF/spring/root

-  cp o11n-gateway-service-context.xml o11n-gateway-service-context.xml.bk

- vi o11n-gateway-service-context.xml

- edit > <property name="socketTimeout" value="#{vcoConfig['vco.socket.timeout.millis']?:30000}"/> to 130000

- service vcac-server restart

View solution in original post

0 Kudos
9 Replies
Highlighted
VMware Employee
VMware Employee

I have a customer with the same problem on vRA 7.2 using external vRO 7.2 with the patch from KB214937 applied.

I assume you have identical symptoms where you can see the VM in Azure portal and in vRO inventory. You can also see all other Azure configuration items like storage accounts, virtual networks etc in vRO proving that the plugin is still connecting to Azure, and if you refresh the Azure inventory in vRO it reloads fine but the VM details still don't load. From memory you can also use the actions to start/stop the VM as long as you aren't trying to view it's details.

We have an SR open with support but don't have a solution yet. Suggest you also contact support for assistance.

0 Kudos
Highlighted
Enthusiast
Enthusiast

Thank you Hejahida. Yes, same symptoms. I feel like the root cause of the error is the amount of time it takes the Azure plugin to retrieve information for VMs. On completed workflow runs it can take upwards of 30 seconds to 1 minute to pull the returned object of type AzureVirtualMachine. I'm sure vRA is not as patient when it comes to things like this. Smiley Happy

Highlighted
VMware Employee
VMware Employee

Hi, . I have a customer with the same issue. Would you be able to share the SR number?

0 Kudos
Highlighted
VMware Employee
VMware Employee

SR number was 17654509312. There was a workaround provided by engineering to change a timeout value which I believe resolved the problem.

Highlighted
Enthusiast
Enthusiast

Hey Hejahida,

What timeout value was increased if I may ask? Sounds like my assumption that it's taking too long to pull the info for vRA to handle was the right one.

0 Kudos
Highlighted
VMware Employee
VMware Employee

rmav01 I think you were right. In one of the config files on the vRA appliance there is a vco config socket timeout value set to 30000, they recommended changing this to 1200000. So it looks like vRO (or the connection to it) was timing out before vRA could get the information it needed from the plugin.

Highlighted
Enthusiast
Enthusiast

Here is the change we made:

-  cd /usr/lib/vcac/server/webapps/o11n-gateway-service/WEB-INF/classes/META-INF/spring/root

-  cp o11n-gateway-service-context.xml o11n-gateway-service-context.xml.bk

- vi o11n-gateway-service-context.xml

- edit > <property name="socketTimeout" value="#{vcoConfig['vco.socket.timeout.millis']?:30000}"/> to 130000

- service vcac-server restart

View solution in original post

0 Kudos
Highlighted
Enthusiast
Enthusiast

Thank you and everyone else. That worked!

0 Kudos
Highlighted
Enthusiast
Enthusiast

Hi rmav01​, I am very glad to hear that it worked for you.

0 Kudos