|
From: | Denis V. Lunev |
Subject: | Re: [Qemu-devel] [PATCH 1/5] block: added lock image option and callback |
Date: | Tue, 12 Jan 2016 18:59:11 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |