[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-block] [PATCH 00/10] qcow2: Implement image locki

From: Denis V. Lunev
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 00/10] qcow2: Implement image locking
Date: Wed, 23 Dec 2015 15:41:01 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

On 12/23/2015 03:29 PM, Daniel P. Berrange wrote:
On Wed, Dec 23, 2015 at 03:15:50PM +0300, Roman Kagan wrote:
On Wed, Dec 23, 2015 at 10:47:22AM +0000, Daniel P. Berrange wrote:
On Wed, Dec 23, 2015 at 11:14:12AM +0800, Fam Zheng wrote:
As an alternative, can we introduce .bdrv_flock() in protocol drivers, with
similar semantics to flock(2) or lockf(3)? That way all formats can benefit,
and a program crash will automatically drop the lock.
FWIW, the libvirt locking daemon (virtlockd) will already attempt to take
out locks using fcntl()/lockf() on all disk images associated with a VM.
Is it even possible without QEMU cooperating?  In particular in complex
cases with e.g. backing chains?
Yes, libvirt already has to know & understand exactly what chains are
in use in order to grant correct permissions via SELinux/AppArmour.
Once it knows that it can also deal with acquiring suitable locks.

This was exactly the reason why we designed the "lock" option to take an
argument describing the locking mechanism to be used (see the tentative
patchset Denis posted in this thread).  The only one currently
implemented is flock()-based; however it can be extended to other
mechanisms like network / cluster / SAN lock managers, etc.  In
particular, it can be made to talk to virtlockd.
NB flock() doesn't work reliably / portably on NFS. Many impls
would treat it as a no-op. Other impls would only acquire the
lock on the local NFS client, not the server. Apparently Linux
now[1] transparently converts flock() into fcntl() locks on NFS
only, so you now have the problem that any close() will release
the lock. So IMHO flock() is even less usable than fcntl() as
a result.


Do you suggest to implement connection FROM qemu-img etc stuff
to libvirt and query libvirt about this?

This is absolutely fine actually, why not. We can made lock mechanics
with type 'libvirt' exactly in the same way as flock. This approach
should satisfy all needs and users.

Isn't it?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]