Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unpredictable disk type creation when cloning VM from the template with thin disk type #2178

Closed
2 of 4 tasks
micropbl4 opened this issue Apr 24, 2024 · 4 comments
Closed
2 of 4 tasks
Assignees
Labels
bug Type: Bug

Comments

@micropbl4
Copy link

micropbl4 commented Apr 24, 2024

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.0

Terraform Provider

2.5.1

VMware vSphere

8.0.2

Description

When attempting to create a disk with the "Thick Provision Lazy Zeroed" type, Terraform randomly creates another type. Upon rerunning the same code, I receive the following output:

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

This occurs within the module.provision_base_vms["hostname"].module.server.vsphere_virtual_machine.server resource in the .terraform/modules/provision_base_vms/server/server.tf file, at line 20, within the resource "vsphere_virtual_machine" "server" block.

In my case 1 of 3 VM was affected.

Affected Resources or Data Sources

"resource/vsphere_virtual_machine"

Terraform Configuration

server.tf

resource "vsphere_virtual_machine" "server" {
....
dynamic "disk" {
    for_each = var.disks
    iterator = each
    content {
      size             = each.value.size
      label            = "disk${each.key}"
      unit_number      = each.key
      attach           = each.value.attach
      path             = each.value.path
      datastore_id     = data.vsphere_datastore.datastore.id
      thin_provisioned = each.value.attach ? null : each.value.thin_provisioned
      eagerly_scrub    = each.value.attach ? null : each.value.eagerly_scrub
    }
clone {
    template_uuid = var.template_uuid
    customize {
      linux_options {
        host_name = var.host_name
        domain    = var.domain
      }

      network_interface {
        ipv4_address = var.ip_v4_address
        ipv4_netmask = var.ip_v4_netmask
      }

      ipv4_gateway    = var.ip_v4_gateway
      dns_server_list = var.dns_server_list
      timeout         = var.timeout
    }
  }
}

variables.tf

variable "disks" {
  type = list(
    object({
      attach           = optional(bool, false)
      size             = optional(number)
      path             = optional(string)
      thin_provisioned = optional(bool, false)
      eagerly_scrub    = optional(bool, false)
    })
  )

Debug Output

terraform plan
1st attempt:

disk { 
 attach            = false 
 controller_type   = "scsi" 
 datastore_id      = "datastore-33009" 
 device_address    = (known after apply) 
 disk_mode         = "persistent" 
 disk_sharing      = "sharingNone" 
 eagerly_scrub     = false 
 io_limit          = -1 
 io_reservation    = 0 
 io_share_count    = 0 
 io_share_level    = "normal" 
 keep_on_remove    = false 
 key               = 0 
 label             = "disk0" 
 path              = (known after apply) 
 size              = 40 
 storage_policy_id = (known after apply) 
 thin_provisioned  = false 
 unit_number       = 0 
 uuid              = (known after apply) 
 write_through     = false 
} 

2nd attempt:

Terraform will perform the following actions: 

  # module.provision_base_vms["hostname"].module.server.vsphere_virtual_machine.server will be updated in-place 

  ~ resource "vsphere_virtual_machine" "server" { 

        id  = "42143a93-de7a-b80c-ab1e-adf3404853e8" 

        name= "hostname" 
      ~ disk { 
          ~ thin_provisioned = true -> false 

} 

Panic Output

No response

Expected Behavior

When attempting to create a disk with the "Thick Provision Lazy Zeroed" type, Terraform inconsistently selects a different type. Upon rerunning the same code, there should be no changes in the output. However, the error message indicates that there is an attempt to change the "thin_provisioned" value from true to false, which should not occur.

Actual Behavior

Provider change infrastructure without actual changes on the code side

Steps to Reproduce

  1. Create a few VMs with the following options:
  dynamic "disk" {
      .....
      thin_provisioned = false
      eagerly_scrub      = false
  1. Execute terraform deploy without any changes

Environment Details

No response

Screenshots

No response

References

No response

@micropbl4 micropbl4 added bug Type: Bug needs-triage Status: Issue Needs Triage labels Apr 24, 2024
Copy link

Hello, micropbl4! 🖐

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.

@micropbl4 micropbl4 changed the title Inconsistent disk type creation Inconsistent disk type creation Apr 24, 2024
@micropbl4 micropbl4 changed the title Inconsistent disk type creation Unpredictable Disk Type Creation When Cloning from Template with Thin Disk Apr 24, 2024
@micropbl4 micropbl4 changed the title Unpredictable Disk Type Creation When Cloning from Template with Thin Disk Unpredictable disk type creation when cloning VM from the template with thin disk type Apr 24, 2024
@spacegospod
Copy link
Collaborator

Looks like a duplicate of #2116

There are other duplicates out there too
#2140

@micropbl4 don't worry I'll try to fix this
Let's move the conversation to #2116

@spacegospod
Copy link
Collaborator

Duplicate of #2116

@spacegospod spacegospod marked this as a duplicate of #2116 Apr 24, 2024
@spacegospod spacegospod closed this as not planned Won't fix, can't repro, duplicate, stale Apr 24, 2024
@tenthirtyam tenthirtyam removed the needs-triage Status: Issue Needs Triage label Apr 29, 2024
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 31, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Type: Bug
Projects
None yet
Development

No branches or pull requests

3 participants