[ceph-users] Re: rh8 krbd mapping causes no match of type 1 in addrvec problem decoding monmap, -2

2022-07-20 Thread Ilya Dryomov 
On Tue, Jul 19, 2022 at 9:55 PM Wesley Dillingham  
wrote:
>
>
> Thanks.
>
> Interestingly the older kernel did not have a problem with it but the newer 
> kernel does.

The older kernel can't communicate via v2 protocol so it doesn't (need
to) distinguish v1 and v2 addresses.

Thanks,

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

[ceph-users] Re: rh8 krbd mapping causes no match of type 1 in addrvec problem decoding monmap, -2

2022-07-19 Thread Wesley Dillingham 
Thanks.

Interestingly the older kernel did not have a problem with it but the newer
kernel does.


Respectfully,

*Wes Dillingham*
w...@wesdillingham.com
LinkedIn 


On Tue, Jul 19, 2022 at 3:35 PM Ilya Dryomov  wrote:

> On Tue, Jul 19, 2022 at 9:12 PM Wesley Dillingham 
> 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

[ceph-users] Re: rh8 krbd mapping causes no match of type 1 in addrvec problem decoding monmap, -2

2022-07-19 Thread Ilya Dryomov 
On Tue, Jul 19, 2022 at 9:12 PM Wesley Dillingham  
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

[ceph-users] Re: rh8 krbd mapping causes no match of type 1 in addrvec problem decoding monmap, -2

2022-07-19 Thread Wesley Dillingham 
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.

As a note i tried with 16.2.9 client as well and it also failed in the same
manner.






Respectfully,

*Wes Dillingham*
w...@wesdillingham.com
LinkedIn 


On Tue, Jul 19, 2022 at 12:51 PM Ilya Dryomov  wrote:

> On Tue, Jul 19, 2022 at 5:01 PM Wesley Dillingham 
> wrote:
> >
> > I have a strange error when trying to map via krdb on a RH (alma8)
> release
> > / kernel 4.18.0-372.13.1.el8_6.x86_64 using ceph client version 14.2.22
> > (cluster is 14.2.16)
> >
> > the rbd map causes the following error in dmesg:
> >
> > [Tue Jul 19 07:45:00 2022] libceph: no match of type 1 in addrvec
> > [Tue Jul 19 07:45:00 2022] libceph: problem decoding monmap, -2
> >
> > I am able to map this rbd to a cent7 / 3.10.0-1160.71.1.el7.x86_64
> machine
> > using the same client and commands.
> >
> > Of note, on the RH8 node I can fetch info about the rbd and list rbds in
> > the pool check ceph status etc. It seems purely limited to the mapping of
> > the RBD:
> >
> > Info about the RBD:
> >
> > [root@alma8rbdtest ~]# rbd --id profilerbd info
> > win-rbd-test/originalrbdfromsnap
> > rbd image 'originalrbdfromsnap':
> > size 5 GiB in 1280 objects
> > order 22 (4 MiB objects)
> > snapshot_count: 0
> > id: 2c5f465fa134c0
> > block_name_prefix: rbd_data.2c5f465fa134c0
> > format: 2
> > features: layering, exclusive-lock
> > op_features:
> > flags:
> > create_timestamp: Mon Jul 18 13:58:39 2022
> > access_timestamp: Mon Jul 18 13:58:39 2022
> > modify_timestamp: Mon Jul 18 13:58:39 2022
> >
> > anybody seen something like this
>
> Hi Wesley,
>
> Could you please provide:
>
> - full "rbd map" ("rbd device map") command
>
> - "mon host = XYZ" line from ceph.conf file
>
> - "ceph mon dump" output
>
> Thanks,
>
> Ilya
>
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

[ceph-users] Re: rh8 krbd mapping causes no match of type 1 in addrvec problem decoding monmap, -2

2022-07-19 Thread Ilya Dryomov 
On Tue, Jul 19, 2022 at 5:01 PM Wesley Dillingham  
wrote:
>
> I have a strange error when trying to map via krdb on a RH (alma8) release
> / kernel 4.18.0-372.13.1.el8_6.x86_64 using ceph client version 14.2.22
> (cluster is 14.2.16)
>
> the rbd map causes the following error in dmesg:
>
> [Tue Jul 19 07:45:00 2022] libceph: no match of type 1 in addrvec
> [Tue Jul 19 07:45:00 2022] libceph: problem decoding monmap, -2
>
> I am able to map this rbd to a cent7 / 3.10.0-1160.71.1.el7.x86_64 machine
> using the same client and commands.
>
> Of note, on the RH8 node I can fetch info about the rbd and list rbds in
> the pool check ceph status etc. It seems purely limited to the mapping of
> the RBD:
>
> Info about the RBD:
>
> [root@alma8rbdtest ~]# rbd --id profilerbd info
> win-rbd-test/originalrbdfromsnap
> rbd image 'originalrbdfromsnap':
> size 5 GiB in 1280 objects
> order 22 (4 MiB objects)
> snapshot_count: 0
> id: 2c5f465fa134c0
> block_name_prefix: rbd_data.2c5f465fa134c0
> format: 2
> features: layering, exclusive-lock
> op_features:
> flags:
> create_timestamp: Mon Jul 18 13:58:39 2022
> access_timestamp: Mon Jul 18 13:58:39 2022
> modify_timestamp: Mon Jul 18 13:58:39 2022
>
> anybody seen something like this

Hi Wesley,

Could you please provide:

- full "rbd map" ("rbd device map") command

- "mon host = XYZ" line from ceph.conf file

- "ceph mon dump" output

Thanks,

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

[ceph-users] Re: rh8 krbd mapping causes no match of type 1 in addrvec problem decoding monmap, -2

2022-07-19 Thread Wesley Dillingham 
Tried with rh8/14.2.16 package version and same issue.
dmesg shows the error in email subject, stdout shows: rbd: map failed:
(110) Connection timed out

Respectfully,

*Wes Dillingham*
w...@wesdillingham.com
LinkedIn 


On Tue, Jul 19, 2022 at 11:00 AM Wesley Dillingham 
wrote:

> I have a strange error when trying to map via krdb on a RH (alma8) release
> / kernel 4.18.0-372.13.1.el8_6.x86_64 using ceph client version 14.2.22
> (cluster is 14.2.16)
>
> the rbd map causes the following error in dmesg:
>
> [Tue Jul 19 07:45:00 2022] libceph: no match of type 1 in addrvec
> [Tue Jul 19 07:45:00 2022] libceph: problem decoding monmap, -2
>
> I am able to map this rbd to a cent7 / 3.10.0-1160.71.1.el7.x86_64 machine
> using the same client and commands.
>
> Of note, on the RH8 node I can fetch info about the rbd and list rbds in
> the pool check ceph status etc. It seems purely limited to the mapping of
> the RBD:
>
> Info about the RBD:
>
> [root@alma8rbdtest ~]# rbd --id profilerbd info
> win-rbd-test/originalrbdfromsnap
> rbd image 'originalrbdfromsnap':
> size 5 GiB in 1280 objects
> order 22 (4 MiB objects)
> snapshot_count: 0
> id: 2c5f465fa134c0
> block_name_prefix: rbd_data.2c5f465fa134c0
> format: 2
> features: layering, exclusive-lock
> op_features:
> flags:
> create_timestamp: Mon Jul 18 13:58:39 2022
> access_timestamp: Mon Jul 18 13:58:39 2022
> modify_timestamp: Mon Jul 18 13:58:39 2022
>
> anybody seen something like this
>
>
> Respectfully,
>
> *Wes Dillingham*
> w...@wesdillingham.com
> LinkedIn 
>
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io