Hi @Martin Weber ,
Thank you for sharing.
So, the work around is to do the Storage vMotion after Deploying the VM from the Template.
What if the VM has already been deployed from Template and running as Production VM?
@vAdmin No, this will not work - I tested it
You have to identify the Disk, shutdown the VM and change UUID over the shell
vmkfstools -J setuuid <vmname>.vmdk
@vAdminNo, this will not work - I tested it
You have to identify the Disk, shutdown the VM and change UUID over the shell
vmkfstools -J setuuid <vmname>.vmdk
Wow, that’s massive outage :-| for a big and busy VM.
Thank you for the sharing @Martin Weber
@vAdmin You said it :(
I found over 300VMs over across multiple customers with duplicate UUIDs.
I understand that the main problem comes from VMware - but VMware has no problems with that at the moment, only VEEAM in Version 12 has it.
I found a blogpost - I will review it and test it… If it work, i will reply the result here
https://blog.milla-online.de/duplicate-disk-uuids-and-how-to-get-rid-of-it-hopefully
Inside the forum there is a workaround to change transport mode to NBD (network) - https://forums.veeam.com/post479533.html#p479533
But this is not a workaround for us - because we have a separate Backup VLAN/Network/Uplink
I created a Powershell script to Change Disk UUIDs without to reboot a vm - https://github.com/claranet/ClaranetHub/tree/main/VMware/Change-DiskUUID
Currently we test it on some vms with failed backups
Ouch! 
Thanks for sharing Martin..
Inside the forum there is a workaround to change transport mode to NBD (network) - https://forums.veeam.com/post479533.html#p479533
But this is not a workaround for us - because we have a separate Backup VLAN/Network/Uplink
I created a Powershell script to Change Disk UUIDs without to reboot a vm - https://github.com/claranet/ClaranetHub/tree/main/VMware/Change-DiskUUID
Currently we test it on some vms with failed backups
Wow, without a reboot 
that sounds promising,
Thank you for sharing it here @Martin Weber
Thanks for sharing this. Will come in handy to add to my script library.
Thank you for sharing this, we discovered plenty of duplicate UUID. We will fix it before v12 update which is planned next week 
Anyone know why it has become a problem now in V12? Why do we have the UUID checks in v12 and not in v11? Can’t we just leave the check out of v12 like it was in v11?
@wouter.oltlammers Yes, to be compatible with vmware they added a DiskUUID check in Version 12. The Problem on VMware side is older - and maybe it can also have some effects there.
I changed 200VMs with this script last days and Backups worked fine again.
Pleas note, if you use Network Transportmode this does not affect - It only affect if you use HotAdd-Mode.
OK, found new issue on this Problem - Backup over HotAdd will not work with “Linked Clone” as the created in vCloud Director if enabled or VM created in Virtual Desktop Environment.
Reproduce
$VM = Get-VM "<my vm>"
$Snapshot = $VM | New-Snapshot -Name "BASE"
New-VM -Name "$($VM.Name) - Linked Clone" -VM $VM -VMHost $VM.VMHost -LinkedClone -ReferenceSnapshot $Snapshot
Get-VM -Name "$($VM.Name)*"| Get-HardDisk | Select @{N='Name';E={$_.Parent.Name}}, @{N='Uuid';E={$_.ExtensionData.Backing.Uuid}}
That's interesting and I've never heard of the issue with duplicate UUIDs. So if you have an affected disk, the backup job via hotadd/virtual appliance mode will fail?
According to the article only vSphere 6.7 and below have this issue. But if you upgraded to 7.0 or higher, it wouldn't solve already duplicated UUIDs ?
No, I have checked our 7 U3 clusters and there are duplicate UUIDs...
@JMeixner you check the issue also on 7.0u3, but is it still a problem with V12 hot-add jobs?
@JMeixner Ok, so this is something which needs to be corrected manually after upgrading.
@fspadaro Only V12 will have this issue.
I will discus this issue with our VMware admins next week.
Another question:
Is there an official statement from Veeam about this problem/feature (
)?
Another question:
Is there an official statement from Veeam about this problem/feature ()?
I was wondering the same thing...
Inside the forum there is a workaround to change transport mode to NBD (network) - https://forums.veeam.com/post479533.html#p479533
But this is not a workaround for us - because we have a separate Backup VLAN/Network/Uplink
I created a Powershell script to Change Disk UUIDs without to reboot a vm - https://github.com/claranet/ClaranetHub/tree/main/VMware/Change-DiskUUID
Currently we test it on some vms with failed backups
thanks Martin!
this is gold!
Another question:
Is there an official statement from Veeam about this problem/feature ()?
Fabian ( @Mildur ) has sent an interesting VMware KB article to me:
https://kb.vmware.com/s/article/1021189
This is a possible explanation of the problem. Disks with the same UUID must not be mounted to the same VM. The Veeam backup proxys are mounting a lot of disks and there is a great chance that disks with the same UUID are among these.
Another question:
Is there an official statement from Veeam about this problem/feature ()?
Fabian ( @Mildur ) has sent an interesting VMware KB article to me:
https://kb.vmware.com/s/article/1021189
This is a possible explanation of the problem. Disks with the same UUID must not be mounted to the same VM. The Veeam backup proxys are mounting a lot of disks and there is a great chance that disks with the same UUID are among these.
I will check on my lab environment, where I’ve found 4 VMs with the same UUID.
Hi to all,
I’m testing in my lab:
- 2 VMs with the same UUID
- Veeam DP v12
- VMware 7.0U3
The proxy server process all disks (simultaneously) in Virtual appliance mode without problems.
