Re: [qemu-web PATCH] Add a blog post about FUSE block exports

[Eric Blake]

On Thu, Aug 19, 2021 at 12:25:01PM +0200, Hanna Reitz wrote:
> This post explains when FUSE block exports are useful, how they work,
> and that it is fun to export an image file on its own path so it looks
> like your image file (in whatever format it was) is a raw image now.
> 
> Signed-off-by: Hanna Reitz <hreitz@redhat.com>
> ---
> You can also find this patch here:
> https://gitlab.com/hreitz/qemu-web fuse-blkexport-v1
> 
> My first patch to qemu-web, so I hope I am not doing anything overly
> stupid here (adding SVGs with extremely long lines comes to mind)...
> ---
...
> +
> +Besides attaching guest devices to block nodes, you can also export them for
> +users outside of qemu, for example via NBD.  Say you have a QMP channel open 
> for
> +the QEMU instance above, then you could do this:
> +```json
> +{
> +    "execute": "nbd-server-start",
> +    "arguments": {
> +        "addr": {
> +            "type": "inet",
> +            "data": {
> +                "host": "localhost",
> +                "port": "10809"
> +            }
> +        }
> +    }
> +}

Rather than using a TCP port, is it worth mentioning that you can use
a Unix socket?  If the point of this is local access to the disk
contents, that feels a bit lighter weight.

> +{
> +    "execute": "block-export-add",
> +    "arguments": {
> +        "type": "nbd",
> +        "id": "fmt-node-export",
> +        "node-name": "fmt-node",
> +        "name": "guest-disk"
> +    }

This defaults to a readonly image; you may want to include
"writable":true in the JSON, especially if the purpose is to show how
to modify guest-visible contents of an at-rest disk image.

> +}
> +```
> +
> +This opens an NBD server on `localhost:10809`, which exports *fmt-node* 
> (under
> +the NBD export name *guest-disk*).  The block graph looks as follows:
> +
> +|![Same block graph as fig. 3, but with an NBD server attached to 
> fmt-node](/screenshots/2021-08-18-block-graph-b.svg)|
> +|:--:|
> +|*Fig. 4: Block graph extended by an NBD server*|
> +
> +NBD clients connecting to this server will see the raw disk as seen by the
> +guest – we have *exported* the guest disk:
> +
> +```
> +$ qemu-img info nbd://localhost/guest-disk
> +image: nbd://localhost:10809/guest-disk
> +file format: raw
> +virtual size: 20 GiB (21474836480 bytes)
> +disk size: unavailable
> +```

If you do choose to rewrite to use a Unix socket, it would change this
to nbd+unix:///guest-disk?socket=/path/to/sock.

> +
> +### QEMU storage daemon
> +
> +If you are not running a guest, and so do not need guest devices, but all you
> +want is to use the QEMU block layer (for example to interpret the qcow2 
> format)
> +and export nodes from the block graph, then you can use the more lightweight
> +QEMU storage daemon instead of a full-blown QEMU process:
> +
> +```
> +$ qemu-storage-daemon \
> +    --blockdev node-name=prot-node,driver=file,filename=$image_path \
> +    --blockdev node-name=fmt-node,driver=qcow2,file=prot-node \
> +    --nbd-server addr.type=inet,addr.host=localhost,addr.port=10809 \
> +    --export type=nbd,id=fmt-node-export,node-name=fmt-node,name=guest-disk
> +```

And if you favor Unix sockets, you'd want to do it for q-s-d as well.
Okay, keeping it as TCP is easy enough (or maybe just a mention that
Unix sockets can be used, while giving a pointer to other
documentation for the interested reader).

> +
> +## Conclusion
> +
> +As shown in this blog post, FUSE block exports are a relatively simple way to
> +access images in any format understood by QEMU as if they were raw images.
> +Any tool that can manipulate raw disk images can thus manipulate images in 
> any
> +format, simply by having the QEMU storage daemon provide a translation layer.
> +By mounting the FUSE export on the original image path, this translation 
> layer
> +will effectively be invisible, and the original image will look like it is in
> +raw format, so it can directly be accessed by those tools.
> +
> +The current main disadvantage of FUSE exports is that they offer relatively 
> bad
> +performance.  That should be fine as long as your use case is just light
> +manipulation of some VM images, like manually modifying some files on them.
> +However, we did not yet really try to optimize performance, so if more 
> serious
> +use cases appear that would require better performance, we can try.

Overall a nice post!  I hope my comments help in addition to all the
other good reviews you got.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org