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 1683902 - Add win2019 to libosinfo
Summary: Add win2019 to libosinfo
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: osinfo-db
Version: 7.7
Hardware: x86_64
OS: Unspecified
low
low
Target Milestone: rc
: ---
Assignee: Fabiano Fidêncio
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 1649362 1685364 1714748
TreeView+ depends on / blocked
 
Reported: 2019-02-28 04:29 UTC by mxie@redhat.com
Modified: 2019-08-06 12:39 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1685364 (view as bug list)
Environment:
Last Closed: 2019-08-06 12:38:49 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
screenshot of win2019 installation (625.89 KB, image/png)
2019-05-24 06:15 UTC, ysu@redhat.com
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2019:2045 0 None None None 2019-08-06 12:39:00 UTC

Description mxie@redhat.com 2019-02-28 04:29:22 UTC
Description of problem:
Add win2019 to libosinfo

Version-Release number of selected component (if applicable):
libosinfo-1.1.0-2.el7.x86_64
osinfo-db-20181214-1.el7_6.noarch

How reproducible:
100%

Steps to reproduce:
1.win2019 isn't listed in osinfo-db
# osinfo-query os |grep win2k
 win2k                | Microsoft Windows 2000                             | 5.0      | http://microsoft.com/win/2k             
 win2k12              | Microsoft Windows Server 2012                      | 6.3      | http://microsoft.com/win/2k12           
 win2k12r2            | Microsoft Windows Server 2012 R2                   | 6.3      | http://microsoft.com/win/2k12r2         
 win2k16              | Microsoft Windows Server 2016                      | 10.0     | http://microsoft.com/win/2k16           
 win2k3               | Microsoft Windows Server 2003                      | 5.2      | http://microsoft.com/win/2k3            
 win2k3r2             | Microsoft Windows Server 2003 R2                   | 5.2      | http://microsoft.com/win/2k3r2          
 win2k8               | Microsoft Windows Server 2008                      | 6.0      | http://microsoft.com/win/2k8            
 win2k8r2             | Microsoft Windows Server 2008 R2                   | 6.1      | http://microsoft.com/win/2k8r2   

Actual results:
win2019 isn't listed in osinfo-db

Expected results:
Add win2019 to libosinfo

Additional info:
If there is no win2019 listed in libosinfo, the osinfo ID shows "http://microsoft.com/win/2k16" in win2019 guest libvirtxml after v2v conversion, details pls refer to https://bugzilla.redhat.com/show_bug.cgi?id=1560935#c9

Comment 5 ysu@redhat.com 2019-05-24 06:15:51 UTC
Created attachment 1572787 [details]
screenshot of win2019 installation

Comment 6 ysu@redhat.com 2019-05-24 06:20:01 UTC
Description of problem:
Incorrectly detecting the system version of win_2019 with microsoft windows 2016 on virt-manager install GUI.

Version-Release number of selected component (if applicable):
libosinfo-1.1.0-3.el7.x86_64
virt-manager-1.5.0-6.el7.noarch

How reproducible:
100%

Steps to reproduce:
1.Launch virt-manager.
2.Click 'create a new virtual machine' button-> choose 'local install media'-> 'forward'.
3.Choose a win_2019 iso for ISO image -> choose 'automatically detect operating system based on install media'.

Result:detect OS type with Windows and Version with Mircosoft Windows Server 2016.
4.Forward and make settings as default until step5 of 5.

Result:default name of new guest is win2k16 and storage is /var/lib/libvirt/images/win2k16.qcow2.
5.Check osinfo on host.
5.1 # osinfo-query os |grep win2k
 win2k                | Microsoft Windows 2000                             | 5.0      | http://microsoft.com/win/2k             
 win2k12              | Microsoft Windows Server 2012                      | 6.3      | http://microsoft.com/win/2k12           
 win2k12r2            | Microsoft Windows Server 2012 R2                   | 6.3      | http://microsoft.com/win/2k12r2         
 win2k16              | Microsoft Windows Server 2016                      | 10.0     | http://microsoft.com/win/2k16           
 win2k19              | Microsoft Windows Server 2019                      | 10.0     | http://microsoft.com/win/2k19           
 win2k3               | Microsoft Windows Server 2003                      | 5.2      | http://microsoft.com/win/2k3            
 win2k3r2             | Microsoft Windows Server 2003 R2                   | 5.2      | http://microsoft.com/win/2k3r2          
 win2k8               | Microsoft Windows Server 2008                      | 6.0      | http://microsoft.com/win/2k8            
 win2k8r2             | Microsoft Windows Server 2008 R2                   | 6.1      | http://microsoft.com/win/2k8r2          
