The resource vim.dvs.DistributedVirtualPort is not available in vim.dvs.DistributedVirtualPortgroup

[lgrn]

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

Terraform Provider

2.8.1

VMware vSphere

7.0.3.01700

Description

We are seeing an issue when moving from 2.6.1 -> 2.8.1, and have confirmed that the issue goes away when reverting to using 2.6.1 in our required_providers block in main.tf. This currently breaks all deploys for us on 2.8.1.

First of all, the complete error:

╷
│ Error: error reconfiguring virtual machine: error reconfiguring virtual machine: The resource vim.dvs.DistributedVirtualPort is not available in vim.dvs.DistributedVirtualPortgroup REDACTED.
│ 
│   with vsphere_virtual_machine.vm["1260"],
│   on virtualmachines.tf line 37, in resource "vsphere_virtual_machine" "vm":
│   37: resource "vsphere_virtual_machine" "vm" {
│ 
╵

Our vsphere_virtual_machine definition looks like this, I've removed some pieces to make it more readable:

resource "vsphere_virtual_machine" "vm" {
  for_each = { for k, v in local.fetched_vms : k => v if v.platform_id == 5 } // 5 = 'linux'
(...)
  dynamic "network_interface" {
    for_each = local.fetched_vms[each.key]["interfaces"]
    content {
      network_id = data.vsphere_network.network[network_interface.key].id
    }
(...)
  depends_on = [
    data.local_file.fetch_netbox,
    data.vsphere_network.network,
    local.fetched_vms,
    data.template_cloudinit_config.user_data,
  ]
}

This takes in local.fetched_vms which is a JSON interpretation of Netbox virtual machines, but I don't think that's the issue since the error mentions vim.dvs.DistributedVirtualPort and vim.dvs.DistributedVirtualPortgroup.

Virtual switch:

data "vsphere_distributed_virtual_switch" "vds" {
  for_each      = local.unique_vswitch_list
  name          = each.key
  datacenter_id = data.vsphere_datacenter.dc.id
}

Network:

data "vsphere_network" "network" {
  for_each = { for x in local.iface_network_map : x.interface_id => {
    vmware_switch_name  = x.vmware_switch_name,
    vmware_network_name = x.vmware_network_name
  } }
  name                            = each.value.vmware_network_name
  datacenter_id                   = data.vsphere_datacenter.dc.id
  distributed_virtual_switch_uuid = data.vsphere_distributed_virtual_switch.vds[each.value.vmware_switch_name].id
}

Googling the error "The resource vim.dvs.DistributedVirtualPort is not available in vim.dvs.DistributedVirtualPortgroup" gives indications that this is an issue on the vmware end of things, but in our case this is not true since the issue only appeared when upgrading the provider, and disappeared when downgrading it.

The reason we provide both name and distributed_virtual_switch_uuid when creating the network is that we have conflicting names in our environment, so both of them are needed for a unique match.

Does anyone have any ideas what could be causing this issue? Is it a bug, or something exotic in our configuration that only became an issue when upgrading?

Also, I'm not sure if it matters, but we're using OpenTofu. If you think there's a reason that would break things we can try Terraform as well.

Happy to provide more config examples if necessary.

Affected Resources or Data Sources

vsphere_virtual_machine or vsphere_network

Terraform Configuration

In description

Debug Output

N/A

Panic Output

No response

Expected Behavior

Successful deploy

Actual Behavior

The resource vim.dvs.DistributedVirtualPort is not available in vim.dvs.DistributedVirtualPortgroup

Steps to Reproduce

N/A

Environment Details

No response

Screenshots

No response

References

No response

[github-actions]

Hello, lgrn! 🖐

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.

[lgrn]

When trying to reproduce this to gather more information, it turns out it now magically works. Let's chalk it up to some bullshit on the vmware end, I guess. Sorry for any time wasted, I'll re-open if we see it again with some debug output.

[tenthirtyam]

Please be mindful of the HashiCorp Community Guidelines .

[lgrn]

Please be mindful of the HashiCorp Community Guidelines .

Care to elaborate?

[tenthirtyam]

"Let's chalk it up to some ******** on the vmware end, I guess..."

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