The short of it:

  • vRealize Suite Lifecycle Manager (vRSLCM/LCM) can use a proxy to get to MyVMware and download patches and binaries, this works fine
  • But LCM content management, is largely backed by built-in vRO workflows, and as of current version (2.0, patch3), these can NOT work with a proxy.

As an aside: While the UI/’my vmware’ portion of LCM works fine through a proxy, the current documentation does not tell you the complete picture of what its trying to connect to. For a better overview, check out this excellent blog post by Mischa Buijs.

The issue with the content management, I ran into this when attempting to use public gitlab.com as a GIT endpoint, behind a proxy.
I have a different LCM instance, that is able to get to Internet directly, and there using gitlab.com as an endpoint works just fine.

When you try get content management to work behind a proxy, the connection test will fail as follows:

Could not connect to endpoint gitlab.com. Connection Test Failure. Failed to find a repository with your account. 

While vRO is part of the Lifecycle Manager appliance, it is, by default, meant to be ‘hidden’. Its used to facilitate work by the LCM itself, but is not meant for customization by end users.

However, despite that, the LCM team have given instructions on how to open the Firewall, to allow access to the vRO welcome page. On port 8281. This is mainly for vRO workflow troubleshooting purposes.

https://docs.vmware.com/en/VMware-vRealize-Suite-Lifecycle-Manager/2018/com.vmware.vrsuite.lcm.20.doc/GUID-2950711E-0A98-4281-92B7-6269C95A1634.html

Log into vRO with the default vcologin as mentioned in the vRO appliance documentation: vcoadmin/vcoadmin

There you will find all the custom vRO workflows that are being used by the LCM content management. This vRO package is internally called ‘blackstone’. If you lookup the Gitlab Test connection workflow, you will find the connect attempts. They produce a default log similar to the following:

[2019-02-07 16:33:05.212] [D] addRESTHost name=6f808dd8-74d0-489e-bfa8-e927e8dfd5c8 url=https://gitlab.com/api/v4/groups/cam_testing/projects/?per_page=1000
[2019-02-07 16:33:05.561] [I] error: InternalError: Cannot execute the request: ; Connection refused (Connection refused) (Dynamic Script Module name : restHttpRequest#67)
[2019-02-07 16:33:05.576] [I] undefined

Here you can see the actual error is ‘connection refused’. Its not even getting to Gitlab.

One of the workarounds I tried, was to set up PhotonOS with a proxy. This caused PhotonOS to be able to connect to Gitlab, but unfortunately had no effect on vRO

If you use vRO built in REST module, you can add your own proxy settings directly. This can confirm vRO can get through the proxy, IF it was supplied with the right proxy settings. But that won’t help you unfortunately, as you cant influence how the LCM interface starts vRO workflows under the hood. (or at least, I cannot figure out how)

At least its an extra way to verify the issue is indeed a proxy and not something else.

I reached out to VMware LCM team, and it was confirmed that its not supported currently, but they are adding it to the roadmap. Until that time, if you need to go through a proxy, you may need to organize an exemption for your LCM instance.

The original article was posted on: thefluffyadmin.net

Related articles

  • Cloud Native
  • Application Navigator
  • Kubernetes Platform
  • Digital Workspace
  • Cloud Infrastructure
  • ITTS (IT Transformation Services)
  • Managed Security Operations
  • Multi-Cloud Platform
  • Backup & Disaster Recovery
Visit our knowledge hub
Visit our knowledge hub
ITQ

Let's talk!

Knowledge is key for our existence. This knowledge we use for disruptive innovation and changing organizations. Are you ready for change?

"*" indicates required fields

First name*
Last name*
Hidden