From patchwork Fri Nov 24 08:53:50 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Fam Zheng X-Patchwork-Id: 840987 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=nongnu.org (client-ip=2001:4830:134:3::11; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3yjqkr21CHz9sQl for ; Fri, 24 Nov 2017 19:54:44 +1100 (AEDT) Received: from localhost ([::1]:48045 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eI9kw-0005g5-DK for incoming@patchwork.ozlabs.org; Fri, 24 Nov 2017 03:54:42 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59512) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eI9kI-0005bz-2R for qemu-devel@nongnu.org; Fri, 24 Nov 2017 03:54:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eI9kH-0001bD-09 for qemu-devel@nongnu.org; Fri, 24 Nov 2017 03:54:02 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54100) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eI9kG-0001aZ-OW for qemu-devel@nongnu.org; Fri, 24 Nov 2017 03:54:00 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E4FC1A0B52; Fri, 24 Nov 2017 08:53:59 +0000 (UTC) Received: from lemon.redhat.com (ovpn-12-45.pek2.redhat.com [10.72.12.45]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1146A1883A; Fri, 24 Nov 2017 08:53:57 +0000 (UTC) From: Fam Zheng To: qemu-devel@nongnu.org Date: Fri, 24 Nov 2017 16:53:50 +0800 Message-Id: <20171124085351.26386-2-famz@redhat.com> In-Reply-To: <20171124085351.26386-1-famz@redhat.com> References: <20171124085351.26386-1-famz@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Fri, 24 Nov 2017 08:53:59 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH v2 1/2] docs: Add image locking subsection X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kwolf@redhat.com, mreitz@redhat.com, famz@redhat.com, Philipp Hahn Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" This documents the image locking feature and explains when and how related options can be used. Signed-off-by: Fam Zheng --- docs/qemu-block-drivers.texi | 36 ++++++++++++++++++++++++++++++++++++ qemu-doc.texi | 1 + 2 files changed, 37 insertions(+) diff --git a/docs/qemu-block-drivers.texi b/docs/qemu-block-drivers.texi index 1cb1e55686..503c1847aa 100644 --- a/docs/qemu-block-drivers.texi +++ b/docs/qemu-block-drivers.texi @@ -785,6 +785,42 @@ warning: ssh server @code{ssh.example.com:22} does not support fsync With sufficiently new versions of libssh2 and OpenSSH, @code{fsync} is supported. +@node disk_image_locking +@subsection Disk image file locking + +By default, QEMU tries to protect image files from unexpected concurrent +access, as long as it's supported by the block protocol driver and host +operating system. If multiple QEMU processes (including QEMU emulators and +utilities) try to open the same image with conflicting accessing modes, all but +the first one will get an error. + +This feature is currently supported by the file protocol on Linux with the Open +File Descriptor (OFD) locking API, and can be configured to fall back to POSIX +locking if the POSIX host doesn't support Linux OFD locking. + +To explicitly enable image locking, specify "locking=on" in the file protocol +driver options. If OFD locking is not possible, a warning will be printed and +the POSIX locking API will be used. In this case there is a risk that the lock +will get silently lost when doing hot plugging and block jobs, due to the +shortcomings of the POSIX locking API. + +QEMU transparently handles lock handover during shared storage migration. For +shared virtual disk images between multiple VMs, the "share-rw" device option +should be used. + +Alternatively, locking can be fully disabled by "locking=off" block device +option. In the command line, the option is usually in the form of +"file.locking=off" as the protocol driver is normally placed as a "file" child +under a format driver. For example: + +@code{-blockdev driver=qcow2,file.filename=/path/to/image,file.locking=off,file.driver=file} + +To check if image locking is active, check the output of the "lslocks" command +on host and see if there are locks held by the QEMU process on the image file. +More than one byte could be locked by the QEMU instance, each byte of which +reflects a particular permission that is acquired or protected by the running +block driver. + @c man end @ignore diff --git a/qemu-doc.texi b/qemu-doc.texi index 617254917d..db2351c746 100644 --- a/qemu-doc.texi +++ b/qemu-doc.texi @@ -405,6 +405,7 @@ encrypted disk images. * disk_images_iscsi:: iSCSI LUNs * disk_images_gluster:: GlusterFS disk images * disk_images_ssh:: Secure Shell (ssh) disk images +* disk_image_locking:: Disk image file locking @end menu @node disk_images_quickstart