[libvirt-users] Making remote access to qemu://session easier?

[Peter Krempa]

On Mon, May 02, 2016 at 12:07:43 -0400, Cole Robinson wrote:
> On 05/02/2016 11:57 AM, Lars Kellogg-Stedman wrote:
> > This is frustrating:
> > 
> >   $ export LIBVIRT_DEFAULT_URI=qemu+ssh://remotehost/session
> >   $ virsh list
> >   error: failed to connect to the hypervisor
> >   error: no valid connection
> >   error: Operation not supported: Connecting to session instance without socket path is not supported by the ssh connection driver
> > 
> > Has there been any thought given to making this easier?  It seems that
> > having a simple helper script on the remote host that could make the
> > same "use $XDG_RUNTIME_DIR or use $HOME/.confg" decision as libvirtd
> > would be able determine the socket path automatically.

Rather than a helper script I planned to add a new binary that would do
the proxy service as we currently do with 'nc' since nc does not really
do a good job in error reporting.

The custom binary would also use the default paths compiled in at the
remote side, since if you compile the client library with a different
path it will break even for /system connections.

> > 
> > Would that be a reasonable solution?
> > 
> > I see that right now, even support for qemu://remotehost/system
> > requires that "virsh" knows that path to the remote socket, so having
> > a remote helper that can read the libvirt configuration might simplify
> > things in general.

The path is compiled in in the libvirt client library and passed to the
ssh command line from the client. Virsh merely passes the URI at that
point -> all client apps are experiencing the same issue.

> > 
> > That is, I am envisioning that for .../session connections, virsh
> > would do something like:
> > 
> >     ssh remotehost libvirt-socket-helper --user
> > 
> > And for .../system connections, virsh would do something like:
> > 
> >     ssh remotehost libvirt-socket-helper --system
> > 
> > Rather than:
> > 
> >    ssh remotehost sh -c 'if nc -q 2>&1 | grep \"requires an argument\"
> >    >/dev/null 2>&1; then ARG=-q0;else ARG=;fi;nc $ARG -U /var/run/libvirt/libvirt-sock'
> > 
> > 
> > And in either of the above cases, "libvirt-socket-helper" would parse
> > the environment and the libvirtd configuration as necessary and

This is the important part. For /session connections it's usually
necessary to start the session daemon, which is not possible with the nc
part. By using a helper compiled against libvirt we can use the internal
functions to do the correct thing.

> > ultimately act like "nc -U /path/to/some/socket".
> 
> Yes it's been thought of before, see this bug which isn't heavy on details but
> it would likely look something like your proposal:
> https://bugzilla.redhat.com/show_bug.cgi?id=1241313
> 
> Just no one has gotten around to implementing it yet

Yes that is exactly it. I'm still having that on my mind but I didn't
have much time to do this.

Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20160503/d1b00af1/attachment.sig>