qemu-devel
[Top][All Lists]
Advanced

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

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


From: Hanna Reitz
Subject: Re: [qemu-web PATCH] Add a blog post about FUSE block exports
Date: Mon, 23 Aug 2021 10:23:53 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

On 20.08.21 23:24, Eric Blake wrote:
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.

Well, the point of this is local access through FUSE; the NBD part here just serves to introduce the concept of block exports, so it shouldn’t really matter whether we use TCP or Unix sockets here.  I like TCP sockets a bit more in this case, because I feel like for people who don’t know much about NBD, that may seem more natural.

+{
+    "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.

Oh, yes, good idea.  I should do this in every export command line.

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

Thanks!  I think I’ll keep TCP for exporting, but I will add writable=on to every export example.

Hanna




reply via email to

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