Discussion on the disk update using ImportFrom.

[Vaneixus]

@bpg Hello! Sorry for not following up earlier for the issue, I got quite busy. I see that you have reverted it, that's good, rather not keep something not working properly that long in the latest release. However, I am still interested by this feature and would like to know if you are as well. In my mind, I was thinking that the only reason that a disk is to be re-imported is if the source has changed, the size shouldn't have had triggered it in the first place. instead of opening a new PR, I would like to discuss the feature properly, and see what do you think and if you're (still) interested in having it.

I will speak a bit more about why I feel it would be useful. currently, I am creating these ephemeral boot disks with data disks, because they're ephemeral, nothing that changes in there will be kept, including updates to the system to keep the software inside up to date and spec. So, to update the boot disk, I change the source, pointing towards a new boot disk source that has the updated configuration.

in the reverted PR, the code was intended to only update the disk if the backing source was changed. now this can be a breaking change, so along side fixing the original functionality, we should most likely introduce a new parameter disk_update_on_source_change or something along those lines to control the new functionality, this parameter should be false by default, which, would maintain the original v87 functionality and avoid the regression scenario we saw earlier in the week. Of course, if we're re-introducing this, I intend to extend the work with new tests to ensure that the new code does not break something like this again.

[bpg-dev]

Hey @Vaneixus, thanks for opening this discussion and for your patience, sorry for the late reply.

I've spent some time thinking about this, and I want to share where I've landed and the reasoning behind it.

The short version

I'm going to keep import_from as create-only and not pursue in-place disk re-import for now. Here's why, and what I'd suggest instead.

The longer version

I looked at how every major Terraform provider handles this (AWS, Azure, GCP, vSphere) and none of them support swapping a boot disk image in-place. They all treat the disk image source as an immutable property that triggers VM recreation when changed. The reasoning is consistent: replacing a boot image is semantically equivalent to creating a new machine, and in-place swaps carry significant data integrity risks.

On the technical side, there are a few things working against us:

1. Proxmox treats import-from as a create-time parameter - the API consumes it and discards it. There's no "replace disk content" endpoint. Re-import means: stop VM, detach old disk, create new disk with import-from, resize, start VM. That's a lot of surface area for things to go wrong, as we saw with v0.88.0.

2. Drift detection is impossible - the Proxmox API doesn't return import-from when reading VM config. The provider copies it from Terraform state. So we can never actually verify whether the current disk came from the declared source.

3. The interaction with other disk changes is tricky - if disk attributes like cache or aio change at the same time as a re-import, there's a reboot timing issue where pending changes can overwrite the new disk size (the exact problem we fixed in fix(vm): reboot before disk resize to prevent pending changes from reverting size #2563).

Your use case with ephemeral boot disks makes sense, especially in an on-prem context. But I think the right approach is to use Terraform's built-in mechanisms for this:

A workaround

Use replace_triggered_by to automatically recreate the VM when the image source changes:

resource "proxmox_virtual_environment_download_file" "boot_image" {
  content_type = "import"
  datastore_id = "local"
  node_name    = "pve"
  url          = var.boot_image_url  # Change this to trigger replacement
}

resource "proxmox_virtual_environment_vm" "server" {
  # ... vm config ...

  disk {
    datastore_id = "local-lvm"
    import_from  = proxmox_virtual_environment_download_file.boot_image.id
    interface    = "scsi0"
    size         = 20
  }

  # Your persistent data disk - NOT recreated
  # (managed as a separate resource or with ignore_changes)

  lifecycle {
    replace_triggered_by = [
      proxmox_virtual_environment_download_file.boot_image.id
    ]
  }
}

This gives you automatic VM recreation when the boot image changes, while keeping data disks intact if they're managed separately.

Future plans

There's a related feature request #1465 with strong community interest that would let you manage disk lifecycle independently from VMs. That would be a cleaner long-term solution for your use case: create the boot disk as a standalone resource and attach/detach it without touching the VM.

[Vaneixus]

Hey @bpg!

thanks for the follow-up and the breakdown of the issues and the potential solution you had in mind. Your reasons for keeping it a create-only parameter is a good point against restoring the updating of disks using the old, reverted method. It is as you had said, the proxmox API endpoint for vm creation/updating does not allow us to identify whether the actual disk has changed or not, only its attributes. we only relied on the terraform state itself to identify if the source had changed, which, while it would have worked in my use case, it is also a hack since the managed resource cannot actually detect any changes beyond that to the source.

Having said that, I was not aware of the feature request you have mentioned. Having looked at it, it is indeed a very good solution for handling my use case while also improving data integrity by seperating the disks out of the VM lifecycle. The workaround you had mentionned, I am aware of, and even the solution you have had mentioned in the documentation, the one about data VMs. But I felt that last one was a bit of a hack and the potential for data loss is there with misconfigurations to the user vm lifecycle ignores.

I will try and take a look at the api endpoint mentionned in #1465 and test its limits before looking if I can work on such feature request.

Thanks for the follow-up!