- ceph-users - lists.ceph.io

Re: squid 19.2.5 QE validation status
by Venky Shankar 09 Jul '26

09 Jul '26

Hi Yuri, fs approved. failures are https://tracker.ceph.com/projects/cephfs/wiki/Squid#Squid-v1925 On Wed, Jul 8, 2026 at 4:50 PM Venky Shankar via dev <dev(a)ceph.io> wrote: > > Hey Yuri, > > On Wed, Jul 8, 2026 at 1:16 AM Yuri Weinstein via ceph-users > <ceph-users(a)ceph.io> wrote: > > > > Hi everyone, > > > > We are currently awaiting the fs review and approval from Venky. > > The run mostly looks good. There were some infra failures for which I > am reruning the failed tests > > https://pulpito.ceph.com/vshankar-2026-07-08_07:40:18-fs-squid-release-dist… > > Once the run finishes, I will post my approval. > > > > > Additionally, please review the Release Notes here: > > https://github.com/ceph/ceph/pull/69886 > > > > Best regards, > > Yuri Weinstein > > > > On Mon, Jun 29, 2026 at 7:26 AM Yuri Weinstein <yweinste(a)redhat.com> wrote: > > > > > Details of this release are summarized here: > > > > > > https://tracker.ceph.com/issues/76983#note-2 > > > > > > Release Notes - TBD > > > LRC upgrade - N/A > > > > > > Note: please reply to this email with comments/approvals and also add your > > > comments to the tracker above. > > > > > > Seeking approvals/reviews for: > > > > > > smoke: PASSED > > > > > > rados: Radek, Laura, Nitzan, Afreen, Travis > > > rgw: Adam Emerson > > > fs: Venky > > > orch/ceph-volume: Redouane & Guillaume > > > rbd: Ilya > > > krbd: Ilya > > > > > > upgrade: Laura, Patrick (see https://tracker.ceph.com/issues/77569, > > > https://github.com/ceph/ceph/pull/69791) > > > > > > upgrade-clients:client-upgrade-reef-squid-squid: PASSED > > > upgrade-clients:client-upgrade-quincy-squid-squid: PASSED > > > > > > perf-basic: PASSED > > > crimson-rados: N/A > > > powercycle: PASSED > > > > > > TIA > > > > > _______________________________________________ > > ceph-users mailing list -- ceph-users(a)ceph.io > > To unsubscribe send an email to ceph-users-leave(a)ceph.io > > > > > -- > Cheers, > Venky > -- Cheers, Venky

1 0

Re: Adding and removing monitors/Impact on consuming systems
by Eugen Block 08 Jul '26

08 Jul '26

Hi, if you haven't yet, check out the docs [0], [1]. It's recommended to first add new MONs, see if they work and then remove the old ones (as you already mentioned yourself). I recommend to turn on this cephadm health check (disabled by default): ceph config set mgr mgr/cephadm/config_checks_enabled true Especially "network_missing" can be valuable here, it will check if your additional hosts have correct network settings before you try to add daemons. You can turn off other checks if you don't need them. Regards, Eugen [0] https://docs.ceph.com/en/latest/rados/operations/add-or-rm-mons/#changing-a… [1] https://docs.ceph.com/en/latest/cephadm/services/mon/#moving-monitors-to-a-… Zitat von Edward R Huyer via ceph-users <ceph-users(a)ceph.io>: > I have a fairly run-of-the-mill cephadm managed/containerized 20.2.1 > cluster. Not hyperconverged or anything like that. It's currently > exporting RBD to a Proxmox VE 8.4 cluster (QEMU virtualization), and > CephFS to a couple RHEL 8.x servers via kernel mounts. > > I need to migrate the whole thing, including the monitors, to new > hardware. My question is, can I rely on the QEMU processes and > kernel mounts to correctly update their internal monitor maps as I > add new monitors and remove old monitors, or will I suddenly reach a > point where the consumers can't find the monitors they started up > with and lose their minds? (I know I'll also need to update the > static configs.) > > I'm pretty sure it should Just Work so long as I don't do something > dumb and lose quorum, but there's a big difference between "should" > and "actually does", and I haven't been able to find any writeups of > people actually doing it, so I'm asking here. Is this likely to > work? Is this known to not work for some reason (e.g., the kernel > mounts or QEMU processes never actually update their mon maps after > startup)? > > TIA! > > ----- > Edward Huyer > Golisano College of Computing and Information Sciences > Rochester Institute of Technology > Golisano 70-2373 > 152 Lomb Memorial Drive > Rochester, NY 14623 > 585-475-6651 > erhvks(a)rit.edu<mailto:erhvks@rit.edu> > > Obligatory Legalese: > The information transmitted, including attachments, is intended only > for the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material. Any review, retransmission, > dissemination or other use of, or taking of any action in reliance > upon this information by persons or entities other than the intended > recipient is prohibited. If you received this in error, please > contact the sender and destroy any copies of this information. > > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0

