uri parameter in the provider block is broken/being ignored

[nohoster]

System Information

Linux distribution

Ubuntu..

Terraform version

1.6.0

Provider and libvirt versions

v0.7.4

---

It seems the uri is being ignored on the most recent version. It just tries to use a local libvirt sock instead of making the ssh connection. Luckily I still had the 0.7.1 version in disk so I changed it and it's working again. The problem is I can't download that version due to the key signing issue.

[nohoster]

I think i know what's the problem. #1030 makes the username a required parameter. If not set then the ssh connection is ignored.

[michaelbeaumont]

Please include the URI you're using

[unimika]

I am facing this same problem with latest Terraform and 0.7.4. All the virtual machines are created to local machine instead of remote machine.

The uri I am using is in format uri = "qemu+ssh://virtuser@10.0.0.10/system"

Managed to continue with:
terraform { required_providers { libvirt = { source = "dmacvicar/libvirt" version = "0.7.1" } } }

[michaelbeaumont]

@nohoster what do you mean #1030 makes the username required? What makes you think it's that PR? There have been a number of larger changes since the last release

[settler-als]

All versions 0.7.* ignore uri and work only local. 0.6.14 work good.

provider "libvirt" {
uri = "qemu+ssh://login@servername/system"
}

[nohoster]

Hi, my uri is "qemu+ssh://192.168.1.100:2221/system?known_hosts_verify=ignore".
I was using that perfectly fine with 0.7.1 but then I created a new project with 0.7.4 and it gave me this error:

│ Error: failed to connect: dial unix /var/run/libvirt/libvirt-sock: connect: no such file or directory
│
│ with provider["registry.terraform.io/dmacvicar/libvirt"],
│ on providers.tf line 1, in provider "libvirt":
│ 1: provider "libvirt" {

That's because it's trying to use a local connection

I did a test just know with just some bare code:

terraform {
required_version = ">= 1.4"
required_providers {
libvirt = {
source = "dmacvicar/libvirt"
version = ">=0.7"
}
}
}
provider "libvirt" {
uri = "qemu+ssh://user@192.168.1.100:2221/system?known_hosts_verify=ignore"
}
resource "libvirt_network" "terraform-net" {
name = "terraform-net"
mode = "nat"
addresses = ["192.168.140.0/24"]
}

and it gave me the same error, so the user in the uri is not the problem. So that PR is not the problem.

To add more info, after I downgraded to 0.7.1 and made a successful connection, I was able to update to 0.7.4 and it's working again.

[rabin-io]

Can it be related to this PR which was merged recently?

[limburgher]

I'm on terraform 1.6.1 and I can't get 0.7.* to work. 0.6.14 seems to. I've not tried anything older. My uri is qemu+ssh://username@hostname/system.

[tuxillo]

Same here. Are there any plans to fix this?

[Mandorath]

I was checking this, I removed the changes done in #1030 and tried a rebuild to verify if this was the change that broke anything. It will still try to connect to a local libvirt socket. My guess would be that the following commit introduced this: 6a406f7 but I might be wrong. I think those changes might have been done due to updating the required go-libvirt package if i do a diff between 0.7.1 and 0.7.4. Here the 'New' function has been deprecated and replaced with NewWithDialer, the change in the commit reflects this.

I have very limited Go knowledge myself but looking at the code maybe it is defaulting to unix in the code below for some reason e.g. the URI is not parsed properly or missing something:

func (u *ConnectionURI) transport() string {
	parts := strings.Split(u.Scheme, "+")
	if len(parts) > 1 {
		return parts[1]
	}

	if u.Host != "" {
		return "tls"
	}
	return "unix"
}

https://github.com/dmacvicar/terraform-provider-libvirt/blob/6a406f773e176ba872ca75a54fa1412f0ae2340e/libvirt/uri/connection_uri.go

Or the dialers are not picked up properly. At this point, I have no idea how to debug this.

You can also find a discussion about dialers below:
digitalocean/go-libvirt#143
digitalocean/go-libvirt#139

[X-Cli]

I believe this issue has the same root cause that the issue that I helped identify in #1040 . Can you retry with the fix that was merged earlier today?

[rabin-io]

With version 0.7.4 (latest as of this moment) I still see this issue.

[michaelbeaumont]

Yes, that's the release the issue was initially made for. There has been the above mentioned fix merged to master since then.

[rabin-io]

How can I test it w/o compiling it manually?

[michaelbeaumont]

You will need to compile it manually and configure terraform to look for the compiled provider

[tuxillo]

Any reason why there hasn't been a new release?

[ingobecker]

I believe this issue has the same root cause that the issue that I helped identify in #1040 . Can you retry with the fix that was merged earlier today?

I had the same issue and tested against 8d7c58f. This fixed the issue for me. Thanks 👍

[limburgher]

When will there be a release with this fix?

[tuxillo]

When will there be a release with this fix?

Exactly. I don't know why the issue is clused when there is no new release yet.

[X-Cli]

Until there is a new release with the fix, people needing an urgent workaround can add the "name" parameter, which makes the bugged function return before the bug manifests.

For instance, if the URI is qemu+ssh://user@host/system?blablabla you can change it to qemu+ssh://user@host/system?name=qemu%3A%2F%2F%2Fsystem&blablabla

In this example, the name parameter is set to qemu:///system in a URL-encoded format. This value was chosen by hand, following the algorithm described in the documentation (i.e. keeping only what is before the + sign, the string "://", followed by the path, including the leading slash, and leaving out the user, the @ sign, the host, and the query string).

Please remember to remove the workaround when the new version is released, as this is a bit dirty ^^

[limburgher]

Thank you, this workaround seems to work.

[limburgher]

0.7.6 works with the standard uri syntax.