Description of problem: Can't remotely connect to qemu:///session instances (which is normally possible with virsh with URLs like "qemu+ssh://hostname/session?socket=path") because one can't enter such a URL in the UI. Manually hacking in the URI with dconf seems to mostly work, but (for example) I quickly encountered a bug when creating a VM where virt-manager assumed the only usable storage pool was my *local* homedir instead of the remote homedir. virsh and other tools support these connections just fine. Some justification of why this is useful: The reason I want to remotely connect to a QEMU session instance is because with qemu-bridge-helper giving unprivileged access to bridges, if one also does chmod 666 /dev/kvm, QEMU session instances actually become quite useful. You can run actual production VMs with them. Specifically, I want to use them as a way to roll out a virtual machine service for all the students at my university: Just give them a shell account, set some ulimits and tell them how to make a session-mode vm. (I know, there are some flaws in my ability to really do limits here, but it's enough for my use case). If they were able to use virt-manager instead of virsh to manage those VMs, it would sure make it easier for them... and I think there are a lot of this kind of use case that are enabled by the existence of qemu-bridge-helper.
For the 'Add Connection' wizard, I don't want to add any UI to support this explicitly since as you mention in the email thread this isn't really a common libvirt use case and it doesn't seem to be supported well (for example there's no autodaemon launching) https://www.redhat.com/archives/virt-tools-list/2015-July/msg00033.html But you can do get this in an easier way than hacking dconf: just launch virt-manager --connect $YOUR-URI and it will be saved permanently to the URI list. We can use this bug to track the other issue you report, that we assume session URIs always == local. There's likely a few issues like that lingering around
I'm open to tweaking virt-manager to not choke on this case, but given current resources and the niche nature of this usecase, I don't expect it to be implemented. However if someone shows up with patches I will be happy to review and test them. Closing as DEFERRED