From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34846) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b5BvN-0002Gs-DK for qemu-devel@nongnu.org; Tue, 24 May 2016 08:59:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b5BvH-0001Q8-LQ for qemu-devel@nongnu.org; Tue, 24 May 2016 08:59:05 -0400 Date: Tue, 24 May 2016 13:58:48 +0100 From: "Richard W.M. Jones" Message-ID: <20160524125848.GX1683@redhat.com> References: <1463470536-8981-1-git-send-email-famz@redhat.com> <20160524114845.GF28935@redhat.com> <20160524124615.GE7091@noname.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160524124615.GE7091@noname.redhat.com> Subject: Re: [Qemu-devel] [PATCH v5 00/27] block: Lock images when opening List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Fam Zheng , qemu-devel@nongnu.org, qemu-block@nongnu.org, Jeff Cody , Markus Armbruster , Max Reitz , stefanha@redhat.com, den@openvz.org, pbonzini@redhat.com, John Snow On Tue, May 24, 2016 at 02:46:15PM +0200, Kevin Wolf wrote: > Am 24.05.2016 um 13:48 hat Richard W.M. Jones geschrieben: > > On Tue, May 17, 2016 at 03:35:09PM +0800, Fam Zheng wrote: > > > v5: - Change "lock-image=on/off" to "lock-mode=exclusive/shared/off". > > > Default is "lock-mode=exclusive" to exclusively lock RW images and shared > > > lock RO images; with lock-mode="shared", RW images are shared locked too; > > > lock-mode=off turns off image locking completely. > > > - Use F_OFD_SETLK fcntl so that close/dup on different fds are not a > > > problem. > > > - Update test cases. > > > > My comments after testing this patch set: > > > > * It's not possible to tell from the `qemu -help' output that this > > binary supports the lock-mode option. Please add this to the -help > > output (under `-drive') so we can detect it in qemu. > > > > * I patched libguestfs to add the `lock-image=off' flag when the drive > > is added readonly. This permits libguestfs to read live guests. I > > also checked that writing to live guests is now forbidden, and it > > is, which is good. In the write-to-live-guest case libguestfs will > > now fail with: > > > > qemu-system-x86_64: -drive file=/var/tmp/centos-6.img,cache=writeback,id=hd0,if=none: Failed to lock image > > > > So definitely we need this option to be reflected in the -help output. > > While you are right that maybe we should mentioned the new options in > -help for human users, help texts are not meant to be parsed. If you do > parse them and a changed help text breaks your code in the future, > that's your problem. > > Consider using query-qmp-schema instead, that one is actually meant to > be processed by machines. Yeah it's probably about time to do this now. Previously it wasn't done because opening a monitor port is slow (adds 60ms just to open it, plus the time taken doing round trips to get the data). However we are now memoizing the results of querying qemu so this is no longer critical. I will have a look at how difficult it will be to query this. Anyway doesn't change the fact we need to be able to automatically detect if the lock-mode flag is needed, given a random qemu binary. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top