VMware Cloud Community
Magicmanashu
Contributor
Contributor

vRA 7.3.1 Upgrade to vRA 7.4.0 using vRLCM 2.0

I am trying to upgrade vRA 7.3.1 to vRA 7.4.0 using vRLCM 2.0.

I have imported my environment to vRLCM successfully.  But during precheck for upgrade it is throwing below error for only my Primary Appliance. Rest everything is passed.

Just for note my vRA environment is 3 Node Cluster with 3 vRA Appliances.

 

  1. com.vmware.vim.vmomi.client.exception.ConnectionException: java.net.UnknownHostException: null: Name or service not known

at com.vmware.vim.vmomi.client.common.impl.ResponseImpl.setError(ResponseImpl.java:250)

at com.vmware.vim.vmomi.client.http.impl.HttpExchange.run(HttpExchange.java:51)

at com.vmware.vim.vmomi.client.http.impl.HttpProtocolBindingBase.executeRunnable(HttpProtocolBindingBase.java:226)

at com.vmware.vim.vmomi.client.http.impl.HttpProtocolBindingImpl.send(HttpProtocolBindingImpl.java:110)

at com.vmware.vim.vmomi.client.common.impl.MethodInvocationHandlerImpl$CallExecutor.sendCall(MethodInvocationHandlerImpl.java:580)

at com.vmware.vim.vmomi.client.common.impl.MethodInvocationHandlerImpl$CallExecutor.executeCall(MethodInvocationHandlerImpl.java:561)

at com.vmware.vim.vmomi.client.common.impl.MethodInvocationHandlerImpl.completeCall(MethodInvocationHandlerImpl.java:347)

at com.vmware.vim.vmomi.client.common.impl.MethodInvocationHandlerImpl.invokeOperation(MethodInvocationHandlerImpl.java:307)

at com.vmware.vim.vmomi.client.common.impl.MethodInvocationHandlerImpl.invoke(MethodInvocationHandlerImpl.java:181)

at com.sun.proxy.$Proxy163.retrieveContent(Unknown Source)

at com.vmware.vrealize.lcm.drivers.vsphere65.vlsi.BasicVlsiOperations.initVlsiConnectionOneTime(BasicVlsiOperations.java:94)

at com.vmware.vrealize.lcm.drivers.vsphere65.vlsi.VlsiOperations.initVlsiConnection(VlsiOperations.java:75)

at com.vmware.vrealize.lcm.drivers.vsphere65.vlsi.utils.VSphereDriverFactory.initConnection(VSphereDriverFactory.java:103)

at com.vmware.vrealize.lcm.drivers.vsphere65.vlsi.utils.CoreUtility.checkVMWithFQDNExists(CoreUtility.java:231)

at com.vmware.vrealize.lcm.plugin.core.vra70.task.VraPreUpgradeCheckTask.performJavaAndPowershellPrecheck(VraPreUpgradeCheckTask.java:566)

at com.vmware.vrealize.lcm.plugin.core.vra70.task.VraPreUpgradeCheckTask.checkIaaSUpgradePrecheck(VraPreUpgradeCheckTask.java:305)

at com.vmware.vrealize.lcm.plugin.core.vra70.task.VraPreUpgradeCheckTask.execute(VraPreUpgradeCheckTask.java:161)

at com.vmware.vrealize.lcm.platform.automata.core.ExecutionTask.run(ExecutionTask.java:41)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

at java.lang.Thread.run(Thread.java:748)

Caused by: java.net.UnknownHostException: null: Name or service not known

at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)

at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928)

at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1323)

at java.net.InetAddress.getAllByName0(InetAddress.java:1276)

at java.net.InetAddress.getAllByName(InetAddress.java:1192)

at java.net.InetAddress.getAllByName(InetAddress.java:1126)

at org.apache.http.impl.conn.SystemDefaultDnsResolver.resolve(SystemDefaultDnsResolver.java:45)

at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:111)

at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)

at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)

at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)

at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)

at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)

at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)

at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)

at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)

at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)

at com.vmware.vim.vmomi.client.http.impl.HttpExchange.run(HttpExchange.java:45)

... 19 more

 

 

Tried to search but coudnt find anything.

 

Please help here.

Reply
0 Kudos
7 Replies
r0j
Enthusiast
Enthusiast

We have used vRLCM 2.0 to upgrade from 7.3.1 to 7.4, and vRLCM 2.0 Patch 1 from 7.4 to 7.5.

on our DEV and PROD instances.

1 vRA appliance 1 IaaS Windows 2012 R2 server.

1 vRA appliance 2 IaaS Windows 2012 R2 servers.

On the 7.4-7.5 upgrade for PROD, The pre-requisite checks failed for our IaaS servers, needed the 2012 R2 .ISO mounted to the vm's cd-rom for .NET 3 for some reason.

The upgrade hung, even though vRLCM said it was complete. A reboot of the vRA appliance was needed to complete / resume the upgrade.

Questions...

Have you rebooted your vRA appliance?

Are all services registered and running in the VAMI?

Are you running patch 1 on vRLCM?

Did you try a manual update from the VAMI mounting the .ISO to the appliance, and see if the pre-requisite checks give more details?

Not sure if this is helpful, but will put it out there.

Reply
0 Kudos
Magicmanashu
Contributor
Contributor

Here are the details that you asked...

Have you rebooted your vRA appliance?   --- Yes 

Are all services registered and running in the VAMI? -- Yes all the services are up and running on all the 3 Appliances, environment is fully stable.

Are you running patch 1 on vRLCM? -- Patch 2 on vRLCM

Did you try a manual update from the VAMI mounting the .ISO to the appliance, and see if the pre-requisite checks give more details? -- No i havent tried this one as dont have the option for that due to security reasons.

My biggest concern is that during precheck validation, all the other components of appliances and iaas servers are passed except my primary appliance, also all other things on primary appliance like cpu,memory disk everything gets passed but at the last we get unknown host or service.

Reply
0 Kudos
r0j
Enthusiast
Enthusiast

Unknown host or service under what PreCheck?

Save the report as a PDF and copy and paste the results of your report here, removing the component / resource info.

Reply
0 Kudos
Magicmanashu
Contributor
Contributor

On Run Precheck before Submit button on vRLCM during upgrade.

Attached the file showing the error.

Reply
0 Kudos
r0j
Enthusiast
Enthusiast

is it possible the vRLCM appliance cannot communicate with your vRA appliance?

I looks like it can communicate with your IaaS servers.

Are you able to successfully use vRLCM for any other content pipeline activities to your vRA appliance?

If not, rule out firewall /port / dns issues.

Magicmanashu
Contributor
Contributor

I guess vRLCM is able to communicate with all the appliances, why i am saying that is because, as i mentioned i have 3 appliances in cluster and for secondary and tertiary appliance it is passing , for primary appliance it is able to fetch all the data like cpu check, memory check, disk check and all other things. Not sure why it is throwing error only for primary one only.

 

  1. com.vmware.vim.vmomi.client.exception.ConnectionException: java.net.UnknownHostException: null: Name or service not known

at com.vmware.vim.vmomi.client.common.impl.ResponseImpl.setError(ResponseImpl.java:250)

at com.vmware.vim.vmomi.client.http.impl.HttpExchange.run(HttpExchange.java:51)

at com.vmware.vim.vmomi.client.http.impl.HttpProtocolBindingBase.executeRunnable(HttpProtocolBindingBase.java:226)

at com.vmware.vim.vmomi.client.http.impl.HttpProtocolBindingImpl.send(HttpProtocolBindingImpl.java:110)

at com.vmware.vim.vmomi.client.common.impl.MethodInvocationHandlerImpl$CallExecutor.sendCall(MethodInvocationHandlerImpl.java:580)

at com.vmware.vim.vmomi.client.common.impl.MethodInvocationHandlerImpl$CallExecutor.executeCall(MethodInvocationHandlerImpl.java:561)

at com.vmware.vim.vmomi.client.common.impl.MethodInvocationHandlerImpl.completeCall(MethodInvocationHandlerImpl.java:347)

at com.vmware.vim.vmomi.client.common.impl.MethodInvocationHandlerImpl.invokeOperation(MethodInvocationHandlerImpl.java:307)

at com.vmware.vim.vmomi.client.common.impl.MethodInvocationHandlerImpl.invoke(MethodInvocationHandlerImpl.java:181)

at com.sun.proxy.$Proxy163.retrieveContent(Unknown Source)

at com.vmware.vrealize.lcm.drivers.vsphere65.vlsi.BasicVlsiOperations.initVlsiConnectionOneTime(BasicVlsiOperations.java:94)

at com.vmware.vrealize.lcm.drivers.vsphere65.vlsi.VlsiOperations.initVlsiConnection(VlsiOperations.java:75)

at com.vmware.vrealize.lcm.drivers.vsphere65.vlsi.utils.VSphereDriverFactory.initConnection(VSphereDriverFactory.java:103)

at com.vmware.vrealize.lcm.drivers.vsphere65.vlsi.utils.CoreUtility.checkVMWithFQDNExists(CoreUtility.java:231)

at com.vmware.vrealize.lcm.plugin.core.vra70.task.VraPreUpgradeCheckTask.performJavaAndPowershellPrecheck(VraPreUpgradeCheckTask.java:566)

at com.vmware.vrealize.lcm.plugin.core.vra70.task.VraPreUpgradeCheckTask.checkIaaSUpgradePrecheck(VraPreUpgradeCheckTask.java:305)

at com.vmware.vrealize.lcm.plugin.core.vra70.task.VraPreUpgradeCheckTask.execute(VraPreUpgradeCheckTask.java:161)

at com.vmware.vrealize.lcm.platform.automata.core.ExecutionTask.run(ExecutionTask.java:41)

 

i havent tried any other pipeline operation on the appliances as of now.

Reply
0 Kudos
r0j
Enthusiast
Enthusiast

looks like I missed the part of you running clustered vs. distributed as in our case.

:smileylaugh:

All of our experiences with clustered deployments, have not been pleasant ones.

Try the manual upgrade process for a clustered environment, otherwise I see a support ticket in your future for vRLCM.

We have opened a few for vRLCM, and they have been great with making changes to this fast changing and very useful product.

Cheers...

Reply
0 Kudos