Am 23.11.2017 um 14:59 hat Fam Zheng geschrieben:
> This documents the image locking feature and explains when and how
> related options can be used.
>
> Signed-off-by: Fam Zheng <f...@redhat.com>
> ---
> 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..fa2e90d15f 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 Open
s/with/with the/
> +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 risk that the lock
s/risk/a risk/ (native speakers, is this the right correction?)
> +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
s/by/with the/
> +option. In the command line the option is usually in the form of
Comma after "command line"?
> +"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 "lslocks" command on
_the_ "lslocks" command
> +host and see if there are locks held by QEMU process on the image file. More
"by a" or "by the", depending on what exactly you want to say
> +than one bytes could be locked by a QEMU instance, each byte of which
> reflects
s/bytes/byte/
> +a perticular permission that are acquired or protected by the running block
s/are/is/
> +driver.
> +
> @c man end
Kevin
