Red Hat Discovery is an agentless inspection and reporting tool that identifies physical and virtual systems on a network, their operating systems, configuration data, and installed Red Hat products. Use these findings to understand and manage your subscription usage and IT inventory.

The ability to inspect the software and systems that are running on your network improves your ability to understand and report on your subscription usage. Ultimately, this inspection and reporting process is part of the larger system administration task of managing your inventories.

Red Hat Discovery requires the configuration of two basic structures to access IT resources and run the inspection process. A credential contains user access data, such as the username and password or Secure Shell (SSH) key. It provides sufficient authority to run the inspection process on a particular source. A source contains data about a single asset or multiple assets that are to be inspected.

These assets can be physical machines, virtual machines, or containers, identified as hostnames, IP addresses, IP ranges, or subnets. These assets can also be a systems management solution such as vCenter Server or Red Hat Satellite Server, or can be clusters deployed on Red Hat OpenShift Container Platform.

You can save multiple credentials and sources to use with Discovery in various combinations as you run inspection processes, or scans. When you have completed a scan, you can access these facts in the output as a collection of formatted data, or report, to review the results.

By default, the credentials and sources that are created during the use of Red Hat Discovery are encrypted in a database. The values are encrypted with AES-256 encryption. They are decrypted when the Red Hat Discovery server runs a scan with the use of a vault password to access the encrypted values that are stored in the database.

Red Hat Discovery is an agentless inspection tool, so there is no need to install the tool on every source that is to be inspected. However, the system that Discovery is installed on must have access to the systems to be discovered and inspected.

Red Hat Discovery detects specific Red Hat products. For each version or release, the earliest supported version is listed, with later releases indicated as applicable.

If a product has changed names recently so that you might be more familiar with the current name for that product, that name is provided as additional information. No later version is implied by the inclusion of a newer product name unless specific versions of that product are also listed.

Red Hat Enterprise Linux

Red Hat Application Services products (formerly Red Hat Middleware)

Red Hat Ansible Automation Platform

Red Hat OpenShift Container Platform

Red Hat Advanced Cluster Security for Kubernetes

Red Hat Advanced Cluster Management for Kubernetes

Red Hat Discovery helps you discover your Red Hat product inventory across complex networks. Work with a Red Hat Solution Architect (SA) or Technical Account Manager (TAM) to interpret the generated reports.

You can also work with the Subscription Education and Awareness Program (SEAP) for analysis and assistance.

Although you can install and use Discovery independently and then generate and view report data, the Discovery documentation does not provide any information to help you interpret report results. Red Hat Support can provide some basic assistance related to installation and usage of Discovery. However, the support team does not provide any assistance to help you understand the reports.

The Discovery tool does not automatically share data directly with Red Hat. Instead, you choose whether to prepare and send report data to Red Hat for ingestion by Red Hat tools and services. You can use the Discovery tool locally to scan your network for the Red Hat products that Discovery currently supports and then use the generated reports for your own internal purposes.

Log in to the Discovery user interface by using the server IP address, port number, and administrator credentials. Contact your Discovery administrator if you do not have this information.

Log out of the Discovery user interface to end your session and secure access to the server.

To log in to the Discovery command line interface, you need the username and password for the Discovery server administrator. If you do not have this information, contact the administrator who installed the Discovery server.

The login command retrieves a token that is used for authentication with subsequent command line interface commands. That token is removed when you log out of the server, and expires daily.

The command to log out of the server removes the token that was created when you logged in to the server. This token also expires daily.

Define network sources to identify the hosts, Internet Protocol (IP) addresses, and IP ranges that Discovery scans across your network.

Create network credentials to authenticate Discovery scans against remote systems in your network by using Secure Shell (SSH)-based authentication.

To run a scan, you must configure data for two basic structures: sources and credentials. The type of source that you are going to inspect during the scan determines the type of data that is required for both source and credential configuration.

A source contains a single asset or a set of multiple assets that are to be inspected during the scan. You can configure any of the following types of sources:

