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

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

* Stefan Hajnoczi <stefanha@gmail.com> [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