From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Npjyg-0007Hu-ON for qemu-devel@nongnu.org; Thu, 11 Mar 2010 10:07:10 -0500 Received: from [199.232.76.173] (port=52186 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Npjyf-0007Gq-Sj for qemu-devel@nongnu.org; Thu, 11 Mar 2010 10:07:09 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Npjye-0001BZ-ED for qemu-devel@nongnu.org; Thu, 11 Mar 2010 10:07:09 -0500 Received: from mail-yw0-f189.google.com ([209.85.211.189]:46865) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Npjye-0001BT-6M for qemu-devel@nongnu.org; Thu, 11 Mar 2010 10:07:08 -0500 Received: by ywh27 with SMTP id 27so66244ywh.22 for ; Thu, 11 Mar 2010 07:07:07 -0800 (PST) Message-ID: <4B990718.90409@codemonkey.ws> Date: Thu, 11 Mar 2010 09:07:04 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/3]: BLOCK_WATERMARK QMP event References: <1268175216-3600-1-git-send-email-lcapitulino@redhat.com> <4B96D4F1.80405@codemonkey.ws> <4B975B0A.1030502@redhat.com> <4B980D26.8070000@codemonkey.ws> <4B98AB17.8080506@redhat.com> <4B98FBE8.5050708@codemonkey.ws> <4B990507.5090101@redhat.com> In-Reply-To: <4B990507.5090101@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Kevin Wolf , uril@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino On 03/11/2010 08:58 AM, Avi Kivity wrote: > On 03/11/2010 04:19 PM, Anthony Liguori wrote: >> >>> But honestly, while I do understand your point, this feels like a hack >>> to work around shortcomings of an interface. So what we need to decide >>> is which criterion outweighs the other in practice. >> >> If I understand the use case correctly, what this really boils down >> to is that you want to create a growable image on top of a >> non-growable device. The management tool then deals with growth >> using this interface. >> >> I'm somewhat inclined to suggest that the proper way to support this >> is to teach qemu how to grow the LVM volume like it would grow any >> normal file. > > Interesting. Could use a helper or helper.so, or a new block format > driver (block/lvm.c). I've suggested plugins for the block drivers in the past. I don't think it was well received. > Still, if management is actually interested in the change, not just > to grow the volume (perhaps to handle out-of-space, or to check > against a global disk low condition), the helper/driver then needs to > communicate with the management system, which is awkward. The management system can poll information from the block driver. Polling is not always evil :-) Regards, Anthony Liguori > > I guess it's workable though. >