On Tue, Jul 19, 2022 at 9:12 PM Wesley Dillingham <wes@xxxxxxxxxxxxxxxxx> 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@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx
