Search results

I confirm that the firewall was responsible of this issue

Hum... Firewall on the new node seems to have a bad setup. I'm monitoring the new setup And will add more logs anywy to be sure.

thanks, I'll check this ASAP

Hi @vch @feisal Do you have any more information ? Regards

and all the logs between the osd start and stop : osd.4 pg_epoch: 34842 pg[2.1d7( v 34623'14234948 (34483'14233294,34623'14234948] lb MIN local-lis/les=34622/34623 n=0 ec=48/48 lis/c=34622/34620 les/c/f=34623/34621/0 sis=34838) [7,1] r=-1 lpr=34842 pi=[33949,34838)/1 crt=34623'14234948 lcod 0'0...

and more lis/c=34622/34620 les/c/f=34623/34621/0 sis=34629) [6,0]/[6,1] r=-1 lpr=34831 pi=[34314,34629)/1 crt=34623'14369446 lcod 0'0 mlcod 0'0 remapped NOTIFY mbc={}] state<Start>: transitioning to Stray 2024-05-18T16:20:43.607+0000 71872b0006c0 0 log_channel(cluster) log [WRN] : Monitor...

Here is thanks for your support @spirit Here are the logs that looks significant to me : y 2024-05-18T16:18:18.292+0000 71872b0006c0 0 log_channel(cluster) log [WRN] : Monitor daemon marked osd.4 down, but it is still running 2024-05-18T16:18:18.292+0000 71872b0006c0 0 log_channel(cluster)...

hum.... seems to be also referenced here https://tracker.ceph.com/issues/43417

Hi everyone, I'm working with a 3 node cluster running with ceph 17 and I'm about to upgrade. I also add a new node to the cluster and install ceph 18.2 . The first OSD i'm creating seems OK yet after a few moments it's shut down. In the logs here is what I can find : May 18 15:34:44 node4...

Hi, I have the same message and as it's raised multiple times it ends into a shutdown of the OSD. Maybe I should open a bug issue

Didi you succeed in preventing issues on this one :

Hi @kifeo The second one seems to be a comestics message https://forum.proxmox.com/threads/ceph-trying-to-reset-class.101841/#post-662923

Hi, Same thing for me with a fresh reef installation. Did you succeed in solving this ?

Hi @fabian , than ks for the answer, any chance to point the issue so that we could follow up the resolution? Regards

Hi @thesix , did you checked the logs IN the proxmox. Maybe the id you're using are not allowed to browse the API.

Hi @radim.smehlik , I understand your point of view. Yet, AFAICS, the ceph bug talk about the same issue, without proxmox.... So IMHO, ceph should first solve the issue or maybe Proxmox team could propose a solution to the ceph team. It looks much mainstream to me this way. But yeah.... we all...

Hi, It depends on the ceph team, not the proxmox one

Hi @fiona, thanks for your feedback, do you need a test on the pve-kernel-6.2.16-3-pve ?

Hi, I confirm that we also have the same messages in the logs : kernel: pverados[4133454]: segfault at 55c6095fa408 ip 000055c607463cef sp 00007ffe68d860d0 error 7 in perl[55c60737b000+195000] likely on CPU 40 (core 21, socket 0) kernel: Code: 48 89 45 70 48 3b 45 78 0f 84 b6 02 00 00 4c 89 ea...

Hi, I have the same logs in PVE8.0.3 for ovs logs : Jan 24 16:05:56 fava2 ovs-vsctl[68966]: ovs|00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl del-port veth113i0 Jan 24 16:05:56 fava2 ovs-vsctl[68966]: ovs|00002|db_ctl_base|ERR|no port named veth113i0 Jan 24 16:05:56 fava2 ovs-vsctl[68967]...