Aria Automation UI Inaccessible after VM Power-On from Aria Suite Lifecycle Manager with error code LCMVRAVACONFIG590070
search cancel

Aria Automation UI Inaccessible after VM Power-On from Aria Suite Lifecycle Manager with error code LCMVRAVACONFIG590070

book

Article ID: 434731

calendar_today

Updated On:

Products

VCF Operations/Automation (formerly VMware Aria Suite)

Issue/Introduction

  • Navigating to Aria Suite Lifecycle Manager  UI > Lifecycle operation> VM power on request failed with error code "LCMVRAVACONFIG590070 Failed to start services on vRA"

LCMVRAVACONFIG590070

Failed to start services on VMware Aria Automation. Refer
to the VMware Aria Suite Lifecycle log for additional
details.

Failed to start services on VMware Aria Automation
FQDN. For more information, login
into the VMware Aria Automation and check
/var/log/deploy.log file.

  • The /var/log/deploy.log on Aria Automation SSH  indicated "Identity Service health check failure: Identity Service health check failed. If load-balancer is deployed, make sure it is properly configured."

##:##:## UTC Identity Service health check failed. If load-balancer is deployed, make sure it is properly configured.

  • The /services-logs/prelude/identity-service-app/files-logs/identity-service-app.log: shows a WebClientRequestException when the identity service attempted to communicate with the Event Broker Service (EBS):

##:##:## ERROR identity-service [host='identity-service-app-############' thread='reactor-http-epoll-4' user='' org='' trace='' parent='' span=''] c.v.a.s.w.platform.client.WebClientUtil
.lambda$registerEntity$3:514 - Exception of type:org.springframework.web.reactive.function.client.WebClientRequestException
org.springframework.web.reactive.function.client.WebClientRequestException: null

Environment

VMware Aria Automation 8.x
VMware Aria Suite Lifecycle 8.x

Cause

  • The issue is caused by a manual proxy configuration added to the /etc/profile file on the Aria Automation appliance.

Resolution

  • Access the VMware Aria Automation appliance via SSH using root credentials.
  • Run the following commands to verify whether a proxy is being used:

curl -v http://identity-service.prelude.svc.cluster.local:8000/identity/healthcheck

 [ ~ ]# curl -v http://identity-service.prelude.svc.cluster.local:8000/identity/healthcheck
* Uses proxy env variable http proxy == 'http://PROXY IP:8080'
Trying PROXY IP:8080 ...
* Connected to PROXY IP (PROXY IP) port 8080
> GET http://identity-service.prelude.svc.cluster.local:8000/identity/healthcheck HTTP/1.1
> Host: identity-service.prelude.svc.cluster.local:8000
User-Agent: curl/8.7.1
Accept: */*
Proxy-Connection: Keep-Alive

* Request completely sent off
< HTTP/1.1 504 Gateway Timeout
< Content-Type: text/html
< Cache-Control: no-cache
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< Content-Security-Policy: frame-ancestors 'self'
< Content-Length: 30055

curl -v --noproxy '*' http://identity-service.prelude.svc.cluster.local:8000/identity/healthcheck

[ ~ ]# curl -v -- noproxy '*' http://identity-service.prelude.svc.cluster.local:8000/identity/healthcheck
* Host identity-service.prelude.svc.cluster.local:8000 was resolved.
* IPv6: (none)
* IPv4: ##.##.##.##
Trying ##.##.##.##:8000 ...
* Connected to identity-service.prelude.svc.cluster.local (##.##.##.##) port 8000
> GET /identity/healthcheck HTTP/1.1
> Host: identity-service.prelude. svc.cluster. local: 8000
> User-Agent: cur1/8.7.1
Accept: */*

* Request completely sent off
< HTTP/1.1 200 OK
< Vary: Origin
< Vary: Access-Control-Request-Method
< Vary: Access-Control-Request-Headers
< Content-Type: application/json
< Content-Length: 1408
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
1< Expires: 0
< X-Content-Type-Options: nosniff
< X-Frame-Options: DENY
< X-XSS-Protection: 0
< Referrer-Policy: no-referrer

If the first command fails (e.g., 504 Gateway Timeout) and the second command succeeds (HTTP 200 OK), this indicates that the issue is related to the proxy configuration.

To resolve this:

  • Open the /etc/profile file using a text editor (e.g., vi).
  • Locate and remove any manually configured proxy environment variables such as: http_proxy.https_proxy,ftp_proxy
  • Save and close the file.(wq!)
  • Restart the pod deployment process using the following command: /opt/scripts/deploy.sh
  • Verify that all pods in the prelude namespace are running and healthy: kubectl get pods -n prelude