• This topic has 2 replies, 2 voices, and was last updated March 13, 2019 by Usman F.

Changing UUID breaks VPG

  • Erik B
    September 11, 2018 08:04:55 PM

    As we are working within our new Zerto environment, we ran across a workload that required (for licensing) that the UUID of the VMs do not change when being orchestrated for testing recovery.

    We have found a solution to this problem by altering the source VMs to include the option “uuid.action = “keep” that will hopefully be replicated. We’re still testing that specific part.

    What happened, though, was when we were testing on a few already orchestrated VMs in Testing Failover, we didn’t think about the fact that changing the UUID on a VM Zerto had orchestrated would cause a problem. It did, and now the 4 VMs are running and working as expected from the VMware side, but Zerto is alerting “Recovery disk and its virtual machine are missing.” Entirely expected, as that’s what we did. Unfortunately, we didn’t log the original UUIDs before changing them.

    Any chance anyone knows where the expected UUID for a VM in testing recovery might be stored or accessible? Obiviously Zerto has it somewhere to be alerting on it.

    If we can’t find that, does anyone have pointers about how we can do a cleanup from the VMware side when we spin these testing failover VMs down? I am assuming since Zerto has lost its knowledge of the running VMs, it will not be able to properly stop the test and clean up the environment behind it.

    Erik B
    September 17, 2018 04:41:09 PM

    We were able to extract the original UUIDs from one of the vmware-#.logs on the hosts. We edited the vmx files for the affected VMs and rebooted them. This allowed Zerto to properly see the VMs again. To be sure, we spun the “testing recovery” VMs down and verified that all of the associated VMs and files were properly taken care of.

    After spinning them back up into “testing recovery” again, we were still seeing some issues, so I individually removed and re-instated the replication for each of the four VMs. That seems to have taken care of the stability issues.

    We also made sure to set the UUID matching setting at the top level of the Zerto configuration (instead of modifying the source VMs). That specifically fixed our licensing issues on these specific VMs

    Usman F
    March 13, 2019 11:17:36 AM

    Hi Erik,

    Just to confirm, are you talking about the “For incoming replication, copy the BIOS UUID of the protected VM to the recovered VM” global setting within ZVM and did enabling this option solve your issue with licensing\re-activation? Also, did you try this with a test failover or live failover of the VMs?

    I am in  a similar situation and having Windows activation issues after failover and was thinking of using the uuid keep option in vmx files.

    Thanks

    Usman

     

You must be logged in to create new topics. Click here to login