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 2012658 - libguestfs fails to detect Windows 11 guest image
Summary: libguestfs fails to detect Windows 11 guest image
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: libguestfs
Version: 9.0
Hardware: x86_64
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Richard W.M. Jones
QA Contact: YongkuiGuo
URL:
Whiteboard:
Depends On:
Blocks: 2149811 2149863
TreeView+ depends on / blocked
 
Reported: 2021-10-11 03:02 UTC by YongkuiGuo
Modified: 2023-05-09 08:38 UTC (History)
8 users (show)

Fixed In Version: libguestfs-1.48.4-4.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-05-09 07:36:38 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-99379 0 None None None 2021-10-11 03:05:28 UTC
Red Hat Product Errata RHBA-2023:2231 0 None None None 2023-05-09 07:36:46 UTC

Description YongkuiGuo 2021-10-11 03:02:01 UTC 
Description of problem:
When handling Windows 11 image with virt-inspector, the output about product_name, major_version and osinfo is incorrect.


Version-Release number of selected component (if applicable):
libguestfs-1.46.0-1.el9.x86_64
guestfs-tools-1.46.1-4.el9.1.x86_64


How reproducible:
100%


Steps:

1. On rhel9 host
$ virt-inspector -a Win11-64-hvm.raw --no-applications
<?xml version="1.0"?>
<operatingsystems>
  <operatingsystem>
    <root>/dev/sda2</root>
    <name>windows</name>
    <arch>x86_64</arch>
    <distro>windows</distro>
    <product_name>Windows 10 Enterprise</product_name>
    <product_variant>Client</product_variant>
    <major_version>10</major_version>
    <minor_version>0</minor_version>
    <windows_systemroot>/Windows</windows_systemroot>
    <windows_current_control_set>ControlSet001</windows_current_control_set>
    <hostname>DESKTOP-GSJ1QBH</hostname>
    <osinfo>win10</osinfo>
    <mountpoints>
      <mountpoint dev="/dev/sda2">/</mountpoint>
    </mountpoints>
    <filesystems>
      <filesystem dev="/dev/sda2">
        <type>ntfs</type>
        <uuid>A244CB2144CAF6D7</uuid>
      </filesystem>
    </filesystems>
    <drive_mappings>
      <drive_mapping name="C">/dev/sda2</drive_mapping>
    </drive_mappings>
  </operatingsystem>
</operatingsystems>

Actual results:
As above

Expected results:
The product_name should be 'Windows 11 Enterprise'.
The major release should be 11.
The osinfo displays win11.

Additional info:
Comment 2 Richard W.M. Jones 2021-10-11 17:21:27 UTC 
Just as a comment: Windows recently changed their internal versioning
system, which is the root cause of a lot of the problems we are having
detecting recent Windows versions (I'm thinking about the similar bug
related to Windows 2022 Server).  Previously there were two fields in
the registry forming a major.minor internal version (CurrentMajorVersionNumber
and CurrentMinorVersionNumber).  That's what you see in the "Version"
column here:

https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions

up to Windows 10 which was bumped from 6.x to 10.0.

However this system changed with "Windows 10 version 1511".  Now
the registry Current{Major,Minor}VersionNumber stays (apparently
forever) at 10.0, and there's a new field.

Because the consumer versions of Windows were until recently always
Windows 10, and 10.0 is still in the registry, this didn't matter.
Obviously Windows 11 changes that.

The new version seems to be stored in the same section of the
registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
in a new field called ReleaseId.  We don't currently look at this
field at all.

