Closed jeremypick-sky closed 8 months 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.
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:
Can you take a look at this individually or jointly when time permits?
Ryan Johnson Staff II Solutions Architect | VMware, Inc.
We are using vSAN storage on the cluster.
Ah, that's what I expected since there was a UUID (e.g ad9ca5f-46df-dfb7-fce5-000af7d265b0
) in the path.
Ryan
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.
@SlimYang has agreed to review this issue.
Ryan Johnson Senior Staff Solutions Architect | Product Engineering @ VMware, Inc.
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.
Thank you for investigating this issue, Xinyu - it's very appreciated. 😀
Ryan Johnson Senior Staff Solutions Architect | Product Engineering @ VMware, Inc.
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.
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.
Terraform Version
1.0.0
vSphere Provider Version
2.0.1
Affected Resource(s)
vsphere_virtual_disk
Terraform Configuration Files
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
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