qemu-block
[Top][All Lists]
Advanced

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

Re: [PATCH 3/4] docs: add qemu-storage-daemon(1) man page


From: Stefan Hajnoczi
Subject: Re: [PATCH 3/4] docs: add qemu-storage-daemon(1) man page
Date: Wed, 9 Sep 2020 09:59:00 +0100

On Tue, Sep 08, 2020 at 04:33:47PM +0200, Kevin Wolf wrote:
> Am 08.09.2020 um 13:42 hat Kashyap Chamarthy geschrieben:
> > On Tue, Sep 08, 2020 at 10:31:12AM +0100, Stefan Hajnoczi wrote:
> > > Document the qemu-storage-daemon tool. Most of the command-line options
> > > are identical to their QEMU counterparts. Perhaps Sphinx hxtool
> > > integration could be extended to extract documentation for individual
> > > command-line options so they can be shared. For now the
> > > qemu-storage-daemon simply refers to the qemu(1) man page where the
> > > command-line options are identical.
> > > 
> > > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> 
> Looks good to me.
> 
> If you have to respin, maybe an example section with some full command
> lines for common cases would be nice. Maybe one for exporting a qcow2
> image via NBD, and another one for attaching a host_device and having a
> QMP monitor, or something like this.

Good idea. Will fix in v2.

> > > +**Warning:** Never modify images in use by a running virtual machine or 
> > > any
> > > +other process; this may destroy the image. Also, be aware that querying 
> > > an
> > > +image that is being modified by another process may encounter 
> > > inconsistent
> > > +state.
> > 
> > I wonder if it's appropriate to mention libguestfs for safe, read-only
> > access to disk images (via `guestfish -ro -i -a disk.qcow2`).  I say
> > this because, the above warning tells what _not_ to do; a pointer on
> > what to do could be useful.  I let you decide on this.
> 
> libguestfs may expose exactly the inconsistent state that the above
> warning is about. Maybe it breaks not very often in practice, but it's
> fundamentally unsafe and if it breaks, you get to keep both pieces.
> 
> The safe way is to access it from the guest.

I agree. If a guest has disk.qcow2 open read/write then libguestfs
cannot open it (even just for reading) and expect a consistent view of
the disk.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

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