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

[Andrea Bolognani]

On Mon, 2020-07-20 at 19:36 +0100, Daniel P. Berrangé wrote:
> 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.

Adding validation sounds good. We should also cross-reference the two
parameters in the documentation, to make sure users changing one of
them is aware of the other existing as well.

> > 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.

If the user is explicitly asking for a specific netcat binary to be
used, then we need to comply with that request, even if we think that
virt-nc would be better. Doing otherwise has the potential to break
the user's setup.

Basically, when the netcat parameter is specified we should behave as
if proxy=netcat had been specified as well.

-- 
Andrea Bolognani / Red Hat / Virtualization