Re: [libvirt PATCH 9/9] rpc: use new virt-nc binary for remote tunnelling
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=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
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: > 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=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. 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 :|
Re: [libvirt PATCH 9/9] rpc: use new virt-nc binary for remote tunnelling
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=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
Re: [libvirt PATCH 9/9] rpc: use new virt-nc binary for remote tunnelling
On Mon, Jul 20, 2020 at 07:18:55PM +0200, Andrea Bolognani wrote: > On Wed, 2020-07-15 at 16:11 +0200, Andrea Bolognani wrote: > > On Wed, 2020-07-15 at 14:25 +0100, Daniel P. Berrangé wrote: > > > On Wed, Jul 15, 2020 at 02:25:14PM +0200, Andrea Bolognani wrote: > > > > Mh, that makes sense but I'm still wary of using "proxy" due to the > > > > potential for confusion, since in this case the proxy is on the > > > > opposite side of the connection than one would probably expect it > > > > to be. Something like "remoteproxy" or "serverproxy", perhaps? > > > > > > I don't think there's really any problem of confusion here unless > > > someone doesn't read the docs at all, in which case they won't > > > even know about this parameter. So I don't think using a more > > > verbose term is any benefit. > > > > Okay. > > 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. 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 :|
Re: [libvirt PATCH 9/9] rpc: use new virt-nc binary for remote tunnelling
On Wed, 2020-07-15 at 16:11 +0200, Andrea Bolognani wrote: > On Wed, 2020-07-15 at 14:25 +0100, Daniel P. Berrangé wrote: > > On Wed, Jul 15, 2020 at 02:25:14PM +0200, Andrea Bolognani wrote: > > > Mh, that makes sense but I'm still wary of using "proxy" due to the > > > potential for confusion, since in this case the proxy is on the > > > opposite side of the connection than one would probably expect it > > > to be. Something like "remoteproxy" or "serverproxy", perhaps? > > > > I don't think there's really any problem of confusion here unless > > someone doesn't read the docs at all, in which case they won't > > even know about this parameter. So I don't think using a more > > verbose term is any benefit. > > Okay. 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? -- Andrea Bolognani / Red Hat / Virtualization
Re: [libvirt PATCH 9/9] rpc: use new virt-nc binary for remote tunnelling
On Wed, 2020-07-15 at 14:25 +0100, Daniel P. Berrangé wrote: > On Wed, Jul 15, 2020 at 02:25:14PM +0200, Andrea Bolognani wrote: > > Mh, that makes sense but I'm still wary of using "proxy" due to the > > potential for confusion, since in this case the proxy is on the > > opposite side of the connection than one would probably expect it > > to be. Something like "remoteproxy" or "serverproxy", perhaps? > > I don't think there's really any problem of confusion here unless > someone doesn't read the docs at all, in which case they won't > even know about this parameter. So I don't think using a more > verbose term is any benefit. Okay. > > Going back to the name of the command itself, since it's an internal > > implementation details, and as such it's not intended to be invoked > > by users and accordingly we're installing it under $(libexecdir) > > along with existing helpers, what about following the established > > naming convention and calling it 'libvirt_proxyhelper'? > > Installing it to libexecdir is actually a mistake in this version. It > needs to be installed into bindir, as it must be present in $PATH. Why is that so? Is it because otherwise we can't guarantee that ssh on the remote end will find it, seeing as $(libexecdir) can be changed at configure time and is usually not part of $PATH anyway? If the binary will show up in $PATH, then I think it's even more important to ensure it's very apparent that it's for internal use and not to be invoked directly. Including a message explaining this in the help output as well as the usage message that is printed when a URI is not passed on the command line would be a great start. As for the name of the binary itself, longer and more descriptive is clearly better to avoid confusion. What about 'virt-proxy-helper'? -- Andrea Bolognani / Red Hat / Virtualization
Re: [libvirt PATCH 9/9] rpc: use new virt-nc binary for remote tunnelling
On Wed, Jul 15, 2020 at 02:25:14PM +0200, Andrea Bolognani wrote: > On Wed, 2020-07-15 at 11:00 +0100, Daniel P. Berrangé wrote: > > On Fri, Jul 10, 2020 at 07:21:47PM +0200, Andrea Bolognani wrote: > > > 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. > > Mh, that makes sense but I'm still wary of using "proxy" due to the > potential for confusion, since in this case the proxy is on the > opposite side of the connection than one would probably expect it > to be. Something like "remoteproxy" or "serverproxy", perhaps? I don't think there's really any problem of confusion here unless someone doesn't read the docs at all, in which case they won't even know about this parameter. So I don't think using a more verbose term is any benefit. > > > 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. > > Yeah, that's much better. > > Going back to the name of the command itself, since it's an internal > implementation details, and as such it's not intended to be invoked > by users and accordingly we're installing it under $(libexecdir) > along with existing helpers, what about following the established > naming convention and calling it 'libvirt_proxyhelper'? Installing it to libexecdir is actually a mistake in this version. It needs to be installed into bindir, as it must be present in $PATH. 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 :|
Re: [libvirt PATCH 9/9] rpc: use new virt-nc binary for remote tunnelling
On Wed, 2020-07-15 at 11:00 +0100, Daniel P. Berrangé wrote: > On Fri, Jul 10, 2020 at 07:21:47PM +0200, Andrea Bolognani wrote: > > 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. Mh, that makes sense but I'm still wary of using "proxy" due to the potential for confusion, since in this case the proxy is on the opposite side of the connection than one would probably expect it to be. Something like "remoteproxy" or "serverproxy", perhaps? > 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. Yeah, that's much better. Going back to the name of the command itself, since it's an internal implementation details, and as such it's not intended to be invoked by users and accordingly we're installing it under $(libexecdir) along with existing helpers, what about following the established naming convention and calling it 'libvirt_proxyhelper'? -- Andrea Bolognani / Red Hat / Virtualization
Re: [libvirt PATCH 9/9] rpc: use new virt-nc binary for remote tunnelling
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 :|
Re: [libvirt PATCH 9/9] rpc: use new virt-nc binary for remote tunnelling
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'd also be remiss if I didn't point out that this is definitely a change worth documenting in our release notes :) -- Andrea Bolognani / Red Hat / Virtualization
Re: [libvirt PATCH 9/9] rpc: use new virt-nc binary for remote tunnelling
On 7/9/20 8:36 PM, 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.
Signed-off-by: Daniel P. Berrangé
---
docs/uri.html.in| 18 ++
src/remote/remote_driver.c | 30 +++-
src/remote/remote_sockets.c | 8 -
src/rpc/virnetclient.c | 70 ++---
src/rpc/virnetclient.h | 30 +---
tests/virnetsockettest.c| 7 ++--
6 files changed, 136 insertions(+), 27 deletions(-)
diff --git a/src/rpc/virnetclient.c b/src/rpc/virnetclient.c
index cd1bcc3ab3..5939f74e62 100644
--- a/src/rpc/virnetclient.c
+++ b/src/rpc/virnetclient.c
@@ -50,6 +50,10 @@ enum {
VIR_NET_CLIENT_MODE_COMPLETE,
};
+VIR_ENUM_IMPL(virNetClientProxy,
+ VIR_NET_CLIENT_PROXY_LAST,
+ "auto", "netcat", "virt-nc");
+
struct _virNetClientCall {
int mode;
@@ -414,20 +418,50 @@ virNetClientDoubleEscapeShell(const char *str)
}
char *
-virNetClientSSHHelperCommand(const char *netcatPath,
- const char *socketPath)
+virNetClientSSHHelperCommand(virNetClientProxy proxy,
+ const char *netcatPath,
+ const char *socketPath,
+ const char *driverURI,
+ bool readonly)
{
g_autofree char *netcatPathSafe =
virNetClientDoubleEscapeShell(netcatPath);
+g_autofree char *driverURISafe = virNetClientDoubleEscapeShell(driverURI);
+g_autofree char *nccmd = NULL;
+g_autofree char *virtnccmd = NULL;
-return g_strdup_printf(
-"sh -c "
-"'if '%s' -q 2>&1 | grep \"requires an argument\" >/dev/null 2>&1; then
"
- "ARG=-q0;"
+nccmd = g_strdup_printf(
+"if '%s' -q 2>&1 | grep \"requires an argument\" >/dev/null 2>&1; then
"
+"ARG=-q0;"
"else "
- "ARG=;"
+"ARG=;"
"fi;"
-"'%s' $ARG -U %s'",
+"'%s' $ARG -U %s",
netcatPathSafe, netcatPathSafe, socketPath);
+
+virtnccmd = g_strdup_printf("%s '%s'",
+readonly ? "virt-nc -r" : "virt-nc",
+driverURISafe);
+
+switch (proxy) {
+case VIR_NET_CLIENT_PROXY_AUTO:
+return g_strdup_printf("sh -c 'which virt-nc 1>/dev/null 2>&1; "
+ "if test $? = 0; then "
+ "%s; "
+ "else"
+ "%s; "
+ "fi'", virtnccmd, nccmd);
+
+case VIR_NET_CLIENT_PROXY_NETCAT:
+return g_strdup_printf("sh -c '%s'", nccmd);
+
+case VIR_NET_CLIENT_PROXY_VIRT_NC:
+return g_strdup_printf("sh -c '%s'", virtnccmd);
+
+case VIR_NET_CLIENT_PROXY_LAST:
+default:
+virReportEnumRangeError(virNetClientProxy, proxy);
+return NULL;
+}
}
This needs to be coupled with virnetsockettest update because the
expected output of executed command changes.
Michal
[libvirt PATCH 9/9] rpc: use new virt-nc binary for remote tunnelling
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.
Signed-off-by: Daniel P. Berrangé
---
docs/uri.html.in| 18 ++
src/remote/remote_driver.c | 30 +++-
src/remote/remote_sockets.c | 8 -
src/rpc/virnetclient.c | 70 ++---
src/rpc/virnetclient.h | 30 +---
tests/virnetsockettest.c| 7 ++--
6 files changed, 136 insertions(+), 27 deletions(-)
diff --git a/docs/uri.html.in b/docs/uri.html.in
index 49f92773f8..5311579273 100644
--- a/docs/uri.html.in
+++ b/docs/uri.html.in
@@ -259,6 +259,24 @@ Note that parameter values must be
Example: mode=direct
+
+
+ proxy
+
+auto, virt, generic
+
+
+autotry virt-nc, fallback to netcat
+netcatonly use netcat
+virt-nconly use virt-nc
+
+ Can also be set in libvirt.conf as
remote_proxy
+
+
+
+
+ Example: proxy=virt-nc
+
command
diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c
index c1f7a45aab..83789a86a9 100644
--- a/src/remote/remote_driver.c
+++ b/src/remote/remote_driver.c
@@ -761,12 +761,14 @@ doRemoteOpen(virConnectPtr conn,
g_autofree char *knownHosts = NULL;
g_autofree char *mode_str = NULL;
g_autofree char *daemon_name = NULL;
+g_autofree char *proxy_str = NULL;
bool sanity = true;
bool verify = true;
#ifndef WIN32
bool tty = true;
#endif
int mode;
+int proxy;
if (inside_daemon && !conn->uri->server) {
mode = REMOTE_DRIVER_MODE_DIRECT;
@@ -774,6 +776,14 @@ doRemoteOpen(virConnectPtr conn,
mode = REMOTE_DRIVER_MODE_AUTO;
}
+/* Historically we didn't allow ssh tunnel with session mode,
+ * since we can't construct the accurate path remotely,
+ * so we can default to modern virt-nc */
+if (flags & VIR_DRV_OPEN_REMOTE_USER)
+proxy = VIR_NET_CLIENT_PROXY_VIRT_NC;
+else
+proxy = VIR_NET_CLIENT_PROXY_NETCAT;
+
/* We handle *ALL* URIs here. The caller has rejected any
* URIs we don't care about */
@@ -813,6 +823,7 @@ doRemoteOpen(virConnectPtr conn,
EXTRACT_URI_ARG_STR("known_hosts_verify", knownHostsVerify);
EXTRACT_URI_ARG_STR("tls_priority", tls_priority);
EXTRACT_URI_ARG_STR("mode", mode_str);
+EXTRACT_URI_ARG_STR("proxy", proxy_str);
EXTRACT_URI_ARG_BOOL("no_sanity", sanity);
EXTRACT_URI_ARG_BOOL("no_verify", verify);
#ifndef WIN32
@@ -865,6 +876,14 @@ doRemoteOpen(virConnectPtr conn,
(mode = remoteDriverModeTypeFromString(mode_str)) < 0)
goto failed;
+if (conf && !proxy_str &&
+virConfGetValueString(conf, "remote_proxy", _str) < 0)
+goto failed;
+
+if (proxy_str &&
+(proxy = virNetClientProxyTypeFromString(proxy_str)) < 0)
+goto failed;
+
/* Sanity check that nothing requested !direct mode by mistake */
if (inside_daemon && !conn->uri->server && mode !=
REMOTE_DRIVER_MODE_DIRECT) {
virReportError(VIR_ERR_INVALID_ARG, "%s",
@@ -949,8 +968,11 @@ doRemoteOpen(virConnectPtr conn,
knownHosts,
knownHostsVerify,
sshauth,
+ proxy,
netcat,
sockname,
+ name,
+ flags & VIR_DRV_OPEN_REMOTE_RO,
auth,
conn->uri);
if (!priv->client)
@@ -970,8 +992,11 @@ doRemoteOpen(virConnectPtr conn,
knownHosts,
knownHostsVerify,
sshauth,
+ proxy,
netcat,
sockname,
+ name,
+ flags & VIR_DRV_OPEN_REMOTE_RO,
