Proxmox Terraform VM Clone Doesn't Apply Cloud-Init Configurations Properly

[zxy]

I'm using Terraform to deploy VMs on Proxmox by cloning a template. The deployment works in the sense that the VM gets created and starts successfully. However, the VM doesn't apply the Cloud-Init configurations I provided, including:

• The VM doesn't use the specified name.
• The Cloud-Init user and password settings are ignored.

When I manually clone the same template through the Proxmox UI and use Cloud-Init, everything works as expected: the name, user, and password are correctly set.
Here’s a snippet of my Terraform configuration for the Proxmox VM resource:

resource "proxmox_vm_qemu" "test-case-15" {
    name = "humus-3"
    desc = "test blae"
    target_node = "eva"

    vmid = 991
    agent = 1

    clone = "test-temp-no-start"
    full_clone = true

    vga {
        type = "virtio"
    }

  os_type = "l26"
  cores = 2
  sockets = 1

  scsihw   = "virtio-scsi-single"

  disks {
    scsi {
      scsi0 {
        disk {
          size = 20
          storage = "local-lvm"
        }
      }
    }
  }

 network {
   bridge    = "vmbr0"
   firewall  = false
   model     = "virtio"
 }

 ipconfig0 = "ip=dhcp"
 }

Here are the Terraform provider details:

terraform {
 required_providers {
   proxmox = {
     source = "telmate/proxmox"
     version = "3.0.1-rc4"
   }
  }

 required_version = ">= 1.7.1"
}

variable "proxmox_api_url" {
   type = string
}

variable "proxmox_api_token_id" {
   type = string
   sensitive = true
}

variable "proxmox_api_token_secret" {
   type =  string
   sensitive = true
}

provider "proxmox" {
   pm_api_url= var.proxmox_api_url
   pm_api_token_id = var.proxmox_api_token_id
   pm_api_token_secret = var.proxmox_api_token_secret
   pm_tls_insecure = true
   pm_debug = true
   pm_log_levels = {
     _default    = "debug"
     _capturelog = ""
   }
}

my template conf:

agent: 1
boot: order=ide2;scsi0;net0
cipassword: $5$XXUY1nUM$Fu5Oll4nxoO9LpQRBWbvQPrVRdBfWF4PvWh77cpoN37
ciuser: bote
cores: 2
ide0: local-lvm:vm-109-cloudinit,media=cdrom,size=4M
ide2: none,media=cdrom
ipconfig0: ip=dhcp
memory: 2048
meta: creation-qemu=9.0.2,ctime=1732140151
name: test-temp-no-start
net0: virtio=BC:24:11:50:E1:2A,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
scsi0: local-lvm:base-109-disk-0,discard=on,iothread=1,size=20G,ssd=1
scsihw: virtio-scsi-single
serial0: socket
smbios1: uuid=711d1814-4c72-4b08-80ac-7617c0a2de24
sockets: 1
template: 1
vga: serial0
vmgenid: ad659086-8c71-4e25-80de-2315c48fb00d

Things I’ve tried so far:

• Verified that the template has the cloud-init drive attached.
• Ensured that the template is configured with a clean base image using cloud-init.
• Rechecked that the Terraform provider has the necessary permissions on Proxmox.

What could be causing the Terraform-deployed VMs to ignore the Cloud-Init settings?

Any tips on debugging this would be greatly appreciated!

 

[bbgeek17]

Hello @zxy, welcome to the forum.

Terraform integration is not developed or maintained by PVE personnel. Its 3rd party developed and your best bet to get support with it - on their forum/github.

That said,

• Verified that the template has the cloud-init drive attached.

Cloud-init ISO is regenerated on each VM cold start

• Ensured that the template is configured with a clean base image using cloud-init.

What is the base image that you are using?

• The VM doesn't use the specified name.
• The Cloud-Init user and password settings are ignored.

You've posted template VM config file but not the resulting clone'd VM. Have you compared the two? Was the template started at some point, i.e. before it was converted to Template?

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[zxy]

Cloud-init ISO is regenerated on each VM cold start

How to check that, i have seen that the cloud-init DISK is attached to the new vm.

What is the base image that you are using?

Ubuntu 22.04 -> https://cloud-images.ubuntu.com/releases/jammy/release/ubuntu-22.04-server-cloudimg-amd64.img

Was the template started at some point,

Yes, the vm starts and on the init process it fails and shows a "end kernel panic not syncing"
And after restart it starts with the base image and skips the cloud-init

 

[bbgeek17]

How to check that, i have seen that the cloud-init DISK is attached to the new vm.

You can examine the code or watch the log (journalctl -f). Its just how this works.

Yes

You've cut off the second, clarifying, part of my question in your quote. The question was - _before_ you converted your "golden" VM into template, did you start and manipulate it?

it fails and shows a "end kernel panic not syncing"

This would not be related to CloudInit. I'd make sure that this does not happen, to the best of my ability.

Here is what I recommend you do:
a) Create a VM using the original Vendor's qcow image
b) Configure it via PVE (qm/GUI) with all the settings you need
c) Start it and make sure it does what you want
d) Delete this VM, or create a new one
e) Configure it the same way that you configured the first VM
f) Do NOT start it
g) Convert it to Template
h) Clone the Template to new VM
i) Start and examine the results carefully
j) If you are still having issues, report back on the steps you took, output you received, any errors, etc

Keep in mind that thousands of people are using Cloud Image/Template/Cloud Init/Clone workflow as you are reading this, and it works for them. There is most likely an error or missing step in your workflow.

