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: Daniel P. Berrange
Subject: Re: [Qemu-devel] QMP: RFC: I/O error info & query-stop-reason
Date: Thu, 2 Jun 2011 10:06:32 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Jun 01, 2011 at 04:35:03PM -0500, Anthony Liguori wrote:
> 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?

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.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



reply via email to

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