user2018
Contributor
Contributor

After Upgrade Vrealize Orchestrator 8.1.0 16376637 to 8.2 17015463 https:// = Service is available

Hello,

 

After successfully upgraded a Orchestrator stand alone appliance to version 8.2, the web page is showing

"Service is unavailable" through https://vcoFullDomainName or https://vcoFullDomainName/vco/

 

The 5480 interface is working good, and I can see the new version is 8.2 17015463 and no error for the last upgrade entry.

 

Here are few commands I have ran. Is anybody encounter the same issue ? (I have a snapshot, but I would like to try the new version ^^)

 

kubectl get namespace
NAME STATUS AGE
default Active 49m
ingress Active 116s
kube-node-lease Active 49m
kube-public Active 49m
kube-system Active 49m
prelude Active 116s

 

kubectl get pods -n prelude
NAME READY STATUS RESTARTS AGE
orchestration-ui-app-658ff586f8-7zwr6 1/1 Running 0 2m44s
postgres-0 1/1 Running 0 4m2s
proxy-service-5b58fbd847-lwv7b 1/1 Running 0 4m1s
vco-app-bc7bcf4df-pck9d 2/3 Running 0 2m43s

 

kubectl get services -n prelude
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
orchestration-ui ClusterIP 10.244.7.161 <none> 80/TCP 2m58s
pgpool ClusterIP 10.244.5.146 <none> 5432/TCP 4m16s
postgres ClusterIP None <none> <none> 4m16s
proxy-service ClusterIP 10.244.6.25 <none> 3128/TCP 4m15s
vco-controlcenter-service ClusterIP 10.244.7.78 <none> 8282/TCP 2m57s
vco-polyglot-debugging-service NodePort 10.244.7.94 <none> 18281:18281/TCP,18282:18282/TCP,18283:18283/TCP,18284:18284/TCP,18285:18285/TCP 2m57s
vco-service ClusterIP 10.244.5.232 <none> 8280/TCP 2m57s

kubectl get deployments -n prelude
NAME READY UP-TO-DATE AVAILABLE AGE
orchestration-ui-app 1/1 1 1 3m22s
proxy-service 1/1 1 1 4m39s
vco-app 0/1 1 0 3m21s

 

I googled but there is no reference to this issue on the doc for 8.2. Thx for helping

0 Kudos
15 Replies
iiliev
VMware Employee
VMware Employee

Hi,

The output of these commands shows that not all vRO pods are up and running (see values in READY column).

I'd suggest to wait a few minutest and run the commands again to check if vco-app pods/services are fully started. If the issue is still there, the next step would be to collect a log bundle (using the command 'vracli log-bundle') and search for errors in the collected logs.

0 Kudos
user2018
Contributor
Contributor

Hello iiliev,

 

Thank you for the reply. I have waited a full night after rebooting the appliance but the problem persists. I have done like you said and generated a log bundle.

 

On vco-server-app.log, I can see this error in loop.

2020-11-10 07:10:13.638+0000 [ApplicaitonEventHandler-1] INFO {} [EnhancedScriptingSDK] Sending started event, after all plug-ins are installed
2020-11-10 07:10:13.639+0000 [ApplicaitonEventHandler-1] WARN {} [BlockingRetrier] Unable to install plugins! Retry 5519 failed because of: Unable to perform plug-in installation, reason : null
ch.dunes.util.DunesServerException: Unable to perform plug-in installation, reason : null
at com.vmware.o11n.sdk.EnhancedScriptingSDK.performPluginServerInstallation(EnhancedScriptingSDK.java:240) ~[?:?]
at ch.dunes.vso.sdk.mbean.PluginInstaller$1.call(PluginInstaller.java:51) ~[?:?]
at ch.dunes.vso.sdk.mbean.PluginInstaller$1.call(PluginInstaller.java:48) ~[?:?]
at ch.dunes.util.BlockingRetrier.retryOperation(BlockingRetrier.java:19) ~[?:?]
at ch.dunes.vso.sdk.mbean.PluginInstaller.onApplicationEvent(PluginInstaller.java:48) ~[?:?]
at ch.dunes.vso.sdk.mbean.PluginInstaller.onApplicationEvent(PluginInstaller.java:25) ~[?:?]
at org.springframework.context.event.SimpleApplicationEventMulticaster.doInvokeListener(SimpleApplicationEventMulticaster.java:172) ~[?:?]
at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:165) ~[?:?]
at org.springframework.context.event.SimpleApplicationEventMulticaster.lambda$multicastEvent$0(SimpleApplicationEventMulticaster.java:136) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_262]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_262]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_262]

 

