qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/2] docs: Add image locking subsection


From: Fam Zheng
Subject: Re: [Qemu-devel] [PATCH 1/2] docs: Add image locking subsection
Date: Fri, 24 Nov 2017 16:43:30 +0800
User-agent: Mutt/1.9.1 (2017-09-22)

On Thu, 11/23 18:01, Kevin Wolf wrote:
> 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 <address@hidden>
> > ---
> >  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.
> >  
> > address@hidden disk_image_locking
> > address@hidden 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:
> > +
> > address@hidden 
> > 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

Updating all of them. Thanks!

Fam



reply via email to

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