A vDiscovery job retrieves information about virtual entities in cloud environments that are managed through cloud management platforms (CMPs) such as VMware, OpenStack, AWS, Azure, and GCP. The current vDiscovery feature supports tenants, networks, and compute VMs only. It does not support data that is retrieved from load balancer networks, load balancer VMs, Kubernetes platform VMs, application gateways, service VMs, SQL VMs, or any other VMs that are created using cloud services such as Kubernetes service or analytics service, where the IPAM is handled by the respective orchestration engines of the cloud provider.
Note that if the vDiscovery job retrieves unsupported data from AWS, Azure, or GCP, then it impacts the performance of the vDiscovery process.
You must first select a member to run the vDiscovery job. To ensure that the job is executed properly, verify the connection between the discovering member and the discovered endpoint. If you select HTTPS as the protocol for communication, you must upload either an SSL CA (Certified Authority) certificate or a self-signed SSL certificate to the Grid. If the certificate has expired, ensure that you delete the expired certificate and then upload a new certificate. For more information about uploading certificates, see Managing Certificates.
...
Discovered data through a specific vDiscovery job can only be modified by the same vDiscovery job. If you create a different vDiscovery job to discover the same network and some of the information in the network has changed, the newly discovered data and the original discovered data (now old data) co-exist in the database. For example, vDiscovery job "AWSJob1" discovers IP address 10.0.0.11 with VM name "corpxyz." This discovered data is stored in the NIOS database. You subsequently create a new vDiscovery Job "AWSJob2" to discover the same IP but now the VM name has been changed to "corp200." The discovered VM name for 10.0.0.11 is now "corp200." Both VM names "corpxyz" and "corp200" exit in the database until you run AWSJob1 again, and "corpxyz" will be removed from the database.
If the "ERROR: PycURL" error is displayed when you run a vDiscovery job, it is possible that the cloud provider has updated their certificate. You need to download the latest certificate from the cloud provider website and upload it to NIOS. For example, for AWS, download the certificates from https://www.amazontrust.com/repository/. For more information see Error while running job below.
Cloud Extensible Attributes:
To merge discovered cloud extensible attributes into NIOS, you must have at least one cloud license (Cloud Network Automation or Cloud Platform) installed in the Grid. However, if you want to view the discovered cloud data in the Cloud tab of Grid Manager, you must have the Cloud Network Automation license installed on the Grid Master. Otherwise, even though the cloud data is merged into the NIOS database, you cannot view it through Grid Manager. For more information about Cloud Network Automation, see Deploying Cloud Automation Network.
To synchronize tags discovered in AWS or Azure object instances as extensible attributes in NIOS, manually create a corresponding extensible attribute in NIOS for each AWS or Azure tag. For more information, see the Extensible Attributes for Tags in AWS and Azure section in the Extensible Attributes for Tags in Cloud Objects topic.
In addition, ensure that you select the auto consolidation options when defining policies for how to handle the discovered cloud extensible attributes, as described in Defining Policies for Handling Discovered Data. Note that only cloud extensible attributes for managed objects are updated. To update cloud extensible attributes for unmanaged objects, you can first convert the unmanaged objects to managed objects. For more information about Managing Unmanaged Data, see Managing Discovered Data.
When you select VMware as the endpoint server for the vDiscovery job, consider the following:
Typically, vDiscovery does not collect data about "Network" from VMware vSphere and vCenter servers. Therefore, you must first define a network in NIOS in order to discover IPs in the network.
However, if you use vCenter to define a network as "IP_Pool," which contains the CIDR for the network, vDiscovery is able to collect this data and translate it into a network. NIOS then creates the network and updates it with corresponding cloud extensible attributes.
If a VMware ESXi server cannot find the IP addresses associated with a VM, vDiscovery ignores the VM and may return a syslog error message "VM: <serial number> (name: <name>) has been ignored". To fix this issue, install VMware Tools on the VM instance.
If you use an AWS Elastic IP address and select AWS as the endpoint server for the vDiscovery job, you must first manually create the network in NIOS before launching the vDiscovery job in order to discover the Elastic IP.
Properties of a VM address (such as interface name, network encapsulation, segmentation, VLAN ID) can only be updated through cloud extensible attributes, depending on the policies you select when configuring a vDiscovery task. To properly integrate discovered VM address properties with NIOS, ensure that you do one of the following:
Define cloud extensible attributes for these properties through your cloud adapter. For information about how to define cloud extensible attributes, refer to the Quick Start Guide for your cloud adapter, available on the Support site.
Convert unmanaged VM addresses to managed so discovered cloud extensible attributes can be merged into NIOS. For more information, see Converting Unmanaged Data.
Unmanaged objects in NIOS are updated with newly discovered data and stay as unmanaged objects. Managed objects in NIOS that have no conflict with newly discovered data are updated and stay as managed objects.
If there is conflict between managed objects in NIOS and newly discovered data, the managed objects are not updated and stay as managed objects while a conflict is flagged for these objects. For more information about how to resolve the conflict, see Resolving Conflicting Addresses.
NIOS does not automatically remove unmanaged objects that were discovered in the past but do not exist in current discoveries. This can happen if your network topology has changed in between discoveries. You can manually remove these unmanaged objects if you do not want them to stay in the database. For more information about how to remove these objects, see Clearing Unmanaged DataandClearing Discovered Data.
For delegated DNS and DHCP objects, changes are handled by the delegated Cloud Platform Appliance based on the scope of delegation. Discovered data is still updated by the Grid Master.
You cannot delete discovered tenants, networks, and VMs through the vDiscovery process. Conflict management is not supported for these objects. Note the following:
Discovered subnets are always created as managed networks. Pools of IP addresses (public pools) when discovered are translated into managed networks. Any discovered public IP that is not linked to a pool is marked as unmanaged data in NIOS, unless there is a corresponding network already created.
Tenant and VM information is merged into NIOS through cloud extensible attributes, only if there is a cloud license (Cloud Network Automation or Cloud Platform) installed in the Grid. Properties for unmanaged tenants and VMs are always updated while properties for managed tenants and VMs are updated only if auto-consolidation of tenant and VM information is selected when you configure the vDiscovery job.
If a newly created vDiscovery job fails, first ensure that no control characters or permanently undefined Unicode characters such as non-breaking space, non-breaking hyphen, and so on are present in the job name.
...