https://bugzilla.redhat.com/show_bug.cgi?id=2012658
We don't currently detect the correct version for Windows 11 (client,
server is OK). After some discussion it turns out the accepted way to
do this is to look at the Windows build ID.
So add some code in the daemon to grab the build ID from
For Windows Client, we can only distinguish between Windows 10 and
Windows 11 using the build ID. The product name in both cases is
"Windows 10 ", apparently intentionally.
References:
https://learn.microsoft.com/en-us/answers/questions/586619/windows-11-build-ver-is-still-10022000194.html
Add an API to return the build ID of the guest. This to allow a
future change to be able to distinguish between Windows 10 and Windows 11
which can only be done using the build ID.
For Windows we can read the CurrentBuildNumber key from the registry.
For Linux there happens to be a BUILD_ID
libguestfs 1.49.8 adds a new API to read the build ID from guests
(especially for Windows). If the new API is available and if it
returns a string other than "unknown", then print it in virt-inspector
output.
---
inspector/inspector.c| 8
inspector/virt-inspector.rng | 1 +
2
Windows versions >= 10 no longer use the NT major.minor numbering
scheme (it is fixed at 10.0). Libguestfs >= 1.49.8 can distinguish
these versions and it sets correctly, so use that instead.
After this change the OVF will contain:
Windows 10 Pro
windows_11
which is strange, but
On Thu, Dec 01, 2022 at 10:34:09AM +, Richard W.M. Jones wrote:
> For Windows Client, we can only distinguish between Windows 10 and
> Windows 11 using the build ID. The product name in both cases is
> "Windows 10 ", apparently intentionally.
>
> References:
>
If the virtio-win ISO contains drivers for Windows 11, Windows 2019 or
Windows 2022, and the guest matches these, then copy in the right
drivers. For this to work you will need libguestfs >= 1.49.8 which
allows osinfo to be used to detect Windows versions >= 10.
Side note: virtio-win uses a mix
