r/(linux|windows)_virtual_machine - support for `managed_disk_id` from an existing OS disk

[jpbuecken]

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

Description

We want to build an instance from a pre-defined managed disk. You forgot to adopt this feature from azurerm_virtual_machine in the new azurerm_*_virtual_machine.

In the legacy resource you could do the following:

  storage_os_disk {
    name              = "myosdisk1"
    caching           = "ReadWrite"
    create_option     = "Attach"
    managed_disk_id = "..."
    managed_disk_type = "Standard_LRS"
  }

New or Affected Resource(s)

• azurerm_linux_virtual_machine
• azurerm_windows_virtual_machine

Potential Terraform Configuration

  os_disk {
    caching           = "ReadWrite"
    managed_disk_id = "..."
    storage_account_type = "Standard_LRS"
  }

References

Use case is to manage metadata of the OS disk. The details are described here:

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

EDIT:
After comment from @tombuildsstuff I removed create_option = "Attach" from the "Potential Terraform Configuration" hcl, since "it should be managed by Terraform due to the quirks behind it"

[tombuildsstuff]

hey @jpbuecken

Thanks for opening this issue.

When building the new VM Resources we intentionally omitted these fields since whilst Azure still supports this pattern - it's generally recommended to use a new OS Disk where possible (for example sourced from an image, which could be an existing image of an OS Disk).

Whilst we may look to re-add the managed_disk_id field to these resources to support attaching existing OS Disks - in practice we probably wouldn't expose the create_option field since it should be managed by Terraform due to the quirks behind it (for example, if provisioning a new Virtual Machine with a new OS Disk, you have to specify "Empty", - but to update that you need to continue to specify "Empty" [where you'd expect to send 'Attach'] - whereas for attaching an existing OS disk this is always "Attach") - since this value needs to be determined at runtime (and so lead to a bunch of issues on the legacy resources).

As such for the moment I'm going to update this issue to focus on supporting attaching existing OS disks to the new virtual machine resources - since we don't plan to expose the create_option field on these new resources.

Thanks!

[jpbuecken]

wouldn't expose the create_option field since it should be managed by Terraform due to the quirks behind it

Agree and I'm totally fine with that.

[grtyso]

We create our Azure VM's with azurerm_windows_virtual_machine and a generalized image from shared image gallery, which works great. We do use Azure recovery services vault for backup of these VMs. This is a disk level backup. If we need to restore the OS disk, this recovery creates a new disk that we then attach to the VM, putting the config out of sync.

If we try to import the resulting VM config, we get the same error:

Error: The "azurerm_windows_virtual_machine" resource doesn't support attaching OS Disks - please use the azurerm_virtual_machine resource instead

There doesn't seem to be a way to use azurerm_windows_virtual_machine with Azure Recovery Services Vault and OS disk restores, which seems to be a major problem.

[jpbuecken]

I want to mention another use case:

The official Azure Migrate service does create a VM from disk. Thus we cannot import VMs created by Azure Migrate to terraform, unless we use the deprecated resource azurerm_virtual_machine.

How is the actual state of this issue? The provider should support import of VMs created by Azure Migrate. I assume this is a use case that will hopefully help to prioritize this issue.

Any known workarounds to my specific case?
Maybe any known settings to Azure Migrate service such that it uses another method to create the VM, to workaround this provider limitation?

[BrewToR]

Hello, any updates about this important feature ?
thanks !

[forgondolin]

Hello, any updates on this case?
thanks