qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] Block layer roadmap on wiki
Date: Mon, 22 Aug 2011 14:04:23 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]