From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: KVM call agenda for Apr 27 Date: Tue, 27 Apr 2010 08:03:42 -0500 Message-ID: <4BD6E0AE.8020307@codemonkey.ws> References: <20100426172634.GC15278@x200.localdomain> <4BD5D28C.7080700@codemonkey.ws> <20100426221258.GH15278@x200.localdomain> <4BD61584.9080208@codemonkey.ws> <4BD69D03.2050502@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Chris Wright , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Avi Kivity Return-path: Received: from mail-pv0-f174.google.com ([74.125.83.174]:59426 "EHLO mail-pv0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755602Ab0D0NDr (ORCPT ); Tue, 27 Apr 2010 09:03:47 -0400 Received: by pvg2 with SMTP id 2so1189585pvg.19 for ; Tue, 27 Apr 2010 06:03:47 -0700 (PDT) In-Reply-To: <4BD69D03.2050502@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 04/27/2010 03:14 AM, Avi Kivity wrote: > On 04/27/2010 01:36 AM, Anthony Liguori wrote: >> >> 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. > > Polling for an event that never happens is bad engineering. What > frequency do you poll? you're forcing the user to make a lose-lose > tradeoff. > >> Otherwise, we'll be adding tons of events to qemu that we'll struggle >> to maintain. > > That's not a valid reason to reject a user requirement. We may argue > the requirement is bogus, or that the suggested implementation is > wrong and point in a different direction, but saying that we may have > to add more code in the future due to other requirements is ... well I > can't find a word for it. Polling is the best solution because it offers the most flexibility. Baking the heuristic into qemu just removes flexibility for all consumers. >> >> 2) A block plugin doesn't solve the problem if it's just at the >> BlockDriverState level because it can't interact with qcow2. > > Why not? We have a layered model. guest -> qcow2 -> plugin (sends > event) -> raw-posix. Just need to insert the plugin at the > appropriate layer. All of the qcow2 information is static to the qcow2 driver and I don't think changing that for plugins is a good idea. >> >> 3) For general block plugins, it's probably better to tackle >> userspace block devices. We have CUSE and FUSE already, a BUSE is a >> logical conclusion. > > We also have an nbd client. > > Here's another option: an nbd-like protocol that remotes all > BlockDriver operations except read and write over a unix domain > socket. The open operation returns an fd (SCM_RIGHTS strikes again) > that is used for read and write. This can be used to implement > snapshots over LVM, for example. How does it address the watermark problem? Regards, Anthony Liguori