Terraform-provider-azurerm: storage_data_disk resize failure

[juanjojulian]

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
• storage_data_disk

Terraform Configuration Files

  storage_data_disk {
    name              = "${var.sub-name}-${var.region}-${var.hostname}-DataDisk"
    caching           = "None"
    create_option     = "Empty"
    lun               = 0
    disk_size_gb      = "${var.data_disk_size_gb}"
    managed_disk_type = "${var.data_sa_type}"
  }

Debug Output

Panic Output

Expected Behavior

Resize the VM data disk from 3GB to 4GB

storage_data_disk.0.disk_size_gb: "3" => "4"

Actual Behavior

Deployed VM with data_disk_size_gb = "3" and worked with no issues. Changed the variable data_disk_size_gb = "4" and plan with no troubles but apply failed with error:

* azurerm_virtual_machine.linux_datadisk: compute.VirtualMachinesClient#CreateOrUpdate: Failure sending request: StatusCode=0 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="ResizeDiskError" Message="Managed disk resize via Virtual Machine 'virtual_machine_name' is not allowed. Please resize disk resource at /subscriptions/88f51c7b-d1cb-48e6-8f5c-6753f6bd4b56/resourceGroups/resoucegroup-rg/providers/Microsoft.Compute/disks/virtual_machine_name-DataDisk." Target="disk.diskSizeGB"

The data_disk_size_gb change is not applied to the VM in Azure but the Terraform state file is changed with the new value:

"storage_data_disk.0.disk_size_gb": "4",

Steps to Reproduce

1. terraform apply

Important Factoids

References

• #0000

[juanjojulian]

I solved my problem by using “azurerm_managed_disk” and “azurerm_virtual_machine_data_disk_attachment” instead of the "storage_data_disk" block inside the "azurerm_virtual_machine" resource.

Resizing works with this method (VM should be shutdown but its Azure the one to blame for this).
Removing the data disk doesn't cause Terraform to destroy the VM.

After the experience I don't recommend using "storage_data_disk" block.

[juanjojulian]

I found exactly the same problem when trying to resize storage_os_disk, changing the "disk_size_gb" with the VM deallocated fails although the plan output is correct:

• Terraform code:

  storage_os_disk {
    name              = "${var.sub-name}-${var.region}-${var.hostname}-OsDisk"
    caching           = "ReadWrite"
    create_option     = "FromImage"
    disk_size_gb      = "${var.os_disk_size_gb}"
    managed_disk_type = "Premium_LRS"
  }

• Plan output:

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

Terraform will perform the following actions:

  ~ module.VM01.azurerm_virtual_machine.main
      storage_os_disk.0.disk_size_gb: "32" => "42"

• Error output after applying:

* azurerm_virtual_machine.main: compute.VirtualMachinesClient#CreateOrUpdate: Failure sending request: StatusCode=0 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="ResizeDiskError" Message="Managed disk resize via Virtual Machine 'VM01' is not allowed. Please resize disk resource at /subscriptions/XXXXX/resourceGroups/XXXXX-RG/providers/Microsoft.Compute/disks/VM01-OsDisk." Target="disk.diskSizeGB"

I cannot bypass this problem as I did with storage_data_disk because there is no "
"azurerm virtual_machine_os_disk attachment" resource available.

What is the correct way to resize a storage_os_disk in Terraform?

[johnathon-b]

I'm experiencing the same issues as you were. Was there any resolution?

[waxb]

I've only made it working via manual VM deallocation. Could it be a feature that the provider deallocates the VM before trying to modify the disk size?

[jackofallops]

Closing this issue as it can be addressed using the fixes in https://github.com/terraform-providers/terraform-provider-azurerm/pull/5579.

We're currently working on version 2.0 of the Azure Provider which we previously announced in https://github.com/terraform-providers/terraform-provider-azurerm/issues/2807.
As a part of this we're introducing five new resources which will supersede the existing azurerm_virtual_machine and azurerm_virtual_machine_scale_set resources:

azurerm_linux_virtual_machine
azurerm_linux_virtual_machine_scale_set
azurerm_virtual_machine_scale_set_extension
azurerm_windows_virtual_machine
azurerm_windows_virtual_machine_scale_set

We recently opened https://github.com/terraform-providers/terraform-provider-azurerm/pull/5550 which adds support for the new Virtual Machine resources - which require attaching Data Disks using the azurerm_managed_disk and azurerm_virtual_machine_data_disk_attachment resources rather than having them defined inline, which allows for more granular control/flexibility when modifying disks. Since the existing Virtual Machine resource is being superseded, unfortunately we have no plans to backport this to the existing azurerm_virtual_machine resource - however we’ll be publishing information on the new resources (and how you can opt-into the Beta) in the near-future.

[hashibot[bot]]

This has been released in version 2.0.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example:

provider "azurerm" {
    version = "~> 2.0.0"
}
# ... other configuration ...

[hashibot[bot]]

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 👉 [email protected]. Thanks!