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: Stefan Hajnoczi
Subject: Re: [Qemu-devel] Block layer roadmap on wiki
Date: Mon, 22 Aug 2011 21:31:49 +0100

On Mon, Aug 22, 2011 at 8:04 PM, Anthony Liguori <address@hidden> 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.

> 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



reply via email to

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