When you are working with network sources, you determine how many individual assets you should group within a single source. Currently, you can add multiple assets to a source only for network sources. The following list contains some of the other factors that you should consider when you are adding sources:

A credential contains data such as the username and password or SSH key of a user with sufficient authority to run the scan on all or part of the assets in that source. As with sources, credentials are configured as the network, vCenter, satellite, OpenShift, Red Hat Ansible Automation Platform, or RHACS type. A network source might require multiple network credentials to access all assets in a broad IP range. Conversely, a vCenter or satellite source typically uses a single credential to access a particular system management solution server. An OpenShift, Red Hat Ansible Automation Platform, or RHACS source uses a single credential to access a single cluster.

You can add new sources from the Sources view and you can add new credentials from the Credentials view. You can also add new or select previously existing credentials during source creation. It is during source creation that you associate a credential directly with a source.

Because sources and credentials must have matching types, any credential that you add during source creation shares the same type as the source. If you want to use an existing credential during source creation, the list of available credentials contains only credentials of the same type. For example, during network source creation, only network credentials are available for selection.

Network scans use Secure Shell (SSH) through Red Hat Ansible Automation Platform to inspect remote systems. Configure network credentials with either a username and password or a username and SSH keyfile pair, optionally including a passphrase.

Also during network credential configuration, you can enable a become method. The become method is used during a scan to elevate privileges. These elevated privileges are needed to run commands and obtain data on the systems that you are scanning.

During network scans, Discovery runs commands on remote systems using the credentials you provide. Some commands require elevated privileges through sudo to gather complete facts for your report.

Although it is possible to run a scan for a network source without elevated privileges, the results of that scan are incomplete. The incomplete results from the network scan affect the quality of the generated report for the scan.

The following information lists the commands that Discovery runs on remote hosts during a network scan. It includes the basic commands that can run without elevated privileges. It also lists the commands that must run with elevated privileges to gather the most accurate and complete information for the report.

Define satellite sources to identify Satellite Server instances and their managed hosts for Discovery scanning.

Create satellite credentials to authenticate Discovery scans against Satellite Server instances.

To run a scan, you must configure data for two basic structures: sources and credentials. The type of source that you are going to inspect during the scan determines the type of data that is required for both source and credential configuration.

A source contains a single asset or a set of multiple assets that are to be inspected during the scan. You can configure any of the following types of sources:

When you are working with network sources, you determine how many individual assets you should group within a single source. Currently, you can add multiple assets to a source only for network sources. The following list contains some of the other factors that you should consider when you are adding sources:

A credential contains data such as the username and password or SSH key of a user with sufficient authority to run the scan on all or part of the assets in that source. As with sources, credentials are configured as the network, vCenter, satellite, OpenShift, Red Hat Ansible Automation Platform, or RHACS type. A network source might require multiple network credentials to access all assets in a broad IP range. Conversely, a vCenter or satellite source typically uses a single credential to access a particular system management solution server. An OpenShift, Red Hat Ansible Automation Platform, or RHACS source uses a single credential to access a single cluster.

You can add new sources from the Sources view and you can add new credentials from the Credentials view. You can also add new or select previously existing credentials during source creation. It is during source creation that you associate a credential directly with a source.

Because sources and credentials must have matching types, any credential that you add during source creation shares the same type as the source. If you want to use an existing credential during source creation, the list of available credentials contains only credentials of the same type. For example, during network source creation, only network credentials are available for selection.

Satellite scans authenticate to Satellite Server by using a username and password encrypted over HTTPS. By default, scans run with certificate validation and secure communication through SSL or TLS protocols, which you can configure during source creation.

You might need to adjust the level of certificate validation to connect properly to the Satellite Server during a scan. For example, your Satellite Server might use a verified SSL certificate from a certificate authority. During source creation, you can upgrade SSL certificate validation to check for that certificate during a scan of that source.

