About 2 months ago I built a new ESXi server (v. 6.0.0) to run a new DC and file server. I built the DC up to a point and then tried to make a template/clone it so I could more quickly build the file server. It seems that plain ESXi (no vSphere) doesn't do that, so I wound up trying to just copy the files to make a clone. That worked just fine as far as I can tell, and the servers have been in production for a little over a month.
My drives for the backup server have arrived, so now I'm trying to build my Unitrends box and get backups going.
When I try to add this ESXi host to the Unitrends backups, Unitrends complains about my DC and file server having the same instance UUID. I found another community thread that said to power off the machine and edit the uuid.bios line in the vmx file. I tried that, but it seems to give the same error. Does anyone have a suggestion?
@vXav It sounds similar, but when I run the command
vmkfstools -J getuuid <vmname>.vmdk
I get different UUID values for the two machines in question. I tried to check the others, but most of them (which are powered off...probably permanently) just say
The virtual disk does not contain a UUID
The two machines in question return the following:
UUID is 60 00 C2 9d e0 a6 61 dd-58 2d 93 18 e9 dc bb e5
UUID is 60 00 C2 93 08 29 8d 86-42 41 35 c4 a6 d6 66 e8
Obviously those are different, so I don't see how Unitrends is finding duplicate anything.
Here is the error from Unitrends. I hope this will help to clarify the issue. I'm not sure what exactly an Instance UUID is, so maybe the extra specificity will help someone figure it out.
@vXav The output of that command does indeed show a duplicate value on the two machines that unitrends is complaining about. I wonder why this command shows different UUID's than the one I documented above. Maybe it's a different type of UUID. I believe it has more dashes as well. Anyway, now I know there IS indeed a duplicate. What now?
Thanks for your help!
If you need to change the UUID, then you need to change this in the VMX file and in the VMDK descriptor files.
There is more information about this here: http://www.derekseaman.com/2010/10/making-your-vmware-vm-uuids-unique.html
You could also try powering off the VM and cloning it to generate new UUIDs for the disks?
I hope this helps
I ran the script, but it didn't take effect on the machines that are still powered on. I went and checked the UUID's it did change (those that were powered off) and they seem to have set the uuid.bios value in the corresponding vmx file. I set a new value in one of my vmx files manually yesterday, and it still gives this error. I first powered off the file server, then downloaded, edited, and then replaced the vmx file after changing the uuid.bios line. I powered up the machine again and I get the same error.
You mentioned a vmdk descriptor file which needs to be modified, but I'm not aware of that file. What is it called and what needs to be changed?
What do you mean register it on another host? I've only got one ESXi host at that site.
Thanks for the replies
vmdk descriptor file which needs to be modified, but I'm not aware of that file. What is it called and what needs to be changed?
The descriptor file is meta-data for the VMDK disk. It's name is usually VM-Name.vmdk it is human readable and contains a line for the UUID as does the VMX file. The data for a VMDK is called VM-Name-flat.vmdk this is not human readable.
Once you change a UUID, you can verify that it has been completed correctly by running:
# vmkfstools -e filename.vmdk
For a complete chain, you see output similar to:
Disk chain is consistent
For a broken chain, you see a summary of the snapshot chain and then an output similar to:
Disk chain is not consistent : The parent virtual disk has been modified since the child was created. The content ID of the parent virtual disk does not match the corresponding parent content ID in the child (18)