[libvirt-users] 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@redhat.com> | larsks @ {freenode,twitter,github} Cloud Engineering / OpenStack | http://blog.oddbit.com/
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@redhat.com> | larsks @ {freenode,twitter,github} Cloud Engineering / OpenStack | http://blog.oddbit.com/
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
participants (3)
-
Cole Robinson -
Lars Kellogg-Stedman -
Peter Krempa