qemu-devel
[Top][All Lists]
Advanced

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

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


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 1/5] block: added lock image option and callback
Date: Tue, 12 Jan 2016 13:28:06 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Am 12.01.2016 um 12:33 hat Fam Zheng geschrieben:
> 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.

This makes two assumptions:

1. qemu is only ever invoked by libvirt
2. qemu-img is only ever invoked by human users

Both of them are wrong. 1. just means that manually started QEMUs are
unprotected (which is already bad), but 2. means that qemu-img called by
libvirt fails (which is obviously not acceptable).

Kevin



reply via email to

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