Re: [libvirt PATCH 9/9] rpc: use new virt-nc binary for remote tunnelling

On Mon, Jul 20, 2020 at 08:20:12PM +0200, Andrea Bolognani wrote: > We could special-case binaries called 'virt-nc' and use our internal > syntax for those. Having two separate URI parameters to control the > same knob sounds like trouble, especially since you can mix and > match: if you try to connect to > > qemu+ssh://host/system?proxy=virt-nc&netcat=my-cool-nc > > for example, what happens? As far as I can tell virt-nc will be used, > but it's certainly not as obvious as it would be if everything was > controlled by a single URI parameter. No, I really don't want to do magic based on the name of the binary. That is a recipe for long term pain. It never turns out well when we try to overload two distinct concepts onto a single tunable. That URL you illustrate should be reported as an error since it is using mutually exclusive args.

> Actually, and I might be very well missing something because I looked > at the code rather quickly, from what I can tell the default value > for proxy will cause libvirt to always prefer virt-nc when available, > which means that the URI > > qemu+ssh://host/system?netcat=my-cool-nc > > will suddenly stop using my-cool-nc and start using virt-nc after > libvirt has been upgraded - a breaking change. It will only stop using my-cool-nc if you have upgraded the remote host to have virt-nc installed, and your local host also has the libvirt supporting virt-nc. I'd consider that desirable, as netcat is redundant once both sides are upgraded.