resource azurerm_windows_virtual_machine has source_image dependiencies wrong

[siemin81]

Is there an existing issue for this?

• I have searched the existing issues

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

1.2.7

AzureRM Provider Version

3.34.0

Affected Resource(s)/Data Source(s)

azurerm_windows_virtual_machine

Terraform Configuration Files

(...)
"source_image_reference" {
      publisher = null
      offer     = null
      sku       = null
      version   = null
    }
}
#source_image_id = "/subscriptions/sub/resourceGroups/rg/providers/Microsoft.Compute/galleries/images/images/image"
(...)

Debug Output/Panic Output

│ Error: Invalid combination of arguments
(...)
│ "source_image_reference": one of `source_image_id,source_image_reference` must be specified
╵
╷
│ Error: Invalid combination of arguments
(...)
│ "source_image_id": one of `source_image_id,source_image_reference` must be specified

Expected Behaviour

There is a possible configuration on Azure (when VM needs to be created from existing disk by attaching it during creation process), that VM doesn't have a source_image parameters set at all.
In that case source_image_reference is null and source_image_id = "" on Azure side and you have to be able to reflect that in terraform, otherwise terraform wants to re-create the whole VM.

Currently the only workaround we've found is to use some not existing, only visually proper source_image_id like the one in example configuration section ("" is not working because of parsing errors) and then add:
lifecycle {
ignore_changes = [
source_image_id
]
}
So that terraform just ignore this section and is not trying to recreate.

Actual Behaviour

Terraform errors out during parsing and doesn't want to proceed with empty source_image variables - which is incorrect given that it is allowed on Azure.
IMPORTANT: It was working correctly up to version 3.30.0, but I couldn't see any remarks about any changes within the resource in release notes after that

Steps to Reproduce

Sorry, since this is a very specific scenario, it is impossible to provide exact steps, unless we include tons of powershell/az commands to prepare the environment first.
The easiest way to reproduce is to create a vm attaching the existing disks, then import in terraform, so that following command displays the same as below:

tf state show MODULE.azurerm_windows_virtual_machine.main | grep image

source_image_id               = ""

and then create a base code for the VM and try to perform terraform plan WITHOUT any source_image_xxxxxx variables present in the code.
With <= 3.30 it will work, with 3.31 it will fail on dependencies.

Important Factoids

No response

References

No response

[myc2h6o]

Hi @siemin81 thanks for opening the issue. azurerm_windows_virtual_machine and azurerm_linux_virtual_machine don't support attaching an existing os disk yet, this has been tracked by #8195. As for the error message, it has been done in #19230 which moves the logic of validating one of source_image_id and source_image_reference is specified from Create() to schema. This is currently a restriction and has been documented at https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/windows_virtual_machine#source_image_reference, but we may be looking for adding the support. Would you mind subscribing to #8195 for update?

[siemin81]

Hi @myc2h6o, thanks for the answer. I appreciate that. I have subscribed to the issue you've suggested. As for the documentation, yes I am aware, but it was working before. Now I know why it stopped (#19230).
I guess that we need to live with workaround until the support is added.
Thank you

[rcskosir]

Thank you @siemin81 for opening this issue, and thank you @myc2h6o for helping find the issue to subscribe to for tracking progress. I am going to close this issue as a duplicate so we can consolidate on issue #8195.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.