`r/virtual_machine`: transition from (BIOS) UUID to instance UUID as ID attribute

[vancluever]

As part of the new VM work we have transitioned to using UUIDs as the id attribute for both the resource and data source form of vsphere_virtual_machine. This was facilitated by using existing functionality in helper/virtualmachine, namely the virtualmachine.FromUUID method that was already being used to search VMs by UUID in the vsphere_virtual_machine_snapshot resource. This UUID was also exposed in the old version of the resource as the uuid field.

However, all of this logic is currently referencing the BIOS UUID of the virtual machine in question - and as such is not optimal. While it has not been observed yet there are situations where the BIOS UUIDs of virtual machines can overlap. This should be fixed sooner rather than later so that we don't run into issues later down the line, as duplicate IDs would have some obviously bad ramifications for working with Terraform.

An outline of the the scenarios a VM's BIOS UUID can be duplicated can be found here. Note that our current cloning logic does not touch the VirtualMachineConfigSpec that can be included in the clone spec, as it is a deprecated field, and that's the only place I can personally see any sort of UUID being settable. The only other real plausible scenario that a BIOS UUID can be duplicated is a manual clone (ie: cold-copy of the VM). See here. There is also possibly advanced configuration that can make UUIDs immutable but again that is not something we touch or something I saw crawling the VirtualMachineConfigSpec, so the only scenario that I can see this possibly happening in is if someone set it in advanced config or in the VMX file directly (see here).

A checklist is below:

• Add virtualmachine.FromInstanceUUID
• Move current virtualmachine.FromUUID to virtualmachine.FromBIOSUUID
• Ensure that all references to virtualmachine.FromUUID change to virtualmachine.FromInstanceUUID
• Increment schema version on vsphere_virtual_machine and vsphere_virtual_machine_snapshot resources
• Add state migration to transition id field on vsphere_virtual_machine to instance UUID
• Add state migration to transition uuid field on vsphere_virtual_machine to bios_uuid
• Add instance_uuid field on vsphere_virtual_machine and populate during state migration
• Add state migration to transition virtual_machine_uuid field on vsphere_virtual_machine_snapshot to instance UUID

Luckily there is not much else using this UUID right now, so we can get this in and correct going forward with the effort above.

[dannyk81]

Hi @vancluever, came across this issue (and also #578 that was referenced).

For a while now, we've been hitting an issue with VMs that changed their UUID which in return triggers terraform to want to create them again, the only remedy for this situation is to remove this VM from the state and import it with the new UUID, this is of course quite tedious and breaks our automation processes.

The reasons their UUID change seem to be:

1. esxi server failures which causes the VM to be "moved" automatically by HA to a different esxi
2. since all VMs have uuid.action = create by default, (1) above causes the UUID to be recreated due to the HA "move"

Do you know if InstanceUUID "suffers" from the same behaviour? or is it considered to be immutable for the VM life cycle (unless modified manually as you described above)?

[tenthirtyam]

Reopening this enhancement.