Import of `vsphere_virtual_disk` imports the wrong `vmdk_path`

jeremypick-sky commented 3 years ago

Terraform Version

1.0.0

vSphere Provider Version

2.0.1

Affected Resource(s)

vsphere_virtual_disk

Terraform Configuration Files

resource "vsphere_virtual_disk" "prometheus" {
  vmdk_path          = "prometheus.my.fqdn_disk1/secondary.vmdk"
  datacenter         = "${data.vsphere_datacenter.datacenter.name}"
  datastore          = "${data.vsphere_datastore.datastore.name}"
  size               = "500"
  type               = "thin"
  create_directories = true
}

Debug Output

Panic Output

Expected Behavior

We wish to import an existing disk containing data into terraform, as the original state file was lost.

terraform import vsphere_virtual_disk.prometheus /my-datacenter/[my-datastore]prometheus.my.fqdn_disk1/secondary.vmdk

This should import the disk and all would be well

Actual Behavior

The disk imports into terraform, but the vmdk.path imported does not match the path in the terraform tf file and the create_directories flag is set to null; both of these differences force a rebuild of the disk and destroy the data on it.

terraform state pull shows

  "resources": [
    {
      "mode": "managed",
      "type": "vsphere_virtual_disk",
      "name": "prometheus",
      "provider": "provider[\"registry.terraform.io/hashicorp/vsphere\"]",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "adapter_type": "lsiLogic",
            "create_directories": null,
            "datacenter": "my-datacenter",
            "datastore": "my-datastore",
            "id": "2ad9ca5f-46df-dfb7-fce5-000af7d265b0/secondary.vmdk",
            "size": 500,
            "type": "thin",
            "vmdk_path": "2ad9ca5f-46df-dfb7-fce5-000af7d265b0/secondary.vmdk"
          },
          "sensitive_attributes": [],
          "private": "**SOME STRING HIDDEN**"
        }
      ]
    }
  ]
}

Steps to Reproduce

Create a resource using terraform then destroy the state file and re-initialise terraform with an empty state

then run:

terraform import vsphere_virtual_disk.prometheus /my-datacenter/[my-datastore]prometheus.my.fqdn_disk1/secondary.vmdk

Important Factoids

References

0000

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 other comments that do not add relevant new information or questions, 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

tenthirtyam commented 2 years ago

Hi @jeremypick-sky, Could you share which storage type you are using? I'm not seeing the issue with VMFS or NFS for the id and vmdk_path however I can confirm (and I am working on) this issue with create_directories during import.

Ryan Johnson Staff II Solutions Architect | VMware, Inc.

tenthirtyam commented 2 years ago

Hi @appilon,

I've done some testing on this and I'm not (yet) seeing an issue with the id and vmdk_path attributes during an import, but I can confirm that I am seeing the issue with create_directories.

Taking a look at r/virtual_disk it's clear that resourceVSphereVirtualDiskImport is not setup to pass the create_directories attribute to the state during the import, which will result in a ForceNew on reapply.

I was having issues determing the best way to pulling in the attribute during the import operations in the below:

https://github.com/hashicorp/terraform-provider-vsphere/blob/2c4b917021345d7c49152f313463c75d4dd00628/vsphere/resource_vsphere_virtual_disk.go#L485-L521

Can you take a look at this individually or jointly when time permits?

Ryan Johnson Staff II Solutions Architect | VMware, Inc.

jeremypick-sky commented 2 years ago

We are using vSAN storage on the cluster.

tenthirtyam commented 2 years ago

Ah, that's what I expected since there was a UUID (e.g ad9ca5f-46df-dfb7-fce5-000af7d265b0) in the path.

Ryan

Simon-TheUser commented 2 years ago

I am seeing the create_directories issue after importing a disk and performing a subsequent terraform apply.

A workaround that I found is to ignore the create_directories value, like this:

resource "vsphere_virtual_disk" "disk1" {
  vmdk_path          = "Persistent_disks/secondary.vmdk"
  datacenter         = "Datacenter"
  datastore          = "datastore1"
  size               = "500"
  type               = "thin"
  create_directories = true
  lifecycle {
    ignore_changes = [create_directories]
  }
}

With the modification above, terraform apply works after re-importing the resource.

Please note that I am not using vSAN, just the default datastore1.

tenthirtyam commented 2 years ago

@SlimYang has agreed to review this issue.

Ryan Johnson Senior Staff Solutions Architect | Product Engineering @ VMware, Inc.

zxinyu08 commented 2 years ago

Hi @tenthirtyam, the issue should come from below - https://github.com/hashicorp/terraform-provider-vsphere/blob/57a2b077667c0399c96898eccb4f2b478182e0ac/vsphere/resource_vsphere_virtual_disk.go#L505-L510

I output the addrParts and di.Name to do some debug work, it displays -

2022-09-23T00:38:34.020-0700 [INFO]  provider.terraform-provider-vsphere: 2022/09/23 00:38:34 zxinyu-debug addrParts: []string{"", "DataCenter", "[vsanDatastore] namespace5/secondary.vmdk"}: timestamp=2022-09-23T00:38:34.019-0700
2022-09-23T00:38:34.020-0700 [INFO]  provider.terraform-provider-vsphere: 2022/09/23 00:38:34 zxinyu-debug di.Name: "[vsanDatastore] 5e622d63-4034-3c5e-5e57-020104167900/secondary.vmdk": timestamp=2022-09-23T00:38:34.019-0700

I'm thinking if uses addrParts[2] directly could resolve this force replacement issue, since the uuid would be replaced by the readable name in tfstate file after running terraform import cmd. Local test of this fix is in-progress.

For the create_directories issue, I found a similar implementation in https://registry.terraform.io/providers/hashicorp/vsphere/latest/docs/resources/drs_vm_override#importing, maybe we could pass create_directories key/value pair in the json data of the terraform import cmd. I'm still working on this, will update once there's any progress.

tenthirtyam commented 2 years ago

Thank you for investigating this issue, Xinyu - it's very appreciated. 😀

Ryan Johnson Senior Staff Solutions Architect | Product Engineering @ VMware, Inc.

knoppiks commented 1 year ago

May I ask what the status here is? We switched to vSAN and vsphere8 very recently and had trouble importing moved disks into terraform. Our workaround was to pull, alter and push the terraform state file - which is obviously not recommended.

github-actions[bot] commented 6 months ago

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.

hashicorp / terraform-provider-vsphere