Description of problem: ----------------------- Geo-replication session was established with IPV6 hostnames, but when starting the geo-rep session, it never starts Version-Release number of selected component (if applicable): --------------------------------------------------------------- RHHI-V 1.8 RHGS 3.5.2 ( glusterfs-6.0-37.1.el8rhgs ) glusterfs-geo-replication-6.0-37.1.el8rhgs How reproducible: ----------------- Always Steps to Reproduce: ------------------- 1. Establish the geo-rep session from master to slave, both master and slave are using IPV6, but no IPv4. 2. Start the session Actual results: ----------------- Session fails to start, remains in geo-rep session remains created state Expected results: ----------------- Session should start sync from master to slave Additional info:
Patch https://review.gluster.org/#/c/glusterfs/+/24706/ is posted upstream
This issue is not a blocker for RHHI-V 1.8 This issue is seen only with the direct usage of IPV6 addresses and not with IPV6 hostnames RHHI-V highly recommends usage of IPV6 hostnames and not direct IPV6 addresses. So this issue can be tracked with RHGS 3.5.3
Tested with glusterfs-6.0-46.el8rhgs and found that files are synced to the secondary volume, when the geo-rep session is configured with IPv4 addresses Here are the much detailed information about the test 0. Created the primary cluster with FQDNs and enabled cluster.enable-shared-storage that creates the gluster-shared-storage volume for meta operations 1. Created the source/primary volume with FQDN on the primary cluster 2. Created the destination/secondary cluster and volume with IPv4 3. Mounted the primary volume on the primary cluster, and created few files on the fuse mounted volume 4. Created the geo-rep session from primary to secondary volume using IPs on the secondary host 5. Configured the geo-rep session to make use of meta volume 6. Started the session 7. Followed up the geo-rep status to make sure, that the sync is completed 8. Mounted the volume on the secondary cluster, and compared the sha256sum on the primary volume and that matched