[AVM Module Issue]: 409 Conflict on migrated VM import

[mikedembek]

Check for previous/existing GitHub issues

• I have checked for previous/existing GitHub issues

Issue Type?

Bug

(Optional) Module Version

0.20.0

(Optional) Correlation Id

No response

Description

I have some VMs that were migrated to Azure from on-prem VMware. I originally had issues with importing these similar to the issue described in #230, which were resolved when I pinned the commit in #234. After that, however, I got a new error:

│ Error: updating Windows Virtual Machine (Subscription: "my-sub-id"
│ Resource Group Name: "rg-example"
│ Virtual Machine Name: "vm-example03"): performing Update: unexpected status 409 (409 Conflict) with error: PropertyChangeNotAllowed: Changing property 'osProfile' is not allowed.
│ 
│   with module.example03[0].azurerm_windows_virtual_machine.this[0],
│   on .terraform/modules/example03/main.windows_vm.tf line 1, in resource "azurerm_windows_virtual_machine" "this":
│    1: resource "azurerm_windows_virtual_machine" "this" {
│ 

That was related to two items in the plan (the only changes/additions):

  # module.example03[0].azurerm_windows_virtual_machine.this[0] will be updated in-place
  # (imported from "/subscriptions/my-sub-id/resourceGroups/rg-example/providers/Microsoft.Compute/virtualMachines/vm-example03")
  ~ resource "azurerm_windows_virtual_machine" "this" {
      + allow_extension_operations                             = true
      + bypass_platform_safety_checks_on_user_schedule_enabled = false
        #etc.

This only occurs one time on apply, subsequent plan/apply operations seem fine with no drift detected.

I believe the issue is that these attributes are immutable and cannot be set post-creation.

[microsoft-github-policy-service]

Important

The "Needs: Triage 🔍" label must be removed once the triage process is complete!

Tip

For additional guidance on how to triage this issue/PR, see the Terraform Issue Triage documentation.

[microsoft-github-policy-service]

Warning

Tagging the AVM Core Team (@Azure/avm-core-team-technical-terraform) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

Tip

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage 🔍" label must be removed as part of the triage process (when the issue is first responded to)!

[EYEVO]

I added a concrete Veeam restore case on PR #241. The remaining concern is restored data disks: create_option = Import and Veeam storage_account_id still force replacement unless the module handles them too.

[microsoft-github-policy-service]

Caution

This issue requires the AVM Core Team's (@Azure/avm-core-team-technical-terraform) immediate attention as it hasn't been responded to within 6 business days.

Tip

• To avoid this rule being (re)triggered, the "Needs: Triage 🔍" and "Status: Response Overdue 🚩" labels must be removed when the issue is first responded to!
• Remove the "Needs: Immediate Attention ‼️" label once the issue has been responded to.

[microsoft-github-policy-service]

Caution

This issue requires the AVM Core Team's (@Azure/avm-core-team-technical-terraform) immediate attention as it hasn't been responded to within 6 business days.

Tip

• To avoid this rule being (re)triggered, the "Needs: Triage 🔍" and "Status: Response Overdue 🚩" labels must be removed when the issue is first responded to!
• Remove the "Needs: Immediate Attention ‼️" label once the issue has been responded to.