Bug 2144887

+++ This bug was initially created as a clone of Bug #2141995 +++

Description of problem:
Use virt-install to install a win2k22 VM via ISO, but virt-install automatically detects the version from the ISO as win2k16, that's incorrect.


Version-Release number of selected component (if applicable):
virt-install-4.0.0-1.el9.noarch
virt-manager-common-4.0.0-1.el9.noarch
osinfo-db-20220727-3.el9.noarch
libosinfo-1.9.0-5.el9.x86_64
libvirt-8.9.0-2.el9.x86_64


How reproducible:
100%

Steps to Reproduce:
1. Download a win2k22 ISO: en-us_windows_server_2022_x64_dvd_620d7eac.iso

2. Install a win2k22 VM via the iso.

# virt-install  --cdrom /var/lib/libvirt/images/en-us_windows_server_2022_x64_dvd_620d7eac.iso  --osinfo detect=on,require=off 
Using default --name win2k16
Using win2k16 default --memory 2048
Using win2k16 default --disk size=40

Starting install...
Allocating 'win2k16.qcow2'                                                   |  79 MB  00:00:02 ... 
Creating domain...                                                           |    0 B  00:00:00     
Running graphical console command: virt-viewer --connect qemu:///system --wait win2k16
....


Actual results:
As per the description, virt-install automatically detects the VM's version as win2k16.

Expected results:
Fix it.

Additional info:
The attachment is the debug log: virt-install.log

--- Additional comment from Jonathon Jongsma on 2022-11-11 22:10:09 UTC ---

The os detection is done by libosinfo. I believe that this would need to be fixed in osinfo-db.

for reference, see the upstream issue https://gitlab.com/libosinfo/osinfo-db/-/issues/87

--- Additional comment from Victor Toso on 2022-11-14 05:31:47 UTC ---

> I believe that this would need to be fixed in osinfo-db.

The suggested fix is to use APIs introduced in v1.10.0 [0] to workaround the fact we can't guarantee that uniqueness response on ISO metadata alone.

[0] https://gitlab.com/libosinfo/libosinfo/-/merge_requests/128

> for reference, see the upstream issue https://gitlab.com/libosinfo/osinfo-db/-/issues/87

I just closed this one.

Jonathon, I think virt-install will need to work with this new APIs. It should probably fail instead of detecting the wrong OS version.

virt-install will need newer libosinfo than what we have in RHEL at the moment so I'm adding depends on the rebase bug.

--- Additional comment from Jonathon Jongsma on 2022-11-17 23:14:00 UTC ---

Hi Victor, it doesn't seem like that will totally solve the issue. On my Fedora laptop for instance:

$ rpm -qa |grep osinfo
osinfo-db-tools-1.10.0-1.fc36.x86_64
libosinfo-1.10.0-1.fc36.x86_64
libosinfo-devel-1.10.0-1.fc36.x86_64
osinfo-db-20221018-1.fc36.noarch

$ osinfo-detect -a ~/work/iso/en-us_windows_server_2022_x64_dvd_620d7eac.iso 
Media is bootable.
#1: Media is an installer for OS 'Microsoft Windows Server 2016 (x86_64)'

$ osinfo-detect -a ~/work/iso/en-us_windows_server_2022_updated_oct_2022_x64_dvd_c5b651c9.iso 
Media is bootable.

If `osinfo-detect -a` doesn't report windows server 2022 for these isos, doesn't that indicate an issue in osinfo-db?

--- Additional comment from Victor Toso on 2022-11-22 10:10:52 UTC ---

Hi Jonathon,

> If `osinfo-detect -a` doesn't report windows server 2022 for these isos, doesn't that indicate an issue in osinfo-db?

That's correct. Seems to be an issue in libosinfo where the internals of the API is not considering `derives-from`.
In this case, windows server 2022 derives from windows server 2019, which derives from windows server 2016 and only the last one is being reported back.

I'm working on a fix for libosinfo for that now, I'll update you here when is posted.

--- Additional comment from Jonathon Jongsma on 2022-11-22 15:00:18 UTC ---

Thanks Victor,

I guess I'll leave this bug under virt-manager since I'll probably need to modify the libosinfo API usage. Should we also clone this bug to osinfo-db?

--- Additional comment from Victor Toso on 2022-11-22 16:12:15 UTC ---

(In reply to Victor Toso from comment #4)
> That's correct. Seems to be an issue in libosinfo where the internals of the
> API is not considering `derives-from`.

`Derives-from` is not for osinfo media types... I've posted a patch updating osinfo-db.
https://gitlab.com/libosinfo/osinfo-db/-/merge_requests/529

(In reply to Jonathon Jongsma from comment #5)
> Should we also clone this bug to osinfo-db?

The fix will be covered by rebase bug 2135751 but this issue might be interesting to be included in the osinfo-db errata, so I'll clone it.
Thanks!