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?

[horvatal]

The attach option for the OS disk (ZRS stroage) is the only solution, to migrate all VMs from one AZ to another (in an AZ failure case).

[siemin81]

The attach option for the OS disk (ZRS storage) is the only solution, to migrate all VMs from one AZ to another (in an AZ failure case).

I agree or at least it is the cleanest one. Also for importing existing VMs created with OS disk attached into terraform this is the only (clean) way. For most of appliances prepared as images from vendors this is literally the only way.

[hofmannma]

We have similar issue when we do ASR and want to get the machine created by ASR under terraform management.
Our current workaround:

• Run terraform apply to create a temporary dummy VM so we have a state.
• Destroy the temporary dummy VM, disks, NIC outside of terraform
• Execute ASR
• Terraform now thinks this ASR VM is the previous one created.
  But a lot of it need to come true such as resource names need to match. And a bunch of lifecycle ignores such as on data disks in regards to create_option, hyper_v_generation, source_resource_id etc.

The os disk id output would also nice for the original VM because the os disk ID is required to setup ASR through terraform. Right now we have to use an external script resource to get the os disk ID for ASR with terraform.

[ebobant]

@tombuildsstuff Thank you for your reply! Do you know when this functionality will be added to the Thank you for your reply! Do you know when this functionality will be added to the azurerm_linux_virtual_machine and azurerm_windows_virtual_machine resources? if not soon then we will use azurerm_virtual_machine resource.

[hofmannma]

Using azurerm_virtual_machine cannot be the answer because it has no feature parity. E.g. azurerm_virtual_machine does not support license_type the same way as azurerm_linux_virtual_machine, capacity reservations are not supported etc.

[horvatal]

@jackofallops what were the technical limitations in your implementation: #10466 (comment)

[avh01]

Would a possible workaround be to convert the virtual os_disk to a Specialized image using the azurerm_image resource and then deploy the VM from the image?