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

[Anthony Liguori <anthony@codemonkey.ws>]

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
>