The next problem is what we map this to.  libguestfs API provides only
major & minor versions.
Comment 3 YongkuiGuo 2021-10-12 11:15:16 UTC 
(In reply to Richard W.M. Jones from comment #2)
> The new version seems to be stored in the same section of the
> registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
> in a new field called ReleaseId.  We don't currently look at this
> field at all.
> 
> The next problem is what we map this to.  libguestfs API provides only
> major & minor versions.

There is a new field 'DisplayVersion'(HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion) in the Windows 11 image. The value of 'DisplayVersion' is 21H2. So it seems the correct version is stored in the 'DisplayVersion' field.
Comment 5 Richard W.M. Jones 2022-03-31 07:42:57 UTC 
*** Bug 2068173 has been marked as a duplicate of this bug. ***
Comment 6 roy.lemmon 2022-03-31 12:52:26 UTC 
Hello,

I do not believe that BZ 2068173 is a duplicate of this issue.  BZ 2068173 has been seen on Windows 2016 and Windows 2019 and concerns Dynamic disks.

Can you please reopen BZ 2068173?
Comment 9 Richard W.M. Jones 2022-11-30 14:36:00 UTC 
Looking back at this old bug, I believe that there would be three
plausible ways to fix this:

(1) Keep major == 10 and minor == 0, but add a new field.  We already
have various Windows-specific fields in the inspection data
(eg. windows_systemroot).

The problem with this is that adding new inspection fields is quite
disruptive throughout the stack (libguestfs, virt-inspector, virt-v2v
and more).

(2) "Fake" a newer major number, ie. if we detect that it's Windows 11,
then return major == 11 (even though the internal Windows version
would be 10).

The problem with this is if MSFT decided to resume increasing the major
version numbers, then we'd be in trouble.

(3) Use the existing osinfo field to distinguish between versions of
Windows > 10.

Conveniently osinfo already distiguishes Windows 2019 Server, Windows 2022 Server,
Windows 10 (but not Windows 11 - I think that's still a bug).  See:

https://github.com/libguestfs/libguestfs/commit/3ed32996ddf863f2c30a92c554029aa01d3689bc
https://gitlab.com/libosinfo/osinfo-db/-/issues/82

Note this bug is not fixed, because we need to add "win11".  I will
make a patch soon.

We do also need to start using the osinfo field in virt-v2v for driver
detection.
Comment 10 roy.lemmon 2022-11-30 14:47:41 UTC 
Will your patch also include a fix for BZ 2068173?
Comment 11 Richard W.M. Jones 2022-11-30 14:49:39 UTC 
Please don't comment on unrelated bugs.
Comment 16 Richard W.M. Jones 2022-12-01 10:45:57 UTC 
Posted:
https://listman.redhat.com/archives/libguestfs/2022-December/030361.html
https://listman.redhat.com/archives/libguestfs/2022-December/030360.html
https://listman.redhat.com/archives/libguestfs/2022-December/030362.html

Also a related patch to update virt-inspector for <build_id>:
https://listman.redhat.com/archives/libguestfs/2022-December/030363.html
Comment 17 Richard W.M. Jones 2022-12-02 10:19:51 UTC 
Upstream in:
https://github.com/libguestfs/libguestfs/commit/f3dd67affe3c657af64ee9f6d70a16e965309556
https://github.com/libguestfs/libguestfs/commit/824c7457489366494f0f10fd3369dc30f3a3c360

virt-inspector change (in guestfs-tools) upstream in:
https://github.com/rwmjones/guestfs-tools/commit/4e703943ca0ac4dc5ae5a1aec229c58c56e83158
Comment 19 YongkuiGuo 2022-12-05 02:08:53 UTC 
Tested with package:
libguestfs-1.48.4-4.el9.x86_64


Steps:

1. On rhel9.2 host
$ virt-inspector -a Win11-64-hvm.raw --no-applications
<?xml version="1.0"?>
<operatingsystems>
  <operatingsystem>
    <root>/dev/sda2</root>
    <name>windows</name>
    <arch>x86_64</arch>
    <distro>windows</distro>
    <product_name>Windows 10 Enterprise</product_name>
    <product_variant>Client</product_variant>
    <major_version>10</major_version>
    <minor_version>0</minor_version>
    <windows_systemroot>/Windows</windows_systemroot>
    <windows_current_control_set>ControlSet001</windows_current_control_set>
    <hostname>DESKTOP-GSJ1QBH</hostname>
    <osinfo>win11</osinfo>
    ...

The osinfo field displays 'win11' correctly.
Comment 23 YongkuiGuo 2023-01-20 02:56:39 UTC 
Verified this bug as this bug has been automated and the test case passed in the latest nightly compose test.
Comment 25 errata-xmlrpc 2023-05-09 07:36:38 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 (libguestfs bug fix and enhancement update), 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/RHBA-2023:2231
Note You need to log in before you can comment on or make changes to this bug.