Search results

don't do apt install ceph-mon manually. Either run pveceph install --version reef --repository {repo} or go via the GUI. This will install all the needed packages and dependencies on the Proxmox VE node.

Depends on what layer you want to benchmark ;) FIO has a Ceph RADOS backend AFAIK. If you check the 2023 Ceph Benchmark whitepaper (pinned post), you can use `rados bench` to benchmark the Ceph object layer. If you run tests within a VM, I would opt for FIO. Just keep in mind that you test the...

Evtl. ist das mpath device nicht früh genug da: https://pve.proxmox.com/wiki/Multipath#FC/SAS-specific_configuration

I would call it a workaround ;) You still have the cause of the split lock, most likely some application in a VM, but disabled the penalty slow down. But then again, that is most likely the only option unless you build and maintain that software yourself.

The node you are getting rid of will be destroyed in its current form right? So the node you want to keep would be the one on which you run these commands to take it out of the cluster. And as always, make sure you have current backups of the guests and documented any modifications. Just in...

https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pvecm_separate_node_without_reinstall With these steps, you should get it back into single-node mode.

Will it be fast and redundant? Keep in mind, that the Ceph Public network is the main Ceph network. The Ceph Cluster network is optional and can be placed on a different physical network to take load away. https://docs.ceph.com/en/latest/rados/configuration/network-config-ref/ The Full-Mesh...

The VMs act as Ceph clients and need access to the Ceph Public network. With both NICs down, that access is most likely not given anymore, therefore from the POV of the guest OS, the disk is not reacting to any IO. Well, the VMs cannot access their disk anymore. Therefore a hard stop will be...

That is a rather constructed scenario, where you intentionally removed both NICs. With one gone, everything would keep working. That is what that network setup can protect you from, but not if both are down. From the POV of Ceph, the node is gone and therefore the OSDs are shown as down and...

Did you see this in the Proxmox VE wiki page? https://pve.proxmox.com/wiki/Split_lock_detection

Yeah, looks like they go out, but never get a reply. Did you check that the router also has the /16 network setup correctly? No firewall rules that would prevent it or anything like that? Do you have other machines in the /16 network? Try pinging those to narrow down what the actual cause ist :)

Can the VMs ping the default gateway 10.20.4.1? If you run tcpdump on the host, do you see the ICMP packets? If so, only the outgoing ones? tcpdump -i vmbr0 icmp You probably need to install the tcpdump tool: apt install tcpdump.

So you only have one pool (we can ignore the Ceph internal .mgr) for now. Set the "target_ratio" value to 1. If you edit the pool in the web UI make sure that the "Advanced" checkbox next to the OK button is enabled. This tells the autoscaler (calculating the number of PGs for you) how much...

Yes, because you cannot choose. It will always be shown as "raw", but not stored as a file, but in the RBD, Cephs block device layer, which supports snapshots and such things. I cannot speak about the Bacula backup plugins due to lack of experience. We are working on a public backup API though...

Please keep in mind, that many storage options in Proxmox VE don't use files at all but expose it as a block device (similar to a physical disk) which will be presented to the VM as its disk. Therefore, the question Qcow or not will not even come up on these storage options (LVM, ZFS, Ceph...

This is regular networking. There can only be one default gateway to which the host (no the VMs, they have their own routing table), will send all packets for which it has no specific route. If you have other networks, that need to be reached via a different gateway that is not the default...

Two more options, besides what @leesteken suggested: first: enable the firewall on the datacenter or host level (the latter will only apply to the individual host) and disable all incoming, except with the 192.168.14.0/24 as source. (first the accept from that source, then the block/drop rule...

You will have a better chance searching for this or creating a new thread, instead of letting this evolve into different topics. Have you tried to run the suggested ssh-keygen command on that node? If that doesn't help -> new thread :)

okay, they've been running for a while :)

With with PVE version were the installed initially? If it was pre PVE 8 then you can install chrony manually: apt install chrony