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

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

[Konstantin Kostiuk]

[-- Attachment #1: Type: text/plain, Size: 2189 bytes --]

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")
= 10, so to get pretty-name the guest agent uses a conversion matrix
between Windows build and name (
https://github.com/qemu/qemu/blob/59a89510b62ec23dbeab8b02fa4e3526e353d8b6/qga/commands-win32.c#L2170
).

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.

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)

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

Best wishes,
Kostiantyn Kostiuk

[-- Attachment #2: Type: text/html, Size: 3435 bytes --]

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

[Philippe Mathieu-Daudé]

On 9/2/21 2:36 PM, 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=1998919>
> https://bugzilla.redhat.com/show_bug.cgi?id=1972070
> <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") = 10, so to get pretty-name the guest agent uses a
> conversion matrix between Windows build and name
> (https://github.com/qemu/qemu/blob/59a89510b62ec23dbeab8b02fa4e3526e353d8b6/qga/commands-win32.c#L2170
> <https://github.com/qemu/qemu/blob/59a89510b62ec23dbeab8b02fa4e3526e353d8b6/qga/commands-win32.c#L2170>).
> 
> 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
> <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.

Sounds good, start with low=high limit then if someone reports
out-of-range we adapt the limit.

BTW instead of burying this in C, I'd store this information in a JSON
file to ease updates.

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

Could this work?

  if ReleaseId:
    return ProductName[ReleaseId];
  else:
    return ProductName[release_id_by_buildnumber(BuildNumber)];

> 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'.
> 
> Best wishes,
> Kostiantyn Kostiuk

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

[Philippe Mathieu-Daudé]

Forgot to Cc Richard & Daniel.

On 9/2/21 3:11 PM, Philippe Mathieu-Daudé wrote:
> On 9/2/21 2:36 PM, 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=1998919>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1972070
>> <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") = 10, so to get pretty-name the guest agent uses a
>> conversion matrix between Windows build and name
>> (https://github.com/qemu/qemu/blob/59a89510b62ec23dbeab8b02fa4e3526e353d8b6/qga/commands-win32.c#L2170
>> <https://github.com/qemu/qemu/blob/59a89510b62ec23dbeab8b02fa4e3526e353d8b6/qga/commands-win32.c#L2170>).
>>
>> 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
>> <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.
> 
> Sounds good, start with low=high limit then if someone reports
> out-of-range we adapt the limit.
> 
> BTW instead of burying this in C, I'd store this information in a JSON
> file to ease updates.
> 
>> 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)
> 
> Could this work?
> 
>   if ReleaseId:
>     return ProductName[ReleaseId];
>   else:
>     return ProductName[release_id_by_buildnumber(BuildNumber)];
> 
>> 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'.
>>
>> Best wishes,
>> Kostiantyn Kostiuk
> 

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

[Marc-André Lureau]

[-- Attachment #1: Type: text/plain, Size: 2614 bytes --]

Hi

On Thu, Sep 2, 2021 at 4:36 PM Konstantin Kostiuk <konstantin@daynix.com>
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")
> = 10, so to get pretty-name the guest agent uses a conversion matrix
> between Windows build and name (
> https://github.com/qemu/qemu/blob/59a89510b62ec23dbeab8b02fa4e3526e353d8b6/qga/commands-win32.c#L2170
> ).
>
> 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.
>
> 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)
>
> In conclusion, I have the next questions:
> What solution we should implement to get the Windows release name?
>


Have you checked the glib implementation?
https://gitlab.gnome.org/GNOME/glib/-/blob/main/glib/gutils.c#L1291

We should probably teach qemu-ga to use g_get_os_info() with glib >= 2.64,
and be consistent with what glib implements (patch it there when necessary)



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

[-- Attachment #2: Type: text/html, Size: 4348 bytes --]

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

[Daniel P. Berrangé]

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

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

[Richard W.M. Jones]

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

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

[Konstantin Kostiuk]

[-- Attachment #1: Type: text/plain, Size: 6235 bytes --]

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.

On Thu, Sep 2, 2021 at 4:55 PM Richard W.M. Jones <rjones@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
>
>

[-- Attachment #2: Type: text/html, Size: 9278 bytes --]

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

[Marc-André Lureau]

[-- Attachment #1: Type: text/plain, Size: 6696 bytes --]

Hi

On Thu, Sep 2, 2021 at 6:16 PM Konstantin Kostiuk <konstantin@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 <rjones@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

[-- Attachment #2: Type: text/html, Size: 10228 bytes --]

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

[Konstantin Kostiuk]

[-- Attachment #1: Type: text/plain, Size: 7871 bytes --]

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.lureau@gmail.com>
wrote:

> Hi
>
> On Thu, Sep 2, 2021 at 6:16 PM Konstantin Kostiuk <konstantin@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 <rjones@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
>

[-- Attachment #2: Type: text/html, Size: 12008 bytes --]

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

[Richard W.M. Jones]

On Mon, Sep 06, 2021 at 06:45:08PM +0300, Konstantin Kostiuk wrote:
> 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.

The important point is, however you get it, return the information as
a libosinfo short value ("win2k22" in this case).

> What do you think about this solution instead of using a conversion matrix?
> What version we should use in this case?

If you need to cover old and new versions of Windows then there's no
good way.  You just need lots of conditionals and to constantly evolve
the code as new versions come out.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

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

[Konstantin Kostiuk]

[-- Attachment #1: Type: text/plain, Size: 1895 bytes --]

On Mon, Sep 6, 2021 at 6:59 PM Richard W.M. Jones <rjones@redhat.com> wrote:

> On Mon, Sep 06, 2021 at 06:45:08PM +0300, Konstantin Kostiuk wrote:
> > 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.
>
> The important point is, however you get it, return the information as
> a libosinfo short value ("win2k22" in this case).
>

To get this string libguestfs just use a set of conditions. Return
"win2k22" if Windows type is 'server'
and ProductName contains 2022.

But as I know guest agent does not returns short name.


>
> > What do you think about this solution instead of using a conversion
> matrix?
> > What version we should use in this case?
>
> If you need to cover old and new versions of Windows then there's no
> good way.  You just need lots of conditionals and to constantly evolve
> the code as new versions come out.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW
>
>

[-- Attachment #2: Type: text/html, Size: 2908 bytes --]