vCenter Connection Issues and DebuggingDescription Overview The goal of this article is to provide general knowledge about vCenter discovery. This article includes potential connection issues and also guides users with some debugging practices thus helping to sort out the issue at the earliest possible. MID Configuration and Credentials Debugging 1. Configuration of the MID Capabilities, IP Ranges, and Supported Applications appropriately. REASON(S): Capabilities play an important role during Cloud Schedule creation via Cloud Discovery Unification (a feature released in New York release). Default: ALL, Expected: ALL or VMwareIP Ranges plays a vital role in deciding whether to go ahead and discover the device using it's IP or not. Default: ALL, Expected: ALL or The user has to provide manually if anything specifics exist for the customer.Last but not least, Supported Applications for a MID is queried by certain applications like "Discovery", "Cloud Management", etc. Default: ALL, Expected: ALL or Application for which current MID shall be used for. 2. vCenter IP may or may not be reachable from the MID server. REASON(S): If the MID server cannot ping the vCenter IP then no point in doing the Discovery using that specific MID. Also, There can be various reasons why IP isn't reachable and few of them are Credentials, Ports, Firewall Settings, etc. DEBUGGING TIP(S): Perform ping against the target IP to see if we get the response or not.From the machine where the MID server is running, open any available browser and enter the target's IP in the URL bar directly thereby assuring the access via browser. If the connection is successful means the MID (deployed in the same machine) can be used for the discovery of the vCenter (Target IP).Once the access is confirmed, please provide the username and password (Login via the browser) to ensure credentials are valid and proper. 3. vCenter credentials, existing in the ServiceNow instance and which were created by the user, may or may not work. REASON(S): Its always better to check the credentials if they are working or not due to either user entering it wrong or credentials changed recently. DEBUGGING TIP(S): Perform the "Test Credential" action available in the credentials page by selection appropriate MID sever and port as 443. 4. Discovery IP Affinity/Credential Affinity too impacts the behaviour of the Discovery run. REASON(S): During the discovery run, In the classification stage, for a given IP, a check is made if any credential affinity available in the system and if we've then we try that credentials and then we decide to roll back for the credential iteration mechanism. so, if there exists wrong credential affinity then the Discovery might fail. DEBUGGING TIP(S): Clear the Credential Affinities i.e., go to the "dscy_credentials_affinity" table, and delete all the records whose IP address is the target vCenter IP. 5. The usefulness of the MID Configuration Parameters - "debug", "debug.logging". REASON(S): The above mentioned MID Configuration parameters enables logging of MID Server events and messages. It is not advised to use it often apart from the time when troubleshooting a problem because setting this parameter to true causes intensive logging on the MID Server, potentially using considerable disk space. DEBUGGING TIP(S): Enable the MID Server Configuration Parameters - "debug", "debug.logging" i.e., go to the MID server screen and click "New" button for the MID Server Configuration Parameter existing in the related list tab. VMWare Console Tools and Debugging 1. Making use of Object Browser. REASON(S): vCenter provides a window or a dot walking console known as - Object Browser. It can be used to check the data of the vCenter Objects like VMs, ESX, etc. so if the uses observes any discrepancy in the data retrieved for vCenter objects during the Discovery then it can be double-checked against this console. DEBUGGING TIP(S): Open the browser and in the URL provide the vCenter IP and in the home page, you'll find the option "Browse objects managed by vSphere". Access it and double check the data against the discovered. 2. vCenter support via "Browse vSphere REST APIs" REASON(S): As mentioned above, vCenter provides the window to check the data via Object Browser but along with that it has also provided an API explorer to try out the vCenter APIs on the fly and check the data retrieved so this also helps in double checking the data with the console and in the CMDB. DEBUGGING TIP(S): Open the browser and in the URL provide the vCenter IP and in the home page, you'll find the option "Browse vSphere REST APIs". Access it and double check the data against the discovered. Probes and Sensors Debugging 1. Port probes and the IP Services. REASON(S): As of part of Shazzam, the initial phase of the Discovery run, all port probes will be triggered and "vmapp" is one of them. It can be made Active/Inactive and applicable to Discovery type- "CIs" (Configuration Items). Default ports configured for the Port probe to scan are - "5480" and "9443". DEBUGGING TIP(S): In the Shazzam's ECC Queue, if the "vmapp" isn't noticed as a part of other port probes then check the flags "Active" and "CIs".If the customer desires to let the discovery look into additional ports then they can be added in the IP Services table and the Port Probe can be updated accordingly. 2. Which Probe is used - "VMWare - vCenter Datacenters" and "VMWare - vCenter". REASON(S): In the "vmapp" port probe, either "VMWare - vCenter Datacenters" or "VMWare - vCenter" will be mapped against the field - "Triggers probe". The "VMWare - vCenter Datacenters" Probe is used to get the information about a vCenter's datacenters. As a part of usual Probe-Sensor flow, the sensor will fire a probe for each type of vCenter object in each datacenter: VMs, explored by the "VMWare - vCenter VMs" probe, clusters, explored by the "VMWare - vCenter Clusters" probe, datastores, explored by the "VMWare - vCenter Datastores" probe, and networks, explored by the "VMWare - vCenter Networks" probe. As of the Istanbul release "VMWare - vCenter Datacenters" Probe has replaced the "VMWare - vCenter" probe for Discovery. So which probe is mapped against the port probe is important. DEBUGGING TIP(S): The "VMWare - vCenter Datacenters" Probe's implementation is located in a MID server script include named VMWarevCenterDatacentersProbe so using "ms.log" would help in logging the appropriate data during the discovery run. 3. Probe and the Script Versions. REASON(S): Whenever customisations done to any Probe(s) or Script Includes (System or Mid) either manually or via an update set then during on upgrade, those Probe(s) and Script(s) will not be updated so this might result in functionality loss and in bugs at times. DEBUGGING TIP(S): Go to the specific script or probe to which the customization is done, lets suppose probe modified is "VMWare - vCenter Datacenters". In the Related list, you'll find something called "Versions" and in it a column called "State" so if the instance is upgraded then newer versions will be noticed here but the "State" which is "Current" matter. If the customer wishes to restore the out of the box content then he/she may opt for reverting to the specific version by right-clicking and selecting the option "Revert to this version". 4. Probe Parameters to enable/disable VM NICs and Tags Probe. REASON(S): At the probe level, we provide the probe parameters - "disable_vm_nic_vdisks", "disable_vm_nic_vnics" and "disable_vm_tags_probe" out of the box for the "VMWare - vCenter VMs" Probe which can be enabled/disabled. If enabled the respective probes will be skipped after the execution fo the "VMWare - vCenter VMs" Sensor. DEBUGGING TIP(S): Turn the probe parameters to "false" if respective probes have to be triggered.