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 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. The workaround is to 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." The workaround is to click the “Resolve Configure Issue” button or execute the Resolve-ClusterIssue cmdlet in AVS. (DRBC4985)
If the VAIO daemon becomes non-operational (very uncommon), vCenter does not report the condition. This issue can be detected from the VM logs. The workaround is to 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. The workaround is to manually resize the DRVA replication log disk then reboot the DRVA. This behavior will be enhanced in future versions. (DRBC5782, DRBC7414)
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. The workaround is to restart the CIM service on the affected host. (DRBC7296, DRBC7460, DRBC7311, DRBC7455)
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.
If a plugin not belonging to JetStream DR is using the CIM service, there is a chance that CIM service may restart frequently. This is a known Broadcom issue. Note that JetStream DR does not use CIM service starting with vSphere 8.0. (DRBC9087)
Under some conditions it is possible for extremely high datastore back-end loads (BUSY condition returned to IOFilter) to cause the garbage collection database to stall resulting in excessive garbage growth. The workaround is to gracefully restart the respective DRVA. (JSDRAVS91)
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. (DRBC6680)
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. (DRBC4190)
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. The workaround is to reset the appliance. (DRBC7632)
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. (DRBC7670)
Under rare conditions a cluster may start showing the status of all hosts as '-' in the JetStream cluster status and 'N/A' in the Health View 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. The workaround is to restart the vme2 service on the MSA to restore communication with hosts. (JSDRAVS123)
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. The workaround is to power on the VM and then try to start protection again. (DRBC7745)
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. (DRBC7312)
If VASA storage providers appear offline, there may be start/stop protection or recovery failures with JetStream DR. This is a known VMware issue. Refer to workarounds described in the articles: Certain IOFIlter Providers are showing as offline [ https://knowledge.broadcom.com/external/article?legacyId=76633 ] and Resolving IOFilter disconnected/offline post upgrade to 7.0u2 [ https://knowledge.broadcom.com/external/article?legacyId=88159 ]. (DRBC8027)
Stopping protection of a VM with suspended protection does not clean garbage from deleted disks. Contact JetStream support for guidance on cleaning garbage. (JSDRAVS229)
Suspending the writeback cache may lead to the protected VM crashing. If this happens, the VM should be manually powered on. (DRBC6734)
When Trim operation is done of a large VM (> 1TB), there is a chance the VM may hang. (DRBC8672)
If there is a JetStream combined policy that was manually created and not deleted from the previous cluster configuration, the current configuration may display the error "vCenter missing JetStream VM protection policy." The workaround is to delete the stale combined policy and resolve configure issue. (DRBC8730)
The maximum number of disks per VM that can be recovered by JetStream DR is 60. This is due to a known issue in RVMs not being able to assign more than 15 disks per controller. This limitation will be addressed in a future release. (DRBC8827)
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)
Under rare circumstances, deletion of an invalid RL section fails with the error message "Replication log section not found on DR Virtual Appliance." The workaround is to switch tabs and come back to the tab and reattempt deletion. (DRBC9213)
For a site where there are active CFO's running, after upgrading JetStream DR, all Domains may show a banner indicating "RVM upgrade is available." RVMs do not exist for Domains where recovery is not running. To resolve this issue, upgrade the RVMs of the CFO Domains and ignore the banner on the other Domains. Once the RVMs of all CFO Domains have been upgraded, the banner on the other Domains no longer appear. (DRBC8693)