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 <[email protected]> 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
>
>