Re: Adding and removing monitors/Impact on consuming systems
by Edward R Huyer 08 Jul '26

08 Jul '26

Awesome, thank you! I knew it should work, but the explosion if it didn't would be big enough I wanted to see if someone could verify. Fortunately I have the hardware installed side by side, so I think I'll add all the new mons, then remove the old ones. Thanks again! > -----Original Message----- > From: Phillip Schichtel via ceph-users <ceph-users(a)ceph.io> > Sent: Wednesday, July 8, 2026 10:28 AM > To: Edward R Huyer <erhvks(a)rit.edu>; ceph-users(a)ceph.io > Subject: [ceph-users] Re: Adding and removing monitors/Impact on > consuming systems > > Hi Edward, > > I'm operating a fairly similar setup. I have done a similar migration to what you > described on a 19.x cluster: Migrated all hosts from an old HPE generation to a > newer one. I added one of the new hosts to the cluster, migrated a mon, mgr, > mds, rgw and osds, propagated the new IPs to firewalls and clients and > eventually removed the old host. I repeated that for the remaining hosts. Due > to a lack of rack space I had to do this host by host. > > The VMs and cephfs mounts did not experience issues during the migration > (both Debian and RHEL machines). > > ~ Phillip > > On Wed, 2026-07-08 at 13:58 +0000, Edward R Huyer via ceph-users wrote: > > I have a fairly run-of-the-mill cephadm managed/containerized 20.2.1 > > cluster. Not hyperconverged or anything like that. It's currently > > exporting RBD to a Proxmox VE 8.4 cluster (QEMU virtualization), and > > CephFS to a couple RHEL 8.x servers via kernel mounts. > > > > I need to migrate the whole thing, including the monitors, to new > > hardware. My question is, can I rely on the QEMU processes and kernel > > mounts to correctly update their internal monitor maps as I add new > > monitors and remove old monitors, or will I suddenly reach a point > > where the consumers can't find the monitors they started up with and > > lose their minds? (I know I'll also need to update the static > > configs.) > > > > I'm pretty sure it should Just Work so long as I don't do something > > dumb and lose quorum, but there's a big difference between "should" > > and "actually does", and I haven't been able to find any writeups of > > people actually doing it, so I'm asking here. Is this likely to work? > > Is this known to not work for some reason (e.g., the kernel mounts or > > QEMU processes never actually update their mon maps after startup)? > > > > TIA! > > > > ----- > > Edward Huyer > > Golisano College of Computing and Information Sciences Rochester > > Institute of Technology Golisano 70-2373 > > 152 Lomb Memorial Drive > > Rochester, NY 14623 > > 585-475-6651 > > erhvks(a)rit.edu<mailto:erhvks@rit.edu> > > > > Obligatory Legalese: > > The information transmitted, including attachments, is intended only > > for the person(s) or entity to which it is addressed and may contain > > confidential and/or privileged material. Any review, retransmission, > > dissemination or other use of, or taking of any action in reliance > > upon this information by persons or entities other than the intended > > recipient is prohibited. If you received this in error, please contact > > the sender and destroy any copies of this information. > > > > _______________________________________________ > > 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

1 0

Re: Adding and removing monitors/Impact on consuming systems
by Phillip Schichtel 08 Jul '26

08 Jul '26

