Add support to include datacenter_id (optional) for r/virtual_machine argument to ignore replicas

[wocomwouter]

Terraform Version

1.1.0

vSphere Provider Version

2.0.2

vSphere Version

7.0.2

Affected Resource(s)

vsphere_virtual_machine

If this issue appears to affect multiple resources, it may be an issue with
Terraform's core, so please mention this.
---> in this case it affects only VMs who have a replica.

Terraform Configuration Files

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key.

Debug Output

Panic Output

Expected Behavior

We have 2 Datacenters, one for production and the other one for non-prod workloads and replica.
When a production VM is initially created, all works fine. By adding a tag to the VM and after pickup of VEEAM, this VM is automatically added as a VEEAM replica to our second datacenter. When we execute a plan or apply, we noticed that now Terraform tries to change the REPLICA VM instead of the source VM. By doing some research we noticed that both VMs have the same VM UUID (both source & replica) and this is as design. Probably Vsphere provider works with this VM UUID but it is not unique within vcenter. MOID should be a better option, I guess...

Actual Behavior

Terraform plan/apply tries to change the replica VM instead of the source VM.
.

The only dirty workaround that we now implemented is by adding a lifecycle block with ignore_changes = all. That way we prevent a VM to be changed, but that means also that we cannot do changes through Terraform on an existing VM.

Steps to Reproduce

Important Factoids

Apparently a terraform refresh state doesn't take into account the datacenter name or resource pool id and so it tries to manipulate the replicated VM instead of the source VM.

References

Think that #1524 is kinda related.

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.

[bmhughes]

Getting the same problem here in the same situation with the same symptoms.

[wocomwouter]

I guess we can say this is quite a HUGE bug...

[tenthirtyam]

Hi @wocomwouter, are these two data centers with a vCenter Server instance in each participating in enhanced linked mode? If so, one method to address this is to use an account with reduced Global Permissions and apply roles/permissions at the vCenter Server level - that will limit the scope and visibility of the account. This would ensure that actions are limited within the scope of the target site. However, if you have any Terraform plans that interact with the Content Library the Global Permissions for content library privileges must be granted the each account.

Ryan Johnson
Staff II Solutions Architect, VMware, Inc.
VMware Validated Solutions Engineering
credly.com/users/tenthirtyam

[bmhughes]

It's all under the same vCenter server for me (not a large setup), I did already consider doing as you suggest but the addition of ELM and another VCSA has a variety of tradeoffs as well so it's a workaround that would work for me personally.

[bmhughes]

To add, I did have a dig through the code back when I first encountered this and it's (as @wocomwouter's initial bug description) because when searching for the VM the datastore/resource pool/etc isn't taken into account to restrict the search.

It's just the VM UUID which is duplicated by the replication operation, I do seem to remember that the govmovi library allowed restricting by datacenter but it wasn't going to be a trivial change (else I'd have put a PR in) so didn't look much further.

[tenthirtyam]

@wocomwouter, checking in for your response as well.

Ryan Johnson
Staff II Solutions Architect at VMware, Inc.

[wocomwouter]

Hi @tenthirtyam, your comment was very usefull - we implemented a workaround where we create 2 accounts - one for datacenter 1, the other one for datacenter 2 and used these in our specific pipelines and did some magic on the global permissions & vcenter level. I can confirm that this workaround works, but it is not optimal of course ...

[tenthirtyam]

Thank for confirming that the recommendation helped to resolve the issue in your environment, @wocomwouter.

Ryan Johnson
Staff II Solutions Architect at VMware, Inc.

[tenthirtyam]

@appilon and @tejavar - An enhancement to consider including datacenter_id (optional) as a parameter to limit the scope.

Ryan Johnson
Staff II Solutions Architect at VMware, Inc.

[tenthirtyam]

Converting an enhancement to consider including datacenter_id (optional) as a parameter to limit the scope.

[tenthirtyam]

I've reopened #282 as this would be a better path.

Ryan