Changing a VM’s Recovery VRA When a Host Crashes or Prior to Recovery Site Maintenance

Yesterday, we had one host in our recovery site PSOD, and that caused all kinds of errors in Zerto, primarily related to VPGs.  In our case, this particular host had both inbound and outbound VPGs attached to it’s VRA, and we were unable to edit (edit button in VPG view was grayed out, along with the “Edit VPG” link when clicking in to the VPG) any of them to recover from the host failure.  Previously when this would happen, we would just delete the VPG(s) and recreate it/them, preserving the disk files as pre-seeded data.

When you have a few of these to re-do, it’s not a big deal, however, when you have 10 or more, it quickly becomes a problem.

One thing that I discovered that I didn’t know was in the product, is that if you click in to the VRA associated with the failed host, and go do the MORE link, there’s an option in there to “Change Recovery VRA.”  This option will allow you to tell Zerto that anything related to this VRA should now be pointed at X. Once I did that, I was able to then edit the VPGs.  I needed to edit the VPGs that were outbound, because they were actually reverse-protected workloads that were missing some configuration details (NIC settings and/or Journal datastore).

Additionally – If you are planning on host maintenance in the recovery site (replacing a host(s), patching, etc…), these steps should be taken prior to taking the host and VRA down to ensure non-disrupted protection.

 

Here’s how:

  1. Log on to the Zerto UI.
  2. Once logged on, click on the Setup tab.
  3. In the “VRA Name” column, locate the VRA associated with the failed host, and then click the link (name of VRA) to open the VRA in a new tab in the UI.
  4. Click on the tab at the top that contains VRA: Z-VRA-[hostName].
  5. Once you’re looking at the VRA page, click on the MORE link.
  6. From the MORE menu, click Change VM Recovery VRA.
  7. In the Change VM Recovery VRA dialog, check the box beside the VPG/VM, then select a replacement host. Once all VPGs have been udpated, click Save.

Once you’ve saved your settings, validate that the VPG can be edited, and/or is once again replicating.

 

Share This:

6 thoughts to “Changing a VM’s Recovery VRA When a Host Crashes or Prior to Recovery Site Maintenance”

  1. This ‘Change to VRA’ option will be nice if it is not grayed out. In our case, this is not possible to change between VRAs due to its current status.

    Thank you for this solution you have mentioned but we are not there yet.

  2. Luis – what version of ZVR are you running, and have you tried clearing your browser cache and retrying? I take it you’re trying to perform this due to a host issue?

  3. Same with Luis, we have problem with host not respond, when i tried to change host with step above, i cant press “save” because zvra still have status power on.
    I cant do reconnect or power off zvra because their gray out. So i tried to power off host, but unfortunately that the zvra still power on.
    Any suggest?

    1. Hi Devia,

      Did your ESXi host become isolated? If that’s the case, you can try connecting to the console and restarting the services to see if it will become manageable again. If that’s due to the RAMDisk filling up because you are booting from SD card or USB and don’t have a scratchdisk configured, you’ll need to power off VMs manually via the DCUI (direct console UI). If you can get to the DCUI and power off the VRA, you can then try via the Zerto UI again, and if it’s still grayed out, please open a support ticket. I tested PSOD in my lab by running the command on this site: http://www.virtualizationguru.org/2013/07/command-to-force-esxi-to-psod-purple.html, and am still able to change the VRA even if the host is sitting at a PSOD.

  4. If a host is PSOD- IE it has crashed, the VRAs on the host will remain in the Powered On state when viewed in vCenter GUI, however they are really “dead” since they always live on the relative host.

    In this case, if the VRA is not accessible, there is no way to use the “Evacuate Host” or “Change VM Recovery VRA” options as these need to be able to remove the replicated vmdks from the recovery VRA on the failed host and move them to another host, something which is NOT possible when the host and VRA are down.

Leave a Reply to Devia Cancel reply

Your email address will not be published. Required fields are marked *