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

[Paolo Bonzini]

> Now an admin comes along with with libguestfs and attempts to access
> the disk containing the GFS volume. libguestfs isn't part of the
> cluster but that doesn't matter because you can happily access a GFS
> filesystem in standalone mode provided it is not in use by any other
> nodes.
>
> We need to stop libguestfs opening the disk in exclusive-write mode
> if other QEMU VMs are using it in shared-write mode.

I think it's simpler to use no locking in QEMU and let the cluster 
management tool do the locking.  The tool would be the one to invoke 
QEMU, of course.

> If QEMU with the shared-writable disks is been using F_RDLOCK, then
> this would have prevent libguestfs opening the disk for write with
> F_WRLOCK, since the F_RDLOCK blocks all F_WRLOCK attempts.
>
> We really do have 3 combinations of locking / access mode here
>
>   - read-only  + F_RDLOCK
>   - read-write + F_RDLOCK
>   - read-write + F_WRLOCK
>
> So a single 'lock' flag is not sufficient, we need the shared/exclusive
> semantics of the original patch.

I'd still prefer having a DWIM lock option that chooses the right kind 
of locking depending on what you are doing.

You could have lock={no,yes,shared,exclusive} as follows

image type         lock=no       yes             shared        exclusive
raw, opened RO     no            F_RDLOCK        F_RDLOCK      F_WRLOCK
raw, opened RW     no            F_WRLOCK        F_RDLOCK      F_WRLOCK
qcow2, opened RO   no            F_RDLOCK        F_RDLOCK      F_WRLOCK
   backing image   no            F_RDLOCK        F_RDLOCK      F_WRLOCK
qcow2, opened RW   no            F_WRLOCK        error         F_WRLOCK
   backing image   no            F_RDLOCK        error         F_WRLOCK

However, I think lock=shared would be the wrong thing to do in the 
cluster case.  It's better if the management tool locks the partitions 
for read-write instead, and this clearly does not belong in QEMU.  It 
would be a step in the wrong direction, and one that will be there 
forever in QEMU.

I think only lock={no,yes} is the best option to start with.

Paolo