Search results

There should be a symlink, /etc/ceph/ceph.conf -> /etc/pve/ceph.conf, is it present? Are the OSD daemons really running? What is the output of journalctl -u ceph-osd@0.service?

Can these MONs be reached by all nodes in the cluster? Anything in the log files of those nodes?

Disable HA, remove VM/CT services and restart the pve-ha-lrm service to disarm the watchdog. Otherwise the load on the cluster might cause other resets. And as a first guess, corosync shares the network with ceph? And also @Christian St. advice. :)

The autoscaler tries to optimize for minimizing resource usage. This may lead to under/over estimation of the PG count in the default setting. If you want to make an informed decision about the PG count for your cluster, I suggest the use of the pgcalc [0] in combination with the autoscaler...

You can do this for flexibility. With enough bandwidth Ceph's public & cluster network can share the same NIC port and just be separated by VLAN. To change the cluster network of Ceph is usually no issue, but the public network is a different story.

Taking your 1..3, then none. Besides, I still suggest to use a seprate NIC port for corosync (at least one link), though that's a different topic.

Nachträglich, yup. Ceph berechnet anhand der "vollsten" OSD die Belegung der Pools.

The autoscaler provides suggestions to what the optimal PG number for a pool might be. It needs some tuning the provide more than just the defaults (off by factor 3). Best have a look at the scaling recommendations...

As installed version or only as running version? If the later, then you will need to migrate any VM/CT to another node and back. Since the connection is kept on update. Usually the ceph.conf is a symlink to /etc/pve/ceph.conf and the ceph.client.admin.keyring is copied on creation into the...

I wouldn't suggest this in general, but I have linked the thread to the upgrade guide. I hope others will share their experience as well.

As you stated yourself: Do this first and check that every node can ping each other on every interface/network configured. Including MTU.

Es werden mehrere TUN devices (zB. tun0, tun1, ...) erstellt. Openvpn macht das automatisch. Du kannst das ganze Setup einfach in einer VM ausprobieren, Proxmox VE läuft auch Nested. ;)

correct.

Warum sich das User wünschen ist mir auch ein Rätsel. Aber es ist machbar und @oguz hat eine Anleitung dafür geschrieben. In meinen Augen macht das nicht viel unterschied, CT vs Host. In beiden Fällen muss der Host Kernel arbeiten. Und ob das Interface direkt oder im CT ist, macht für das...

Diese ganze Thematik lässt sich viel leichter am Host abbilden. Dort wird bereits routing betrieben und die Firewall verwendet. Zusätzlich baust du damit einen weiteren Layer an Komplexität, der im Fehlerfall bedacht werden muss. The issue might be the permission of the tun device. Stéphane...

That you need Ceph Octopus to have snapshot based mirroring. As said, this is up to your automation. The rbd-mirror is a daemon that pulls from the remote cluster.

Proxmox VE uses an Ubuntu Kernel. If you don't intent to run graphic intense applications, then you don't need a GPU to run X11.

Have you seen our wiki page on migrations? Best keep your virtual hardware as close as possible to the original. https://pve.proxmox.com/wiki/Migration_of_servers_to_Proxmox_VE Alternatively you can try the build-in Windows backup and restore the OS including the system state.

If so, we like to hear them as well. :) So that we may extend our wiki.

That's up to your automation and procedures. Not quite. And see Ceph's docs. https://docs.ceph.com/en/latest/rbd/rbd-mirroring/