On vco-controlcenter-app.log

2020-11-10 07:09:54.449+0000 [access.log] [http-nio-8282-exec-5] 10.244.0.1 - - "GET /vco-controlcenter/api/server/about HTTP/1.1" 200 173 1
2020-11-10 07:10:00.432+0000 [access.log] [http-nio-8282-exec-4] 10.244.0.1 - - "GET /vco-controlcenter/api/server/about HTTP/1.1" 200 173 0
2020-11-10 07:10:04.449+0000 [access.log] [http-nio-8282-exec-7] 10.244.0.1 - - "GET /vco-controlcenter/api/server/about HTTP/1.1" 200 173 1
2020-11-10 07:10:10.435+0000 [access.log] [http-nio-8282-exec-6] 10.244.0.1 - - "GET /vco-controlcenter/api/server/about HTTP/1.1" 200 173 2
2020-11-10 07:10:14.448+0000 [access.log] [http-nio-8282-exec-8] 10.244.0.1 - - "GET /vco-controlcenter/api/server/about HTTP/1.1" 200 173 0

 

Nothing seems wrong.

 

The others logs are empty on the location services-logs\prelude\vco-app so nothing more I can extract.

 

 

sqidproxy.log

1604992189.141 0 10.244.0.1 NONE/000 0 NONE error:transaction-end-before-headers - HIER_NONE/- -
1604992199.141 0 10.244.0.1 NONE/000 0 NONE error:transaction-end-before-headers - HIER_NONE/- -
1604992209.141 0 10.244.0.1 NONE/000 0 NONE error:transaction-end-before-headers - HIER_NONE/- -

 

Seems no good but I don't know what to do here. The ip looks internal to the pod so maybe the error is somewhere else.

 

 

On var\log\vmware-vmsvc.log

 

[2020-11-10T07:08:16.748Z] [ warning] [guestinfo] GetDiskInfo: ERROR: Partition name buffer too small
[2020-11-10T07:08:16.748Z] [ warning] [guestinfo] Failed to get disk info.
[2020-11-10T07:08:46.749Z] [ warning] [guestinfo] GetDiskInfo: ERROR: Partition name buffer too small
[2020-11-10T07:08:46.749Z] [ warning] [guestinfo] Failed to get disk info.
[2020-11-10T07:09:16.749Z] [ warning] [guestinfo] GetDiskInfo: ERROR: Partition name buffer too small
[2020-11-10T07:09:16.749Z] [ warning] [guestinfo] Failed to get disk info.
[2020-11-10T07:09:46.750Z] [ warning] [guestinfo] GetDiskInfo: ERROR: Partition name buffer too small
[2020-11-10T07:09:46.750Z] [ warning] [guestinfo] Failed to get disk info.
[2020-11-10T07:10:16.751Z] [ warning] [guestinfo] GetDiskInfo: ERROR: Partition name buffer too small
[2020-11-10T07:10:16.751Z] [ warning] [guestinfo] Failed to get disk info.

 

Maybe that's the root cause ? however I have no idea what it means. I can see all the partition with df -h so ...

 

Any advice ? seems like I need to revert my snapshot after all 😞

 

Thx

0 Kudos
iiliev
VMware Employee
VMware Employee

It's probably caused by the first error - some plug-in fails to install correctly and the server is stuck retrying this operation over and over.

Unfortunately, it doesn't say which plug-in exactly fails to deploy. Could you set the vRO log level to DEBUG (or better TRACE) in vRO Control Center, restart, and collect a new log bundle? Hopefully there will be more info logged with increased log level.

0 Kudos
user2018
Contributor
Contributor

Hello,

Thx you. I will dig more that part. Unfortunately, the access to the servicecontrol page gives me the same error Service is available so I cannot change the logging level.

 

Is there any config file I can change to change the logging to TRACE or DEBUG ?

 

I have googled a little and I find this file but I am not sure this is still applicable for VRO 8.2

 

