From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52984) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QS3rW-0000Xu-6j for qemu-devel@nongnu.org; Thu, 02 Jun 2011 05:06:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QS3rU-0002wk-8I for qemu-devel@nongnu.org; Thu, 02 Jun 2011 05:06:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31671) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QS3rT-0002wZ-PE for qemu-devel@nongnu.org; Thu, 02 Jun 2011 05:06:40 -0400 Date: Thu, 2 Jun 2011 10:06:32 +0100 From: "Daniel P. Berrange" Message-ID: <20110602090632.GB14571@redhat.com> References: <20110601181255.077fb5fd@doriath> <4DE6B087.6010708@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4DE6B087.6010708@codemonkey.ws> Subject: Re: [Qemu-devel] QMP: RFC: I/O error info & query-stop-reason Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , Stefan Hajnoczi , qemu-devel@nongnu.org, Markus Armbruster , jdenemar@redhat.com, Luiz Capitulino 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 :|