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

[leblancs321]

Community Guidelines

• I have read and agree to the HashiCorp Community Guidelines .
• Vote on this issue by adding a 👍 reaction to the original issue initial description to help the maintainers prioritize.
• Do not leave "+1" or other comments that do not add relevant information or questions.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.

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]

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]

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]

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:

• lifecycle ignore_changes ... Yes we did, we confirm it does not fail, but the disk state of the VM is 'thin' after the creation process, which is not what we need since the workaround simply ignores the change of disk and scrubbing type. So we cannot apply this workaround. (template is 'thick' and we request to keep 'thick', but in the process of the VM creation, intermittently, the disk changes to 'thin' and TF complains when it tries to switch it back.

• VMWare vSphere client version - 7.0.3.01700 (corrected in the issue description)

• HCL code, I provided two .tf files in the collected data.
  We have some sentitive information in that code. We are discussing options within the team and with VMWare and coming back to you.

[vasilsatanasov]

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]

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]

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

[micropbl4]

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]

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.