Recently I've dealt with a few cases that are resulted due to the confusion or the knowledge gap regarding how the IP Discovery Schedule works after the Cloud Discovery when opted for, during the Cloud Discovery Schedule creation so the purpose of this article is to broadcast the knowledge to a wider audience to help out the user at the earliest time possible.

This article addresses customer concerns like:

• Script pointers for the IP information fetching for the IP discovery post-Cloud Discovery run
• How the IPs are considered for various Clouds
• Possible Situations when an IP Discovery Run can go to Cancelled state

Please note this article provides the data pointers which are sufficient enough to understand the configuration detail and not the in-depth walkthrough.

Script pointers for IP information fetching for the IP Discovery post-Cloud Discovery run

Once the Cloud Discovery is complete, the flow goes to the method "populateIPAddressList" method in the "CloudDiscoveryScheduleConfig" Script Include (sys_id=96891f3953f313007f3c48f153dc348b).

How the IPs are considered for various Clouds

We've separate flow for VMWare and others (AWS / Azure / GCP). As we dealing with the "Azure" Cloud, let me elaborate on the flow.

For Non-VMWare:

STEP 1: Query the VM Instance table whose STATE==On

STEP 2: Now get the respective "cmdb_ci_endpoint_vnic" entries for above VMs

**STEP 3: From the endpoint vnic information, get the NIC entries ("cmdb_ci_nic") and gather the IP

STEP 4: Once all the IPs are gathered for all the VMs, pass the same list to the IP Schedule dynamically.

For VMWare:

STEP 1: Query the vCenter Datastore table ("cmdb_ci_vcenter_datastore") based on the Datacenter selected

STEP 2: For each datastore, Query the associated VMs i.e., entries from the VMWare Instance table ("cmdb_ci_vm_instance")

**STEP 3: For each VM, Query the associated NIC ("cmdb_ci_nic") entries

STEP 4: From each filtered NIC entry, grab the ip_address

STEP 5: Once all the ip_addresses are gathered for all the VMs, pass the same list to the IP Schedule dynamically.

Please note that the above discovery works for private_ip starting "Quebec" and "Paris Patch5" onwards. The issue for private IPs is fixed via defect (PRB1433691).

With the above-mentioned detail, the IP addresses are fetched dynamically i.e., Once the Cloud Schedule finishes its execution, we take all the VMs that are discovered for the datacenters selected and IP addresses are gathered and provided to the IP Schedule for that run. This is how the addition of IP ranges of the VMs discovered via Cloud Discovery is automated. That's the reason when you open the respective IP Schedule from the Discovery Schedules list, the IP ranges will be empty, in that stand-alone/static platform UI screen.

Possible Situations when an IP Discovery Run can go to Cancelled state

USE CASE - 1: None of the VMs have the IPs thus no IPs are inputted for IP Schedule to scan/discover.

[POSSIBLE SOLUTION]: Have an IP associated, via the Cloud Console, for the VM(s) deployed and rerun the Cloud Discovery.

** USE CASE-1 is applicable only for Paris Patch 4 and earlier releases.

USE CASE - 2: IPs are available but not reachable by the MID/MID Cluster selected

[POSSIBLE SOLUTION]: Check where the MID is located and if the host is reachable via a simple "ping" test

USE CASE - 3: IPs available, Host is reachable to VM, but no Credentials available

[POSSIBLE SOLUTION]: Ensure the credentials are created in the SN Instance.

Please note, in this situation, the discovery status will stop at the Classification stage only

USE CASE - 4: IPs available, Host is reachable to VM, but ports aren't configured properly

[POSSIBLE SOLUTION]: Ensure the ports of the hosts are properly configured

Please note, in this situation, the discovery status will stop at the Shazzam stage only

USE CASE - 5: IPs of a few are considered but not others during the IP schedule

[POSSIBLE SOLUTION]: We do run the IP discovery only on the ACTIVE VMs i.e., Vm's state==on but not on Retired/Terminated VMs so please double-check.

Apart from the above use cases, please keep an eye on the ECC Queue(s) of the Discovery Status of IP Schedule because the IP schedule may fail for various reasons while the IPs of the VMs are still included in the Discovery Status. You can observe in the Payload of the ECC Queue entry whose topic is Shazzam / Classification Stage.