importing vm with clone / efi disk forces replacement

[aquirdTurtle]

Describe the bug
The provider seems to not realize that an imported vm was originally cloned. It thinks it must add the cloned part of the state which forces replacement.

To Reproduce
Steps to reproduce the behavior:

1. Create a cloned vm resource proxmox_virtual_environment_vm.test_vm
2. Remove the vm from state tofu state rm proxmox_virtual_environment_vm.test_vm
3. Re-import the vm tofu import proxmox_virtual_environment.test_vm <mynode>/<vmid>
4. Check state tofu plan, notice that it wants to replace the vm.

Please also provide a minimal Terraform configuration that reproduces the issue.

resource "proxmox_virtual_environment_vm" "test_vm" {
  name = "test-vm"
  node_name = "my-node-name"
  agent {
    enabled = false
  }
  clone {
    vm_id = 1005
    full = false
  }
}

and the output of terraform|tofu apply.

> tofu plan
proxmox_virtual_environment_vm.test_vm: Refreshing state... [id=192]

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_vm.test_vm must be replaced
-/+ resource "proxmox_virtual_environment_vm" "test_vm" {
      ~ bios                    = "ovmf" -> "seabios"
      ~ id                      = "192" -> (known after apply)
      ~ ipv4_addresses          = [] -> (known after apply)
      ~ ipv6_addresses          = [] -> (known after apply)
      + keyboard_layout         = "en-us"
      ~ mac_addresses           = [
          - "BC:24:11:FA:A8:1E",
        ] -> (known after apply)
      - machine                 = "q35" -> null
      + migrate                 = false
        name                    = "test-vm"
      ~ network_interface_names = [] -> (known after apply)
      + on_boot                 = true
      + reboot                  = false
      + reboot_after_update     = true
      + stop_on_destroy         = false
      - tags                    = [
          - "24_04",
          - "cloudinit",
          - "ubuntu-template",
        ] -> null
      + timeout_clone           = 1800
      + timeout_create          = 1800
      + timeout_migrate         = 1800
      + timeout_move_disk       = 1800
      + timeout_reboot          = 1800
      + timeout_shutdown_vm     = 1800
      + timeout_start_vm        = 1800
      + timeout_stop_vm         = 300
      ~ vm_id                   = 192 -> (known after apply)
        # (7 unchanged attributes hidden)

      + agent {
          + enabled = false
          + timeout = "15m"
          + trim    = false
          + type    = "virtio"
        }

      + clone {
          + full    = false # forces replacement
          + retries = 1 # forces replacement
          + vm_id   = 1005 # forces replacement
        }

      - cpu {
          - cores      = 2 -> null
          - flags      = [] -> null
          - hotplugged = 0 -> null
          - limit      = 0 -> null
          - numa       = false -> null
          - sockets    = 1 -> null
          - type       = "host" -> null
          - units      = 1024 -> null
        }

      - disk {
          - aio               = "io_uring" -> null
          - backup            = true -> null
          - cache             = "none" -> null
          - datastore_id      = "vms_ssd" -> null
          - discard           = "on" -> null
          - file_format       = "raw" -> null
          - interface         = "virtio0" -> null
          - iothread          = false -> null
          - path_in_datastore = "vm-192-disk-1" -> null
          - replicate         = true -> null
          - size              = 64 -> null
          - ssd               = false -> null
        }

      - efi_disk { # forces replacement
          - datastore_id      = "vms_ssd" -> null
          - file_format       = "raw" -> null
          - pre_enrolled_keys = false -> null
          - type              = "2m" -> null
        }

      - initialization {
          - datastore_id = "vms_ssd" -> null
          - interface    = "scsi1" -> null

          - ip_config {
              - ipv4 {
                  - address = "dhcp" -> null
                }
            }

          - user_account {
              - keys     = [] -> null
              - password = (sensitive value) -> null
              - username = "atom" -> null
            }
        }

      - memory {
          - dedicated      = 2048 -> null
          - floating       = 0 -> null
          - keep_hugepages = false -> null
          - shared         = 0 -> null
        }

      ~ network_device {
          + acpi                    = (known after apply)
          + bios                    = (known after apply)
          + boot_order              = (known after apply)
          + description             = (known after apply)
          + hook_script_file_id     = (known after apply)
          + id                      = (known after apply)
          + ipv4_addresses          = (known after apply)
          + ipv6_addresses          = (known after apply)
          + keyboard_layout         = (known after apply)
          + kvm_arguments           = (known after apply)
          + mac_addresses           = (known after apply)
          + machine                 = (known after apply)
          + migrate                 = (known after apply)
          + name                    = (known after apply)
          + network_interface_names = (known after apply)
          + node_name               = (known after apply)
          + on_boot                 = (known after apply)
          + pool_id                 = (known after apply)
          + protection              = (known after apply)
          + reboot                  = (known after apply)
          + reboot_after_update     = (known after apply)
          + scsi_hardware           = (known after apply)
          + started                 = (known after apply)
          + stop_on_destroy         = (known after apply)
          + tablet_device           = (known after apply)
          + tags                    = (known after apply)
          + template                = (known after apply)
          + timeout_clone           = (known after apply)
          + timeout_create          = (known after apply)
          + timeout_migrate         = (known after apply)
          + timeout_move_disk       = (known after apply)
          + timeout_reboot          = (known after apply)
          + timeout_shutdown_vm     = (known after apply)
          + timeout_start_vm        = (known after apply)
          + timeout_stop_vm         = (known after apply)
          + vm_id                   = (known after apply)
        } -> (known after apply)

      - operating_system {
          - type = "l26" -> null
        }

      ~ vga {
          + acpi                    = (known after apply)
          + bios                    = (known after apply)
          + boot_order              = (known after apply)
          + description             = (known after apply)
          + hook_script_file_id     = (known after apply)
          + id                      = (known after apply)
          + ipv4_addresses          = (known after apply)
          + ipv6_addresses          = (known after apply)
          + keyboard_layout         = (known after apply)
          + kvm_arguments           = (known after apply)
          + mac_addresses           = (known after apply)
          + machine                 = (known after apply)
          + migrate                 = (known after apply)
          + name                    = (known after apply)
          + network_interface_names = (known after apply)
          + node_name               = (known after apply)
          + on_boot                 = (known after apply)
          + pool_id                 = (known after apply)
          + protection              = (known after apply)
          + reboot                  = (known after apply)
          + reboot_after_update     = (known after apply)
          + scsi_hardware           = (known after apply)
          + started                 = (known after apply)
          + stop_on_destroy         = (known after apply)
          + tablet_device           = (known after apply)
          + tags                    = (known after apply)
          + template                = (known after apply)
          + timeout_clone           = (known after apply)
          + timeout_create          = (known after apply)
          + timeout_migrate         = (known after apply)
          + timeout_move_disk       = (known after apply)
          + timeout_reboot          = (known after apply)
          + timeout_shutdown_vm     = (known after apply)
          + timeout_start_vm        = (known after apply)
          + timeout_stop_vm         = (known after apply)
          + vm_id                   = (known after apply)
        } -> (known after apply)
    }

