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 certificate 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 Comodo Knowledgebase. Details about using third-party certificates are described in the VMware article: Add a Trusted Root Certificate to the Certificate Store. After adding the trusted root certificate, retry installing 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. To work around, either change the boot sequence before starting protection or manually start the OS after recovery.
If there is a need to restart the Management Server, 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." Click the “Resolve Configure Issue” button or execute Resolve-ClusterIssue cmdlet in AVS to resolve the problem. (DRBC-4985)
If (in very rare cases) the VAIO Daemon is not operational, vCenter does not report the condition. The Daemon issue can be detected from the VM logs. For restarting Daemons use Restart-JetDRDaemon cmdlet.
It is not possible to continue replication or recovery if the DRVA cannot resize metaspace because free and reserved space on respective replication log disk is depleted. In such cases replication log disk on DRVA must be resized manually, then DRVA rebooted. The behavior will be enhanced in future versions. (DRBC-5782)
Under rare conditions, CIM server could enter a failed state. It could be related to undisclosed timeout values specific to ESX CIM server builds, or internal memory management in CIM server. It will not be possible to replicate the background data for the offline VMs or perform start/stop protection for VMs on a specific host. Workaround: restart CIM service on the affected host. (DRBC-7296, DRBC-7460, DRBC-7311, DRBC-7455)
Under some conditions it is possible that extremely high datastore backend load (BUSY condition returned to I/O filter) will lead to GCDB stall and high garbage growth. The workaround is to gracefully restart respective DRVA. (JSDRAVS-91)
Older Linux versions contain a flaw that prevents a protected VM with pvscsi adapter from running. (E.g., 4.14 kernels are affected until patch 261.) The workaround is to switch to LSI Logic adapter or upgrade linux kernel to the one without the fault. (DRBC-6680)
Under some conditions, starting protection of a VM in WB mode would result in some protected disks failing starting WB mode. If protection of a VM does not fail, then it is OK to continue running, and WB mode could be re-established by taking/removing a snapshot or by doing a vMotion of the protected VM. If the protection start fails, it is OK to retry. It appears to be an internal VMware issue, and a DCPN 00098282 was raised. (DRBC-4190)
Under some conditions, JetDR appliance VM (DRVA, RocVA, RVM) boot will be unsuccessful. This is a known OS problem - see https://access.redhat.com/discussions/3536621. The workaround is to reset the appliance. (DRBC-7632)
‘Known Remaining’ field in the CFO/FO/FB UI will be blank until recovery finishes total objects computation. It 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)
When more than 1 disk is deleted during a powered off VM edit operation, it may result in a message "Error deleting disk. Operation failed" on vCenter. In this case some disks are removed from the VM but are not deleted. It is OK to delete them directly from the datastore afterwards. This behavior will be addressed in a future release. (DRBC-7702)
Under rare conditions a cluster may start showing the status of all hosts as '-' in JetStream cluster status and 'N/A' in HealthView digest. Possible consequences may be that VM protection on any host could fail, or some VMs will not be able to connect to the DRVA for data replication. Restart the vme2 service on the MSA to restore communication with hosts. (JSDRAVS-123)