Re: [Qemu-devel] [PATCH VERSION 3] Disk image exclusive and shared locks.

[Jamie Lokier <jamie@shareable.org>]

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.
> 
> 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?

> To keep the implementation very simple, the "commit" doesn't try to
> acquire any extra locks.  The "commit" command should probably never
> be used when a backing file could be shared.

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 offer a bit more protection would be: backing
disks opened read-only, re-opened as writable at the time of "commit",
and (where the format supports it) have a generation number stored in
them which is incremented prior to the first write after writable
open.  The generation number would be stored in the referring delta
image, which would complain if it found the backing file did not have
a matching generation.  This would at least alert the user to
inconsistencies, and the exclusive lock arising from re-opening as
writable would block "commit" if there were actively running VMs.

A different strategy would be to simply have a user-settable flag in
backing VM images meaning "shared therefore commit not allowed".

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).

-- Jamie