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

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

On 01/11/2016 08:31 PM, Kevin Wolf wrote:
> Am 23.12.2015 um 08:46 hat Denis V. Lunev geschrieben:
>> From: Olga Krishtal <okrishtal@virtuozzo.com>
>>
>> While opening the image we want to be sure that we are the
>> one who works with image, anf if it is not true -
>> opening the image for writing should fail.
>>
>> There are 2 ways at the moment: no lock at all and lock the file
>> image.
>>
>> Signed-off-by: Olga Krishtal <okrishtal@virtuozzo.com>
>> Signed-off-by: Denis V. Lunev <den@openvz.org>
>> CC: Kevin Wolf <kwolf@redhat.com>
>> CC: Max Reitz <mreitz@redhat.com>
>> CC: Eric Blake <eblake@redhat.com>
>> CC: Fam Zheng <famz@redhat.com>
> As long as locking is disabled by default, it's useless and won't
> prevent people from corrupting their images. These corruptions happen
> exactly because people don't know how to use qemu properly. You can't
> expect them to enable locking manually.
You are right. Though this is not a big problem to enable locking.
If there are several mechanics, we could save one into the
qcow2 header.


> Also, you probably need to consider bdrv_reopen() and live migration.
> I think live migration would be blocked if source and destination both
> see the lock; which is admittedly less likely than with the qcow2 patch
> (and generally a problem of this series), but with localhost migration
> and potentially with some NFS setups it can be the case.
>
> Kevin
for live migration the situation should be not that problematic.
The disk is opened in RW mode only on one node. Am I right?

The lock is taken when the image is opened in RW mode only.

Den