Docs: Example `cloud-init`

[Tinyblargon]

Please do note this is about the latest state of the master branch, not release v3.0.1-rc1

The template

Create base vm

We first create a vm with id: 9000 and name: cloudinit-template.

After the vm is created we remove as much hardware as possible, everything else we'll leave as default.

You should now have the following:

Terraform enforces the full configuration of the cloned vm. This means Terraform will remove any hardware that isn't accounted for in the Terraform config. If it doesn't do this it's a bug, please report it.

Add cloud-init image

We will now add an OS image that has cloud-init support, for this example I used the the debian-12-genericcloud-amd64.qcow2 that can be downloaded form https://cloud.debian.org/images/cloud/bookworm/latest/

To add the disk run the following command on the shell of you PVE.

wget https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-genericcloud-amd64.qcow2 --output-document /tmp/debian-12-genericcloud-amd64.qcow2
qm importdisk 9000 /tmp/debian-12-genericcloud-amd64.qcow2 local-lvm

The disk is added as a detached disk, now you can add it as ide0.

Your final setup should look like this:

CiCustom

to use cicustom a snipped must be created, mine is located at /var/lib/vz/snippets/ci-custom.yml

runcmd:
    - apt update
    - apt install -y qemu-guest-agent
    - systemctl start qemu-guest-agent
    - reboot

Terraform config

resource "proxmox_vm_qemu" "cloudinit-test" {
    name = "test1"
    target_node = "pve8"
    clone = "cloudinit-template"
    os_type = "cloud-init"
    boot = "order=ide0"
    cloudinit_cdrom_storage = "local-lvm"
    ciuser = "root"
    cipassword = "Enter123!"
    cicustom = "vendor=local:snippets/ci-custom.yml" # /var/lib/vz/snippets/ci-custom.yml
    disks {
        ide {
            ide0 {
                disk {
                    size = 8
                    storage = "local-lvm"
                }
            }
        }
    }
    network {
        bridge    = "vmbr0"
        model     = "virtio"
    }
    ipconfig0 = "ip=dhcp"
}

[electropolis]

@Tinyblargon so what E'm I looking on ? There is no need to set cloudinit as ide2 ? and what about scsi0 ? I'm bit confused. Because it's much more different from current process of creating template (steps related further with adding cloudinit drive and importing disk scsi0). In your example there is lack of many steps and I wonder how to understand it.

