• This topic has 3 replies, 2 voices, and was last updated February 22, 2018 by Chris S.

Discard changes from a live failover test or move.

  • Anish K
    February 22, 2018 04:19:08 PM

    We are replicating two sites, vmware to vmware.  Is there a way to failover or move a VPG live, then after the test is over discard the changes and fail back?  My first choice was going to be to do a test instead of a live failover, but our environment isn’t going to allow us to use the test feature of Zerto.  We cannot have duplicate MAC addresses in our environment at all, even between the protected and recovery sites.  We are also not changing IP addresses, or MAC addresses during the failover.  I thought I could try a combination of disabling AutoCommit, and reverse protection, but I can’t quite figure out how I would do this when testing it out.  Thanks in advance!

    Chris S
    February 22, 2018 05:25:46 PM

    If you really want to discard any changes during a live failover, this is easy. Remember, your VM will be running and IO will be processed, so ensure that’s actually what you want to do.

    All you need to do is perform a failover (or use the MOVE option for a graceful transition) and ensure the auto-commit policy is set to “do not auto-commit.” Ensure that the commit is set to manual. Then do your tests, and when you’re done, instead of committing, you’ll press the “roll-back” button, and everything will go right back the way it was in production, before you failed over. Any IO that happened during this process will be lost. Replication will pick back up again and you’ll continue to be protected.

    This is actually a designed feature. Zerto allows you to have thousands of check points to choose from when you failover. If you failover and the checkpoint you chose doesn’t work, you rollback and try another checkpoint. No different than what you want to use it for really.

    Anish K
    February 22, 2018 07:09:07 PM

    I think this still has the original protected VM in place, though powered off.  At the same time keeping the newly created VM powered up at the recovery site.  Our issues is our SDN runs into conflicts with duplicate MAC addresses in vcenter, even across sites.

    Chris S
    February 22, 2018 08:06:07 PM

    It shouldn’t. The source VM should be powered off and removed from the vcenter inventory. Only 1 version of the VM stays in play during the process. When you revert, same operation. VM is powered off and removed from inventory, then the VM is added to inventory on the other side and turned on.

The forum ‘General Discussion’ is closed to new topics and replies.