What causes UUID errors with Replication 6?

A universally unique identifier (UUID) is a 128-bit code assigned to each VM. The UUID is created when the VM is first powered on or moved, and gives the VM a unique identity versus any other VMs in the environment. UUIDs are typically created from a mix of physical host and path information and often resemble a format in uuid.bios such as:

46 5d 2e 28 55 e5 2e 03 21 51 0b cd 2f a3 20 44

One advantage of the UUID is it can be linked to other settings for the VM such as a unique media access control (MAC) address. If you were to produce multiple copies of the VM, they would all wind up with the same MAC address and present a host of networking conflicts. By setting unique UUIDs during the copy process, each copy can have its own UUID and be treated as a distinctive entity. If the VM is simply migrated, the UUID and associated details remain unchanged.

But vSphere Replication 6 makes an exception here. When replicating VMs to a remote data center, vSphere Replication 6 will create an initial copy on the remote end and assign the remote copy the same UUID used for the original local VM. This way, vSphere Replication 6 knows that both copies are the same, and will use the remote copy as a basis for comparison and delta differencing during subsequent replication cycles; this delta differencing can be performed at the remote end. This is faster and more efficient for the network than recording changed blocks locally and moving them across the network. However, the UUID for the actual VM must match the UUID of the "base" or "remote reference" VM at the remote data center. If not, a UUID error will occur.

UUIDs will change when vSphere Replication 6 processes are not followed precisely. For example, cloning the VM first and then transferring the cloned file to the disaster recovery (DR) site will result in a different UUID for the manually cloned VM. Manually registering and powering on the copied VM -- and telling vSphere that it's a copy -- will result in a VM with a different UUID. And restoring a VM file to a DR site using a third-party backup tool and then trying to replicate the VM will cause UUIDs to be different. All of these scenarios will cause target disk UUID validation errors during vSphere Replication 6 cycles.

Regardless of the cause, the most direct method of resolving this problem is to correct the erroneous UUID on the remote VM files. This can be accomplished using an ordinary text editor. Log onto the source VM and obtain the UUID from the original VM file. Then log onto the remote site and use a text editor to overwrite the ddb.uuid field in the troubled .vmdk file at the DR site. It's best to create a snapshot or other backup of the remote VM before attempting any manual changes to file data. Once corrected, subsequent replications should not produce validation errors.