I am sorry for nuking the template - none of it applies. This is a feature request / change proposal.
Currently, this provider connects to libvirt/qemu over SSH with SSH unix socket forwarding (direct-streamlocal).
virsh itself does not do this - instead, it uses a binary called virt-ssh-helper running in a terminal session - here is sshd debug of this happening:
debug3: mm_audit_run_command entering command sh -c 'which virt-ssh-helper 1>/dev/null 2>&1; if test $? = 0; then virt-ssh-helper 'qemu:///system'; else if 'nc' -q 2>&1 | grep "requires an argument" >/dev/null 2>&1; then ARG=-q0;else ARG=;fi;'nc' $ARG -U /opt/homebrew/var/run/libvirt/libvirt-sock; fi'
My proposal is that this provider should do the same - as some ssh servers (for example, the tailscale sshd) does not support direct-streamlocal (unix) channels.
Alternatively, perhaps we try direct-streamlocal, and fall back to virt-ssh-helper if this errors?
I am sorry for nuking the template - none of it applies. This is a feature request / change proposal.
Currently, this provider connects to libvirt/qemu over SSH with SSH unix socket forwarding (direct-streamlocal). virsh itself does not do this - instead, it uses a binary called
virt-ssh-helperrunning in a terminal session - here is sshd debug of this happening:My proposal is that this provider should do the same - as some ssh servers (for example, the tailscale sshd) does not support direct-streamlocal (unix) channels.
Alternatively, perhaps we try direct-streamlocal, and fall back to virt-ssh-helper if this errors?