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 _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users