[libvirt] [PATCH 0/9] extend virsh domstate to show additional information

[Jiri Denemark]

On Wed, Jul 11, 2018 at 12:49:13 +0200, Bjoern Walk wrote:
> This patch series introduces the ability to save additional information
> for the domain state and exposes this information in virsh domstate.
> 
> For example in the case of QEMU guest panic events, we can provide additional
> information like the crash reason or register state of the domain. This
> information usually gets logged in the domain log but for debugging it is
> useful to have it accessible from the client. Therefore, let's introduce a new
> public API function, virDomainGetStateParams, an extensible version of
> virDomainGetState, which returns the complete state of the domain, including
> newly introduced additional information.
> 
> Let's also extend virsh domstate and introduce a new parameter --info to show
> the domain state, reason and additional information when available.
> 
>     virsh # domstate --info guest-1
>     crashed (panicked: disabled-wait core='1' psw-mask='0x000000000010f146' \
>          psw-addr='0x0002000180000000')

I was thinking you introduced a new API with typed parameters so that
you can return each part of the info string as a separate parameter with
a defined semantics. But I was wrong, you're just adding a new opaque
string with more details about the reason. In that case typed parameters
don't actually bring any additional value, they just complicate the
usage of the API. The following prototype would be much better

    int
    virDomainGetState...(virDomainPtr domain,
                         int *state,
                         int *reason,
                         char **info,
                         unsigned int flags)

On the other hand, is an opaque string really a good idea? It makes the
additional info usable only for being shown to the user rather than
being processed by an upper management layer. That's probably fine for
crashed state, but perhaps other states would want to return something
that is supposed to be processed. Maybe I'm just overthinking this, but
I'd like to avoid having to add yet another API later. So the API could
have the following prototype

    int
    virDomainGetStateParams(virDomainPtr domain,
                            int *state,
                            int *reason,
                            virTypedParameterPtr *params,
                            int *nparams,
                            unsigned int flags)

I'd still keep the state and reason parameters directly to make the API
easier to use.

Jirka