On Thu, May 16, 2024 at 11:12:55AM +0100, Daniel P. Berrangé wrote:
I don't believe QEMU complains about unknown URI query
parameters, though I might make the argument that it should
complain about anything unknown as an aid to dianose user
errors. I'm not planning any such change myself though.
Let me actually look at what qemu does ...
qemu has partial support for NBD URIs
(
https://github.com/NetworkBlockDevice/nbd/blob/master/doc/uri.md)
It supports nbd://, nbd+unix://, and nbd+tcp:// (non-standard).
It supports server, port, export name, and ?socket.
It doesn't support TLS username or any tls-* parameters, but since it
doesn't support nbds:// (ie. TLS) via URIs that doesn't matter at the
moment.
tls-certificates and tls-psk-file are strictly libnbd extensions, and
libnbd doesn't support tls-type=anon|x509|psk.
So there's a bit of work for both libnbd & qemu to get fully compliant
TLS support.
Using the separate -object argument is painful and obscure for users.
Is there a reason why qemu could never support tls-certificates=<path>
or tls-psk-file=<filename> in future? For example that it's
architecturally difficult for qemu to work this way?
Thanks for the review.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top