Quipucords – now officially called Discovery – is a Red Hat tool that scans your infrastructure to identify RHEL installations, subscriptions, and software usage across physical servers, virtual machines, and cloud instances. It connects via SSH to network hosts and through APIs to VMware vCenter and Red Hat Satellite, then collects, deduplicates, and reports what it finds. This guide covers installing and configuring Quipucords (Discovery) on RHEL 10 and Rocky Linux 10 using Podman containers.
Discovery runs as a set of Podman containers managed through systemd, with a PostgreSQL database, Redis cache, and Celery worker handling async scan jobs. The CLI tool qpc is used to configure credentials, define sources, run scans, and export reports. Version 2.5.1 is the latest release at the time of writing.
Prerequisites
Before you begin, make sure the following requirements are met:
- A server running RHEL 10, Rocky Linux 10, or AlmaLinux 10 with at least 2 CPU cores, 2 GB RAM, and 30 GB disk space
- Root or sudo access on the server
- Podman installed on the system (ships by default on RHEL 10)
- Network access from the Discovery server to all target systems you want to scan
- SSH credentials or API credentials for the target systems (network hosts, vCenter, or Satellite)
- A Red Hat registry account for pulling container images from
registry.redhat.io
Step 1: Install Quipucords Discovery Using Podman
The recommended way to deploy Quipucords is through quipucordsctl, which manages the full container stack – the server, PostgreSQL, Redis, and Celery worker – using Podman Quadlets and systemd. Start by enabling the Copr repository and installing the management tool.
sudo dnf copr enable -y @quipucords/quipucordsctl
sudo dnf install -y quipucordsctl
Next, run the installer. This sets up the Podman Quadlet files and systemd units for all Quipucords components. Run this as a regular (non-root) user – only the RPM installation requires root.
quipucordsctl install
Before starting the service, log into the Red Hat container registry. This is required to pull the Quipucords container images.
podman login registry.redhat.io
Enter your Red Hat account credentials when prompted. Once authenticated, start the Quipucords application stack.
systemctl --user start quipucords-app
Verify that all containers are running. You should see the quipucords-server, quipucords-db (PostgreSQL), quipucords-redis, and quipucords-celery-worker containers in a running state.
podman ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"
The output should show all four containers running:
NAMES STATUS PORTS
quipucords-server Up 2 minutes 0.0.0.0:9443->443/tcp
quipucords-db Up 2 minutes
quipucords-redis Up 2 minutes
quipucords-celery-worker Up 2 minutes
The Quipucords web interface is now available at https://localhost:9443. The service uses a self-signed SSL certificate, so your browser will show a security warning on first access – this is expected.
Step 2: Install the QPC CLI and Configure Credentials
The qpc command-line tool is the primary interface for managing Discovery. Install it from the Quipucords Copr repository.
sudo dnf copr enable -y @quipucords/qpc
sudo dnf install -y qpc
Point the CLI to your local Quipucords server and log in. The default admin credentials are set during the quipucordsctl install process.
qpc server config --host 127.0.0.1 --port 9443
qpc server login
Now add the credentials Discovery will use to access your target systems. For scanning Linux servers over SSH, create a network credential with either a password or SSH key.
To add a credential using an SSH key (recommended for production):
qpc cred add --type network --name server-ssh-key --username root --sshkeyfile ~/.ssh/id_rsa
To add a credential using a password instead:
qpc cred add --type network --name server-password --username root --password
The --password flag prompts you interactively so the password is not stored in shell history. For scanning VMware vCenter, add a vCenter credential:
qpc cred add --type vcenter --name vcenter-admin --username [email protected] --password
For Red Hat Satellite integration:
qpc cred add --type satellite --name satellite-admin --username admin --password
Verify all configured credentials with:
qpc cred list
Step 3: Add Scan Sources (Network, vCenter, Satellite)
Sources tell Discovery what to scan. Each source is linked to one or more credentials. You can define three types of sources – network (SSH-based), vCenter, and Satellite.
Add a network source to scan a subnet of Linux servers:
qpc source add --type network --name datacenter-servers --hosts 192.168.1.[1:254] --cred server-ssh-key
You can also specify individual hosts, ranges, or CIDR notation. Multiple hosts are separated by spaces:
qpc source add --type network --name web-servers --hosts 10.0.1.10 10.0.1.11 10.0.1.12 --cred server-ssh-key
Add a VMware vCenter source to discover virtual machines:
qpc source add --type vcenter --name vmware-dc --hosts vcenter.example.com --cred vcenter-admin
Add a Red Hat Satellite source to pull managed host data:
qpc source add --type satellite --name satellite-server --hosts satellite.example.com --cred satellite-admin
List all configured sources to confirm they are set up correctly:
qpc source list
Step 4: Run Discovery Scans
With credentials and sources configured, create a scan that combines one or more sources. A scan can include network, vCenter, and Satellite sources in a single job – Discovery will correlate data across all of them.
qpc scan add --name full-infrastructure --sources datacenter-servers vmware-dc satellite-server
Start the scan. Each run creates a unique scan job with its own ID for tracking and reporting.
qpc scan start --name full-infrastructure
The scan job ID is returned in the output. Use it to check progress:
qpc scan job --id 1
For a quick overview of all scans and their status:
qpc scan list
Scans run consecutively on the server, in the order they were started. Depending on the number of hosts, a scan can take anywhere from a few minutes to several hours. Discovery uses Ansible under the hood to connect to each target system, collect facts about the OS, hardware, installed packages, and running services.
Step 5: View Scan Reports
Once a scan completes, Discovery generates two types of reports. The details report contains raw collected data from every scanned host. The deployments report is the processed, deduplicated summary that maps systems to Red Hat products and subscriptions.
View the details report for scan job 1 in JSON format:
qpc report details --scan-job 1 --json --output-file ~/scan_details.json
Generate the deployments report in CSV format for easy spreadsheet analysis:
qpc report deployments --scan-job 1 --csv --output-file ~/scan_deployments.csv
The deployments report includes fields like system name, IP address, OS version, CPU count, installed Red Hat products, entitlements, and subscription status. This is the report you typically share with procurement or compliance teams.
Step 6: Fingerprinting and Deduplication
One of Discovery’s strongest features is automatic fingerprinting and deduplication. When you scan the same host through multiple sources – for example, a server appears in both a network scan and a vCenter scan – Discovery merges these into a single system record rather than counting it twice.
The fingerprinting process works by matching systems across sources using attributes like MAC addresses, BIOS UUIDs, subscription manager IDs, and IP addresses. When a match is found, Discovery combines the data from all sources into one consolidated entry in the deployments report.
This deduplication is critical for accurate subscription counting. Without it, a single RHEL server managed by both Satellite and discovered via network SSH would appear as two separate systems, inflating your subscription requirements. The deployments report only includes deduplicated results, while the details report preserves the raw data from each source separately for audit purposes.
Step 7: Export and Download Reports
Discovery supports exporting reports in both CSV and JSON formats. For a complete archive of a scan result, download the full tarball that includes both the details and deployments reports.
qpc report download --scan-job 1 --output-file ~/scan_report.tar.gz
The tarball contains both report types in JSON and CSV format, ready for archiving or sharing. You can also merge reports from multiple scans into a single combined report:
qpc report merge --json --ids 1 2 3 --output-file ~/merged_report.json
For organizations with multiple Discovery servers or separate scan batches, merging lets you produce a single unified view of your entire infrastructure. The merged report goes through the same deduplication process, so systems found across different scans are still counted once.
You can also access reports through the web interface at https://your-server:9443. The UI provides a visual dashboard for reviewing scan results, filtering by product, and downloading reports directly from the browser.
Step 8: Configure Firewall for Quipucords Discovery
If you need to access the Discovery web interface from other machines on the network, open port 9443/tcp in firewalld.
sudo firewall-cmd --permanent --add-port=9443/tcp
sudo firewall-cmd --reload
Verify the port is open:
sudo firewall-cmd --list-ports
The output should include 9443/tcp in the list. Also ensure the Discovery server has outbound SSH access (port 22/tcp) to all network scan targets, HTTPS access (port 443/tcp) to vCenter and Satellite servers, and that SELinux is not blocking Podman container networking.
Conclusion
You now have Quipucords (Discovery) running on RHEL 10 or Rocky Linux 10 with the qpc CLI configured to scan network hosts, VMware vCenter, and Red Hat Satellite sources. The fingerprinting and deduplication engine gives you an accurate count of Red Hat product usage across your entire infrastructure.
For production deployments, restrict access to port 9443 to authorized admin networks only, schedule regular scans using cron or systemd timers, and archive reports for compliance audits. Check the qpc documentation for advanced options like custom scan configurations, SSH port overrides, and disabling SSL verification for internal vCenter instances.