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

[Kevin Wolf <kwolf@redhat.com>]

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

Probably both suggestions are doable in qcow2 with an extended header.
However, raw backing file are not uncommon and you'll have a hard time
adding something there.

Also I'm not sure if they are really helpful. Who would really set the
user-settable flag after all? The generation number works automatically,
but it only can recognize the damage afterwards when the image is
already corrupted.

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

Kevin