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.

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 the Creating DNS Records for Newly Discovered VMs section.
Before you configure and start a vDiscovery job, there are a few guidelines to consider.

Guidelines for Configuring vDiscovery Jobs

Consider the following guidelines before starting a vDiscovery job:

• 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 the information regarding the Error while running job status.

• 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 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 the Defining Policies for Handling Discovered Data.section. 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.

• 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 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.

• 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 the Defining Policies for Handling Discovered Data section.

• 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.

Creating a new vDiscovery Job

To create a new vDiscovery job, complete the following tasks:

1. 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.

2. Select a cloud platform for the vDiscovery, as described in the Selecting the Endpoint Server section.

3. Define network views for public and private IP addresses, as described in the Defining Network Views section.

4. Define policies for handling discovered data, as described in the Defining Policies for Handling Discovered Data section.

5. Optionally, you can enable NIOS to automatically create DNS records for newly discovered VMs using their IP addresses, as described in the  Creating DNS Records for Newly Discovered VMs section.

6. Schedule the vDiscovery job, as described in the Scheduling vDiscovery Jobs section.

Selecting the vDiscovery Member

To create a new or modify an existing vDiscovery job:

1. For a new vDiscovery job: From the Data Management tab, select the IPAM tab, then select vDiscovery -> New from the Toolbar; or from the Cloud tab, select vDiscovery -> New from the Toolbar.
   or
   To modify an existing job: From the Data Management tab, select the IPAM tab and click vDiscovery -> Discovery Manager from the Toolbar, or from the Cloud tab, select vDiscovery -> Discovery Manager from the Toolbar. In the vDiscovery Job Manager editor, click the Action icon next to a selected job and select Edit from the menu.

2. In step one of the vDiscovery Job wizard or in the General tab of the vDiscovery Job Properties editor, complete the following:

   • Job Name: Enter the job name for this vDiscovery. It might be helpful to use a name that is unique to this specific discovery if you plan to configure multiple vDiscovery jobs.
     Note that you cannot update the job name after the vDiscovery job is run for the first time.

   • Member: Click Select to choose the Grid member that will perform the vDiscovery job. If only a single member is active, the appliance name automatically appears here. When you select a Cloud Platform Appliance to perform vDiscovery, it communicates directly with the CMPs to obtain information that is not available through the provisioning process from the cloud adapter.

   • Comment: Enter information to describe this discovery.
     The new job will not execute until you have completed all configuration steps in the wizard. You will not be able to save this job until you have completed all job settings.

3. Click Next to select an endpoint server on which you want to perform the vDiscovery job, as described in the Selecting the Endpoint Server section, or save the configuration after you have modified data in this tab.

Selecting the Endpoint Server

1. In step two of the vDiscovery Job wizard, or on the Endpoint tab of the vDiscovery Job Properties editor, complete the following:
   Note:
   You might lose some discovered data if you modify any of the following parameters for an existing vDiscovery job. To avoid this, create a new vDiscovery job instead.

   • Server Type: Choose one of the following server types for this vDiscovery:

     • AWS: Collects information available for the AWS service endpoint. You can perform vDiscovery jobs through a proxy server in an AWS deployment, including Amazon Route 53. For more information, see Configuring Proxy Servers.

     • Azure: Collects information available for virtual entities in the specified VNets (Azure virtual networks) within the Microsoft Cloud.

     • OpenStack: When you select this server type, vDiscovery discovers network information stored in Neutron servers, VM instance information in Nova servers, and tenant or project information in Keystone servers.

     • VMware: Supports VMware vCenter and vSphere servers v5.0 and later. Collects information for all virtual entities running on the specified servers.

     • GCP: Collects information available for virtual entities in the specified GCP project.
       Depending on the server type you select, other options in this step change accordingly, as follows:
       
       For AWS, complete the following:

       • Service Endpoint: This is typically the regional service endpoint for the desired Amazon region.
         Example: ec2.us-west-1.amazonaws.com. For more information about AWS service endpoints, refer to the Infoblox Installation Guide for vNIOS for AWS, available on the Infoblox Support site. For a list of available AWS service endpoints, see  https://docs.aws.amazon.com/general/latest/gr/ec2-service.html 

       • Port: Enter the port you want to use for the vDiscovery job.

       • Protocol: The protocol used for AWS is always over SSL. AWS 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 AWS. 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.

       • Allow unsecured connection: This option is not applicable for AWS connection.

       • 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 use to pass role information to an EC2 instance when the instance is up and running. Select this option if you want to collect 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.

         • 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, available on the Infoblox Support site.
             For more information about instance profiles and IAM roles, refer to the AWS documentation.
             
             For Azure, complete the following:

           • Service Endpoint: 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.

           • 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.

           • Allow unsecured connection: This option is not applicable for Azure connection.

           • Client ID and Client Secret: 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. If you replace the client secret of the vDiscovery job with the existing client ID, you must restart the vDiscovery job for the changes to take effect. 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.
             - Updates to the root CAs of Azure services installed by Microsoft, can cause vDiscovery to fail. If vDiscovery fails with ERROR: PycURL error: (60, 'SSL certificate problem: unable to get local issuer certificate'):
             a. Download the DigiCert Global Root G2 Certificate from DigiCert Root Certificates.
             b. Upload the certificate to NIOS as described in Uploading CA Certificates.
             
             For OpenStack, complete the following:

           • Keystone Server IP: Enter the Keystone Server IP address.

           • Keystone Server Port: Select this checkbox If you are using Identity Endpoint for the connection, else enter the Keystone Server Port number.

           • Protocol: Select HTTP or HTTPS as the protocol. When you select HTTPS, you must upload the corresponding SSL CA certificate to the Grid in order for NIOS to communicate with OpenStack, as described in Managing Certificates.

           • Allow unsecured connection: This option is enabled when you use HTTPS as the protocol. When you select this, the appliance bypasses remote SSL certificate validation. Select this option only if security for the HTTPS connection between the discovering member and OpenStack is irrelevant, or if the connection is protected by other security measure besides TSL/SSL, such as an isolated private circuit.

           • Username and Password: Enter the username and password of the administrative account that was configured on OpenStack. When you configure the administrative account, ensure that you have authorization to obtain device information on a wide network basis.

           • Identity Version: Select the Keystone server identity service version from the drop-down list. You can select one of the following: Keystone v2 and Keystone v3. By default, Keystone v2 is selected.

           • Domain Name: Enter the domain name. This field is displayed only if you select Keystone v3 as the identity version.
             
             For VMware, complete the following:

           • Host: Enter the host name of the VMware server.

           • Port: Enter the port number of the VMware server.

           • Protocol: Select HTTP or HTTPS as the protocol. When you select HTTPS, you must upload the corresponding SSL CA certificate in order for NIOS to communicate with the VMware server, as described in Managing Certificates.

           • Allow unsecured connection: This option is enabled when you use HTTPS as the protocol. When you select this, the appliance bypasses remote SSL certificate validation. Select this option only if security for the HTTPS connection between the discovering member and VMware is irrelevant, or if the connection is protected by other security measure besides TSL/SSL, such as an isolated private circuit.

           • Username and Password: Enter the username and password of the administrative account that was configured on the specified VMware server. When you configure the administrative account, ensure that you have authorization to obtain device information.
             
             For GCP, complete the following:

           • Service Account File: Click Upload to select and upload the GCP service account file from your local disk. For more information about creating a GCP Service Account, see Creating GCP Service Account.
             Note:
             - NIOS 8.4.2 onward, each GCP vDiscovery job can utilize only one uniquely named service account file.
             - You can use the same service account file for different GCP vDiscovery jobs in earlier NIOS releases (such as 8.4.0, 8.4.1). However, deleting one vDiscovery job causes the other vDiscovery job with the same name to be stuck in "Job in Progress" state. It is recommended to use only one uniquely named service account file for each vDiscovery job.
             - You cannot edit an existing GCP vDiscovery job to upload a different service account file.
             - Auto created networks and VM instances having IP address of auto created networks cannot be discovered by GCP vDiscovery.

2. Click Next to define the network views to which discovered data belongs for both public and private IP addresses, as described in the Defining Network Views section.

Defining Network Views

To track overlapping networks and IP address ranges so you can discover specific networks and IP addresses, you can associate one or more network views with a Grid member or Cloud Platform Appliance that is selected to run the vDiscovery. You can then define a specific network view to which discovered data for public and private IP addresses belongs if the network view is not automatically detected. If no network view is specified, the default network view is used.
For Network Insight, when you discover networks using multiple discovery interfaces, you must configure network views so you can associate each discovery interface with an available network view. Note that on the same discovering member, each discovery interface must have a unique network view association.

1. For a new vDiscovery job: From the Data Management tab, select the IPAM tab, then select vDiscovery -> New from the Toolbar; or from the Cloud tab, select vDiscovery -> New from the Toolbar.
   or
   To modify an existing job: From the Data Management tab, select the IPAM tab and click vDiscovery -> Discovery Manager from the Toolbar, or from the Cloud tab, select vDiscovery -> Discovery Manager from the Toolbar. In the vDiscovery Job Manager editor, click the Action icon 

   Open

   

   next to a selected job and select Edit from the menu.

2. In step three of the vDiscovery Job wizard, or in the Network View tab of the vDiscovery Job Properties editor, complete the following:

   • Under the For Public IP Addresses section, select one of the following options the appliance uses if the network view is not automatically detected:

     • This Network View: From the drop-down list, specify a network view to which discovered data for public IP addresses belongs. The default is the default network view. You cannot create a new network view for this option.

     • The tenant's network view (if it does not exist, create a new one): Select this only if at least one cloud license is installed in the Grid. When you select this, discovered data for public IP addresses belongs to the tenant's network view. If the network view does not exist, the appliance creates it (only if a cloud license is installed in the Grid). The appliance uses tenant information of a discovered public IP address to create a new NIOS network view for all discovered objects (primarily subnets) for that tenant. For example, AWS tenants by default are associated with the user account's 12-digit account number (such as 2233441247523), which is the identifier for all objects that are created by that account in AWS. That tenant value becomes the identifier for the new network view as its objects are discovered by NIOS.

   • Under the For Private IP Addresses section, select one of the following options the appliance uses if the network view is not automatically detected:

     • This Network View: From the drop-down list, select a network view to specify a network view to which discovered data for private IP addresses belongs. The default is the default network view. You cannot create a new network view for this option.

     • The tenant's network view (if it does not exist, create a new one): Select this only if at least one Cloud Platform Appliance is active, or a cloud license is installed in the Grid. When you select this, discovered data for private IP addresses belongs to the tenant's network view. If the network view does not exist, the appliance creates it (only if a cloud license is installed in the Grid). The appliance uses tenant information of a discovered private IP address to create a new NIOS network view for all discovered objects (primarily subnets) for that tenant. For example, AWS tenants by default are associated with the user account's 12-digit account number (such as 2233441247523), which is the identifier for all objects that are created by that account in AWS. That tenant value becomes the identifier for the new network view as its objects are discovered by NIOS.

3. Click Next to configure how you want the appliance to handle discovered data, as described in the Defining Policies for Handling Discovered Data section.

Defining Policies for Handling Discovered Data

In this step, you define how the appliance handles discovered data.

1. For a new vDiscovery job: From the Data Management tab, select the IPAM tab, then select vDiscovery -> New from the Toolbar; or from the Cloud tab, select vDiscovery -> New from the Toolbar.
   or
   To modify an existing job: From the Data Management tab, select the IPAM tab and click vDiscovery -> Discovery Manager from the Toolbar, or from the Cloud tab, select vDiscovery -> Discovery Manager from the Toolbar. In the vDiscovery Job Manager editor, click the Action icon next to a selected job and select Edit from the menu.menu.

   Open

   

2. In step four of the vDiscovery Job wizard, or in the Data Consolidation tab of the vDiscovery Job Properties editor, complete the following:
   Under When inserting discovered into NIOS, select one or both of the following:

   • Merge the discovered data with existing data: When you select this checkbox, the appliance merges the discovered data with the existing data. It appends newly discovered data to existing data and preserves the existing data when there is no newly discovered data. This checkbox is selected by default.
     Note that if you clear this checkbox, the appliance replaces the existing data with the newly discovered data and if there are no newly discovered values for some fields, the appliance removes the existing values for these fields and the fields become empty.

   • Update discovered data for managed objects: Select this checkbox if you want the appliance to update discovered data for all corresponding NIOS objects (if they exist in NIOS). If you do not select this checkbox, the appliance updates only the discovered data for unmanaged objects. None of the managed data will be updated. This checkbox is selected by default.

   • For every newly discovered IP address, create: Select this checkbox to enable NIOS to automatically create or update DNS records for discovered network entities and VM instances. It does not include cloud adapters such as AWS or DDNS. This is applicable if the records were originally created by vDiscovery. If you select this checkbox, NIOS considers all records created in a zone as one and calculate it as one serial number change. For more information about this feature, see the Creating DNS Records for Newly Discovered VMs section.

     • Host: Select this to automatically create Host records for discovered entities.

     • A & PTR Record: Select this to automatically create A and PTR records for discovered entities. Note that the DNS zones and reverse-mapping zones to which the records belong must exist in NIOS before the vDiscovery job is executed. Otherwise, vDiscovery does not create the records.

     • The DNS name will be computed from the formula: Enter the formula that NIOS uses to create the DNS records for each discovered VM address. For example, if there are two IP addresses associated with a VM, NIOS creates two DNS records, or a host record with two IP addresses, depending on your configuration. You must use the syntax of ${parameter name} for the formula.

       For AWS, Azure, GCP, OpenStack, and VMware cloud platforms, this field supports the following parameters: vm_id, vm_name, discovered_name, tenant_id, tenant_name, subnet_id, subnet_name, network_id, network_name, vport_name, ip_address, ip_address_octet1 or 1, ip_address_octet2 or 2, ip_address_octet3 or 3, ip_address_octet4 or 4. Note that it does not support IPv6 addresses.

       For example, when you enter ${vm_name}.corpxyz.com and the discovered vm_name = XYZ, the DNS name for this IP becomes XYZ.corpxyz.com . When you enter ${discover_name} here and the discovered name for the IP is ip-172-31-1-64.us-west-1.compute.internal, the DNS name for this IP is ip-172-31-1-64.us-west-1.compute.internal.

   • Under Select the DNS view to which the DNS records are being added, select one or both of the following:

     • Use this DNS view for public IPs: Select this checkbox to add DNS records to a specific DNS view for public IPs. Select a DNS view from the drop-down list. If you do not select a DNS view, the DNS records are added to the default DNS view.

     • Use this DNS view for private IPs: Select this checkbox to add DNS records to a specific DNS view for private IPs. Select a DNS view from the drop-down list. If you do not select a DNS view, the DNS records are added to the default DNS view.
       If you are changing the DNS view, ensure that the Merge the discovered data with existing data checkbox is not selected.
       Note that the Use this DNS view for public IPs and Use this DNS view for private IPs fields will be disabled, if you select The tenant’s network view (if it does not exist, create a new one) option when you define the network views to which discovered data belongs for both public and private IP addresses, as described in the Defining Network Views section.

     • Under When discovered data is linked to managed data, select any combination of the following.
       Note that tenants and VMs are managed objects when they have NIOS objects, such as host records or fixed addresses, associated with them. Otherwise, they are unmanaged objects. The appliance always updates properties for all unmanaged objects.

   • Auto-consolidate on managed Tenant's properties: When you select this checkbox, the appliance updates properties with discovered data for managed tenants, as well as unmanaged tenants (NIOS always update unmanaged tenants). When you clear this checkbox, the appliance does not update discovered data for managed tenants. This checkbox is selected by default.

   • Auto-consolidate on managed Tenant's properties: When you select this checkbox, the appliance updates properties with discovered data for managed tenants, as well as unmanaged tenants (NIOS always update unmanaged tenants). When you clear this checkbox, the appliance does not update discovered data for managed tenants. This checkbox is selected by default.

   • Auto-consolidate managed VM's properties: When you select this checkbox, the appliance updates properties and extensible attributes with discovered data for managed VMs, as well as unmanaged tenants (NIOS always update unmanaged tenants). When you clear this checkbox, the appliance does not update discovered data for managed VMs. This checkbox is selected by default.

   • Auto-consolidate Cloud EAs on managed data: When you select this checkbox, NIOS updates discovered extensible attribute values for managed objects that contain cloud extensible attributes, only if a cloud license is installed in the Grid. This includes the update of the extensible attribute VM ID (which links the NIOS object to the VM) whenever a VM is added, updated or removed depending on the information collected. As a result, when a VM instance reuses an IP address or when a VM instance is deleted in the Cloud, the DNS Records or fixed address tied to that IP address are also updated, reflecting the new value of the VM instance ID. To update cloud extensible attributes for unmanaged objects, convert the objects to managed objects in NIOS. For more information, see Managing Unmanaged Data.
     Note that the extensible attribute VM ID is not updated if you do not enable the Auto-consolidate Cloud EAs on managed data checkbox, which leads to a conflict on that IP address. The NIOS object does not link to the same VM as the newly discovered IP. In such cases, you can use the Resolve Conflicts option to update either your NIOS objects or your discovered data. For information about resolving conflicts, see Resolving Conflicting Addresses.

3. Click Next to schedule this vDiscovery job and specify when the job should start, as described in the Scheduling vDiscovery Jobs section.

Creating DNS Records for Newly Discovered VMs

When you configure the policies NIOS uses to handle discovered data, you can enable NIOS to automatically create or update DNS records for discovered IP addresses of VM instances. NIOS automatically adds Host records or A and PTR records for the discovered VMs based on your configuration. You can also enter a formula that NIOS uses to create the DNS name for the discovered IP based on its VM parameters such as VM name or discovered name. By doing so, NIOS is able to discover public and private IP addresses by looking up the corresponding DNS names.
Discovered data includes IP addresses for the VMs and the associated information such as VM ID, VM Name, Tenant ID, and others. Note that corresponding zones must already exist in order for NIOS to add DNS records. Otherwise, NIOS does not add any DNS records and it logs a message in the syslog. For information about how to enable this feature, see Defining Policies for Handling Discovered Data.
NIOS automatically adds DNS records based on the following conditions:

• The corresponding DNS zones must already exist in the NIOS database. NIOS does not automatically create DNS zones for the records.

• To create a PTR record, the corresponding reverse-mapping zone must exist.

• A DNS zone cannot be associated with more than one DNS view. NIOS does not create DNS records for zones that are associated with multiple DNS views.

• NIOS adds new DNS records only if the VM name for the discovered IP address is available and there is no conflict with information about the associated network view.

On subsequent vDiscovery, if an IP for a VM is removed, the corresponding DNS records are removed. If the IP for a VM is changed, the IP address in the corresponding DNS record is changed accordingly. If the DNS record name template is changed, all the DNS recorded are replaced with the DNS records using the new template. All administrative actions for these changes are recorded in the Audit log. Summary of the changes are logged in the syslog.
The following table captures some scenarios about how vDiscovery handles various actions and what the outcome is for the information on the Cloud Platform appliance and in the NIOS database. All the scenarios in the table use the following template: $(discovered_name).

Scheduling vDiscovery Jobs

You can enable the appliance to start a vDiscovery immediately after you configure it, schedule it for a later date and time, or configure a recurring discovery based on a recurrence pattern. Note that all scheduled vDiscovery jobs are executed in queue based on the order of the schedule in the vDiscovery Job Manager. Therefore, a scheduled vDiscovery might be delayed if there are other jobs being executed before its scheduled start time.

1. For a new vDiscovery job: From the Data Management tab, select the IPAM tab, then select vDiscovery -> New from the Toolbar; or from the Cloud tab, select vDiscovery -> New from the Toolbar.
   or
   To modify an existing job: From the Data Management tab, select the IPAM tab and click vDiscovery -> Discovery Manager from the Toolbar, or from the Cloud tab, select vDiscovery -> Discovery Manager from the Toolbar. In the vDiscovery Job Manager editor, click the Action icon next to a selected job and select Edit from the menu.

2. In step five of the vDiscovery Job wizard, or in the Schedule tab of the vDiscovery Job Properties editor, complete the following:

   • Enable: To ensure that the scheduled vDiscovery job takes place, select this checkbox. When you upgrade from a previous version of NIOS, you must select this checkbox after the upgrade to ensure that the previously configured discovery tasks are being executed at the scheduled time.
     If you select Once, complete the following:

   • Choose a Start Date using the date picker.

   • Time Zone: Select the time zone for the scheduled time from the drop-down list.
     If you select Hourly, complete the following

     • Schedule every hour(s) at: Enter the number of hours between each update instance. You can enter a value from 1 to 24.

     • Minutes past the hour: Enter the number of minutes past the hour. For example, enter 5 if you want to schedule the rule update five minutes after the hour.

     • Time Zone: Select the time zone for the scheduled time from the drop-down list.

   If you select Daily, you can select either Every day or Every Weekday and then complete the following:

   • Time: Enter a time in hh:mm:ss AM/PM (hours:minutes:seconds AM or PM) format. You can also select a time from the drop-down list by clicking the time icon.

   • TimeZone: Select the time zone for the scheduled time from the drop-down list. If you select Weekly, complete the following:

   • Scheduleeveryweekon: Select any day of the week.

   • Time: Enter a time in hh:mm:ss AM/PM (hours:minutes:seconds AM or PM) format. You can also select a time from the drop-down list by clicking the time icon.

   • TimeZone: Select the time zone for the scheduled time from the drop-down list. If you select Monthly, complete the following:

   • Schedulethedayofthemonth: Enter the day of the month and the monthly interval. For example, to schedule the rule update on the first day after every 2 months, you can enter Day 1 every 2 month(s).

   • Time: Enter a time in hh:mm:ss AM/PM (hours:minutes:seconds AM or PM) format. You can also select a time from the drop-down list by clicking the time icon.

   • TimeZone: Select the time zone for the scheduled time from the drop-down list.

3. Save the vDiscovery job. The appliance lists all vDiscovery jobs in the vDiscovery Job Manager, from which you can manage jobs that have not been executed, including modifying selected jobs or deleting some. For more information about how to manage vDiscovery jobs, see the Managing vDiscovery Jobs section.

Managing vDiscovery Jobs

You can view all configured vDiscovery jobs or modify some of the settings for selected ones in the vDiscovery Job Manager. You can also add a new vDiscovery job by clicking the Add icon.
To view or modify vDiscovery jobs:

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:

     • Job created: The configured job has been created.

     • Job starting: Starting the configured job.

     • Job in progress: The job is being executed at the moment.

     • Job completed: The job is completed successfully. 

     • 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

3. Click the Action icon 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.

   • Delete: Remove the vDiscovery job from the list.

   • Start: Start vDiscovery now for the selected job.
     Note that 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.

4. Click Close to close the vDiscovery Job Manager.