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.
MSA GUI has minor problems when used with Firefox browser. If failover/failback runbook is configured with very long names, truncated names may appear in the GUI. Additionally, some of the GUI elements may not render perfectly. However, this will not cause problems with functionality of the product. (DRBC-4075)
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.
In rare cases, deleting a protected domain may fail with the error message “Internal server error occurred”. The workaround is to reboot the DRVA and then try deleting the protected domain. (DRBC-6901)
After upgrading JetStream DR from 4.1.12 to 4.1.14, the old 4.1.12 folders for DRVA and RocVA are left over at the MSA. These folders should be deleted or moved to a different location before upgrading to subsequent versions. (DRBC-7301)
If there are prolonged datastore disruptions in the primary site, the background data might not get replicated completely. DRVA should be gracefully rebooted to continue background replication in such cases. (DRBC-7256)
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 or recovery must be restarted on a bigger replication log disk. In such cases JetStream proposes to allocate disk capacity such that free space size would match the size of the whole domain (double the space allocated for domain). (DRBC-5782)
Under rare conditions, CIM server could enter a failed state. It is partially related to undisclosed timeout values specific to ESX CIM server builds. 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)
In releases 4.1.14 and 4.1.16, when DRVA appliance is gracefully rebooted - manually or automatically as a part of DRVA upgrade, it might generate some amount of unneeded background - 8 GB / disk + 1..32 GB / domain approximately. The workaround is to log in to DRVA appliance and execute the command DRVAPID=$(pidof drva_prog) ; sudo kill ${DRVAPID}; while sudo kill -0 ${DRVAPID} 2>/dev/null ; do sleep 1; done; echo "complete" before rebooting DRVA. In the DRVA upgrade case it is also necessary to restart DRVA service with the command sudo systemctl restart drva before requesting upgrade from the JetStream UI. The issue is fixed in release 4.1.18. We recommend to apply this workaround when upgrading mentioned versions to 4.1.18 or higher.
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)