Hi All,
I reviewed glib, libguestfs, and libosinfo tools. All tools read the registry to get information about Windows but read different registry values. All information is returned in a localized form.
Related key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion
We can get 'pretty-name' from 'ProductName' value (all tools use it).
About 'version' there is three variant:
1. Set 'version' equals to 'kernel-version'. libguestfs and libosinfo have this behavior.
2. Read 'version' from 'ReleaseId' value. glib has this behavior. In the case of Windows Server 2022, 'ReleaseId' equals 2009.
3. Read 'version' from 'DisplayVersion' value. In the case of Windows Server 2022, 'DisplayVersion' equals 21H2.
What do you think about this solution instead of using a
conversion matrix?
What version we should use in this case?
Best wishes,
Kostiantyn Kostiuk
Hi
I tried to use glib to get OS info. Glib provide 3 values with version about Windows:
g_get_os_info(G_OS_INFO_KEY_PRETTY_NAME)
g_get_os_info(G_OS_INFO_KEY_VERSION)
g_get_os_info(G_OS_INFO_KEY_VERSION_ID)
Output for Windows Server 2019:
PRETTY_NAME = Windows 10 Server 1809
VERSION = 10 Server 1809
VERSION_ID = 10_server_1809
Output for Windows Server 2022:
PRETTY_NAME = Windows 10 Server 2009
VERSION = 10 Server 2009
VERSION_ID = 10_server_2009
So, for now, we can't use glib directly.
Ah apparently there is a bug about it:
(we should aim for reusing glib functions, imho)
On Thu, Sep 02, 2021 at 02:36:51PM +0100, Daniel P. Berrangé wrote:
> On Thu, Sep 02, 2021 at 03:36:01PM +0300, Konstantin Kostiuk wrote:
> > Hi Team,
> >
> > We have several bugs related to 'guest-get-osinfo' command in Windows Guest
> > Agent:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1998919
> > https://bugzilla.redhat.com/show_bug.cgi?id=1972070
> >
> > This command returns the following data:
> > {
> > "name": "Microsoft Windows",
> > "kernel-release": "20344",
> > "version": "N/A",
> > "variant": "server",
> > "pretty-name": "Windows Server 2022 Datacenter",
> > "version-id": "N/A",
> > "variant-id": "server",
> > "kernel-version": "10.0",
> > "machine": "x86_64",
> > "id": "mswindows"
> > }
> >
> > The problem is with "version" and "pretty-name". Windows Server
> > 2016/2019/2022 and Windows 11 have the same MajorVersion ("kernel-version")
>
> Yes, this is a long standing issue with version mapping Windows
> guests, to which no one has ever come up with a nice solution
> that I know of.
>
> In libosinfo database, we just report the kernel version as the
> OS version, and accept the fact that there's a clash in version
> between various Windows products.
>
> https://gitlab.com/libosinfo/osinfo-db/-/blob/master/data/os/microsoft.com/win-2k19.xml.in
>
> https://gitlab.com/libosinfo/osinfo-db/-/blob/master/data/os/microsoft.com/win-10.xml.in
>
> Apps that need to distinguish simply have to look at the
> product name, even if this causes localization pain.
>
> Similarly in libguestfs, the virt-inspector tool just reports
> the kernel version, and product name from the registry:
>
> # virt-inspector -d win2k8r2
> <?xml version="1.0"?>
> <operatingsystems>
> <operatingsystem>
> <root>/dev/sda2</root>
> <name>windows</name>
> <arch>x86_64</arch>
> <distro>windows</distro>
> <product_name>Windows Server 2008 R2 Standard</product_name>
> <product_variant>Server</product_variant>
> <major_version>6</major_version>
> <minor_version>1</minor_version>
>
>
> # virt-inspector -d win10x64
> <?xml version="1.0"?>
> <operatingsystems>
> <operatingsystem>
> <root>/dev/sda2</root>
> <name>windows</name>
> <arch>x86_64</arch>
> <distro>windows</distro>
> <product_name>Windows 10 Pro</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-GR8HTR3</hostname>
> <osinfo>win10</osinfo>
We actually try to turn it into a libosinfo compatible short string as
you can see from Dan's second example above and this code:
https://github.com/libguestfs/libguestfs/blob/master/lib/inspect-osinfo.c
Which is I think what every tool should return. libosinfo is the only
project that attempts to classify a broad range of OSes and is
constantly being updated.
> > This solution has several problems: need to update the conversion matrix
> > for each Windows build, one Windows name can have different build numbers.
> > For example, Windows Server 2022 (preview) build number is 20344, Windows
> > Server 2022 build number is 20348.
> >
> > There are two possible solutions:
> > 1. Use build number range instead of one number. Known implementation
> > issue: Microsoft provides a table (
> > https://docs.microsoft.com/en-Us/windows-server/get-started/windows-server-release-info)
> > only with stable build numbers. So, we exactly don't know the build number
> > range.
>
> Yep, this looks troublesome when considering non-GA releases.
>
> > 2. We can read this string from the registry
> > (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion). Known
> > implementation issues: ProductName value is localized (in a Russian version
> > of Windows, the word "Microsoft' is translated), so we should ignore it.
> > ReleaseId value does not equal to Windows Server version (for Windows
> > Server 2019, ReleaseId is 1809)
>
> This reg key is what libguestfs reports IIUC
>
> https://github.com/libguestfs/libguestfs/blob/master/daemon/inspect_fs_windows.ml#L227
>
> > In conclusion, I have the next questions:
> > What solution we should implement to get the Windows release name?
> > Does someone know how end-users use this information? Should it be English
> > only or it can be localized? Should we have exactly the same output as now?
> > What should we do with the 'Standard' server edition? Currently, the guest
> > agent always returns 'Datacenter'.
>
> This is equiv ot libguestfs' "product variant" data,w hich it gets
> from InstallationType registry key
>
> https://github.com/libguestfs/libguestfs/blob/master/daemon/inspect_fs_windows.ml#L259
>
> Personally I think there's value in having consistent treatment of this
> info across qemu guest agent and libguestfs / libosinfo.
Agree.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
Marc-André Lureau