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

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

On 01/13/2016 11:52 AM, Markus Armbruster wrote:
> Kevin Wolf <kwolf@redhat.com> writes:
>
>> Am 11.01.2016 um 18:58 hat Daniel P. Berrange geschrieben:
>>> On Mon, Jan 11, 2016 at 06:31:06PM +0100, 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.
>>>>
>>>> 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.
>>> Note that when libvirt does locking it will release locks when a VM
>>> is paused, and acquire locks prior to resuming CPUs. This allows live
>>> migration to work because you never have CPUs running on both src + dst
>>> at the same time. This does mean that libvirt does not allow QEMU to
>>> automatically re-start CPUs when migration completes, as it needs to
>>> take some action to acquire locks before allowing the dst to start
>>> running again.
>> This assumes that block devices can only be written to if CPUs are
>> running. In the days of qemu 0.9, this was probably right, but with
>> things like block jobs and built-in NBD servers, I wouldn't be as sure
>> these days.
> Sounds like QEMU and libvirt should cooperate more closely to get the
> locking less wrong.
>
> QEMU should have more accurate knowledge on how it is using the image.
> Libvirt may be able to provide better locks, with the help of its
> virtlockd daemon.
daemon owning locks is a problem:
- there are distributed cases
- daemons restart from time to time