Bug 2141995

Summary: virt-install detects the wrong operating system version from the win2k22 ISO file
Product: Red Hat Enterprise Linux 9 Reporter: zhoujunqin <juzhou>
Component: virt-managerAssignee: Jonathon Jongsma <jjongsma>
virt-manager sub component: Common QA Contact: Hongzhou Liu <hongzliu>
Status: CLOSED MIGRATED Docs Contact:
Severity: medium    
Priority: unspecified CC: hongzliu, jjongsma, jsuchane, tyan, tzheng, victortoso, virt-maint
Version: 9.2Keywords: MigratedToJIRA, Triaged
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 2144887 (view as bug list) Environment:
Last Closed: 2023-09-22 17:37:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2135755, 2144887    
Bug Blocks:    
Attachments:
Description Flags
virt-install debug log none

Description zhoujunqin 2022-11-11 11:12:20 UTC
Created attachment 1923769 [details]
virt-install debug log

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

Comment 1 Jonathon Jongsma 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

Comment 2 Victor Toso 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.

Comment 3 Jonathon Jongsma 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?

Comment 4 Victor Toso 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.

Comment 5 Jonathon Jongsma 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?

Comment 6 Victor Toso 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!

Comment 7 Victor Toso 2022-11-30 21:56:01 UTC
> I'm working on a fix for libosinfo for that now, I'll update you here when is posted.

libosinfo rebase is done: bug 2135755
osinfo-db rebase is done: bug 2135751

If one finds an Windows ISO that is not recognized, feel free to ping me or open a bug.
Cheers,

Comment 10 Jonathon Jongsma 2023-02-13 21:07:10 UTC
FYI, I did submit a patch upstream, but the proper approach is still under discussion: https://github.com/virt-manager/virt-manager/pull/465

Comment 11 RHEL Program Management 2023-09-22 17:31:56 UTC
Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

Comment 12 RHEL Program Management 2023-09-22 17:37:10 UTC
This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.