Recent content by gurubert

For 4. you need OCFS2. It can be used by Proxmax as shared directory storage like NFS. With qcow2 for the VM images you get thin provisioning and snapshots. But this setup is not officially supported by the company that makes Proxmox. You have to configure OCFS2 yourself.

With a SAN and LUNs presented to each Proxmox host you do not use Ceph as the SAN already has its internal replication (RAID). You can use LVM on top of the LUN as written in the Proxmox documentation. Or if you want to have something similar to VMFS you can use a cluster filesystem like OCFS2...

You have a LUN from a SAN presented to all Proxmox nodes via FC or iSCSI? This is something that cannot be used with Ceph. Ceph uses local disks and replicates over the network. With a LUN you can use LVM as storage for the VMs.

This is normal. Ceph adds the size of the RocksDB device to the total size of the OSD. But since the RocksDB device cannot store any data it is computed as completely used. This is why you see a 10% usage on your fresh OSD. BTW: 80GB RocksDB device seems a little bit large for a 750GB HDD. And...

To create client keys for mounting CephFS use the command "ceph fs authorize". It will create the necessary capabilities for the key.

This will not work. The public network is called public for a reason: each client that wants to access the Ceph storage cluster needs to be able to talk to every node in each public network.

If you want to run MSSQL in a clustered setup use local storage for its nodes. There is no need to replicate on the storage level if the DB replicates its data on the application level.

You need to create OCFS2 on the shared LUN including an OCFS2 cluster on all nodes. Read the OCFS2 documentation for details. The OCFS2 filesystem is then mounted at the same mountpoint on all Proxmox nodes. In Proxmox you can then create a new storage of type directory with the shared flag set...

We are running such a setup with OCFS2 on the shared LUNs and qcow2 images in the filesystem for several years now. It works but is unsupported by Proxmox.

You really need your old cluster map extracted from the OSDs. As long as you are only deploying a new MON you create a new Ceph cluster. The existing OSDs will not be able to join it. The ceph.conf file does not matter here. It only tells the clients and the OSDs where to find the MONs.

You need to create the OCFS2 filesystem with "-T vmstore", which creates 1MB clusters for the files. Each time when a file needs to be enlarged, all nodes have to communicate so that they know about the newly allocated blocks. With larger cluster sizes this happens less often.

From kernel 6.5 to at least 6.8 there is an issue with OCFS2 and io_uring that produces IO errors inside the VM. Unfortunately OCFS2 is not well maintained.

There is OCFS2 which can be setup as clustered filesystem on a shared LUN. You need the 6.14 kernel and will get no official support.

With "# ceph-mon --monmap /root/monmap --keyring /etc/pve/priv/ceph.mon.keyring --mkfs -i nextclouda -m 10.0.1.1" you created a new MON database (--mkfs) and removed all info from the old one, not only the monmap. You should have just inserted the new monmap with "ceph-mon -i mon.nextclouda...

"wipefs -a" may be your friend.