Page Comparison

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.

Note that when you disable any virtual entities or interfaces on the CMP, the appliance excludes them from the vDiscovery job. In situations where the discovering member you select to perform vDiscovery jobs is disconnected from the Grid Master, the member continues to execute vDiscovery jobs based on the configured schedule. Newly discovered data replaces previously discovered data. The last set of discovered data is considered the most
up-to-date and is sent to the Grid Master when the member reconnects with the Grid Master.
When you configure vDiscovery jobs, you can enable the Infoblox NIOS appliance to automatically create DNS records for discovered IP addresses of VM instances that are served by the NIOS appliance. You can configure the appliance to add DNS records for specific DNS views associated with the network view defined for public and private IP addresses of VM instances served by the appliance. For more information about this feature, see Creating DNS Records for Newly Discovered VMs.
Before you configure and start a vDiscovery job, there are a few guidelines to consider. For more information, see
Guidelines for Configuring vDiscovery Jobs.

• 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.
• Cloud Extensible Attributes:To merge discovered cloud extensible attributes into NIOS, you must 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 Infoblox Installation Guide for vNIOS for Azure, 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 Government 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.

...

For OpenStack, complete the following:

...

1. From the Data Management tab, select the IPAM tab, then select vDiscovery -> Discovery Manager from the Toolbar; or from the Cloud tab, select vDiscovery -> Discovery Manager from the Toolbar.
2. The appliance displays the following information in the vDiscovery Job Manager:
• Name: The name of the vDiscovery job.
• Status: The current status of the vDiscovery job. Grid Manager displays an icon and descriptive information about the status. You can hover you mouse over the icon to view the current status, as follows:
Inactive
• Job created: The configured job
exists but is currently inactive
• has been created.
Idle
• Job starting:
Waiting for the next discovery schedule before the job is executed.
3. Ready: The job is in queue for execution based on the configured scheduled.
Running
• Starting the configured job.
• Job in progress: The job is being executed at the moment.
Discovery Task Completed
• Job completed: The job is completed successfully.
It will return to the Ready state for the next scheduled discovery time.
4. Discovery Task Completed failed: The job is completed but failed during the process. It will return to the Ready state for the next scheduled discovery time.
Canceled: The job was cancelled while it was being executed. It will return to the Ready state for the next scheduled discovery time
•  
• Cancelled: The job was cancelled while it was being executed. 
• Error while running job: The job has failed.
  If the "ERROR: PycURL error: (60, 'SSL certificate problem: unable to get local issuer certificate')" error message is displayed, it means that the certificate has expired or is invalid. You need to remove the expired or invalid certificate and upload a new one. If the error is displayed for an AWS vDiscovery job, download the certificates from https://www.amazontrust.com/repository/ and upload them. If it is displayed for an Azure vDiscovery job, follow the instructions in the Azure documentation to generate a root certificate for Azure and upload it to NIOS. For information about uploading certificates, see Managing Certificates.
• Schedule: Displays the configured schedule for the selected job.
• Public IP's Network View: The name of the network view to which discovered data for public IP addresses belongs.
• Private IP's Network View: The name of the network view to which discovered data for private IP addresses belongs.
• Member: The Grid member that performs the vDiscovery job.
• Last Run: The timestamp when the selected vDiscovery job was last performed.
• Comment: Comments added when the vDiscovery job was created.
5. Click the Action icon (shown as a gear in each row) next to a selected job, and you can do one of the following:
   • Edit: Modify the vDiscovery job settings in the vDiscovery Job Properties editor. The editor displays the following tabs: General, Endpoint, Network View, Data Consolidation, and Schedule. Click the tab that contains information you want to modify, and then modify the information as described in Configuring vDiscovery Jobs.
   • Delete: Remove the vDiscovery job from the list.
   • Start: Start vDiscovery now for the selected job.
     

     ---

     Note: The appliance might display an AMQP error when you first start a newly created vDiscovery job. This is due to the start-on-demand mechanism experiencing a delay in executing the job. Wait a few seconds and start the job again.
     

     ---

     Stop: Stop and terminate the vDiscovery job that is in progress. You cannot resume this discovery once you stop it. All discovered data remains intact in the database.
6. Click Close to close the vDiscovery Job Manager.