From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:32829)
	by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <hch@lst.de>)
	id 1Qog9I-0003XZ-NS
	for qemu-devel@nongnu.org; Wed, 03 Aug 2011 14:26:33 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <hch@lst.de>) id 1Qog9H-0007fC-Si
	for qemu-devel@nongnu.org; Wed, 03 Aug 2011 14:26:32 -0400
Received: from verein.lst.de ([213.95.11.211]:47072 helo=newverein.lst.de)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <hch@lst.de>)
	id 1Qog9H-0007f7-Lk
	for qemu-devel@nongnu.org; Wed, 03 Aug 2011 14:26:31 -0400
Date: Wed, 3 Aug 2011 20:26:30 +0200
From: Christoph Hellwig <hch@lst.de>
Message-ID: <20110803182630.GA9899@lst.de>
References: <1312384765-721-1-git-send-email-lcapitulino@redhat.com>
	<20110803163131.GA8411@lst.de> <20110803151138.28850d1c@doriath>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20110803151138.28850d1c@doriath>
Subject: Re: [Qemu-devel] [PATCH v2 0/5]: QMP: Proper thin
	provisioning	support
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Luiz Capitulino <lcapitulino@redhat.com>
Cc: kwolf@redhat.com, armbru@redhat.com, aliguori@us.ibm.com, Christoph Hellwig <hch@lst.de>, qemu-devel@nongnu.org

On Wed, Aug 03, 2011 at 03:11:38PM -0300, Luiz Capitulino wrote:
> > > It's already possible for QMP clients to implement this feature by using
> > > the BLOCK_IO_ERROR event. However, the event can be missed. When this
> > > happens QMP clients need a way to query if any block device has hit a
> > > no space condition.
> > 
> > We have a mode where we stop the VM when it hits ENOSPC, and that is
> > the only reliably way to handle it. 
> 
> This series just complements that mode by allowing a mngt application
> to query which device triggered the ENOSPC. Well, that's my intention :)

Oh, so you only plan to use the QMP command post-mortem?  That makes a lot
more sense.  But relying on that fact should also help to simplify the
implementation and make it more robust by storing the error code from
the same place that we stop them VM.