Summary: What challenges are seen when VMware Integration fails to function as expected? This article explores the main reasons for these issues, providing insight into common error scenarios and troubleshooting approaches.
Problem
“UNKNOWN HOST” Error During VMware Integration
One of the most frequently encountered problems during the process of integrating VMware with Dynatrace is the appearance of the “UNKNOWN HOST” error. This error signifies that the Environment ActiveGate is unable to establish a connection with the vCenter server. In such cases, the ActiveGate cannot reach the vCenter, failing the integration process.
Troubleshooting steps
- Pre-requisite: Verifying Connectivity Between the Environment ActiveGate and vCenter.
Before proceeding with the VMware integration setup, ensure that your Environment ActiveGate can successfully communicate with the vCenter server on port 443. This is particularly important because the connection is established externally, outside the Dynatrace Cluster (whether SaaS or Managed). Verifying this connectivity upfront helps avoid integration failures caused by network restrictions or misconfigurations. -
Determine whether a proxy is configured between the Environment ActiveGate and the vCenter server. Proxy settings can significantly impact connectivity and may be the source of integration failures if not properly configured. To accurately assess and resolve any proxy-related concerns, it is crucial to refer to the official documentation that outlines the requirements for establishing a connection through a proxy. The documentation provides comprehensive guidance on the necessary configurations and considerations when connecting ActiveGate to vCenter via a proxy.
- If all the above configurations have been thoroughly checked and updated, but you're still unable to establish a connection, the next step is to execute the following curl commands. Running these commands will help identify any missing or misconfigured components in the setup. By observing the output, you can pinpoint whether the issue lies with the server's response, network elements, or any other component involved in the connection process.
A) Validating vCenter SOAP Endpoints and WSDL from ActiveGate
To ensure proper connectivity between the ActiveGate and vCenter, it is essential to validate the SOAP endpoints and WSDL accessibility from the ActiveGate. The ActiveGate interacts with vCenter using SOAP calls directed at the /sdk path. It is important to note that even if vCenter appears reachable at the TCP level, failures can still occur at the SOAP or WSDL layer. These failures may be the result of insufficient permissions, issues with the service state, or interference from proxies.
The connection process fundamentally involves fetching the vimService.wsdl file to verify if the endpoint is responding as expected. This step confirms that there are no “localhost” misaddressing problems and that the WSDL is not being blocked. Successful retrieval of the WSDL file ensures that the SOAP service is correctly exposed and accessible from the ActiveGate.
curl -k https://<vcenter ip>/sdk/vimService.wsdl -o /tmp/vimService.wsdl If the output of the curl command shows that the client never received any bytes from https://172.x.x.x/sdk/vimService.wsdl, this is a strong indication of a server-side stall or a problem within the network path. This means that while the connection was accepted at the transport layer, no actual data was transferred to the client (ActiveGate). This points to issues like server-side stalling or certain network elements blocking or dropping the application data after the handshake has been completed
curl -k https://172.x.x.x/sdk/vimService.wsdl -o /tmp/vimService.wsdl
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:48 --:--:-- 0^C
B) To further investigate the connection issue, the next step is to verify whether the TLS handshake is successfully occurring and to capture the associated timing using two commands.
- Command 1: time nc -vz 172.x.x.x 443
- Command 2: openssl s_client -connect 172.x.x.x:443 -servername 172.x.x.x -showcerts -brief
These commands together facilitate a comprehensive check, confirming a complete handshake, displaying the server certificates, and helping to identify whether the stall occurs after the TLS handshake (potentially at the HTTP layer on the vCenter reverse proxy or the SOAP service) or before it. If the handshake does not complete or is reset, it is likely indicative of an issue with an intermediary device such as a proxy, intrusion prevention system (IPS), SSL inspection mechanism, or a TLS protocol mismatch.
Example:
time nc -vz 172.x.x.x 443
Ncat: Version 7.91 ( https://nmap.org/ncat )
Ncat: Connected to 172.x.x.x:443.
Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.
real 0m0.012s
user 0m0.007s
sys 0m0.004s
openssl s_client -connect 172.x.x.x:443 -servername 172.x.x.x
Connecting to 172.x.x.x
CONNECTED(00000003)
The output above demonstrates that both the ActiveGate and the shell can establish a connection with vCenter. However, it is also evident that when attempting to access the /sdk/vimService.wsdl endpoint, no data is being returned.
- vCenter Reverse Proxy or SOAP Service Issues: The reverse proxy or SOAP service within vCenter may be experiencing heavy load or may be unresponsive.
- Security Device Interference: A security device could be intercepting and buffering the request, preventing data from being returned.
- vCenter Service Misconfiguration: Misconfiguration within the vCenter service itself could be responsible for the observed issue.
C) Next, we will run Verbose Curl to confirm where it gets stuck
curl -v -k --connect-timeout 10 --max-time 60 https://172.x.x.x/sdk/vimService.wsdl -o /tmp/vimService.wsdl
Example output:
curl -v -k --connect-timeout 10 --max-time 60 https://172.x.x.x/sdk/vimService.wsdl -o /tmp/vimService.wsdl
* Trying 172.x.x.x:443...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 172.x.x.x (172.x.x.x) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
0 0 0 0 0 0 0 0 --:--:-- 0:00:09 --:--:-- 0* Operation timed out after 10000 milliseconds with 0 out of 0 bytes received
0 0 0 0 0 0 0 0 --:--:-- 0:00:10 --:--:-- 0
* Closing connection 0
curl: (28) Operation timed out after 10000 milliseconds with 0 out of 0 bytes received
The output provided demonstrates that the connection process stalls before the TLS handshake is completed. Specifically, the process does not advance beyond the "Client hello" stage, indicating that the handshake is not being finalized.
Given that the TCP connection appears to be functioning correctly, as confirmed by a successful nc (netcat) test, it can be concluded that the underlying network connectivity is not the issue. The fact that the server does not respond after the initial SYN/ACK packet exchange further confirms that TCP is operating as expected.
This suggests that the problem does not originate from the Dynatrace or ActiveGate configuration. Instead, the root cause points towards a network-related issue or a problem with the vCenter SSL listener. Specifically, the SSL listener on the vCenter side may fail to send the necessary data back to the ActiveGate, resulting in an incomplete TLS handshake.
4. Another approach to verify whether the connection is functioning as expected is to use the SOAP UI tool. This application provides a straightforward way to determine if connectivity to the vCenter is established. For example, by installing SoapUI locally on your system or server, you can attempt to connect to vCenter using the same URL (https://172.x.x.x/sdk/vimService.wsdl). Once connected, you may execute typical service operations, such as QueryHostsCountVMs, which triggers the CreateFilter operation within the vimService. This method allows you to observe whether the connection is successful and whether operations can be performed.
What's next
- Check the ActiveGate logs for any error messages related to the connection. You can also check if the Credentials are correct or not.
- If you're still facing issues, open a support ticket with the following details
- ActiveGate support archive
- Tenant link with VCenter information
- Curl outputs as shared above
What to read next:
VMare WSphere monitoring
ActiveGate proxy setting scenarios