Cannot Open Journal Disk During RTR Failover
Product version: 11.1
Last modified: 7 October 2025
Problem
When performing a Real-Time Replication Failover or restarting the stopped Real-Time Replication job, the job may fail with the following error message in the Journal Service logs:
JournalDriver_OpenRemoteJournal - Open JournalFile 14009, FrameFile 0, IndexFile 0, BlockFile 0 - Failed
[2025-09-11 12:52:53.025Z] - _TargetCommandHandler_GetJournalRecoveryPoint -
JournalMngr_GetJournalRecoveryPoints: (192.168.200.254, vm-388286) - Failed
[2025-09-11 12:52:53.025Z] - TargetCommandHandler_ProcessJSONRequest - sock 9 BEGIN RESPONSE:
{"command":"get_journal_recovery_point","error": {"error_code":12,"error_message":"Failed to open journal disk"}} - END RESPONSE
Background
This issue occurs when the Target Transporter cannot resolve the target ESXi host’s name or connect to it via the required network port.
For Real-Time Replication, the Journal Service installed on the Target Transporter uses port 902 to access detached journal disks via the LAN transport mode when the job is stopped and later resumed.
Additionally, during the failover or replication operations, the target Transporter may need to access target ESXi hosts by hostname. If hostname resolution fails, disk access errors may occur.
Solution
To resolve the issue, follow these steps:
-
Ensure that port 902 is open between the Target Transporter and ESXi hosts.
-
Check the VMware firewall or intermediate network devices for blocked connections.
-
Ensure the Transporter can resolve all ESXi hostnames involved in replication. If not, add an IP-to-hostname entry in the local hosts file in the target Transporter:
-
Edit the /etc/hosts file and add the ESXi host entry, for example:
192.168.200.241 esx-nbg2-1
-
Verify the connection by running:
ping esx-nbg2-1
-
-
After correcting the network and hostname configurations, restart the failed job. If the job resumes successfully, the Transporter will need to use LAN mode to access journal disks.