Bug 1793925

Summary: RFE: Ship a drop-in file for osinfo-db, including the path of the drivers
Product: Red Hat Enterprise Linux 8 Reporter: Fabiano FidĂȘncio <fidencio>
Component: virtio-winAssignee: Vadim Rozenfeld <vrozenfe>
virtio-win sub component: distribution QA Contact: lijin <lijin>
Status: CLOSED ERRATA Docs Contact:
Severity: unspecified    
Priority: unspecified CC: ddepaula, lijin, ptoscano, vrozenfe
Version: 8.3Keywords: FutureFeature, RFE
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-07-22 07:30:25 UTC Type: Feature Request
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.