Do all of the above without using Terraform. Once you have the procedure down, and you are sure your template works, then you can add Terraform to the mix.

Good luck

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[zxy]

You've cut off the second, clarifying, part of my question in your quote. The question was - _before_ you converted your "golden" VM into template, did you start and manipulate it?

No, I didn't start the VM. I'm confident that the template is working. Before converting the VM into a template, I cloned it and tested the cloned VM. It worked perfectly without any errors. After confirming this, I converted the original VM into a template.

Here is what I recommend you do:

Thank you for your time! I followed all the steps you recommended, and they worked perfectly in the GUI. However, the process fails when I try to implement it using Terraform.

I was hoping someone with more experience could review my Terraform configuration and help me troubleshoot the issue

 

[bbgeek17]

Thank you for your time! I followed all the steps you recommended, and they worked perfectly in the GUI. However, the process fails when I try to implement it using Terraform.

I was hoping someone with more experience could review my Terraform configuration and help me troubleshoot the issue

Great! Now that we know that you have covered your basics, can you address my question from #2:

You've posted template VM config file but not the resulting clone'd VM. Have you compared the two?

Is the configuration of the clone same, similar or different from the template?

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[zxy]

Is the configuration of the clone same, similar or different from the template?

Sry i missed to reply on that.
I gave it another try to ensure everything is correct. Here’s the Terraform snippet:

resource "proxmox_vm_qemu" "test-vm" {
  target_node = "eva"
  clone = "test-temp-no-start"
  count = 1
  vmid = 999
  full_clone = "true"

  agent = 0
  os_type = "cloud-init"
  cores = 1
  sockets = 1

  name = "test-${count.index +1}"
  scsihw   = "virtio-scsi-single"

  disks {
    scsi {
      scsi0 {
        disk {
          size = 20
          storage = "local-lvm"
        }
      }
    }
  }

 network {
   bridge    = "vmbr0"
   firewall  = false
   model     = "virtio"
 }

 ipconfig0 = "ip=dhcp"
 ciuser = "bote"
vm_state = "stopped"

I’ll attach the results as a screenshot. The differences include memory, disk settings (SSD is not enabled), and the absence of Cloud-Init entirely.

 

[bbgeek17]

However, the VM doesn't apply the Cloud-Init configurations I provided, including:

• The VM doesn't use the specified name.
• The Cloud-Init user and password settings are ignored.

My apologies. The way I read the above opening statement is that:
- you confirmed that the VM name is specified and is being ignored by the resulting VM on start.
- CloudInit user and password are configured in the VM resulting from the clone operation, but, again, ignored during the VM boot

I can now see that what you execute via TerraForm API/workflow does not create a valid clone.
You are correct that you need to fix your TerraForm structure. There is nothing inherently wrong with the PVE clone operation.

I am not a TerraForm expert. That said, your resource looks very suspect to me.
I'd recommend removing all the extra config from the TF config and leaving it as small as possible - single clone instruction.
https://4sysops.com/archives/clone-proxmox-vms-with-terraform/ may be a good resource to consult

Good luck

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[zxy]

I gave it a try, here is the result.
it's not able to boot...

 

[sribs]

try this:

 disks {
    ide{
      ide0{
        cloudinit{
          storage="local-lvm"
        }
      }
    }

    scsi{
      scsi0{
        disk{
          storage="local-lvm"
          size="30G"
          discard=true
        }
      }
    }
  }

write your terraform configuration to match what you expect it to provision - add a cloud init disk configuration respective to the PVE gui page on vm hardware, and change the specific device interface to your needs.

 

[boobytrap]

try this:

 disks {
    ide{
      ide0{
        cloudinit{
          storage="local-lvm"
        }
      }
    }

    scsi{
      scsi0{
        disk{
          storage="local-lvm"
          size="30G"
          discard=true
        }
      }
    }
  }

write your terraform configuration to match what you expect it to provision - add a cloud init disk configuration respective to the PVE gui page on vm hardware, and change the specific device interface to your needs.

Confirmed this solved the myths, look like the glitch happen on terraform snippet. add an extra ide mount solved the problem

 

[Pepo32SVK]

i am experiencing exactly the same, cloud init login and password are not working. I can see username, password and also IP address set correctly in the Proxmox GUI, but when i try to login, i get wrong password. Even if i try to changes this values via GUI and then regenerate the image, username and password are not working at all. Any ideas ?

 

[bbgeek17]

i am experiencing exactly the same, cloud init login and password are not working. I can see username, password and also IP address set correctly in the Proxmox GUI, but when i try to login, i get wrong password. Even if i try to changes this values via GUI and then regenerate the image, username and password are not working at all. Any ideas ?

Is the template a stock cloud image, or was it previously booted and then converted to a template? Or created manually?

A few things to be aware of:

• In Proxmox VE (PVE), CloudInit data is provided via an ISO image attached as a CD.
• When changing a value, the CloudInit ISO needs to be regenerated and re-attached, and typically, these changes only take effect on a cold start of the VM.
• The users and groups module runs once per instance, meaning it won’t reapply settings automatically. See CloudInit documentation

​

Please clarify:

1. Is this a stock image where password authentication is disabled by default?
2. Are you able to log in at all? If yes, check the CloudInit logs for any errors.
3. Start with a known-good template and manually go through cloning and setting values.
   • Does it boot?
   • Can you log in successfully?
4. If everything works manually, start incorporating your management layer (Ansible, Terraform, etc.).
   • If things break at this stage, reach out to the maintainers of these tools, as they might have insights.

By isolating each step, you can pinpoint where the issue arises.

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox