- ceph-users - lists.ceph.io

Re: since squid (19.2.3) orch puts OSD block.db and data on same device
by Robert Sander 24 Feb '26

24 Feb '26

Am 24.02.26 um 12:04 PM schrieb Boris via ceph-users: > Hi, > we've upgraded from reef to squid lately and are encountering the problem > that the orchestrator now puts the block.db together with the data on the > same HDD. > > We've set the orch config to use non rotational devices for the block.db > and the rotational devices for the data. We use one SSD/NVMe for multiple > HDDs. The orchestrator in Ceph 19 and 20 has a bug with hybrid OSDs: https://tracker.ceph.com/issues/72696 There is a patch available but it has not been merged yet. Regards -- Robert Sander Linux Consultant Heinlein Consulting GmbH Schwedter Str. 8/9b, 10119 Berlin https://www.heinlein-support.de Tel: +49 30 405051 - 0 Fax: +49 30 405051 - 19 Amtsgericht Berlin-Charlottenburg - HRB 220009 B Geschäftsführer: Peer Heinlein - Sitz: Berlin

1 0

since squid (19.2.3) orch puts OSD block.db and data on same device
by Boris 24 Feb '26

24 Feb '26

Hi, we've upgraded from reef to squid lately and are encountering the problem that the orchestrator now puts the block.db together with the data on the same HDD. We've set the orch config to use non rotational devices for the block.db and the rotational devices for the data. We use one SSD/NVMe for multiple HDDs. We've now encountered that in two different clusters where we replaced HDDs. The existing block.db VGs still have capacity left. Below the output of lsblk with the mentioned disk, ceph orch ls export (only the osd service), vgs sds 65:32 0 14.6T 0 disk ├─ceph--92b5842c--8df3--43ef--9814--6707eb970cc6-osd--block--f0fe19ce--7b79--466f--a889--1935aa3e8b85 252:8 0 14.1T 0 lvm │ └─YbVkPH-f3ZG-IZfE-jdGc-CCf6-597l-uo8J3W 252:59 0 14.1T 0 crypt └─ceph--92b5842c--8df3--43ef--9814--6707eb970cc6-osd--db--1a1a654e--145f--45b5--a5b0--9cb322db6093 252:26 0 430G 0 lvm └─Xpt9TE-3Z40-1lvl-j8iS-OWYj-mQXx-waw2cR 252:77 0 430G 0 crypt --- service_type: osd service_id: osd_1_ssd service_name: osd.osd_1_ssd placement: host_pattern: '*' spec: data_devices: limit: 2 rotational: 0 size: :2TB vendor: SAMSUNG encrypted: true filter_logic: AND objectstore: bluestore --- service_type: osd service_id: osd_2_hdd_8tb service_name: osd.osd_2_hdd_8tb placement: host_pattern: '*' spec: block_db_size: 343597383680 data_devices: rotational: 1 size: :10TB db_devices: rotational: 0 size: :2TB db_slots: 5 encrypted: true filter_logic: AND objectstore: bluestore --- service_type: osd service_id: osd_4_hdd_16tb service_name: osd.osd_4_hdd_16tb placement: hosts: - s3db23 spec: block_db_size: 461708984320 data_devices: rotational: 1 size: '10TB:' db_devices: rotational: 0 size: 3TB:4TB db_slots: 8 encrypted: true filter_logic: AND objectstore: bluestore VG #PV #LV #SN Attr VSize VFree ceph-0161de84-5042-4925-a959-b9d214852511 1 4 0 wz--n- 3.49t 1.81t ceph-02da2287-597a-4619-a3d3-9358cbb60622 1 1 0 wz--n- 14.55t 0 ceph-05813ea9-d14a-4e6c-81b0-9605f0001766 1 1 0 wz--n- 14.55t 0 ceph-06d405e7-abfa-4f5d-b4e3-7229bb96f2fd 1 1 0 wz--n- 14.55t 0 ceph-18ac75a3-d187-4fc2-a8aa-3b6a26b70246 1 1 0 wz--n- 14.55t 0 ceph-19a0db63-89ed-4f2e-b5ab-961dc0f8d413 1 5 0 wz--n- 3.49t 1.39t ceph-2ecb6728-0fc3-4622-acd7-298ec3a02c02 1 1 0 wz--n- 14.55t 0 ceph-306a63bc-5a8a-44d9-af80-d4cf825ceeca 1 5 0 wz--n- 3.49t 1.39t ceph-47a79684-9cba-4e51-b143-c05f3307a876 1 1 0 wz--n- <1.75t 0 ceph-4d80d916-db9b-46f6-9e34-29ae35879e8e 1 1 0 wz--n- 14.55t 0 ceph-5fe43992-3918-4a81-bbee-fc08e1329c0b 1 1 0 wz--n- <1.75t 0 ceph-84fb035b-0c57-4249-98d5-92fdb010867d 1 1 0 wz--n- 14.55t 0 ceph-92b5842c-8df3-43ef-9814-6707eb970cc6 1 2 0 wz--n- 14.55t 0 <------ ceph-96d2979a-ac09-492a-a4c5-466fb8ca44c3 1 1 0 wz--n- 14.55t 0 ceph-a49a0de2-a9e9-47d4-aff2-e96660c4267a 1 1 0 wz--n- 14.55t 0 ceph-ac752e7a-db71-4c3b-9158-dcc3b6aebcb7 1 1 0 wz--n- 14.55t 0 ceph-c6e94f1e-0b48-4966-9e31-a67232733a63 1 1 0 wz--n- 14.55t 0 ceph-c791562d-69b2-4463-ae53-77b0997c1cd7 1 1 0 wz--n- 14.55t 0 ceph-c7bbf14b-ac87-47cc-86f9-173a113a9b80 1 1 0 wz--n- 14.55t 0 ceph-cd38189c-b8c9-40e1-a528-d645838144e4 1 1 0 wz--n- 14.55t 0 ceph-cf93829f-086b-451a-b5cb-b4ca9462f660 1 1 0 wz--n- 14.55t 0 ceph-d6dfd5aa-635d-4ba3-8efd-15764f4cdd18 1 1 0 wz--n- 14.55t 0 ceph-e247cda8-e206-42bc-ad0b-88639944ddf2 1 1 0 wz--n- 14.55t 0 ceph-e3f5355e-8653-46c4-8ea2-ae632196a062 1 5 0 wz--n- 3.49t 1.39t ceph-eee43b8f-6653-4b9d-8547-f40d94927840 1 1 0 wz--n- 14.55t 0 ceph-f208c77f-9821-4580-ab7b-63093f12a671 1 1 0 wz--n- 14.55t 0

1 0

NVMe ARM cluster: throughput plateaus and initial OSD hotspot
by Lina SADI 24 Feb '26

24 Feb '26

1 0

OSD memory usage exceeding configured limits during reads (Tentacle v20.2.0, ec_optimizations on)
by Chanu Yu 24 Feb '26

24 Feb '26

Hi all, I have a question regarding OSD memory behavior during read workloads. During sequential read tests, I observe that a small number of OSD daemons sometimes grow their memory usage far beyond configured limits and end up consuming most of the host memory. This memory is not reclaimed even after the workload stops, unless the OSD is restarted. I have already set explicit limits such as osd_memory_target and bluestore cache size (with autotune off), but some OSDs still exceed them significantly. My main questions are: 1. Is it considered normal for OSDs to exceed configured memory targets by a large margin during read workloads? 2. Is there any supported way to strictly enforce OSD memory limits (beyond current tuning options), without relying on container OOM or suffering major performance degradation? If this behavior is expected or already known, I’d appreciate any pointers. I can provide more details if needed. Thanks in advance. Best regards, Chanu Yu

1 0

Re: Ceph MDS super slow
by Martin Gerhard Loschwitz 24 Feb '26

24 Feb '26

Hey Venky, thank you for your reply! > Am 16.02.2026 um 08:34 schrieb Venky Shankar via ceph-users <ceph-users(a)ceph.io>: > > Hi Martin, > > Could you additionally do a minute worth of MDS perf dump captures at > 5 second intervals during the observed slowness? This can be done > using > >> ceph tell mds.<id> perf dump > > and pipe the result to separate (time-stamped) files and share those. > I am attaching a tarball with the perf dumps alongside the wall clock profiles generated at the same time. Please note that when running gdbpmp on the MDS, it appears to stall / hang so that after a while, the MONs declare the rank failed and initiate a fail-over. I am not sure that is supposed to be this way … I am seeing SIGINT messages in those moments in the logs. At such events, the „perf dump“ Generated would be empty. Best regards Martin -- Martin Gerhard Loschwitz Geschäftsführer / CEO, True West IT Services GmbH Phone: +49 2433 5253130 Mobile: +49 176 61832178 Address: Schmiedegasse 24a, 41836 Hückelhoven, Germany Legal: HRB 21985, Amtsgericht Mönchengladbach VAT: DE363893844 True West IT Services GmbH is compliant with the GDPR regulation on data protection and privacy in the European Union and the European Economic Area. You can request the information on how we collect and process your private data according to the law by contacting the email sender.

2 1

Re: reef 18.2.8 QE validation status
by Yuri Weinstein 23 Feb '26

23 Feb '26

Patrick, The only outstanding issues are the FS approval and upgrade issues, reported by Laura. What do you suggest we do next here? On Mon, Feb 23, 2026 at 8:54 AM Adam King via Dev <dev(a)ceph.io> wrote: > orch approved. Run looks ugly due to us no having a proper ignorelist for > the orch suite on reef, but the actual results are okay > > On Sat, Nov 29, 2025 at 12:09 PM Yuri Weinstein via ceph-users < > ceph-users(a)ceph.io> wrote: > >> Rerun scheduled for krbd >> >> Still waiting for replies from dev leads >> >> On Mon, Nov 24, 2025 at 6:24 AM Ilya Dryomov <idryomov(a)gmail.com> wrote: >> >> > On Fri, Nov 21, 2025 at 12:04 AM Yuri Weinstein <yweinste(a)redhat.com> >> > wrote: >> > > >> > > Note: this is an attempt to test and publish post EOL reef point >> release >> > > >> > > Details of this release are summarized here: >> > > >> > > https://tracker.ceph.com/issues/73906#note-1 >> <https://qcflzmq6.r.us-east-1.awstrack.me/L0/https:%2F%2Ftracker.ceph.com%2F…> >> > > Release Notes - TBD >> > > LRC upgrade - N/A >> > > >> > > distro => jammy focal centos9 windows bookworm >> > > >> > > Seeking approvals/reviews for: >> > > >> > > smoke - Laura approved? >> > > >> > > rados - Radek, Laura approved? Travis? Nizamudeen? Adam King >> approved? >> > > (rados is also running on build 2 == build 1 + >> > > https://github.com/ceph/ceph/pull/66056 >> <https://qcflzmq6.r.us-east-1.awstrack.me/L0/https:%2F%2Fgithub.com%2Fceph%2…> >> per Igor's request) >> > > >> > > rgw - Adam E approved? >> > > >> > > fs - Venky approved? >> > > >> > > orch - Adam King approved? >> > > >> > > rbd - Ilya approved? >> > > krbd - Ilya approved? >> > >> > rbd approved, krbd needs a rerun as all jobs failed while >> > going through cephlab.yml playbook (not related to RBD): >> > >> > ['Error mounting /var/lib/ceph: mount: /var/lib/ceph: wrong fs type, >> > bad option, bad superblock on /dev/mapper/vg_nvme-lv_5, missing >> > codepage or helper program, or other error.'] >> > >> > Thanks, >> > >> > Ilya >> > >> > >> _______________________________________________ >> ceph-users mailing list -- ceph-users(a)ceph.io >> To unsubscribe send an email to ceph-users-leave(a)ceph.io >> > _______________________________________________ > Dev mailing list -- dev(a)ceph.io > To unsubscribe send an email to dev-leave(a)ceph.io >

1 0

Re: reef 18.2.8 QE validation status
by Adam King 23 Feb '26

23 Feb '26

orch approved. Run looks ugly due to us no having a proper ignorelist for the orch suite on reef, but the actual results are okay On Sat, Nov 29, 2025 at 12:09 PM Yuri Weinstein via ceph-users < ceph-users(a)ceph.io> wrote: > Rerun scheduled for krbd > > Still waiting for replies from dev leads > > On Mon, Nov 24, 2025 at 6:24 AM Ilya Dryomov <idryomov(a)gmail.com> wrote: > > > On Fri, Nov 21, 2025 at 12:04 AM Yuri Weinstein <yweinste(a)redhat.com> > > wrote: > > > > > > Note: this is an attempt to test and publish post EOL reef point > release > > > > > > Details of this release are summarized here: > > > > > > https://tracker.ceph.com/issues/73906#note-1 > > > Release Notes - TBD > > > LRC upgrade - N/A > > > > > > distro => jammy focal centos9 windows bookworm > > > > > > Seeking approvals/reviews for: > > > > > > smoke - Laura approved? > > > > > > rados - Radek, Laura approved? Travis? Nizamudeen? Adam King approved? > > > (rados is also running on build 2 == build 1 + > > > https://github.com/ceph/ceph/pull/66056 per Igor's request) > > > > > > rgw - Adam E approved? > > > > > > fs - Venky approved? > > > > > > orch - Adam King approved? > > > > > > rbd - Ilya approved? > > > krbd - Ilya approved? > > > > rbd approved, krbd needs a rerun as all jobs failed while > > going through cephlab.yml playbook (not related to RBD): > > > > ['Error mounting /var/lib/ceph: mount: /var/lib/ceph: wrong fs type, > > bad option, bad superblock on /dev/mapper/vg_nvme-lv_5, missing > > codepage or helper program, or other error.'] > > > > Thanks, > > > > Ilya > > > > > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io >

1 0

Re: reef 18.2.8 QE validation status
by Venky Shankar 23 Feb '26

23 Feb '26

