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

Andrea Bolognani abologna at redhat.com
Mon Jul 20 18:20:12 UTC 2020


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

  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.

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.

-- 
Andrea Bolognani / Red Hat / Virtualization




More information about the libvir-list mailing list