In some uncommon error scenarios (e.g., MSA unable to contact a DRVA) a failback task may become stuck and display a generic error message without an obvious meaning to the user. In such case, contact JetStream Software for assistance. (DRBC4305)
While running a test failover runbook in manual mode, the runbook groups dialog box may show an empty group of independent protected VMs. This can be safely ignored. (DRBC4694)
If the protected site goes down, the "Planned Failover" option will still appear in the GUI for all forms of failover. This option is only valid for “graceful” failover cases and will fail if planned failover is selected; however, the "Force Failover" option is appropriate and can be used successfully. (DRBC5139)
If recovery fails or is cancelled and the MSA is unable to remove some representation VMs (RVMs), it might not automatically delete other related RVMs created for the same Domain. It is OK to manually delete all RVMs no longer needed. (DRBC7178)
If a DRVA is restarted non-gracefully after failover or failback on the current site awaiting to start recovery, the resume continuous rehydration function may fail. (This is an uncommon occurrence.) (DRBC7377)
If the source site is not properly cleaned up after a forced failover, it is possible the DRVA can become inaccessible requiring a hard reset. To avoid this, clean up by removing the policy from stale VMs and delete the stale protection Domain from the DRVA. (JSDRAVS187)
Continuous failover, test failover, and failback may incorrectly indicate “Invalid operation” after successful completion. This is a corner case and the actual process will have completed without errors. This error can be safely ignored. (DRBC8156)
In some cases when there is no IO activity on a failover site with a total protected size less than 8GB, the regular failback operation may appear to hang indefinitely. A similar condition may also occur for continuous failback regardless of the total protected size. The workaround is to click the “Stop Remote site” button. (DRBC8472)
Failback becomes stuck while taking ownership of the Domain. This can happen when the Domain on the primary site still exists and forced failover is performed. The workaround is to restart the DRVA, delete the Domain and then re-run failback. Please contact support to perform required operations. (DRBC8399)
It is advisable not to terminate the failback task after the Domain ownership is transferred. If done so, the Domain can enter a bad state. The workaround is to do a restore to the same site. (DRBC8713)
If secure boot is enabled on a protected VM, the VM might not boot after a TFO with CFO. The workaround is to copy the .nvram file from this VM on the protected site to the TVM and boot. Regular recovery after CFO is expected to succeed. (DRBC8667)
If there are more than 180 vDisks in a Domain that has VMs protected in writeback mode, then any rehydration of the Domain will switch the VMs to writethrough mode. (DRBC8735)
If there is a RCR running on a site older than 4.3, then upgrading that site to 4.3 or later will lead to a wrong rehydration state. RCR should be completed before the upgrade. (DRBC8738)
If a protected VM uses the E1000 network adapter and it occupies the first PCI slot (32); after TFO with CFO, the test VM can come up with a different network interface. Due to this condition, the test VM may not get an IP. (DRBC8916)
After re-protecting CFO VMs, a banner indicating "Representation VM not found" may appear. The workaround is to restart the Tomcat service. (DRB8938)
When the "Cleanup" button is clicked from the "Show Kept VMs" window, the MSA will delete the "Kept VMs" even if the VMs were intentionally registered. The workaround is to register the VMs in a folder different from the original one, to prevent the VMs from being deleted. (DRBC9256)
When running a test failover over CFO, under some conditions the representation VMs may end up with unconsolidated disks. The workaround is to manually consolidate any affected disks. (DRBC9292)
A Health View alert may be triggered for a Domain while it is being failed back and this condition persists throughout the course of the failback operation. This occurs when the Domain state is UNKNOWN and the DRVA state is DRVA_EMPTY. The alert and the statuses can be safely ignored. (DRBC8894)
VMware changed the algorithm for assigning PCI slot IDs in vSphere 8. Because of this, recovered VMs may not be able to apply ReIP options. (DRBC9228)