Christoph Hellwig wrote:
> If you want to provide
> protection against mounting the image on the host or scribbling over it
> using mkfs you need to open the block device node with O_EXCL on Linux
> as that's the mechanisms most tools and the filesystem code us for
> exclusion.
Due to that I do su
Kevin Wolf wrote:
> > You might think the user could do that by setting the permissions to
> > read-only, but root ignores file permissions. (That's why we need a
> > "ro" option too).
>
> We do have readonly=on|off.
Sure, but if you have to do that for safe behaviour when running qemu
as root,
On Thu, Dec 17, 2009 at 11:53:45AM +0100, Christoph Hellwig wrote:
> If you're primarily interested in protection against other qemu
> instances you can add you code on top, but that seems like a rather
> marginal use case.
It's a pretty serious case for people accessing live virtual machines
with
FYI I don't think this is all too useful. Just about no one actually
uses file locking APIs on block devices. If you want to provide
protection against mounting the image on the host or scribbling over it
using mkfs you need to open the block device node with O_EXCL on Linux
as that's the mechan
Am 15.12.2009 19:33, schrieb Jamie Lokier:
> Shared backing disks aren't safe after "commit" anyway. Other VMs may
> not be running at the time "commit" renders their image corrupt, so
> locks don't offer adequate protection against the backing disk being changed.
>
> One strategy that would offe
Jamie Lokier wrote:
> > At Kevin Wolf's suggestion,
> > lock=exclusive|shared => all backing disks are locked shared
> > lock=none => no locks are acquired on any front or back disks
>
> What do you recommend when backing disks are shared?
Please ignore that part of my reply. It was meant to be
Richard W.M. Jones wrote:
Thanks for looking at this.
Thanks for following up :-)
The use case is "cluster filesystem with an admin tool that must be
run exclusively". Cluster nodes open the block device for write, but
with a shared lock. The admin tool needs exclusive access (no nodes
m
Richard W.M. Jones wrote:
> This is v3 of the lock patch, previously discussed here:
>
> http://lists.gnu.org/archive/html/qemu-devel/2009-12/threads.html#00461
>
> In this version I've reverted back to the simpler interface. There is
> now only one "lock" option, which can be lock=exclusive|sha
On Tue, Dec 15, 2009 at 12:02:04PM -0600, Anthony Liguori wrote:
> Richard W.M. Jones wrote:
>> This is v3 of the lock patch, previously discussed here:
>>
>> http://lists.gnu.org/archive/html/qemu-devel/2009-12/threads.html#00461
>>
>> In this version I've reverted back to the simpler interface.
Richard W.M. Jones wrote:
This is v3 of the lock patch, previously discussed here:
http://lists.gnu.org/archive/html/qemu-devel/2009-12/threads.html#00461
In this version I've reverted back to the simpler interface. There is
now only one "lock" option, which can be lock=exclusive|shared|none.
This is v3 of the lock patch, previously discussed here:
http://lists.gnu.org/archive/html/qemu-devel/2009-12/threads.html#00461
In this version I've reverted back to the simpler interface. There is
now only one "lock" option, which can be lock=exclusive|shared|none.
At Kevin Wolf's suggestion,
11 matches
Mail list logo
