From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48164) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSCKS-0006pB-T6 for qemu-devel@nongnu.org; Thu, 02 Jun 2011 14:09:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QSCKQ-0001Jh-Rz for qemu-devel@nongnu.org; Thu, 02 Jun 2011 14:09:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1365) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSCKQ-0001JZ-Dl for qemu-devel@nongnu.org; Thu, 02 Jun 2011 14:09:06 -0400 Date: Thu, 2 Jun 2011 15:09:00 -0300 From: Luiz Capitulino Message-ID: <20110602150900.7d2657fb@doriath> In-Reply-To: <4DE7CFA4.9040300@codemonkey.ws> References: <20110601181255.077fb5fd@doriath> <4DE6B087.6010708@codemonkey.ws> <20110602145730.4c80d668@doriath> <4DE7CFA4.9040300@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Anthony Liguori Cc: Kevin Wolf , Stefan Hajnoczi , jdenemar@redhat.com, qemu-devel@nongnu.org, Markus Armbruster On Thu, 02 Jun 2011 13:00:04 -0500 Anthony Liguori wrote: > On 06/02/2011 12:57 PM, Luiz Capitulino wrote: > > On Wed, 01 Jun 2011 16:35:03 -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". > > > > You mean, we should do: > > > > "reason": "no space" > > > > Or that we should make it a boolean, like: > > > > "no space": true > > > Do we need reason in BLOCK_IO_ERROR if query-block returns this information? True, no. > > I'm ok with either way. But in case you meant the second one, I guess > > we should make "reason" a dictionary so that we can group related > > information when we extend the field, for example: > > > > "reason": { "no space": false, "no permission": true } > > Why would we ever have "no permission"? It's an I/O error. I have a report from a developer who was getting the BLOCK_IO_ERROR event and had to debug qemu to know the error cause, it turned out to be no permission. > Part of my argument for not having reason is I don't think we actually > need to be this generic. I think we're over abstracting. I'm quite sure we'll want to add new errors reasons in the near future.