Recent content by Waschbüsch

Very glad it helped!!

Do you have a keyring in /etc/pve/priv/ceph/<your_rbd_storage>.keyring? If so, AND you still have auth_client_required = none auth_cluster_required = none auth_service_required = none set in your ceph.conf, try renaming that to <your_rbd_storage>.keyring_old (and have the reverse...

I solved this for my cluster. The steps were thus: Make sure all your monitor keyring files are identical (all mon use the same key!) and of this structure (use your real client-admin key) [mon.] key = <somekey> caps mon = "allow *" [client.admin] key = <anotherkey>...

FWIW: If it were necessary to first re-enable cephx on the cluster to proceed with migration, steps on how to do that *safely* (and hopefully without downtime?) would be appreciated.

I have the exact same situation. Advice on how to proceed is highly appreciated.

Thank you for the suggestion. I was not aware of the fuse variant. That works and resolves my problem! Where did you get the link to the upstream doc? It points to an error page. This still works, though: https://docs.ceph.com/en/latest/rados/operations/require-min-compat-client The hint about...

I experience the same issue mentioned here: https://forum.proxmox.com/threads/ceph-client-still-using-luminous-while-on-squid.165370/ and here: https://forum.proxmox.com/threads/unable-to-mount-cephfs-when-set-require-min-compat-client-squid.159502/ (both of which seem to have remained...

I have to correct myself - I did not have the latest packages, but what was on my apt-proxy. Apologies for that. I have now updated to the latest as of this morning and now experience the same issues. However: for me this is NOT restricted to FreeBSD 14 machines, but 13.2 as well.

I run FreeBSD 14.0 based VMs on the latest PVE versions without problems whatsoever. What storage backend do you use? My VMs are using VirtIO SCSI Single with either zfs or ceph as backend.

Unsure, really. It may be enough to restart the mon instances, then again maybe not. I don't recall.

That all depends on who your ceph clients are. If you use ceph exclusively as a storage backend for VMs, then your cluster nodes will be the only clients and you can then determine if the network that traffic runs on actually needs the security.

First recommendation: do benchmarks, identify whether you lack IOPS or bandwidth, whether some storage medium is the problem and if so, which one and then you have a much better chance adressing the specific reasons. Also keep in mind that the limiting factor in ceph may not be the storage...

correct. You can do that on the fly to change the current scheduler. I actually doubt there will be any performance benefit with regards to I/O. However, you might save some CPU cycles because none does less work than mq-deadline. It all obviously heavily on your specific hardware, but I do not...

The schedulers you mentioned are what older kernels offered and no longer available. More modern kernels offer multiqueue alternatives to these schedulers. If you have SSDs and you see none as the scheduler or have HDDs and their scheduler is mq-deadline, you already have the desired...

We have seen the same sort of thing happen. Upon reboot one (or more) OSDs may (or may not) crash in this manner. So far, it seems random. There is a ceph issue for just such a crash here: https://tracker.ceph.com/issues/56292 But there does not seem much (if any) activity as of now. ceph crash...