* Stefan Hajnoczi <stefa...@gmail.com> [2011-08-22 15:32]: > On Mon, Aug 22, 2011 at 8:04 PM, Anthony Liguori <anth...@codemonkey.ws> > 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. 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. > > 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. > > > In addition, it makes QEMU tied to a specific platform (most likely Linux). > > 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. > > > 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. > > 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. > > > That may require tighter integration and more focus on the higher up pieces > > in the stack to really enable this. > > Yes, exactly. Much of it shouldn't be inside QEMU. > > Stefan -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ry...@us.ibm.com
