libvirt users - May 2016 - Re: Making remote access to qemu://session easier?

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.

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.

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
ultimately act like "nc -U /path/to/some/socket".

-- 
Lars Kellogg-Stedman <lars at redhat.com> | larsks @
{freenode,twitter,github}
Cloud Engineering / OpenStack          | http://blog.oddbit.com/

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

On Mon, May 02, 2016 at 11:57:24AM -0400, Lars Kellogg-Stedman
wrote:
> And in either of the above cases, "libvirt-socket-helper" would
parse
> the environment and the libvirtd configuration as necessary and
> ultimately act like "nc -U /path/to/some/socket".
In fact, this would be *extra* useful, because of course right now you
simply can't access a remote .../session instance unless you have
either (a) just run a "virsh" comman recently on the remote host, or
(b) otherwise set up a persistent user libvirt instance.

Having a remote helper like this would mean that it could start up the
user libvirt instance just like "virsh" does right now.

-- 
Lars Kellogg-Stedman <lars at redhat.com> | larsks @
{freenode,twitter,github}
Cloud Engineering / OpenStack          | http://blog.oddbit.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://listman.redhat.com/archives/libvirt-users/attachments/20160502/9a1812d4/attachment.sig>

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.
> 
> 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.
> 
> 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
> 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

- Cole

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