Im doing the import like disk (not using the importdisk subcommand , but I believe it's irrelevant

# import the downloaded disk to the local-lvm storage, attaching it as a SCSI drive
qm set 9000 --scsi0 local-lvm:0,import-from=/path/to/bionic-server-cloudimg-amd64.img

And here the disk is already imported AND attached as scsi0 in the same command So in my case, you did

   disks {
        ide {
            ide0 {
                disk {
                    size = 8
                    storage = "local-lvm"
                }
            }
        }
    }

so I should have

  disks {
    scsi {
      scsi0 {
        disk {
          size       = each.value.hdd
          storage    = var.pve_pool
          emulatessd = true
        }
      }
    }
  }

variable "pve_pool" {
  type    = string
  default = "vms"
}

and thats why the boot should be boot = "order=scsi0" instead yours boot = "order=ide0" ? But I wonder how you manage to get cloudinit on ide1 where are the rest of commands during the template creation process ? qm set 9000 --ide2 local-lvm:cloudinit

Did you omitted it or set using ide1 ? Im trying to establish the differences.

Thank you for your example but Like I said, small clarification about the process, the difference between this and the current process from source to have it understandable. source: https://pve.proxmox.com/wiki/Cloud-Init_Support

[Tinyblargon]

@electropolis

The disks and boot properties you've correctly adapted to your setup.

The cloud-init disk will be added by Terraform as ide3 I included it in the template to demonstrate that it will be removed from ide1 and added as ide3, as this previously gave an error for some people.

I don't think it is different form the official Proxmox guide, just formatted differently so it's easier to find if there is a Terraform config issue.

I'll make this guide a bit more extensive, as i did skip over some details.

[electropolis]

The cloud-init disk will be added by Terraform as ide3

I would love to have terraform add this disk finally as ide3 as I constantly can't reach the point where it does. I struggled with many different setups and no combination works. That's why I was trilled when you posted.

I don't think it is different form the official Proxmox guide

Yeah I see now it doesn't as you mention that you omitted some steps only in the post. But I look forward to have your full setup as I don't see where I do make something different. I think I make the exact setup. I also tried with ide3 when creating the template by setting cloudinit as ide3

qm set 9000 --ide3 local-lvm:cloudinit

and still it was removing the cloudinit drive when changing the scsi0 disk size and suddenly after that cdrom appeared and cloudinit disappeared.

[Tinyblargon]

@electropolis did you run it against a local build of the master branch? As v3.0.1-rc1 does not include the latest fixes that make this setup possible.

This is our guide for the local build: https://github.com/Telmate/terraform-provider-proxmox/blob/master/docs/guides/installation.md#manual-build--install

[electropolis]

@electropolis did you run it against a local build of the master branch? As v3.0.1-rc1 does not include the latest fixes that make this setup possible.

This is our guide for the local build: https://github.com/Telmate/terraform-provider-proxmox/blob/master/docs/guides/installation.md#manual-build--install

Nah, I was using tf init . I wasn't cloning the repo manually. I will try it. And give a feedback here after tests.

[electropolis]

@Tinyblargon why when installing it manually

❯ rm .terraform.lock.hcl
❯ rm .terraform
rm: .terraform: is a directory
❯ rm -rf .terraform
❯ tf init

Initializing the backend...

Initializing provider plugins...
- Finding telmate/proxmox versions matching ">= 1.0.0"...
- Finding latest version of hashicorp/null...
- Finding latest version of hashicorp/local...
- Finding latest version of hashicorp/template...
- Installing telmate/proxmox v2.9.14...
- Installed telmate/proxmox v2.9.14 (self-signed, key ID A9EBBE091B35AFCE)
- Installing hashicorp/null v3.2.2...
- Installed hashicorp/null v3.2.2 (signed by HashiCorp)
- Installing hashicorp/local v2.4.1...
- Installed hashicorp/local v2.4.1 (signed by HashiCorp)
- Installing hashicorp/template v2.2.0...
- Installed hashicorp/template v2.2.0 (unauthenticated)

Partner and community providers are signed by their developers.
If you'd like to know more about provider signing, you can read about it here:
https://www.terraform.io/docs/cli/plugins/signing.html

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

╷
│ Warning: Incomplete lock file information for providers
│
│ Due to your customized provider installation methods, Terraform was forced to calculate lock file checksums locally for the following providers:
│   - hashicorp/template
│
│ The current .terraform.lock.hcl file only includes checksums for darwin_arm64, so Terraform running on another platform will fail to install these providers.
│
│ To calculate additional checksums for another platform, run:
│   terraform providers lock -platform=linux_amd64
│ (where linux_amd64 is the platform to generate)
╵

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
❯ tf plan
╷
│ Error: Unsupported block type
│
│   on main.tf line 15, in resource "proxmox_vm_qemu" "cloudinit":
│   15:   disks {
│
│ Blocks of type "disks" are not expected here. Did you mean "disk"?
╵

it looks for disk instead of disks ? I see there is v.2.9.14 version installed that doesn't have disks in code. So how you handle the disks inside your resource?

Im doing everything according to https://github.com/Telmate/terraform-provider-proxmox/blob/master/docs/guides/installation.md#manual-build--install

And btw probably there is a mistake in docs

# Uncomment for macOS
# PLUGIN_ARCH=darwin_amd64

but when running command

make local-dev-install

that does all the jobs for us it creates darwin_arm64/ dir instead darwin_amd64/

❯ make local-dev-install
 -> Building
mkdir -p bin
CGO_ENABLED=0 go build -trimpath -o bin/terraform-provider-proxmox
Built terraform-provider-proxmox
Building this release 3.0.2 on darwin/arm64
rm -rf ~/.terraform.d/plugins/localhost/telmate/proxmox
mkdir -p ~/.terraform.d/plugins/localhost/telmate/proxmox/3.0.2/darwin_arm64/
cp bin/terraform-provider-proxmox ~/.terraform.d/plugins/localhost/telmate/proxmox/3.0.2/darwin_arm64/

So how to force terraform to run it with that local prebuild provider

❯ tf --version
Terraform v1.5.7
on darwin_arm64
+ provider registry.terraform.io/hashicorp/local v2.4.1
+ provider registry.terraform.io/hashicorp/null v3.2.2
+ provider registry.terraform.io/hashicorp/template v2.2.0
+ provider registry.terraform.io/telmate/proxmox v2.9.14

Your version of Terraform is out of date! The latest version
is 1.7.4. You can update by downloading from https://www.terraform.io/downloads.html

[Tinyblargon]

@electropolis I think that in your case the provider should be configured like this:

terraform {
  required_providers {
    proxmox = {
      source  = "localhost/telmate/proxmox"
      version >= "1.0.0"
    }
  }
}

[electropolis]

@electropolis I think that in your case the provider should be configured like this:

terraform {

  required_providers {

    proxmox = {

      source  = "localhost/telmate/proxmox"

      version >= "1.0.0"

    }

  }

}

Exactly. Did some debug after my post and yes. It should be with localhost/... , so why there is without localhost or registry... ?

[electropolis]

@Tinyblargon

Finally works! Thank you for your guidance. Btw check the documentation with that provider setup localhost/... cicustom works

local_file.cloud_init_network-config_file[0]: Creating...
local_file.cloud_init_user_data_file[0]: Creation complete after 0s [id=2cad6635c2ab8fd04c7297e089a50b9299dfd7ec]
local_file.cloud_init_network-config_file[0]: Creation complete after 0s [id=584397ad1c649775dfef64cff2484d781972e34c]
null_resource.cloud_init_network-config_files[0]: Creating...
null_resource.cloud_init_config_files[0]: Creating...
null_resource.cloud_init_network-config_files[0]: Provisioning with 'file'...
null_resource.cloud_init_config_files[0]: Provisioning with 'file'...
null_resource.cloud_init_config_files[0]: Still creating... [10s elapsed]
null_resource.cloud_init_network-config_files[0]: Still creating... [10s elapsed]
null_resource.cloud_init_config_files[0]: Still creating... [20s elapsed]
null_resource.cloud_init_network-config_files[0]: Still creating... [20s elapsed]
null_resource.cloud_init_network-config_files[0]: Still creating... [30s elapsed]
null_resource.cloud_init_config_files[0]: Still creating... [30s elapsed]
null_resource.cloud_init_config_files[0]: Still creating... [40s elapsed]
null_resource.cloud_init_network-config_files[0]: Still creating... [40s elapsed]
null_resource.cloud_init_config_files[0]: Still creating... [50s elapsed]
null_resource.cloud_init_network-config_files[0]: Still creating... [50s elapsed]
null_resource.cloud_init_config_files[0]: Creation complete after 52s [id=441540502752639479]
null_resource.cloud_init_network-config_files[0]: Creation complete after 52s [id=529443998753148410]
proxmox_vm_qemu.cloudinit["srv-app-1"]: Creating...
proxmox_vm_qemu.cloudinit["srv-app-1"]: Still creating... [10s elapsed]
proxmox_vm_qemu.cloudinit["srv-app-1"]: Still creating... [20s elapsed]
proxmox_vm_qemu.cloudinit["srv-app-1"]: Still creating... [30s elapsed]
proxmox_vm_qemu.cloudinit["srv-app-1"]: Still creating... [40s elapsed]
proxmox_vm_qemu.cloudinit["srv-app-1"]: Still creating... [50s elapsed]
proxmox_vm_qemu.cloudinit["srv-app-1"]: Still creating... [1m0s elapsed]
proxmox_vm_qemu.cloudinit["srv-app-1"]: Still creating... [1m10s elapsed]
proxmox_vm_qemu.cloudinit["srv-app-1"]: Still creating... [1m20s elapsed]
proxmox_vm_qemu.cloudinit["srv-app-1"]: Still creating... [1m30s elapsed]
proxmox_vm_qemu.cloudinit["srv-app-1"]: Creation complete after 1m34s [id=pve1-hw/qemu/100]```

with installation of qemu-agent :) and agent = 1

[Tinyblargon]

@electropolis happy to help. I've created #961 for the qemu_os diff issue.

[electropolis]

@electropolis happy to help. I've created #961 for the qemu_os diff issue.

Yeah I've just deleted that post as it's just being resolved when adding the qemu_os to resource. But would be great if that could be set as a default to null.

[hestiahacker]

Since this was mentioned in 3.0.1-rc4, I'd just like to mention that we should make sure the release notes mentioned the breaking change of removing cloudinit_cdrom_storage.

It is already documented here but since this just bit me while I was testing 3.0.1-rc3 I figured I'd mention it so make sure it hits the release notes when the official v3.0.1 is released.