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 <[email protected]>
> Sent: Wednesday, July 8, 2026 10:28 AM
> To: Edward R Huyer <[email protected]>; [email protected]
> 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
> > [email protected]<mailto:[email protected]>
> >
> > 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 -- [email protected] To unsubscribe send an
> > email to [email protected]
> _______________________________________________
> ceph-users mailing list -- [email protected] To unsubscribe send an email to
> [email protected]
_______________________________________________
ceph-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to