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