Changing UUID on restore

[lloyd.mills]

Hi,

Is there a method for changing the UUID in Veeam when you restore the VM.
Currently the only way i know is to clone the VM after restoring, or edit the .vmx file.

If not is this a feature that is planned for the future?

Thanks

Lloyd

[Vitaliy S.]

Hello Lloyd,

No, there is no way to change UUID on VM restore. Thanks for the feature request, but could you please tell me what is the use case for this change?

Thank you.

[lloyd.mills]

Hi Vitaliy,

The main reason for this is we currently restore the backup of live servers to a DR cluster that we also use for test. So there are only a few changes required to make to the OS to repurpose the machine as a test box etc.
The DR cluster is the destination for our replica's so in the event our live site went down for a prolonged period, we would power off the test servers and failover to the replica's.

This would leave us with duplicate UUID's, currently we have to manually change them.

Thanks

Lloyd

[Vitaliy S.]

Hmm...ok, how about using replication jobs for VMs that you're using in the DR tests? That should change UUID for replicated VMs automatically, as it is not possible to have two VMs in the infrastructure with the same UUID.

[lloyd.mills]

Maybe we need to open a support case then....
As we have in more than one instance, 2 vm's with the same UUID replicated from two different clusters (so shouldn't cause an issue here..) to the same cluster and they both have the same UUID on the destination cluster as on both source clusters.

E.g.
Cluster 1 Cluster 2 Cluster 3
VM1 UUID=543 VM2 UUID=543 VM1_replica UUID=543
VM2_replica UUID=543

Please let me know your thoughts

[Vitaliy S.]

I've just consulted with our development team and I was told that basically there are two types of UUIDs, one of them is assigned on VM level, another one is called instance UUID.

VM UUID should always be the same for both replicated and source VMs, because it is used by Guest BIOS to identify the VM. Many software applications are using this ID to verify licensing/configuration status (e.g. Windows is using this ID for activation).

That said, If you want to dig deeper, please take a look at UUID numbers for these VMs via MOB (Managed Object Browser), because the IDs you've posted do not look like UUID. UUIDs should have the following format "501988ca-a82b-20e3-7a18-1ef90f0b105a".

Thanks.

[lloyd.mills]

Hi Vitaliy,

These were examples as i did not want to type in full UUID's. Also it looks like the example was reformatted after i posted it.

That information is helpful and makes me less worried about the duplicate ID's - we do however still plan to change these.

Thankyou for your help

[Daveyd]

Looking at the KB article from Veeam: http://www.veeam.com/kb1669 It states that "After a short time, VMware vSphere changes replica’s MAC address and UUID."

So, if I look in the vCenter's Managed Object Browser and look for the replicas Instance UUID, should it be different than the productions Instance UUID? In my case, the Instance UUIDs are the same.

[Vitaliy S.]

Hi Dave, I doubt that they should be different, as replication job creates a complete copy of your source VM, so seeing MAC address/UUID conflicts is fully expected during replication jobs.

[Daveyd]

OK. We are having an issue with another piece of software that monitors VMs. The software sees both UUIDs being the same and gets confused.

[Vitaliy S.]

Yeah, monitoring tools will most likely be confused by this, but in Veeam ONE we are suppressing these alarms by default.

[JuA]

Hi,

Is this feature still unavailable ? (Changing the VM Bios UUID while restoring with Veeam).

Some non-funny guys with blue suits want us to run a tool called "IBM Licence Metric Tool", and it doesn't like UUID duplicates at all.

Regards,

[foggy]

Changing UUID upon VM restore is still not possible.

[lienkristian]

What if you do a sysprep? Then it will get new uuid?

[fabsainte]

Hello,

I am facing same issue in our VMware environment: I used Veeam B&R to restore two production VMs under new names to create preproduction plateform . I could do a VMware copy but I prefer proceed this way to validate the whole Veeam B&R chain, restoring data from a nightly backup.
The two new VMs got:
- new MAC adress (OK)
- same UUID (and same serial number) as the source VMs : annoying

How I detected this strange behaviour, and why it is annoying ?

In fact, we rely on fusioninventory-agent to fill our configuration management database (GLPI), which relies by default on systems UUID to import the VMs. I could not figure why I could not get the new VMs integrated into GLPI, until I noticed the duplicates UUID between original and restored VMs.

In dmidecode, we can see that both "Serial Number" and "UUID" remain unchanged... which is definitively not clean.

By the way, we can also do a quick audit with powershell to detect duplicates...
Get-VM | select @{N="VMname"; E={$_.Name}}, @{N="UUID"; E={($_ | Get-View).config.uuid}}

So the question is: why are "Serial Number" and "UUID" not modified in case of VM restoration, whereas a new MAC address is correctly generated?

[foggy]

I believe MAC address is changed by VMware (see above).

[fabsainte]

Agreed.

However, why Veeam B&R is not able - at restore time - to:

• either assign automatically new UUID and serial number,

• or display an option (new check button) for assigning new UUID and serial number,

• or trigger the standard VMware question "This virtual machine might have been moved or copied. In order to configure certain management and networking features, VMware ESX needs to know if this virtual machine was moved or copied....I Moved It. I Copied It." ?

[foggy]

It just didn't get high enough in the priority list.