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 <hre...@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:
> +
> +||
> +|:--:|
> +|*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