Hi Yuri, On Thu, Feb 12, 2026 at 9:30 PM Yuri Weinstein via ceph-users <ceph-users(a)ceph.io> wrote: > > Still seeking approvals for: > > (smoke - FAILED, was reviewed and approved by Laura and Patrick, see Slack > thread for details) > rados - FAILED, Afreen, Travis? ( Laura approved for core) > > rgw - FAILED, Adam E approved? > > (rbd, krbd - FAILED, Ilya approved) > fs - FAILED, Venky approved? I wasn't able to finish reviewing the run and teuthology results are unavailable right now due to the lab outage. > orch - FAILED, Adam K approved? > > upgrade/pacific-x (reef) - FAILED Laura, approved? > upgrade/quincy-x (reef) - FAILED Laura, approved? > upgrade/reef-p2p - FAILED Laura, approved? > > (powercycle - FAILED Brad, approved) > ceph-volume - Approved Guillaume? > > On Wed, Feb 11, 2026 at 12:10 PM Laura Flores via Dev <dev(a)ceph.io> wrote: > > > The rados suite is approved: > > https://tracker.ceph.com/projects/rados/wiki/REEF#reef-v1828-httpstrackerce… > > > > On Tue, Feb 10, 2026 at 6:33 PM Brad Hubbard via Dev <dev(a)ceph.io> wrote: > > > >> Powercycle approved. > >> > >> On Tue, Feb 10, 2026 at 10:35 AM Brad Hubbard via Dev <dev(a)ceph.io> > >> wrote: > >> > >>> > >>> > >>> On Fri, Feb 6, 2026 at 12:36 PM Brad Hubbard <bhubbard(a)redhat.com> > >>> wrote: > >>> > >>>> > >>>> > >>>> On Fri, Feb 6, 2026 at 8:33 AM Brad Hubbard via ceph-users < > >>>> ceph-users(a)ceph.io> wrote: > >>>> > >>>>> On Fri, Feb 6, 2026 at 7:59 AM Yuri Weinstein via ceph-users < > >>>>> ceph-users(a)ceph.io> wrote: > >>>>> > >>>>> > We are continuing on this release. > >>>>> > > >>>>> > > >>>>> > powercycle - FAILED Brad, approved? > >>>>> > > >>>>> > >>>>> Unfortunately, I don't see any logs anywhere where I have access to > >>>>> them so > >>>>> I have no way of checking this? > >>>>> > >>>> > >>>> OK, I have the latest logs. The three failing jobs appear to have all > >>>> timed out after running for about six hours. At this time I don't know why > >>>> but I continue to investigate. > >>>> > >>> > >>> One point of commonality of the three tests that failed is that they are > >>> all running tests using ceph fuse. I'll reach out to the FS guys to see if > >>> they can help me get to the bottom of these failures. > >>> > >>> > >>>> > >>>> > >>>>> > >>>>> > >>>>> > ceph-volume - Approved Guillaume? > >>>>> > > >>>>> > Patrick was reviewing some tests, please see his comments in the same > >>>>> > tracker. > >>>>> > TIA > >>>>> > > >>>>> > > >>>>> > On Sat, Dec 13, 2025 at 1:19 AM Ilya Dryomov via ceph-users < > >>>>> > ceph-users(a)ceph.io> wrote: > >>>>> > > >>>>> > > On Mon, Dec 8, 2025 at 11:31 PM Yuri Weinstein via Dev < > >>>>> dev(a)ceph.io> > >>>>> > > wrote: > >>>>> > > > > >>>>> > > > This test branch was built loner then 2.5 weeks ago > >>>>> > > > I have to rebuild it first and then will schedule krbd > >>>>> > > > >>>>> > > krbd approved based on > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > >>>>> https://pulpito.ceph.com/yuriw-2025-12-10_21:26:56-krbd-reef-release-testin… > >>>>> > > > >>>>> > > > >>>>> > > >>>>> https://pulpito.ceph.com/yuriw-2025-12-12_18:20:32-krbd-reef-release-testin… > >>>>> > > > >>>>> > > Thanks, > >>>>> > > > >>>>> > > Ilya > >>>>> > > > >>>>> > > > > >>>>> > > > On Mon, Dec 8, 2025 at 1:39 PM Ilya Dryomov via ceph-users < > >>>>> > > ceph-users(a)ceph.io> wrote: > >>>>> > > >> > >>>>> > > >> On Mon, Dec 8, 2025 at 8:50 PM Ilya Dryomov <idryomov(a)gmail.com > >>>>> > > >>>>> > wrote: > >>>>> > > >> > > >>>>> > > >> > On Mon, Dec 8, 2025 at 5:00 PM Venky Shankar via ceph-users > >>>>> > > >> > <ceph-users(a)ceph.io> wrote: > >>>>> > > >> > > > >>>>> > > >> > > Hi Yuri, > >>>>> > > >> > > > >>>>> > > >> > > On Fri, Nov 21, 2025 at 4:34 AM Yuri Weinstein < > >>>>> > yweinste(a)redhat.com> > >>>>> > > wrote: > >>>>> > > >> > > > > >>>>> > > >> > > > Note: this is an attempt to test and publish post EOL > >>>>> reef > >>>>> > point > >>>>> > > release > >>>>> > > >> > > > > >>>>> > > >> > > > Details of this release are summarized here: > >>>>> > > >> > > > > >>>>> > > >> > > > https://tracker.ceph.com/issues/73906#note-1 > >>>>> > > >> > > > Release Notes - TBD > >>>>> > > >> > > > LRC upgrade - N/A > >>>>> > > >> > > > > >>>>> > > >> > > > distro => jammy focal centos9 windows bookworm > >>>>> > > >> > > > > >>>>> > > >> > > > Seeking approvals/reviews for: > >>>>> > > >> > > > > >>>>> > > >> > > > smoke - Laura approved? > >>>>> > > >> > > > > >>>>> > > >> > > > rados - Radek, Laura approved? Travis? Nizamudeen? Adam > >>>>> King > >>>>> > > approved? > >>>>> > > >> > > > (rados is also running on build 2 == build 1 + > >>>>> > > >> > > > https://github.com/ceph/ceph/pull/66056 per Igor's > >>>>> request) > >>>>> > > >> > > > > >>>>> > > >> > > > rgw - Adam E approved? > >>>>> > > >> > > > > >>>>> > > >> > > > fs - Venky approved? > >>>>> > > >> > > > >>>>> > > >> > > There are lot many failures in the fs suite resembling > >>>>> > > >> > > > >>>>> > > >> > > Error mounting /var/lib/ceph: mount: /var/lib/ceph: > >>>>> wrong > >>>>> > fs > >>>>> > > >> > > type, bad option ... > >>>>> > > >> > > > >>>>> > > >> > > which is an issue with the testing kernel. Adding Alex who > >>>>> was > >>>>> > > looking > >>>>> > > >> > > into this issue. > >>>>> > > >> > > > >>>>> > > >> > > As far as the run validation is concerned, it's risky to > >>>>> ignore > >>>>> > the > >>>>> > > >> > > large number of failures. We have two options: > >>>>> > > >> > > > >>>>> > > >> > > - fix the testing kernel issue and rerun > >>>>> > > >> > > - rerun with `for-linus` branch (with `-k for-linus` in the > >>>>> > > >> > > teuthology-suite schedule command) > >>>>> > > >> > > > >>>>> > > >> > > The latter would be using an older kernel branch, but I > >>>>> think it > >>>>> > > >> > > should suffice for this case. > >>>>> > > >> > > >>>>> > > >> > Hi Venky, > >>>>> > > >> > > >>>>> > > >> > With your report of the fs suite being affected as well, I > >>>>> carved > >>>>> > out > >>>>> > > >> > some time to take a look. > >>>>> > > >> > > >>>>> > > >> > I think it's happening because XFS maintainers disabled > >>>>> support for > >>>>> > V4 > >>>>> > > >> > filesystems that was deprecated 5 years ago -- as of 6.18 > >>>>> kernel > >>>>> > it's > >>>>> > > >> > no longer compiled in by default. The proper fix would be to > >>>>> create > >>>>> > > an > >>>>> > > >> > image with/move to V5 on-disk format; I have opened [1] to > >>>>> try to > >>>>> > > >> > achieve that. We can also re-enable V4 on-disk format in our > >>>>> kernel > >>>>> > > >> > builds as a workaround. > >>>>> > > >> > > >>>>> > > >> > [1] https://github.com/ceph/ceph-cm-ansible/pull/799 > >>>>> > > >> > >>>>> > > >> This should be fixed now. Yuri, please schedule a rerun for > >>>>> krbd. > >>>>> > > >> > >>>>> > > >> Thanks, > >>>>> > > >> > >>>>> > > >> Ilya > >>>>> > > >> _______________________________________________ > >>>>> > > >> ceph-users mailing list -- ceph-users(a)ceph.io > >>>>> > > >> To unsubscribe send an email to ceph-users-leave(a)ceph.io > >>>>> > > > > >>>>> > > > _______________________________________________ > >>>>> > > > Dev mailing list -- dev(a)ceph.io > >>>>> > > > To unsubscribe send an email to dev-leave(a)ceph.io > >>>>> > > _______________________________________________ > >>>>> > > ceph-users mailing list -- ceph-users(a)ceph.io > >>>>> > > To unsubscribe send an email to ceph-users-leave(a)ceph.io > >>>>> > > > >>>>> > _______________________________________________ > >>>>> > ceph-users mailing list -- ceph-users(a)ceph.io > >>>>> > To unsubscribe send an email to ceph-users-leave(a)ceph.io > >>>>> > > >>>>> > >>>>> > >>>>> -- > >>>>> Cheers, > >>>>> Brad > >>>>> _______________________________________________ > >>>>> ceph-users mailing list -- ceph-users(a)ceph.io > >>>>> To unsubscribe send an email to ceph-users-leave(a)ceph.io > >>>>> > >>>> > >>>> > >>>> -- > >>>> Cheers, > >>>> Brad > >>>> > >>> > >>> > >>> -- > >>> Cheers, > >>> Brad > >>> _______________________________________________ > >>> Dev mailing list -- dev(a)ceph.io > >>> To unsubscribe send an email to dev-leave(a)ceph.io > >>> > >> > >> > >> -- > >> Cheers, > >> Brad > >> _______________________________________________ > >> Dev mailing list -- dev(a)ceph.io > >> To unsubscribe send an email to dev-leave(a)ceph.io > >> > > > > > > -- > > > > Laura Flores > > > > She/Her/Hers > > > > Software Engineer, Ceph Storage <https://ceph.io> > > > > Chicago, IL > > > > lflores(a)ibm.com | lflores(a)redhat.com <lflores(a)redhat.com> > > M: +17087388804 > > > > > > _______________________________________________ > > Dev mailing list -- dev(a)ceph.io > > To unsubscribe send an email to dev-leave(a)ceph.io > > > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io -- Cheers, Venky

1 1

Re: 8443: connect: connection refused
by Eugen Block 23 Feb '26

23 Feb '26

It could be, yes. But maybe you could add more details to the story so we could get a full picture. In the first post you didn't mention nginx, I assume you're trying to use the mgmt-gateway? Zitat von listy via ceph-users <ceph-users(a)ceph.io>: > -> $ ceph mgr services > { > "dashboard": "http://10.1.1.63:8080/", > "prometheus": "http://10.1.1.63:9283/" > } > > Could the fact that I use - or rather try to for cannot figure out > configs - nginx-ha for accesing web-dashboard be the culprit here? > > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0

Re: 8443: connect: connection refused
by listy 23 Feb '26

23 Feb '26

-> $ ceph mgr services { "dashboard": "http://10.1.1.63:8080/", "prometheus": "http://10.1.1.63:9283/" } Could the fact that I use - or rather try to for cannot figure out configs - nginx-ha for accesing web-dashboard be the culprit here?

1 0