Conversely, your Satellite Server might use self-signed certificates. During source creation, you can leave the SSL validation at the default so that a scan of that source does not check for a certificate. This choice, to leave the option at the default for a self-signed certificate, could possibly avoid scan errors.

Although the option to disable SSL is currently available in the interface, Satellite Server does not support the disabling of SSL. If you select the Disable SSL option when you create a satellite source, this option is ignored.

Define vCenter sources to identify vCenter Server instances and their managed virtual machines for Discovery scanning.

Create vCenter credentials to authenticate Discovery scans against vCenter Server instances.

To run a scan, you must configure data for two basic structures: sources and credentials. The type of source that you are going to inspect during the scan determines the type of data that is required for both source and credential configuration.

A source contains a single asset or a set of multiple assets that are to be inspected during the scan. You can configure any of the following types of sources:

When you are working with network sources, you determine how many individual assets you should group within a single source. Currently, you can add multiple assets to a source only for network sources. The following list contains some of the other factors that you should consider when you are adding sources:

A credential contains data such as the username and password or SSH key of a user with sufficient authority to run the scan on all or part of the assets in that source. As with sources, credentials are configured as the network, vCenter, satellite, OpenShift, Red Hat Ansible Automation Platform, or RHACS type. A network source might require multiple network credentials to access all assets in a broad IP range. Conversely, a vCenter or satellite source typically uses a single credential to access a particular system management solution server. An OpenShift, Red Hat Ansible Automation Platform, or RHACS source uses a single credential to access a single cluster.

You can add new sources from the Sources view and you can add new credentials from the Credentials view. You can also add new or select previously existing credentials during source creation. It is during source creation that you associate a credential directly with a source.

Because sources and credentials must have matching types, any credential that you add during source creation shares the same type as the source. If you want to use an existing credential during source creation, the list of available credentials contains only credentials of the same type. For example, during network source creation, only network credentials are available for selection.

vCenter scans authenticate to vCenter Server by using a username and password encrypted over HTTPS. By default, scans run with certificate validation and secure communication through SSL or TLS protocols, which you can configure during source creation.

You might need to adjust the level of certificate validation to connect properly to the vCenter server during a scan. For example, your vCenter server might use a verified SSL certificate from a certificate authority. During source creation, you can upgrade SSL certificate validation to check for that certificate during a scan of that source.

Conversely, your vCenter server might use self-signed certificates. During source creation, you can leave the SSL validation at the default so that scan of that source does not check for a certificate. This choice, to leave the option at the default for a self-signed certificate, could possibly avoid scan errors.

You might also need to disable SSL as the method of secure communication during the scan if the vCenter server is not configured to use SSL communication for web applications. For example, your vCenter server might be configured to communicate with web applications by using HTTP with port 80. If so, then during source creation you can disable SSL communication for scans of that source.

Define Red Hat OpenShift Container Platform sources to identify OpenShift clusters for Discovery scanning.

Create Red Hat OpenShift Container Platform credentials to authenticate Discovery scans against OpenShift clusters by using an application programming interface (API) token.

To run a scan, you must configure data for two basic structures: sources and credentials. The type of source that you are going to inspect during the scan determines the type of data that is required for both source and credential configuration.

A source contains a single asset or a set of multiple assets that are to be inspected during the scan. You can configure any of the following types of sources:

When you are working with network sources, you determine how many individual assets you should group within a single source. Currently, you can add multiple assets to a source only for network sources. The following list contains some of the other factors that you should consider when you are adding sources:

A credential contains data such as the username and password or SSH key of a user with sufficient authority to run the scan on all or part of the assets in that source. As with sources, credentials are configured as the network, vCenter, satellite, OpenShift, Red Hat Ansible Automation Platform, or RHACS type. A network source might require multiple network credentials to access all assets in a broad IP range. Conversely, a vCenter or satellite source typically uses a single credential to access a particular system management solution server. An OpenShift, Red Hat Ansible Automation Platform, or RHACS source uses a single credential to access a single cluster.

