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: Tue, 23 Aug 2011 08:59:30 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Aug 22, 2011 at 04:01:08PM -0500, Anthony Liguori wrote:
> On 08/22/2011 03:48 PM, Ryan Harper wrote:
> >* Stefan Hajnoczi<address@hidden>  [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 don't think we should remove qcow2 internal snapshots or
blockdev_snapshot.  But they have performance limitations where it makes
sense to start using existing storage support instead of reimplementing
efficient and scalable snapshots ourselves.

btrfs is maturing and its BTRFS_IOC_CLONE ioctl is unprivileged.  So we
can offer that option for unprivileged users.

Stefan



reply via email to

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