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

[Kevin Wolf <kwolf@redhat.com>]

Am 22.08.2011 23:01, schrieb Anthony Liguori:
> On 08/22/2011 03:48 PM, Ryan Harper wrote:
>> * Stefan Hajnoczi<stefanha@gmail.com>  [2011-08-22 15:32]:
>>> 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.
>>
>> I think this is a key point.  While I do like the idea of keeping QEMU
>> focused on single VM, I think we don't help ourselves by not consuming
>> the hypervisor platform services and integrating/exploiting those
>> features to make using QEMU easier.
> 
> Let's avoid the h-word here as it's not terribly relevant to the discussion.
> 
> Configuring block devices is fundamentally a privileged operation.  QEMU 
> fundamentally is designed to be useful as an unprivileged user.
> 
> That's the trouble with something like LVM.  Only root can create LVM 
> snapshots and it's an all-or-nothing security model.
> 
> If you want to get QEMU out of the snapshot business, you need a file 
> system that's widely available that allows non-privileged users to take 
> snapshots of individual files.

I agree with you there (and it's interesting how different perception of
the BoF results can be ;-))

It's probably true that there are ways to do certain things on host
block devices and we should definitely support such use cases better
(where we means mostly the management layer, but we can possibly
integrate things into qemu like a file-btrfs or lvm_device backend that
supports snapshots or something).

It isn't for everyone, though, and this is why I tried to point out in
the BoF that image formats aren't going to go away and we still need
good support for them. Providing only raw for running VMs and declaring
the rest of the formats to be intended for import/export only doesn't work.

Kevin