From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52361) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSCBn-0004jC-B6 for qemu-devel@nongnu.org; Thu, 02 Jun 2011 14:00:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QSCBk-0008EG-3n for qemu-devel@nongnu.org; Thu, 02 Jun 2011 14:00:10 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:50756) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSCBj-0008Ch-J7 for qemu-devel@nongnu.org; Thu, 02 Jun 2011 14:00:07 -0400 Received: by gyg4 with SMTP id 4so517433gyg.4 for ; Thu, 02 Jun 2011 11:00:06 -0700 (PDT) Message-ID: <4DE7CFA4.9040300@codemonkey.ws> Date: Thu, 02 Jun 2011 13:00:04 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20110601181255.077fb5fd@doriath> <4DE6B087.6010708@codemonkey.ws> <20110602145730.4c80d668@doriath> In-Reply-To: <20110602145730.4c80d668@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/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? > > 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"? 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. Regards, Anthony Liguori