Re: [Qemu-devel] QMP: RFC: I/O error info & query-stop-reason

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/02/2011 08:24 AM, Jiri Denemark wrote:
> On Thu, Jun 02, 2011 at 08:08:35 -0500, Anthony Liguori wrote:
>> On 06/02/2011 04:06 AM, Daniel P. Berrange wrote:
>>>>> B. query-stop-reason
>>>>> --------------------
>>>>>
>>>>> I also have a simple solution for item 2. The vm_stop() accepts a reason
>>>>> argument, so we could store it somewhere and return it as a string, like:
>>>>>
>>>>> ->    { "execute": "query-stop-reason" }
>>>>> <- { "return": { "reason": "user" } }
>>>>>
>>>>> Valid reasons could be: "user", "debug", "shutdown", "diskfull" (hey,
>>>>> this should be "ioerror", no?), "watchdog", "panic", "savevm", "loadvm",
>>>>> "migrate".
>>>>>
>>>>> Also note that we have a STOP event. It should be extended with the
>>>>> stop reason too, for completeness.
>>>>
>>>>
>>>> Can we just extend query-block?
>>>
>>> Primarily we want 'query-stop-reason' to tell us what caused the VM
>>> CPUs to stop. If that reason was 'ioerror', then 'query-block' could
>>> be used to find out which particular block device(s) caused the IO
>>> error to occurr&   get the "reason" that was in the BLOCK_IO_ERROR
>>> event.
>>
>> My concern is that we're over abstracting here.  We're not going to add
>> additional stop reasons in the future.
>>
>> Maybe just add an 'io-error': True to query-state.
>
> Sure, adding a new field to query-state response would work as well. And it
> seems like a good idea to me since one already needs to call query-status to
> check if CPUs are stopped or not so it makes sense to incorporate the
> additional information there as well. And if you want to be safe for the
> future, the new field doesn't have to be boolean 'io-error' but it can be the
> string 'reason' which Luiz suggested above.


String enumerations are a Bad Thing.  It's impossible to figure out what 
strings are valid and it lacks type safety.

Adding more booleans provides better type safety, and when we move to 
QAPI with a queryable schema, provides a way to figure out exactly what 
combinations are supported by QEMU.

Regards,

Anthony Liguori

>
> Jirka
>