cat /data/vco/usr/lib/vco/configuration/conf/log4j2.xml
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="INFO" monitorInterval="15">
<Appenders>
<Console name="CONSOLE" target="SYSTEM_OUT">
<PatternLayout
pattern="%d{yyyy-MM-dd HH:mm:ss.SSSZ} [%t] %-5p {%X{full}} [%c{1}] %m%n" />
</Console>
</Appenders>

<Loggers>
<Logger
name="org.apache.commons.vfs2.impl.StandardFileSystemManager"
level="ERROR" additivity="true">
<AppenderRef ref="CONSOLE" />
</Logger>

<Root level="INFO">
<AppenderRef ref="CONSOLE" />
</Root>
</Loggers>
</Configuration>

Can you confirm me this is the right file ? 🙂

0 Kudos
iiliev
VMware Employee
VMware Employee

That's the log configuration file for vRO Control Center; you need to change the log level in vRO server's configuration file. Just replace /configuration/ segments in its path with /app-server/.

 

Also note that all manual changes done in this file may be overwritten automatically when you do a restart. In this case, what you can try is to attach a Bash terminal to vRO server container vco-server-app, list running processes with 'ps' command, and kill the process with PID 1 (this should be the Java process which runs vRO server). This should restart the process without redeploying the pods/containers, and the manual changes in the file won't be lost.

0 Kudos
user2018
Contributor
Contributor

thank you iiliev, I will try 🙂

In case anybody is looking for the file here is the example

 

cat /data/vco/usr/lib/vco/app-server/conf/log4j2.xml
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="INFO" monitorInterval="15"
packages="com.vmware.o11n.service.logging">
<Appenders>
<Lucene name="SCRIPT_LOGS"
fileName="${sys:catalina.base}/logs/scripting.log"
filePattern="${sys:catalina.base}/logs/scripting.log.%i">
<PatternLayout
pattern="%d{yyyy-MM-dd HH:mm:ss.SSSZ} %-5p {|%X{tenantId}|%X{username}:%X{token}%X{tokenctx}} [%c{1}] %m%n" />
<Policies>
<SizeBasedTriggeringPolicy
size="20MB" />
</Policies>
<DefaultRolloverStrategy max="5" />
</Lucene>
<Console name="CONSOLE" target="SYSTEM_OUT">
<PatternLayout
pattern="%d{yyyy-MM-dd HH:mm:ss.SSSZ} [%t] %-5p {%X{full}} [%c{1}] %m%n" />
</Console>
</Appenders>

<Loggers>
<Logger name="IGNORED_EXCEPTION" level="WARN"
additivity="false">
<AppenderRef ref="CONSOLE" />
</Logger>
<Logger name="metrics" level="INFO" additivity="false">
<AppenderRef ref="CONSOLE" />
</Logger>
<Logger name="vc-metrics" level="INFO" additivity="false">
<AppenderRef ref="CONSOLE" />
</Logger>

<Logger name="ch.dunes" level="INFO" additivity="true">
</Logger>
<Logger name="com.vmware.o11n" level="INFO"
additivity="true">
</Logger>
<Logger name="Execution" level="INFO" additivity="true">
</Logger>

<Logger name="com.vmware.vim.sso.client" level="ERROR"
additivity="true">
</Logger>
<Logger name="com.vmware.vim.sso.admin.client.common"
level="ERROR" additivity="true">
</Logger>

<Logger name="com.vmware.vim.vmomi.core.types"
level="ERROR" additivity="true">
</Logger>

<Logger name="com.vmware.vmo.plugin.vi35" level="INFO"
additivity="true">
</Logger>
<Logger name="com.vmware.vmo.plugin.vi4" level="INFO"
additivity="true">
</Logger>

<Logger name="org.springframework" level="INFO"
additivity="true">
</Logger>
<Logger name="org.hornetq" level="INFO" additivity="true">
</Logger>
<Logger name="org.hibernate" level="WARN"
additivity="true">
</Logger>
<Logger name="org.hibernate.cfg.SettingsFactory"
level="ERROR" additivity="true">
</Logger>
<Logger name="org.apache.http" level="INFO"
additivity="true">
</Logger>
<Logger name="org.apache.directory" level="FATAL"
additivity="true">
</Logger>
<Logger name="net.sf.ehcache" level="INFO"
additivity="true">
</Logger>
<Logger name="org.apache.tomcat.jdbc.pool.ConnectionPool"
level="INFO" additivity="false">
</Logger>

<Logger name="com.vmware.o11n.git" level="DEBUG"
additivity="false">
<AppenderRef ref="CONSOLE" />
</Logger>
<Logger name="com.vmware.o11n.service.version"
level="DEBUG" additivity="false">
<AppenderRef ref="CONSOLE" />
</Logger>

<Logger name="SCRIPTING_LOG" level="DEBUG"
additivity="false">
<AppenderRef ref="CONSOLE" />
<AppenderRef ref="SCRIPT_LOGS" />
</Logger>

<Root level="INFO">
<AppenderRef ref="CONSOLE" />
</Root>
</Loggers>
</Configuration>

0 Kudos
user2018
Contributor
Contributor

That's what I could extract from the second log-bundle

It seems the blocking point is at the plugin installation. However I don't know why because they are all built-in for me. So that's strange

2020-11-10 10:55:22.052+0000 [localhost-startStop-1] INFO {} [ThreadPoolTaskScheduler] Shutting down ExecutorService 'tokenLifetimeMonitorScheduler'
2020-11-10 10:55:22.052+0000 [localhost-startStop-1] INFO {} [ThreadPoolTaskScheduler] Shutting down ExecutorService 'cleanCustomEventsScheduler'
2020-11-10 10:55:22.053+0000 [localhost-startStop-1] INFO {} [ThreadPoolTaskScheduler] Shutting down ExecutorService 'pollCustomEventsScheduler'
2020-11-10 10:55:22.055+0000 [localhost-startStop-1] INFO {} [ThreadPoolTaskExecutor] Shutting down ExecutorService
2020-11-10 10:55:22.056+0000 [localhost-startStop-1] INFO {} [ThreadPoolTaskScheduler] Shutting down ExecutorService 'taskCenterScheduler'
2020-11-10 10:55:22.057+0000 [localhost-startStop-1] INFO {} [ThreadPoolTaskScheduler] Shutting down ExecutorService 'initialConfigScheduler'
2020-11-10 10:55:22.057+0000 [ApplicaitonEventHandler-1] INFO {} [SDKModuleDescription] Performing server side installation for plug-in 'DynamicTypes'
2020-11-10 10:55:22.058+0000 [localhost-startStop-1] INFO {} [ThreadPoolTaskScheduler] Shutting down ExecutorService 'serverHealthMonitorScheduler'
2020-11-10 10:55:22.091+0000 [localhost-startStop-1] INFO {} [EhCacheManagerFactoryBean] Shutting down EhCache CacheManager
2020-11-10 10:55:22.092+0000 [ApplicaitonEventHandler-1] ERROR {} [ModulesFactory] Unable to perform plug-in installation 'DynamicTypes', reason : null
2020-11-10 10:55:22.093+0000 [ApplicaitonEventHandler-1] INFO {} [SDKModuleDescription] Performing server side installation for plug-in 'SSH'
2020-11-10 10:55:22.094+0000 [ApplicaitonEventHandler-1] ERROR {} [ModulesFactory] Unable to perform plug-in installation 'SSH', reason : null
2020-11-10 10:55:22.094+0000 [ApplicaitonEventHandler-1] INFO {} [SDKModuleDescription] Performing server side installation for plug-in 'AD'
2020-11-10 10:55:22.096+0000 [ApplicaitonEventHandler-1] ERROR {} [ModulesFactory] Unable to perform plug-in installation 'AD', reason : null
2020-11-10 10:55:22.097+0000 [ApplicaitonEventHandler-1] INFO {} [SDKModuleDescription] Performing server side installation for plug-in 'VCO'
2020-11-10 10:55:22.098+0000 [ApplicaitonEventHandler-1] ERROR {} [ModulesFactory] Unable to perform plug-in installation 'VCO', reason : null
2020-11-10 10:55:22.098+0000 [ApplicaitonEventHandler-1] INFO {} [SDKModuleDescription] Performing server side installation for plug-in 'Library'
2020-11-10 10:55:22.099+0000 [ApplicaitonEventHandler-1] ERROR {} [ModulesFactory] Unable to perform plug-in installation 'Library', reason : null
2020-11-10 10:55:22.100+0000 [ApplicaitonEventHandler-1] INFO {} [SDKModuleDescription] Performing server side installation for plug-in 'VC'
2020-11-10 10:55:22.101+0000 [ApplicaitonEventHandler-1] ERROR {} [ModulesFactory] Unable to perform plug-in installation 'VC', reason : null
2020-11-10 10:55:22.101+0000 [ApplicaitonEventHandler-1] INFO {} [SDKModuleDescription] Performing server side installation for plug-in 'REST'
2020-11-10 10:55:22.102+0000 [ApplicaitonEventHandler-1] ERROR {} [ModulesFactory] Unable to perform plug-in installation 'REST', reason : null
2020-11-10 10:55:22.102+0000 [ApplicaitonEventHandler-1] INFO {} [SDKModuleDescription] Performing server side installation for plug-in 'Workflow documentation'
2020-11-10 10:55:22.103+0000 [ApplicaitonEventHandler-1] ERROR {} [ModulesFactory] Unable to perform plug-in installation 'Workflow documentation', reason : null
2020-11-10 10:55:22.104+0000 [ApplicaitonEventHandler-1] INFO {} [SDKModuleDescription] Performing server side installation for plug-in 'SQL'
2020-11-10 10:55:22.105+0000 [ApplicaitonEventHandler-1] ERROR {} [ModulesFactory] Unable to perform plug-in installation 'SQL', reason : null
2020-11-10 10:55:22.132+0000 [ApplicaitonEventHandler-1] INFO {} [EnhancedScriptingSDK] Sending started event, after all plug-ins are installed
2020-11-10 10:55:22.133+0000 [ApplicaitonEventHandler-1] WARN {} [BlockingRetrier] Unable to install plugins! Retry 1 failed because of: Unable to perform plug-in installation, reason : null
ch.dunes.util.DunesServerException: Unable to perform plug-in installation, reason : null
at com.vmware.o11n.sdk.EnhancedScriptingSDK.performPluginServerInstallation(EnhancedScriptingSDK.java:240) ~[o11n-licensing-provider-8.2.0.jar:?]
at ch.dunes.vso.sdk.mbean.PluginInstaller$1.call(PluginInstaller.java:51) ~[o11n-sdkcenter-8.2.0.jar:?]
at ch.dunes.vso.sdk.mbean.PluginInstaller$1.call(PluginInstaller.java:48) ~[o11n-sdkcenter-8.2.0.jar:?]
at ch.dunes.util.BlockingRetrier.retryOperation(BlockingRetrier.java:19) ~[o11n-util-8.2.0.jar:?]
at ch.dunes.vso.sdk.mbean.PluginInstaller.onApplicationEvent(PluginInstaller.java:48) ~[o11n-sdkcenter-8.2.0.jar:?]
at ch.dunes.vso.sdk.mbean.PluginInstaller.onApplicationEvent(PluginInstaller.java:25) ~[o11n-sdkcenter-8.2.0.jar:?]
at org.springframework.context.event.SimpleApplicationEventMulticaster.doInvokeListener(SimpleApplicationEventMulticaster.java:172) ~[spring-context-5.1.17.RELEASE.jar:5.1.17.RELEASE]
at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:165) ~[spring-context-5.1.17.RELEASE.jar:5.1.17.RELEASE]
at org.springframework.context.event.SimpleApplicationEventMulticaster.lambda$multicastEvent$0(SimpleApplicationEventMulticaster.java:136) ~[spring-context-5.1.17.RELEASE.jar:5.1.17.RELEASE]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_262]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_262]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_262]
2020-11-10 10:55:22.162+0000 [localhost-startStop-1] INFO {} [ThreadPoolTaskScheduler] Shutting down ExecutorService 'vcoSystemTaskScheduler'
2020-11-10 10:55:22.163+0000 [localhost-startStop-1] INFO {} [ContentCacheFactoryBean] Shutting down EhCache CacheManager
2020-11-10 10:55:22.164+0000 [localhost-startStop-1] INFO {} [ThreadPoolTaskExecutor] Shutting down ExecutorService 'policyEventExecutor'
2020-11-10 10:55:22.165+0000 [localhost-startStop-1] INFO {} [ThreadPoolTaskScheduler] Shutting down ExecutorService 'membershipScheduler'
2020-11-10 10:55:22.165+0000 [localhost-startStop-1] INFO {} [ThreadPoolTaskScheduler] Shutting down ExecutorService 'configScheduler'

 

 

