Run plan with existing local state file against resource that has changed crashes Terraform with 'Error: rpc error: code = Unavailable desc = transport is closing'

[pauledavey]

Terraform version: v0.12.10
vSphere Provider version: v1.13.0

I have a simple script to add a portgroup to an ESXi host (as follows)

data "vsphere_datacenter" "datacenter" {
  name = "AutomationCore"
}

data "vsphere_host" "esxi_host" {
  name          = "${var.esxi_hostName}"
  datacenter_id = "${data.vsphere_datacenter.datacenter.id}"
}

resource "vsphere_host_port_group" "pg" {
  name                = "PGTerraformTest"
  host_system_id      = "${data.vsphere_host.esxi_host.id}"
  virtual_switch_name = "vSwitch0"
  vlan_id = 4095
  allow_promiscuous = true
}

This adds the portgroup to a host specified as a variable correctly. I can plan and apply successfully.
Following this I can run plan again against the same host. It states that the same resource needs to be created again (1 to add) which I find strange. If I attempt to apply it tells me the resource already exists.

If I manually change the vLAN on the portgroup from 4095 to something else (i.e. 999) and then run plan against the host, Terraform crashes. My understanding is that it should show me that there is a difference between the locally saved state file and the deployed portgroup. I have this issue against multiple ESXi hosts.

I have attached the crash.log file to this issue ticket.
crash.log

[koikonom]

HI @pauledavey! Thanks for taking the time to report this issue.

I tried to reproduce this against my own vsphere lab with little success. Can you please reproduce the issue, with the environment variable TF_LOG set to DEBUG before running terraform, and upload the debug output ?

You don't have to repeat the whole process. I am interested in seeing why terraform believes it needs to create the resource again, so I just need the debug logs of the plan operation right after the resource has been created.

The logs from the resource creation are useful too, assuming you can get these as well.

[aareet]

I am closing this issue since it has been waiting for a response for 22 days. Please reopen if this is reproducible. Additionally, we've issued a fix in a4b6343 that might have fixed this.