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@xxxxxxxxxx> | larsks @ {freenode,twitter,github} Cloud Engineering / OpenStack | http://blog.oddbit.com/
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users