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 On Thu, Sep 2, 2021 at 5:54 PM Marc-André Lureau <marcandre.lur...@gmail.com> wrote: > Hi > > On Thu, Sep 2, 2021 at 6:16 PM Konstantin Kostiuk <konstan...@daynix.com> > wrote: > >> 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: > https://gitlab.gnome.org/GNOME/glib/-/issues/2443 > > (we should aim for reusing glib functions, imho) > > >> On Thu, Sep 2, 2021 at 4:55 PM Richard W.M. Jones <rjo...@redhat.com> >> wrote: >> >>> 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 >
