[libvirt PATCH 9/9] rpc: use new virt-nc binary for remote tunnelling
Daniel P. Berrangé
berrange at redhat.com
Mon Jul 20 18:36:40 UTC 2020
On Mon, Jul 20, 2020 at 08:20:12PM +0200, Andrea Bolognani wrote:
> On Mon, 2020-07-20 at 18:21 +0100, Daniel P. Berrangé wrote:
> > On Mon, Jul 20, 2020 at 07:18:55PM +0200, Andrea Bolognani wrote:
> > > The other day I randomly realized the ssh-based transports already
> > > accept a 'netcat' URI parameter which can be used to point libvirt
> > > to a non-standard nc stand-in. With that in mind, is it really
> > > necessary to introduce another URI parameter? Can't we just reuse
> > > the existing one?
> > Any binary provided there needs to implement netcat syntax. The whole
> > point of this work is that we don't want to use the netcat syntax since
> > it is impossible to know the correct socket path.
> 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
> 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
> 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.
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
More information about the libvir-list