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 <stefa...@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
signature.asc
Description: PGP signature