4 vm creation - all get the same id and it fails. new version "3.0.1-rc4"

[zuka1337]

Tring to create 4 machines. Terraform apply try to create all 4 with the same id and it fails:

Simple example, there is also a second part of the "loop" to create other two machines.

resource "proxmox_vm_qemu" "cloudinit-k3s-master" {
    # Node name has to be the same name as within the cluster
    # this might not include the FQDN
    target_node = "home"
    desc = "Cloudinit Ubuntu"
    count = 2
    onboot = true

    # The template name to clone this vm from
    clone = "ubuntu-cloud"

    # Activate QEMU agent for this VM
    agent = 0

    os_type = "cloud-init"
    cores = 2
    sockets = 2
    numa = true
    vcpus = 0
    cpu = "host"
    memory = 2048
    name = "k3s-master-0${count.index + 1}"

    #cloudinit_cdrom_storage = "local-lvm"
    scsihw   = "virtio-scsi-pci" 
    bootdisk = "scsi0"
    boot = "order=scsi0;ide2"

    disks {
        ide {
            ide2 {
                cloudinit {
                    storage = "local-lvm"

                }
            }
        }
        scsi {
            scsi0 {
                disk {
                    size            = "22732M"
                    #cache           = "writeback"
                    storage         = "local-lvm"
                    #storage_type    = "rbd"
                    #iothread        = true
                    #discard         = true
                }
            }
        }
    }

    # Setup the ip address using cloud-init.
    # Keep in mind to use the CIDR notation for the ip.
    ipconfig0 = "ip=192.x${count.index + 1}/24,gw=192.x"
    ciuser = "var.user"
    nameserver = "192.x"
    sshkeys = var.ssh
}

[zuka1337]

Adding vmid field solve the issue, but is not practical if we use multiple terraform projects. It is nonsense to map vmid each time you create a new vm:

[hayer]

Got into the same issue, currently running with

provider "proxmox" {
    pm_parallel = 1
    # ...
}

I know this slows down the whole process since its not running anything in parallel any more, but at least it is usable until this has been fixed.

[Tinyblargon]

@zuka1337 for now the solution is what @hayer suggests. The treading at the core of the provider needs to be reworked.

Probably best for now to make pm_parrallel default to 1, and put a warning in the description that setting it higher causes issues in certain scenarios.