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

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

[Yu Zhang]

[-- Attachment #1: Type: text/plain, Size: 2510 bytes --]

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", and
"node-name" can be obtained from the querying result of "query-block". 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 }}
{"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 }}
{"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. It seems that sending "device" is quite easy, but
sending "device" and translating it to the correct "node-name" is not quite
straightforward.
The "block-export-add" command made it somehow unnecessarily complicated.

For this reason, we would like to know:
- whether it's possible not to deprecate the use of "nbd-server-add"
command, or
- whether there is a simpler QMP command for block device migration

Thank you so much for your reply.

Yu Zhang @Compute Platform Team of IONOS SE
05.07.2022

[1] https://wiki.qemu.org/ChangeLog/5.2

[-- Attachment #2: Type: text/html, Size: 3446 bytes --]

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

[Hanna Reitz]

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

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

[Yu Zhang]

[-- Attachment #1: Type: text/plain, Size: 5352 bytes --]

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
>
>

[-- Attachment #2: Type: text/html, Size: 6972 bytes --]