On Fri, Jul 10, 2020 at 07:21:47PM +0200, Andrea Bolognani wrote:
On Thu, 2020-07-09 at 19:36 +0100, Daniel P. Berrangé wrote:
> This wires up support for using the new virt-nc binary with the ssh,
> libssh and libssh2 protocols.
>
> The new binary will be used preferentially if it is available in $PATH,
> otherwise we fall back to traditional netcat.
>
> The "proxy" URI parameter can be used to force use of netcat e.g.
>
> qemu+ssh://host/system?proxy=netcat
>
> or the disable fallback e.g.
>
> qemu+ssh://host/system?proxy=virt-nc
>
> With use of virt-nc, we can now support remote session URIs
>
> qemu+ssh://host/session
>
> and this will only use virt-nc, with no fallback. This also lets the
> libvirtd process be auto-started.
Just a couple of comments about the UI: would it make sense to use
something like
qemu+ssh://host/system?tunnelcmd=virt-tunnel
instead? virt-nc could be seen as a bit of a misnomer, considering
that (by design) it doesn't do nearly as much as the actual netcat
does; as for the 'proxy' argument, I'm afraid it might lead people
to believe it's used for HTTP proxying or some other form of
proxying *between the client and the host*, whereas it's really
something that only affects operations on the host itself - not to
mention that we also have a virtproxyd now, further increasing the
potential for confusion...
I chose proxy not tunnel, because SSH is providing the tunnel here.
virt-nc is a proxy linking the tunnel to the daemon. virtproxyd is
conceptually similar, again linking a libvirt client to the real
daemon.
I probably shouldn't mention "virt-nc" by name in the URI and instead
have "proxy=netcat" vs "proxy=native", as users don't get to
choose
the actual binary here - they are providing an enum string, which
gets mapped to the desired binary.
Regards,
Daniel
--
|:
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 :|