From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NpTKr-000738-Qx for qemu-devel@nongnu.org; Wed, 10 Mar 2010 16:20:57 -0500 Received: from [199.232.76.173] (port=36299 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NpTKr-00072B-6Q for qemu-devel@nongnu.org; Wed, 10 Mar 2010 16:20:57 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NpTKp-0005Na-GV for qemu-devel@nongnu.org; Wed, 10 Mar 2010 16:20:56 -0500 Received: from ey-out-1920.google.com ([74.125.78.150]:38883) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NpTKp-0005NW-6K for qemu-devel@nongnu.org; Wed, 10 Mar 2010 16:20:55 -0500 Received: by ey-out-1920.google.com with SMTP id 5so4611582eyb.14 for ; Wed, 10 Mar 2010 13:20:54 -0800 (PST) Message-ID: <4B980D26.8070000@codemonkey.ws> Date: Wed, 10 Mar 2010 15:20:38 -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> In-Reply-To: <4B975B0A.1030502@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: Kevin Wolf Cc: uril@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino On 03/10/2010 02:40 AM, Kevin Wolf wrote: > Am 10.03.2010 00:08, schrieb Anthony Liguori: > >> On 03/09/2010 04:53 PM, Luiz Capitulino wrote: >> >>> Hi, >>> >>> This series is based on a previous series submitted by Uri Lublin: >>> >>> http://lists.gnu.org/archive/html/qemu-devel/2009-03/msg00864.html >>> >>> Details on the patches, except for this question: does it make sense to have >>> a 'low' watermark for block devices? >>> >>> I think it doesn't, then the event (and the monitor accompanying command) >>> should be called BLOCK_HIGH_WATERMARK. But this makes the event very >>> unflexible, so I have called it BLOCK_WATERMARK and added parameters for the >>> high/low watermark type. >>> >>> >> The alternative way to implement this is for a management tool to just >> poll the allocated disk size periodically. >> > Then we need to provide that information using the monitor. As far as I > know, we don't do that yet. Okay, but that's certainly a reasonable thing to add though, no? >> It's no more/less safe than generating an event on a "watermark" because >> the event is still racy with respect to a guest that's writing very >> quickly to the disk. >> > Being racy isn't a problem, a management tool doing this kind of things > needs to use werror=ENOSPC (at least) anyway. The watermark thing, as I > understand it, is only a mechanism to make it less likely that the VM > has to be stopped. > Correct. A management tool could poll every 5 minutes to make the same determination. This approach seems superior to me because it's considerably more flexible. In this particular model, you have one disk on an LVM volume and you need to grow that single disk image when you hit a high water mark. However, an alternative and equally valid model would be an LVM volume containing a file system with multiple disk images for a single guest. In this case, there is no high water mark for an individual disk, but rather, there's a high water mark for the combination of all the disks. You can do both with polling. Ultimately, it comes down to a question of mechanism vs. policy. You're generating an event based on a policy (stat > THRESHOLD) verses providing an event that's a mechanism to implement a policy (VNC client connected). Basically, whenever there's one of more valid choices, it's probably a policy and is better done in a management tool. Regards, Anthony Liguori Regards, Anthony Liguori > Kevin >