I recently came across an issue with creating subscribed VMware Content Libraries, and deploying templates from a Content Library.
An error similar to the one below, would be received when attempting to deploy a VM template or OVF from a Content Library, or an error related to connection issues when setting up a subscribed Content Library.
1Failed to deploy OVF Package. ThrowablePrxy.cause A general system error occurred: Transfer failed.
After some investigation, I came to see that vCenter was attempting to communicate with linked vCenter’s and hosts via the web proxy that was configured in the VAMI, when attempting to deploy an OVF from a Content Library or when trying to synchronise a library.
As I didn’t want this traffic going via the proxy as it is internal traffic, a support ticket was logged. It was advised to add proxy exceptions, or bypasses, to the proxy file located here on a vCenter Server Appliance:
1/etc/sysconfig/proxy
As this information isn’t something I managed to find documented publicly and support couldn’t provide me with anything as they were using internal documentation to assist, I thought I would write a quick post on it to help anyone facing the same issue!
Note: Always test in a non production environment and contact official support channels!
To begin reviewing and editing this file, you will need to SSH to the VCSA using the below command using your SSH tooling of choice.
1ssh root@vm-vcsa-01.smt-lab.local
Using the following cat command you can then view the file:
1cat /etc/sysconfig/proxy
Here is what the default file looks like with the HTTP and HTTPS options set:
1# Enable a generation of the proxy settings to the profile.
2# This setting allows to turn the proxy on and off while
3# preserving the particular proxy setup.
4#
5PROXY_ENABLED="no"
6
7# Some programs (e.g. wget) support proxies, if set in
8# the environment.
9# Example: HTTP_PROXY="http://proxy.provider.de:3128/"
10HTTP_PROXY="proxy.smt-lab.local"
11
12# Example: HTTPS_PROXY="https://proxy.provider.de:3128/"
13HTTPS_PROXY="proxy.smt-lab.local"
14
15# Example: FTP_PROXY="http://proxy.provider.de:3128/"
16FTP_PROXY=""
17
18# Example: GOPHER_PROXY="http://proxy.provider.de:3128/"
19GOPHER_PROXY=""
20
21# Example: SOCKS_PROXY="socks://proxy.example.com:8080"
22SOCKS_PROXY=""
23
24# Example: SOCKS5_SERVER="office-proxy.example.com:8881"
25SOCKS5_SERVER=""
26
27# Example: NO_PROXY="www.me.de, do.main, localhost"
28NO_PROXY="localhost, 127.0.0.1"
Take note of the section at the bottom, “NO_PROXY”. This is where we need to add the fqdn’s of any hosts and VCSA’s you wish to deploy to, or subscribe with. If however you don’t want to maintain this for each and every host, you can add a wild card:
1.*.domain.name
Note the ‘.’ at the beginning!
For instance, in my lab I would add the following entry to the NO_PROXY list:
1.*.smt-lab.local
To edit this we can use the VI editor (More info on using VI here.):
1vi /etc/sysconfig/proxy
Edit the file to include the FQDN’s or a wildcard, based on your requirements.
1# Example: NO_PROXY="www.me.de, do.main, localhost"
2NO_PROXY="localhost, 127.0.0.1, .*.smt-lab.local"
I found a short period of time is needed for this to take effect. Or you can reboot the VCSA to speed things along.
Following this, you will then be able to deploy or subscribe without issue!
Hope this has been useful and thanks for reading!
If you like my content, consider following me on Twitter so you don’t miss out!