Resource azurerm_virtual_machine -> storage_os_disk creates disk resource that can't be modified (tags)

[mystcb]

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 (and AzureRM Provider) Version

Terraform v0.11.11
+ provider.azurerm v1.20.0

Affected Resource(s)

• azurerm_virtual_machine

Terraform Configuration Files

resource "azurerm_virtual_machine" "azurevm" {

  ...<snip>...

  storage_os_disk {
    name              = "${var.disk_name}"
    caching           = "ReadWrite"
    create_option     = "FromImage"
    managed_disk_type = "Standard_LRS"
  }

  tags = {
    environment  = "${var.environment}"
    costcentre = "${var.costcentre}"
  }

 ...<snip>...

}

Expected Behavior

When updating the tags on an azurerm_virtual_machine resource, it should update the tags on the managed disk created by the storage_os_disk block.

Actual Behavior

The managed disk created by Terraform during the creation of the azurerm_virtual_machine resource doesn't get updated with changes to the tags.

Steps to Reproduce

1. Create a template to generate an azurerm_virtual_machine resource.
2. Select any Operating System
3. Ensure that you use the storage_os_disk block to generate the OS BOOT drive.
4. Ensure that you set a number of tags at the azurerm_virtual_machine resource level
5. terraform apply to depoy the VM and Boot Disk - wait for creation
6. Update the azurerm_virtual_machine resource tags to modify one of the existing values.
7. terraform plan shows tags being updated at the azurerm_virtual_machine resource level. But not the managed disk

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

  ~ azurerm_virtual_machine.azurevm
      tags.costcentre: "H79" => "H78"


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

8. terraform apply updates the azurerm_virtual_machine resource, but doesn't touch the managed disk.

• #0000

[swheettaos]

This is also an issue for me. Any recommendations?

[jpbuecken]

The bug has been labled with "question". I'm not sure what the question is, imho the bug has been described very well and just avoided that we open a new one...
What is the open question?

[mystcb]

I am not sure why it was ever tagged as a question. It was more of explaining the unexpected behaviour with the tagging on disks created by the azurerm_virtual_machine. I thought that there was a question internally that needed answering.

Hopefully, that clarifies what I originally put down! (Although feel free to ping me any questions on this!)

[jpbuecken]

@mystcb

What is the open question?

It was a question to the developer, I'm not an developer myself.
I'm affected by the bug myself.

[jpbuecken]

I took a look myself: The initial tag is done by the azure api. The azure process to create an instance writes the tags to the boot vhd. So this has not been done by terraform intentionally.
Since the azure api does not allow to modify the boot VHD tags via instance object, the terraform instance resource cannot refresh the tags (unless you mix instance and VHD objects inside terraform provider)

A clean workaround would be to have the boot VHD in terraform as independent managed ressource.
Our idea

• Get image data via azurerm_platform_image datasource
• Create VHD from Image via terraform
• Use this VHD to create you instance

With this workflow the boot VHD is managed by terraform and you can change the tags.
But for our workflow, we have a blocker: #4402

We do not want to rely on latest images. We define a version, and if we bump the version, we test the new image beforehand.
Since the azurerm_platform_image does not allow to specify a specific version yet, we can decide if we want to use latest image or do not tag the boot VHD with terraform.
Since some vendor do changes during lifecycle, we choose stability. (e.g. SLES images got a EFI partition by an image update recently, even for gen1; CentOS by rougewave/OpenLogic enabled Networkmanager between 7.5 and 7.6)

[etaham]

I took a look myself: The initial tag is done by the azure api. The azure process to create an instance writes the tags to the boot vhd. So this has not been done by terraform intentionally.
Since the azure api does not allow to modify the boot VHD tags via instance object, the terraform instance resource cannot refresh the tags (unless you mix instance and VHD objects inside terraform provider)

A clean workaround would be to have the boot VHD in terraform as independent managed ressource.
Our idea

• Get image data via azurerm_platform_image datasource
• Create VHD from Image via terraform
• Use this VHD to create you instance

With this workflow the boot VHD is managed by terraform and you can change the tags.
But for our workflow, we have a blocker: #4402

This isn't possible on azurerm_linux_virtual_machine. There is no option to attach to an OS disk.

#6117

[jpbuecken]

This isn't possible on azurerm_linux_virtual_machine. There is no option to attach to an OS disk.

#6117

#6117 is more about attaching data disks to the vm pre-boot via a data_disk block.
I'm missing create_option + managed_disk_id from azurerm_virtual_machine in azurerm_linux_virtual_machine and azurerm_windows_virtual_machine in the os_disk block
https://www.terraform.io/docs/providers/azurerm/r/virtual_machine.html#managed_disk_id

[tombuildsstuff]

hi @mystcb

Taking a look through here the azurerm_virtual_machine resource has since been superseded by the azurerm_linux_virtual_machine and azurerm_windows_virtual_machine resources. Whilst the existing azurerm_virtual_machine resource continues to be available in 2.x releases of the Provider, it's feature-frozen and thus no longer receiving any bugfixes or enhancements to maintain compatibility.

As such I'm going to close this issue for the moment - but I'd recommend looking into the azurerm_linux_virtual_machine and azurerm_windows_virtual_machine resources going forward - however issue #8162 is tracking support for this functionality in the new resources - would you mind subscribing to that issue for updates?

Thanks!

[ghost]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks!