Bug 2012658
| Summary: | libguestfs fails to detect Windows 11 guest image | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | YongkuiGuo <yoguo> |
| Component: | libguestfs | Assignee: | Richard W.M. Jones <rjones> |
| Status: | CLOSED ERRATA | QA Contact: | YongkuiGuo <yoguo> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9.0 | CC: | lersek, mxie, rjones, roy.lemmon, tyan, tzheng, virt-maint, vwu |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | libguestfs-1.48.4-4.el9 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-05-09 07:36:38 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: | |||
| Bug Blocks: | 2149811, 2149863 | ||
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. (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. *** Bug 2068173 has been marked as a duplicate of this bug. *** 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? 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. Will your patch also include a fix for BZ 2068173? Please don't comment on unrelated bugs. 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 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 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.
Verified this bug as this bug has been automated and the test case passed in the latest nightly compose test. 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 |
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: