RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1793925 - RFE: Ship a drop-in file for osinfo-db, including the path of the drivers
Summary: RFE: Ship a drop-in file for osinfo-db, including the path of the drivers
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: virtio-win
Version: 8.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Vadim Rozenfeld
QA Contact: lijin
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-01-22 09:40 UTC by Fabiano Fidêncio
Modified: 2021-07-28 01:03 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-07-22 07:30:25 UTC
Type: Feature Request
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Fabiano Fidêncio 2020-01-22 09:40:47 UTC 
For osinfo-db to provide information about the drivers installed in the system via virtio-win rpm, we'd have to ship a drop-in file like https://gitlab.com/libosinfo/osinfo-db/blob/master/data/os/microsoft.com/win-10.d/pre-installable-drivers.xml.in.

The main difference would be the location pointing to the folder where the files are located.

The naming could something like: virtio-win-pre-installable-drivers.xml and the driver element should have a "priority=$num" attribute, where $num is any number > 50 (which is the default priority).

By doing this, virt-install and GNOME Boxes can consume the drivers from the RPM without having to deal with the shipped ISO itself.
Comment 1 Jeff Nelson 2020-01-22 15:47:51 UTC 
>virt-install and GNOME Boxes can consume the drivers from the RPM without having to deal with the shipped ISO itself.

Can you provide an example of how this would work? I'm a bit confused how virt-install or GNOME Boxes (running on RHEL) would consume Windows drivers. Why would you want to do this?

Meanwhile, I'm delegating the BZ to Amnon.
Comment 2 Fabiano Fidêncio 2020-01-22 16:13:06 UTC 
(In reply to Jeff Nelson from comment #1)
> >virt-install and GNOME Boxes can consume the drivers from the RPM without having to deal with the shipped ISO itself.
> 
> Can you provide an example of how this would work?

Sure, sorry for the lack of information.

> I'm a bit confused how
> virt-install or GNOME Boxes (running on RHEL) would consume Windows drivers.

Both GNOME Boxes and virt-install, when performing an unattended installation of a Windows Guest, try to install all the possible virtio-win drivers.

With the latest changes done by Cole, these drivers are already unpacked in the same place where the virtio-win ISO is installed and we could take advantage of this and just pick the drivers from the system.

The approach taken by Fedora (for the non signed drivers) is to:
- Once a new release is out, unpack the drivers and upload them into virt-sig;
- Change osinfo-db entries to point to this virt-sig page;
- Download the drivers from there;
- Use them during the unattended installation;

For RHEL it's not viable as we cannot just upload virtio-win package somewhere, neither should we use the non-signed drivers when performing Windows unattended installations.

However, with the last changes done by Cole, we now have a way to take advantage of the drivers on RHEL.

> Why would you want to do this?

Does the explanation above make sense, Jeff? I've tried to summarize the current approach (or lack of approach for RHEL) and how it could be improved.

> 
> Meanwhile, I'm delegating the BZ to Amnon.

I guess Amnon team who'll inherit this package is the right team to look at that. I, of course, can help.
Comment 4 Pino Toscano 2020-08-12 05:30:07 UTC 
This will be also used by virt-v2v 1.42.0, currently in AV 8.3.0.

virt-v2v tries to detect the right directory with Windows drivers depending on the path elements in /usr/share/virtio-win, which is still a sort of heuristic. Starting with 1.42.0, it queries libosinfo for drivers of Windows guests (when converting them), so with these configuration files we get the lists of drivers directly, with no need to guess from the paths.
Comment 8 RHEL Program Management 2021-07-22 07:30:25 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Note You need to log in before you can comment on or make changes to this bug.