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