Hi Edward, I'm operating a fairly similar setup. I have done a similar migration to what you described on a 19.x cluster: Migrated all hosts from an old HPE generation to a newer one. I added one of the new hosts to the cluster, migrated a mon, mgr, mds, rgw and osds, propagated the new IPs to firewalls and clients and eventually removed the old host. I repeated that for the remaining hosts. Due to a lack of rack space I had to do this host by host. The VMs and cephfs mounts did not experience issues during the migration (both Debian and RHEL machines). ~ Phillip On Wed, 2026-07-08 at 13:58 +0000, Edward R Huyer via ceph-users wrote: > I have a fairly run-of-the-mill cephadm managed/containerized 20.2.1 > cluster. Not hyperconverged or anything like that. It's currently > exporting RBD to a Proxmox VE 8.4 cluster (QEMU virtualization), and > CephFS to a couple RHEL 8.x servers via kernel mounts. > > I need to migrate the whole thing, including the monitors, to new > hardware. My question is, can I rely on the QEMU processes and > kernel mounts to correctly update their internal monitor maps as I > add new monitors and remove old monitors, or will I suddenly reach a > point where the consumers can't find the monitors they started up > with and lose their minds? (I know I'll also need to update the > static configs.) > > I'm pretty sure it should Just Work so long as I don't do something > dumb and lose quorum, but there's a big difference between "should" > and "actually does", and I haven't been able to find any writeups of > people actually doing it, so I'm asking here. Is this likely to > work? Is this known to not work for some reason (e.g., the kernel > mounts or QEMU processes never actually update their mon maps after > startup)? > > TIA! > > ----- > Edward Huyer > Golisano College of Computing and Information Sciences > Rochester Institute of Technology > Golisano 70-2373 > 152 Lomb Memorial Drive > Rochester, NY 14623 > 585-475-6651 > erhvks(a)rit.edu<mailto:erhvks@rit.edu> > > Obligatory Legalese: > The information transmitted, including attachments, is intended only > for the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material. Any review, retransmission, > dissemination or other use of, or taking of any action in reliance > upon this information by persons or entities other than the intended > recipient is prohibited. If you received this in error, please > contact the sender and destroy any copies of this information. > > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0

Adding and removing monitors/Impact on consuming systems
by Edward R Huyer 08 Jul '26

08 Jul '26

