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