Re: Guest Agent issue with 'guest-get-osinfo' command on Windows

["Daniel P. Berrangé" <berrange@redhat.com>]

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>


> 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.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|