Re: [Qemu-devel] [PATCH 1/5] block: added lock image option and callback

[Denis V. Lunev]

On 01/12/2016 02:33 PM, Fam Zheng wrote:
> On Tue, 01/12 11:10, Kevin Wolf wrote:
> > The problem is that libvirt already takes a lock, as Dan mentioned in
> > another reply in this thread, so we can't enable locking in qemu by
> > default. It would always fail when run under libvirt.
> >
> > Unless I'm seriously mistaken, this means that flock() inside qemu is
> > dead.
> Yes, I see the problem with libvirt, but can we instead do these?
>
>    1) Do a soft flock() in QEMU invocation. If it fails, sliently ignore.
>    2) Do a hard flock() in qemu-img invocation. If it fails, report and exit.
>
> This way, if libvirt is holding flock, we can assume libvirt is actually
> "using" the image: 1) just works as before, but 2) will not break the qcow2.
> That is still a slight improvement, and does solve the reckless "qemu-img
> snapshot create" user's problem.
>
> Fam
There is a better way though.

If we will switch default in my patch from 'nolock' to 'lock' then
pour guys which are calling qemu-img etc stuff will see the lock
as necessary while 'proper management software' aka libvirt
will be able to call qemu/qemu-img etc with proper 'nolock'
flag as they do care about the locking.

Though from my POW all locks should be taken in the responsible
entity, i.e. qemu or qemu-img as if locks are held by libvirt then
they should be re-taken on f.e. daemon restart, which could happen.
This is not that convenient.

Den