Re: [Qemu-devel] Block layer roadmap on wiki

[Ryan Harper <ryanh@us.ibm.com>]

* Stefan Hajnoczi <stefanha@gmail.com> [2011-08-22 15:32]:
> On Mon, Aug 22, 2011 at 8:04 PM, Anthony Liguori <anthony@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
ryanh@us.ibm.com