Cloud Proxies becoming dysfunctional after upgrading to vRealize Operations 8.10
search cancel

Cloud Proxies becoming dysfunctional after upgrading to vRealize Operations 8.10

book

Article ID: 340241

calendar_today

Updated On:

Products

VMware Aria Suite

Issue/Introduction

Symptoms:
  • After upgrading to vRealize Operations 8.10 Cloud Proxy not completing the upgrade.
  • On Cloud Proxy, the command service httpd-north status shows that it failed to start with an error similar to:
Failed to resolve server name for 172.17.0.1 (check DNS) -- or specify an explicit ServerName
Oct 28 14:48:38 localhost httpd[8746]: (99)Cannot assign requested address: AH00072: make_sock: could not bind to address 172.17.0.1:443 


Environment

VMware vRealize Operations 8.10.x

Cause

While running custom adapters in containers, there were changes in /etc/httpd-north/httpd.conf to listen 172.17.0.1, which is docker's default gateway in case of a bridged network.
 

However, if the 172.17.X.X subnet is used, the docker service will use another subnet for the bridged network, e.g. 172.18.X.X (usually it increments the second byte).  As in httpd.conf it is hard coded to listen on 172.17.0.1, and the docker uses 172.18.0.1, it causes the could not bind to address 172.17.0.1:443 and fails.

Resolution

This issue is resolved in vRealize Operations 8.10.1 and later available at VMware Downloads.

Workaround:

In case of the mentioned issues with the mentioned symptoms, as a workaround, via ifconfig command should be checked the docker's gateway.

Example
docker0 Link encap:Ethernet HWaddr 07:12:ba:7e:2f:59
inet addr:172.18.0.1 Bcast:172.18.255.255 Mask:255.255.0.0


After, in /etc/httpd-north/httpd.conf file change all 172.17.0.1 appearances to 172.18.0.1 (IP shown in if config) and restart httpd-north service, i.e. service httpd-north restart.

Note: In case of a CP reboot, the mentioned manual changes will be reverted, so there will be a need to repeat the workaround.