A vDiscovery job retrieves information about virtual entities in cloud environments that are managed through CMPs such as VMware, OpenStack, and AWS. 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. For information about how to upload a certificate, see Managing Certificates.
...
- Discovered data through a specific vDiscovery job can only be modified or deleted 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. The old data is deleted only when you run the original discovery job again. 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 information see Error while running job.
- 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 information about Cloud Network Automation, see Deploying Cloud Network Automation.
- 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, see Managing Unmanaged 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 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.
- 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. For information about auto-consolidation options, see Defining Policies for Handling Discovered Data.
- 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 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 information about how to remove these objects, see Clearing Unmanaged Data and Clearing 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.
...
- ServiceEndpoint: This is the service endpoint for the desired VNet in the Microsoft Cloud. For more information about Azure service endpoints, refer to the InfobloxInstallationGuideforvNIOSforAzure, available on the Infoblox Support site Infoblox Installation Guide for vNIOS for Azure.
- Port: Enter the port you want to use for the vDiscovery job.
- Protocol: The protocol used for Azure is always over SSL. Azure provides certificates that is linked to the CA. By default, this certificate is embedded in NIOS and used as a reference for the CA when connecting to Azure. You can also upload a new certificate as described in Managing Certificates. If you upload a new certificate, the embedded certificate will be overwritten by the new one.
- Allowunsecuredconnection: This option is not applicable for Azure connection.
- ClientID and ClientSecret: Enter the client ID and client secret for the Microsoft Azure account. When you configure the client account, ensure that you have authorization to obtain device information on a wide network basis. For information about Azure client ID and client secret, refer to Microsoft Azure documentation.
...
Note: Azure Azure Government Cloud uses different Service Endpoints for Cloud uses different service endpoints for its services. For more information about Azure service endpoints, refer to the Infoblox Installation Guide for vNIOS for Azure, available on the Infoblox Support site.
...
For OpenStack, complete the following:
...