Bug 1032709

Created attachment 826725 [details]
strace of non-working virsh

The default UNIX sock path used for 'qemu+ssh://foo/system' will be determined according to the --prefix used when building the libvirt.so binary used on the *client*.  If both client & server used the same --prefix it would work fine

In this case your have used different prefix for client & server, hence brokeness. We can't second guess what prefix might have been used, so you have to manually override the socket path. See the 'socket' query param

http://libvirt.org/remote.html#Remote_URI_parameters

Are you for real!?

Ok, lets not call it a bug then, but a serious design flaw. I know of no other client/server setup that depends on having client and server configured for the same prefix, seriously.

And from what part of the error message should I deduct that the path to the socket is derived from the local setup?

How should I know what options libvirt on the server was configured with? Running virsh the only info I can get is the uri, which "conveniently" hides the path to the socket.

Having to know the remote socket path is a design flaw, that should be handled by the protocol, but as a workaround perhaps virsh could get a directive to print the socket path, so the remote client as part of the connect procedure could just do "virsh socket-path" and then use that.

(In reply to Andreas Nilsson from comment #3)
> Are you for real!?
> 
> Ok, lets not call it a bug then, but a serious design flaw. I know of no
> other client/server setup that depends on having client and server
> configured for the same prefix, seriously.

Any client/server where the server merely listens on a known TCP port does not have the issue. But any client/server such as libvirt where the server does not open any TCP port itself but instead listens only on a Unix socket, and where remote connection relies on ssh or other transport to patch things through to the local Unix socket path, has the issue of knowing what the Unix socket path is.

> 
> And from what part of the error message should I deduct that the path to the
> socket is derived from the local setup?

Perhaps that could indeed be improved, by having the error message list the path that was attempted.

> Having to know the remote socket path is a design flaw, that should be
> handled by the protocol,

Umm, how do you propose to do that?  Connecting to the remote side to ask what its socket path is implies that you know the socket path.  It's a chicken-and-egg situation - you CAN'T ask the remote side protocol to tell you where it lives if you don't already know how to connect to the remote side.

You are more than welcome to attempt a patch, though.

(In reply to Eric Blake from comment #4)
> (In reply to Andreas Nilsson from comment #3)
> > Are you for real!?
> > 
> > Ok, lets not call it a bug then, but a serious design flaw. I know of no
> > other client/server setup that depends on having client and server
> > configured for the same prefix, seriously.
> 
> Any client/server where the server merely listens on a known TCP port does
> not have the issue. But any client/server such as libvirt where the server
> does not open any TCP port itself but instead listens only on a Unix socket,
> and where remote connection relies on ssh or other transport to patch things
> through to the local Unix socket path, has the issue of knowing what the
> Unix socket path is.
> 
> > 
> > And from what part of the error message should I deduct that the path to the
> > socket is derived from the local setup?
> 
> Perhaps that could indeed be improved, by having the error message list the
> path that was attempted.
> 
> > Having to know the remote socket path is a design flaw, that should be
> > handled by the protocol,
> 
> Umm, how do you propose to do that?  Connecting to the remote side to ask
> what its socket path is implies that you know the socket path.  It's a
> chicken-and-egg situation - you CAN'T ask the remote side protocol to tell
> you where it lives if you don't already know how to connect to the remote
> side.

I proposed to add a directive to virsh that prints the socket path, lets call it socketpath, so that virsh socketpath would return /path/to/socket

The the client could issue a "ssh $server virsh socketpath" and then use the return value for the path in the actual connect call.

> 
> You are more than welcome to attempt a patch, though.

I would think a much cleaner solution would be to use ssh subsystem support, because than the server side setup would be abstracted to the Subsystem definition in sshd_config, like
Subsystem  virsh  /usr/bin/nc -q /path/to/socket
and client could happily just use ssh -s virsh