From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35277) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvVTY-0006R7-9r for qemu-devel@nongnu.org; Mon, 22 Aug 2011 10:27:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QvVTT-0000CU-V8 for qemu-devel@nongnu.org; Mon, 22 Aug 2011 10:27:40 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]:36482) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvVTT-0000AZ-Lp for qemu-devel@nongnu.org; Mon, 22 Aug 2011 10:27:35 -0400 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e32.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7MEJg0q005348 for ; Mon, 22 Aug 2011 08:19:42 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7MERKqM094136 for ; Mon, 22 Aug 2011 08:27:23 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7M8RF2S001134 for ; Mon, 22 Aug 2011 02:27:15 -0600 Date: Mon, 22 Aug 2011 09:27:12 -0500 From: Ryan Harper Message-ID: <20110822142712.GR5792@us.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] Block layer roadmap on wiki List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , qemu-devel , Christoph Hellwig * Stefan Hajnoczi [2011-08-22 08:35]: > At KVM Forum Kevin, Christoph, and I had an opportunity to get > together for a Block Layer BoF. We went through the recent "roadmap" > mailing list thread and touched on each proposed feature. > > Here is the block layer roadmap wiki page: > http://wiki.qemu.org/BlockRoadmap > > Kevin: I have moved the runtime WCE toggling to QEMU 1.0 since you > mentioned you want it for the next release. > > My main take-away from the BoF was that integrating support for host > block devices and storage appliances will allow us to reduce the > amount of effort spent on image formats. In order to make image > formats support the desired features and performance we end up > implementing much of the storage stack and file systems in userspace - > code that is duplicated and cannot take advantage of the existing > storage stack. +1 > > Storage management features are not just available in remote SAN and > NAS appliances anymore. For local storage, btrfs has file-level > clones and thin-dev is significantly improving LVM snapshots. > > Thin-dev is bringing a much more efficient and scalable snapshot model > to LVM. This device-mapper feature will make LVM attractive for high > performance I/O without giving up snapshot and clone features. It > also supports cloning off block devices that are not in the pool (e.g. > external storage, much like QEMU's backing files feature): > https://github.com/jthornber/linux-2.6/tree/thin-dev > > This will not replace image formats overnight because image formats > are still widely used and will continue to be a useful for > transferring and sharing disk images. But focussing on the larger Any thoughts on how to make this easily usable for LVM? If there were an export/import to/from file to LVM? is that sufficient? Anything like this in existence? > storage stack where either local LVM, btrfs, or storage appliances do > the storage management means we exploit those options instead of > implementing equivalent functionality ourselves. QEMU then runs with > plain old raw in more cases. > > Stefan -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh@us.ibm.com