The ESXi host log (iofilterd-emcjiraf.log) contains the error log messages as shown below:
2019-08-07T11:20:45Z iofilterd-emcjiraf[68109]: jiraf_receive_msg: unknown cmd type 2019-08-07T11:21:04Z iofilterd-emcjiraf[68109]: jiraf_receive_msg: unknown cmd type 2019-08-07T11:21:04Z iofilterd-emcjiraf[68109]: jiraf_receive_msg: unknown cmd type 2019-08-07T11:21:04Z iofilterd-emcjiraf[68109]: jiraf_receive_msg: unknown cmd type
NOTE:The preceding log excerpts are only examples.Date,time and environmental variables may vary depending on your environment.
Environment
VMware vSphere 7.x
VMware vSphere 8.x
Cause
RecoverPoint IO-filter daemon is single threaded.
A deadlock could occur, where the IO filter daemon is stuck in a vSocket receive, because an unknown command type was received from one of the Recover Point Appliance(RPA) VMs. In this case, no communication would happen until the deadlock was resolved.
The second issue was that the IO filter daemon was scanning datastores for new files - again in the single thread of the daemon. This scanning would occur periodically (every 30 seconds appeared to be the default setting), and nothing else would happen during this scan. These scans could take several minutes, if access to datastores was slow, and thereby causing vSocket timeouts in the RP appliance VMs, since the IO filter daemon would not process vSocket communication during the scans.
Resolution
This is not a VMware issue.
Workaround:
Contact DellEMC support to implement the below workaround.
To change vSocket timeout values in EMC RP iofilter deamon:
t_JIRAFvSocketTimeoutSecs - change from 10 to 30 [how long RP waited for the vSocket communication]
t_SocketIOProviderDeadlockConfig - change the value to 35 [how long before a dedlock was declared ]
Disclaimer: VMware is not responsible for the reliability of any data, opinions, advice or statements made on third-party websites. Inclusion of such links does not imply that VMware endorses, recommends or accepts any responsibility for the content of such sites.