0 Kudos
iiliev
VMware Employee
VMware Employee

It doesn't seem like log level has been changed successfully. I would expect a message like "Plug-in install error" on DEBUG level, followed by the full Java exception stack trace pointing where exactly the error is thrown in the code.

0 Kudos
user2018
Contributor
Contributor

Yeah it looks like the pod has revert the log level ... I just cat the config file and the loglevel is back to INFO  😞

 

I am not very familiar with pod and linux so I think I will revert my snapshot until I have a better way to update. Or I will try a migrate. That's maybe more easy.

 

Anyway thanks for the helping.

0 Kudos
luoh9
Contributor
Contributor

Hi,

Did you encounter the error "Updating bootstrap patch was terminated with error. Upgrade will not be continue. More details available at /var/log/vmware/prelude" during the upgrade?

Thank you!

0 Kudos
user2018
Contributor
Contributor

Hello,

 

Sorry for my late reply, I was on day off.

 

I have checked the location and I see see this output of latestreport

 

cat upgrade-report-latest


Upgrade Report


Summary
-------------------------------------------------------------------------------------

Date: Mon Nov 9 16:39:15 CET 2020
Duration: 177553 minutes
Result: Upgrade Failure
Description: Upgrade failed and left the system in non-working state. Check the error report below to correct the problem. Once addressed, you can continue the upgrade by running 'vracli upgrade exec --resume'


Reference
-------------------------------------------------------------------------------------

Logs: /var/log/vmware/prelude
Backup: /data/restorepoint
Runtime: /var/vmware/prelude/upgrade

Some directories might not exist.


Version
-------------------------------------------------------------------------------------

Services
Before: 8.1.0.9465
After: 8.2.0.12957

Platform
Before: 8.1.0.9465
After: 8.2.0.12957


Errors
-------------------------------------------------------------------------------------
File manifest/manifest-latest.xml is not available in the repository.
File manifest/manifest-latest.xml.sig is not available in the repository.
Manifest cannot be downloaded from the repository.
File manifest/manifest-latest.xml is not available in the repository.
File manifest/manifest-latest.xml.sig is not available in the repository.
Manifest cannot be downloaded from the repository.
[ERROR][2020-11-09 16:39:08][MYHOSTNAME][Exit Code: 123] Error while deploying infrastructure and application services.

 

0 Kudos
HuiLuo_new
Contributor
Contributor

Hello,

Could you tell me how to upgrade from 8.1 to 8.2, I tried according to the doc, but still got the error "Updating bootstrap patch was terminated with error. Upgrade will not be continue. More details available at /var/log/vmware/prelude."

Do you have any suggestions? Thank you!

0 Kudos
user2018
Contributor
Contributor

Ok

 

I have upgraded to 8.1.0 patch3. I will try later again to update to 8.2.

 

{"version":"8.1.0.16945213",
"build-number":"16945213",
"build-date":"2020-09-24T20:32:55Z",
"api-version":"5.5.2",
"time-zone":"GMT",
"features":[]}

The vra services seems to work, and the GUI is up and running. Finger crossed for following 🙂

 

Huiluo, Sorry I can't help you but it seems we are a very small amount of people to get headache when upgrading Vrealize Orchestrator .... that's the only appliance from vmware to give me so much difficulty.

Maybe check the log file in /var/log/vmware/prelude, if you find any useful message.

In my case, it seems the upgrade is not finished, but I can't fix it to resume the upgrade.

 

Kind regards

 

 

 

 

0 Kudos
HuiLuo_new
Contributor
Contributor

Update, Successfully upgrade to 8.2 patch1🤣

0 Kudos
nef_user
Enthusiast
Enthusiast

Hi,

I was having the exact same issue. I don't have vRA license, and I've noticed a exclamation mark at vCAC plugin at control center. After removing the 2 vCACs plugins I've upgraded successfully. I do not know if there is something related to the license, maybe someone from VMware can help.

best regards

0 Kudos