I have a fairly run-of-the-mill cephadm managed/containerized 20.2.1 cluster. Not hyperconverged or anything like that. It's currently exporting RBD to a Proxmox VE 8.4 cluster (QEMU virtualization), and CephFS to a couple RHEL 8.x servers via kernel mounts. I need to migrate the whole thing, including the monitors, to new hardware. My question is, can I rely on the QEMU processes and kernel mounts to correctly update their internal monitor maps as I add new monitors and remove old monitors, or will I suddenly reach a point where the consumers can't find the monitors they started up with and lose their minds? (I know I'll also need to update the static configs.) I'm pretty sure it should Just Work so long as I don't do something dumb and lose quorum, but there's a big difference between "should" and "actually does", and I haven't been able to find any writeups of people actually doing it, so I'm asking here. Is this likely to work? Is this known to not work for some reason (e.g., the kernel mounts or QEMU processes never actually update their mon maps after startup)? TIA! ----- Edward Huyer Golisano College of Computing and Information Sciences Rochester Institute of Technology Golisano 70-2373 152 Lomb Memorial Drive Rochester, NY 14623 585-475-6651 erhvks(a)rit.edu<mailto:erhvks@rit.edu> Obligatory Legalese: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

1 0

Re: squid 19.2.5 QE validation status
by Venky Shankar 08 Jul '26

08 Jul '26

Hey Yuri, On Wed, Jul 8, 2026 at 1:16 AM Yuri Weinstein via ceph-users <ceph-users(a)ceph.io> wrote: > > Hi everyone, > > We are currently awaiting the fs review and approval from Venky. The run mostly looks good. There were some infra failures for which I am reruning the failed tests https://pulpito.ceph.com/vshankar-2026-07-08_07:40:18-fs-squid-release-dist… Once the run finishes, I will post my approval. > > Additionally, please review the Release Notes here: > https://github.com/ceph/ceph/pull/69886 > > Best regards, > Yuri Weinstein > > On Mon, Jun 29, 2026 at 7:26 AM Yuri Weinstein <yweinste(a)redhat.com> wrote: > > > Details of this release are summarized here: > > > > https://tracker.ceph.com/issues/76983#note-2 > > > > Release Notes - TBD > > LRC upgrade - N/A > > > > Note: please reply to this email with comments/approvals and also add your > > comments to the tracker above. > > > > Seeking approvals/reviews for: > > > > smoke: PASSED > > > > rados: Radek, Laura, Nitzan, Afreen, Travis > > rgw: Adam Emerson > > fs: Venky > > orch/ceph-volume: Redouane & Guillaume > > rbd: Ilya > > krbd: Ilya > > > > upgrade: Laura, Patrick (see https://tracker.ceph.com/issues/77569, > > https://github.com/ceph/ceph/pull/69791) > > > > upgrade-clients:client-upgrade-reef-squid-squid: PASSED > > upgrade-clients:client-upgrade-quincy-squid-squid: PASSED > > > > perf-basic: PASSED > > crimson-rados: N/A > > powercycle: PASSED > > > > TIA > > > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io > -- Cheers, Venky

1 0

squid 19.2.5 QE validation status
by Yuri Weinstein 07 Jul '26

07 Jul '26

Details of this release are summarized here: https://tracker.ceph.com/issues/76983#note-2 Release Notes - TBD LRC upgrade - N/A Note: please reply to this email with comments/approvals and also add your comments to the tracker above. Seeking approvals/reviews for: smoke: PASSED rados: Radek, Laura, Nitzan, Afreen, Travis rgw: Adam Emerson fs: Venky orch/ceph-volume: Redouane & Guillaume rbd: Ilya krbd: Ilya upgrade: Laura, Patrick (see https://tracker.ceph.com/issues/77569, https://github.com/ceph/ceph/pull/69791) upgrade-clients:client-upgrade-reef-squid-squid: PASSED upgrade-clients:client-upgrade-quincy-squid-squid: PASSED perf-basic: PASSED crimson-rados: N/A powercycle: PASSED TIA

1 1

Ceph Tech Talk July Reminder
by Anthony Middleton 07 Jul '26

07 Jul '26

Hey Ceph Friends, Please join us tomorrow, July 8, at 10:00 AM PDT / 17:00 UTC for the next Ceph Tech Talk: "*For Whom the Doorbell Tolls: GPU-Initiated Key-Value Storage on Ceph*" Together, we will learn how rados-nkv enables AMD GPUs to retrieve key-value data directly from Ceph using the NVMe KV command set. Featuring Kyle Bader (IBM) and Stephen Bates (AMD). RSVP here: https://www.linkedin.com/events/7473007902295773184/?viewAsMember=true If you have a topic in mind for a future tech talk, reach out to me with details. Best, ------- Anthony Middleton Community Manager, Ceph Foundation amiddleton(a)linuxfoundation.org LinkedIn <https://www.linkedin.com/company/ceph>| BlueSky <https://bsky.app/profile/ceph.io> | Twitter <https://x.com/Ceph>

1 0

Re: umbrella 21.1.0 RC QE validation status
by Brad Hubbard 07 Jul '26

07 Jul '26

On Tue, Jul 7, 2026 at 1:03 AM Yuri Weinstein via ceph-users < ceph-users(a)ceph.io> wrote: > Details of this release are summarized here: > > https://tracker.ceph.com/issues/76757 > > Release Notes - TBD > LRC upgrade - TBD > > > *PLEASE ADD YOUR COMMENTS/APPROVALS TO THE TRACKER!* > Seeking approvals/reviews for: > > smoke: Radek, Laura, Nitzan > > rados: Radek, Laura, Notzan, Afreen, Travis > rgw: Adam Emerson > fs: Venky > orch/ceph-volume: Adam King & Guillaume > rbd: Ilya > krbd: Ilya > > nvmeof: PASSED > > upgrade: Laura, Patrick > > upgrade-clients:client-upgrade-tentacle-umbrella-umbrella: TBD ( > https://github.com/ceph/ceph/pull/69888) > upgrade-clients:client-upgrade-squid-umbrella-umbrella: TBD ( > https://github.com/ceph/ceph/pull/69887) > > perf-basic: PASSED > > crimson-rados: Matan > > powercycle: Brad > The problem does not appear to be in the powercycle test but seems to expose an issue in the LibRadosIoECPPParamCombination/LibRadosIoECPP tests. I created a tracker, https://tracker.ceph.com/issues/77970 and asked Alex for comment. TIA > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io > > -- Cheers, Brad

1 0

CSC Minutes 2026/07/06
by Ernesto Puerta 06 Jul '26

06 Jul '26

Short meeting today: - [Dan] Waiting for the results of the ongoing motions (already closed). - [KyleB] Adopt rados-nkv <https://github.com/mmgaggle/rados-nkv> under the Ceph org (https://tracker.ceph.com/issues/77960) It'll be released as a container, potentially merging with the existing ceph-nvmeof container. - [Neha] Cephalocon working group <https://pad.ceph.com/p/cephalocon-working-group> (also <https://tracker.ceph.com/issues/77296>) starting today (interested parties are encouraged to join). - [Laura] Sepia Lab down due to storms (AdamK working on that; updates available at #sepia Slack channel). Kind Regards, Ernesto

1 0