Jump to content
Welcome to our new Citrix community!
  • 0

VM gets automatically replaced in catalog with clone

Franc van de Westelaken




I noticed probably a bug in the delivery controller. We use Veeam backup and replication for backing up our environment. Veeam also has the option to verify the backups (sure backup functionality). To do this it temporarily adds the VM from the backup completely isolated from the production environment to the vSphere environment and starts the VM up to do some verifications. Once it's finished it deletes this VM again.


However, Citrix Delivery Controller seems to have an issue with this. When the VM is added to the vSphere environment, the UUID of the VM is the same, since this is the original VM from the backup. The same thing happens when you clone a VM. This one also gets the same UUID. When this situation exists, one of the services running on the delivery controller replaces the original VM in the machine catalog with the temporary VM. The end-result of this is that you end-up with a non-working machine catalog, since the temporary VM is being deleted when verification is completed. Also, the delivery controller shouldn't touch the catalog at all.


Further investigation shows that this issue is caused by the fact that the Citrix Broker uses the extensiondata.config.uuid as the unique identified. It stores this value in the HostedMachineID of the broker database. Since the temporary VM is a clone of the original VM, it has the same extensiondata.config.uuid. Apparently there's some re-scanning process in the background running on the broker that for some reason replaces the VM in the catalog without any message or notification.


I opened a case with citrix already, but anyone experienced the same?



Link to comment

2 answers to this question

Recommended Posts

  • 0



I don’t think it’s a Veeam issue. Same happens when you clone a XenApp VM from vCenter itself.  The Citrix broker uses the bios UUID instead of the MoREFID from vSphere to identify the Vm in the catalogs. Since the bios UUID is not always unique, this causes havoc.


veeam doesn’t touch the original vms.


The issue also occurs when you use Veeam to replicate production to a test environment within the same vCenter. The Citrix broker then also replaces the VM with the cloned one without any notice. After the replication job I know run a PowerShell script to change the bios UUID to a unique value, so the issue doesn’t occur any more after a replication job.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...