[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2] qemu-ga: add guest-get-osinfo command
From: |
Vinzenz Feenstra |
Subject: |
Re: [Qemu-devel] [PATCH v2] qemu-ga: add guest-get-osinfo command |
Date: |
Fri, 24 Mar 2017 10:48:43 +0100 |
> On Mar 23, 2017, at 3:58 PM, Eric Blake <address@hidden> wrote:
>
> On 03/16/2017 09:50 AM, Vinzenz 'evilissimo' Feenstra wrote:
>> From: Vinzenz Feenstra <address@hidden>
>>
>> Add a new 'guest-get-osinfo' command for reporting basic information of
>> the guest operating system (hereafter just 'OS'). This information
>> includes the type of the OS, the version, and the architecture.
>> Additionally reported would be a name, distribution type and kernel
>> version where applicable.
>>
>> Here an example for a Fedora 25 VM:
>>
>> $ virsh -c qemu:////system qemu-agent-command F25 \
>> '{ "execute": "guest-get-osinfo" }'
>> {"return":{"arch":"x86_64","codename":"Server Edition","version":"25",
>> "kernel":"4.8.6-300.fc25.x86_64","type":"linux","distribution":"Fedora"}}
>>
>> And an example for a Windows 2012 R2 VM:
>>
>> $ virsh -c qemu:////system qemu-agent-command Win2k12R2 \
>> '{ "execute": "guest-get-osinfo" }'
>> {"return":{"arch":"x86_64","codename":"Win 2012 R2",
>> "version":"6.3","kernel":"","type":"windows","distribution":""}}
>>
>> Signed-off-by: Vinzenz Feenstra <address@hidden>
>> ---
>
> Let's make sure we get the interface right, before I even bother looking
> at the code.
Sure
>
>> +++ b/qga/qapi-schema.json
>> @@ -1042,3 +1042,43 @@
>> 'data': { 'path': 'str', '*arg': ['str'], '*env': ['str'],
>> '*input-data': 'str', '*capture-output': 'bool' },
>> 'returns': 'GuestExec' }
>> +
>> +##
>> +# @GuestOSType:
>> +#
>> +# @linux: Indicator for linux distributions
>> +# @windows: Indicator for windows versions
>> +# @other: Indicator for any other operating system that is not yet
>> +# explicitly supported
>> +#
>> +# Since: 2.10
>> +##
>> +{ 'enum': 'GuestOSType', 'data': ['linux', 'windows', 'other'] }
>> +
>> +##
>> +# @GuestOSInfo:
>> +#
>> +# @version: OS version, e.g. 25 for FC25 etc.
>> +# @distribution: Fedora, Ubuntu, Debian, CentOS...
>> +# @codename: Code name of the OS. e.g. Ubuntu has Xenial Xerus etc.
>> +# @arch: Architecture of the OS e.g. x86, x86_64, ppc64, aarch64...
>> +# @type: Specifies the type of the OS.
>> +# @kernel: Linux kernel version (Might be used by other OS types too).
>> +# May be empty.
>
> Why would it be empty, instead of just omitted?
That’s a relict of v1 where this was still the case and all fields were
supposed to be there all the time.
>
>> +# Since: 2.10
>> +##
>> +{ 'struct': 'GuestOSInfo',
>> + 'data': { '*version': 'str', '*distribution': 'str', '*codename': 'str',
>> + '*arch': 'str', 'type': 'GuestOSType', '*kernel': 'str'} }
>
> So everything except 'type' is optional? Is there anything a client can
> actually rely on being always present?
>
> uname() is probably the lowest-common-denominator interface for
> describing a system (in that it is implemented on more OSs than anything
> else, and Windows information can be mapped to uname concepts). Let's
> compare:
>
> POSIX says:
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_utsname.h.html#tag_13_70
>
> <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_utsname.h.html#tag_13_70>
>
> The <sys/utsname.h> header shall define the structure utsname which
> shall include at least the following members:
>
> char sysname[] Name of this implementation of the operating system.
> char nodename[] Name of this node within the communications
> network to which this node is attached, if any.
> char release[] Current release level of this implementation.
> char version[] Current version level of this release.
> char machine[] Name of the hardware type on which the system is
> running.
>
> So you both have version; your 'arch' maps somewhat to machine, your
> 'type' maps somewhat to sysname, your 'kernel' probably matches release,
> and then you are adding 'distribution' and 'codename' which don't appear
> in uname output. Is it worth naming your members after the uname()
> names, for less confusion?
OK So how about something like this:
{‘struct’: ‘GuestWindowsVersionInfo’,
‘data’: {
‘version’: ‘str’,
‘name’: ‘str’,
} }
{‘struct’: ‘GuestLinuxOSRelease’,
‘data’: {
‘id’: ‘str’,
‘name’: ‘str'
‘*version’: ‘str’,
‘*variant’: ‘str’
‘*codename’: ‘str’
} }
{‘enum’: ‘GuestOSVersionInfo’,
‘data’: {‘linux’: ‘ GuestLinuxOSRelease’,
‘win’: ‘ GuestWindowsVersionInfo’
}}
{ 'struct': 'GuestOSInfo’,
'data': {
‘machine': 'str’,
’sysname': 'GuestOSType’,
‘release': ‘str’,
‘*version_info’: ‘GuestOSVersionInfo’,
} }
>
>> +
>> +##
>> +# @guest-get-osinfo:
>> +#
>> +# Retrieve guest operating system information
>> +#
>> +# Returns: operating system information on success
>> +#
>> +# Since 2.10
>> +##
>> +{ 'command': 'guest-get-osinfo',
>> + 'returns': 'GuestOSInfo' }
>>
>
> --
> Eric Blake eblake redhat com +1-919-301-3266
> Libvirt virtualization library http://libvirt.org <http://libvirt.org/>
- [Qemu-devel] [PATCH] qemu-ga: add guest-get-osinfo command, Vinzenz 'evilissimo' Feenstra, 2017/03/21
- Re: [Qemu-devel] [PATCH] qemu-ga: add guest-get-osinfo command, Eric Blake, 2017/03/21
- Re: [Qemu-devel] [PATCH] qemu-ga: add guest-get-osinfo command, Vinzenz Feenstra, 2017/03/21
- [Qemu-devel] (no subject), Vinzenz 'evilissimo' Feenstra, 2017/03/22
- [Qemu-devel] [PATCH v2] qemu-ga: add guest-get-osinfo command, Vinzenz 'evilissimo' Feenstra, 2017/03/22
- Re: [Qemu-devel] [PATCH v2] qemu-ga: add guest-get-osinfo command, Eric Blake, 2017/03/23
- Re: [Qemu-devel] [PATCH v2] qemu-ga: add guest-get-osinfo command,
Vinzenz Feenstra <=
- Re: [Qemu-devel] [PATCH v2] qemu-ga: add guest-get-osinfo command, Vinzenz Feenstra, 2017/03/28
- Re: [Qemu-devel] [PATCH v2] qemu-ga: add guest-get-osinfo command, Marc-André Lureau, 2017/03/28
- Re: [Qemu-devel] (no subject), Eric Blake, 2017/03/23