From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Konstantin Kostiuk <konstantin@daynix.com>,
Developers <qemu-devel@nongnu.org>
Cc: "Vladimir Sementsov-Ogievskiy" <vsementsov@virtuozzo.com>,
"Michael Roth" <michael.roth@amd.com>,
"Yuri Benditovich" <yuri.benditovich@daynix.com>,
"Tomas Golembiovsky" <tgolembi@redhat.com>,
"Yan Vugenfirer" <yan@daynix.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>
Subject: Re: Guest Agent issue with 'guest-get-osinfo' command on Windows
Date: Thu, 2 Sep 2021 15:11:56 +0200 [thread overview]
Message-ID: <b09b85ed-1c7a-72fc-b4fa-7930f8c44c9f@redhat.com> (raw)
In-Reply-To: <CAJ28CFSFEatxgfvUE3gvnFBVX7GrqMwk0+t1foFfNzDu7bwv3A@mail.gmail.com>
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
next prev parent reply other threads:[~2021-09-02 13:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-02 12:36 Guest Agent issue with 'guest-get-osinfo' command on Windows Konstantin Kostiuk
2021-09-02 13:11 ` Philippe Mathieu-Daudé [this message]
2021-09-02 13:15 ` Philippe Mathieu-Daudé
2021-09-02 13:24 ` Marc-André Lureau
2021-09-02 13:36 ` Daniel P. Berrangé
2021-09-02 13:55 ` Richard W.M. Jones
2021-09-02 14:12 ` Konstantin Kostiuk
2021-09-02 14:54 ` Marc-André Lureau
2021-09-06 15:45 ` Konstantin Kostiuk
2021-09-06 15:59 ` Richard W.M. Jones
2021-09-06 16:30 ` Konstantin Kostiuk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b09b85ed-1c7a-72fc-b4fa-7930f8c44c9f@redhat.com \
--to=philmd@redhat.com \
--cc=konstantin@daynix.com \
--cc=marcandre.lureau@redhat.com \
--cc=michael.roth@amd.com \
--cc=qemu-devel@nongnu.org \
--cc=tgolembi@redhat.com \
--cc=vsementsov@virtuozzo.com \
--cc=yan@daynix.com \
--cc=yuri.benditovich@daynix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).