Re: questions about QMP commands - "block-export-add" and "nbd-server-add"

[Yu Zhang]

Hello Hanna,

We added @node-name in -drive line and tested the live migration between QEMU-6.1 and QEMU-7.0 in different directions.
Block devices can be identified correctly on both source and target servers. Thank you so much for your quick and helpful reply.

I think it makes sense to update the QEMU man page and help page by a small fix like this:

diff --git a/qemu-options.hx b/qemu-options.hx
index 377d22fbd8..8a8f92739c 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1367,7 +1367,7 @@ DEF("drive", HAS_ARG, QEMU_OPTION_drive,
     "-drive [file=file][,if=type][,bus=n][,unit=m][,media=d][,index=i]\n"
     "       [,cache=writethrough|writeback|none|directsync|unsafe][,format=f]\n"
     "       [,snapshot=on|off][,rerror=ignore|stop|report]\n"
-    "       [,werror=ignore|stop|report|enospc][,id=name]\n"
+    "       [,werror=ignore|stop|report|enospc][,id=name][,node-name=node-name]\n"
     "       [,aio=threads|native|io_uring]\n"
     "       [,readonly=on|off][,copy-on-read=on|off]\n"
     "       [,discard=ignore|unmap][,detect-zeroes=on|off|unmap]\n"
@@ -1411,6 +1411,16 @@ SRST
         index in the list of available connectors of a given interface
         type.
 
+   ``node-name``
+        This option defines the name of the block driver node by which it
+        will be referenced later. The name must be unique, i.e. it
+        must not match the name of a different block driver node.
+
+        If no node name is specified, it is automatically generated.
+        The generated node name is not intended to be predictable
+        and changes between QEMU invocations. For the top level, an
+        explicit node name must be specified.
+
     ``media=media``
         This option defines the type of the media: disk or cdrom.
         
Yu Zhang

On Tue, Jul 5, 2022 at 1:32 PM Hanna Reitz <hreitz@redhat.com> wrote:

On 05.07.22 11:57, Yu Zhang wrote:
> Hi All,
>
> since QEMU-5.2, the QMP command "nbd-server-add" was deprecated and
> replaced with "block-export-add" [1].
>
> Arguments for the two are different. For using "block-export-add",
> "id" and "node-name" are needed, of which "id" is "device" for
> "nbd-server-add"

No, @id is the ID for the export, which is used to identify it it in
other block-export-* commands like block-export-del. nbd-server-add’s
@device parameter corresponds to block-export-add’s @node-name parameter.

> and "node-name" can be obtained from the querying result of "query-block".

Ideally, management tools would set every block node’s @node-name
manually so it doesn’t need to be queried.

> As shown by an example below:
>
> { "execute": "query-block" }
> {"return": [..., {..., "device": "drive-virtio-disk5", ...: {...:
> {"virtual-size": 53687091200, "filename": "/dev/md0", "format": "raw",
> ...}
> , ..., "node-name": "#block349", ...}, "qdev":
> "/machine/peripheral/virtio-disk5/virtio-backend", "type": "unknown"}]}
>
> { "execute": "nbd-server-add", "arguments": { "device":
> "drive-virtio-disk5", "writable": true }}

Note that you could pass “#block349” for @device here, instead of
“drive-virtio-disk5”.

> {"error": {"class": "GenericError", "desc": "Permission conflict on
> node '#block349': permissions 'write' are both required by an unnamed
> block device (uses node '#block349' as 'root' child) and unshared by
> block device 'drive-virtio-disk5' (uses node '#block349' as 'root'
> child)."}}
>
> { "execute": "block-export-add", "arguments": { "type": "nbd", "id":
> "drive-virtio-disk5", "node-name": "#block349", "writable": true }}

You can pass anything for @id that you’d like, for example
“nbd-export-349”.  It should identify the export, not the block device
underneath.

> {"error": {"class": "GenericError", "desc": "Permission conflict on
> node '#block349': permissions 'write' are both required by an unnamed
> block device (uses node '#block349' as 'root' child) and unshared by
> block device 'drive-virtio-disk5' (uses node '#block349' as 'root'
> child)."}}
>
>
> An issue we encountered with "block-export-add" for VM live migration:
>
> on the target server
> - exported device name: drive-virtio-disk5
> - node name of the exported device: #node123
>
> on the source server
> - gets the device name from target via network: driver-virtio-disk5
> - gets the node name from the target via network: #node123
>
> However, on the source server, the node name #node123 can't be identified.
>
> Assumption: the same "device" may have different "node-name" on the
> source and target servers.

Yes.  You should configure the node name to match or at least to be
something that you can work with.

I don’t know how you command line to configure block devices looks, but
if you’re using -drive (which I assume you do, because with -blockdev,
the @node-name parameter would be mandatory for you to set), then you
can simply use something like

-drive id=drive-virtio-disk5,node-name=drive-virtio-disk5-node,...

And then you can address the drive-virtio-disk5 block device with the
node name “drive-virtio-disk5-node”.

Hanna