From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44218) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTZZ0-00081O-HT for qemu-devel@nongnu.org; Mon, 06 Jun 2011 09:09:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QTZYx-00048j-GX for qemu-devel@nongnu.org; Mon, 06 Jun 2011 09:09:50 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:47540) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTZYw-00048P-FI for qemu-devel@nongnu.org; Mon, 06 Jun 2011 09:09:47 -0400 Received: by yia27 with SMTP id 27so483423yia.4 for ; Mon, 06 Jun 2011 06:09:46 -0700 (PDT) Message-ID: <4DECD198.8020206@codemonkey.ws> Date: Mon, 06 Jun 2011 08:09:44 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20110601181255.077fb5fd@doriath> <4DE6B087.6010708@codemonkey.ws> <20110602145730.4c80d668@doriath> <4DE7CFA4.9040300@codemonkey.ws> <20110602150900.7d2657fb@doriath> <4DEC9D07.5080409@redhat.com> In-Reply-To: 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: Markus Armbruster Cc: Kevin Wolf , Stefan Hajnoczi , jdenemar@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino On 06/06/2011 06:27 AM, Markus Armbruster wrote: > Kevin Wolf writes: > >> Am 02.06.2011 20:09, schrieb Luiz Capitulino: >>> 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 } >> >> Splitting up enums into a number of booleans looks like a bad idea to >> me. It makes things more verbose than they should be, and even worse, it >> implies that more than one field could be true. >> >> If this new schema thing doesn't support proper enums, that's something >> that should be changed. >> >>>> >>>> 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. >> >> And I want to add that it's a PITA to handle bug report when the only >> message you get from qemu is "something went wrong". Sorry, that's not >> useful at all. I want to see the real error reason (and at least for >> debugging this means, I want to see the errno value/string). > > And I want it straight, not wrapped in a pile of pseudo-abstractions > that make me go to the source code to figure out how to unwrap them. A set of default logged trace points would be perfect, no? Regards, Anthony Liguori > > [...] >