From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53988) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRt4I-0002xE-83 for qemu-devel@nongnu.org; Wed, 01 Jun 2011 17:35:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QRt4F-0007yR-Nl for qemu-devel@nongnu.org; Wed, 01 Jun 2011 17:35:10 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:49911) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRt4F-0007x6-GX for qemu-devel@nongnu.org; Wed, 01 Jun 2011 17:35:07 -0400 Received: by gwb19 with SMTP id 19so121995gwb.4 for ; Wed, 01 Jun 2011 14:35:06 -0700 (PDT) Message-ID: <4DE6B087.6010708@codemonkey.ws> Date: Wed, 01 Jun 2011 16:35:03 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20110601181255.077fb5fd@doriath> In-Reply-To: <20110601181255.077fb5fd@doriath> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] QMP: RFC: I/O error info & query-stop-reason List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Kevin Wolf , Stefan Hajnoczi , jdenemar@redhat.com, qemu-devel@nongnu.org, Markus Armbruster 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