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.
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.
...
Name the new job and select a member to perform the vDiscovery, as described in the Selecting the vDiscovery Member section. Do not use control characters or undefined Unicode characters in your job name.
Select a cloud platform for the vDiscovery, as described in the SelectingtheEndpointServer section.
Define network views for public and private IP addresses, as described in the Defining Network Views section.
Define policies for handling discovered data, as described in the Defining Policiesfor HandlingDiscoveredData section.
Optionally, you can enable NIOS to automatically create DNS records for newly discovered VMs using their IP addresses, as described in theCreating DNS Records for Newly Discovered VMs section below.
Schedule the vDiscovery job, as described in the in Scheduling vDiscovery Jobs section below.
...
GovCloud: Select the option if the region in which you want to run vDiscovery is on a Gov cloud. This option cannot be edited once the vDiscovery job is created. It can be defined only when creating a new job.
Credentials: Select the method you want to use to authenticate the connection between the Grid member and AWS for discovery jobs. You can select one of the following:
Use instance profile: An instance profile is a container for an IAM role that you can use to pass the role information to an EC2 instance when the instance is up and running. Select this option if you want to collect the information from AWS by waiving a user's credentials and using configuration of a predefined IAM role to get a temporary token that allows API calls. Note that you must first configure the option for "instance profile" in AWS, define an IAM role in the instance profile, and then set permissions for this role before you can select this option. Otherwise, this option is disabled. When you select this, you do not need to provide user credentials. For more information about instance profiles and IAM roles, refer to the AWS documentation.
Use IAM credential: Select this if you want to authenticate by using IAM roles to grant secure access to AWS resources from your EC2 instances. Click Select to choose the IAM role and use its credentials to access AWS resources from your EC2 instances when they are up and running.
Access Key ID and Secret Access Key: Enter the Access Key ID and Secret Access Key for the AWS service endpoint. This is the secret key pair for the administrator account that executes the discovery job. For more information, refer to the Infoblox Installation Guide for vNIOS for AWS.
Regions: From the list of regions that are retrieved from AWS and saved in the NIOS database, select the regions in which the vDiscovery job must run. You can run vDiscovery on one or multiple regions of an account. To know if any new regions are added to the displayed list, run the set refresh_supported_cloud_regions command.
To select a region, click a region in the Available list and click the > arrow to move it to the Selected list. Select multiple fields by using SHIFT-click or CTRL-click.
If you enabled the GovCloud option, then regions that are set up only on AWS Gov cloud are displayed.
Multiple Account Sync If you want data to be discovered from multiple AWS accounts of an organization, select this option and configure the following settings:
Role ARN: Enter the ARN (Amazon Resource Name) of the role that you configured in your AWS management account.
Multi Account Options: You can set the data of all child accounts of an AWS organization to be synchronized or specify the accounts from which data must be synchronized.
Select one of the following options:Discover Child Accounts: Select this option if you want a sync task to discover and synchronize data from all child accounts of an AWS organization to which the specified role ARN belongs.
Add or Upload Child Accounts: Select this option to specify the list of child accounts that a sync task must discover and synchronize data from. To define the list, do one of the following:
Note that the multi-account sync option synchronizes data from the specified child accounts and also their parent AWS Management account for which you specified the role ARN.Upload a CSV file:
Click the Import icon.
In the Upload dialog box, click Select to browse for the CSV file containing the list of account IDs of child accounts you want to add.
Select the file and click Open.
Click Upload to upload the file, and then click Close.
Manually specify the account IDs of child accounts from which resources must be discovered and synchronized. Repeat the following steps for every account that you want to add:
Click the Add icon to add a row in the Account IDs table.
Click the new row and specify the account ID of a child account.
...