Support new modular libvirt daemons

[michaelbeaumont]

Provider and libvirt versions

$ terraform-provider-libvirt -version
0.7.1

libvirt 9.5.0

---

Description of Issue/Question

Setup

There's a new modular architecture for the libvirt daemons that's not supported by this provider.

Steps to Reproduce Issue

There is no longer a /var/run/libvirt/libvirt-sock with this setup, so any attempt to use the provider via the unix socket fails.

For example using qemu+ssh I was running into ssh: rejected: connect failed (open failed)

[michaelbeaumont]

Actually there's now virtproxyd as described here that provides the old socket. It works after enabling that socket and service!

[kastl-ars]

Just stumbled upon this. In your case, this is valid as you like to connect via SSH. But enabling the proxy on local machine just to use this provider seems like an ugly workaround.

So this would be nice to have without the proxy workaround.

[michaelbeaumont]

@kastl-ars I don't know, I think it's not really a workaround, it's the official way to get a socket interface

[kastl-ars]

@kastl-ars I don't know, I think it's not really a workaround, it's the official way to get a socket interface

Hi @michaelbeaumont

the documentation says this:

If connections from remote hosts need to be supported the proxy daemon must be enabled and started

This explicitly mentions "remote hosts". That is way I called it a workaround.

Local connections using virsh are working even with the proxy daemon disabled, as there are lots of sockets available. My guess is that the libvirt provider "just needs to be told" to look in a different place for the socket...

[michaelbeaumont]

I'm not enough of an expert in libvirt here but from my understanding, the issue is that there are multiple sockets now. Is it clear that we only need say, the qemud socket? I don't know. Also we'd need digitalocean/go-libvirt#171 anyway, because the API calls happen in go-libvirt.