From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42272) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvZnP-0006qh-LI for qemu-devel@nongnu.org; Mon, 22 Aug 2011 15:04:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QvZnO-0001cG-Ax for qemu-devel@nongnu.org; Mon, 22 Aug 2011 15:04:27 -0400 Received: from mail-gx0-f173.google.com ([209.85.161.173]:62034) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvZnO-0001cB-2h for qemu-devel@nongnu.org; Mon, 22 Aug 2011 15:04:26 -0400 Received: by gxk26 with SMTP id 26so4506985gxk.4 for ; Mon, 22 Aug 2011 12:04:25 -0700 (PDT) Message-ID: <4E52A837.4080809@codemonkey.ws> Date: Mon, 22 Aug 2011 14:04:23 -0500 From: Anthony Liguori MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 On 08/22/2011 08:34 AM, Stefan Hajnoczi wrote: > 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. The flip side is, tighter integration either makes features hard to consume or makes QEMU enter a space it currently hasn't. Many features require root privileges to configure and a system-wide scope. That's not QEMU today. In addition, it makes QEMU tied to a specific platform (most likely Linux). None of this is especially bad I guess, but none of it is a simple problem. You could certainly rm -rf block/* and still be able to accomplish much of what's done today but it would be extremely painful to do in practice. We have to find a balance of not reinventing things and making sure that simple things are simple to do. That may require tighter integration and more focus on the higher up pieces in the stack to really enable this. Regards, Anthony Liguori > > 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 > 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 >