[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guest Agent issue with 'guest-get-osinfo' command on Windows
From: |
Daniel P . Berrangé |
Subject: |
Re: Guest Agent issue with 'guest-get-osinfo' command on Windows |
Date: |
Thu, 2 Sep 2021 14:36:51 +0100 |
User-agent: |
Mutt/2.0.7 (2021-05-04) |
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 :|
- Guest Agent issue with 'guest-get-osinfo' command on Windows, Konstantin Kostiuk, 2021/09/02
- Re: Guest Agent issue with 'guest-get-osinfo' command on Windows, Philippe Mathieu-Daudé, 2021/09/02
- Re: Guest Agent issue with 'guest-get-osinfo' command on Windows, Marc-André Lureau, 2021/09/02
- Re: Guest Agent issue with 'guest-get-osinfo' command on Windows,
Daniel P . Berrangé <=
- Re: Guest Agent issue with 'guest-get-osinfo' command on Windows, Richard W.M. Jones, 2021/09/02
- Re: Guest Agent issue with 'guest-get-osinfo' command on Windows, Konstantin Kostiuk, 2021/09/02
- Re: Guest Agent issue with 'guest-get-osinfo' command on Windows, Marc-André Lureau, 2021/09/02
- Re: Guest Agent issue with 'guest-get-osinfo' command on Windows, Konstantin Kostiuk, 2021/09/06
- Re: Guest Agent issue with 'guest-get-osinfo' command on Windows, Richard W.M. Jones, 2021/09/06
- Re: Guest Agent issue with 'guest-get-osinfo' command on Windows, Konstantin Kostiuk, 2021/09/06