search

hashicorp / terraform-provider-vsphere

Terraform Provider for VMware vSphere
https://registry.terraform.io/providers/hashicorp/vsphere/
Mozilla Public License 2.0
616 stars 451 forks source link

TF reports error on VM creation when trying to switch back disk to Thick Provision Eager Zeroed (intermittent) #2116

Closed leblancs321 closed 5 months ago

leblancs321 commented 9 months ago

Community Guidelines

Terraform

1.6.3

Terraform Provider

2.5.1

VMware vSphere

7.0.3.01700

Description

When creating several VMs from a Terraform recipe. I can get a Terraform error on disk property change. This problem is related to issue 1028 that was clamed fixed but it did not fixed our issue.

Template used starts with a disk that is 'Thick Provision Eager Zeroed' Expected end-result on VM is that the disk setup do not change (keep) 'Thick Provision Eager Zeroed'

The problem is intermittent. And it SEEMS to occure more on Clusters that are being actively used (normally, we do not get this problem on newly deployed Clusters.

Our current work-around is to delete the VM that reported the error and run the deployment recipe again.

For more complete information, complete VCenter and Terraform logs set was given to 'Yanie Nicole'.

Affected Resources or Data Sources

module.recipe.module.sesrv.vsphere_virtual_machine.vm

Terraform Configuration

Complete TF recipe was given to Yanie Nicole

Debug Output

EXTRACT from Console execution (this is a result of a recipe rerun, the error was already present):

11/24/2023 10:28:57 AM null_resource.remoteExecConfigure[0] (remote-exec): PLAY RECAP ***** 11/24/2023 10:28:57 AM null_resource.remoteExecConfigure[0] (remote-exec): DBR7Ply : ok=67 changed=36 unreachable=1 failed=0 skipped=14 rescued=0 ignored=0 11/24/2023 10:28:57 AM null_resource.remoteExecConfigure[0] (remote-exec): DBR7Sesrv1 : ok=11 changed=2 unreachable=0 failed=0 skipped=1 rescued=0 ignored=0 11/24/2023 10:28:57 AM null_resource.remoteExecConfigure[0] (remote-exec): DBR7Svd1 : ok=11 changed=2 unreachable=0 failed=0 skipped=1 rescued=0 ignored=0 11/24/2023 10:28:57 AM null_resource.remoteExecConfigure[0] (remote-exec): localhost : ok=5 changed=2 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0 11/24/2023 10:28:57 AM

Error: remote-exec provisioner error

with null_resource.remoteExecConfigure[0], on ansible_docker_exec.tf line 84, in resource "null_resource" "remoteExecConfigure": 84: provisioner "remote-exec" {

error executing "/tmp/terraform_1153439670.sh": Process exited with status 4

Error: disk.0: cannot change the value of "thin_provisioned" - (old: true newValue: false)

with module.recipe.module.sesrv.vsphere_virtual_machine.vm, on Modules\VirtualMachine\VirtualMachine.tf line 146, in resource "vsphere_virtual_machine" "vm": 146: resource "vsphere_virtual_machine" "vm" {

Panic Output

No response

Expected Behavior

Keep Template disk setup. Fix error.

Actual Behavior

During VM creation process from Template, it seems that the VM disk type goes from Thick to Thin, then TF tries to switch it back to Thick.

Steps to Reproduce

Run a TF recipe that contains several VMs to create (10+) on a Cluster that is being actively used. Repeat operation until TF fails with the reported error.

Environment Details

No response

Screenshots

No response

References

issue #1028

github-actions[bot] commented 9 months ago

Hello, leblancs321! 🖐

Thank you for submitting an issue for this provider. The issue will now enter into the issue lifecycle.

If you want to contribute to this project, please review the contributing guidelines and information on submitting pull requests.

vasilsatanasov commented 9 months ago

Hi @leblancs321 have you tried to use 

lifecycle {
    ignore_changes = [
      thin_provisioned
    ]
  }

as a workaround for this issue ? Also could you provide some HCL code which will help us reproduce the issue plus the version of vSphere you are using.

Best Regards, Vasil

leblancs321 commented 9 months ago

Hi, Thanks for fast answer. I corrected the plugin and client versions in the issue above, sorry for my missinterpretation of the questions.

So, to answer your questions:

vasilsatanasov commented 9 months ago

Hi @leblancs321 did you checked the https://kb.vmware.com/s/article/2145183 regarding disk provisioning types. Also can you check how the same operation goes with the vSphere HTML client UI ?

leblancs321 commented 9 months ago

Hi @vasilsatanasov , that kb goes from thick eager zeroed to thick lazy, to my understanding. We are just cloning from thick eager zeroed to thick eager zeroed. (we do not request any change). Sometimes, the VM disk seems to switch from thick to thin, and TF tries to bring it back to thick, which is not accepted.

As for the second part of the question, we never noticed an unexpected change of disk type when cloning from tempate or VM when using the vSphere client.

leblancs321 commented 9 months ago

Another information: Our current cluster global storage solution is using a NAS (Synology) with NFS storage type with VAAI plugin.

micropbl4 commented 6 months ago

I noted that the problem appears only when you try to clone a VM from a template with a thin disk type. On my side, this approach was applied as a workaround

github-actions[bot] commented 4 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.