You can add new sources from the Sources view and you can add new credentials from the Credentials view. You can also add new or select previously existing credentials during source creation. It is during source creation that you associate a credential directly with a source.

Because sources and credentials must have matching types, any credential that you add during source creation shares the same type as the source. If you want to use an existing credential during source creation, the list of available credentials contains only credentials of the same type. For example, during network source creation, only network credentials are available for selection.

Red Hat OpenShift scans authenticate to the cluster application programming interface (API) address by using an API token encrypted over HTTPS. By default, scans run with certificate validation and secure communication through SSL or TLS protocols, which you can configure during source creation.

You might need to adjust the level of certificate validation to connect properly to the Red Hat OpenShift Container Platform cluster API address during a scan. For example, your Red Hat OpenShift cluster API address might use a verified SSL certificate from a certificate authority. During source creation, you can upgrade SSL certificate validation to check for that certificate during a scan of that source. Conversely, your cluster API address might use self-signed certificates. During source creation, you can leave the SSL validation at the default so that scan of that source does not check for a certificate. This choice, to leave the option at the default for a self-signed certificate, could possibly avoid scan errors.

You might also need to disable SSL as the method of secure communication during the scan. This applies if the Red Hat OpenShift cluster API address is not configured to use SSL communication for web applications. For example, your Red Hat OpenShift server might be configured to communicate with web applications by using HTTP with port 80. If so, then during source creation you can disable SSL communication for scans of that source.

Define Red Hat Ansible Automation Platform sources to identify Ansible Controller instances for Discovery scanning.

Create Red Hat Ansible Automation Platform credentials to authenticate Discovery scans against Ansible Controller instances.

To run a scan, you must configure data for two basic structures: sources and credentials. The type of source that you are going to inspect during the scan determines the type of data that is required for both source and credential configuration.

A source contains a single asset or a set of multiple assets that are to be inspected during the scan. You can configure any of the following types of sources:

When you are working with network sources, you determine how many individual assets you should group within a single source. Currently, you can add multiple assets to a source only for network sources. The following list contains some of the other factors that you should consider when you are adding sources:

A credential contains data such as the username and password or SSH key of a user with sufficient authority to run the scan on all or part of the assets in that source. As with sources, credentials are configured as the network, vCenter, satellite, OpenShift, Red Hat Ansible Automation Platform, or RHACS type. A network source might require multiple network credentials to access all assets in a broad IP range. Conversely, a vCenter or satellite source typically uses a single credential to access a particular system management solution server. An OpenShift, Red Hat Ansible Automation Platform, or RHACS source uses a single credential to access a single cluster.

You can add new sources from the Sources view and you can add new credentials from the Credentials view. You can also add new or select previously existing credentials during source creation. It is during source creation that you associate a credential directly with a source.

Because sources and credentials must have matching types, any credential that you add during source creation shares the same type as the source. If you want to use an existing credential during source creation, the list of available credentials contains only credentials of the same type. For example, during network source creation, only network credentials are available for selection.

Red Hat Ansible Automation Platform scans authenticate to the host Internet Protocol (IP) address by using a username and password over HTTPS. By default, scans use Secure Sockets Layer (SSL) or Transport Layer Security (TLS) certificate validation, which you can configure during source creation.

You might need to adjust the level of certificate validation to connect properly to the Red Hat Ansible Automation Platform host IP address during a scan. For example, your Red Hat Ansible Automation Platform host IP address might use a verified SSL certificate from a certificate authority. During source creation, you can upgrade SSL certificate validation to check for that certificate during a scan of that source. Conversely, your host IP address might use self-signed certificates. During source creation, you can leave the SSL validation at the default so that scan of that source does not check for a certificate. This choice, to leave the option at the default for a self-signed certificate, could possibly avoid scan errors.

You might also need to disable SSL as the method of secure communication during the scan. This applies if the Red Hat Ansible Automation Platform host IP address is not configured to use SSL communication for web applications. For example, your Red Hat Ansible Automation Platform host IP address might be configured to communicate with web applications by using HTTP with port 80. If so, then during source creation you can disable SSL communication for scans of that source.

Define Red Hat Advanced Cluster Security for Kubernetes sources to identify RHACS deployments for Discovery scanning.

Create RHACS credentials to authenticate Discovery scans against Red Hat Advanced Cluster Security for Kubernetes instances by using an API token.

To run a scan, you must configure data for two basic structures: sources and credentials. The type of source that you are going to inspect during the scan determines the type of data that is required for both source and credential configuration.

A source contains a single asset or a set of multiple assets that are to be inspected during the scan. You can configure any of the following types of sources:

When you are working with network sources, you determine how many individual assets you should group within a single source. Currently, you can add multiple assets to a source only for network sources. The following list contains some of the other factors that you should consider when you are adding sources:

A credential contains data such as the username and password or SSH key of a user with sufficient authority to run the scan on all or part of the assets in that source. As with sources, credentials are configured as the network, vCenter, satellite, OpenShift, Red Hat Ansible Automation Platform, or RHACS type. A network source might require multiple network credentials to access all assets in a broad IP range. Conversely, a vCenter or satellite source typically uses a single credential to access a particular system management solution server. An OpenShift, Red Hat Ansible Automation Platform, or RHACS source uses a single credential to access a single cluster.

You can add new sources from the Sources view and you can add new credentials from the Credentials view. You can also add new or select previously existing credentials during source creation. It is during source creation that you associate a credential directly with a source.

Because sources and credentials must have matching types, any credential that you add during source creation shares the same type as the source. If you want to use an existing credential during source creation, the list of available credentials contains only credentials of the same type. For example, during network source creation, only network credentials are available for selection.

RHACS scans authenticate to the application programming interface (API) by using a bearer token encrypted over TLS. By default, scans run with certificate validation and secure communication through TLS protocols, which you can configure during source creation.

You might need to adjust the level of certificate validation to connect to the RHACS portal during a scan. For example, your RHACS instance might use a verified TLS certificate from a certificate authority. During source creation, you can upgrade TLS certificate validation to check for that certificate during a scan of that source.

Conversely, your RHACS instance might use self-signed certificates. During source creation, you can leave the TLS validation at the default so that scan of that source does not check for a certificate. This choice, to leave the option at the default for a self-signed certificate, could possibly avoid scan errors.

You might also need to disable TLS as the method of secure communication during the scan if the RHACS instance is not configured to use TLS communication for web applications. For example, your RHACS instance might be configured to communicate with web applications by using HTTP with port 80. If so, then during source creation you can disable TLS communication for scans of that source.

Run a standard scan to inspect your sources and detect Red Hat products installed in default locations. Select one or more sources from the Sources view to combine into a single scan.

After you name a scan and run it for the first time, it is added to the Scans view. You can then run a new instance of that scan, known as a scan job, to update the data that is gathered for that scan.

Cancel a running scan job to free system resources or address higher-priority operational needs.

Deleting a scan is a nonreversible action that deletes the scan and all scan jobs for that scan. Deleted scans cannot be retrieved.

After you create sources and credentials, you can create scans. A scan groups sources into a reproducible inspection unit. Each time a saved scan runs, that instance is stored as a scan job. The output of a scan job is a report containing the facts gathered for all IT resources in the scanned sources.

A scan includes at least one source and the credentials that were associated with that source at source creation time. When the scan job runs, it uses the provided credentials to contact the assets contained in the source. It then inspects the assets to gather facts about those assets for the report. You can add multiple sources to a single scan, including a combination of different types of sources into a single scan.

A scan job manages one or more inspection tasks that gather data from systems defined in the scan’s sources. These tasks handle all aspects of connecting to systems and collecting information needed to generate the scan’s reports.

When a scan job runs, Discovery creates an inspection task for each source assigned to the scan. Each inspection task connects to systems defined by its source and collects facts that Discovery uses to produce the scan’s reports.

If a source includes multiple systems, the inspection task attempts to connect to and inspect each one. If some systems are unreachable, the task records partial results based on the systems it was able to inspect.

In scans with multiple sources, each source’s inspection task runs independently of the inspection tasks for other sources. A scan job is marked as completed only if all inspection tasks across all sources finish successfully. If any inspection task fails or cannot connect to any systems in its source, the scan job is marked as failed.

A scan job, or individual instance of a scan, moves through several states during its life cycle.

When you start a scan, a scan job is created and the scan job is in the created state. The scan job is then queued for processing and the scan job transitions to the pending state. Scan jobs run serially, in the order that they are started.

As the Discovery server reaches a specific scan job in the queue, that scan job transitions from the pending state to the running state as the processing of that scan job begins. If the scan process completes successfully, the scan job transitions to the completed state and the scan job produces results that can be viewed in a report. If the scan process results in an error that prevents successful completion of the scan, the scan job halts and the scan job transitions to the failed state. An additional status message for the failed scan contains information to help determine the cause of the failure.

Other states for a scan job result from user action that is taken on the scan job. You can pause or cancel a scan job while it is pending or running. A scan job in the paused state can be resumed. A scan job in the canceled state cannot be resumed.

Run a deep scan to detect products installed in nonstandard locations. Deep scans use the find command and can be CPU-intensive, so use discretion on production systems. After you run a scan for the first time, the scan is saved to the Scans view. From that view, you can run the scan again to update its data.

After you name a scan and run it for the first time, it is added to the Scans view. You can then run a new instance of that scan, known as a scan job, to update the data that is gathered for that scan.

Cancel a running scan job to free system resources or address higher-priority operational needs.

Deleting a scan is a nonreversible action that deletes the scan and all scan jobs for that scan. Deleted scans cannot be retrieved.

After you create sources and credentials, you can create scans. A scan groups sources into a reproducible inspection unit. Each time a saved scan runs, that instance is stored as a scan job. The output of a scan job is a report containing the facts gathered for all IT resources in the scanned sources.

A scan includes at least one source and the credentials that were associated with that source at source creation time. When the scan job runs, it uses the provided credentials to contact the assets contained in the source. It then inspects the assets to gather facts about those assets for the report. You can add multiple sources to a single scan, including a combination of different types of sources into a single scan.

A scan job manages one or more inspection tasks that gather data from systems defined in the scan’s sources. These tasks handle all aspects of connecting to systems and collecting information needed to generate the scan’s reports.

When a scan job runs, Discovery creates an inspection task for each source assigned to the scan. Each inspection task connects to systems defined by its source and collects facts that Discovery uses to produce the scan’s reports.

If a source includes multiple systems, the inspection task attempts to connect to and inspect each one. If some systems are unreachable, the task records partial results based on the systems it was able to inspect.

In scans with multiple sources, each source’s inspection task runs independently of the inspection tasks for other sources. A scan job is marked as completed only if all inspection tasks across all sources finish successfully. If any inspection task fails or cannot connect to any systems in its source, the scan job is marked as failed.

A scan job, or individual instance of a scan, moves through several states during its life cycle.

When you start a scan, a scan job is created and the scan job is in the created state. The scan job is then queued for processing and the scan job transitions to the pending state. Scan jobs run serially, in the order that they are started.

As the Discovery server reaches a specific scan job in the queue, that scan job transitions from the pending state to the running state as the processing of that scan job begins. If the scan process completes successfully, the scan job transitions to the completed state and the scan job produces results that can be viewed in a report. If the scan process results in an error that prevents successful completion of the scan, the scan job halts and the scan job transitions to the failed state. An additional status message for the failed scan contains information to help determine the cause of the failure.

Other states for a scan job result from user action that is taken on the scan job. You can pause or cancel a scan job while it is pending or running. A scan job in the paused state can be resumed. A scan job in the canceled state cannot be resumed.

