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

["Denis V. Lunev" <den@openvz.org>]

On 01/13/2016 07:44 PM, Eric Blake wrote:
> On 01/12/2016 05:10 PM, Fam Zheng wrote:
>
>>> 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.
>> That is wrong because then we break old libvirt with the new qemu-img (acquires
>> lock by default), which is IMO a breakage of backward compatibility.
> In the big software stack picture, it is okay to reject 'old libvirt/new
> qemu' as an invalid combination.  Upgrade-wise, we specifically support
> 'new libvirt/old qemu' - but it is fair game to say that 'if you want to
> run new qemu, you must first upgrade to new libvirt that knows how to
> drive it'.
>
> That said, minimizing back-compat breaks, so that old libvirt can
> (usually) correctly drive new qemu, is a worthy design goal for qemu.
>
there is one other thing I have originally missed to add to the
picture.

Locking could be complex and format specific. In original
Parallels disk format (not image but entire bundle), the locking
is performed on a very special file.

Thus either libvirt must know exact format details or it must
rely on something which really does know details, i.e. QEMU/qemu-img.

Den