Import conflicts when using `datastoreClusterId` vs `datastoreId` with VM disks

[MeganYTan]

Describe what happened

When importing an existing VM with an attached disk into Pulumi, conflicts occur between datastoreId and datastoreClusterId.

• If only datastoreId is specified on the VM and the disk, the preview shows [diff: -datastoreClusterId] which blocks the import.
• If only datastoreClusterId is specified on the VM, and no datastoreId is specified on the disk level, there is the following error:

[13:34:38 INF]     error: vsphere:index/virtualMachine:VirtualMachine resource 'rsgberger01' has a problem: Conflicting configuration arguments. "datastore_cluster_id": conflicts with datastore_id. Examine values at 'rsgberger01.datastoreClusterId'.
[13:34:38 INF]     error: vsphere:index/virtualMachine:VirtualMachine resource 'rsgberger01' has a problem: Conflicting configuration arguments. "datastore_id": conflicts with datastore_cluster_id. Examine values at 'rsgberger01.datastoreId'.

• If only datastoreId is specified on the VM, there is the following error:

[13:36:30 INF]   vsphere:index:VirtualMachine (rsgadcita3):
[13:36:30 INF]     error: vsphere:index/virtualMachine:VirtualMachine resource 'rsgadcita3' has a problem: Conflicting configuration arguments. "disk.0.datastore_id": conflicts with datastore_cluster_id. Examine values at 'rsgadcita3.disks[0].datastoreId'.

• If both datastoreId and datastoreClusterId are specified, conflicting configuration argument errors are raised.

Pulumi commands run:

pulumi import vsphere:index/virtualMachine:VirtualMachine rsgadcita3 vm-12345
pulumi preview

Sample program

This is an import issue with no sample.

Log output

See above for various logs under different scenarios.

Affected Resource(s)

vsphere:index/virtualMachine:VirtualMachine

Output of pulumi about

Awaiting response

Additional context

Found a related issue with the Terraform provider: vmware/terraform-provider-vsphere#483

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[EronWright]

(automated analysis)

The Pulumi vSphere issue #873 describes import conflicts between datastoreClusterId and datastoreId when importing VM resources. The Terraform provider comment reveals the root cause:

Key Insight: The Terraform vSphere provider has conditional logic that executes different code paths during planning based on which field (datastore_id vs datastore_cluster_id) is set.

The Problem: The bridge's import logic likely doesn't correctly handle this mutual exclusivity. During import:

1. The bridge may be setting both fields when it should set only one
2. The import process might not correctly detect which field was originally used in the infrastructure
3. The state representation doesn't maintain the distinction between "use datastore" vs "use datastore cluster"

Expected Behavior:

• If the VM was created with a datastore cluster, only datastoreClusterId should be set on import
• If the VM was created with a specific datastore, only datastoreId should be set
• Setting both triggers the Terraform provider's validation errors

This is a schema mapping issue in the bridge where the mutual exclusivity (ConflictsWith in Terraform schema) needs to be properly handled during import operations.

[EronWright]

The issue seems to be a continuation of: pulumi/pulumi-terraform-bridge#2314

TODO at provider.go:1588 suggests that the nested disk object isn't de-conflicted:

  // do not process errors on nested types
  // TODO: https://github.com/pulumi/pulumi-terraform-bridge/issues/2314

For reference, the schema:

  "datastore_id": {
      Type:          schema.TypeString,
      Optional:      true,
      Computed:      true,
      ConflictsWith: []string{"datastore_cluster_id"},
  }

  "datastore_cluster_id": {
      Type:          schema.TypeString,
      Optional:      true,
      ConflictsWith: []string{"datastore_id"},
  }