qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] QMP: RFC: I/O error info & query-stop-reason
Date: Wed, 01 Jun 2011 16:35:03 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10

On 06/01/2011 04:12 PM, Luiz Capitulino wrote:
Hi there,

There are people who want to use QMP for thin provisioning. That's, the VM is
started with a small storage and when a no space error is triggered, more space
is allocated and the VM is put to run again.

QMP has two limitations that prevent people from doing this today:

1. The BLOCK_IO_ERROR doesn't contain error information

2. Considering we solve item 1, we still have to provide a way for clients
    to query why a VM stopped. This is needed because clients may miss the
    BLOCK_IO_ERROR event or may connect to the VM while it's already stopped

A proposal to solve both problems follow.

A. BLOCK_IO_ERROR information
-----------------------------

We already have discussed this a lot, but didn't reach a consensus. My solution
is quite simple: to add a stringfied errno name to the BLOCK_IO_ERROR event,
for example (see the "reason" key):

{ "event": "BLOCK_IO_ERROR",
    "data": { "device": "ide0-hd1",
              "operation": "write",
              "action": "stop",
              "reason": "enospc", }

you can call the reason whatever you want, but don't call it stringfied errno name :-)

In fact, just make reason "no space".

    "timestamp": { "seconds": 1265044230, "microseconds": 450486 } }

Valid error reasons could be: "enospc", "eio", etc.

No etc :-)  Error reasons should we be well known and well documented.

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?

Regards,

Anthony Liguori



reply via email to

[Prev in Thread] Current Thread [Next in Thread]