failed to determine the IP address of "<node-name>" when using `proxmox_virtual_environment_file` about terraform-provider-proxmox HOT 28 CLOSED

I'm re-tagging this issue as "question", as there seems to be no unexpected behaviour with the provider.

from terraform-provider-proxmox.

Nevermind, I found it. : https://github.com/bpg/terraform-provider-proxmox/blob/main/proxmox/virtual_environment_datastores.go#L237

from terraform-provider-proxmox.

1. First, appreciate your eyes on this. :D

2. It's going to take me a minute but I will get some curls against the API and try to correlate that with logs and share them. The /nodes/<node>/network thing is interesting because I not only have a few interfaces in that server but I have quite a few VLANs as well.

Please stay tuned...

from terraform-provider-proxmox.

Hi @kunleoladimeji!

None of the interfaces from the list have a static IP, so the provider can't determine the address it should use to connect to the pve-1 node.

Currently, the provider does not use DNS lookup to determine the node IP. There is an open PR to add it as a fallback mechanism. I'll probably go ahead, clean up, and merge it for the next release.

In the meantime, you can specify an IP override for your PVE node(s) as described here in the section "Node IP address used for SSH connection."

from terraform-provider-proxmox.

Added a static IP to the management interface and works fine!

from terraform-provider-proxmox.

Note: If the node_name is changed to an IP address, I get the following error:

error: Received an HTTP 596 response - Reason: tls_process_server_certificate: certificate verify failed

from terraform-provider-proxmox.

Thanks for the report. Just a quick sanity check -- I don't see the password field is being set in the virtual_environment section. Is it simply omitted in the example here, or is actually missing in the template?

from terraform-provider-proxmox.

It is missing in the template and is instead set by an environment variable.

from terraform-provider-proxmox.

Also note: I've gotten the package to create a vm (so the login works for the API), I just can't get it to build a file.

from terraform-provider-proxmox.

So, since submitting this ticket, I have gotten a DNS Server up and running. It works fine (pinging moneta works), however I'm still getting the same problem. (failed to determine the IP address of node "moneta").

Just thought I would throw this out there, as it doesn't appear to be a (management computer) DNS problem.

from terraform-provider-proxmox.

Thanks, will take a look in the next few days.

from terraform-provider-proxmox.

Hey @spott, unfortunately, I wasn't able to reproduce the issue. My test PVE instance was able to create a file successfully, using your example.

Though in my case the node name pve is not resolvable via DNS, but it is set as the host name in the Proxmox configs and at the OS level:

from terraform-provider-proxmox.

Thanks! It was the hostname.

Now I get a success from terraform... but no snippet in the snippet directory... I'm not sure what I'm missing.

Trying to use output blocks to look at file_name, file_tag, file_modification_date, and file_size don't show anything, and the task log doesn't show anything either.

When I do a terraform destroy, I'm getting a task of "erase data" that says the file doesn't exist.

Any ideas?

from terraform-provider-proxmox.

Does you storage (I assume it is local?) support "Snippets"? Is the target folder writable? This is how it looks like on my PVE:

from terraform-provider-proxmox.

Ok, it looks like that is a permissions issue, though I'm unclear what permissions I need to give.

from terraform-provider-proxmox.

@spott I'm going to close this ticket as the original issue (as per title) seems to be resolved.
You may try to review installation and storage configuration steps of your PVE environment to see if there is anything missing from the setup.

from terraform-provider-proxmox.

I was able to repro this reliably and I was able to get past it by using the FQDN, as opposed to the shortname, of the proxmox server in node_name parameter of the file resource.

I'll dive down into the code for that resource and see if I can spot anything obvious though I'm not a golang hacker...

from terraform-provider-proxmox.

So, it's interesting....using the FQDN gets past the inability to resolve the node_name however it later throws errors during apply in that it fails to verify the TLS cert of the server even if I have told the Provider to not do TLS cert verification:

Error: received an HTTP 596 response - Reason: tls_process_server_certificate: certificate verify failed

from terraform-provider-proxmox.

I got as far as seeing how the node_name is packed/unpacked as a schema item. It looks to me like the schema stuff comes from the HashiCorp SDK plugin but I didn't see anything there to suggest that that SDK would care about shortnames v FQDNs.

Not sure how to proceed except to say I can repro this very reliably.

Perhaps it makes sense to re-open this Issue?

from terraform-provider-proxmox.

Hey @nrvale0, I suspect the " failed to determine the IP address" error is coming from this function

It opens an SSH session with the node by its hostname, which is taken from the node_name parameter.
This means that this node's short hostname must resolve to an IP from the machine you're running terrafrom on.

Could you check if you can, for example, ping the proxmox host by its short name from this machine? If not, check hostname -d output on this machine. If it is empty, you may need to add your domain name to /etc/resolv.conf (or similar, whichever is appropriate for your OS)

from terraform-provider-proxmox.

