From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40755) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvbRI-0007C7-Pk for qemu-devel@nongnu.org; Mon, 22 Aug 2011 16:49:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QvbRG-0007pX-UG for qemu-devel@nongnu.org; Mon, 22 Aug 2011 16:49:44 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]:47217) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvbRG-0007oV-Ov for qemu-devel@nongnu.org; Mon, 22 Aug 2011 16:49:42 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e33.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7MKfYIe017905 for ; Mon, 22 Aug 2011 14:41:34 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p7MKmFh8166400 for ; Mon, 22 Aug 2011 14:48:16 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7MElm9D009299 for ; Mon, 22 Aug 2011 08:47:48 -0600 Date: Mon, 22 Aug 2011 15:48:10 -0500 From: Ryan Harper Message-ID: <20110822204810.GZ5792@us.ibm.com> References: <4E52A837.4080809@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable 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 15:32]: > On Mon, Aug 22, 2011 at 8:04 PM, Anthony Liguori wrote: > > 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. =A0We went through the recent "roadm= ap" > >> 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. =A0In 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 c= onsume > > or makes QEMU enter a space it currently hasn't. =A0Many features req= uire root > > privileges to configure and a system-wide scope. =A0That's not QEMU t= oday. >=20 > QEMU itself should be about emulation and virtualization. Storage > management needs to be done outside of QEMU. Today you can already > take an LVM snapshot - it happens outside of QEMU. It's at the > libvirt level where different storage systems get abstracted (LVM, > directory, iSCSI, etc) and there is a single API/command set to invoke > management functions. But even without libvirt you can do it > yourself, and I think this separation makes sense so that QEMU can be > focussed on running a single VM rather than managing storage. >=20 > > In addition, it makes QEMU tied to a specific platform (most likely L= inux). >=20 > QEMU will still work but certain features might not be available. For > example, this is true today if you're using a storage appliance that > does deduplication - that's a feature you're getting on top of the > emulation/virtualization that QEMU does. But it doesn't tie QEMU to a > particular platform. >=20 > > You could certainly rm -rf block/* and still be able to accomplish mu= ch of > > what's done today but it would be extremely painful to do in practice= . =A0We > > have to find a balance of not reinventing things and making sure that= simple > > things are simple to do. >=20 > We wouldn't rm -rf block/* because we still need qemu-nbd. It > probably makes sense to keep what we have today. I'm talking more > about a shift from writing our own image format to integrating > existing storage support. I think this is a key point. While I do like the idea of keeping QEMU focused on single VM, I think we don't help ourselves by not consuming the hypervisor platform services and integrating/exploiting those features to make using QEMU easier. That said, it does mean that some things like system-wide config and privs are hard and aren't strictly virtualization issues, but that doesn't mean we can't integrate some sort of solution. >=20 > > That may require tighter integration and more focus on the higher up = pieces > > in the stack to really enable this. >=20 > Yes, exactly. Much of it shouldn't be inside QEMU. >=20 > Stefan --=20 Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh@us.ibm.com