On Tue, Jul 19, 2022 at 9:12 PM Wesley Dillingham <w...@wesdillingham.com> 
wrote:
>
>
> from ceph.conf:
>
> mon_host = 10.26.42.172,10.26.42.173,10.26.42.174
>
> map command:
> rbd --id profilerbd device map win-rbd-test/originalrbdfromsnap
>
> [root@a2tlomon002 ~]# ceph mon dump
> dumped monmap epoch 44
> epoch 44
> fsid 227623f8-b67e-4168-8a15-2ff2a4a68567
> last_changed 2022-05-18 15:35:39.385763
> created 2016-08-09 10:02:28.325333
> min_mon_release 14 (nautilus)
> 0: [v2:10.26.42.173:3300/0,v1:10.26.42.173:6789/0] mon.a2tlomon003
> 1: v2:10.26.42.174:3300/0 mon.a2tlomon004
> 2: [v2:10.26.42.172:3300/0,v1:10.26.42.172:6789/0] mon.a2tlomon002
>
> Looks like something is up with mon:1 only listening on v2 addr not sure if 
> thats the root cause but seems likely. Though would think the map should 
> still be able to have success.

Yes, this is the root cause.  Theoretically the kernel client could
ignore it and attempt to proceed but it doesn't, on purpose.  This is
a clear configuration/user error which is better fixed than worked
around.

You need to either amend mon1 addresses or tell the kernel client to
use v2 addresses with e.g. "rbd device map -o ms_mode=prefer-crc ...".

Thanks,

                Ilya
_______________________________________________
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

Reply via email to