qemu-devel
[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: Kevin Wolf
Subject: Re: [PATCH 3/4] docs: add qemu-storage-daemon(1) man page
Date: Tue, 8 Sep 2020 16:33:47 +0200

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.

> > +**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.

Kevin




reply via email to

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