5.2 #virt-manager --debug
[Fri, 24 May 2019 11:32:29 virt-manager 7756] DEBUG (create:2329) Starting OS detection thread for media=/root/Downloads/en_windows_server_2019_updated_march_2019_x64_dvd_2ae967ab.iso
[Fri, 24 May 2019 11:32:29 virt-manager 7756] DEBUG (storagebrowse:66) Closing storage browser
[Fri, 24 May 2019 11:32:29 virt-manager 7756] DEBUG (distroinstaller:283) installer.detect_distro returned=win2k16
[Fri, 24 May 2019 11:32:29 virt-manager 7756] DEBUG (create:2407) Finished UI OS detection.

Actual results:
win2019 is listed in osinfo-db but version of win_2019 is detecting incorrectly with Mircosoft Windows Server 2016/win2k16.

Expected results:
version of win_2019 should be detect as win2k19.

Additional info:
screenshot https://bugzilla.redhat.com/attachment.cgi?id=1572787

Comment 7 Fabiano Fidêncio 2019-05-24 06:26:15 UTC
(In reply to ysu from comment #6)
> Description of problem:
> Incorrectly detecting the system version of win_2019 with microsoft windows
> 2016 on virt-manager install GUI.

There's absolutely nothing that could be done from libosinfo side to prevent this to happen.
Both Windows 2016 and 2019 ISOs have exactly the same volume-id. I've discussed this with Pino when he originally submitted the patch. One this that could be done would be to add the volume-size for *each* of the Windows 2k19 ISOs (including different languages), but this doesn't scale. :-/

In the end we agreed on having an "almost empty" entry for Windows 2019 as libguestfs would already benefit from that.

Comment 8 Fabiano Fidêncio 2019-05-24 06:37:17 UTC
(In reply to Fabiano Fidêncio from comment #7)
> (In reply to ysu from comment #6)
> > Description of problem:
> > Incorrectly detecting the system version of win_2019 with microsoft windows
> > 2016 on virt-manager install GUI.
> 
> There's absolutely nothing that could be done from libosinfo side to prevent
> this to happen.
> Both Windows 2016 and 2019 ISOs have exactly the same volume-id. I've
> discussed this with Pino when he originally submitted the patch. One this
> that could be done would be to add the volume-size for *each* of the Windows
> 2k19 ISOs (including different languages), but this doesn't scale. :-/
> 
> In the end we agreed on having an "almost empty" entry for Windows 2019 as
> libguestfs would already benefit from that.

Btw, sorry, we should have made it clear in the BZ that this would happen (as we did in the commit message).
For historic purposes, here's the link for the commit: https://gitlab.com/libosinfo/osinfo-db/commit/4a45fde98cf2aa80fabd5a11c97a3f4e13d33d9c and it mentions:

"This new OS does not include any <media>, and this is done on purpose:
sadly, the ISOs have the same metadata (like Volume ID, etc) as win2k16
(Windows Server 2016), and thus it is not possible to distinguish them.
Theoretically, using the volume size can help with the detection;
however, the Windows ISOs have different supported languages, and there
is no way to specify the volume size for each language.

Regardless, having this OS is still useful for users to match an OS with
an osinfo ID."

Comment 9 ysu@redhat.com 2019-05-24 07:48:36 UTC
I agree with you that nothing we can do about the same metadata between win2019 and win2016.But thank you so much for such a quick response!

Comment 11 errata-xmlrpc 2019-08-06 12:38:49 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:2045


Note You need to log in before you can comment on or make changes to this bug.