From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58178) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRsiv-0005o6-3U for qemu-devel@nongnu.org; Wed, 01 Jun 2011 17:13:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QRsit-0002jd-FA for qemu-devel@nongnu.org; Wed, 01 Jun 2011 17:13:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43900) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRsis-0002jM-Rq for qemu-devel@nongnu.org; Wed, 01 Jun 2011 17:13:03 -0400 Date: Wed, 1 Jun 2011 18:12:55 -0300 From: Luiz Capitulino Message-ID: <20110601181255.077fb5fd@doriath> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] QMP: RFC: I/O error info & query-stop-reason List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Kevin Wolf , Stefan Hajnoczi , jdenemar@redhat.com, Markus Armbruster 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", } "timestamp": { "seconds": 1265044230, "microseconds": 450486 } } Valid error reasons could be: "enospc", "eio", etc. 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.