From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58933) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSC9N-00048p-9B for qemu-devel@nongnu.org; Thu, 02 Jun 2011 13:57:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QSC9L-0007jP-0X for qemu-devel@nongnu.org; Thu, 02 Jun 2011 13:57:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12485) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSC9K-0007ir-HO for qemu-devel@nongnu.org; Thu, 02 Jun 2011 13:57:38 -0400 Date: Thu, 2 Jun 2011 14:57:30 -0300 From: Luiz Capitulino Message-ID: <20110602145730.4c80d668@doriath> In-Reply-To: <4DE6B087.6010708@codemonkey.ws> References: <20110601181255.077fb5fd@doriath> <4DE6B087.6010708@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 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 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 }