Thanks. Interestingly the older kernel did not have a problem with it but the newer kernel does. Respectfully, *Wes Dillingham* wes@xxxxxxxxxxxxxxxxx LinkedIn <http://www.linkedin.com/in/wesleydillingham> On Tue, Jul 19, 2022 at 3:35 PM Ilya Dryomov <idryomov@xxxxxxxxx> wrote: > 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
 |