Bug 1032709 - virsh fails for qemu+ssh uris when configured with any other prefix than /usr
virsh fails for qemu+ssh uris when configured with any other prefix than /usr
Status: CLOSED NOTABUG
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Libvirt Maintainers
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-20 10:48 EST by Andreas Nilsson
Modified: 2013-11-21 09:56 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-20 11:02:14 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Strace of working virsh (65.51 KB, text/plain)
2013-11-20 10:48 EST, Andreas Nilsson
no flags Details
strace of non-working virsh (58.08 KB, text/plain)
2013-11-20 10:49 EST, Andreas Nilsson
no flags Details

  None (edit)
Description Andreas Nilsson 2013-11-20 10:48:50 EST
Created attachment 826724 [details]
Strace of working virsh

Description of problem:
Running virsh over ssh ( qemu+ssh:// uri ) fails to connect to hypervisor when libvirt is configured with any other prefix than /usr

Version-Release number of selected component (if applicable):
Happens in at least 1.1.1, 1.1.3 and 1.1.4

How reproducible:
Always, on Linux ( ubuntu 13.10 amd64 , FreeBSD 10.0-BETA3, 8.2-RELEASE-p7 and OS X 10.9 )

Steps to Reproduce:
1. configure --prefix=/usr/local/libvirt (for example)
2. make && make install
3. virsh -c qemu+ssh://host/system

Actual results:
$ virsh -c qemu+ssh://exodus/system
error: failed to connect to the hypervisor
error: internal error: received hangup / error event on socket
or
$ virsh -c qemu+ssh://exodus/system
error: failed to connect to the hypervisor
error: End of file while reading data: : Input/output error

Expected results:
$ virsh -c qemu+ssh://exodus/system
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit

virsh # 


Additional info:
Attached is to strace runs from, one with a libvirt with prefix=/usr and one with prefix=/usr/local
Comment 1 Andreas Nilsson 2013-11-20 10:49:41 EST
Created attachment 826725 [details]
strace of non-working virsh
Comment 2 Daniel Berrange 2013-11-20 11:02:14 EST
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
Comment 3 Andreas Nilsson 2013-11-21 04:25:28 EST
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.
Comment 4 Eric Blake 2013-11-21 08:52:20 EST
(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.
Comment 5 Andreas Nilsson 2013-11-21 09:56:34 EST
(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

Note You need to log in before you can comment on or make changes to this bug.