Plan: 1 to add, 0 to change, 1 to destroy.

─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so OpenTofu can't guarantee to take exactly these actions if you run "tofu apply" now.

Expected behavior
I would expect removing the vm from state and re-importing it to work without needing replacement.

I note that tofu also seems to want to remove a lot of state which was present from my template image that it cloned from, despite me not declaring anything about it in my resource config. This also seems not ideal but not a big deal as I can make my resource config reflect the template for these types of things. The issue with the clone however seems impossible to fix, so my options seem to be to recreate resources (which I can't for my actual use case) or to remove the clone section from my resource definition for the resources which I import.

Additional context
Add any other context about the problem here.

• Single or clustered Proxmox: clustered
• Proxmox version: 8.3
• Provider version (ideally it should be the latest version): 0.78.1
• Terraform/OpenTofu version: v1.9.0
• OS (where you run Terraform/OpenTofu from): ubuntu server 24.04

[elias314]

I don't think this is a bug. I can't speak to the cloning specifically since I don't do any cloning, but everything else looks correct. You're importing a resource that has elements to it like disk and efi_disk but since they're not present in your resource definition, you're actively telling Terraform to remove them. And then you're getting odd changes like this too:
~ bios = "ovmf" -> "seabios".

I note that tofu also seems to want to remove a lot of state which was present from my template image that it cloned from, despite me not declaring anything about it in my resource config. This also seems not ideal but not a big deal as I can make my resource config reflect the template for these types of things.

This behavior seems correct to me. You'll want to update your resource definition to match what your deployed VM actually looks like. And at the same time, just remove the clone block.

Just out of curiosity, what's your use-case for re-importing Terraform deployed VMs like this?

[aquirdTurtle]

I definitely think the cloning is the bigger problem to me, as I said, it's easier to work around the other stuff.

The rest does still feel buggy to me though. My problem is that terraform was perfectly happy with my vm's state before I removed it from state and re-imported it from state. I feel these should be inverse operations, ideally. Terraform didn't care about my efi disk when I did the initial clone, it only noticed it after removing and importing it. I'm not experienced enough with terraform to know if this type of non-invertible behavior is common with other providers.

My use case is that we have a lot of existing VMs that we created mostly from scratch which we can't easily tear down and rebuild under terraform because they have a lot of internal state. New VMs are being managed via terraform, and I would like to manage the older VMs with terraform as well. Importing seems like the natural solution, except these problems.

[JumboBear]

I have the same issue and I can confirm it happens exactly that.

Just out of curiosity, what's your use-case for re-importing Terraform deployed VMs like this?

Image this use case.

1. I wrote my configuration with a single cloned VM. It spun up correctly.
2. Then I completely delete all the states for any reason (mistake, for instance).
3. Then I want to add a new VM along the one that was already cloned.
4. To do so I need to import the existing VM into the state first. I do it and the VM is imported correctly.
5. When I go to plan the entire new configuration with two VMs the plugin thinks I need to delete my first VM and reclone it. Which I don't want to, maybe I already started to work on it.

[TobiPeterG]

I guess the easy fix is to make the cloneparameter ignored in the lifecycle. This fixes it for me. Only the attributes that have changed from the imported VM need to match.