When deploying the JetStream DR OVA to vCenter Server 7.0 U2 or higher, a warning will be displayed indicating the certificate is untrusted. This is not an issue with the OVA certificate signing. Rather, VMware has changed the cedertificate validation process to only approve certificates signed by Authorities in the vCenter's Trusted Root store. It is recommended to install "Sectigo Public Code Signing CA R36”, “SectigoPublicCodeSigningRootR46_AAA", and "AAA Certificate Services (AddTrust)” from the Comodo Knowledge Base. Details about using third-party certificates are described in the VMware article: Add a Trusted Root Certificate to the Certificate Store [https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.authentication.doc/GUID-B635BDD9-4F8A-4FD8-A4FE-7526272FC87D.html]. After adding the trusted root certificate, re-install JetStream DR software.
If a protected VM uses UEFI boot with the boot loader in a custom location, the VM will power on, but the OS will not boot automatically after recovery. Workaround: Either change the boot sequence before starting protection or manually start the OS after recovery.
If there is a need to restart the MSA, it is recommended to contact JetStream Software for guidance.
In rare cases, during the installation of JetStream DR software, cluster configuration may fail with the error message: "An unexpected error occurred on the remote system. null. No VASA Provider for schema namespace (jetdr) found." Workaround: Click the “Resolve Configure Issue” button or execute the Resolve-ClusterIssue cmdlet in AVS. (DRBC-4985)
If the VAIO daemon becomes non-operational (very uncommon), vCenter does not report the condition. This issue can be detected from the VM logs. Workaround: Restart the daemon using the Restart-JetDRDaemon cmdlet.
If free or reserved space of the DRVA replication log disk become depleted it will not be possible to continue replication or recovery because the DRVA will be unable to resize metaspace. Workaround: Manually resize the DRVA replication log disk then reboot the DRVA. This behavior will be enhanced in future versions. (DRBC-5782, DRBC-7414)
Under rare conditions, the CIM server may enter a failed state. It can be related to undisclosed timeout values specific to ESX CIM server builds or internal memory management in the CIM server. If this happens it will not be possible to replicate background data for offline VMs or perform start/stop protection for VMs on a specific host. Workaround: Restart the CIM service on the affected host. (DRBC-7296, DRBC-7460, DRBC-7311, DRBC-7455)
There is a known issue with the HPE SmartArray CIM module, leading to CIM service restarts. JetStream DR cannot operate when the CIM service is not available. A possible workaround is described in the article: https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=a00117054en_us. Contact the hardware vendor for further recommendations.
Under some conditions it is possible for extremely high datastore back-end loads (BUSY condition returned to IO Filter) to cause the garbage collection database to stall resulting in excessive garbage growth. Workaround: Gracefully restart the respective DRVA. (JSDRAVS-91)
Older Linux versions contain a flaw that prevent protected VMs with PVSCSI adapters from running. (E.g., 4.14 kernels are affected until patch 261.) The workaround is to switch to the LSI Logic adapter or upgrade the Linux kernel to a newer version without the fault. (DRBC-6680)
Under some conditions, starting protection of a VM in writeback mode can result in some protected disks failing to start WB mode. If protection of a VM does not fail, then it is OK to continue running and WB mode can be re-established by taking/removing a snapshot or by performing vMotion of the protected VM. If protection fails to start, it is OK to retry. This is an internal VMware issue and a DCPN 00098282 has been raised. (DRBC-4190)
Under some conditions, the JetStream DR appliance VM (DRVA, RocVA, RVM) may not boot successfully. This is a known OS problem – refer to: https://access.redhat.com/discussions/3536621. Workaround: Reset the appliance. (DRBC-7632)
The ‘Known Remaining’ field in the CFO/FO/FB UI will be blank until recovery finishes total objects computation. The duration of this condition depends on the object server response time and total number of objects present in the container for the domain. This is only a reporting issue and does not affect the recovery progression. (DRBC-7670)
Under rare conditions a cluster may start showing the status of all hosts as '-' in the JetStream cluster status and 'N/A' in the HealthView digest. Possible consequences are VM protection on any host can fail, or some VMs will not be able to connect to the DRVA for data replication. Workaround: Restart the vme2 service on the MSA to restore communication with hosts. (JSDRAVS-123)
Starting protection for a powered-off virtual machine with disks more than 32 TiB in size may fail. The large volume size could cause a timeout error of the VMware API scan. Workaround: Power on the VM and then try to start protection again. (DRBC-7745)
If the JetStream daemon is down on two hosts of a configured cluster, Storage vMotion of a protected VM between these two hosts can fail. (DRBC-7312)
Stopping protection of a VM with suspended protection does not clean garbage from deleted disks. Contact JetStream support for guidance on cleaning garbage. (JSDRAVS-229)