From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52880) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIyw0-00089z-Mr for qemu-devel@nongnu.org; Tue, 12 Jan 2016 08:24:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aIyvx-00006t-Gx for qemu-devel@nongnu.org; Tue, 12 Jan 2016 08:24:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56076) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIyvx-00006o-9L for qemu-devel@nongnu.org; Tue, 12 Jan 2016 08:24:25 -0500 Date: Tue, 12 Jan 2016 13:24:20 +0000 From: "Daniel P. Berrange" Message-ID: <20160112132420.GL17626@redhat.com> References: <567A4EB0.1040807@parallels.com> <1450856816-9816-1-git-send-email-den@openvz.org> <1450856816-9816-2-git-send-email-den@openvz.org> <20160111173106.GL9454@noname.redhat.com> <56949140.1010800@openvz.org> <20160112101031.GB4841@noname.redhat.com> <20160112113331.GA16191@ad.usersys.redhat.com> <20160112122806.GC4841@noname.redhat.com> <20160112131751.GC3903@ad.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160112131751.GC3903@ad.usersys.redhat.com> Subject: Re: [Qemu-devel] [PATCH 1/5] block: added lock image option and callback Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: Kevin Wolf , qemu-devel@nongnu.org, Max Reitz , Olga Krishtal , "Denis V. Lunev" On Tue, Jan 12, 2016 at 09:17:51PM +0800, Fam Zheng wrote: > On Tue, 01/12 13:28, Kevin Wolf wrote: > > 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). > > No, my assumptions are: > > a. libvirt calls flock() when invoking qemu; > b. libvirt doesn't call flock() when invoking qemu-img; (if I read the libvirt > code correctly, input from libvirt folks needed); b. is /currently/ true, but I wouldn't guarantee that will always be true, because we've (vague) plans to extend our locking infrastructure to cover our storage pools APIs too, at which point we'd likely be have locking around qemu-img based API calls too. There's also likelihood we'll make our locking API public, in which case it is possible that an app using libvirt could have acquired locks on the file. > So, 1. means that multiple manually started QEMU instances writing to the same > image are NOT protected, that's the limitation. 2. means that qemu-img called > by either libvirt or a human user is prevented from corrupting an in-use qcow2. > > As long as I'm not wrong about b. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|