[pve-devel] [RFC qemu-server] migration: nbd export: switch away from deprecated QMP command

[Fiona Ebner]

Am 16.12.22 um 12:52 schrieb Thomas Lamprecht:
> On 02/12/2022 13:54, Fiona Ebner wrote:
>> The 'nbd-server-add' QMP command has been deprecated since QEMU 5.2 in
>> favor of a more general 'block-export-add'.
>>
>> When using 'nbd-server-add', QEMU internally converts the parameters
>> and calls blk_exp_add() which is also used by 'block-export-add'. It
>> does one more thing, namely calling nbd_export_set_on_eject_blk() to
>> auto-remove the export from the server when the backing drive goes
>> away. But that behavior is not needed in our case, stopping the NBD
>> server removes the exports anyways.
>>
>> It was checked with a debugger that the parameters to blk_exp_add()
>> are still the same after this change. Well, the block node names are
>> autogenerated and not consistent across invocations.
>>
>> The alternative to using 'query-block' would be specifying a
>> predictable 'node-name' for our '-drive' commandline. It's not that
>> difficult for this use case, but in general one needs to be careful
>> (e.g. it can't be specified for an empty CD drive, but would need to
>> be set when inserting a CD later). Querying the actual 'node-name'
>> seemed a bit more future-proof.
> 
> are there other examples than the CD-Drive, as that one wouldn't be
> really relevant for us here or?

Not relevant here, but I'd expect that *if* we introduce node-names,
that we can rely on them in the future in other situations too. The CD
drive example is the only one I found.

> 
> IMO they key disadvantage of switching to computed node-names is the
> upgrade path, as I'd expect that for running VMs we cannot change them
> to computed ones and thus we would need to still query (or keep the
> legacy command) for those...

Since introduction of node-names and export happen on the fresh target
instance there should not be an issue with the upgrade path.