Reports for a scan are available in two formats, a comma-separated variable (CSV) format and a JavaScript Object Notation (JSON) format. They are also available in two content types, raw output from the scan as a details report and processed content as a deployments report.

From the Scans view, you can select one or more reports and download them to view the report data.

To view the report, uncompress the .tar.gz file into a report_id_ID directory. The uncompressed report bundle includes five report files: two details reports in CSV and JSON formats, two deployments reports in CSV format, and one summary report in JSON format.

After a scan job completes, you can view a summary of the scan results directly in the Discovery graphical user interface. This eliminates the need to download and extract report files manually, offering a more efficient way to assess key results.

The scan process discovers the systems in your IT infrastructure and inspects them to gather information about their nature and contents. It then creates a report from the information gathered during the inspection of each system.

A system is any entity that can be interrogated by the inspection tasks through an SSH connection, vCenter Server data, the Satellite Server API, or the Red Hat OpenShift cluster API. A system can be a physical or virtual machine, or it can be a different type of entity, such as a container or a cluster.

{
    "os_release": "Red Hat Enterprise Linux Atomic Host 7.4",
    "cpu_count": 4,
    "products": [
        {
            "name": "JBoss EAP",
            "version": null,
            "presence": "absent",
            "metadata": {
                "source_id": 5,
                "source_name": "S62Source",
                "source_type": "satellite",
                "raw_fact_key": null
            }
        }
    ],
    "entitlements": [
        {
            "name": "Satellite Tools 6.3",
            "entitlement_id": 54,
            "metadata": {
                "source_id": 5,
                "source_name": "S62Source",
                "source_type": "satellite",
                "raw_fact_key": "entitlements"
            }
        }
    ],
    "metadata": {
        "os_release": {
            "source_id": 5,
            "source_name": "S62Source",
            "source_type": "satellite",
            "raw_fact_key": "os_release"
        },
        "cpu_count": {
            "source_id": 4,
            "source_name": "NetworkSource",
            "source_type": "network",
            "raw_fact_key": "os_release"
        }
    },
    "sources": [
        {
            "id": 4,
            "source_type": "network",
            "name": "NetworkSource"
        },
        {
            "id": 5,
            "source_type": "satellite",
            "name": "S62Source"
        }
    ]
}

When you need to provide report data to the Red Hat Hybrid Cloud Console services such as the Red Hat Lightspeed Subscriptions Inventory and Subscription Services, you download and send an insights report.

This type of report is different from a details report or a deployments report. A Red Hat Lightspeed report is a Discovery report with data that is similar to the deployments report. However, its contents and format are designed especially to be ingested and used by the Red Hat Hybrid Cloud Console services.

Download and publish a Lightspeed report with the Discovery command line interface (CLI) to provide data from Discovery to Red Hat Hybrid Cloud Console services such as Red Hat Lightspeed Subscriptions Inventory and Subscription Services.

This type of report is different from the details report or deployments report contained in the .tar.gz files you may normally download from Discovery. A Lightspeed report is a Discovery report with data that is similar to the deployments report, but its contents and format are restructured specifically for use by the Red Hat Hybrid Cloud Console services.

An Red Hat Lightspeed report is a specialized report formatted for Red Hat Hybrid Cloud Console services. Send it to Subscriptions Inventory for host-based inventory data and Subscription Services for subscription usage data.

Although Discovery is useful for scanning and reporting on all parts of your IT infrastructure, sending a report to the Red Hat Hybrid Cloud Console services is particularly useful for disconnected or air-gapped environments. By using Discovery to gather data about those parts of your network, you can get a more complete and more curated view of your overall network.

Red Hat Hybrid Cloud Console provides a unified inventory and a more complete picture of subscription usage. This is possible when the data from Discovery’s Red Hat Lightspeed report combines with data from other tools that support Red Hat Hybrid Cloud Console.