From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] Re: KVM call agenda for Apr 27 Date: Tue, 27 Apr 2010 08:10:01 -0500 Message-ID: <4BD6E229.60501@codemonkey.ws> References: <20100426172634.GC15278@x200.localdomain> <4BD5D28C.7080700@codemonkey.ws> <20100426221258.GH15278@x200.localdomain> <4BD61584.9080208@codemonkey.ws> <4BD6A61C.3010100@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Chris Wright , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Kevin Wolf Return-path: Received: from mail-pv0-f174.google.com ([74.125.83.174]:54243 "EHLO mail-pv0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753834Ab0D0NKI (ORCPT ); Tue, 27 Apr 2010 09:10:08 -0400 Received: by pvg2 with SMTP id 2so1196226pvg.19 for ; Tue, 27 Apr 2010 06:10:07 -0700 (PDT) In-Reply-To: <4BD6A61C.3010100@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 04/27/2010 03:53 AM, Kevin Wolf wrote: > Am 27.04.2010 00:36, schrieb Anthony Liguori: > >> On 04/26/2010 05:12 PM, Chris Wright wrote: >> >>> * Anthony Liguori (anthony@codemonkey.ws) wrote: >>> >>> >>>> On 04/26/2010 12:26 PM, Chris Wright wrote: >>>> >>>> >>>>> Please send in any agenda items you are interested in covering. >>>>> >>>>> While I don't expect it to be the case this week, if we have a >>>>> lack of agenda items I'll cancel the week's call. >>>>> >>>>> >>>> - qemu management interface (and libvirt) >>>> - stable tree policy (push vs. pull and call for stable volunteers) >>>> >>>> >>> block plug in (follow-on from qmp block watermark) >>> >>> >> A few comments: >> >> 1) The problem was not block watermark itself but generating a >> notification on the watermark threshold. It's a heuristic and should be >> implemented based on polling block stats. Otherwise, we'll be adding >> tons of events to qemu that we'll struggle to maintain. >> > Polling just feels completely wrong. You're almost guaranteed to poll in > the wrong intervals because depending on what the guest is doing you > might need it every couple of seconds (installation) or you may not need > it in days (just working on a fully allocated image). > The event basically boils down to: when some threshold is reached, raise an event. What statistics go into this computation and what algorithm is used to compute the threshold depends on the management tool. The memory ballooning daemon we're developing basically does nothing but this. It monitors stats from the guest to generate events when we've reached a certain memory condition that will likely require some action (like ballooning). Why would we do the block watermarking in qemu and not do the ballooning heuristics too? I know of quite a few tools that all do some form of this. >> 2) A block plugin doesn't solve the problem if it's just at the >> BlockDriverState level because it can't interact with qcow2. >> > There's no interaction with qcow2 needed, it would just need to remember > the highest offset it was requested to read or write. But I'd really > hate to stick another protocol between qcow2 and file. > > It doesn't solve the problem nicely though because it still needs to > generate some event which is not present in a normal qemu without the > plugin. > Polling is really the right solution. It gives the management tool ultimate flexibility in tweaking the heuristics as they see fit. Regards, Anthony Liguori > Kevin >