• Taking a snapshot on a restored offline VM immediately after Failback or Failover may fail. This error is transient and will self-correct. Wait a period of time then retry taking a snapshot. (DRBC-6824)
  • Snapshots of protected VMs will fail while their respective DRVA appliance or replication log are down. (DRBC-6529)
  • Logical consistency-based I/O errors may appear for VMs running on a snapshot. This is a known VMware issue fixed in ESXi 7.0 u3f. For more information refer to:  VMware ESXi 7.0 Update 3f Release Notes [https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-70u3f-release-notes.html]. (DRBC-6767)
  • If the DRVA or replication log is not available, vMotion for an affected VM will fail with timeout. It may take several minutes depending on the number of disks involved. Eventually, the VM will become responsive again on the source host. (DRBC-7046)
  • In comparison with previous versions, in JetDR 4.2 revert to a VM snapshot does not cancel protection but restarts VM protection from scratch. Disks content is re-replicated completely after revert. In a rare situation of reverting to a quiesced snapshot that was taken under JetDR 4.1.x, VM replication gets “frozen”. Data content in the cloud remains in pre-revert state. UI is stuck with background data size at 0. The workaround is to restart the protection for the affected VM. (DRBC-7509)
  • When reverting to the snapshot prior to disk being removed from the protected VM, automatic protection of the restored disk would not be started. The workaround is to remove the snapshots and stop & start protection. (DRBC-7463)
  • If DRVA replication log is down or DRVA is not accessible, then a VM protected on that DRVA may become powered off after svMotion attempt, because of svMotion internal timeout. (DRBC-7409)