The Proxmox server name resolves as shortname and FQDN. I even did a packet dump of the DNS traffic, noticed that there was some IPv6 going on, and disabled IPv6 on all nodes and the switch/router just to reduce the possible variables.

I need to do a packet dump of the TF apply traffic to rule out a resolution problem there since I think I recall golang has its own resolver library it favors over the one in the OS.

My network uses a TLD that is not an official TLD so... ? It's weird that other resources with the same node_name specified don't seem to have any issues.

from terraform-provider-proxmox.

Just confirming that DNS capture during TF apply with both shortname and FQDN come back clean, correct, and with no intermediate errors but end result is still "failed to determine..."

from terraform-provider-proxmox.

It opens an SSH session with the node by its hostname, which is taken from the node_name parameter.

Can you elaborate on this? The TF Provider makes an SSH connection to the Proxmox server? I'm trying to think of scenario where I would expect that to happen.

Connecting to the spun VM for, say, cloud-init or a TF provisioner run ... those scenarios sort of fit with my expectations.

from terraform-provider-proxmox.

Could you also run with TF_DEBUG=1 terraform apply ... and attach the log?

from terraform-provider-proxmox.

Sure. Two files below. The file names describe the scenario but basically using shortname and FQDN. When I saw that it "works" with FQDN I mean that it was able to at least resolve the host and connect to it but as you can see it failed because it was upset that the FQDN was not present in TLS certificate. But that's at least further than it gets with shortname.

I did not provide output showing that both names resolve because it exposes a bit too much information about internal network. I guess you'll have to trust my nslookup/dig/host skills. ;)

• tf-shortname-apply.log

• tf-fqdn-apply.log

Also, re previous comments about it being weird that some resources with specified node_name worked while others did not...that makes a lot more sense if there's an SSH going on when creating ..._environment_file resource.

from terraform-provider-proxmox.

OK, DNS was a red herring, the issue is related to the way the provider determines the node IP when it opens SSH. It doesn't do a DNS lookup, but rather calls proxmox API /nodes/<node>/network to list node's network devices and get the IP from there.

So, for some reason it either gets back an empty list, or adapter(s) has no IP4s set. The former could be a permission issue, the latter seems quite possible for DHCP-assigned IPs. Could you pls double check that?

from terraform-provider-proxmox.

I encountered the same error today:

Error: failed to find node endpoint: failed to determine the IP address of node "pve-1"

I have verified that DNS for the hostname works from both Proxmox and also my local dev machine.

Could it be that there is no check if the interface is active? I am certain that all the active interfaces can resolve the hostname fine.

Here's my current network config.

root@pve-1:/var/lib/vz# pvesh get /nodes/pve-1/network
┌────────┬───────────┬───────────┬─────────────────┬────────────┬─────────────────────────────────────────┬────────┬──────────┬─────────────────┬────────┬─────────┬──────────┬─────────┐
│ active │ autostart │ bridge_fd │ bridge_ports    │ bridge_stp │ comments                                │ exists │ families │ iface           │ method │ method6 │ priority │ type    │
╞════════╪═══════════╪═══════════╪═════════════════╪════════════╪═════════════════════════════════════════╪════════╪══════════╪═════════════════╪════════╪═════════╪══════════╪═════════╡
│        │           │           │                 │            │                                         │        │ ["inet"] │ wlp1s0          │ manual │ manual  │ 5        │ unknown │
├────────┼───────────┼───────────┼─────────────────┼────────────┼─────────────────────────────────────────┼────────┼──────────┼─────────────────┼────────┼─────────┼──────────┼─────────┤
│ 1      │ 1         │           │                 │            │ Management Interface                    │ 1      │ ["inet"] │ enp2s0          │ manual │ manual  │ 3        │ eth     │
├────────┼───────────┼───────────┼─────────────────┼────────────┼─────────────────────────────────────────┼────────┼──────────┼─────────────────┼────────┼─────────┼──────────┼─────────┤
│ 1      │ 1         │           │                 │            │ Bridge Interface for VMs and Containers │ 1      │ ["inet"] │ enx207bd24f48a2 │ manual │ manual  │ 4        │ eth     │
├────────┼───────────┼───────────┼─────────────────┼────────────┼─────────────────────────────────────────┼────────┼──────────┼─────────────────┼────────┼─────────┼──────────┼─────────┤
│ 1      │ 1         │ 0         │ enx207bd24f48a2 │ off        │ VM Bridge                               │        │ ["inet"] │ vmbr0           │ manual │ manual  │ 6        │ bridge  │
└────────┴───────────┴───────────┴─────────────────┴────────────┴─────────────────────────────────────────┴────────┴──────────┴─────────────────┴────────┴─────────┴──────────┴─────────┘```

from terraform-provider-proxmox.

Thanks for the clear explanation.

I'll update the Proxmox Web UI to reflect the static IP of the management interface and retry.

from terraform-provider-proxmox.