Stuck on LXC ssh key management

[Mijux]

Hello,
I am trying to generate one LXC with my public key.

NOTE: I tried without the ssh keys and my config works

Below is the tf log when creating my LXC:

 # module.lxc.proxmox_virtual_environment_container.batch_lxcs["1"] will be created
  + resource "proxmox_virtual_environment_container" "batch_lxcs" {
      + description    = <<-EOT
            Debian LXC
        EOT
      + id             = (known after apply)
      + node_name      = "[redacted]"
      + pool_id        = "[redacted]"
      + protection     = false
      + start_on_boot  = true
      + started        = true
      + tags           = [
          + "debian-12",
        ]
      + template       = false
      + timeout_clone  = 1800
      + timeout_create = 1800
      + timeout_delete = 60
      + timeout_start  = 300
      + timeout_update = 1800
      + unprivileged   = true
      + vm_id          = 10004

      + clone {
          + datastore_id = "[redacted]"
          + node_name    = "[redacted]"
          + vm_id        = 400
        }

      + console {
          + enabled   = true
          + tty_count = 2
          + type      = "tty"
        }

      + cpu {
          + architecture = "amd64"
          + cores        = 1
          + units        = 1024
        }

      + disk {
          + datastore_id = "[redacted]"
          + size         = 32
        }

      + features {
          + fuse    = false
          + keyctl  = false
          + mount   = []
          + nesting = true
        }

      + initialization {
          + hostname = "test-lxc-debian"

          + dns {
              + domain  = "[redacted]"
              + servers = [
                  + "1.1.1.1",
                ]
            }

          + ip_config {
              + ipv4 {
                  + address = "[redacted]"
                  + gateway = "[redacted]"
                }
              + ipv6 {
                  + address = "dhcp"
                }
            }

          + user_account {
              + keys = [
                  + "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKmdszWbK/Ix0Vz+b1gwL/Yeed9HYAM28NMPs/LOph3O",
                ]
            }
        }

      + memory {
          + dedicated = 1024
          + swap      = 512
        }

      + network_interface {
          + bridge     = "vmbr0"
          + enabled    = true
          + firewall   = false
          + mtu        = 800
          + name       = "eth0"
          + rate_limit = 0
          + vlan_id    = 110
        }

      + startup {
          + down_delay = 0
          + order      = 100
          + up_delay   = 0
        }
    }

But I get the following error:

╷
│ Error: error updating container: received an HTTP 400 response - Reason: Parameter verification failed. (ssh-public-keys: property is not defined in schema and the schema does not allow additional properties)
│ 
│   with module.lxc.proxmox_virtual_environment_container.batch_lxcs["1"],
│   on lxc/main.tf line 1, in resource "proxmox_virtual_environment_container" "batch_lxcs":
│    1: resource "proxmox_virtual_environment_container" "batch_lxcs" {
│ 
╵

It seems that the provider tries to update the LXC config after its creation but the Proxmox API does not allow modification

Logs from /var/log/pveproxy/access.log

"PUT /api2/json/nodes/[redacted]/lxc/10004/config HTTP/1.1" 400 175

And then here the API Proxmox documentation:

• Create LXC - POST
  • Here we can see that ssh-public-keys is referenced
• Update LXC - PUT

If this is a bug, I can create an issue with all the information abose

[bpg]

Hey @Mijux 👋🏼

Hm... not sure what's going on here. I just tried to create a container, and it works fine:

resource "proxmox_virtual_environment_container" "ubuntu_container" {
  description = "Managed by Terraform"

  node_name = "pve"
  vm_id     = 1234

  initialization {
    hostname = "terraform-provider-proxmox-ubuntu-container"

    ip_config {
      ipv4 {
        # address = "dhcp"
        address = "192.168.3.233/24"
        gateway = "192.168.3.1"
      }
    }

    user_account {
      keys     = ["ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOQCHPhOV9XsJa3uq4bmKymklNy6ktgBB/+2umizgnnY"]
    }
  }

  network_interface {
    name = "veth0"
  }

  disk {
    datastore_id = "local-lvm"
    size         = 4
  }

  operating_system {
    template_file_id = "local:vztmpl/ubuntu-20.04-standard_20.04-1_amd64.tar.gz"
    type             = "ubuntu"
  }
}

❯ tofu apply -auto-approve

OpenTofu used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

OpenTofu will perform the following actions:

  # proxmox_virtual_environment_container.ubuntu_container will be created
  + resource "proxmox_virtual_environment_container" "ubuntu_container" {
      + description    = <<-EOT
            Managed by Terraform
        EOT
      + id             = (known after apply)
      + node_name      = "pve"
      + protection     = false
      + start_on_boot  = true
      + started        = true
      + template       = false
      + timeout_clone  = 1800
      + timeout_create = 1800
      + timeout_delete = 60
      + timeout_start  = 300
      + timeout_update = 1800
      + unprivileged   = false
      + vm_id          = 1234

      + disk {
          + datastore_id = "local-lvm"
          + size         = 4
        }

      + initialization {
          + hostname = "terraform-provider-proxmox-ubuntu-container"

          + ip_config {
              + ipv4 {
                  + address = "192.168.3.233/24"
                  + gateway = "192.168.3.1"
                }
            }

          + user_account {
              + keys = [
                  + "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOQCHPhOV9XsJa3uq4bmKymklNy6ktgBB/+2umizgnnY",
                ]
            }
        }

      + network_interface {
          + bridge     = "vmbr0"
          + enabled    = true
          + firewall   = false
          + mtu        = 0
          + name       = "veth0"
          + rate_limit = 0
          + vlan_id    = 0
        }

      + operating_system {
          + template_file_id = "local:vztmpl/ubuntu-20.04-standard_20.04-1_amd64.tar.gz"
          + type             = "ubuntu"
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.
proxmox_virtual_environment_container.ubuntu_container: Creating...
proxmox_virtual_environment_container.ubuntu_container: Creation complete after 6s [id=1234]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
❯ tofu apply -auto-approve

Changing user_account (like adding a password) causes replacement, as expected (you're right, there is no way to update that over API.

❯ tofu apply -auto-approve
proxmox_virtual_environment_container.ubuntu_container: Refreshing state... [id=1234]

OpenTofu used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement

OpenTofu will perform the following actions:

  # proxmox_virtual_environment_container.ubuntu_container must be replaced
-/+ resource "proxmox_virtual_environment_container" "ubuntu_container" {
      ~ id             = "1234" -> (known after apply)
      - tags           = [] -> null
        # (13 unchanged attributes hidden)

      ~ initialization {
            # (1 unchanged attribute hidden)

          ~ user_account {
              + password = (sensitive value) # forces replacement
                # (1 unchanged attribute hidden)
            }

            # (1 unchanged block hidden)
        }

      ~ network_interface {
          - mac_address = "BC:24:11:79:58:A2" -> null
            name        = "veth0"
            # (6 unchanged attributes hidden)
        }

        # (2 unchanged blocks hidden)
    }

Plan: 1 to add, 0 to change, 1 to destroy.
proxmox_virtual_environment_container.ubuntu_container: Destroying... [id=1234]
proxmox_virtual_environment_container.ubuntu_container: Destruction complete after 4s
proxmox_virtual_environment_container.ubuntu_container: Creating...
proxmox_virtual_environment_container.ubuntu_container: Creation complete after 7s [id=1234]

Apply complete! Resources: 1 added, 0 changed, 1 destroyed.

But I can update other initialization parameters without re-creating the container, like IP:

❯ tofu apply -auto-approve
proxmox_virtual_environment_container.ubuntu_container: Refreshing state... [id=1234]

OpenTofu used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

OpenTofu will perform the following actions:

  # proxmox_virtual_environment_container.ubuntu_container will be updated in-place
  ~ resource "proxmox_virtual_environment_container" "ubuntu_container" {
        id             = "1234"
        tags           = []
        # (13 unchanged attributes hidden)

      ~ initialization {
            # (1 unchanged attribute hidden)

          ~ ip_config {
              ~ ipv4 {
                  ~ address = "192.168.3.233/24" -> "dhcp"
                  - gateway = "192.168.3.1" -> null
                }
            }

            # (1 unchanged block hidden)
        }

        # (3 unchanged blocks hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.
proxmox_virtual_environment_container.ubuntu_container: Modifying... [id=1234]
proxmox_virtual_environment_container.ubuntu_container: Modifications complete after 0s [id=1234]

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

So i'm really puzzled what's going on there. Would you mind sharing your full log of terraform appy ?

[Mijux]

Hello again @bpg ,

Thank you for your quick reply! I was able to read your answer and especially your terraform file...

During a break, I found the solution!

The problem is not with the provider itself, but with proxmox. So I tested it from the interface and in my tf configuration. The problem is as follows:

• It is not possible to enter an SSH public key from an LXC clone. This is only possible using the operating_system block and is not possible with the clone block.

So I just replace the following:

  console {
    enabled               = each.value.console.enabled
    type                  = each.value.console.type
    tty_count             = each.value.console.tty_count
  }

with:

  operating_system {
    template_file_id      = each.value.operating_system.template_file_id
    type                  = each.value.operating_system.type
  }

And it works!

This is not the first time I have encountered a problem of “dependency” between certain blocks. In the end, it's not a problem linked to your provider but to the limitations imposed by Proxmox.....

[bpg]

Ah, I missed the clone part in your original post 🤦🏼
That explains it. I do think there's room for improvement, though the use case isn't entirely straightforward, as cloning is quite a complex process in the provider.

I'll create an enhancement ticket to address that.