Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm

[Avi Kivity <avi@redhat.com>]

On 05/25/2010 04:29 PM, Anthony Liguori wrote:
>> The current situation is that those block format drivers only exist 
>> in qemu.git or as patches.  Surely that's even more unhappiness.
>>
>> Confusion could be mitigated:
>>
>>   $ qemu -module my-fancy-block-format-driver.so
>>   my-fancy-block-format-driver.so does not support this version of 
>> qemu (0.19.2).  Please contact 
>> my-fancy-block-format-driver-devel@example.org.
>>
>> The question is how many such block format drivers we expect.  We now 
>> have two in the pipeline (ceph, sheepdog), it's reasonable to assume 
>> we'll want an lvm2 driver and btrfs driver.  This is an area with a 
>> lot of activity and a relatively simply interface.
>
>
> If we expose a simple interface, I'm all for it.  But BlockDriver is 
> not simple and things like the snapshoting API need love.
>
> Of course, there's certainly a question of why we're solving this in 
> qemu at all.  Wouldn't it be more appropriate to either (1) implement 
> a kernel module for ceph/sheepdog if performance matters 

We'd need a kernel-level generic snapshot API for this eventually.

> or (2) implement BUSE to complement FUSE and CUSE to enable proper 
> userspace block devices.

Likely slow due do lots of copying.  Also needs a snapshot API.

(ABUSE was proposed a while ago by Zach).

> If you want to use a block device within qemu, you almost certainly 
> want to be able to manipulate it on the host using standard tools 
> (like mount and parted) so it stands to reason that addressing this in 
> the kernel makes more sense.

qemu-nbd also allows this.

This reasoning also applies to qcow2, btw.

-- 
error compiling committee.c: too many arguments to function