Search results

You could use wipefs on that device and have it cleaned out. I just had to do that with 24 NVMe devices, which had been part of a former ZPOOL, before being re-purposed for a ceph storage.

This doesn't matter anyway, at least regarding the "issue" the op has. Any kind of shared storage is required to have HA in the first place. The guest runs on a pve node and if that nodes crashes, then so do all guests running on it, regardless of which storage the guest is stored on. Just...

Hi, I started to notice that pve nodes get fenced, when the swap space, provided by zramswap, becomes full. This only happens when the pve node is performing backups of its guests. In such a case, messages like these are to be found in the system log. A couple of RIP: 0010:_raw_spin_lock...

Reduced the bluestore_cache_size_ssd from 3GB to 2GB for the Ceph node with the tight memory situation and restarted all OSDs. This time, there where no OOM killers, while the backup ran. Interestingly, the amount of memory used on the system has slowly crept up to the same amount as it had...

Thanks for the offer. I have just had another instance of that and this time, I also got a fence notification. I probably did not take into account, that the guest, that runs our internal mail relay could have also been subject to be fenced together with the host it has been running on… duh…...

Hi, I have two separate PVE clusters: one hosts my Ceph storage, while the other hosts only the guests. The PVE nodes do have 2 1GbE and 2 10GbE interfaces, where the 10GbE ones are configured as a LACP bond. I had all the communication run over different VLANs on that bonds and this led to...

Soo… for me it was enough to restart the affected OSD, which made the error go away.

Can you elaborate on that "missing stanza"? I do face the same issue, after having to shut down one of m Ceph nodes, to move it physically to a new location. After bringing up all OSD and bringing them into the pool again, every pg synched up, but one didn't: root@iceph03-oh1c:~# ceph health...

Worked like a charm - thank you!

Just read on some other thread, that once all HA resources are deleted, it's necessary to restart the lrm daemon on each node like this… systemctl restart pve-ha-lrm We'll see, how it goes…

Hi, I am about to manually change the corosync config on my PVE cluster to introduce a 2ng Ring-Interface. I have read up on how to do that and although I am pretty sure, I got the config right, I was wondering if I could somehow prevent my nodes to be fenced, should I have messed up the new...

So - I think the issue came up since two of my nodes are on that network, which became unresponsive and I have already tried to figure out, how to change the ring0 address, such as that those nodes are in line with the others. I think, I do have some two options… I could either: remove these...

Ahh… I see… the daemon.log seems to hold some information on that… I will investigate that.

If that's the case, then I'd like to find out how that happened, of course, but there seems to be no information about this incident in the logs. At least not in /var/log/... Anything else, I can check about what happened? When I look at the messages sent by PVE, I would reckon, that only...

A couple of daya ago, we experienced an issue with a switch, which carried the corosync traffic for two of the 6 PVE hosts in our cluster. I can understand that PVE fenced those two hosts, but why did the other 4 ones rebooted as well? How can I fin out, what caused all my nodes to reboot...

Well, /etc/pve hosts PVE's cluster file system, which is an instance of a FUSE filesystem and that got somehow screwed. I'd check my network connections thoroughly - if proxmox can't access this file system, it'll likely fence itself and reboot.

This is surely not a regular behaviour. I have also setup two PVE clusters and also added nodes later on, and none of the other nodes rebooted itself. If your other cluster nodes rebootet, then there should be logs, which explain, what happened and why. E.g., I'd check the corosync logs…

Aww… sorry - you meant the gauges… yes, those seem all aggregated. I was talking about the summary, where this isn't the case.

Well, partially it is. Memory and Load seem to be aggregated, where as CPU isn't.

You can issue this query directly in influx after switching to your proxmox db. This is what this query spits out on my influx: > SHOW TAG VALUES FROM system WITH KEY=host WHERE object='nodes' name: system key value --- ----- host hades host hydra host pan host pandora host platon And...