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. _______________________________________________ pve-devel mailing list [email protected] https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
